看護事故警告システム
【構成】 状況（要因）、結果および頻度のデータを含むインシデントレポート分析表（３８）を知識データベース（３６）に記憶し、看護師の行動をモニタするセンサユニット（２０）などで、その分析表に挙げた状況ないし要因を検出する（ステップＳ１）と、サーバ（１２）は、ステップＳ３で、分析表で該当する結果は、頻度が高いかどうか判断する（ステップＳ３）。頻度が高いと判断したときステップＳ５で警告を発し、頻度が低いと判断したとき、ステップＳ７-Ｓ１１を実行して、公理が証明できるかどうか判断する。つまり、事故を起すかどうか予測する。事故の予測があれば、ステップＳ１３で警告するが、事故の可能性がないと予測したときは警告を発しない。
【効果】 頻度が低いときには、事故の可能性がないと予測したときは警告を発せず、事故の可能性があると予測したときだけ警告するようにしたので、看護師が「警告慣れ」になることはない。したがって、看護事故の発生が効果的に抑制できる。
【効果】 頻度が低いときには、事故の可能性がないと予測したときは警告を発せず、事故の可能性があると予測したときだけ警告するようにしたので、看護師が「警告慣れ」になることはない。したがって、看護事故の発生が効果的に抑制できる。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は看護事故警告システムに関し、特にたとえば、看護師による看護事故の発生を予測して警告する、看護事故警告システムに関する。
【背景技術】
【０００２】
医療事故や看護事故を未然に防止するための様々なシステムや方法が提案されている。
【０００３】
その１つが、特許文献１に開示されているシステムである。特許文献１に開示されているシステムは、インシデントレポートにより報告された各インシデントについて、慣れに基づく行為に関するエラー、規則に基づく行為に関するエラーなどのエラー種別と、環境施設、作業環境、作業要因、個人要因などの直接誘因と、医療情報管理上の問題、労務管理上の問題などの間接誘因とのそれぞれからそのインシデント発生に最も寄与した要因を抽出し、それらを関連付けた連関鎖を定義するとともに、看護業務に関係なく各連関鎖の出現率を計算し、その出現率を参考にして対応する優先順位を決め、その医療施設特有の組織文化やマネージメント上の問題を見つけ出し、それを解決する対応策を立案することによって医療事故の危険性を大幅に軽減することができるようにしようとするものである。
【特許文献１】特開２００３−９１６００[Ｇ０６Ｆ １７／６０]
【発明の開示】
【発明が解決しようとする課題】
【０００４】
特許文献１におけるシステムでは、出現率によって優先順位を決めるため、必然的に、出現率の高い要因に注目するものであり、出現率の低い要因については見過されてしまう可能性がある。
【０００５】
一方、事故が起きる一般的傾向すなわち頻度は低くても問題となる事故の可能性がない訳ではないので、頻度が低い状況であっても、事故防止の観点からは、看護師に警告を与えることが望ましい。しかしながら、頻度が低い場合に全て警告を発すると、たとえば、警告を発したのに事故がなかった場合などに看護師がだんだん慣れて、しまいにはその警告を無視するような状態（警告慣れ）にもなってしまう。これでは何のための警告システムかわからない。
【０００６】
したがって、事故につながる可能性の状況だけに警告を与えるのが望ましい。
【０００７】
それゆえに、この発明の主たる目的は、新規な看護事故警告システムを提供することである。
【０００８】
この発明の他の目的は、事故につながる可能性の状況だけｉ警告を与えることができる、看護事故警告システムを提供することである。
【課題を解決するための手段】
【０００９】
請求項１の発明は、インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を記憶する第１記憶手段、分析表に挙げられている状況が発生したかどうかを検出する状況検出手段、状況検出手段によって検出した状況について分析表を参照して頻度が高いかどうか判断する頻度判断手段、頻度判断手段によって頻度が低いと判断したとき事故を起すかどうか予測する予測手段、および予測手段によって事故の可能性がないと予測したときは警告を発せず、予測手段によって事故の可能性があると予測したときは警告を発する第１警告手段を備える、看護事故警告システムである。
【００１０】
請求項1の発明では、第１記憶手段（実施例中での知識データベース３６、インシデントレポート分析表３８に相当する。）にインシデントレポートを分析し、状況（要因）、結果、そして頻度を含む分析表を記憶しておく。一例として実施例のサーバ１２である状況検出手段は、モニタ手段から得られるモニタデータに基づいて、その分析表にリストアップされた状況が発生したかどうか判断する(ステップＳ１)。同じく実施例のサーバ１２が機能する頻度判断手段は、その分析表を参照して、当該検出した状況が事故につながる頻度が高いか低いか判断する(ステップＳ３)。頻度か低いときには、看護事故につながる可能性はあるものの、本当に事故を起すかどうか、予測手段（サーバ１２）によって推論または予測する(ステップＳ７-Ｓ１１)。予測手段が、看護事故を予測したとき、第１警告手段（１２、Ｓ１３）が警告を発する。
【００１１】
したがって、請求項１の発明によれば、看護事故を結果的に招来する可能性がある状況を検出しても、頻度が低いときには、事故が予測できるときだけ警告する。
【００１２】
請求項２の発明は、頻度判断手段によって頻度が高いと判断したとき警告を発する第２警告手段をさらに備える、請求項１記載の看護事故警告システムである。
【００１３】
請求項２の発明では、第２警告手段（実施例ではサーバ１２とステップＳ５が相当する）は、検出した状況が事故につながる可能性が大（高頻度）のときには、予測なしに、直ちに警告を発する。したがって、看護事故の発生が防止できる。
【００１４】
請求項３の発明は、看護師の行為をモニタしてモニタデータを得るモニタ手段をさらに備え、状況検出手段はモニタデータに基づいて状況を検出する、請求項１または２記載の看護事故警告システムである。
【００１５】
請求項４の発明は、少なくとも看護業務における公理を記憶するとともに、その公理の成立に影響を与える仮説データを記憶する第２記憶手段をさらに備え、予測手段は、モニタ手段から得られるモニタデータに基づいて仮説データを参照して公理が成立するかどうかで事故の可能性を予測する、公理成立判断手段を含む、請求項３記載の看護事故警告システムである。
【００１６】
請求項４の発明では、たとえば実施例の知識データベース３６中の推論用データベース４０が第２記憶手段であり、この第２記憶手段には、公理データ領域４２ａと仮説データ領域４２ｂとが設けられ、それぞれに、公理や仮説データが設定されている。実施例のサーバ１２であってよい、予測手段は、モニタ手段から得られるモニタデータに基づいてその仮説データを参照して、患者に対する処置の理想状態を結果的に得るための公理が成立するかどうかで事故の可能性を予測する。
【００１７】
請求項５の発明は、インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を用いて看護事故に対して警告を行なう看護事故警告方法であって、分析表に挙げられている状況が発生したかどうかを検出する状況検出ステップ、状況検出ステップによって検出した状況について分析表を参照して頻度が高いかどうか判断する頻度判断ステップ、頻度判断ステップによって頻度が低いと判断したとき事故を起すかどうか予測する予測ステップ、および予測ステップによって事故の可能性がないと予測したときは警告を発せず、予測手段によって事故の可能性があると予測したときは警告を発する警告ステップを含む、看護事故警告方法である。
【００１８】
請求項６の発明は、インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を記憶手段に記憶したコンピュータによって看護事故に対して警告を行なう看護事故警告プログラムであって、コンピュータに、分析表に挙げられている状況が発生したかどうかを検出する状況検出ステップ、状況検出ステップによって検出した状況について分析表を参照して頻度が高いかどうか判断する頻度判断ステップ、頻度判断ステップによって頻度が低いと判断したとき事故を起すかどうか予測する予測ステップ、および予測ステップによって事故の可能性がないと予測したときは警告を発せず、予測手段によって事故の可能性があると予測したときは警告を発する警告ステップを実行させる、看護事故警告プログラムである。
【発明の効果】
【００１９】
この発明によれば、頻度が低いときに、事故の可能性がないと予測したときは警告を発せず、事故の可能性があると予測したときだけ警告するようにしたので、看護師が「警告慣れ」になることはない。したがって、看護師がシステムからの警告を常に真摯に受け止める環境になるため、看護事故の発生が効果的に抑制できる。
【００２０】
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【発明を実施するための最良の形態】
【００２１】
図１を参照して、この発明の一実施例である看護事故警告モニタシステム１０は、たとえば病院に適用され、サーバ１２を含む。このサーバ１２は、有線或いは無線による通信回線（ネットワーク）１４を介して複数の看護師用端末（以下、単に「端末」という。）１６および複数のステーション１８に接続される。端末１６は、パーソナルコンピュータ或いはワークステーションのようなコンピュータであり、看護師毎に割り当てられる。たとえば、端末１６は看護師の詰所などに設置される。ただし、１台の端末１６を数人の看護師で使用する場合もあり得る。複数のステーション１８は、それぞれ、入院患者を収容する病棟内であり、廊下、病室（入り口、ベッド或いはその近傍）および看護師の詰所などの所定位置に配置され、無線通信可能なウェアラブルセンサユニット（以下、単に「センサユニット」という。）２０の識別情報を取得し、サーバ１２に送信する。複数のセンサユニット２０は、それぞれ、看護師に割り当てられ（装着され）、センサユニット２０の識別情報は、無線通信可能な範囲（たとえば、半径３〜５メートル）に存在するステーション１８によって検出される。また、ステーション１８とセンサユニット２０とは互いに通信可能であるため、センサユニット２０は、無線通信可能な範囲に存在するステーション１８の識別情報（ステーションＩＤ）を検出する。図示は省略するが、センサユニット２０は、センサユニット２０同士で無線通信することが可能であるため、無線通信可能な範囲に存在する２以上のセンサユニット２０同士で、互いの識別情報を検出することもできる。また、センサユニット２０は、無線ＬＡＮによってネットワーク１４に直接接続される場合もある。
【００２２】
図２はサーバ１２の具体的な構成を示すブロック図であり、この図２を参照して、サーバ１２には、図１では省略したが、複数の対物センサ２２、複数の集音マイク２４、および複数のビデオカメラ２６などが接続される。
【００２３】
図示は省略するが、この実施例では、複数の対物センサ２２は、体温計、血圧計、注射器、点滴注射器（注入器）、血液採取用試験管、検尿コップなどの医療器具を格納してある格納箱の取り出し部分やナースコール端末などに設置され、それらの医療器具等についての使用（取り出し）の有無を検知する。ただし、これらの医療器具等には、タグ情報やバーコードのような識別情報を付加しておき、タグ情報やバーコードを読み取ることにより、その使用の有無を検出するようにしてもよい。
【００２４】
また、複数の集音マイク２４は、入院患者を収容する病棟内であり、廊下および病室（ベッド或いはその近傍）などに設置され、周囲音を集音する。
【００２５】
なお、複数のビデオカメラ２６は、看護師の行動を記録するために用いられ、このビデオカメラ２６からの動画および／または静止画のデータがサーバ１２に蓄積される。ただし、そのようなカメラ２６は、たとえば、看護詰め所、廊下、病室などに設けられる。
【００２６】
また、図１では省略したが、サーバ１２には、複数のデータベース（データベース）が接続される。具体的には、看護師データベース２８、病棟イベントデータベース３０、所在情報データベース３２、電子カルテデータベース３４および知識データベース３６が接続される。
【００２７】
看護師データベース２８は、看護師の一日の業務おける行動についてのデータ（看護師データ）を看護師毎に記録する。看護師データには、たとえば、ラベルとして看護師名が記述され、看護師名の横に日付が記述される。看護師名および日付の下側には、当該看護師の看護業務に関する項目（内容）が記述される。つまり、看護業務の開始時刻、看護業務の終了時刻、看護業務の対象患者、看護業務の内容、看護業務における歩数、看護業務における傾斜（上半身（上体）を傾ける）角度の平均値および医療ミス等の業務における事故（アクシデント・インシデント）がそれぞれ記述される。このような看護師データでは、基本的には、センサユニット２０で計測されるデータから取得される。
【００２８】
病棟イベントデータベース３０は、複数のセンサすなわち上述した複数の対物センサ２２から得られる対物検知データ、複数の集音マイク２４から得られる音データおよびビデオカメラ２６から得られる画像データ（これらのデータをまとめて「病棟イベントデータ」という。）を記録する。対物検知データには、検知する対象となる医療器具等の名称のような識別情報がタグとして付される。音データには、集音マイク２４の設置場所を示す識別情報がタグとして付される。画像データには、ビデオカメラ２６の設置場所を示す識別情報がタグとしてとして付される。つまり、対物検知データから検知対象物を特定することができ、音データや画像データのタグから集音したり画像を取得した場所を特定することができる。
【００２９】
さらに、サーバ１２は、情報のような病棟イベントデータを取得した時間（時間データ）を、内蔵される時計回路１２ａから取得して、当該病棟イベントデータに付加する。
【００３０】
たとえば、対物検知データの入力があると、サーバ１２は当該対物検知データに時間データを付加して、病棟イベントデータベース３０に記録する。集音マイク２４は、たとえば、物が落下したときに生じる音や、人間が発した大声などを集音することを目的とするため、所定のレベル以上の音が入力されたときに、当該音に対応する音データがサーバ１２に入力され、サーバ１２は当該音データに時間データを付加して、病棟イベントデータベース３０に記録する。ただし、基本的にはタイムラプス(間欠記録)ではあるものの、時系列的に画像データが蓄積される。
【００３１】
所在情報データベース３２には、看護師についての所在情報のデータ（所在情報データ）が記録される。後で詳細に説明するが、所在情報データは、看護師のそれぞれが装着するセンサユニット２０に割り当てられたタグ情報のような識別情報（看護師ＩＤ）と、当該看護師ＩＤを検出したステーション１８のタグ情報すなわち識別情報（ステーションＩＤ）とを時系列に従って記録したデータである。また、上述したように、ステーション１８とセンサユニット２０とは互いに通信するため、所在情報データは、センサユニット２０で検出したステーションＩＤを時系列に従って記録したデータも含む。さらに、上述したようにセンサユニット２０同士は無線通信可能であり、各センサユニット２０に割り当てられた看護師ＩＤと、当該センサユニット２０と無線通信したセンサユニットの看護師ＩＤとを時系列に従って記録したデータも含まれる。この所在情報データによって、看護師の所在（行動）を知ることができる。たとえば、何時何分何秒にどこ（病室、詰所または廊下など）に居たかを知ることができ、また、何時何分何秒にどの看護師と一緒に居たか或いはすれ違ったか等を知ることができる。
【００３２】
電子カルテデータベース３４には、現在入院中或いは治療中の患者についての電子カルテが記録される。図示は省略するが、この電子カルテは、医師等が記載するカルテの内容から必要な事項を抽出するとともに、必要な事項を追加して、電子データにしたものである。たとえば、電子カルテには、患者名、担当看護師名（看護師カテゴリ番号）、性別、病名、病状、処方（どのような注射や点滴、あるいは投薬をするかという処方）、リハビリの状況、入院暦、患者に対する注意事項などの情報のデータ（テキストデータ）が記述されるとともに、このテキストデータに当該患者についての患者カテゴリ番号がラベルとして付される。したがって、患者が特定されると、その患者カテゴリ番号に応じて、当該患者についての電子カルテを特定することができる。
【００３３】
第１記憶手段や第２記憶手段として機能する知識データベース３６には、図３および図４に示すデータベースが蓄積されている。
【００３４】
図３に示すインシデントレポート分析表３８は、インシデントレポート（看護師等から報告される、医療看護業務に関する何らかのミスや誤った業務行為のこと）を分析した結果をテーブル形式にまとめたものであり、状況（または要因）とそれによって生じた結果を含む。さらに、第１記憶手段としてのこの分析表３８には、必要に応じて、その結果を生じる前提条件を記録する。たとえば、環境が変わると誤った行為が行なわれる結果になるが、それは、環境に順応できていない、という前提条件の下に生じた結果であり、環境に順応できていれば、誤った行為を行うこともない。たとえば、それぞれの病院にはそれぞれのシステムがあるが、他の病院からきた看護師は、前の病院でのルールがそのまま使えると思い込んだ結果、誤った行動をする。
【００３５】
この分析表３８において特徴的なことは、上述のような状況や結果の他に、頻度のデータを併せて記録していることである。ここで、「頻度」とは、事故の起きる一般的傾向のことであり、たとえば、看護師のある行動ないし行為またはそれによる状況が事故につながる可能性が高い場合には、その状況は頻度が高いといい、必ずしも事故につながるものではないが、事故の可能性がまったくないというものでもない場合を、その状況は頻度が低いという。
【００３６】
この図３に示す、頻度データ付インシデントレポート分析表３８に挙げた結果、すなわち「誤った行為」、「伝達の誤り」、「誤った作業」などはすべて、頻度の高低はあるものの、看護事故につながるものである。したがって、後に説明するセンサユニット２０によってこの表に挙げた状況または要因を検出またはモニタしたときには、サーバ１２（図１）は、警告を発する。ただし、頻度が低い場合でもすべて警告を発すると、警告慣れが生じて好ましくないので、この実施例では、頻度が高いときには必ず警告を発するが、頻度が低いときには、事故が起きるかどうか予測しまたは推論（abduction：アブダクション）を行い、事故が予測できるときだけ、警告を発することにしている。
【００３７】
このような予測または推論のために、図４に示す、推論用データベース４０が利用される。この推論用データベース４０は、第２記憶手段として、図２に示す知識データベース３６に設定されている。
【００３８】
推論用データベース４０には、公理（該当の患者に対する処方または処置の理想状態が必然的に得られる事象、行為、または要素などとその理想状態の因果律、さらにもっと一般的に言えば、どのような場合でも関係が崩れることがない、そのような関係のことである）を設定しておくための公理データ領域４２ａと、仮説（モニタ手段やＲＦＩＤなどで観測またはモニタ可能な事象、行為、要素など、可変なもの、同時に成り立たない可能性があるもの（イベント））を設定しておく仮説データ領域４２ｂとが設けられる。
【００３９】
図４の公理データ領域４２ａに例示されている３つの公理について、ここで説明する。ただし、「∧」は論理であり「ａｎｄ」を示す。
【００４０】
最初の公理は、変数項としてコンテンツ（Ｘ）（Ｘ：変数）を検出し、イベントとして蒸留水を検出し、別のイベントとして看護師が注射をしようとしていことを検出したとき、そのときの患者に対する処置の理想状態が達成できることを示している。Ｘは変数であるが、たとえば、Diamoxという注射用薬剤であるとすると、Diamox注射という、その患者にとっての理想状態が実現できることを示す。
【００４１】
公理の２番目は、イベントとして、アミノフリードパックを検出し、その輸液パックを混注することによって、コンテンツ（Ｘ）、Ｘ＝アミノフリードが検出できるので、行為（do点滴）によって、そのときの患者に対する処置の理想状態（アミノフリードの点滴）が達成できることを示している。
【００４２】
例示の最後の公理は、変数Ｘとインシュリンとのミキシングを検出し、さらに、コンテンツ（Ｚ）＝（抑圧剤インシュリン混合）をモニタすれば、行為（do点滴）によって、そのときの患者に対する処置の理想状態（インシュリン混合の点滴）が達成できることを示している。
【００４３】
なお、仮説データ領域４２ｂの各事象、行為、ないしは要素は、すべて、モニタ手段でモニタできる。たとえばコンテンツ（Ｘ：Ｘ＝変数）は看護師がたとえば薬品棚から取り出したものを、たとえばＲＦＩＤ（赤外線タグ）で検出するか、さらにはビデオカメラ２６で取得した画像データを分析または解析することによって、検出することができる。
【００４４】
また、看護師の行為「do…」も同様に、ビデオカメラ２６からの画像データの分析によって、あるいはＲＦＩＤのデータから検出することができる。
【００４５】
その他、「蒸留水」、「Diamox」、「生理食塩水」などのイベントも同様にして検出することができる。
【００４６】
ここで、モニタ手段の一部として機能するウェアラブルセンサユニット２０の詳細なブロック図が図５に示される。
【００４７】
この図５を参照して、センサユニット２０はＣＰＵ４４を含む。ＣＰＵ４４には、Ａ／Ｄ変換器４６，４８，エンコーダ５０，非接触センサ５２，インターフェイス５４，カードスロット５６，時計回路５８，ＤＩＰスイッチ６０，無線送信機６２および無線受信機６４が接続される。Ａ／Ｄ変換器４６には歩数計６６が接続され、Ａ／Ｄ変換器４６は、歩数計６６から入力される歩数をディジタルデータ（バイナリデータ）に変換してＣＰＵ４４に入力する。また、Ａ／Ｄ変換器４８には傾斜角センサ６８が接続され、Ａ／Ｄ変換器４８は、傾斜角センサ６８から入力される傾斜角（角度）をディジタルデータ（バイナリデータ）に変換してＣＰＵ４４に入力する。エンコーダ５０にはマイク７０が接続され、エンコーダ５０は、マイク７０から入力される音声信号をＭＰ３のような圧縮音声データ（以下、単に「音声データ」という。）に変調してＣＰＵ４４に入力する。このように、音声信号を圧縮変調するのは、後述するメモリカード７２の容量を考慮したためであり、このような記録媒体の容量を無視できる場合には、単にディジタルデータに変換するだけでもよい。
【００４８】
非接触センサ５２としては、焦電センサを用いることができ、ＣＰＵ４４は非接触センサ５２からの入力に応じてマイク７０をオン／オフする。この実施例では、非接触センサ５２すなわち焦電センサの前で、看護師が手を２回上下させると、その検出信号がＣＰＵ４４に入力され、これに応じて、ＣＰＵ４４はマイク７０をオンし、その後、看護師が焦電センサの前で、手を２回上下させると、マイク７０をオフする。ただし、ＣＰＵ４４は、看護師の操作によらないで、所定時間（１０秒）が経過した場合にもマイク７０をオフするようにしてある。この実施例では、マイク７０としては、ヘッドセットタイプのものが用いられ（図６参照）、また、指向性を有する。これは、看護師の音声を正確に入力するとともに、患者のプライバシーを守るためである。
【００４９】
インターフェイス５４は、ＬＡＮ（無線ＬＡＮ）アダプタのようなインターフェイスであり、これにより、センサユニット２０はネットワーク１４に直接接続される。ただし、ＲＳ２３２ＣやＵＳＢのようなインターフェイスを設けて、ケーブルを用いることにより、サーバ１２或いは端末１６のような他の端末に通信可能に接続することもできる。
【００５０】
カードスロット５６には、ＭＭＣのようなメモリカード７２が着脱自在に設けられる。このメモリカード７２には、このセンサユニット２０で検出或いは取得されるデータ（歩数データ、傾斜角データ、音声データ）が記憶される。また、メモリカード７２に記憶されたデータは、メモリカード７２をサーバ１２或いは端末１６のような他の端末に装着することにより、当該他の端末に移動（コピー）することができる。
【００５１】
時計回路５８は、日付および時刻を計時する回路であり、ＣＰＵ４４は、時計回路５８から取得した時間データを、各センサ（５２，６６、６８、７０）から取得したデータや看護師ＩＤのデータに付加して、メモリカード７２に記憶する。また、必要に応じて、時間データを付されたデータは、インターフェイス５４を介してネットワーク１４に接続されるサーバ１２または端末１６或いはその両方に出力される。
【００５２】
ＤＩＰスイッチ６０は、たとえば８ビットで構成され、各ビットのオン／オフを切り替えることにより、０〜２５５の間で数値を設定することができる。この数値が識別情報すなわち看護師ＩＤであり、各センサユニット２０で異なる値が設定される。ＣＰＵ４４は、看護師ＩＤをラベルとして付するとともに、時間データを付加したデータを、メモリカード７２に記憶したり、サーバ１２に転送したりする。
【００５３】
ただし、ＤＩＰスイッチ６０に代えて、メモリカード７２に看護師ＩＤを記憶させておくようにすることもできる。また、ＤＩＰスイッチ６０に代えて、看護師ＩＤを記憶したＲＯＭなどを設けておくようにすることもできる。
【００５４】
無線送信機６２は、ＣＰＵ４４の指示に従って、ＤＩＰスイッチ６０または別の手段によって設定された看護師ＩＤを所定の周波数による電波（微弱電波）で送信する。無線受信機６０は、無線通信可能な範囲に存在する他のセンサユニット２０から送信される微弱電波を受信し、看護師ＩＤに復調し、復調した看護師ＩＤについてのデータをＣＰＵ４４に入力する。
【００５５】
ここで、ステーション１８は、上述したように、センサユニット２０の看護師ＩＤを検出し、検出した看護師ＩＤを、ネットワーク１４を介してサーバ１２に送信する。また、ステーション１８にも識別情報（ステーションＩＤ）が割り当てられ、上述したように、このステーションＩＤがセンサユニット２０によって検出される。したがって、たとえば、ステーション１８は、センサユニット２０の一部の回路コンポーネントを用いることにより、構成することができる。具体的には、ステーション１８は、ＣＰＵ４４，インターフェイス５４，ＤＩＰスイッチ６０，無線送信機６２および無線受信機６４によって構成される。
【００５６】
なお、ＤＩＰスイッチ６０に代えて、ステーションＩＤを記憶したＲＯＭを設けるようにしてもよい点は、センサユニット２０の場合と同様である。
【００５７】
上述したような構成のセンサユニット２０は、各看護師に装着される。たとえば、図６に示すように、非接触センサ５２，歩数計６６，傾斜角センサ６８およびマイク７０以外の回路コンポーネントはボックス（筐体）７４に収容され、ボックス７４は看護師の腰部（ベルト部分）に装着される。また、非接触センサ５２および傾斜角センサ６８は、ペン型のケース７６に収容され、看護師の衣服（白衣）の胸ポケットに挿すように収納される。ただし、図面では、分かり易く示すために、ケース７6を胸ポケットの外部に記載してある。また、歩数計６６は、上述のボックス７４と同様に看護師の腰部に装着される。さらに、マイク７０は看護師の頭部に装着される。
【００５８】
なお、図６においては省略するが、非接触センサ５２は接続線を用いてボックス７４内のＣＰＵ４４に接続され、歩数計６６，傾斜角センサ６８およびマイク７０は、それぞれ、接続線を用いてボックス７４内のＡ／Ｄ変換器４６，Ａ／Ｄ変換器４８およびエンコーダ５０に電気的に接続される。ただし、接続線を用いずに、ブルートゥースのような近距離無線によって接続するようにしてもよい。つまり、電気的に接続されればよいのである。
【００５９】
また、図６に示すように、看護師は、たとえば、白衣の前ポケットに携帯型のコンピュータ（この実施例では、ＰＤＡ）７８を収納し、所持（携帯）している。図示は省略するが、ＰＤＡ７８は、無線ＬＡＮによって、図１に示したネットワーク１４に接続可能な構成にされる。ＰＤＡ７８は既に周知であるため、その構成および動作等の詳細な説明は省略することにする。なお、図面では、分かり易くするため、前ポケットの外部に示してある。
【００６０】
たとえば、看護師の操作によって、センサユニット２０の主電源がオンされると、ＣＰＵ４４は、傾斜角センサ６８からの入力を所定時間（この実施例では、５００ｍｓ）毎に検出する。上述したように、マイク７０は、非接触センサ５２の入力に応じて、そのオン／オフが制御される。また、ＣＰＵ４４は、マイク７０がオフされているとき、歩数計６６からの入力を有効化する。
【００６１】
したがって、ＣＰＵ４４は、歩数計６６によって計測された歩数のデータ（歩数データ），傾斜角センサ６８によって計測された角度のデータ（角度データ）およびマイク７０で検出された音声のデータ（音声データ）を、識別してメモリカード７２に記憶するとともに、無線ＬＡＮによって他の端末（この実施例では、サーバ１２）に送信する。また、ＣＰＵ４４は、歩数データ、角度データおよび音声データを記録する場合には、各データの取得開始時刻および取得終了時刻についての時間データを時計回路６０から取得し、各データに当該時間データを付すようにしてある。
【００６２】
なお、ウェラブルセンサユニット２０によって取得した上述のような行動データ、さらには先に述べたビデオカメラ２６などで取得した行動データは、最終的には、すべてサーバ１２およびそれぞれの関連データベース（図２）に記録される。
【００６３】
たとえば、看護師ｎが患者ｋさんの患者訪問を行う場合には、看護師ｎが「患者ｋさんの（患者）訪問に行きます。」と発話した内容、患者ｋさんの病室を往復する間の歩数および当該病室を往復する間に上半身を傾斜した際の角度（傾斜角度）のそれぞれについてのデータが記録される。また、このデータに，看護業務の開始時刻および終了時刻の時間データが付加される。
【００６４】
このような音声，歩数および傾斜角度についてのデータおよびこれらに付される時間データ（以下、これらをまとめて「計測データ」ということがある。）は、看護師ｎの１日の業務のすべてについて取得される。上述したように、センサユニット２０は、無線ＬＡＮ（ネットワーク１４）によって接続され、したがって、上述のようにして取得された１日の業務についての計測データ（業務計測データ）は、センサユニット２０から端末１６に送信（転送）することができる。また、メモリカード７２を端末１６に着脱自在にすれば、業務計測データを直接端末１６に入力することができる。
【００６５】
端末１６は転送された業務計測データを受信し、たとえば、看護師の操作によって、その業務計測データはサーバ１２にアップロードされる。サーバ１２は、アップロードされた業務計測データに基づいて、アクシデント・インシデントを除く看護師データを作成する。つまり、看護師を特定し、その後、各計測データからアクシデント・インシデントを除く看護師データの項目を特定（決定）して、記録する。
【００６６】
ただし、業務計測データは、センサユニット２０からネットワーク１４を介してサーバ１２に直接アップロードされるようにしてもよい。
【００６７】
たとえば、看護師は、センサユニット２０から転送される業務計測データに付された看護師ＩＤに基づいて、サーバ１２側で容易に特定することができる。
【００６８】
また、計測データに含まれる音声データは、音声認識処理を施され、認識した音声から患者名や当該患者に対して行った看護業務が特定される。つまり、サーバ１２は、音声認識機能を備えており、また、音声認識のための辞書すなわち複数の発話（音声）に対応する音声データを記録したメモリ（たとえば、ハードディスクやＲＯＭ）を有している。ただし、看護師の音声データは、一例として、看護師データベース２８に記録される。
【００６９】
図７は図１実施例においてサーバ１２の動作を示すフローチャートであり、このフローチャート（プログラム）は、一例として、サーバ１２の内部メモリ（ＲＯＭまたはＲＡＭ：図示せず）に設定されている。
【００７０】
ここで、この図７を参照して、図１実施例の看護事故警告システム１０の特にサーバ１２の動作について説明する。サーバ１２は、動作を開始した後、ステップＳ１で、先の図３の分析表３８に挙げた状況（または要因）を検出したかどうか判断する。このような状況が発生したかどうかは、ビデオカメラ２６やセンサユニット２０を含むモニタ手段からの画像データ、音声データ、さらにはＲＦＩＤデータなどから検出できる。たとえば「作業の中断」という状況は次のように判断できる。ＲＦＩＤデータで看護師が注射器を持ったことがわかり、該当する看護師を撮影しているビデオカメラ２６からの画像データを解析すれば、看護師がその注射器で注射の準備をしていることがわかる。集音マイク２４の音声データを解析することによって、たとえば医師か患者かに呼びつけられたことがわかる。その後、歩数計６６のデータを見れば、誰かに呼ばれた時刻より後に、看護師が歩行したことが検出でき、したがって、先の作業（注射の準備）が中断したことが検出できる。分析表３８にリストアップされている他の「状況」についても、同様にして、検出することができる。
【００７１】
また、たとえば、「似た苗字の患者」の存在、「同姓同名の患者」の存在、あるいは「兄弟（姉妹）」の患者の存在などは、電子カルテ３４からのデータで判断できる。
【００７２】
サーバ１２がステップＳ１で、分析表３８に挙げられた状況を検出した後、サーバ１２は、続くステップＳ３で、その分析表３８を参照して、ステップＳ１で検出した「状況」による事故の発生頻度が高いのか低いのか判断する。検出した状況の結果が、たとえば誤った行為、伝達の誤りなどであれば看護事故につながりやすいので、このステップＳ３で“ＹＥＳ”が判断され、たとえば作業の中断や作業の交代などの状況の場合には頻度が低いので、ステップＳ３では“ＮＯ”が判断される。
【００７３】
ステップＳ３で“ＹＥＳ”のときには、看護事故が発生する可能性が高いので、サーバ１２は、ステップＳ５において、図１に示すネットワーク１４を介して看護師用端末１６に警告を送る。ただし、看護師端末１６を当該看護師が見ていないことも考えられるので、そのときには、その看護師端末１６から、もしくはサーバ１２から直接、看護師のヘッドセット（図５および図６のマイク７０と図示しないイヤホンとが一体化させたもの）のイヤホンを利用して看護師に音声で警告を与えるようにしてもよい。また、ヘッドセットに代えて、またはそれと併用して、たとえば振動付き腕時計型表示器を看護師に装着させ、その表示器に看護師端末１６からか、もしくはサーバ１２から直接警告を送るようにしてもよい。
【００７４】
ステップＳ３で“ＮＯ”を判断した後、つまり、ステップＳ１で検出した状況から事故の発生の頻度が低いとき、サーバ１２は、直ちに無条件に警告を発するのではなく、看護事故につながる可能性に応じて、警告を発するようにする。つまり、サーバ１２は、続くステップＳ７、Ｓ９、およびＳ１１を実行することによって、当該「状況」から看護事故が起きる可能性があるかどうか予測または推論し、その結果、事故が予測できるときには警告する。
【００７５】
具体的には、まずステップＳ７において、サーバ１２は、図４に示す公理データ領域４２ａを参照して、そのときの患者に対する処置の理想状態、たとえば図４の公理データ領域４２ａの右端の項目を調べる。そして、ステップＳ９で、そのときにモニタ手段当から入力されている看護師の行動データやその他イベント（事象）を、図４に示す仮説データ領域４２ｂからピックアップする。そして、ステップＳ１１において、そのとき生じているイベントから上記理想状態が成立するかどうか、つまり、公理が証明できるかどうか判断する。ここで、公理が証明できれば、事故の発生の可能性はなく、したがって、そのまま終了する。しかしながら、ステップＳ１１で、サーバ１２が、そのときモニタしているイベントでは理想状態は成立しないと判断したときは、看護事故の可能性があるので、続くステップＳ１３（第１警告手段）で、先のステップＳ５（第２警告手段）と同様にして、看護師に警告を発する。
【００７６】
ただし、第１警告手段では、ステップＳ１１において“ＹＥＳ”を判断したとき、つまり事故を予測しないときには、警告を発しない。つまり、第１警告手段では、予測結果によって、警告を発したり、しなかったりする。
【００７７】
以下に、３つの具体例を用いて、このシステム１０の動作について説明する。
【００７８】
具体例１（核医学検査はキャンセルが多いので、蒸留水のみ注射器に吸って準備し、ダイアモックス（Diamox）は直前に溶解しようと思い、箱から出して注射器のそばにおいた。検査が順々に進められていくうちに、溶解してあるものと思い込んでしまって、医師に渡してしまった。）
この第１の具体例では、図７のステップＳ１で分析表３８中の状況「作業の中断」が検出される。看護行為は上で説明したように常時モニタされているので、モニタ手段からのデータに基づいてサーバ１２が「作業の中断」を検知することができる。
【００７９】
看護師の作業の中断が生じると、図３の分析表３８にもあるとおり、看護事故につながる可能性がある。しかしながら、頻度が「低」であるので、いきなり警告することはしないで、図７のステップＳ７−Ｓ１１を実行して、本当に事故が起こるかどうか予測する。
【００８０】
この具体例の場合、看護メモや電子カルテを参照することにより、図７のステップＳ７で、該当の患者（患者ＩＤ＝１２３４５６）に対する処置の理想状態は「注射（Diamox）」であることがわかる。そして、図７のステップＳ９で、その理想状態「注射（Diamox）」を現在得られているモニタデータを用いて仮説集合から予測する。このステップＳ９でのモニタデータ（イベント）は上述のようにモニタ手段から獲得できる。そして、ステップＳ１１で、その仮説集合から理想状態が説明できるかどうか、つまり公理が成立するかどうか推論する。
【００８１】
ここで、「蒸留水」、「do注射」のモニタデータだけが得られた場合を考える。上述の理想状態「注射（Diamox）」の達成のためには、図４からわかるとおり、仮説データとしてcontent(X)、X=Diamoxが必要であるが、Diamoxはモニタされていないので、content(Diamox)が支持できない。したがって、理想状態が説明できない。したがって、図７のステップＳ１１では、看護事故の生じる可能性があるので、あるから“ＮＯ”を判断することになる。したがって、ステップＳ１３で警告が看護師に送られ、Diamoxを使用しないと看護事故を起すと警告する。
【００８２】
この具体例の場合に、イベント（仮説データ）として「生理食塩水」、「蒸留水」、「do注射」がモニタされたときにも、Diamoxはモニタされていないので、ステップＳ１１で“ＮＯ”を判断し、ステップＳ１３で、看護師に、たとえば生理食塩水の代わりにDiamoxを使わないと事故を起す、と警告する。
【００８３】
ただし、「Diamox」、「蒸留水」、「do注射」のイベントがモニタされたときには、content(X)においてXにDiamoxが代入できるため、ステップＳ１１で、理想状態の説明が可能となる。したがって、ステップＳ１３で“ＹＥＳ”となり、看護事故の可能性がないので、「作業の中断」という看護事故につながる状況を検出したにも拘らず、警告はしない。
【００８４】
具体例２（ＩＶＨメニューの変更があり、主治医が準備を行い、看護師が中心静脈注射のパックの更新をした。上層と下層とが混ぜられておらず、深夜勤務者に指摘されて気付く。これらの輸液パックは、上室がアミノ酸、下室が糖・電解質で、開通しない場合には、１１％の高カロリの糖輸液が行なわれることになり、危険な状態を惹起する。）
この第２の具体例では、図７のステップＳ１で分析表３８中の状況「作業の交代」が検出される。看護行為は上で説明したように常時モニタされているので、モニタ手段からのデータに基づいてサーバ１２が「作業の交代」を検知することができる。
【００８５】
看護師の作業の交代が生じると、図３の分析表３８にもあるとおり、看護事故につながる可能性がある。しかしながら、頻度が「低」であるので、いきなり警告することはしないで、図７のステップＳ７−Ｓ１１を実行して、本当に事故が起こるかどうか予測する。
【００８６】
この具体例２の場合、看護メモや電子カルテを参照することにより、図７のステップＳ７で、該当の患者（患者ＩＤ＝１２３４５６７）に対する処置の理想状態は「点滴（アミノフリード）」であることがわかる。そして、図７のステップＳ９で、その理想状態「点滴（アミノフリード）」を現在得られているモニタデータで予測する。このステップＳ９でのモニタデータは上述のようにモニタ手段から獲得できる。そして、ステップＳ１１で、その仮説集合から理想状態が説明できるかどうか、つまり公理が成立するかどうか推論する。
【００８７】
ここで、「アミノフリードパック」、「do点滴」のイベントだけがモニタされた場合を考える。上述の理想状態「点滴（アミノフリード）」の達成のためには、図４からわかるとおり、混注（アミノ酸、糖・電解質）の支持が必要であるが、ここではそれを支持できるイベントがモニタされていない。したがって、理想状態が説明できない。したがって、図７のステップＳ１１では、看護事故の生じる可能性があると判断し、ステップＳ１３で、ちゃんと混注（アミノ酸、糖・電解質）をしないと看護事故が発生する旨警告が看護師に送られる。
【００８８】
この具体例の場合に、イベント（仮説データ）として「アミノフリードパック」、「do点滴」、「混注（アミノ酸、糖・電解質）」がモニタされたときには、必要な仮説データが全てモニタされているので、ステップＳ１１で、理想状態の説明が可能となる。したがって、ステップＳ１１で“ＹＥＳ”となり、看護事故の可能性がないので、「作業の交代」という看護事故につながる状況を検出したにも拘らず、警告はしない。
【００８９】
具体例３（ナースコールで作業が中断されたため、点滴注射準備にインシュリンを入れ忘れた。インシュリンは冷蔵庫にあった。定期血糖測定時に高血糖で気付いた。）
この第３の具体例では、図７のステップＳ１で分析表３８中の状況「作業の中断」が検出される。作業の中断が生じると、図３の分析表３８にもあるとおり、看護事故につながる可能性があるが、頻度が低いので、いきなり警告することはしないで、図７のステップＳ７−Ｓ１１を実行して、本当に事故が起こるかどうか予測する。
【００９０】
具体例３の場合、看護メモや電子カルテを参照することにより、図７のステップＳ７で、該当の患者（患者ＩＤ＝１２３４５６７８）に対する処置の理想状態は「点滴（インシュリン混合（抑圧剤）」であることがわかる。そして、図７のステップＳ９で、その理想状態「点滴（インシュリン混合（抑圧剤）」を現在得られている仮説データで予測する。そして、ステップＳ１１で、その仮説集合から理想状態が説明できるかどうか、つまり公理が成立するかどうか推論する。
【００９１】
ここで、モニタデータとして、「抑圧剤」、「do点滴」だけが得られた場合を考える。上述の理想状態「点滴（インシュリン混合（抑圧剤）」の達成のためには、図４からわかるとおり、インシュリン混合が必要であるが、ここではそれを支持できる仮説データ(イベント)がモニタされていない。したがって、図７のステップＳ１１では、“ＮＯ”と、すなわち看護事故の生じる可能性があると判断し、ステップＳ１３で、インシュリン混合（抑圧剤）を使わないと看護事故が発生する旨警告する。
【００９２】
この具体例３の場合に、イベント（仮説データ）として、「do点滴」、「抑圧剤」、「ミキシング（インシュリン、抑圧剤）」がモニタされたときには、必要な仮説データが全てモニタされているので、ステップＳ１１で、理想状態の説明が可能となる。したがって、ステップＳ１１で“ＹＥＳ”となり、看護事故の可能性がないので、「作業の中断」という看護事故につながる状況を検出したにも拘らず、警告はしない。
【図面の簡単な説明】
【００９３】
【図１】図１はこの発明の看護事故警告システムの構成の一例を示す図解図である。
【図２】図２は図１に示すサーバおよびその付属部分の電気的な構成を示す図解図である。
【図３】図３は図２に示す知識データベースに設定されているインシデントレポート分析表の一例を示す図解図である。
【図４】図４は図２に示す知識データベースに設定されている公理データ領域と仮説データ領域とを示す図解図である。
【図５】図５は看護師に装着されるセンサユニットの電気的な構成の一例を示す図解図である。
【図６】図６は図５に示すセンサユニットを看護師に装着した様子を示す図解図である。
【図７】図７はこの実施例の動作を示すフロー図である。
【符号の説明】
【００９４】
１０ …看護事故警告モニタシステム
１２ …サーバ
１６ …端末
１８ …ステーション
２０ …センサユニット
【技術分野】
【０００１】
この発明は看護事故警告システムに関し、特にたとえば、看護師による看護事故の発生を予測して警告する、看護事故警告システムに関する。
【背景技術】
【０００２】
医療事故や看護事故を未然に防止するための様々なシステムや方法が提案されている。
【０００３】
その１つが、特許文献１に開示されているシステムである。特許文献１に開示されているシステムは、インシデントレポートにより報告された各インシデントについて、慣れに基づく行為に関するエラー、規則に基づく行為に関するエラーなどのエラー種別と、環境施設、作業環境、作業要因、個人要因などの直接誘因と、医療情報管理上の問題、労務管理上の問題などの間接誘因とのそれぞれからそのインシデント発生に最も寄与した要因を抽出し、それらを関連付けた連関鎖を定義するとともに、看護業務に関係なく各連関鎖の出現率を計算し、その出現率を参考にして対応する優先順位を決め、その医療施設特有の組織文化やマネージメント上の問題を見つけ出し、それを解決する対応策を立案することによって医療事故の危険性を大幅に軽減することができるようにしようとするものである。
【特許文献１】特開２００３−９１６００[Ｇ０６Ｆ １７／６０]
【発明の開示】
【発明が解決しようとする課題】
【０００４】
特許文献１におけるシステムでは、出現率によって優先順位を決めるため、必然的に、出現率の高い要因に注目するものであり、出現率の低い要因については見過されてしまう可能性がある。
【０００５】
一方、事故が起きる一般的傾向すなわち頻度は低くても問題となる事故の可能性がない訳ではないので、頻度が低い状況であっても、事故防止の観点からは、看護師に警告を与えることが望ましい。しかしながら、頻度が低い場合に全て警告を発すると、たとえば、警告を発したのに事故がなかった場合などに看護師がだんだん慣れて、しまいにはその警告を無視するような状態（警告慣れ）にもなってしまう。これでは何のための警告システムかわからない。
【０００６】
したがって、事故につながる可能性の状況だけに警告を与えるのが望ましい。
【０００７】
それゆえに、この発明の主たる目的は、新規な看護事故警告システムを提供することである。
【０００８】
この発明の他の目的は、事故につながる可能性の状況だけｉ警告を与えることができる、看護事故警告システムを提供することである。
【課題を解決するための手段】
【０００９】
請求項１の発明は、インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を記憶する第１記憶手段、分析表に挙げられている状況が発生したかどうかを検出する状況検出手段、状況検出手段によって検出した状況について分析表を参照して頻度が高いかどうか判断する頻度判断手段、頻度判断手段によって頻度が低いと判断したとき事故を起すかどうか予測する予測手段、および予測手段によって事故の可能性がないと予測したときは警告を発せず、予測手段によって事故の可能性があると予測したときは警告を発する第１警告手段を備える、看護事故警告システムである。
【００１０】
請求項1の発明では、第１記憶手段（実施例中での知識データベース３６、インシデントレポート分析表３８に相当する。）にインシデントレポートを分析し、状況（要因）、結果、そして頻度を含む分析表を記憶しておく。一例として実施例のサーバ１２である状況検出手段は、モニタ手段から得られるモニタデータに基づいて、その分析表にリストアップされた状況が発生したかどうか判断する(ステップＳ１)。同じく実施例のサーバ１２が機能する頻度判断手段は、その分析表を参照して、当該検出した状況が事故につながる頻度が高いか低いか判断する(ステップＳ３)。頻度か低いときには、看護事故につながる可能性はあるものの、本当に事故を起すかどうか、予測手段（サーバ１２）によって推論または予測する(ステップＳ７-Ｓ１１)。予測手段が、看護事故を予測したとき、第１警告手段（１２、Ｓ１３）が警告を発する。
【００１１】
したがって、請求項１の発明によれば、看護事故を結果的に招来する可能性がある状況を検出しても、頻度が低いときには、事故が予測できるときだけ警告する。
【００１２】
請求項２の発明は、頻度判断手段によって頻度が高いと判断したとき警告を発する第２警告手段をさらに備える、請求項１記載の看護事故警告システムである。
【００１３】
請求項２の発明では、第２警告手段（実施例ではサーバ１２とステップＳ５が相当する）は、検出した状況が事故につながる可能性が大（高頻度）のときには、予測なしに、直ちに警告を発する。したがって、看護事故の発生が防止できる。
【００１４】
請求項３の発明は、看護師の行為をモニタしてモニタデータを得るモニタ手段をさらに備え、状況検出手段はモニタデータに基づいて状況を検出する、請求項１または２記載の看護事故警告システムである。
【００１５】
請求項４の発明は、少なくとも看護業務における公理を記憶するとともに、その公理の成立に影響を与える仮説データを記憶する第２記憶手段をさらに備え、予測手段は、モニタ手段から得られるモニタデータに基づいて仮説データを参照して公理が成立するかどうかで事故の可能性を予測する、公理成立判断手段を含む、請求項３記載の看護事故警告システムである。
【００１６】
請求項４の発明では、たとえば実施例の知識データベース３６中の推論用データベース４０が第２記憶手段であり、この第２記憶手段には、公理データ領域４２ａと仮説データ領域４２ｂとが設けられ、それぞれに、公理や仮説データが設定されている。実施例のサーバ１２であってよい、予測手段は、モニタ手段から得られるモニタデータに基づいてその仮説データを参照して、患者に対する処置の理想状態を結果的に得るための公理が成立するかどうかで事故の可能性を予測する。
【００１７】
請求項５の発明は、インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を用いて看護事故に対して警告を行なう看護事故警告方法であって、分析表に挙げられている状況が発生したかどうかを検出する状況検出ステップ、状況検出ステップによって検出した状況について分析表を参照して頻度が高いかどうか判断する頻度判断ステップ、頻度判断ステップによって頻度が低いと判断したとき事故を起すかどうか予測する予測ステップ、および予測ステップによって事故の可能性がないと予測したときは警告を発せず、予測手段によって事故の可能性があると予測したときは警告を発する警告ステップを含む、看護事故警告方法である。
【００１８】
請求項６の発明は、インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を記憶手段に記憶したコンピュータによって看護事故に対して警告を行なう看護事故警告プログラムであって、コンピュータに、分析表に挙げられている状況が発生したかどうかを検出する状況検出ステップ、状況検出ステップによって検出した状況について分析表を参照して頻度が高いかどうか判断する頻度判断ステップ、頻度判断ステップによって頻度が低いと判断したとき事故を起すかどうか予測する予測ステップ、および予測ステップによって事故の可能性がないと予測したときは警告を発せず、予測手段によって事故の可能性があると予測したときは警告を発する警告ステップを実行させる、看護事故警告プログラムである。
【発明の効果】
【００１９】
この発明によれば、頻度が低いときに、事故の可能性がないと予測したときは警告を発せず、事故の可能性があると予測したときだけ警告するようにしたので、看護師が「警告慣れ」になることはない。したがって、看護師がシステムからの警告を常に真摯に受け止める環境になるため、看護事故の発生が効果的に抑制できる。
【００２０】
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【発明を実施するための最良の形態】
【００２１】
図１を参照して、この発明の一実施例である看護事故警告モニタシステム１０は、たとえば病院に適用され、サーバ１２を含む。このサーバ１２は、有線或いは無線による通信回線（ネットワーク）１４を介して複数の看護師用端末（以下、単に「端末」という。）１６および複数のステーション１８に接続される。端末１６は、パーソナルコンピュータ或いはワークステーションのようなコンピュータであり、看護師毎に割り当てられる。たとえば、端末１６は看護師の詰所などに設置される。ただし、１台の端末１６を数人の看護師で使用する場合もあり得る。複数のステーション１８は、それぞれ、入院患者を収容する病棟内であり、廊下、病室（入り口、ベッド或いはその近傍）および看護師の詰所などの所定位置に配置され、無線通信可能なウェアラブルセンサユニット（以下、単に「センサユニット」という。）２０の識別情報を取得し、サーバ１２に送信する。複数のセンサユニット２０は、それぞれ、看護師に割り当てられ（装着され）、センサユニット２０の識別情報は、無線通信可能な範囲（たとえば、半径３〜５メートル）に存在するステーション１８によって検出される。また、ステーション１８とセンサユニット２０とは互いに通信可能であるため、センサユニット２０は、無線通信可能な範囲に存在するステーション１８の識別情報（ステーションＩＤ）を検出する。図示は省略するが、センサユニット２０は、センサユニット２０同士で無線通信することが可能であるため、無線通信可能な範囲に存在する２以上のセンサユニット２０同士で、互いの識別情報を検出することもできる。また、センサユニット２０は、無線ＬＡＮによってネットワーク１４に直接接続される場合もある。
【００２２】
図２はサーバ１２の具体的な構成を示すブロック図であり、この図２を参照して、サーバ１２には、図１では省略したが、複数の対物センサ２２、複数の集音マイク２４、および複数のビデオカメラ２６などが接続される。
【００２３】
図示は省略するが、この実施例では、複数の対物センサ２２は、体温計、血圧計、注射器、点滴注射器（注入器）、血液採取用試験管、検尿コップなどの医療器具を格納してある格納箱の取り出し部分やナースコール端末などに設置され、それらの医療器具等についての使用（取り出し）の有無を検知する。ただし、これらの医療器具等には、タグ情報やバーコードのような識別情報を付加しておき、タグ情報やバーコードを読み取ることにより、その使用の有無を検出するようにしてもよい。
【００２４】
また、複数の集音マイク２４は、入院患者を収容する病棟内であり、廊下および病室（ベッド或いはその近傍）などに設置され、周囲音を集音する。
【００２５】
なお、複数のビデオカメラ２６は、看護師の行動を記録するために用いられ、このビデオカメラ２６からの動画および／または静止画のデータがサーバ１２に蓄積される。ただし、そのようなカメラ２６は、たとえば、看護詰め所、廊下、病室などに設けられる。
【００２６】
また、図１では省略したが、サーバ１２には、複数のデータベース（データベース）が接続される。具体的には、看護師データベース２８、病棟イベントデータベース３０、所在情報データベース３２、電子カルテデータベース３４および知識データベース３６が接続される。
【００２７】
看護師データベース２８は、看護師の一日の業務おける行動についてのデータ（看護師データ）を看護師毎に記録する。看護師データには、たとえば、ラベルとして看護師名が記述され、看護師名の横に日付が記述される。看護師名および日付の下側には、当該看護師の看護業務に関する項目（内容）が記述される。つまり、看護業務の開始時刻、看護業務の終了時刻、看護業務の対象患者、看護業務の内容、看護業務における歩数、看護業務における傾斜（上半身（上体）を傾ける）角度の平均値および医療ミス等の業務における事故（アクシデント・インシデント）がそれぞれ記述される。このような看護師データでは、基本的には、センサユニット２０で計測されるデータから取得される。
【００２８】
病棟イベントデータベース３０は、複数のセンサすなわち上述した複数の対物センサ２２から得られる対物検知データ、複数の集音マイク２４から得られる音データおよびビデオカメラ２６から得られる画像データ（これらのデータをまとめて「病棟イベントデータ」という。）を記録する。対物検知データには、検知する対象となる医療器具等の名称のような識別情報がタグとして付される。音データには、集音マイク２４の設置場所を示す識別情報がタグとして付される。画像データには、ビデオカメラ２６の設置場所を示す識別情報がタグとしてとして付される。つまり、対物検知データから検知対象物を特定することができ、音データや画像データのタグから集音したり画像を取得した場所を特定することができる。
【００２９】
さらに、サーバ１２は、情報のような病棟イベントデータを取得した時間（時間データ）を、内蔵される時計回路１２ａから取得して、当該病棟イベントデータに付加する。
【００３０】
たとえば、対物検知データの入力があると、サーバ１２は当該対物検知データに時間データを付加して、病棟イベントデータベース３０に記録する。集音マイク２４は、たとえば、物が落下したときに生じる音や、人間が発した大声などを集音することを目的とするため、所定のレベル以上の音が入力されたときに、当該音に対応する音データがサーバ１２に入力され、サーバ１２は当該音データに時間データを付加して、病棟イベントデータベース３０に記録する。ただし、基本的にはタイムラプス(間欠記録)ではあるものの、時系列的に画像データが蓄積される。
【００３１】
所在情報データベース３２には、看護師についての所在情報のデータ（所在情報データ）が記録される。後で詳細に説明するが、所在情報データは、看護師のそれぞれが装着するセンサユニット２０に割り当てられたタグ情報のような識別情報（看護師ＩＤ）と、当該看護師ＩＤを検出したステーション１８のタグ情報すなわち識別情報（ステーションＩＤ）とを時系列に従って記録したデータである。また、上述したように、ステーション１８とセンサユニット２０とは互いに通信するため、所在情報データは、センサユニット２０で検出したステーションＩＤを時系列に従って記録したデータも含む。さらに、上述したようにセンサユニット２０同士は無線通信可能であり、各センサユニット２０に割り当てられた看護師ＩＤと、当該センサユニット２０と無線通信したセンサユニットの看護師ＩＤとを時系列に従って記録したデータも含まれる。この所在情報データによって、看護師の所在（行動）を知ることができる。たとえば、何時何分何秒にどこ（病室、詰所または廊下など）に居たかを知ることができ、また、何時何分何秒にどの看護師と一緒に居たか或いはすれ違ったか等を知ることができる。
【００３２】
電子カルテデータベース３４には、現在入院中或いは治療中の患者についての電子カルテが記録される。図示は省略するが、この電子カルテは、医師等が記載するカルテの内容から必要な事項を抽出するとともに、必要な事項を追加して、電子データにしたものである。たとえば、電子カルテには、患者名、担当看護師名（看護師カテゴリ番号）、性別、病名、病状、処方（どのような注射や点滴、あるいは投薬をするかという処方）、リハビリの状況、入院暦、患者に対する注意事項などの情報のデータ（テキストデータ）が記述されるとともに、このテキストデータに当該患者についての患者カテゴリ番号がラベルとして付される。したがって、患者が特定されると、その患者カテゴリ番号に応じて、当該患者についての電子カルテを特定することができる。
【００３３】
第１記憶手段や第２記憶手段として機能する知識データベース３６には、図３および図４に示すデータベースが蓄積されている。
【００３４】
図３に示すインシデントレポート分析表３８は、インシデントレポート（看護師等から報告される、医療看護業務に関する何らかのミスや誤った業務行為のこと）を分析した結果をテーブル形式にまとめたものであり、状況（または要因）とそれによって生じた結果を含む。さらに、第１記憶手段としてのこの分析表３８には、必要に応じて、その結果を生じる前提条件を記録する。たとえば、環境が変わると誤った行為が行なわれる結果になるが、それは、環境に順応できていない、という前提条件の下に生じた結果であり、環境に順応できていれば、誤った行為を行うこともない。たとえば、それぞれの病院にはそれぞれのシステムがあるが、他の病院からきた看護師は、前の病院でのルールがそのまま使えると思い込んだ結果、誤った行動をする。
【００３５】
この分析表３８において特徴的なことは、上述のような状況や結果の他に、頻度のデータを併せて記録していることである。ここで、「頻度」とは、事故の起きる一般的傾向のことであり、たとえば、看護師のある行動ないし行為またはそれによる状況が事故につながる可能性が高い場合には、その状況は頻度が高いといい、必ずしも事故につながるものではないが、事故の可能性がまったくないというものでもない場合を、その状況は頻度が低いという。
【００３６】
この図３に示す、頻度データ付インシデントレポート分析表３８に挙げた結果、すなわち「誤った行為」、「伝達の誤り」、「誤った作業」などはすべて、頻度の高低はあるものの、看護事故につながるものである。したがって、後に説明するセンサユニット２０によってこの表に挙げた状況または要因を検出またはモニタしたときには、サーバ１２（図１）は、警告を発する。ただし、頻度が低い場合でもすべて警告を発すると、警告慣れが生じて好ましくないので、この実施例では、頻度が高いときには必ず警告を発するが、頻度が低いときには、事故が起きるかどうか予測しまたは推論（abduction：アブダクション）を行い、事故が予測できるときだけ、警告を発することにしている。
【００３７】
このような予測または推論のために、図４に示す、推論用データベース４０が利用される。この推論用データベース４０は、第２記憶手段として、図２に示す知識データベース３６に設定されている。
【００３８】
推論用データベース４０には、公理（該当の患者に対する処方または処置の理想状態が必然的に得られる事象、行為、または要素などとその理想状態の因果律、さらにもっと一般的に言えば、どのような場合でも関係が崩れることがない、そのような関係のことである）を設定しておくための公理データ領域４２ａと、仮説（モニタ手段やＲＦＩＤなどで観測またはモニタ可能な事象、行為、要素など、可変なもの、同時に成り立たない可能性があるもの（イベント））を設定しておく仮説データ領域４２ｂとが設けられる。
【００３９】
図４の公理データ領域４２ａに例示されている３つの公理について、ここで説明する。ただし、「∧」は論理であり「ａｎｄ」を示す。
【００４０】
最初の公理は、変数項としてコンテンツ（Ｘ）（Ｘ：変数）を検出し、イベントとして蒸留水を検出し、別のイベントとして看護師が注射をしようとしていことを検出したとき、そのときの患者に対する処置の理想状態が達成できることを示している。Ｘは変数であるが、たとえば、Diamoxという注射用薬剤であるとすると、Diamox注射という、その患者にとっての理想状態が実現できることを示す。
【００４１】
公理の２番目は、イベントとして、アミノフリードパックを検出し、その輸液パックを混注することによって、コンテンツ（Ｘ）、Ｘ＝アミノフリードが検出できるので、行為（do点滴）によって、そのときの患者に対する処置の理想状態（アミノフリードの点滴）が達成できることを示している。
【００４２】
例示の最後の公理は、変数Ｘとインシュリンとのミキシングを検出し、さらに、コンテンツ（Ｚ）＝（抑圧剤インシュリン混合）をモニタすれば、行為（do点滴）によって、そのときの患者に対する処置の理想状態（インシュリン混合の点滴）が達成できることを示している。
【００４３】
なお、仮説データ領域４２ｂの各事象、行為、ないしは要素は、すべて、モニタ手段でモニタできる。たとえばコンテンツ（Ｘ：Ｘ＝変数）は看護師がたとえば薬品棚から取り出したものを、たとえばＲＦＩＤ（赤外線タグ）で検出するか、さらにはビデオカメラ２６で取得した画像データを分析または解析することによって、検出することができる。
【００４４】
また、看護師の行為「do…」も同様に、ビデオカメラ２６からの画像データの分析によって、あるいはＲＦＩＤのデータから検出することができる。
【００４５】
その他、「蒸留水」、「Diamox」、「生理食塩水」などのイベントも同様にして検出することができる。
【００４６】
ここで、モニタ手段の一部として機能するウェアラブルセンサユニット２０の詳細なブロック図が図５に示される。
【００４７】
この図５を参照して、センサユニット２０はＣＰＵ４４を含む。ＣＰＵ４４には、Ａ／Ｄ変換器４６，４８，エンコーダ５０，非接触センサ５２，インターフェイス５４，カードスロット５６，時計回路５８，ＤＩＰスイッチ６０，無線送信機６２および無線受信機６４が接続される。Ａ／Ｄ変換器４６には歩数計６６が接続され、Ａ／Ｄ変換器４６は、歩数計６６から入力される歩数をディジタルデータ（バイナリデータ）に変換してＣＰＵ４４に入力する。また、Ａ／Ｄ変換器４８には傾斜角センサ６８が接続され、Ａ／Ｄ変換器４８は、傾斜角センサ６８から入力される傾斜角（角度）をディジタルデータ（バイナリデータ）に変換してＣＰＵ４４に入力する。エンコーダ５０にはマイク７０が接続され、エンコーダ５０は、マイク７０から入力される音声信号をＭＰ３のような圧縮音声データ（以下、単に「音声データ」という。）に変調してＣＰＵ４４に入力する。このように、音声信号を圧縮変調するのは、後述するメモリカード７２の容量を考慮したためであり、このような記録媒体の容量を無視できる場合には、単にディジタルデータに変換するだけでもよい。
【００４８】
非接触センサ５２としては、焦電センサを用いることができ、ＣＰＵ４４は非接触センサ５２からの入力に応じてマイク７０をオン／オフする。この実施例では、非接触センサ５２すなわち焦電センサの前で、看護師が手を２回上下させると、その検出信号がＣＰＵ４４に入力され、これに応じて、ＣＰＵ４４はマイク７０をオンし、その後、看護師が焦電センサの前で、手を２回上下させると、マイク７０をオフする。ただし、ＣＰＵ４４は、看護師の操作によらないで、所定時間（１０秒）が経過した場合にもマイク７０をオフするようにしてある。この実施例では、マイク７０としては、ヘッドセットタイプのものが用いられ（図６参照）、また、指向性を有する。これは、看護師の音声を正確に入力するとともに、患者のプライバシーを守るためである。
【００４９】
インターフェイス５４は、ＬＡＮ（無線ＬＡＮ）アダプタのようなインターフェイスであり、これにより、センサユニット２０はネットワーク１４に直接接続される。ただし、ＲＳ２３２ＣやＵＳＢのようなインターフェイスを設けて、ケーブルを用いることにより、サーバ１２或いは端末１６のような他の端末に通信可能に接続することもできる。
【００５０】
カードスロット５６には、ＭＭＣのようなメモリカード７２が着脱自在に設けられる。このメモリカード７２には、このセンサユニット２０で検出或いは取得されるデータ（歩数データ、傾斜角データ、音声データ）が記憶される。また、メモリカード７２に記憶されたデータは、メモリカード７２をサーバ１２或いは端末１６のような他の端末に装着することにより、当該他の端末に移動（コピー）することができる。
【００５１】
時計回路５８は、日付および時刻を計時する回路であり、ＣＰＵ４４は、時計回路５８から取得した時間データを、各センサ（５２，６６、６８、７０）から取得したデータや看護師ＩＤのデータに付加して、メモリカード７２に記憶する。また、必要に応じて、時間データを付されたデータは、インターフェイス５４を介してネットワーク１４に接続されるサーバ１２または端末１６或いはその両方に出力される。
【００５２】
ＤＩＰスイッチ６０は、たとえば８ビットで構成され、各ビットのオン／オフを切り替えることにより、０〜２５５の間で数値を設定することができる。この数値が識別情報すなわち看護師ＩＤであり、各センサユニット２０で異なる値が設定される。ＣＰＵ４４は、看護師ＩＤをラベルとして付するとともに、時間データを付加したデータを、メモリカード７２に記憶したり、サーバ１２に転送したりする。
【００５３】
ただし、ＤＩＰスイッチ６０に代えて、メモリカード７２に看護師ＩＤを記憶させておくようにすることもできる。また、ＤＩＰスイッチ６０に代えて、看護師ＩＤを記憶したＲＯＭなどを設けておくようにすることもできる。
【００５４】
無線送信機６２は、ＣＰＵ４４の指示に従って、ＤＩＰスイッチ６０または別の手段によって設定された看護師ＩＤを所定の周波数による電波（微弱電波）で送信する。無線受信機６０は、無線通信可能な範囲に存在する他のセンサユニット２０から送信される微弱電波を受信し、看護師ＩＤに復調し、復調した看護師ＩＤについてのデータをＣＰＵ４４に入力する。
【００５５】
ここで、ステーション１８は、上述したように、センサユニット２０の看護師ＩＤを検出し、検出した看護師ＩＤを、ネットワーク１４を介してサーバ１２に送信する。また、ステーション１８にも識別情報（ステーションＩＤ）が割り当てられ、上述したように、このステーションＩＤがセンサユニット２０によって検出される。したがって、たとえば、ステーション１８は、センサユニット２０の一部の回路コンポーネントを用いることにより、構成することができる。具体的には、ステーション１８は、ＣＰＵ４４，インターフェイス５４，ＤＩＰスイッチ６０，無線送信機６２および無線受信機６４によって構成される。
【００５６】
なお、ＤＩＰスイッチ６０に代えて、ステーションＩＤを記憶したＲＯＭを設けるようにしてもよい点は、センサユニット２０の場合と同様である。
【００５７】
上述したような構成のセンサユニット２０は、各看護師に装着される。たとえば、図６に示すように、非接触センサ５２，歩数計６６，傾斜角センサ６８およびマイク７０以外の回路コンポーネントはボックス（筐体）７４に収容され、ボックス７４は看護師の腰部（ベルト部分）に装着される。また、非接触センサ５２および傾斜角センサ６８は、ペン型のケース７６に収容され、看護師の衣服（白衣）の胸ポケットに挿すように収納される。ただし、図面では、分かり易く示すために、ケース７6を胸ポケットの外部に記載してある。また、歩数計６６は、上述のボックス７４と同様に看護師の腰部に装着される。さらに、マイク７０は看護師の頭部に装着される。
【００５８】
なお、図６においては省略するが、非接触センサ５２は接続線を用いてボックス７４内のＣＰＵ４４に接続され、歩数計６６，傾斜角センサ６８およびマイク７０は、それぞれ、接続線を用いてボックス７４内のＡ／Ｄ変換器４６，Ａ／Ｄ変換器４８およびエンコーダ５０に電気的に接続される。ただし、接続線を用いずに、ブルートゥースのような近距離無線によって接続するようにしてもよい。つまり、電気的に接続されればよいのである。
【００５９】
また、図６に示すように、看護師は、たとえば、白衣の前ポケットに携帯型のコンピュータ（この実施例では、ＰＤＡ）７８を収納し、所持（携帯）している。図示は省略するが、ＰＤＡ７８は、無線ＬＡＮによって、図１に示したネットワーク１４に接続可能な構成にされる。ＰＤＡ７８は既に周知であるため、その構成および動作等の詳細な説明は省略することにする。なお、図面では、分かり易くするため、前ポケットの外部に示してある。
【００６０】
たとえば、看護師の操作によって、センサユニット２０の主電源がオンされると、ＣＰＵ４４は、傾斜角センサ６８からの入力を所定時間（この実施例では、５００ｍｓ）毎に検出する。上述したように、マイク７０は、非接触センサ５２の入力に応じて、そのオン／オフが制御される。また、ＣＰＵ４４は、マイク７０がオフされているとき、歩数計６６からの入力を有効化する。
【００６１】
したがって、ＣＰＵ４４は、歩数計６６によって計測された歩数のデータ（歩数データ），傾斜角センサ６８によって計測された角度のデータ（角度データ）およびマイク７０で検出された音声のデータ（音声データ）を、識別してメモリカード７２に記憶するとともに、無線ＬＡＮによって他の端末（この実施例では、サーバ１２）に送信する。また、ＣＰＵ４４は、歩数データ、角度データおよび音声データを記録する場合には、各データの取得開始時刻および取得終了時刻についての時間データを時計回路６０から取得し、各データに当該時間データを付すようにしてある。
【００６２】
なお、ウェラブルセンサユニット２０によって取得した上述のような行動データ、さらには先に述べたビデオカメラ２６などで取得した行動データは、最終的には、すべてサーバ１２およびそれぞれの関連データベース（図２）に記録される。
【００６３】
たとえば、看護師ｎが患者ｋさんの患者訪問を行う場合には、看護師ｎが「患者ｋさんの（患者）訪問に行きます。」と発話した内容、患者ｋさんの病室を往復する間の歩数および当該病室を往復する間に上半身を傾斜した際の角度（傾斜角度）のそれぞれについてのデータが記録される。また、このデータに，看護業務の開始時刻および終了時刻の時間データが付加される。
【００６４】
このような音声，歩数および傾斜角度についてのデータおよびこれらに付される時間データ（以下、これらをまとめて「計測データ」ということがある。）は、看護師ｎの１日の業務のすべてについて取得される。上述したように、センサユニット２０は、無線ＬＡＮ（ネットワーク１４）によって接続され、したがって、上述のようにして取得された１日の業務についての計測データ（業務計測データ）は、センサユニット２０から端末１６に送信（転送）することができる。また、メモリカード７２を端末１６に着脱自在にすれば、業務計測データを直接端末１６に入力することができる。
【００６５】
端末１６は転送された業務計測データを受信し、たとえば、看護師の操作によって、その業務計測データはサーバ１２にアップロードされる。サーバ１２は、アップロードされた業務計測データに基づいて、アクシデント・インシデントを除く看護師データを作成する。つまり、看護師を特定し、その後、各計測データからアクシデント・インシデントを除く看護師データの項目を特定（決定）して、記録する。
【００６６】
ただし、業務計測データは、センサユニット２０からネットワーク１４を介してサーバ１２に直接アップロードされるようにしてもよい。
【００６７】
たとえば、看護師は、センサユニット２０から転送される業務計測データに付された看護師ＩＤに基づいて、サーバ１２側で容易に特定することができる。
【００６８】
また、計測データに含まれる音声データは、音声認識処理を施され、認識した音声から患者名や当該患者に対して行った看護業務が特定される。つまり、サーバ１２は、音声認識機能を備えており、また、音声認識のための辞書すなわち複数の発話（音声）に対応する音声データを記録したメモリ（たとえば、ハードディスクやＲＯＭ）を有している。ただし、看護師の音声データは、一例として、看護師データベース２８に記録される。
【００６９】
図７は図１実施例においてサーバ１２の動作を示すフローチャートであり、このフローチャート（プログラム）は、一例として、サーバ１２の内部メモリ（ＲＯＭまたはＲＡＭ：図示せず）に設定されている。
【００７０】
ここで、この図７を参照して、図１実施例の看護事故警告システム１０の特にサーバ１２の動作について説明する。サーバ１２は、動作を開始した後、ステップＳ１で、先の図３の分析表３８に挙げた状況（または要因）を検出したかどうか判断する。このような状況が発生したかどうかは、ビデオカメラ２６やセンサユニット２０を含むモニタ手段からの画像データ、音声データ、さらにはＲＦＩＤデータなどから検出できる。たとえば「作業の中断」という状況は次のように判断できる。ＲＦＩＤデータで看護師が注射器を持ったことがわかり、該当する看護師を撮影しているビデオカメラ２６からの画像データを解析すれば、看護師がその注射器で注射の準備をしていることがわかる。集音マイク２４の音声データを解析することによって、たとえば医師か患者かに呼びつけられたことがわかる。その後、歩数計６６のデータを見れば、誰かに呼ばれた時刻より後に、看護師が歩行したことが検出でき、したがって、先の作業（注射の準備）が中断したことが検出できる。分析表３８にリストアップされている他の「状況」についても、同様にして、検出することができる。
【００７１】
また、たとえば、「似た苗字の患者」の存在、「同姓同名の患者」の存在、あるいは「兄弟（姉妹）」の患者の存在などは、電子カルテ３４からのデータで判断できる。
【００７２】
サーバ１２がステップＳ１で、分析表３８に挙げられた状況を検出した後、サーバ１２は、続くステップＳ３で、その分析表３８を参照して、ステップＳ１で検出した「状況」による事故の発生頻度が高いのか低いのか判断する。検出した状況の結果が、たとえば誤った行為、伝達の誤りなどであれば看護事故につながりやすいので、このステップＳ３で“ＹＥＳ”が判断され、たとえば作業の中断や作業の交代などの状況の場合には頻度が低いので、ステップＳ３では“ＮＯ”が判断される。
【００７３】
ステップＳ３で“ＹＥＳ”のときには、看護事故が発生する可能性が高いので、サーバ１２は、ステップＳ５において、図１に示すネットワーク１４を介して看護師用端末１６に警告を送る。ただし、看護師端末１６を当該看護師が見ていないことも考えられるので、そのときには、その看護師端末１６から、もしくはサーバ１２から直接、看護師のヘッドセット（図５および図６のマイク７０と図示しないイヤホンとが一体化させたもの）のイヤホンを利用して看護師に音声で警告を与えるようにしてもよい。また、ヘッドセットに代えて、またはそれと併用して、たとえば振動付き腕時計型表示器を看護師に装着させ、その表示器に看護師端末１６からか、もしくはサーバ１２から直接警告を送るようにしてもよい。
【００７４】
ステップＳ３で“ＮＯ”を判断した後、つまり、ステップＳ１で検出した状況から事故の発生の頻度が低いとき、サーバ１２は、直ちに無条件に警告を発するのではなく、看護事故につながる可能性に応じて、警告を発するようにする。つまり、サーバ１２は、続くステップＳ７、Ｓ９、およびＳ１１を実行することによって、当該「状況」から看護事故が起きる可能性があるかどうか予測または推論し、その結果、事故が予測できるときには警告する。
【００７５】
具体的には、まずステップＳ７において、サーバ１２は、図４に示す公理データ領域４２ａを参照して、そのときの患者に対する処置の理想状態、たとえば図４の公理データ領域４２ａの右端の項目を調べる。そして、ステップＳ９で、そのときにモニタ手段当から入力されている看護師の行動データやその他イベント（事象）を、図４に示す仮説データ領域４２ｂからピックアップする。そして、ステップＳ１１において、そのとき生じているイベントから上記理想状態が成立するかどうか、つまり、公理が証明できるかどうか判断する。ここで、公理が証明できれば、事故の発生の可能性はなく、したがって、そのまま終了する。しかしながら、ステップＳ１１で、サーバ１２が、そのときモニタしているイベントでは理想状態は成立しないと判断したときは、看護事故の可能性があるので、続くステップＳ１３（第１警告手段）で、先のステップＳ５（第２警告手段）と同様にして、看護師に警告を発する。
【００７６】
ただし、第１警告手段では、ステップＳ１１において“ＹＥＳ”を判断したとき、つまり事故を予測しないときには、警告を発しない。つまり、第１警告手段では、予測結果によって、警告を発したり、しなかったりする。
【００７７】
以下に、３つの具体例を用いて、このシステム１０の動作について説明する。
【００７８】
具体例１（核医学検査はキャンセルが多いので、蒸留水のみ注射器に吸って準備し、ダイアモックス（Diamox）は直前に溶解しようと思い、箱から出して注射器のそばにおいた。検査が順々に進められていくうちに、溶解してあるものと思い込んでしまって、医師に渡してしまった。）
この第１の具体例では、図７のステップＳ１で分析表３８中の状況「作業の中断」が検出される。看護行為は上で説明したように常時モニタされているので、モニタ手段からのデータに基づいてサーバ１２が「作業の中断」を検知することができる。
【００７９】
看護師の作業の中断が生じると、図３の分析表３８にもあるとおり、看護事故につながる可能性がある。しかしながら、頻度が「低」であるので、いきなり警告することはしないで、図７のステップＳ７−Ｓ１１を実行して、本当に事故が起こるかどうか予測する。
【００８０】
この具体例の場合、看護メモや電子カルテを参照することにより、図７のステップＳ７で、該当の患者（患者ＩＤ＝１２３４５６）に対する処置の理想状態は「注射（Diamox）」であることがわかる。そして、図７のステップＳ９で、その理想状態「注射（Diamox）」を現在得られているモニタデータを用いて仮説集合から予測する。このステップＳ９でのモニタデータ（イベント）は上述のようにモニタ手段から獲得できる。そして、ステップＳ１１で、その仮説集合から理想状態が説明できるかどうか、つまり公理が成立するかどうか推論する。
【００８１】
ここで、「蒸留水」、「do注射」のモニタデータだけが得られた場合を考える。上述の理想状態「注射（Diamox）」の達成のためには、図４からわかるとおり、仮説データとしてcontent(X)、X=Diamoxが必要であるが、Diamoxはモニタされていないので、content(Diamox)が支持できない。したがって、理想状態が説明できない。したがって、図７のステップＳ１１では、看護事故の生じる可能性があるので、あるから“ＮＯ”を判断することになる。したがって、ステップＳ１３で警告が看護師に送られ、Diamoxを使用しないと看護事故を起すと警告する。
【００８２】
この具体例の場合に、イベント（仮説データ）として「生理食塩水」、「蒸留水」、「do注射」がモニタされたときにも、Diamoxはモニタされていないので、ステップＳ１１で“ＮＯ”を判断し、ステップＳ１３で、看護師に、たとえば生理食塩水の代わりにDiamoxを使わないと事故を起す、と警告する。
【００８３】
ただし、「Diamox」、「蒸留水」、「do注射」のイベントがモニタされたときには、content(X)においてXにDiamoxが代入できるため、ステップＳ１１で、理想状態の説明が可能となる。したがって、ステップＳ１３で“ＹＥＳ”となり、看護事故の可能性がないので、「作業の中断」という看護事故につながる状況を検出したにも拘らず、警告はしない。
【００８４】
具体例２（ＩＶＨメニューの変更があり、主治医が準備を行い、看護師が中心静脈注射のパックの更新をした。上層と下層とが混ぜられておらず、深夜勤務者に指摘されて気付く。これらの輸液パックは、上室がアミノ酸、下室が糖・電解質で、開通しない場合には、１１％の高カロリの糖輸液が行なわれることになり、危険な状態を惹起する。）
この第２の具体例では、図７のステップＳ１で分析表３８中の状況「作業の交代」が検出される。看護行為は上で説明したように常時モニタされているので、モニタ手段からのデータに基づいてサーバ１２が「作業の交代」を検知することができる。
【００８５】
看護師の作業の交代が生じると、図３の分析表３８にもあるとおり、看護事故につながる可能性がある。しかしながら、頻度が「低」であるので、いきなり警告することはしないで、図７のステップＳ７−Ｓ１１を実行して、本当に事故が起こるかどうか予測する。
【００８６】
この具体例２の場合、看護メモや電子カルテを参照することにより、図７のステップＳ７で、該当の患者（患者ＩＤ＝１２３４５６７）に対する処置の理想状態は「点滴（アミノフリード）」であることがわかる。そして、図７のステップＳ９で、その理想状態「点滴（アミノフリード）」を現在得られているモニタデータで予測する。このステップＳ９でのモニタデータは上述のようにモニタ手段から獲得できる。そして、ステップＳ１１で、その仮説集合から理想状態が説明できるかどうか、つまり公理が成立するかどうか推論する。
【００８７】
ここで、「アミノフリードパック」、「do点滴」のイベントだけがモニタされた場合を考える。上述の理想状態「点滴（アミノフリード）」の達成のためには、図４からわかるとおり、混注（アミノ酸、糖・電解質）の支持が必要であるが、ここではそれを支持できるイベントがモニタされていない。したがって、理想状態が説明できない。したがって、図７のステップＳ１１では、看護事故の生じる可能性があると判断し、ステップＳ１３で、ちゃんと混注（アミノ酸、糖・電解質）をしないと看護事故が発生する旨警告が看護師に送られる。
【００８８】
この具体例の場合に、イベント（仮説データ）として「アミノフリードパック」、「do点滴」、「混注（アミノ酸、糖・電解質）」がモニタされたときには、必要な仮説データが全てモニタされているので、ステップＳ１１で、理想状態の説明が可能となる。したがって、ステップＳ１１で“ＹＥＳ”となり、看護事故の可能性がないので、「作業の交代」という看護事故につながる状況を検出したにも拘らず、警告はしない。
【００８９】
具体例３（ナースコールで作業が中断されたため、点滴注射準備にインシュリンを入れ忘れた。インシュリンは冷蔵庫にあった。定期血糖測定時に高血糖で気付いた。）
この第３の具体例では、図７のステップＳ１で分析表３８中の状況「作業の中断」が検出される。作業の中断が生じると、図３の分析表３８にもあるとおり、看護事故につながる可能性があるが、頻度が低いので、いきなり警告することはしないで、図７のステップＳ７−Ｓ１１を実行して、本当に事故が起こるかどうか予測する。
【００９０】
具体例３の場合、看護メモや電子カルテを参照することにより、図７のステップＳ７で、該当の患者（患者ＩＤ＝１２３４５６７８）に対する処置の理想状態は「点滴（インシュリン混合（抑圧剤）」であることがわかる。そして、図７のステップＳ９で、その理想状態「点滴（インシュリン混合（抑圧剤）」を現在得られている仮説データで予測する。そして、ステップＳ１１で、その仮説集合から理想状態が説明できるかどうか、つまり公理が成立するかどうか推論する。
【００９１】
ここで、モニタデータとして、「抑圧剤」、「do点滴」だけが得られた場合を考える。上述の理想状態「点滴（インシュリン混合（抑圧剤）」の達成のためには、図４からわかるとおり、インシュリン混合が必要であるが、ここではそれを支持できる仮説データ(イベント)がモニタされていない。したがって、図７のステップＳ１１では、“ＮＯ”と、すなわち看護事故の生じる可能性があると判断し、ステップＳ１３で、インシュリン混合（抑圧剤）を使わないと看護事故が発生する旨警告する。
【００９２】
この具体例３の場合に、イベント（仮説データ）として、「do点滴」、「抑圧剤」、「ミキシング（インシュリン、抑圧剤）」がモニタされたときには、必要な仮説データが全てモニタされているので、ステップＳ１１で、理想状態の説明が可能となる。したがって、ステップＳ１１で“ＹＥＳ”となり、看護事故の可能性がないので、「作業の中断」という看護事故につながる状況を検出したにも拘らず、警告はしない。
【図面の簡単な説明】
【００９３】
【図１】図１はこの発明の看護事故警告システムの構成の一例を示す図解図である。
【図２】図２は図１に示すサーバおよびその付属部分の電気的な構成を示す図解図である。
【図３】図３は図２に示す知識データベースに設定されているインシデントレポート分析表の一例を示す図解図である。
【図４】図４は図２に示す知識データベースに設定されている公理データ領域と仮説データ領域とを示す図解図である。
【図５】図５は看護師に装着されるセンサユニットの電気的な構成の一例を示す図解図である。
【図６】図６は図５に示すセンサユニットを看護師に装着した様子を示す図解図である。
【図７】図７はこの実施例の動作を示すフロー図である。
【符号の説明】
【００９４】
１０ …看護事故警告モニタシステム
１２ …サーバ
１６ …端末
１８ …ステーション
２０ …センサユニット
【特許請求の範囲】
【請求項１】
インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を記憶する第１記憶手段、
前記分析表に挙げられている状況が発生したかどうかを検出する状況検出手段、
前記状況検出手段によって検出した前記状況について前記分析表を参照して前記頻度が高いかどうか判断する頻度判断手段、
前記頻度判断手段によって頻度が低いと判断したとき事故を起すかどうか予測する予測手段、および
前記予測手段によって事故の可能性がないと予測したときは警告を発せず、前記予測手段によって事故の可能性があると予測したときは警告を発する第１警告手段を備える、看護事故警告システム。
【請求項２】
前記頻度判断手段によって頻度が高いと判断したとき警告を発する第２警告手段をさらに備える、請求項１記載の看護事故警告システム。
【請求項３】
看護師の行為をモニタしてモニタデータを得るモニタ手段をさらに備え、
前記状況検出手段は前記モニタデータに基づいて前記状況を検出する、請求項１または２記載の看護事故警告システム。
【請求項４】
少なくとも看護業務における公理を記憶するとともに、その公理の成立に影響を与える仮説データを記憶する第２記憶手段をさらに備え、
前記予測手段は、前記モニタ手段から得られるモニタデータに基づいて前記仮説データを参照して前記公理が成立するかどうかで前記事故の可能性を予測する、公理成立判断手段を含む、請求項３記載の看護事故警告システム。
【請求項５】
インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を用いて看護事故に対して警告を行なう看護事故警告方法であって、
前記分析表に挙げられている状況が発生したかどうかを検出する状況検出ステップ、
前記状況検出ステップによって検出した前記状況について前記分析表を参照して前記頻度が高いかどうか判断する頻度判断ステップ、
前記頻度判断ステップによって頻度が低いと判断したとき事故を起すかどうか予測する予測ステップ、および
前記予測ステップによって事故の可能性がないと予測したときは警告を発せず、前記予測手段によって事故の可能性があると予測したときは警告を発する警告ステップを含む、看護事故警告方法。
【請求項６】
インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を記憶手段に記憶したコンピュータによって看護事故に対して警告を行なう看護事故警告プログラムであって、
前記コンピュータに、
前記分析表に挙げられている状況が発生したかどうかを検出する状況検出ステップ、
前記状況検出ステップによって検出した前記状況について前記分析表を参照して前記頻度が高いかどうか判断する頻度判断ステップ、
前記頻度判断ステップによって頻度が低いと判断したとき事故を起すかどうか予測する予測ステップ、および
前記予測ステップによって事故の可能性がないと予測したときは警告を発せず、前記予測手段によって事故の可能性があると予測したときは警告を発する警告ステップを実行させる、看護事故警告プログラム。
【請求項１】
インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を記憶する第１記憶手段、
前記分析表に挙げられている状況が発生したかどうかを検出する状況検出手段、
前記状況検出手段によって検出した前記状況について前記分析表を参照して前記頻度が高いかどうか判断する頻度判断手段、
前記頻度判断手段によって頻度が低いと判断したとき事故を起すかどうか予測する予測手段、および
前記予測手段によって事故の可能性がないと予測したときは警告を発せず、前記予測手段によって事故の可能性があると予測したときは警告を発する第１警告手段を備える、看護事故警告システム。
【請求項２】
前記頻度判断手段によって頻度が高いと判断したとき警告を発する第２警告手段をさらに備える、請求項１記載の看護事故警告システム。
【請求項３】
看護師の行為をモニタしてモニタデータを得るモニタ手段をさらに備え、
前記状況検出手段は前記モニタデータに基づいて前記状況を検出する、請求項１または２記載の看護事故警告システム。
【請求項４】
少なくとも看護業務における公理を記憶するとともに、その公理の成立に影響を与える仮説データを記憶する第２記憶手段をさらに備え、
前記予測手段は、前記モニタ手段から得られるモニタデータに基づいて前記仮説データを参照して前記公理が成立するかどうかで前記事故の可能性を予測する、公理成立判断手段を含む、請求項３記載の看護事故警告システム。
【請求項５】
インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を用いて看護事故に対して警告を行なう看護事故警告方法であって、
前記分析表に挙げられている状況が発生したかどうかを検出する状況検出ステップ、
前記状況検出ステップによって検出した前記状況について前記分析表を参照して前記頻度が高いかどうか判断する頻度判断ステップ、
前記頻度判断ステップによって頻度が低いと判断したとき事故を起すかどうか予測する予測ステップ、および
前記予測ステップによって事故の可能性がないと予測したときは警告を発せず、前記予測手段によって事故の可能性があると予測したときは警告を発する警告ステップを含む、看護事故警告方法。
【請求項６】
インシデントレポートを分析して少なくとも状況、結果および頻度のデータを含む分析表を記憶手段に記憶したコンピュータによって看護事故に対して警告を行なう看護事故警告プログラムであって、
前記コンピュータに、
前記分析表に挙げられている状況が発生したかどうかを検出する状況検出ステップ、
前記状況検出ステップによって検出した前記状況について前記分析表を参照して前記頻度が高いかどうか判断する頻度判断ステップ、
前記頻度判断ステップによって頻度が低いと判断したとき事故を起すかどうか予測する予測ステップ、および
前記予測ステップによって事故の可能性がないと予測したときは警告を発せず、前記予測手段によって事故の可能性があると予測したときは警告を発する警告ステップを実行させる、看護事故警告プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００６−５９０５４（Ｐ２００６−５９０５４Ａ）
【公開日】平成１８年３月２日（２００６．３．２）
【国際特許分類】
【出願番号】特願２００４−２３９１５１（Ｐ２００４−２３９１５１）
【出願日】平成１６年８月１９日（２００４．８．１９）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成１６年度独立行政法人情報通信研究機構、研究テーマ「超高速知能ネットワーク社会に向けた新しいインタラクション・メディアの研究開発」に関する委託研究、産業活力再生特別措置法第３０条の適用を受ける特許出願
【出願人】（３９３０３１５８６）株式会社国際電気通信基礎技術研究所 (905)
【Ｆターム（参考）】
【公開日】平成１８年３月２日（２００６．３．２）
【国際特許分類】
【出願日】平成１６年８月１９日（２００４．８．１９）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成１６年度独立行政法人情報通信研究機構、研究テーマ「超高速知能ネットワーク社会に向けた新しいインタラクション・メディアの研究開発」に関する委託研究、産業活力再生特別措置法第３０条の適用を受ける特許出願
【出願人】（３９３０３１５８６）株式会社国際電気通信基礎技術研究所 (905)
【Ｆターム（参考）】
[ Back to top ]