JP4191561B2 - 医療支援システム - Google Patents

Description

本発明は、医療事故防止のための医療支援システムに関する。

従来より、所定形式の看護業務スケジュール表がナースの看護業務管理に広く用いられている。当該看護業務スケジュール表は、看護業務に先立って事前に作成される。また、当該看護業務スケジュール表には、看護対象の患者を特定する情報、看護を担当するナース、看護業務内容および看護時間帯などの看護業務情報が含まれている。そして、ナースの業務ルーチンとしては、当該看護業務スケジュールにしたがって看護業務を遂行し、当該看護業務を完了すると所定形式の看護業務完了報告を作成して保管するという業務ルーチンが定められることが多い。なお、ここでいう「ナース」は、看護婦や看護士などの看護業務従事者を総称した呼称である。

一方、近年の医療技術の高度化および複雑化により、医療現場の環境が変化している。これにともない、ナースの看護業務も多様化しており、これまでになかった看護業務も行われるようになりつつある。さらに、入院期間の短縮により看護対象の患者が頻繁に入れ替わったり、昼夜を通して同様の医療が継続されるという状況も発生している。また、週休２日制や交代勤務の導入などのナースの勤務形態の変化により、ひとりのナースがひとりの患者の看護を継続して担当することが困難になっている。さらに、ひとりのナースが一連の看護業務を一貫して担当することが従来は多かったが、看護業務の効率化のため看護業務の分業も不可避となりつつある。

このような医療現場の環境の変化により、医療現場では人為的なミスによる医療事故の潜在的リスクが高まっていると考えられる。実際に、このような医療現場の環境の変化が遠因と思われる医療事故の報道も散見されるようになってきている。

そこで、看護業務管理をシステム化して、看護業務から人為的なミスを排除する試みも行われるようになってきている。たとえば、特許文献１や特許文献２には、ナースに携帯情報端末を所持させて看護業務管理を行う技術が開示されている。

また、医療事故の傾向を分析して医療事故防止に活用する試みも行われている。たとえば、特許文献３には、医療過誤を洗い出してデータベース化する技術が開示されている。

また、看護業務のやり方そのものへの工夫も行われている。たとえば、特許文献４には、医学知識に基づいて全ての医療行為をルール化し、医療事故防止のための警告を発する技術が開示されている。

特開２００２−３５１９７６号公報 特開２００２−８３０６５号公報 特開２００２−１３２９５５号公報 特開１１−２４２７０２号公報

これらの技術は、限られた条件下では医療事故の潜在的リスク低減に確かに有効である。しかし、これらの技術では、ナースが医療現場で実際に体験したインシデント（医療事故の前触れ）をフィードバックしてインシデント防止のための情報をナースに略リアルタイムで提供しないために、これらの技術の運用実態が医療現場の実情から乖離してしまうこも多かった。また、これらの技術では、近年の目覚しい医療技術の進歩にともなうインシデント傾向の経時的な変化も考慮されない。このため、これらの技術が一時的に医療事故の潜在的リスク低減に役立つことがあっても、時間が経過するにつれてその有効性が低下してしまうことも多かった。

本発明は、これらの問題点を解決するためになされたもので、医療現場で実際に発生するインシデントを考慮して、ナースなどの医療従事者に略リアルタイムにインシデント防止のための情報を提供するとともに、医療現場の環境変化にともなうインシデント傾向の経時的な変化にも対応可能な医療支援システムを提供することを目的とする。

上記課題を解決するため、請求項１の発明は、医療支援システムであって、医療従事者によって実際に実行された実行済医療行為に関する実行済医療行為情報と、前記実行済医療行為によって実際に発生したインシデント事例に関するインシデント事例情報とを含むインシデント報告を取得する手段と、前記インシデント報告をインシデントデータ群として格納するデータストアと、所定の生成規則に基づいて、医療行為に関する医療行為情報から、前記医療行為に対応したインシデント防止情報を生成するインシデント防止情報生成手段と、一の前記実行済医療行為情報と一の前記インシデント事例情報との個別の対応をあらわす論理経路を解析する論理解析手段と、複数の医療行為と複数のインシデントとの一般的な関係を前記インシデントデータ群の具体的データ内容とは独立して表現した論理モデルを保持する論理モデル保持手段と、前記論理モデルに基づいて前記生成規則を更新する生成規則更新手段とを備え、前記インシデント報告が新たに取得されるごとに、新たなインシデント報告を前記インシデントデータ群に追加するとともに、前記論理解析手段が、当該新たなインシデント報告と、既に蓄積されている過去のインシデント報告とのうち少なくとも前者に対応する論理経路の解析を行うことによって、解析した論理経路に対応する医療行為とインシデントとの関係を強化するように前記論理モデルを更新することを特徴とする。
請求項２の発明は、請求項１に記載の医療支援システムにおいて、前記インシデントデータ群のデータ構造を保持する構造保持手段と、前記論理モデルに基づいて、前記データ構造を更新する構造更新手段とをさらに備えることを特徴とする。

また、請求項３の発明は、請求項１又は請求項２に記載の医療支援システムにおいて、前記データストアが、前記インシデントデータ群に加えて、医療従事者に与えられる医療指示の情報を含む医療指示データ群を格納するとともに、医療従事者の位置情報を取得する位置情報取得手段と、前記医療指示データ群と前記位置情報とから、前記実行済医療行為を特定する特定手段と、前記位置情報から特定された前記実行済医療行為に関する実行済医療行為情報を利用して、前記インシデント事例情報を入力する入力手段とをさらに備え、前記インシデント報告が、前記実行済医療行為情報と前記インシデント事例情報とから生成されることを特徴とする。

また、請求項４の発明は、請求項１又は請求項２に記載の医療支援システムにおいて、医療従事者に与えられる医療指示の情報を含む医療指示データ群を格納するデータストアと、前記医療指示データ群に基づいて、医療従事者への医療指示を生成する医療指示生成手段と、前記医療指示と前記インシデント防止情報とを同期させて医療従事者に通知する通知手段とをさらに備え、前記インシデント防止情報生成手段は、前記生成規則に基づいて、前記医療指示に係る医療行為に対応したインシデント防止情報を生成することを特徴とする。

また、請求項５の発明は、請求項４に記載の医療支援システムにおいて、医療従事者の位置情報を取得する位置情報取得手段と、前記医療指示データ群と前記位置情報とから、医療従事者によって実際に実行された実行済医療行為を特定する特定手段と、前記実行済医療行為によって実際に発生したインシデント事例に関するインシデント事例情報を入力する入力手段と、前記実行済医療行為に関する実行済医療行為情報と、前記インシデント事例情報とを含むインシデント報告を生成するインシデント報告生成手段とをさらに備えることを特徴とする。

また、請求項６の発明は、請求項１又は請求項２に記載の医療支援システムにおいて、医療従事者によって実際に実行された実行済医療行為によって実際に発生したインシデント事例に関するインシデント事例情報を逐次的に入力する入力手段と、前記入力手段による入力を支援する補助情報を医療従事者へ逐次的に通知する補助情報通知手段と、前記入力手段によって入力された情報に応じて、前記補助情報の具体的内容を変化させる変化手段と、を備えることを特徴とする。

請求項１ないし請求項６の発明によれば、インシデント報告の解析結果がインシデントデータ群とは独立して保持される論理モデルに反映され、さらに当該論理モデルに基づいてインシデント防止情報の生成規則が更新されるので、経時的にインシデント傾向が変化してゆく場合でも、適切なインシデント防止情報を生成可能になる。また、未知の医療行為に対しても、インシデント防止情報を生成可能になる。

請求項４ないし請求項５の発明によれば、医療指示と、当該医療指示に対応したインシデント防止情報とが同期して医療従事者に通知されるので、医療従事者は医療指示に係る医療行為の実行時に配慮すべきインシデントを容易に知ることが可能になる。

請求項３又は請求項５の発明によれば、医療従事者の位置情報から実行中の医療指示が特定されるので、医療従事者がインシデント報告時にマニュアル入力する情報を減少させることが可能になり、医療行為従事中のインシデント報告が容易になる。

請求項６の発明によれば、双方向性のインターフェースによりインシデント事例情報が取得されるので、インシデントの解析に必要な項目をもれなく取得可能になる。

実施の形態に係る医療支援システムは、医療従事者が実際に実行した医療行為の情報と、当該医療行為を実行時に実際に体験したインシデント事例の情報とを蓄積する。そして、当該医療支援システムは、蓄積されたこれらの情報を利用して、医療行為を実行時に発生する可能性が高いインシデントを防止するための情報を医療従事者に提供する。換言すれば、医療支援システムは、過去に発生した既知のインシデント事例から、将来発生するであろう未知のインシデントを予想する。そして、予想されるインシデントを防止するための情報を医療従事者に提供する。当該医療支援システムは、医師、ナース（以下では、看護婦や看護士などの看護業務従事者を総称してナースと呼ぶ）、薬剤師、保健師、助産師、診療放射線技師、臨床検査技師、衛生検査技師、理学療法士および作業療法士などの医療従事者の医療行為全般を適用対象とすることができるが、以下の説明では、医療機関に在籍するナースの入院患者への医療行為（ケアないしは看護）を適用対象とした医療支援システムを例にあげて説明を行う。また、ここでいうインシデントとは、実際の医療事故（アクシデント）に至る可能性がある前触れの出来事を指し、「ヒヤリハット」あるいは「ニアミス」とも呼ばれる。

＜ハードウエア構成＞
実施の形態に係る医療支援システム１のハードウエア構成を、図１のブロック図を参照しながら説明する。

医療支援システム１は、ネットワーク１０上に構成されたクライアント・サーバ型のデータベースシステムを中心に構成されている。医療支援システム１は、サーバとなるデータベースサーバ２０と、クライアントとなるコンピュータ端末３０および携帯情報端末４０とを備える。データベースサーバ２０、コンピュータ端末３０および携帯情報端末４０は、ネットワーク１０によって接続され相互に通信可能である。ネットワーク１０の物理層の構成は制限されないが、医療支援システム１においては、有線ＬＡＮ１１および無線ＬＡＮ１２が混在したネットワーク１０が使用されている。また、通信プロコトルも制限されないが、以下ではＴＣＰ／ＩＰが通信プロトコルとして採用されているとして説明を行う。また、ネットワーク１０においては、ナースによるケアが実行される場所がセルに含まれるように無線ＬＡＮ１２のアクセスポイント１３が医療機関内に設置されている。アクセスポイント１３のタイプも制限されないが、医療支援システム１では、有線ＬＡＮ１１と無線ＬＡＮ１２とを接続するブリッジとして機能するアクセスポイントが採用されている。このため、有線ＬＡＮ１１および無線ＬＡＮ１２の境界ではＩＰアドレスの変換は行われない。そして、データベースサーバ２０、コンピュータ端末３０およびアクセスポイント１３が有線ＬＡＮ１１により接続されている。もちろん、ネットワーク１０全体が無線ＬＡＮによって構成されていてもよく、ネットワーク１０の一部または全部が公衆回線を利用して構成されていてもよい。ただし、携帯情報端末４０は、携帯を容易ならしめるとともにナースへの略リアルタイムの通知を可能とするために、ネットワーク１０へ無線接続可能であることが望ましい。なお、図１においては、無線ＬＡＮ１２のアクセスポイント１３がひとつだけ記されているが、アクセスポイント１３の数は、医療機関の面積や障害物の存在によって適宜増加させるべきものであり、特に制限されない。

さらに、ネットワーク１０の有線ＬＡＮ１１には、外部ネットワークであるインターネット６０との間で通信を行う場合のゲートウェイとなるルータ５０が接続されている。

また、医療支援システム１が適用される医療機関内のケアが実行される領域には、ナースがケアを実行する場所の単位ごと（たとえば、入院患者のベッドごと）に位置を示す電波標識として機能するＲＦＩＤタグ７０が設置されている。ＲＦＩＤタグ７０には、複数のＲＦＩＤタグを識別するために、当該ＲＦＩＤタグ７０が設置された位置の情報（たとえば、ベッド名）が書き込まれており、携帯情報端末４０はこの位置の情報を非接触で読み出し可能である。そして、ＲＦＩＤタグ７０と携帯情報端末４０とは、医療支援システム１における、ナースの位置を特定する手段の要部として機能している。

続いて、図１のブロック図における各ブロックについてより詳細に説明する。

○データベースサーバ；
データベースサーバ２０は、データを格納するデータストアとして機能する記憶媒体を備えたコンピュータである。データベースサーバ２０には、データベース管理システム（ＤＢＭＳ；DataBase Management System）およびミドルウエアがインストールされる。これにより、データベースサーバ２０は、医療支援システム１の中心となるデータベースシステムの本体部として機能する。データベースサーバ２０は、ネットワーク１０を介して得られたコンピュータ端末３０および携帯情報端末４０の指示に応答可能である。データベースサーバ２０は、コンピュータルームなどの病院内の一室に設置されてもよいし、病院外の遠隔地に設置されてもよい。

○コンピュータ端末；
コンピュータ端末３０は、ＣＲＴディスプレイなどの表示装置およびキーボードやポインティングデバイスなどの入力装置を備えたコンピュータである。コンピュータ端末３０には、後述するインシデントレポートの編集用のプログラムがインストールされている。そして、コンピュータ端末３０においては、ＧＵＩ（Graphical User Interface）の所定の操作を行うことにより、後述するテンポラリ格納部に一時的に格納されているインシデントレポートを編集可能となっている。なお、ユーザインターフェースとしては、ＣＵＩ（Character User Interface）等のＧＵＩ以外のユーザインターフェースを採用してもよい。コンピュータ端末３０の設置場所は制限されないが、ナースステーションなどのナースの利便性を考慮した場所に設置することが望ましい。

○携帯情報端末；
携帯情報端末４０は、電池を駆動電源とする携帯が容易な小型コンピュータである。携帯情報端末４０は、アクセスポイント１３を介してネットワーク１０へ無線接続可能な無線ＬＡＮ端末としての機能を有している。また、携帯情報端末４０は、ＲＦＩＤタグ７０のリーダとしての機能を備えている。そして、携帯情報端末４０からの距離が数ｍ以内に設置されたＲＦＩＤタグ７０を検出し、当該ＲＦＩＤタグ７０に書き込まれた位置の情報を読み取り可能である。ナースは、携帯情報端末４０を介してケア指示とインシデント防止情報である警告とを受け取る。また、ナースは携帯情報端末４０を用いて自分が体験したインシデントの報告を行う。

なお、図１においては、携帯情報端末４０がひとつだけ記されているが、実際の医療支援システム１においては携帯情報端末４０はナースひとりひとりに貸与されるため、医療支援システム１はナースの人数分の携帯情報端末４０を含んでいる。また、各携帯情報端末４０には、複数の携帯情報端末を識別するための識別アドレスが設定される。医療支援システム１においては、この識別アドレスとして、ＴＣＰ／ＩＰにおけるＩＰアドレスを使用する。ただし、識別アドレスはＩＰアドレスに制限されず、他の論理的なアドレスや、ＭＡＣアドレスなどのハードウエアに与えられた物理的なアドレスも使用可能である。

続いて、携帯情報端末４０のより詳細な構成を図２の外観図および図３のブロック図を参照しながら説明する。

図２の外観図は、携帯情報端末４０を正面から見た正面図である。図２に示すように、略直方体形状の携帯情報端末４０の前面には、ＧＵＩによる操作を実行するための液晶ディスプレイ４１およびボタン群４２が設けられている。液晶ディスプレイ４１には、データベースサーバ２０から送信されたケア指示を閲覧するための画面や、体験したインシデントを報告するための画面が表示される。また、ボタン群４２は、４連スイッチ４３、実行ボタン４４およびインシデント報告ボタン４５を含んでいる。４連スイッチ４３は、液晶ディスプレイ４１上に表示されたカーソルを上下左右に移動させる４つのボタン４３Ｕ，４３Ｄ，４３Ｌおよび４３Ｒからなる。また、実行ボタン４４は、液晶ディスプレイ４１上に表示されたカーソルによる選択を確定するために設けられている。また、インシデント報告ボタン４５は、携帯情報端末４０でインシデント報告プログラムを起動するために設けられている。図２の携帯情報端末４０では、ボタン群４２はメカニカルスイッチとして提供されているが、液晶ディスプレイ４１にタッチパネルを設置して、液晶ディスプレイ４１上に表示された仮想的なボタンとしてこれらのボタン群４２が提供されてもよい。

次に、携帯情報端末４０の内部構成を図３のブロック図を参照しながら説明する。携帯情報端末４０は、小型コンピュータとしての機能を実現するためのコンピュータ本体部４６と、コンピュータ本体部４６をネットワーク１０へ無線接続するための無線ＬＡＮインターフェース４７と、読み取り可能範囲内に存在するＲＦＩＤタグ７０との間でデータの送受信を行うＲＦＩＤタグリーダ４８とを備える。コンピュータ本体部４６は、無線ＬＡＮインターフェース４７およびＲＦＩＤタグリーダ４８と接続されている。これにより、携帯情報端末４０は、ネットワーク１０への接続およびＲＦＩＤタグ７０の読み取りが可能となっている。

○ＲＦＩＤタグ；
ＲＦＩＤタグ７０は、駆動電源を内蔵しておらず、携帯情報端末４０から送信される所定の周波数の電磁波の電磁エネルギーの一部を利用して内蔵ＩＣチップの駆動を行う。また、ＲＦＩＤタグ７０は、携帯情報端末４０との間で電磁波を利用した非接触によるデータの送受信が可能となっている。

＜データ群＞
医療支援システム１では、ナースからのインシデント報告を解析し、ケア指示（看護指示、より一般的には医療指示）とインシデント防止のための警告とをナースへ通知するため、以下の６種類のデータ群を利用している。すなわち、医療支援システム１は、
（１）ナースに与えられるケア指示の情報（予定）と、ケア指示の実行結果に関する情報（結果）とを含むケアフローデータ群；
（２）ナースが実際に実行したケアの情報と、当該ケアを実行時にナースが体験したインシデント事例の情報とを含むインシデントデータ群；
（３）インシデントを防止するための警告の情報を含む警告データ群；
（４）ナースの属性情報を含むナース属性データ群；
（５）患者の属性情報を含む患者属性データ群；および
（６）ナースが実行するケアの内容と、インシデントの内容および原因とをカテゴリに分けてリストアップしたカテゴリデータ群；
の６種類のデータ群を利用している。これらのデータ群は、ＸＭＬ（eXtensible Markup Language）で記述され、データベースサーバ２０の記憶媒体（データストア）に格納される。これらのＸＭＬ文書は、データストアに格納されているケアフローデータ構造モデル、インシデントデータ構造モデル、警告データ構造モデル、ナース属性データ構造モデル、患者属性データ構造モデルおよびカテゴリデータ構造モデルで定義されているデータ構造を有している。

以下では、これらの６種類のデータ群およびデータ構造について、順次説明する。

○ケアフローデータ群；
ケアフローデータ群を記述するＸＭＬ文書のデータ構造を表現した階層構造ツリー１００の一例を図４に示す。図４の階層構造ツリー１００のノード（矩形の枠で囲まれた文字列部分、以下同様）はＸＭＬ文書における要素に対応しており、末端のリーフ（矩形の枠で囲まれない文字列部分、以下同様）はＸＭＬ文書における要素内容に対応している。この点は、図５〜図９および図１４においても同様である。

階層構造ツリー１００のルートには、ルートノードとして「ケアフロー」ノード１０１が設けられている。この「ケアフロー」ノード１０１から分岐して全てのケア指示の情報と、ケア指示の実行結果に関する情報とが記述される。

「ケアフロー」ノード１０１からは、「医療花子」および「医療太郎」という患者氏名ノード１０２ａ〜１０２ｂが分岐している。なお、図４の階層構造ツリー１００ではふたつの患者氏名ノード１０２ａ〜１０２ｂが記されているが、実際の階層構造ツリー１００では患者の人数分の患者氏名ノードが「ケアフロー」ノード１０１から分岐している。これらの患者氏名ノードのさらに下の階層のデータ構造は各患者氏名ノードで共通しているので、以下では「医療太郎」の患者氏名ノード１０２ｂを例として、階層構造ツリー１００のデータ構造を説明する。

「医療太郎」の患者氏名ノード１０２ｂからは、「ケア００１」および「ケア００２」というケアノード１０３ａ〜１０３ｂ、および「担当ナース氏名」という「医療太郎」のケアを主に担当するナースの氏名を記述するためのノード１０３ｃが分岐している。なお、図４の階層構造ツリー１００ではふたつのケアノード１０３ａ〜１０３ｂが記されているが、ひとつのケアノードはひとつのケアの単位に対応しているので、実際の階層構造ツリー１００のケアノードの数はふたつに限られない。

さらに、「ケア００２」のケアノード１０３ｂに注目してさらに下の階層の説明を行う。「ケア００２」のケアノード１０３ｂからは、「ケア予定日」、「ケア予定時間帯」、「ケアカテゴリ」、「ケア内容詳細」、「ケア予定ナース氏名」および「ケア実行ナース氏名」というケアの情報を記述するためのノード１０４ａ〜１０４ｆが分岐している。これらのノードのさらに下の階層のリーフ１０５ａ〜１０５ｆには、具体的なケアの情報が記述される。たとえば、階層構造ツリー１００においては、具体的なケアの情報として、「２００３年４月１７日」、「午前６時−午前９時」、「注射」、「１０単位の薬剤Ａを上腕に筋肉注射して下さい」、「看護順子」および「看護知子」が記述されている。

ここで、「ケア予定日」および「ケア予定時間帯」のさらに下の階層のリーフ１０５ａ〜１０５ｂには、「ケア００２」のケアノード１０３ｂに係るケア（以下では、「ケア００２」と略記する）の実行予定日および実行予定時間帯が記述される。また、「ケアカテゴリ」のさらに下の階層のリーフ１０５ｃには、カテゴリデータ群にケアカテゴリとしてリストアップされた中から選択されたカテゴリが記述される。「ケア内容詳細」のさらに下の階層のリーフ１０５ｄには、「ケアカテゴリ」の内容を補う情報が記述される。「ケア内容詳細」は、ケアノードごとに固有の内容を有している。また、「ケア予定ナース氏名」のさらに下の階層のリーフ１０５ｅには、「ケア００２」を担当する予定のナースの氏名が記述される。さらに、「ケア実行ナース氏名」のさらに下の階層のリーフ１０５ｆには、「ケア００２」を実際に実行したナースの氏名が記述される。なお、「担当ナース氏名」「ケア予定ナース氏名」および「ケア実行ナース氏名」は、一致している場合も一致していない場合もありうる。また、図４においては、ケア指示の実行結果に関する情報として「ケア実行ナース氏名」のみが記述されているが、ケア指示の実行結果に関する他の情報を含んでいてもよい。たとえば、患者の検温を行った場合、その検温によって得られた患者の体温の情報をケアフローデータ群に記述してもよい。

このようなデータ構造を有するケアフローデータ群を備えることによって、医療支援システム１は、「患者氏名」、「ケア予定日」、「ケア予定時間帯」および「ケア予定ナース氏名」から、「ケアカテゴリ」および「ケア内容詳細」を特定可能である。この特定のための処理は、後述するインシデントレポート生成部で実行され、ナースのインシデント報告の手間の削減に利用される。より具体的には、医療支援システム１は、ナースがインシデントを報告する場合に、「ケアカテゴリ」および「ケア内容詳細」の煩雑なマニュアル入力を省略可能に構成されている。

○インシデントデータ群；
インシデントデータ群を記述するＸＭＬ文書の医療支援システム１の運用開始時点（初期状態）のデータ構造を表現した階層構造ツリー１１０の一例を図５に示す。インシデントデータ構造モデルは、新たに追加されるインシデントデータ（インシデントレポート）の解析結果に基づいて随時更新される。したがって、インシデントデータ構造モデルは不変ではなく動的に変化する。すなわち、階層構造ツリー１１０は、医療支援システム１の運用実績が重ねられるにしたがって動的に変化してゆく。この階層構造ツリー１１０の変化については後述する。

階層構造ツリー１１０のルートには、ルートノードとして「インシデント」ノード１１１が設けられている。この「インシデント」ノード１１１から分岐して、ナースが実際に実行したケアの情報と、当該ケアを実行時にナースが体験したインシデント事例の情報とが記述される。

「インシデント」ノード１１１からは、「看護君子」および「看護順子」というナース氏名ノード１１２ａ〜１１２ｂが分岐している。なお、図５の階層構造ツリー１１０ではふたつのナース氏名ノード１１２ａ〜１１２ｂが記されているが、実際の階層構造ツリー１１０ではナースの人数分のナース氏名ノードが「インシデント」ノード１１１から分岐している。また、これらのナース氏名ノード１１２ａ〜１１２ｂのさらに下の階層のデータ構造は各ナース氏名ノード１１２ａ〜１１２ｂで共通しているので、以下では「看護順子」のナース氏名ノード１１２ｂを例として、階層構造ツリー１１０のデータ構造を説明する。

「看護順子」のナース氏名ノード１１２ｂからは、「看護順子」が体験したインシデントに係る「Ｉ００１」および「Ｉ００２」というインシデントＩＤノード１１３ａ〜１１３ｂが分岐している。なお、図５の階層構造ツリー１１０ではふたつのインシデントＩＤノード１１３ａ〜１１３ｂが記されているが、実際にはインシデントＩＤノードの数はふたつとは限らない。

さらに、「Ｉ００２」のインシデントＩＤノード１１３ｂに注目してさらに下の階層の説明を行う。「Ｉ００２」のインシデントＩＤノード１１３ｂからは、「患者氏名」、「インシデント発生日」、「インシデント発生時間」、「インシデント発生位置」、「ケアカテゴリ」、「ケア内容詳細」、「インシデント内容」、「インシデント原因」および「報告ナース氏名」という、実行した医療行為の情報とインシデント事例の情報とを記述するためのノード１１４ａ〜１１４ｉが分岐している。これらのノードのさらに下の階層のリーフ１１５ａ〜１１５ｉには、実行した医療行為の具体的な情報とインシデント事例の具体的な情報とが記述されている。階層構造ツリー１１０においては、具体的な情報として、「医療太郎」、「２００３年４月１７日」、「０８：３０」、「第３ベッド」、「注射」、「１０単位の薬剤Ａを上腕に筋肉注射して下さい」、「薬剤種類間違い」、「薬剤容器類似」および「看護順子」が記述されている。

「患者氏名」、「インシデント発生日」、「インシデント発生時間」および「インシデント発生位置」のさらに下の階層のリーフ１１５ａ〜１１５ｄには、インシデントが発生したケアの対象の患者の氏名、インシデントの発生日、インシデントの発生時間およびインシデントの発生位置が記述される。発生位置は、ＲＦＩＤタグ７０が設置される位置の単位であるベッド名で表現される。「ケアカテゴリ」および「ケア内容詳細」のさらに下の階層のリーフ１１５ｅ〜１１５ｆの記述内容は、ケアフローデータ群と同様である。「インシデント内容」および「インシデント原因」のさらに下の階層のリーフ１１５ｇ〜１１５ｈには、カテゴリデータ群にリストアップされた中から選択されたカテゴリが記述される。これらの記述内容は、後述するインシデントレポート生成部で生成され、トランスレータによってインシデントデータ構造モデルで定義されるデータ構造に変換された後にインシデントデータ群に追加される。「報告ナース氏名」のさらに下の階層のリーフ１１５ｉには、インシデントを報告したナースの氏名が記述される。なお、医療支援システム１においては、インシデント体験者の自己申告によるインシデント報告と、インシデント目撃者によるインシデント報告との両方が行われるので、「報告ナース氏名」はインシデント体験者本人であるとは限らない。

上述のインシデントデータ群においては、「看護君子」「看護順子」等のナースの具体的氏名が記述される態様を例示した。しかし、インシデント報告に関係した者の具体的氏名が明らかになることによって職場における人間関係などに障害が発生することを懸念して、インシデントが秘匿されてしまうことを防止するために、インシデントデータを暗号化することや、ナースの具体的氏名に替えて異なるナースを単に識別するための符号を使用することも許容される。

また、ナースから報告された１次的な情報がそのままインシデントデータとして使用される態様をここでは例示したが、リスクマネージャ等の管理者が内容の補充、内容の訂正および匿名化処理等を行った２次的な情報をインシデントデータとして使用する態様であってもよい。

ここで、インシデントが特定のナースによって集中的に引き起こされていれば、ルートノードのひとつ下の階層がナース氏名（すなわち、インシデントの最上位の分類基準がナース氏名）である階層構造ツリー１１０で表現されるインシデントデータ構造は、実際に発生するインシデントの傾向を反映しているといえる。この場合、階層構造ツリー１１０の狭い範囲にインシデントＩＤノードが集中するので、効率的なデータベース検索を実行可能である。より一般的にいえば、インシデントデータ構造モデルが、実際に発生するインシデントの傾向を反映していれば、階層構造ツリー１１０の狭い範囲にインシデントＩＤノードが集中するので、効率的なデータベース検索を実行可能になる。

しかし、インシデントデータ構造モデルが、実際に発生するインシデントの傾向を反映していなければ、階層構造ツリー１１０の広い範囲にインシデントＩＤノードが分散し、データベース検索の効率は低下する。たとえば、インシデントが特定の「ケアカテゴリ」に集中して発生しているにもかかわらず、「ケアカテゴリ」がインシデント分類の上位の分類基準となっていなければ、階層構造ツリー１１０の広い範囲にインシデントＩＤノードが分散し、データベース検索の効率は低下する。さらに、インシデント発生の支配的要因がインシデントデータ群構造モデルの分類基準として含まれていなければ、データベース検索の効率が低下するのみならず、意味のある検索出力を行うことさえ不可能になる。たとえば、インシデント発生の支配的要因が時間帯であるような場合に、図５の階層構造ツリー１１０で表現されるインシデントデータ構造に時間帯の情報が含まれていなければ、有効なデータベース検索を実行することはできない。

そこで、医療支援システム１においては、データベース検索効率を高い水準に維持するために、後述するリストラクチャエンジンによるインシデントデータ構造モデルの更新が医療支援システム１の運用中に随時行われる。したがって、階層構造ツリー１１０で表現されるインシデントデータ構造は動的に変化してゆく。このインシデントデータ構造の変化については後述する。このような変化によって、インシデントの傾向が経時的に変化しても（たとえば、医療技術の進歩により新しいケアが導入され、従来は起こらなかったようなインシデントがだんだん増加しても）、医療支援システム１は有効に機能することになる。あるいは、医療支援システム１の構築時にインシデント発生要因を十分に解析できていない場合でも、医療支援システム１は有効性を向上させてゆくことができる。

○警告データ群；
警告データ群を記述するＸＭＬ文書のデータ構造を表現した階層構造ツリー１２０の一例を図６に示す。警告データ群には、インシデントと、当該インシデントを防止するための警告との関係の情報が記述される。

階層構造ツリー１２０のルートには、ルートノードとして「警告」ノード１２１が設けられている。この「警告」ノード１２１から分岐して、インシデントと、当該インシデントを防止するための警告との関係の情報が記述される。

「警告」ノード１２１からは、複数の「インシデント内容カテゴリ」ノード１２２ａ〜１２２ｃが分岐している。これらの「インシデント内容カテゴリ」ノード１２２ａ〜１２２ｃは、「カテゴリ」という属性名の異なる属性値（「薬剤種類間違い」「薬剤量間違い」および「患者間違い」；後述するカテゴリデータ群のインシデント内容カテゴリ名と一致している）によって区別されている。各「インシデント内容カテゴリ」ノード１２２ａ〜１２２ｃのさらに下の階層のリーフ１２３ａ〜１２３ｃには、当該インシデント内容カテゴリの属性値で表現されたインシデント内容に対する、具体的な警告の情報が表示される。たとえば、「薬剤種類間違い」という属性値を有するインシデント内容カテゴリのさらに下の階層のリーフ１２３ａには、「薬剤種類間違いが多くなっています。注意して下さい」という情報が記述されている。「薬剤種類間違いが多くなっています。注意して下さい」という情報は、ケア実行時に発生可能性が高いインシデントとして「薬剤種類間違い」が特定された場合に、当該ケアの指示とともにナースに通知される（詳細は後述）。なお、上述した例では、インシデント内容カテゴリごとに対応する警告を定めたが、インシデント原因なども考慮したより詳細な警告を定めてもよい。

○ナース属性データ群；
ナース属性データ群を記述するＸＭＬ文書のデータ構造を表現した階層構造ツリー１３０の一例を図７に示す。

階層構造ツリー１３０のルートには、ルートノードとして「ナース属性」ノード１３１が設けられている。この「ナース属性」ノード１３１から分岐して全てのナースの属性情報が記述される。

「ナース属性」ノード１３１からは、「看護君子」および「看護順子」というナース氏名ノード１３２ａ〜１３２ｂが分岐している。インシデントデータ群と同様に、ナース氏名ノードの数はふたつとは限らない。また、これらのナース氏名ノード１３２ａ〜１３２ｂのさらに下の階層のデータ構造は各ナース氏名ノード１３２ａ〜１３２ｂで共通しているので、以下では「看護順子」のナース氏名ノード１３２ｂを例として、階層構造ツリー１３０のデータ構造を説明する。

「看護順子」のナース氏名ノード１３２ｂからは、「診療科」、「経験情報」、「適正診断テスト結果」、「資格種別」および「ＩＰアドレス」というナースの属性情報を記述するためのノード１３３ａ〜１３３ｅが設けられている。これらのノードのさらに下の階層のリーフ１３４ａ〜１３４ｅには、具体的なナースの属性情報が記述されている。たとえば、階層構造ツリー１３０においては、具体的なナースの属性情報として、「外科」、「経験年数＝”５年”，手術経験＝”有”，診療科歴＝”内科””外科”，役職歴＝”無”」、「適正Ａ」、「正看護師」および「192.168.0.125」が記述されている。

ここで、「診療科」、「経験情報」、「適正診断テスト結果」および「資格種別」のさらに下の階層のリーフ１３４ａ〜１３４ｄには、ナースが所属する診療科、ナースの業務経験情報、適正診断テストの結果および看護師資格の種別（正看護師または準看護師）というナースの属人的な情報が記述される。一方、「ＩＰアドレス」のさらに下の階層のリーフ１３４ｅには、「看護順子」という氏名のナースに配布されている携帯情報端末４０に設定されたＩＰアドレスが記述される。後述するインシデントレポート生成部は、インシデント報告を行ったナース氏名をこのＩＰアドレスから特定する。これにより、ナースはインシデント報告時に氏名の入力を省略可能である。

ただし、ＩＰアドレスを用いて携帯情報端末４０とナースとを１対１に対応づけることは必ずしも必須ではない。たとえば、携帯情報端末４０の使用開始時にナースが認証手続を行ってデータベースサーバ２０にログインすることによって、インシデント報告を行ったナースを特定できるようにしてもよい。この場合、一台の携帯情報端末を複数のナースで共用することも可能になる。

このようなナース属性データは、後述するリアライゼーションストアでインシデントとナース属性との関係を解析する場合に使用される。すなわち、医療支援システム１は、複数のデータ体系を参照しながら解析を行うことが可能に構成されている。

○患者属性データ群；
患者属性データを記述するＸＭＬ文書のデータ構造を表現した階層構造ツリー１４０の一例を図８に示す。

階層構造ツリー１４０のルートには、ルートノードとして「患者属性」ノード１４１が設けられている。この「患者属性」ノード１４１から分岐して全ての患者の属性情報が記述される。

「患者属性」ノード１４１からは、「医療花子」および「医療太郎」という患者氏名ノード１４２ａ〜１４２ｂが分岐している。ケアフローデータ群と同様に、患者氏名ノードの数はふたつとは限らない。また、これらの患者氏名ノード１４２ａ〜１４２ｂのさらに下の階層のデータ構造は各患者氏名ノードで共通であるので、以下では「医療太郎」の患者氏名ノード１４２ｂを例として、階層構造ツリー１４０のデータ構造を説明する。

「医療太郎」の患者氏名ノード１４２ｂからは、「位置」という患者の位置情報を記述するためのノード１４３ａが分岐している。このノードのさらに下の階層のリーフ１４４ａには、具体的な患者の位置情報が記述される。階層構造ツリー１４０においては、具体的な患者の位置情報として「第３ベッド」が記述されている。さらに、「医療太郎」の患者氏名ノード１４２ｂからは、「病歴」および「アレルギー」という、患者の病歴およびアレルギーを記述するためのノード１４３ｂ〜１４３ｃが分岐している。階層構造ツリー１４０においては、これらのノードのさらに下の階層のリーフ１４４ｂ〜１４４ｃには、具体的な患者の病歴およびアレルギーとして、「糖尿病」および「ペニシリンアレルギー」が記述されている。医療支援システム１においては、これらの病歴およびアレルギーに関する情報は、ケア指示生成部２５０がケア指示を生成する場合に参照され、患者に対して不適当なケアが実行されないようになっている。たとえば、ペニシリンアレルギーの患者にペニシリンが注射されたりすることがないように構成されている。

このような患者属性データ群により、各患者氏名はベッドと１対１に対応させられている。この患者属性データ群は、ナースがインシデント報告を行う場合に患者氏名の入力を省略するため、および実行中のケアを特定するために使用される。

○カテゴリデータ群；
カテゴリデータ群を記述するＸＭＬ文書のデータ構造を表現した階層構造ツリー１５０の一例を図９に示す。

階層構造ツリー１５０のルートには、ルートノードとして「カテゴリ」ノード１５１が設けられている。この「カテゴリ」ノード１５１から分岐して全てのカテゴリの情報が記述される。

「カテゴリ」ノード１５１からは、複数の「ケアカテゴリ」ノード１５２ａ〜１５２ｂが分岐している。これらの「ケアカテゴリ」ノード１５２ａ〜１５２ｂは、「カテゴリ」という属性名の異なる属性値（「検査」および「注射」）によって区別されている。ここでは、属性値が「注射」という「ケアカテゴリ」ノード１５２ｂに注目して、さらに下の階層の構造について説明する。

属性値が「注射」という「ケアカテゴリ」ノード１５２ｂからは複数の「インシデント内容」ノード１５３ａ〜１５３ｃが分岐している。これらの「インシデント内容」ノード１５３ａ〜１５３ｃは、「内容」という属性名の異なる属性値（「薬剤種類間違い」「薬剤量間違い」および「患者間違い」）によって区別されている。さらに、属性値が「薬剤種類間違い」という「インシデント内容」ノード１５３ａからは、複数の「原因」ノード１５４ａ〜１５４ｃが分岐している。これらの「原因」ノード１５４ａ〜１５４ｃのさらに下の階層のリーフ１５５ａ〜１５５ｃには、「薬剤種類間違い」というインシデントの具体的原因（「薬剤容器類似」「薬剤色類似」および「指示誤解」）が記述されている。同様にして、属性値が「薬剤量間違い」という「インシデント内容」ノード１５３ｂからは、「単位誤解」および「指示誤解」が記述されたリーフ１５５ｄ〜１５５ｅをさらに下の階層に有する「原因」ノード１５４ｄ〜１５４ｅが設けられる。また、属性値が「患者間違い」という「インシデント内容」ノード１５３ｃからは、「患者名確認不充分」が記述されたリーフ１５５ｆをさらに下の階層に有するノード１５４ｆが設けられる。

階層構造ツリー１５０のこのような構造により、様々なケアで想定されるインシデントの内容と原因とが関連付けられてリストアップされることになる。

なお、ここで説明したカテゴリ分類は、説明のために簡略化した例であって、このカテゴリ分類に制限されない。したがって、医療支援システム１が適用される医療機関の個別の事情に合わせて任意に変形可能である。

＜機能構成＞
医療支援システム１の機能構成を図１０の概略機能ブロック図を参照しながら説明する。なお、図１０における各機能ブロックは、医療支援システム１の機能を模式的に表現したものであり、必ずしも各機能ブロックがハードウエアな個別のコンポーネントに対応している必要はない。例えば、図１０における各機能ブロックの機能を、コンピュータにプログラムを実行させることにより実現する場合、当該機能ブロックの各々はハードウエア的に分別されない。

○データストア；
医療支援システム１のデータベース本体部となるデータベースサーバ２０には、データ群２１１を格納するデータストア２１０が設けられる。

医療支援システム１においては、データストア２１０に、先述したケアフローデータ群、インシデントデータ群、警告データ群、ナース属性データ群、患者属性データ群およびカテゴリデータ群の６種類のデータ群２１１が格納される。さらに、データストア２１０には、これらの６種類のデータの構造を規定するデータ構造モデル２１２（ケアフローデータ構造モデル、インシデントデータ構造モデル、警告データ構造モデル、ナース属性データ構造モデル、患者属性データ構造モデルおよびカテゴリデータ構造モデル）も格納されている。

○携帯情報端末；
携帯情報端末４０においては、インシデント報告ボタン４５の押下に応答してインシデント報告プログラムが起動され、インシデント発生信号ＩＨＳがネットワーク１０を介してインシデントレポート生成部２２０へ出力される。インシデント発生信号ＩＨＳは、携帯情報端末４０に設定されているＩＰアドレスと、ＲＦＩＤタグリーダ４８が読み出したＲＦＩＤタグ７０の位置情報とを含んでいる。さらに、携帯情報端末４０は、後述するインシデント内容入力画面およびインシデント原因入力画面でナースが入力したインシデント内容ＩＤＴおよびインシデント原因ＩＯＲをインシデントレポート生成部２２０へ出力する。

また、携帯情報端末４０はケア指示を閲覧するブラウザ端末としての機能を備えており、後述するケア指示画面生成部２６０から入力されたケア指示画面ＣＩＳなどを液晶ディスプレイ４１に視認可能に表示する。

○インシデントレポート生成部；
インシデントレポート生成部２２０は、携帯情報端末４０から入力されるインシデント発生信号ＩＨＳに応答して、所定のデータ構造を有するインシデントレポートＩＲＰの生成を開始する。さらに、インシデントレポート生成部２２０は、生成したインシデントレポートＩＲＰをテンポラリ格納部２３０へ出力する。先述のインシデントデータ群が複数のインシデント事例の情報を含むのに対して、インシデントレポート生成部２２０で生成されるインシデントレポートＩＲＰは、インシデント発生（報告）ごとに生成されるので、特定の１件のインシデント事例の情報のみを含む。インシデントレポートＩＲＰは複数の項目からなる。そして、これらの複数の項目は、生成方法が異なる６種類の情報に分類することができる。以下では、この６種類の情報について説明する。

（１）ナース氏名；
インシデントレポート生成部２２０は、インシデント発生信号ＩＨＳの送信元の携帯情報端末４０をＩＰアドレスで特定する。そして、インシデントレポート生成部２２０は、特定された携帯情報端末４０を所持しているナースの氏名ＮＮをナース属性データから読み出し、インシデントレポートＩＲＰに記述する。

（２）インシデントＩＤ；
インシデントレポート生成部２２０は、インシデント事例を識別するためのインシデントＩＤを生成して、インシデントレポートＩＲＰに記述する。インシデントＩＤは、発生したインシデント事例ごとに与えられるユニークな情報であれば制限されない。たとえば、「Ｉ００２」のようなインシデントが発生した時間順に与えられる自然数（連番）を含む文字列をインシデントＩＤとして使用可能である。

（３）インシデント発生日およびインシデント発生時間；
インシデントレポート生成部２２０は、インシデント発生信号ＩＨＳが入力された日時を、「インシデント発生日」および「インシデント発生時刻」として、インシデントレポートＩＲＰに記述する。

（４）インシデント発生位置；
インシデントレポート生成部２２０は、インシデント発生信号ＩＨＳに含まれる携帯情報端末４０の位置情報（携帯情報端末４０を携帯するナースの位置情報）をインシデント発生位置としてインシデントレポートＩＲＰに記述する。

（５）患者氏名、ケアカテゴリおよびケア内容詳細；
インシデントレポート生成部２２０は、上述のナース氏名、インシデント発生日、インシデント発生時間およびインシデント発生位置の情報を用いて患者属性データ群およびケアフローデータ群に対して検索を行い、患者氏名ＰＮ、ナースが実行していたケアのケアカテゴリＣＣＡおよびケア内容詳細ＣＤＴを特定する。さらに特定したこれらの情報をインシデントレポートＩＲＰに記述する。

（６）インシデント内容ＩＤＴおよびインシデント原因ＩＯＲ；
インシデントレポート生成部２２０は携帯情報端末４０を用いてナースによって入力されたインシデント内容ＩＤＴおよびインシデント原因ＩＯＲをインシデントレポートＩＲＰに記述する。

なお、上述のインシデントレポートＩＲＰに含まれる情報は一例であって、これに制限されない。すなわち、インシデントの解析に使用する他の情報をインシデントレポートＩＲＰに適宜追加してもよい。

○テンポラリ格納部；
テンポラリ格納部２３０は、インシデントレポート生成部２２０から入力されたインシデントレポートＩＲＰを一時的に格納する。そして、テンポラリ格納部２３０は、インシデントレポートＩＲＰが入力されてから所定時間（ここでは２４時間とする）が経過すると、当該インシデントレポートＩＲＰをトランスレータ２４０へ出力する。さらに、テンポラリ格納部２３０は、インシデントレポートＩＲＰをトランスレータ２４０へ出力後に、一時的に格納していたインシデントレポートＩＲＰを消去する。

○コンピュータ端末；
コンピュータ端末３０は、テンポラリ格納部２３０に一時的に格納されたインシデントレポートＩＲＰを読み出して編集する。

○トランスレータ；
トランスレータ２４０は、テンポラリ格納部２３０から入力されたインシデントレポートＩＲＰをインシデントデータ構造モデルと整合性を有するデータ構造へ変換して、データストア２１０に格納されたインシデントデータ群に追加する。ここで、テンポラリ格納部２３０から入力される（すなわち、インシデントレポート生成部２２０で生成される）インシデントレポートＩＲＰのデータ構造が一定であるのに対して、インシデントデータ構造モデルはリストラクチャエンジン２７０によって随時更新される。そこで、データ構造の変換が適切に行われるようにするために、トランスレータ２４０のデータ構造変換特性もリストラクチャエンジン２７０によって、インシデントデータ構造モデルの更新に同期して更新される。

○ケア指示生成部；
ケア指示生成部２５０は、データストア２１０に格納されたケアフローデータ群からケア指示の情報ＣＩＩを読み出して、ナース別のケア指示データＣＩＤを生成する。生成されたケア指示データＣＩＤは、ケア指示画面生成部２６０およびエクゼキュートコンポジション部２９０のクエリ生成部２９４へ出力される。

○エクゼキュートコンポジション部；
医療支援システム１は、ケア指示を生成するとともに、当該ケア指示を実行する場合に発生する可能性が高いインシデントを特定し、当該インシデントを防止するための警告を生成する。エクゼキュートコンポジション部２９０は、医療支援システム１のこの警告生成機能を実現するため、以下に列記する検索用のクエリを生成してクエリエンジンマイニング部２８０へ出力する。すなわち、エクゼキュートコンポジション部２９０は、
（ａ１）インシデントデータ群を対象に検索を行い、ケア指示生成部２５０から入力されたケア指示データＣＩＤに係るケアを実行時に発生する可能性が高いインシデントに関するインシデントデータＩＤをインシデントデータ群から抽出するためのクエリ（以下では、「インシデントクエリＩＱ」と略記する）；および
（ａ２）警告データ群を対象に検索を行い、インシデントデータＩＤ（または後述する重要インシデントデータＩＤ’）に係るインシデントに対応する警告データＡＤを警告データ群から抽出するためのクエリ（以下では、「警告クエリＡＱ」と略記する）；
の２種類のクエリを生成する。

インシデントクエリＩＱおよび警告クエリＡＱの生成は、周知の様々なクエリ生成技術を用いても実現可能である。しかし、周知のクエリ生成技術を用いた場合、
（ｂ１）重要でない多くのノイズ情報（発生可能性が低いインシデントに関するインシデントデータ）が抽出されることが多い；および
（ｂ２）インシデント傾向の経時的な変化に対応して抽出内容を変化させることができない；
という問題がある。すなわち、重要性が低いインシデントデータが抽出される可能性が高くなるので、抽出されたインシデントデータを用いて抽出される警告にも的外れな警告が含まれる可能性が高くなるという問題がある。あるいは、クエリ生成技術に様々な工夫を行って適切な警告を一時的に抽出可能としても、時間が経過してインシデントの傾向が変化すると適切な警告を抽出できなくなるという問題がある。

そこで、医療支援システム１においてはケア（より一般的には医療行為全般）とインシデントとの一般化された関係の情報を含む知識・構造・発見（ＫＳＤ；Knowledge Structure Discovery）モデル３０２（ケアから発生可能性が高いインシデントを推定するための知識）を、（ａ１）のインシデントデータＩＤ（または重要インシデントデータＩＤ’）の抽出に反映させる。その反映させる方法には、大きく分類して、
（ｃ１）インシデントクエリＩＱにＫＳＤモデル３０２を反映させる方法；および
（ｃ２）インシデントクエリＩＱを用いて抽出されたインシデントデータＩＤにＫＳＤモデル３０２を利用したフィルタリングを行う方法（重要インシデントデータＩＤ’の抽出処理）；
のふたつの方法がある。そして、エクゼキュートコンポジション部２９０においては、（ｃ１）および（ｃ２）の両方の方法が組み合わせて使用される。これらの方法およびインシデントデータＩＤから警告データＡＤを生成する方法の組み合わせは、医療支援システム１における警告生成規則の要部を規定している。以下では、これらの（ｃ１）および（ｃ２）の方法について詳細に説明する。なお、（ｃ１）および（ｃ２）の両方の方法を組み合わせて使用することは必ずしも必須ではなく、いずれかひとつのみを使用してもよい。また、ＫＳＤモデル３０２が、発生可能性が高いインシデントに係るインシデントデータＩＤに相当する内容を直接出力可能に構成されている場合は、上述のインシデントデータ群を対象とした検索を省略して、最も発生可能性が高いインシデントをＫＳＤモデル３０２から直接取得してもよい。

（ｃ１）インシデントクエリＩＱにＫＳＤモデル３０２を反映させる方法；
この方法は、重要キーワードをインシデントクエリＩＱに含めることにより、重要性が高いインシデントデータＩＤが抽出されるようにする方法である。ここで、重要キーワードとは、インシデント発生と相関が強い情報またはインシデント発生と因果関係が強い情報であることが、ＫＳＤモデル３０２に知識として内在されている情報を意味する。たとえば、特定の適正診断テスト結果がインシデント発生と強い相関があるという知識がＫＳＤモデル３０２に内在している場合、当該適正診断テスト結果をインシデントクエリＩＱに含めて、当該適性診断テスト結果を有するナースが体験したインシデント事例を優先的に出力されるようにする方法が考えられる。

なお、エクゼキュートコンポジション部２９０は、ケア指示データＣＩＤに含まれる様々な情報（ケアカテゴリＣＣＡ、ケア内容詳細ＣＤＴ、ナース氏名ＮＮおよびケア予定時間帯など）あるいはケア指示データＣＩＤと他のデータ体系（たとえば、ナース属性データ）とを組み合わせて得られる情報（たとえば、ナースの経験年数や適正診断テスト結果）からインシデントクエリＩＱを生成可能である。そして、インシデントクエリＩＱの生成時に検索キーワードとして抽出される情報は、インシデントクエリ構造モデルで定義されている。したがって、インシデントクエリ構造モデル２９１にＫＳＤモデル３０２を反映させれば、上述したようなインシデントクエリＩＱへのＫＳＤモデル３０２の反映が可能になる。そこで、エクゼキュートコンポジション部２９０には、ＫＳＤモデル３０２を参照しつつ、インシデントクエリ構造モデル２９１を更新する更新エンジン２９２が設けられている。このようなインシデントクエリ構造モデル２９１の更新によって、エクゼキュートコンポジション部２９０は、ノイズの少ない高品質の検索出力（インシデントデータ群から抽出されるインシデントデータＩＤ）を取得可能となる。

（ｃ２）インシデントクエリＩＱを用いて抽出されたインシデントデータＩＤにＫＳＤモデル３０２を利用したフィルタリングを行う方法；
エクゼキュートコンポジション部２９０のフィルタリング部２９５では、抽出されたインシデントデータＩＤから、最も発生可能性が高いインシデントに係るインシデントデータを重要インシデントデータＩＤ’として抽出する。この重要インシデントデータＩＤ’が先述した警告クエリＡＱの生成対象となるインシデントデータとなる。重要インシデントデータＩＤ’の抽出処理は、発生可能性が高いインシデントをＫＳＤモデル３０２を参照して特定することにより行われる。なお、インシデントクエリＩＱを用いて抽出されたインシデントデータＩＤが単数である場合は、フィルタリング部２９５におけるフィルタリング処理は行われず、インシデントデータＩＤがそのままクエリ生成部２９４へ出力されることになる。

このように、一般的な知識であるＫＳＤモデル３０２を利用することにより、医療支援システム１は、発生可能性が高いインシデントをより的確に推定可能となる。

なお、上述のインシデントクエリＩＱおよび警告クエリＡＱは、各々インシデントクエリ構造モデル２９１および警告クエリ構造モデル２９３で定義されるクエリ構造を有している。以下では、これらのクエリ構造モデルの一例を説明する。

まず、インシデントクエリ構造モデル２９１の構造を表現するグラフを図１１に示す。インシデントクエリ構造モデル２９１は、ルート要素"root"に"incidentquery-id""query"の予約属性を持つ。"incidentquery-id"には、インシデントクエリＩＱを識別する固有の自然数が記述される。該自然数はインシデントクエリＩＱの作成時に作成され変更されることはない。"query"には、ケア指示生成部２５０から入力されたケア指示データＣＩＤなどから生成されたクエリが記述される。たとえば、図１１のグラフの"query"には、「看護順子」というナース氏名が記述されている。もちろん、このクエリは説明のための一例に過ぎず、実際には入力されたケア指示データＣＩＤに含まれる全ての情報、および当該情報と他のデータ群とを参照して得られる全ての情報をクエリとして採用可能である。

次に、警告クエリ構造モデル２９３の構造を表現するグラフを図１２に示す。警告クエリ構造モデル２９３は、ルート要素"root"に"attentionquery-id""query"の予約属性を持つ。"attentionquery-id"には、警告クエリＡＱを識別する固有の自然数が記述される。該自然数は警告クエリＡＱの作成時に作成され変更されることはない。"query"には、インシデントデータＩＤ（または重要インシデントデータＩＤ’）から生成されたクエリが記述される。たとえば、図１２のには"query"には、「薬剤種類間違い」というインシデント内容ＩＤＴが記述されている。

○クエリエンジンマイニング部；
クエリエンジンマイニング部２８０は、エクゼキュートコンポジション部２９０から入力されたクエリとマッチするデータをデータ群２１１から抽出する。より具体的には、クエリエンジンマイニング部２８０は、インシデントクエリＩＱおよび警告クエリＡＱの末端要素をキーワードとして全文検索を行い、キーワードを含むインシデントデータＩＤおよび警告データＡＤを抽出する。これにより、クエリエンジンマイニング部２８０およびエクゼキュートコンポジション部２９０は、医療支援システム１における警告（インシデント防止情報）を生成する機能を実現する要部となっている。

○ケア指示画面生成部；
ケア指示画面生成部２６０は、ケア指示生成部２５０から入力されたケア指示データＣＩＤおよびエクゼキュートコンポジション部２９０から入力された警告データＡＤを、コンパクトＨＴＭＬ文書などの閲覧に適した形式に変換し、ネットワーク１０を介して、携帯情報端末４０へ出力する。

○リアライゼーションストア；
リアライゼーションストア３００には、ケアから、発生可能性が高いインシデントを導く論理モデルであるＫＳＤモデル３０２が格納されている。ＫＳＤモデル３０２は、インシデントレポートＩＲＰに含まれる既知のケアと既知のインシデント事例との論理経路を解析し、その論理経路の特性を論理モデルとして特定するＫＳＤモデル構築部３０１によって随時更新可能である。すなわち、ＫＳＤモデル構築部３０１は、インシデントレポートＩＲＰに含まれる既知のケアと既知のインシデント事例との相関の分析および因果関係の特定を行い、その特定結果に基づいてＫＳＤモデル３０２を更新する。これにより、リアライゼーションストア３００は、新たになケアの指示が与えられた場合に、特定した相関および因果関係を利用して発生可能性が高いインシデントを推測することが可能になる。

このリアライゼーションストア３００は、単に特定の時点までに得られたケアとインシデントとの相関を計算する統計手段ではなく、時間の経過（インシデントレポートの蓄積）にしたがって進化する動的な学習装置である。したがって、同じインシデントレポートＩＲＰが繰り返し入力された場合でも、単に同じ論理パターンを繰り返し特定するのではなく、繰り返しの回数が増加するにつれて結果予測能力が向上するように構成される。すなわち、継続的に学習を続けることによって、ケアと発生可能性が高いインシデントとの間の意味理解を深めるように構成される。換言すれば、追加学習が可能なように構成される。これにより、リアライゼーションストア３００は論理経路の変化に合わせて論理モデルを少しづつ（すなわち、段階的ないしは連続的に）変化させて、発生可能性が高いインシデントを予測する能力を絶えず維持および向上可能である。この点で、リアライゼーションストア３００は従来から行われていたインシデントレポートＩＲＰの単なる統計的分析とは異なる。

上述の追加学習の結果予測能力への寄与の大きさは、医療支援システム１が適用される医療機関に応じて様々に設計可能である。すなわち、遠い過去よりも近い過去の学習のほうが重要である医療支援システム（たとえば、先端医療による治療を積極的に行っており、新しい医療技術が積極的に導入される医療機関に適用される医療支援システム）の場合は、追加学習の寄与を大きくして古い学習を少しづつ「忘れる」ようにリアライゼーションストア３００を構成する。また、遠い過去および近い過去の学習が同程度に重要である医療支援システム（たとえば、治療方法が確立した傷病への治療を中心に行う医療機関に適用される医療支援システム）の場合は、追加学習の寄与を比較的小さくして、古い学習結果の結果予測能力への寄与を長期間維持できるようにリアライーゼーションストアを構成する。

なお、リアライゼーションストア３００のより詳細な説明は、後述する＜リアライゼーションストアの詳細について＞の欄で行う。

○リストラクチャエンジン；
リストラクチャエンジン２７０は、インシデントデータ構造モデル２９１およびトランスレータ２４０のデータ構造変換特性を最適化するために設けられている。以下では、リストラクチャエンジン２７０の詳細について、図１３の機能ブロック図を参照しながら説明する。

図１３に示すように、リストラクチャエンジン２７０は、構造変化判断部２７１とリファクタリング部２７２とを備える。構造変化判断部２７１は、ＫＳＤモデル３０２とインシデントデータ構造モデル２１３とを対比して、インシデントデータ構造モデル２１３がＫＳＤモデル３０２を反映しているかどうかの判断を行う。さらに、構造変化判断部２７１は、インシデントデータ構造モデル２１３がＫＳＤモデル３０２を反映していない場合に、構造変化指示信号ＳＡＳをリファクタリング部２７２へ出力する。リファクタリング部２７２は、この構造変化指示信号ＳＡＳに応答して、インシデントデータ構造モデル２１３をＫＳＤモデル３０２が反映されたものに更新する。また、リファクタリング部２７２は、トランスレータ２４０のデータ構造変換特性を、更新後のインシデントデータ構造モデル２１３に適合した特性に更新する。

ここで、インシデントデータ構造モデル２１３の変更について、より具体的な例を説明する。

たとえば、インシデントデータ構造モデル２１３が図５の階層構造ツリーで表現される階層構造を有している一方で、ナースによるインシデント発生頻度差はなく、特定のケアカテゴリでインシデントが多発するという知識がＫＳＤモデル３０２に蓄積されている場合、インシデントデータ構造モデル２１３はＫＳＤモデル３０２を反映しているとはいえない。この場合、構造変化判断部２７１から構造変化指示信号ＳＡＳがリファクタリング部２７２へ出力される。そして、リファクタリング部２７２はＫＳＤモデル３０２に蓄積された知見に基づいて、インシデントデータ構造モデル２１３を図１４の階層構造ツリーで表現される形に変化させる。このような変化により、インシデントデータ群のデータ構造は発生するインシデントの傾向を反映したものとなり、警告生成時（インシデントデータ抽出時）のデータ抽出効率を高水準に維持することが可能になる。

なお、先述したエクゼキュートコンポジション部２９０におけるＫＳＤモデル３０２の利用は、データを抽出する方法へのＫＳＤモデル３０２の適用であるのに対して、ここで説明したＫＳＤモデル３０２の利用は、データ抽出の対象となるデータ群のデータ構造へのＫＳＤモデル３０２の適用である。すなわち、医療支援システム１においては、データ抽出の主体および客体の両方に対して、一般的知識であるＫＳＤモデル３０２を反映させることによって、高効率のデータ抽出が可能となっている。

なお、ここで説明したデータ構造変形例は単純化した一例であって、データ構造変更方法はこれに限定されない。たとえば、多数の条件（ナースの経験年数、インシデント発生位置、性格診断テスト結果など）を同時に考慮してもよいし、元々のデータ構造に新たになデータ構造を付加するデータ構造変形を行ってもよい。あるいは、データ中の構造化されていない部分を新たに構造化することも許容される。すなわち、定義されたデータ構造を何らかの形で変更する方法は全て許容される。

＜リアライゼーションストアの詳細について＞
リアライゼーションストア３００における「論理経路」および「論理モデル」についてより具体的に説明する。まず、インシデントレポートＩＲＰに含まれるケアの情報をケアＡ（ｉ）とし、発生したインシデント事例の情報をインシデントＢ（ｉ）とする（ｉ＝１，２，３，・・・，ｎ）とする。このときに、Ａ（ｉ）→Ｂ（ｉ）の各々の対応が「論理経路」に相当する。そして、ｉ＝１，２，３，・・・，ｎの複数の論理経路を包含する一般的な関係（写像）ｆ：ケア群Ａ→インシデント群Ｂが「論理モデル」である。ここで、
ケア群Ａ＝｛Ａ（１），Ａ（２），・・・，Ａ（ｎ）｝、
インシデント群Ｂ＝｛Ｂ（１），Ｂ（２），・・・，Ｂ（ｎ）｝、
である。ケアとインシデントとの対応である「論理経路」は、個別の対応であるから、過去のインシデントレポートＩＲＰで報告されたのとまったく同じケアが与えられた場合しか、対応するインシデントを特定することができない。それに対して、「論理モデル」は、ケアとインシデントとの一般的な関係であるから、過去にまったく同じ条件のケアが存在しない、新たになケアＡ（ｊ）に対応するインシデントＢ（ｊ）を推測するために利用可能である。実際の医療支援システムにおいては、写像ｆは完全に正しい結果を与える場合だけではなく、近似的に正しい結果を与える近似関係をも含むが、インシデント報告数ｎが増加するにしたがって、写像ｆの精度ないしは近似度は向上する。すなわち、医療支援システム１の使用実績が重ねられるにしたがって、リアライゼーションストア３００は発生可能性が高いインシデントを正確に予測可能となる。この意味でリアライゼーションストア３００は、自律的に学習を行う進化するデータベースの中核的な機能を有する。

○追加学習（動的変化）；
上述の写像ｆは経時的に変化可能でもある。すなわち、時間が経過して上述したｎ個のインシデントレポートＩＲＰに、新たに追加されたｋ個のインシデントレポートＩＲＰに係るｋ個のケア群
Ａ’＝｛Ａ（ｎ＋１），Ａ（ｎ＋１），・・・，Ａ（ｎ＋ｋ）｝、
とｋ個のインシデント群
Ｂ’＝｛Ｂ（ｎ＋１），Ｂ（ｎ＋１），・・・，Ｂ（ｎ＋ｋ）｝、
とが追加された場合、写像ｆは、
（１）複数のケア群を結合した集合すなわちケア群Ａ＋Ａ’と、
（２）複数のインシデント群を結合した集合すなわちインシデント群Ｂ＋Ｂ’と、
の関係を反映したものに進化する。このため、写像ｆ’：Ａ’→Ｂ’が写像ｆと異なる場合、写像ｆは写像ｆ’を考慮して修正される。これが、上述した追加学習に相当する。もちろん、写像ｆ’が写像ｆと同じである場合は、写像ｆは修正されない。

ここで、ＫＳＤモデル３０２が追加学習を行う頻度は特に制限されないが、後に詳述するニューラルネットワークをＫＳＤモデル３０２に用いた場合は、インシデントレポートＩＲＰが追加されるたびにＫＳＤモデル３０２に追加学習をさせることが可能である。

○ＫＳＤモデルのインポート、エクスポート
写像ｆすなわちＫＳＤモデル３０２は、インシデントデータ群とは分離して生成される。このため、ＫＳＤモデル３０２は、特定の医療機関（典型的には、病院や、病院内の診療科などのグループ）にのみ適用可能な属組織的なものではなく、拡張利用可能である。より具体的には、ＫＳＤモデル３０２をエクスポートして他の医療支援システムで用いたり、他の医療支援システムで構築されたＫＳＤモデルを医療支援システム１へ導入することが可能である。これらのＫＳＤモデルの移動は、インターネット６０におけるＦＴＰ（File Transfer Protocol）を使用してもよいし、所定のリムーバブル記録メディアを用いて行ってもよい。

また、リアライゼーションストア３００が複数のＫＳＤモデルを保持して、それらのＫＳＤモデルを結合して新たになＫＳＤモデルを構築することも可能である。具体的には、複数の写像ｆ₁，ｆ₂を結合して新たにな写像、たとえば、
線形結合写像：ｃ₁ｆ₁＋ｃ₂ｆ₂、（ｃ₁およびｃ₂は定数）
を作成して利用することも可能である。

このようなＫＳＤモデルの拡張利用により、医療支援システム１の運用実績が少ない医療機関でも、高度に進化したＫＳＤモデルを利用することが可能になる。これにより、適切な警告出力が可能になる。

○ＫＳＤモデルの具体例（ニューラルネットワーク）；
ＫＳＤモデル３０２の構築には様々な態様が考えられるが、ここでは次のような事例をあげて説明する。すなわち、実際に実行されたケアと、当該ケアの実行により実際に発生したインシデント事例との関係をニューラルネットワークに学習させてＫＳＤモデル３０２として蓄積する場合を考える。この場合、インシデントレポート生成部２２０で生成されたインシデントレポートＩＲＰが、テンポラリ格納部２３０およびトランスレータ２４０を介して、リアライゼーションストア３００に出力されてＫＳＤモデル３０２の構築に利用される。この場合、原理的には、ケアカテゴリおよびケア内容詳細に含まれる全ての情報と、インシデントカテゴリおよびインシデント詳細内容に含まれる全ての情報（適正診断テスト結果などの他のデータ群と組み合わせて得られる情報を含む）とを考慮可能であるが、本項では説明を簡潔にするために、ケアの情報として、「看護花子」、「看護順子」および「看護貴子」の３人のナース氏名のみが、インシデントとして「薬剤種類間違い」「薬剤量間違い」および「患者間違い」の３つのインシデントカテゴリのみが含まれる単純なニューラルネットワーク４００を例にあげて説明する。

当該ニューラルネットワークの模式図を図１５に示す。ニューラルネットワーク４００は、構成素子であるニューロンを３個ずつ備える入力層Ｉ、中間層Ｍ、出力層Ｏの３層からなるパーセプトロンである。ここでは、「看護花子」、「看護順子」および「看護貴子」の各ナース氏名をそれぞれ入力Ｘ１，Ｘ２，Ｘ３に対応づける。入力Ｘ１，Ｘ２，Ｘ３は、それぞれ「０」または「１」の値をとり、インシデントを発生させたナースの氏名を「１」で、インシデントを発生させたナース以外の氏名を「０」で表現する。つまり、「看護順子」がインシデントを発生させた当事者である場合は、入力は（Ｘ１，Ｘ２，Ｘ３）＝（０,１,０）となる。同様に、「薬剤種類間違い」「薬剤量間違い」および「患者間違い」の各インシデントカテゴリをそれぞれ、出力Ｙ１，Ｙ２，Ｙ３に対応づける。出力Ｙ１，Ｙ２，Ｙ３は、それぞれ「０」または「１」の値をとり、報告されたインシデントカテゴリを「１」で、報告されたインシデントカテゴリ以外のインシデントカテゴリを「０」で表現する。つまり、「薬剤種類間違い」というカテゴリのインシデントが報告された場合に対応する出力は（Ｙ１，Ｙ２，Ｙ３）＝（１,０,０）となる。

入力（Ｘ１，Ｘ２，Ｘ３）は、それぞれ入力層のニューロンＩ１，Ｉ２，Ｉ３に入力される。また、ニューロンＩ１，Ｉ２，Ｉ３の各出力は中間層のニューロンＭ１，Ｍ２，Ｍ３全てに入力される。さらに続けて、ニューロンＭ１，Ｍ２，Ｍ３の各出力は出力層のニューロンＯ１，Ｏ２，Ｏ３全てに入力される。ニューロンＯ１，Ｏ２，Ｏ３の出力は、それぞれ、出力Ｙ１，Ｙ２，Ｙ３となる。

ここで、ニューロンおよびニューロン間の情報伝達特性について説明する。図１６に示すように、一般にニューロン４１０は入力ｘ₁，ｘ₂，・・・，ｘ_N（本事例ではＮ＝３）に応じて、出力ｙを決定可能である。入力ｘ₁，ｘ₂，・・・，ｘ_Nには、それぞれ、各入力の重みである結合加重ｗ₁，ｗ₂，・・・，ｗ_Nが定められている。ニューロン４１０に入力が与えられた場合、入力ｘ₁，ｘ₂，・・・，ｘ_Nと結合加重ｗ₁，ｗ₂，・・・，ｗ_Nとから算出されるネット値ｕ（数１）および結合関数Ｆ（数２）によって出力ｙが決定される。

数２におけるθは、結合関数Ｆのしきい値である。つまり、ネット値ｕがしきい値θを超えると出力が「０」から「１」へ変化することを示す。なお、上述の結合加重ｗ₁，ｗ₂，・・・，ｗ_Nはニューラルネットワーク４００の学習によって変化する。また、上述の結合関数Ｆは一例であって、医療支援システムの特徴によって様々に変更されうる。

次に、ニューラルネットワーク４００の学習について説明する。ニューラルネットワーク４００は、トランスレータ２４０からリアライゼーションストア３００が取得したインシデントレポートＩＲＰを教師信号として学習を行う。すなわち、ニューラルネットワーク４００において、入力信号ベクトルｖ_i＝（Ｘ１，Ｘ２，Ｘ３）＝（１，０，０）に対するニューラルネットワーク４００の出力信号ベクトルｖ_o＝（Ｙ１，Ｙ２，Ｙ３）＝（０，１，０）が、教師信号となるインシデントベクトルｖ_key＝（Ｙ１’，Ｙ２’，Ｙ３’）＝（１，０，０）に近づくように、ニューロンの結合加重を変化させるプロセスを実行する（これらの関係を図１７に一覧表にして示す）。学習は、たとえば標準デルタ則に基づいて行われる。具体的には、ニューロンＭｊからニューロンＯｉへの学習前の結合加重がＶ_ijであるとき、数３で定められるＶ_ij’をニューロンＭｊからニューロンＯｉへの新たにな結合加重として採用することによって、ニューラルネットワーク４００に学習させる。

ただし、εは正の実数であり、直近の学習の寄与度を示すパラメータである。ａ_jはニューロンＭｊの出力である。

数３より明らかなように、教師信号と出力信号とが等しい場合は、結合加重の変化はなく学習は行われない。ある出力に対応するニューロンの出力信号が「０」で教師信号が「１」の場合は、ニューロンの出力が大きくなるように結合加重が増加させられる。逆に、ある出力に対応するニューロンの出力信号が「１」で教師信号が「０」の場合は、ニューロンの出力が小さくなるように結合加重が減少させられる。これらにより、特定の入力信号に対する出力信号を教師信号に近づけるように結合加重は変化してゆくことになる。

なお、上述の学習プロセスにおいては中間層Ｍの結合加重は変化しないが、実際の医療支援システムにおいては、バックプロパゲーションなどのより高度な学習則により中間層Ｍの結合加重を変化させることもできる。

これらの学習を繰り返すことにより（すなわち、インシデントレポートＩＲＰが多数入力されればされるほど）、リアライゼーションストア３００におけるナース氏名（一般的にはケアに関する情報全般）からインシデント（一般的にはインシデントに関する情報全般）への写像の近似度を向上することが可能である。近似度が向上すれば、新たになケアが入力された場合に、リアライゼーションストア３００は発生する可能性が高いインシデントをより正確に推測可能になる。この推測能力向上は、先述したように、より適切な警告を出力するために使用される。

○ＫＳＤモデルの利用例；
続いて、ニューラルネットワーク４００で表現されたＫＳＤモデル３０２のエクゼキュートコンポジション部２９０における具体的利用例について説明する。

（１）インシデントクエリＩＱにＫＳＤモデル３０２を反映させる方法の一例；
ニューラルネットワーク４００において、特定の入力（ケア）に対して特定の出力（インシデント）が出力されることは、当該ケアと当該インシデントの間に強い相関または因果関係があるという知識がＫＳＤモデル３０２に蓄積されていることに相当する。逆に、ニューラルネットワーク４００において、特定の入力（ケア）に対する出力信号ベクトルとしてゼロベクトルが出力されるということは、当該ケアがインシデント発生とは相関または因果関係がほとんどないという知識がＫＳＤモデル３０２に蓄積されていることに相当する。そこで、このような場合は、インシデントクエリ構造モデル２９１を更新して、前者のケアに関する情報のみをインシデントクエリＩＱのクエリとして採用するようにする。これにより、検索ノイズの少ない高品質のインシデントデータＩＤの抽出が可能になる。

（２）インシデントクエリＩＱを用いて抽出されたインシデントデータＩＤにＫＳＤモデル３０２を利用したフィルタリングを行う方法の一例；
ニューラルネットワーク４００の出力ベクトルの成分値は「０」または「１」のふたつの値のみをとるが、その基準となる出力層のニューロンＯ１，Ｏ２，Ｏ３のネット値は、０以上１以下の連続値をとりうる。そこで、この連続値が、出力層の当該ニューロンに対応するインシデントの起こりやすさに対応しているとみなして、先述のフィルタリングに利用することもできる。より具体的には、エクゼキュートコンポジション部２９０でインシデントデータ群から抽出されたインシデントデータＩＤが複数存在する場合、このネット値が最も大きいインシデントデータを重要インシデントデータＩＤ’として抽出してもよい。

＜携帯情報端末の表示画面と操作＞
医療支援システム１からナースへのケア指示の出力およびナースから医療支援システム１へのインシデントの報告は、ユーザインターフェースとして機能する携帯情報端末４０を用いて行われる。携帯情報端末４０では、ＧＵＩが採用されており、当該ＧＵＩで所定の操作を行うことにより、ナースはケア指示の通知の受け取りおよびインシデントの報告を行う。なお、医療支援システム１においては、携帯情報端末４０によるケア指示の通知と同期して、インシデント防止のための警告がナースに提供される。なお、医療支援システム１においては、インシデントの報告（医療支援システム１によるインシデント事例情報の取得）にあたって会話型のインターフェースが使用される。すなわち、インシデント事例に関する情報を入力するための補助情報が逐次的に医療支援システム１からナースに提供されるとともに、当該補助情報の具体的な内容がナースの逐次的なインシデント事例に関する情報に応じて変化する。このような双方向性の入力支援機能を医療支援システム１が備えることにより、ナースは医療支援システム１におけるインシデント事例の解析に必要な項目をもれなく報告することが可能になる。また、このようなインタラクティブな入力支援機能により、単に要報告項目を列挙してナースに通知する場合と異なり、入力に要する手間を減らすことができる。これにより、ナースはケア業務に影響を与えることなく、インシデント報告を略リアルタイムに実施可能になる。

以下では、携帯情報端末４０の液晶ディスプレイ４１上のＧＵＩの画面表示例を参照しながら、これらのケア指示の通知の受け取り方法およびインシデントの報告方法を説明する。

○ケア指示画面；
液晶ディスプレイ４１に表示されたケア指示画面５００の一例を図１８に示す。ケア指示画面５００の上方には、インシデント防止のための警告（注意事項）５０１が表示される。図１８においては、「薬剤種類間違いが多くなっています。薬剤容器類似に注意して下さい。」という警告５０１がケア指示画面５００に表示されている。このような警告５０１は、ケア指示５０２の通知と同期してケア指示５０２ごとにナースに与えられる。そして、警告の具体的内容は、ナース、ケア指示５０２およびその他の条件（時間帯など）によって異なり、一定ではない。すなわち、ナース、ケア指示５０２およびその他の条件の個別の特性に合わせた警告５０１がケア指示画面５００には表示される。たとえば、同じ「注射」といるケアを実行する場合であっても、薬剤種類を間違える可能性が高いナースと、薬剤量を間違える可能性が高いナースとには別の警告が与えられる。あるいは、特定のナースが同じ「注射」というケアを実行する場合でも、実行する時間帯が異なれば別の警告が与えられる。さらに、ナース、ケア内容およびその他の条件が同じであっても、医療支援システム１の運用を続けるにつれて、表示される警告の具体的内容は動的に変化して行く。このような動的な変化は、インシデントの傾向の経時的な変化を警告の具体的な内容に反映させることにより実現される。

警告５０１の下方には、ケア指示５０２およびチェックリスト５０３が表示される。図１８のケア指示画面５００においては、ケア指示５０２には、ナース氏名、ケア予定日、ケア予定時間帯、患者氏名、位置（ベッド名）およびケア内容（「ケアカテゴリ」および「ケア内容詳細」）が含まれている。また、チェックリスト５０３には、ケア指示を実行する場合にナースが確認すべき項目がリストアップされている。たとえば、図１８においては、「薬剤種類確認」「薬剤量確認」および「患者確認」の３項目がリストアップされている。さらに、各項目の先頭には、チェックボックス５０３ａ〜５０３ｃが表示されている。また、ケア指示画面５００の下方には、「前へ」ボタン５０３、「次へ」ボタン５０５および「完了」ボタン５０４が表示されている。チェックリスト５０３の各項目またはこれらのボタンのいずれかひとつにはカーソルＣＲが重畳表示されている。そして、カーソルＣＲの位置は、４連スイッチ４３の押下によって移動可能である（以後の説明におけるカーソルＣＲも同様）。そして、チェックリスト５０３の「薬剤種類確認」「薬剤量確認」または「患者確認」の項目にカーソルＣＲが重畳表示された状態で実行ボタン４４の押下が行われると、チェックボックス５０３ａ〜５０３ｃの対応部分には確認済であることを示すマークＭが表示される。図１８においては、チェックボックス５０３ａおよび５０３ｂに、このマークＭが表示された状態が示されている。さらに、全チェックボックス５０３ａ〜５０３ｃにマークＭが表示された状態になると、未確認項目が残っていることを示す文字列５０３ｄは消滅する。これにより、ナースが要確認項目の確認を完了するまでは、ケア指示画面５００にはナースに注意を促す文字列５０３ｄが表示され続けることになる。すなわち、ケア指示画面５００は、医療支援システム１からナースにケア指示を通知するのみならず、ナースのケア実行状況に関する情報を随時入力させる双方向性の情報交換が可能なユーザインターフェース画面となっている。なお、このような双方向性の情報のやり取りの方法は上述のヴィジュアルな方法に限定されない。たとえば、携帯情報端末４０に音声言語認識機能および音声通知機能を付与して、音声によってコミュニケーションを行うようにしてもよい。また、「前へ」ボタン５０３または「次へ」ボタン５０５にカーソルＣＲが重畳表示された状態で実行ボタン４４の押下が行われると、ケア指示画面５００には別のケア指示および対応した警告およびチェックリストが表示される。また、「完了」ボタン５０４にカーソルＣＲが重畳表示された状態で実行ボタン４４の押下が行われると、ケア指示画面５００に表示されているケアの完了報告がデータベースサーバ２０へ送信され、ケア指示画面５００には別のケア指示および対応した警告およびチェックリストが表示される。なお、完了報告が行われたケアは、前へボタン５０３および「次へ」ボタン５０５を押下してもケア指示画面５００には表示されない。

○インシデント報告画面；
液晶ディスプレイ４１に表示されたインシデント報告画面の一例を図１９〜図２３に示す。以下では、図１９〜図２３のＧＵＩの画面表示例を表示順序にしたがって説明する。

（１）報告種類選択画面；
まず、インシデント報告ボタン４５をナースが押下すると、図１９の報告内容選択画面５７０が表示される。報告内容選択画面５７０には、「自己申告または目撃情報報告を選択して下さい」という文字列５７１とともに、「自己申告」および「目撃情報報告」という報告種類の一覧が表示される。ここで、「自己申告」とは報告者自身が体験したインシデントの報告を意味し、「目撃情報報告」とは報告者が目撃した自分以外のナースが発生させたインシデントの報告を意味する。

ナースは、「自己申告」および「目撃情報報告」のいずれかをカーソルＣＲで選択して、実行ボタン４４を押下することにより、報告種類を選択可能である。そして、これ以降は、液晶ディスプレイ４１には選択された報告種類に応じた画面が表示されることになる。

（２）ナース選択画面；
報告種類選択画面５７０において「目撃情報報告」が選択された場合、報告種類選択画面５７０に続いて、図２０のナース選択画面５８０が表示される。ナース選択画面５８０には、「インシデント当事者のナースを選択して下さい」という文字列５８１とともにインシデント報告を行うナースから所定範囲内に存在するナースの氏名の一覧が表示される。ここで、「所定範囲」とは、ケアの具体的作業内容を判別可能な範囲であり、たとえば同じ部屋内に設定する。

インシデントを報告するナースは、ナースの氏名の一覧からインシデントを発生させたナースをカーソルＣＲで選択して、実行ボタン４４を押下することにより、報告対象のインシデントを発生させたナースを報告可能である。このような処理により、目撃情報の場合でも自己申告の場合と同等のインシデントレポートＩＲＰを生成可能になる。もちろん、目撃情報の場合と自己申告の場合とで生成されるインシデントレポートＩＲＰ間で整合性を維持する方法はこの方法には限定されない。

（３）ケア内容確認画面；
報告種類選択画面５７０における「自己申告」の選択（インシデントを発生させたのは報告者）、およびナース選択画面５８０におけるナースの氏名の選択に続いて、図２１のケア内容確認画面５１０が表示される。換言すれば、インシデントを発生させたナースが特定されるのに続いて、図２１のケア内容確認画面が表示される。ケア内容確認画面５１０には、ナース氏名、日時、患者の氏名、位置（ベッド名）およびケア内容（「ケアカテゴリ」および「ケア内容詳細」）が表示される。ケア内容確認画面５１０の表示の具体的内容は、携帯情報端末４０からデータベースサーバ２０に送信される携帯情報端末４０の位置情報（すなわち、ナースの位置情報）、インシデント報告ボタン４５が押下された日時およびケアフローデータ群を用いて、インシデントレポート生成部２０で自動的に生成される。したがって、ナースがケアフローデータ群に記述されたケア予定にしたがってケアを実行している場合は、患者の氏名、日時、位置およびケア内容のマニュアル入力を行うことなく、ナースはインシデント報告を実行可能である。すなわち、ケア内容確認画面５１０においては、ナースのインシデント報告を容易ならしめるための補助情報が医療支援システム１からナースに提供されることになる。先述したように、この提供される具体的なケア内容確認画面の内容は、報告種類選択画面５７０およびナース選択画面５８０でのナースの操作（ナースから医療支援システム１への入力情報）に依存して変化する。この点で、ケア内容確認画面５１０は、医療支援システム１における双方向性のインターフェースの一例となっている。

さらに、これらの下方には、「ＯＫ」ボタン５１１および「リセット」ボタン５１２が表示される。ナースは、表示されたこれらの情報が正しい場合はカーソルＣＲを「ＯＫ」ボタン５１２へ移動させて実行ボタン４４を押下する。この場合、ケア内容確認画面５１０に表示された情報が、インシデントレポート生成部２２０でインシデントレポートＩＲＰに記述される。一方、予定外のケアや緊急事態への対応などの理由により、表示されたこれらの情報が正しくない場合は、ナースはカーソルＣＲを「リセット」ボタン５１１へ移動させて実行ボタン４４を押下する。この場合、インシデントレポート生成部２２０で生成されるインシデントレポートＩＲＰの患者の氏名、日時、位置およびケア内容は空データ（ＸＭＬ文書の空要素に対応する）となる。このデータは、コンピュータ端末３０を用いて後から編集可能である。あるいは、携帯情報端末４０にキーボードや手書き入力などの周知の文字入力手段を設けて、携帯情報端末４０から入力可能とすることも許容される。

（４）インシデント内容入力画面；
ケア内容確認画面５１０に続いて、液晶ディスプレイ４１には図２２に例示するインシデント内容入力画面５２０が表示される。インシデント内容入力画面５２０には、「インシデント内容またはスキップを選択して下さい」という文字列５２１とともに、インシデント内容のカテゴリの一覧が表示される。たとえば、図２０においては、「薬剤種類間違い」、「薬剤量間違い」および「患者間違い」というカテゴリに「スキップ」という文字列を含めた一覧５２２が、「インシデント内容またはスキップを選択して下さい」という文字列５２１の下方に表示されている。一覧表示されるカテゴリは、医療支援システム１によって、実行中のケアで想定されるインシデント内容のカテゴリがカテゴリデータ群から読み出され、ネットワーク１０を介して、携帯情報端末４０へ入力されている。したがって、表示されるカテゴリは、先述のケア内容確認画面５１０で表示されたケア内容によって異なる。つまり、インシデント内容入力画面５２０で医療支援システム１からナースに提供される補助情報（インシデント報告を支援するための情報）もまた、それまでのナースの入力内容によって変化しており、ナースおよび医療支援システムの間でインタラクティブな情報のやり取りが実行されていることになる。

ナースは、これらのカテゴリのいずれかひとつをカーソルＣＲで選択して、実行ボタン４４を押下することにより、選択されたカテゴリをインシデント内容ＩＤＴとして報告可能である。一方、予定外のケアや緊急事態への対応などでインシデントが発生したため、表示されたカテゴリに適切なものが含まれていない場合は、スキップへカーソルＣＲを合わせて実行ボタン４４を押下する。この場合、インシデント内容ＩＤＴを空データとしたインデントレポートＩＲＰがインシデントレポート生成部２２０で生成される。

（５）インシデント原因入力画面；
インシデント内容入力画面５２０に続いて、液晶ディスプレイ４１には図２３に例示するインシデント原因入力画面５３０が表示される。インシデント原因入力画面５３０には、「インシデント原因またはスキップを選択して下さい」という文字列５３１とともに、インシデント原因のカテゴリの一覧が表示される。たとえば、図２３においては、「薬剤容器類似」、「薬剤色類似」および「指示誤解」というカテゴリに「スキップ」という文字列を含めた一覧５３２が、「インシデント原因またはスキップを選択して下さい」という文字列５３１の下方に表示されている。一覧表示されるカテゴリは、インシデント内容入力画面で選択したインシデント内容に関連付けられたインシデント原因のカテゴリである。これらのインシデント原因のカテゴリは、カテゴリデータ群から読み出され、ネットワーク１０を介して、携帯情報端末４０へ入力されている。したがって、表示されるインシデント原因のカテゴリは、先述のケア内容確認画面で表示されたケア内容によって異なる。換言すれば、インシデント原因入力画面５３０の具体的表示内容は、インシデント内容入力画面で選択したインシデント内容を反映したものになっており、医療支援システム１におけるインタラクティブなインターフェースの一例となっている。

ナースは、これらのカテゴリのいずれかひとつをカーソルＣＲで選択して、実行ボタン４４を押下することにより、選択されたカテゴリをインシデント原因ＩＯＲとして報告可能である。あるいは、一方、予定外のケアや緊急事態への対応などでインシデントが発生したため、表示されたカテゴリに適切なものが含まれていない場合は、ナースはスキップへカーソルＣＲを合わせて実行ボタン４４を押下する。この場合、インシデント内容ＩＤＴは空データとしたインデントレポートがインシデントレポート生成部２２０で生成される。

＜コンピュータ端末の表示画面と操作＞
インシデント報告、すなわち、ナースから医療支援システム１へのインシデント情報の入力は、原則として携帯情報端末４０を用いて行われる。しかし、上述したように、予定外のケアや緊急事態への対応時にインシデントが発生した場合、ケア内容の自動入力が利用できない場合がある。あるいは、ケア作業が多忙のため、インシデント報告の内容を十分に検討できない場合もある。

このような場合に備えて、医療支援システム１では、いったん作成したインシデントレポートＩＲＰを作成後２４時間が経過するまでは編集可能である。この編集作業は、ナースステーションに設置されたコンピュータ端末３０を用いて行われる。コンピュータ端末３０では、ＧＵＩが採用されており、当該ＧＵＩで所定の操作を行うことにより、ナースはインシデントレポートＩＲＰの編集を行うことができる。

以下では、コンピュータ端末３０のディスプレイ上のＧＵＩの画面表示例を参照しながら、インシデントレポートＩＲＰの編集方法を説明する。

コンピュータ端末３０上でインシデントレポート編集用のプログラムを起動すると、コンピュータ端末３０のディスプレイには、図２４に例示するログイン画面５４０が表示される。ログイン画面５４０には、ナース氏名の入力欄５４１と「ＯＫ」ボタン５４２が設けられている。ナースは、ナース指名欄に氏名を入力して、「ＯＫ」ボタン５４２を押下することにより、インシデントレポートＩＲＰの編集作業を開始可能である。

ディスプレイには、ログイン画面５４０に続いて、図２５に例示するインシデントレポート選択画面５５０が表示される。インシデントレポート選択画面５５０には、編集可能なインシデントレポートＩＲＰの一覧５５１が表示される。ここで表示されるインシデントレポートＩＲＰは、テンポラリ格納部２３０に格納されているインシデントレポートＩＲＰのうち、ログインしたナース（ここでは、「看護順子」）が作成したインシデントレポートＩＲＰである。図２５においては、インシデントレポートＩＲＰの報告日時および報告位置がインデックスレポートの見出しとして表示されており、各見出しには各インシデントレポートＩＲＰの編集画面へのリンクが埋め込まれていることを示すアンダーライン５５２が引かれている。また、インシデントレポート選択画面５５０の下方には、「終了」ボタン５５３が表示されている。ナースは、アンダーライン５５２をクリックすることにより、対応するインシデントレポートＩＲＰの編集画面へ移行可能であるとともに、「終了」ボタン５５３を押下することにより、インシデントレポート編集用のプログラムを終了させることが可能である。

続いて、図２６に例示するインデントレポート編集画面５６０について説明する。インシデントレポート編集画面５６０には、インシデントレポート選択画面５５０で選択されたインシデントレポートＩＲＰの内容が表示される。そして、ナースは入力手段を所定の操作方法で操作することにより、表示された内容を編集である。そして、インシデントレポート編集画面の下方に表示された「終了」ボタン５６１を押下することにより、編集内容を確定することができる。一方、戻るボタン５６２を押下することにより、インシデントレポートＩＲＰの編集を中止して、インシデントレポート選択画面５５０へ戻ることができる。

このように携帯情報端末４０以外でインシデントレポートＩＲＰの編集を可能にすることにより、予定外のケアなどで携帯情報端末４０から適切なインシデントレポートＩＲＰを提出できない場合でも、有効なインシデントレポートを提出可能になる。

また、上述のインシデントレポート編集画面５６０に自由入力が可能な備考欄を設けて、小型の携帯情報端末では入力が難しい複雑な内容を入力可能にしてもよい。

＜動作＞
医療支援システム１のケア指示通知時およびインシデント報告時の動作について、図２７および図２８のフローチャートを参照しながら説明する。

○ケア指示通知時の動作；
最初に、医療支援システム１におけるケア指示通知動作について、図２７のフローチャートを参照しながら説明する。

まず、ケア指示通知時動作の最初のステップＳ１０１では、ケア指示生成部２５０が、ケアフローデータ群からケア指示の情報ＣＩＩを読み出して、ナースごとのケア指示データＣＩＤを生成する。そして、ケア指示生成部２５０は、ケア指示データ指示データＣＩＤをケア指示画面生成部２６０およびエクゼキュートコンポジション部２９０へ出力する。

ステップＳ１０１に続くステップＳ１０２では、エクゼキュートコンポジション部２９０のクエリ生成部２９４において、ケア指示データＣＩＤから、インシデントクエリＩＱが生成され、クエリエンジンマイニング部２８０へ出力される。このとき、インシデントクエリＩＱは、インシデントクエリ構造モデル２９１に基づいて生成されるので、ＫＳＤモデル３０２を反映したものとなっている。

ステップＳ１０２に続くステップＳ１０３では、クエリエンジンマイニング部２８０が、インシデントデータ群を対象とした検索を行い、インシデントクエリＩＱにマッチするインシデントデータＩＤを抽出する。そして、動作フローは次のステップＳ１０４へ移行する。

ステップＳ１０４では、クエリエンジンマイニング部２８０によって抽出されたインシデントデータＩＤがエクゼキュートコンポジション部２９０のフィルタリング部２９５へ返される。そして、フィルタリング部２９５は、返されたインシデントデータＩＤが単数か複数かによって分岐処理を行う。単数の場合は、フィルタリング部２９５は、インシデントデータＩＤのフィルタリング処理を行わずに、インシデントデータＩＤをそのままクエリ生成部２９４へ出力して、動作フローはステップＳ１０６へ移行する。そして、複数の場合は動作フローはステップＳ１０５へ移行する。

ステップＳ１０５では、フィルタリング部２９５においてフィルタリング処理、すなわち複数のインシデントデータＩＤから最も重要性が高い重要インシデントデータＩＤ’が選択される。具体的には、先述したようにインシデントデータＩＤに係るインシデントに対応するニューラルネットワーク４００の出力層Ｏのニューロンのネット値が参照され、ネット値が最大のインシデントに係る重要インシデントデータＩＤ’が抽出される。フィルタリング処理が終了後、抽出された重要インシデントデータＩＤ’がクエリ生成部２９４へ出力され、動作フローはステップＳ１０６へ移行する。

ステップＳ１０６では、クエリ生成部２９４において、インシデントデータＩＤ（または重要インシデントデータＩＤ’）から警告クエリＡＱが生成され、クエリエンジンマイニング部２８０へ出力される。

ステップＳ１０６に続くステップＳ１０７では、クエリエンジンマイニング部２８０が警告データ群を対象とした検索を行い、警告クエリＡＱにマッチする警告データＡＤを抽出する。そして、動作フローは次のステップＳ１０８へ移行する。

ステップＳ１０８では、クエリエンジンマイニング部２８０によって抽出された警告データＡＤがエクゼキュートコンポジション部２９０へ返される。さらに、エクゼキュートコンポジション部２９０は、警告データＡＤをケア指示画面生成部２６０へ転送する。

ステップＳ１０８に続くステップＳ１０９では、ケア指示画面生成部２６０は、ステップＳ１０１で入力されたケア指示データＣＩＤとステップＳ１０８で入力された警告データＡＤからケア指示画面５００（ＣＩＳ）を生成して携帯情報端末４０へネットワーク１０を介して送信する。これにより、ケア指示および警告が同期してナースへ通知されることになる。

ステップＳ１０９に続くステップＳ１１０では、携帯情報端末４０でケア指示画面５００が液晶ディスプレイ４１に表示される。これにより、ケア指示通知動作が終了する。

○インシデント報告時の動作；
続いて、医療支援システム１におけるインシデント報告動作について、図２８のフローチャートを参照しながら説明する。

まず、インシデント報告動作の最初のステップＳ２０１では、携帯情報端末４０のインシデント報告ボタン４５の押下検出が行われる。インシデント報告ボタン４５の押下が検出された場合、動作フローは次のステップＳ２０２へ移行する。押下が検出されない場合、押下が検出されるまでステップＳ２０１が繰り返される。

ステップＳ２０２では、携帯情報端末４０においてインシデント報告プログラムが起動されて、インシデント発生信号ＩＨＳが携帯情報端末４０からデータベースサーバ２０のインシデントレポート生成部２２０へネットワーク１０を介して送信される。先述したように、このインシデント発生信号ＩＨＳには、携帯情報端末４０に設定されたＩＰアドレスと、ＲＦＩＤタグリーダ４８が読み取った携帯情報端末４０の近傍のＲＦＩＤタグ７０の位置情報が含まれている。

ステップＳ２０２に続くステップＳ２０３では、インシデントレポート生成部２２０は、受信したインシデント発生信号ＩＨＳに含まれるＩＰアドレスを用いて、インシデント報告を行うナースの氏名ＮＮをナース属性データ群から読み出す。また、ナース氏名ＮＮ、インシデント発生信号ＩＨＳが入力された時間および位置情報を用いて、当該ナースが実行中のケアをケアフローデータ群から読み出す。そして、読み出したデータなどをコンパクトＨＴＭＬなどの表示に適した形式に変換して、携帯情報端末４０へケア内容確認画面５１０（ＣＳ）として送信する。これらの処理が終了後、動作フローは次のステップＳ２０４へ移行する。

ステップＳ２０４では、携帯情報端末４０において、インシデントレポート生成部２２０から入力されたケア内容確認画面５１０が表示される。

ステップＳ２０５では、携帯情報端末４０におけるＧＵＩボタン操作の検出に応じて分岐処理が行われる。すなわち、リセットボタン５１１の押下が検出されると、動作フローはステップＳ２０６へ移行する。また、ＯＫボタン５１２の押下が検出されると動作フローはステップＳ２０７へ移行する。また、いずれのボタンの押下も検出されない場合、いずれかのボタンの押下が検出されるまで、ステップＳ２０５が繰り返される。

ステップＳ２０６では、リセット信号ＲＳＳが携帯情報端末４０からインシデントレポート生成部２２０へ送信される。そして、リセット信号ＲＳＳを受信したインシデントレポート生成部２２０はインシデントレポートＩＲＰのケア内容を記述しないまま、動作フローが次のステップＳ２０８へ移行する。これにより、ケア内容確認画面５１０でリセットボタン５１１が押下された場合は、先述したようにインシデントレポートＩＲＰのケア内容は空欄となる。

一方、ステップＳ２０７では、ＯＫ信号ＯＳＳが携帯情報端末４０からインシデントレポート生成部２２０へ送信される。そして、ＯＫ信号ＯＳＳを受信したインシデントレポート生成部２２０は、ステップＳ２０３でケアフローデータ群から読み出したケアデータをインシデントレポートＩＲＰに記述して、動作フローはステップＳ２０８へ移行する。

ステップＳ２０８では、インシデントレポート生成部２２０において、ステップＳ２０７でインシデントレポートＩＲＰに記述されたケアカテゴリＣＣＡに対応するインシデント内容カテゴリがカテゴリデータ群から読み出され、インシデント内容入力画面５２０が生成される。生成されたインシデント内容入力画面５２０（ＩＳ）は、インシデントレポート生成部２２０から携帯情報端末４０へ送信される。

ステップＳ２０９では、携帯情報端末４０の液晶ディスプレイ４１にインシデント内容入力画面５２０が表示される。そして、動作フローは次のステップＳ２１０へ移行する。

ステップＳ２１０では、携帯情報端末４０において選択されたインシデント内容ＩＤＴがインシデントレポート生成部２２０へ送信され、当該インシデント内容ＩＤＴがインシデントレポートＩＲＰに記述される（ただし、スキップの場合はインシデント内容は空欄となる）。

ステップＳ２１０に続くステップＳ２１１では、インシデントレポート生成部２２０において、ステップＳ２０７でインシデントレポートＩＲＰに記述されたインシデント内容ＩＤＴに対応するインシデント原因カテゴリがカテゴリデータ群から読み出される。そして、インシデント原因入力画面５３０が生成される。生成されたインシデント原因入力画面５３０（ＯＳ）は、インシデントレポート生成部２２０から携帯情報端末４０へ送信される。

ステップＳ２１１に続くステップＳ２１２では、携帯情報端末４０の液晶ディスプレイ４１にインシデント原因入力画面５３０が表示され、動作フローが次のステップＳ２１３へ移行する。

ステップＳ２１３では、携帯情報端末４０において選択されたインシデント原因ＩＯＲがインシデントレポート生成部２２０へ送信され、当該インシデント原因ＩＯＲがインシデントレポートＩＲＰに記述される（ただし、スキップの場合はインシデント原因は空欄となる）。

ステップＳ２１３に続くステップＳ２１４では、インシデントレポート生成部２２０からテンポラリ格納部２３０へインシデントレポートＩＲＰが転送され、インシデント報告時の動作が終了する。

＜リアライゼーションストアの変形例＞
上述の実施の形態の説明においては、リアライゼーションストア３００にニューラルネットワーク４００としてＫＳＤモデル３０２が構築されたが、ＫＳＤモデル３０２の構築方法はこれに制限されない。以下では、変形例として、ＫＳＤモデル３０２の構築にペトリネットを使用した例を図２９を参照しながら説明する。

図２９のペトリネット６００は、処置項目などを記述するプレース６０１〜６０４およびプレース間の移行条件などを記述するトランジション６１１〜６１３という２種類のノードを備える。また、プレース６０１〜６０４やトランジション６１１〜６１３は、前後関係を示すアーク６２１〜６２６で関連付けられている。

図２９のペトリネットにおいては、プレース６０１〜６０４にそれぞれ「作業開始」「薬剤の確認」「作業終了」という処置項目などが記述される。また、トランジション６１２には、正しい薬剤の準備完了という、プレース６０２からプレース６０３への移行条件が記述されている。この移行条件は、それが満たされた場合に、トランジション６１２に接続されたアーク６２３および６２４にしたがって、プレース６０２からプレース６０３への移行が行われることを示す。すなわち、プレース６０２に記述された「薬剤の確認」が行われた場合に、正しい薬剤の準備が完了されると、プレース６０３に記述された「作業終了」という状態へ移行することを示している。なお、何も記述されていないトランジション６１１は、プレースに記述された「作業開始」が行われた場合は全て後続するプレース６０２へ移行することを示している。

さらにペトリネット６００は、プレース６０２からアーク６２５によって分岐された、トランジション６１３およびプレース６０４が設けられている。トランジション６１３には、「薬剤間違い」というヒヤリハットの発生条件が記述されている。そして、この記述された条件が満たされた場合は、プレース６０４に記述された「ヒヤリハット」の状態へ移行することを示している。

そして、この変形例では、以上で説明したペトリネット６００をＫＳＤモデル３０２として設けておく。また、プレース６０４に接続されたトランジションには発生頻度（回数）を記述しておく、このように発生頻度を記述しておけば、医療事故に至る可能性が高いパスを情報として蓄積可能になる。

なお、このペトリネット６００では簡単な分岐を有する例をあげたが、さらに複雑なペトリネットを用いてよい。なお、ペトリネットには、複数の要因の組み合わせによるヒヤリハットをも考慮することができるという利点がある。

＜インシデントデータ群の変形例＞
上述のインシデントデータ群では、階層構造を有するデータ構造を持たせたが、図３０に例示されているようなリレーショナルデータを用いてもよい。この場合も、データ検索効率を最適化するためにデータ構造を変更可能である。

＜ナースの位置情報を取得する方法の変形例＞
上述の実施の形態の説明では、携帯情報端末４０の位置の特定にＲＦＩＤタグ７０とＲＦＩＤタグリーダ４８とを使用したが、携帯情報端末４０（またはナース）の位置の特定方法はこれに制限されない。以下では、ＲＦＩＤタグ７０とＲＦＩＤタグリーダ４８を使用しないで携帯情報端末４０の位置情報を取得する方法を説明する。

○ビーコン電波の強度を利用した位置特定方法；
医療機関内に存在する携帯情報端末４０から送信されるビーコン電波を固定された複数の受信アンテナ７０３〜７０６で受信して電界強度を測定し、当該電界強度から携帯情報端末４０を携帯するナースの位置を特定する方法を図３１の機器概念図を参照しながら説明する。

この方法においては、携帯情報端末４０にはＲＦＩＤタグリーダ４８は搭載されず、医療機関内にはＲＦＩＤタグ７０は設置されない。そして、これらに代えて、携帯情報端末４０にはナースの位置を知らせるためのビーコン電波を発生する送信機７０１と、当該ビーコン電波を送信するための送信アンテナ７０２が設けられている。また、医療機関内には、ビーコン電波を受信するための複数の受信アンテナ７０３〜７０６が設けられる。受信アンテナ７０３〜７０６には、同軸ケーブルを介して受信機７０７〜７１０が接続されている。受信機７０７〜７１０は、ネットワーク１０にも接続されており、受信したビーコン電波の強度（ここでは電界強度で代表させる）を算出してデータベースサーバ２０へ送信可能である。受信アンテナ７０３〜７０６には、垂直ダイポールアンテナなどの水平面指向性が無指向性で垂直偏波のアンテナが採用されている。送信アンテナ７０２としては、ホイップアンテナなどの、携帯情報端末４０を垂直に保持した場合に、水平面指向性が無指向性で垂直偏波となるアンテナが採用される。ただし、携帯情報端末４０は固定されておらず、必ずしも垂直に保持されているとは限らないので、送信アンテナ７０２の空間に対する指向性や偏波面は一定ではない。

この方法で使用されるビーコン電波の周波数は特に制限されないが、以下に列記する条件を満たす周波数を選択することが望ましい。すなわち、
（１）医療用電子機器や無線ＬＡＮ１２との相互干渉を引き起こさない；
（２）人体による指向性の変化が小さい；および
（３）医療機関内の障害物（壁など）による減衰、反射および回折の影響が小さい；
という条件を満たす周波数を選択することが望ましい。また、ビーコン電波のキャリアには、携帯情報端末４０を識別するためのＩＤが所定の変調方法で付加されている。したがって、受信機７０７〜７１０は受信しているビーコン電波の送信元の携帯情報端末４０を特定可能である。また、同じ周波数で同時に複数の携帯情報端末４０がビーコン電波を送信することがないように、ビーコン電波が送出されるタイムスケジュールおよび周波数はあらかじめ定められている。

続いて、受信アンテナ７０３〜７０６が受信したビーコン電波の電界強度から携帯情報端末４０の位置を特定する方法を説明する。ここでは、受信アンテナ７０３〜７０６および送信アンテナ７０２が近似的に同一平面内に存在するとみなせる場合、たとえば、受信アンテナ７０３〜７０６および送信アンテナ７０２が同一のフロアに存在する場合を例として説明する。なお、医療支援システム１の適用対象の医療機関が複数のフロアに渡る場合は、同様の設備を各階ごとに設けてもよいし、受信アンテナ７０３〜７０６の数を増加させることによって携帯情報端末４０の３次元的な位置を特定可能としてもよい。

ここで、説明の便宜のために、医療機関の建物に固定された３次元直交座標系ＸＹＺを考える。また、３次元直交座標系ＸＹＺにおける送信アンテナの位置をＰＴ（ＸＴ，ＹＴ，Ｚ）、受信アンテナの位置をＰＲ（ＸＲ，ＹＲ，Ｚ）とする。また、送信アンテナの３次元直交座標系ＸＹＺに対する向きを極座標の角度成分Ｒ（θ，φ）で表現する。この場合、受信アンテナで測定される電界強度ＥＲは数４で表現される（遠傍領域を仮定）。

ここで、関数ｆは、送信アンテナの指向性を表現する関数であり、ｋは定数である。また、受信アンテナは固定されているのでＸＲ，ＹＲは既知であり、ＥＲは測定により明らかになる。また、定数ｋは、理論的または実験的に事前に決定可能である。しがたって、数４に含まれる実質的な未知数は、θ，φ，ＸＴ，ＸＲの４個である。よって、４個の受信アンテナ７０３〜７０６および４個の受信機７０７〜７１０があれば、携帯情報端末４０の位置情報を算出可能である。

このような位置情報は、受信機７０７〜７１０からネットワーク１０を介して得られた電界強度に基づいてデータベースサーバ２０で算出される。そして、上述のＲＦＩＤタグ７０などで特定された位置情報と同様にインシデント報告の入力の省力化に利用される。

○電波の到達時間を利用した位置特定方法；
複数の送信アンテナから送信される電波を医療機関内に存在する携帯情報端末４０で受信して、携帯情報端末４０を携帯するナースの位置を特定する方法を図３２の機器概念図を参照しながら説明する。

この方法においては、携帯情報端末４０にはＲＦＩＤタグリーダ４８は搭載されず、医療機関内にはＲＦＩＤタグ７０は設置されない。そして、これらに代えて、医療機関内には、測位用の電波を送信するための複数の送信アンテナ７２１〜７２４および送信機７２８〜７３１が設けられている。また、携帯情報端末４０には、測位用の電波を受信する受信アンテナ７３２と受信機７３３とが設けられている。また、送信機７２８〜７３１および受信機７３３には時刻を計測するための時計が搭載されている。

なお、この方法で使用される周波数も特に制限されないが、先述したビーコン電波の周波数と同様な配慮を行うことが望ましい。

送信機７２８〜７３１は、キャリアを１次変調した信号に所定の拡散符号を適用して、スペクトラム拡散信号を生成し、送信アンテナ７２１〜７２４から送信する。このスペクトラム拡散信号には、正確な時刻の情報が含まれている。

一方、受信機７３３は、送信機７２８〜７３１から送信された信号に送信時と同じ拡散符号を適用して、逆拡散を行う。そして、信号を復元可能な逆拡散タイミングを特定することにより、送信機７２８〜７３１から受信機７３３まで電波が到達するのに要した時間を特定して、データベースサーバ２０へネットワーク１０を介して送信する。データベースサーバ２０は、このようにして入力された到達時間の情報から、送信機７２８〜７３１と受信機７３３との距離を算出して、携帯情報端末４０の３次元位置を算出する。

なお、受信機７３３に搭載された時計が十分に正確である場合、３つの送信アンテナがあれば、携帯情報端末４０の３次元位置（３つの未知パラメータを含む）を算出できるが、携帯情報端末４０に十分に正確な時計を搭載することができない場合でも、４つの送信アンテナを用いれば携帯情報端末４０の３次元位置を特定することが可能になる。

○加速度センサを利用した位置特定方法；
携帯情報端末４０に搭載された加速度センサの検出結果から携帯情報端末４０を携帯するナースの位置を決定する方法を図３３の機器概略図を参照しながら説明する。

この方法においては、携帯情報端末４０にはＲＦＩＤタグリーダ４８は搭載されず、医療機関内にはＲＦＩＤタグ７０は設置されない。そして、これらに代えて、携帯情報端末４０には、動的な加速度（加速度の非直流成分）を検出して加速度信号として出力する３軸加速度センサ７４０と、加速度信号を積分して位置変位を示す位置変位信号へ変換する積分器７４１とが設けられている。積分器７４１は、加速度信号を積分して速度信号を生成し、さらに速度信号を積分して位置変位信号を生成する。これらの信号はデジタル信号およびアナログ信号のどちらでもよく、積分処理もデジタル信号処理およびアナログ信号処理のいずれであってもよい。

携帯情報端末４０のコンピュータ本体部４６のメモリには、携帯情報端末４０の位置情報７４２を格納する位置情報記憶エリアが設けられている。この位置情報記憶エリアに記憶された携帯情報端末４０の位置情報７４２は、上述の積分器７４１から出力される位置変位信号に基づいて随時更新される。

さらに、医療機関内には、位置の基準（基準位置）が設定されている。基準位置の設定場所は特に制限されないが、ナースが最も頻繁に通過する場所、たとえば、ナースステーションの出入り口などに設定されることが望ましい。基準位置には、基準位置であることを示す電波を発生する送信機７４３と、当該電波を送信するための送信アンテナ７４４が設けられている。この電波の出力電力は、基準位置近傍のごく狭い範囲のみで検出可能となるように、微弱なレベルに制限されている。より具体的には、位置特定に求められる分解能よりも十分に小さい距離にのみ到達するように制限されている。

携帯情報端末４０には、この微弱信号を検出するための受信機７４６と受信アンテナ７４５が設けられている。そして、当該微弱信号を検出すると、上述の位置情報記憶エリアに格納されている位置情報７４２が基準位置に初期化されるように構成されている。

このように基準位置を設けることにより、位置情報７４２に誤差が蓄積して位置情報７４２の精度が低下することを防止可能である。

○画像解析を利用した位置特定方法；
医療機関内に設置されたカメラで撮影した画像から、ナースの位置を決定する方法を図３４の機器概略図を参照しながら説明する。

この方法においては、携帯情報端末４０にはＲＦＩＤタグリーダ４８は搭載されず、医療機関内にはＲＦＩＤタグ７０は設置されない。そして、これらに代えて、医療機関内のケアが実行される単位ごとにカメラ７５１が設置される。カメラ７５１はネットワーク１０に接続され、撮影した画像をデータベースサーバ２０に送信可能となっている。さらに、データベースサーバ２０には、位置情報取得手段の一部として機能する画像解析エンジン７６０が搭載されている。

画像解析エンジン７６０には、ナースの顔を事前に撮影して得た顔画像データが格納される顔画像データ格納部７６１が設けられている。また、設置されたカメラ７５１から入力される人物像から顔部分を抽出する抽出部７６２と、抽出された顔部分と事前登録された顔画像データとのテンプレートマッチングを行うマッチング部７６３とを備える。

抽出部７６２は、顔特有の形状や色の情報を利用して、人物像中の顔部分を抽出する。

マッチング部７６３は、抽出部７６２から得た顔画像と、あらかじめ登録された顔画像との間でテンプレートマッチングを行い、入力された顔画像と最もマッチング度が高い顔画像を決定する。これにより、カメラ７５１が撮影した人物のナース氏名が特定可能となる。

なお、ここでは顔画像を利用する例を説明したが、ナースが着用している制服などにバーコードなどの識別図案を取り付けて、当該識別図案に対して解析を行うようにしてもよい。あるいは、ナースが着用している制服に発光ダイオード等の発光素子を取り付けて識別信号を発信させ、当該識別信号に対して解析を行うようにしてもよい。また、電磁相互作用による受動的または能動的なデータ送受信が可能な識別信号生成装置をナースが着用している制服に取り付けて、医療機関内のケアが実行される単位ごとに設けられた読取装置で当該識別信号生成装置から識別信号を読み取るようにしてもよい。

＜その他＞
なお、上述の発明の実施の形態は以下に示す構成を有する発明を含んでいる。

［１］ 請求項１に記載の医療支援システムにおいて、
前記インシデントデータ群のデータ構造を保持する構造保持手段と、
前記論理モデルに基づいて、前記データ構造を更新する構造更新手段と、
をさらに備えることを特徴とする医療支援システム。

［１］の発明によれば、インシデントデータ群のデータ構造にインシデントの傾向を反映可能であるので、インシデントの傾向が変化してもインシデントデータ群に対する検索操作の効率を高水準に維持可能となる。

［２］ 請求項１に記載の医療支援システムにおいて、
前記インシデントデータ群とは異なるデータ群が前記データストアに格納されており、
前記インシデント防止情報生成手段は、前記インシデント防止情報の生成時に前記データ群を参照することを特徴とする医療支援システム。

［２］の発明によれば、インシデント防止情報を生成するときに複数のデータ群を参照するので、多くのインシデント要因を考慮可能となる。これにより、より適切なインシデント防止情報を生成可能となる。

［３］ 請求項１に記載の医療支援システムにおいて、
前記論理モデルが、他の医療支援システムからインポート可能であることを特徴とする医療支援システム。

［４］ 請求項１に記載の医療支援システムにおいて、
前記論理モデルが、他の医療支援システムへエクスポート可能であることを特徴とする医療支援システム。

［５］ 請求項１に記載の医療支援システムにおいて、前記論理モデル保持手段が複数の論理モデルを保持可能であることを特徴とする医療支援システム。

［３］ないし［５］の発明によれば、適切な論理モデルを医療支援システムに導入可能になるので、適切なインシデント防止情報を生成可能になる。

［６］ ［５］に記載の医療支援システムにおいて、
前記複数の論理モデルを結合する結合手段をさらに備えることを特徴とする医療支援システム。

［６］の発明によれば、より高度の論理モデルを構築可能になる。

［７］ 請求項１に記載の医療支援システムにおいて、
前記インシデントデータ群がＸＭＬで記述されており、
前記データ構造が階層構造を有することを特徴とする医療支援システム。

［８］ 請求項１に記載の医療支援システムにおいて、
前記医療行為と対応づけられた第１構成素子群と、
前記インシデントと対応づけられた第２構成素子群と、
前記第１構成素子群および前記第２構成素子群を含む構成素子群の各々の構成素子間の情報伝達を伝達特性に基づいて行う伝達手段と、
前記論理解析手段の要素として設けられ、所定の更新規則に基づいて前記伝達特性を更新する伝達特性更新手段と、
を備える構成素子網を備え、
前記論理モデルが前記伝達特性として蓄積されることを特徴とする医療支援システム。

［９］ ［８］に記載の医療支援システムにおいて、
前記構成素子網がコンピュータにインストールされたプログラムによって実現されたニューラルネットワークであることを特徴とする医療支援システム。

［１０］ 請求項１に記載の医療支援システムにおいて、
前記インシデント防止情報生成手段が、
前記医療行為情報から、前記医療行為を実行時に他のインシデントよりも相対的に発生可能性が高い高頻度インシデントを抽出する抽出手段と、
前記高頻度インシデントに対応したインシデント防止情報を特定する特定手段と、
を備えることを特徴とする医療支援システム。

［１１］ 請求項２に記載の医療支援システムにおいて、
前記位置情報取得手段が、
前記医療行為が実行される領域内に所定の配置で設置された複数の標識と、
電磁相互作用により、所定の距離範囲内に存在する前記標識を検出する検出手段と、
を備え、
前記標識には複数の標識を識別するための識別情報が格納されており、
前記検出手段が電磁相互作用により前記識別情報を読み出すことにより、前記検出手段を携帯する医療従事者の位置情報を取得することを特徴とする医療支援システム。

［１２］ 請求項２に記載の医療支援システムにおいて、
前記位置情報取得手段が、
送信元を特定可能な電磁波を送信する送信手段と、
前記医療行為が実行される領域内から送信された前記電磁波を受信して、前記電磁波の強度に関する強度情報を出力する複数の受信手段と、
を備え、
前記強度情報に基づいて前記送信手段の位置を解析することにより、前記送信手段を携帯する医療従事者の位置情報を取得することを特徴とする医療支援システム。

［１３］ 請求項２に記載の医療支援システムにおいて、
前記位置情報取得手段が、
送信元および送信時刻を特定可能な電磁波を前記医療行為が実行される領域内へ送信する複数の送信手段と、
前記電磁波を受信して、前記複数の送信手段から到達までの時間を特定する受信手段と、
を備え、
前記時間を解析して前記受信手段の位置を算出することによって、前記受信手段を携帯する医療従事者の位置情報を取得することを特徴とする医療支援システム。

［１４］ 請求項２に記載の医療支援システムにおいて、
前記位置情報取得手段が、
医療従事者の位置情報を格納する位置情報格納手段と、
医療従事者が所定の基準位置に存在する場合に前記位置情報を初期化する初期化手段と、
医療従事者の移動加速度を検出する加速度検出手段と、
前記移動加速度から医療従事者の移動量を算出する算出手段と、
前記移動量に基づいて前記位置情報を更新する手段と、
を備えることを特徴とする医療支援システム。

［１５］ 請求項２に記載の医療支援システムにおいて、
前記位置情報取得手段が、
前記医療行為が実行される領域内に所定の配置で設置された複数の撮像手段と、
前記撮像手段で撮像された画像内の医療従事者を特定する医療従事者特定手段と、
を備え、
医療従事者の存在が特定された画像を撮像した撮像手段の設置場所を特定することにより、医療従事者の位置情報を取得することを特徴とする医療支援システム。

［１６］ 医療支援システムであって、
医療指示と、前記医療指示に対応したインシデント防止情報とを同期させて送信するデータベース本体部と、
前記医療指示および前記インシデント防止情報を受信するデータベース端末と、
前記データベース本体部と前記データベース端末とを通信可能に接続するネットワークと、
を備え、
前記データベース端末から前記データベース本体部へと送信される情報に基づいて、医療従事者によって実際に実行された実行済医療行為に関する実行済医療行為情報と、前記実行済医療行為によって実際に発生したインシデント事例に関するインシデント事例情報とを含むインシデント報告が生成され、
前記インシデント報告に基づいて、前記インシデント防止情報の生成規則が更新されることを特徴とする医療支援システム。

［１７］ ［１６］に記載の医療支援システムにおいて、
前記携帯情報端末が前記ネットワークに無線通信手段によって接続可能であることを特徴とする医療支援システム。

［１７］の発明によれば、無線通信手段により医療従事者は携帯が容易な端末を用いて医療指示およびインシデント防止情報を受け取り可能となるので、医療従事者は医療行為の現場でインシデント防止情報を知ることが可能になる。これにより、インシデント防止情報を医療行為の実行時に配慮しやすくなる。

医療支援システム１のハードウエア構成を説明するブロック図である。 携帯情報端末４０の構成を説明する正面図である。 携帯情報端末４０の構成を説明するブロック図である。 ケアフローデータ群の階層データ構造を説明する図である。 インシデントデータ群の階層データ構造を説明する図である。 警告データ群の階層データ構造を説明する図である。 ナース属性データ群の階層データ構造を説明する図である。 患者属性データ群の階層データ構造を説明する図である。 カテゴリデータ群の階層データ構造を説明する図である。 医療支援システム１の構成を説明するブロック図である。 インシデントクエリ構造モデルを表現するグラフを説明する図である。 警告クエリ構造モデルを表現するグラフを説明する図である。 リストラクチャエンジン２７０の構成を説明するブロック図である。 インシデントデータ群の階層データ構造を説明する図である。 ニューラルネットワーク４００を説明する図である。 ニューロンを説明する図である。 ニューラルネットワークの学習を説明する図である。 ケア指示画面を説明する図である。 報告種類選択画面を説明する図である。 ナース選択画面を説明する図である。 ケア内容確認画面を説明する図である。 インシデント内容画面を説明する図である。 インシデント原因画面を説明する図である。 インシデントレポート編集プログラムのログイン画面を説明する図である。 インシデントレポート選択画面を説明する図である。 インシデントレポート編集画面を説明する図である。 ケア指示通知動作を説明するフローチャートである。 インシデント報告動作を説明するフローチャートである。 ペトリネットを説明する図である。 ルールベースを説明する図である。 ビーコン電波の強度を利用した位置特定方法を説明する図である。 電波の到達時間を利用した位置特定方法を説明する図である。 加速度センサを利用した位置特定方法を説明する図である。 画像解析を利用した位置特定方法を説明する図である。

符号の説明

１ 医療支援システム
４１ 液晶ディスプレイ
４２ ボタン群
４３ ４連スイッチ
４４ 実行ボタン
４５ インシデント報告ボタン
４００ ニューラルネットワーク
４１０ ニューロン
５００ ケア指示画面
５１０ ケア内容確認画面
５２０ インシデント内容入力画面
５３０ インシデント原因入力画面
５４０ ログイン画面
５５０ インシデントレポート選択画面
５６０ インシデントレポート編集画面
５７０ 報告種類選択画面
５８０ ナース選択画面
６００ ペトリネット
ＡＤ 警告データ
ＡＱ 警告クエリ
ＣＳ ケア内容確認画面
ＣＣＡ ケアカテゴリ
ＣＤＴ ケア内容詳細
ＣＩＤ ケア指示データ
ＣＩＩ ケア指示の情報
ＣＩＳ ケア指示画面
ＩＤ インシデントデータ
ＩＤ’ 重要インシデントデータ
ＩＱ インシデントクエリ
ＩＳ インシデント内容入力画面
ＩＤＴ インシデント内容
ＩＨＳ インシデント発生信号
ＩＯＲ インシデント原因
ＩＲＰ インシデントレポート
ＮＮ ナース氏名
ＯＳ インシデント原因入力画面
ＯＳＳ ＯＫ信号
ＰＮ 患者氏名
ＲＳＳ リセット信号
ＳＡＳ 構造変化指示信号

Claims (6)

1. 医療支援システムであって、
   医療従事者によって実際に実行された実行済医療行為に関する実行済医療行為情報と、前記実行済医療行為によって実際に発生したインシデント事例に関するインシデント事例情報とを含むインシデント報告を取得する手段と、
   前記インシデント報告をインシデントデータ群として格納するデータストアと、
   所定の生成規則に基づいて、医療行為に関する医療行為情報から、前記医療行為に対応したインシデント防止情報を生成するインシデント防止情報生成手段と、
   一の前記実行済医療行為情報と一の前記インシデント事例情報との個別の対応をあらわす論理経路を解析する論理解析手段と、
   複数の医療行為と複数のインシデントとの一般的な関係を前記インシデントデータ群の具体的データ内容とは独立して表現した論理モデルを保持する論理モデル保持手段と、
   前記論理モデルに基づいて前記生成規則を更新する生成規則更新手段と、
   を備え、
   前記インシデント報告が新たに取得されるごとに、新たなインシデント報告を前記インシデントデータ群に追加するとともに、前記論理解析手段が、当該新たなインシデント報告と、既に蓄積されている過去のインシデント報告とのうち少なくとも前者に対応する論理経路の解析を行うことによって、解析した論理経路に対応する医療行為とインシデントとの関係を強化するように前記論理モデルを更新することを特徴とする医療支援システム。
2. 請求項１に記載の医療支援システムにおいて、
   前記インシデントデータ群のデータ構造を保持する構造保持手段と、
   前記論理モデルに基づいて、前記データ構造を更新する構造更新手段と、
   をさらに備えることを特徴とする医療支援システム。
3. 請求項１又は請求項２に記載の医療支援システムにおいて、
   前記データストアが、前記インシデントデータ群に加えて、医療従事者に与えられる医療指示の情報を含む医療指示データ群を格納するとともに、
   医療従事者の位置情報を取得する位置情報取得手段と、
   前記医療指示データ群と前記位置情報とから、前記実行済医療行為を特定する特定手段と、
   前記位置情報から特定された前記実行済医療行為に関する実行済医療行為情報を利用して、前記インシデント事例情報を入力する入力手段と、
   をさらに備え、
   前記インシデント報告が、前記実行済医療行為情報と前記インシデント事例情報とから生成されることを特徴とする医療支援システム。
4. 請求項１又は請求項２に記載の医療支援システムにおいて、
   医療従事者に与えられる医療指示の情報を含む医療指示データ群を格納するデータストアと、
   前記医療指示データ群に基づいて、医療従事者への医療指示を生成する医療指示生成手段と、
   前記医療指示と前記インシデント防止情報とを同期させて医療従事者に通知する通知手段と、
   をさらに備え、
   前記インシデント防止情報生成手段は、
   前記生成規則に基づいて、前記医療指示に係る医療行為に対応したインシデント防止情報を生成することを特徴とする医療支援システム。
5. 請求項４に記載の医療支援システムにおいて、
   医療従事者の位置情報を取得する位置情報取得手段と、
   前記医療指示データ群と前記位置情報とから、医療従事者によって実際に実行された実行済医療行為を特定する特定手段と、
   前記実行済医療行為によって実際に発生したインシデント事例に関するインシデント事例情報を入力する入力手段と、
   前記実行済医療行為に関する実行済医療行為情報と、前記インシデント事例情報とを含むインシデント報告を生成するインシデント報告生成手段と、
   をさらに備えることを特徴とする医療支援システム。
6. 請求項１又は請求項２に記載の医療支援システムにおいて、
   医療従事者によって実際に実行された実行済医療行為によって実際に発生したインシデント事例に関するインシデント事例情報を逐次的に入力する入力手段と、
   前記入力手段による入力を支援する補助情報を医療従事者へ逐次的に通知する補助情報通知手段と、
   前記入力手段によって入力された情報に応じて、前記補助情報の具体的内容を変化させる変化手段と、
   を備えることを特徴とする医療支援システム。

Images