(57)【要約】  【課題】  有害な医療事故の数を低減するために、健康管理の手順および実務を全体的に改善すること。  【解決手段】  回答を求める質問の形の返答要求の階層的シリーズおよび複数の一般的返答識別子のデータベースから選択した１つまたは複数の一般的返答識別子を使用し、１つまたは複数の選択した一般的返答識別子を使用して上記第１の返答に対して階層的な他の返答要求質問のデータベースから選択を行う、避けることができる潜在的に有害な医療事故データの分析を行うための方法を実施するための方法およびコンピュータ・システム。【選択図】      図１
2006301730.tif 000002
【特許請求の範囲】
【請求項１】
医療事故を収集し、分類するステップを含む、避けることができる潜在的に有害な医療事故データの分析を容易にするための方法であって、
回答を求める質問の形の返答要求の階層的シリーズの最初のものを表示するステップと、
前記最初の各返答要求に対して、複数の一般的返答識別子のデータベースから選択した１つまたは複数の一般的返答識別子を選択し、次に前記選択した１つまたは複数の一般的返答識別子を使用して前記第１の返答に対して階層的な他の返答要求質問のデータベースから選択を行うステップと、
次に、前記または各選択した一般的返答識別子に関連するように選択される、選択した他の返答要求質問を表示するステップと、
返答要求および１つまたは複数の返答識別子の階層を識別するのに十分な情報を記憶するステップとを含む方法。
【請求項２】
１つの医療事故に関連する返答要求の２つ以上の階層的シリーズが存在する、請求項１に記載の方法。
【請求項３】
１つの階層的シリーズの前記返答要求および対応する返答識別子の組合わせを分類構造と呼ぶことができる、前記請求項のいずれか１項に記載の方法。
【請求項４】
前記返答要求が、特定の産業または医療事故タイプのために選択した階層医療事故モデルが指定した返答要求である、前記請求項のいずれか１項に記載の方法。
【請求項５】
収集する前記医療事故データが健康管理医療事故データである、前記請求項のいずれか１項に記載の方法。
【請求項６】
前記階層医療事故モデルがランシマン・モデルである、前記請求項のいずれか１項に記載の方法。
【請求項７】
コンピュータ・システムであって、
返答要求の階層的シリーズの最初のものを表示し、次に
前記要求に応じて、データベースから複数の一般的返答識別子のうちの１つまたは複数の識別子を選択し、
前記選択が、前記選択した一般的返答識別子に関連する選択した他の返答要求を表示し、
次に、返答要求および返答識別子の階層を識別するのに十分な情報を記憶し、
これらのステップを反復してある医療事故についての他の情報を引き出すように配置されているコンピュータ・システム。
【請求項８】
さらに、医療事故報告および分類構造の構成を容易にするために、データ・エントリ・フォームおよび結果としての分類を一緒に表示することができる、請求項７に記載のコンピュータ・システム。
【請求項９】
分類構造の選択したカスケード状のブランチが、他の分類構造で必要に応じて再使用される、請求項７または８のいずれか１項に記載のコンピュータ・システム。
【請求項１０】
各分類構造が、選択した数の一次分類部門を含む、請求項７〜９のいずれか１項に記載のコンピュータ・システム。
【請求項１１】
さらに、前記分類階層の集中制御および修正を受け入れることができる、請求項７〜１０のいずれか１項に記載のコンピュータ・システム。
【請求項１２】
一般的返答識別子が選択できるように表示されているテキストが、ユーザが選択可能な言語で書かれている、請求項７〜１１のいずれか１項に記載のコンピュータ・システム。
【請求項１３】
一般的返答識別子が選択できるように表示されているテキストが、ユーザが選択可能な記述規格で書かれている、請求項７〜１２のいずれか１項に記載のコンピュータ・システム。
【請求項１４】
ユーザにコンテキスト感知可能ヘルプおよび正しい使用上の指示を提供するために規則が使用され、前記規則が前記階層項目を入力する際に前記データベース内に入力される、請求項７〜１２のいずれか１項に記載のコンピュータ・システム。
【請求項１５】
医療事故を収集し、分類するステップを含む、避けることができる潜在的に有害な医療事故データの分析を容易にするための方法を実行するようにプログラムされているコンピュータであって、前記方法が、
回答を求める質問の形の返答要求の階層的に配置されているシリーズの最初のものを視覚的出力として表示するステップと、
次に、前記コンピュータが、複数の一般的返答識別子のデータベースから選択した１つまたは複数の分類識別子を、前記各最初の返答要求回答に対して選択し、次に、前記選択した１つまたは複数の一般的返答識別子を使用して前記第１の返答に対して前記コンテキストの後に続く他の質問のデータベースから選択を行うステップと、
次に、前記または各選択した一般的返答識別子に関連するように選択される、選択した他の返答要求質問を表示するステップと、
返答要求および１つまたは複数の返答識別子のランク内でその階層またはシリーズを識別するのに十分な情報を記憶するステップとを含むコンピュータ。
【請求項１６】
前記請求項のいずれか１項に記載の方法を実行するようにプログラムされているコンピュータ。
【請求項１７】
添付の図面のうちの任意の１つまたは複数を参照しながら、またこのような図面に示す前記明細書に実質的に記載されているコンピュータ・システム。
【請求項１８】
添付の図面のうちの任意の１つまたは複数を参照しながら、またこのような図面に示す前記明細書に実質的に記載されている、避けることができる潜在的に有害な医療事故データの分析を容易にするための方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、避けることができる潜在的に有害な医療事故データの分析を助けるための方法、この目的のためのコンピュータ・プログラムおよびこの目的のためにプログラムされたコンピュータに関する。
【背景技術】
【０００２】
傷害を生じる多くの訓練の際に医療事故が発生しているということは重大な問題である。
【０００３】
典型的で悲劇的な例としては、避けることができる医療事故による、現時点で負傷を除いて、年間約１８，０００人の死者がでると推定されているオーストラリアでの健康産業がある。この問題は、この業界においては明らかに非常に大きな問題であり、他の訓練または産業も同じような被害を出していることが十分理解される。
【０００４】
また、このような医療事故を最初に検出するのが難しいのは、また検出した場合ですら分析するのが困難であるのは多くの理由によるものであり、そのためこれらの数字を低減したいと思っている人々により、何か役に立つことをすることができると考えられている。その基本的性質により、これらの医療事故は故意によるものではないが、怠慢によるものであると分類される場合があり、発見され、個人または団体にその責任が課せられた場合には、損害賠償の問題が起こる恐れがある。しかし、さらに、この問題を軽減する際に、２つ以上の効果を持つ解決方法により処理することができる場合がある共通の原因を識別するのは難しい。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の１つの目的は、少なくともある程度これらの問題のうちの１つまたは複数を軽減することである。
【課題を解決するための手段】
【０００６】
ある態様においては、本発明は、医療事故を収集し、分類するステップを含む、避けることができる潜在的に有害な医療事故データの分析を助けるための方法を提供する。この方法は、
回答を求める質問の形で階層的な一連の返答要求の最初のものを表示するステップと、
上記第１の各返答要求に対して、複数の一般的返答識別子のデータベースから選択した一般的返答識別子を選択し、次に、上記１つまたは複数の選択した１つまたは複数の一般的返答識別子を使用して上記第１の返答に対して階層的なもう１つの返答要求質問のデータベースから選択を行うステップと、
上記または選択した各一般的返答識別子に関連するように選択される、選択した他の返答要求質問を表示するステップと、
返答要求および１つまたは複数の返答識別子の階層を識別するのに十分な情報を記憶するステップとを含む。
【０００７】
他の態様においては、本発明は、医療事故を収集し、分類するステップを含む、避けることができる潜在的に有害な医療事故データの分析を、助けるための方法を実行するようにプログラムされているコンピュータ内に常駐している方法ということができる。この方法は、回答を求める質問の形で階層的に配置されている一連の返答要求のうちの最初のものを視覚的出力として表示するステップを含み、
コンピュータは、複数の一般的返答識別子のデータベースから選択した１つまたは複数の分類識別子の上記第１の各返答要求回答に対してある選択を行い、次に、１つまたは複数の選択した１つまたは複数の一般的返答識別子を使用して上記第１の返答のコンテキストの後に続くもう１つの質問のデータベースから選択を行うステップと、
次に、上記または各選択した一般的返答識別子に関連するように選択される選択した他の返答要求質問を表示するステップと、
返答要求および１つまたは複数の返答識別子をランク分けする際の階層またはシリーズを識別するのに十分な情報を記憶するステップとを含む。
【０００８】
好適には、１つの医療事故に関連している階層的な一連の返答要求は２つ以上であることが好ましい。
【０００９】
好適には、１つの階層的シリーズの返答要求および対応する返答識別子の組み合わせは分類構造であるということができるものであることが好ましい。
【００１０】
好適には、返答要求は、特定の産業または医療事故のタイプのために選択した階層的医療事故モデルが指定する返答要求であることが好ましい。
【００１１】
好適には、収集する医療事故データは、健康管理（ｈｅａｌｔｈ  ｃａｒｅ）医療事故データであることが好ましい。
【００１２】
好適には、階層的医療事故モデルは、ランシマン・モデル（Ｒｕｎｃｉｍａｎ  ｍｏｄｅｌ）であることが好ましい。
【００１３】
さらに他の態様においては、本発明は、
階層的な一連の返答要求のうちの最初のものを表示し、次に
上記要求に応じてデータベースから複数の一般的返答識別子のうちの１つまたは複数を選択し、
上記選択が、選択した一般的返答識別子に関連する選択した他の返答要求の表示を行い、
次に、返答要求および返答識別子の階層を識別するのに十分な情報を記憶し、
これらのステップを反復して、ある医療事故についての他の情報を引き出すように配置されているコンピュータ・システム内に常駐するものということができる。
【００１４】
好適には、コンピュータ・システムは、医療事故の報告および分類構造を容易に構成することができるように、データ・エントリ・フォームおよび結果としての分類を一緒に表示することができることが好ましい。
【００１５】
好適には、分類構造の選択したカスケード状のブランチは、必要に応じて他の分類構造で再使用することが好ましい。
【００１６】
好適には、各分類構造は、選択した数の一次分類部門を含むことが好ましい。
【００１７】
これらの分類部門は、「誰が／どこで／何を／いつ／何故／どうして」、「詳細」、「誘因」、「予防」および「結果」を含むことができる。
【００１８】
好適には、コンピュータ・システムは、分類階層の集中制御および修正を受け入れることができるものであることが好ましい。
【００１９】
好適には、一般的返答識別子の選択を行うことができるように表示されるテキストは、ユーザが選択可能な言語で書かれていることが好ましい。
【００２０】
好適には、一般的返答識別子の選択を行うことができるように表示されるテキストは、ユーザが選択可能な記述基準であることが好ましい。
【００２１】
さて、任意の入力返答を一般的な識別子へ変更することにより、報告言語、スタイルおよび訓練内の種々様々な変化を返答中に受け入れることができる一方で、依然としてその後で効果的で効率的な分析を行うことができることを理解することができるだろう。例えば、ある地域のある人が皮膚の損傷という用語、または種々の方言を含むこの言葉に対するフランス語の他の用語を使用した場合には、大規模な分析の場合、普通の医療事故に対してある論理的および効率的検出方法を行うのが実際非常に難しくなることを理解することができるだろう。最初に、これらの言語を共通の一般的な識別子にし、選択した１つの階層の下で任意のシリーズ内に質問を行い、直前の返答に基づいて論理的進行に追随しさえすれば、この主要な改善を行うことができる。
【００２２】
例えば、広範なものであると同時に、すべての必要な可能性をカバーしていて、綿密な分析のために必要なすべての詳細を含んでいるという点で詳細な健康産業の階層的分類構造の大きさは、当然非常に大きなものである。
【００２３】
健康管理医療事故分類用のランシマン・モデルの場合には、分類ツリー内に無数のブランチが存在する。コンピュータ・システムは、効率的で実用的な方法で、非常に大きな階層的分類構造を維持し、ユーザに提示できるようになっている。より詳細に説明すると、医療事故分類データを入力し、閲覧するユーザは、非常に大きな階層的分類構造の無関係な任意の部分を見なくても、上記の入力および表示を行うことができる。このことは、医療事故報告に費やす時間を短縮するという利点がある。医療事故分類を入力する際にスタッフが費やす時間はかなり長いものであり、そのための人的資源が十分でない場合には、分類タスクをバイパスされる恐れがある。
【００２４】
好適には、ユーザにコンテキスト感知可能ヘルプおよび修正使用法についての命令を供給するための規則を使用することが好ましい。規則は、階層項目の入力の際にデータベース内に入力され、以降の任意の時点で、ユーザ指向非ＩＴスタッフによりさらに修正することができる。この設計は内蔵されていて動的性質を有しているので、正確なデータ補足を容易に行えるという利点を有する。
【００２５】
分類構造についてデータ・エントリ・フォームの定義のために同じ階層的構造を使用すると、プログラム、データおよび使用方法の一貫性が改善されるという非常に有意な利点がある。データ・エントリ・フォーム設計は、コンピュータ・プログラムを全然変更しないで、またコンピュータ・プログラミングの専門知識を持たないスタッフにより行うことができる。
【００２６】
健康産業用の階層的分類構造は、健康医療事故分類の分野での多くの研究および経験により開発されたものである。分類のいくつかの部分は、例えば、投薬のような健康産業内の規格であるサブ分類を含んでいるが、全体としての分類の内容は、革新的なもので開発するのにコストが掛かり、そのため独占的なものである。
【発明を実施するための最良の形態】
【００２７】
本発明の原理の理解を促進するために、この時点で図面の実施形態を参照し、この実施形態を説明するために特定の言語を使用する。しかし、これら特定の言語は本発明の範囲を制限するものでないことを理解されたい。上記実施形態のすべての変更および他の修正、および本明細書に記載する本発明の原理の任意の他の適用は、本発明が関連する当業者であれば、通常思い付くものであり理解できるものと考える。本発明を説明するためにある実施形態を詳細に図示するが、当業者であれば、本発明と無関係な特徴のうちのいくつかは、図面を分かり易くするために省略してあることを理解することができるだろう。
本発明を説明するために、多数の例示としての画面／フォームを使用する。本発明は、図面に示す画面／フォームに限定されないことに留意されたい。理解してもらえると思うが、本明細書に記載するものとは異なる追加のおよび／または別の組み合わせを含む画面／フォーム設計も使用することができる。
【００２８】
図１は、医療事故に関連する健康管理の記録および分類のためのコンピュータ実行システムの好ましい実施形態である。最初に、このシステムを簡単に説明し、その後で多数の例示としての図面および説明で示すシステムの一実施形態をさらに詳細に説明する。
【００２９】
図１を参照すると、この実施形態の場合、医療事故に関連する健康管理の記録および分類のためのコンピュータ実行システムは、参照番号１で示すシステムである。このシステムは、これらの説明で識別する機能を一緒に供給する、一連のコンピュータ実行ソフトウェア・プログラムを備える。このシステムは、この実施形態による参照番号２で示すデータベースと呼ばれるデータベース内に医療事故データおよび分類データを記憶する。ソフトウェア・プログラムは、その機能を実行する際に、この実施形態によりデータベースと相互に作用する。この実施形態によるこのシステムおよびデータベースは、参照番号３に示すようにコンピュータ上で実行される。本発明のこの実施形態の場合には、以下の例示としての図面に示すように、このシステムは、マイクロソフト・ウィンドウズ（登録商標）動作環境（米国ワシントン州レドモンド所在のマイクロソフト社）で実行され、データベースはマイクロソフトＳＱＬサーバ（商標）内で実行される。当業者であれば、このシステムを他の動作およびデータベース環境で実施することができることを容易に理解することができるだろう。
【００３０】
引き続き図１を参照すると、このシステムは、地方の病院、病院のグループ、ある地方レベルまたは州レベル、または実際に全国レベルまたは国際レベルで実施することができる。システム構成の種々の組み合わせがこれらの異なるシナリオをサポートする。一例を挙げて説明すると、病院６は、局地的にこの実施形態によるシステム１およびデータベース２を設置することができ、病院自身のネットワーク１０およびコンピュータ１１を通して、医療事故情報を記録し、分類することができる。他の実施形態の場合には、「領域」８は、この実施形態によりシステムおよびデータベースを実施することができ、ネットワーク５（インターネット、１つまたは複数のワイド・エリア・ネットワーク（ＷＡＮ）、ローカル・エリア・ネットワーク（ＬＡＮ）、専用ネットワーク、これらの組み合わせ、または当業者であれば周知の他のネットワークを含むことができる）を通してこの領域内の病院６、７へのアクセスを許可することができる。「ＰＣ」デバイス４は、地域的実施で医療事故情報を収集し、分類することができ、このようなデバイスは、実際に、医療事故情報の収集を必要とする病院または他の組織内に常駐することができる。この構成の場合、地域的実施は、またシステムおよびデータベースの局所的実施からデータを受信することができる。全国レベルの実施９も同様に柔軟に構成することができることを容易に理解することができるだろう。本明細書全体を通しての例示としての図面の場合には、病院６での簡単な設置について考える。
【００３１】
この実施形態によるシステムおよびデータベースは、健康管理医療事故情報を記録し、分類するために設計されたものである。このような項目の記録および分類の背後にある主な目的は、有害な医療事故の数を低減するために、健康管理の手順および実務を全体的に改善することである。はっきり言えることは、これには地方的な規模のものおよび全国的な規模のものがあるということである。何故なら、病院は地方的実務の変更によりその地方的医療事故を低減しようとしているし、政府は全国的規模で医療事故を低減しようとしているからである。医療事故の記録および分類の認識されている面のうちの１つは、いくつかの医療事故はある地方では非常に少ないという事実である。全国規模でデータを集計すると、そのことは、もちろん、そうでない場合には、見逃されてきた手順および実務の変更を識別することができる、より大きな統計上の意味を示すことができる。
【００３２】
図２は、それにより医療事故情報を集計し、解釈２４し、次にシステム２３で使用するために改訂した分類の開発にフィードバックされる広範なプロセスを示す。２２で識別された医療事故を、電子手段または他の手段の範囲である多数の機構２１を通して報告することができる。医療事故データは、システムを通して収集され、個人識別解除された（ｄｅ−ｉｄｅｎｔｉｆｉｅｄ）（すなわち、個人の識別が除去され、無名になった）データが、内部組織団体、または地域的患者安全機関、国家／政府機関または国際団体を含むが、これらに限定されない他の第三者であってもよい団体２４に送られる。団体２４からの結果は、国家政策指導要綱、医療事故統計、病院実地指導要項およびその他多くのもののように種々様々の場合がある。しかし、本発明のこの実施形態に関連する要素は、分類構造２５への推奨強化である。この推奨強化は、次にシステム内で実施され、医療事故記録および分類を改善する。システムは、２つの主要な機構、すなわち、ａ）集計のためにデータを抽出する機能、ｂ）分類システムに強化を内蔵させるための機能により、この反復分類強化アプローチをサポートする。これらについては、下記のシステム機能の説明のところで詳細に説明する。
【００３３】
すでに説明したように、システム１は、一緒に本明細書に記載する機能を供給する一連のコンピュータ実行ソフトウェア・プログラムを備える。システム１は、この実施形態によるデータベースと呼ばれるデータベース２内に、医療事故および分類データを記憶する。ソフトウェア・プログラムは、その機能を実行する際に、この実施形態によるデータベース２と相互に作用する。本発明のこの実施形態においては、システム１の機能は、すべてこの実施形態によるデータベース２上で動作する個々の機能モジュールに分割されるが、当業者であれば、この機能は他の実施形態に異なる方法で内蔵させることができることを容易に理解することができるだろう。図３は、システム１の主モジュール構造３１であり、モジュールによりサポートされ、これらの詳細な実施形態の説明に記載する主機能（参照番号３２で示す）を識別する。本発明のこの実施形態の場合には、モジュールは階層的構造発生および管理モジュール３２、データ・マネージャ３３、分析装置３４、ワークフロー・マネージャ３５、アドミニストレータ３６、データベース・アドミニストレータ３７、ウェブ・フォーム３８、エージェント３９、エクスポート４０および根本原因４１である。
【００３４】
システムは、医療事故データ収集および分類を容易に行うことができるように設計されているが、その基本は、図４に示し、この実施形態の場合にはランシマン・モデル４２と呼ばれている一般的な参照モデルである。このモデルは、健康管理医療事故を正しく識別し、分類するのに必要であると思われる基本構成要素について記述している。システムは、医療事故データ収集分類学および医療事故分類分類学の両方を表す拡張可能な階層的構造の形で、この一般的な参照モデルを実施する。好ましい実施形態の詳細な説明を読めば分かるように、これらの分類学は、システム機能および行動の基本構成要素である。
【００３５】
システム１は、医療事故および分類データをデータベース２内に記憶する。このデータベースのコア部分は、本発明を支持する拡張可能な階層的構造の表示である。図５は、分類学、医療事故データおよび分類データを機密保護環境で記憶するために、本発明のこの実施形態ですでに使用しているデータベース構造の１つの例示としての図面の高いレベルの図面である。分類学は「用語」５２と呼ばれる一般的返答識別子、「フォーム」５３と呼ばれる一般的返答要求グループ、および「分類階層」５４を含むがこれらに限定されない一連のエンティティに記憶される。これらのエンティティは、データ・エントリ・フォームを通して医療事故情報を、分類質問を通して分類情報を構造捕捉するために、データ・エントリ５６および分類５７エンティティにより使用される。これらの行動の結果は、医療事故記録５８に記憶される。医療事故記録５８は、医療事故分析５５の際に使用される。データ・エントリ５６、分類５７および医療事故分析５５は、すべてユーザ内で組織および許可を各エンティティ５６、５７、５５にリンクする参照番号５１で示す許可構造を通して入手される。
【００３６】
当業者であれば、このハイレベルの図面内のエンティティの配置は、本発明の一実施形態であり、当業者であれば他の実施形態を思い付くことができることを容易に理解することができるだろう。
【００３７】
医療事故の分類は、本発明の基本的な機能のうちの１つである。これについては、下記の例示としての説明のところで説明する。ランシマン分類モデル４２の上記説明を参照しながら、本発明のこの実施形態は、拡張できる階層的分類構造の形で分類コンセプトを実施する。図６０、図６１、図６２および図６３は、一般的な構造化コンセプトを示す。本発明のこの実施形態の場合には、階層的構造の最高のレベルのところで、「分類のグループ分け」６２が行われる。この分類のグループ分けは、もっと低いレベルの分類を論理的グループに配列および配置するのに便利な手段であり、この例示としての図面の場合には、「治療薬／栄養」分類グループ分け６１は、「投薬／ＩＶ流体」６３、「血液および血液製品」６４、「酸素／ガス／蒸気」６５、「栄養」６６に対するもっと低いレベルの分類を含むことを理解することができるだろう。これらは、「治療薬」または「栄養」要因、それ故、この「分類グループ分け」６１内のその関連のすべての形である。このレベル（「投薬／ＩＶ流体」６３、「血液および血液製品」６４、「酸素／ガス／蒸気」６５、「栄養」６６）での分類は、本発明のこの実施形態の場合には「ＨＩＴ」（「健康医療事故タイプ」）と呼ばれる。この例示としての図面は、分類グループ分けへの分類の配置の制限を意味するものでないことを理解されたい。
【００３８】
「投薬／ＩＶ流体」分類ブランチ６３の後は（この時点から先は、「分類ブランチ」という句は、「ＨＩＴ」と同義に使用することができ、ＨＩＴを分類ブランチと同義に使用することができる）図７に続く。図７の例を見れば、「投薬／ＩＶ流体」分類６３は、多数のもっと低いレベルのブランチを含むことが分かる。この例示としての図面の場合には、これらブランチは、「どこで／いつ／どうして／誰に」６７、「詳細」６８、「誘因」６９、「予防」７０、「最小化要因」７１、「行った処置」７２、および「結果」７３である。本発明のこの実施形態の場合には、分類階層のこのレベルのブランチは、「一次分類部門」７４と呼ばれる標準化部門である。これらの一次分類部門７４は、すでに説明したランシマン分類モデル４２の主要構成要素を反映している。「どこで／いつ／どうして／誰に」６７部門を選択すると、本発明のこの実施形態の場合には、図８に参照番号８１で示す「主な質問」と呼ばれる第１のレベルの階層的分類質問のところへ行く。階層構造は拡張することができるので、このレベルには多くのこのような分類質問８３を含むことができる。分かり易くするために、主な質問８１は、質問をするために階層的構造のこのコンテキストで使用する「用語」５２の一例である。この例示としての図面の場合には、この図は、用語５２の「医療事故はどこで起きたのか」８２が、医療事故の位置の詳細についてユーザに質問するコンテキストで使用されたことを示す。同様に、「医療事故がどこで起きたのか」より下のもっと低いレベルのブランチ、ノードおよびリーフは、図９の参照番号９１が示すように、その医療事故の増大する特定の定義を供給する際のコンテキストで使用した用語５２である。階層的構造は拡張することができるので、所望のレベルの分類を達成するために、増大する特定の質問をする多くのこのようなサブブランチ、ノードおよびリーフを含むことができる。階層の拡張性は、本発明のこの実施形態の基本的なコンセプトであり、これにより定義した用語を階層構造の任意のところで表示することができ、それに対するコンテキストは用語の絶対コンテキスト定義を供給する。上記の用語について説明すると、用語は制限的なものでなく、用語は、語、または質問、句、名称または他の類似の抽出概念である。図１０は、単に用語に対する絶対コンテキストのこの原理を示す。この図は、一方は医療事故自身の詳細に関連し、他方は医療事故内である役割を果たしたかも知れない誘因に関連する２つのはっきりと異なるコンテキストを含む例示としての分類階層１０１の一部を示す。この場合には、たまたま薬剤「アセタゾラミド」１０２である用語５２は、すでにシステム内で定義されている。図を見れば、用語５２が、分類で２つの全く異なるコンテキストで使用されたことは明らかである。すなわち、一方の場合には、どの薬剤が過剰に投与されたのかを識別するために使用され、他方のコンテキストの場合には、その薬剤が処方により患者に投与され、そのため過剰投与という医療事故の誘因であったことを示すために使用された。用語「アセタゾラミド」１０２にナビゲートするために横切ったいくつかのブランチが、それぞれの場合で全く異なることは明らかである。このことは、階層的分類構造で必要とする場合には、用語を任意の回数使用することができること、および用語の各例のコンテキストは全く異なるものであることを示す。それ故、この例を見れば、システムが、融通のきかない構造を有しているのではなく、代わりに分類目的の必要に応じて、多くの用語および用語のコンテキストの特定の例を含むように拡張することができることがはっきり分かる。
【００３９】
すでに説明したように、この実施形態の場合には、システム１は、システムの特定の機能を提供するいくつかのモジュールを含むモジュラ・タイプである。ここでは階層的構造生成および管理モジュール３２に関連する、本発明のこの実施形態の主な特徴について説明する。その主な目的は、本発明を支持しているデータ項目および階層的構造の生成、修正および管理をできるようにすることである。図１１は、ユーザが、システムの階層的構造生成および管理モジュールをスタートした場合に生成される「ようこそ画面」である。モジュール内で機能的行動を行うためには、ユーザは、好ましい実施形態の場合には、コンピュータ・マウスまたは類似のオンスクリーン・ポインティング・デバイスである入力デバイスにより、オープン・ボタン１１１を「押し」たりまたは「クリック」して、最初にログオンしなければならない。オープン・ボタン１１１が作動すると、ログオン画面が図１２に示すように表示される。ログオン画面は、ユーザに、サーバ１２１、データベース１２２、ユーザ１２３およびパスワード１２４でログオン信任状を入力するように要求する。その詳細については、システム１のアドミニストレータによりユーザにすでに説明してある。この画面に有効な信任状を入力すると、ユーザは、主階層的構造生成および管理モジュールの機能にアクセスすることができる。図１１に戻って説明すると、ユーザは、参照番号１１５で示すボタンを押すことにより、階層的構造生成および管理モジュールの他の管理面と一緒に、データ要素を生成し、編集し、また維持するために多数のオプションを選択することができる。この例示としての図面の場合には、例えば、ヘルプ１１３（初心者にテキストによるオン・スクリーン・ガイドおよび支援を提供する）およびエクシット１１４（モジュールをクローズし、それによりシステムから抜け出るための）のような当業者であれば他の実施形態に同様に内蔵させることができると思われるシステムの一般的な特徴および機能ではなく、本発明の基本原理およびコンセプトをサポートする階層的構造生成および管理モジュールのこれらの要素を重点的に説明することに留意されたい。設計ボタン１１２をクリックすることにより、図１３に示すように、ユーザは、階層的構造生成および管理モジュール内の主データ要素維持画面を選択する。
【００４０】
主データ要素維持画面は、さらに２つの主要なセクション、「ドメイン構造」１３２および「ノード特性」１３３に分割される。この画面の頂部には多数の機能ボタン１３１が配置されていて、これらのボタンにより、ユーザはそれぞれ新しいデータ要素項目を生成し、データ要素項目を編集し、データ要素項目位置を管理し、用語データ要素を管理し、データ要素の別の提示を表示し、データ要素定義をデバッグし、コンテキスト内のヘルプ情報を表示し、また階層的構造生成および管理モジュールをクローズすることができる。
【００４１】
「ドメイン構造」セクション１３２は、システム・データベース内に保持されているデータ要素の視覚的表示を含んでいて、この実施形態の場合には、この視覚的表示は、本明細書内の以下の説明を読めば分かるように、拡張可能な階層ツリーの形をしている。「ノード特性」セクション１３３は、ドメイン構造セクション１３２内に示す各データ要素の属性を含む。各データ要素の属性は、入力デバイスによりクリックして、「ドメイン構造」セクション１３２内のある項目を選択すると表示される。ドメイン構造セクション１３２からのいくつかのタイプのデータ要素は、選択した項目によりノード特性セクション１３３内にいくつかの属性を示す。
【００４２】
本発明の基本原理は、ドメイン構造セクション１３２内に示すように、ドメイン構造におけるデータ要素の定義および配列である。これにより、システムは柔軟なデータ収集およびデータ分類機能を有することになる。データ要素の配列は、根、幹、枝および葉を含む自然界の樹木に類似している拡張可能な階層的構造を形成する。この類比により、樹木の枝や葉の成長性と同じデータ要素の階層的構造の拡張性を理解することができるだろう。この実施形態の場合には、ブランチ、ノードおよびリーフという用語は、階層的なデータ要素の配置を記述するために使用される。この場合、ブランチはすべての接合部を意味し、ノードは階層のすべての中間レベルを意味し、リーフは詳細の最も低いレベルを意味する。図１０は、このコンセプトの例示としての図面である。
【００４３】
このツリーを形成するデータ要素は、最初にシステム１の基本用語５２として生成される。用語は、制限的なものではなく、語であっても、または質問であっても、句であっても、名前であっても、または他の類似の抽象概念であってもよい。類似のものとして、「用語」を、例えば、英語の語および句と同じものであると見なすことができる。これらの用語は、本発明のこの実施形態でのその異なる使用方法を表す論理的タイプにグループ分けされる。図１４は、参照番号１４２で示す本発明のこの実施形態で定義した用語のいくつかの例を示し、またこの例の場合には、グループ分け「医療事故タイプ」１４３による用語の基本的なグループ分けを示す。システム内に定義した用語のリストは、必要に応じて追加する新しい用語により拡張することができることを理解されたい。リストへの新しい用語の追加は、新しいボタン１４１をクリックし、必要に応じて画面の一番下のグループ１４５、用語１４６、コメント１４７の詳細を完了することにより行われる。
【００４４】
用語１４４を定義すると、その用語はすでに説明し以下に詳細に説明する階層的構造で使用することができる。図１５は、階層的構造の一番上のレベルの典型的実施形態を示す。この図を見れば分かるように、この実施形態の場合には、ツリーの一番上のレベル、すなわち根は、「ドメイン」１５１と呼ばれる。根の下には、この例示としての主要なブランチ１５６が位置する。リストはこの図に示すこれらブランチに限定されずに、必要に応じて他にいくらでもブランチを定義することができるように拡張することができることを理解されたい。本発明のこの実施形態の場合には、編成のためまた便宜上、多数の主要なブランチが標準化されている。これらの主要なブランチは、「＜グローバル・リソース＞」１５２、「医療事故報告」１５３、「リスク・レジスタ」１５４、「分類」１５５である。分かりやすくするために、これらの標準化したブランチの使用方法についてここで説明する。「＜グローバル・リソース＞」１５２ブランチは、「データ・エントリ・フィールド」への用語１４４の定義および配列を含む。（当業者であれば、通常、「フィールド」は、システムのデータ処理のために、ユーザ入力デバイスからデータを捕捉し、この捕捉したデータを一時的にまたは永久に記憶するための手段であることを知っている。また、「フィールド」という語は、セクションおよびタブ・ページ内にグループ分けされたフィールドに関してはもっと一般的に使用される。）「医療事故報告」１５３ブランチは、「データ・エントリ・フォーム」（当業者が、データ・エントリ・フィールドのオン・スクリーン配列を意味すると通常理解している「フォーム」）の収集を含む。「リスク・レジスタ」１５４ブランチは、「リスク」のフィールド内の精通している人が、リスク査定、評価および管理プロセスを意味すると広く理解しているコンセプトに関連するフォームの収集を含む。「分類」１５５ブランチは、システムが記録した医療事故の分類に関連する用語１４４の階層的配列を含む。
【００４５】
今説明した主要な各ブランチは、オン・スクリーン・ポインティング・デバイスでそのブランチをダブル・クリックすることにより拡張することができる（「ダブル・クリック」は、ポインティング・デバイスでオン・スクリーン選択を確認する１つの形である。本発明の他の実施形態の場合には、ダブル・クリックは、異なるデバイス指定手段により行うことができる）。ダブル・クリックすると、図１６に示すように、そのブランチは次のレベルの下の詳細に対して開く。この例示としての図面の場合には、それぞれがもっと低いレベルのブランチ、「＜グローバル・データ・エントリ・フィールド＞」１６１および「＜アセンブリ＞」１６２を含む２つのブランチが存在する。
【００４６】
最初に、「＜グローバル・データ・エントリ・フィールド＞」１６１ブランチについて説明すると、このブランチを「ダブル・クリック」すると、図１７に示すようにこのブランチが開き、もっと下のレベルのブランチ、ノードおよびリーフが表示される。図１７を見れば分かるように、この視覚的表示には、多くのこのようなもっと下のレベルのブランチ、ノードおよびリーフが含まれていることが分かる。図１７は、このような例示としての配置を１つだけを示す。この配置の場合には、システムで生成された用語１４４は、この場合、「データ・エントリ・フィールド」を定義するために使用される。新しいデータ・エントリ・フィールド１７４は、新しいボタン１７１をクリックし、図１４のリストから適当な用語１４４を選択し、それを現在のブランチに追加することにより階層図の任意の点で生成することができる。次に、データ・エントリ・フィールドの属性情報が完成し、「タイプ」１７５のところでフィールドのタイプのような属性を含むデータ・エントリ・フィールドの行動を指定する。ブランチ、ノードおよびリーフの視覚的表示を見れば、異なるアイコン１７３は、階層内に定義されているフィールドの異なるタイプを表すことが分かる（当業者は、通常、「アイコン」がそれが関連するオブジェクトを絵画的にまたは抽象的に表す小さな絵画的要素を意味することを知っている）。このような「アイコン」表示は、さらに、異なるタイプの要素を示すために本発明のこの実施形態全体を通して使用される。また、データ・エントリ・フィールドは、消去ボタン１７２を使用することにより、階層図の任意の点から除去することができ、編集プロセスをスタートするために、編集ボタン１７６によりデータ・エントリ・フィールドを編集することができる。
【００４７】
次に、図１６の「＜アセンブリ＞」１６２ブランチについて説明すると、このブランチをダブル・クリックすると、それが開き、図１８に示すように、もっと下のレベルのブランチ、ノードおよびリーフが表示される。本発明のこの実施形態の場合には、「アセンブリ」１６２は、使いやすくするために生成された階層的構造の再使用可能なセクションである。データ要素が全階層的構造の２カ所以上の場所で使用される可能性があると考えられる場合に、アセンブリ１６２を生成することができる。説明のために、ユーザが一方では故障したある装置を記述することができるように、他方では人を打ったある装置を記述することができるようにするために、階層内の多くの場所で、例えば、ある装置、その特性およびその構成要素の定義が必要になる場合も考えられる。都合の良いことに、アセンブリ１６２内に装置の複数の品目の定義を配列すると、全階層内の複数のコンテキストで１つの装置の定義を再使用することができる。図１８を見れば、本発明のこの実施形態の場合には、この図の参照番号１８１が示すように、用語１４４のもっと多くの階層的な配列と一緒に、装置、投薬、身体の各部、位置のような情報の種々のリストを保持するためにアセンブリ１６２を使用することができることは明らかである。当業者であれば、このようなリストは、この例示としての説明のためのものであって、そのため本発明の制限の明示的定義でないことを理解することができる。「＜グローバル・データ・エントリ・フィールド＞」１６１のところで説明した方法により、新しいアセンブリを容易に構成することができるし、または現在のアセンブリを容易に編集することができる。
【００４８】
再び図１５および「医療事故報告」ブランチ１５３について説明するために、以下に、階層的構造のデータ・エントリ・フォームを生成し、維持するための好ましい実施形態の機構を説明する。ここで生成するデータ・エントリ・フォームは、データ・マネージャ・モジュール３３を含むがこれに限定されない他のシステム・モジュールで使用するためのものである。「医療事故報告」ブランチ１５３をダブル・クリックすると、このブランチが開き、図１９に示すように、もっと低いレベルのブランチが表示される。この例示としての図面の場合には、グループ・ヘッディングの下にリストの形で示すグループ１９２に属するデータ・エントリ・フォーム１９５と一緒に、データ・エントリ・フォーム１９１、１９２、１９３および１９４のグループを表す多数の中間ブランチが位置する。「ニューサウスウェールズのデータ・エントリ・フォーム」グループ１９２内の「患者医療事故」ブランチ１９６をダブル・クリックすると、それが開き、図２０に示すように、「患者医療事故」データ・エントリ・フォームを定義する次のレベルのブランチが表示される。この図の場合には、このブランチ・レベルのところにリストの形で表示されている２つの項目、すなわち、「通知」２０１および「管理」２０２が存在する。これら２つのブランチは、データ・マネージャ・モジュール３３の「患者医療事故」データ・エントリ・フォーム内に別々の「タブ」または「タブ・ページ」として表示されるタイプ属性を有する（当業者は、通常、「タブ」または「タブ・ページ」が、通常、前面に主フォームを含み、残りのフォームが背後に隠れていて、「タブ」と呼ばれる主フォームの頂部または側部のところの突き出ている説明またはボックスによりアクセスすることができる２つ以上のフォームとしての大きなフォームの視覚的表示を意味することを知っている）。各ブランチ内には任意の数のブランチが位置していること、および「タブ」はそれにより大量の情報をユーザに便利な提示に編成することができる機構のうちの１つに過ぎないことを容易に理解することができるだろう。
【００４９】
図２０も、「患者医療事故」データ・エントリ・フォーム内の例示としての「通知」２０１タブ・ページのセクションを定義する階層ブランチ２０３を示す。これらのブランチは、それぞれがセクション・ヘッディングおよび１つまたは複数のデータ・エントリ・フィールドを含む別々のセクション２０３として表示されるタイプ属性２１２を含む。セクション２０３のタイプ属性２１２は、また、これらタイプ属性を常に表示するのか、または指定の医療事故タイプ１９４に対してだけ表示するのかを指定する。「投薬／ＩＶ流体」ブランチ２０４をダブル・クリックすると、このブランチが開き、図２１に示すように、もっと低いレベルのブランチ、ノードおよびリーフ２１１が表示される。もっと低いレベルのブランチ、ノードおよびリーフは、それぞれ、フォームのセクション２０３内に前に定義したデータ・エントリ・フィールド１７４を指定する。
【００５０】
図１９を参照すると、データ・エントリ・フォームの新しいグループおよび個々のデータ・エントリ・フォームは、階層的構造のあるブランチをクリックし、新しいボタン１７１をクリックすることにより容易に生成することができる。図２２の例示としての図面の場合には、データ・エントリ・フォーム・グループ「ニューサウスウェールズ・データ・エントリ・フォーム」２２２ブランチが選択され、新しいボタン２２１がクリックされ、そこから好適な用語２３３を強調し、「用語追加」ボタン２３２をクリックすることにより、データ・エントリ・フォーム名を選択することができる、前に定義したデータ・エントリ・フォーム２３１のリストを表示している図２３の用語選択画面が開く。セーブ・ボタン２３４をクリックすると、新しいデータ・エントリ・フォームのための用語２３３が、現在選択しているブランチ内の他のデータ・エントリ・フォームと一緒に表示される。用語定義の上記説明を参照すると、この例示としての図面の場合には、「データ・エントリ画面」セクションである図１４の用語リスト１４２の適当なセクション内に用語が生成されていなければならない。
【００５１】
図２０を参照すると、例えば、「通知」２０１のような現在のブランチ・リストから「データ・エントリ・フォーム」を選択し、新しいボタン２０５をクリックすることにより、「データ・エントリ・フォーム」上に「データ・エントリ」フィールドを生成することができる。そうすることにより、挿入データ・エントリ・フィールド画面を図２４に示すように表示することができる。この例の場合には、「セキュリティ医療事故」２４２である「データ・エントリ・フィールド」リスト２４３からデータ・エントリ・フィールドまたはアセンブリを選択すると、クリックした場合、「データ・エントリ・フィールド」、ブランチ、または「アセンブリ」を「選択したフィールド」パネル２４５に追加する「追加フィールド」ボタン２４４が作動できるようになる。この例の場合には、「データ・エントリ・フィールド」リスト２４３からのすべての「セキュリティ医療事故」ブランチ２４２がすでに追加されている。セーブ・ボタン２４１により定義をセーブすると、図２５の参照番号２５３で示すように、選択したフィールドがデータ・エントリ・フォーム内に入る。そうしたい場合には、データ・エントリ・フォーム内に位置する「データ・エントリ・フィールド」、ブランチまたは「アセンブリ」のうちの任意のものを、「編集」ボタン２５１または「削除」ボタン２５２により編集または削除することができる。
【００５２】
再度図１５および「リスク・レジスタ」ブランチ１５４について説明する。本発明のこの実施形態の場合には、「リスク・レジスタ」は、システム内の他のすべてのデータ・エントリ・フォームの方法で構成されたデータ・エントリ・フォームであるが、査定、評価および管理情報に関連するリスクを特に捕捉するために別々に識別される。「リスク・レジスタ」ブランチを選択した場合、図２６を見れば分かるように、リスク・レジスタ・データ・エントリ・フォーム２６１は、単に例示としてのものであって、それが意味するリスク・レジスタの範囲に限定されない。
【００５３】
図１０に示し、すでに説明した階層的分類構造のコンセプトは、本発明の一番上のレベルの「ドメイン」図１５の下に位置する「分類」主ブランチ１５５内で実施される。「分類」主ブランチ１５５を選択すると、図２７に示すように、「分類グループ分け」２７１および「分類」２７２のリストが表示される。システムは定義された多くの「分類」（「ＨＩＴ」）を含むことができる。図２７は、例示としての図面のリストである。この例は分類の範囲を制限するためのものではない。実際には、本発明の好ましい実施形態の場合には、健康および安全についての医療事故の広範で綿密な分類を行うために実施したブランチの数は無数にある。しかし、階層的構造生成および管理モジュールの使用は、このような非常に多くのブランチを効率的にまた高い信頼性で管理し、使用できるように設計されている。
【００５４】
図２７の場合には、リストから「転落」分類２７２を選択すると、図２８に示すように、この分類のこのレベルに関連する一次分類部門７４が表示される。好ましい実施形態の場合には、一次分類部門７４は、「どこで／いつ／どうして／誰に」２８１、「詳細」２８２、「誘因」２８３、「予防」２８４、「最小化要因」２８５、「行った処置」２８６、および「結果」２８７である。これらのブランチを順次拡張すると、図２９に示すように、各一次分類部門７４に関連する「主な質問」が表示される。図２９のこの例示としての図面を見れば、各一次分類部門７４内に表示された主な質問が、異なるアイコン２９１および２９２を表示し、その違いは「主な質問」２９３および２９４が最初に生成された方法の関数であることが分かる。説明すると、矢印形のアイコン２９１は、本発明のこの実施形態の場合には、「主な質問」が、それ故、一連のすでに定義したサブブランチ、ノードおよびリーフを含むことができるアセンブリ（本明細書ですでに説明した）からのものであることを意味する。分類の定義中にアセンブリを使用することができるために、もちろん、大型で広範な階層的分類構造を生成する際に時間を短縮することができる。このことはまた使用方法を確実に一貫性のあるものにする。同様に、アイコン２９２は、前に生成した用語リスト１４２からの個々の用語により、その場でアセンブルしたブランチを意味する。「この医療事故はどのようにして検出されたか」ブランチ２９３を選択すると、図３０に示すように、このブランチの内容が表示される。この場合も、異なるアイコン３０１および３０２は、分類項目の異なるタイプおよび行動を意味する。
【００５５】
この例示としての図面の場合、「後で直接責任をとる人により」項目３０１は、チェックボックス・ユーザ返答フィールドとして機能する（当業者は、通常、「チェックボックス」は、クリックした場合、項目のリストからの非独占的選択を示すために通常使用される肯定的な選択を意味するチェックまたはチックマークを表示するオン・スクリーン・ユーザ返答データ・フィールドを意味することを知っている）。本発明のこの実施形態で使用される他の形のユーザ返答フィールドは、図３１に示すように、「ラジオ・ボタン」３１１および「テキスト・エントリ」３１２を含むがこれらに限定されない。（当業者は、通常、「ラジオ・ボタン」をクリックした場合、項目のリストからの排他的選択を示すために通常使用される肯定的な選択を意味するために陰影がつけられる丸いオン・スクリーン返答データ・フィールドを意味することを知っている。「テキスト・エントリ」は、通常、英数字のデータ・エントリを捕捉するためのデータ・フィールドであると理解されている）。図３０の図面を見れば、もっと低いレベルのブランチも、参照番号３０２で示すように、アセンブリを含むことができ、それ故、アセンブリとその場で定義した分類項目の任意の組み合わせを生成することができることを理解することができるだろう。このことは、階層的分類構造の柔軟で拡張できる性質を示している。
【００５６】
完全に理解してもらうために、分類項目をその場で生成するための機構について、図３２を出発点として使用して以下に説明する。新しい分類項目を生成するために、階層的構造のどのレベルを必要とするにせよ、階層内の１つのブランチ、ノードまたはリーフが、この例示としての図面においては、「転落」分類階層（ＨＩＴ）内の「どこで／いつ／どうして／誰に」一次分類部門７４で最初に選択される。新規項目を生成するためには、図３３に示すように、用語選択画面を表示するために、「新規」ボタン３２１がクリックされる。この例示としての図面の場合、用語リストの主な質問セクション３３１が、デフォールトで左のパネル内に表示される。何故なら、新規項目を現在生成しようとしている階層のこのレベルは、元来主な質問レベルであるからである。それ故、用語リストは、現在選択しているレベルにより異なるセクションにデフォールトすることを暗黙に示している。「使用可能用語」リスト３３２からある用語を選択し、「用語追加」３３５をクリックすると、その用語は「選択した用語」パネル３３４に追加され、その場合、セーブ・ボタン３３３をクリックすることにより、分類階層に付託することができる。同様に、分類項目、ブランチ、ノードまたはリーフを選択し、図３２の削除ボタン３２２をクリックすることにより、分類階層から分類要素を削除することができる。
【００５７】
上記の例示としての図面によるこの実施形態に記載する階層的構造は、この実施形態によるデータベース２に記憶される。システム１のすべてのモジュールは、その機能を実行する際に階層的構造を含むデータベース内に記憶している情報を使用する。
【００５８】
本発明のこの実施形態の場合には、現在のブランチ、およびそのもっと低いレベルのブランチ、ノードおよびリーフを印刷するために、印刷ボタン１７７により、階層的構造の任意の点で階層的構造を印刷デバイスに出力することができる。
【００５９】
本発明のこの実施形態での階層的構造の生成、操作および管理は、システムの階層的構造生成および管理モジュール３２の分野である。当業者であれば、この機能を異なる方法で他の実施形態に内蔵させることができることを容易に理解することができるだろう。
【００６０】
すでに説明したように、この実施形態の場合には、システム１は、システムの特定の特徴を提供するいくつかのモジュールを含むモジュラ・タイプのものである。ここで、データ・マネージャ・モジュール３３に関連する本発明のこの実施形態の主な特徴について説明する。その主な目的は、特に医療事故データ・エントリのためのデータ・エントリ施設を提供することである。図３４〜図５４は、データ・マネージャ・モジュール３３の好ましい実施形態である。このモジュールは、図１のシステム全体のコンテキストに示してある。
【００６１】
図３４は、ユーザがデータ・マネージャ・モジュールをスタートした場合に表示される最初の画面である。先に進むためには、ユーザは、最初にステップ３４１においてログイン・ボタンを選択し、有効なデータベース参照、ユーザ名およびパスワードを入力しなければならない。
【００６２】
データ・マネージャ・モジュール全体を通して、ユーザにすでに割り当てられているセキュリティ規則が、各ユーザが適当なデータおよび行動を閲覧および使用することを許可するために適用される。これらのセキュリティ規則は、アドミニストレータ・モジュール３６により、システム・アドミニストレータが定義する。ユーザが有効なユーザ名およびパスワードを入力するまで、ログイン３４１、ヘルプ３４４およびエクシット３４５ボタンだけが表示される。ユーザが有効なユーザ名およびパスワードを入力すると、医療事故ボタン３４２およびオプション・ボタン３４３が画面上に表示される。オプション・ボタン３４３により、ユーザは画面上のデータの広いまたは狭い画面のような好適なデータ表示オプションを選択することができる。当業者であれば理解できると思うが、システム全体を通してヘルプ・ボタン３４４およびエクシット・ボタン３４５は、ウィンドウをベースとするユーザ・インタフェースによりシステムの共通な通常の機能を実行する。
【００６３】
ユーザが医療事故ボタン３４２を選択した場合には、図３５に示す医療事故コンソール画面が表示される。この画面は、ユーザが正式に閲覧することができるすべての医療事故３５２のリスト３５１を含む。ユーザがこのリスト内の医療事故行３５２をクリックすると、画面の一番下の注パネルが、この医療事故のためにすでに入力されているすべての注３５３を表示する。この画面は、新規３５４、オープン３５５、コピー３５６、リンク３５７、注３５８、表示３５９、全部３６０、ワークフロー３６１および報告３６２というラベルがついているいくつかのボタンを含む。これらのボタンにより、ユーザは以下に説明する他の特定の行動を選択することができる。
【００６４】
ユーザが表示ボタン３５９を選択した場合には、図３６に示すように、表示選択画面が表示される。ユーザは、医療事故コンソール画面内に表示されている医療事故のリストを選択または制限するために、状態およびフラグ３６３、基本３６４または拡張３６５のラベルがついているタブのうちの１つを選択することができる。ユーザが全部ボタン３６０を選択した場合には、図３７に示すように全画面が表示される。全画面は、ユーザに各状態３７１を含むどれだけ多くの医療事故がデータベース内に存在するのか、および各フラグ値３７２を含むどれだけ多くの医療事故がデータベース内に存在するのかを示す。
【００６５】
ユーザが注ボタン３５８を選択した場合には、データ・エントリ・ボックスが表示され、ユーザは医療事故またはデータまたは両方についてのテキストを含むことができる医療事故注３５３を追加または修正することができる。
【００６６】
ユーザがリンク・ボタン３５７を選択すると、図３８の画面が表示され、ユーザは関連する医療事故間にリンクを確立または修正することができる。一例を挙げると、母親およびその乳児に影響を与える産科の医療事故がある。各リンクにはリンク名３８１が付けられ、リンクした医療事故の説明およびリスト３２８を、使用可能な医療事故のリスト３８３から選択することにより定義することができる。
【００６７】
ユーザが新しいボタン３５４を選択すると、新しい医療事故選択オプションが図３９に示すように表示される。これらのオプションは、ユーザが、医療事故データ・エントリ３９１、またはリスク・レジスタ３９２を選択することができるようにメニュー・リストの形で表示される。
【００６８】
ユーザがリスク・レジスタ３９１を選択すると、リスク・レジスタ・データ・エントリ画面が、図４０に示すように表示される。この画面により、医療事故リスク・データのエントリおよび維持を特定の医療事故データから区別することができる。例えば、リスク査定４０１、コスト有利分析４０２および再検討４０３のようなタブを使用することにより、またはヘッディング４０４の下のデータ項目をグループ分けすることにより、大量のデータが編成される。リスク・レジスタ画面の設計およびこの実施形態によるデータベース内へのリスク・レジスタ・データの記憶は、以下に説明する医療事故データのために使用するのと同じ方法により行われる。
【００６９】
ユーザが医療事故データ・エントリ３９２を選択すると、使用可能な医療事故データ・エントリ画面の第２のリスト３９３が表示される。これらの画面は、種々の一般的な目的または顧客の特定の要件に合わせて調整される。これらの画面は調整されるが、これらの画面は、すべて階層的構造生成および管理モジュール３２により一貫して生成され、階層的構造生成および管理モジュール３２の説明のところでさらに詳細に説明するように、１つの根本的データ定義構造に基づいている。
【００７０】
ユーザが、使用可能な医療事故データ・エントリ画面３９３の例えば患者の医療事故３９４のようなリスト内のあるエントリを選択すると、選択したデータ・エントリ画面が、図４１に示すように表示される。図４１、図４２、図４３および図４４は、例示としての患者医療事故データ・エントリ画面を示す。この画面は、好ましい実施の代表的実施形態であり、本発明の多くの特徴を示す。
【００７１】
図４１の患者医療事故データ・エントリ画面により、ユーザは新規の医療事故の詳細を入力することができる。この画面は横に並んでいる２つのセクションを含む。左側の画面４１１は、タブをクリックすることによりユーザが選択することができるタブ４１５および４１６により識別される２つのページ上の大きなまた種々の数のデータ・エントリ・フィールド４１４を含む。右側の画面４１２は、タブをクリックすることによりユーザが選択することができるタブ４１７および４１８により識別される１つまたは複数のページを含む。左右の画面の内容については、以下にさらに詳細に説明する。
【００７２】
左側のデータ・エントリ・フォーム４１１は、最初に、位置、時間および医療事故の記述および影響を受ける人を記述するデータを入力するための基本的なフィールド４１４だけを表示する。これらのフィールドは、最初空白であり、図４２、図４３および図４４は、医療事故を入力した後の患者医療事故データ・エントリ画面のいくつかの例のうちの一例である。多くのフィールドは、ユーザがフィールドに入力することができる値のリストを表示するためにユーザが選択することができるボタン４１９を含む。値のリストの多くは、ユーザがリスト内の２つ以上の値を選択することができる図４５に示すような多重選択リストである。例えば、図４６のリスク・データ・エントリ・マトリックスのように、値のあるリストは複雑なものである。また、多くのフィールドも疑問符がついている規則ボタン４２０を有する。ユーザが規則ボタン４２０を選択すると、図４７に示すようなテキスト４７１の適当なブロックが表示される。表示されたテキスト４７１は、階層的構造生成および管理モジュール３２内の画面設計者データ定義構造に定義されていて、この実施形態によるデータベース２に記憶される。値「その他」を選択すると、もう１つのテキスト・ボックスがデータ・エントリ・フォーム４１１上に表示され、ユーザに値「その他」に関連するあるテキストを入力するように要求する。ユーザが、例えば、転落のような医療事故タイプ４３１を選択した場合には、特にその医療事故タイプのための一組の追加データ・エントリ・フィールド４３３が、データ・エントリ・フォーム上に表示される。他の医療事故タイプ４３２を選択した場合には、他の一組の追加データ・フィールド４３３がフォーム上に表示される。例えば、医療事故日付のようなある種のデータ・エントリ・フィールドがフォーム上で強制的に指定され、マーカ４２１により強調される。これらの仕様は、階層的構造生成および管理モジュール３２により、フォーム設計者によりフォーム内に含まれていて、この実施形態によるデータベース２に記憶される。
【００７３】
ユーザが、左側のデータ・エントリ・フォーム４１１上で医療事故タイプ４３１を選択するまで、右側のデータ・エントリ・フォーム４１２は空白のままである。ユーザが、例えば、「転落」のような医療事故タイプ４３１を選択すると、その医療事故タイプ４３１のためのタブ・ページ４１７が右側４１２に表示される。このタブ・ページ４１７は、階層的構造生成および管理モジュール３２により生成され、維持されている主階層的分類構造５７（図５参照）から選択した医療事故タイプ４３１のための完全な階層的分類ブランチ６１（図６参照）を含む。左側のデータ・エントリ・フォーム４１１上で他の医療事故タイプ４３２を選択すると、各医療事故タイプ４３１のための他のタブ・ページ４１８が右側４１２上に表示される。右側の４１２上の各タブ・ページ４１７は、階層的構造生成および管理モジュール３２により生成され、維持されている階層的分類構造５７から選択した医療事故タイプ４３１のための完全な階層的分類ブランチを含む。クライアントの好みおよびユーザ・アクセスの許可により、階層的分類構造５７の予め定義した「基本」サブセットを全分類の代わりに表示することができる。
【００７４】
右側上の選択した医療事故タイプ４３１のための階層的分類ブランチ４１３は、階層構造の拡張可能な視覚的表示内に表示される。この視覚的表示は、当業者が「ツリー図」と通常呼んでいるものに似ている。しかし、このツリー図は、その設計および実施の点で標準的なツリー図とは異なる。これにより、ツリーに埋め込まれている選択したフィールド内にデータを入力することができる。また、これによりツリーのブランチ内で複数のサブブランチを複数選択することができる。新しい医療事故のための図４１の例示としての図面においては、この医療事故タイプ４３１のための最高のレベルの分類だけが表示される。この最高レベルの分類は、階層的構造生成および管理モジュール３２により、医療事故タイプ２７１のためにすでに定義したように、一次分類部門７４のリスト４１３として表示され、この実施形態によるデータベース２に記憶される。各一次分類部門７４は、関連するアイコン４２３と一緒に一次分類部門４２２のテキスト・タイトルとして表示される。
【００７５】
ユーザは、一次分類部門４２２のうちの１つを選択することにより、新規の医療事故の分類をスタートする。この分類のスタートは、そのアイコン４２３をクリックすることにより行われる。一次分類部門４２２を選択すると、医療事故分類質問４８１の第１のレベルが、図４８に示すように開く。これらの質問は、医療事故タイプ４３１に対して医療事故分類システム５７が定義している分類質問の可能な多くのレベルのうちの第１のレベルである。これは、それぞれに疑問符アイコン４８２がついている質問のリスト４８１として表示される。ユーザがある質問をクリックすると、予め定義した返答のリスト４８３が表示される。これらの返答は、医療事故タイプ４３１に対する医療事故分類システム５７の質問に対して定義されている。各返答は、ユーザに対して適当なデータ・エントリ・フィールド４８４に付属しているテキスト説明４８３として表示される。データ・エントリ・フィールド４８４の性質および外見は、必要とする返答のタイプにより異なる。医療事故分類システム５７の設計の際に、ある種の返答フィールドを使用することにより、ユーザは正方形の「チェックボックス」４８４をクリックして、２つ以上の返答を選択することができ、ある種の返答フィールドを使用することにより、ユーザは丸い「ラジオ・ボタン」４８６をクリックして、返答を１つだけ選択することができ、ある種の返答フィールドを使用することにより、ユーザは、例えば、返答「その他」４８５に関連する説明のようなテキストを入力することができる。ユーザがある返答を選択するか、入力すると、医療事故分類質問の次のレベルを表示することができる。
【００７６】
医療事故分類の一番深いレベルに達するまで、ユーザは、医療事故分類プロセスを続行する。各アイコン上の視覚的インジケータは、ユーザに他に分類のもっと深いレベルが存在するかどうかを知らせる。次に、ユーザは、次の質問に対してこのプロセスを反復し、一次分類部門４１３に対するすべての質問に対する回答を得るまでこの反復を続行する。次に、ユーザは、一次分類部門４１３に対するすべての質問に対する回答を得るまで、次の一次分類部門４１３また再度残りの一次分類部門４１３に対してこのプロセスを反復する。
【００７７】
注意深く設計し、医療事故分類構造５７内に分類定義を入力することにより、一次分類部門４１３は、各医療事故タイプ４３１に対して調整される。同様に、ユーザが分類のより深いレベルに進むにつれて、各レベルは、ユーザに適当で広範な一組の可能な質問４８１および各質問に対する可能な返答４８３を供給するように設計されている。供給された返答４８３のうちのどれもが質問４８１に適合しない場合には、ユーザはその他４８５を選択し、その返答に対するテキスト説明を入力する。各分類質問４８１に関連する規則４８７および階層的構造生成および管理モジュール医療事故分類内の返答４８３が、ユーザを助けるためにいつでも表示される。
【００７８】
ユーザは任意の段階で返答を変更し、セーブ４８８し、キャンセル４８９することができる。医療事故データ・エントリが完了した場合には、ユーザはセーブ・ボタン４２４をクリックすることにより、データベース内に医療事故を記憶する。システムは、図４９に示すように、医療事故記録が確実に完全または不完全４９４として分類されるように保護を行う。強制的データ・フィールド４９１内に何らかの喪失したエントリを含む医療事故には完全のマークを付けることはできない。強制的分類項目４９３内に何らかの喪失エントリを含んでいる医療事故には、完全マークを付けることはできない。ある医療事故記録が完全でない場合には、分析報告には記載されず、分析装置モジュール３４によりプロットが実行される。ユーザは、あるレベルの下の詳細な分類を打ち切るのか、または質問に全然答えないのかを選択することができる。医療事故分類構造の任意の医療事故タイプ４３１および任意の他の項目は、アドミニストレータ・モジュール内で「分類に対する標的」４９２とすることができ、そのため強制的分類を必要とするが、強制的項目４９３を超えた場合には、個々の医療事故に対して供給される詳細の量は、データを入力するユーザが選択するものになる。クライアントは、研究または他の目的のために特定の分類項目を目標とすることができる。医療事故分類構造５７の設計は、また例えば、医療事故報告から収集した「その他」４８５返答の分析により、改善を周期的に挿入することができる周期的再検討プロセス２５（図２参照）を含む。
【００７９】
図３５に戻って説明すると、ユーザが医療事故の行３５２を強調し、オープン・ボタン３５５を選択すると、その医療事故に適している医療事故データ・エントリ・フォームが表示され、前に入力した医療事故データが表示される。次に、ユーザは、新規ボタン３５４のところで説明したすべての行動を行うことができ、変更しないでデータをチェックすることができる。ユーザは、当業者であれば理解することができるように、スクロールにより、左側のフォーム４１１上に入力されているすべてのデータを表示することができる。ユーザは、その医療事故のための前に入力した分類のブランチを拡張または縮小するために、分類部門アイコン４２３をスクロールすることにより、およびクリックすることにより、右側の４１２上のすべての分類データを表示することができる。分類内の可能なブランチの数は非常に大きい場合があるが、任意の１つの医療事故分類で実際に使用するブランチの数は極端に多くはないので、この方法で容易に表示することができる。ユーザが最高レベルの一次分類部門アイコン４２３ではない、あるアイコンをクリックすると、その医療事故に対して前に入力した分類ではなく、そのレベルで使用することができる全分類構造が表示される。次に、ユーザは、必要に応じて他の詳細を入力するために、または変更を行うために前に進むことができる。ユーザは、データの表示または入力が簡単に行えるように、全コンピュータ画面一杯に広げるために、左側４１１または右側４１２の拡張を選択することができる。ユーザはデータを表示、追加および更新することができるので、アドミニストレータ・モジュール３６を用いてシステム・アドミニストレータによりユーザに前に割り当てたセキュリティ規則にいつでも従う。データの変更を含むすべてのユーザの行動は、アドミニストレータ・モジュール３６のところで説明するように、広範な監査追跡システムで完全に追跡することができる。
【００８０】
図３５の場合には、ユーザが医療事故の行３５２を強調し、コピー・ボタン３５６を選択すると、ユーザが入力画面を選択できない点、および図４１の画面は、最初に、選択した医療事故の行３５２からコピーしたすべてのデータを含んでいるという点を除けば、その行動は新規ボタン３５４に対する行動と同じである。このデータは、左側４１１上の入力データおよび右側４１２上の分類データを含む。ユーザが、セーブ・ボタン４２４をクリックすることにより、データベース内に医療事故をセーブすると、上記のようなユーザによる変更を除いて、元の記録と同じデータを含む新規の記録が生成される。
【００８１】
図３５の場合には、ユーザがワークフロー・ボタン３６１を選択し、「あなたの注意を必要とするプロジェクト」オプションを選択すると、図５０に示すように、データ・マネージャ・ワークフロー・タスク画面が表示される。この画面は、ワークフロー・マネージャ・モジュール３５内で正式に許可を受けたユーザにより、ユーザに割り当てられたプロジェト５０１およびタスク５０２を示す。タスクの詳細、タスクの依存性および関連プロジェクトは、画面の右側上のタブ５０３の使用により適当である場合には、表示および編集することができる。指定したタイプの医療事故および指定したタイプの分類項目が、データ・マネージャ・モジュールに入力されると、ワークフロー・タスク５０２がシステムにより自動的に上に移動する。この表示は、電子メールにより指名したユーザに自動的に提示されるワークフロー通知に追加される。ワークフローの管理については、ワークフロー・マネージャ・モジュール３５の説明のところでさらに詳細に説明する。
【００８２】
ユーザがワークフロー・ボタン３６１を選択し、「通知」オプションを選択すると、図５１に示すように、データ・マネージャ通知画面が表示される。この画面は、それに対してユーザに通知が送られるデータ入力項目５１１を示す。これにより正式に許可を受けたユーザは、それに対して自分達が通知を受信したい任意のデータ・エントリ項目５１１を指定することもできる。この指定を行うには、ワークフロー・マネージャ・モジュール３５内で管理行動を行う必要はなく、ワークフロー・マネージャ・モジュールを設置しないことを選択するクライアントが使用することができる。指定したタイプのデータ・エントリ項目５１１がデータ・マネージャ・モジュールに入力されると、この通知はシステムにより自動的に上に移動する。この通知は、図５１に示すようにデータ・マネージャ内に表示され、また電子メールによりユーザに送られる。
【００８３】
ユーザが報告ボタン３６２を選択すると、図５２に示すようにデータ・マネージャ報告画面が表示される。この画面は、ユーザが表示することができる医療事故５２１、および使用できる報告タイプ５２３のリストを表示する。ユーザは、１つまたは複数の医療事故５２２を選択し、報告タイプ５２４を選択し、次に印刷ボタン５２５、プレビュー・ボタン５２６、エクスポート・ボタン５２７または送信ボタン５２８のうちの１つをクリックする。ユーザが印刷ボタン５２５を選択した場合には、報告は指名したプリンタに送られる。ユーザがプレビュー・ボタン５２６を選択した場合、報告はコンピュータ画面上に表示される。図５３は、データ・マネージャ詳細報告の一部の一例を示す。ユーザがエクスポート・ボタン５２７を選択した場合、報告は、ユーザが指定した多数の産業標準フォーマットのうちの１つのフォーマットに指名されたコンピュータ・ファイルにセーブされる。ユーザが送信ボタン５２８を選択した場合には、報告がユーザが指定した多数の産業標準フォーマットのうちの１つのフォーマットに指名されたコンピュータ・ファイルにセーブされ、次に電子メールにより指名されたユーザに送られる。データ・マネージャ・モジュールの使用を正式に許可されているすべてのユーザは、報告設計を生成し、セーブし、例えば、公的なものまたは私的なものにするために、その使用のための許可を割り当てることができる。上記すべてのユーザは、図５４のデータ・マネージャ医療事故報告設計者画面を使用することにより、これらのことを行うことができる。データ・マネージャ報告は、潜在的に感知可能データを含むすべての医療事故データを含むことができ、そのためアドミニストレータ・モジュール３６を使用することにより、そうすることの正式な許可を受けているユーザにだけアクセスすることができる。
【００８４】
データ・マネージャ・モジュールは、すべてが同じデータベース上で動作し、アドミニストレータ・モジュール内に指定されているユーザにアクセスすることができる他のシステム１のモジュールと一緒に動作する。この実施形態によるデータベース２の構造は、階層的構造生成および管理モジュール３２により定義され、維持される。データ・マネージャ３３の機能は、アドミニストレータ・モジュール３６の使用により制御される正式に許可を受けたユーザだけにアクセスすることができる。データ・マネージャ・ワークフローおよび通知機能は、識別データを含む生のデータを入力および表示するためにアクセスしているユーザが必要とする機能である。広範なワークフロー機能およびワークフロー管理は、ワークフロー・マネージャ・モジュール３５に内蔵されている。データ・マネージャ報告は、識別されたデータを含む特定のデータ上の報告に限定される。多くの他の報告およびプロットは、分析装置モジュール３４内で入手することができ、これらの報告は、データ・マネージャ報告とは異なるものである。何故なら、これらの報告は、分析装置モジュール３４の説明のところで説明するように、個人識別解除したデータに基づく要約およびプロットであるからである。
【００８５】
すでに説明したように、この実施形態の場合には、システム１は、システムの特定の特徴を供給するいくつかのモジュールを含むモジュラ・タイプのものである。ここで、分析装置モジュール３４に関連する本発明のこの実施形態の主な特徴について説明する。その主な目的は、ユーザに、医療事故の原因、医療事故の頻度および予防可能性の分析および病院および健康機関に関連する他の分析を助けるために、医療事故データの広い範囲の報告およびチャートを提供することである。
【００８６】
図５５〜図６９は、分析装置モジュール３４の好ましい実施形態である。このモジュールは、図３の全システム１のコンテキスト内に表示される。ＡＩＭＳ（商標）システムが、大きな一組の報告タイプおよびチャート・タイプを内蔵していて、またユーザが他の報告タイプおよびチャート・タイプの定義を生成し、記憶するための機能も内蔵している。分析装置により、確実に完全であり能動的な医療事故だけが報告およびチャートに含まれる。この分析装置は、また確実に選択した組織５１（図５参照）のまたはそれ以下の医療事故だけが含まれるようにする。この分析装置は、また識別されたおよび個人識別解除されたデータを含むデータの閲覧許可を有するユーザだけが分析報告およびチャートを表示または印刷できるようにする。
【００８７】
図５５は、ユーザが分析装置モジュールをスタートした場合に表示される最初の画面である。先に進むためには、ユーザは、最初にログイン・ボタン５５１を選択し、有効なデータベース参照、ユーザ名およびパスワードを入力しなければならない。分析装置モジュール全体を通して、各ユーザに適当なデータおよび行動の閲覧および使用を正式に許可するために、ユーザに前に割り当てられたセキュリティ規則が適用される。例えば、ユーザに報告を実行する許可を与えることはできるが、報告を設計する許可を与えることはできない。これらのセキュリティ規則はアドミニストレータ・モジュール３６により、システム・アドミニストレータが定義する。
【００８８】
ユーザが有効なユーザ名およびパスワードを入力するまで、ログイン・ボタン５５１、ヘルプ・ボタン５５５およびエクシット・ボタン５５６だけが表示される。ユーザが有効なユーザ名およびパスワードを入力すると、実行ボタン５５２、設計ボタン５５３およびオプション・ボタン５５４が画面上に表示される。ユーザがオプション・ボタン５５４を選択すると、図５６に示すようにオプション画面が表示される。この画面を使用することにより、当業者であれば理解することができると思うが、ユーザは、画面上にデータの好適な日付表示フォーマット５６１、フィルタ５６２およびソート５６３のようなオプションを表示する好適なデータを選択することができる。ヘルプ・ボタン５５５およびエクシット・ボタン５５６は、当業者であれば理解することができると思うが、ウィンドウをベースとするユーザ・インタフェースによりシステムで共通な通常の機能を実行する。
【００８９】
ユーザが実行ボタン５５２を選択した場合には、図５７に示すように実行報告画面が表示される。この画面は、ユーザに閲覧する許可を与えたすべての前に設計した報告設計５７２のリスト５７１を含む。このリストは、報告の規格のセットおよび分析装置モジュールの正式に許可を受けたユーザが、前に設計し記憶した報告設計として供給した報告設計を含む。この画面は、また、報告５７３、グループ５７４、バッチ５７５、印刷５７６、プレビュー５７７、エクスポート５７８、チャート５７９および表示５８０と表示されているいくつかのボタンを含む。これらのボタンにより、ユーザは、以下に説明するように他の特定の行動を選択することができる。
【００９０】
ユーザが表示ボタン５８０を選択すると、ユーザは編成、公的／私的基準およびソートを含むがこれらに限定されない、前に選択したオプションを変更することができる。
【００９１】
ユーザが報告ボタン５７３を選択すると、個々の報告設計５７２のリストが図５７に示すように表示される。ユーザがグループ・ボタン５７４を選択すると、報告グループのリストが、図５８に示すように表示される。ユーザが報告グループ５８２をクリックすると、その報告グループ５８２内に報告設計５８３のリストが表示される。ユーザがバッチ・ボタン５７５を選択すると、報告グループのバッチ５９１のリストが図５９に示すように表示される。ユーザがバッチ５９２をクリックすると、そのバッチ５９２内に報告グループ５９３のリストが表示される。グループ・ボタン５７４およびバッチ・ボタン５７５は、ユーザが医療事故データの選択した組の上で予め定義した数組の報告を迅速に実行するのを助ける。グループ・ボタン５７４およびバッチ・ボタン５７５を使用した結果の報告は、報告ボタン５７３を使用した場合の個々の報告と同じものである。
【００９２】
ユーザが報告設計５７２を選択し、印刷ボタン５７６をクリックすると、データベースから選択した報告が生成され、プリンタに送られる。ユーザが１つまたは複数の報告グループ５８２またはバッチ５９２を選択し、印刷ボタン５７６をクリックすると、選択した報告グループ５８２またはバッチ５９２内に含まれるすべての報告が、データベースから生成され、プリンタに送られる。
【００９３】
ユーザが報告設計５７２を選択し、プレビュー・ボタン５７７をクリックすると、選択した報告がデータベースから生成され、印刷した場合と同じフォーマットで画面上に表示される。図６０は、チャート報告の一例を示す。図６１はチャート報告データの一例を示す。図６２は多重コラム報告の一例を示す。図６３は、リスク・マトリックス報告の一例を示す。
【００９４】
ユーザが報告設計５７２を選択し、エクスポート・ボタン５７８をクリックすると、選択した報告がデータベースから生成され、ファイルにセーブされる。当業者であれば理解することができると思うが、ユーザは、ポータブル・ドキュメント・フォーマット（ＰＤＦ）、リッチ・テキスト・フォーマット（ＲＴＦ）、エクセル（ＸＬＳ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）および拡張可能マークアップ言語（ＸＭＬ）を含むが、これらに限定されない多くの業界標準ファイル・フォーマットを選択することができる。ユーザが１つまたは複数のグループ５８２またはバッチ５９２を選択し、エクスポート・ボタン５７８をクリックすると、選択したグループ５８２またはバッチ５９２内に含まれるすべての報告がデータベースから生成され、上記フォーマットのうちの１つのフォーマットによりファイルにセーブされる。
【００９５】
ユーザが分析タイプのチャート６６５である報告設計５７２を選択し、チャート・ボタン５７９をクリックすると、選択したチャートが、ユーザがオプションのある範囲をチャートに構成することができるフォームで表示される。図６４は、このようなチャート表示の一例を示す。ユーザ定義の報告を含むタイプ・チャートの各報告は、このようなフォーマットで表示することができる。多数のタブ６４１およびパラメータ・エントリ・フィールド６４２により、ユーザは、チャートのレイアウトおよびフォーマッテングを調整することができ、チャートに貢献するデータを表示することができる。この画面の主な特徴は、「ドリルダウン」することができることである。すなわち、チャートに貢献する詳細なデータ記録を表示することができることである。このことは、図３５類似のディスプレイ内に関連するデータ記録を表示するために、データ・マネージャ・モジュール３３を呼び出すことにより行うことができる。ユーザは、ユーザが閲覧することができる任意のさらなる詳細を表示するために、「ドリルダウン」を行うことができる。当業者であれば理解することができると思うが、柔軟なチャート作成機能は、標準チャート・ソフトウェア・モジュールを使用することにより提供され、その機能は図の例に限定されない。
【００９６】
図５５に戻って説明すると、ユーザが設計ボタン５５３を選択すると、図６５に示すように設計報告メイン画面が表示される。この画面は、ユーザが使用することができる、前に設計したすべての報告設計６５２のリスト６５１を含む。この画面は、また問い合わせ６５３、報告６５４、グループ６５５、バッチ６５６、新規６５７、編集６５８、削除６５９、実行６６０および表示６６１と表示されているいくつかのボタンを含む。これらのボタンを使用することにより、ユーザは以下に説明するように、他の特定の行動を選択することができる。
【００９７】
図６５の場合には、ユーザが表示ボタン６６１を選択した場合、ユーザは、編成、公的／私的基準およびソートを含むがこれらに限定されないすでに選択したオプションを変更することができる。ユーザが実行ボタン６６０を選択すると、実行報告画面が、図５７に示すように表示される。これにより、ユーザは報告を設計しながら簡単に報告を実行することができる。ユーザが報告設計６５２を選択し、削除ボタン６５９をクリックすると、当業者であれば理解することができると思うが、ユーザが通常の確認を行った後で報告設計６５２が削除される。
【００９８】
ユーザが問い合わせボタン６５３を選択すると、前に設計した問い合わせ６６９のリストが図６６に示すように表示される。次に、ユーザが問い合わせ６７０を選択すると、問い合わせの定義６７１が表示される。ユーザが新規ボタン６５７を選択すると、問い合わせ設計問い合わせビルダ画面が、図６７に示すように表示される。この画面の左側は、用語６７２およびツリー６７３と表示されているタブを含む。これらのタブにより、ユーザは個々の用語５２（図５参照）、または問い合わせに内蔵させる明示的階層的分類構造エントリ５４の使用を選択することができる。用語５２のリスト、および階層的分類構造エントリ５４のリストの両方は、階層的構造生成および管理モジュール３２内に前に定義したものである。階層的分類構造は、ツリーの図面に表示され、当業者であれば理解することができると思うが、ナビゲート、拡張および縮小することができる。ユーザは左側から項目６７４を選択し、アンド（Ａｎｄ）ボタン６７６、オア（Ｏｒ）ボタン６７７またはアンドノット（Ａｎｄ  Ｎｏｔ）ボタン６７８をクリックすることにより、問い合わせを構成する。右側６７５は最初空白であり、ユーザがそれを漸次構成するにつれて、問い合わせの定義６７６を漸次表示する。ユーザに冗長な構造化問い合わせ言語（ＳＱＬ）コード文を表示する大部分の問い合わせビルダとは異なり、この画面は、ユーザが問い合わせに内蔵させるためにすでに選択したものの比較的コンパクトで、ハイレベル定義６７９を表示する。それ故、ユーザはＳＱＬ語を理解する必要はない。階層的分類構造５４から必要なデータを正しく選択するために必要な複雑なＳＱＬ文は、ユーザに表示されない。
【００９９】
ユーザが問い合わせボタン６５３を選択し、次に編集ボタン６５８を選択すると、図６７に示すように問い合わせ設計画面が表示される。次に、ユーザは問い合わせに追加することもできるし、新規ボタン６５７のところで説明したように変更することもできる。
【０１００】
図６５の場合には、ユーザが報告ボタン６５４を選択すると、現在の報告設計６５１のリストが図６５に示すように表示される。画面の右側は、タイトル６６２、アクセス６６３、位置６６４、分析タイプ６６５、説明６６６および報告問い合わせ６６７を含むがこれに限定されない報告設計属性を含む。右側の内容も、例えば、リスク・マトリックス６６８が必要とする追加情報を入力できるようにするために、必要な分析タイプ６６５により異なる。これらのオプションにより、ユーザは比較的少数の問い合わせ６７０から多数の報告設計６５１を定義することができる。
【０１０１】
ユーザが新規ボタン６５７を選択すると、分析タイプがチャートである場合には、設計報告新規／編集画面が図６８に示すように表示され、分析タイプがチャートでない場合には、図６９に示すように表示が行われる。分析タイプ６６５がチャートである場合には、ユーザが容易にチャート・タイプ、Ｘ軸仕様およびＹ軸仕様を選択することができるように、「チャート・ウィザード」ボタン６８１が表示される。このボタンを選択すると、ＸおよびＹ軸仕様を入力するために、一連の調整したデータ・エントリ画面が表示され、個々のデータ項目による簡単な分析ではなく、分析タスクに対して調整されたデータの予め定義した複雑なグループ分けの選択を含む。位置６６４の選択は、アドミニストレータ・モジュール３６が維持していて、ユーザがアクセスできるように定義されている位置のリストに限定される。アクセス６６３および分析タイプ６６５の選択は、ユーザが選択しなければならないリストにより定義される。問い合わせ６６７の選択は、この実施形態によるデータベース２内に前に定義され記憶されている各問い合わせ６６９の設計者により定義されていて、その問い合わせへのアクセスを公開するかどうかが指定される。ユーザに対して回答のカウントから医療事故のカウントを区別し、比較の単位当たりのカウントの比率からカウントを区別するようにとの指示が行われる。例えば、各組織５１に対するベッドデイを占める比較の単位は、アドミニストレータ・モジュール３６内で構成される。セーブ・ボタン６８２およびキャンセル・ボタン６８３を使用することにより、ユーザは報告設計をセーブすることもできるし、行った任意の変更をキャンセルすることもできる。何故なら、報告設計は最後にセーブされるからである。
【０１０２】
ユーザが報告ボタン６５４を選択し、次に編集ボタン６５８を選択すると、設計報告新規／編集画面が、図６８および図６９に示すように表示され、図６５の報告設計画面の右側上の項目を新規ボタン６５７のところで説明したように修正することができる。
【０１０３】
ユーザがグループ・ボタン６５５を選択すると、画面の左側には、図６５内のように更新ボタン、すなわち、新規６５７、編集６５８および削除６５９と一緒に、図５８の実行報告グループ画面類似の報告グループ５８１のリストが表示される。ユーザが報告グループ５８２をクリックすると、報告グループ５８２内の報告設計５８３のリストが画面の右側上に表示される。報告グループ５８２は、編集ボタン６５８をクリックすることにより修正することができ、または削除ボタン６５９をクリックすることにより削除することができる。新規報告グループ５８２は、新規ボタン６５７を選択することにより生成することができる。
【０１０４】
ユーザが報告バッチ・ボタン６５６を選択すると、画面の左側には、図６５のように更新ボタン、すなわち、新規６５７、編集６５８および削除６５９と一緒に、図５９の実行報告バッチ画面類似の報告グループ５８１のバッチ５９２のリストが表示される。ユーザがバッチ５９２をクリックすると、そのバッチ５９２内のグループ５９３のリストが画面の右側上に表示される。バッチ５９２は編集ボタン６５８をクリックすることにより修正することもできるし、または削除ボタン６５９をクリックすることにより削除することができる。新規報告グループ５９２は、新規ボタン６５７を選択することにより生成することができる。報告グループ５８２およびバッチ５９２を生成すると、ユーザは容易に、選択した一組の医療事故データ上で、複数の組の報告を迅速に実行することができるようになる。
【０１０５】
ユーザに対する問い合わせおよび報告の設計の許可は、アドミニストレータ・モジュール３６内で形成される。ユーザに対する報告実行の許可は、アドミニストレータ・モジュール３６内で形成され、また各報告設計６５２の生成者により制御される。
【０１０６】
ほとんどのタイプの分析は、個人識別解除したデータだけを必要とする。ユーザは必要な時にデータを表示できるだけである。私的なものであり、分析のために個人識別解除しなければならないデータの仕様は、アドミニストレータ・モジュール３６で行われる。識別したデータを表示することができるユーザは、また識別したデータにより問い合わせおよび報告を生成することもできる。どのユーザが識別したまたは個人識別解除したデータを表示できるのかの管理は、アドミニストレータ・モジュール３６で行われる。
【０１０７】
すでに説明したように、この実施形態の場合には、システム１は、このシステムの特定の特徴を提供するいくつかのモジュールを含むモジュラ・タイプである。ここで、ワークフロー・マネージャ・モジュール３５に関連する本発明のこの実施形態の主な特徴について説明する。その主な目的は、医療事故データ・エントリに関連するワークフロー・プロジェクト、活動およびタスクを生成し、修正し、管理できるようにすることである。当業者は、通常、「ワークフロー」という用語は、時間に依存する場合があり、完成のために個人に割り当てられる場合がある一連の計画した活動およびタスクを意味することを知っている。
【０１０８】
この実施形態の場合には、２つの主な方法で、すなわちデータ・マネージャ・モジュールを通して、またはワークフロー・マネージャ・モジュールをスタートすることにより直接ワークフローにアクセスすることができる。ワークフロー・マネージャ・モジュール、その特徴、機能およびデータへのアクセスは、種々のアクセス許可の割り当てを通してシステム・アドミニストレータにより制御される。ユーザは、システム・アドミニストレータが提供する信任状によりワークフロー・マネージャ・モジュールにログオンする。
【０１０９】
ワークフロー・マネージャ・モジュール３５は、個人が完了しなければならない一連の活動およびタスクの生成に関連する。人が手動でスタートするワークフロー、または種々のトリガ基準に応じてシステムにより自動的にスタートするワークフローを生成することができる。
【０１１０】
ワークフローは、図７３のところで例示としての図面で詳細に説明する論理的な方法で配列されたタスクの集まりである。図では、ワークフロー内の各活動または「タスク」７３１は、スタート点「トリガ」７３２と終点「エンド」７３３との間のワークフロー内の個々のラインである。各タスクには、参照番号７３４の図で示すように、「タスク・タイプ」、「タスク名」、「タスク説明」、「タスク・コスト」および「タスク持続時間」が割り当てられる。ワークフロー・タスクの集まりはワークフロー「設計」を形成することにより生成される。
【０１１１】
ワークフロー・マネージャ・モジュールにログオンすると、一番上の「タスク」７０１、「プロジェクト」７０２、「設計」７０３に沿って、機能ボタンの配列と一緒に図７０に示す「ようこそ画面」が表示される。この例示としての図面に場合には、例えば、ヘルプおよびエクシットのような、当業者が他の実施形態に同じように内蔵していると予想することができるシステムの一般的な特徴および機能でなく、本発明の基本原理およびコンセプトをサポートしているワークフロー・マネージャ・モジュールのこれらの要素を重点的に説明することに留意されたい。設計ボタン７０３をクリックすると、ユーザに対して図７１の参照番号７１１が示すように、現在のワークフロー設計のリストが表示される。このリストからワークフローを選択するには、特定のワークフロー設計をダブル・クリックするか、設計を強調し、編集ボタン７１２をクリックすればよい。ワークフローを選択した場合には、ワークフロー設計編集画面が、図７２に示すように表示され、ユーザに２つのデータ・エントリ・タブ「通常」７２１および「タスク」７２２が表示される。「通常」タブ７２１は、ワークフロー設計の基本的な詳細および属性、すなわち、「設計オーナー」、「設計名」、「設計の説明」、「設計コスト」、「設計アクセス」および「設計能動」を含む。「タスク」タブ７２２は、図７３の例示としての図面に示すように、ワークフロー設計の主要な詳細を保持する。現在選択している項目の前または後にタスクを置くために、現在のタスクのうちの１つおよび追加ボタン７３４をクリックすることにより、新規のタスクがワークフローに追加される。タスクに対する詳細の入力は、画面の右側上の図７３の参照番号７３７が示す「タスク・タイプ」、「タスク名」、「タスク説明」、「タスク・コスト」および「タスク持続時間」上で行うことができ、そうすることによりタスクの定義が完了する。最後に、セーブ・ボタン７３６をクリックすると、ワークフロー設計が実施形態によるデータベース２に記憶される。タスクは、タスクを強調し、除去ボタン７３５をクリックすることによりワークフロー設計から除去することができる。
【０１１２】
ワークフローを設計すると、そのワークフローを「プロジェクト」で使用することができる。この実施形態の「プロジェクト」は、医療事故イベントにより自動的にトリガされた、またはユーザが手動でトリガした、ワークフロー・タスクが個人に割り当てられたワークフロー設計の能動例である。プロジェクトは、正式に許可を受けたプロジェクト・マネージャにより任意の時点で中止、作動または除去することができる。図７４および図７５は、プロジェクトの定義タブ、すなわち「通常」７４１および「タスク」７５１を示す。図７５を見れば分かるように、「医療事故の調査」タスクが、参照番号７５２を見れば分かるように「ＪｏｈｎＷ」に割り当てられる。参照番号７５３で「医療事故アクセス」を選択すると、プロジェクト・スーパバイザまたはマネージャは、ユーザがプロジェクト・ワークフローを始めた医療事故にアクセスできるようにすることができる。プロジェクト・ワークフローは、ある場合に、そのセキュリティ構成のために通常アクセスすることができない。この特徴の目的は、特定の医療事故を調査するためにアクセスを制御することである。ワークフロー・モジュールは、さらに、電子メールによるタスク通知のための機能を提供し、それによりプロジェクト・スーパバイザは、個人にタスクが必要とされていることを知らせ、マネージャに割り当てられた時間内にタスクができないかどうかを知らせ、タスクを実行しなければならない日付後何日たってもタスクが完了していない場合には、上位のマネージャにエスカレートするための機構を生成することができる。本発明のこの実施形態の場合には、プロジェクトは、個人にワークフロー・タスクを割り当てるための主要な手段であるが、他の実施形態も他の手段によりワークフロー・タスクを割り当てることができることを容易に理解することができる。
【０１１３】
図７０に戻って再度説明すると、タスク・ボタン７０１をクリックすると、図７６に示す主タスク・ウィンドウが開く。ここからユーザは、ａ）注目してもらいたいプロジェクト７６１、ｂ）注目してもらいたい個々のタスク７６２を見ることができる。画面の右側上には、図７６、図７７および図７８に示すように、「プロジェクト詳細」、「タスク詳細」および「タスク依存性」についてのさらなる詳細を提供する多数のタブが表示される。ユーザは、プロジェクト医療事故、タスクの完了およびタスクのコメントのような詳細を更新するために、タブ・ページ上に詳細を入力する。タスク完了日付を入力すると、そのタスクは閉じられ、完了となる。図７６の画面は、データ・マネージャ・モジュール内からワークフローにアクセスした場合に表示される主要画面である。
【０１１４】
プロジェクト・スーパバイザはワークフローを手動でスタートすることができ、またはデータ・マネージャ・モジュール３３内の医療事故エントリに応じてワークフローがシステムにより自動的にトリガされることについてはすでに説明した。トリガ機構はすでに説明したワークフロー設計画面内に設定される。図７９の参照番号７９２は、ワークフロー・タスク生成画面および「トリガ・タイプ」選択を示す。トリガ・タイプ選択は、ウィンドウの左側の第１のタスクを参照番号７９１で選択した場合だけ表示される。トリガ・タイプ選択から「自動」オプションを選択すると、参照番号７９３で「データ・フィールド」選択ウィンドウが開く。ここから、「データ・フィールド」ボタン７９４をクリックすると、使用可能なデータ・エントリ項目ビューワ７９５が開く。データ・エントリ・フィールドの階層表示をナビゲートすると、ユーザは、この例示としての図面の場合には、データ・エントリ項目ビューワから「トリップ、スリップまたはスタンブル」が選択されたリストからトリガ点を選択することができる。「ＯＫ」をクリックすると、図８０の８０１に示すように、選択した項目がデータ・フィールド選択ウィンドウ７９３内に入る。このようにして自動トリガを選択し、データ・エントリ・フィールド値を設定すると、このワークフロー設定に基づく任意の能動プロジェクトが、この例示としての図面の場合には、「トリップ、スリップまたはスタンブル」である、選択したトリガ・データ・フィールドに対応するデータ・エントリ・フォーム上にユーザがある値を入力する度にトリガされる。
【０１１５】
このモジュールが生成し、上記例示としての図面によりこの実施形態で説明したワークフロー設計およびプロジェクトは、実施形態によるデータベース２に記憶される。このシステムは、その機能の通常の実行の際に、この実施形態によりデータベース内に記憶しているこのような情報を使用する。
【０１１６】
本発明のこの実施形態のシステムのワークフロー・モジュールは、個々のモジュールであるが、当業者であれば、このモジュール内に示した機能は、他の実施形態に異なる方法で内蔵させることができることを容易に理解することができるだろう。
【０１１７】
すでに説明したように、この実施形態の場合には、システムは、システムの特定の特徴を提供するいくつかのモジュールを含むモジュラ・タイプのものである。ここで、要約した形で、アドミニストレータ・モジュール３６に関連する本発明のこの実施形態の主な特徴について説明する。その主な目的は、本発明のこの実施形態を含むシステムの種々の態様、すなわち、ユーザ、ユーザ口座、グループ、許可、組織構造、データ識別許可、分類目標定義、監査ロッギングおよび追跡、プロジェクト、通知、測定単位、アプリケーション登録キーおよびユーザ定義フィールド維持を管理することである。好ましい実施形態のこの説明においては、当業者がある実施形態に内蔵していると予想することができるシステムのもっと周辺的な特徴および機能の詳細ではなく、本発明の基本原理およびコンセプトをサポートしているアドミニストレータ・モジュールのこれらの要素を重点的に説明することに留意されたい。
【０１１８】
図８１は、ボタン、すなわち「セキュリティ」８１１、「データ」８１２、「監査」８１３、および「レジスタ」８１４によりアクセスする４つの主要な機能を示し、アドミニストレータ・モジュールのためのトップ・レベルの画面を示す。
【０１１９】
これらの機能を順次使用して、セキュリティ８１１ボタンをクリックすると、図８２に示すセキュリティ管理画面が開く。この図を見れば分かるように、システムのセキュリティの異なる小さな面を反映している多数の個々のタブがある。これらのタブのうちの第１のタブは、参照番号８２１で組織およびその各サブ組織構造の定義をホストする。第２のタブ（それ自身、それぞれ図８３および図８４に示す、２つの他の部分、すなわち、「通常」および「アプリケーション」からなる）は、セキュリティ・グループおよびシステム内のモジュールへのグループ・アクセスの定義を示し、第３のタブ（図８５に示す）は、システム内の個々のユーザを示し、第４のタブ（図８６に示す）は、各ユーザに与えられる許可を示す。
【０１２０】
本発明のこの実施形態の場合には、ユーザ定義、グループ定義および許可定義の組合わせは基本的なものである。何故なら、この組合わせは、ａ）システム（例示としての図８４に参照番号８４１、８４２および８４３で示す）のモジュールへのアクセス、ｂ）組織構造（図８２に参照番号８２１で示す）内のレベル、ｃ）データ・マネージャ・モジュール３３（図８４に参照番号８４３で示す）内で見ることができるデータ・エントリ・フォームへのアクセスおよび使用方法、およびｄ）医療事故（図８４に参照番号８４４で示す）を分類するための機能に対する許可を一緒にリンクするからである。
【０１２１】
図８１に戻って説明すると、「データ」ボタン８１２をクリックすると、アドミニストレータは、図８７に参照番号８７１で示すように、多数のデータに関連する管理活動、すなわち、「目標データ」、「識別データ」、「ユーザ定義フィールド」、「比較の単位」、「通知」、「プロジェクト」を選択することができる。これらのオプションのうちの「目標データ」は重要である。何故なら、目標データは、医療事故分類の命令を制御するからである。さらに詳細に説明すると、医療事故がデータ・マネージャ・モジュール３３内に記録されると、これが「開き」、システムの質問「分類は完了したか」によりプロンプトされた場合、オプション「Ｙｅｓ」を選択することにより、ユーザが医療事故記録を「終了」するまで開いたままである。ある医療事故が目標にされた場合、必要な分類が完了するまで、その医療事故に完了のマークを付けることはできない。その医療事故が、２つ以上の「ＨＩＴ」分類階層を行わなければならない場合には、両方の「ＨＩＴ」分類を行わない限り、その医療事故を完了することはできない。図８８は、データ・エントリ・フォームのうちのどの要素を目標にするのかを識別するために使用する「目標データ」画面を示す。例示としての図面の場合には、「目標項目」８８１は、「患者医療事故」データ・エントリ・フォーム８８２内の参照番号８８３が示す医療事故タイプ「転落」である。さらに、この特定の例は、これは「ニューサウスウェールズ」組織だけのための目標であることを示す。
【０１２２】
図８７に戻って説明すると、「識別データ」オプションにより、システム・アドミニストレータは、特定のデータ・エントリ・フォーム・フィールドをシステム分析装置モジュール内で見えないようにすることもできるし、見えるようにすることもできる。この特徴の目的は、一般的な医療事故分析を行っている場合に、患者名およびアドレス詳細のようなシステムの潜在的に重要な内容に対してセキュリティを行うことである。大部分の組織の場合、医療事故の一般的な分析を行っている人は、医療事故の詳細を見る必要はない。
【０１２３】
図８７の場合、残りの項目、すなわち、「ユーザ定義フィールド」、「比較単位」、「通知」および「プロジェクト」により、システム・アドミニストレータは、それぞれ、簡単なユーザ定義フィールドを生成、管理することができ、組織の加重を生成、管理することができ、通知を生成、管理することができ、プロジェクトを生成、管理することができる。ここではユーザ定義フィールドも比較単位も説明しない。何故なら、これらは本発明の原理にとって重要なものでないからである。好ましい実施形態のこの説明の他のところで通知およびプロジェクトを生成する機構について説明したが、アドミニストレータ・モジュールは、このような詳細を再検討および管理することができるように、画面およびフォームの組を供給するので、ここではこれ以上の説明は省略する。
【０１２４】
図８１に戻って説明すると、「監査」ボタン８１３をクリックすると、図８９に示すように監査画面が開く。このモジュールの監査特徴により、アドミニストレータはユーザ活動を広範に追跡することができる。図８９の例示としての図面を見れば分かるように、参照番号８９１のフィールドにより、アドミニストレータはある範囲の日付、特定のユーザ、特定のアプリケーション、能動タイプに対して報告８９２を作成することができ、結果としての報告を種々の方法でソートすることができる。「ユーザ活動」タブは、モジュール・アクセスおよびモジュール活動に対する監査活動を示し、「監査追跡ログ」タブは、データベース内の種々の項目に対して行った変更を示し、「医療事故履歴」タブは選択した特定の医療事故に起こった変更を示す。
【０１２５】
図８１に戻って説明すると、「レジスタ」ボタン８１４をクリックすると、図９０にシステム免許および登録画面が表示され、アドミニストレータは、アプリケーションを正式に登録することができる。
【０１２６】
このモジュールが生成し、上記例示としての図面によりこの実施形態で説明した管理の詳細は、実施形態によるデータベース２に記憶される。システム１は、その機能の一般的実行の際にこの実施形態によりデータベース内に記憶しているこのような情報を使用する。
【０１２７】
本発明のこの実施形態のシステムのアドミニストレータ・モジュールは、独立しているモジュールであるが、当業者であれば、このモジュール内に示すこの機能を他の実施形態に異なる方法で内蔵させることができることを容易に理解することができるだろう。
【０１２８】
すでに説明したように、この実施形態の場合には、システム１は、このシステムの特定の特徴を供給するいくつかのモジュールを含むモジュラ・タイプである。ここで、要約した形で、データベース・アドミニストレータ・モジュール３７に関連する本発明のこの実施形態の主な特徴について説明する。その主な目的は、この実施形態およびシステムによるデータベース２への強化の展開を制御する施設、データ・インポートおよびエクスポートのための施設、およびこのデータベースを達成するための施設を含むこの実施形態のユーティリティにより、汎用データベースを供給することである。顧客は、システムおよびデータベースのそれ自身の例でシステム強化を適用するために、またそのデータベースの内容をインポート、エクスポート、およびアーカイブするためにデータベース・アドミニストレータ・モジュールを使用する。
【０１２９】
データベース・アドミニストレータ・モジュール３７を開くと、図９１の画面が表示される。この図の例示としての図面を見れば分かるように、データベース・アドミニストレータ・モジュールは、それぞれ、ボタン９１１、すなわち、「データベース」、「更新」、「エクスポート」、「インポート」および「アーカイブ」によりアクセスすることができる多数の機能を有する。「更新」ボタンをクリックすると、図９２の画面が表示される。この画面は、参照番号９２１のところで使用可能な更新および参照番号９２２のところで更新スクリプトの内容を示す。ここから、ユーザは、システムにすでに適用した更新を再検討することができ、ユーザが適用したい新規の更新を選択することができる。
【０１３０】
「インポート」ボタンをクリックすると、インポート機能の基本的特徴、すなわち、マッピング定義９３１、この実施形態項目９３３によるデータベースへの個々のインポート・データ・フィールドのマッピング、およびどの組織がインポート・データを受信するのかの選択を示す図９３の画面が開く。この例示としての図面の場合には、インポートは「ニューサウスウェールズ」９３２に適用される。「エクスポート」機能は、類似の方法で動作する。セキュリティ／プライバシーのために、個人識別解除したデータだけがエクスポートされる。システムのアドミニストレータだけが、これらの機能にアクセスすることができる。
【０１３１】
本発明のこの実施形態のシステムのデータベース・アドミニストレータ・モジュールは独立しているモジュールであるが、当業者であれば、このモジュール内に示すこの機能を他の実施形態に異なる方法で内蔵させることができることを容易に理解することができるだろう。
【０１３２】
すでに説明したように、この実施形態の場合には、システムは、このシステムの特定の特徴を提供するいくつかのモジュールを含むモジュラ・タイプである。ここで、要約した形で、ウェブ・フォーム・モジュール３８に関連する本発明のこの実施形態の主な特徴について説明する。その主な目的は、データ・マネージャ・モジュールのデータ・エントリ特徴にウェブをベースとするアクセスを行うことである。
【０１３３】
図９４は、この例示として図面の場合には医療事故を示すウェブ・フォーム・モジュールを示す。この画面は、データ・マネージャ・モジュールに入った場合にユーザに提示される画面と同じものであるが、この場合、表示環境はウェブ・ブラウザである（ウェブ・ブラウザは、当業者には、ユーザがワールド・ワイド・ウェブ・コンテンツを表示し、ナビゲートするグラフィカル・インタフェースとしての通称であると理解されている）。この画面から新規の医療事故を生成することができ、現在の医療事故を編集することができ、データ・マネージャ・モジュール機能と同等の方法で、医療事故報告を生成することができ、また現在のワークフロー・タスクを再検討することができる。この例示としての図面に表示されたリストからある医療事故をクリックすると、そこから医療事故詳細を編集およびセーブすることができる図９５の医療事故データ・エントリ・フォームが開く。
【０１３４】
本発明のこの実施形態のシステムのウェブ・フォーム・モジュール３８は、独立しているモジュールであるが、当業者であれば、このモジュール内に示すこの機能を他の実施形態に異なる方法で内蔵させることができることを容易に理解することができるだろう。
【０１３５】
すでに説明したように、この実施形態の場合には、システムは、このシステムの特定の特徴を提供するいくつかのモジュールを含むモジュラ・タイプである。ここで、要約した形で、エージェント・モジュール３９に関連する本発明のこの実施形態の主な特徴について説明する。その主な目的は、通知の発生およびワークフロー・トリガ・イベントについて、この実施形態によりデータベースを周期的にポーリングすることである。
【０１３６】
図９６は、エージェント・モジュール３８を示す。この例示としての実施形態の場合には、エージェントは、１５分検索周期（ポーリング周期）９６２を有する。このことは、エージェントが、停止するまで１５分間隔で通知の発生およびワークフロー・トリガのために、この実施形態によりデータベースに問い合わせを行うことを意味する。通知の発生についてこの実施形態によりデータベースに問い合わせを行う場合、エージェントは、データ・マネージャ・モジュール、ワークフロー・モジュールまたはアドミニストレータ・モジュールのようなこのシステムの他のモジュール内で生成され、構成された通知の定義を探す。同様に、エージェントは、ワークフロー・モジュール内で生成されたワークフロー・トリガについて、この実施形態によりデータベースに問い合わせを行う。上記例示としての図面の場合には、ワークフロー・トリガは、「トリップ、スリップまたはスタンブル」データ・エントリ・フィールドに対して設定された。エージェントは、その最後のポーリング以降、この実施形態によりデータベース内のこの項目の例を探し、各発生に対して対応するワークフローをスタートする。エージェントは、「スタート／ストップ」ボタン９６１をクリックすることにより、任意の時点でスタートまたはストップすることができる。
【０１３７】
本発明のこの実施形態のシステムのエージェント・モジュールは独立しているモジュールであるが、当業者であれば、このモジュール内に示すこの機能を他の実施形態に異なる方法で内蔵させることができることを容易に理解することができるだろう。
【０１３８】
すでに説明したように、この実施形態の場合には、システム１は、このシステムの特定の特徴を提供するいくつかのモジュールを含むモジュラ・タイプである。ここで、要約した形で、エクスポート・モジュール４０に関連する本発明のこの実施形態の主な特徴について説明する。その主な目的は、例えば、他の分析のために多くのソースからのデータを結合する目的で、データベースに含まれているデータを抽出する手段を提供することである。
【０１３９】
エクスポート・モジュールを使用することにより、システムの正式に許可を受けたユーザは、構成された方法で個人識別解除した医療事故データの抽出を構成することができる。このモジュールを使用すれば、データ項目の仕様のために、エクスポート・ファイル内のこれらの項目の位置、エクスポート・ファイル・フォーマットの選択、およびそれ自身マニュアルまたは自動的／タイミングをとったエクスポート行動を構成することができるファイル・エクスポートの実行をエクスポートすることができる。エクスポートの監査は、すでに説明したように、アドミニストレータ・モジュール３６により維持される。図９７は、このアプローチを示す。
【０１４０】
本発明のこの実施形態のシステムのエクスポート・モジュール４０は独立しているモジュールであるが、当業者であれば、このモジュール内に示すこの機能を他の実施形態に異なる方法で内蔵させることができることを容易に理解することができるだろう。
【０１４１】
すでに説明したように、この実施形態の場合には、システム１は、このシステムの特定の特徴を提供するいくつかのモジュールを含むモジュラ・タイプである。ここで、要約した形で、根本原因モジュール４１に関連する本発明のこの実施形態の主な特徴について説明する。その主な目的は、医療事故根本原因分析を動作可能にすることである。当業者は、通常、根本原因分析（ＲＣＡ）が、ある医療事故の基本的原因を識別するための技術を意味することを知っている。ＲＣＡを実行するための多くの認識された方法があるが、すべての方法は、当該医療事故の完全な分類に基づいて記述される。本発明のこの実施形態の場合には、階層的分類構造５７は、ＲＣＡ活動のベースラインを提供する。
【０１４２】
図９８は、ＲＣＡプロセスを示す。根本原因分析プロセスは、特定の医療事故の原因を顕在化させる連続的反復である。図９８の例示としての図面は、根本原因を入手するための簡単な４回の反復分析を示す。階層的構造でこの実施形態によるデータベース２内に記憶している情報は、基本テンプレートとしてすでに説明したランシマン・モデル４２により、また医療事故分類情報および医療事故詳細情報を提供することにより、分析をサポートするために使用される。ＲＣＡモジュールは、分析／反復の各レベルにおける原因を表示する連続的な詳細な分析報告を作成するために、分析装置モジュール３４の原理を使用する。
【０１４３】
本発明のこの実施形態のシステムの根本原因モジュール４１は独立しているモジュールであるが、当業者であれば、このモジュール内に示すこの機能を他の実施形態に異なる方法で内蔵させることができることを容易に理解することができるだろう。
【０１４４】
今まで、本発明を最も実際的で好ましい実施形態と思われる形で図示し、説明してきたが、上記の詳細な説明に限定されないが、任意のおよびすべての等価デバイスおよび装置を包含するための添付の特許請求の範囲の全範囲内に含まれる本発明の範囲内で種々に修正および変更することができることを理解されたい。
本発明をよりよく理解してもらうために、図面を参照しながら一実施形態について説明する。
【図面の簡単な説明】
【０１４５】
【図１】本発明の好ましい実施形態およびその関連する構成要素の全コンテキストを示すブロック図である。
【図２】外部の組織分析、研究および政策調査、およびフィードバック／勧告を通しての本発明のコアである分類構造の強化に関連する本発明のコンテキストの図面である。
【図３】本発明の機能をホストするコンピュータ・プログラムのモジュラ構造の図面である。
【図４】分類階層を構成するためのフレームワークとしての本発明のこの実施形態で使用する通常の参照モデル（ランシマン・モデル）を示す図面である。
【図５】本発明のこの実施形態で使用するデータベース構造のハイレベルの図面である。
【図６】分類階層の第１の（最高の）レベルを示す例示としての図面である。
【図７】図４に示すランシマン・モデルの原理と結びついている分類階層の標準化部門レベルを示す例示としての図面である。
【図８】本発明のこの実施形態で「主要質問」と呼ばれる分類階層のレベルを示す例示としての図面である。
【図９】本発明のこの実施形態で表示された分類階層のもっと低いレベルを示す例示としての図面である。
【図１０】本発明のこの実施形態に示す分類階層内のいくつかのブランチおよびノード内の「用語」の再使用の例示としての図面である。
【図１１】本発明の好ましい実施形態の階層的構造生成および管理モジュールの主要な機能ボタンの例示としての図面である。
【図１２】本発明の一実施形態の階層的構造生成および管理モジュールが生成したログイン信任状ユーザ入力画面の例示としての図面である。
【図１３】本発明の一実施形態が生成した階層的構造の階層的構造生成および管理モジュールの視覚的表示を示す例示としての画面である。
【図１４】本発明の一実施形態が生成した「用語」リストの階層的構造生成および管理モジュールの視覚的表示を示す例示としての画面である。
【図１５】本発明の一実施形態が生成した階層的構造の階層的構造生成および管理モジュールの視覚的表示を示す例示としての画面である。
【図１６】本発明の一実施形態が生成したデータ・エントリ・フィールドの定義をホストするハイレベル階層ブランチを示す階層的構造生成および管理モジュール画面の例示としての図面である。
【図１７】本発明の一実施形態が生成したもっと低いレベルのブランチ、ノードおよびリーフを示すデータ・エントリ・フィールド定義をホストしているハイレベル階層ブランチの拡張の例示としての図面である。
【図１８】本発明の一実施形態が生成したもっと低いレベルのブランチ、ノードおよびリーフを示すアセンブリ構成要素をホストしているハイレベル階層ブランチの拡張の例示としての図面である。
【図１９】本発明の一実施形態が生成したすぐ下のレベルのブランチを示す医療事故報告要素をホストしているハイレベル階層ブランチの拡張の例示としての図面である。
【図２０】すぐ下のレベルのブランチを示し、本発明の一実施形態が生成した新規のデータ・エントリ・フィールドを生成するための新規ボタンの使用を示す患者医療事故データ・エントリ・フォームに関連する階層ブランチの拡張の例示としての図面である。
【図２１】本発明の一実施形態が生成したもっと低いレベルのブランチ、ノードおよびリーフを示す患者医療事故データ・エントリ・フォームに関連する階層ブランチのさらなる拡張を示す例示としての図面である。
【図２２】本発明の一実施形態が生成した階層ツリーのあるブランチ内の新規データ・エントリ・フォームを生成するためのスタート点を示す例示としての図面である。
【図２３】本発明の一実施形態が生成したデータ・エントリ・フォーム上での新規な項目の生成の一部としてのデータ・エントリ・フォームに内蔵するための使用可能な用語リストを示す例示としての図面である。
【図２４】本発明の一実施形態が生成したデータ・エントリ・フォーム内のブランチへのデータ・エントリ・フィールドの収集の追加を示す例示としての図面である。
【図２５】本発明の一実施形態が生成したデータ・エントリ・フォーム内の正しい位置の新規に追加したデータ・エントリ・フィールドを示す例示としての図面である。
【図２６】本発明の一実施形態が生成したデータ・エントリ階層のリスク・レジスタ・ブランチおよび構成要素を示す例示としての図面である。
【図２７】本発明の好ましい実施形態が生成したコンテキスト内の特定の分類（ＨＩＴ）「転落」を示す階層的構造の分類ブランチの例示としての図面である。
【図２８】本発明の好ましい実施形態が生成した分類（ＨＩＴ）内の一次分類部門の例示としての図面である。
【図２９】本発明の好ましい実施形態が生成した一次分類部門のすぐ下の階層レベルのところに位置する主要な質問の例示としての図面である。
【図３０】本発明の好ましい実施形態が生成した主要な質問のすぐ下の階層レベルのところに位置する分類質問の例示としての図面である。
【図３１】本発明の好ましい実施形態が生成した分類階層のリーフ・レベルのところに位置する低いレベルの質問の例示としての図面である。
【図３２】本発明の一実施形態が生成した主要な質問の下のレベルの階層ブランチ内の新規の分類質問を生成するためのスタート点の例示としての図面である。
【図３３】本発明の一実施形態が生成した階層内で新規の質問を生成する際に使用することができる使用可能な分類質問のリストの例示としての図面である。
【図３４】本発明の一実施形態が生成したデータ・マネージャ・モジュール内の主な機能ボタンの例示としての図面である。
【図３５】本発明の一実施形態が生成した主な医療事故管理画面の例示としての図面である。
【図３６】本発明の一実施形態が生成した医療事故表示選択画面の例示としての図面である。
【図３７】本発明の一実施形態が生成した要約医療事故統計画面の例示としての図面である。
【図３８】本発明の一実施形態が生成したデータ・マネージャ・モジュール内に位置する医療事故リンク機能の例示としての図面である。
【図３９】本発明の一実施形態が生成したタイプ患者医療事故の医療事故データ・エントリ・フォームを使用する新規の医療事故を生成するためのスタート点の例示としての図面である。
【図４０】本発明の一実施形態が生成したリスク・レジスタのためのデータ・エントリ・フォームの例示としての図面である。
【図４１】本発明の一実施形態が生成したデータ・マネージャ・モジュール内の主データ・エントリおよび分類画面の例示としての図面である。
【図４２】本発明の一実施形態が生成した完成中の分類質問のうちのいくつかを示すデータ・マネージャ・モジュール内の主データ・エントリおよび分類画面の例示としての図面である。
【図４３】本発明の一実施形態が生成した医療事故のために選択したいくつかの医療事故タイプを示すデータ・マネージャ・モジュール内の主データ・エントリおよび分類画面の例示としての図面である。
【図４４】本発明の一実施形態が生成した完成した分類階層の追加セクションを示すデータ・マネージャ・モジュール内の主データ・エントリおよび分類画面の例示としての図面である。
【図４５】本発明の一実施形態が生成した医療事故タイプ選択画面の例示としての図面である。
【図４６】本発明の一実施形態が生成した厳密評価コード選択画面の例示としての図面である。
【図４７】本発明の一実施形態が生成したデータ・エントリ・フォーム規則メッセージ画面の例示としての図面である。
【図４８】本発明の一実施形態が生成した最も下のレベルの詳細への分類階層質問の拡張の例示としての図面である。
【図４９】本発明の一実施形態が生成した閉医療事故画面の例示としての図面である。
【図５０】本発明の一実施形態が生成したプロジェクト・タスク画面の例示としての図面である。
【図５１】本発明の一実施形態が生成した通知選択画面の例示としての図面である。
【図５２】本発明の一実施形態が生成した実行医療事故報告選択画面の例示としての図面である。
【図５３】本発明の一実施形態が生成したある医療事故選択後にデータ・マネージャ・モジュールが作成した医療事故詳細報告の最初の部分の例示としての図面である。
【図５４】本発明の一実施形態が生成した特定の報告の基本属性を示すデータ・マネージャ・モジュール内の設定医療事故報告画面の例示としての図面である。
【図５５】本発明の一実施形態が生成した分析装置モジュール内の主機能ボタンの例示としての図面である。
【図５６】本発明の一実施形態が生成した分析装置モジュール内のユーザ・オプションおよび表示選択画面の例示としての図面である。
【図５７】本発明の一実施形態が生成した強調した報告および特定の報告の実行特性を示す実行報告選択画面の例示としての図面である。
【図５８】本発明の一実施形態が生成した強調したグループおよびグループに属する報告を示す実行報告グループ選択画面の例示としての図面である。
【図５９】本発明の一実施形態が生成した強調したバッチおよびバッチに属するグループを示す実行報告バッチ選択画面の例示としての図面である。
【図６０】本発明の一実施形態が生成したチャートを示す実行報告プレビュー画面の例示としての図面である。
【図６１】本発明の一実施形態が生成したチャート・データを示す実行報告プレビュー画面の例示としての図面である。
【図６２】本発明の一実施形態が生成した多重コラム報告を示す実行報告プレビュー画面の例示としての図面である。
【図６３】本発明の一実施形態が生成したリスク・マトリックスを示す実行報告プレビュー画面の例示としての図面である。
【図６４】本発明の一実施形態が生成したユーザが構成することができるチャートを示す実行報告プレビュー画面の例示としての図面である。
【図６５】本発明の一実施形態が生成した強調した報告および強調した報告設計の詳細を含む報告設計のリストを示す主報告設計画面の例示としての図面である。
【図６６】本発明の一実施形態が生成した強調した問い合わせおよび強調した問い合わせの詳細を含む問い合わせのリストを示す問い合わせ設計画面の例示としての図面である。
【図６７】本発明の一実施形態が生成した使用可能用語および使用できる分類および部分的に構成した問い合わせの詳細のリストを示す問い合わせ設計ビルダ画面の例示としての図面である。
【図６８】本発明の一実施形態が生成した強調した１つの報告設計および強調した報告設計の詳細およびチャート報告ウィザード・ボタンを含む報告設計のリストを示す新規または編集チャート報告設計画面の例示としての図面である。
【図６９】本発明の一実施形態が生成した強調した１つの報告設計および強調した報告設計の詳細を含む報告設計のリストを示す新規または編集非チャート報告設計画面の例示としての図面である。
【図７０】本発明の一実施形態が生成した主な機能ボタンを示すワークフロー・モジュール内の第１の画面の例示としての図面である。
【図７１】本発明の一実施形態が生成した維持ワークフロー設計画面の例示としての図面である。
【図７２】本発明の一実施形態が生成した一般特性タブを示すワークフロー設計編集画面の例示としての図面である。
【図７３】本発明の一実施形態が生成した簡単なワークフロー構造を表示するタスク定義タブを示すワークフロー設計編集画面の例示としての図面である。
【図７４】本発明の一実施形態が生成した入力したプロジェクトの詳細を含む一般特性タブを示すワークフロー・プロジェクト編集画面の例示としての図面である。
【図７５】本発明の一実施形態が生成した簡単なワークフロー構造および完了したタスク割当て詳細を表示するタスク定義タブを示すワークフロー・プロジェクト編集画面の例示としての図面である。
【図７６】本発明の一実施形態が生成したユーザに注目してもらいたいプロジェクトおよびタスクおよびデュー・タスクの基本プロジェクトの詳細を示すデータ・マネージャ・タスク再検討画面の例示としての図面である。
【図７７】本発明の一実施形態が生成したユーザに注目してもらいたいプロジェクトおよびタスクおよびプロジェクト・タスクの詳細を示すデータ・マネージャ・タスク再検討画面の例示としての図面である。
【図７８】本発明の一実施形態が生成したユーザに注目してもらいたいプロジェクトおよびタスクおよびタスク依存性を示すデータ・マネージャ・タスク再検討画面の例示としての図面である。
【図７９】本発明の一実施形態が生成したトリップ、スリップまたはスタンブル選択を示すワークフローのためのトリガ・データ・フィールドの定義の例示としての図面である。
【図８０】本発明の一実施形態が生成したワークフローに対するトリガ・データ・フィールドの選択の結果の例示としての図面である。
【図８１】本発明の一実施形態が生成した主な機能ボタンを示すアドミニストレータ・モジュールの第１の画面の例示としての図面である。
【図８２】本発明の一実施形態が生成したアドミニストレータ・モジュール内の組織定義ページの例示としての図面である。
【図８３】本発明の一実施形態が生成した一般的詳細エントリ・タブを示すアドミニストレータ・モジュール内のグループ定義ページの例示としての図面である。
【図８４】本発明の一実施形態が生成したアプリケーション詳細エントリ・タブを示すアドミニストレータ・モジュール内のグループ定義ページの例示としての図面である。
【図８５】本発明の一実施形態が生成したユーザ属性を示すアドミニストレータ・モジュール内のユーザ定義ページの例示としての図面である。
【図８６】本発明の一実施形態が生成したユーザ、グループおよび組織の組合わせに対する許可を示すアドミニストレータ・モジュール内の許可定義ページの例示としての図面である。
【図８７】本発明の一実施形態が生成したアドミニストレータ・モジュール内のデータ管理オプションの例示としての図面である。
【図８８】本発明の一実施形態が生成した目標データ項目の選択、組織階層へのリンケージを示すアドミニストレータ・モジュール内の目標定義ページの例示としての図面である。
【図８９】本発明の一実施形態が生成した監査報告選択基準およびサンプル報告出力を示すアドミニストレータ・モジュールの監査機能の例示としての図面である。
【図９０】本発明の一実施形態が生成したアドミニストレータ・モジュールのシステム登録キー機能の例示としての図面である。
【図９１】本発明の一実施形態が生成した主な機能ボタンを示すデータベース・アドミニストレータ・モジュールの最初の画面の例示としての図面である。
【図９２】本発明の一実施形態が生成したスクリプト／更新履歴の詳細および適用した個々のスクリプト／更新の詳細を示す主データベース管理画面の例示としての図面である。
【図９３】本発明の一実施形態が生成したインポート・マッピング定義、インポート目標組織およびマッピングしたフィールドを示すインポート機能画面の例示としての図面である。
【図９４】本発明の一実施形態が生成した記録した医療事故およびその基本属性のリストを示すウェブ・フォーム・モジュール医療事故管理ウェブ・ページの例示としての図面である。
【図９５】本発明の一実施形態が生成した医療事故記録データ・エントリ・フィールドを示すウェブ・フォーム・モジュールのデータ・エントリ・ウェブ・ページの例示としての図面である。
【図９６】本発明の一実施形態が生成したエージェント構成特性およびエージェント処理履歴の詳細を示すエージェント・モジュール・メイン画面の例示としての図面である。
【図９７】本発明の好ましい実施形態で実施したファイル・マッピング手順へのデータ項目を示すエクスポート・モジュール・プロセス方法の例示としての図面である。
【図９８】本発明の好ましい実施形態が生成したシステムの根本原因モジュールが行った根本原因分析の抽象的結果内に示す根本原因分析ツリーの例示としての図面である。
【符号の説明】
【０１４６】
１．ＡＩＭＳシステム
２．ＡＩＭＳデータベース
３．コンピュータ
４．デバイス
５．ネットワーク
６．病院Ａ−１
７．病院Ａ−２
８．領域
９．全国レベルの実施
２１．医療事故報告機構
２２．医療事故
２３．ＡＩＭＳシステム
２４．解釈
２５．改訂分類構造
３１．主モジュール構造
４２．ランシマン・モデル
５１．組織
５２．用語
５３．データ・エントリ・フォーム
５４．分類階層
５５．医療事故分析
５６．データ・エントリ
５７．分類
５８．医療事故記録
６１．治療薬／栄養分類グループ分け
６２．分類のグループ分け
６３．投薬／ＩＶ流体
７４．一次分類部門
８１．主な質問
８３．分類質問
１０１．例示としての分類階層
１０２．用語（アセタゾラミド）
１１１．オープンボタン
１１２．設計ボタン
１１３．ヘルプ
１１４．エクシット
１２１．サーバー
１２２．データベース
１２３．ユーザー
１２４．パスワード
１３１．機能ボタン
１３２．ドメイン構造
１３３．ノード特性
２０１．通知
２０２．管理
２０３．ブランチ
２０４．ブランチ
２０５．新しいボタン
２５１．編集ボタン
２５２．削除ボタン
２６１．リスクレジスタデータエントリフォーム
３３１．質問セクション
３３２．使用可能用語リスト
３３３．セーブボタン
３３４．選択した用語パネル
４３１．医療事故タイプ
４３２．医療事故タイプ
４３３．追加データエントリフィールド
４９１．データフィールド
４９２．分類に対する標的
４９３．分類項目
４９４．完全又は不完全
５１１．データ入力項目
５２５．印刷ボタン
５６１．フォーマット
５６２．フィルター
５６３．ソート
５７３．報告
６５４．報告
６７２．用語
６７３．ツリー
７１２．編集ボタン
７２１．データエントリータブ
８８１．目標項目
８８２．データエントリーフォーム
９３１．マッピング定義
９６２．検索周期
【図１】
2006301730.tif 000003
【図２】
2006301730.tif 000004
【図３】
2006301730.tif 000005
【図４】
2006301730.tif 000006
【図５】
2006301730.tif 000007
【図６】
2006301730.tif 000008
【図７】
2006301730.tif 000009
【図８】
2006301730.tif 000010
【図９】
2006301730.tif 000011
【図１０】
2006301730.tif 000012
【図１１】
2006301730.tif 000013
【図１２】
2006301730.tif 000014
【図１３】
2006301730.tif 000015
【図１４】
2006301730.tif 000016
【図１５】
2006301730.tif 000017
【図１６】
2006301730.tif 000018
【図１７】
2006301730.tif 000019
【図１８】
2006301730.tif 000020
【図１９】
2006301730.tif 000021
【図２０】
2006301730.tif 000022
【図２１】
2006301730.tif 000023
【図２２】
2006301730.tif 000024
【図２３】
2006301730.tif 000025
【図２４】
2006301730.tif 000026
【図２５】
2006301730.tif 000027
【図２６】
2006301730.tif 000028
【図２７】
2006301730.tif 000029
【図２８】
2006301730.tif 000030
【図２９】
2006301730.tif 000031
【図３０】
2006301730.tif 000032
【図３１】
2006301730.tif 000033
【図３２】
2006301730.tif 000034
【図３３】
2006301730.tif 000035
【図３４】
2006301730.tif 000036
【図３５】
2006301730.tif 000037
【図３６】
2006301730.tif 000038
【図３７】
2006301730.tif 000039
【図３８】
2006301730.tif 000040
【図３９】
2006301730.tif 000041
【図４０】
2006301730.tif 000042
【図４１】
2006301730.tif 000043
【図４２】
2006301730.tif 000044
【図４３】
2006301730.tif 000045
【図４４】
2006301730.tif 000046
【図４５】
2006301730.tif 000047
【図４６】
2006301730.tif 000048
【図４７】
2006301730.tif 000049
【図４８】
2006301730.tif 000050
【図４９】
2006301730.tif 000051
【図５０】
2006301730.tif 000052
【図５１】
2006301730.tif 000053
【図５２】
2006301730.tif 000054
【図５３】
2006301730.tif 000055
【図５４】
2006301730.tif 000056
【図５５】
2006301730.tif 000057
【図５６】
2006301730.tif 000058
【図５７】
2006301730.tif 000059
【図５８】
2006301730.tif 000060
【図５９】
2006301730.tif 000061
【図６０】
2006301730.tif 000062
【図６１】
2006301730.tif 000063
【図６２】
2006301730.tif 000064
【図６３】
2006301730.tif 000065
【図６４】
2006301730.tif 000066
【図６５】
2006301730.tif 000067
【図６６】
2006301730.tif 000068
【図６７】
2006301730.tif 000069
【図６８】
2006301730.tif 000070
【図６９】
2006301730.tif 000071
【図７０】
2006301730.tif 000072
【図７１】
2006301730.tif 000073
【図７２】
2006301730.tif 000074
【図７３】
2006301730.tif 000075
【図７４】
2006301730.tif 000076
【図７５】
2006301730.tif 000077
【図７６】
2006301730.tif 000078
【図７７】
2006301730.tif 000079
【図７８】
2006301730.tif 000080
【図７９】
2006301730.tif 000081
【図８０】
2006301730.tif 000082
【図８１】
2006301730.tif 000083
【図８２】
2006301730.tif 000084
【図８３】
2006301730.tif 000085
【図８４】
2006301730.tif 000086
【図８５】
2006301730.tif 000087
【図８６】
2006301730.tif 000088
【図８７】
2006301730.tif 000089
【図８８】
2006301730.tif 000090
【図８９】
2006301730.tif 000091
【図９０】
2006301730.tif 000092
【図９１】
2006301730.tif 000093
【図９２】
2006301730.tif 000094
【図９３】
2006301730.tif 000095
【図９４】
2006301730.tif 000096
【図９５】
2006301730.tif 000097
【図９６】
2006301730.tif 000098
【図９７】
2006301730.tif 000099
【図９８】
2006301730.tif 000100
【外国語明細書】
2006301730000001.pdf
2006301730000002.pdf
2006301730000003.pdf
2006301730000004.pdf