事例構築装置およびその事例構築方法
【構成】 警告システム１０はサーバ１２を含み、このサーバ１２は事例構築装置として機能する。仮ＤＢ（３６）には、日々発生する事故の事例についての事例情報が蓄積される。サーバ１２は、蓄積された事例情報のうち、事故の内容が同じものをグループ化し（Ｓ９１）、グループ化した複数の事例情報のうち、事故が発生したときの行動（処置）や事故が発生したときに使用していた物（薬品・器具）が同じまたは類似するものをまとめる（Ｓ１０５，Ｓ１０７，Ｓ１１１，Ｓ１１３）。このようにして、複数の事例情報から同じ事故の内容のものについて、１つの新しい事故の事例情報が作成される。
【効果】 複数の事例を１つにまとめるので、同様の事例が重複して構築されることがなく、最適な事例を構築することができる。
【効果】 複数の事例を１つにまとめるので、同様の事例が重複して構築されることがなく、最適な事例を構築することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は事例構築装置およびその事例構築方法に関し、特にたとえば、或る業務についての事故の事例についての事例データを知識としてデータベースに構築する、事例構築装置およびその事例構築方法に関する。
【背景技術】
【０００２】
この種の事例構築装置の一例が特許文献１に開示される。この特許文献１の警告システムによれば、看護師が看護業務を行うとき、当該看護業務に対応するシナリオに従って実際の業務が実行されているか否かを判断する。具体的には、看護師の実際の業務と、看護業務に対応するシナリオとから看護業務の目標を得られるかどうかを判断する。そして、看護業務の目標を得られないことが判断されたときに、シナリオ違反のアラームを看護師に与える。
【特許文献１】特開２００７−３４７３８号公報[G08B 21/02, G06Q 50/00, G06N 5/04, A61G 12/00]
【発明の開示】
【発明が解決しようとする課題】
【０００３】
この背景技術では、必要なときにのみ看護師にアラームを与えるようにしてあるが、シナリオ違反かどうかの判断処理を実行する場合に、データベースに記憶されているすべてのシナリオを検索するようにしてあるため、処理が膨大となり、判断処理に時間がかかってしまう恐れがあった。
【０００４】
それゆえに、この発明の主たる目的は、新規な、事例構築装置およびその事例構築方法を提供することである。
【０００５】
また、この発明の他の目的は、シナリオ違反の判断処理を軽減するためのデータベースを構築できる、事例構築装置およびその事例構築方法を提供することである。
【課題を解決するための手段】
【０００６】
本発明は、上記の課題を解決するために、以下の構成を採用した。なお、括弧内の参照符号および補足説明等は、本発明の理解を助けるために後述する実施の形態との対応関係を示したものであって、本発明を何ら限定するものではない。
【０００７】
第１の発明は、或る業務についての事故の事例についての事例データを記録し、当該事例データを知識としてデータベースに構築する事例構築装置であって、事故の内容と事故が発生したときの処置の内容と事故が発生したときに使用していた物の名称とを含む事故情報を少なくとも含む事例情報を記憶する事例情報記憶手段、事例情報記憶手段に記憶された複数の事例情報のうち、事故の内容が一致する事例情報をグループ化するグループ化手段、グループ化手段によってグループ化された複数の事例情報の中で、事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在するか否かを判断する事故情報判断手段、事故情報判断手段によって事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、グループ化した事例情報を１つにまとめて新規の事例情報を作成する新規事例作成手段、および新規事例作成手段によって作成された新規の事例情報をデータベースに登録する登録手段を備える、事例構築装置である。
【０００８】
第１の発明では、事例構築装置（１２）は、或る業務（たとえば、看護業務）についての事故の事例についての事例データをデータベース（３０）に構築する。事例情報記憶手段（１２，３６）は、事故の内容と事故が発生したときの処置（行動）の内容と事故が発生したときに使用していた物（薬品・器具）の名称とを含む事故情報を少なくとも含む事例情報を記憶する。たとえば、日々発生する事故の事例情報が蓄積されているのである。グループ化手段（１２，Ｓ９１）は、事例情報記憶手段に記憶された複数の事例情報のうち、事故の内容が一致する事例情報をグループ化する。事故情報判断手段（１２，Ｓ１０３，Ｓ１０９）は、
グループ化手段によってグループ化された複数の事例情報の中で、事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在するか否かを判断する。新規事例作成手段（１２，Ｓ１０５，Ｓ１０７，Ｓ１１１，Ｓ１１３，Ｓ１１５，Ｓ１１７，Ｓ１１９，Ｓ１２１）は、事故情報判断手段によって事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、グループ化した事例情報を１つにまとめて新規の事例情報を作成する。つまり、同じまたは類似する処置を行っていたときに発生した事故や同じまたは類似する物を使用ないし所持していたときに発生した事故についての事例情報がまとめられる（統合される）。登録手段（１２，Ｓ１２３）は、新規事例作成手段によって作成された新規の事例情報をデータベースに登録する。
【０００９】
第１の発明によれば、同じ事故の内容について、同じまたは類似する処置の内容や物の名称をまとめることにより１つの事故の事例情報を作成するので、同様の事故の事例情報が重複してデータベースに登録されるのを回避することができる。つまり、最適な事故の事例情報を構築することができる。
【００１０】
第２の発明は第１の発明に従属し、新規事例作成手段は、事故情報判断手段によって事故が発生したときの処置の内容が少なくとも類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときに使用していた物の名称のそれぞれを含むように、グループ化した事例情報を１つにまとめて新規の事例情報を作成する。
【００１１】
第２の発明では、新規事例作成手段は、事故情報判断手段によって事故が発生したときの処置の内容が少なくとも類似する、つまり同一のまたは類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときに使用していた物の名称のそれぞれを含むように、たとえば、リストにして記述することにより、グループ化した事例情報を１つにまとめて新規の事例情報を作成する。ただし、同一の事例情報については、そのまま物の名称を記述した新規の事例情報が作成される。
【００１２】
第２の発明によれば、類似する物については、それぞれを含むようにリストにするので、同様の事例情報が重複して作成されるのを回避することができる。
【００１３】
第３の発明は第１の発明に従属し、新規事例作成手段は、事故情報判断手段によって事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときの処置の内容のそれぞれを含むように、グループ化した事例情報を１つにまとめて新規の事例情報を作成する。
【００１４】
第３の発明では、新規事例作成手段は、事故情報判断手段によって事故が発生したときに使用していた物の名称が少なくとも類似する、すなわち同一のまたは類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときの処置の内容のそれぞれを含むように、グループ化した事例情報を１つにまとめて新規の事例情報を作成する。ただし、同一の事例情報については、そのまま処置の内容を記述した新規の事例情報が作成される。
【００１５】
第３の発明においても、第２の発明と同様に、同様の事例情報が重複して作成されるのを回避することができる。
【００１６】
第４の発明は第１ないし第３の発明に従属し、新規事例作成手段は、事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称に類似する内容を追加する追加手段を含む。
【００１７】
第４の発明では、追加手段（１２，Ｓ１１５）は、事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称に類似する内容を追加する。つまり、実際に発生した事故の事例のみならず、それに類似する内容（類型）が追加される。
【００１８】
第４の発明によれば、実際に発生した事故の事例のみならず、その類型を含む新しい事故の事例情報が作成されるので、より最適な事故の事例情報を構築することができる。
【００１９】
第５の発明は、或る業務についての事故の事例についての事例データを記録し、当該事例データを知識としてデータベースに構築する事例構築装置の事例構築方法であって、（ａ）事故の内容と事故が発生したときの処置の内容と事故が発生したときに使用していた物の名称とを含む事故情報を少なくとも含む事例情報を記憶し、（ｂ）ステップ（ａ）によって記憶された複数の事例情報のうち、事故の内容が一致する事例情報をグループ化し、（ｃ）ステップ（ｂ）によってグループ化された複数の事例情報の中で、事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在するか否かを判断し、（ｄ）ステップ（ｃ）によって事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、グループ化した事例情報を１つにまとめて新規の事例情報を作成し、そして（ｅ）ステップ（ｄ）によって作成された新規の事例情報をデータベースに登録する、事例構築方法である。
【００２０】
第５の発明においても、第１の発明と同様に、最適な事故の事例情報を構築することができる。
【発明の効果】
【００２１】
この発明によれば、同じ事故の内容について、同じまたは類似する処置の内容や物の名称をまとめることにより１つの事故の事例情報を作成するので、同様の事故の事例情報が重複してデータベースに登録されるのを回避することができる。つまり、最適な事故の事例情報を構築することができる。
【００２２】
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【発明を実施するための最良の形態】
【００２３】
図１を参照して、この発明の一実施例である警告システム１０は、たとえば病院に適用され、少なくとも、警告装置および事故の事例を構築する事例構築装置として機能するサーバ１２を含む。このサーバ１２は、有線或いは無線による通信回線（ネットワーク）１４を介して複数の看護師用端末（以下、単に「端末」という。）１６、複数の通過センサ１８および複数の中継器２０に接続される。端末１６は、ＰＤＡやＰＨＳのような携帯型の端末であり、看護師毎に割り当てられる。通過センサ１８は、赤外線を受光する受光装置であり、入院患者を収容する病棟内の廊下や診察室、手術室、トイレ、階段室、病室および看護師詰所などの各部屋の出入り口などに配置される。中継器２０は、ＰＤＡや携帯型のコンピュータのような携帯型の装置であり、看護師毎に割り当てられる。
【００２４】
図２はサーバ１２の具体的な構成を示すブロック図であり、サーバ１２には、図１では省略したが、モニタ装置２２が接続される。モニタ装置２２は、たとえば、複数の対物センサ、複数の集音マイク（音センサ）および複数のビデオカメラ（イメージセンサ）などのセンサを含む。図示は省略するが、この実施例では、複数の対物センサは、体温計、血圧計、注射器、点滴注射器（注入器）、血液採取用試験管、検尿コップなどの器具（医療機器など）を格納してある格納箱（格納庫）の取り出し部分（出入り口）、格納箱（格納庫）の鍵やナースコール端末などに設置され、それらの器具等についての使用（取り出し）の有無を検知する。ただし、これらの器具等に、電子タグ情報（ＲＦ−ＩＤ）やバーコードのような識別情報を付加しておき、タグ情報やバーコードを読み取ることにより、その使用の有無を検出するようにしてもよい。
【００２５】
複数の集音マイクは、入院患者を収容する病棟内の廊下および病室（ベッド或いはその近傍）などに設置され、周囲音を集音する。さらに、複数のビデオカメラは、集音マイクと同様に、入院患者を収容する病棟内の廊下および病室（ベッド或いはその近傍）などに設置されるとともに、看護師詰所などにも設置され、主として、看護業務を行う看護師（の行動）を撮影する。ここで、看護業務とは、問診、検温、検圧、注射、投薬、点滴注射、退院指導などの看護師が行うべき業務の総称である。ただし、この実施例では、単に「看護業務」という場合には、任意の１つの業務を示す。
【００２６】
また、図２に示すように、サーバ１２には、８つのデータベース（ＤＢ）が接続される。具体的には、属性ＤＢ２４、電子カルテＤＢ２６、シナリオＤＢ２８、知識ＤＢ３０、行動履歴ＤＢ３２、病棟イベントＤＢ３４、仮ＤＢ３６およびグループＤＢ３８がサーバ１２に接続される。
【００２７】
属性ＤＢ２４は、この警告システム１０が適用される病棟（病院）内で働く者（この実施例では、看護師）についての属性情報を記憶する。この実施例では、属性情報とは、看護師としての職歴（経験年数（たとえば、月日））および当該病院（病棟）や現在の部署での経験（継続年数（たとえば、月日））を意味する。
【００２８】
電子カルテＤＢ２６には、現在入院中或いは治療中の患者についての電子カルテが記録される。図示は省略するが、この電子カルテは、医師等が記載するカルテの内容から必要な事項を抽出するとともに、必要な事項を追加して、電子データにしたものである。たとえば、電子カルテには、患者名、担当看護師名（または、識別情報（看護師ＩＤ））、性別、病名、病状、処方（どのような注射や点滴、或いは投薬をするかという処方および処方する時間）、リハビリの状況、入院暦、患者に対する注意事項などの情報の電子データ（テキストデータ）が記述される。
【００２９】
シナリオＤＢ２８には、看護業務の正しい行動手順（シナリオ）が記述される。ただし、看護業務の実行の際に使用する器具についての情報やその使用方法についての情報も含まれる。ここで、シナリオｓｉは、看護師の業務マニュアルを参照して作成された、看護業務における行動ないし動作（イベント）の集合であり、基本的な手順（時系列）に従って並べられる。ただし、後述するように、シナリオＤＢ２８に登録されたシナリオｓｉと一致しない行動列が発見された場合には、新しいシナリオｓｉとして追加される。たとえば、シナリオｓｉは数１で示される。ただし、数１において、「ｉｎ ｃｈｒｏｎｏｌｏｇｉｃａｌ ｏｒｄｅｒ」としてあるのは、すべてのイベントｅｉを必ずしも手順（時系列）に従って実行する必要はないが、一部に時系列に従って実行する必要があるイベントｅｉを含んでいることを意味する。
【００３０】
［数１］
【００３１】
たとえば、シナリオｓｉ，ｓｈ，ｓａは、それぞれ、複数のイベントによって構成され、数２で示される。
【００３２】
［数２］
ｓｉ＝｛ｅｉ１＝注射器を準備する，ｅｉ２＝蒸留水とダイアモックス（Ｄｉａｍｏｘ）とを準備する，ｅｉ３＝ダイアモックスを溶かす，ｅｉ４＝ダイアモックスを溶かしたものを吸引する，ｅｉ５＝待つ，ｅｉ６＝注射をする｝
ｓｈ＝｛ｅｈ１＝各種モニタの電源の確認，ｅｈ２＝点滴のセット，ｅｈ３＝必要物品の準備，ｅｈ４＝吸引をセット，ｅｈ５＝腰・硬麻の準備，ｅｈ６＝ライト・ヘッドの位置を確認｝
ｓａ＝｛ｅａ１＝病棟看護師より申し送りを受ける，ｅａ２＝コスト表にＩＤカードを押す，ｅａ３＝麻酔医に患者の血圧等を報告，ｅａ４＝胸写をシャーカステンにかける，ｅａ５＝モニタ類の装着，ｅａ６＝血管確保の介助，ｅａ７＝腰・硬麻の介助，ｅａ８＝麻酔導入の介助，ｅａ９＝導尿・深部体温モニタの装着，ｅａ１０＝電気メスの対極板の貼付，ｅａ１１＝体位をとる，ｅａ１２＝Ｌ枠、メーヨ台、ライトの設置、ｅａ１３＝ガウンテクニックの介助，ｅａ１４＝イソジン、生食を器機台に出す、ｅａ１５＝電気メス、吸引のコード接続｝
ただし、シナリオｓｉ（他のシナリオｓｈ，ｓａも同様。）は、数３に示すように、複数のシナリオｓｉｎ（以下、説明の都合上、「部分シナリオ」ということがある。）の集合で表わすことができる。詳細な説明は省略するが、各部分シナリオｓｉｊは、２以上のイベント（ｅ）の集合（イベント群）で表わされる。また、数３において、Ｏｉはシナリオｓｉを実行した場合における最終的な目標であり、Ｏｉｊは部分シナリオｓｉｊを実行した場合における下位の（補助的な）目標である。ただし、最終的な目標（最終目標）は、看護師がシナリオｓｉに従って看護業務を実行することにより得られる。つまり、最終目標は、看護行為による正しい結果である。また、下位の目標（下位目標）は、部分シナリオｓｉｊに従って看護業務の一部を実行することにより得られる。
【００３３】
［数３］
ｓｉ＝｛ｓｉ１，ｓｉ２，…，ｓｉｎ；Ｏｉ｝
ｓｉｊ＝｛ｅｊ１，ｅｊ２，…，ｅｊｋ；Ｏｉｊ｝
ただし、たとえば、或る部分シナリオｓｉｌ（ｃ）＝｛ｅｌ１，ｅｌ２，…，ｅｌｍ；Ｏｉｌ｝は時系列に従って実行する必要があるが、他の部分シナリオｓｉｐ（ｎ）＝｛ｅｐ１，ｅｐ２，…，ｅｐｑ；Ｏｉｐ｝は時系列に従って実行する必要はない。たとえば、数２に示した例では、イベントｅｉ４（ダイアモックスを溶かしたもの吸引する）は、イベントｅｉ６（注射する）の前に実行されている必要がある。
【００３４】
なお、図示は省略するが、時系列に従って実行する必要のある部分シナリオであるか否かの情報は、各部分シナリオにラベルを付して識別可能としてある。ただし、部分シナリオであるか否かの情報は、各部分シナリオに対応づけて別途記憶しておいてもよい。
【００３５】
知識ＤＢ３０には、公理および仮説についてのデータが記憶される。この実施例では、公理とは、該当の患者に対する処方または処置の理想状態が必然的に得られる事象、行為、または要素などとその理想状態の因果律、さらにもっと一般的に言えば、どのような場合でも関係が崩れることがない、そのような関係（一般的事実）のことである。また、仮説とは、モニタ手段（この実施例では、通過センサ１８、中継器２０、モニタ装置２２）やＲＦＩＤ（タグ情報）などで観測可能な事象、行為、要素など、可変なもの、同時に成り立たない可能性があるもの（イベント）をいう。また、知識ＤＢ３０には、看護業務に関する知識も記憶される。具体的には、看護業務毎に、看護業務を行うときの両手、胸および腰についての加速度の時間変化（加速度データ）を予め取得して、これを辞書データとして記憶してある。ただし、看護師毎に看護業務を行う手順、癖或いは身体的な特徴（身長，手の長さなど）が異なるため、看護師毎に辞書データを記憶するようにしてもよい。さらに、知識ＤＢ３０には、類義語辞書が記憶される。この類義語辞書は、類似する用語を検索可能な辞書であり、一般的な用語（言葉）のみならず、複数の看護業務の名称（シナリオ名）についての総括名称、類似する薬品や器具の名称についても検索可能である。また、知識ＤＢ３０には、アクシデントやインシデント（事故）についての事例の情報（事例情報）のデータ（事例データ）が識別情報（事故ラベル）を付して識別可能に記憶される。この事例データは、参照するシナリオを特定する（絞り込む）ために用いる。たとえば、看護師が看護業務を行う際に、その状況（行動，現在位置，使用する薬品・器具など）から事例データが特定され、特定された事例データが示す看護業務の名称（シナリオ名）に応じたシナリオが参照するシナリオとして特定される。ただし、後述するように、学習することにより、新しい事故の事例情報の事例データが知識ＤＢ３０に登録（追加）される。
【００３６】
たとえば、事故の事例情報の内容は次の通りである。或るイベント（看護業務）について事故が発生した場合に、当該事故の識別情報（事故ラベル）に対応して、理由、事故、属性情報（職歴、部署経験）、時間、場所および背景の各情報が記録される。ただし、背景の情報は省略してもよい。これらの情報は、たとえば、テキストで記述される。
【００３７】
なお、看護師のみならず、医師や清掃員のように、病院（病棟）内で勤務する者についてのすべての事故の事例について管理する場合には、属性情報として、職務の種類（医師，看護師，清掃員などの別）を記録するようにしてもよい。
【００３８】
理由の情報としては、当該事故の発生した看護業務の名称（シナリオ名）が記憶される。事故詳細の情報としては、薬品名または器具のような看護業務に使用する物の名称、事故が発生したときの処置の内容、事故の詳細についての内容（事故の内容）が記憶される。たとえば、事故が発生したときの処置の内容としては、オーダー、伝達、輸血、点滴注射、注射、投薬などのイベントであり、当該看護業務の名称と一致することもある。また、事故の内容は、過剰投与、混注ミス、薬剤混同、患者取り違えなどである。職歴の情報としては、看護師としての経験年数（たとえば、年月）が記憶される。部署経験の情報としては、当該部署に配属されてからの継続年数（たとえば、年月）が記憶される。時間の情報としては、事故が発生した時刻（時分）ないし時間帯が記憶される。場所の情報としては、事故が発生した場所が、病室、トイレ、浴室、洗濯室、廊下、階段室、診察室、手術室、レントゲン室などのように具体的に記憶される。背景の情報としては、同じ名前の患者が存在すること、ナースコールで呼び出されたこと、忙しかったこと、複数種類の薬品が存在することなどのように、事故の背景に有る様々な事情（状況）が記憶される。
【００３９】
ただし、理由の情報については、後述する行動履歴ＤＢ３２に記憶された加速度データおよび音声データと、知識ＤＢ３０に記憶された辞書データとから特定することができる。また、職歴の情報や部署経験の情報については、属性ＤＢ２４から取得することができる。そして、場所の情報および時間の情報については、後述する病棟イベントＤＢ３４から取得することができる。
【００４０】
行動履歴ＤＢ３２は、看護師の行動履歴のデータ（行動履歴データ）を看護師毎に記憶する。行動履歴データは、中継器２０から送信される加速度データおよび音声データを意味する。ただし、行動履歴データは、看護業務毎に１つのファイルとして記憶される。たとえば、各ファイルには、該当する看護師の看護師ＩＤのラベルが付される。
【００４１】
病棟イベントＤＢ３４は、上述した通過センサ１８から得られるデータと、上述したモニタ装置２２から得られる対物検知データ、音声データおよび映像データと（これらのデータをまとめて「病棟イベントデータ」という。）を記録する。通過センサ１８から得られるデータには、後述するように、当該通過センサ１８の識別情報に、検知した看護師の看護師ＩＤが付加されている。対物検知データには、検知する対象となる医療器具等の名称のような識別情報がタグとして付される。音声データには、集音マイク２４の設置場所を示す識別情報がタグとして付される。映像データには、ビデオカメラ２８の設置場所を示す識別情報がタグとしてとして付される。つまり、対物検知データから検知対象物を特定することができ、音声データや映像データのタグから集音したり映像を取得した場所を特定したりすることができる。
【００４２】
ここで、サーバ１２は、その内部に時計回路１２ａを有している。この時計回路１２ａは、日付および時間を計時する。したがって、サーバ１２は、時計回路１２ａから日付および時間を検出し、上述のような病棟イベントデータを取得したときの時間（時間データ）を、当該病棟イベントデータに付加する。たとえば、サーバ１２は、通過センサ１８からのデータを受信すると、そのデータに時間データを付加して、病棟イベントＤＢ３４に記録する。また、対物検知データの入力があると、サーバ１２は当該対物検知データに時間データを付加して、病棟イベントＤＢ３４に記録する。集音マイクは、たとえば、物が落下したときに生じる音や、人間が発した大声などを集音することを目的とするため、所定のレベル以上の音が入力されたときに、当該音に対応する音データがサーバ１２に入力され、サーバ１２は当該音データに時間データを付加して、病棟イベントＤＢ３４に記録する。したがって、たとえば、患者が転倒したり、ナースコール端末が押されたりしたことが記憶される。ただし、基本的にはタイムラプス(間欠記録)ではあるものの、時系列的に映像データが蓄積される。
【００４３】
仮ＤＢ３６は、事故が発生した場合に、その事故の事例情報を記憶（蓄積）するために用いられる。この仮ＤＢ３６に記憶された事故の事例情報は、予め作成された知識ＤＢ３０に登録されているものとは異なり、事故が発生した場合に、知識ＤＢ３０に登録されている事例情報と同様にして作成されたものである。また、グループＤＢ３８は、新しい事故の事例情報を作成する際の作業領域ないしバッファ領域として用いられる。したがって、グループＤＢ３８に代えて、サーバ１２の内部メモリ（ハードディスクやＲＡＭなど）を用いるようにしてもよい。ただし、図１および図２では、サーバ１２の内部メモリは省略してある。
【００４４】
図３は端末１６の電気的な構成を示すブロック図である。図３を参照して、端末１６はＣＰＵ４０を含み、このＣＰＵ４０には、メモリ４２，キースイッチ４４，ＬＣＤドライバ４６，モータドライバ５０，無線ＬＡＮ５４およびアンプ５６が接続される。また、ＬＣＤドライバ４６にはＬＣＤ４８が接続され、モータドライバ５０には振動モータ５２が接続され、そして、アンプ５６にはスピーカ５８が接続される。
【００４５】
なお、上述したように、端末１６としてＰＨＳを用いる場合には、図３に示すような構成において、さらに通話（電話）機能が備えられる。
【００４６】
ＣＰＵ４０は、端末１６の全体制御を司る。メモリ４２は、ＲＯＭやＲＡＭを含む。この実施例では、端末１６は主として情報提示装置として機能し、ＲＯＭには、情報提示のためのプログラム（情報提示プログラム）や情報提示のために必要なデータ（画像データ，音データ）が記憶されている。ＲＡＭは、ＣＰＵ４０の記憶領域、作業領域およびバッファ領域として用いられる。
【００４７】
なお、この実施例では、情報提示のために必要なプログラムやデータをＲＯＭに記憶するようにしてあるが、サーバ１２からダウンロードするようにしてもよい。このようにすれば、ＲＯＭの使用容量を削減することができる。
【００４８】
キースイッチ４４は、テンキー、十字キーのようなカーソルキーおよび選択キーなどの各種キーないしボタン（スイッチ）であり、看護師の指示入力に用いられる。ＬＣＤドライバ４６はＬＣＤ４８の駆動装置であり、ＣＰＵ４０からの指示に従ってＬＣＤ４８に画像を表示する。図示は省略するが、ＬＣＤ４８には、看護業務に関するメッセージなどの情報を提示するための画面が表示される。モータドライバ５０は、振動モータ５２の駆動装置であり、ＣＰＵ４０からの指示に従って振動モータ５２を駆動する。たとえば、サーバ１２から情報の提示があると、振動モータ５２を駆動することにより、端末１６を振動させて、その旨をユーザに知らせる。または、スピーカ５８から通知音（音声，音楽）を出力して、情報の提示がある旨をユーザに知らせるようにしてもよい。このとき、ＣＰＵ４０からの音データ（音、音声ないし音楽のデータ）は、アナログの音（音声）信号に変換された後、アンプ５６で増幅され、スピーカ５８から出力される。ただし、振動および音（音楽）の両方で通知するようにしてもよい。
【００４９】
無線ＬＡＮ５４は、ＣＰＵ４０の指示に従って、看護師がキースイッチ４４を用いて入力した指示入力（コマンド）を、ネットワーク１４を介してサーバ１２に送信する。詳細な説明は省略するが、サーバ１２では、端末１６の無線ＬＡＮ５４のＭＡＣアドレスを看護師ＩＤに対応づけて管理しているため、通信している端末１６の使用者（看護師）をサーバ１２側で認識することが可能である。ただし、メモリ４２（ＲＯＭ）に看護師ＩＤを記憶しておき、コマンドとともに看護師ＩＤをサーバ１２に送信するようにしてもよい。また、無線ＬＡＮ５４は、サーバ１２から送信された情報（画面表示に関する情報）を受信して、ＣＰＵ４０に与える。
【００５０】
図４に示すように、通過センサ１８は、第１受光モジュール７２および第２受光モジュール７４を含み、第１受光モジュール７２および第２受光モジュール７４は、ゲートの上部であり、互いに異なる側面に装着される。また、ゲートの上に載置されるケース１８０内には、通過センサ１８の受光モジュール（７２，７４）以外のコンポーネント（ＣＰＵ７０，ＲＡＭ７６，無線ＬＡＮ７８：図６参照）が内蔵される。ただし、ゲートは分かり易く示すために図示しただけであり、通常は、看護師詰所、診察室、病室のような部屋の出入り口、廊下と廊下との連結部（十字路、Ｔ字路など）、廊下と階段との連結部のような要所に通過センサ１８は設置される。また、必要であれば、エレベータのゲートに設置されてもよい。
【００５１】
また、図５に示すように、各看護師の頭部には、赤外線信号を発信する送信機１１０が装着される。たとえば、送信機１１０は、クリップのような固定器具を用いて、ナースキャップや頭髪に固定される。送信機１１０が発信する赤外線信号は、たとえば、８ビットの固定のパターン（看護師ＩＤ）である。
【００５２】
図６は通過センサ１８の電気的な構成を示すブロック図である。図６を参照して、通過センサ１８はＣＰＵ７０を含み、ＣＰＵ７０には、第１受光モジュール７２、第２受光モジュール７４、ＲＡＭ７６および無線ＬＡＮ７８が接続される。各通過センサ１８の受光モジュール（７２，７４等）のそれぞれには、固有の識別情報（受光モジュールＩＤ）が割り当てられている。各受光モジュール（７２，７４等）は、送信機１１０（図５参照）からの赤外線信号を検出する。ここで、送信機１１０から送信される赤外線信号は、上述したように、８ビットの固定のパターン（看護師ＩＤ）である。たとえば、受光モジュール（７２，７４）は、看護師ＩＤを受信すると、受信した看護師ＩＤをＣＰＵ７０に与える。ＣＰＵ７０は、看護師ＩＤを受信した受光モジュール（７２，７４）の受光モジュールＩＤを当該看護師ＩＤに付加して、ＲＡＭ７６に記憶（一時記憶）し、その後、無線ＬＡＮ７８およびネットワーク１４を介して、サーバ１２に送信する。
【００５３】
サーバ１２では、受光モジュールＩＤが付加された看護師ＩＤを受信すると、受信した受光モジュールＩＤに対応する場所を看護師ＩＤが示す看護師の現在位置として検出する。
【００５４】
なお、この実施例では、端末１６の処理負担の軽減やメモリ４２の容量節約のために、サーバ１２側で、当該看護師の現在位置を特定するようにしてあるが、通過センサ１８がネットワーク１４を介して受光モジュールＩＤと看護師ＩＤとを端末１６に送信し、当該端末１６が看護師自身の現在位置を特定するようにしてもよい。
【００５５】
図７は中継器２０の電気的な構成を示すブロック図である。図７を参照して、中継器２０はＣＰＵ９０を含む。ＣＰＵ９０には、メモリ９２，エンコーダ９４，非接触センサ９８，加速度センサ１００および無線ＬＡＮ１０２が接続される。メモリ９２は、ワークメモリないしバッファメモリとして働き、ＣＰＵ９０によって使用される。エンコーダ９４にはピンマイク９６が接続され、エンコーダ９４は、ピンマイク９６から入力される音声信号をＭＰ３のような圧縮音声データ（以下、単に「音声データ」という。）に変調してＣＰＵ９０に入力する。このように、音声信号を圧縮変調するのは、メモリ９２の使用量を比較的少なくするためであり、また、後述するように、無線ＬＡＮ１０２を介して送信するデータのデータ量を低減するためである。たとえば、看護師は、ピンマイク９６を通して、開始するまたは終了した看護業務の内容を音声で入力する。したがって、サーバ１２は、音声を解析することにより、看護師が行っている看護業務の内容およびその開始と終了とを知ることができる。
【００５６】
なお、図７では、簡単のため、複数の加速度センサ１００ａ，１００ｂ，１００ｃ，１００ｄを、加速度センサ１００として包括的に示してある（図５参照）。
【００５７】
ここで、図５を参照して分かるように、端末１６，中継器２０および赤外線を発信する送信機１１０は、各作業者（看護師）に装着される。図５に示すように、端末１６は、看護師の手首に装着される。図示は省略するが、端末１６のＬＣＤ４８が見えるように、腕時計を装着するように、バンドのような固定器具を用いて装着される。
【００５８】
また、中継器２０では、ピンマイク９６，非接触センサ９８および加速度センサ１００（１００ａ，１００ｂ，１００ｃ，１００ｄ）以外の回路コンポーネント（図７参照）はボックス２００に収容され、ボックス２００は看護師の腰部（ベルト部分）に装着される。
【００５９】
図５に示すように、ピンマイク９６は、看護師の衣服（白衣）の襟元付近に装着される。また、非接触センサ９８は、ペン型のケースに収容され、看護師の白衣の胸ポケットに挿すように収納される。ただし、図面では、分かり易く示すために、ペン型のケースを胸ポケットの外部に記載してある。
【００６０】
また、看護師の両手（両腕）、胸および腰などには、加速度センサ１００が装着される。この実施例では、加速度センサ１００ａが右腕に装着され、加速度センサ１００ｂが左腕に装着され、加速度センサ１００ｃが胸に装着され、そして、加速度センサ１００ｄが腰に装着される。ただし、図５では、分かり易く示すために、各加速度センサ１００を白衣の外部に記載してあるが、各加速度センサ１００は、実際には、ゴムバンドのような適宜の固定器具を用いて、白衣の内部で腕などに固定される。
【００６１】
なお、図５においては省略するが、非接触センサ９８と加速度センサ１００とは接続線を用いてボックス２００内のＣＰＵ９０に電気的に接続され、ピンマイク９６は接続線を用いてボックス２００内のエンコーダ９４に電気的に接続される。ただし、接続線を用いずに、ブルートゥースのような近距離無線によって接続するようにしてもよい。つまり、電気的に接続されればよいのである。
【００６２】
また、この実施例で用いるピンマイク９６は指向性を有するものである。これは、ピンマイク９６を装着する看護師の音声のみを検出するようにするためであり、さらには、患者のプライバシーを守るためでもある。
【００６３】
非接触センサ９８としては、焦電センサを用いることができ、ＣＰＵ９０は非接触センサ９８からの入力に応じてピンマイク９６をオン／オフする。この実施例では、非接触センサ９８すなわち焦電センサの前で、看護師が手を２回上下させると、その検出信号がＣＰＵ９０に入力され、これに応じて、ＣＰＵ９０はピンマイク９６をオンし、その後、看護師が焦電センサの前で、手を２回上下させると、ピンマイク９６をオフする。ただし、ＣＰＵ９０は、看護師の操作によらないで、所定時間（１０秒）が経過した場合にもピンマイク９６をオフするようにしてある。
【００６４】
加速度センサ１００は、たとえば、多軸（３軸）の加速度センサであり、サンプリング周波数が２００Hzであり、加速度は±３Ｇ（Ｇは重力）まで計測可能である。この中継器２０では、加速度センサ１００で検出される加速度のデータ（加速度データ）がＣＰＵ９０に与えられる。ＣＰＵ９０は、加速度センサ１００からの加速度データをメモリ９２に記憶（一時記憶）し、一定時間（たとえば、１０秒）毎に、その一定時間分の加速度データを、無線ＬＡＮ１０２およびネットワーク１４を介してサーバ１２に送信する。上述したように、知識ＤＢ３０には、予め看護業務を実行した場合の加速度データの時間変化を辞書データとして記憶しているので、中継器２０から送信される加速度データと比較することにより、実行中の看護業務の内容を特定することができる。たとえば、辞書データと中継器２０からの加速度データとを、周知のＤＰマッチングの方法により、比較することにより、看護業務を特定することができる。
【００６５】
なお、加速度センサ１００に代えて、ジャイロセンサ、照度センサまたは温度センサなどの他のセンサを用いることもできる。他のセンサを用いる場合には、その他のセンサの出力がサーバ１２に送信される。ただし、かかる場合には、他のセンサを用いて予め取得されたデータが看護業務に対応付けられた辞書データとして知識ＤＢ３０に記憶される。
【００６６】
上述したように、サーバ１２は、通過センサ１８からのデータに基づいて看護師の現在位置（所在）を知ることができる。また、モニタ装置２２（対物センサ）の出力によって、看護師が使用する器具等を知ることができる。さらに、モニタ装置２２（集音マイク）の出力およびピンマイク９６を通して入力される音声に基づいて看護師が実行しようとする看護業務を知ることもできる。さらにまた、モニタ装置２２（ビデオカメラ）の撮影映像（画像データ，映像データ）を分析したり、中継器２０からの加速度データを辞書データと比較したりすることにより、看護師の行動を検出（特定）することもできる。たとえば、このようなモニタ手段（サーバ１２，通過センサ１８，中継器２０，モニタ装置２２）の検出結果を複合的に勘案すれば、看護師の行動（イベント）を比較的正確に検出することができる。以下、同様である。
【００６７】
なお、モニタ装置２２（集音マイク）の出力（音声）を解析したり、モニタ装置２２（ビデオカメラ）の撮影映像を解析したりすることにより、病院（病棟）内に存在する他の者すなわち医師、清掃員、患者等の様子を知ることもできる。
【００６８】
また、看護師の行動が目標を達成するか否かの推論は、数４に従って行われる。ただし、背景知識Ｆとしては、知識ＤＢ３０に含まれる公理も含まれる。
【００６９】
［数４］
【００７０】
ただし、∪は論理のＯＲを意味する。
【００７１】
また、最終目標Ｏをサブ目標Ｏｊの部分集合と考えると、数５に従って推論することも可能である。
【００７２】
［数５］
【００７３】
ここで、推論結果がサブ目標Ｏｊを得ることができる場合には、次の部分シナリオについての推論を行う。ただし、当該サブ目標Ｏｊが最終目標Ｏと一致する場合には、看護業務を終了したと判断する。
【００７４】
一方、推論結果がサブ目標Ｏｊを得ることができない場合には、次のいずれかの場合に、看護業務がシナリオに違反していることを警告する。これは、医療事故や医療ミスが発生するのを事前に防止するためである。具体的には、推論結果がサブ目標Ｏｊを得ることができない場合には、看護師が別の看護業務に移行したかどうかを判断する。ここで、看護師の行動が、戻るべき、または、進むべきイベントに復帰または到達し得ないときに、別の看護業務に移行したと判断される。
【００７５】
看護師が別の看護業務に移行していなければ、現在の看護業務を途中で終了しようとしているかどうかを判断する。たとえば、看護師が現在の看護業務に全く関係のないイベントを実行したり、途中のイベントを飛ばして最後のイベントを実行しようとしたり（たとえば、ダイアモックスを溶かさないで、注射しようとする。）すると、現在の看護業務を途中で終了しようとしていると判断する。
【００７６】
また、看護師が別の看護業務に移行すると、当該別の看護業務を終了した後に、元の看護業務（上述の現在の看護業務）に戻るか否かを判断する。別の看護業務を終了したか否かは、当該別の看護業務についてのシナリオに含まれる最後のイベントを実行したか否かで判断される。また、元の看護業務に戻ったか否かは、看護師の行動が元の看護業務に対応するシナリオに含まれる、かつ実行すべきであるイベントと一致するか否かで判断される。
【００７７】
現在の看護業務を途中で終了しようとする場合、または、別の看護業務を終了した後に元の看護業務に戻らない場合には、当該看護業務についてのシナリオの正しい最終目標を得ることができない。つまり、上述したような医療事故などの不都合を引き起こす可能性があるため、看護師にシナリオに違反していることの警告を与えるようにしてある。
【００７８】
なお、看護師が或る看護業務を行っている場合に、他の看護業務を頼まれることは日常茶飯事であり、単に他の看護業務に移行したことだけでは警告を発しないようにしてある。これは、警告の乱発を防止して、医療事故や医療ミスが発生する恐れのあるような本当に必要なときだけ警告を与えて、警告システム１０としての機能を十分に発揮させるためである。
【００７９】
具体的には、サーバ１２は図８および図９に示すフロー図に従って全体処理を実行する。ただし、図８および図９に示す全体処理は、着目する１人の看護師について一定時間（たとえば、１５分〜３０分）毎に実行される。つまり、全体処理は看護師毎に実行される。図８に示すように、サーバ１２は全体処理を開始すると、ステップＳ１で、業務を確認する。ここでは、図示しないワークフローのデータを参照して、着目する看護師が担当する患者について行うべき看護業務が有るかどうかを判断するのである。ただし、ワークフローは、当該着目する看護師の一日の看護業務が時系列に従って記述された表であり、電子カルテなどに基づいて作成される。
【００８０】
続くステップＳ３では、看護業務の開始時間であるかどうかを判断する。つまり、開始すべき看護業務が有るかどうかを判断する。ただし、厳密に看護業務の開始時間であるかを判断する必要はなく、看護業務の開始時間の前後一定時間（たとえば、３〜５分）内であるかどうかを判断するようにしてある。
【００８１】
ステップＳ３で“ＮＯ”であれば、つまり看護業務の開始時間でなければ、そのまま同じステップＳ３に戻る。ただし、無駄な処理を削減するために、一定時間（たとえば、３〜５分）待機してから、ステップＳ３に戻るようにしてもよい。一方、ステップＳ３で“ＹＥＳ”であれば、つまり看護業務の開始時間であれば、ステップＳ５で、着目する看護師が看護業務を開始したかどうかを判断する。ここでは、着目する看護師の看護師ＩＤを検出する通過センサ１８が変化したり、ビデオカメラで撮影される当該看護師に動きがあったり、当該看護師がピンマイク９６を通して看護業務を開始することの音声入力があったりしたかどうかを判断する。
【００８２】
ステップＳ５で“ＮＯ”であれば、つまり看護業務を開始していなければ、ステップＳ７で、業務開始のアラーム（警告）を発して、ステップＳ５に戻る。ここで、警告は、たとえば、着目する看護師に割り当てられた端末１６に、看護業務を開始すべき旨のメッセージを送信することにより行う。なお、メッセージのような情報が端末１６に送信されると、上述したように、音ないし振動またはその両方で当該端末１６を装着する看護師にメッセージ（情報）があることが報知される。
【００８３】
一方、ステップＳ５で“ＹＥＳ”であれば、つまり看護業務を開始すれば、ステップＳ９で、看護師の現在の状況を検出する。具体的には、ここでは、サーバ１２は、看護師の現在位置、現在の行動（処置）および看護師が所持ないし使用する薬品・器具を、通過センサ１８からのデータ、中継器２０からのデータまたはモニタ装置２２からのデータに基づいて検出する。ここで、通過センサ１８からのデータに基づいて看護師の現在位置を検出するのは、中継器２０からのデータに基づいて処置（イベント）を特定できない場合であっても、当該看護師の現在位置と当該看護師のワークフローとに基づいて、処置を特定できる場合があるからである。たとえば、看護師の現在位置がレントゲン室や病室であれば、患者のレントゲン撮影の補助を行ったり、患者の検温、検圧、注射または点滴注射を行ったりしていることを特定（推定）することができる。また、モニタ装置２２の出力から使用している物（薬品・器具）を特定することができる。
【００８４】
次のステップＳ１１では、処置や薬品・器具を、特定可能かどうかを判断する。ステップＳ１１で“ＮＯ”であれば、つまり処置や薬品・器具を特定できなければ、そのまま図９に示すステップＳ１５に進む。かかる場合には、事故の事例情報（事例データ）を特定できないため、シナリオｓｉを絞り込むことができない。したがって、後述するステップＳ１５において、シナリオＤＢ２８に記憶された全シナリオｓｉを参照することとなる。一方、ステップＳ１１で“ＹＥＳ”であれば、つまり処置や薬品・器具を特定できれば、ステップＳ１３で、シナリオＤＢ２８に記憶された全シナリオｓｉのうち、特定した処置や薬品・器具を含む事例データを知識ＤＢ３０から抽出し、抽出した事例データが示すシナリオｓｉを特定（選択）する。ただし、後述するように、事例データが示す事例情報の理由の情報として、シナリオ名の総括名称が記述されている場合には、総括名称が示すすべてのシナリオｓｉが特定される。たとえば、ステップＳ１３では、サーバ１２は、シナリオＤＢ２８において、特定したシナリオｓｉのみにフラグを立てたり、サーバ１２の内部メモリに特定したシナリオｓｉのみを読み出したりすることにより、ステップＳ１５において参照するシナリオｓｉを絞り込むのである。これによって、参照するシナリオｓｉの数が大幅に削減される。
【００８５】
なお、この実施例では、処置や薬品・器具のような事故詳細の情報のみに基づいて事例データ（シナリオ名）を特定するようにしたが、事例データが示す事例情報には、職歴、部署経験、場所および背景の情報も含まれるため、事故詳細の情報に加えて、職歴、部署経験、場所および背景の情報のうちの少なくとも１つ以上をさらに満たす事例データ（シナリオ名）を特定するようにしてもよい。
【００８６】
図９に示すように、ステップＳ１５では、イベントｅｉを含むシナリオｓｉが有るかどうかを判断する。ここでは、サーバ１２は、上述のようにして、着目する看護師の行動を検出する。そして、サーバ１２は、シナリオＤＢ２８の全部または特定した一部のシナリオｓｉを参照して、検出した行動と一致するイベントｅｉを含むシナリオｓｉが存在するかどうかを判断する。
【００８７】
ステップＳ１５で“ＹＥＳ”であれば、つまり看護師の行動と一致するイベントｅｉを含むシナリオｓｉがあれば、ステップＳ１７で、目標Ｏｉを確認する。ここで、目標Ｏｉは、シナリオｓｉに従って業務を行った場合に得られる目標である。ステップＳ１７では、イベントｅｉを含むシナリオｓｉの目標Ｏｉが、ステップＳ９で検出された看護業務（最終目標Ｏ）と一致するかどうかを確認しているのである。
【００８８】
続くステップＳ１９では、現在の背景知識Ｆと行動ｅｉを含むすべてのシナリオｓｉとから最終目標Ｏを説明できないかどうかどうかを判断（確認）する。ステップＳ１９で“ＹＥＳ”であれば、つまり現在の背景知識Ｆと行動ｅｉを含むすべてのシナリオｓｉとから最終目標Ｏを説明できない場合には、そのままステップＳ１５に戻って、シナリオｓｉの検出および目標Ｏｉの確認を再度実行する。しかし、ステップＳ１９で“ＮＯ”であれば、つまり現在の背景知識Ｆと行動ｅｉを含むすべてのシナリオｓｉとから最終目標Ｏを説明できる場合には、ステップＳ２１で、後述する各サブ目標達成の確認および警告処理（図１０および図１１参照）を実行して、全体処理を終了する。
【００８９】
また、ステップＳ１５で“ＮＯ”であれば、つまり看護師の行動と一致するイベントｅｉを含むシナリオｓｉが存在しなければ、ステップＳ２３で、当該看護師の一連の行動（イベントｅｉ）を獲得する。続くステップＳ２５では、着目する看護師が当該看護業務を終了したかどうかを判断する。ステップＳ２５で“ＮＯ”であれば、つまり着目する看護師が当該看護業務を終了していなければ、そのままステップＳ２３に戻る。一方、ステップＳ２５で“ＹＥＳ”であれば、つまり着目する看護師が当該看護業務を終了すれば、ステップＳ２７で、着目する看護師の一連の行動を新しいシナリオｓｉとしてシナリオＤＢ２８に記憶（追加）して、全体処理を終了する。
【００９０】
なお、この実施例では、看護師の行動と一致するシナリオｓｉが存在しない場合には、当該看護師の一連の行動を新しいシナリオｓｉとしてシナリオＤＢ２８に記憶するようにしてあるが、このような一連の行動を別途データベースに蓄積しておき、学習処理によって統合（一般化）するなどして新しいシナリオｓｉを作成するようにしてもよい。
【００９１】
図１０および図１１は、図９に示したステップＳ２１の各サブ目標達成の確認（推論）および警告処理を示すフロー図である。サーバ１２は、各サブ目標達成の確認および警告処理を開始すると、ステップＳ４１で、変数ｊを初期化する（ｊ＝１）。続くステップＳ４３では、現在の背景知識Ｆと部分シナリオｓｉｊとからサブ目標Ｏｊを説明できないかどうかを判断（確認）する。ステップＳ４３で“ＮＯ”であれば、つまり現在の背景知識Ｆと部分シナリオｓｉｊとからサブ目標Ｏｊを説明できると推論されれば、サブ目標Ｏｊを達成できると判断し、ステップＳ４５で、シナリオｓｉｊが時系列順に実行すべきイベントを含むかどうかを判断する。これは、部分シナリオｓｉｊに付されたラベルを参照して判断する。
【００９２】
ステップＳ４５で“ＮＯ”であれば、つまりシナリオｓｉｊが時系列順に実行すべきイベントを含んでいない場合には、そのままステップＳ５１に進む。しかし、ステップＳ４５で“ＹＥＳ”であれば、つまりシナリオｓｉｊが時系列順に実行すべきイベントを含む場合には、ステップＳ４７で、当該イベントが時系列順に実行されているか否かを判断する。ここでは、看護師の行動を検出し、当該行動がシナリオｓｉｊに含まれるイベントに従って実行されようとしているか否かを判断する。
【００９３】
ステップＳ４７で“ＮＯ”であれば、つまりイベントが時系列順に実行されていなければ、ステップＳ４９で、シナリオ違反をアラームして、ステップＳ４７に戻る。しかし、ステップＳ４７で“ＹＥＳ”であれば、つまりイベントが時系列順に実行されている場合には、ステップＳ５１で、現在の業務をすべて終了したかどうかを判断する。つまり、シナリオｓｉに含まれるすべてのイベントｅｉの実行を終了し、目標Ｏｉを達成（ワークフローが示す看護業務を完了）したかどうかを判断する。ステップＳ５１で“ＮＯ”であれば、つまり現在の業務をすべて終了していなければ、ステップＳ５３で、変数ｊをインクリメントして（ｊ＝ｊ＋１）、ステップＳ４３に戻る。つまり、次のサブ目標Ｏｊ＋１を達成するか否かの推論を行う。しかし、ステップＳ５１で“ＹＥＳ”であれば、つまり現在の業務をすべて終了すれば、各サブ目標達成の確認および警告処理をリターンする。
【００９４】
また、ステップＳ４３で“ＹＥＳ”であれば、つまり現在の背景知識Ｆとシナリオｓｉｊとからサブ目標Ｏｊを説明できないと推論されれば、サブ目標Ｏｊを達成できないと判断し、図１１に示すステップＳ５５で、別の看護業務へ移ったかどうかを判断する。ステップＳ５５で“ＮＯ”であれば、つまり別の看護業務に移っていなければ、ステップＳ５７で、現在の看護業務を途中で終了したかどうかを判断する。
【００９５】
ステップＳ５７で“ＮＯ”であれば、つまり現在の看護業務を途中で終了していない場合には、そのまま図１０に示したステップＳ４３に戻る。一方、ステップＳ５７で“ＹＥＳ”であれば、つまり現在の看護業務を途中で終了した場合には、そのままステップＳ６３に進む。
【００９６】
また、ステップＳ５５で“ＹＥＳ”であれば、つまり別の看護業務に移った場合には、ステップＳ５９で、当該別の看護業務に対応するシナリオｓｋを確認して、ステップＳ６１に進む。なお、この実施例では、簡単のため、別の看護業務に対応するシナリオｓｋの確認処理については、１つのステップ（処理）で示してあるが、厳密には、図９に示したステップＳ１５〜ステップＳ１９と同様の処理が実行されるのである。これは、途中で別の看護業務に移行した場合であっても、当該別の看護業務において医療事故等が発生する可能性もあり、当該別の看護業務についてもシナリオを用いた推論により、シナリオ違反の発生を事前に発見し、その警告を与えるためである。
【００９７】
ステップＳ６１では、元の看護業務に戻るか否かを判断する。ここで、元の看護業務は、ステップＳ５５で“ＹＥＳ”と判断される直前までに行っていた看護業務（上述の現在の看護業務）である。ステップＳ６１で“ＹＥＳ”であれば、つまり元の看護業務に戻る場合には、そのままステップＳ４３に戻る。しかし、ステップＳ６１で“ＮＯ”であれば、つまり元の看護業務に戻らない場合には、ステップＳ６３で、シナリオ違反のアラームを与えて、ステップＳ６１に戻る。
【００９８】
なお、図示等は省略したが、ステップＳ４３，Ｓ４７，Ｓ５１，Ｓ５５，Ｓ５７，Ｓ６１の処理では、着目する看護師の行動が検出される。
【００９９】
このように、看護師の看護業務における行動等とシナリオとから得られる結果を推論し、推論結果が所望の目標を達成できない場合にのみ警告を発するので、警告の乱発を防止し、本当に必要なときだけ警告することができる。また、事例データに基づいてシナリオを絞り込むので、判断処理（Ｓ１５，Ｓ１９，Ｓ４７など）の誤りを少なくすることができる。
【０１００】
なお、この実施例では、事故が発生するおそれのある看護師のみに警告を与えるようにしてあるが、当該看護師以外の者（医師、他の看護師、師長）にも警告するようにして、医療事故等を確実に防止するようにしてもよい。
【０１０１】
以上のように、知識として記憶してある事故の事例情報に基づいて、参照するシナリオｓｉを絞り込むことができるので、全部のシナリオｓｉを参照する場合に比べて、シナリオ違反のアラーム（警告）を発するか否かの判断処理を軽減することができる。したがって、最適な事例情報を構築することができれば、警告を発するか否かの判断処理をさらに軽減することができると考えられる。
【０１０２】
このため、この実施例では、日々発生する事故の事例を収集（記憶）しておき、同様の事故の事例については１つにまとめて新しい事故の事例として登録（追加）するようにしてある。
【０１０３】
上述したように、事故の事例情報の事例データには、事例情報に事故ラベルが付され、事例情報には、理由、事故、属性情報、時間、場所および背景の各情報が含まれる。たとえば、「４月の或る早朝、勤務異動してきて間もない看護師がインスリン注射を担当しました。薬品庫からインスリンのバイアルを取り出し、いつものごとく注射器に予定量を扱い、患者さんの所へ出かけて注射してきました。その後、バイアルを薬品庫に戻すときに、「ノボリン３０Ｒ（４０）」と書いたバイアルがあります。自分が持っているインスリンのバイアルには「ノボリン３０Ｒ（１００）」と書かれてありました。患者さんに、「ノボリン３０Ｒ（４０）」のつもりで、「ノボリン３０Ｒ（１００）」の方を注射してしまいました。」という事故の事例がある。
【０１０４】
このような事故の事例では、事例情報は次のように示される。具体的には、事故の事例情報（１）として、｛理由，事故詳細，職歴，部署経験，時間，場所，背景｝＝｛インスリン注射，事故，３年，１年，６：００，病室，異動直後，複数種類の薬品｝と表わすことができる。ただし、事故詳細の情報は、｛薬品，処置，事故の内容｝＝｛ノボリン３０Ｒ（１００），注射，過剰投与｝である。また、背景の情報として、｛異動直後，複数種類の薬品｝が記述されている。
【０１０５】
また、詳細な具体例は省略するが、同様の事故の事例情報（２）として、｛理由，事故，職歴，部署経験，時間，場所，背景｝＝｛ノボリン注射，事故，２年６月，１０か月，１１：００，病室，複数種類の薬品｝が得られ、同様に事故の事例（３）として、｛理由，事故，職歴，部署経験，時間，場所，背景｝＝｛インスリン注射，事故，１０年，５年，１６：００，病室，複数種類の薬品｝が得られたと仮定する。ただし、事故の事例情報（２）および（３）において、事故詳細の情報は、｛薬品，処置，事故の内容｝＝｛ノボリン３０Ｒ（１００），注射，過剰投与｝と仮定する。
【０１０６】
たとえば、事故の事例情報（１）と事故の事例情報（２）とを学習処理によってまとめる（統合する）と、新しい事故の事例情報として、｛理由，事故詳細，職歴，部署経験，時間，場所，背景｝＝｛注射，事故詳細，短期（３年未満），短期（１年以内），♯，病室，異動直後，複数種類の薬品｝を得ることができる。ただし、事故詳細の情報は、｛薬品，処置，事故の内容｝＝｛ノボリン３０Ｒ（１００），注射，過剰投与｝である。
【０１０７】
また、事故の事例情報（１）と事故の事例情報（３）とを学習処理によってまとめると（事故の事例情報（１）−（３）をまとめる場合も同様）、新しい事故の事例として、｛理由，事故詳細，職歴，部署経験，時間，場所，背景｝＝｛注射，事故，♯，♯，♯，病室，複数種類の薬品｝を得ることができる。ただし、事故詳細の情報は、｛薬品，処置，事故の内容｝＝｛ノボリン３０Ｒ（１００），注射，過剰投与｝である。
【０１０８】
ここで、複数の事故の事例情報から１つの新しい事故の事例情報を作成する方法（学習方法）について説明することにする。まず、複数の事故の事例情報のうち、事故詳細の情報に含まれる「事故の内容」が同じものをグループ化する。次に、理由の情報と事故詳細の情報のうちの「事故の内容」とが入力された或る列を作成する。ここで作成される或る列は、理由の情報および事故詳細の情報のうちの「事故の内容」以外の事故（「事故の内容」を除く。），職歴，部署経験，時間，場所，背景の各情報が空欄にされた配列である。このとき、類義語辞書を参照することにより、理由の情報については、可能であれば総括名称にまとめられる。上述の例では、“インシュリン注射”と“ノボリン注射”との総括名称である“注射”が或る列の理由の情報として格納される。なお、「事故の内容」が同じものをグループ化しているため、或る列においても「事故の内容」として“過剰投与”が格納される。
【０１０９】
続いて、グループ化された複数の事故の事例情報の中で、事故詳細の情報に含まれる「処置」の内容が同じものまたは類似するものが存在するかどうかが判断される。ただし、「処置」の内容が類似するか否かは、知識ＤＢ３０内の類義語辞書を参照して判断される。「処置」の内容が少なくとも類似する場合には、それらの事故詳細の情報に含まれる「薬品」または「器具」を或る列に格納するとともに、その「処置」を或る列に格納する。ただし、「薬品」，「器具」，「処置」の内容が同じである場合には、各事故の事例情報をまとめるべく、「薬品」，「器具」，「処置」の内容を或る列にそのまま格納し、「薬品」，「器具」，「処置」の内容が類似する場合には、各事故の事例情報をまとめるべく、それぞれの「薬品」，「器具」，「処置」の内容をリストにして或る列に格納する。
【０１１０】
ただし、「処置」の内容が非類似である場合には、事故詳細の情報に含まれる「薬品，器具」が同一のものまたは類似するものが有るかどうかが判断される。「薬品，器具」の内容が類似するか否かもまた、類義語辞書を参照して判断される。「薬品，器具」の内容が少なくとも類似する場合には、それらの事故詳細の情報に含まれる「処置」を或る列に格納するとともに、その「薬品，器具」を或る列に格納する。「薬品」，「器具」，「処置」を或る列に格納する方法は上記のとおりであるが、ここでは、前提として、「処置」が非類似であるため、各事故の事例情報についての「処置」の内容がリストにされて或る列に格納される。
【０１１１】
このようにして、事故詳細の情報が、グループ化された複数の事故の事例情報について統合されるのである。
【０１１２】
さらに、この実施例では、類義語辞書を参照して、類似する「処置」，「薬品」，「器具」が追加される。類似する他の「処置」を行う場合や類似する他の「薬品・器具」を使用する場合にも同様の事故が発生する可能性があると考えられるからである。したがって、たとえば、上述の事例情報には、（シグマート ２ｍｇ／Ｖ，シグマート ４８ｍｇ／Ｖ）や（ミスリロール ５ｍｇ／１０ｍＬ／Ａ，ミスリロール ２５ｍｇ／５０ｍＬ／Ａ）などの薬品が、事故詳細の情報における薬品のリストに追加される。したがって、或る列では「薬品」のリストとして、｛ノボリン，シグマート，ミスリロール…｝が記述される。
【０１１３】
次に、グループ化された複数の事故の事例情報の中で、理由の情報および事故詳細の情報以外の情報、すなわち職歴、部署経験、時間、場所、背景の各情報のうち、同じ内容のものがあるかどうかが判断される。
【０１１４】
同じ内容のものがあれば、同じ内容のものについては、それらの事故の事例情報をまとめるべく、そのままの内容を或る列に格納する。そして、同じ内容で無いものについては、それらを含むようにまとめた内容を或る列に格納する。たとえば、グループ化されたすべての事故の事例情報において、場所の情報が「レントゲン室」を示す場合には、或る列の場所の情報についても「レントゲン室」が記述される。また、たとえば、グループ化された３つの事故の事例情報において、職歴が、それぞれ、１年，半年，１０か月である場合には、或る列の職歴については「１年未満」または「短期」などが記述される。他の情報についても同様である。
【０１１５】
この実施例では、職歴の情報については、３年未満（短期）、３年以上１０年未満、１０年以上（ベテラン）のような３つの区分でまとめる（分類する）ようにしてある。ただし、２区分以上をまとめる場合には、職歴は事故の要因とは関係ないとして、或る列の職歴の情報として「♯」が記述される。また、部署経験の情報については、１年未満（短期）、１年以上５年未満、５年以上（ベテラン）のような３つの区分でまとめるようにしてある。ただし、２区分以上をまとめる場合には、部署経験は事故の要因とは関係ないとして、或る列の部署経験の情報として「♯」が記述される。
【０１１６】
なお、これらの年月の数値は例示であり、実際には、この警告システム１０が適用される病院等において実験するなどして経験的に得られた数値を設定すればよい。
【０１１７】
また、たとえば、時間の情報については、早朝（４時−８時）、午前（８時−１２時）、午後（１２時−１６時）、夕方（１６時−２０時）、夜間（２０時−４時）のような５つの区分でまとめるようにしてある。ただし、３区分以上をまとめる場合や隣接しない２区分をまとめる場合には、時間（帯）は事故の要因とは関係ないとして、或る列の時間の情報として「♯」が記述される。
【０１１８】
さらに、たとえば、場所の情報については、病室、トイレ、浴室、洗濯室、廊下、階段室、診察室、手術室、レントゲン室などの具体的な場所が一義的に決定されるため、これらのうちの２つないし３つを１つにまとめるようなことは困難である。したがって、グループ化された事例情報の場所の情報が異なる場合には、場所は事故の要因とは関係ないとして、或る列の場所の情報として「♯」が記述される。
【０１１９】
さらにまた、たとえば、背景の情報としては、上述したように、同じ名前の患者が存在すること、ナースコールで呼び出されたこと、忙しかったこと、複数種類の薬品が存在することなどの具体的な内容で決定されるため、これらのうちの２つないし３つを１つにまとめるようなことはできない。したがって、グループ化された事例情報の場所の情報が異なる場合には、背景の内容は事故の要因とは関係ないとして、或る列の背景の情報として「♯」が記述される。
【０１２０】
なお、これらは単なる例示であり、区分の仕方やまとめ方は適宜変更可能であり、警告システム１０が設置（適用）される病院や病棟毎に設定することも可能である。
【０１２１】
このように、同じ事故の内容の事例情報では、理由の情報は、可能であれば総括名称でまとめられ、職歴、部署経験、時間、場所および背景の各情報については、同様の内容についてはまとめるようにし、事故詳細の情報に含まれる薬品・器具や処置については、同じ内容でない場合には、リストとしてそれぞれを記述することにより、或る程度の幅を持たせるようにしてある。このようにして、或る列の空欄を埋めることにより、新しい事故の事例情報が作成される。そして、作成された新しい事故の事例情報が知識ＤＢ３０に登録（追加）される。
【０１２２】
具体的には、サーバ１２は、図１２ないし図１４に示すフロー図に従って事例構築処理を実行する。なお、事例構築処理は、たとえば、事故の事例情報が所定個数（たとえば、３０個）以上仮ＤＢ３６に記憶された場合や一定期間（たとえば、３０日）が経過した場合に、実行される。ただし、サーバ１２の管理者等が必要に応じてこの事例構築処理を実行させるようにしてもよい。また、事例構築処理は、上述した全体処理（図８および図９）と並列的に実行される。
【０１２３】
図１２に示すように、サーバ１２は、事例構築処理を開始すると、ステップＳ８１で、変数Ｃｏｕｎｔを初期化する（Ｃｏｕｎｔ＝０）。この変数Ｃｏｕｎｔは、事故の事例についてのグループの数をカウントするためのカウンタである。続くステップＳ８３では、仮ＤＢ３６からデータを読み込む。つまり、サーバ１２は、仮ＤＢ３６に記憶された事故の事例情報についてのデータをすべて読み出し、図示しないＲＡＭのような内部メモリに記憶（ロード）する。次のステップＳ８５では、変数ｉを初期化する（ｉ＝１）。この変数ｉは、ロードされた事故の事例情報についての事例データを識別可能にカウントするための変数である。
【０１２４】
続いて、ステップＳ８７では、抜き出した（選択した）１つのデータを基準として、ｉ番目のデータと比較する。つまり、読み込んだ事故の事例情報のうちの１つを基準の事例情報とし、他の事故の事例情報と順次比較するのである。次のステップＳ８９では、基準の事例情報とｉ番目の事例情報とが同じ事故のものであるかどうかを判断する。つまり、比較する２つの事例情報が示す事故詳細の情報のうち、「事故の内容」が同じであるかどうかを判断するのである。ステップＳ８９で“ＮＯ”であれば、つまり異なる事故のものであれば、そのままステップＳ９５に進む。
【０１２５】
しかし、ステップＳ８９で“ＹＥＳ”であれば、つまり同じ事故のものであれば、ステップＳ９１で、基準の事例情報とｉ番目の事例情報とをグループにまとめる。たとえば、基準の事例情報の識別情報（事故ラベル）とｉ番目の事例情報の事故ラベルとがグループ化される。そして、ステップＳ９３で、変数Ｃｏｕｎｔをインクリメントして（Ｃｏｕｎｔ＝Ｃｏｕｎｔ＋１）、ステップＳ９５に進む。
【０１２６】
ステップＳ９５では、すべてのデータと比較したかどうかを判断する。つまり、変数ｉが仮ＤＢ３６から読み込んだ事故の事例情報のデータの総数以上であるかどうかを判断する。ステップＳ９５で“ＮＯ”であれば、つまり比較していないデータが有れば、次の（ｉ＋１番目の）データと比較するべく、ステップＳ９７で、変数ｉをインクリメントして（ｉ＝ｉ＋１）、ステップＳ８７に戻る。一方、ステップＳ９５で“ＹＥＳ”であれば、つまりすべてのデータと比較すれば、ステップＳ９９で、変数Ｃｏｕｎｔが０よりも大きいかどうかを判断する。つまり、この事例構築処理では、同じ或いは類似する事例情報をまとめるようにしてあるため、少なくとも２つの事例情報をグループにまとめたかどうかを判断しているのである。
【０１２７】
ステップＳ９９で“ＮＯ”であれば、つまり変数Ｃｏｕｎｔが０であれば、グループ化された事例情報が無いと判断して、そのまま事例構築処理を終了する。一方、ステップＳ９９で“ＹＥＳ”であれば、つまり変数Ｃｏｕｎｔが１以上であれば、グループ化された事例情報が有ると判断して、図１３に示すステップＳ１０１で、理由の情報および事故詳細の情報のうちの事故の内容のみを入力した或る列をグループＤＢ３８に作成する。
【０１２８】
続くステップＳ１０３では、グループの中で、処置が少なくとも類似するものがあるかどうかを判断する。なお、類似するか否かは、知識ＤＢ３０に記憶された類義語辞書を参照して判断される。以下、同様である。ステップＳ１０３で“ＹＥＳ”であれば、つまりグループの中で、処置が少なくとも類似するものが有る場合には、ステップＳ１０５で、薬品または器具を或る列に格納し、ステップＳ１０７で、処置を或る列に格納して、ステップＳ１１５に進む。ただし、ステップＳ１０５では、グループ化された事例情報に記述された薬品または器具が同じ場合には、そのまま当該薬品または器具を或る列に格納する。また、ステップＳ１０５では、グループ化された事例情報に記述された薬品または器具が類似する（異なる）場合には、それぞれの事例情報に記述された薬品または器具をリストにして或る列に格納する。同様に、ステップＳ１０７では、グループ化された事例情報に記述された処置が同じ場合には、そのまま当該処置を或る列に格納する。また、ステップＳ１０７では、グループ化された事例情報に記述された処置が類似する（異なる）場合には、それぞれの事例情報に記述された処置をリストにして或る列に格納する。
【０１２９】
また、ステップＳ１０３で“ＮＯ”であれば、つまりグループの中で、処置が非類似であれば、ステップＳ１０９で、グループの中で、薬品または器具すなわち使用する物が少なくとも類似するものがあるかどうかを判断する。ステップＳ１０９で“ＮＯ”であれば、つまりグループの中で、薬品または器具が非類似であれば、新しい事例情報として追加するのは不適切であると判断して、図１４に示すように、そのまま事例構築処理を終了する。
【０１３０】
しかし、ステップＳ１０９で“ＹＥＳ”であれば、つまりグループの中で、薬品または器具が少なくとも類似するものが有る場合には、ステップＳ１１１で、処置を或る列にリストとして格納し、ステップＳ１１３で、薬品または器具を或る列に格納して、ステップＳ１１５に進む。ただし、グループ化された事例情報の処置はステップＳ１０３で“ＮＯ”と判断されているため、非類似の処置である。したがって、ステップＳ１１１では、グループ化された事例情報のそれぞれに記述された処置をリストにして或る列に格納する。ただし、ステップＳ１１３では、グループ化された事例情報に記述された薬品または器具が同じ場合には、そのまま当該薬品または器具を或る列に格納する。また、ステップＳ１１３では、グループ化された事例情報に記述された薬品または器具が類似する（異なる）場合には、それぞれの事例情報に記述された薬品または器具をリストにして或る列に格納する。
【０１３１】
ステップＳ１１５では、処置、薬品または器具のそれぞれについて、似たものをリストに追加する。ここでは、類義語辞書を参照して、類似する処置や薬品，器具をリストに追加して、より多くの事例に当てはまる事例情報を作成するのである。そして、図１４に示すステップＳ１１７では、グループの中で、理由および事故以外の情報、つまり職歴、部署経験、時間、場所および背景の各情報で同じものがあるかどうかを判断する。
【０１３２】
ステップＳ１１７で“ＹＥＳ”であれば、つまりグループの中で、理由および事故以外の情報で同じものが有る場合には、職歴、部署経験、時間、場所および背景の各情報について同じものはそのまま或る列に格納し、異なるものはそれらを含むようにまとめて或る列に格納して、ステップＳ１２３に進む。一方、ステップＳ１１７で“ＮＯ”であれば、つまりグループの中で、理由および事故以外の情報で同じものが無い場合には、職歴、部署経験、時間、場所よび背景の各情報について、異なるものを含むようにまとめて或る列に格納して、ステップＳ１２３に進む。ステップＳ１２３では、或る列すなわち新しい事故の事例情報についての事例データを知識ＤＢ３０に登録（追加）して、知識構築処理を終了する。
【０１３３】
なお、この実施例では、新しく作成された事故の事例情報をそのまま知識ＤＢ３０に追加するようにしたが、同じ事例情報が知識ＤＢ３０に既に登録されている場合には、追加しないようにしてもよい。また、類似する事例情報が知識ＤＢ３０に既に登録されている場合には、当該類似する事例情報と新しい事例情報とをまとめることにより、既に登録されている事例情報を再構築するようにしてもよい。ただし、まとめ方は、グループ化された複数の事例情報をまとめる方法（ステップＳ１０１−ステップＳ１２１）と同様である。
【０１３４】
また、図１２−図１４に示す事例構築処理では、１つのグループについてのみ説明したが、１つのグループについての事例構築処理を終了した後に、残りの事故の事例情報について再度事例構築処理を実行し、これを繰り返し、グループが作成できなくなった時点で、事例構築処理を終了するようにしてもよい。
【０１３５】
この実施例によれば、複数の事故の事例情報のうち、同じまたは類似するものを１つにまとめた新しい事故の事例情報を作成して知識ＤＢに登録するので、同様の事故の事例情報が重複して作成されることがない。つまり、最適な事故の事例情報を構築することができる。したがって、最適な事故の事例情報に基づいて参照するシナリオを絞り込むことができ、警告を発するか否かの判断処理が大幅に軽減される。
【０１３６】
なお、この実施例では、看護師についての行動を監視し、看護師の行動に起因する事故を防止するようにしたが、医師や清掃員など、病院（病棟）内で勤務する他の人員の行動に起因する事故を防止するようにしてもよい。かかる場合には、医師や清掃員などに、端末１６、中継器２０、ピンマイク９６、非接触センサ９８、加速度センサ１００および送信機１１０などを装着（所持）させる必要がある。また、看護師、医師および清掃員など、病院（病棟）内で勤務するすべての人員に起因する事故を防止するようにしてもよい。かかる場合には、事故の事例としては、すべての人員について記憶され、また、事故の事例に含まれる属性情報として、職務（医師、看護師、清掃員など）の区別も記述される。
【０１３７】
また、この実施例では、予め事故の事例についての事例データが知識ＤＢに登録されていることを前提として説明したが、知識ＤＢに予め事例データを登録しておく必要性はなく、初めから（１から）事例データを構築することもできる。
【０１３８】
さらに、この実施例では、看護業務についての事故の事例を構築する場合について説明したが、他の業務についての事故の事例を構築するようにしてもよい。たとえば、劇薬を扱うような試験（実験）施設ないし工場における業務や自動車などの組み立て作業を行う工場における業務の事故の事例を構築することができる。
【図面の簡単な説明】
【０１３９】
【図１】図１はこの発明の事例構築装置としてのサーバを含む警告システムの構成の一例を示す図解図である。
【図２】図２は図１に示すサーバの電気的な構成を示す図解図である。
【図３】図３は図１に示す看護師用端末の電気的な構成を示す図解図である。
【図４】図４は図１に示す通過センサの設置状況を説明するための図解図である。
【図５】図５は看護師用端末、中継器および送信機を看護師に装着した状態を示す図解図である。
【図６】図６は図１に示す通過センサの電気的な構成を示す図解図である。
【図７】図７は図１に示す中継器の電気的な構成を示す図解図である。
【図８】図８は図１に示すサーバの全体処理の一部を示すフロー図である。
【図９】図９は図１に示すサーバの全体処理の他の一部であって、図８に後続するフロー図である。
【図１０】図１０は図１に示すサーバの各サブ目標達成確認および警告処理の一部を示すフロー図である。
【図１１】図１１は図１に示すサーバの各サブ目標達成確認および警告処理の他の一部であって、図１０に後続するフロー図である。
【図１２】図１２は図１に示すサーバの事例構築処理の一部を示すフロー図である。
【図１３】図１３は図１に示すサーバの事例構築処理の他の一部であって、図１２に後続するフロー図である。
【図１４】図１４は図１に示すサーバの事例構築処理のその他の一部であって、図１３に後続するフロー図である。
【符号の説明】
【０１４０】
１０ …警告システム
１２ …サーバ
１６ …看護師用端末
１８ …通過センサ
２０ …中継器
２２ …モニタ装置
２４，２６，２８，３０，３２，３４，３６，３８ …データベース
４０，７０，９０ …ＣＰＵ
４２，９２ …メモリ
４４ …キースイッチ
４８ …ＬＣＤ
５２ …振動モータ
５４，７８，１０２ …無線ＬＡＮ
７２，７４ …受光モジュール
７６ …ＲＡＭ
９６ …ピンマイク
９８ …非接触センサ
１００ …加速度センサ
１１０ …送信機
【技術分野】
【０００１】
この発明は事例構築装置およびその事例構築方法に関し、特にたとえば、或る業務についての事故の事例についての事例データを知識としてデータベースに構築する、事例構築装置およびその事例構築方法に関する。
【背景技術】
【０００２】
この種の事例構築装置の一例が特許文献１に開示される。この特許文献１の警告システムによれば、看護師が看護業務を行うとき、当該看護業務に対応するシナリオに従って実際の業務が実行されているか否かを判断する。具体的には、看護師の実際の業務と、看護業務に対応するシナリオとから看護業務の目標を得られるかどうかを判断する。そして、看護業務の目標を得られないことが判断されたときに、シナリオ違反のアラームを看護師に与える。
【特許文献１】特開２００７−３４７３８号公報[G08B 21/02, G06Q 50/00, G06N 5/04, A61G 12/00]
【発明の開示】
【発明が解決しようとする課題】
【０００３】
この背景技術では、必要なときにのみ看護師にアラームを与えるようにしてあるが、シナリオ違反かどうかの判断処理を実行する場合に、データベースに記憶されているすべてのシナリオを検索するようにしてあるため、処理が膨大となり、判断処理に時間がかかってしまう恐れがあった。
【０００４】
それゆえに、この発明の主たる目的は、新規な、事例構築装置およびその事例構築方法を提供することである。
【０００５】
また、この発明の他の目的は、シナリオ違反の判断処理を軽減するためのデータベースを構築できる、事例構築装置およびその事例構築方法を提供することである。
【課題を解決するための手段】
【０００６】
本発明は、上記の課題を解決するために、以下の構成を採用した。なお、括弧内の参照符号および補足説明等は、本発明の理解を助けるために後述する実施の形態との対応関係を示したものであって、本発明を何ら限定するものではない。
【０００７】
第１の発明は、或る業務についての事故の事例についての事例データを記録し、当該事例データを知識としてデータベースに構築する事例構築装置であって、事故の内容と事故が発生したときの処置の内容と事故が発生したときに使用していた物の名称とを含む事故情報を少なくとも含む事例情報を記憶する事例情報記憶手段、事例情報記憶手段に記憶された複数の事例情報のうち、事故の内容が一致する事例情報をグループ化するグループ化手段、グループ化手段によってグループ化された複数の事例情報の中で、事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在するか否かを判断する事故情報判断手段、事故情報判断手段によって事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、グループ化した事例情報を１つにまとめて新規の事例情報を作成する新規事例作成手段、および新規事例作成手段によって作成された新規の事例情報をデータベースに登録する登録手段を備える、事例構築装置である。
【０００８】
第１の発明では、事例構築装置（１２）は、或る業務（たとえば、看護業務）についての事故の事例についての事例データをデータベース（３０）に構築する。事例情報記憶手段（１２，３６）は、事故の内容と事故が発生したときの処置（行動）の内容と事故が発生したときに使用していた物（薬品・器具）の名称とを含む事故情報を少なくとも含む事例情報を記憶する。たとえば、日々発生する事故の事例情報が蓄積されているのである。グループ化手段（１２，Ｓ９１）は、事例情報記憶手段に記憶された複数の事例情報のうち、事故の内容が一致する事例情報をグループ化する。事故情報判断手段（１２，Ｓ１０３，Ｓ１０９）は、
グループ化手段によってグループ化された複数の事例情報の中で、事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在するか否かを判断する。新規事例作成手段（１２，Ｓ１０５，Ｓ１０７，Ｓ１１１，Ｓ１１３，Ｓ１１５，Ｓ１１７，Ｓ１１９，Ｓ１２１）は、事故情報判断手段によって事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、グループ化した事例情報を１つにまとめて新規の事例情報を作成する。つまり、同じまたは類似する処置を行っていたときに発生した事故や同じまたは類似する物を使用ないし所持していたときに発生した事故についての事例情報がまとめられる（統合される）。登録手段（１２，Ｓ１２３）は、新規事例作成手段によって作成された新規の事例情報をデータベースに登録する。
【０００９】
第１の発明によれば、同じ事故の内容について、同じまたは類似する処置の内容や物の名称をまとめることにより１つの事故の事例情報を作成するので、同様の事故の事例情報が重複してデータベースに登録されるのを回避することができる。つまり、最適な事故の事例情報を構築することができる。
【００１０】
第２の発明は第１の発明に従属し、新規事例作成手段は、事故情報判断手段によって事故が発生したときの処置の内容が少なくとも類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときに使用していた物の名称のそれぞれを含むように、グループ化した事例情報を１つにまとめて新規の事例情報を作成する。
【００１１】
第２の発明では、新規事例作成手段は、事故情報判断手段によって事故が発生したときの処置の内容が少なくとも類似する、つまり同一のまたは類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときに使用していた物の名称のそれぞれを含むように、たとえば、リストにして記述することにより、グループ化した事例情報を１つにまとめて新規の事例情報を作成する。ただし、同一の事例情報については、そのまま物の名称を記述した新規の事例情報が作成される。
【００１２】
第２の発明によれば、類似する物については、それぞれを含むようにリストにするので、同様の事例情報が重複して作成されるのを回避することができる。
【００１３】
第３の発明は第１の発明に従属し、新規事例作成手段は、事故情報判断手段によって事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときの処置の内容のそれぞれを含むように、グループ化した事例情報を１つにまとめて新規の事例情報を作成する。
【００１４】
第３の発明では、新規事例作成手段は、事故情報判断手段によって事故が発生したときに使用していた物の名称が少なくとも類似する、すなわち同一のまたは類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときの処置の内容のそれぞれを含むように、グループ化した事例情報を１つにまとめて新規の事例情報を作成する。ただし、同一の事例情報については、そのまま処置の内容を記述した新規の事例情報が作成される。
【００１５】
第３の発明においても、第２の発明と同様に、同様の事例情報が重複して作成されるのを回避することができる。
【００１６】
第４の発明は第１ないし第３の発明に従属し、新規事例作成手段は、事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称に類似する内容を追加する追加手段を含む。
【００１７】
第４の発明では、追加手段（１２，Ｓ１１５）は、事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称に類似する内容を追加する。つまり、実際に発生した事故の事例のみならず、それに類似する内容（類型）が追加される。
【００１８】
第４の発明によれば、実際に発生した事故の事例のみならず、その類型を含む新しい事故の事例情報が作成されるので、より最適な事故の事例情報を構築することができる。
【００１９】
第５の発明は、或る業務についての事故の事例についての事例データを記録し、当該事例データを知識としてデータベースに構築する事例構築装置の事例構築方法であって、（ａ）事故の内容と事故が発生したときの処置の内容と事故が発生したときに使用していた物の名称とを含む事故情報を少なくとも含む事例情報を記憶し、（ｂ）ステップ（ａ）によって記憶された複数の事例情報のうち、事故の内容が一致する事例情報をグループ化し、（ｃ）ステップ（ｂ）によってグループ化された複数の事例情報の中で、事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在するか否かを判断し、（ｄ）ステップ（ｃ）によって事故が発生したときの処置の内容または事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、グループ化した事例情報を１つにまとめて新規の事例情報を作成し、そして（ｅ）ステップ（ｄ）によって作成された新規の事例情報をデータベースに登録する、事例構築方法である。
【００２０】
第５の発明においても、第１の発明と同様に、最適な事故の事例情報を構築することができる。
【発明の効果】
【００２１】
この発明によれば、同じ事故の内容について、同じまたは類似する処置の内容や物の名称をまとめることにより１つの事故の事例情報を作成するので、同様の事故の事例情報が重複してデータベースに登録されるのを回避することができる。つまり、最適な事故の事例情報を構築することができる。
【００２２】
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【発明を実施するための最良の形態】
【００２３】
図１を参照して、この発明の一実施例である警告システム１０は、たとえば病院に適用され、少なくとも、警告装置および事故の事例を構築する事例構築装置として機能するサーバ１２を含む。このサーバ１２は、有線或いは無線による通信回線（ネットワーク）１４を介して複数の看護師用端末（以下、単に「端末」という。）１６、複数の通過センサ１８および複数の中継器２０に接続される。端末１６は、ＰＤＡやＰＨＳのような携帯型の端末であり、看護師毎に割り当てられる。通過センサ１８は、赤外線を受光する受光装置であり、入院患者を収容する病棟内の廊下や診察室、手術室、トイレ、階段室、病室および看護師詰所などの各部屋の出入り口などに配置される。中継器２０は、ＰＤＡや携帯型のコンピュータのような携帯型の装置であり、看護師毎に割り当てられる。
【００２４】
図２はサーバ１２の具体的な構成を示すブロック図であり、サーバ１２には、図１では省略したが、モニタ装置２２が接続される。モニタ装置２２は、たとえば、複数の対物センサ、複数の集音マイク（音センサ）および複数のビデオカメラ（イメージセンサ）などのセンサを含む。図示は省略するが、この実施例では、複数の対物センサは、体温計、血圧計、注射器、点滴注射器（注入器）、血液採取用試験管、検尿コップなどの器具（医療機器など）を格納してある格納箱（格納庫）の取り出し部分（出入り口）、格納箱（格納庫）の鍵やナースコール端末などに設置され、それらの器具等についての使用（取り出し）の有無を検知する。ただし、これらの器具等に、電子タグ情報（ＲＦ−ＩＤ）やバーコードのような識別情報を付加しておき、タグ情報やバーコードを読み取ることにより、その使用の有無を検出するようにしてもよい。
【００２５】
複数の集音マイクは、入院患者を収容する病棟内の廊下および病室（ベッド或いはその近傍）などに設置され、周囲音を集音する。さらに、複数のビデオカメラは、集音マイクと同様に、入院患者を収容する病棟内の廊下および病室（ベッド或いはその近傍）などに設置されるとともに、看護師詰所などにも設置され、主として、看護業務を行う看護師（の行動）を撮影する。ここで、看護業務とは、問診、検温、検圧、注射、投薬、点滴注射、退院指導などの看護師が行うべき業務の総称である。ただし、この実施例では、単に「看護業務」という場合には、任意の１つの業務を示す。
【００２６】
また、図２に示すように、サーバ１２には、８つのデータベース（ＤＢ）が接続される。具体的には、属性ＤＢ２４、電子カルテＤＢ２６、シナリオＤＢ２８、知識ＤＢ３０、行動履歴ＤＢ３２、病棟イベントＤＢ３４、仮ＤＢ３６およびグループＤＢ３８がサーバ１２に接続される。
【００２７】
属性ＤＢ２４は、この警告システム１０が適用される病棟（病院）内で働く者（この実施例では、看護師）についての属性情報を記憶する。この実施例では、属性情報とは、看護師としての職歴（経験年数（たとえば、月日））および当該病院（病棟）や現在の部署での経験（継続年数（たとえば、月日））を意味する。
【００２８】
電子カルテＤＢ２６には、現在入院中或いは治療中の患者についての電子カルテが記録される。図示は省略するが、この電子カルテは、医師等が記載するカルテの内容から必要な事項を抽出するとともに、必要な事項を追加して、電子データにしたものである。たとえば、電子カルテには、患者名、担当看護師名（または、識別情報（看護師ＩＤ））、性別、病名、病状、処方（どのような注射や点滴、或いは投薬をするかという処方および処方する時間）、リハビリの状況、入院暦、患者に対する注意事項などの情報の電子データ（テキストデータ）が記述される。
【００２９】
シナリオＤＢ２８には、看護業務の正しい行動手順（シナリオ）が記述される。ただし、看護業務の実行の際に使用する器具についての情報やその使用方法についての情報も含まれる。ここで、シナリオｓｉは、看護師の業務マニュアルを参照して作成された、看護業務における行動ないし動作（イベント）の集合であり、基本的な手順（時系列）に従って並べられる。ただし、後述するように、シナリオＤＢ２８に登録されたシナリオｓｉと一致しない行動列が発見された場合には、新しいシナリオｓｉとして追加される。たとえば、シナリオｓｉは数１で示される。ただし、数１において、「ｉｎ ｃｈｒｏｎｏｌｏｇｉｃａｌ ｏｒｄｅｒ」としてあるのは、すべてのイベントｅｉを必ずしも手順（時系列）に従って実行する必要はないが、一部に時系列に従って実行する必要があるイベントｅｉを含んでいることを意味する。
【００３０】
［数１］
【００３１】
たとえば、シナリオｓｉ，ｓｈ，ｓａは、それぞれ、複数のイベントによって構成され、数２で示される。
【００３２】
［数２］
ｓｉ＝｛ｅｉ１＝注射器を準備する，ｅｉ２＝蒸留水とダイアモックス（Ｄｉａｍｏｘ）とを準備する，ｅｉ３＝ダイアモックスを溶かす，ｅｉ４＝ダイアモックスを溶かしたものを吸引する，ｅｉ５＝待つ，ｅｉ６＝注射をする｝
ｓｈ＝｛ｅｈ１＝各種モニタの電源の確認，ｅｈ２＝点滴のセット，ｅｈ３＝必要物品の準備，ｅｈ４＝吸引をセット，ｅｈ５＝腰・硬麻の準備，ｅｈ６＝ライト・ヘッドの位置を確認｝
ｓａ＝｛ｅａ１＝病棟看護師より申し送りを受ける，ｅａ２＝コスト表にＩＤカードを押す，ｅａ３＝麻酔医に患者の血圧等を報告，ｅａ４＝胸写をシャーカステンにかける，ｅａ５＝モニタ類の装着，ｅａ６＝血管確保の介助，ｅａ７＝腰・硬麻の介助，ｅａ８＝麻酔導入の介助，ｅａ９＝導尿・深部体温モニタの装着，ｅａ１０＝電気メスの対極板の貼付，ｅａ１１＝体位をとる，ｅａ１２＝Ｌ枠、メーヨ台、ライトの設置、ｅａ１３＝ガウンテクニックの介助，ｅａ１４＝イソジン、生食を器機台に出す、ｅａ１５＝電気メス、吸引のコード接続｝
ただし、シナリオｓｉ（他のシナリオｓｈ，ｓａも同様。）は、数３に示すように、複数のシナリオｓｉｎ（以下、説明の都合上、「部分シナリオ」ということがある。）の集合で表わすことができる。詳細な説明は省略するが、各部分シナリオｓｉｊは、２以上のイベント（ｅ）の集合（イベント群）で表わされる。また、数３において、Ｏｉはシナリオｓｉを実行した場合における最終的な目標であり、Ｏｉｊは部分シナリオｓｉｊを実行した場合における下位の（補助的な）目標である。ただし、最終的な目標（最終目標）は、看護師がシナリオｓｉに従って看護業務を実行することにより得られる。つまり、最終目標は、看護行為による正しい結果である。また、下位の目標（下位目標）は、部分シナリオｓｉｊに従って看護業務の一部を実行することにより得られる。
【００３３】
［数３］
ｓｉ＝｛ｓｉ１，ｓｉ２，…，ｓｉｎ；Ｏｉ｝
ｓｉｊ＝｛ｅｊ１，ｅｊ２，…，ｅｊｋ；Ｏｉｊ｝
ただし、たとえば、或る部分シナリオｓｉｌ（ｃ）＝｛ｅｌ１，ｅｌ２，…，ｅｌｍ；Ｏｉｌ｝は時系列に従って実行する必要があるが、他の部分シナリオｓｉｐ（ｎ）＝｛ｅｐ１，ｅｐ２，…，ｅｐｑ；Ｏｉｐ｝は時系列に従って実行する必要はない。たとえば、数２に示した例では、イベントｅｉ４（ダイアモックスを溶かしたもの吸引する）は、イベントｅｉ６（注射する）の前に実行されている必要がある。
【００３４】
なお、図示は省略するが、時系列に従って実行する必要のある部分シナリオであるか否かの情報は、各部分シナリオにラベルを付して識別可能としてある。ただし、部分シナリオであるか否かの情報は、各部分シナリオに対応づけて別途記憶しておいてもよい。
【００３５】
知識ＤＢ３０には、公理および仮説についてのデータが記憶される。この実施例では、公理とは、該当の患者に対する処方または処置の理想状態が必然的に得られる事象、行為、または要素などとその理想状態の因果律、さらにもっと一般的に言えば、どのような場合でも関係が崩れることがない、そのような関係（一般的事実）のことである。また、仮説とは、モニタ手段（この実施例では、通過センサ１８、中継器２０、モニタ装置２２）やＲＦＩＤ（タグ情報）などで観測可能な事象、行為、要素など、可変なもの、同時に成り立たない可能性があるもの（イベント）をいう。また、知識ＤＢ３０には、看護業務に関する知識も記憶される。具体的には、看護業務毎に、看護業務を行うときの両手、胸および腰についての加速度の時間変化（加速度データ）を予め取得して、これを辞書データとして記憶してある。ただし、看護師毎に看護業務を行う手順、癖或いは身体的な特徴（身長，手の長さなど）が異なるため、看護師毎に辞書データを記憶するようにしてもよい。さらに、知識ＤＢ３０には、類義語辞書が記憶される。この類義語辞書は、類似する用語を検索可能な辞書であり、一般的な用語（言葉）のみならず、複数の看護業務の名称（シナリオ名）についての総括名称、類似する薬品や器具の名称についても検索可能である。また、知識ＤＢ３０には、アクシデントやインシデント（事故）についての事例の情報（事例情報）のデータ（事例データ）が識別情報（事故ラベル）を付して識別可能に記憶される。この事例データは、参照するシナリオを特定する（絞り込む）ために用いる。たとえば、看護師が看護業務を行う際に、その状況（行動，現在位置，使用する薬品・器具など）から事例データが特定され、特定された事例データが示す看護業務の名称（シナリオ名）に応じたシナリオが参照するシナリオとして特定される。ただし、後述するように、学習することにより、新しい事故の事例情報の事例データが知識ＤＢ３０に登録（追加）される。
【００３６】
たとえば、事故の事例情報の内容は次の通りである。或るイベント（看護業務）について事故が発生した場合に、当該事故の識別情報（事故ラベル）に対応して、理由、事故、属性情報（職歴、部署経験）、時間、場所および背景の各情報が記録される。ただし、背景の情報は省略してもよい。これらの情報は、たとえば、テキストで記述される。
【００３７】
なお、看護師のみならず、医師や清掃員のように、病院（病棟）内で勤務する者についてのすべての事故の事例について管理する場合には、属性情報として、職務の種類（医師，看護師，清掃員などの別）を記録するようにしてもよい。
【００３８】
理由の情報としては、当該事故の発生した看護業務の名称（シナリオ名）が記憶される。事故詳細の情報としては、薬品名または器具のような看護業務に使用する物の名称、事故が発生したときの処置の内容、事故の詳細についての内容（事故の内容）が記憶される。たとえば、事故が発生したときの処置の内容としては、オーダー、伝達、輸血、点滴注射、注射、投薬などのイベントであり、当該看護業務の名称と一致することもある。また、事故の内容は、過剰投与、混注ミス、薬剤混同、患者取り違えなどである。職歴の情報としては、看護師としての経験年数（たとえば、年月）が記憶される。部署経験の情報としては、当該部署に配属されてからの継続年数（たとえば、年月）が記憶される。時間の情報としては、事故が発生した時刻（時分）ないし時間帯が記憶される。場所の情報としては、事故が発生した場所が、病室、トイレ、浴室、洗濯室、廊下、階段室、診察室、手術室、レントゲン室などのように具体的に記憶される。背景の情報としては、同じ名前の患者が存在すること、ナースコールで呼び出されたこと、忙しかったこと、複数種類の薬品が存在することなどのように、事故の背景に有る様々な事情（状況）が記憶される。
【００３９】
ただし、理由の情報については、後述する行動履歴ＤＢ３２に記憶された加速度データおよび音声データと、知識ＤＢ３０に記憶された辞書データとから特定することができる。また、職歴の情報や部署経験の情報については、属性ＤＢ２４から取得することができる。そして、場所の情報および時間の情報については、後述する病棟イベントＤＢ３４から取得することができる。
【００４０】
行動履歴ＤＢ３２は、看護師の行動履歴のデータ（行動履歴データ）を看護師毎に記憶する。行動履歴データは、中継器２０から送信される加速度データおよび音声データを意味する。ただし、行動履歴データは、看護業務毎に１つのファイルとして記憶される。たとえば、各ファイルには、該当する看護師の看護師ＩＤのラベルが付される。
【００４１】
病棟イベントＤＢ３４は、上述した通過センサ１８から得られるデータと、上述したモニタ装置２２から得られる対物検知データ、音声データおよび映像データと（これらのデータをまとめて「病棟イベントデータ」という。）を記録する。通過センサ１８から得られるデータには、後述するように、当該通過センサ１８の識別情報に、検知した看護師の看護師ＩＤが付加されている。対物検知データには、検知する対象となる医療器具等の名称のような識別情報がタグとして付される。音声データには、集音マイク２４の設置場所を示す識別情報がタグとして付される。映像データには、ビデオカメラ２８の設置場所を示す識別情報がタグとしてとして付される。つまり、対物検知データから検知対象物を特定することができ、音声データや映像データのタグから集音したり映像を取得した場所を特定したりすることができる。
【００４２】
ここで、サーバ１２は、その内部に時計回路１２ａを有している。この時計回路１２ａは、日付および時間を計時する。したがって、サーバ１２は、時計回路１２ａから日付および時間を検出し、上述のような病棟イベントデータを取得したときの時間（時間データ）を、当該病棟イベントデータに付加する。たとえば、サーバ１２は、通過センサ１８からのデータを受信すると、そのデータに時間データを付加して、病棟イベントＤＢ３４に記録する。また、対物検知データの入力があると、サーバ１２は当該対物検知データに時間データを付加して、病棟イベントＤＢ３４に記録する。集音マイクは、たとえば、物が落下したときに生じる音や、人間が発した大声などを集音することを目的とするため、所定のレベル以上の音が入力されたときに、当該音に対応する音データがサーバ１２に入力され、サーバ１２は当該音データに時間データを付加して、病棟イベントＤＢ３４に記録する。したがって、たとえば、患者が転倒したり、ナースコール端末が押されたりしたことが記憶される。ただし、基本的にはタイムラプス(間欠記録)ではあるものの、時系列的に映像データが蓄積される。
【００４３】
仮ＤＢ３６は、事故が発生した場合に、その事故の事例情報を記憶（蓄積）するために用いられる。この仮ＤＢ３６に記憶された事故の事例情報は、予め作成された知識ＤＢ３０に登録されているものとは異なり、事故が発生した場合に、知識ＤＢ３０に登録されている事例情報と同様にして作成されたものである。また、グループＤＢ３８は、新しい事故の事例情報を作成する際の作業領域ないしバッファ領域として用いられる。したがって、グループＤＢ３８に代えて、サーバ１２の内部メモリ（ハードディスクやＲＡＭなど）を用いるようにしてもよい。ただし、図１および図２では、サーバ１２の内部メモリは省略してある。
【００４４】
図３は端末１６の電気的な構成を示すブロック図である。図３を参照して、端末１６はＣＰＵ４０を含み、このＣＰＵ４０には、メモリ４２，キースイッチ４４，ＬＣＤドライバ４６，モータドライバ５０，無線ＬＡＮ５４およびアンプ５６が接続される。また、ＬＣＤドライバ４６にはＬＣＤ４８が接続され、モータドライバ５０には振動モータ５２が接続され、そして、アンプ５６にはスピーカ５８が接続される。
【００４５】
なお、上述したように、端末１６としてＰＨＳを用いる場合には、図３に示すような構成において、さらに通話（電話）機能が備えられる。
【００４６】
ＣＰＵ４０は、端末１６の全体制御を司る。メモリ４２は、ＲＯＭやＲＡＭを含む。この実施例では、端末１６は主として情報提示装置として機能し、ＲＯＭには、情報提示のためのプログラム（情報提示プログラム）や情報提示のために必要なデータ（画像データ，音データ）が記憶されている。ＲＡＭは、ＣＰＵ４０の記憶領域、作業領域およびバッファ領域として用いられる。
【００４７】
なお、この実施例では、情報提示のために必要なプログラムやデータをＲＯＭに記憶するようにしてあるが、サーバ１２からダウンロードするようにしてもよい。このようにすれば、ＲＯＭの使用容量を削減することができる。
【００４８】
キースイッチ４４は、テンキー、十字キーのようなカーソルキーおよび選択キーなどの各種キーないしボタン（スイッチ）であり、看護師の指示入力に用いられる。ＬＣＤドライバ４６はＬＣＤ４８の駆動装置であり、ＣＰＵ４０からの指示に従ってＬＣＤ４８に画像を表示する。図示は省略するが、ＬＣＤ４８には、看護業務に関するメッセージなどの情報を提示するための画面が表示される。モータドライバ５０は、振動モータ５２の駆動装置であり、ＣＰＵ４０からの指示に従って振動モータ５２を駆動する。たとえば、サーバ１２から情報の提示があると、振動モータ５２を駆動することにより、端末１６を振動させて、その旨をユーザに知らせる。または、スピーカ５８から通知音（音声，音楽）を出力して、情報の提示がある旨をユーザに知らせるようにしてもよい。このとき、ＣＰＵ４０からの音データ（音、音声ないし音楽のデータ）は、アナログの音（音声）信号に変換された後、アンプ５６で増幅され、スピーカ５８から出力される。ただし、振動および音（音楽）の両方で通知するようにしてもよい。
【００４９】
無線ＬＡＮ５４は、ＣＰＵ４０の指示に従って、看護師がキースイッチ４４を用いて入力した指示入力（コマンド）を、ネットワーク１４を介してサーバ１２に送信する。詳細な説明は省略するが、サーバ１２では、端末１６の無線ＬＡＮ５４のＭＡＣアドレスを看護師ＩＤに対応づけて管理しているため、通信している端末１６の使用者（看護師）をサーバ１２側で認識することが可能である。ただし、メモリ４２（ＲＯＭ）に看護師ＩＤを記憶しておき、コマンドとともに看護師ＩＤをサーバ１２に送信するようにしてもよい。また、無線ＬＡＮ５４は、サーバ１２から送信された情報（画面表示に関する情報）を受信して、ＣＰＵ４０に与える。
【００５０】
図４に示すように、通過センサ１８は、第１受光モジュール７２および第２受光モジュール７４を含み、第１受光モジュール７２および第２受光モジュール７４は、ゲートの上部であり、互いに異なる側面に装着される。また、ゲートの上に載置されるケース１８０内には、通過センサ１８の受光モジュール（７２，７４）以外のコンポーネント（ＣＰＵ７０，ＲＡＭ７６，無線ＬＡＮ７８：図６参照）が内蔵される。ただし、ゲートは分かり易く示すために図示しただけであり、通常は、看護師詰所、診察室、病室のような部屋の出入り口、廊下と廊下との連結部（十字路、Ｔ字路など）、廊下と階段との連結部のような要所に通過センサ１８は設置される。また、必要であれば、エレベータのゲートに設置されてもよい。
【００５１】
また、図５に示すように、各看護師の頭部には、赤外線信号を発信する送信機１１０が装着される。たとえば、送信機１１０は、クリップのような固定器具を用いて、ナースキャップや頭髪に固定される。送信機１１０が発信する赤外線信号は、たとえば、８ビットの固定のパターン（看護師ＩＤ）である。
【００５２】
図６は通過センサ１８の電気的な構成を示すブロック図である。図６を参照して、通過センサ１８はＣＰＵ７０を含み、ＣＰＵ７０には、第１受光モジュール７２、第２受光モジュール７４、ＲＡＭ７６および無線ＬＡＮ７８が接続される。各通過センサ１８の受光モジュール（７２，７４等）のそれぞれには、固有の識別情報（受光モジュールＩＤ）が割り当てられている。各受光モジュール（７２，７４等）は、送信機１１０（図５参照）からの赤外線信号を検出する。ここで、送信機１１０から送信される赤外線信号は、上述したように、８ビットの固定のパターン（看護師ＩＤ）である。たとえば、受光モジュール（７２，７４）は、看護師ＩＤを受信すると、受信した看護師ＩＤをＣＰＵ７０に与える。ＣＰＵ７０は、看護師ＩＤを受信した受光モジュール（７２，７４）の受光モジュールＩＤを当該看護師ＩＤに付加して、ＲＡＭ７６に記憶（一時記憶）し、その後、無線ＬＡＮ７８およびネットワーク１４を介して、サーバ１２に送信する。
【００５３】
サーバ１２では、受光モジュールＩＤが付加された看護師ＩＤを受信すると、受信した受光モジュールＩＤに対応する場所を看護師ＩＤが示す看護師の現在位置として検出する。
【００５４】
なお、この実施例では、端末１６の処理負担の軽減やメモリ４２の容量節約のために、サーバ１２側で、当該看護師の現在位置を特定するようにしてあるが、通過センサ１８がネットワーク１４を介して受光モジュールＩＤと看護師ＩＤとを端末１６に送信し、当該端末１６が看護師自身の現在位置を特定するようにしてもよい。
【００５５】
図７は中継器２０の電気的な構成を示すブロック図である。図７を参照して、中継器２０はＣＰＵ９０を含む。ＣＰＵ９０には、メモリ９２，エンコーダ９４，非接触センサ９８，加速度センサ１００および無線ＬＡＮ１０２が接続される。メモリ９２は、ワークメモリないしバッファメモリとして働き、ＣＰＵ９０によって使用される。エンコーダ９４にはピンマイク９６が接続され、エンコーダ９４は、ピンマイク９６から入力される音声信号をＭＰ３のような圧縮音声データ（以下、単に「音声データ」という。）に変調してＣＰＵ９０に入力する。このように、音声信号を圧縮変調するのは、メモリ９２の使用量を比較的少なくするためであり、また、後述するように、無線ＬＡＮ１０２を介して送信するデータのデータ量を低減するためである。たとえば、看護師は、ピンマイク９６を通して、開始するまたは終了した看護業務の内容を音声で入力する。したがって、サーバ１２は、音声を解析することにより、看護師が行っている看護業務の内容およびその開始と終了とを知ることができる。
【００５６】
なお、図７では、簡単のため、複数の加速度センサ１００ａ，１００ｂ，１００ｃ，１００ｄを、加速度センサ１００として包括的に示してある（図５参照）。
【００５７】
ここで、図５を参照して分かるように、端末１６，中継器２０および赤外線を発信する送信機１１０は、各作業者（看護師）に装着される。図５に示すように、端末１６は、看護師の手首に装着される。図示は省略するが、端末１６のＬＣＤ４８が見えるように、腕時計を装着するように、バンドのような固定器具を用いて装着される。
【００５８】
また、中継器２０では、ピンマイク９６，非接触センサ９８および加速度センサ１００（１００ａ，１００ｂ，１００ｃ，１００ｄ）以外の回路コンポーネント（図７参照）はボックス２００に収容され、ボックス２００は看護師の腰部（ベルト部分）に装着される。
【００５９】
図５に示すように、ピンマイク９６は、看護師の衣服（白衣）の襟元付近に装着される。また、非接触センサ９８は、ペン型のケースに収容され、看護師の白衣の胸ポケットに挿すように収納される。ただし、図面では、分かり易く示すために、ペン型のケースを胸ポケットの外部に記載してある。
【００６０】
また、看護師の両手（両腕）、胸および腰などには、加速度センサ１００が装着される。この実施例では、加速度センサ１００ａが右腕に装着され、加速度センサ１００ｂが左腕に装着され、加速度センサ１００ｃが胸に装着され、そして、加速度センサ１００ｄが腰に装着される。ただし、図５では、分かり易く示すために、各加速度センサ１００を白衣の外部に記載してあるが、各加速度センサ１００は、実際には、ゴムバンドのような適宜の固定器具を用いて、白衣の内部で腕などに固定される。
【００６１】
なお、図５においては省略するが、非接触センサ９８と加速度センサ１００とは接続線を用いてボックス２００内のＣＰＵ９０に電気的に接続され、ピンマイク９６は接続線を用いてボックス２００内のエンコーダ９４に電気的に接続される。ただし、接続線を用いずに、ブルートゥースのような近距離無線によって接続するようにしてもよい。つまり、電気的に接続されればよいのである。
【００６２】
また、この実施例で用いるピンマイク９６は指向性を有するものである。これは、ピンマイク９６を装着する看護師の音声のみを検出するようにするためであり、さらには、患者のプライバシーを守るためでもある。
【００６３】
非接触センサ９８としては、焦電センサを用いることができ、ＣＰＵ９０は非接触センサ９８からの入力に応じてピンマイク９６をオン／オフする。この実施例では、非接触センサ９８すなわち焦電センサの前で、看護師が手を２回上下させると、その検出信号がＣＰＵ９０に入力され、これに応じて、ＣＰＵ９０はピンマイク９６をオンし、その後、看護師が焦電センサの前で、手を２回上下させると、ピンマイク９６をオフする。ただし、ＣＰＵ９０は、看護師の操作によらないで、所定時間（１０秒）が経過した場合にもピンマイク９６をオフするようにしてある。
【００６４】
加速度センサ１００は、たとえば、多軸（３軸）の加速度センサであり、サンプリング周波数が２００Hzであり、加速度は±３Ｇ（Ｇは重力）まで計測可能である。この中継器２０では、加速度センサ１００で検出される加速度のデータ（加速度データ）がＣＰＵ９０に与えられる。ＣＰＵ９０は、加速度センサ１００からの加速度データをメモリ９２に記憶（一時記憶）し、一定時間（たとえば、１０秒）毎に、その一定時間分の加速度データを、無線ＬＡＮ１０２およびネットワーク１４を介してサーバ１２に送信する。上述したように、知識ＤＢ３０には、予め看護業務を実行した場合の加速度データの時間変化を辞書データとして記憶しているので、中継器２０から送信される加速度データと比較することにより、実行中の看護業務の内容を特定することができる。たとえば、辞書データと中継器２０からの加速度データとを、周知のＤＰマッチングの方法により、比較することにより、看護業務を特定することができる。
【００６５】
なお、加速度センサ１００に代えて、ジャイロセンサ、照度センサまたは温度センサなどの他のセンサを用いることもできる。他のセンサを用いる場合には、その他のセンサの出力がサーバ１２に送信される。ただし、かかる場合には、他のセンサを用いて予め取得されたデータが看護業務に対応付けられた辞書データとして知識ＤＢ３０に記憶される。
【００６６】
上述したように、サーバ１２は、通過センサ１８からのデータに基づいて看護師の現在位置（所在）を知ることができる。また、モニタ装置２２（対物センサ）の出力によって、看護師が使用する器具等を知ることができる。さらに、モニタ装置２２（集音マイク）の出力およびピンマイク９６を通して入力される音声に基づいて看護師が実行しようとする看護業務を知ることもできる。さらにまた、モニタ装置２２（ビデオカメラ）の撮影映像（画像データ，映像データ）を分析したり、中継器２０からの加速度データを辞書データと比較したりすることにより、看護師の行動を検出（特定）することもできる。たとえば、このようなモニタ手段（サーバ１２，通過センサ１８，中継器２０，モニタ装置２２）の検出結果を複合的に勘案すれば、看護師の行動（イベント）を比較的正確に検出することができる。以下、同様である。
【００６７】
なお、モニタ装置２２（集音マイク）の出力（音声）を解析したり、モニタ装置２２（ビデオカメラ）の撮影映像を解析したりすることにより、病院（病棟）内に存在する他の者すなわち医師、清掃員、患者等の様子を知ることもできる。
【００６８】
また、看護師の行動が目標を達成するか否かの推論は、数４に従って行われる。ただし、背景知識Ｆとしては、知識ＤＢ３０に含まれる公理も含まれる。
【００６９】
［数４］
【００７０】
ただし、∪は論理のＯＲを意味する。
【００７１】
また、最終目標Ｏをサブ目標Ｏｊの部分集合と考えると、数５に従って推論することも可能である。
【００７２】
［数５］
【００７３】
ここで、推論結果がサブ目標Ｏｊを得ることができる場合には、次の部分シナリオについての推論を行う。ただし、当該サブ目標Ｏｊが最終目標Ｏと一致する場合には、看護業務を終了したと判断する。
【００７４】
一方、推論結果がサブ目標Ｏｊを得ることができない場合には、次のいずれかの場合に、看護業務がシナリオに違反していることを警告する。これは、医療事故や医療ミスが発生するのを事前に防止するためである。具体的には、推論結果がサブ目標Ｏｊを得ることができない場合には、看護師が別の看護業務に移行したかどうかを判断する。ここで、看護師の行動が、戻るべき、または、進むべきイベントに復帰または到達し得ないときに、別の看護業務に移行したと判断される。
【００７５】
看護師が別の看護業務に移行していなければ、現在の看護業務を途中で終了しようとしているかどうかを判断する。たとえば、看護師が現在の看護業務に全く関係のないイベントを実行したり、途中のイベントを飛ばして最後のイベントを実行しようとしたり（たとえば、ダイアモックスを溶かさないで、注射しようとする。）すると、現在の看護業務を途中で終了しようとしていると判断する。
【００７６】
また、看護師が別の看護業務に移行すると、当該別の看護業務を終了した後に、元の看護業務（上述の現在の看護業務）に戻るか否かを判断する。別の看護業務を終了したか否かは、当該別の看護業務についてのシナリオに含まれる最後のイベントを実行したか否かで判断される。また、元の看護業務に戻ったか否かは、看護師の行動が元の看護業務に対応するシナリオに含まれる、かつ実行すべきであるイベントと一致するか否かで判断される。
【００７７】
現在の看護業務を途中で終了しようとする場合、または、別の看護業務を終了した後に元の看護業務に戻らない場合には、当該看護業務についてのシナリオの正しい最終目標を得ることができない。つまり、上述したような医療事故などの不都合を引き起こす可能性があるため、看護師にシナリオに違反していることの警告を与えるようにしてある。
【００７８】
なお、看護師が或る看護業務を行っている場合に、他の看護業務を頼まれることは日常茶飯事であり、単に他の看護業務に移行したことだけでは警告を発しないようにしてある。これは、警告の乱発を防止して、医療事故や医療ミスが発生する恐れのあるような本当に必要なときだけ警告を与えて、警告システム１０としての機能を十分に発揮させるためである。
【００７９】
具体的には、サーバ１２は図８および図９に示すフロー図に従って全体処理を実行する。ただし、図８および図９に示す全体処理は、着目する１人の看護師について一定時間（たとえば、１５分〜３０分）毎に実行される。つまり、全体処理は看護師毎に実行される。図８に示すように、サーバ１２は全体処理を開始すると、ステップＳ１で、業務を確認する。ここでは、図示しないワークフローのデータを参照して、着目する看護師が担当する患者について行うべき看護業務が有るかどうかを判断するのである。ただし、ワークフローは、当該着目する看護師の一日の看護業務が時系列に従って記述された表であり、電子カルテなどに基づいて作成される。
【００８０】
続くステップＳ３では、看護業務の開始時間であるかどうかを判断する。つまり、開始すべき看護業務が有るかどうかを判断する。ただし、厳密に看護業務の開始時間であるかを判断する必要はなく、看護業務の開始時間の前後一定時間（たとえば、３〜５分）内であるかどうかを判断するようにしてある。
【００８１】
ステップＳ３で“ＮＯ”であれば、つまり看護業務の開始時間でなければ、そのまま同じステップＳ３に戻る。ただし、無駄な処理を削減するために、一定時間（たとえば、３〜５分）待機してから、ステップＳ３に戻るようにしてもよい。一方、ステップＳ３で“ＹＥＳ”であれば、つまり看護業務の開始時間であれば、ステップＳ５で、着目する看護師が看護業務を開始したかどうかを判断する。ここでは、着目する看護師の看護師ＩＤを検出する通過センサ１８が変化したり、ビデオカメラで撮影される当該看護師に動きがあったり、当該看護師がピンマイク９６を通して看護業務を開始することの音声入力があったりしたかどうかを判断する。
【００８２】
ステップＳ５で“ＮＯ”であれば、つまり看護業務を開始していなければ、ステップＳ７で、業務開始のアラーム（警告）を発して、ステップＳ５に戻る。ここで、警告は、たとえば、着目する看護師に割り当てられた端末１６に、看護業務を開始すべき旨のメッセージを送信することにより行う。なお、メッセージのような情報が端末１６に送信されると、上述したように、音ないし振動またはその両方で当該端末１６を装着する看護師にメッセージ（情報）があることが報知される。
【００８３】
一方、ステップＳ５で“ＹＥＳ”であれば、つまり看護業務を開始すれば、ステップＳ９で、看護師の現在の状況を検出する。具体的には、ここでは、サーバ１２は、看護師の現在位置、現在の行動（処置）および看護師が所持ないし使用する薬品・器具を、通過センサ１８からのデータ、中継器２０からのデータまたはモニタ装置２２からのデータに基づいて検出する。ここで、通過センサ１８からのデータに基づいて看護師の現在位置を検出するのは、中継器２０からのデータに基づいて処置（イベント）を特定できない場合であっても、当該看護師の現在位置と当該看護師のワークフローとに基づいて、処置を特定できる場合があるからである。たとえば、看護師の現在位置がレントゲン室や病室であれば、患者のレントゲン撮影の補助を行ったり、患者の検温、検圧、注射または点滴注射を行ったりしていることを特定（推定）することができる。また、モニタ装置２２の出力から使用している物（薬品・器具）を特定することができる。
【００８４】
次のステップＳ１１では、処置や薬品・器具を、特定可能かどうかを判断する。ステップＳ１１で“ＮＯ”であれば、つまり処置や薬品・器具を特定できなければ、そのまま図９に示すステップＳ１５に進む。かかる場合には、事故の事例情報（事例データ）を特定できないため、シナリオｓｉを絞り込むことができない。したがって、後述するステップＳ１５において、シナリオＤＢ２８に記憶された全シナリオｓｉを参照することとなる。一方、ステップＳ１１で“ＹＥＳ”であれば、つまり処置や薬品・器具を特定できれば、ステップＳ１３で、シナリオＤＢ２８に記憶された全シナリオｓｉのうち、特定した処置や薬品・器具を含む事例データを知識ＤＢ３０から抽出し、抽出した事例データが示すシナリオｓｉを特定（選択）する。ただし、後述するように、事例データが示す事例情報の理由の情報として、シナリオ名の総括名称が記述されている場合には、総括名称が示すすべてのシナリオｓｉが特定される。たとえば、ステップＳ１３では、サーバ１２は、シナリオＤＢ２８において、特定したシナリオｓｉのみにフラグを立てたり、サーバ１２の内部メモリに特定したシナリオｓｉのみを読み出したりすることにより、ステップＳ１５において参照するシナリオｓｉを絞り込むのである。これによって、参照するシナリオｓｉの数が大幅に削減される。
【００８５】
なお、この実施例では、処置や薬品・器具のような事故詳細の情報のみに基づいて事例データ（シナリオ名）を特定するようにしたが、事例データが示す事例情報には、職歴、部署経験、場所および背景の情報も含まれるため、事故詳細の情報に加えて、職歴、部署経験、場所および背景の情報のうちの少なくとも１つ以上をさらに満たす事例データ（シナリオ名）を特定するようにしてもよい。
【００８６】
図９に示すように、ステップＳ１５では、イベントｅｉを含むシナリオｓｉが有るかどうかを判断する。ここでは、サーバ１２は、上述のようにして、着目する看護師の行動を検出する。そして、サーバ１２は、シナリオＤＢ２８の全部または特定した一部のシナリオｓｉを参照して、検出した行動と一致するイベントｅｉを含むシナリオｓｉが存在するかどうかを判断する。
【００８７】
ステップＳ１５で“ＹＥＳ”であれば、つまり看護師の行動と一致するイベントｅｉを含むシナリオｓｉがあれば、ステップＳ１７で、目標Ｏｉを確認する。ここで、目標Ｏｉは、シナリオｓｉに従って業務を行った場合に得られる目標である。ステップＳ１７では、イベントｅｉを含むシナリオｓｉの目標Ｏｉが、ステップＳ９で検出された看護業務（最終目標Ｏ）と一致するかどうかを確認しているのである。
【００８８】
続くステップＳ１９では、現在の背景知識Ｆと行動ｅｉを含むすべてのシナリオｓｉとから最終目標Ｏを説明できないかどうかどうかを判断（確認）する。ステップＳ１９で“ＹＥＳ”であれば、つまり現在の背景知識Ｆと行動ｅｉを含むすべてのシナリオｓｉとから最終目標Ｏを説明できない場合には、そのままステップＳ１５に戻って、シナリオｓｉの検出および目標Ｏｉの確認を再度実行する。しかし、ステップＳ１９で“ＮＯ”であれば、つまり現在の背景知識Ｆと行動ｅｉを含むすべてのシナリオｓｉとから最終目標Ｏを説明できる場合には、ステップＳ２１で、後述する各サブ目標達成の確認および警告処理（図１０および図１１参照）を実行して、全体処理を終了する。
【００８９】
また、ステップＳ１５で“ＮＯ”であれば、つまり看護師の行動と一致するイベントｅｉを含むシナリオｓｉが存在しなければ、ステップＳ２３で、当該看護師の一連の行動（イベントｅｉ）を獲得する。続くステップＳ２５では、着目する看護師が当該看護業務を終了したかどうかを判断する。ステップＳ２５で“ＮＯ”であれば、つまり着目する看護師が当該看護業務を終了していなければ、そのままステップＳ２３に戻る。一方、ステップＳ２５で“ＹＥＳ”であれば、つまり着目する看護師が当該看護業務を終了すれば、ステップＳ２７で、着目する看護師の一連の行動を新しいシナリオｓｉとしてシナリオＤＢ２８に記憶（追加）して、全体処理を終了する。
【００９０】
なお、この実施例では、看護師の行動と一致するシナリオｓｉが存在しない場合には、当該看護師の一連の行動を新しいシナリオｓｉとしてシナリオＤＢ２８に記憶するようにしてあるが、このような一連の行動を別途データベースに蓄積しておき、学習処理によって統合（一般化）するなどして新しいシナリオｓｉを作成するようにしてもよい。
【００９１】
図１０および図１１は、図９に示したステップＳ２１の各サブ目標達成の確認（推論）および警告処理を示すフロー図である。サーバ１２は、各サブ目標達成の確認および警告処理を開始すると、ステップＳ４１で、変数ｊを初期化する（ｊ＝１）。続くステップＳ４３では、現在の背景知識Ｆと部分シナリオｓｉｊとからサブ目標Ｏｊを説明できないかどうかを判断（確認）する。ステップＳ４３で“ＮＯ”であれば、つまり現在の背景知識Ｆと部分シナリオｓｉｊとからサブ目標Ｏｊを説明できると推論されれば、サブ目標Ｏｊを達成できると判断し、ステップＳ４５で、シナリオｓｉｊが時系列順に実行すべきイベントを含むかどうかを判断する。これは、部分シナリオｓｉｊに付されたラベルを参照して判断する。
【００９２】
ステップＳ４５で“ＮＯ”であれば、つまりシナリオｓｉｊが時系列順に実行すべきイベントを含んでいない場合には、そのままステップＳ５１に進む。しかし、ステップＳ４５で“ＹＥＳ”であれば、つまりシナリオｓｉｊが時系列順に実行すべきイベントを含む場合には、ステップＳ４７で、当該イベントが時系列順に実行されているか否かを判断する。ここでは、看護師の行動を検出し、当該行動がシナリオｓｉｊに含まれるイベントに従って実行されようとしているか否かを判断する。
【００９３】
ステップＳ４７で“ＮＯ”であれば、つまりイベントが時系列順に実行されていなければ、ステップＳ４９で、シナリオ違反をアラームして、ステップＳ４７に戻る。しかし、ステップＳ４７で“ＹＥＳ”であれば、つまりイベントが時系列順に実行されている場合には、ステップＳ５１で、現在の業務をすべて終了したかどうかを判断する。つまり、シナリオｓｉに含まれるすべてのイベントｅｉの実行を終了し、目標Ｏｉを達成（ワークフローが示す看護業務を完了）したかどうかを判断する。ステップＳ５１で“ＮＯ”であれば、つまり現在の業務をすべて終了していなければ、ステップＳ５３で、変数ｊをインクリメントして（ｊ＝ｊ＋１）、ステップＳ４３に戻る。つまり、次のサブ目標Ｏｊ＋１を達成するか否かの推論を行う。しかし、ステップＳ５１で“ＹＥＳ”であれば、つまり現在の業務をすべて終了すれば、各サブ目標達成の確認および警告処理をリターンする。
【００９４】
また、ステップＳ４３で“ＹＥＳ”であれば、つまり現在の背景知識Ｆとシナリオｓｉｊとからサブ目標Ｏｊを説明できないと推論されれば、サブ目標Ｏｊを達成できないと判断し、図１１に示すステップＳ５５で、別の看護業務へ移ったかどうかを判断する。ステップＳ５５で“ＮＯ”であれば、つまり別の看護業務に移っていなければ、ステップＳ５７で、現在の看護業務を途中で終了したかどうかを判断する。
【００９５】
ステップＳ５７で“ＮＯ”であれば、つまり現在の看護業務を途中で終了していない場合には、そのまま図１０に示したステップＳ４３に戻る。一方、ステップＳ５７で“ＹＥＳ”であれば、つまり現在の看護業務を途中で終了した場合には、そのままステップＳ６３に進む。
【００９６】
また、ステップＳ５５で“ＹＥＳ”であれば、つまり別の看護業務に移った場合には、ステップＳ５９で、当該別の看護業務に対応するシナリオｓｋを確認して、ステップＳ６１に進む。なお、この実施例では、簡単のため、別の看護業務に対応するシナリオｓｋの確認処理については、１つのステップ（処理）で示してあるが、厳密には、図９に示したステップＳ１５〜ステップＳ１９と同様の処理が実行されるのである。これは、途中で別の看護業務に移行した場合であっても、当該別の看護業務において医療事故等が発生する可能性もあり、当該別の看護業務についてもシナリオを用いた推論により、シナリオ違反の発生を事前に発見し、その警告を与えるためである。
【００９７】
ステップＳ６１では、元の看護業務に戻るか否かを判断する。ここで、元の看護業務は、ステップＳ５５で“ＹＥＳ”と判断される直前までに行っていた看護業務（上述の現在の看護業務）である。ステップＳ６１で“ＹＥＳ”であれば、つまり元の看護業務に戻る場合には、そのままステップＳ４３に戻る。しかし、ステップＳ６１で“ＮＯ”であれば、つまり元の看護業務に戻らない場合には、ステップＳ６３で、シナリオ違反のアラームを与えて、ステップＳ６１に戻る。
【００９８】
なお、図示等は省略したが、ステップＳ４３，Ｓ４７，Ｓ５１，Ｓ５５，Ｓ５７，Ｓ６１の処理では、着目する看護師の行動が検出される。
【００９９】
このように、看護師の看護業務における行動等とシナリオとから得られる結果を推論し、推論結果が所望の目標を達成できない場合にのみ警告を発するので、警告の乱発を防止し、本当に必要なときだけ警告することができる。また、事例データに基づいてシナリオを絞り込むので、判断処理（Ｓ１５，Ｓ１９，Ｓ４７など）の誤りを少なくすることができる。
【０１００】
なお、この実施例では、事故が発生するおそれのある看護師のみに警告を与えるようにしてあるが、当該看護師以外の者（医師、他の看護師、師長）にも警告するようにして、医療事故等を確実に防止するようにしてもよい。
【０１０１】
以上のように、知識として記憶してある事故の事例情報に基づいて、参照するシナリオｓｉを絞り込むことができるので、全部のシナリオｓｉを参照する場合に比べて、シナリオ違反のアラーム（警告）を発するか否かの判断処理を軽減することができる。したがって、最適な事例情報を構築することができれば、警告を発するか否かの判断処理をさらに軽減することができると考えられる。
【０１０２】
このため、この実施例では、日々発生する事故の事例を収集（記憶）しておき、同様の事故の事例については１つにまとめて新しい事故の事例として登録（追加）するようにしてある。
【０１０３】
上述したように、事故の事例情報の事例データには、事例情報に事故ラベルが付され、事例情報には、理由、事故、属性情報、時間、場所および背景の各情報が含まれる。たとえば、「４月の或る早朝、勤務異動してきて間もない看護師がインスリン注射を担当しました。薬品庫からインスリンのバイアルを取り出し、いつものごとく注射器に予定量を扱い、患者さんの所へ出かけて注射してきました。その後、バイアルを薬品庫に戻すときに、「ノボリン３０Ｒ（４０）」と書いたバイアルがあります。自分が持っているインスリンのバイアルには「ノボリン３０Ｒ（１００）」と書かれてありました。患者さんに、「ノボリン３０Ｒ（４０）」のつもりで、「ノボリン３０Ｒ（１００）」の方を注射してしまいました。」という事故の事例がある。
【０１０４】
このような事故の事例では、事例情報は次のように示される。具体的には、事故の事例情報（１）として、｛理由，事故詳細，職歴，部署経験，時間，場所，背景｝＝｛インスリン注射，事故，３年，１年，６：００，病室，異動直後，複数種類の薬品｝と表わすことができる。ただし、事故詳細の情報は、｛薬品，処置，事故の内容｝＝｛ノボリン３０Ｒ（１００），注射，過剰投与｝である。また、背景の情報として、｛異動直後，複数種類の薬品｝が記述されている。
【０１０５】
また、詳細な具体例は省略するが、同様の事故の事例情報（２）として、｛理由，事故，職歴，部署経験，時間，場所，背景｝＝｛ノボリン注射，事故，２年６月，１０か月，１１：００，病室，複数種類の薬品｝が得られ、同様に事故の事例（３）として、｛理由，事故，職歴，部署経験，時間，場所，背景｝＝｛インスリン注射，事故，１０年，５年，１６：００，病室，複数種類の薬品｝が得られたと仮定する。ただし、事故の事例情報（２）および（３）において、事故詳細の情報は、｛薬品，処置，事故の内容｝＝｛ノボリン３０Ｒ（１００），注射，過剰投与｝と仮定する。
【０１０６】
たとえば、事故の事例情報（１）と事故の事例情報（２）とを学習処理によってまとめる（統合する）と、新しい事故の事例情報として、｛理由，事故詳細，職歴，部署経験，時間，場所，背景｝＝｛注射，事故詳細，短期（３年未満），短期（１年以内），♯，病室，異動直後，複数種類の薬品｝を得ることができる。ただし、事故詳細の情報は、｛薬品，処置，事故の内容｝＝｛ノボリン３０Ｒ（１００），注射，過剰投与｝である。
【０１０７】
また、事故の事例情報（１）と事故の事例情報（３）とを学習処理によってまとめると（事故の事例情報（１）−（３）をまとめる場合も同様）、新しい事故の事例として、｛理由，事故詳細，職歴，部署経験，時間，場所，背景｝＝｛注射，事故，♯，♯，♯，病室，複数種類の薬品｝を得ることができる。ただし、事故詳細の情報は、｛薬品，処置，事故の内容｝＝｛ノボリン３０Ｒ（１００），注射，過剰投与｝である。
【０１０８】
ここで、複数の事故の事例情報から１つの新しい事故の事例情報を作成する方法（学習方法）について説明することにする。まず、複数の事故の事例情報のうち、事故詳細の情報に含まれる「事故の内容」が同じものをグループ化する。次に、理由の情報と事故詳細の情報のうちの「事故の内容」とが入力された或る列を作成する。ここで作成される或る列は、理由の情報および事故詳細の情報のうちの「事故の内容」以外の事故（「事故の内容」を除く。），職歴，部署経験，時間，場所，背景の各情報が空欄にされた配列である。このとき、類義語辞書を参照することにより、理由の情報については、可能であれば総括名称にまとめられる。上述の例では、“インシュリン注射”と“ノボリン注射”との総括名称である“注射”が或る列の理由の情報として格納される。なお、「事故の内容」が同じものをグループ化しているため、或る列においても「事故の内容」として“過剰投与”が格納される。
【０１０９】
続いて、グループ化された複数の事故の事例情報の中で、事故詳細の情報に含まれる「処置」の内容が同じものまたは類似するものが存在するかどうかが判断される。ただし、「処置」の内容が類似するか否かは、知識ＤＢ３０内の類義語辞書を参照して判断される。「処置」の内容が少なくとも類似する場合には、それらの事故詳細の情報に含まれる「薬品」または「器具」を或る列に格納するとともに、その「処置」を或る列に格納する。ただし、「薬品」，「器具」，「処置」の内容が同じである場合には、各事故の事例情報をまとめるべく、「薬品」，「器具」，「処置」の内容を或る列にそのまま格納し、「薬品」，「器具」，「処置」の内容が類似する場合には、各事故の事例情報をまとめるべく、それぞれの「薬品」，「器具」，「処置」の内容をリストにして或る列に格納する。
【０１１０】
ただし、「処置」の内容が非類似である場合には、事故詳細の情報に含まれる「薬品，器具」が同一のものまたは類似するものが有るかどうかが判断される。「薬品，器具」の内容が類似するか否かもまた、類義語辞書を参照して判断される。「薬品，器具」の内容が少なくとも類似する場合には、それらの事故詳細の情報に含まれる「処置」を或る列に格納するとともに、その「薬品，器具」を或る列に格納する。「薬品」，「器具」，「処置」を或る列に格納する方法は上記のとおりであるが、ここでは、前提として、「処置」が非類似であるため、各事故の事例情報についての「処置」の内容がリストにされて或る列に格納される。
【０１１１】
このようにして、事故詳細の情報が、グループ化された複数の事故の事例情報について統合されるのである。
【０１１２】
さらに、この実施例では、類義語辞書を参照して、類似する「処置」，「薬品」，「器具」が追加される。類似する他の「処置」を行う場合や類似する他の「薬品・器具」を使用する場合にも同様の事故が発生する可能性があると考えられるからである。したがって、たとえば、上述の事例情報には、（シグマート ２ｍｇ／Ｖ，シグマート ４８ｍｇ／Ｖ）や（ミスリロール ５ｍｇ／１０ｍＬ／Ａ，ミスリロール ２５ｍｇ／５０ｍＬ／Ａ）などの薬品が、事故詳細の情報における薬品のリストに追加される。したがって、或る列では「薬品」のリストとして、｛ノボリン，シグマート，ミスリロール…｝が記述される。
【０１１３】
次に、グループ化された複数の事故の事例情報の中で、理由の情報および事故詳細の情報以外の情報、すなわち職歴、部署経験、時間、場所、背景の各情報のうち、同じ内容のものがあるかどうかが判断される。
【０１１４】
同じ内容のものがあれば、同じ内容のものについては、それらの事故の事例情報をまとめるべく、そのままの内容を或る列に格納する。そして、同じ内容で無いものについては、それらを含むようにまとめた内容を或る列に格納する。たとえば、グループ化されたすべての事故の事例情報において、場所の情報が「レントゲン室」を示す場合には、或る列の場所の情報についても「レントゲン室」が記述される。また、たとえば、グループ化された３つの事故の事例情報において、職歴が、それぞれ、１年，半年，１０か月である場合には、或る列の職歴については「１年未満」または「短期」などが記述される。他の情報についても同様である。
【０１１５】
この実施例では、職歴の情報については、３年未満（短期）、３年以上１０年未満、１０年以上（ベテラン）のような３つの区分でまとめる（分類する）ようにしてある。ただし、２区分以上をまとめる場合には、職歴は事故の要因とは関係ないとして、或る列の職歴の情報として「♯」が記述される。また、部署経験の情報については、１年未満（短期）、１年以上５年未満、５年以上（ベテラン）のような３つの区分でまとめるようにしてある。ただし、２区分以上をまとめる場合には、部署経験は事故の要因とは関係ないとして、或る列の部署経験の情報として「♯」が記述される。
【０１１６】
なお、これらの年月の数値は例示であり、実際には、この警告システム１０が適用される病院等において実験するなどして経験的に得られた数値を設定すればよい。
【０１１７】
また、たとえば、時間の情報については、早朝（４時−８時）、午前（８時−１２時）、午後（１２時−１６時）、夕方（１６時−２０時）、夜間（２０時−４時）のような５つの区分でまとめるようにしてある。ただし、３区分以上をまとめる場合や隣接しない２区分をまとめる場合には、時間（帯）は事故の要因とは関係ないとして、或る列の時間の情報として「♯」が記述される。
【０１１８】
さらに、たとえば、場所の情報については、病室、トイレ、浴室、洗濯室、廊下、階段室、診察室、手術室、レントゲン室などの具体的な場所が一義的に決定されるため、これらのうちの２つないし３つを１つにまとめるようなことは困難である。したがって、グループ化された事例情報の場所の情報が異なる場合には、場所は事故の要因とは関係ないとして、或る列の場所の情報として「♯」が記述される。
【０１１９】
さらにまた、たとえば、背景の情報としては、上述したように、同じ名前の患者が存在すること、ナースコールで呼び出されたこと、忙しかったこと、複数種類の薬品が存在することなどの具体的な内容で決定されるため、これらのうちの２つないし３つを１つにまとめるようなことはできない。したがって、グループ化された事例情報の場所の情報が異なる場合には、背景の内容は事故の要因とは関係ないとして、或る列の背景の情報として「♯」が記述される。
【０１２０】
なお、これらは単なる例示であり、区分の仕方やまとめ方は適宜変更可能であり、警告システム１０が設置（適用）される病院や病棟毎に設定することも可能である。
【０１２１】
このように、同じ事故の内容の事例情報では、理由の情報は、可能であれば総括名称でまとめられ、職歴、部署経験、時間、場所および背景の各情報については、同様の内容についてはまとめるようにし、事故詳細の情報に含まれる薬品・器具や処置については、同じ内容でない場合には、リストとしてそれぞれを記述することにより、或る程度の幅を持たせるようにしてある。このようにして、或る列の空欄を埋めることにより、新しい事故の事例情報が作成される。そして、作成された新しい事故の事例情報が知識ＤＢ３０に登録（追加）される。
【０１２２】
具体的には、サーバ１２は、図１２ないし図１４に示すフロー図に従って事例構築処理を実行する。なお、事例構築処理は、たとえば、事故の事例情報が所定個数（たとえば、３０個）以上仮ＤＢ３６に記憶された場合や一定期間（たとえば、３０日）が経過した場合に、実行される。ただし、サーバ１２の管理者等が必要に応じてこの事例構築処理を実行させるようにしてもよい。また、事例構築処理は、上述した全体処理（図８および図９）と並列的に実行される。
【０１２３】
図１２に示すように、サーバ１２は、事例構築処理を開始すると、ステップＳ８１で、変数Ｃｏｕｎｔを初期化する（Ｃｏｕｎｔ＝０）。この変数Ｃｏｕｎｔは、事故の事例についてのグループの数をカウントするためのカウンタである。続くステップＳ８３では、仮ＤＢ３６からデータを読み込む。つまり、サーバ１２は、仮ＤＢ３６に記憶された事故の事例情報についてのデータをすべて読み出し、図示しないＲＡＭのような内部メモリに記憶（ロード）する。次のステップＳ８５では、変数ｉを初期化する（ｉ＝１）。この変数ｉは、ロードされた事故の事例情報についての事例データを識別可能にカウントするための変数である。
【０１２４】
続いて、ステップＳ８７では、抜き出した（選択した）１つのデータを基準として、ｉ番目のデータと比較する。つまり、読み込んだ事故の事例情報のうちの１つを基準の事例情報とし、他の事故の事例情報と順次比較するのである。次のステップＳ８９では、基準の事例情報とｉ番目の事例情報とが同じ事故のものであるかどうかを判断する。つまり、比較する２つの事例情報が示す事故詳細の情報のうち、「事故の内容」が同じであるかどうかを判断するのである。ステップＳ８９で“ＮＯ”であれば、つまり異なる事故のものであれば、そのままステップＳ９５に進む。
【０１２５】
しかし、ステップＳ８９で“ＹＥＳ”であれば、つまり同じ事故のものであれば、ステップＳ９１で、基準の事例情報とｉ番目の事例情報とをグループにまとめる。たとえば、基準の事例情報の識別情報（事故ラベル）とｉ番目の事例情報の事故ラベルとがグループ化される。そして、ステップＳ９３で、変数Ｃｏｕｎｔをインクリメントして（Ｃｏｕｎｔ＝Ｃｏｕｎｔ＋１）、ステップＳ９５に進む。
【０１２６】
ステップＳ９５では、すべてのデータと比較したかどうかを判断する。つまり、変数ｉが仮ＤＢ３６から読み込んだ事故の事例情報のデータの総数以上であるかどうかを判断する。ステップＳ９５で“ＮＯ”であれば、つまり比較していないデータが有れば、次の（ｉ＋１番目の）データと比較するべく、ステップＳ９７で、変数ｉをインクリメントして（ｉ＝ｉ＋１）、ステップＳ８７に戻る。一方、ステップＳ９５で“ＹＥＳ”であれば、つまりすべてのデータと比較すれば、ステップＳ９９で、変数Ｃｏｕｎｔが０よりも大きいかどうかを判断する。つまり、この事例構築処理では、同じ或いは類似する事例情報をまとめるようにしてあるため、少なくとも２つの事例情報をグループにまとめたかどうかを判断しているのである。
【０１２７】
ステップＳ９９で“ＮＯ”であれば、つまり変数Ｃｏｕｎｔが０であれば、グループ化された事例情報が無いと判断して、そのまま事例構築処理を終了する。一方、ステップＳ９９で“ＹＥＳ”であれば、つまり変数Ｃｏｕｎｔが１以上であれば、グループ化された事例情報が有ると判断して、図１３に示すステップＳ１０１で、理由の情報および事故詳細の情報のうちの事故の内容のみを入力した或る列をグループＤＢ３８に作成する。
【０１２８】
続くステップＳ１０３では、グループの中で、処置が少なくとも類似するものがあるかどうかを判断する。なお、類似するか否かは、知識ＤＢ３０に記憶された類義語辞書を参照して判断される。以下、同様である。ステップＳ１０３で“ＹＥＳ”であれば、つまりグループの中で、処置が少なくとも類似するものが有る場合には、ステップＳ１０５で、薬品または器具を或る列に格納し、ステップＳ１０７で、処置を或る列に格納して、ステップＳ１１５に進む。ただし、ステップＳ１０５では、グループ化された事例情報に記述された薬品または器具が同じ場合には、そのまま当該薬品または器具を或る列に格納する。また、ステップＳ１０５では、グループ化された事例情報に記述された薬品または器具が類似する（異なる）場合には、それぞれの事例情報に記述された薬品または器具をリストにして或る列に格納する。同様に、ステップＳ１０７では、グループ化された事例情報に記述された処置が同じ場合には、そのまま当該処置を或る列に格納する。また、ステップＳ１０７では、グループ化された事例情報に記述された処置が類似する（異なる）場合には、それぞれの事例情報に記述された処置をリストにして或る列に格納する。
【０１２９】
また、ステップＳ１０３で“ＮＯ”であれば、つまりグループの中で、処置が非類似であれば、ステップＳ１０９で、グループの中で、薬品または器具すなわち使用する物が少なくとも類似するものがあるかどうかを判断する。ステップＳ１０９で“ＮＯ”であれば、つまりグループの中で、薬品または器具が非類似であれば、新しい事例情報として追加するのは不適切であると判断して、図１４に示すように、そのまま事例構築処理を終了する。
【０１３０】
しかし、ステップＳ１０９で“ＹＥＳ”であれば、つまりグループの中で、薬品または器具が少なくとも類似するものが有る場合には、ステップＳ１１１で、処置を或る列にリストとして格納し、ステップＳ１１３で、薬品または器具を或る列に格納して、ステップＳ１１５に進む。ただし、グループ化された事例情報の処置はステップＳ１０３で“ＮＯ”と判断されているため、非類似の処置である。したがって、ステップＳ１１１では、グループ化された事例情報のそれぞれに記述された処置をリストにして或る列に格納する。ただし、ステップＳ１１３では、グループ化された事例情報に記述された薬品または器具が同じ場合には、そのまま当該薬品または器具を或る列に格納する。また、ステップＳ１１３では、グループ化された事例情報に記述された薬品または器具が類似する（異なる）場合には、それぞれの事例情報に記述された薬品または器具をリストにして或る列に格納する。
【０１３１】
ステップＳ１１５では、処置、薬品または器具のそれぞれについて、似たものをリストに追加する。ここでは、類義語辞書を参照して、類似する処置や薬品，器具をリストに追加して、より多くの事例に当てはまる事例情報を作成するのである。そして、図１４に示すステップＳ１１７では、グループの中で、理由および事故以外の情報、つまり職歴、部署経験、時間、場所および背景の各情報で同じものがあるかどうかを判断する。
【０１３２】
ステップＳ１１７で“ＹＥＳ”であれば、つまりグループの中で、理由および事故以外の情報で同じものが有る場合には、職歴、部署経験、時間、場所および背景の各情報について同じものはそのまま或る列に格納し、異なるものはそれらを含むようにまとめて或る列に格納して、ステップＳ１２３に進む。一方、ステップＳ１１７で“ＮＯ”であれば、つまりグループの中で、理由および事故以外の情報で同じものが無い場合には、職歴、部署経験、時間、場所よび背景の各情報について、異なるものを含むようにまとめて或る列に格納して、ステップＳ１２３に進む。ステップＳ１２３では、或る列すなわち新しい事故の事例情報についての事例データを知識ＤＢ３０に登録（追加）して、知識構築処理を終了する。
【０１３３】
なお、この実施例では、新しく作成された事故の事例情報をそのまま知識ＤＢ３０に追加するようにしたが、同じ事例情報が知識ＤＢ３０に既に登録されている場合には、追加しないようにしてもよい。また、類似する事例情報が知識ＤＢ３０に既に登録されている場合には、当該類似する事例情報と新しい事例情報とをまとめることにより、既に登録されている事例情報を再構築するようにしてもよい。ただし、まとめ方は、グループ化された複数の事例情報をまとめる方法（ステップＳ１０１−ステップＳ１２１）と同様である。
【０１３４】
また、図１２−図１４に示す事例構築処理では、１つのグループについてのみ説明したが、１つのグループについての事例構築処理を終了した後に、残りの事故の事例情報について再度事例構築処理を実行し、これを繰り返し、グループが作成できなくなった時点で、事例構築処理を終了するようにしてもよい。
【０１３５】
この実施例によれば、複数の事故の事例情報のうち、同じまたは類似するものを１つにまとめた新しい事故の事例情報を作成して知識ＤＢに登録するので、同様の事故の事例情報が重複して作成されることがない。つまり、最適な事故の事例情報を構築することができる。したがって、最適な事故の事例情報に基づいて参照するシナリオを絞り込むことができ、警告を発するか否かの判断処理が大幅に軽減される。
【０１３６】
なお、この実施例では、看護師についての行動を監視し、看護師の行動に起因する事故を防止するようにしたが、医師や清掃員など、病院（病棟）内で勤務する他の人員の行動に起因する事故を防止するようにしてもよい。かかる場合には、医師や清掃員などに、端末１６、中継器２０、ピンマイク９６、非接触センサ９８、加速度センサ１００および送信機１１０などを装着（所持）させる必要がある。また、看護師、医師および清掃員など、病院（病棟）内で勤務するすべての人員に起因する事故を防止するようにしてもよい。かかる場合には、事故の事例としては、すべての人員について記憶され、また、事故の事例に含まれる属性情報として、職務（医師、看護師、清掃員など）の区別も記述される。
【０１３７】
また、この実施例では、予め事故の事例についての事例データが知識ＤＢに登録されていることを前提として説明したが、知識ＤＢに予め事例データを登録しておく必要性はなく、初めから（１から）事例データを構築することもできる。
【０１３８】
さらに、この実施例では、看護業務についての事故の事例を構築する場合について説明したが、他の業務についての事故の事例を構築するようにしてもよい。たとえば、劇薬を扱うような試験（実験）施設ないし工場における業務や自動車などの組み立て作業を行う工場における業務の事故の事例を構築することができる。
【図面の簡単な説明】
【０１３９】
【図１】図１はこの発明の事例構築装置としてのサーバを含む警告システムの構成の一例を示す図解図である。
【図２】図２は図１に示すサーバの電気的な構成を示す図解図である。
【図３】図３は図１に示す看護師用端末の電気的な構成を示す図解図である。
【図４】図４は図１に示す通過センサの設置状況を説明するための図解図である。
【図５】図５は看護師用端末、中継器および送信機を看護師に装着した状態を示す図解図である。
【図６】図６は図１に示す通過センサの電気的な構成を示す図解図である。
【図７】図７は図１に示す中継器の電気的な構成を示す図解図である。
【図８】図８は図１に示すサーバの全体処理の一部を示すフロー図である。
【図９】図９は図１に示すサーバの全体処理の他の一部であって、図８に後続するフロー図である。
【図１０】図１０は図１に示すサーバの各サブ目標達成確認および警告処理の一部を示すフロー図である。
【図１１】図１１は図１に示すサーバの各サブ目標達成確認および警告処理の他の一部であって、図１０に後続するフロー図である。
【図１２】図１２は図１に示すサーバの事例構築処理の一部を示すフロー図である。
【図１３】図１３は図１に示すサーバの事例構築処理の他の一部であって、図１２に後続するフロー図である。
【図１４】図１４は図１に示すサーバの事例構築処理のその他の一部であって、図１３に後続するフロー図である。
【符号の説明】
【０１４０】
１０ …警告システム
１２ …サーバ
１６ …看護師用端末
１８ …通過センサ
２０ …中継器
２２ …モニタ装置
２４，２６，２８，３０，３２，３４，３６，３８ …データベース
４０，７０，９０ …ＣＰＵ
４２，９２ …メモリ
４４ …キースイッチ
４８ …ＬＣＤ
５２ …振動モータ
５４，７８，１０２ …無線ＬＡＮ
７２，７４ …受光モジュール
７６ …ＲＡＭ
９６ …ピンマイク
９８ …非接触センサ
１００ …加速度センサ
１１０ …送信機
【特許請求の範囲】
【請求項１】
或る業務についての事故の事例についての事例データを記録し、当該事例データを知識としてデータベースに構築する事例構築装置であって、
事故の内容と事故が発生したときの処置の内容と事故が発生したときに使用していた物の名称とを含む事故情報を少なくとも含む事例情報を記憶する事例情報記憶手段、
前記事例情報記憶手段に記憶された複数の事例情報のうち、事故の内容が一致する事例情報をグループ化するグループ化手段、
前記グループ化手段によってグループ化された複数の事例情報の中で、前記事故が発生したときの処置の内容または前記事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在するか否かを判断する事故情報判断手段、
前記事故情報判断手段によって前記事故が発生したときの処置の内容または前記事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、前記グループ化した事例情報を１つにまとめて新規の事例情報を作成する新規事例作成手段、および
前記新規事例作成手段によって作成された新規の事例情報を前記データベースに登録する登録手段を備える、事例構築装置。
【請求項２】
前記新規事例作成手段は、前記事故情報判断手段によって前記事故が発生したときの処置の内容が少なくとも類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときに使用していた物の名称のそれぞれを含むように、前記グループ化した事例情報を１つにまとめて新規の事例情報を作成する、請求項１記載の事例構築装置。
【請求項３】
前記新規事例作成手段は、前記事故情報判断手段によって前記事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときの処置の内容のそれぞれを含むように、前記グループ化した事例情報を１つにまとめて新規の事例情報を作成する、請求項１記載の事例構築装置。
【請求項４】
前記新規事例作成手段は、前記事故が発生したときの処置の内容または前記事故が発生したときに使用していた物の名称に類似する内容を追加する追加手段を含む、請求項１ないし３のいずれかに記載の事例構築装置。
【請求項５】
或る業務についての事故の事例についての事例データを記録し、当該事例データを知識としてデータベースに構築する事例構築装置の事例構築方法であって、
（ａ）事故の内容と事故が発生したときの処置の内容と事故が発生したときに使用していた物の名称とを含む事故情報を少なくとも含む事例情報を記憶し、
（ｂ）前記ステップ（ａ）によって記憶された複数の事例情報のうち、事故の内容が一致する事例情報をグループ化し、
（ｃ）前記ステップ（ｂ）によってグループ化された複数の事例情報の中で、前記事故が発生したときの処置の内容または前記事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在するか否かを判断し、
（ｄ）前記ステップ（ｃ）によって前記事故が発生したときの処置の内容または前記事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、前記グループ化した事例情報を１つにまとめて新規の事例情報を作成し、そして
（ｅ）前記ステップ（ｄ）によって作成された新規の事例情報を前記データベースに登録する、事例構築方法。
【請求項１】
或る業務についての事故の事例についての事例データを記録し、当該事例データを知識としてデータベースに構築する事例構築装置であって、
事故の内容と事故が発生したときの処置の内容と事故が発生したときに使用していた物の名称とを含む事故情報を少なくとも含む事例情報を記憶する事例情報記憶手段、
前記事例情報記憶手段に記憶された複数の事例情報のうち、事故の内容が一致する事例情報をグループ化するグループ化手段、
前記グループ化手段によってグループ化された複数の事例情報の中で、前記事故が発生したときの処置の内容または前記事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在するか否かを判断する事故情報判断手段、
前記事故情報判断手段によって前記事故が発生したときの処置の内容または前記事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、前記グループ化した事例情報を１つにまとめて新規の事例情報を作成する新規事例作成手段、および
前記新規事例作成手段によって作成された新規の事例情報を前記データベースに登録する登録手段を備える、事例構築装置。
【請求項２】
前記新規事例作成手段は、前記事故情報判断手段によって前記事故が発生したときの処置の内容が少なくとも類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときに使用していた物の名称のそれぞれを含むように、前記グループ化した事例情報を１つにまとめて新規の事例情報を作成する、請求項１記載の事例構築装置。
【請求項３】
前記新規事例作成手段は、前記事故情報判断手段によって前記事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、当該類似する事例情報に含まれる事故が発生したときの処置の内容のそれぞれを含むように、前記グループ化した事例情報を１つにまとめて新規の事例情報を作成する、請求項１記載の事例構築装置。
【請求項４】
前記新規事例作成手段は、前記事故が発生したときの処置の内容または前記事故が発生したときに使用していた物の名称に類似する内容を追加する追加手段を含む、請求項１ないし３のいずれかに記載の事例構築装置。
【請求項５】
或る業務についての事故の事例についての事例データを記録し、当該事例データを知識としてデータベースに構築する事例構築装置の事例構築方法であって、
（ａ）事故の内容と事故が発生したときの処置の内容と事故が発生したときに使用していた物の名称とを含む事故情報を少なくとも含む事例情報を記憶し、
（ｂ）前記ステップ（ａ）によって記憶された複数の事例情報のうち、事故の内容が一致する事例情報をグループ化し、
（ｃ）前記ステップ（ｂ）によってグループ化された複数の事例情報の中で、前記事故が発生したときの処置の内容または前記事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在するか否かを判断し、
（ｄ）前記ステップ（ｃ）によって前記事故が発生したときの処置の内容または前記事故が発生したときに使用していた物の名称が少なくとも類似する事例情報が存在することが判断されたとき、前記グループ化した事例情報を１つにまとめて新規の事例情報を作成し、そして
（ｅ）前記ステップ（ｄ）によって作成された新規の事例情報を前記データベースに登録する、事例構築方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２００９−２１１２３８（Ｐ２００９−２１１２３８Ａ）
【公開日】平成２１年９月１７日（２００９．９．１７）
【国際特許分類】
【出願番号】特願２００８−５１５３６（Ｐ２００８−５１５３６）
【出願日】平成２０年３月３日（２００８．３．３）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成１９年度独立行政法人情報通信研究機構「民間基盤技術研究促進制度／日常行動・状況理解に基づく知識共有システムの研究開発」、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（３９３０３１５８６）株式会社国際電気通信基礎技術研究所 (905)
【Ｆターム（参考）】
【公開日】平成２１年９月１７日（２００９．９．１７）
【国際特許分類】
【出願日】平成２０年３月３日（２００８．３．３）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成１９年度独立行政法人情報通信研究機構「民間基盤技術研究促進制度／日常行動・状況理解に基づく知識共有システムの研究開発」、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（３９３０３１５８６）株式会社国際電気通信基礎技術研究所 (905)
【Ｆターム（参考）】
[ Back to top ]