JP5132321B2

JP5132321B2 - データ交換、収集、モニタリングおよび／または警告のためのメッセージ統合システム

Info

Publication number: JP5132321B2
Application number: JP2007549886A
Authority: JP
Inventors: アイゼンバーガー、ジョージ; マカロック、エドガー、サード; リチャーズ、トマス、セカンド
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2005-01-10
Filing date: 2006-01-03
Publication date: 2013-01-30
Anticipated expiration: 2026-01-03
Also published as: WO2006072609A3; TW200705303A; JP2008527519A; US20060168043A1; CN101061485A; WO2006072609A2; TWI374396B; US8306831B2; EP1849114A2

Description

本発明は、コンピュータ・ネットワークを使用したデータ共有に関係し、特にイントラネットおよび／または公衆インターネットでの医療臨床データの共有に適する。

医療通信システムは通例限られたものであり、一般的に複数の機関の間での標準がなく、多数の医療従事者にまたがって医療データにアクセス、追跡、モニタリングおよび／または警告するのは難しい。合衆国内では、６千を超える病院、何十万もの医療者、臨床データの交換を望むその他の関係者も多数いる。データ交換を促す中央データ・レポジトリを利用するデータ共有には技術的、法律的および／または社会的な障害があり、たとえ当該レポジトリが存在しても、常に最新情報を把握することおよび／または中央データ・レポジトリにアクセスすることはほぼ不可能であろう。また、多数の民間組織は、医療システムで治療を受けた患者から患者情報を収集する全国的な（または多国家もしくは全世界的な）レポジトリに反対している。

過去において、医療データを交換する従来のアプローチは、郵便、電話、データ・テープ、ディスク、もしくはファイルのプロジェクト固有のフォーマットおよび／またはポイント・ツー・ポイント・インターフェースでの交換など、人手によるデータの伝達や、データ・マイニング技術を用いてデータ共有を提供することが含まれた。すなわち、一部の従来のシステムは、情報源からデータを抽出し（Ｅｘｔｒａｃｔｉｎｇ）、そのデータを変換（Ｔｒａｎｓｆｏｒｍｉｎｇ）および正規化し、さらに変換したデータをデータ・マイニング用の中央レポジトリにロード（Ｌｏａｄｉｎｇ）することによって（「ＥＴＬ」）、多様なデータ・セットを共有し、特定のイベントに関する情報だけを取り出すように構成されている。残念ながら、ＥＴＬは当該システムを使いにくくすることもあり、その拡張性を制限するかもしれない。

本発明のある実施例は、データの収集、フィルタリング、リンク、交換、モニタリングおよび／または警告の方法、システムおよび／またはコンピュータ・プログラムを提供する。

ある実施例は、多数の医療システムが医療の質のパフォーマンス、医療行為の審査の標準、薬物有害事象、疾病監視（集団発生など）、およびその種の他のものを識別またはモニタリングするのに使える連携データ共有システムに向けられる。ある実施例は患者データの中央レポジトリを必要としない。

本発明のある側面によると、サブスクライバおよびパブリッシャである参加者のコンピュータ・ネットワークを使用して連携的な医療データの交換を促進する方法を提供する。方法は、（ａ）各々が臨床データのレポジトリをもつ参加パブリッシャからの選択臨床データの発行を求める参加サブスクライバの要求を受信するステップと、（ｂ）各パブリッシャが選択臨床データおよび要求元サブスクライバに関してその臨床データの発行を承認するかどうかを判定するステップと、（ｃ）要求された選択臨床データの発行を承認する参加パブリッシャから承認を受けた要求元サブスクライバに選択臨床データを電子的に転送するステップとを含む。

本発明の別の側面は、インターネットベースの管理サーバーと通信するように構成された医療情報パブリッシャに向けられる。パブリッシャはパブリッシャ・ゲートウェイをインストールして構成することによりメッセージ・フロー・サーバーと通信する。メッセージ・フロー・サーバーは他のゲートウェイおよび管理サーバーとつながっている。パブリッシャ・ゲートウェイはその電子的な患者データを受信し、患者データをオープン・スタンダードのメッセージにフォーマット化し、患者データ・メッセージを一定期間パブリッシャ・ゲートウェイのデータベースに電子的に格納するように構成される。パブリッシャは、管理サーバーを使って、（ａ）そのパブリッシャの臨床データを受信できるサブスクライバ、および（ｂ）そのパブリッシャから各サブスクライバが受信できる臨床データを許可および制御する。

本発明のさらに別の側面は、パブリッシャおよびサブスクライバの参加者サイト間の連携医療データ共有を提供および制御するウエブベースのシステムに向けられる。システムは、（ａ）標準化した医療データ・メッセージを使用して、参加医療情報パブリッシャ・ゲートウェイおよびサブスクライバと通信するように構成されるメッセージ・フロー・サーバーと、メッセージ・フロー・サーバー並びにサブスクライバおよびパブリッシャとつながっている管理サーバーとを含み、管理サーバーは参加および／または参加サブスクライバと参加パブリッシャの間のデータ共有通信を制御するように構成される。

本発明の別の側面によると、インターネット上で連携医療データ交換を提供する方法を提供する。方法は、複数の異なる医療パブリッシャとサブスクライバの間で、選択した医療トピックのメッセージ・フォーマット化した通信を提供するステップを含む。各医療パブリッシャは自己の各メッセージ・フォーマット化した医療記録を電子的に格納し、それに対するサブスクライバのアクセスを制御する。この方法では、各パブリッシャはサブスクライバに対する自己のメッセージ・フォーマット化した臨床データの出力パブリケーションを制御するように構成できる。代わりに、この方法はさらに、ハブに管理サーバーを使って、サブスクライバからパブリッシャに発行要求の電子通知を転送し、それに応答して要求元サブスクライバに承認または拒否の電子通知を転送し、管理サーバーとつながっているメッセージ・フロー・サーバーを使ってパブリッシャから承認を受けたサブスクライバにメッセージ・フォーマット化した臨床データを選択的に転送するステップを有してもよい。各パブリッシャは自身のパブリッシャ・ゲートウェイを有することができ、メッセージ・フロー・サーバーはパブリッシャ・ゲートウェイおよびサブスクライバとつながっている。さらに、管理サーバーは、様々な医療データ・トピックをサブスクライバが選択可能なトピック・カタログ、参加者登録データベース、メッセージ・キュー・データベースを有することができ、データベースを使ってパブリッシャ・メッセージを許可されたサブスクライバとだけ共有するように制御する。

本発明の別の側面は、医療用連携データ共有コンピュータ・ネットワーク・システムに向けられる。システムは、（ａ）メッセージ・フロー・サーバーと、（ｂ）患者の医療記録にアクセスできる複数のパブリッシャ参加者であって、各パブリッシャが少なくとも１つのパブリッシャ・ゲートウェイを有し、パブリッシャ・ゲートウェイが標準化されたメッセージの形で医療データをメッセージ・フロー・サーバーに制御可能に提供するよう構成された、複数のパブリッシャ参加者と、（ｃ）メッセージ・フロー・サーバーとつながっている複数のサブスクライバ参加者とを含む。運用に際し、希望のトピックに関連する医療データをサブスクライバがパブリッシャに要求する。各パブリッシャは各サブスクライバの要求に応答してその医療データの発行を承認または拒否するように構成される。承認または拒否は典型的にはウエブ・アプリケーションを使って１度だけ行えるようにできる。承認されれば、当該トピックおよび当該サブスクライバに関する当該パブリッシャからのその後の通信は追加承認なく実施できる。

本発明の別の側面は、多数の機関の間でデータを取得および交換するインターネットベースのシステムに向けられる。システムは、（ａ）参加サブスクライバから参加パブリッシャへの発行要求の依頼を制御するように構成される管理サーバーと、（ｂ）パブリッシャとサブスクライバとの間の通信をルーティングするように構成された管理サーバーとつながっているメッセージ・フロー・サーバーと、（ｃ）各々がメッセージ・フロー・サーバーとつながっている少なくとも１つのパブリッシャ・ゲートウェイをもち、個々のパブリッシャ・ルールに基づいて出力データを提供するように構成された、複数の参加パブリッシャと、（ｄ）管理サーバーに関連するウエブ・ポータルを使って、関心のある選択トピックの発行を複数のパブリッシャに要求するように構成された、複数の参加サブスクライバとを含む。

本発明の別の側面は、ウエブベースの連携データ共有システムを提供する方法に向けられる。方法は、（ａ）参加者のアクセスを管理し、参加サブスクライバだけがシステムにアクセスできるように構成されたハブ・サイトでウエブ・アプリケーションをホストするステップと、（ｂ）複数のサブスクライバからの少なくとも１つのトピック・データ要求をパブリッシャに電子的に通知するステップと、（ｃ）メッセージ・フロー・サーバーでトピック・データと一緒にパブリッシャ・メッセージを電子的に受信するステップと、（ｄ）メッセージ・フロー・サーバーからパブリッシャが承認したサブスクライバにのみパブリッシャ・メッセージを選択的に電子的に転送するステップとを含む。複数のサブスクライバからの少なくとも１つのトピック・データ要求をパブリッシャに電子的に通知するステップは、サブスクライバが要求する各データ要求トピックに関し要求元サブスクライバを識別する通知を転送するステップと、その後各パブリッシャが要求元サブスクライバからのトピック・データ要求を審査して電子的に承認または拒否させるステップとを有してもよい。メッセージ・フロー・サーバーからパブリッシャが承認したサブスクライバにのみパブリッシャ・メッセージを選択的に電子的に転送するステップは、パブリッシャからの、承認を受けたトピック・データ要求と一致するデータを包含するパブリッシャ・メッセージに関してのみ実施できる。この方法はさらに、パブリッシャへのサブスクライバ要求の通知に応答して、各パブリッシャが自己のデータ記録を電子的に審査して、電子データ記録がサブスクライバのデータ要求と一致するかどうかを判定させるステップと、承認されたら、サブスクライバのトピック・データ要求と一致するデータと一緒にパブリッシャ・メッセージをメッセージ・フロー・サーバーに送るステップを有してもよい。

本発明の別の側面は、コンピュータ・ネットワークを使って連携医療データ共有システムを提供するコンピュータ・プログラムに向けられ、コンピュータ・プログラムは、コンピュータ可読記憶媒体に記憶されるコンピュータ可読プログラム・コードを含む。コンピュータ可読プログラム・コードは、（ａ）医療データを要求するサブスクライバおよび医療データをもつパブリッシャに対して、サブスクライバ要求／パブリッシャ承認・拒否通信プロトコルを提供するように構成されたコンピュータ可読プログラム・コードと、（ｂ）参加サブスクライバおよびパブリッシャの参加者登録モジュールを提供するように構成されたコンピュータ可読プログラム・コードと、（ｃ）パブリッシャに要求することができ、選択可能な様々な医療トピックをもった、サブスクライバがアクセス可能なトピック・カタログを提供するように構成されたコンピュータ可読プログラム・コードとを含む。

他のコンピュータ・プログラムは、（ａ）電子的な患者医療データを標準メッセージ・フォーマットにすることにより、患者医療データ・メッセージをサブスクライバが望むフォーマットで生成するように構成されたコンピュータ可読プログラム・コードと、（ｂ）患者データ・メッセージから患者識別子データを選択的に除くように構成されたコンピュータ可読プログラム・コードと、（ｃ）一または複数のサブスクライバに発行するために患者データ・メッセージを選択的に送信するように構成されたコンピュータ可読プログラム・コードとを含む。

特定の種類の実施に関して記述する実施例および／または機能は、他の形態でも実施できる。例えば、実施例が方法として記述される場合、その機能はコンピュータ・プログラム製品および／またはデバイスもしくはシステムとして実施できる。本発明の上記並びにその他の目的および／または側面は、以下で詳しく説明する。

ここで本発明の実施例を、添付の図面を参照しながら以下詳細に述べる。図面を通し同じ数字は同じ要素を表す。図面において、ある層、コンポーネント、または機能を明確にするために誇張していることがあり、破線は別途明記されない限りオプションの機能または操作を表す。さらに、操作（またはステップ）の順序は、別途具体的に示されない限り、請求項または図面で提示する順番に制限されない。使用される場合、「取り付け」、「接続」、「接触」、「結合」等の用語は、別途記載されない限り、直接的または間接的のいずれをも意味することができる。

本明細書で使用される「および／または」という用語は、関連して列挙する項目のうちの一または複数のありとあらゆる組み合わせを含む。

第１、第２等の用語は様々な要素を記述するために本明細書で使用することがあるが、これら要素はこれらの用語に制限されるものではないことは理解されるであろう。これらの用語は単にある要素を別の要素と区別するために使われる。このため、以下に述べる第１要素は、本発明の範囲を逸脱することなく第２要素と呼ぶこともできよう。

本明細書で使用する用語は単に特定の実施例を記述するためのものであり、本発明の制限とすることを意図していない。本明細書では、個数は、それに関連して別途明確に示されない限り、一または複数を意味する。また、「有する」という用語は、本明細書で使用される場合、述べられた機能、エンティティ、ステップ、操作、要素および／またはコンポーネントの存在を示すが、一または複数の他の機能、エンティティ、ステップ、操作、要素、コンポーネントおよび／またはそれらのグループの存在もしくは追加を排除するものではないことは理解されるであろう。

別途定義されない限り、本明細書で使用されるすべての用語（技術用語および科学用語を含む）は、本発明が属する分野の当業者が一般に理解するのと同じ意味をもつ。さらに、一般に使用される辞書で定義されるもののような用語は、本明細書および関連技術に関連してその意味と矛盾のない意味をもつと解釈するべきであり、本明細書でそのように明示的に定義されない限り観念的な意味または厳密すぎる意味で解釈するべきではない。

「パブリッシャ」という用語は、コンピュータ・ネットワークを使って外部サイトおよび／または内部サイトにデータを提供または「発行」できる参加者を意味する。パブリッシャは典型的にはオリジナル・データ・ソースである。「サブスクライバ」という用語は、コンピュータ・ネットワークを使ってトピック・データを要求できる参加者を意味する。パブリッシャは自己のデータまたは他のパブリッシャのデータのサブスクライバにもなれる。「自動的」という用語は、そのように記述される操作の実質的に全部もしくは全部を、人のオペレータの手助けおよび／または手入力がなくても行えることを意味する。「電子的」という用語は、システム、操作、またはデバイスが何か適切な電子媒体を使って通信できることを意味し、典型的にはコンピュータ・ネットワークを使った参加者間の通信のプログラム制御を採用する。「ハブ」という用語は、コンピュータ・ネットワークを使ったパブリッシャとサブスクライバとの間のデータ交換を制御するノードおよび／または制御サイトを意味する。パブリッシャ・サイトが自己のメッセージにアクセスするにはハブは必要ない（すなわち、医療データ要求がパブリッシャ機関内のサブスクライバからのものであり、典型的には、パブリッシャ・ゲートウェイによって制御される、パブリッシャ機関からの機関固有のデータのみに関する場合）。「ＨＩＰＰＡ」という用語は、合衆国の「医療保険の相互運用性と説明責任に関する法律（ＨｅａｌｔｈＩｎｓｕｒａｎｃｅＰｏｒｔａｂｉｌｉｔｙａｎｄＡｃｃｏｕｎｔａｂｉｌｉｔｙＡｃｔ」のことをいう。「オープン・スタンダード」という用語は、一般に公開された（すなわち、非専有の）標準を使う標準化された電子フォーマットのことをいう。現在のオープン・スタンダードのメッセージング・フォーマットの例は、ＨＬ−７、ＭＡＧＥ−ＭＬ、および現在存在するまたは今後開発される関連業界標準コードを含む。例えば、医療用アプリケーションの場合、業界標準コードは、診断（ＩＣＤ−９、ＩＣＤ−１０）、医療行為（ＣＰＴ）、検査結果（ＬＯＩＮＣおよび／またはＳＮＯＭＥＤ）、医薬品（ＮＤＣ、ＲｘＮｏｒｍ）に使われるものを含めることができるが、それだけに限定されない。

「メッセージ」という用語は、定義されたコンピュータ・コード言語フォーマットをもち得るトピックに関する一または複数のデータ要素を意味する。これだけに限定されないが、指令・制御メッセージ、臨床データまたはターゲット・データ発行メッセージ、通知メッセージ、および警告メッセージなど、多様なメッセージの種類がありうる。メッセージはパブリッシャ独自の内部ＩＴコンピュータ・システムから受け取る要素、典型的にはＨＬ７メッセージ・フォーマットを含むことができる。ターゲット・データの発行は、それぞれのゲートウェイによってサブスクライバに送信できるトピック発行メッセージとして行える。トピック発行メッセージは内容定義ヘッダーを含むことができ、これはトピック発行メッセージ内の他のデータ要素とは異なるフォーマットとすることができる（ＸＭＬなど）。典型的には、ヘッダーを付けて送信するデータはメッセージ本文（エンベロープまたはエンクロージャと呼ばれる）に封入され、エンベロープ内に存在するものは一般的にあらゆる任意の業界固有フォーマットのデータとすることができる。トピック発行メッセージ内の他のデータ要素は業界固有フォーマットおよび／またはコードとすることができ、あるいは全参加者間で定義される通信プロトコル／共通言語に関して定義される標準化されたメッセージ・コード／内容にマップできる。例えば、医療データ共有システムの場合、トピック発行メッセージは内容定義要約／ヘッダーを含むことができ、サブスクライバのデータ要求に関連する臨床データ要素を含むことができる。メッセージ・データ要素はそのデータ要素の（典型的には短い）テキスト要約を生成するように構成できる。

本発明の実施例は、コンピュータ・ネットワークを使って実施できる連携医療データ共有システムに特に適する。「コンピュータ・ネットワーク」という用語は、一または複数のローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）を含み、また実施例によっては、プライベート・イントラネットおよび／または公衆インターネット（ワールド・ワイド・ウエブまたは「ウエブ」としても知られる）を含むことができる。本発明の実施例が想定する医療またはその他のデータ共有システムは、一または複数の州システム、地域システム、国家システムおよび／または多国間システムとして実施できる。

「医療データ」および「臨床データ」という用語は交換可能に使われ、事象または患者に関連する治療、医薬、薬または処方箋の用途、検査や検査結果、診断に関する情報、人口統計学的情報、所在地、住所（郵便番号など）、または旅行その他の関連データのいずれか、その組み合わせ、またはそのすべてを含む。医療データは臨床試験、有害薬物事象、疾病監視（伝染の封じ込めまたは警告のためなど）またはその他バイオ・サーベイランスおよび／または医療の質の評価のために使える。本発明の実施例は、医療以外のシステムにも使うことができる。医療以外のシステムはアプリケーション固有データ用のシステムを提供するように構成できる。このため、議論を明確にするために、本発明は本明細書において主に医療システムに関して述べるが、その機能、コンポーネントおよび／または操作はそれに制限されない。

本発明の実施例は議論を完全にするためにＩＢＭ固有の製品に関して述べることにも留意する。しかし、本発明は、他の製品および／または供給者も本発明の実施に使用できるため、それに制限されない。

当業者には認識されるように、本発明の実施例は方法、システム、データ処理システム、またはコンピュータ・プログラムとして具現できる。従って、本発明は全体がソフトウェアの実施例またはソフトウェアとハードウェアの側面を組み合わせた実施例の形態をとることができ、本明細書ではすべてを一般的に「回路」または「モジュール」という。また、本発明は、媒体に具現されるコンピュータ可用プログラム・コードをもつコンピュータ可用記憶媒体上のコンピュータ・プログラムの形態をとることもできる。ハードディスク、ＣＤ−ＲＯＭ、光記憶デバイス、インターネットまたはイントラネットをサポートするもののような伝送媒体、磁気記憶デバイス、あるいはその他の電子的な記憶デバイスを含めあらゆる適切なコンピュータ可読媒体を利用できる。

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

プログラム・コードの一部は、全部を一または複数のユーザー・コンピュータで実行してもよく、独立型ソフトウェア・パッケージとして一部をユーザー・コンピュータで実行してもよく、一部をユーザー・コンピュータで一部をリモート・コンピュータで実行してもよく、または全部をリモート・コンピュータで実行してもよい。後者の状況では、リモート・コンピュータはローカル・エリア・ネットワーク（ＬＡＮ）もしくは広域ネットワーク（ＷＡＮ）でユーザーのコンピュータに接続してもよく、または外部コンピュータに接続してもよい（例えば、インターネット・サービス・プロバイダーを利用してインターネット経由で）。以下詳細に述べるように、典型的には、一部のプログラム・コードは各パブリッシャ・ゲートウェイ・コンピュータで実行し、一部のプログラム・コードはインターネットを使ってゲートウェイとハブ・サーバーとの間を連絡するハブ・サーバー（メッセージ・フロー・サーバーおよび／またはウエブ・アプリケーションもしくは管理サーバーなど）で実行する。

本発明は、本発明の実施例による方法、コンピュータ・プログラム、並びにデータおよび／またはシステム・アーキテクチャ構成のフローチャート図および／またはブロック図を参照して以下一部を説明する。図の各ブロックおよび／またはブロックの組み合わせをコンピュータ・プログラム命令で実施できることは理解されるであろう。これらコンピュータ・プログラム命令を汎用コンピュータ、専用コンピュータ、またはその他のプログラム可能なデータ処理装置のプロセッサに提供することにより、コンピュータまたはその他プログラム可能なデータ処理装置のプロセッサを介して実行する命令がブロックに明記される機能／作用を実施する手段を生み出すようなマシンが構成される。

これらコンピュータ・プログラム命令をコンピュータ可読メモリーまたはストレージに格納して、コンピュータまたはその他プログラム可能なデータ処理装置に、ある特定の方法で機能するよう指示できるようにしてもよい。その場合、コンピュータ可読メモリーまたはストレージに格納された命令は、ブロック明記される機能／作用を実施する命令手段を含む製造物を生み出す。。

コンピュータ・プログラム命令をコンピュータまたはその他プログラム可能なデータ処理装置にロードして、一連の操作ステップをコンピュータまたはその他プログラム可能な装置で行わせて、コンピュータまたはその他プログラム可能な装置で実行する命令がブロックに明記される機能／作用を実施するステップを提供するようなコンピュータ実装プロセスを生み出すようにしてもよい。

ここで、本発明の実施例を図面と関連して述べる。図１は、管理サーバー１１００とつながっているメッセージ・フロー・サーバーを含む例示的な電子連携データ共有システム１０を示す。図示するように、システムは参加者であるパブリッシャ２００とサブスクライバ３００（議論しやすくするためにそれぞれ１つずつ示す）も含む。管理サーバー１１００は、パブリッシャ承認のパブリケーションだけをパブリッシャの入力に応じるサブスクライバに送信またはルーティングするように、参加者のアクセスを制御し、メッセージ・フロー・サーバー１００と通信するように構成できる。管理サーバー１１００の全部もしくは一部の機能はメッセージ・フロー・サーバー１００に組み込める。しかし、典型的には管理サーバー１１００はメッセージ・フロー・サーバー１００とは分離しており、それと電子的に通信する。同様に、２つのサーバーを図示しているが、メッセージ・フロー・サーバーまたは管理サーバーの機能のいずれかを行うのに３つ以上のサーバーを使用することもできる。当業者には機能を単一の物理ノードにまとめられることは認識されるであろう。

各パブリッシャ２００は少なくとも１つのパブリッシャ・ゲートウェイ２００ｇを含むことができる。パブリッシャ・ゲートウェイ２００ｇはメッセージ・フロー・サーバー１００と通信して、（それが内部で許可した）発行用データをサブスクライバ３００に送信する。以下詳細に述べるように、パブリッシャ２００は典型的には付属部門（入院および／または退院など）、医師、検査部、および薬局のプライベート・イントラネットを含む。ゲートウェイ２００ｇは各パブリッシャ２００から臨床データを収集するように構成される。ある実施例では、ゲートウェイ２００ｇは記憶媒体のサイズに基づいて一時的なデータのみを収集するように構成される。

サブスクライバ３００は、ＰＤＡ、無線通信システム（携帯電話など）、パーソナル・コンピュータ、ビジネス・コンピュータ、携帯型コンピュータへの無線メッセージング、電子メール（添付ファイル有りまたは添付ファイル無し）、ボイスメール、サブスクライバに関連したデータベースもしくは記憶媒体への格納、サブスクライバ・ゲートウェイ（図９の３００ｇ）およびその種の他のものの一以上を含む、任意の適切な通信手段によって参加パブリッシャ２００から承認済みの発行臨床データを受信できる。発行データはサブスクライバ３００が選択できるフォーマットでの臨床トピック発行メッセージとして供給できる。サブスクライバ３００は、別の発行データについては、別の発行フォーマットまたは宛先を要求できる。宛先はサイトの設置または構成中に設定しても、またはスタートアップ時もしくは変更要求に応答して管理サーバー１１００が設定を行ってもよい。ある実施例では、発行（パブリケーション）、加入（サブスクリプション）、宛先、およびデータ・フォーマットの条件またはルールは管理サーバー１１００を使って制御／設定できる。

図２に図示するように、システム１０は、関心がありそうな多様なデータのタイプまたは内容のトピック・カタログを含むことができ、これは多様な発行ルールをもつことができる。電子トピック・カタログ１１０１は管理サーバー１１００がサブスクライバ３００およびパブリッシャ２００に表示する総合トピック・カタログ１１０１となりうる。サブスクライバ３００はトピック・カタログ１１０１から関心のあるトピックを選択でき、または既存のトピックが希望の内容、フォーマットおよび／またはセキュリティ・レベルになっていない場合には新たなトピックを作成することができる。希望のメッセージ・フォーマットは、希望のフォーマットを選択する内容制約付きのトピックを作成または選択することによって要求できる。すなわち、トピック・カタログ内で、２つの異なるトピックは同じデータ内容をもってもよいが、要求されるデータをどのように送信するかを指示する希望の出力フォーマットおよび／または通信モードに基づいてトピック・カタログにおけるトピック項目は別になる。

さらに図２を参照すると、例示的な発行サイクルが図示されている。サブスクライバ３００は管理サーバー１１００がホストするポータルでシステムにアクセスし、臨床データの要求３００Ｒを入力する。管理サーバー１１００はシステム・ポータル（管理サーバーのウエブ・アプリケーション）を使ってサブスクライバの発行要求３００Ｒをパブリッシャ２００に転送できる。典型的には、要求は各パブリッシャ２００が人（電子的にではなく）による審査で承認または拒否する。特定のサブスクライバおよびトピックに関する要求は１度だけ承認すればよい。典型的には、管理サーバー１１００は要求通知を送り、パブリッシャが管理サーバーのウエブ・アプリケーションを使って要求通知に応答する。そのため、運用に際し、要求通知メッセージおよび要求応答（それに関するサブスクライバ通知も）は、管理サーバー経由でサブスクライバ／パブリッシャに、およびサブスクライバ／パブリッシャから電子的に移動できる。

ある特定の実施例では、一または複数のパブリッシャ２００は、トピックの一部または全部に対する発行要求を自動的に電子的に承認または拒否できる電子フィルターまたは制約をつけて構成できる。加えて、ある実施例では、パブリッシャ２００は「拒否」の状態にある（トピックによるか、またはサブスクライバのアイデンティティによるかに関係なく）サブスクライバを管理サーバー１１００に予め識別できる。このような状況において、管理サーバー１１００は識別された「ブラックリスト」のサブスクライバおよび／または「トピック」から発行要求を送らないよう構成できる。

パブリッシャ２００がある特定のサブスクライバ３００の発行要求３００Ｒを承認したら、そのゲートウェイに患者に関して収集もしくは集計した、そのトピック（内容定義）要求３００Ｒを満たす随時更新される臨床データをパブリケーション２００ｍとしてメッセージ・フロー・サーバー１００に発行でき、さらに承認を受けた要求元サブスクライバ３００に自動的に転送される。このことは、特定のサブスクライバに対し定義されたデータ内容をもつ特定のトピックに関してパブリッシャ固有の承認済みサブスクリプションとして記述できる。各パブリッシャ２００が特定のパブリッシャパブリケーションを送信する場合、サブスクリプションの承認を受けた多数の承認済みサブスクライバが存在しうる。パブリッシャ２００がトピック・データ２００ｍ付きパブリケーションをメッセージ・フロー・サーバー１００に送信する場合、ほぼ同時に多数の承認済みサブスクライバ３００に「ブロードキャスト」できる。サブスクリプションを取り消すには、各パブリッシャ２００は管理サーバー１１００のシステム・ポータルにアクセスして、一または複数のサブスクライバおよび／または特定のトピックに関するサブスクリプション取り消し命令を送信すればよい。これによって、そのパブリッシャ２００からの将来のパブリケーションの送信（選択したトピックまたは全トピックに関して）がそのサブスクライバ３００に自動的に送られないようにする。

図３は、参加者とサーバー１１００、１００との通信をメッセージベースの通信にできることを示している。図示するように、サブスクライバ３００はトピック・カタログ１１０１から特定のトピックの発行要求３００Ｒを選択（または作成）できる。これにより、管理サーバー１１００がシステム・ポータルのパブリッシャ表示画面に表示できる発行トピック要求３００Ｒの通知が生成される。発行トピック要求３００Ｒは関心のある関係臨床データのトピックのタイトルまたは名前（これには関連のトピックの説明がある）を定義し、要求元サブスクライバを識別する。パブリッシャ２００は要求を承認または拒否して、メッセージを管理サーバー１１００に送ることによって発行要求に応答する。図示するように、各パブリッシャ２００は管理サーバー１１００に承認応答２００ａを送る。承認される場合、管理サーバー１１００はメッセージ・フロー・サーバー１００に指令メッセージ１１００ｃを送って、サブスクライバ３００が承認を受けたサブスクリプションをもち、その承認されたトピックに関して特定のパブリッシャから送られる発行メッセージ２００ｍを受信する権利をもつことをメッセージ・フロー・サーバー１００に通知する。図示するように、サブスクライバ３００からの１回の発行トピック要求に対し、メッセージ・フロー・サーバー１００は様々なパブリッシャ２００から臨床データの多くのトピック発行メッセージ２００ｍを送受信できる。

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

図４は、一部のサブスクライバ３００をパブリッシャ２００の系列機関にできることを示している。メッセージ・フロー・サーバー１００は選択した臨床データをパブリッシャの組織内のサブスクライバ３００（同様に外部のサブスクライバにも）に送信またはルーティングできる。メッセージ・フロー・サーバー１００はパブリッシャ・ゲートウェイ２００ｇまたは別のサブスクライバ・ゲートウェイ３００ｇ（図９）を介してサブスクライバ３００と通信でき、前者の場合、パブリッシャ・ゲートウェイ２００ｇはサブスクライバ・ゲートウェイ３００ｇとしても機能するように二重属性の操作／機能をもつように構成され、従ってサブスクライバ／パブリッシャ共通ゲートウェイ２００ｇｃ（図１０）を利用する。他の実施例では、メッセージ・フロー・サーバー１００は、前述した選択したその電子通信属性を利用して臨床データおよび／または要求された情報をサブスクライバ３００に直接送信できる。サブスクライバ３００は、管理者、医師、科長、または臨床データを望む他のファンクションもしくは人を含むことができる。前述したように、臨床データは、これだけに限定されないが、電子メール、データベースまたは電子記憶媒体へのダウンロードまたは送信、携帯電話およびＰＤＡその他の携帯型コンピューティング・デバイス、パーベイシブ・コンピューティング・デバイスなどの無線通信デバイスまたは電話によるページ、テキストまたは音声のメッセージングを含む、一または複数のフォーマットでサブスクライバに送信できる。例えば、臨床医は自身の医療機関（または他の医療科もしくは専門科）から、特定の症状または処方薬などの選択した基準を示す心臓病患者を知らせてくれる臨床データを受信するように申し込みできる。

この情報は、より迅速な通知ができ、望ましい医療の継続管理ができる携帯通信機器など、任意の適切なフォーマットで送ることができる。別の例では、管理者は、様々な診断の所定の閾値を超える、または医療モニタリング報告の医療標準に関する基準を超える全入院患者の臨床データを要求できる。さらに別の例では、科長は自身の医療機関から、同じ科内の医師が処置した患者で、特定の症状、検査、および／または診断に対して一定の薬を処方したまたは一定の薬を処方しなかった人の通知を含む発行メッセージのトピックへのサブスクリプションを申し込んでもよい。これにより訓練の必要性または患者の予後管理を識別できよう。

システム１０は数多くの参加サブスクライバおよびパブリッシャを含むことができる。図では単一ノードでの１つのメッセージ・フロー・サーバー１００を示しているが、冗長性および／またはサービスに適切なら、複数の当該サーバーおよび／またはノードを使用してもよい。

医療向けの場合、データのパブリッシャの１タイプが典型的には病院、診療所、老人ホーム、リハビリテーション・センター、救急病院、検査部、医師、およびその他の医療従事者、特に監督機関に臨床データの報告義務のある医療従事者である。パブリッシャの他のタイプは独立検査所、薬剤給付管理機関、およびその他臨床リポジトリを含むことができる。

典型的なサブスクライバは、連邦、州、および／または地方（パブリッシャのサイトの地域）の監督機関および／または行政機関、保健所、診療所または病院（パブリッシャでもありうる）、保険会社、製薬会社、研究者、公衆衛生および／または警察施設／機関、およびその種の他のものを含む。システム１０は全米医療情報基盤（ＮＨＩＩ：ＮａｔｉｏｎａｌＨｅａｌｔｈＩｎｆｏｒｍａｔｉｏｎＩｎｆｒａｓｔｒｕｃｔｕｒｅ）、および／または地域あるいは州の医療情報ネットワークの一部として使用できる。

ある実施例では、オブザーバーといえる参加者の第３のカテゴリーが任意に存在してもよい。オブザーバーは標準モニタリング・プロトコルを確立させることができ、それによってオブザーバーは一部もしくはすべてのパブリッシャ２００および／または一部および／またはすべてのサブスクライバ３００に送られおよび／またはそこから送られる臨床データ、データ・メッセージおよび／またはメッセージの要約のコピーを取得できる。加えて、ホスティング・サービスに関して第４の管理カテゴリーの参加者が存在しうる（図示せず）。

インターネットベースのアプリケーションの場合、メッセージ・フロー・サーバー１００、サブスクライバ３００、パブリッシャ２００および／または関連のゲートウェイ２００ｇ、３００ｇは、ＳＳＬ（セキュア・ソケット・レイヤ）および高レベルの暗号化を使って動作するように構成できる。ユーザーまたは参加者を、そのシステムのデータを処理する１組の属性をもつ「組織」に配属できる。システム１０はユーザーの役割を定義し、ウエブ・ポータルで識別される（サインオンしたときなど）特定レベルの権限を付与するユーザーのレジストリをもつ。パブリッシャ２００およびサブスクライバ３００はウエブ・ポータル１０ｐ（図９、１１）および管理サーバー１１００を介してハブ１０ｈと通信し、トピックに関する一または複数のパブリッシャ２００からの臨床データを管理サーバー１１００が制御するメッセージ・フロー・サーバー１００を介して関心をもつサブスクライバ３００に発行する。

図５は、本発明の実施例により管理サーバー１１００およびメッセージ・フロー・サーバー１００を使ってデータの連携共有を促進する操作を表す。図示するように、選択したトピックの発行を求める要求を管理サーバーが受信する（ブロック１０５）。管理サーバーは、サブスクライバが参加パブリッシャ（任意のパブリッシャ、全パブリッシャまたは選択されたパブリッシャだけなど）からデータを受信することを認められているかどうかを評価できる（ブロック１１０）。発行要求をパブリッシャに転送して、各パブリッシャが特定のトピックまたはサブスクライバに関する発行要求を承認または拒否できるようにする（ブロック１１５）。ある実施例では、サブスクライバのトピック要求を管理サーバーが予め選別して、特定のサブスクライバまたはトピックに関して特定のパブリッシャからの「ブラックリスト」または有効な命令が存在するかどうかを見極めることができる。パブリッシャが特定のサブスクライバからの特定のトピックに関する発行要求を承認したら、許可された有効なサブスクリプション・オーダーを成立でき、臨床データは承認を与えるパブリッシャからメッセージ・フロー・サーバー１００を介して許可された要求元サブスクライバに自動的に送られる（ブロック１１６）。管理サーバー１１００はサブスクリプション・メッセージをメッセージ・フロー・サーバーに送信して、サブスクリプションバを開始し、要求者がそのサブスクライバからそのトピックに関する将来のイベントまたはデータの発行を要求しなくても、臨床データをパブリッシャからメッセージ・フロー・サーバーを介してサブスクライバにルーティングさせることができる。

図６は、パブリッシャ２００が行える例示的な操作を示す。図示するように、識別されたサブスクライバおよびトピックに関して、発行要求の通知がパブリッシャのポータル（管理サーバーのアプリケーション）で受信される（ブロック２０１）。通知は任意の表示画面で行えるが、典型的にはパブリッシャの「受信箱」内にある。パブリッシャは各サブスクライバおよび／またはトピック要求に関して発行要求を承認または拒否するかどうかを各々判断できる。パブリッシャは通知を審査して、パブリッシャ独自の設定、基準、ルール、および／または制約に基づいてウエブ・アプリケーション・ポータルに承認または拒否を回答する（ブロック２０２）。要求に対するパブリッシャの承認および／または拒否はウエブ・アプリケーション・ポータルで選択して、管理サーバーからサブスクライバに通知として送ることができる。通知は要求元サブスクライバがサブスクライバのポータルの「受信箱」で見ることができる。

パブリッシャ・ゲートウェイは、集められて、標準化メッセージ・データ・フォーマット、典型的にはオープン・スタンダードのメッセージ・フォーマットに構成された、患者の臨床データ・メッセージ記録をなす電子的な患者データ記録のメッセージ・キュー・データベースとつなげられる。パブリッシャ・ゲートウェイは承認済み発行要求の選択トピックと一致する患者記録データのメッセージを電子的に検索して抽出できる（ブロック２０３）。抽出したパブリッシャ患者データ・メッセージはメッセージ・フロー・サーバーに送信できる（ブロック２０４）。ある実施例では、患者データ・メッセージをフィルタリングして、送信前に個人の識別子などの特定の情報を自動的および／または電子的に除くことができる（ブロック２０５）。オプションのフィルタリングはパブリッシャの規則に基づいて（ＨＩＰＡＡ法のプライバシーに関する規則等の、業務上または取締り上の規則に準拠するため）、またはデータを要求するサブスクライバのアイデンティティおよび／または発行要求されるトピックに基づいて、使用できる。

メッセージ・キュー・データベースは記憶媒体のサイズによって、有限期間の患者データ・メッセージ、典型的には３０日から１２０日の間、さらに典型的には約３０日間の患者データ・メッセージを含むよう構成できる。古いメッセージ・データは、パージしてもよいし、要望に応じて、履歴トレンド分析などその後使用するために、一または複数のパブリッシャ管理の履歴データベースに転送してもよい。古いまたは未使用のデータ（最近、例えば過去３０日から６０日の間に受信された、「使用中」、または最近使用されたとマークされないデータ）はキャッシュ期間の終了時に自動的に電子的に「消去」できる（キャッシュ期間は典型的にはハードウェアの記憶容量で制限される）。定期的にパージする実施例では、先入れ先出し法（ＦＩＦＯ）に基づくパージ・プロトコルを採用できる。運用に際し、パブリッシャおよびシステム１０は比較的最近の臨床データを提供できる一時システムとして機能する。サブスクライバ３００はメッセージを自己の履歴データベースまたはシステムに格納またはキャッシュするリポジトリをもつことができる。このように、
実施例によっては、患者データの中央リポジトリがない。パブリッシャ・ゲートウェイ２００ｇは、以下詳しく述べるようにトピックに対してより完全に応答するために、追加患者データ（研究所、薬局等からの多様な入力の集合体）を受信するまで、抽出した患者データ・メッセージの送信を一時停止できるメッセージ・キャッシュなど、他の回路またはモジュールをもつこともできる。

サブスクライバからの発行要求は、パブリッシャから発行された患者データ・メッセージと同じ標準化メッセージ・フォーマットにすることができる（例、ＨＬ７）。パブリッシャ・データ・メッセージの発行は、患者記録が承認済みサブスクリプション・トピックのデータ内容と一致すると識別されたときからサブスクライバの発行要求まで（典型的には１時間以内、また実施例によっては約１０分以内）、実質的にリアルタイムでパブリケーションを生成できるイベントベースの動作とすることができる。他の実施例では、データ記録の評価を所望の間隔で、所定の評価サイクルまたはその場で適用される評価サイクルで行える。

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

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

特に、プロセッサ１３８、２３８は市販または特注のマイクロプロセッサ、マイクロコントローラー、デジタル信号プロセッサ等でありうる。メモリー１３６、２３６は、本発明の実施例に従い使われる機能回路またはモジュールを実装するのに使うソフトウェアおよびデータを記憶する任意のメモリー・デバイスおよび／または記憶媒体を含んでもよい。メモリー１３６、２３６は、次のタイプのデバイスを含むことができるが、これだけに限定されない：キャッシュ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリー、ＳＲＡＭ、ＤＲＡＭ、および磁気ディスク。実施例によっては、メモリー１３６、２３６は連想メモリー（ＣＡＭ）でもよい。

さらに図７および図８に図示するように、メモリー（および／または記憶媒体）１３６、２３６は、オペレーティング・システム１５２、２５２、アプリケーション・プログラム１５４、２５４、入出力デバイス・ドライバ１５８、２５８、およびデータ１５６、２５６といった、データ処理システムで使用する数カテゴリーのソフトウェアおよびデータを含んでもよい。当業者には認識されるように、オペレーティング・システム１５２、２５２はデータ処理システムと合わせて使用するのに適していればどのオペレーティング・システムでもよく、ＩＢＭ（Ｒ）ＯＳ／２（Ｒ）、ＡＩＸ（Ｒ）、またはｚＯＳ（Ｒ）オペレーティング・システム、あるいはＭｉｃｒｏｓｏｆｔ（Ｒ）Ｗｉｎｄｏｗｓ (登録商標） (登録商標）（Ｒ）９５、Ｗｉｎｄｏｗｓ (登録商標）９８、Ｗｉｎｄｏｗｓ (登録商標）２０００またはＷｉｎｄｏｗｓ (登録商標）ＸＰオペレーティング・システム、Ｕｎｉｘ（登録商標）またはＬｉｎｕｘ（ＴＭ）などがある。ＩＢＭ、ＯＳ／２、ＡＩＸおよびｚＯＳはインターナショナル・ビジネス・マシーンズ・コーポレーションの米国およびその他の国における商標であり、ＬｉｎｕｘはＬｉｎｕｓＴｏｒｖａｌｄｓの米国およびその他の国における商標である。ＭｉｃｒｏｓｏｆｔおよびＷｉｎｄｏｗｓ (登録商標）はマイクロソフト・コーポレーションの米国およびその他の国における商標である。入出力デバイス・ドライバ１５８、２５８は典型的には、アプリケーション・プログラム１５４、２５４が、入出力回路１４６、２４６および特定のメモリー１３６、２３６コンポーネントなどのデバイスと通信するために、オペレーティング・システム１５２、２５２からアクセスするソフトウェア・ルーチンを含む。アプリケーション・プログラム１５４、２５４は本発明の実施例による回路およびモジュールの様々な機能を実装するプログラムの例である。最後に、データ１５６、２５６は、アプリケーション・プログラム１５４、２５４、オペレーティング・システム１５２、２５２、入出力デバイス・ドライバ１５８、２５８、並びにメモリー１３６、２３６に記憶可能な他のソフトウェア・プログラムが使用する静的および動的データを表す。

図７に関して、データ１５６は、本明細書で詳しく述べるように本発明の実施例に従い、アプリケーション・プログラム１５４の回路およびモジュールによる使用のために、多様なサブスクライバまたはトピックからデータの発行要求を受け取るというパブリッシャの意思を定義する参加者またはユーザー・プロファイル型データ１２６を含んでもよい。例えば、系列サブスクライバである病院または診療所は非系列のエンティティと比べて、各関係パブリッシャまたは系列パブリッシャからの記録を受信する資格のレベルを高くできる。他の例では、非系列であるが承認を受けたサブスクライバ（政府機関など）も高いレベルの資格をもつであろう。

図８に関して、データ２５６は電子的な患者データ記録２２６を含むことができる。患者データ記録は、本明細書で詳しく述べるように本発明の実施例に従い、アプリケーション・プログラム２５４の回路およびモジュールによる使用のために、患者データ・メッセージにマップおよびパースされた患者データ記録を有することができる。ある実施例では、パブリッシャが保有する患者データ記録は、例えば、名、姓、社会保障番号、不透明な識別子（発信元のパブリッシャにはトレーサビリティを、患者には間接的なトレーサビリティを提供しながら、患者固有のプライバシーを保護するために使う）、性別、生年月日、住所、電話番号、出生地、血液型、年齢、身長、体重、目の色、髪の色、人種および／または一塩基多型（ＳＮＰ）などの遺伝子特性、検査および／またはテスト並びにその結果、ＯＴＣ（一般市販薬）または処方薬（現在、過去、もしくは現在の発症に処方済み）、予防接種、その他の過去、現在、または処方済みの治療、診断、入退院日、症状、人口統計学的および地理的情報（自宅、居住地および／または勤務地の郵便番号、市、州、最近の旅行に関するコメントまたは所見）、担当医師、職場その他の潜在的に有毒もしくは有害な曝露等を含むことができる。前述したように、何らかの発行の目的で、パブリッシャおよび／または取締り上のローカル規則に準拠するために、メッセージ・フロー・サーバーに（または他の実施例では、メッセージ・フロー・サーバーから）送信する前に患者の個人識別子データをメッセージから除くことができる。この患者データのリストは単に例示目的で挙げており、本発明の実施例は本明細書に記載の属性タイプに限定されないことは理解されるであろう。

さらに図７に図示するように、本発明の実施例によると、アプリケーション・プログラム１５４はユーザー／参加者レジストリ・モジュール１２０、パブリッシャ／サブスクライバ通信プロトコル・インターフェース・モジュール１２４、および／またはサブスクライバがアクセス可能かつ選択可能可能な電子トピック・カタログ・モジュール１２５の一以上を含む。アプリケーション・プログラム１２０、１２４、１２５はローカル・サーバー（またはプロセッサ）および／またはデータベース、リモート・サーバー（またはプロセッサ）および／またはデータベース、あるいはローカルとリモートのデータベースおよび／またはサーバーの組み合わせに配置できる。

さらに図８に図示するように、本発明のある実施例によると、アプリケーション・プログラム２５４は、患者データを患者メッセージ・フォーマットに変換、マップおよび／またはパースできるメッセージ・フォーマット標準化モジュール２２０、パブリッシャ・メッセージ・フロー・サーバー・インターフェース・モジュール２２４、および／または各パブリッシャが自己の患者データに関する自己の発行ルールを定義できる発行ルールまたは制約モジュール２３４の一以上を含む。アプリケーション・プログラム２２０、２２４、２３４は、ローカル・サーバー（またはプロセッサ）および／またはデータベース、あるいはリモート・サーバー（またはプロセッサ）および／またはデータベースに配置できる。

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

図９は、本発明の実施例による操作およびデバイスの例示的な環境を示す。図９に図示されるように、メッセージ・フロー・サーバー１００はハブ環境１０ｈの一部を有することができる。一般的に言うと、ハブ環境１０ｈはパブリッシャにサブスクライバへの内容ベースのルーティングを提供するように構成される。前述したように、ハブ環境１０ｈはメッセージをパブリッシャから許可されたサブスクライバだけに転送して、承認された内容ベース・メッセージをパブリケーション固有の承認を受けたサブスクライバにルーティングするように構成することもできる。システムは参加者が、受信したい（サブスクライバ側）および／または提供してもよい（パブリッシャ側）臨床情報のタイプに関して、内容、フォーマット、および／または宛先を識別できるようにする。

図９に図示するように、ハブ環境１０ｈはメッセージ・フロー・サーバー１００とつながっている管理サーバー１１００を含むことができる。ハブ環境１０ｈはＡＧＰＩ（ＡｎｏｎｙｍｏｕｓＧｌｏｂａｌＰａｔｉｅｎｔＩｄｅｎｔｉｆｉｅｒ（グローバル匿名患者ＩＤ））サーバー１１０９をオプションで含むこともできる。ＡＧＰＩはＪ２ＥＥデバイスとして構成してもよい。当業者には周知のように、Ｊ２ＥＥはコンポーネントベースの多層エンタープライズ・アプリケーションを開発するためのＪａｖａ（登録商標）（ＴＭ）２プラットフォームのエンタープライズ版（Ｊ２ＥＥ）標準である（Ｊａｖａ（登録商標）はサン・マイクロシステムズ社の米国およびその他の国における商標である）。図９に図示するメッセージ・サーバー１００および／または管理サーバー１１０９は、図７に関して上記したデータ処理システムまたはデータベース環境の全部または一部を含むことができる。実施例によっては、ウエブベース管理アプリケーションとも呼べるウエブベース管理サーバー１１００もＪ２ＥＥデバイスとして構成できる。ハブ環境１０ｈは、例えばＷｅｂＳｐｈｅｒｅアプリケーション・サーバー、ＷｅｂＳｐｈｅｒｅＭＱ、Ｔｉｖｏｌｉ（Ｒ）ディレクトリ・サーバー（ＬＤＡＰ）または「ライトウェイト・ディレクトリ・アクセス・プロトコル」、およびＤＢ２（Ｒ）ＵＤＢ（「ＤＢ２ＵｎｉｖｅｒｓａｌＤａｔａｂａｓｅ」：これはＩＢＭ社のｅＳｅｒｖｅｒ（ＴＭ）ｉＳｅｒｉｅｓ（ＴＭ）のオンデマンド機能を強力にしたリレーショナル・データベース管理システム（ＲＤＢＭＳ）である）のような、ＩＢＭ社のＷｅｂＳｐｈｒｅ（Ｒ）製品群から入手できる製品など他の機能も含むことができる。ＷｅｂＳｐｈｅｒｅ、Ｔｉｖｏｌｉ、ＤＢ２、ｅＳｅｒｖｅｒ、およびｉＳｅｒｉｅｓは、インターナショナル・ビジネス・マシーンズ・コーポレーションの米国およびその他の国における商標である。

図９は、ハブ環境１０ｈが複数のパブリッシャ２００_１、２００_２、２００_ｎおよびサブスクライバ３００_１、３００_２、３００_ｎにつながっていることも示している。サブスクライバ３００_１からの特定の選択トピックに関する発行要求に対し、管理サーバー１１００は選択トピックの発行要求の通知を一または複数のパブリッシャ（２つのパブリッシャ２００_１、２００_２として示される）に送り出して、これらパブリッシャから戻る応答を受信する。応答は要求元サブスクライバへの発行を承認するメッセージまたは要求の拒否とすることができる。応答は特定のトピックに関する以前の（または現在有効な）発行の承認の取り消しとすることもできる。次に、メッセージ・フロー・サーバー１００は各パブリッシャから承認された発行メッセージのすべてを要求元サブスクライバ３００_１に送る。管理サーバー１１００は、サブスクライバの要求を潜在的に受ける意思のあるパブリッシャにのみために、参加者および許可または参加のレベルを予め選別できる。パブリッシャおよびサブスクライバへのメッセージ並びにパブリッシャおよびサブスクライバからのメッセージは、ＳＳＬ（セキュア・ソケット・レイヤ）チャネル、暗号化、および／またはその他セキュアなデータ伝送手段を使ってインターネット経由で送信できる。ネットワーク・システムは少なくとも１つのドメイン・ファイアウォール１２００を含むことができる。典型的には、病院ハブおよびサブスクライバ・ファイアウォール１２００（図１２）を含む２以上のファイアウォールを使用する。

ここでも図９を参照して、パブリッシャ・ゲートウェイ２００_１、２００_２、２００_ｎは、特定の患者またはその他望ましい基準に相関させることのできる電子データ記録を収集、集計、および／または受け付ける、それぞれのパブリッシャ参加者の施設内のコンピュータ・システムおよび／または情報技術システムに接続するように構成できる。パブリッシャ・ゲートウェイ２００ｇ_１、２００ｇ_２、２００ｇ_ｎは次のように構成してもよい。（ａ）患者データ・メッセージの発行または通知の前および／または患者データを標準メッセージ・フォーマットの患者データ記録メッセージにマップする前に、関連データを患者データ記録に集計および／または編集できるように、所望の期間中患者データをキャッシュする、（ｂ）発行前に特定の患者情報を識別できなくするまたは患者記録から除く（匿名データおよび／またはプライバシーに関してＨＩＰＡＡ法に準拠したデータにするため）、（ｃ）ローカル・データを標準化フォーマットに変換するために、メッセージ、イベント、および／または一般に受け入れられる医用基準コード（検査結果の項目名およびコード分類「ＬＯＩＮＣ」、国際疾病分類の分類コードＩＣＤ−９、ＩＣＤ−１０等）をマップおよび／または正規化する、（ｄ）ＨＬ７およびＸＭＬデータ・タイプをパースするなど、メッセージのパーシングを行う、および（ｅ）ローカル・ビジネスまたはデータ使用／発行規則を適用する。

実施例によっては、パブリッシャ・ゲートウェイ２００は、不適切に形成されたＨＬ７メッセージを有する電子患者データ記録を電子的に修正し、電子患者データ記録内の非標準のＨＬ７観察メッセージを標準ＨＬ７メッセージに変換し、非標準のＨＬ７観察からの薬剤オーダーを標準薬局オーダー・メッセージに変換し、入院元および退院処置に関するローカル・パブリッシャ・コードをＨＬ７推奨コードおよび／またはデータ・フィールドにマップし、検査の観察に関するローカル・コードを検査／結果に関して一般に受け入れられる業界標準コーディング・システム（ＬＯＩＮＣ）にマップするように構成される。すなわち、パブリッシャ・ゲートウェイは患者データ記録メッセージ内のすべてのフィールドを審査し、非標準の名称またはコードを識別し、ローカルな非標準の名称を、容認されたフォーマットのシステム全体にわたる統一名称に変換できる。運用に際し、パブリッシャ・ゲートウェイ２００ｇはデータを受信し、データを検査し、入りデータの中の不正を識別し、不正を正す新しい文法を作成できる。実施例によっては、オペレータはシステムまたはゲートウェイのデータベースに入力する前に変更を承認できる。別の実施例では、パブリッシャ・ゲートウェイ２００ｇは手動で定義した入力または「オンボーディング」プロセス中に識別した相関スクリプトに従い、入りデータを（スクリプトで）自動的に電子的にマップできる。

サブスクライバ・ゲートウェイ３００は、トピック・データ要求に応答して受信したメッセージのパブリケーションを格納できるリポジトリ・データベース（または特定のサブスクライバもしくはオブザーバーの場合、メッセージおよび／または警告のリポジトリ）を含むか、またはこれにつなげられる。

実施例によっては、ゲートウェイ２００、３００はＪＡＶＡ（登録商標）および／またはＩＢＭＷＢＩコード、その他適切なプログラム・コードを採用できる。パブリッシャ・ゲートウェイ２００は、患者データ・メッセージから個人識別子（名前、社会保障番号等）を除くＸＭＬベースの患者「匿名化ルーチン」を含むことができる。パブリッシャ・ゲートウェイ２００は、患者データ記録をＨＬ７メッセージからＣＤＡＸＭＬドキュメントに変換するドキュメント変換ルーチン、ＨＬ７パーシング（カナダ、トロントに所在のｉＮｔｅｒｆａｃｅｗａｒｅ社のＣｈａｍｅｌｅｏｎを使って実行できるメッセージングＨＬ７ツールキット）、Ｗｅｂｓｐｈｅｒｅビジネス・インテグレーション製品群、ＤＢ２ＵＤＢ、およびＷＢＩコネクタに繋ぐＨＬ７ＴＣＰ／ＩＰソケットも含むことができる。

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

図１１は、連携データ・ネットワーク・システム１０の例示的なアーキテクチャを示す。システム１０はメッセージ・フロー・サーバー１００および患者ネットワーク・ファイアウォール１２００を備えるインターネット・ポータルまたはハブ１０ｈを含む。図示するように、各パブリッシャ・サイト２００ｓは、リンクされた様々な（内部および／または外部）サービス・プロバイダーまたはデータ収集ステーション、例えば、それだけに限定されないが、医療費請求システム２０６（退院または受入診断を提供できる）、検査部２０７（検査もしくはテストの結果またはオーダーしたテスト／評価を提供できる）、薬局２０８（薬剤オーダーの入力のため）、および他の関連データ収集入力、と通信する少なくとも１つのパブリッシャ・ゲートウェイ２００ｇを含むことができる。パブリッシャ・ゲートウェイ２００は、パブリッシャが選択、承認、および／または定義するパブリッシャ固有のビジネス・ルールまたは制約に基づいて医療データ要素をフィルタリング、リンク、およびマップするように構成できる。

ビジネス・ルールの一例は、診断に基づいて推奨テストまたは処置のすべてが完了しているかどうかを確認するために患者記録を点検することである。また、システムは特定の疾病または障害をもつ診断患者を識別して、予後検査結果と相関させて診断を確認することもできる。これらの点検またはルールは患者ケアの改善を推進し、適正な治療を促し、および／または病気の集団発生の管理に役立てることができる。実施例によっては、患者記録の結果またはデータ要約をＩＢＭ社のＷｅｂＳｐｈｅｒｅＭＱを使って迅速かつ信頼性をもって組織内で共有できる。システム１０は、遅い、またはエラーが多くなりがちな従来のカルテ出しより優れた迅速かつ間違いの少ないまたは間違いのないやり方で治療成果を追跡するために使用できる。この種の自動化レポーティングは監査計画または監査要件に遵守しやすくできる。

ゲートウェイ２００ｇは警告レセプター２０９とつなぐことができ、それによってゲートウェイ２００ｇが集めるおよび／または提供するデータを電子的にモニタリングして、一定の異常状態が識別されたら内部および／または外部の関係機関および管理者に警告を発することができる。警告レセプター２０９はゲートウェイ２００ｇと通信するまたはゲートウェイ２００ｇに統合できる、パブリッシャ２００の個別モジュールおよび／またはデータベースとすることができる。例えば、警告レセプター２０９は特定の条件で入院する患者数の増加を検知でき、および／または食中毒診断、一または複数の患者の炭疽菌への曝露もしくは脊髄膜炎の識別、バイオテロリズムへの曝露、特定の薬剤もしくは薬剤のタイプ（中毒性と識別されるものまたは死亡リスクの高いものなど）の処方の増加、薬物有害事象等、蔓延の可能性のある健康問題を識別できる。

図１１は、サブスクライバ（組織またはサイト）３００が、質および／または有害事象の監視または臨床データの分析が可能で、サブスクライバ・ゲートウェイ３００ｇに接続できる一または複数の系列エンティティ（互いにローカルもしくはリモートでありうる）を含むことができることを示す。図示するように、サブスクライバ３００はネットワーク・オフィス３０１、臨床責任者３０２、感染症予防の公的組織／エンティティ３０３を含むことができる。サブスクライバはトピックを作成（要求されたデータのパラメータを定義）し、トピックをサブスクライブおよび／または選択（トピックへの各サブスクライバ固有の関心を定義）できる。

前述したように、サブスクライバ・サイトおよびパブリッシャ２００は、パブリッシャ・モードおよびサブスクライバ・モードのいずれでも動作できる共通ゲートウェイ２００ｇｃ（図１０）を採用したパブリッシャ／サブスクライバ共通サイトにできる。警告レセプター２０９と、パブリッシャ・ゲートウェイ２００ｇおよび／またはサブスクライバ３００は、患者のケアプロセスとケアの質をモニタするため、および図１５に図示するようなレポートを作成するために使える。すなわち、実施例によっては、サブスクライバ３００は受信したデータ記録のローカル・リポジトリを維持でき、そのリポジトリ・データベースに問い合わせルと、カスタム・レポートを作成できる。

図１２は、例示的な連携医療データ共有システム１０の様々なコンポーネントの概略図である。前述したように、システム１０は参加者のアクセスを制御し、メッセージのトラフィックを制御するメッセージ・フロー・サーバー１００と通信するウエブ・ポータル１０ｐを含むことができる。ウエブ・ポータル１０ｐは単一の連合ポータルまたはグローバル・ポータルでも、外国または選択したネットワーク用の個別のポータルなどのいくつかのポータルをリンクしたシステムでも、その種の他のものでもよい。システム１０で参加者はデータ共有ルールを定義し、どのデータを共有するかを選択し、誰と共有するかを決定し、選択したトピックに関してモニタリング、警告、通知、および報告をし、アカウント状況を提供できる。

図１３は、本発明の実施例による例示的なウエブベースのデータ共有システム１０のより詳細なアーキテクチャを示す。図示するように、ハブ１０ｈは中央管理運用アプリケーションを提供するサーバー１１００を有する。管理サーバー１１００はセッション管理、追跡およびロギング・システム管理、作業負荷管理、およびメンバー・サービスを提供するように構成できる。管理サーバー１１００は、トピック・カタログ１１０１、参加者（サブスクライバおよびパブリッシャ）プロファイル１１０２、セキュリティ・ディレクトリ１１０３、発行またはルーティング・セキュリティ・ルール１１０４、および通知１１０５を含め、複数のデータベースを含むことができ、または該複数のデータベースと通信できる。管理サーバー１１００はウエブ・システムに統合するためのいくつかのサブサーバーを含むことができ、例えば、ＩＢＭＷｅｂＳｐｈｅｒｅアプリケーション・サーバーを有することができるＷＡＳ（ウエブ・アプリケーション・サーバー）、Ｔｉｖｏｌｉディレクトリ・サーバー（ＬＤＡＰ）、ＡＧＰＩ（グローバル患者レジストリまたはＩＤ）サーバー１１０９、ＤＢ２サーバー、およびＳＭＴＰ（簡易メール転送プロトコル）サーバー１１１０などであるが、それだけに限定されない。本明細書では「サーバー」と記述したが、他の適切なコンピュータ構成を使用してもよいことに留意する。

トピック・カタログ・データベース１１０１（図１３）は、図１８に示すもののようなサブスクライバ選択可能トピックの電子カタログまたは一覧表（トピック名およびトピックの説明を含んでもよい）とすることができる。トピック・カタログはアルファベット順に提示でき（完全な一覧表が提供される場合など）、または図１８にも図示されるようなキーワード入力を使って検索可能としてもよい。サブスクライバがカタログに載っていないトピックに関するデータを要求したい場合、サブスクライバは「新」トピック項目として要求を入力でき、これは発行ルールを満たすかどうかを確認するために保存して審査できる。カタログに載ってしまえば、サブスクライバはそのトピックに関するデータを要求できるが、ハブ１０ｈ（管理サーバー１１００またはメッセージ・フロー・サーバー１００のいずれか）は以前に確立したサブスクライバおよび／またはパブリッシャの参加ルール等に基づいて、どのパブリッシャ（もしいれば）が新しい（または既存の）トピックに関する医療データの発行要求を送るかを選択できる。

通知データベース１１０５を使って、図１７および図１９に図示するような通知要約を提供できる。これらの図面に図示するように、パブリッシャは、日付、時間、タイプ、発行元、および件名を含めた通知の詳細を見ることができる。パブリッシャは要求元サブスクライバのアイデンティティ／名前、および要求されるトピックを提供する発行要求を審査することもできる。図１７および図１９に図示する表示画面はパブリッシャの「ホーム」画面ビューとして構成できる。

もう一度図１３を参照すると、メッセージ・フロー・サーバー１００は参加パブリッシャから関心のある選択トピックを参加（承認を受けた）サブスクライバに動的に発行および／またはサブスクライブして、発行／サブスクライブ通信プロトコルを実装するように構成できる。メッセージ・フロー・サーバー１００は、トピックベースおよび／または内容ベースのルーティングを提供し、選択情報の要求に応答して動的にサブスクリプションを登録し、トピック名前空間におけるアクセス管理を提供できるＷｅｂＳｐｈｅｒｅＷＢＩ（ＷｅｂＳｐｈｅｒｅＢｕｓｉｎｅｓｓＩｎｔｅｇｒａｔｉｏｎ）メッセージ・ブローカーなどのメッセージ・ブローカーを有することができる。メッセージ・フロー・サーバー１００は、例えば、それだけに限定されないが、構成マネージャー１００１、ユーザー名サーバー１００２、メッセージ・ブローカー１００３、およびキュー・マネージャー１００４といった、一または複数のサブサーバー、クライアント、またはマネージャーを含むことができる。メッセージ・フロー・サーバー１００は、例えば、それだけに限定されないが、メッセージ・フロー・データベース１００５、メタデータ辞書１００６、パブリッシャ・サブスクライバリスト１００７、ユーザー・ノード・サーバー１００８、およびメッセージ・キュー・データベース１００９といった、いくつかのデータベースまたはサーバー、クライアント等を有すること、および／またはそれらと通信することができる。

図１３にも図示するように、管理サーバー１１００は、パブリッシャ・ポータル・サイト２００ｓに現れるウエブ・アプリケーション機能を含めて構成することができる。サーバー１１００はＷＢＩサーバー・エクスプレスを有してもよく、ＷＢＩサーバー・エクスプレスとして構成してもよい。ウエブ・アプリケーションを使うと、ユーザが参加者として登録でき、ＡＣＬ（アクセス制御リスト）の管理、ＵＩＤ／ＰＷＤへのログオン（ユニバーサルＩＤまたはパスワード・アクセスを使って）、ログオフ、プロファイル設定の定義、検索、発行要求の承認、データの要求の受信、および通知イベントの作成が可能である。

パブリッシャ・ゲートウェイ２００ｇは、病院、または薬局、検査部、およびＡＤＴ（入院、退院および転院）等といった他のパブリッシャＩＴ（情報技術）環境もしくはプラットフォームと統合するように構成できる。ゲートウェイ２００ｇは、ＨＬ７のパース／マップ／変換を行い、ＨＬ７メッセージをトピック・フレーミングで正規化し、ＬＯＩＮＣ、ＩＣＤコードをマップし、ウエブ・ポータルでメッセージ・フロー・サーバー１００とインターフェースし、メッセージをキューに入れ、データをデータ・ブローカーにプッシュし、ウエブサービス・インターフェースをハブ１０ｈのグローバル患者レジストリ１１０９に提供するように構成することもできる。ゲートウェイ２００ｇは、例えば、一または複数のローカル辞書２００ｄｂ_１、ＨＬ７メッセージおよびメッセージ・キュー２００ｄｂ_２、並びに指令データベース２００ｄｂ_３といった、複数のデータベースとつながっているおよび／または複数のデータベースを有することができる。

表１は例示的なＨＬ７サポート・イベントをトピックの説明と関連コードと合わせて示す。

追加のＨＬ７メッセージは要望に応じて構成の一部として実装できる。

図１３はウエブ・アプリケーション機能３００ａと通信できるサブスクライバ・ポータル・サイト３００ｓも示す。パブリッシャ・サイトの場合と同様、ウエブ・アプリケーション機能の全部または一部を管理サーバー１１００で行える。ウエブ・アプリケーション機能を使うと、サブスクライバが参加者として登録でき、ＵＩＤ／ＰＷＤへのログオン、ログオフ、プロファイル設定の定義、サブスクライブ、サブスクライブ中止、検索、データ要求の発行、および通知イベントの作成が可能である。ゲートウェイ３００ｇはウエブ・ポータルでメッセージ・フロー・サーバー１００とインターフェースし、入りメッセージをキューに入れ、ストアを開き、ローカルＩＴシステムにインターフェースするように構成できる。図１３に図示するように、ゲートウェイ３００ｇは、メッセージ・キュー・データベース３００ｄｂ_１、受信したメッセージのローカルＨＬ７リポジトリ３００ｄｂ_２、および指令データベース３００ｄｂ_３を含め、複数のデータベースを含むこと、またはそれらと通信することができる。

図１４はレガシーまたは既存のＩＴシステム５００およびその環境内で使用する様々なコードまたは分類体系をもつ既存の医療情報パブリッシャ・サイト２００ｓを示す。例えば、サイト２００ｓでは、薬局２０８が医薬品コード（ジェネリック／市販）を使用でき、検査部２０７はＬＯＩＮＣコードを使用でき、管理入力記録２０６（入院、退院および転院、または患者の治療記録）はＣＰＴ４コードを使用できる。これらの異種のコード／分類を典型的にはＨＬ７メッセージを使って、標準メッセージ・フォーマットに変換できる。

表２は、本発明の実施例によるメッセージを使用してモニタリングおよび／または追跡できるデータ要素を示す。

これら例は単に例示のためのものであり、トピック・データ・カテゴリおよび要素の種類は例に示すものに限定されないため、本発明の範囲を制限するものではない。

図１５は、特定の参加者の監視またはビジネス上のニーズもしくは要望のために編集できる様々なイベントのデータ・フロー要約を示す。図示するように、日付別およびイベント／健康問題別の集計メッセージのチャートを提供できる。当該情報を使用して、特殊な観察（呼吸器系ウイルステスト結果など）のためにフラグを立てることのできる対象母集団を識別すること、または臨床警告を発することができる（急性心筋梗塞の患者が入院から特定の時間内にβ遮断剤の投薬をオーダーしたと識別されなかったときなど）。レポートは様々な現場の用途に応じてカスタマイズおよび／または自動的に作成できる。図１８はポータル１０ｐを使ってパブリッシャ・ゲートウェイ２００ｇでトピック名別に内部のパブリッシャ固有のメッセージを見るための活動要約のサンプル・ビューを示す。

表３は、参加機関、特に政府機関が追跡して、医療の質および／または健康上のトレンドを評価できる「主要」データ要素のいくつかの例を示す。

図１６は、患者の検査データ２００ｌ、薬局データ２００ｐ、および診断データ２００Ｄという３つのデータ・メッセージ・セグメントを含むメッセージ２００ｍの例である。メッセージ２００ｍは発行の承認を受けており、要求元サブスクライバに送信するためにメッセージ・フロー・サーバー１００に提出された。メッセージはトピック「発作診断」を識別し、「発作診断」の関連のルール名、プロバイダー識別子、およびグローバル患者ＩＤ番号（患者ＩＤ）を含み、メッセージ・タイム・スタンプが付く。

図１９はパブリッシャの表示および使用モードを示し、図２０は発行モードで、パブリッシャがその明細を付けて発行しているパブリケーションを見られることを示す（また、パブリッシャは望む場合パブリケーションを取り消すことができる）。パブリッシャはパブリケーションを作成する（トピック・サブスクリプションに関するデータの提供に同意する）ことができ、パブリケーションを見る（パブリケーションの明細−全部のまたは選択した記録−を一覧表示する）ことができ、パブリケーションを削除する（パブリッシャが既存のパブリケーションを削除するのを認める）ことができる。参加パブリッシャは一般的にすべての患者に関して連続的にすべてのサポート・データを自己のゲートウェイ２００ｇにストリームできる。臨床システムは一般的にデータをＨＬ７メッセージの形でストリームする（送る）ことができる。そのそれぞれのゲートウェイ２００は前述したように希望する期間中その患者メッセージを格納できる。

図２１は、サブスクライバ・モードにするようにユーザーが電子的に選択できることを示す。図２１は、サブスクライバが関心のある医療情報を取得するために識別または選択できる選択トピックのいくつかの明細（「トピック定義明細」）を示す（サブスクライバが定義されるルールに従いそのことを許可されている場合）。トピックは、トピック・トリガー・イベント（疾病診断の「ＡＭＩ」または急性心筋梗塞として示されている）と、一致する薬剤オーダーを示す記録だけが返信データに含まれるようにする関心のある項目（アスピリンの薬剤オーダーとして示されている）と、人口統計学的データに関心があるかどうか、または要求がそれによってさらに制限されるかどうかとを含む。トピックが作成されて、トピック・カタログに格納されると、各サブスクライバの使用資格（プライバシー規定または資格）がトピックと適合する限り、すべてのサブスクライバはそれを使うことができる。

システム１０は、参加者が送信データの内容を制限できるフィルターを提供する。デフォルトで、典型的には、すべてのフィルターが適用され、サブスクライバはシステムがサポートする全種類のデータを受信する。参加者は一または複数のフィルターを「ターンオフ」または選択解除できる。その場合、システム１０はトピック・イベントと一致するデータおよびフィルターをかけられなかったカテゴリーのデータを送ることができる。

「トピック・イベント」機能の主な目的は、関係あるデータをもつ患者記録を選択することである。トピック・イベント機能はデータの内容にも影響を与えることができる。例えば、トピック・イベントの最初の発生は送られるメッセージの始めの括弧をしるし、最後のトピック・イベントの最初の発生は送られるメッセージの終わりの括弧をしるす。トピック・イベントを突き合わす順番は一般には考慮されない。他のルールがこのプロシージャに優先しない場合、始めと終わりの括弧の間に発生するすべてのメッセージが送られることになる。トピック・イベントが診断の場合、始めの括弧を入院にでき、終わりの括弧は退院にできる（典型的には全患者がヒットする）。サブスクライバは期間を指定することによって期間を制限できる。期間が識別される場合、評価は入院から始まり、タイムリミットに達すると終了する。すべてのトピック・イベントと指定される人口統計学的データが指定の時間中に一致しない場合、データ・メッセージ記録は送られない。すべてのトピック・イベントが一致する場合にデータを送ることができる。ただし、典型的には、参加者はいつデータを送るかは指定できない。

サブスクライバからのトリガー・イベントが（メッセージ・フロー・サーバー１００を介して）パブリッシャで受信されたら、パブリッシャは患者の格納されたメッセージおよびその後のメッセージを評価して、患者がすべての指定基準を示すかどうかを確認する。

図２２は、「表示」ボタンでアクセスできるトリガー・イベント・フィールドに関する詳細な情報の表示画面である。図示するように、診断名「ＡＭＩ」は３つのＩＣＤ−９コード、４１０．０１、４１０．２１、４１０．７１に関連する。この要求されたトリガー・イベントに基づいて、これらコードの一以上に一致する記録を含めることができる。診断に関して、参加者はすべての関係するバリエーションおよび有効なＩＣＤ−９コードを定義するべきである。同様に、図２３は、アスピリンの薬剤オーダーに関する詳細な情報を関連の表示ボタンで取得できることを示す。図示するように、薬剤名識別子「アスピリン」の場合、「アスピリン」または「ａｓａ」で処方される薬をもつ記録が含まれることになる。

典型的には、システム１０はオーダーＩＤおよびオーダーからの関連ＬＯＩＮＣ、ＣＰＴ、またはＩＣＤ−９コードを包含する検査および処置の観察／結果メッセージを受信できる。参加者（サブスクライバ）が検査または処置のオーダーに関するデータを欲しい場合、検査または処置の結果を追加データのトピック・イベント・カテゴリーとして指定するべきである。イベントが検査結果で定義されると、参加者は対応するＬＯＩＮＣコードを使って検査の所望のバリエーションのすべてを指定するべきである。参加者はトピック・イベントに基づく結果の基準も指定できる。イベントが処置の場合、参加者は指定される各処置の有効値である処置の所望のバリエーションのすべてを指定するべきであり、対応する有効なＩＣＤ−９、またはＣＰＴコードをつけるべきである。参加者はＩＣＤ−９コードおよび／またはＣＰＴコードを使用するかどうかを指定できる。

本発明の実施例は質およびコンプライアンスの報告、並びにＣＤＣ（米国疾病管理予防センター）、ＦＤＡ（食品医薬品局）、ＮＩＨ（米国国立衛生研究所）、およびＣＭＳ（米国医療保険センター）のような連邦および州の機関との臨床データの共有を自動化するために使うことができる。連携データ共有システムに参加する可能性のある他の連邦機関には、ＤＯＤ（米国国防総省）、ＦＡＡ（連邦航空局）、ＦＢＩ（米国連邦捜査局）、米国国土安全保障省等が含まれる。実施例によっては、本発明のシステムは、ＩＣＤ、ＣＰＴ、ＬＯＩＮＣ、およびＨＬ７を介するＮＤＣなど、多くのプロバイダー設定で利用できる既存の電子データを利用できる。

図２４は、本発明の実施例を使って薬物有害事象（ＡＤＥ）を識別できることを示す。ゲートウェイ２００ｇは薬物有害事象を識別するように構成できる。実施例によっては、識別された薬物有害事象のメッセージ・データを、専用のデータベースおよび／または警告レセプター（図１１の２０９）に保持できる。パブリッシャ・サイト２００_２でＡＤＥを検出すると、ハブ１０ｈから他のパブリッシャ２００および／またはサブスクライバ３００に自動化された電子警告２００Ａを送ることができる。警告２００Ａは、制約ベースのルールを使って選択した参加者に送るメッセージ統合警告としてフォーマット化できる。ルールはトピック・カタログ内の関連の健康トピックのサブスクライバに警告２００Ａを選択的に送るように設定できる。サブスクライバの例は、前述したメッセージング・システムを使って概ねリアルタイムで、担当医師および／または病院、製薬メーカー、臨床試験の管理者、別の代替薬の競合メーカー、または政府機関（ＣＤＣ、ＦＤＡ等）を含むことができる。

図２５は、本発明の実施例を使って病気の集団発生をモニタリングおよび／または識別できることを示す。ＡＤＥ警告の場合と同様、病気の集団発生、特定の診断または曝露の観察が、参加サブスクライバ３００の全部または一部に対する病気／曝露警告２００Ａ’をトリガーできる。前のとおり、警告２００Ａ’を制約ベースのルールに基づいて選択したサブスクライバに送ってもよい。例えば、一部の参加サブスクライバ（政府機関など）は、パブリッシャが死亡率の上昇、公衆衛生リスク、伝染性と考えられる病気、共通の診断をされた患者数の増加（異常な集団発生）、および／またはバイオテロリズム・イベントまたは生物兵器に関連する病気または曝露にかかった患者を識別する場合、迅速な通知に特に関心をもつであろう。例えば、システムは、チフス、結核、ポリオ、天然痘、ペスト（腺ペスト）、エボラ出血熱、マールブルグ病、鳥インフルエンザ、西ナイルウイルス、ＳＡＲＳ（重症急性呼吸器症候群）、肝炎、およびＨＩＶを含むが、それだけに限定されない、ウイルス性、細菌性、および／または原生動物により引き起こされる病気の新たなあるいは予期しない増加をモニタリングおよび識別できる。システムは、炭疽菌曝露、食中毒、大腸菌曝露、クロイツフェルト・ヤコブ病、放射能曝露、リシン曝露、アスベスト曝露、および鉛曝露など、バイオテロリズム・イベントもしくは生物兵器、または環境災害もモニタリングおよび識別できる。潜在的な生物兵器のより完全なリストはＣＤＣのウエブサイトｗｗｗ．ｂｔ．ｃｄｃ．ｇｏｖ／ａｇｅｎｔ／ａｇｅｎｔｌｉｓｔ．ａｓｐで閲覧できる。

警告２００Ａ’はパブリッシャ発信元２００からハブ１０ｈを経由してサブスクライバ３００に実質的にリアルタイムで送ることができる。特定の実施例では、パブリッシャから一または複数の承認を受けたサブスクライバへのデータ送信の周期性は、サブスクライバの要求および／またはパブリッシャの関係あるデータの収集によって変えることができる。パブリッシャ２００は、患者データをストリームし、データを概ねまたは実質的に連続的に相関させて（電源またはコンピュータのダウンタイム、障害、または停電に関わらず連続的にそうしてもよい）、入院、検査、および／または退院の時点で疑われる病気を速やかに識別できるように構成できる。

モニタリングを利用して、規制機関および／または保険会社などの支払者に概ねリアルタイムの病気のモニタリングを提供できる。支払者による早期検出およびモニタリングで、特に早期発見および病気管理が費用の削減、寿命の延び、および／または死亡率の低下に有益である病気の場合、潜在的に医療費コストを削減しながら、患者を適切なまたはより積極的な治療プログラムまたは療法に委ねることができる。

本発明の実施例を使用して、患者データを異種の臨床システム全体（システム間およびシステム内）で統合し、質の審査および監視を提供し、医療処置中に生じうる過誤の数を潜在的に減らすことができる。システムは診療行為、経過変化のモニタリング、および費用分析などのビジネス関連データの提供にも使用できる。単一のパブリッシャが複数のサブスクライバをサポートして、前述したように様々なフォーマットで臨床データを発行し（ＨＬ７メッセージ、短いテキストメッセージ、電子メール等を使うなどして）、ＰＤＡ、パーソナル・コンピュータ、メインフレーム（リポジトリ・データベースに直接発行する）、携帯型無線通信機器、携帯電話／通信等のなどさまざまなデバイスに発行できる。

発行側サイト（データ発信元の組織）は自己の患者データの発行を制御でき、サブスクライバ（データの審査組織）のデータ要求を承認または拒否できる。パブリッシャは認証および暗号化に高セキュリティ標準を使って、患者データ（適切なら直接識別できない患者データ）を送信することにより、ＨＩＰＡＡ法のプライバシーに関する規制を遵守できる。

システムは薬局、検査部、および入院／退院システムを統合し、関係あるデータ・ストリーム（ＨＬ７データ・ストリームなど）を収集し、比較的包括的な記録を承認されたサブスクライバに転送できるように患者データを相関させることができる。システムは、承認されたデータだけを合意された方法（患者の識別子データがないなど）で安全に発行することを制御および／または検証するように構成する。

システムは要求されるデータを内容（医療システムの臨床トピック）に基づいてルーティングする「パブリッシュ・サブスクライブ」プロトコルと、プライバシーおよび／または許可レベルにリンクさせるサブスクリプション資格を使用できる。アーキテクチャは比較的柔軟で拡張性があり、参加者のサイトで採用しやすいように構成する。

前記事項は本発明の例であり、本発明を制限すると解釈してはならない。本発明の少数の例示的な実施例を説明してきたが、当業者には、本発明の新規な教示および利点から実質的に逸脱することなく例示的な実施例に数多くの変更を行えることは容易に認識されるであろう。従って、当該変更のすべては請求項に定義される本発明の範囲内に含まれることが意図される。請求項において、〜するための手段という言い回しが使用される場合、これは、述べられる機能を遂行するものとして本明細書に記載された構造をカバーし、更にその構造的な均等物だけでなく均等の構造もカバーすることを意図する。従って、前記事項は本発明の例であり、開示された特定の実施例に制限されると解釈してはならず、また開示された実施例の変更およびその他の実施例を請求項の範囲に含むことを意図していると理解されるべきである。本発明は請求項によって定義され、請求項の均等物はそれに含まれる。

本発明の実施例による連携データ交換を提供するのに使うコンピュータ・ネットワーク・システムの概略図である。本発明の実施例による例示的な発行サイクルを示す図１に図示するシステムの概略図である。本発明の実施例により、サブスクライバの選択したトピックおよび、１サブスクライバと複数の異なるパブリッシャ間の例示的な発行サイクルを示す図１に図示するシステムの概略図である。本発明の実施例により、データを発信元であるパブリッシャのパブリッシャ・ゲートウェイに入力でき、発信元パブリッシャ内のエンティティまたは発信元パブリッシャに関連するエンティティにパブリケーションを（多様な出力フォーマットで）送り返すことのできることを示す図１に図示するシステムの概略図である。本発明を実施するために使える例示的な操作のフローチャートである。本発明を実施するために使える他の例示的な操作のフローチャートである。本発明の実施例によるデータ処理システムのブロック図である。本発明の実施例によるデータ処理システムのブロック図である。本発明の実施例による連携コンピュータ・ネットワーク・システムの概略図である。本発明の実施例によるハブのコンポーネントの概略図である。本発明の実施例によるネットワーク接続したシステムの例示的なシステム・アーキテクチャの概略図である。本発明の実施例による一定のシステムの追加的な特徴の概略図である。本発明の実施例によるパブリッシャおよびサブスクライバとインターフェースするハブを含むシステムの概略図である。本発明の実施例による患者記録データのメッセージ統合システムの概略図である。本発明の実施例により生成できるトピック・イベントのデータ要約のグラフである。本発明の実施例による１患者の多様なデータ記録を含むサンプル・メッセージである。本発明の実施例による１パブリッシャの例示的なコンピュータ・ネットワーク（典型的には、ウエブ）ポータルの表示画面のプリントアウトである。本発明の実施例によるコンピュータ・ネットワーク・ポータル上でアクセス可能な例示的なトピック・カタログの表示画面のプリントアウトである。本発明の実施例による管理用アプリケーションからのまたは管理用アプリケーション上の例示的なパブリッシャ「ホーム」ビューの表示画面のプリントアウトまたはビューの例である。本発明の実施例による管理用アプリケーションからのまたは管理用アプリケーション上の例示的なパブリッシャ「ホーム」ビューの表示画面のプリントアウトまたはビューの例である。本発明の実施例による発行トピックを見るのに使えるパブリッシャの画面ビューの例である。本発明の実施例による発行トピックを見るのに使えるパブリッシャの画面ビューの例である。本発明の実施例による発行トピックを見るのに使えるパブリッシャの画面ビューの例である。本発明の実施例による薬物有害事象の警告を識別および生成するのに使われる医療システムの概略図である。本発明の実施例による病気の集団発生、公衆衛生リスク、環境災害および／またはバイオテロリズムのイベントを識別し、識別する警告を発するのに使われる医療システムの概略図である。

Claims

臨床データの発行を複数のパブリッシャ・コンピュータ（以下、「パブリッシャ」という）に求めるサブスクライバ・コンピュータ（以下、「サブスクライバ」という）および臨床データのリポジトリをもつパブリッシャのコンピュータ・ネットワークを使って医療データの連携交換を促進する方法であって、
管理サーバが、サブスクライバからの医療データの要求を受信するステップであって、前記要求は、電子カタログから選択された臨床データ・トピックの発行のための要求である、前記受信するステップと、
前記管理サーバが、許可されたデータ・アクセス・レベルを定義するパブリッシャの電子レジストリ及び／又はパブリッシャの許可されたレベルに基づいて前記要求を電子的にフィルタリングすることによって、前記サブスクライバからの前記医療データの前記要求を前記複数のパブリッシャのそれぞれに転送するステップと、
前記複数のパブリッシャのそれぞれが、前記サブスクライバから要求された前記医療データに関して自己の医療データの発行を、前記選択された臨床データ・トピックに基づいて承認又は拒否をできるようにするステップと、
前記医療データの前記発行が承認されることに応じて、前記発行を承認した各パブリッシャが、前記要求された医療データを、前記管理サーバとつながっているメッセージ・フロー・サーバに送信するステップと、
前記メッセージ・フロー・サーバが、前記発行を承認した各パブリッシャから送信された医療データを、各パブリッシャに関してサブスクライバ固有の許可されたトピック・サブスクリプションに従い要求元の前記サブスクライバに転送するステップと
を含む、前記方法。
前記管理サーバが、当該管理サーバからアクセス可能なトピックの電子カタログを前記サブスクライバに提供するステップであって、各トピックが関心のある定義されたデータ内容をもつ、前記提供するステップと、
前記サブスクライバが、前記電子カタログ内の既存のトピックが選択されることに応じて前記選択されたトピックに関する前記臨床データの要求を前記管理サーバに送信するステップと
をさらに含む、請求項１に記載の方法。
前記サブスクライバが、選択臨床データの要求に関連する関心のある新トピックを作成するステップをさらに含み、前記作成された新トピックは前記電子トピック・カタログ内に格納される、請求項１に記載の方法。
前記パブリッシャのそれぞれがパブリッシャ・ゲートウェイを備えており、
前記要求された医療データを前記メッセージ・フロー・サーバに送信するステップが、
前記要求された医療データを前記パブリッシャ・ゲートウェイから前記メッセージ・フロー・サーバに送信するステップ
を含む、請求項１に記載の方法。
前記要求された医療データをメッセージ・フロー・サーバに送信するステップ前に、各前記パブリッシャ・ゲートウェイが、個人的な患者識別子を削除するステップをさらに含む、請求項４に記載の方法。
コンピュータ・ネットワークを使って医療データの連携交換を促進するデータ共有システムであって、
臨床データの発行を各パブリッシャ・コンピュータ（以下、「パブリッシャ」という）に求めるサブスクライバ・コンピュータ（以下、「サブスクライバ」という）と、
臨床データのリポジトリをもつ複数のパブリッシャと、
前記サブスクライバからの医療データの要求を受信する管理サーバであって、前記要求は、電子カタログから選択された臨床データ・トピックの発行のための要求である、前記管理サーバと、
前記複数のパブリッシャのそれぞれからの医療データを受信し、且つ当該受信した医療データを前記臨床データの発行を求めたサブスクライバに転送するメッセージ・フロー・サーバと
を備えており、
前記管理サーバが、サブスクライバからの医療データの要求を受信し、前記要求は、電子カタログから選択された臨床データ・トピックの発行のための要求であり、
前記管理サーバが、許可されたデータ・アクセス・レベルを定義するパブリッシャの電子レジストリ及び／又はパブリッシャの許可されたレベルに基づいて前記要求を電子的にフィルタリングすることによって、前記サブスクライバからの前記医療データの前記要求を前記複数のパブリッシャのそれぞれに転送し、
前記複数のパブリッシャのそれぞれが、前記サブスクライバから要求された前記医療データに関して自己の医療データの発行を、前記選択された臨床データ・トピックに基づいて承認又は拒否をできるようにし、
前記医療データの前記発行が承認されることに応じて、前記発行を承認した各パブリッシャが、前記要求された医療データを、前記管理サーバとつながっている前記メッセージ・フロー・サーバに送信し、
前記メッセージ・フロー・サーバが、前記発行を承認した各パブリッシャから送信された医療データを、各パブリッシャに関してサブスクライバ固有の許可されたトピック・サブスクリプションに従い要求元の前記サブスクライバに転送する、前記データ共有システム。
前記管理サーバが、当該管理サーバからアクセス可能なトピックの電子カタログを前記サブスクライバに提供し、ここで、各トピックが関心のある定義されたデータ内容をもち、
前記サブスクライバが、前記電子カタログ内の既存のトピックが選択されることに応じて前記選択されたトピックに関する前記臨床データの要求を前記管理サーバに送信する、請求項６に記載のデータ共有システム。
前記サブスクライバが、選択臨床データの要求に関連する関心のある新トピックを作成し、ここで、前記作成された新トピックは前記電子トピック・カタログ内に格納される、請求項６に記載のデータ共有システム。
前記パブリッシャのそれぞれがパブリッシャ・ゲートウェイを備えており、
前記パブリッシャ・ゲートウェイが、前記要求された医療データを前記メッセージ・フロー・サーバに送信する、請求項６に記載のデータ共有システム。
各前記パブリッシャ・ゲートウェイが、前記要求された医療データをメッセージ・フロー・サーバに送信するステップ前に、個人的な患者識別子を削除する、請求項９に記載のデータ共有システム。