JP5336380B2 - 個人の健康記録システムおよび装置 - Google Patents

Description

発明の分野

本願はラルフ・Ａ．コープマンほかによる２００６年９月２６日付米国仮出願第６０/８２６、９６７号に基づく優先権を主張する。上記出願の明細書、添付書類および図面は引用により本願の一部を形成する。

本発明は、多様な情報システムおよび情報ソースから個人のヘルスケア情報を収集し、処理し、評価し、変換し、報告するためのシステム、装置および関連の方法に係わる。

発明の背景

多くの情報技術（ＩＴ）アプリケーションは、ＩＴサービスまたはアプリケーションによって受信され、送信され、処理され、蓄積される情報のタイプおよび構成を高い特異度で事前に定義して作成される。多くの産業において、このモデルはかなり有効に作用する。ヘルスケアの分野でも、関連情報がかなり制限され、具体的に定義され、収集され、管理される場合、特定の施設または事業を運営するのにこのモデルを使用してまずまずの成果をあげることができる。しかし、このように限られた状況においても、生物学的機能にはランダム性がつきものであるから、このようなアプリケーションには問題がある。生物学的機能に固有の予測不可能性は個人の健康が事前に定義された過程を辿るとは限らないことを意味し、従って、自動化を試みるのは特に困難である。

このモデルはヘルスケアに関する個人中心のアプローチには充分対応できない。ヘルスケアは従来のプロバイダー中心の、組織によって推進されるアプローチから個人中心のシステムへ変容しつつある。この個人中心のアプローチはすべてのプロバイダーおよび患者にまたがっており、情報ソースの相互関係を事前に想定することはできない。しかも情報間および情報ソース間の関係は個々のエンティティ、場所、時間に応じて大きく異なる。さらにまた、広範囲に亘る患者、医師、および介護士が多様な目的で且つ多様な目的でアクセスし、使用しているから、情報ソースを事前定義できないだけでなく、情報の使用も予定できない。現在のモデルを使用して個人のヘルスケア記録を取扱うための包括的な有効なシステムを作成しようとすると、コストばかりが大きく、運営、保守に時間がかかる、手に負えないほどの厖大なデータベースとアプリケーションとなり、このようなシステムが所期の機能を満たすことを不可能にする。

従って、必要なのは堅牢であって、しかも広範囲で予測不可能な情報ソースからの健康情報に対応できる充分なフレキシビリティを有し、広範囲の患者、医師、およびその他のユーザーが健康情報を事前に想定されていない態様で操作し、利用できる個人健康記録を作成し、これを保守するための新しいモデルおよびアプローチである。

本発明は、種々の情報システムおよび情報ソースからの個人ヘルスケア情報を収集、処理、評価、変換および報告するためのシステム、装置、および方法に係わる。ヘルスケアは従来のプロバイダー中心、組織主導型のアプローチから個人中心のシステムに変わりつつある。本発明の個人健康記録（ＩＨＲ）はヘルスケア組織および管理組織側のニーズを満たしながら、個人が自らのヘルスケアおよびメディカルケアに参加し、且つその運営にも参加できるようにする構造を提供することによって、新しい態様の協調的なケアを支援する。

ＩＨＲは、種々のヘルスケア情報システムおよび情報ソース、例えば、従業員健康記録、薬局、研究所、医療費請求情報の流れのような既存のシステムおよび情報の流れから情
報を得ることによって形成される。これらのソースからの情報は個人の綜合的な健康およびケアの整然とした記録に変換され、新しい使用目的を与えられる。ＩＨＲは個人に関する単なるヘルスケア情報収集コレクションではなく、この情報は包括的なヘルスケア・オントロジーに立脚する個人健康情報モデルによって処理される。

１つの実施例では、情報がソースから受信され、認証され、構文解析され、変換され、既存の個人と一致照合され、オントロジー・コンセプト・コードが割当てられる。次いで、メッセージ・オブジェクトが作成され、データが使用目的変換され、ルールに照らして評価され、ＩＨＲデータベースにファイルされる。種々のソースからの情報が更新または追加されると、その都度、ＩＨＲは連続的または定期的に更新される。情報のシングル・ベスト・レコード（ＳＢＲ）を作成することができる。

他の実施例として、本発明は例えばヘルス・ポータル、ヘルス・ポートレットおよびウェブ・サービスを介して種々の態様でＩＨＲ中の情報と相互作用する方法および手段を提供する。これによって個人はそれぞれのヘルスケアを理解し且つヘルスケアに参加することができ、他方、管理者および消費者は同じ記録を異なる方法で利用することによって協力し、相互作用することができる。ＩＨＲシステムは管理者とヘルスケア助言者の新しい役割を含み、ヘルスケア・システムが将来に向かって発展するのに必要な条件を満たすため、ヘルスケアに関与する、例えば、ヘルス・システム、ヘルス・プラン、ＩＰＡ、ＲＨＩＯ、雇用者、プロバイダー、個人などを支援する。１つの実施例として、本発明は既存の情報システムおよびインフラストラクチャーを取り替えるのではなく、迅速且つ容易に健康関連情報を提供する規格に準拠し、サービスに寄与するインフラストラクチャーおよび既存のシステムと協働するコンポーネントを提供する。

他の実施例では、ＩＨＲシステムが内蔵型パッケージまたは器具に内蔵される。ＩＨＲ器具は既存のヘルスケアＩＴシステムおよびネットワークに「プラグ接続して利用」できるように設計されており、しかもユーザーの介入は最小限に抑えられている。情報は利用可能なあらゆるソースシステムから得られ、動的にＩＨＲに組み込まれる。

図１は本発明の１つの実施例としてのＩＨＲシステムの説明図である。 図２は本発明の１つの実施例としてのカスタマー・ポータルにおけるカスタマー・ポートレットの説明図である。 図３は本発明の１つの実施例としてのＩＨＲシステムの他の説明図である。 図４は本発明の１つの実施例としてのＩＨＲシステムのさらに他の説明図である。 図５は本発明の１つの実施例としてのＩＨＲシステムのカスタム化されたアプリケーションを示すＩＨＲシステムの他の説明図である。 図６は本発明の１つの実施例としてのデータ・フロー図である。 図７は本発明の１つの実施例としてのメッセージ処理マップである。 図８は本発明の他の実施例としてのインターフェース・サービス処理を示す説明図である。 図９は本発明の実施例として、２つのエンティティの統合を示す説明図である。 図１０は本発明の実施例としてのＩＨＲデータベースに対するオントロジー・ツールの相互関係を示す説明図である。 図１１は本発明の実施例としての許可権コンポーネントを示す説明図である。 図１２は個人のヘルスケア関練情報の例を示す簡略図である。 図１３は本発明の実施例としての役割に基づくユーザー許可セキュリティ・コンポーネントを示す。 図１４は本発明の実施例としての役割に基づくユーザー許可セキュリティ・コンポーネントを示す。 図１５は本発明の実施例としての器具のエレメントを示す説明図である。 図１６は本発明の実施例としてのアプリケーション・サーバーのエレメントを示す説明図である。 図１７も本発明の実施例としてのＩＨＲシステムを示す図である。 図１８の本発明の実施例としてのＩＨＲシステムを示す図である。 図１９は本発明の実施例としてのデータ・フロー図である。 図２０は本発明の実施例としてのメッセージ処理マップである。 図２１は本発明の実施例としてのＩＨＲエータベースに対するオントロジー・ツールの関係を示す説明図である。 図２２は本発明の実施例としての器具のエレメントを示す説明図である。

本発明は多様な、恐らくは予測不可能な情報システムおよび情報ソースからの個人ヘルスケア情報を収集し、処理し、評価し、変換し、報告するシステム、装置、および関連の方法であり、これにより広範囲の患者、介護士、医師、およびその他のユーザーが多様な、この情報を恐らくは予測不可能な態様で操作し、利用することを可能にする。本発明の個人健康記録（ＩＨＲ）システムは個人がその健康および医療に参加し、管理することを可能にする一方、ヘルスケア施設および介護士の要望を満たすことにより、新しい態様で協力的なヘルスケアを支援することができる。

本発明は「ヘルス・ユニバーサル・ジェネリシティ（ＨＵＧ）」として知られる新しいビジネス・オブジェクト・モデル・アプローチを使用する。このアプローチは受信される情報を一握りの高度に抽象化された健康オブジェクトで表現できると仮定している。これらの抽象化概念には、例えば、健康事象、健康状態、医療サービス、健康製品、健康関連情報などが含まれる。個々のオブジェクトはこれら抽象化された健康オブジェクトによって共有されるデータから、ＩＨＲに基づく医療提供プロセスを可能にする状態にデータを保持するためにだけ存在する「データ・オブジェクト」のユニークな相互作用を介して作成される。それぞれのオブジェクトの属性はオブジェクト分類において定義され、非プログラム的なユーザー定義属性によって拡張される特定変数の組み合わせである。

１つの実施例として、例えば、既存のヘルスケア情報システムおよび従業員の健康記録、薬局情報、試験所情報、医療費請求情報などの情報流れなどを含む多様なヘルスケア情報システムおよびヘルスケア情報ソースから情報を得ることによってＩＨＲを形成する。これらの情報ソースからの情報を個人の綜合的な健康および管理の明快なレポートに変換する。ＩＨＲは個人に関するヘルスケア情報の単なる収集物ではない；即ち、情報は包括的なヘルスケア・オントロジーに立脚する個人ヘルスケア・モデルによって処理される。

本発明のシステムは従来型システムとは異なる幾つかの独自の特徴を有する。第１の特徴として、抽象化レベルがヘルスケアに従来採用されてきたレベルよりもはるかに高い。即ち、従来のようにそれぞれの医療環境に特異な詳細なオブジェクトを使用するのではなく、各個人のヘルスケアに適合した高度に抽象化されたオブジェクトが使用される。本発明にこれらの高度に抽象化されたオブジェクトを採用することによって、本来なら他のシステムへの変化に必要な変更および資源のプログラミングの介入を必要としない広範囲の適応性とフレキシビリティを可能にする。第２の特徴として、オブジェクト・モデルを包括的なヘルスケア・オントロジーに結合することによるオブジェクト・モデルの拡張が従来のオブジェクト・パラダイムの意味と利用法を変える。第３の特徴として、本発明のシステムは（例えば、臨床情報、金銭情報、個人情報、健康情報、管理情報などを含む）個
人に関する殆どあらゆる情報を取出し、これを単一の、統一された形で表現することができる。これにより、本発明のシステムは密接に関連する臨床情報-臨床情報間または金銭情報-金銭情報間のトランザクションだけでなく、これら従来なら別々のデータの流れとされるデータの流れを横断するトランザクションまたは相互作用をも１つにまとめることができる。これによってそれぞれの個人、そのヘルスケア状態、およびヘルスケア・システムの関連事項の極めて堅牢な一覧が提供される。第４の特徴として、本発明のシステムは健康オブジェクト自体ではなくオントロジーを修正することによって健康オブジェクトおよびその挙動を拡張することができる。この修正は非プログラム的に行うことができるから、従来技術よりも高い導入容易度およびフレキシビリティが得られる。第５の特徴として、「遠心分離」処理（詳しくは後述する）によってメタデータ・データ・オブジェクトから健康オブジェクトが作成されるから、情報ソース情報を保存すると同時に、情報を使用目的変更処理して均一且つ統一された表現にすることができる。尚、本発明は、データ領域およびその定義を対で蓄積するがそのインフラストラクチャーはこの対に関して何も関知しないＸＭＬのようなアプローチは採用しない；本発明の場合、それぞれの対を構成するデータ領域とその定義に関してインフラストラクチャーが完全に把握している。

１つの実施例では、一連の健康オブジェクトがユニークであり、実質的に如何なる健康事例または健康活動をも特徴付け、個人に関する既知の、または未知の他の健康情報と相関させることができる。

図１はＩＨＲの広範な抽象図である。コアとなるＩＨＲアプリケーション１０は健康データ１２、接続性サービス１４およびインターネット・ウェブ・サービス１６から成る。データは多様な情報ソースシステム２０から受信される。多様なタイプのユーザーがカスタマー・アプリケーション３０またはカスタマー・ポートレット３２（詳しくは後述する）を介してＩＨＲシステムにアクセスする。カスタマー・ポートレット３２は図２に示すようにカスタマー・ポータル３４において使用することができる。

図３および図１７はファイアウォール４０に保護されたカスタマーの既存のＩＴシステムにインストールされた器具１０としてＩＨＲを示している。情報は多様な情報ソースシステム２０から受信される。ユーザーは、例えば、公共健康機関４２、開業薬局４３、試験所４４、病院４５などを含む。

１つの実施例として、図４および図１８に示すように、ＩＨＲシステムは休止状態オブジェクトおよび関連マッピングによって支援されるアプリケーション層におけるフル・オブジェクト・モデルと共に永続データ記憶層２００を含む。永続記憶層の一部はバイナリ・ラージ・オブジェクトおよびその他の典型的な非オブジェクト指向データ（例えば、画像、文献、ルール定義、メッセージテンプレート、情報コンテンツ、ヘルプ・ファイル）などのようなＩＨＲコンテンツ・アイテムの記憶機構として機能するコンテンツ・レポジトリーを含むとともに標準化テクノロジー（例えば、Java）をも含むことができる。コンテンツの属性またはコンテンツ・アイテムに連携するメタデータを利用することによって離散コンテンツ・アイテムを管理し、選択することができる。属性の例としては、例えば、オントロジー分類、ターゲットの年齢、ターゲットの性別、利用コンテキスト、有効期間、期限切れ日時、キーワード、状態、場所などが挙げられる。コンテンツ・レポジトリーは汎用アプリケーション・データ「スーパーストア」、即ち、殆ど如何なるタイプのコンテンツをも扱うことができ、データ・ストレージ手段からコンテンツを分離することができる。コンテンツはＸＭＬ言語で出し入れすることができる。標準的なＡＰＩ（例えば、JSR 170またはJSR 238）を使用することによってコンテンツ・レポジトリーと相互作用することができ、これによって他の標準的なコンテンツ・レポジトリーにアクセスすることができ、外部編集、およびJavaコンテンツ・レポジトリー間のコンテンツ転送が可能になる。

ＩＨＲサービス層２０６は、例えば、セントリフィケーション・サービス、相関サービス、管理サービス、システム管理サービスなどを含む主要なＩＨＲ機能を提供する。接続性サービス１４は情報ソースシステムとのインターフェース手段を提供し、メッセージや記録の構文解析を扱う。接続アダプタを使用することができる。ウェブ・サービス・コンポーネント２０８はユーザーからＩＨＲデータへの外部アクセスを可能にし、カストマーの申込書を含む種々のポートレット３２を介して機能する。１つの実施例では、ウェブ・アプリケーションとしてJava Specification Request 168(JSR-168)またはWeb Services for Remote Portlets(WSRP)標準ポートレットが使用することができる。図５に示すように、その他のアプリケーション２１０はウェブ・サービス２０８をコールすることによってカスタム化された解を作成することができる。

図６および図１９は本発明の１つの実施態様によるデータ流れの概観を示す。「メッセージ」５２（その他の形式または用語を採用することも可能）の形態を呈する情報およびデータが情報ソース５０から受信され、正当性を確認され５４、構文解析され５６、変換される５８。これらのステップは接続性サービス１４の一部としての統合サービスを介して遂行される。変換データは一致管理サービス６４を介して実在する個人に照合し６２、オントロジー・サービス６８を介してオントロジー・コンセプト・コード６６（後述するＣＨＩＤ）を割当てられる。次いで、メッセージ・オブジェクトが作成され７２、データが使用目的変更され７４、ルール・エンジン７８を利用してルール評価され７６、永続ＩＨＲデータベース９０にファイルされる８０。図１９に示すように、これらのステップを上記とは異なる順序で実行することもできる。一致管理サービス６４、オントロジー・サービス６８およびルール・エンジン７８はＩＨＲシステムのビジネス・プロセス・サービス７０のコンポーネントである。種々の情報ソースからの情報が更新されるのに伴って、ＩＨＲは連続的または定期的な態様でダイナミックに更新され、提供される。

接続性サービス・コンポーネント１４は健康データ供給ソースシステムとの接続を扱う。１つの実施例では、接続性サービスがオープンソース・クロス・プラットフォームＨＬ７インタフェース・エンジンを使用するが、他のプラットフォームを使用することもできる。接続構成マネジャーは構成データを記憶し、配置環境を管理する。プラットフォームは特定のメッセージ・ハンドリング・プロセス、接続性アダプタ、およびランタイム・エンジンを定義するのに利用される接続性・デザイナーを含む接続性ランタイム・コンポーネントをモニターし、管理する。

図７および図２０は本発明の１実施例のためのメッセージ処理マップを示す。図２０には２つのソースシステム、即ち、ソースシステムＡ９１およびソースシステムＢ ９２を示す。データはプロトコル９４およびエンベロープ９６処理され、変換処理９８される。データはマップされ１０２、インターフェース・スキーマ・ファイリング待ち行列に入れられる１０４。上記以外のインターフェース内部処理を図８に示す。

他の実施例として、本発明はシングル・ベスト・レコード（ＳＢＲ）を含む。ＳＢＲはヘルスケア事象、試験などに関して判明している「極めて優良」複合情報のようなヘルスケア・オブジェクトを含む。現在のヘルスケア電子記録システムおよびオペレーションにおいては、個人患者に関する大量の情報（この情報の多くは同じ事象に係わる）を試験する際に個人に依存し、事例のどの部分を関連事例と見做すかを手動で判断することになる。例えば、乳房Ｘ線写真については、先ず予約リクエスト、次いで患者登録時のアクセス要旨、数日後試験の報告、支払請求、試験に対する支払という順序で報告が行なわれる。公知システムでは、これらは別々の記録であり、実際にはすべて同じ事象を指しているにも係わらず、重要な情報を探し出すのは飽くまでもユーザーである本発明のＳＢＲのプロセスでは、これらすべての記録およびデータソースを評価し、すべてのソースから乳房Ｘ
線写真に関して判明している「極めて良好」情報を含む単一のＳＢＲオブジェクトに正しくまとめることができる。要約すれば、情報事象として受信された生々しい健康事象に関する断片的な情報がこれらの生々しい事象の綜合評価に再構成される。ＳＢＲオブジェクトは具体例としてＩＨＲシステムに取込まれる。後日８（１ヶ月、１年またはもっと遅れて）受信されたデータは受信と同時にＳＢＲ処理され、適切なＳＢＲオブジェクトとして成文化され、個人の健康記録の一部としてそれまでの記録に加えられる。

ＳＢＲプロセスは「情報事象」として入力されるそれぞれのデータを取込むことによって行なわれる。情報事象は必ずしも実生活事象との１対１の対応とは限らない。情報事象とは個人に関する情報を如何なるソースからも、如何なる時点においても受信できる方法を表わす。それぞれの情報事象から、主要健康データの具体的なサブセットをＳＢＲ処理する（即ち、評価し、組み合わせてＳＢＲとする）ことによって特定の個人に関するＩＨＲシステムの知識を作成または更新する。この処理には、例えば、サービス、日付、状態、製品、試験などの変更が含まれる。それぞれの情報事象をＩＨＲシステム中に既存のオブジェクトと比較することによって、この情報事象が新しい健康事象を示しているのか、それとも既知の健康事象に対する補足の情報なのか、もしそうなら、既知の健康事象に対して改善なのかどうかを判定する。このようにしてＳＢＲプロセスは外部ソースから得た情報を健康事象または健康コンセプトに関して既知である情報と独自の態様で組み合わせることによって、それまで断片データに過ぎなかったものを複合した情報を提供する。

幾つかの実施形態においては、或る人物に関してＩＨＲシステムが知る最善の人口統計データを複合することによって個人ＳＢＲを作成することができる。各人のデータ・オブジェクトからの人口統計データを用いてその人のＳＢＲを更新する。

一つの実施形態において、ＩＨＲシステムはエンティティを正確に同定または作成して、データを正確にリンクする能力に依存する。一致管理サービス（ＩＭＳ）６２はこれらの機能を扱う。１つの実施例では、２つのタイプのエンティティが特に重要である：即ち、（例えば、患者、会員、消費者、臨床医、個人などのような）個人と（例えば、従業員、支払人、プロバイダー、例えば、病院、参照試験所、撮像センター、または養護施設などのような)組織。ＩＭＳ機能はそれぞれのタイプのエンティティの作成、照合、統合および分離を含む。

一致照合の１つの目的は複数のソースからの或るエンティティに関する本質的に異なるデータを単一の記録（例えば、ＳＢＲ）に配置または挿入することにある。メッセージまたは入力データ中の個人および/または組織がＩＨＲシステムにとって既知の個人および/または組織と照合する（または、既存のものがないエンティティについては新しい記録を作成する）。一致照合プロセスはエンティティに割当てられているＣＨＩＤに戻る。照合のために基準照合を利用することもできる。基準は人口学的情報（例えば、氏名、生年月日、性別、アドレス、電話番号、ｅ-メール・アドレス、母親の旧姓）、識別子（例えば、診療記録番号、社会保障番号、会員番号、プロバイダーＩＤ、運転免許証ＩＤ）、または続柄情報（例えば、家族データ、サービス・プロバイダーとの関係）を含む。確率的照合を利用することもできる。

基準に基づく照合として、１つの実施例では、照合基準ルールのライブラリーまたは表を利用するができる。人物照合または組織照合にはルールが存在することがある。それぞれのルールは正しい照合を達成するのに満たさねばならない１つまたは２つ以上の基準を含むことがある。ルールは電子システムに応じて異なることがある。最良の実績が得られたら、他の電子システムに適用することができる。

一致が存在しないと判断したら、システムは新しいエンティティの記録を作成すること
ができる。

１つの実施例では、すべての人口学的ソースデータを他のデータ・オブジェクトと同様に処理する：即ち、メッセー中に人口学的ソースデータが受信されると、フォームまたはウェブ・サービス入力が事象を作成する。これにより、システムは関連事象中の人口学的データを表示することができ、必要に応じてエンティティを「再照合」および/または再ＳＢＲ処理することができる。

他の実施形態においては、２つのエンティティ１１０、１１２が実は同じエンティティであることをシステムが認識する場合、図９に示すように、第３のエンティティ１１４を作成することによって両エンティティを効果的に統合する。即ち、２つのエンティティからのデータおよび事象を統合する。事象１１６はオリジナル・エンティティを指すだけでなく、新しいエンティティをも指す。新しい事象は正しく付け加える必要がある：即ち、新しいデータを高レベルのエンティティだけでなく、最も特異な（最低レベルの）エンティティにも添える。統合されたエンティティによって直接、または統合されたエンティティにおいて形成された新しいデータはすべてこのエンティティに付け加えられる。統合されたエンティティ自体も統合されることがある。

逆に、エンティティを分離することもできる（即ち、連結されたエンティティを分離させる）。分離されるそれぞれのエンティティについては監査歴を作成することができ、従って、統合されていた状態のエンティティにはこの監査歴を介してアクセスすることができる。分離に際しては、分離されるエンティティにおける事象を手動で該当の低レベル・エンティティに割当てねばならない。

さらに他の実施例において、本発明のシステムは知識および情報の表現における公知技術の制約を克服するユニークなヘルス・オントロジーを含む。健康に関する情報を統一された態様で処理することが極めて望ましい。公知システムの多くは内部または外部になんらかのタイプのコード体系を含む。比較的ポピュラーなスキームとしては、標準医学用語(Standardized Nomenclature of Medicine-SNORMED)、およびＩＣＤ-９またはＩＣＤ-１０（臨床用改訂版を含む疾病国際分類-International Classification of Disease）が挙げられる。これらのコード体系は健康に関するＩＴシステムに必要な体系として古くから提案され、多くのシステムに採用されているが、主として遡及的研究に利用されており、リアルタイムの健康情報配信には余り貢献していない。

オントロジーは正式表現された知識の実質であり、一連のコンセプト、その定義、および特定ドメイン（この場合には健康と健康管理）との関係から成る。本発明のシステムのオントロジーはコード体系とは比較にならないものである：即ち、ヘルスケアに関するコンセプトの表現形式に止まらず、個人のヘルスケアを支援するためこのようなコンセプトを相関させる方法およびこのようなコンセプトを問い合わせ、呼び出す方法でもある。

１つの実施例として、本発明のシステムのオントロジー・サービスは受信された情報のそれぞれのエレメントを遠心分離して健康識別子（ＣＨＩＤ）を形成する。それぞれのＣＨＩＤは関係情報および属性情報の双方を含むから、受信されたままの情報における個々の情報エレメントの意味以上の内容を伝えることができる。例えば、帝王切開は単なる手術方法ではない。患者が帝王切開を経験したという事実から、多くの「知識コンセプト」が示唆される。特定の患者に関して利用できる種々のケア・コート体系によって、帝王切開だけでなく、恐らくは帝王切開に関連するその他の知見をも得ることができる。これらの相互関係をオントロジーでは、このような患者と関係がある問題点と所見の分野が、本発明が使用し、伝える固有の知識の一部となるように表現される。例えば、個人に帝王切開を経験したことが判明している場合、オントロジーはシステムに対してこの個人が女性
であり、妊娠の経験があり（妊娠回数＞０）こと、特に非膣分娩であったことも知らせる。他の例として、オントロジーの構造およびコンテンツによれば、高ヘモグロビンＡ１Ｃはその人物が糖尿病を経験したことだけでなく、糖尿病を患っている人々のすべての特徴分類の遺伝的形質をも通告する。

オントロジーは所与のコンセプトの特徴を識別する「多様な」属性を有し、例えば、表示方法、表示場所のほか、何がプライバシーであり、機密扱いを適用すべきかを認識する。データは情報ソースと同じ語彙コードとＩＨＲコンセプト・コード（例えば、ＣＨＩＤ）の双方で記憶される。

１つの実施例として、本発明のオントロジーは１，５００，０００以上のソース用語を含み、３００，０００個以上の明確なコンセプトを参照照合する。ＣＨＩＤとコンセプトには厖大な数のリンケージが存在するから、付加的使用事例を検討し、システムに組み込めばコンセプトもＣＨＩＤもさらに成熟し、意味も豊かになる。コンセプトは多様なソース用語との間で双方向にマップすることができる。情報をこのように表現することによって公知技術では不可能であったオペレーションがかのうになる。１例として、患者と介護者は、品質監視会社や疾病管理会社が利用するような事後の介入とは異なり、（疾病管理会社によって適用されると推定される）ルールに基づくケア・アルゴリズムをリアルタイムで活用することができる。

他の実施例では、オントロジー・ウェブ・サービスがＩＨＲシステム・オントロジーから該当のコンセプトを識別し、配信する。オントロジー・ウェブ・サービスによって採用される方法の例として、（マッピングされたＣＨＩＤを検索するために外部キーを通す場合に使用される）ｇｅｔＣＨＩＤ、（マッピングされた外部コンセプトＩＤを検索するためにＣＨＩＤを通す場合に使用される）ｇｅｔＦｏｒｅｉｇｎＫｅｙ、（システムによって制御される医学用語を検索するために使用される）ｇｅｔＮａｍｅ、および（外国述語を検索する場合に使用される）ｇｅｔＦｏｒｅｉｇｎが挙げられる。

実施例において、すべてのソース、使用、およびデータのユーザーにまたがることによって、個人中心の概要を提供し、的確な単一の最良記録の作成を支援することを目的とするオントロジーの使用はユニークである。

オントロジーの他の目的は警告および注意を発し、個人の健康状態を更新し、医療活動の推移および同様の活動をモニターするルールを採用してＩＨＲシステムにおけるデータが「相互作用」することを可能にすることにある。この目的を達成するためには、ＩＨＲシステムにおけるデータがコード化され、文脈および意味を有し、コンテンツにリンクされ、比較可能でなければならない（図１０および図２１参照）。このシステムから得られる主な利点は高い相互作用性、増大するユーザーの人数、診断の質の向上、医療ミスの減少、向上するデータマイニング、および結果分析の質の向上である。

ソース語彙は多数のコード体系およびコード・セットを含む。例えば、（ヘルスケア管理トランザクションの電子的なデータ交換を規定する）ＡＮＳＩＸ．１２；（電子的なヘルスケア情報の交換、管理および統合を規定する）ＡＭＳＩ ＨＬ-７のバージョン２およびバージョン３；ＣＰＴ（Ｃｕｒｒｅｎｔ Ｐｒｏｃｅｄｕｒａｌ Ｔｅｒｍｉｎｏｌｏｇｙ−医師診療行為用語）；ＨＣＰＣＳ（Ｈｅａｌｔｈｃａｒｅ Ｃｏｍｍｏｎ Ｐｒｏｃｅｄｕｒｅ Ｃｏｄｉｎｇ Ｓｙｓｔｅｍ−ヘルスケア常用コード化体系）；ＩＣＤ-９-ＣＭおよびＩＣＤ-１０（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｌａｓｓｉｆｉｃａｔｉｏｎ ｏｆ Ｄｉｓｅａｓｅｓ Ｐｒｏｃｅｄｕｒｅｓ−国際疾病および医療分類）；ＩＳＯ（Ｉｎｔｅｒｎａｌ Ｓｔａｎｄａｒｄｓ Ｏｒｇａｎｉｚａｔｉｏｎ−国際標準化機構）；ＬＯＩＮＣ（Ｌｏｇｉｃａｌ Ｏｂｓｅｒｖａｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒｓ、Ｎａｍｅｓ
ａｎｄ Ｃｏｄｅｓ−論理的観察識別子、名称およびコード）；ＮＡＣＩＳ（Ｎｏｒｔｈｅｒｎ Ａｍｅｒｉｃａｌ Ｉｎｄｕｓｔｒｙ Ｃｌａｓｓｉｆｉｃａｔｉｏｎ Ｓｙｓｔｅｍ−北米産業分類体系）；ＮＣＰＤＰ（ｓｃｒｉｐｔ ｅＰｒｅｓｃｒｉｂｉｎｇ ｓｔａｎｄａｒｄ−処方箋作成規定）；ＮＤＣ（Ｎａｔｉｏｎａｌ Ｄｒｕｇ Ｃｏｄｅｓ−全米医薬品コード）；ＮＵＢＣ（Ｎａｔｉｏｎａｌ Ｕｎｉｆｏｒｍ Ｂｉｌｌｉｎｇ Ｃｏｄｅ−全米請求書作成コード）；ＲｘＮｏｍ（ｎｏｍｅｎｃｌａｔｕｒｅ ｆｏｒ ｃｌｉｎｉｃａｌ ｄｒｕｇｓ−臨床薬学名）；およびＳＮＯＭＥＤ ＣＴ（Ｓｙｓｔｅｍａｔｉｚｅｄ Ｎｏｍｅｎｃｌａｔｕｒｅ ｏｆ Ｍｅｄｉｃｉｎｅ−系統別薬剤名）。ソースシステムからの使用権付コードも必要に応じて使用することができる。

１つの実施例として、中枢オントロジーはサービス・プロバイダーによって維持され、且つ連続的に更新される。大きく更新される場合には、更新されたオントロジーが公開される。管理者および健康問題助言者は局所的に自らのオントロジーへ拡張することができる。

他の実施例では、システムが認証されたソースから随時データを収集するというＩＨＲシステムのアプローチを支援する接続性アプリケーション・モジュールを含む。接続性アプリケーション・モジュールはあらゆるタイプのデータ、情報およびメッセージを受信し、理解し、処理することによって殆どあらゆるタイプまたは種類のソースがＩＨＲシステムに対して情報を提供することを可能にする。１つの実施例では、ＩＨＲシステムの特定装置に１５０個以上のソースシステムからの情報を取込むことができる。ソースシステムの数は無制限である。

ＩＨＲシステムのさらに他の実施形態として、システム内に理解可能な、および理解されたデータが存在することで、患者、介護者、およびその他のユーザーは広範な用途にデータを活用することができる。利用目的の例としては、質の向上（例えば、重複ブロック化、相互作用検出および導出、疾病管理およびその他のプロトコルとのリアルタイム密着、および最善治療法の実行）、および効果/能率の最適化を挙げることができる。これら使用目的の多くはＩＨＲシステム中に継目無く組み込まれて、それまでは利用できなかったようなレベルの綜合的なルールを提供するルールを検出し、実行することによって達成される。

ＩＨＲルール環境は完全にオントロジー表現されたデータを利用するシステムのために作成されたオブジェクトに追随する。オブジェクトが作成または修正されるごとに、適用可能なすべてのルールを評価することによって特定の基準が満たされているかどうかを知る。このプロセスには、例えば、すべての状態インジケーターの更新、時間依存基準（例えば、４０名以上の女性の１年毎の乳房Ｘ線写真）に関連するルールの調達およびスケジューリングが含まれる。従って、１つの実施例では、データ作成事象またはデータ修正事象によって時々刻々ルールを実行することができる。ルールはまた他のルールをトリガーし、運用しながらヘルス配信システムの複雑化させることができる。

個人の健康状態インジケーターはＩＨＲシステムにデータが入力されるのに伴って更新される。個人のＩＨＲに新しいデータが追加されると（またはデータが修正されると）、ルールが評価される。ルール・スケジュールも利用され、オブジェクトが特定の周波数で自らをスケジュールすることができる。スケジューラーは時間依存基準に関してルール評価を実行する。この時間依存基準は年齢依存性のルールを含むことがある。また、医療活動予定日前の適当な時期に最初の通知が届けられる。

一般論として、ＩＨＲシステムはルールを利用することによって個人およびユーザーを分類し、個人の健康状態を更新し、これをユーザーに通知し、健康維持対策、プロセス・
アクション・プランを作成し、他のデータからデータを作成し、データ入力ビジネス・ロジックを実行し、該当するＣＨＩＤ、アプリケーション・フローを選択し、加入広報サービスを支援し、個人名入りのコンテンツを提供する。ルール・アプリケーションの例として、健康問題オブジェクトの作成；ヘルス・サービス・オブジェクトの作成；状態の更新；アクション・プランの更新；安全メッセージのトリガー；注意喚起のトリガー；コンテンツ表示の起動；入力のリストアップ；外部システムへのメッセージ送信；ファックス送信；リスト補充；ヘルス・カレンダーの充実などが挙げられる。

１つの実施例では、ビジネス・ルールをアプリケーション・コードの変化とは独立に管理する。プログラムに基づかないでルールを作成し、変更することができる。これはアドオン・デシジョン・テーブルによる支援で行なわれる。多種にわたるルールを支援することができ、ルール変更のオーディット・トレールを保管することができる。

デシジョン・テーブルを利用することによって条件付きロジックを表現することができる。集計表を利用することによってルールを定めることができる。ルール作成者はオブジェクト・モデル対ルール・データをマップするスクリプトを隠したまま、パラメータを定義することができる。

ルールが真なら、アクションがトリガーされる。アクションとしては、健康問題オブジェクトの作成；ヘルス・サービス・オブジェクトの作成；状態インジケーターの更新；アクション・プランの更新；メッセージの安全確保；コンテンツ表示；入力のリストアップ；ヘルス・カレンダーの入力；外部システムへのメッセージ送信；またはファックスの送信などが挙げられる。

本発明の他の実施例は使用目的変更オブジェクト・プログラム（ＲＯＰ）を含む。ＲＯＰは多くの公知システムの基本的な制約、即ち、それぞれのデータ・アイテムの目的、それぞれのデータ・エレメトが収まる分類棚が永遠にかわらない、という制約を克服する。ＩＨＲシステムにおいては、システムが受信するデータを、システムを構築した時点において既に意図されていた多様な目的に利用することができる。上述した構成要件と相俟って、ＲＯＰはデータの使用目的を変更できるシステムを実現する。

上述したプロセスとコンポーネントとを組み合わせた結果がいわゆる遠心分離プロセスである。遠心分離プロセスは断片的な、フォーマットの曖昧な、多くの場合非包括的なヘルスケア・データを排除して、有用な、個人中心のヘルスケア情報に仕上げる。

１つの実施例では、ヘルスケアに関するオントロジーを生み出した概念化、設計、開発および実行のプロセスをシステム全体に亘って一般化し、適用した。（例えば、表示、レンダリング・モデル、ラベル、入力フィールド、コンテンツ・マネジャーなどのような）アプリケーション構成要素の幾つか、またはすべてを体系化することによって、これらを非プログラム的に制御できるようにした。

さらに他の実施形態では、ＩＨＲシステムが、複数の情報流れおよび情報ソースからのコンテンツを一致参照し、表示し、オントロジーまたは他のＩＨＲシステム・サービスを介して提供される該当のキーとリンクさせることができるメタデータ・コンテンツ制御モデルを採用する。これによって、個人および専門家ユーザーの双方に対するコンテンツ表示に関して、公知技術には存在しないレベルの個人化が可能になる。

他の実施例では、ＩＨＲシステムがセキュリティー基準サービスを含む。公知のセキュリティー・モデルは既知の、予測可能なシステムの使用パターン、ユーザーのタイプ、およびデータのタイプなど、すべてがデータ管理者によって、且つデータ管理者に対して何
らかの制約を課せられる環境においてインストールされることを前提としている。その上、公知のセキュリティー・モデルは多種類のユーザーがそれぞれ異なる目的で同じ記録を利用する環境において作用するには融通性に欠ける。これに反して、ＩＨＲシステムは確保すべき情報の量も詳細度も予め推測できないとの認識に立っている。ＩＨＲシステムは例えば下記のような多様なユーザーに対応するように設計されている：患者；消費者；管理者に安全管理を委任するユーザー；および直接的な管理介入ではなく監査の必要からシステムと行き来するユーザー。ＩＨＲシステムは完全に適応できる：サービスは確保すべきデータ、このデータにアクセスする可能性があるエンティティに関する既知の事項、およびこれらの組み合わせから生まれる結果を評価する。図１１に示すように、認可権コンポーネントはスコープ・アクセス、オペレーション・アクセスおよびデータ・アクセス・エレメントを含むことができる。

１つの実施例として、データ・アクセスは保護健康情報、機密を要する健康情報および作成された保護健康情報を含むデータ分類次第である。保護健康情報（ＰＨＩ）は個人の過去、現在、または将来の肉体的または精神的な健康または状態、個人に対するヘルスケアの提供、または個人に対するヘルスケア提供のための過去、現在または将来の支払に関する、および個人を識別するまたは識別するのに利用できそうな情報を意味する。機密を要するＰＨＩは(i)個人のＨＩＶ状態または個人のＨＩＶ関連の疾病またはＡＩＤＳに対する治療、(ii)個人の薬物乱用状態または薬物乱用障害の治療、または(iii)個人の精神障害またはその治療に関するＰＨＩを意味する。作成されたＰＨＩとは催し物の主唱者または出演者のような特定のユーザーによって作成された情報を指す。いずれの実施例においても、個人的なヘルス・データの扱いには関連するすべての条例および法律、例えば、ＨＩＰＡＡ（ＨｅａｌｔｈＩｎｓｕｒａｎｃｅ
Ｐｏｒｔａｂｉｌｉｔｙ ａｎｄＡｃｃｏｕｎｔａｂｉｌｉｔｙ Ａｃｔ-医療保険携行性と責任に関する法律）の順守が義務付けられる。

１つの実施例として、ＩＨＲ管理サービスはＩＨＲが知っているおよび/または推測できるエンティティ間の関係に基づくセキュリティー・アーキテクチャーを含む。ＩＨＲシステムのユーザーがアクセスできる、いわゆる「スコープ」は個人に関するデータが増えるに従って動的に再定義される。直接データ入力またはその他のソース、例えば、ソースシステムとのネットワークまたはウェブ・サービスの相互作用などからデータが受信されると、エンティティ間の関係が収集され、体系化され、関係に関する既知情報が充実される。このようにしてエンティティ間の種々の関係が記録され、それぞれの関係毎のＳＢＲに集約される。

ユーザーがＩＨＲシステムのアクセスポイント、例えば、ヘルス・ポートレットにアクセスすると、ユーザーの権利に応じたスコープが評価される。ユーザーがアクセスすると、関係パラメータに合致する健康記録のデータおよび情報のみが回答として返信される。

スコープ・アクセスは個人に対するユーザーの関係に基づいている。個人のケア関係の１例を図１２に示す。個人と「合法的な関係」を有するユーザーだけがこの個人に関する記録にアクセスできる。１つの実施例として、ＩＨＲシステムにおける合法的な関係は健康関係である。

セキュリティー・アーキテクチャーは多数のそれぞれ独自の管理サービスを含む。公知システムは多くの場合、ヘルス・システムにおいては記録のレベルではなくデータのレベルでセキュリティーを実行すべきであり、従って、患者のデータへの完全なアクセスを制限するか、またはあらゆる項目に亘って患者情報（例えば、保険情報）へのアクセスを制限すべきであることを見落としている。必要なのは患者情報の如何なる要素（例えば、医学的コンセプト）へのアクセスをも制限できることである。本発明のＩＨＲシステムは特
定のコンセプトまたはＣＨＩＤ、またはフィールドまたはデータ・エレメントの数値、またはこれらの組み合わせに対するアクセスを制限することができる。従って、本発明のシステムはオントロジーで定義されるＣＨＩＤの属性（またはその他の数値）に基づくオブジェクトの属性へのアクセスまたはその表示を制限することができる。

さらに他の実施例として、図１３および図１４に示すように、ＩＨＲシステムはユーザーの役割に応じて多層的に、但し非階層的にアクセスまたは表示を制限することができる。役割とはヘルスケア事象に関して個人が果す職務または責任を意味する。役割情報は分類されているヘルスケア活動との個人の関連を文書で証明する情報である。役割の例としては、プロバイダーとしての役割（例えば、認証、看護、請求書作成、コンサルティング、協力、通訳、主催、照会、付帯サービス、管理、治療など）、個人的な役割（本人、近親者、緊急連絡、保証人、保護者）、または組織に関練する役割（通信事業者、従業員、雇用主、被保険者、受信契約者）が挙げられる。ユーザーは複数の役割１２０，１２１、１２２を持つことができ、それぞれの役割に特定の権利１２４、１２５、１２６、１２７が付与される。ユーザーの役割または「職務」が変わると、その権限も変わる。ユーザーの権限にはスコープ・アクセス権、オペレーション・アクセス権、およびデータ・アクセス権が含まれる。即ち、例えば、医師が治療に際して行使できるアクセス権は同じ医師が自身の記録を閲覧する際の権限または健康保険会社の保険医として行動する際の権限を超えて多様である。同様に個人もまた、情報の種類によっては（機密を要する個人健康情報、例えば、精神科情報、薬物乱用情報、ＨＩＶ状態、ＡＩＤＳデータなど）、自身のＩＨＲの一部または全部に対する介護者のアクセスを許諾または制限することができる。緊急時において、その措置が妥当であるなら、権限を認められているユーザーが制限されている情報を「開封」することができる。

本発明は、例えば、ヘルス・ポータル、ヘルス・ポートレットおよびウェブ・サービスを介してＩＨＲに含まれる情報と相互作用する種々の方法および手段を提供する。即ち、本発明は単なるエンドユーザー・アプリケーションではなく、完全な情報サービス・スイートを提供する。これにより、本発明は事前「記録」方式では不可能な態様で既存の情報システムを支援することができる。１つの実施例として、Ｊａｖａ規格ポートレットおよびウェブ・サービスを利用することによって、標準的なポータルを介してユーザー・インターフェース（およびユーザーの相互作用）を成立させる。ポータルはインターネット-ベースのアプリケーションであり、他の資源またはアプリケーションに対する起点またはゲートウェイとして機能する。従来、ポートレットは特定のポータルに合わせたカスタム・アプリケーションであったが、最近になって初めてポートレット規格（例えば、ＪＳＲ１６８）が規定された。相互作用はすべて、ポートレットを介してポータルからインターネット・サービスを通過してＩＨＲアプリケーション・サーバーに至る通信・チェインを介して行なわれる。本発明のシステムはユーザーの便宜を図るという意味でフレキシビリティとプラットフォームを横切る広範な偏在性を向上させる。

ＩＨＲシステムとＩＨＲポータルおよびポートレットとの接続は暗号化される。１つの実施例では、標準インターネット・ウェブ・ブラウザーを使用することによってポータルおよびポートレットがアクセスされ、接続は１２８-ビットのＳＳＬ-暗号化接続である。また、すべての管理サイトとの支援接続も認証されたユーザーだけがネットワークにアクセスし、データを傍受できないように暗号を使用するＶＰＮを介して行われる。

管理サービスは、例えば、データベース・ファイルおよびジャーナル・キューを含む種々のシステム・コンポーネントのバックアップを含む。中期的なストレージには高い頻度で、長期的ストレージには少ない頻度で段階的にバックアップを行なえばよい。データおよびシステムのセキュリティーおよび連続的なオペレーションのためには、故障回復オペレーションおよびフェイルオーバー・データベース・サーバーをも使用することができる
。

１つの実施例では、図３、１５、１７および２２に示すように、ＩＨＲシステムを内蔵型のパッケージまたは「器具」の形にＩＨＲをまとめることができる。器具はネットワーク・ファイヤーウォールで防護することができる。情報はすべての利用可能なソースシステムから得られ、動的にＩＨＲに組み込まれる。既存のヘルスケア・テクノロジー・システムおよびネットワークに「プラグ・アンド・プレイ」方式で簡単に且つ殆ど手を加えることなく機能するように設計された自己完結タイプのパッケージまたは「器具」に内蔵される。このレベルのアプリケーション・レベル・ソリューション用器具・モデルは新規であり、任意の数の器具を提供することができ、ＩＨＲを機能させるのに必要なユーザーの介入を極力少なくすることができる。さらにまた、このモデルはソリューションまたはノードのアーキテクチャーを大きく改変することなく、ノードに器具を補足するだけで処理容量を増大することができる。

このようにしてＩＨＲシステムは個人がそれぞれのヘルスケアを理解し、これに参加することを可能にする一方、同じ記録を異なる方法で利用することによって管理者と消費者が協力し且つ相互作用することを可能にする。ＩＨＲシステムは管理者とヘルスケア賛同者の新しい役割を含み、ヘルスケア・システムが将来に向かって発展するのに必要な条件を満たすため、ヘルスケアに関与する、例えば、ヘルス・システム、ヘルス・プラン、ＩＰＡ、ＲＨＩＯ、雇用者、プロバイダー、個人などを支援する。１つの実施例として、本発明は既存の情報システムおよびインフラストラクチャーを取り替えるのではなく、迅速且つ容易に健康関連の情報を提供する規格に準拠し、サービスに寄与するインフラストラクチャーおよび既存のシステムと協働するコンポーネントを提供する。

種々の実施例においてユーザーが利用できるオペレーションとして、例えば、個人の識別、事象リストの閲覧、事象のフィルタリング、事象の列挙、事象の追記、事象のプリンティング、列挙された事象の閲覧、ユーザーの管理（例えば、ユーザーの追加、ユーザーの追記、ユーザー・フィールドの追記、ユーザーの活動停止、ユーザーの識別）、個人の識別、健康問題のハンドリング（例えば、健康問題のフィルタリング、リスト閲覧、詳細の閲覧、補足、プリンティング）を挙げることができる。

尚、本発明の原理およびその実用性を解りやすく説明し、当業者が多様な実施形態で且つ多様な変更を加え、具体的な使用目的に合わせて本発明を利用できるように実施形態および実施例を以上に説明した。本発明の特定の実施形態を説明したが、これらの実施形態が本発明の範囲を限定するものではなく、ほかにも種々の実施形態が可能であることは当業者に明白であろう。

Claims (21)

1. ヘルスケア情報を処理し、蓄積し、操作するためのシステムであって、
   （ａ）永続データ・ストレージ・デバイスと；
   （ｂ）１つまたは２つ以上のヘルスケア情報ソースからのヘルスケア情報を受信する情報入力コンポーネントと；
   （ｃ）受信される情報を個人の総合的な健康および管理の明快なレポートに変換および使用目的変更し、受信される情報のそれぞれのエレメントから健康識別子（ＣＨＩＤ）を形成することによってオントロジー・サービスを提供し、当該情報から抽象的なヘルスケア・オブジェクトを作成または変更する中央ヘルス・レコード・コンポーネントと；
   （ｄ）単数または複数のユーザーによるシステムへのアクセスを可能にするユーザー・インターフェース・コンポーネントと；
   （ｅ）複数の情報流れおよび情報ソースからのコンテンツを一致参照し、表示し、該当のキーとリンクさせ、コンテンツ表示に関する個人化を行うメタデータ・コンテンツ制御モデルと；
   （ｆ）前記健康識別子の属性に基づくオブジェクトの属性へのアクセスまたはその表示を制限するセキュリティー・アーキテクチャーを含み、
   前記健康識別子は明確なコンセプトを表し、前記コンセプトは１つまたは２つ以上のヘルスケア情報ソースとの間で双方向にマップされ、リアルタイムで活用され、前記中央ヘルス・レコード・コンポーネントは、断片的な、フォーマットの曖昧な、非包括的なヘルスケア・データを、有用な、個人中心のヘルスケア情報に仕上げることを特徴とする
   ヘルスケア情報を処理し、蓄積し、操作するためのシステム。
2. オブジェクト向きでないデータを蓄積するためのコンテンツ・レポジトリーをも含む請求項１に記載のシステム。
3. ユーザーがウェブにおける１つまたは２つ以上のポートレットまたはポータルを介してユーザー・インターフェース・コンポーネントにアクセスでき、前記ユーザーは複数の役割を持ち、それぞれの役割に特定の権利が付与され、前記役割が変わると、前記ユーザーの権限も変わり、前記権限にはスコープ・アクセス権、オペレーション・アクセス権、およびデータ・アクセス権が含まれる、請求項１に記載のシステム。
4. ユーザーがインターネット・ブラウザーを介してユーザー・インターフェース・コンポーネントにアクセスできる請求項１に記載のシステム。
5. ヘルスケア・オブジェクトの作成または変更が非ＸＭＬベースのヘルスケア・オントロジーを利用して情報を処理することである請求項１に記載のシステム。
6. 受信される情報が臨床、金銭、健康、または管理情報、またはこれらの情報の組み合わせを含む請求項１に記載のシステム。
7. オントロジーを変更することによってヘルスケア・オブジェクトを変更または拡張できる請求項５に記載のシステム。
8. 変更が非プログラム的に行われる請求項７に記載のシステム。
9. システムのコンポーネントが単一の器具に内蔵され、前記器具を既存のネットワークまたは情報技術システムに組み込むことができる請求項１に記載のシステム。
10. 既存のネットワークまたは情報技術システムに複数の器具を組み込むことができる請求項９に記載のシステム。
11. ヘルスケア・データを処理し、変換する方法であって、
    （ａ）情報入力コンポーネントが１つまたは２つ以上のヘルスケア情報ソースから個人のヘルスケアに関する情報を受信し；
    （ｂ）中央ヘルス・レコード・コンポーネントが情報を統合し；
    （ｃ）前記中央ヘルス・レコード・コンポーネントが情報を識別し；
    （ｄ）前記中央ヘルス・レコード・コンポーネントが、情報を、個人に関する、必ずしも特定の医療環境に特異ではない１つまたは２つ以上の抽象化された健康オブジェクトに変換し；
    （ｅ）メタデータ・コンテンツ制御モデルが、複数の情報流れおよび情報ソースからのコンテンツを一致参照し、表示し、該当のキーとリンクさせ、コンテンツ表示に関する個人化を行い；
    （ｆ）セキュリティー・アーキテクチャーが前記オブジェクトの属性へのアクセスまたはその表示を制限し；
    （ｇ）前記中央ヘルス・レコード・コンポーネントがコンセプトを１つまたは２つ以上のヘルスケア情報ソースとの間で双方向にマップしてリアルタイムで活用し；
    （ｈ）前記中央ヘルス・レコード・コンポーネントが、断片的な、フォーマットの曖昧な、非包括的なヘルスケア・データを、有用な、個人中心のヘルスケア情報に仕上げる
    ステップを含む、ヘルスケア・データを処理し、変換する方法。
12. 前記中央ヘルス・レコード・コンポーネントが変換された情報にルールを適用し；
    前記中央ヘルス・レコード・コンポーネントが変換された情報をデータベースにファイルするステップをも含む請求項１１に記載の方法。
13. 前記中央ヘルス・レコード・コンポーネントが情報を統合するステップが、
    情報の正当性を確認し；
    情報を構文解析し；
    情報を変換するステップから成る請求項１１に記載の方法。
14. 前記中央ヘルス・レコード・コンポーネントが情報を識別するステップが、情報に対応するエンティティを、既にデータベースにその情報が存在するエンティティと一致させようとするステップである請求項１１に記載の方法。
15. 前記中央ヘルス・レコード・コンポーネントが情報を使用目的変更処理し、ユーザーについて複数の役割を作成するステップをも含み、前記ユーザーは複数の役割を持ち、それぞれの役割に特定の権利が付与され、前記役割が変わると、前記ユーザーの権限も変わり、前記権限にはスコープ・アクセス権、オペレーション・アクセス権、およびデータ・アクセス権が含まれることを特徴とする
    請求項１１に記載の方法。
16. ヘルスケア情報を処理する方法であって、
    （ａ）情報入力コンポーネントが１つまたは２つ以上のヘルスケア情報ソースから個人のヘルスケアに関する情報を受信し；
    （ｂ）前記中央ヘルス・レコード・コンポーネントが非ｘｍｌベースのヘルスケア・オントロジーを用いて、情報を、個人に関する、必ずしも特定の医療環境に特異ではない１つまたは２つ以上の抽象化された健康オブジェクトに変換し；
    （ｃ）メタデータ・コンテンツ制御モデルが、複数の情報流れおよび情報ソースからのコンテンツを一致参照し、表示し、該当のキーとリンクさせ、コンテンツ表示に関する個人化を行い；
    （ｄ）セキュリティー・アーキテクチャーが前記オブジェクトの属性へのアクセスまたはその表示を制限し；
    （ｅ）前記中央ヘルス・レコード・コンポーネントがコンセプトを１つまたは２つ以上のヘルスケア情報ソースとの間で双方向にマップしてリアルタイムで活用し；
    （ｆ）前記中央ヘルス・レコード・コンポーネントが、断片的な、フォーマットの曖昧な、非包括的なヘルスケア・データを、有用な、個人中心のヘルスケア情報に仕上げる
    ステップを含む、ヘルスケア情報を処理する方法。
17. ヘルスケア・オブジェクトが２つ以上の情報ソースからの情報から成る請求項１６に記載の方法。
18. オントロジーを変更することによって前記中央ヘルス・レコード・コンポーネントがヘルスケア・オブジェクトを変更または拡張でき
    る請求項１６に記載の方法。
19. 前記中央ヘルス・レコード・コンポーネントによる変更が非プログラム的に行われる請求項１６に記載の方法。
20. 前記中央ヘルス・レコード・コンポーネントが情報ソースおよび関連するヘルス・オブジェクトの双方を保存する請求項１６に記載の方法。
21. ヘルス・オブジェクトが方法、属性、および遺伝的形質、またはこれらの組み合わせを含む請求項１６に記載の方法。