JP4658036B2 - 機能増強型データ記録システム及びデータ記録方法 - Google Patents

Description

本発明は、グラフィカルユーザインタフェースに関する改良に関連し、より詳細には、医療従事者が患者を診断し治療する際に使用するグラフィカルユーザインタフェース(GUI)を提供するものである。

医療提供関係者は、ケアの水準を高めつつコストを削減するというプレッシャーに常に苛まれており、これらの難題に対処する助けとなる情報技術に対する期待は益々高まっている。特定の作業に職員が費やす時間を削減することによって、健康管理組織は、労働コストを節約でき、より多くの患者を治療することができ、効率をより高めることができる。高い効率を達成するに際しての最大の障害の１つとして、旧来の紙に基づいたシステム、特に患者記録に関するシステムが挙げられる。

患者記録は法的必要条件であり、患者の健康履歴を記録するために医療従事者が使用するものである。大多数の患者記録は依然として紙上にまとめられた情報よりなり、病院、一般開業医院等といった異なる医療機関ごとに、別個の記録の集合が保管されている。実際、同じ病院の中でさえ、患者が治療を受けている医師、診療科、病棟等ごとに多くの記録が別個に保管されていることもある。そのような記録の物理的な管理は、医療提供関係者にとって相当の負担となっており、例えば大きな地域総合病院では年間40,000〜80,000件の患者記録を現場で保管する必要がある。それほど頻繁にアクセスされない記録は別の場所で保管することができるが、現場での保管施設は、治療区域、病床、管理職員用オフィス空間または駐車場にも使用できるような貴重なスペースを占有している。紙に基づいた患者記録の管理、すなわち記録をファイルし、検索し、必要とされている場所へ送達することに関係する財政的コストは、相当なものである。健康管理システム内で記録を迅速に移送することはできず、また患者記録を置き忘れたり紛失したりすることも珍しくなく、患者の治療の遅れ（予約に合わせて到着した後に家に送られなければならないことのある患者の場合）および患者の秘密保護に対する懸念につながり得る。

加えて、分析のために紙の記録から情報を抽出することは、面倒で費用がかかる。このために、管理目的として、紙に基づいた記録の高水準電子的要約を提供するために、ローカルな「患者管理システム（PAS）」が病院に導入されている。PAS記録の情報には、患者番号、生年月日、入院・治療・退院の日付、患者が治療を受けている医師の氏名、並びに診断や処置を示すコード（つまり「国際疾病分類コード(ICD)」や「手術手順コードシステム(OPCS)」に基づくコード）等が含まれる。よってPAS記録から記録を容易に抽出して、内部使用のため、若しくはより広範な人口統計的精査システムへの供給として、病院が提供する患者のケアに関する統計情報を生成することができる。さらにこのシステムは、患者記録を追跡する際の助けにもなる。しかし、主な機能は臨床的というよりははむしろ管理的なものであって、PAS記録には医療従事者が患者を治療するために必要とする詳細な情報が含まれていない。

高齢者人口による健康管理システムに対する需要が高まり、これまでになく多数の患者が一度に治療を必要とすることになると、紙に基づいた患者記録システムに関係する困難及び問題が今後悪化することは必至である。効率的な患者記録管理は将来的に質の高い患者ケアを提供するにあたって必須事項であると考えられており、紙を追い回していた過去のやり方に終止符を打つ電子患者記録(EPR)の導入によって実現され得ると期待されている。EPRシステムは試行的にはすでに首尾よく具体化されており、１機関における一人の患者の全記録を、その機関の電子患者記録管理システム(EPRMS)とネットワーク化されたあらゆるワークステーションからアクセス可能な電子フォーマットでまとめている。

EPRMSは現在のところ局所的なものであり、個々の病院／一般開業医院が別個のシステムを導入している。しかし、国内規模のシステムも徐々に見られるようになってきており、それにより患者に関する情報が、患者自身のように移動可能となり、患者がケアを必要とする時にどこででも権限のある医療従事者が利用できるようになるであろう。

さらに、EPRMSを開発して、医療従事者に対し、手動または他の自動化システムを補助的に使用することなく一つのワークステーションで患者記録を見て、処理し、完成させることを可能にする完全な一揃いのソフトウェアアプリケーションを提供することが意図されている。

一つ重要な懸念となっているのは、病状を診断し治療する方法に関する新しい研究および最善の診療ガイドラインの最新情報を、常に医療専門家に提供することである。現在、医学の最善診療ガイドラインは、発表された研究文献の精査を行い、コンセンサスプロセスを経て、手に入れ得る証拠を評価することによって作成されており、同僚によって再検討、承認されている。その後ガイドラインは、発表され、医師の間に広まっていく。しかしこれは、医療従事者がガイドラインを読んで習得し、適切な状況となった時に実際に使用するということに頼っているものである。現実には、これは開業医、特に一般開業医に対し、過酷な仕事量にもかかわらず、医学的進歩に充分について行くための面倒な作業や多くの苦労を強いるものである。

また、専門病院の診察環境および一般開業医院のどちらにおいても、診察環境において対処しなければならない膨大な時間的プレッシャーが存在する。例えば英国では、一般開業医院での平均診察時間は、８〜１０分である。この間に一般開業医は、患者の記録を見直し、患者と面談し、何らかの必要な検査を行い、診断し、適切な治療形態を選択し、処方箋を出さなければならない。

ある状況においては、医療従事者は、特定の症状や状態についてさらなる情報を見つけ出す必要がある場合がある。インターネットはデスクトップ端末を通じて豊富な資料を入手可能にしたが、ワールドワイドウェブのサーチは一般に、関連情報が得られるまでに評価し斟酌する必要がある何十もの結果を返してくるものであり、これら全てに診察環境における貴重な時間を費やすことはできない。加えて、インターネット上で公開される情報は統制するのが難しく、同僚が精査した医療文献と同じ厳しい評価は受けていない。それにもかかわらず、医療従事者がケアを提供することについての要求は非常に高いので、時としてそうした情報に頼らざるを得なくなるようなプレッシャーを受けることもある。

統制された情報は、所有者のいる第三者知識ベースからの方が得られる可能性が高い。しかし、このような資源は、使用するのに面倒で時間がかかる場合がある。いかなるシステムでも一つのシステムが開業医のニーズを全て満たすことはまずないので、開業医は、所望の情報を引き出すためには、様々なシステムの様々な使用技術を覚えて使用することが必要となる。

EPRMSを通じてケアの現場で開業医がガイドラインを利用できるようにする試みは、とりわけGLIF及びSAGE研究プロジェクトによって行われている。GLIFプロジェクトは、臨床ガイドラインを表現するための共通言語、すなわち、いわゆるGUIdeLine Interchange Format（ガイドライン互換フォーマット）を開発しており、その目標はGLIF表現を健康管理組織が利用できるようにし、それによりガイドラインがローカル臨床情報システムで使用できるようにすることである（医療機関が一般的ガイドラインを、少なくとも何らかの若干のローカル修正も行わずに受け入れることはまずあり得ない、ということがわかっている）。対照的に、Standard-based sharable Active GUIdeline Environment (SAGE)（標準に基づいた共有可能なアクティブガイドライン環境）は、ガイドラインに基づいた意志決定支援システムをローカル臨床情報システムと統合する最善の方法にその努力を集中させてきた。SAGE意思決定支援エンジンは、推奨ガイドライン、並びに証拠および根拠へのアクセスを既存の臨床ワークフローに統合するものである。しかし、GLIF又はSAGE方法論のどちらかを用いてこれまでに具体化されている臨床支援システムでは、医療従事者が予備診断を行うことが必要であり、予備診断の後、診断を支援する情報を提供し、必要な付加的検査または行為を助言するものである。

現実には、診察環境における診断は必ずしも容易でない。一般に患者が示している１つ以上の新しい症状は、現在の状態及び過去の病歴と関連づけて検討しなければならない。GLIFおよびSAGEは、臨床支援システム内に事前にコード化されたケア経路が存在することを前提としており、新しく呈示された症状が、既に行った診断や患者の病歴の他の詳細と組み合わせて検討されなかった場合には、適切なケア経路が存在しないことになる。これらの方法論は本質的に融通がきかないので、患者が示し得るすべてのバリエーションや組合せについて既定の経路を生成することは不可能であるので、ケアの現場において医療従事者の必要性を満たすことができない。

上述の課題の一部を克服するか、または実質的に低減することが望ましい。より詳細には、各自の機能を実行する際にユーザを援助して、例えば患者のケアの提供において医療従事者を援助して、当該グラフィカルユーザインタフェースを通じて提供され得る支援情報とのより迅速な対話を促進するグラフィカルユーザインタフェースを提供することが望ましい。これは、医療従事者の置かれている状況において、彼らが最善業務ガイドラインに従ってケアを提供することを可能にする。

本発明は、ワークフロープロセスのステップの図形的表現を提供することが、ワークフロープロセスにおけるデータ入力および指示のためにそのインタフェースが使用された時に極めて有利となり得るという評価に帰せられる。

本発明の一態様によれば、ワークフロープロセスの間にユーザと対話するためのグラフィカルユーザインタフェース(GUI)が提供され、GUIは、保存されているワークフロープロセスにおける相互リンクしている複数のステップの構造を図形的に表現する、相互リンクしている複数のノードを含むページと、選択された特定のノードに関するデータを入力するためのデータ入力手段であって、ノードはワークフロープロセスにおけるステップと一意の関係を有しており、入力されたデータを用いてワークフロープロセス内での特定の経路を決定するための経路手段と、ページにおいてワークフロープロセス内の結果的に得られた経路を図形的に表現するための手段とを含む。

相互リンクされたノードのページは、辿るべきワークフロープロセスの少なくとも一部のマップを提供する。ワークフローの表現は、このようにして、ユーザとの単純かつ直観的な対話を可能にする。各ノードはワークフロープロセスにおけるステップと直接的な関係を有するので、データ入力およびユーザ対話は加速される。

好ましくは、相互リンクしている複数のノードは、ワークフロープロセス全体を単一のページにおいて提示する。これは、ユーザがワークフローの異なるステップを辿る際に各自の履歴を直接見ることができるばかりでなく、特定のワークフローの終点を一目で決定できることから、特に有利である。

本発明は、多段階プロセスにおいて、複数の段階が単一のページ上で示され、それによりユーザが自己の履歴を一目で見ることができるばかりでなく、決定プロセスにおいて自己の診断で誤りを犯したかもしれない箇所まで追跡して戻ることができるという重要な利益を有する。

本発明の実施形態において、有用な情報は、臨床の最善業務ワークフローの内部でコンテキスト化され得て、より効果的なグラフィカルユーザインタフェースが、患者の懸念、疑わしい診断または発現した徴候のいずれかから始まり、ワークフロー内を健康管理開業医(healthcare practitioner)が直観的に移動できるようにすることによって実現され得る。

データ入力手段は好ましくは、相互リンクしている複数のノード内の選択されたノードの位置に関連するデータを提示するための提示手段と、そのデータの少なくとも一部のユーザ選択を可能にするための選択手段とを含む。このようにして、ユーザは、マップ内での各自の位置に応じて入力すべき関連データが提示され得て、それを単純に選択することができる。これは、例えば健康管理開業医にとってデータ入力を有利に加速し、より容易にする。

好ましくは、データ入力手段は、第１のノードで入力されたデータを使用して第１のノードにリンクされた第２のノードにおいて必要なさらなる情報を決定するように構成されている。このようにして、特定のデータは、一度入力されるだけで済み、しかも異なるノードにおいて何度でも使用され得る。

GUIはまた、入力されたデータをそのデータを表現する分類コードに変換するための手段を含み得る。これは、GUI内部でのあらゆるデータの統一的な表現が実現されることを可能にする。これは、同じ分類コードが理解され得る外部システムとリンクしている場合に特に有利である。

好ましくは、GUIは、入力されたデータを分析しそれに関係する行為のリストを生成するための分析手段および、関係する行為のリストを複数の表示された相互リンクされたノードの近傍のユーザにリスト化するためのリスト手段をさらに含む。これは、マップを案内するプロセスのほとんど副産物としてタスクが生成されることを可能にし、それによりユーザは、基となるワークフローによって正しく案内されるだけでなく、決定される帰結として彼らが実行する必要がある行為の多くを有するという利益を有する。この行為のリストはその後、そうした行為が行われるように自動的に命令するように処理され得る。例えば、そのリストから血液検査が患者に対し命じられ得るであろう。

行為リスト手段は、そのページを含んでいる相互リンクしている複数のノードの通過の最後に、各行為のユーザ確認のためのオプションとともにリストをユーザに提示し、ユーザ確認から具体化される行為のリストを決定するように構成され得る。このようにして、ユーザが必要であると感じたそれらの行為だけが実行される。

各ノードは好ましくは、ノードに設けられ、ユーザ選択時にノードに関係する情報を提示するための情報手段をさらに含む。これは、ユーザがワークフロー内を進行し、各ノードでの決定に必要ないずれかのさらなる関連情報を取得することを助ける。

マップは好ましくは、ユーザの選好に適応するためにカスタマイズ可能である。より詳細には、GUIは、特定のノードに関するユーザ生成テキストノートを記録するためのノート記録手段をさらに含み、ノート記録手段は、ノートを特定のノードにリンクして、それによりユーザがその特定のノードに案内された時に保存されたノートが検索可能なように構成されている。

GUIは、ユーザ決定ノートを送信可能メッセージに変換し、メッセージをGUIのバージョンにアクセスできる別のユーザに送信するためのフィードバック生成手段をさらに含み得る。これは、マップの使用に起因する質問が迅速かつ有効な様態で取り扱われることを可能にし、フィードバックの脈絡をより正確に伝える際にしばしば助けとなる。

好ましくは、GUIは電子患者記録管理システム(EPRMS)にアクセスすることができ、GUIは、ページの一部において選択された電子患者記録の詳細を取得し提示するためのEPRMS管理手段をさらに含む。これは本発明の極めて有利な態様である。電子患者記録との統合は、患者について以前に保存された情報がワークフローの進行を援助するために使用され得るという点で、極めて有益となり得る。さらに、ワークフロープロセスにおいて得られたデータは、患者記録を同時に更新するために使用され得て、それによって患者の履歴のより正確なビューをいつでも提供できる。

EPRMS管理手段は、選択された電子患者記録の詳細を使用してノードにおいてユーザからどのような情報が要求されるかを決定するように構成され得る。このようにして、マップは、すでに患者記録にあるデータに応答し、それらによって形成され得る。

GUIは好ましくは、外部アクセス可能な知識ベースをサーチするためのサーチ手段をさらに含み、サーチ手段は、選択された情報トピックをそのトピックを表す既定の分類コードに変換し、その分類コードを情報要求に含めて知識ベースに送信し、知識ベースに含まれている関連情報を得るように構成されている。このようなコードの使用は、実行すべきサーチの要求条件を備えない知識ベースへの直接アクセスを可能にするので、極めて有利である。これはさらに、所要の情報を取得するために要する時間を最小限にする。これに関して好ましくは、分類コードは、ワークフロープロセスの対象に関して入力され得る全範囲のデータを記述している標準的分類コードを含む。これは、要求の改善された適用範囲およびより良好な互換性を助成する。

サーチ手段は、情報要求への応答を受け取り、応答を使用してユーザへの表示のために複数のページのうちの関連するページを決定するように構成され得る。このようにして、受け取られた情報は、各自のサーチ照会に大きく関連するワークフロープロセスにおける特定の出発点にユーザを振り向けるために使用され得る。

好ましくはGUIは、複数の相互接続されたノードをページ上で編集するための編集手段をさらに含み、編集手段は、ページになされたあらゆる変更を反映するために保存されたワークフローを更新するように構成されている。GUIの編集可能な性質は、有利にはユーザが、必要とされるワークフローにおけるあらゆる局所変更を考慮することを可能にする。ユーザに対する権限のレベルは、彼らがマップに変更を行うことが許される範囲を決定し得る。

GUIは好ましくは、相互リンクしている複数のノードを通るユーザナビゲーションを記録するための記録手段をさらに含む。これは、多くの形で使用され得るワークフロー内で取った経路の履歴をユーザに提供する。

GUIは、ワークフロープロセス内で取った正確な経路を決定するためにユーザナビゲーションを分析するためのナビゲーション分析手段をさらに含み得る。このナビゲーション履歴は、監査およびユーザの遂行の分析のために使用され得る。

本発明の別の態様によれば、ワークフロープロセスの間にユーザと対話するためのグラフィカルユーザインタフェース(GUI)が提供され、GUIは、保存されたワークフロープロセスの相互リンクしている複数のステップの構造を図形的に表現する相互リンクしている複数のノードを含んでいるマップと、選択した特定のノードに関するデータを入力するためのデータ入力モジュールと、ノードはワークフロープロセスにおけるステップと一意の関係を有しており、入力されたデータを用いてワークフロープロセス内での特定の経路を決定するための経路モジュールと、マップにおいてワークフロープロセス内の結果的に得られた経路を図形的に表現するための表示モジュールとを含む。

本発明の別の態様によれば、ワークフロープロセスを保存する知識ベースとのユーザインタフェースを提供するためのグラフィカルユーザインタフェース(GUI)が提供され、GUIは、保存されたワークフロープロセスの相互リンクしている複数のステップの構造を図形的に表現する相互リンクしている複数のノードを含むページと、選択した特定のノードに関するデータを入力するための手段と、ノードは保存されたワークフロープロセスにおけるステップと一意の関係を有しており、入力されたデータを用いてワークフロープロセス内での特定の経路を決定するための手段と、ページにおいてワークフロープロセス内の結果的に得られた経路を図形的に表現するための手段とを含む。

本発明の別の態様によれば、ワークフロープロセスの間にユーザと対話するためのグラフィカルユーザインタフェース(GUI)が提供され、GUIは、複数の相互関係のあるワークフロープロセスを表現する複数のページと、各ページは、保存されたワークフロープロセス内の相互リンクしている複数のステップの構造を図形的に表現する相互リンクしている複数のノードを含んでおり、選択した特定のノードに関するデータを入力するためのデータ入力手段と、ノードはワークフロープロセスにおけるステップと一意の関係を有しており、入力されたデータを用いてワークフロープロセス内での特定の経路を決定するための決定手段と、ページにおいてワークフロープロセス内の結果的に得られた経路を図形的に表現するためのグラフィック手段とを含む。

本発明はまた、グラフィカルユーザインタフェース(GUI)を用いてワークフロープロセスの間にユーザと対話する方法にも及び、方法は、GUIのページを生成することと、ページはワークフロープロセスの相互リンクしている複数のステップの構造を図形的に表現する相互リンクしている複数のノードを含んでおり、選択した特定のノードに関するデータを入力することと、ノードはワークフロープロセスにおけるステップと一意の関係を有しており、入力されたデータを用いてワークフロープロセス内での特定の経路を決定することと、ページにおいてワークフロープロセス内の結果的に得られた経路を図形的に表現することとを含む。

本発明の別の態様によれば、ワークフロープロセスの間にユーザと対話するためのグラフィカルユーザインタフェース（GUI）が提供され、GUIは、外部アクセス可能な知識ベースをサーチするためのサーチ手段を含み、サーチ手段は、選択された情報トピックをそのトピックを表わす既定の分類コードに変換するための変換手段と、情報要求内のその分類コードを、その中に含まれた関連情報にアクセスするために知識ベースに通信ネットワークによって送信するための送信手段とを含む。

このGUIは、いずれのサーチも実行されることを必要とせずに外部知識ベースへのアクセスを付与する。これは、それらの知識ベース内に含まれたデータへのより高速でより正確なアクセスを可能にするので、極めて有利である。

変換手段が、既定の分類コードのローカルデータベースおよび、各々が特定の分類コードにマップされている特定の情報トピックの関係するリストをさらに含む場合、実用的なインプリメンテーションが実現される。従って、ユーザによって指定されたトピックが、ローカルデータベースを用いて、情報要求のための適切なコードを予めまたはリアルタイムで調べるために使用され得る。

本発明はまた、グラフィカルユーザインタフェース（GUI）を用いてワークフロープロセスの間にユーザと対話する方法にも及び、方法は、外部アクセス可能な知識ベースをサーチするためにGUIからユーザ命令を受け取ることと、選択された情報トピックをそのトピックを表す既定の分類コードに変換することおよび、情報要求内のその分類コードを、その中に含まれた関連情報にアクセスするために知識ベースに通信ネットワークによって送信することによって、知識ベースのサーチを開始することとを含む。

本発明の別の態様によれば、ワークフロープロセスの間にユーザと対話するためのグラフィカルユーザインタフェース（GUI）が提供され、GUIは、保存されたワークフロープロセスの相互リンクしている複数のステップの構造を図形的に表現する相互リンクしている複数のノードを含むページと、相互リンクしている複数のノードを編集するための編集手段と、保存されたワークフロープロセスの相互リンクしている複数のステップを、相互リンクしている複数のノードになされたあらゆる対応する変更で更新するための更新手段とを含む。このようにしてワークフロー表現の編集を可能にすることは、ワークフロー表現の局所変更が実行されることを可能にするので、極めて有利である。これは、前述した従来技術のシステムの硬直性を軽減する。

本発明の別の態様によれば、ワークフロープロセスの間にユーザとの分散形対話を支援するためのシステムが提供され、システムは、ワークフロープロセスの中央に保存された図形的表現と、中央に保存された表現から遠隔に位置し、ユーザ階層において互いに関連する複数のユーザと、各ユーザは表現のバージョンにアクセスすることができ、紹介メッセージを生成するために表現の各バージョンの内部に設けられた紹介手段とを含み、紹介手段はユーザ階層において次の高位レベルの査閲者にメッセージを送るように構成されている。

本発明のこの態様は、何十万ものユーザが存在し得るシステムによってフィードバックが制御された方式で生成され取り扱われることを可能にする。

本発明の別の態様によれば、グラフィカルユーザインタフェース（GUI）の新バージョンをユーザに配布するためのシステムが提供され、システムは、ワークフロープロセスのGUI表現を保持している中央の記憶装置と、中央の記憶装置から遠隔に位置し、中央の記憶装置の下でユーザ階層において互いに関連する複数のユーザと、各ユーザは以前の表現のバージョンにアクセスすることができ、いずれかの相違を決定するためにユーザの表現の以前のバージョンと表現の新バージョンを比較するための比較手段と、検討のために表現のそのバージョンと関係するユーザにそれらの相違を転送するための転送手段と、表現の個々の以前のバージョンの内部に設けられたレビュー手段とを含み、レビュー手段は、相違を受容または拒否し、受容または拒否を階層内の高位レベルへ伝達するように構成されている。

これは、何を受け入れるかを制御するコンテントエディタの能力を使用可能にする制御された様態で多くのユーザ間で更新を配布する一法を提供する。

本発明の別の態様によれば、グラフィカルユーザインタフェースを構成する方法が提供され、方法は、特定のワークフローに関する内容をコレートすることと、その内容を階層的に構造化されたワークフローの一連のステップとしてデータベースに記録することと、ユーザをワークフロー内で案内するために使用され得る階層的ワークフロー構造の図形的表現を生成することとを含み、図形的表現は各ノードが階層的ワークフロー構造の内部の特定のポイントに対応する相互リンクしている複数のノードを含んでいる。

これは本発明の１つの新規の態様であり、すなわち、ソフトウェアアプリケーションおよびGUIは、マップの内容の周辺に設計および構築され、内容へのソフトウェアアプリケーションの以後の追加を助成する。この分野における他の全部のアプリケーションは、まず第一にソフトウェアアプリケーションとして構築されて、後に内容を追加する。

グラフィカルユーザインタフェースを介して改善された患者のケアを提供するための本発明の好ましい実施形態に従った方法および装置について、添付図面に関して以下に例証として説明する。

図１に関して、本発明の現在好ましい実施形態を具体化するための通信システム１００をここで説明する。通信システム１００は、医療機関と、患者のケアの提供を援助するために電子診断・治療ツールの一式を利用可能にするグラフィカルユーザインタフェースを付与する所有者システムとの間の通信を助成する。グラフィカルユーザインタフェースは、疑わしい診断または発現した徴候に始まる一連の患者のケア経路を、臨床ワークフローまたは「ロードマップ」の図形的表現の形態で提示する。個々の患者のケア経路は、最善業務ガイドラインに合致し、以下「ノード」と称する一連の行為または決定点に分解される。健康管理開業医(healthcare practitioner)が患者を正しく管理するために要する必要な情報およびソフトウェアツールの全部は、適切なノードにおいて、以下「医療マップ(Map of Medicine)」と称するロードマップに埋め込まれている。インタフェースでは、健康管理開業医がマップを辿るルートを案内および記録する両方が可能である。案内機能は臨床ガイドラインに従って患者のケアを最適化するのを助け、記録機能はさらに医療マップを研修および監査目的に使用できるようにする。

上記の通信システム１００は、分散形所有者システム１０２、種々の医療機関に配置された複数のコンピュータ装置１０４、中央EPRMS１０６および、医療機関によってアクセスされるいずれかのローカルEPRMS１０８（そのデータは定期的に中央EPRMS１０６にアップロードされる）、複数の第三者知識ベース１１０、および上記の全部が接続されている通信ネットワーク１１２より構成される。医療マップは、通信ネットワーク１１２を通じて所有者システム１０２によって医療機関内のコンピュータ装置１０４に提供される。通信ネットワーク１１２は、物理的にはリンクされているが実質的に閉じられている安全な態様を有する開放型ネットワークであり、従ってそれは、インターネットといった一般的な広域通信ネットワーク（図示せず）内の仮想プライベートネットワークとみなされ得る。第三者知識ベース１１０からの情報は、医療マップインタフェース上のノードを通じてコンピュータ装置１０４にアクセス可能である。

図１では、２つのコンピュータ装置１０４、１つのローカルEPRMS１０８および２つの第三者知識ベース１１０だけが図示されている。両方のコンピュータ装置１０４は、現在の説明の目的でコンピュータ端末であると解され、第１のコンピュータ端末１１４は中央EPRMS１０６にアクセスし、第１のものとは異なる医療機関にある第２のコンピュータ端末１１６はローカルEPRMS１０８にアクセスする。中央EPRMS１０６によって保存された電子患者記録からの情報は、第１のコンピュータ１１４に提供された医療マップに取り込まれ得て、ローカルEPRMS１０８によって保存された電子患者記録からの情報は、第２のコンピュータ１１６に提供された医療マップに取り込まれ得る。代替として、コンピュータ端末１１４および１１６の各々は、例えば、コンピュータ装置１０４のブラウザ（図示せず）に特定のユニフォームリソースアイデンティファイヤ(URL)を入力することによって、各自のEPRMS（複数）とは独立して医療マップにアクセスすることができる。

分散形所有者システム１０２は、中央所有者サブシステム１１８、バックアップ所有者サブシステム１２０および複数のローカル所有者サブシステム１２２（それらのうちの１つだけが図１に図示されている）より構成される。所有者サブシステム１１６、１１８および１２０の各々は、医療マップサーバ１２４および医療マップデータベース１２６を備えており、ネットワーク通信マネージャ(NCM)１２８を通じて通信ネットワーク１１２に接続している。ローカル所有者サブシステム１２２の場合、NCM１２８はまた、サブシステム１２２をローカルEPRMS１０８に接続している。

中央所有者サブシステム１１８は、医療マップのマスターコピーおよび医療マップの局所化バージョンの両方のほか、これらに関係するデータを保存および提供する。マップの局所化バージョンは、例えばコストの問題のために別のものと比較してある特定の薬剤を治療に指定するなど、それぞれの臨床スタッフによる使用のために地域医療機関によってカスタマイズされたものである。中央所有者サブシステム１１８は、バックアップ所有者サブシステム１２０によって複製されており、それにより医療マップは中央システムの故障の場合でも医療機関に依然として提供され得る。加えて、特定の地域医療機関（または機関のグループ）は、ローカル所有者サブシステム１２２によって提供および保存される各自の医療マップの局所化バージョンおよび関係するデータを有することを保証するために十分な規模とし得るが、局所化されたマップおよび関連するデータのコピーは中央所有者サブシステム１１８およびバックアップ所有者サブシステム１２０によってやはり補足的に維持されるであろう。特定の地理的領域における医療マップを取り扱うためにローカル所有者サブシステム１２２を有する重要な利益は、要求される外部ネットワーク接続性の低減であり、それはその地域における機関にとってマップの配信および応答時間を改善する。

例えば中央所有者サブシステム１１８、バックアップ所有者サブシステム１２０およびローカル所有者サブシステム１２２の間に見られる通り、システム１００のモジュール性は、必要な場合、さらなる下位レベルが全システム１００の内部に設けられることを可能にする。これは転じて、これらの下位レベルで要求される外部ネットワーク接続性のさらなる低減をもたらす。

個々の医療マップサーバ１２４は、それがどの外部システムと通信しなければならないか、例えば、他の所有者サブシステムのうちのいずれに更新を送りいずれから更新を受け入れなければならないか、それがどのEPRMSシステム１０６、１０８と通信できるか、それがどの第三者知識ベース１１０にアクセスできるか、それがどの医療機関に医療マップを提供できるかを指定するように構成されている。医療マップグラフィカルユーザインタフェースは、医療マップデータベース１２６に保存されている様々な健康問題を扱っている、拡張可能なマーク付け言語(XML)で書かれた一連の相互リンクされたページの形態を取り、各ページは、その特定の健康問題の標準化臨床コード（例えばSNOMED−CTコード）によって識別されている。しかし、マップからのページは一般に、それが大部分のブラウザが使用するために構成され得る言語であることから、医療マップサーバ１２４によってハイパーテキストマークアップ言語(HTML)に変換されてから、要求側コンピュータ端末１１４、１１６のブラウザ（図１には図示せず）に配信される。

種々の医療機関およびそれらの機関からの健康管理開業医は、それに照らしてマップの適切なバージョンの詳細が医療マップデータベース１２６に保存される識別子を割り当てられる。従って、例えば、コンピュータ端末１１４を使用する健康管理開業医には中央所有者サブシステム１１８から医療マップが提供され、各自のユーザＩＤは、彼らがマップのマスターバージョンを受け取るのか、または彼らが関係する医療機関によって指定されたローカルバージョンを受け取るのかを決定する。加えて、マップ内のノードで健康管理開業医によって作成された個人化されたノートもまた、ユーザＩＤに照らして医療マップデータベース１２６に保存され得る。それ故、健康管理開業医がマップから特定のページを要求すると、彼らがそのページ上でノードに対して以前に作成したいずれかの個人化ノートが、彼らのユーザＩＤに照らして医療マップデータベース１２６に保存され、そして彼らが提供されるページに取り込まれ得る。マップを使用する時に健康管理開業医によってどのような行為が許されるかを指定する許可のリストもまた、彼らが研修および監査目的のためにマップを辿った経路の詳細と同様、彼らのユーザＩＤに照らして保存される。

図２および３に関して、それぞれ、上記の機能性を具体化している３つの所有者サブシステム１１８、１２０および１２２の医療マップサーバ１２４および医療マップデータベース１２６をここでさらに詳細に説明する。

図２に図示された医療マップサーバ１２４は、１１のソフトウェア処理モジュールより構成され、それらのうちの９つは処理マネージャであり（ルーティングマネージャ２００、医療マップデータベースマネージャ２０２、配布マネージャ２０４、セキュリティマネージャ２０６、配信マネージャ２０８、外部通信マネージャ２１０、追跡マネージャ２１２、バージョン公開マネージャ２１４およびフィードバックマネージャ２１６）、それらは所有者サブシステム１１８、１２０、１２２内の内部データ処理および、NCM１２８を通じた通信ネットワーク１１２との接続を取り扱う。あとの２つはソフトウェアアプリケーション（編集ツールアプリケーション２１８および統轄アプリケーション２２０）であり、それらは医療マップデータベース１２６に保存された情報がアクセスされ得るためのソフトウェアインタフェースを提供する。

医療マップサーバ１２４との間の通信は、ネットワーク通信のインプリメンテーションによって構成された通り、NCM１２８によって適切なソフトウェア処理モジュールに振り向けられる。ルーティングマネージャ２００は、他の処理マネージャおよび２つのソフトウェアアプリケーションモジュールの全部が接続する中央ハブとして機能し、処理命令およびデータを関連するソフトウェア処理モジュールに転送する。医療マップデータベースマネージャ２０２は、医療マップサーバ１２４内の他のソフトウェア処理モジュールの命令の下で医療マップデータベース１２６と連絡し、データベース１２６に対する全部の照会および更新を取り扱う。他の処理マネージャの各々の一般的機能の簡単な説明は、以下の通りである。

医療マップサーバ１２４によって送受されるあらゆる通信の詳細は、配布マネージャ２０４に転送され、後者はその通信が許可されたものであるかどうかを確かめるために検査する。配布マネージャ２０４は、コンフィギュレーションモジュール２２２および事例間モジュール２２４より構成される。コンフィギュレーションモジュール２２２は、医療マップサーバ１２４が通信できる外部システムの詳細および、医療マップサーバ１２４のその事例内で使用可能にされている機能性を指定し（ソフトウェア処理モジュールの必ずしも全部がサーバ１２４のすべての事例に利用可能にされているわけではない）、それは前述のコンフィギュレーション機能性、すなわち、サーバ１２４がいずれの他の所有者サブシステムに更新を送りいずれから更新を受け入れなければならないか、それがいずれのEPRMSシステム１０６、１０８と通信できるか、それがいずれの第三者知識ベース１１０にアクセスできるか、そして、それがいずれの医療機関に医療マップを提供できるか、を取り扱う。例えば、ローカル医療マップサーバ１２４は一般に、中央所有者サブシステム１１８およびバックアップ所有者サブシステム１２０との間でデータを送受するだけであるように設定されるはずであり、また中央医療マップサーバ１２４は、全部の医療機関およびローカル所有者サブシステム１２２からデータを受け入れ、それをバックアップ所有者サブシステム１２０に転送するように設定されるであろう。接続の管理ならびにデータのスケジューリングおよび転送といった他の所有者サブシステムとの通信は、事例間モジュール２２４によって取り扱われる。

医療マップサーバ１２４が医療マップを見るために健康管理開業医のコンピュータ装置１０４から要求を受け取り、配布マネージャ２０４が関連する医療機関からの通信が取り扱われ得ることを確かめた後、健康管理開業医のユーザＩＤおよびパスワードの詳細がセキュリティマネージャ２０６によって要求されるであろう。健康管理開業医が医療マップに直接アクセスしている場合、セキュリティマネージャ２０６は関連する詳細を取得するためにログオンスクリーンを送出する。代替として、健康管理開業医がEPRMS１０６、１０８によって提供された電子患者記録内から医療マップにアクセスしている場合、セキュリティマネージャ２０６はEPRMS１０６、１０８から直接、健康管理開業医の詳細を取得することができる。セキュリティマネージャ２０６は、ユーザの詳細を医療マップデータベースマネージャ２０２に転送して、それらが医療マップデータベース１２６に保存されたものと照合され得るようにする。健康管理開業医に対する許可の集合は、セキュリティマネージャ２０６に返され、その健康管理開業医が医療マップに関して何ができ何ができないかを決定するためにユーザセッションの間ずっと参照される。典型的な許可の例は、医療マップを変更する権利および医療マップの更新を受け入れる権利を含む（これらについては、それぞれ、編集ツールアプリケーション２１８およびバージョン公開マネージャ２１４に関して以下でさらに詳細に検討する）。

いったん健康管理開業医が検証されると、要求に対応している医療マップの適切なページ（医療マップのホームページまたは、要求において受信された標準化臨床コードによって指定された特定の健康問題に関するページ）が、医療マップデータベースマネージャ２０２によって検索され、配信マネージャ２０８に転送される。前述の通り、医療マップデータベース１２６に保存された医療マップページは、XMLで書かれている。配信マネージャ２０８は、ページを装置のブラウザに送信する前に、当業で周知である標準技法を用いて、医療マップから検索されたページを要求側コンピュータ装置１０４によって指定されたあらゆるフォーマットに変換する。

外部アプリケーションマネージャ２１０は、医療マップサーバ１２４によって受け取られる２種類の要求を取り扱う。すなわち、（１）電子患者記録を通じて行われた医療マップからのページの要求（これはEPRMSモジュール２２６によって取り扱われる）、および（２）外部情報源に接続するために医療マップインタフェースを通じて行われた要求（これは第三者知識ベースモジュール２２８によって取り扱われる）。これらのモジュール２２６および２２８の両方とも、分散形所有者システム１０２の外部に保存されたデータとインタフェースを取るために標準化臨床コード（診断、徴候、行為、治療、手術手順等に対応する）を使用する。EPRMSモジュール２２６は、電子患者記録からのデータにアクセスし、それを使用してその患者の医療マップから要求されたページの対応するデータフィールドを事前格納する。それは医療マップページ内のデータフィールドに埋め込まれた臨床コードを使用して、同じ集合の標準化臨床コードを用いて索引づけられた電子患者記録の内部でデータを調べる。それ故、患者の電子患者記録からの情報は、医療マップ内でコンテキスト化され、それによって健康管理開業医を各自の患者の評価に際し援助する。同様に、臨床状態または徴候に関するさらなる情報を決定するために医療マップから要求がなされた場合、状態または徴候に関係する標準化臨床コードが第三者知識ベースモジュール２２８によって使用され、第三者知識ベース１１０内部の関連情報を識別し、健康管理開業医を直接その情報へ導く。このプロセスは、第三者知識ベース１１０によりいかなるサーチも行われることを要求せず、所要の情報へのより高速なアクセスをもたらす。これらの機能性の両方については、医療マップインタフェースから得られる例示的なスクリーンショットに関して、しかるべき時にさらに詳細に説明する。

医療マップインタフェースの記録機能は、追跡マネージャ２１２によって取り扱われる。健康管理開業医が医療マップを辿ったルートおよび取られた行為は、追跡マネージャ２１２によって記録され、その後、医療マップデータベースマネージャ２０２に転送されて開業医のユーザＩＤに照らして医療マップデータベース１２６に保存される。追跡マネージャ２１２は、医療マップを用いて記録されるあらゆる治療および行為の財政コストを決定するために使用される臨床監査モジュール２３０および、教育的および職業的開発目的に使用されるエデュ・マイルズモジュール２３２をさらに含む。臨床監査モジュール２３０は、マップ内に埋め込まれた標準化臨床コードを、行為、治療および手術手順に照らして使用して、それらの同じ行為、治療および手術手順に関係するコストを調べる。このようにして、医療マップは、マップを通る経路によって決定されるケアのコストを数量化することができる。この情報はその後、そのケアについての明細記入請求書が以後生成され得るように、EPRMS１０６、１０８に利用できるようにされ得る。エデュ・マイルズモジュール２３２は、医療マップを辿るルートおよび健康管理開業医が受け取る情報に、値つまり「マイル」を割り当て、健康管理開業医が受けてきた技量のレベルの指標を与える。

編集ツールアプリケーション２１８は、例えばノード／ページの編集または追加によって、医療マップの局所化バージョンを作成できるようにする。これらの編集ツール２１８の使用は許可によって制限されている。それは２つの異なるレベル、すなわち臨床レベルおよび管理レベルでの局所化を可能にし、これらはそれぞれ、臨床モジュール２３４および管理モジュール２３６によって取り扱われる。臨床モジュール２３４は、（特定の条件の定義、臨床コードの割り当て等といった）特定のノードとの臨床情報の関連付けを助成し、管理モジュール２３６は（地域の専門クリニックに関する連絡の詳細といった）管理データフィールドを指定できるようにする。

医療マップのあらゆる新バージョンの公開は、バージョン公開マネージャ２１４によって取り扱われる。バージョン公開マネージャ２１４は、医療マップデータベース１２６に保存された医療マップのいずれかの局所化バージョンを調査し、あらゆる領域の矛盾を識別し、その後、新しい公開および矛盾領域の詳細は、局所化マップが提供される医療機関の臨床編集者に転送される。臨床編集者はその後、新バージョンを受け入れるか、新バージョンを受け入れることを拒否するか、または新バージョンを部分的に受け入れるかのいずれかが可能であり、編集ツールアプリケーション２１８を用いて手動統合を実行する。

医療マップを通じて最善業務ガイドラインに基づくワークフローを健康管理開業医に提供することと同様に、現在の実施形態はまた、管理されたフィードバック配布ネットワークを提供することによってそれらのワークフローの内容に関する健康管理コミュニティ内での議論を助成する。医療マップインタフェースを通じてフィードバックとして提出される論評は、後にさらに詳細に述べる通り、適切なフィードバック査閲者にフィードバックマネージャ２１６によって配布される。

最後に、医療マップサーバ１２４内の統轄アプリケーション２２０は、医療マップデータベース１２６から得られた情報に基づき監査、管理および統轄報告を作成するために使用され得る。報告要素は、特定の医療機関において具体化された局所化臨床内容の量の評価、マップの新しい公開を考慮し具体化するために要する時間の評価および、特定の医療機関から生成されるフィードバックの量の評価を含む。報告要素の全部は、そのような報告機能を具体化している当業者には十分に理解されるはずである技法を用いて具体化され得る。

外部アプリケーションマネージャ２１０および追跡マネージャ２１２によって提供される機能性は、医療マップからの一連の例示的なスクリーンショットに関して、しかるべき時にさらに詳細に説明され、スクリーンショットはまた編集ツールアプリケーション２１８の機能性をさらに検討するためにも使用され、バージョン公開マネージャ２１４およびフィードバックマネージャ２１６の機能性は、健康管理システム内に一般に存在する異なる階層レベルを示す概略図に関して検討されるであろう。

しかしその前に、医療マップデータベース１２６に保存されるデータの形式の概略図を図３に関して説明する。上記の説明に関して、医療マップデータベース１２６が少なくとも以下のデータ要素を含むことは明白であろう。すなわち、医療マップXMLページ３００（これらは中央およびバックアップ医療マップデータベースによって保存される必要があるだけであろうが）、局所化医療マップXMLページ３０２、少なくとも配布マネージャ２０４によって参照される機関ＩＤ３０４、少なくともセキュリティマネージャ２０６によって参照されるユーザＩＤ３０６、ユーザパスワード３０８および許可３１０、健康管理開業医によってマップのノードに追加され後にマップのそれらのノードとともにその健康管理開業医に提供される個人化ノート３１２、永久データ源とインタフェースを取る際には少なくとも外部アプリケーションマネージャ２１０によって使用され、コストを監視する際には臨床監査モジュール２３０によって使用される、診断、徴候、行為、治療、手術手順等に対応する一組の標準化臨床コード３１４、追跡マネージャ２１２によって記録される健康管理開業医が医療マップ内を通ったルートを詳述している通過経路３１６、少なくとも臨床監査モジュール２３０によって参照される臨床コード３１４の少なくとも一部に対応する一組の臨床料金３１８、および、フィードバックマネージャ２１６によって管理されるフィードバックデータ３２０。データ要素は、当業者（例えばデータベース管理者）には十分に理解される通り、従来のデータ構造を用いて標準の様態で医療マップデータベース１２６内で編成されるであろう。

図４ａ〜４ｆに関して、EPRMS１０６、１０８と統合された時のインタフェース機能性を示す医療マップGUIの第１の実施形態をここで説明し、そして医療マップサーバ１２４の内部のEPRMSモジュール２２６の機能性に発展させる。健康管理開業医は、各自のコンピュータ装置１０４を用いてEPRMS１０６、１０８からの患者の電子患者記録にアクセスする。EPRMSによって提供されるGUIは、医療マップにアクセスするためのオプションを含む。このオプションを選択すると、EPRMS GUI４００は、図４ａに示す通り、EPRMS１０６、１０８の制御下で動作し続ける上部４０２および、医療マップGUI４０６が挿入される下部４０４に分割される。医療マップGUI４０６は、下部４０４によって提供される領域を完全に占有し、医療マップサーバ１２４内のEPRMSモジュール２２６の制御下で動作する。

EPRMSモジュール２２６によってコンピュータ装置１０４に提供される医療マップの最初のページは、健康管理開業医が健康管理問題（例えば、患者が呈している徴候または疑わしい診断）の詳細を入力することができる、問題ダイアログボックス４０８を含む。現在の例では、検討される健康管理問題は疑わしい結腸直腸癌である。EPRMSモジュール２２６は、GUI４０６からこのテキストを受け取ると、その健康管理問題についての対応する臨床コード３１４を決定するために医療マップデータベース１２６と連絡する。その後、決定された臨床コード３１４に基づき、その健康管理問題のための医療マップの推奨ページへのリンク４１０が、関連する健康管理問題に関するガイドラインのためのプロトコル（ワークフロー）への可能な代替リンク４１２（それらのうちの２つが図４ａに図示されている）とともに、GUI４０６上に示される。

リンクのうちの１つを選択すると、健康管理開業医は、医療マップから適切なページが提示される。図４ｂに図示された例では、推奨リンク４１０が選択された。GUI４０６は、医療マップからのページを表示する時、右側のマップナビゲーション部４１４および左側の経路記録部４１６より構成され、経路記録部４１６はマップナビゲーション部４１４の余白として機能する。経路記録部４１６は、医療マップ内を健康管理開業医が取れるルートの記録可能な詳細を表示する。各ノードが辿られた時の日付および時間を含むこの情報は、追跡マネージャ２１２に転送され、後者はそれを医療マップデータベース１２６にアップロードし、そこでそれは通過経路３１６として保存される。アップロード（実際の記録）は、各ノードが辿られた時点で自動的に行われ得るか、または他に、それらの行為は、ワークフローにおいて適切なポイントに到達した時に健康管理開業医によって検分され、記録の前にそれが望ましければ変更を行うことができる（図示せず）。図４ａから推奨リンク４１０を選定した健康管理開業医に関して、経路記録部４１６は、医療マップの対応するページの名称４１８を表示する。転じてマップナビゲーション部４１４は、医療マップ内の現在のページの相対位置を識別するヘッダ部４２０、および対話型マップ表示部４２２より構成される。

マップ表示部４２２は、階層ツリー構造において一体にリンクされている一連のノード４２６を含む医療マップからの経路または「ワークフロー」４２４の図形的表現を提示し、ノード４２６は、健康管理問題に関して行うべき決定または取るべき行為を詳述している。表示されたワークフロー表現４２４は、医療マップの単一のページに対応する。また、マップ表示部４２２には、キー４２８、クイック情報バー４３０およびスクロールバー４３２が含まれる。キー４２８は、ノード４２６に適用される色分け４３４（黒はマップの専門家ゾーンを示し、白は非専門家ゾーンを示す）および、ノード４２６に現れる一組の対話型アイコン４３６（すなわち「ｉ」４３８、「＞」４４０および「Ｒ」４４２）を定義し、これらの機能性についてはしかるべき時に説明する。クイック情報バー４３０は、クイック情報タブ４４４およびノートタブ４４６より構成され、情報が健康管理開業医によってマップに迅速に入力され得るようにするかまたは、しかるべき時に説明する通り、第三者知識ベース１１０から迅速に推定され得るようにする。スクロールバー４３２は、標準の様態で動作し、そのページの一部を形成するがマップ表示部４２２の範囲を越えて広がる、ワークフロー表現４２４から別のノード４２６を見えるようにする。

図４ｂはまた、健康管理開業医がノード４２６に現れる「ｉ」アイコン４３８上で各自のコンピュータ装置１０４のポインティングデバイスを動かした時に生じることも図示しており、すなわちこの行為は、ワークフロー表現４２４内でそのノード４２６と関係するさらなる情報を含む情報テキストボックス４４８を明示する。

情報テキストボックス４４８によって指示された通り、健康管理開業医が各自のポインティングデバイスで「ｉ」アイコン４３８をクリックした場合、図４ｃに示す通り、クイック情報バー４３０が起動する。クイック情報バー４３０は、画面全体に広がり、情報入力部４５０および、集合的に「全国健康ライブラリ(National Library for Health)」と称する第三者知識ベース１１０にリンクしているアイコン「NLH」４５２を明示する。

クイック情報タブ４４４を選択すると、情報入力部４５０は、ノード４２６が関係するワークフロー表現４２４のあらゆる段階に関する質問表が格納される。情報入力部４５０はさらに、ノード４２６に関するローカル管理情報を入力できるようにするテキストボックス（図示せず）が格納され得る。現在の例では、疑わしい結腸直腸癌に関して、クイック情報バー４３０は、健康管理開業医に患者における特定の想定可能な警戒徴候の発現を検討するように促すワークフロー表現４２４のルート「警戒」ノード４５４について起動された。従って、質問表は、健康管理開業医が患者を評価する際に検討するべき、直腸出血、排便習慣の変化等に関する一連の質問４５６を提起する。

健康管理開業医は、個々の質問４５６のすぐ下に現れる１つ以上のドロップダウンテキストボックス４５８からオプションを選択することによって、質問４５６に対応して自己の所見を記録し得る。質問表はまた、質問表の内部の適切な場所に予約を予定する機会も付与し、現在の例では、血液検査４６０を手配するためのオプションが鉄分不足に関する質問の下に示される。EPRMSモジュール２２６は、関連情報が患者のＥＰＲから入手可能であれば質問に自動的に回答できるが、これは図４ｃに図示された例には当てはまらない。クイック情報タブ４４４を通じて入力されたあらゆる情報は、電子患者記録への包含のためにEPRMS １０６、１０８へEPRMSモジュール２２６によって自動的に転送される。

対照的に、クイック情報バー４３０のノートタブ４４６を選択すると、現在選択されたノード４２６において検討中の問題に関する個人化ノート３１２を入力または編集するためのテキストボックス（図示せず）が情報入力部４５０に格納される。例えば、健康管理開業医は、現在の最善業務ガイドラインによって指示されたアプローチに疑いを狭む各自が知っている研究の詳細をノートし得る。いったん個人化ノート３１２がノード４２６に追加されると、そのノードはノートアイコン（図示せず）を伴いワークフロー表現４２４に示され、それにより健康管理開業医はいずれのノード４２６がそれらのわきに個人化ノート３１２を有するかがわかる。EPRMSモジュール２２６は、医療マップデータベースマネージャ２０２に、健康管理開業医のユーザＩＤ ３０６に照らして全部の個人化ノート３１２を保存するように指示し、それによりそれらが医療マップ内で同じワークフロー表現４２４を返した時は常に、それらの個人化ノート３１２がいつも現れる。また、情報入力部４５０には、個人化ノート３１２をフィードバックデータ３２０として提出するためのオプション（図示せず）も含まれる。

現在の例に戻って、図４ｄは、健康管理開業医によって完成された後の、情報入力部４５０の内部の「警戒」ノード４５４に関係する質問表を図示している。医療マップGUI ４０６の経路記録部４１６は、健康管理開業医が辿った「警戒」ノード４５４の名称４６２を付加的に含むように更新されている。質問表に応答して健康管理開業医によって付与された回答は、通過ノード４５４の隣のマップ上に警告メッセージ４６４が発せられるように作動させ、また警告の言及は、経路記録部４１６に現れた時点でノードの名称４６２にも含まれる。警告メッセージ４６４は、ワークフロー表現４２４内のいずれのノード４２６を次に移動すべきかを健康管理開業医に助言し、現在の例では「高危険度徴候」ノード４６６が示唆されたノード４６６であり、それは健康管理開業医の注意を引くために強調表示される。図４ｄは、健康管理開業医が警告メッセージ４６４に留意し、そのノード４６６内に現れた「ｉ」アイコン４３８上で自己のポインティングデバイスを動かした後に示唆されたノード４６６に関係するさらなる情報を検討していることを図示している。

図４ｅは、健康管理開業医が示唆されたノード４６６、すなわち「高危険度徴候」についてのクイック情報バー４３０を起動した時の医療マップGUI４０６を図示している。やはり健康管理開業医は質問表を提示されるが、今回、回答の一部は、ワークフロー表現４２４内で先行ノードに付与された情報に基づき事前格納されている。「高危険度徴候ノード」４６６に関してさらなる措置はいっさい取られず、従ってその名称は経路記録部４１６に付加されない。

「高危険度徴候ノード」４６６に関係する情報を検討した後、健康管理開業医は、ワークフロー表現４２４内の次の段階、すなわち、患者を手術に回すことを可能にするノード４６８に進む。これを誘起するために、健康管理開業医が紹介ノード４６８上で指示された「Ｒ」アイコン４４２をクリックすると、図４ｆに示す通り、適切な紹介書式４７０が医療マップGUI４０６のマップナビゲーション部４１４にポップアップする。紹介書式４７０はEPRMSモジュール２２６によって電子患者記録からの情報が事前格納されているが、健康管理開業医はさらに、書式４７０内のドロップダウンテキストボックス４７２から選択を行うことによって、紹介を行うべき相手を指定することができる。完成した情報に関して、医療マップGUI４０６の経路記録部４１６は、紹介ノード４６８の名称４７４を付加的に含むために更新される。

キー４２８にリスト化された残りのアイコン、すなわち「＞」アイコン４４０は、付加的なページ上のワークフロー４２４の関連する健康問題または継続に関して、医療マップ内の異なるページ（ワークフロー表現４２４）にリンクする。

ここで、医療マップ内で提供されるサーチ機能性を、EPRMS GUI４００を通じてではなく、直接アクセスされる医療マップGUIの第２の実施形態に従った図５ａ〜５ｄに関して説明する。また、医療マップサーバ内の第三者知識ベースモジュール２２８の機能性にも発展させる。

図５ａは、コンピュータ装置１０４に表示されるブラウザウインドウ５００を図示している。前述の通り、医療マップに直接アクセスするために、健康管理開業医は各自のブラウザウインドウ５００内のアドレスボックス５０２に適切なＵＲＬ（図示せず）を入力し得る。健康管理開業医が医療マップサーバ１２４内の配布マネージャおよびセキュリティマネージャ２０６および２０８によってそれぞれ検証されることに関して、医療マップGUI５０４の第２の実施形態がブラウザウインドウ５００の内部に提供されるであろう。最初のページは、医療マップのワークフロー表現４２４がアクセスされ得る３つの異なる手段を提供し、部門部５０６、索引部５０８および一般サーチ部５１０より構成される。部門部５０６は、異なる健康管理部門のワークフロー表現４２４への一組のリンク５１２を含む。索引部５０８は、医療マップワークフロー表現（経路）４２４へのリンク５１６のアルファベット順リストをサーチするために使用され得る索引ボックス５１４を含む。代替として、健康管理開業医は、サーチ部５１０に提示されるサーチボックス５１８を用いて、各自が必要とするワークフロー表現４２４を直接サーチすることができる。現在の例では、健康管理開業医は、索引部５０８を使用してジゴキシン毒性ワークフロー表現４２４のリンク５１６を選択し、図５ｂに図示されるページ５２０が提示される。

ページ５２０は、選択されたワークフロー表現４２４の名称を記述している標題部５２２、上述のサーチ部５１０およびマップナビゲーション部５２４から構成されている。第１の実施形態とは異なり、第２の実施形態の医療マップGUI５０４は、経路記録部４１６を特徴としていない。しかし、第２の実施形態のマップナビゲーション部５２４は、第１の実施形態のマップナビゲーション部４１４と極めて類似であり、以下を特徴としている。ヘッダ部４２０、ワークフロー表現４２４、キー４２８、クイック情報タブ４４４および、情報入力部４５０および第三者知識ベース１１０にリンクしているアイコン「ＮＬＨ」４５２を明示するために展開するノートタブ４４６を特徴とするクイック情報バー４３０。

図５ｂにおいて、臨床開業医は、「臨床評価」ノード５２６上の「ｉ」アイコン４３８を選択したので、以前の実施形態の場合のように質問表ではなく、そのノード５２６に関するさらなる情報、すなわち評価を実施する方法が提示されている。しかし、健康管理開業医は、「ＮＬＨ」アイコン４５２によって評価に関するより詳細な情報を検索することができる。

図５ｃは、健康管理開業医が「NLH」アイコン４５２をクリックした時に生じることを図示しており、すなわち彼らはノードサーチダイアログボックス５２８が提示される。第三者知識ベースモジュール２２８は、医療マップデータベース１２６から、現在のノード５２６と関係づけられている臨床コード３１４のテキスト等価物を検索し、それらはチェックボックスリスト５３０としてノードサーチダイアログボックス５２８において健康管理開業医に提示される。健康管理開業医が必要としないさらなる情報のあらゆる条件はチェックマークをはずすことができるが、健康管理開業医がサーチに含めたいあらゆる追加条件は追加条件テキストボックス５３２において指定され得る。健康管理開業医は、「サーチ」ボタン５３４をクリックすることによって指定された条件に関する情報のサーチを開始し得る。

サーチ要求の詳細は第三者知識ベースモジュール２２８に付与され、後者は（前述した通り）第三者知識ベース１１０とインタフェースを取るためにコード３１４を使用する前に、いずれかの付加的な指定条件の臨床コード３１４を取得する医療マップデータベース１２６と連絡する。

サーチ結果を提示する際に、医療マップGUI５０４は、情報入力部４５０と一緒にクイック情報バー４３０を画面を越えて移動させ、一時的にワークフロー表現４２４を見にくくするが、その後、図５ｄに図示の通り、サーチ結果部５３６を付加することによってそれを拡大する。相談した異なる第三者知識ベース１１０の全部からの要約結果５３８は、結果の類別ごとに集められてサーチ結果部５３６に一覧にされ、完全な結果は通常の方式でアクセスされ得る。

ここで、医療マップサーバ１２４内の追跡マネージャ２１２の機能性について、EPRMS GUI４００を通じてではなくやはり直接アクセスされる医療マップGUIの第３の実施形態に従って、図６ａおよび６ｂに関して簡単に説明する。

第３の実施形態に従った選択されたワークフロー表現４２４を表示している医療マップGUI６００が図６ａに図示されている。この実施形態において、ノード４２６に関係する情報は、通常の方式で、すなわち健康管理開業医が各自のポインティングデバイスをそのノード４２６の「ｉ」アイコン４３８上で動かすことによって、テキストボックス４４８に明示され得る。しかし、その同じ情報は、図６ｂに図示の通り、健康管理開業医によって行為リスト６０２に記録され得る。行為リスト６０２内のオプションは、健康管理開業医が情報を印刷、編集または保存できるようにし、最後のオプションは、追跡マネージャ２１２によって記録される通過経路データ３１６とともに情報を包含されるようにする。

図６ａおよび６ｂはまた、健康管理開業医のマップへの露出を計測する、追跡マネージャ２１２内のエデュ・マイルズモジュール２３２によって生成される出力６０４も図示している。

ここで、編集ツールアプリケーション２１８の機能性について、図７ａ〜７ｅ（これらはツールが既存のワークフロー表現４２４を拡張するためにどのように使用され得るかを図示する）および図８ａ〜８ｅ（これらは臨床および管理データがワークフロー表現４２４における特定のノード４２６とどのように関係づけられ得るかを図示する）に関して説明する。

編集ツールアプリケーション２１８がユーザによって開かれると、それはナビゲーションバー７０２より構成される図７ａに図示された編集GUI７００を提示する。ユーザは、医学分野を連続的に絞って行くナビゲーションバー７０２内の３つのドロップダウンボックスから選択を行うことによって医療マップから編集するために、ワークフロー表現４２４（経路）を選択することができる。第１のドロップダウンボックス７０４は部門を指定し、第２のもの７０６はその部門内の下位の専攻を指定し、そして第３のもの７０８は、その部門の下位の専攻に関係するワークフロー表現４２４をリスト化する。

行われた選択に関して、ワークフロー表現４２４は、図７ｂに図示の通り、ナビゲーションバー７０２の下にある編集領域７１０においてユーザに提示される。ワークフロー表現４２４の構造を編集するためのツールバー７１２が編集領域７１０の最上部に提示され、拡張可能バー７１３（これによって個々のノード４２６の外観が決定され得る）が編集領域７１０のいちばん右側に提示される。新しいノード４２６をワークフロー表現４２４に追加するための新規ノードアイコン７１４が、ツールバー７１２上に提示され、ノード４２６間の接続を行うための４つのコネクタアイコン７１６も同様である。２つのアイコンが編集領域７１０内に現れる各ノード４２６と関係づけられており、すなわち、編集領域７１０周辺でノード４２６を移動するために使用され得るローリーアイコン７１８および、ノード４２６を除去するために使用され得る「Ｘ」アイコン７２０である。

図７ｃは、ユーザが新規ノードアイコン７１４をクリックした後の編集GUI７００を図示している。新しいノード７２２が編集領域７１０に現れる。そのローリーアイコン７１８を使用することによって、新しいノード７２２は、編集領域７１０内の適切な位置にうまく移動させられ得て、その後、図７ｄに図示の通り、コネクタアイコン７１６によって付与される接続７２４を用いてワークフロー表現４２４内のノード４２６と接続され得る。図７ｄはまた、新しいノード７２２がクリックされた時に生じることも図示しており、すなわち、拡張可能バー７１４が起動され、画面にわたって拡張して、ユーザが新しいノード７２２の標題を指定できるノード標題テキストボックス７２６および、新しいノード７２２が色分けされる方法をユーザが指定できるケアゾーンドロップダウンボックス７２８を明示する。図７ｅは、ユーザが更新ボタン７３０を用いてそれらをコミットした後に新しいノード７２２で具体化される図７ｄの選択を図示している。

健康管理開業医が各自のポインティングデバイスを「ｉ」アイコン４３８上で動かした時に明示されるノード４２６の情報テキストボックス４４８に現れる情報は、コンテントエディタを使用することによってノード４２６と関係づけられ、その機能性をここで図８ａ〜８ｅに関して説明する。コンテントエディタは、メニューオプション（図示せず）によって編集GUI７００内で起動され、編集領域７１０を、ワークフロー表現リスト化部８００、ノードヘッダ部８０２、臨床情報編集領域８０４および管理情報編集領域８０６に分割させる。臨床情報編集領域８０４は、編集ツールアプリケーション２１８内の臨床モジュール２３４の制御下で動作し、管理情報編集領域８０６は管理モジュール２３６の制御下で動作する。

ワークフローリスト化部８００は、階層ワークフローツリー構造のリーフ端のそれらに始まり、ナビゲーションバー７０２を用いて選択されたワークフロー表現４２４内のノード４２６の全部の標題をリスト化する。図８ａに図示された現在の例では、図７ｂのワークフロー表現４２４において現れるノード４２６の標題がリスト化される（このリストは、図７ｂでは画面外にあるノード４２６の標題から始まる）。

ユーザがワークフローリスト化部８００からノードの標題のうちの１つを選択すると、その標題はノードのヘッダ部８０２に書き込まれる。図８ａに図示された例では、リスト化された最初のノードの標題が選択された。加えて、すでに選択されたノード４２６とすでに関係づけられていたあらゆる臨床情報または管理情報は、それぞれ、臨床情報編集領域および管理情報編集領域８０４および６０６において表示される。

情報は、そのグループ見出し８０８に関連する一連のポイント８１０としてグループ見出し８０８の下の臨床情報編集領域８０４に入力される。従って、臨床情報編集領域８０４は、新規グループ操作ボタン８１２、新規ポイント操作ボタン８１４、グループ標題テキストボックス８１６（その中にユーザは見出しテキストを指定できる）および、ポイントテキストボックス８１８（その中にユーザは作成されているポイントを指定できる）を備える。対照的に、ノード４２６と関係づけられるべきあらゆる管理情報には、より少ない構造が要求され、従って、管理情報編集領域８０６は単に管理テキストボックス８２０を備えているにすぎない。

ユーザがポイントテキストボックス８１８または管理テキストボックス８２０のどちらか一方でもクリックすると、彼らは図８ｂに図示された情報編集ツールバー８２２が提示される。このツールバー８２２上のアイコンの１つ（すなわち、コード関連付けアイコン８２４）は、臨床コード３１４が、テキストボックス８１８または８２０に入力された情報と関係づけられるのを可能にする。このアイコン８２４をクリックすると、図８ｃに図示の通り、コード関連付け入力ボックス８２６を編集GUI ７００に出現させる。

図８ｄは、最初のグループ見出し８０８の下に第１のポイント８１０の臨床コードボックス８２８に現れる一連の臨床コード３１４を図示しており、コード３１４は、そのポイント８１０のポイントテキストボックス８１８を通じて起動されたコード関連付け入力ボックス８２６によって入力されたものである。図８ｄはまた、ユーザによって管理テキストボックス８２０に入力されている管理情報も図示しており、テキストボックス８２０は、ユーザがそれをクリックした時に情報編集ツールバー８２２とともに付与されたものである。

臨床コード３１４はまた、「ページ編集」オプション８３０を選択することによって到達する画面を図示している図８ｅからわかるように、その個々のノード４２６と同様にその全体としてワークフロー表現４２４と関係づけられている。

上述の編集ツールアプリケーション２１８を用いて編集された例えば新規または更新されたワークフロー表現４２４を含む医療マップの新バージョンの公開について、ここで図９に関して説明する。一般に、健康管理システムは必然的に、それらの管理を援助するために異なる階層レベルに構成される。ある特定の局所地域内の個々の病院および一般開業医院は、強固に相互リンクされているはずであり、医院はそれぞれの患者を地域病院での治療に回す。一般開業医院レベルのプライマリーケアと病院によって提供されるセカンダリケアとの間の関係を管理するために、局所地域における健康管理供給を監督する機関が存在し得る。複数の局所地域を包括する地方内の健康管理は、その地方全体の統一方針を具体化するために単一の管理組織を有することにより利益を得るかもしれない。例えば英国におけるような国内の健康管理システムの場合、地方の健康管理運営組織の全部はさらに単一の政府部門に報告するであろう。

階層的健康管理構造９００内の異なるレベルが、図９において図式的に表現されている。国内の健康問題を監督する保健省９０２が階層構造９００の最上位で統括する。特定の地方全体の健康管理方針を監督する複数の戦略的保健局（Strategic Health Authority）９０４（それらのうちの２つだけが図示されている）は、保健省９０２に直接報告する。個々の戦略的保健局９０４は、複数のプライマリーケアトラスト(Primary Care Trust）９０６を管轄し、後者は地方の局所地域内の健康管理の関係を監督する。図９には、戦略的保健局９０４の１つについて３つのプライマリーケアトラスト９０６だけが図示されている。階層的健康管理構造９００の最下位レベルにおいて、図９は、プライマリーケアトラスト９０６のうちの１つの「傘下」に入っている単一の一般開業医院９０８および単一の病院９１０だけを図示している。

前述の通り、医療マップの更新バージョンが医療機関に公開される場合、医療機関によってアクセスされる医療マップサーバ１２４内のバージョン公開マネージャ２１４は、その機関の局所化バージョンとのあらゆる領域の矛盾を識別し、その機関の臨床編集者の注意をそれらの領域に向ける。図９において、臨床編集者９１２は、階層的健康管理構造９００のバーの内部のあらゆるレベルに配備されており、最下位のものは、現在の例において、各自自身の変更を医療マップに具体化するために必要な許可３１０を付与されていない一般開業医院９０８および病院９１０を含んでいる。

現在の例において、医療マップのマスターコピーの新バージョンが、分散処理システム１０２の所有者によって中央所有者サブシステム１１８に公開される。中央医療マップサーバ１２４内のバージョン公開マネージャ２１４は、マップの現在のマスターコピーと新バージョンとの間の変更を識別し、それを保健省９０２に配備された臨床編集者９１２に通知する。臨床編集者９１２はその後、新バージョンを受け入れるか、または新バージョンを受け入れることを拒否し得る。また、臨床編集者が編集ツールアプリケーション２１８を用いていずれかの部分の手動統合を実行することによって、新バージョンを部分的に受け入れることも可能である。現在の例の目的で、変更は完全に受け入れられ、それにより保健省９０２内の職員は以後、医療マップの更新されたマスターコピーからのページが提供されるはずであると仮定する。この行為は、バージョン公開マネージャ２１４に、階層構造９００内の次のレベル、すなわち戦略的保健局９０４への公開を処理させる。戦略的保健局９０４のうちの１つは、中央医療マップデータベース１２６に保存されている医療マップの自己自身の局所化バージョン３０２を有する。従って、バージョン公開マネージャ２１４は、（保健省９０２が受け入れた）マップの新しいマスターコピーと戦略的保健局９０４によって使用される局所化バージョン３０２との間の相違を識別し、それらが矛盾を提示しない場合ローカルの選好を自動的に取り入れるが、以前に具体化された局所変更とのあらゆる領域の矛盾を、フローステップ９１６を通じて、その戦略的保健局９０４に配備された臨床編集者９１２に通知する。臨床編集者９１２は、同僚と相談した後、編集ツールアプリケーション２１８を使用して局所化マップの新バージョンを許容可能な形式に手動で編集し、このバージョンが、戦略的保健局９０４内の職員によって以後アクセスされることになる。

階層的健康管理構造９００の次のレベルは、プライマリーケアトラスト９０６によって格納される。バージョン公開マネージャ２１４は、それらのうちの１つが自己自身のローカル所有者サブシステム１２２からその医療マップにアクセスすることを指摘する。従って、中央所有者サブシステム１１８内のバージョン公開マネージャ２１４は、図９でフローステップ９１８によって指示されている通り、戦略的保健局９０４が許容可能とみなした医療マップの新しいコピーをローカル所有者サブシステム１２２に転送する。

プライマリーケアトラスト９０６のローカル医療マップサーバ１２４内のバージョン公開マネージャ２１４は、いかなる矛盾も提示しないローカルマップからの変更を新しいマップに具体化してから、矛盾が存在する場合それらの領域をローカル臨床編集者９１２に知らせる。これらの領域はローカル臨床編集者によって解決され、局所化マップの新バージョンが具体化され、それにより階層９００における下位の次のレベルの病院９１０がマップからページを要求した時、それは、フローステップ９２０によって指示された通り、新しい局所化バージョンからページが提供される。

バージョン公開管理に関して上述した階層的健康管理構造９００はここでまた、医療マップサーバ１２４内のフィードバックマネージャ２１６の機能性を説明するために、図１０においても使用される。健康管理開業医は十分な研究および証拠を前にして最善業務ガイドラインについて容易に同意し得るが、医療の大部分は、コンセンサスおよび専門家の意見に基づいている。最善業務ガイドラインに一致するワークフロー表現４２４の図形的表現を健康管理開業医に提供することと同様に、現在の実施形態はまた、ワークフロー表現４２４の内容のフィードバックが配布され得るための管理されたネットワークも提供する。

既述の通り、ワークフロー４２４内の特定のノード４２６に関するフィードバックは、クイック情報バー４３０のノートタブ４４６を用いて健康管理開業医１０００によって医療マップGUI４０６から提出され得る。健康管理開業医１０００は、個人化ノート３１２を起草してから、ノートを医療マップサーバ１２４に提出するオプションを選択することができる。ノートはその後、フローステップ１００２において指示された通り、その健康管理開業医１０００にマップページを提供する医療マップサーバ１２４内のフィードバックマネージャ２１６に転送され、医療マップデータベース１２６においてフィードバックデータ３２０として保存される。

種々の医療部門およびそれらの部門内の専門家のためのフィードバック査閲者１００４が階層構造９００の各レベルにおいて割り当てられており、フィードバックマネージャ２１６は各査閲者１００４のユーザＩＤ３０６を備えている。従って、健康管理開業医１０００からフィードバックデータ３２０を受け取ると、フィードバックマネージャ２１６は、その情報がいずれのノード４２６から発信されたかを確認し、そのノード４２６の健康管理開業医１０００と同じ機関内のフィードバック査閲者１００４を調べ（現在の例では、健康管理開業医は病院９１０に存在する）、そのフィードバック査閲者３２０にフィードバックデータ３２０を転送し、その者は電子メールによって通知される。電子メールは、彼らがフィードバックにおいて取り上げられた問題を評価できる場合、フィードバック査閲者１００４を医療マップ内のフィードバック要約ページ（図示せず）に向かわせる。

フィードバック査閲者１００４が照会に回答できない場合、彼らはそれを、その医学的専攻について階層構造９００内で上位の次のレベルのフィードバック査閲者１００４に送る責任を有する。要約ページからのこのオプションが選択された後、フィードバックマネージャ２１６は、関連するフィードバック査閲者１００４を識別し、（フローステップ１００６によって指示された通り）電子メールによって彼らに通知する。また、問題が転送されたことをフィードバック連鎖内の他の人々にも通知し、その後この行為をフィードバック要約ページに記録する。特定の照会に関するフィードバック連鎖のいずれの者も、いつでも、フィードバック要約ページにアクセスすることができ、行われている進捗の詳細を見ることができる。それ故、現在の例では、照会に回答する責任はこの時、プライマリーケアトラスト９０６におけるフィードバック査閲者１００４にある。

同様に、フィードバック査閲者１００４がフィードバック要約ページを通じてフィードバックに回答した場合、フィードバックマネージャ２１６はフィードバック連鎖のすべての者に通知し、彼らはフィードバック要約ページ上でその回答を見ることができる。図１０において、回答はフローステップ１００８によって指示されている。

本発明の特定の好ましい実施形態を説明したが、当該の実施形態は例示的であるにすぎず、適切な知識および技術を備える人々に想起されるはずであるような変更および修正が、添付クレームにおいて記載された本発明の精神および範囲から逸脱することなく行い得ることは理解されるはずである。

図１に図示された通信システム１００は、多様な方式で構成できるであろう。例えば、第２のコンピュータ端末１１６は、通信ネットワーク１１２によってではなく、ローカルネットワークを通じてローカルEPRMS１０８と直接に接続され得るであろう。ローカル医療マップサーバ１２４は、ローカルEPRMS１０８と同様に中央EPRMS１０６からのデータにアクセスするように構成され得る。また、いわゆる「グリッド」方法論を用いて、ローカル所有者サブシステム１２２の種々の事例が他の局所事例によって保存された医療マップにアクセスすることも可能であろう。従って例えば、異なる地方の病院に一時的に転属された健康管理開業医が、依然として医療マップの各自の「家庭用」バージョンにアクセスできるであろう。さらに、ローカルEPRMS１０８からのデータが「グリッド」方法論によって他の全部のローカル所有者サブシステム１２２にもアクセス可能であるならば、中央EPRMS １０６は冗長にされ得るであろう。加えて、ある地方のローカル医療マップデータベース１２６は、その地方の複数の病院のローカル医療マップを保存することができるであろう。実際に、医療マップの局所化バージョンが「個々の」健康管理開業医のために保存されることは可能であるが、これは、調和した患者のケアを促進しないはずであるので、現在好ましい実施形態によっては支援されない。当然ながら、通信システム１００は、「いかなる」ローカル所有者サブシステム１２２も持たないことによって単純化され得るであろう。さらに、医療マップページが、パーソナルディジタルアシスタントといった移動電気通信プロトコルによって動作するものを含む、ある範囲のコンピュータ装置１０４に配信マネージャ２０８によって提供され得ることは明白である。

また、医療マップが多くの異なる方式で健康管理開業医にアクセス可能にされ得ることも実現可能である。例えば、健康管理開業医が徴候／診断の臨床コード３１４に精通している場合、彼らはそれを図４ａに図示された問題ダイアログボックス４０８に直接入力し、マップから関連するワークフロー４２４を提供され得るであろう。代替として、健康管理開業医は、特定の健康管理問題を指定しなければならないのではなく、患者の電子患者記録内で直近に指定された臨床コード３１４に基づき、患者の医療マップ内のページに導かれ得る。別の可能性は、健康管理開業医が患者について以前に辿ったワークフロー４２４をリスト化している要約ページを提示されるというものであり、健康管理開業医は、関連するワークフロー４２４を選択し、現在までその中で辿ったノードを知らされ、そして患者の行程を継続することができよう。また、EPRMS１０６、１０８が医療マップを通じてアクセスされ得ること、さらにその逆も同様であることも考えられる。

マップ内で取られるルートは、ノード４２６が選択された時点で、何らかの形で識別され得るであろう。例えば、ノード４２６自体が何らかの形で強調表示され得るかまたは、それらの間の接続がそのようにされ得る。取った経路を指示するために付加的手段もまた使用され得るし、例えば一連の矢印が選択されたノード４２６の上部に重ねられ得るであろう。場合によっては、臨床開業医がワークフロー４２４における特定のノード４２６をスキップすることも可能かもしれず、この機能性はノードの定義に統合される。

また、患者の電子患者記録から医療マップに取り込まれる情報が、EPRMSモジュール２２６によってある種の制限時間処理を適用されることも想定される。例えば、５年前に記録された直腸出血の詳細は、現在の結腸直腸癌の評価には関連しないかもしれない。

研修の目的で、医療マップは、シミュレートされたEPRMS環境を創成するために偽の患者データのデータベースに照らして具体化され得るであろう。健康管理開業医の研修および職業的成長の監視の両方に関して、エデュ・マイルズモジュール２３２は、辿ったマップのいずれかの新しい領域に関して「マイル」を与えるだけにするように構成され得るであろう。

特に、医療マップGUIの特定の実施形態を以上に説明したが、異なる実施形態からの特徴が、やはり本発明の範囲内にある新規なインタフェースを創成するために多様な形で結合され得ることは理解されるはずである。

編集ツールアプリケーション２１８内での変更もまた可能である。例えば、臨床コード３１４がノード４２６に自動的に割り当てられ、それによって図８ｃに図示されたコード関連付けプロセスの必要性を除くことが可能であると想定される。例えば説明において概説した手動併合プロセスといったバージョン公開管理プロセスの態様もまた、しかるべき時に自動化の対象となり得るであろう。

最後に、本発明は健康管理環境における実現に制限されるものではなく、むしろそれは、相互リンクされた一連のワークフローからのデータ入力が要求されるあらゆる環境に適用され得ることが理解されるはずである。

図１は、本発明の典型的な実施形態に従った、サーバおよびデータベースを含む所有者システムから健康管理システム内部の種々の機関にグラフィカルユーザインタフェースを提供するための通信システムを図示している概略図である。 図２は、グラフィカルユーザインタフェースによって表示される患者のケア経路を作成および編集する際に使用するための、臨床モジュールおよび管理モジュールを含む、編集ツールアプリケーションを備える図１の所有者サーバに組み込まれたソフトウェアモジュールを図示している略ブロック図である。 図３は、図１の所有者データベースの内容を図示している概略図である。 図４ａは、EPRMSと統合された場合のインタフェース機能性を示す、グラフィカルユーザインタフェースの第１の実施形態に従った一連のスクリーンショットである。 図４ｂは、EPRMSと統合された場合のインタフェース機能性を示す、グラフィカルユーザインタフェースの第１の実施形態に従った一連のスクリーンショットである。 図４ｃは、EPRMSと統合された場合のインタフェース機能性を示す、グラフィカルユーザインタフェースの第１の実施形態に従った一連のスクリーンショットである。 図４ｄは、EPRMSと統合された場合のインタフェース機能性を示す、グラフィカルユーザインタフェースの第１の実施形態に従った一連のスクリーンショットである。 図４ｅは、EPRMSと統合された場合のインタフェース機能性を示す、グラフィカルユーザインタフェースの第１の実施形態に従った一連のスクリーンショットである。 図４ｆは、EPRMSと統合された場合のインタフェース機能性を示す、グラフィカルユーザインタフェースの第１の実施形態に従った一連のスクリーンショットである。 図５ａは、サーチ機能性を示す、インタフェースがEPRMSと統合されていない場合のグラフィカルユーザインタフェースの第２の実施形態に従った一連のスクリーンショットである。 図５ｂは、サーチ機能性を示す、インタフェースがEPRMSと統合されていない場合のグラフィカルユーザインタフェースの第２の実施形態に従った一連のスクリーンショットである。 図５ｃは、サーチ機能性を示す、インタフェースがEPRMSと統合されていない場合のグラフィカルユーザインタフェースの第２の実施形態に従った一連のスクリーンショットである。 図５ｄは、サーチ機能性を示す、インタフェースがEPRMSと統合されていない場合のグラフィカルユーザインタフェースの第２の実施形態に従った一連のスクリーンショットである。 図６ａは、監査機能性を示す、やはりインタフェースがEPRMSと統合されていない場合のグラフィカルユーザインタフェースの第３の実施形態に従った一連のスクリーンショットである。 図６ｂは、監査機能性を示す、やはりインタフェースがEPRMSと統合されていない場合のグラフィカルユーザインタフェースの第３の実施形態に従った一連のスクリーンショットである。 図７ａは、図２の編集ツールアプリケーションを用いて拡張されている、グラフィカルユーザインタフェースによる表示のための患者のケア経路を図示している一連のスクリーンショットである。 図７ｂは、図２の編集ツールアプリケーションを用いて拡張されている、グラフィカルユーザインタフェースによる表示のための患者のケア経路を図示している一連のスクリーンショットである。 図７ｃは、図２の編集ツールアプリケーションを用いて拡張されている、グラフィカルユーザインタフェースによる表示のための患者のケア経路を図示している一連のスクリーンショットである。 図７ｄは、図２の編集ツールアプリケーションを用いて拡張されている、グラフィカルユーザインタフェースによる表示のための患者のケア経路を図示している一連のスクリーンショットである。 図７ｅは、図２の編集ツールアプリケーションを用いて拡張されている、グラフィカルユーザインタフェースによる表示のための患者のケア経路を図示している一連のスクリーンショットである。 図８ａは、図２の臨床モジュールおよび管理モジュールを用いて図７ａ〜７ｅの患者のケア経路内の臨床および管理データの統合を図示している一連のスクリーンショットである。 図８ｂは、図２の臨床モジュールおよび管理モジュールを用いて図７ａ〜７ｅの患者のケア経路内の臨床および管理データの統合を図示している一連のスクリーンショットである。 図８ｃは、図２の臨床モジュールおよび管理モジュールを用いて図７ａ〜７ｅの患者のケア経路内の臨床および管理データの統合を図示している一連のスクリーンショットである。 図８ｄは、図２の臨床モジュールおよび管理モジュールを用いて図７ａ〜７ｅの患者のケア経路内の臨床および管理データの統合を図示している一連のスクリーンショットである。 図８ｅは、図２の臨床モジュールおよび管理モジュールを用いて図７ａ〜７ｅの患者のケア経路内の臨床および管理データの統合を図示している一連のスクリーンショットである。 図９は、健康管理システム内の階層レベルの下位へのグラフィカルユーザインタフェースの新バージョンの配布を図示している概略図である。 図１０は、患者のケア経路に関連しグラフィカルユーザインタフェースによって開始された、健康管理システム内の階層レベルの上位へのフィードバックの配布を図示している概略図である。

Claims (36)

1. 複雑なワークフロープロセスを案内するために用いるデータ記録システムであって、
   プログラムされたコンピュータと、
   表示画面と、
   ユーザ入力部と、
   ワークフロープロセスに関連する複数のデータ記録を含むコンテンツを格納し、前記コンピュータによりアクセス可能なデータベースと、を備え、
   前記コンピュータは、データベースに格納されたコンテンツからワークフロー表現を生成するようにプログラムされ、このワークフロー表現は表示画面上に、相互にリンクされた複数のノードを含むマップの形で表示され、各ノードは格納されたワークフロープロセス内のステップと一意の関係を持ち、前記相互にリンクされた複数のノードはマップ上で複数の経路を表示し、各経路は２以上の相互にリンクされた複数のノードを含み、また、
   前記コンピュータは、
   ユーザがノードを選択し、このノードに関連するデータを前記ユーザ入力部を経由して入力させるデータ入力モジュールであって、予め決められたデータ入力要求並びにユーザ入力部を用いてユーザにより行われた前記要求に対する応答を生成し、表示画面に表示するように構成されたデータ入力モジュールと、
   データベースの複数のデータ記録部の１つに、ユーザ入力部を経由して入力された前記データ入力要求に対するユーザの応答を格納するデータ記録モジュールと、
   経路モジュールであって、
   (i)格納されたワークフロープロセスにおいて、現在のユーザの位置を表示するマップ上における現在のノードから次に辿るようにユーザに示唆されている次のノードを決定し、この示唆された次ノードは、データ記録モジュールにより得られ且つデータ記録部に格納されたユーザの応答に基づいて決定され、また、
   (ii)前記示唆された次ノードを表示画面に表示するように図形的表現を生成する、ように構成された経路モジュールと、
   ユーザ入力部に作動接続されたナビゲーションモジュールであって、
   （ａ）前記経路モジュールにおいて決定され且つ表示画面に表示された示唆された次ノードからは独立して、次に辿るべきノードをユーザ入力部を介してユーザが選択し得るようにし、
   （ｂ）ユーザが実際に辿った一連のノードからなる、マップ上でユーザが取ったルートを記録し、
   （ｃ）前記ルートの図形的表現を表示画面上に生成する
   ように構成されたナビゲーションモジュールと、
   から成る機能増強型データ記録システム。
2. ワークフロープロセスの全体が表示画面上に表示されることを特徴とする請求項１記載のデータ記録システム。
3. 各ノードはワークフロープロセスにおける行為、決定又は結果を表すことを特徴とする請求項１又は２に記載のデータ記録システム。
4. データ入力モジュールは、さらに、選択されたノードのマップ上での位置に関するデータを提示するための提示手段と、ユーザがそのデータの少なくとも一部を選択できるようにするための選択手段とをさらに含むことを特徴とする請求項１乃至３のいずれかに記載のデータ記録システム。
5. 前記提示手段が、位置特定的情報の複数のドロップダウンリストを含むことを特徴とする請求項４記載のデータ記録システム。
6. 前記データ入力モジュールが、第１のノードにリンクされる第２のノードにおいて必要なさらなる情報を、第１のノードで入力されたデータをベースとして決定するように構成されていることを特徴とする請求項１乃至５のいずれかに記載のデータ記録システム。
7. 前記コンピュータは、ワークフロープロセスのステップに関するあらゆる情報を、入力されたデータで更新するための更新手段をさらに有することを特徴とする請求項１乃至６のいずれかに記載のデータ記録システム。
8. 前記コンピュータは、入力されたデータを、そのデータを表わす分類コードに変換するための手段をさらに含むことを特徴とする請求項１乃至７のいずれかに記載のデータ記録システム。
9. 前記分類コードが、ワークフロープロセスの対象に関して入力され得る全範囲のデータを記述している標準的分類コードを含むことを特徴とする請求項８記載のデータ記録システム。
10. 前記コンピュータは、(i)ユーザによりユーザ入力装置を経由して入力されたデータを使用して、予め明示された規則に基づいてユーザが実行できるように行為のリストを生成し、また (ii)この行為のリストをマップ近傍の表示画面上に表示する、ように構成された行為モジュールをさらに含むことを特徴とする請求項１乃至９のいずれかに記載のデータ記録システム。
11. 前記コンピュータは、ユーザによりユーザ入力部を経由して入力されたユーザの選択を受けてデータベースにノードと関連させて格納された前記ノード関連せしめられたアイコンの情報を取得し、表示画面上に表示するように構成されていることを特徴とする請求項１乃至１０のいずれかに記載のデータ記録システム。
12. 前記コンピュータは、
    ユーザが複数のノードを辿った後で、ユーザが完遂することができる行為のリストであって、予め明示された規則及びマップ上でユーザが取ったルートに基づいて決定される行為のリストを生成し、また、
    前記行為のリストをマップ近傍の表示画面上に表示することを特徴とする請求項１乃至１１のいずれかに記載のデータ記録システム。
13. 前記コンピュータは、
    (i)ユーザが、ユーザ入力部を経由して行為のリスト内のどの行為が必要であるかを確認できるようにし、
    (ii) 実行されるべき行為のリストを、ユーザ入力部を経由してユーザが行ったユーザ確認と予め明示された規則に基づいて決定し、
    (iii)前記実行されるべき行為のリストを表示画面上に表示する、
    ように構成された確認モジュールをさらに備えていることを特徴とする請求項１２記載のデータ記録システム。
14. 前記コンピュータは、
    特定のノードに関するユーザ生成テキストノートを記録するためのノート記録手段をさらに含み、該ノート記録手段はノートを特定のノードにリンクして、ユーザがその特定のノードに案内された時に、保存されているノートを検索することができるように構成されていることを特徴とする請求項１乃至１３のいずれかに記載のデータ記録システム。
15. 前記コンピュータは、
    ユーザ決定ノートを送信可能メッセージに変換し、該メッセージをコンピュータにアクセスできる別のユーザに送信するためのフィードバック生成モジュールをさらに含むことを特徴とする請求項１４記載のデータ記録システム。
16. 前記コンピュータは、
    マップの第１のセクションにあるノードを、マップの第２のセクションにあるノードにリンクするためのリンク手段をさらに含むことを特徴とする請求項１乃至１５のいずれかに記載のデータ記録システム。
17. 前記リンク手段はグラフィックアイコンを含み、
    前記コンピュータは、
    (i)ユーザ入力部を経由してユーザがマップの第１セクションのグラフィックアイコンを選択したことを受けてマップの第２セクションを表示画面上に表示し、また、
    (ii)ユーザ入力部を経由してユーザがマップの第２セクションのグラフィックアイコンを選択したことを受けてマップの第１セクションを表示画面上に表示する、
    ことを特徴とする請求項１６記載のデータ記録システム。
18. 前記コンピュータは、電子患者記録管理システム（ＥＰＲＭＳ）にアクセスできるように構成され、コンピュータはさらに、選択された電子患者記録の詳細をＥＰＲＭＳから取得し、この電子患者記録の詳細を表示画面上に表示するＥＰＲＭＳ管理手段を含む、ことを特徴とする請求項１乃至１７のいずれかに記載のデータ記録システム。
19. 前記ＥＰＲＭＳ管理手段が、選択された電子患者記録の詳細の少なくとも一部を１つ以上のノードに付加することにより、そのノードにおけるデータ入力の必要性を低減するための付加手段をさらに含む、請求項１８に記載のデータ記録システム。
20. 前記ＥＰＲＭＳ管理手段が、電子患者記録から取得不可能な詳細を１つ以上のノードに付加するためのデータをユーザに入力させる要求を生成し表示画面上に表示するように構成されていることを特徴とする請求項１８または１９に記載のデータ記録システム。
21. 前記コンピュータは紹介メッセージを生成するための紹介手段をさらに含み、該紹介手段は、ノードに表示され、また、ユーザがユーザ入力部を経由して選択した場合に、紹介メッセージの少なくとも一部にノードに関連付けられた情報を付加するように構成されていることを特徴とする請求項１乃至２０のいずれかに記載のデータ記録システム。
22. 前記紹介手段はグラフィックアイコンを含むことを特徴とする請求項２１記載のデータ記録システム。
23. 前記紹介手段は紹介メッセージの少なくとも一部に電子患者記録から得られる情報を付加するように構成されていることを特徴とする請求項２１又は２２に記載のデータ記録システム。
24. 前記コンピュータは、外部アクセス可能な知識ベースをサーチするためのサーチモジュールをさらに含み、該サーチモジュールは、ユーザ入力部を経由して選択された情報トピックをそのトピックを表す予め決められた分類コードに変換し、その分類コードを情報要求に含めて前記知識ベースに送信し、該知識ベースに含まれている関連情報を得ることを特徴とする請求項１乃至２３のいずれかに記載のデータ記録システム。
25. 前記分類コードが、ワークフロープロセスの対象に関して入力され得る全範囲のデータを記述している標準的分類コードを含む、請求項２４に記載のデータ記録システム。
26. 前記サーチモジュールが、情報要求に対する応答を受け取り、サーチの結果をユーザに表示画面上に表示するように構成されている、請求項２４又は２５に記載のデータ記録システム。
27. 前記サーチモジュールが、情報要求に対する応答を受け取り、この応答を使用して、マップの関連する部分を予め明示された規則に基づいて決定し表示画面上に表示するように構成されている、請求項２４乃至２６のいずれかに記載のデータ記録システム。
28. 前記サーチモジュールが、表示画面上で複数の情報トピックをユーザに表示し、これらの情報トピックの少なくとも一部の選択を可能にするように構成されており、個々の情報トピックは、現在のワークフロー内におけるユーザの現在位置を表示する選択されたノードに関連している、請求項２４乃至２７のいずれかに記載のデータ記録システム。
29. 前記サーチモジュールが、サーチモジュールによって表示されていない付加的な情報トピックをユーザが入力することができるように構成されている、請求項２８に記載のデータ記録システム。
30. 前記コンピュータが、相互接続されている複数のノードをユーザがユーザ入力部を用いて編集できるようにするための編集モジュールをさらに含み、該編集モジュールは、ワークフロー表現になされた変更を反映して、保存されているワークフローを更新するように構成されている、請求項１乃至２９のいずれかに記載のデータ記録システム。
31. 前記編集モジュールが、ユーザが新しいノードを追加し、その新しいノードの内容を指定することができるように構成されている、請求項３０に記載のデータ記録システム。
32. 前記編集モジュールが、ノードに関する機能性をユーザが指定することができるように構成されている、請求項３０又は３１に記載のデータ記録システム。
33. 前記編集モジュールが、ユーザがノードの内容に関する分類コードを追加または編集することができるように構成されている、請求項３０乃至３２のいずれかに記載のデータ記録システム。
34. 前記編集モジュールが、ユーザが、ユーザ入力部を用いて、(i)ワークフロー表現内に新しいノードの位置を決定し、(ii)この新しいノードを既存のマップに相互接続する、ことができるように構成されている、請求項３０乃至３３のいずれかに記載のデータ記録システム。
35. (i)データベースが相互に関連する複数のワークフローに関連するコンテンツを格納し、
    (ii)マップの各ノードが相互に関連付けられた複数のワークフローの１つのステップと一意の関係を有し、
    (iii)コンピュータが前記相互に関連付けられたワークフローの少なくとも一部を表すマップの部分を表示し、ユーザがユーザ入力部を用いてマップのほかの部分を案内し得るようにする
    ことを特徴とする請求項１乃至３４のいずれかに記載のデータ記録システム。
36. 複雑なワークフロープロセスを案内する一方でデータを記録する方法であって、該方法は、
    プログラムされたコンピュータを用いて、データベースに格納されたワークフロープロセスに関連するコンテンツからワークフロー表現を生成する工程であって、前記ワークフロー表現は、相互にリンクされた複数のノードを含むマップを備え、各ノードは前記格納されたワークフロープロセス内のステップと一意の関係を持ち、前記相互にリンクされた複数のノードはマップ上で複数の経路を図形的に表し、各経路は前記相互にリンクされた複数のノードのうち２つ以上を含む、ワークフロー表現を生成する工程と、
    プログラムされたコンピュータを用いて、少なくともマップの一部を表示画面上に表示する工程と、
    ユーザがユーザ入力装置を介してノードを選択する工程と、
    プログラムされたコンピュータのデータ入力モジュールを用いて：
    (a)選択されたノードに関する予め決められたデータ入力要求を生成し、
    (b)前記データ入力要求をユーザの表示画面上に表示し、
    (c)前記要求に対するユーザによる応答を表示画面上に表示する工程と、
    前記要求に対する応答を、プログラムされたコンピュータのデータ記録モジュールを用いて、データ記録部に格納する工程と、
    プログラムされたコンピュータの経路モジュールを用いて：
    (d)格納されたワークフロープロセスにおいて、現在のユーザの位置を表示するマップ上における現在のノードから次に辿るようにユーザに示唆された次のノードを決定する工程であって、前記示唆された次ノードはデータ記録部により得られ且つデータ記録部に格納されたユーザの応答に基づいて決定される、示唆された次ノードを決定し、
    (e)前記示唆された次ノードを表示画面でユーザに表示するように図形的表現を生成する工程と、
    ユーザがユーザ入力装置を介して、示唆された次ノードからは独立して次に辿るべきノードを選択する工程と、
    プログラムされたコンピュータのナビゲーションモジュールを用いて、
    (f)ユーザが実際に辿った一連のノードからなる、マップ上でユーザが取ったルートを記録し、
    (g)前記ルートの図形表現を表示画面上に生成する工程と、
    から成るデータ記録方法。

Images