JP2008527520A - 安全なデータ交換、収集、監視及び／または警告のためのプライバシー資格プロトコル - Google Patents

Abstract

サブスクライバ及びパブリッシャのコンピュータ・ネットワークを用いてデータの協調交換の資格制御されたレベルを提供する方法、システム及び関連のコンピュータ製品は、（ａ）一連の異なるプライバシー・レベルを定義し、各プライバシー・レベルが、コンテンツ固有のデータを送信する参加中のパブリッシャの能力と、コンテンツ固有のデータを受信する参加中のサブスクライバの能力とを制御する関連のデータ共用パラメータを有し、（ｂ）異なるプライバシー・レベルごとに異なるデータ共用パラメータを定義し、参加中のサブスクライバ及びパブリッシャごとに、関連する少なくとも１つのプライバシー・レベルを識別する電子プライバシー・レベル・レジスタを提供するように構成されている。

Description

関連出願の相互参照
本願は、これと同時に提出した代理人整理番号５５７７‐３２８、５５７７‐３２９及び５５７７‐３３２の譲受人に譲渡された同時係属出願であって、本明細書では、これら文献の内容を全体として援用する。

本発明は、コンピュータ・ネットワークを用いるデータ共用に関し、特に、イントラネット及び／または公衆インターネットにわたった医療ケア臨床データ共用に適する。

医療ケア通信システムは団体間で一般的に制限され、通常、規格外であり、複数の医療ケア・プロバイダにわたって医療ケア・データへアクセスし、これを追跡し、及び／または警告するのが難しい。米国では、６千以上の病院、何十万もの医療従事者、及び、臨床データの交換を希望する可能性がある他の複数の団体が存在する。中央データ・リポジトリを用いてデータ交換を容易にするデータ共用に対して、技術上、法律上及び／または社会的な障害が存在し、このようなリポジトリが存在したとしても、中央データ・リポジトリへの現在の認識及び／またはアクセスを維持するのはほとんど不可能である。更に、多くのプライバシー団体は、医療ケア・システムで治療を受けている患者から患者情報を収集する国家的な（または多国籍あるいはグローバルな）リポジトリに反対する。

過去において、医療ケア・データを交換する従来手段には、郵送のようなデータの手動伝達、電話通信、プロジェクト固有の形式及び／または２地点間インターフェースのデータ・テープ、ディスクまたはファイルの交換、及び／または、データ共用を提供するデータ・マイニング技術の使用が含まれた。すなわち、幾つかの従来のシステムは、ソースからデータを抽出し、データを変換及び正規化し、次に、変換したデータをデータ・マイニング用の中央リポジトリにロードすること（「ＥＴＬ」）によって様々なデータ・セットを共用し、特定の事象に関する情報を取り出すように構成されている。残念なことに、ＥＴＬは、このようなシステムを使用し難くすることがあり、システムのスケーラビリティを制限することがある。

本発明の一側面によれば、本発明は、加入者（サブスクライバ）及び公開者（パブリッシャ）のコンピュータ・ネットワークを用いてデータの協調交換の資格制御されたレベルを提供する方法を提供する。この方法は、（ａ）一連の異なるプライバシー・レベルを定義するステップであって、各プライバシー・レベルが、各パブリッシャからコンテンツ固有のデータを受信する参加中のサブスクライバの能力を制御する関連データ共用パラメータを有するステップと、（ｂ）一連の異なるプライバシー・レベルから参加中のパブリッシャごとに選択されたとして承認されたプライバシー・レベルがどれであるかを参加中のサブスクライバごとに識別し、これによって、サブスクライバとパブリッシャとの間の制御された電子データ共用プロトコルに基づいて資格を提供する電子プライバシー・レベル・レジスタを提供するステップとを含む。

本発明の別の側面によれば、本発明は、サブスクライバ及びパブリッシャ・パーティシパントを含むウェブ・ベースの医療ケア協調データ共用システムを提供する。パブリッシャは、サブスクライバとデータ共用プロトコルを確立する、異なる医療ケア・データ・コンテンツに対して少なくとも１つの定義されたプライバシー・レベルを有する。サブスクライバは、パブリッシャとデータ共用プロトコルを確立する少なくとも１つの定義されたプライバシー・レベルを有する。定義されたプライバシー・レベルは、参加中のサブスクライバ及びパブリッシャに対するシステムによって用いられる一連の共通の定義されたプライバシー・レベルから選択される。

本発明の別の側面は、インターネットを用いてパブリッシャ・パーティシパントとサブスクライバ・パーティシパントとの間の協調医療ケア・データ共用を提供し制御するウェブ・ベースの安全なデータ共用システムに関する。このシステムは、（ａ）インターネットを介してパーティシパント医療ケア・パブリッシャ・ゲートウェイ及びサブスクライバと通信するように構成されたメッセージ・フロー・サーバと、（ｂ）メッセージ・フロー・サーバと通信する管理サーバとを含む。管理サーバは参加中のサブスクライバとパブリッシャとの間の通信を制御するように構成されている。各参加中のサブスクライバ及びパブリッシャは、定義された一連のプライバシー・レベルから選択された少なくとも１つのプライバシー・レベルを有する。管理サーバは、特定タイプの患者医療ケア・データに対してプライバシー・レベルを定義する電子プライバシー・レベル・レジスタと通信する。このシステムは、サブスクライバとパブリッシャとの間の通信をそれぞれのプライバシー・レベルに基づいて制御するように構成されている。

本発明の別の側面は、（ａ）メッセージ・フロー・サーバと、（ｂ）メッセージ・フロー・サーバと通信する電子患者医療ケア・レコードへアクセスする複数のパブリッシャ・パーティシパントと、（ｃ）メッセージ・フロー・サーバと通信する複数のサブスクライバ・パーティシパントとを含む医療ケア協調データ共用コンピュータ・ネットワーク・システムに関する。各パブリッシャは、少なくとも１つのパブリッシャ・ゲートウェイを含む。パブリッシャ・ゲートウェイは、それぞれのサブスクライバとの間の電子通信を受信し中継するデータ共用プロトコルを電子的に制御する少なくとも１つの定義されたプライバシー・レベルを有するように構成されている。各サブスクライバは、参加中のパブリッシャからの医療ケア・データへのアクセスを制御する定義されたプライバシー・レベルを有する。医療ケア・トピックに関連する医療ケア・データは、サブスクライバが、トピックの医療ケア・データに対してサブスクライバに資格を与えるプライバシー・レベルを有する場合だけ、メッセージ・フロー・サーバを介してパブリッシャ・ゲートウェイからサブスクライバに選択的に電子的に自動的に転送される。

更なる他の側面は、コンピュータ・ネットワークを用いる協調データ共用システムにおいてデータ共用を制御するコンピュータ・プログラム製品に関する。このコンピュータ・プログラム製品は、コンピュータ可読プログラム・コードを内部で統合させたコンピュータ可読ストレージ媒体を含む。コンピュータ可読プログラム・コードは、（ａ）パブリッシャ及びサブスクライバごとに少なくとも１つのプライバシー・レベルを定義するように構成されたコンピュータ可読プログラム・コードであって、少なくとも１つのプライバシー・レベルが、グローバルな一連の定義されたプライバシー・レベルから選択され、異なるプライバシー・レベルが、データ・レコードの異なるコンテンツと関連するコンピュータ可読プログラム・コードと、（ｂ）データをリクエストしているサブスクライバと、定義されたプライバシー・レベルに基づくデータを有するパブリッシャとのデータ共用プロトコルを定義するように構成されたコンピュータ可読プログラム・コードと、（ｃ）サブスクライバ及びパブリッシャのパーティシパント登録と、それらの定義されたプライバシー・レベルとを提供するように構成されたコンピュータ可読プログラム・コードとを含む。

例えば、実施形態が方法として記述される場合、機能をコンピュータ・プログラム製品及び／または、装置またはシステムとして実装できるような他の方法で、特定タイプの実施に関して記述した実施形態及び／または機能を実装できることに留意すべきである。本発明のこれら及び他の目的及び／または側面は、以下に詳細に説明される。

次に本発明を、本発明の実施形態が示されている添付図面を参照して以下に更に詳細に説明する。しかし、本発明を多くの異なる形態で実装することができ、本明細書で記述する実施形態に限定すると解釈すべきでない。図中、同一の符号は、同様な要素を示す。図面において、特定の層、コンポーネント（構成要素）または機能を明確にするために強調することがあり、破線は、他に指定のない限り、任意選択の機能または動作を示す。更に、一連の動作（またはステップ）は、他に指定のない限り、特許請求の範囲または図面に記載された順序に限定されるものではない。「取り付け」、「接続」、「接触」、「結合」などの用語は、他に記述がない限り、直接または間接的に意味を表すことができる。

本明細書で用いられるように、用語「及び／または」は、関連してリストされた項目のいずれか１つまたはそれ以上のあらゆる組み合わせを含む。

当然のことながら、本明細書では、様々な要素を記述するのに第１、第２などの用語を用いることができるが、これら要素をこれら用語によって限定すべきではない。これら用語は、ある要素を別の要素と区別することだけに用いられる。従って、以下で説明する第１要素を、本発明の範囲から逸脱することなく第２要素と称することができる

本明細書で用いられる用語は、特定の実施形態だけを記述するためのものであって、本発明を限定するものではない。単数複数について、他に明確に指示のないものは１つ以上とする。当然のことながら、更に、本明細書で用いられる用語「備える」及び／または「含む」は、記述された機能、整数、ステップ、動作、要素及び／またはコンポーネントの存在を明示するが、１つ以上の他の機能、整数、ステップ、動作、要素、コンポーネント及び／またはそれらのグループの存在または追加を排除しない。

本明細書で用いられる（技術用語及び科学用語を含む）すべての用語は、特別の定義がない限り、本発明が属する技術分野における当業者によって一般的に理解される意味と同じ意味を有する。更に、当然のことながら、一般的に用いられる辞書に定義されるような用語は、本明細書及び関連技術の文脈にある意味と一致する意味を有すると解釈されるべきであって、本明細書で明確に定義されない限り、理想的に、またはあまりにも形式的に解釈されるべきではない。

用語「パブリッシャ」は、コンピュータ・ネットワークを用いて外部及び／または内部のサイトにデータを提供または「公開」することができるパーティシパントを意味する。一般的に、パブリッシャはオリジナルのデータ・ソースである。用語「サブスクライバ」は、コンピュータ・ネットワークを用いてトピックのデータをリクエストすることができるパーティシパントを意味する。パブリッシャを、それら自体のデータ、または他の参加中のパブリッシャのデータのサブスクライバとすることができる。用語「自動」は、人間オペレータの支援及び／または手動入力なしに、記述された動作のほとんどすべてまたはすべてを行うことができることを意味する。用語「電子」は、システム、動作または装置が任意の適切な電子媒体を用いて通信できることを意味し、一般的に、コンピュータ・ネットワークを用いてパーティシパント間の通信をプログラマチックに制御することに使用する。用語「ハブ」は、コンピュータ・ネットワークを用いてパブリッシャとサブスクライバとの間のデータ交換を制御するノード及び／または制御サイト（またはサイト）を意味する。パブリッシャ・サイトがそれ自体のメッセージへアクセスすることにハブを必要としなくてもよい（すなわち、この場合、医療ケア・データ・リクエストはパブリッシャ団体内のサブスクライバからのものであって、一般的に、団体固有のデータのためだけに、パブリッシャ団体からパブリッシャ・ゲートウェイによって制御される）。用語「ＨＩＰＡＡ」は、医療保険の相互運用性と説明責任に関する法律によって定義された米国の法律を意味する。用語「（１つ以上の）オープン・スタンダード」は、一般に公開された（すなわち、機密ではない）規格を用いてデータの標準化された電子形式を意味する。現在のオープン・スタンダード・メッセージング形式の例として、ＨＬ７、ＭＡＧＥ‐ＭＬ、及び、既存するか、あるいはまだ開発されていない関連業界規格コードが挙げられる。例えば、医療ケアの分野に対して、業界規格コードは、診断（ＩＣＤ９、ＩＣＤ１０）、手続き（ＣＰＴ）、実験結果（ＬＯＩＮＣ及び／またはＳＮＯＭＥＤ）及び薬品（ＮＤＣ、ＲｘＮｏｒｍ）に用いられる業界規格コードを含むことができるが、これらに限定されない。

用語「メッセージ」は、定義されたコンピュータ・コード言語形式とすることができるトピックに関する１つ以上のデータ要素を意味する。コマンド及び制御メッセージ、臨床またはターゲット・データ公開メッセージ、通知メッセージ及び警告メッセージのような異なるメッセージ・タイプがあるが、これらに限定されない。メッセージは、パブリッシャ固有の内部ＩＴコンピュータ・システムから受信された要素、一般的にはＨＬ７メッセージ形式を含むことができる。ターゲット・データの公開を、サブスクライバに送信できるトピック公開メッセージとしてそれぞれのゲートウェイによって行うことができる。トピック公開メッセージは、このトピック公開メッセージの他のデータ要素と異なる（ＸＭＬのような）形式とすることができるコンテンツ定義ヘッダを含むことができる。一般的に、ヘッダを有して送信すべきデータはメッセージ本体に入れられ（エンベロープまたはエンクロージャと称され）、エンベロープ内にあるデータを、通常、任意の業界固有の形式のデータとすることができる。トピック公開メッセージの他のデータ要素を、業界固有の形式及び／またはコードとすることができ、または、すべてのパーティシパント間で定義された通信プロトコル／共通言語に対して定義された標準化メッセージ・コード／コンテンツにマッピングすることができる。例えば、医療ケア・データ共用システムに対して、トピック公開メッセージはコンテンツ定義要約／ヘッダを含み、サブスクライバのデータ・リクエストと関連する臨床データ要素を含むことができる。このデータ要素の（一般的に短い）テキスト要約を生成するようにメッセージ・データ要素を構成することができる。

本発明の実施形態は、特に、コンピュータ・ネットワークを用いて１つ以上を実装できる協調医療ケア・データ共用システムに適することができる。用語「コンピュータ・ネットワーク」は、１つ以上のローカル・エリア・ネットワーク（ＬＡＮ）や広域ネットワーク（ＷＡＮ）を含み、特定の実施形態では、専用イントラネット及び／または（ワールド・ワイド・ウェブまたは「ウェブ」としても既知である）公衆インターネットを含むことができる。本発明の実施形態によって意図される医療ケア・データ共用システムまたは他のデータ共用システムを、状態システム、地域システム、国家的システム及び／または多国籍システムの１つ以上として実装することができる。

用語「医療ケア・データ」及び「臨床データ」は交換可能に用いられ、治療、医薬、薬品または処方用途、実験テスト及び／または結果、診断情報、人口統計情報、物理的な位置、（郵便番号のような）自宅の住所または旅行、あるいは、事象または患者と関連する他の関連データの一部及び／または全部を含む。医療ケア・データを臨床試験、薬物有害事象、（感染の封じ込めまたは警告用のような）疾病監視または他のバイオ監視、及び／または、ケアの質の評価に用いることができる。非医療ケア・システムにも本発明の実施形態を用いることができる。分野固有のデータ用システムを提供するように非医療ケア・システムを構成することができる。従って、説明を明確にするため、本明細書では、主として医療ケア・システムに関して本発明を説明するが、機能、コンポーネント及び／または動作は、医療ケア・システムに限定されない。

また、説明を完全なものにするため、ＩＢＭ（登録商標）特定製品に関して本発明の実施形態を説明できることに留意すべきである。しかし、本発明を実装するのに他の製品及び／または供給業者を用いることができるので、本発明は、ＩＢＭ（登録商標）特定製品に限定されない。

当業者は明らかなように、本発明の実施形態を方法、システム、データ処理システムまたはコンピュータ・プログラム製品として具現化することができる。従って、本発明は、完全にソフトウェアの実施形態、または、ソフトウェア側面及びハードウェア側面を組み合わせた実施形態の形をとることができ、本明細書では、概して、すべてを「回路」または「モジュール」と称する。更に、本発明は、コンピュータ使用可能プログラム・コードを内部で統合させたコンピュータ使用可能ストレージ媒体上にコンピュータ・プログラム製品の形をとることができる。ハード・ディスク、ＣＤ‐ＲＯＭ、光ストレージ装置、インターネットまたはイントラネットをサポートするような送信媒体、または、磁気ストレージ装置または他の電子ストレージ装置を含む任意の適切なコンピュータ可読媒体を用いることができる。

本発明の動作を行うコンピュータ・プログラム・コードを、ＪＡＶＡ（登録商標）、スモールトーク（Ｓｍａｌｌｔａｌｋ）またはＣ＋＋のようなオブジェクト指向プログラミング言語で書くことができる。しかし、本発明の動作を行うコンピュータ・プログラム・コードを、「Ｃ」プログラミング言語のような従来のプロシージャー型プログラミング言語、または、ＶｉｓｕａｌＢａｓｉｃ（登録商標）のような視覚型プログラミング環境でも書くことができる。

特定のプログラム・コードをユーザのコンピュータの１つ以上で全体として実行することができ、独立型ソフトウェア・パッケージとして一部をユーザのコンピュータで実行することができ、一部をユーザのコンピュータで実行し、一部を遠隔コンピュータで実行することができ、または、遠隔コンピュータで全体として実行することができる。後者の場合では、ローカル・エリア・ネットワーク（ＬＡＮ）または、広域ネットワーク（ＷＡＮ）を介して遠隔コンピュータをユーザのコンピュータに接続することができ、または、外部のコンピュータとの接続を（例えば、インターネット・サービス・プロバイダを用いるインターネットを介して）行うことができる。以下で更に説明するように、一般的に、一部のプログラム・コードは各パブリッシャ・ゲートウェイ・コンピュータで実行し、一部のプログラム・コードは（メッセージ・フロー・サーバ及び／またはウェブ・アプリケーションまたは管理サーバのような）ハブ・サーバで実行し、ゲートウェイとハブ・サーバとの間の通信はインターネットを用いる。

以下で、本発明の実施形態による方法、システム、コンピュータ・プログラム製品、及び、データ及び／またはシステム・アーキテクチャ構造のフローチャート及び／またはブロック図を参照して本発明を一部説明する。当然のことながら、フローチャートの各ブロック及び／またはブロックの組み合わせをコンピュータ・プログラム命令によって実装することができる。これらコンピュータ・プログラム命令を汎用コンピュータ、専用コンピュータまたは他のプログラマブル・データ処理装置のプロセッサに提供して当該プロセッサで実行することによって、フローチャート及びブロック図で指定された機能／作用を実装する手段を生成することができる。

これらコンピュータ・プログラム命令をコンピュータ可読メモリまたはストレージ内に格納すると、コンピュータまたは他のプログラマブル・データ処理装置に対して特定の態様で機能するように指図することができ、これによって、コンピュータ可読メモリまたはストレージ内に格納された命令が、フローチャートまたはブロック図で指定された機能／作用を実装する命令手段を含む製品を生成する。

コンピュータ・プログラム命令をコンピュータまたは他のプログラマブル・データ処理装置にロードすると、当該コンピュータまたは他のプログラマブル・データ処理装置で一連の動作ステップが実行され、その結果、当該コンピュータまたは他のプログラマブル装置で実行される命令がフローチャートまたはブロック図で指定された機能／作用を実装するステップを提供するようにコンピュータに実装された処理を生成することになる。

次に、図面に関して本発明の実施形態を説明する。図１には、管理サーバ１１００と通信するメッセージ・フロー・サーバ１００を含む例示的な電子協調データ共用システム１０を示す。図示のように、システムは、（説明を容易にするため、各々を１つとして示す）パーティシパント・パブリッシャ２００及びサブスクライバ３００をも含む。パーティシパントのアクセス及びメッセージ・フロー・サーバ１００との通信を制御して、パブリッシャによって承認された公開情報だけが、パブリッシャ入力に応答するサブスクライバに送信または経路指定されるように管理サーバ１１００を構成することができる。管理サーバ１１００の全部または一部の機能をメッセージ・フロー・サーバ１００に組み入れることができる。しかし、一般的には、管理サーバ１１００はメッセージ・フロー・サーバ１００から分離され、メッセージ・フロー・サーバ１００と電子的に通信する。同様に、２つのサーバとして図示したが、３つ以上のサーバを用いて、メッセージ・フロー・サーバ１００または管理サーバ１１００のいずれか一方の機能を行うことができる。これら機能を単一の物理ノード内で結合できることは、当業者に明らかである。

各パブリッシャ２００は、少なくとも１つのパブリッシャ・ゲートウェイ２００ｇを含むことができる。パブリッシャ・ゲートウェイ２００ｇは、（内部で許可された）公開データをサブスクライバ３００に送信するためにメッセージ・フロー・サーバ１００と通信する。一般的に、パブリッシャ２００は、以下で更に説明するように、（入院及び／または退院のような）提携部門、医師、研究所及び薬局の専用イントラネットを含む。ゲートウェイ２００ｇは、それぞれのパブリッシャ２００から臨床データを収集するように構成されている。幾つかの実施形態では、ゲートウェイ２００ｇは、ストレージ媒体のサイズに基づいて一時的なデータだけを収集するように構成されている。

サブスクライバ３００は、ＰＤＡ、（携帯電話のような）無線通信システム、個人または業務用コンピュータ、ポータブル・コンピュータへの無線メッセージングの１つ以上を含む任意の適切な通信手段によって、（添付ファイルを有する場合とそうでない場合がある）電子メール、ボイス・メール、サブスクライバやサブスクライバ・ゲートウェイ（図６の３００ｇ）と関連するデータベースまたはストレージ媒体への記憶などを介して、参加中のパブリッシャ２００から承認された臨床公開データを受信することができる。サブスクライバ３００が選択できる形式で公開データを臨床トピック公開メッセージとして提供することができる。サブスクライバ３００は、異なる公開データに対して異なる公開形式または宛先をリクエストすることができる。サイトのインストールまたは構成中、宛先を確立することができ、または、開始時に、または変更リクエストに応答して管理サーバ１１００によって達成することができる。幾つかの実施形態では、公開、サブスクリプション、宛先及びデータ形式の条件またはルールを、管理サーバ１１００を用いて制御／確立することができる。

図２に示すように、システム１０は、興味を持ちそうな異なる公開ルールを有することができる異なるデータ・タイプまたはコンテンツのトピック・カタログを含むことができる。電子トピック・カタログ１１０１を、管理サーバ１１００によってサブスクライバ３００及びパブリッシャ２００に表示されるグローバル・トピック・カタログ１１０１とすることができる。サブスクライバ３００は、興味を持つトピックをトピック・カタログ１１０１から選択することができ、または、既存のトピックが所望のコンテンツ、形式及び／またはセキュリティ・レベルを有していない場合、新たなトピックを生成することができる。所望の形式を選択するコンテンツ制約を有するトピックを生成または選択することによって所望のメッセージ形式をリクエストすることができる。すなわち、トピック・カタログ内では、２つの異なるトピックは同じデータ・コンテンツを有するが、所望の出力形式、及び／または、リクエストされたデータをどのように送信するかを指示する通信モードに基づいてトピック・カタログ内のトピック項目が異なることができる。

更に図２に関して、例示的な公開サイクルを示す。サブスクライバ３００は、管理サーバ１１００によってホストされるポータルでシステムへアクセスし、臨床データに対するリクエスト３００Ｒを入力する。管理サーバ１１００は、システム・ポータル（管理サーバ・ウェブ・アプリケーション）を用いて、サブスクライバの公開リクエスト３００Ｒをパブリッシャ２００に転送することができる。一般的に、リクエストは、（電子的にというよりはむしろ）個人による検討に応じて、それぞれのパブリッシャ２００によって承認または否認される。特定のサブスクライバ及びトピックに対するリクエストを一度だけ承認することができる。一般的に、管理サーバ１１００はリクエスト通知を送信し、パブリッシャは管理サーバ・ウェブ・アプリケーションを用いてリクエスト通知に応答する。従って、動作中、リクエスト通知メッセージ及びリクエスト応答（並びに、それに関するサブスクライバ通知）は、管理サーバを介して電子的にサブスクライバ／パブリッシャとの間を移動することができる。

幾つかの特定の実施形態では、トピックの一部または全部に対する公開リクエストを自動的に電子的に承認または否認できる電子フィルタまたは制約を用いて１つ以上のパブリッシャ２００を構成することができる。更に、幾つかの実施形態では、パブリッシャ２００は、（トピックによってもサブスクライバ識別子によっても）継続的に「否認」するサブスクライバを管理サーバ１１００に事前確認することができる。このような状況では、識別した「ブラックリスト」サブスクライバ及び／または「トピック」からの公開に対するリクエストを送信しないように管理サーバ１１００を構成することができる。

パブリッシャ２００が、特定のサブスクライバ３００に対する公開リクエスト３００Ｒを承認した後、トピック（コンテンツ定義）リクエスト３００Ｒを満足させ、ゲートウェイ内に患者に関して収集または集合化される継続中の臨床データのいずれをも、公開情報２００ｍとしてメッセージ・フロー・サーバ１００に公開することができる。公開情報２００ｍは、次に、承認されたリクエスト中のサブスクライバ３００に自動的に転送される。このことを、特定のサブスクライバに対してデータ・コンテンツが定義された特定のトピックに対して承認されたパブリッシャ固有のサブスクリプションと称することができる。それぞれのパブリッシャ２００によって送信された特定のパブリッシャ公開情報に対して承認されたサブスクリプションを有する承認されたサブスクライバが多く存在する。パブリッシャ２００は、トピック・データ２００ｍを有する公開情報をメッセージ・フロー・サーバ１００に送信する場合、複数の承認されたサブスクライバ３００にほぼ同時に「ブロードキャストする」ことができる。サブスクリプションを取り消すため、それぞれのパブリッシャ２００は、管理サーバ１１００のシステム・ポータルへアクセスし、１つ以上のサブスクライバ及び／または特定のトピックへのサブスクリプションの取り消し注文を送信することができる。このことは、（選択された１つ以上のトピック、または全部のトピックに対する）将来の公開情報の送信がパブリッシャ２００からサブスクライバ３００に自動的に送信されないようにする。

図３には、パーティシパントとサーバ１１００，１００との間の通信を、メッセージに基づく通信とすることができることを示す。図示のように、サブスクライバ３００は、特定のトピックの公開リクエスト３００Ｒをトピック・カタログ１１０１から選択（または生成）することができる。このことは、管理サーバ１１００がシステム・ポータルのパブリッシャ画面に表示できるトピックの公開リクエスト３００Ｒの通知を生成する。トピックの公開リクエスト３００Ｒは、興味を持つ関連の臨床データに対して（関連のトピック記述を有する）トピック・タイトルまたは名前を定義し、リクエスト中のサブスクライバを識別する。パブリッシャ２００は、リクエストを承認または否認し、メッセージを管理サーバ１１００に送信することによって公開リクエストに応答する。図示のように、各パブリッシャ２００は承認応答２００Ａを管理サーバ１１００に送信する。承認された場合、管理サーバ１１００は、コマンド及び制御メッセージ１１００ｃをメッセージ・フロー・サーバ１００に送信して、サブスクライバ３００が、承認されたサブスクリプションを有し、承認されたトピックに関して特定のパブリッシャから送信された公開メッセージ２００ｍを受信する資格がサブスクライバ３００に与えられていることをメッセージ・フロー・サーバ１００に通知する。図示のように、サブスクライバ３００からの単一トピック公開リクエストに対して、メッセージ・フロー・サーバ１００は、異なるパブリッシャ２００から臨床データ２００ｍの多くのトピック公開メッセージを受信及び送信することができる。

また、図１０に示すように、サブスクライバとして外部データを受け入れ、パブリッシャとして内部データを送信する両方の機能に対する共通のゲートウェイ２００ｇｃとなるようにパブリッシャ・ゲートウェイ２００ｇの１つ以上をサブスクライバ・ゲートウェイ３００ｇとして構成することができる。他の実施形態では、サブスクライバ３００は、上述したようにサブスクライバ・ゲートウェイ３００ｇを用いずに通信することができ、または、サブスクライバ３００は専用のサブスクライバ・ゲートウェイ３００ｇを有することができる。

図４には、幾つかのサブスクライバ３００がパブリッシャ２００と提携することができることを示す。メッセージ・フロー・サーバ１００は、選択された臨床データをパブリッシャ組織内のサブスクライバ３００（及び外部サブスクライバ）に送信または経路指定することができる。共通のサブスクライバ／パブリッシャ・ゲートウェイ２００ｇｃ（図１０）を用いることによってサブスクライバ・ゲートウェイ３００ｇとしても作用する二重形態の動作／機能を有するように構成されたパブリッシャ・ゲートウェイ２００ｇを介して、または、別個のサブスクライバ・ゲートウェイ３００ｇ（図９）を介してメッセージ・フロー・サーバ１００はサブスクライバ３００と通信することができる。他の実施形態では、メッセージ・フロー・サーバ１００は、前述したように選択された電子通信形態を用いて、臨床データ及び／またはリクエストされた情報をサブスクライバ３００に直接に送信することができる。サブスクライバ３００は、管理者、医師、部門長、または、臨床データを希望する他の機能または人々を含むことができる。前述したように、電子メールと、データベースまたは電子ストレージ媒体へのダウンロードまたは送信と、携帯電話及びＰＤＡ、または、他のポータブル及び／またはパーベイシブ・コンピュータ装置を含む電話または無線通信装置を介するページ、テキストまたはボイス・メッセージングとを含むが、これらに限定されない１つ以上の形式で臨床データをサブスクライバに送信することができる。例えば、臨床医は、特定の症状または処方された薬剤のような選択された基準を示す心臓病患者（または、他の医療ケア部門または専門）に関して通知する臨床データを自身の医療ケア団体から受信するためにサブスクライブすることができる。

この情報を任意の適切な形式で、例えば、より多くのプロンプト通知を可能にし、所望に応じて、任意のケア・フォローアップを可能にするポータブル通信装置に送信することができる。別の例では、管理者は、様々な診断用に定義されたしきい値、または、ケア監視レポートの医療ケア規格に対する他の基準を超える入院経験のあるすべての患者に関する臨床データをリクエストすることができる。更に別の例では、部門長は、例えば、特定の症状、臨床検査及び／または診断に対して特定の薬剤が処方され、または、特定の薬剤が処方されなかった部門長自身の部門内の医師によって治療された患者の通知を含む公開メッセージのトピックへ部門長自身のそれぞれのケア施設からサブスクライブすることができる。このことは、訓練の必要性または患者フォローアップを識別することができる。

システム１０は、多数のパーティシパント・サブスクライバ及びパブリッシャを含むことができる。単一ノードの単一のメッセージ・フロー・サーバ１００として図に示しているが、複数のこのようなサーバ及び／またはノードを冗長及び／またはサービスに応じて適切に用いることができる。

医療ケアの分野に対して、一般的に、データのパブリッシャの一分類は、病院、診療所、介護施設、リハビリ・センター、応急手当施設、研究所、医師のようなケア・プロバイダ及び他のケア・プロバイダであり、特に、これらプロバイダは、臨床データを規制機関にリポートする義務がある。パブリッシャの他の分類は、独立研究所、薬剤給付管理会社及び他の臨床リポジトリを含むことができる。

代表的なサブスクライバは、連邦、州及び／または（パブリッシャ・サイトに対してローカルである）地方の規制及び／または政府機関、（パブリッシャとすることもできる）公衆衛生機関、診療所または病院、保険業者、製薬会社、調査員、公衆衛生及び／または政策団体／機関などを含む。国家医療情報基盤（ＮＨＩＩ）及び／または（１つ以上の）地域または州医療情報組織の一部としてシステム１０を用いることができる。

幾つかの実施形態では、オブザーバと称することができるパーティシパントの第３分類が任意に存在しうる。オブザーバは、確立された標準の監視プロトコルを有することができ、これによって、オブザーバは、特定またはすべてのパブリッシャ２００及び／または特定またはすべてのサブスクライバ３００に送信され、及び／または、そこから送信された臨床データ、データ・メッセージ及び／またはメッセージの要約のコピーを獲得することができる。更に、ホスティング・サービス（図示せず）に対してパーティシパントの第４の管理分類が存在しうる。

インターネットに基づく分野に対して、ＳＳＬ（セキュア・ソケット層）及び高レベルの暗号化を用いて動作するようにメッセージ・フロー・サーバ１００、サブスクライバ３００、パブリッシャ２００及び／または関連のゲートウェイ２００ｇ，３００ｇを構成することができる。システムのデータを処理する一連の属性を有する「組織」にユーザまたはパーティシパントを割り当てることができる。システム１０は、ユーザの役割を定義し、（サインオンの際のような）ウェブ・ポータルで識別される特定レベルの権限を提供するユーザ登録を有する。パブリッシャ２００及びサブスクライバ３００は、ウェブ・ポータル１０ｐ（図９，１１）及び管理サーバ１１００を介してハブ１０ｈと通信して、管理サーバ１１００によって制御されるメッセージ・フロー・サーバ１００を介して１つ以上のパブリッシャ２００からトピックに関する臨床データを、興味を持つサブスクライバ３００に公開する。

図５には、本発明の実施形態に従って管理サーバ１１００及びメッセージ・フロー・サーバ１００を用いてデータの協調共用を容易にすることができる動作を示す。図示のように、選択されたトピックを公開するためのリクエストを管理サーバによって受信する（ブロック１０５）。管理サーバは、参加中のパブリッシャから（例えば、任意のパブリッシャ、すべてのパブリッシャ、または、選択されたパブリッシャだけから）データを受信することをサブスクライバが許可されているかどうかを評価することができる（ブロック１１０）。公開リクエストをパブリッシャに転送することができ、これによって、各パブリッシャは、特定のトピックまたはサブスクライバに対して公開リクエストを承認または否認することができる（ブロック１１５）。特定の実施形態では、特定のサブスクライバまたはトピックに対して特定のパブリッシャから「ブラックリスト」または継続的な命令が存在するかどうかを確かめるため、管理サーバによってサブスクライバのトピック・リクエストを事前選別することができる。パブリッシャが、特定のサブスクライバから特定のトピックに対する公開リクエストを承認した場合、許可された継続的なサブスクリプション注文を確立することができ、これによって、承認したパブリッシャから、メッセージ・フロー・サーバ１００を介して、許可されたリクエスト中のサブスクライバに臨床データを自動的に送信させることができる（ブロック１１６）。管理サーバ１１００は、サブスクリプション・メッセージをメッセージ・フロー・サーバに送信してサブスクリプションを開始し、将来の事象またはトピックに関するデータに対する公開をサブスクライバからリクエストするリクエスタを必要とせずにパブリッシャからメッセージ・フロー・サーバを介してサブスクライバに臨床データを経路指定させることができる。

図６には、パブリッシャ２００によって行うことができる例示的な動作を示す。図示のように、識別されたサブスクライバ及びトピックに対して公開するためのリクエストの通知をパブリッシャ・ポータル（管理サーバアプリケーション）で受信する（ブロック２０１）。通知を任意の表示画面上に位置付けることができるが、一般的には、パブリッシャの「インボックス（受信箱）」内である。パブリッシャは、それぞれのサブスクライバに対する公開リクエスト及び／またはトピック・リクエストを承認するか否認するかを各々決定することができる。パブリッシャは通知を検討し、パブリッシャ固有の設定、基準、ルール及び／または制約に基づく承認または否認をウェブ・アプリケーション・ポータルに応答することができる（ブロック２０２）。リクエストに対するパブリッシャの承認及び／または否認をウェブ・アプリケーション・ポータル上で選択し、通知として管理サーバからサブスクライバに送信することができる。リクエスト中のサブスクライバによってサブスクライバ・ポータルの「インボックス」内に通知を表示することができる。

パブリッシャ・ゲートウェイは、患者の電子臨床データ・メッセージ・レコードを形成するために集合化され、標準化メッセージ・データ形式、一般的にはオープン・スタンダード・メッセージ形式に構成された電子患者データ・レコードのメッセージ待ち行列データベースと通信することができる。パブリッシャ・ゲートウェイは、承認された公開リクエストに対する選択されたトピックに一致する患者レコード・データのメッセージを電子的に検索し、抽出することができる（ブロック２０３）。パブリッシャの抽出された患者データ・メッセージをメッセージ・フロー・サーバに送信することができる（ブロック２０４）。幾つかの実施形態では、送信前に、個人識別子のような特定の情報を除去するために患者データ・メッセージを自動的及び／または電子的にフィルタリングすることができる（ブロック２０５）。（ＨＩＰＡＡプライバシー・ルールなどのようなビジネスまたは規制ルールを準拠するため、）パブリッシャのルールに基づいて任意選択のフィルタリングを用いることができ、または、データをリクエストしているサブスクライバの識別子、及び／または、公開のためにリクエストされたトピックに基づくことができる。

ストレージ媒体のサイズに応じて患者データ・メッセージの有限期間、一般的には約３０〜１２０日の間、より一般的には約３０日を含むようにメッセージ待ち行列データベースを構成することができる。所望に応じて、古いメッセージ・データを消去するか、または、履歴データによるトレンド分析の場合のような次の使用のために１つ以上のパブリッシャ制御履歴データベースに転送することができる。周期的に消去する実施形態（一般的には、先入れ先出し（ＦＩＦＯ）に基づく消去プロトコル）では、システム１０は、比較的現在の臨床データを提供することができる一時的なシステムとして作用する。（最近の３０〜６０日以内のように最近受信した、「使用中」、または、最近用いられたとマークを付けなかった）古いか、または未使用のデータが、（一般的には、ハードウェア・ストレージ限度によって限定されている）キャッシュ期間の終了を自動的に電子的に「減衰させる」ことができるようにデータをキャッシュするようにパブリッシャ２００を構成することができる。サブスクライバ３００は、それら自体の履歴データベースまたはシステムにメッセージを格納またはキャッシュするリポジトリを有することができる。従って、幾つかの実施形態では、患者データの中央リポジトリが存在しない。また、パブリッシャ・ゲートウェイ２００ｇは、以下に更に説明するように、より完全にトピックに応答するために追加の患者データ（研究所、薬局などからの異なる入力の集合体）を受信するまで、（１つ以上の）抽出された患者データの送信を一時的に中断することができるメッセージ・キャッシュのような他の回路またはモジュールを有することができる。

サブスクライバからの公開リクエストを、パブリッシャから公開された患者データ・メッセージと同じ標準化メッセージ形式（例えば、ＨＬ７）とすることができる。パブリッシャ・データ・メッセージの公開を、事象に基づく動作とすることができ、これによって、サブスクライバの公開リクエストに対して承認されたサブスクリプション・トピックのデータ・コンテンツを満足すると患者レコードが識別された時点からほぼリアル・タイム（一般的には１時間未満、幾つかの実施形態では約１０分未満）で公開情報を生成することができる。他の実施形態では、定義された所望の間隔で、または、原位置で適用された評価サイクルでデータ・レコードの評価を実行することができる。

図７及び図８には、本発明の幾つかの実施形態に従って動作する装置内に含めることができる例示的なデータ処理システムまたはデータベース環境を示す。図７に示すように、ハブ、及び／または、ウェブ・アプリケーション（管理サーバ）及び／またはメッセージ・フロー・サーバの動作を行う、または指図するのに用いることができるデータ処理システムは、プロセッサ１３８、メモリ１３６及び入出力回路１４６を含む。例えば、パーソナル・コンピュータ、サーバ、ルータなどの１つ以上にデータ処理システムを組み入れることができる。プロセッサ１３８はアドレス／データ・バス１４８を介してメモリ１３６と通信し、アドレス／データ・バス１４９を介して入出力回路１４６と通信する。例えばインターネット・プロトコル（ＩＰ）接続を用いてメモリ（メモリ及び／またはストレージ媒体）１３６と別のコンピュータ・システムまたはネットワークとの間で情報を転送するのに入出力回路１４６を用いることができる。これらコンポーネントを、本明細書で説明する動作をするように構成できる多くの従来のデータ処理システムで用いられるコンポーネントのような従来のコンポーネントとすることができる。

同様に、図８には、パブリッシャ・ゲートウェイの動作を行う、及び／または指図するのに用いることができ、プロセッサ２３８、メモリ２３６及び入出力回路２４６を含むデータ処理システムを示す。例えば、パーソナル・コンピュータ、サーバ、ルータなどの１つ以上にデータ処理システムを組み入れることができる。プロセッサ２３８はアドレス／データ・バス２４８を介してメモリ２３６と通信し、アドレス／データ・バス２４９を介して入出力回路２４６と通信する。例えばインターネット・プロトコル（ＩＰ）接続を用いてメモリ（メモリ及び／またはストレージ媒体）２３６と別のコンピュータ・システムまたはネットワークとの間で情報を転送するのに入出力回路２４６を用いることができる。これらコンポーネントを、本明細書で説明する動作をするように構成できる多くの従来のデータ処理システムで用いられるコンポーネントのような従来のコンポーネントとすることができる。

特に、プロセッサ１３８，２３８を、市販または特注のマイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサなどとすることができる。メモリ１３６，２３６は、本発明の実施形態に従って用いられる機能回路またはモジュールを実装するのに用いられるソフトウェア及びデータを含む任意のメモリ装置及び／またはストレージ媒体を含むことができる。メモリ１３６，２３６は、キャッシュ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ，フラッシュ・メモリ、ＳＲＡＭ、ＤＲＡＭ及び磁気ディスクを含むことができるが、これらに限定されない。本発明の幾つかの実施形態では、メモリ１３６，２３６を、コンテント・アドレッサブル・メモリ（ＣＡＭ）とすることができる。

図７及び図８に更に示すように、メモリ（及び／またはストレージ媒体）１３６，２３６は、データ処理システムに用いられる幾つかの分類のソフトウェア及びデータ、すなわち、オペレーティング・システム１５２，２５２、アプリケーション・プログラム１５４，２５４、入出力装置ドライバ１５８，２５８及びデータ１５６，２５６を含むことができる。当業者は明らかなように、オペレーティング・システム１５２，２５２を、ＩＢＭ（登録商標）ＯＳ／２（登録商標）、ＡＩＸ（登録商標）またはｚＯＳ（登録商標）オペレーティング・システム、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）９５、Ｗｉｎｄｏｗｓ（登録商標）９８、Ｗｉｎｄｏｗｓ（登録商標）２０００またはＷｉｎｄｏｗｓ（登録商標）ＸＰオペレーティング・システム、Ｕｎｉｘ（登録商標）またはＬｉｎｕｘ（登録商標）のようなデータ処理システムと用いるのに適する任意のオペレーティング・システムとすることができる。ＩＢＭ（登録商標）、ＯＳ／２（登録商標）、ＡＩＸ（登録商標）またはｚＯＳ（登録商標）は、米国または他国あるいはその両方にあるインターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標であり、Ｌｉｎｕｘ（登録商標）は、米国または他国あるいはその両方にあるリーナス・トーバルズの登録商標である。Ｍｉｃｒｏｓｏｆｔ（登録商標）及びＷｉｎｄｏｗｓ（登録商標）は、米国または他国あるいはその両方にあるマイクロソフト・コーポレーションの登録商標である。一般的に、入出力装置ドライバ１５８，２５８は、入出力回路１４６，２４６及び特定のメモリ１３６，２３６コンポーネントのような装置と通信するため、オペレーティング・システム１５２，２５２を介してアプリケーション・プログラム１５４，２５４によってアクセスされるソフトウェア・ルーチンを含む。アプリケーション・プログラム１５４，２５４は、本発明の幾つかの実施形態による回路及びモジュールの様々な機能を実装する例示的なプログラムである。最後に、データ１５６，２５６は、アプリケーション・プログラム１５４，２５４、オペレーティング・システム１５２，２５２、入出力装置ドライバ１５８，２５８、及び、メモリ１３６，２３６内に存在しうる他のソフトウェア・プログラムによって用いられる静的及び動的データを表す。

図７に関して、データ１５６は、本明細書で更に説明するように、本発明の幾つかの実施形態に従ってアプリケーション・プログラム１５４の回路及びモジュールによって用いる異なるサブスクライバまたはトピックからデータの公開リクエストを受信するパブリッシャの意思を定義するパーティシパントまたはユーザ・プロファイル・タイプ・データ１２６を含むことができる。例えば、提携しているサブスクライバの病院または診療所は、提携していないエンティティに比べて、関連または提携しているパブリッシャの各々からレコードを受信するため、より高いレベルの資格を有することができる。他の例では、（政府機関のような）提携していないが、承認されたサブスクライバも、高レベルの資格を有することができる。

図８に関して、データ２５６は電子患者データ・レコード２２６を含むことができる。患者データ・レコードは、本明細書で更に説明するように、本発明の幾つかの実施形態に従ってアプリケーション・プログラム２５４の回路及びモジュールによって用いる患者データ・メッセージにマッピングされ解析された患者データ・レコードを含むことができる。幾つかの実施形態では、パブリッシャによって保持された患者データ・レコードは、例えば、名（ファースト・ネーム）、姓、社会保障番号、（ソース・パブリッシャへの追跡可能性を提供し、患者への間接的な追跡可能性を提供しながら、患者固有のプライバシーを提供するのに用いられる）不透明な識別子、性別、生年月日、住所、電話番号、出生地、血液型、年齢、身長、体重、目の色、髪の色、人種及び／または一塩基変異多型（ＳＮＰ）のような遺伝子署名、実験及び／またはテスト及び関連結果、ＯＴＣ（店頭販売）または（現在の、過去の、または、現在の事象に対して処方された）処方薬剤、予防接種、過去の、現在の、または処方されたセラピー、診断、退院及び入院日、症状、人口統計及び地理情報（自宅、居住及び／または勤め先の郵便番号、市、州、最近の旅行コメントまたは観察意見）、治療医師、職場または他の潜在的に毒性または有害な汚染などを含むことができる。前述したように、幾つかの公開目的に対して、メッセージ・フロー・サーバに（または、他の幾つかの実施形態では、メッセージ・フロー・サーバによって）送信する前に患者の個人識別子データをメッセージから除去して、ローカル・パブリッシャ及び／または規制ルールに準拠することができる。当然のことながら、患者データのこのリストは、例示的な目的のためだけに提供され、本発明の実施形態は、本明細書で設定される属性タイプに限定されない。

図７に更に示すように、本発明の幾つかの実施形態によれば、アプリケーション・プログラム１５４は、ユーザ／パーティシパント登録モジュール１２０、パブリッシャ／サブスクライバ通信プロトコル・インターフェース・モジュール１２４、及び／または、サブスクライバ・アクセス可能及び選択可能電子トピック・カタログ・モジュール１２５の１つ以上を含む。ローカル・サーバ（またはプロセッサ）及び／またはデータベース、または、遠隔サーバ（またはプロセッサ）及び／またはデータベース、または、ローカル及び遠隔データベース及び／またはサーバの組み合わせにアプリケーション・プログラム１２０，１２４，１２５を位置付けることができる。

図８に更に示すように、本発明の幾つかの実施形態によれば、アプリケーション・プログラム２５４は、患者データを患者メッセージ形式に変換、マッピング及び／または解析することができるメッセージ形式標準化モジュール２２０、パブリッシャ・メッセージ・フロー・サーバ・インターフェース・モジュール２２４、及び／または、それぞれのパブリッシャに患者データの公開ルールを定義させることができる公開ルールまたは制約モジュール２３４の１つ以上を含む。ローカル・サーバ（またはプロセッサ）及び／またはデータベース、または、遠隔サーバ（またはプロセッサ）及び／またはデータベースにアプリケーション・プログラム２２０，２２４，２３４を位置付けることができる。

図７及び図８のそれぞれのアプリケーション・プログラム１２０，１２４，１２５，２２０，２２４，２３４に関して本発明を示すが、当業者は明らかなように、他の構成も本発明の範囲内にある。例えば、アプリケーション・プログラム１５４，２５４であるというよりは、これら回路及びモジュールを、オペレーティング・システム１５２，２５２またはデータ処理システムの他のこのような論理分割にも組み入れることができる。更に、図７及び図８のアプリケーション・プログラム１２０，１２４，１２５，２２０，２２４，２３４を単一のデータ処理システム内に示すが、当業者は明らかなように、このような機能を１つ以上のデータ処理システムにわたって分散させることができる。従って、本発明を、図７及び図８に示す構成に限定されるものと解釈すべきではないが、他の配置及び／またはデータ処理システム間の機能分割によって提供することができる。例えば、様々な回路及びモジュールを有するとして図７及び図８を示すが、これら回路またはモジュールの１つ以上を、本発明の範囲から逸脱することなく結合させることができる。

図９には、本発明の幾つかの実施形態による動作及び装置のための例示的な環境を示す。図９に示すように、メッセージ・フロー・サーバ１００はハブ環境１０ｈの一部を備えることができる。概説するならば、ハブ環境１０ｈは、パブリッシャに対してサブスクライバへのコンテンツに基づく経路指定を提供するように構成されている。前述したように、許可されたサブスクライバだけにパブリッシャからメッセージを転送して、承認されたコンテンツに基づくメッセージを、公開固有の承認されたサブスクライバに経路指定するようにもハブ環境１０ｈを構成することができる。このシステムは、受信したいと思う（サブスクライバ・ビュー）、及び／または、パーティシパントが提供する意思がある（パブリッシャ・ビュー）臨床情報のコンテンツ、形式、及び／または、タイプに対する宛先をパーティシパントに識別させることができる。

図９に示すように、ハブ環境１０ｈは、メッセージ・フロー・サーバ１００と通信する管理サーバ１１００を含むことができる。ハブ環境１０ｈは、任意にＡＧＰＩ（匿名グローバル患者識別子）サーバ１１０９をも含むことができる。Ｊ２ＥＥ装置としてＡＧＰＩを構成することができる。当業者にとって既知であるように、Ｊ２ＥＥは、コンポーネントに基づく多層エンタープライズ・アプリケーションを開発するＪａｖａ（登録商標）２プラットフォーム・エンタープライズ・エディション（Ｊ２ＥＥ）規格である（Ｊａｖａ（登録商標）は、米国または他国あるいはその両方にあるサン・マイクロシステムズの登録商標である）。当然のことながら、図９に示すメッセージ・サーバ１００及び／または管理サーバ１１００は、図７を参照して前述したデータ処理システムまたはデータベース環境の全部または一部を含むことができる。幾つかの実施形態では、ウェブ・ベースの管理アプリケーションとも称することができるウェブ・ベースの管理サーバ１１００をＪ２ＥＥ装置としても構成することができる。ハブ環境１０ｈは、ＷｅｂＳｐｈｅｒｅ（登録商標）アプリケーション・サーバ、ＷｅｂＳｐｈｅｒｅ（登録商標）ＭＱ、Ｔｉｖｏｌｉ（登録商標）ディレクトリ・サーバ（ＬＤＡＰ）または「Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ」、及び、ＤＢ２（登録商標）ＵＤＢ（リレーショナル・データベース管理システム（ＲＤＢＭＳ）であって「ＩＢＭ（登録商標）のｅＳｅｒｖｅｒ（登録商標）ｉＳｅｒｖｅｒ（登録商標）のオンデマンド機能を利用するＤＢ２（登録商標）ユニバーサル・データベース」）のようなＩＢＭ（登録商標）のＷｅｂＳｐｈｅｒｅ（登録商標）製品一式を通して利用できる製品のような他の機構をも含むことができる。ＷｅｂＳｐｈｅｒｅ（登録商標）、Ｔｉｖｏｌｉ（登録商標）、ＤＢ２（登録商標）、ｅＳｅｒｖｅｒ（登録商標）及びｉＳｅｒｖｅｒ（登録商標）は、米国または他国あるいはその両方にあるインターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標である。

図９には、ハブ環境１０ｈが、複数のパブリッシャ２００_１，２００_２，２００_ｎ及びサブスクライバ３００_１，３００_２，３００_ｎと通信することをも示す。サブスクライバ３００_１から選択された特定のトピックに対する公開リクエストに対して、管理サーバ１１００は、選択されたトピックに対する公開リクエストの通知を（２つのパブリッシャ２００_１，２００_２として示す）１つ以上のパブリッシャに送信し、これらパブリッシャから応答を受信する。応答を、リクエスト中のサブスクライバへの公開に対して承認されたメッセージ、または、リクエストの否認とすることができる。応答を、特定のトピックに対して以前に（または継続的に）承認された公開の取り消しともすることができる。メッセージ・フロー・サーバ１００は、次に、承認されたすべての公開メッセージをそれぞれのパブリッシャからリクエスト中のサブスクライバ３００_１に送信する。管理サーバ１１００は、パーティシパント、及び、許可または参加のレベルを事前選別して、サブスクライバのリクエストを、潜在的に意図するパブリッシャなどだけに送信することができる。パブリッシャとサブスクライバとの間で、ＳＳＬ（セキュア・ソケット層）チャネル、暗号化及び／または他の安全なデータ送信手段を用いるインターネットを介してメッセージを送信することができる。ネットワーク・システムは、少なくとも１つのドメイン・ファイアウォール１２００を含むことができる。一般に、病院ハブ及びサブスクライバ・ファイアウォール１２００（図１２）を含む２つ以上のファイアウォールが用いられる。

図９に関して、更に、特定の患者または他の所望の基準に相互に関連できる電子データ・レコードを収集、集合化及び／または受け入れるため、それぞれのパブリッシャ・パーティシパントの団体コンピュータ・システム及び／または情報技術システムに接続するようにパブリッシャ・ゲートウェイ２００ｇ_１，２００ｇ_２，２００ｇ_ｎを構成することができる。（ａ）患者データ・メッセージを公開または通知する前に、及び／または、患者データを標準のメッセージ形式で患者データ・レコード・メッセージにマッピングする前に、関連データを患者データ・レコードに集合化及び／またはコンパイルするため、所望の期間中、患者データをキャッシュし、（ｂ）（匿名及び／またはＨＩＰＡＡプライバシー準拠データを提供するため、）公開前に患者レコードから特定の患者情報を匿名化または除去し、（ｃ）ローカル・データを標準化形式に変更するため、メッセージ、事象及び／または（論理観察識別子名及びコード分類「ＬＯＩＮＣ」、疾患分類コードの国際分類ＩＣＤ９、ＩＣＤ１０などのような）一般に受け入れられる医療参照コードをマッピング及び／または正規化し、（ｄ）ＨＬ７及びＸＭＬデータ・タイプを解析するようなメッセージ解析を実行し、（ｅ）局所ビジネスまたはデータ使用／公開ルールを適用するようにもパブリッシャ・ゲートウェイ２００ｇ_１，２００ｇ_２，２００ｇ_ｎを構成することができる。

幾つかの実施形態では、パブリッシャ・ゲートウェイ２００ｇは、不適切に形成されたＨＬ７メッセージを有する電子患者データ・レコードを電子的に訂正し、電子患者データ・レコードの標準外ＨＬ７観察メッセージを標準ＨＬ７メッセージに変換し、標準外ＨＬ７観察メッセージから標準の薬局注文メッセージに薬品注文を変換し、入院原因及び退院処置のローカル・パブリッシャ・コードをＨＬ７奨励コード及び／またはデータ・フィールドにマッピングし、実験観察のローカル・コードを、実験テスト／結果の一般に受け入れられる業界規格（ＬＯＩＮＣ）にマッピングするように構成されている。

サブスクライバ・ゲートウェイ３００ｇは、トピックのデータ・リクエストに応答して受信したメッセージの公開情報を格納することができるリポジトリ・データベース（または、特定のサブスクライバまたはオブザーバに対してメッセージ及び／または警告のリポジトリ）を含み、または、これと通信することができる。

特定の実施形態では、ゲートウェイ２００ｇ，３００ｇは、Ｊａｖａ（登録商標）及び／またはＩＢＭ（登録商標）ＷＢＩコード、または他の適切なプログラム・コードを用いることができる。パブリッシャ・ゲートウェイ２００ｇは、患者データ・メッセージから個人識別子（名前、社会保障番号など）を除去するＸＭＬに基づく患者「匿名化ルーチン」を含むことができる。また、パブリッシャ・ゲートウェイ２００ｇは、患者データ・レコードがＨＬ７メッセージからＣＤＡ ＸＭＬ文書に変換される文書変換ルーチンと、ＨＬ７解析（カナダのトロントに位置するｉＮｎｔｅｒｆａｃｅｗａｒｅによるカメレオンを用いて行うことができるＨＬ７メッセージング・ツールキット）と、ＷｅｂＳｐｈｅｒｅ（登録商標）ビジネス・インテグレーション製品、ＤＢ２（登録商標）ＵＤＢ、及び、ＷＢＩコネクタへのＨＬ７ ＴＣＰ／ＩＰソケットとを含むことができる。

図１０には、パブリッシャ・ゲートウェイ２００ｇ及びサブスクライバ・ゲートウェイ３００ｇを、両方の機能を実装する共通のゲートウェイ２００ｇｃとして提供できることを示す。図１０には、ＡＧＰＩ（匿名グローバル患者登録または識別子）サーバ１１０９が、共通の患者登録サービスをそれぞれのパブリッシャ・ゲートウェイ２００ｇに提供するようにパブリッシャ・ゲートウェイ２００ｇと直接に通信できることをも示す。

図１１には、協調データ・ネットワーク・システム１０の例示的なアーキテクチャを示す。システム１０は、メッセージ・フロー・サーバ１００及びパーティシパント・ネットワーク・ファイアウォール１２００を有するインターネット・ポータルまたはハブ１０ｈを含む。図示のように、各パブリッシャ・サイト２００ｓは、（退院または入院の診断を提供することができる）病院会計システム２０６、（注文された実験またはテスト結果あるいはテスト／評価を提供することができる）研究所２０７、（薬品注文の入力のための）薬局２０８及び他の関連データ収集入力部を含むがこれらに限定されない様々なリンクされた（内部及び／または外部）サービス・プロバイダまたはデータ収集ステーションと通信する少なくとも１つのパブリッシャ・ゲートウェイ２００ｇを含むことができる。パブリッシャ・ゲートウェイ２００ｇが選択、承認及び／または定義するパブリッシャ固有のビジネス・ルールまたは制約に基づいて医療ケア・データ要素をフィルタリングし、リンクしマッピングするようにパブリッシャ・ゲートウェイ２００ｇを構成することができる。

ビジネス・ルールの一例として、すべての奨励テストまたは手続きが診断に基づいて完了したかどうかを確かめるために患者レコードが検査されるということが挙げられる。また、システムは、特定の疾病または機能障害を有すると診断された患者を識別し、フォローアップ実験結果を相互に関連付けて診断を確認することができる。これら検査またはルールは患者ケアを改善させ、適切な治療を容易にし、及び／または、疾患の大発生を管理するのに役立つ。幾つかの実施形態では、ＩＢＭ（登録商標）によるＷｅｂＳｐｈｅｒｅ（登録商標）ＭＱを用いて患者レコードの結果またはデータ要約を組織内で迅速かつ確実に共用することができる。遅延されエラーが発生しやすい従来のチャート・プルよりも優れ、迅速に、かつ、エラーを減少させて、またはエラーなしに結果を追跡するのにシステム１０を用いることができる。このタイプの自動報告は、監査計画または要件への準拠を容易にすることができる。

ゲートウェイ２００ｇは警告レセプタ２０９と通信することができ、これによって、ゲートウェイ２００ｇにより収集及び／または提供されたデータを電子的に監視して、特定の異常な状態が識別されると、内部当局及び／または管理者に警告することができる。警告レセプタ２０９を、ゲートウェイ２００ｇと通信するパブリッシャ２００の別個のモジュール及び／またはデータベースとすることができ、または、ゲートウェイ２００ｇ内に統合することができる。例えば、警告レセプタ２０９は、特定の状態のために入院した患者の数の増加を検出し、及び／または、食中毒の診断、１人以上の患者における炭疽菌汚染または脊髄膜炎の識別、バイオ・テロリズムの発覚、（中毒を起こすか、または、死亡の危険性が高いと識別されるような）特定の薬品または薬品タイプの処方の増大、薬物有害事象などのような起こりうる蔓延する健康上の懸念を識別することができる

図１１には、サブスクライバ（組織またはサイト）３００が、上質及び／または有害事象の監視を提供するか、または、臨床データを分析し、サブスクライバ・ゲートウェイ３００ｇに接続することができる（ローカルとすることができ、または、互いに離間することができる）１つ以上の提携エンティティを含むことができることをも示す。図示のように、サブスクライバ３００は、（１つ以上の）ネットワーク・オフィス３０１、（１つ以上の）臨床ディレクタ３０２及び感染対策公的組織／エンティティ３０３を含むことができる。サブスクライバは、（リクエストされたデータのパラメータを定義する）トピックを生成し、（トピックへのそれぞれのサブスクライバの特定の興味を定義する）トピックをサブスクライブ及び／または選択することができる。

前述したように、サブスクライバ・サイト及びパブリッシャ２００を、パブリッシャまたはサブスクライバ・モードで作用できる共通のゲートウェイ２００ｇｃ（図１０）を用いる共通のパブリッシャ及びサブスクライバ・サイトとすることができる。警告レセプタ２０９、及び、パブリッシャ・ゲートウェイ２００ｇ及び／またはサブスクライバ３００を用いて患者のケア処置及びケアの質を監視することができ、図１２に示すようなリポートを生成するのに用いることができる。

図１２は、例示的な協調医療ケア・データ共用システム１０での異なるコンポーネントの概略図である。前述したように、システム１０は、パーティシパントのアクセスを制御するウェブ・ポータル１０ｐを含むことができ、ウェブ・ポータル１０ｐは、メッセージ・トラフィックを制御するメッセージ・フロー・サーバ１００と通信する。ウェブ・ポータル１０ｐを、単一の連合またはグローバル・ポータル、または、外部ネットワークまたは選択されたネットワークの分離されたポータルのような幾つかのポータルのリンクされたシステムなどとすることができる。システム１０は、パーティシパントにデータ共用ルールを定義させ、共用するデータを選択させ、誰と共用するかを決定させ、選択されたトピックに対して監視させ、警告させ、通知させ、レポートさせ、会計活動を提供させることができる。

図１３には、本発明の幾つかの実施形態による例示的なウェブ・ベースのデータ共用システム１０の更に詳細なアーキテクチャを示す。図示のように、ハブ１０ｈは、中央管理アプリケーションを提供するサーバ１１００を備える。セッション管理、追跡及びロギング・システム管理、作業負荷管理、及び、メンバー・サービスを提供するのに管理サーバ１１００を構成することができる。管理サーバ１１００は、トピック・カタログ１１０１、パーティシパント（サブスクライバ及びパブリッシャ）プロファイル１１０２、セキュリティ・ディレクトリ１１０３、公開または経路指定セキュリティ・ルール１１０４及び通知１１０５を含む複数のデータベースを含むか、または、これらと通信することができる。管理サーバ１１００は、例えば、ＩＢＭ（登録商標）ＷｅｂＳｐｈｅｒｅ（登録商標）アプリケーション・サーバ、Ｔｉｖｏｌｉ（登録商標）ディレクトリ・サーバ（ＬＤＡＰ）、ＡＧＰＩ（匿名グローバル患者登録または識別子）サーバ１１０９、ＤＢ２サーバ及びＳＭＴＰ（簡易メール転送プロトコル）サーバ１１１０を備えることができるＷＡＳ（ウェブ・アプリケーション・サーバ）であるがこれに限定されないウェブ・システム内に統合された幾つかのサブ・サーバを含むことができる。本明細書では「サーバ」と記述したが、他の適切なコンピュータ構成を用いることができることに留意すべきである。

トピック・カタログ・データベース１１０１（図１３）を、図１８に示すように（トピック名及びトピック記述を含むことができる）サブスクライバによって選択可能なトピックの電子カタログまたはリストとすることができる。トピック・カタログを（完全なリストが提供される場合のような）アルファベット順に表示することができ、または、この場合も図１８に示すように、キー作業入力を用いて検索可能とすることができる。サブスクライバが、カタログにないトピックに関するデータをリクエストしたい場合、サブスクライバは、「新たな」トピック項目としてリクエストを入力することができる。「新たな」トピック項目を保存することができ、公開ルールを満足するかどうかを確かめるために検討することができる。トピックがカタログ内にある場合、サブスクライバはこのトピックに関してデータをリクエストすることができるが、ハブ１０ｈ（管理サーバ１１００またはメッセージ・フロー・サーバ１００）は、リクエストを送信して新たな（または既存の）トピックに関する医療ケア・データを公開するパブリッシャを、以前確立したサブスクライバ及び／またはパブリッシャ参加ルールなどに基づいて（もしあれば）選択することができる。

図１７及び図１９に示すような通知の要約を提供するのに通知データベース１１０５を用いることができる。これらの図面に示すように、パブリッシャは、日付、時間、タイプ、送信元及び件名を含む通知の詳細を表示することができる。また、パブリッシャは、リクエスト中のサブスクライバの識別子／名前、及び、リクエストされたトピックを提供する公開リクエストを検討することができる。図１７及び図１９に示す画面ビューをパブリッシャ「ホーム」画面ビューとして構成することができる。

再び図１３に関して、興味を持つ選択されたトピックを参加中のパブリッシャから参加中の（承認された）サブスクライバへ動的に公開及び／またはサブスクライブし、公開／サブスクライブ通信プロトコルを実装するようにメッセージ・フロー・サーバ１００を構成することができる。メッセージ・フロー・サーバ１００は、トピック及び／またはコンテンツに基づく経路指定を提供し、選択された情報に対するリクエストに動的に応答してサブスクリプションを登録し、トピック名前空間にわたるアクセス制御を提供できるＷｅｂＳｐｈｅｒｅ（登録商標）ＷＢＩ（Ｗｅｂｓｐｈｅｒｅ（登録商標）ビジネス・インテグレーション）メッセージ・ブローカのようなメッセージ・ブローカを備えることができる。メッセージ・フロー・サーバ１００は、例えば、構成マネージャ１００１、ユーザ名サーバ１００２、メッセージ・ブローカ１００３、待ち行列マネージャ１００４を含むがこれらに限定されない１つ以上のサブ・サーバ、クライアントまたはマネージャを含むことができる。メッセージ・フロー・サーバ１００は、例えば、メッセージ・フロー・データベース１００５、メタデータ・ディクショナリ１００６、公開及びサブスクライバ・リスト１００７、ユーザ・ノード・サーバ１００８及びメッセージ待ち行列データベース１００９を含むがこれらに限定されない幾つかのデータベースまたはサーバ、クライアントなどを備え、及び／または、これらと通信することができる。

この場合も図１３に示すように、パブリッシャ・ポータル・サイト２００ｓに現れるウェブ・アプリケーション機能を用いて管理サーバ１１００を構成することができる。サーバ１１００はＷＢＩサーバ・エクスプレスを備えることができ、及び／または、サーバ１１００をＷＢＩサーバ・エクスプレスとして構成することができる。ユーザにパーティシパントとして登録させ、ＡＣＬ（アクセス制御リスト）を管理させ、（汎用ＩＤまたはパスワード・アクセスを用いて）ＵＩＤ／ＰＷＤをログオンさせ、ログオフさせ、プロファイル設定を定義させ、検索させ、公開リクエストを承認させ、データに対する（１つ以上の）リクエストを受信させ、通知事象を生成させるのにウェブ・アプリケーションを用いることができる。

病院、または、薬局、研究所及びＡＤＴ（入院、退院及び移転）のような他のパブリッシャＩＴ（情報技術）環境またはプラットフォームなどと統合するようにパブリッシャ・ゲートウェイ２００ｇを構成することができる。また、ＨＬ７／マッピング／変換を解析し、ＨＬ７メッセージをトピック・フレーム指示で正規化し、ＬＯＩＮＣ、ＩＣＤコードをマッピングし、ウェブ・ポータルでメッセージ・フロー・サーバ１００とインターフェースをとり、メッセージを待ち行列に入れ、データをデータ・ブローカにプッシュし、ウェブサービス・インターフェースをハブ１０ｈのグローバル患者レジストリ１１０９に提供するようにゲートウェイ２００ｇを構成することができる。ゲートウェイ２００ｇは、例えば、１つ以上のローカル・ディクショナリ２００ｄｂ_１、ＨＬ７メッセージ及びメッセージ待ち行列２００ｄｂ_２、及び、コマンド及び制御データベース２００ｄｂ_３のような複数のデータベースと通信することができ、及び／または、これらを備えることができる。

表１には、トピック記述及び関連コードを用いてＨＬ７によってサポートされる例示的な事象を示す。

所望に応じて、構成の一部として追加のＨＬ７メッセージを実装することができる。

図１３には、ウェブ・アプリケーション機能３００ａと通信するサブスクライバ・ポータル・サイト３００ｓをも示す。パブリッシャ・サイトの場合のように、管理サーバ１１００によってウェブ・アプリケーション機能の全部または一部を行うことができる。サブスクライバにパーティシパントとして登録させ、ＵＩＤ／ＰＷＤをログオンさせ、ログオフさせ、プロファイル設定を定義させ、サブスクライブさせ、アンサブスクライブさせ、検索させ、データに対するリクエストを送出させ、通知事象を生成させるのにウェブ・アプリケーション機能を用いることができる。ウェブ・ポータルでメッセージ・フロー・サーバ１００とインターフェースをとり、入ってくるメッセージを待ち行列に入れ、格納をアンラップし、ローカルＩＴシステムとインターフェースをとるようにゲートウェイ３００ｇを構成することができる。図示のように、図１３では、ゲートウェイ３００ｇは、メッセージ待ち行列データベース３００ｄｂ_１、受信したメッセージのローカルＨＬ７リポジトリ３００ｄｂ_２、及び、コマンド及び制御データベース３００ｄｂ_３を含む複数のデータベースを含むことができ、または、これらと通信することができる。

図１４には、レガシーまたは既存のＩＴシステム５００と、この環境内に用いられる異なるコードまたは分類体系とを有する既存の医療ケアパブリッシャ・サイト２００ｓを示す。例えば、サイト２００ｓの薬局２０８は、（ジェネリック／市販の）薬品コードを用いることができ、研究所２０７はＬＯＩＮＣコードを用いることができ、管理入力レコード２０６（入院、退院及び移転、または、患者ケア・レコード）はＣＰＴ４コードを用いることができる。これら異なるコード／分類を、一般にはＨＬ７メッセージを用いて標準のメッセージ形式に変換することができる。

表２には、本発明の幾つかの実施形態に従ってメッセージを用いて監視及び／または追跡することができるデータ要素を示す。

トピック・データ分類及び要素のタイプは、例示されたものに限定されないので、これらの例は一例にすぎず、本発明の範囲に限定されるものではない。

図１５には、監視またはビジネス・ニーズ、あるいは特定のパーティシパントの要望に対してコンパイルすることができる異なる事象のデータ・フロー要約を示す。図示のように、事象／医療ケア問題の日付及びタイプごとの集合化メッセージのチャートを提供することができる。このような情報を用いて、（呼吸器ウィルス・テスト結果のような）特定の観察に対してフラグを立てることができるターゲットの母集団を識別することができ、または、（例えば、急性心筋梗塞の患者が、入院から特定の期間内にベータ遮断薬を注文したとして識別されなかった場合、）臨床警告を生成することができる。異なる局所使用に従ってレポートをカスタマイズし、及び／または、自動的に生成することができる。図１８には、ポータル１０ｐを用いてトピック名ごとの内部パブリッシャ固有のメッセージを表示するパブリッシャ・ゲートウェイ２００ｇでの活動要約のサンプル・ビューを示す。

表３には、ケアの質及び／または医療の傾向を評価するため、参加中の機関、特に政府機関によって追跡することができる「重要な」データ要素の幾つかの例を示す。

図１６は、患者に関する３つのデータ・メッセージ・セグメント、すなわち、実験データ２００ｌ，薬局データ２００ｐ及び診断データ２００ｄを含むメッセージ２００ｍの一例である。メッセージ２００ｍは承認され、公開のためにメッセージ・フロー・サーバ１００に送信されて、リクエスト中の（１つ以上の）サブスクライバに送信される。メッセージはトピック「脳卒中診断」を識別し、「脳卒中診断」の関連するルール名、プロバイダ識別子、グローバル患者識別子番号（患者ＩＤ）及びメッセージ・タイム・スタンプを含む。

図１９には、パブリッシャ・ビュー及び使用モードを示し、図２０には、公開情報の詳細を用いて公開中にある公開情報をパブリッシャが公開モードの下で表示できる（また、所望に応じてパブリッシャは公開をキャンセルすることができる）ことを示す。パブリッシャは、公開情報を生成し（トピック・サブスクリプションへのデータを提供するのに同意し）、公開情報を表示し（公開情報の詳細すなわち、すべてまたは選択されたレコードをリストし）、公開情報を削除することができる（パブリッシャに既存の公開情報を削除させることができる）。一般に、パーティシパント・パブリッシャは、すべての患者に対して、サポートされたすべてのデータをゲートウェイ２００ｇに継続的にストリーミングすることができる。一般的に、臨床システムは、データをＨＬ７メッセージの形式でストリーミング（送信）することができる。それぞれのゲートウェイ２００ｇは、前述したように、所望の期間中、患者メッセージを格納することができる。

図２１には、ユーザがサブスクライバ・モードに移行するように電子的に選択できることを示す。図２１には、（サブスクライバが、興味を持つ医療ケア・レコードに対して、定義されたルールに従って許可された場合、）サブスクライバが、興味を持つ医療ケア・レコードを獲得するために識別または選択することができる選択されたトピックの幾つかの詳細（「トピック定義詳細」）を示す。トピックは、（「ＡＭＩ」すなわち急性心筋梗塞の疾病診断として示す）トピック起動事象と、一致する薬品の注文を示すレコードだけが返信データに含まれるようにする（アスピリンの薬品注文として示す）興味を持つ項目と、人口統計データに興味を持つかどうか、または、リクエストが人口統計データによって更に限定されるかどうかとを含む。トピックが生成され、トピック・カタログ内に格納された後、それぞれの使用資格（プライバシー提供または資格）がトピックと互換性がある限り、すべてのサブスクライバによってトピックを用いることができる。

システム１０は、パーティシパントに、送信されるデータのコンテンツを限定させることができるフィルタを提供する。デフォルトによって、一般的に、すべてのフィルタは適用され、サブスクライバは、システムによってサポートされたデータのすべてのタイプに対してデータを受信する。パーティシパントは、１つ以上のフィルタを「ターン・オフ」または選択解除することができる。このような場合には、システム１０は、トピック事象に一致するデータと、フィルタリングされなかった分類のデータとを送信することができる。

「トピック事象」機能の主目的は、関連データで患者レコードを選択するということである。また、トピック事象機能はデータのコンテンツに影響を与えることができる。例えば、任意のトピック事象の第１発生は、送信されるメッセージの開始ブラケットにマークを付け、最終トピック事象の第１発生は、送信されるメッセージの終了ブラケットにマークを付ける。トピック事象が一致する順序は、通常、考慮されない。他のルールがこの手続きをオーバーライドしない場合、開始ブラケットと終了ブラケットとの間で生じるすべてのメッセージは送信される。トピック事象が診断である場合、開始ブラケットを入院とし、終了ブラケットを退院とすることができる（一般的には、患者全体が遭遇する）。サブスクライバは、時間期間を特定することによって期間を限定することができる。期間が識別された場合、評価は入院から開始し、制限時間が到達されると終了する。すべてのトピック事象と、指定された人口統計データとが、指定された時間中に一致しなかった場合、いかなるデータ・メッセージ・レコードも送信されない。すべてのトピック事象が一致する場合にデータを送信することができる。しかし、一般的には、パーティシパントは、データが送信される時刻を指定することができない。

（メッセージ・フロー・サーバ１００を介する）サブスクライバからの起動事象がパブリッシャで受信された後、（１人以上の）患者が、すべての指定された基準を示すかどうかを確かめるため、パブリッシャは、患者に関して格納されたメッセージ及び後続のメッセージを評価する。

図２２は、「表示」ボタンを介してアクセスすることができる起動事象領域に関する更なる情報の画面ビューである。図示のように、診断名「ＡＭＩ」に対して、３つのＩＣＤ９コードすなわち４１０．０１、４１０．２１及び４１０．７１が関連する。これらコードの１つ以上に一致するレコードを、このリクエストされた起動事象に基づいて含めることができる。診断に対して、パーティシパントは、すべての関連変量及び有効ＩＣＤ９コードを定義する必要がある。同様に、図２３には、関連の表示ボタンを介して獲得することができるアスピリンの薬品注文に関する更なる情報を示す。図示のように、「アスピリン」の薬品名識別子に対して、「アスピリン」または「ａｓａ」の下の処方済み薬品を有するレコードが含まれる。

一般的に、システム１０は、注文識別子と、注文から関連するＬＯＩＮＣ、ＣＰＴまたはＩＣＤ９コードとを含む実験及び手続き観察／結果メッセージを受信することができる。パーティシパント（サブスクライバ）が実験または手続きの注文に関するデータを欲しい場合、実験または手続き結果を、追加データのトピック事象分類と指定する必要がある。事象が実験結果によって定義される場合、パーティシパントは、対応するＬＯＩＮＣコードを用いて実験テストの所望変量のすべてを指定する必要がある。また、パーティシパントは、トピック事象の下で結果基準を指定することができる。事象が手続きである場合、パーティシパントは、指定された各手続きの有効値である手続きの所望変量のすべてを指定する必要があり、対応する有効ＩＣＤ９またはＣＰＴコードを有する必要がある。ＩＣＤ９及び／またはＣＰＴコードを用いる必要があるかどうかをパーティシパントは指定することができる。

ＣＤＣ（疾病対策センター）、ＦＤＡ（食品医薬品局）、ＮＩＨ（国立衛生研究所）及びＣＭＳ（メディケア・メディケイド・センター）のような連邦及び州機関との臨床データの共用に加えて、質及び準拠のレポートをも自動化するのに本発明の実施形態を用いることができる。協調データ共用システムにおいてパーティシパントとなる可能性のある他の連邦機関は、ＤＯＣ（国防総省）、ＦＡＡ（連邦航空局）、ＦＢＩ（連邦捜査局）、米国国土安全保障省などを含む。幾つかの実施形態では、本発明のシステムは、ＨＬ７を介するＩＣＤ、ＣＰＴ、ＬＯＩＮＣ及びＮＤＣのような多くのプロバイダ設定で使用可能な既存の電子データを利用することができる。

図２４は、薬物有害事象（ＡＤＥ）を識別するのに用いることができる本発明の実施形態を示す。薬物有害事象を識別するようにゲートウェイ２００ｇを構成することができる。幾つかの実施形態では、識別された薬物有害事象のメッセージ・データを専用のデータベース及び／または警告レセプタ（図１１の２０９）に保持することができる。パブリッシャ・サイト２００_２でＡＤＥを検出すると、自動化電子警告２００Ａをハブ１０ｈによって他のパブリッシャ２００及び／またはサブスクライバ３００に送信することができる。制約に基づくルールを用いて、選択されたパーティシパントに送信されるメッセージ内に統合された警告として警告２００Ａを形式設定することができる。警告２００Ａを、トピック・カタログ内にある関連する医療トピックのサブスクライバに選択的に送信するようにルールを設定することができる。サブスクライバの例として、前述したような、ほぼリアル・タイムのメッセージング・システムを用いる、治療を行う医師及び／または病院、薬品製造業者、臨床試験管理者、異なる代替薬品の競合する製造業者、または（ＣＤＣ、ＦＤＡなどのような）政府機関を挙げることができる。

図２５には、本発明の実施形態を用いて疾病の大発生を監視及び／または識別できることを示す。ＡＤＥ警告の場合のように、疾病の大発生、特定の診断または汚染の観察は、参加中のサブスクライバ３００の全部または一部への疾病／汚染警告２００Ａ’を起動することができる。前述のように、制約に基づくルールに基づいて警告２００Ａ’を、選択されたサブスクライバに送信することができる。例えば、パブリッシャが、死亡率の増大、公衆衛生のリスク、伝染性と見なされる疾病、共通の診断を有する患者の増大数（異常な大発生）、及び／または、バイオ・テロリズムの事象または薬剤と関連して疾病または汚染を有する患者を識別する場合、（政府機関のような）参加中の幾つかのサブスクライバは、特に、迅速な通知に興味を持つかもしれない。例えば、システムは、腸チフス、結核、ポリオ、天然痘、（腺）ペスト、エボラ、マールブルグ、鳥インフルエンザ、西ナイル・ウィルス、ＳＡＲＳ（重症急性呼吸器症候群）、肝炎及びＨＩＶを含むがこれらに限定されないウィルス、細菌及び／または原生動物によって生じる疾病の新たな、または予期しない増大量を監視し識別することができる。システムは、炭疽菌汚染、食中毒、大腸菌汚染、クロイツフェルト・ヤコブ病、放射能汚染、リシン汚染、アスベスト汚染及び鉛汚染のようなバイオ・テロリズムの事象または薬剤、または環境危険に対しても監視し識別することができる。可能性があるバイオ・テロリズムの薬剤の更なる完全なリストを、ＣＤＣウェブサイトｗｗｗ．ｂｔ．ｃｄｃ．ｇｏｖ／ａｇｅｎｔ／ａｇｅｎｔｌｉｓｔ．ａｓｐで見つけることができる。

パブリッシャ・ソース２００からハブ１０ｈを介してサブスクライバ３００に警告２００Ａ’をほぼリアル・タイムで送信することができる。特定の実施形態では、パブリッシャから、１つ以上の承認されたサブスクライバへのデータ送信の周期を、サブスクライバのリクエスト及び／またはパブリッシャの関連データの収集に従って変更することができる。入院、実験テスト及び／または退院時に、疑わしい疾病を直ちに識別することができるように、患者データをストリーミングし、ほとんどまたはほぼ連続して（コンピュータまたは電源の破壊または機能停止を無視する場合には連続して）データを相互に関連付けるのにパブリッシャ２００を構成することができる。

この監視を用いて、ほぼリアル・タイムの疾病監視を、保険会社のような規制機関及び／または支払業者に提供することができる。支払業者による早期検出及び監視によって、患者は、適切または更に積極的な治療プログラムまたはセラピーを受けることができ、特に、早期検出及び疾病管理が費用の減少、寿命の延び、及び／または死亡率の減少に有益である疾病に対して、医療ケア費用を減少させる可能性を秘める。

異種の（相互及び内部）臨床システムにわたって患者データを統合し、臨床の質の検討及び監視を提供し、治療中に上昇することがあるエラーの数を減少させる可能性を秘めるのに本発明の実施形態を用いることができる。このシステムを用いて、臨床性能を監視し、変量を処理し、費用分析のようなビジネス関連データを提供することができる。単一のパブリッシャは複数のサブスクライバをサポートし、前述したような（ＨＬ７メッセージ、短いテキスト・メッセージ、電子メールなどを用いるような）異なる形式で臨床データを公開し、ＰＤＡ、パーソナル・コンピュータ、（リポジトリ・データベースへ直接つながる）メインフレーム、ポータブル無線通信装置、携帯電話／通信機関などのような異なる装置に公開することができる。

公開サイト（データ・ソース組織）は、それ自体の患者データの公開を制御し、データに対するサブスクライバ（データ検討組織）リクエストを承認または否認することができる。パブリッシャは、認証及び暗号化を中心として高いセキュリティ規格を用いて患者データ（必要に応じて、直接に識別できない患者データ）を送信することによってＨＩＰＡＡプライバシー規則を準拠することができる。

システムは、承認されたサブスクライバに比較的総合的なレコードを転送できるように、薬局、研究所及び入院／退院システムを統合し、（ＨＬ７データ・ストリームのような）関連データ・ストリームを収集し、関連データを関連付けることができる。システムは、承認されたデータだけが（患者識別子データを用いないような）合意に基づくように安全に公開されるように制御し、及び／または、このことを検証するように構成されている。

システムは、リクエストされたデータをコンテンツ（医療ケア・システムに対する臨床トピック）に基づいて経路指定する「公開及びサブスクライブ」プロトコルと、プライバシー及び／または許可レベルにリンクされたサブスクリプション資格とを用いることができる。アーキテクチャは、比較的柔軟かつスケーラブルであって、パーティシパント・サイトで簡易導入を容易にするように構成されている。

図２６、図２７、図２８及び図２９は、本発明の実施形態に従ってパブリッシャ２００とサブスクライバ３００との間で安全なデータ共用を提供するのに用いることができるプライバシー・レベルのデータ共用プロトコルの実施形態を示す。すなわち、外部の許可されていないユーザがデータへアクセスしないように、または、データを改ざんしないように、許可されたユーザだけがデータ共用ネットワークに参加することができるプロトコル・レベル・セキュリティを用いてシステム１０を構成することができる。更に、システム１０は、すべてまたは特定のタイプのデータを受信する許可及び／または資格が与えられていないサブスクライバ３００にデータのパブリッシャ２００がデータを送信しないようにする「資格」プライバシー・レベル・プロトコルを用いることができる。

図２６には、ある組織が有することができるプライバシー・レベルのシステム・セットを定義するプライバシー・レベル・グリッド１４００を示す。用語「組織」を、一群の提携部門及び／またはエンティティ、一連の提携外エンティティまたは人々、及び／または、全体のシステム１０自体と見なすことができる。すべてのクライアントが、所定のプライバシー・レベルと、資格に対して共通の定義を有する共通のプライバシー・レベル・セットとの意味について単一の権限を参照することができるように中央プライバシー・レジスタを用いて所定のネットワークを構成することができ、及び／または、データ共用プロトコルをネットワークまたはシステムに対して（すなわち、アプリケーション・ドメイン内に）定義することができる。用語「プライバシー・レベル」は、程度の大きいコンテンツまたは患者識別子データに対する、程度の小さいコンテンツまたは患者識別子データ（すなわち、機密な、個人的、及び／または「秘密」データと見なされるデータに対する、より一般的であると見なされるデータ）に従ってデータのタイプを分類する分類体系を意味する。大規模または異なるデータ・コンテンツへアクセスさせることができるようにプライバシー・レベルを構成することができる。他の実施形態では、大きいプライバシー・レベルが、下位のプライバシー・レベルを有するデータへアクセスする権利を含むことができるように、プライバシー・レベルを階層的に構成することができる。幾つかの実施形態では、別個のデータ・コンテンツ、すなわち、患者の医療ケアに関するデータ・レコード、及び、患者識別情報のパブリッシャ・ゲートウェイのフィルタリング及び／またはサブスクライバのアクセスに対する資格を定義するようにプライバシー・レベルを構成することができる。

特定のクライアント（すなわち、サブスクライバ及び／またはパブリッシャ）は、データ共用のための特定のネットワークまたはシステムに対して、定義されたプライバシー・レベルの全セットまたはサブセットをサポートすることができる。従って、例えば、サブスクライバ３００は、（１つ以上の）割り当てられたプライバシー・レベル以外であるトピックに関してサポートする（データをリクエストまたは生成する）ことができず、パブリッシャ・ゲートウェイ２００ｇは、特定の（１つ以上の）割り当てられたプライバシー・レベル以外であるデータ・レコードを公開する（または、幾つかの実施形態ではコンパイルする）ことができない。組織１０００内の定義されたプライバシー・レベルの全部のスーパーセットをサポートするのにそれぞれのパブリッシャ・ゲートウェイ２００ｇ（または、実際にはサブスクライバ・ゲートウェイ３００ｇ）は必要とされないが、それぞれのゲートウェイ２００ｇは、それらがサポートするポータルのプライバシー・レベルをサポートする必要がある。

概説するならば、すべての異なるゲートウェイ２００ｇの異なるプライバシー・レベルの交点にあるプライバシー・レベルのデータ・コンテンツを備える（トピックに従って定義することができる）電子データ・レコード１０００Ｇだけを特定の組織に対して「グローバル」とさせることができる（すなわち、グローバル・データ・トピックに対して、すべてのサブスクライバはデータ３００Ｒをリクエストすることができ、すべてのパブリッシャは公開データ２００Ｍを送信することができる）。グローバル・プライバシー・レベルを、すべてのゲートウェイ２００ｇ，３００ｇ及び／または参加中の組織によって寛容に用いる／サポートすることができる。すべてのユーザは、他のデータ・リクエストをグローバルに利用できなくなる。医療ケア・データ共用実施形態に対して、１つの定義されたプライバシー・レベルを「ＨＩＰＡＡＬｉｍｉｔｅｄＡ」とすることができ、もう１つの定義されたプライバシー・レベルを「ＨＩＰＡＡＦｕｌｌｙＤｅｉｄｅｎｔｉｆｉｅｄ」とすることができ、各々は、これらレベルを定義する法的ルールに対応するデータ共用制約を有する。他の非医療分野では、異なるデータ共用制約及びプライバシー・レベルを用いることができる。

一般的に、「オンボード」またはカスタマ・セットアップ中、クライアント（サブスクライバまたはパブリッシャあるいはその他）はネットワークまたはシステム１０に組み込まれ、ローカル・パーティシパント・データ共用決定または選択、及び／または、法的資格に基づいて１つ以上のプライバシー・レベルが割り当てられて、特定のタイプ（及び／またはコンテンツ）のデータを送信及び／または受信する。それぞれのパブリッシャ２００が２つ以上のパブリッシャ・ゲートウェイ２００ｇを有する場合、各パブリッシャ・ゲートウェイ２００ｇは異なるプライバシー・レベルをサポートすることができる。パブリッシャ・ゲートウェイ２００ｇまたはサブスクライバ３００のそれぞれの（１つ以上の）プライバシー・レベルは、レベルに含まれたデータを提供またはアクセスするための法的権利を定義する１つまたは一連のプライバシー・レベルに対して割り当てられる。例えば、幾つかの特定の実施形態では、サブスクライバ・パーティシパントを、免除、非免除、内部、外部または政府のパーティシパントなどとして定義することができる。あるいはまた、プライバシー・レベルを所定のシステムの導入／アプリケーションに定義または確立することができる。特定の政府のサブスクライバ３００は、これらに、「完全に識別された」患者データの表示を許可する資格を有することができる。パーティシパントが、（１つ以上の）割り当てられたプライバシー・レベルで動作するか、または、これらをサポートする他のパーティシパントだけと通信することができるように、システム１０を構成することができる。サブスクライバ３００及び／またはパブリッシャ２００が通信（サブスクライバのデータを受信し、パブリッシャのデータを送信）したい場合、それらは、（１つ以上の）同じプライバシー・レベルをサポートするサブスクライバ３００及び／またはパブリッシャ２００間だけで通信を行うことができる。従って、２つのパーティシパント間で共用されるデータは特定のプライバシー・レベルに一致する。例えば、パブリッシャ（１）がプライバシー・レベルＡ，Ｂ，Ｃをサポートするが、サブスクライバ（１）はプライバシー・レベルＣだけをサポートする場合、パブリッシャ（１）は、プライバシー・レベル「Ｃ」に一致するデータだけをサブスクライバ（１）と共用することができる。幾つかの実施形態では、サブスクライバ３００は、それらがサポートするプライバシー・レベルを有するトピックだけを表示／生成することができる。同様に、パブリッシャ・ゲートウェイ２００ｇがサポートするプライバシー・レベルのトピックだけに対して公開するようにパブリッシャ・ゲートウェイ２００ｇを構成することができる。従って、これら実施形態では、サブスクライバ３００は、それらのプライバシー・レベルをサポートするパブリッシャ２００からのデータだけサブスクライブすることができる。管理サーバ１１００は、トピックのプライバシー・レベルを用いてパブリッシャ２００とサブスクライバ３００との間の通信を制御することができる。管理サーバ１１００と関連する（組み入れ、または通信する）ことができるプライバシー・レベル電子レジスタ内にプライバシー・レベルを維持することができる。

組織１０００は複数のパブリッシャ・ゲートウェイ２００ｇを備えることができ、各々は、１つ以上の異なる割り当てられたプライバシー・レベルを有する。サブスクライバ３００に対するプライバシー・レベルは、エンティティが受信できるデータがどれであるかを定義するが、パブリッシャ・ゲートウェイ２００ｇに対するそれぞれの（１つ以上の）プライバシー・レベルは、ゲートウェイ２００ｇが送信できるデータがどれであるかを定義する。

図２７及び図２８に関して、前述したようなデータ共用システム１０に３つのサブスクライバ３００_１，３００_２，３００_３及び３つのパブリッシャ２００_１，２００_２，２００_３を示す。この場合も前述したように、電子トピック・カタログ１１０１を用いるようにシステム１０を構成することができ、各トピックは、（「プライバシー・レベル」（「ＰＬ」）Ａ，Ｂ，Ｃとして示すが、大きいまたは小さいプライバシー・レベル分類を用いることができる）割り当てられたプライバシー・レベルを有する。各サブスクライバ３００は、リクエスト中、表示中、または生成中のサブスクライバのプライバシー・レベルに一致するプライバシー・レベルを有するトピック・カタログ１１０１内のトピックに対するリクエストを表示、選択及び／または生成することができる。例えば、図示のように、サブスクライバ３００_１はプライバシー・レベル「Ａ」を有し、プライバシー・レベル「Ａ」を有するカタログ１１０１内のデータ・トピックを表示及び／または生成することができる。同様に、「トピック」がプライバシー・レベルＤトピックとして定義され、サブスクライバ３００がレベル「Ａ」及び「Ｄ」をサポートしている場合、サブスクライバ３００はレベルＤのデータだけを受信する。同様に、パブリッシャ２００がＡ、Ｂ及びＣをサポートし、レベルＤトピックに対して公開したい場合、パブリッシャ２００はこのトピックを公開することができる。パブリッシャ・ゲートウェイ２００ｇは、それらの組織がそれらに対して定義するプライバシー・レベルを有するトピックに対して公開することができる。サブスクライバ３００またはパブリッシャ２００がそれぞれ、異なるプライバシー・レベルのトピックにデータを受信または公開したい場合、これらのエンティティによってサポートされるプライバシー・レベルで新たなトピックを指定する必要がある。サポートされるプライバシー・レベルを、パブリッシャ２００に対しては、許可された「オファリング・レベル」と称し、サブスクライバ３００に対しては「資格レベル」と称することができる。プライバシー・レベルが、サポートされていないプライバシー・レベルである場合でさえ、トピックに対して寛容に公開する（公開を必要とされない）ように、それぞれのパブリッシャ２００を構成することができるが、サブスクライバ３００は、サポートされるプライバシー・レベルを有する新たなトピックを生成することができる。

管理サーバ１１００は、対応するプライバシー・レベルを有するそれぞれのパーティシパントを定義する電子プライバシー・レベル・レジスタ１１００Ｒと通信し、及び／または、これを含むことができる。レジスタ１１００Ｒは、メッセージ・フロー・サーバ１００を表すボックス内に示されるが、図２７及び図２８において、レジスタ１１００Ｒは管理サーバ１１００内に存在し、及び／または、これと通信することができ、あるいは、独立型モジュールまたはコンポーネントとして作用することができる。レジスタ１１００Ｒはサブスクライバ３００を特定のプライバシー・レベルと相互に関連付け、パブリッシャ２００から、許可または資格が与えられていないデータへのアクセスを阻止または防止するようにメッセージ・フロー・サーバ１００を介してサブスクライバ３００とパブリッシャ２００との間の通信を制御する作用をする。プライバシー・レベル・レジスタ１１００Ｒの機能コンポーネントの例は、セキュリティ・ディレクトリ１１０３、パーティシパント・プロファイル１１０２及びルール１１０４として一般的に称されるデータベースの１つ以上を含む図１３に示されている。管理サーバ１１００は、前述したようにトピック・カタログ１１０１及びメッセージ・フロー・サーバ１００と同様にレジスタ１１００Ｒを含み、及び／または、これと通信することができ、これによって、プライバシー・レベルに資格が与えられたサブスクライバ３００だけがコンテンツ固有のデータをパブリッシャ２００から受信する。

図２７及び図２８に示すように、各サブスクライバ３００_１〜３００_ｎ（図では、３００_１〜３００_３と示す）は、グローバル・プライバシー・レベルとすることができる割り当てられたプライバシー・レベルを有する。幾つかの実施形態では、サブスクライバ３００及び／またはパブリッシャ２００は、２つ以上の割り当てられたプライバシー・レベルを有することができる。幾つかの実施形態では、特定のサブスクライバ３００に対するプライバシー・レベルを、パブリッシャ２００固有のプライバシー・レベルとすることができる。例えば、サブスクライバ３００が特定のパブリッシャ２００と連携されている場合、（増大した資格を有する）高次のプライバシー・レベルを、パブリッシャ‐サブスクライバ通信データ共用プロトコルに対して割り当てることができる。

図２７には、それぞれのサブスクライバ３００が、ポータル（管理サーバまたはウェブ・アプリケーション）を介してトピック・カタログ１１０１からトピックのサブセットを表示できることを示す。管理サーバは、すべてのサブスクライバ及びパブリッシャ及びメッセージ・フロー・サーバ１００と通信する。メッセージ・フロー・サーバ１００とそれぞれのパーティシパントとの間の通信フローは、図２７に示されていない。

図２８には、プライバシー・レベル「Ａ」を有するサブスクライバ３００_１が、割り当てられたプライバシー・レベル「Ａ」を有するトピックに関するトピック公開情報を表示及び／またはリクエストできることを示す。プライバシー・レベル「Ａ」をサポートするパブリッシャはリクエストを受信し、及び／または、メッセージ・フロー・サーバ１００を介してトピックに一致するデータを転送することができる。この通信プロトコルは、パブリッシャ２００_１，２００_３からメッセージ・フロー・サーバ１００を介してサブスクライバ３００_１への矢印を有する比較的太い線によって示されている。

図２９には、プライバシー・レベル・レジスタ１１００Ｒが、資格の定義されたプライバシー・レベルに従って、参加中のサブスクライバとパブリッシャとの間のデータ共用プロトコルを制御できる電子互換性相関行列１１００Ｍを備えることができることを示す。行列１１００Ｍは、各パブリッシャ２００に対してサブスクライバ３００ごとに通信プロトコル／データ・コンテンツを定義するデータ・フィールドを含むことができ、トピックがプライバシー・レベルを満足する場合、特定のパブリッシャ２００がトピックに関するデータへのサブスクリプションを承認したことを確認する「サブスクリプション」セグメントを含むことができる。動作中、資格が与えられていないサブスクライバ３００がデータを獲得しようとする場合、メッセージ・フロー・サーバ１００は、特定の選択されたトピックに関するデータへの「サブスクリプション」に対して、及び／または、サブスクライバのプライバシー・レベルに一致しないトピックに対してこのサブスクライバを承認しなかったパブリッシャ２００からデータを転送しない。メッセージ・フロー・サーバ１００は、管理サーバ１１００及び／またはプライバシー・レジスタ１１００Ｒと通信して、トピックに対するサブスクライバ３００の資格レベルを検証し、必要に応じてパブリッシャのデータへのアクセスを阻止することができる。

前述は本発明の例示であって、本発明を限定するものと解釈されるべきではない。本発明の少数の例示的な実施形態を説明したが、当業者は、本発明の新規な教示及び利点から実質的に逸脱することなく、例示的な実施形態に多くの変更が可能であることを容易に理解するであろう。従って、すべてのこのような変更は、特許請求の範囲に定義されているように本発明の範囲内に含まれるものである。特許請求の範囲では、ミーンズ・プラス・ファンクション・クローズは、列挙した機能を実行するように、本明細書で記述した構造にまで及ぶものであって、構造上等価なものだけでなく、等価な構造にも及ぶ。従って、当然のことながら、前述は本発明の例示であって、開示した特定の実施形態に限定されるものと解釈されるべきではなく、開示した実施形態及び他の実施形態の変更は特許請求の範囲内に含まれるものである。本発明は特許請求の範囲によって定義され、特許請求の範囲の等価物は本発明に含まれる。

本発明の実施形態による協調データ交換を提供するのに用いられるコンピュータ・ネットワーク・システムの概略図である。 図１に示すシステムにおいて、本発明の実施形態による例示的な公開サイクルを示す概略図である。 図１に示すシステムにおいて、本発明の実施形態によるサブスクライバと複数の異なるパブリッシャとの間の選択されたサブスクライバ・トピックの例示的な公開サイクルを示す概略図である。 図１に示すシステムにおいて、本発明の実施形態に従ってデータを発信ソース・パブリッシャのパブリッシャ・ゲートウェイに入力でき、（異なる出力形式の）公開情報を発信パブリッシャ内または関連のエンティティに返信できることを示す概略図である。 本発明の特定の実施形態を行うのに用いることができる例示的な動作のフローチャートである。 本発明の実施形態を行うのに用いることができる他の例示的な動作のフローチャートである。 本発明の実施形態によるデータ処理システムのブロック図である。 本発明の実施形態によるデータ処理システムのブロック図である。 本発明の実施形態による協調コンピュータ・ネットワーク・システムの概略図である。 本発明の実施形態によるハブのコンポーネントの概略図である。 本発明の実施形態によるネットワーク・システムの例示的なシステム・アーキテクチャの概略図である。 本発明の実施形態による特定システムの追加機能の概略図である。 本発明の実施形態によるパブリッシャ及びサブスクライバとインターフェースをとるハブを含むシステムの概略図である。 本発明の実施形態による患者レコード・データのメッセージ統合システムの概略図である。 本発明の実施形態に従って生成できるトピック事象のデータ要約のグラフである。 本発明の実施形態に従って、患者に関する様々なデータ・レコードを含むサンプル・メッセージである。 本発明の実施形態によるパブリッシャの例示的なコンピュータ・ネットワーク（一般にはウェブ）ポータルの画面印刷出力である。 本発明の実施形態によるコンピュータ・ネットワーク・ポータルへのアクセス可能な例示的なトピック・カタログ・リストの画面印刷出力である。 本発明の実施形態による管理アプリケーションから／上の例示的なパブリッシャ「ホーム」ビューの画面印刷出力である。 本発明の実施形態による管理アプリケーションから／上の例示的なパブリッシャ「ホーム」ビューの画面印刷出力である。 本発明の実施形態に従って、興味を持つ（１つ以上の）トピックの公開に関してシステムと対話するのに用いることができる画面ビューである。 本発明の実施形態に従って、興味を持つ（１つ以上の）トピックの公開に関してシステムと対話するのに用いることができる画面ビューである。 本発明の実施形態に従って、興味を持つ（１つ以上の）トピックの公開に関してシステムと対話するのに用いることができる画面ビューである。 本発明の実施形態に従って薬物有害事象を識別し、警告を生成するのに用いられる医療ケア・システムの概略図である。 本発明の実施形態に従って疾病の大発生、公衆衛生のリスク、環境危険及び／またはバイオ・テロリズムの事象を識別し、識別の警告を生成するのに用いられる医療ケア・システムの概略図である。 本発明の実施形態によるプライバシー・レベル・グリッドの概略図である。 本発明の実施形態に従って、定義されたプライバシー・レベルを有するサブスクライバ及びパブリッシャのコンピュータ・ネットワーク・システム、及びトピックの一例を示すブロック図である。 本発明の実施形態に従って、定義されたプライバシー・レベルを有するサブスクライバ及びパブリッシャのコンピュータ・ネットワーク・システム、及びトピックの一例を示すブロック図である。 本発明の実施形態によるサブスクライバとパブリッシャとの間のデータ共用を制御するのに用いることができる互換性相関行列の概略図である。

Claims (33)

1. 登録された参加中の加入者及び公開者のコンピュータ・ネットワークを用いてデータの協調交換の制御されたレベルを提供する方法であって、
   一連の異なるプライバシー・レベルを定義するステップであって、各プライバシー・レベルが、各参加中の公開者からコンテンツ固有のデータを受信する参加中の加入者の能力を電子的に制御する関連データ共用パラメータを有するステップと、
   前記一連の異なるプライバシー・レベルから参加中の公開者ごとに選択されたとして承認されたプライバシー・レベルがどれであるかを参加中の加入者ごとに識別し、これによって、加入者と公開者との間の制御された電子データ共用プロトコルに基づいて資格を提供する電子プライバシー・レベル・レジスタを提供するステップと
   を含む方法。
2. 各公開者は、公開者が加入者に公開することができるデータを制御する前記一連の異なるプライバシー・レベルから選択された少なくとも１つの定義されたプライバシー・レベルを有する、請求項１に記載の方法。
3. 前記データの協調交換は、公開者と加入者との間のデータ共用を制御するために参加中の加入者と公開者との間で仲介するゲートキーパとして作用する管理サーバ・ウェブ・アプリケーションと関連し、及び／または、これに組み入れられた前記電子プライバシー・レベル・レジスタを有するウェブ・ベースのコンピュータ・ネットワークを用いて提供される、請求項１に記載の方法。
4. 各公開者は、電子患者データ・レコードのリポジトリを保持し、それぞれの公開者から、承認されたプライバシー・レベルを有する加入者だけに電子医療ケア・データを選択的に転送するメッセージ・フロー・サーバに電子医療ケア・データを電子的に提供する公開者・ゲートウェイを備える、請求項１に記載の方法。
5. 前記データの協調交換は患者医療ケア・データを対象とし、前記公開者は医療ケア・プロバイダを備え、前記プライバシー・レベルは、どの公開者が医療ケア・データをそれぞれの加入者に送信でき、どのコンテンツをそれぞれの加入者が公開者から電子的にリクエストできるかを制御する、請求項１に記載の方法。
6. 医療ケア・トピックの電子トピック・カタログを提供するステップを更に含み、各トピックは、それぞれのプライバシー資格レベルのトピックに関するデータだけを加入者がリクエストでき、それらのプライバシー資格レベルのトピックに関するデータだけを公開者が公開できるように前記一連の異なるプライバシー・レベルの１つに対応する割り当てられたプライバシー・レベルを有する、請求項１に記載の方法。
7. 前記リクエスト中の加入者が、１つ以上の公開者からの医療ケア・データへアクセスする資格を前記加入者に与えるプライバシー・レベルを有する場合、前記管理サーバから１つ以上の公開者へ加入者によって開始される選択された医療ケア・トピックに対する加入者・トピック・データ・リクエストを電子的に自動経路指定するステップを更に含み、請求項６に記載の方法。
8. 前記トピック・カタログが、すべての異なるプライバシー・レベルにあるすべての選択可能なトピックのグローバル・カタログである、請求項６に記載の方法。
9. 前記管理サーバは、前記電子トピック・カタログ内の医療ケア・トピックだけをそれぞれの加入者に、加入者のプライバシー・レベルと対応するそれぞれのウェブ・ポータルで表示するように構成される、請求項８に記載の方法。
10. 管理サーバ・ウェブ・アプリケーションは、加入者ごとに前記プライバシー・レジスタ内に定義された公開者固有のプライバシー・レベルに基づいて資格が与えられた加入者だけに公開者から送信された公開者医療ケア・データを選択的に転送するために前記メッセージ・フロー・サーバと通信する、請求項６に記載の方法。
11. 前記プライバシー・レベル・レジスタは、医療ケア・データ・トピックごとに、加入者ごとに、かつ、公開者ごとに定義されたプライバシー・レベルを相互に関連付ける互換性相関行列を備える、請求項１０に記載の方法。
12. それぞれの公開者に対して許可されたプライバシー・レベルを有する加入者からの選択された医療ケア公開トピックに対するリクエストだけを表示するウェブ・ポータル表示を公開者ごとに選択的に生成するステップを更に含む、請求項２に記載の方法。
13. 前記複数の異なるプライバシー・レベルは、患者匿名化データだけを公開者と加入者との間で共用させることができる第１プライバシー・レベルと、限定された患者データを公開者と加入者との間で共用させることができる第２プライバシー・レベルとを備える、請求項１に記載の方法。
14. 公開者と加入者との間のデータ・コンテンツに関して非制限的である第３プライバシー・レベルを更に備える、請求項１３に記載の方法。
15. 興味を持つトピックを電子トピック・カタログから加入者に電子的に選択させ、前記トピックに関連するデータの公開に対するリクエストを電子的に自動的に起動させ、前記リクエストは次にコンピュータ・ネットワークを介して、準拠したプライバシー・レベルを有する参加中の公開者に送信されるステップとを更に含む、請求項１に記載の方法。
16. 所望のデータ制約を有する新たなトピック・データ・リクエストを加入者に電子的に開始させ、前記新たなトピック・データ・リクエストが、前記加入者・プライバシー・レベルを準拠するプライバシー・レベルを有する場合には前記トピック・カタログ内に自動的に電子的に格納されるステップを更に含む、請求項１５に記載の方法。
17. 加入者及び公開者・パーティシパントを備えるウェブ・ベースの医療ケア協調データ共用システムであって、前記公開者が、加入者とデータ共用プロトコルを確立する、異なる医療ケア・データ・コンテンツに対して少なくとも１つの定義されたプライバシー・レベルを有し、前記加入者が、公開者とデータ共用プロトコルを確立する少なくとも１つの定義されたプライバシー・レベルを有し、加入者及び公開者に対して前記少なくとも１つの定義されたプライバシー・レベルは、加入者及び公開者に対する前記ウェブ・ベースのシステムによって用いられる一連の共通の定義されたプライバシー・レベルから選択されるシステム。
18. 各公開者は、電子患者データを受信し、前記患者データをオープン・スタンダード・メッセージに自動的に電子的に形式再設定し、所望の間隔で前記患者データ・メッセージをそれぞれの公開者・メッセージ・データベースに自動的に電子的に格納するように構成された少なくとも１つの公開者・ゲートウェイを備える、請求項１７に記載のシステム。
19. 前記複数の異なるプライバシー・レベルは、インターネットを用いて患者匿名化データだけを公開者と加入者との間で共用させることができる第１プライバシー・レベルと、限定された患者データを、前記インターネットを用いて公開者と加入者との間で共用させることができる第２プライバシー・レベルとを備え、請求項１７に記載のシステム。
20. 公開者と加入者との間のデータ・コンテンツに関して非制限的である第３プライバシー・レベルを更に備え、前記第３プライバシー・レベルは、通常、医療ケア・プロバイダにわたって監視権限を有する政府機関と関連し、前記プライバシー・レベルは、前記インターネットを介する公開者と加入者との間の通信用のＨＩＰＡＡプライバシー準拠データ共用プロトコルを提供するように構成されている、請求項１７に記載のシステム。
21. インターネットを介する公開者・パーティシパントと加入者・パーティシパントとの間の協調医療ケア・データ共用を提供し制御するウェブ・ベースの安全なデータ共用システムであって、前記システムは、
    前記インターネットを介してパーティシパント医療ケア・公開者・ゲートウェイ及び加入者と通信するように構成されたメッセージ・フロー・サーバと、
    前記メッセージ・フロー・サーバと通信する管理サーバであって、前記管理サーバが参加中の加入者と公開者との間の電子通信を制御するように構成され、各参加中の加入者及び公開者が、定義された一連のプライバシー・レベルから選択された少なくとも１つの定義されたプライバシー・レベルを有し、特定タイプの患者医療ケア・データに対してプライバシー・レベルを定義する電子プライバシー・レベル・レジスタと通信する管理サーバと
    を備え、加入者と公開者との間の前記通信を（１つ以上の）それぞれの定義されたプライバシー・レベルに基づいて電子的に制御するように構成されているシステム。
22. 前記管理サーバ及び／または前記メッセージ・フロー・サーバが、異なる医療ケア・データ・トピックの加入者選択可能電子トピック・カタログ・データベースと通信し、前記異なる医療ケア・トピックの各々が関連のプライバシー・レベルを有する、請求項２１に記載のシステム。
23. 加入者がアクセスする資格を与えられていることをトピックのプライバシー・レベルが示す前記トピック・カタログ内のトピックだけをそれぞれの加入者が表示できるように構成されている、請求項２２に記載のシステム。
24. 前記管理サーバは、公開者から、サブスクリプションに基づいて資格が与えられた加入者だけへ受信されたそれぞれのトピックに関する医療ケア公開データを選択的に自動的に電子的に転送するためにそれぞれの公開者及び加入者及び前記メッセージ・フロー・サーバと通信し、前記サブスクリプションは、公開者ごとに前記医療ケア・データの前記トピック及び前記加入者・プライバシー・レベルと関連する前記プライバシー・レベルに基づいて加入者及びトピックに固有である、請求項２１に記載のシステム。
25. 前記管理サーバは、前記トピック及び／またはリクエスト中の加入者が、一致しないプライバシー・レベルを有する場合に、公開者患者医療ケア・データへの許可されていない加入者のアクセスを自動的に電子的に防止するように構成された互換性相関行列と通信する、請求項２１に記載のシステム。
26. メッセージ・フロー・サーバと、
    電子患者医療ケア・レコードへアクセスする複数の公開者・パーティシパントであって、各公開者が、前記メッセージ・フロー・サーバと通信する少なくとも１つの公開者・ゲートウェイを備え、それぞれの公開者・ゲートウェイが、それぞれの加入者との前記公開者・ゲートウェイのデータ共用プロトコルを電子的に制御する少なくとも１つの定義されたプライバシー・レベルを有するように構成されている公開者・パーティシパントと、
    前記メッセージ・フロー・サーバと通信する複数の加入者・パーティシパントであって、各加入者が、参加中の公開者からの医療ケア・データへのアクセスを電子的に制御する定義されたプライバシー・レベルを有する加入者・パーティシパントと
    を備える医療ケア協調データ共用コンピュータ・ネットワーク・システムであって、
    医療ケア・トピックに関連する医療ケア・データは、前記加入者が、前記トピックの医療ケア・データに対して前記加入者に資格を与えるプライバシー・レベルを有する場合だけ、前記メッセージ・フロー・サーバを介してそれぞれの公開者・ゲートウェイから加入者に自動的に選択的に電子的に転送されるシステム。
27. 各公開者から加入者ごとに異なるタイプの医療ケア・データに対して資格のレベルを定義する電子ユーザ・プライバシー・レジスタと通信する管理サーバを更に備え、動作中、医療ケア・トピックに関連する医療ケア・データに対する電子リクエストは、加入者が、前記トピックの医療ケア・データに対して前記加入者に資格を与えるプライバシー・レベルを有する場合だけ、前記メッセージ・フロー・サーバを介してそれぞれの公開者に自動的に電子的に選択的に転送される、請求項２６に記載のシステム。
28. 前記管理サーバは、リクエスト中の加入者から医療ケア・データの公開に対するリクエストを、前記リクエスト中の加入者へ公開を不許可としていない公開者だけに電子的に送信するように構成されている、請求項２７に記載のシステム。
29. 前記ユーザ・プライバシー・レジスタは、定義された一連のプライバシー・レベルから、異なる医療ケア・トピック、加入者及び公開者ごとに前記プライバシー・レベルを相互に関連付ける電子互換性相関データベースを備え、前記システムは、プライバシー・レベルごとに、前記コンピュータ・ネットワークを用いるデータ共用ルールを更に備え、前記データ共用ルールは、公開者が医療ケア・プライバシー規則を準拠するように構成されている、請求項２７に記載のシステム。
30. 前記加入者は、電子トピック・カタログを表示し、前記管理サーバと関連するウェブ・アプリケーションを用いて前記それぞれの加入者の前記プライバシー・レベルと関連して電子トピック・カタログから医療ケア・トピックを選択できるように構成されている、請求項２６に記載のシステム。
31. コンピュータ・ネットワークを用いる協調データ共用システムにおいてデータ共用を制御するコンピュータ・プログラムであって、コンピュータ・プログラムは、
    公開者及び加入者ごとに少なくとも１つのプライバシー・レベルを定義するように構成されたコンピュータ可読プログラム・コードであって、前記少なくとも１つのプライバシー・レベルが、グローバルな一連の定義されたプライバシー・レベルから選択され、前記異なるプライバシー・レベルが、データ・レコードの異なるコンテンツと関連するコンピュータ可読プログラム・コードと、
    データをリクエストしている加入者と、前記定義されたプライバシー・レベルに基づくデータを有する公開者とに対するデータ共用プロトコルを定義するように構成されたコンピュータ可読プログラム・コードと、
    加入者及び公開者のパーティシパント登録と、それらの定義されたプライバシー・レベルとを提供するように構成されたコンピュータ可読プログラム・コードと
    を備えるコンピュータ・プログラム。
32. 選択可能な異なる医療ケア・トピックの加入者・アクセス可能電子トピック・カタログを提供するように構成されたコンピュータ可読プログラム・コードを更に備え、前記選択可能なトピックの各々が、前記それぞれの加入者のプライバシー・レベルと互換性があるプライバシー・レベルを有する、請求項３１に記載のコンピュータ・プログラム。
33. 前記データ・レコードが患者医療ケア・レコードを備え、前記コンピュータ・プログラム製品は、異なる公開者からの医療ケア・データ・コンテンツに対して加入者資格レベルを定義する互換性相関行列を生成するように構成されたコンピュータ可読プログラム・コードを更に備える、請求項３２に記載のコンピュータ・プログラム。

Images