(57)【要約】  互いに異なるデータフォーマットまたは規格を有する複数のローカルデータベースを効率的にネットワークにリンクさせるシステムおよび方法であって、コンテンツベースのルータが、各データベースとネットワーク「パーティライン」バスとの間に提供され、各データベースからのデータを共通のカノニカルフォームまたはフォーマットに翻訳して、ネットワーク内のコンテンツベースのルータ間の全ての情報を共通のカノニカルフォームに準拠させ、例えば情報が最初にネットワークに入る際等に、単一の規格またはメカニズムに応じて検証するようにする。さらには、トラッキングまたは監査メカニズムが提供され、ここでは、最初にネットワークに入るとき各情報アイテムは固有のネットワーク識別子を提供され、さらに、ローカルデータベースに対応するコンテンツベースのルータのルータ識別子および情報アイテムから生じる、またはアクセスする各ローカルデータベースからローカル識別子を提供される、または関連付けられる。【選択図】  図１
2011501834.tif 000002
【特許請求の範囲】
【請求項１】
システムであって、
各々がデータベースを有し、異なる情報規格に準拠している複数の実体と、
各々が前記複数の実体の少なくとも１つに割り当てられている複数のコンテンツベースのルータと、
第１のカノニカル規格と、
データが前記第１のカノニカル規格に準拠しているか否かを検証するメトリックとを備え、
前記複数のコンテンツベースのルータはネットワークを形成するよう接続され、
前記複数のコンテンツベースのルータ間の前記ネットワーク内の通信は前記第１のカノニカル規格に準拠しており、
前記複数の実体の各々は、前記ネットワークと、対応するコンテンツベースのルータを介して通信し、
前記複数のコンテンツベースのルータの各々は、前記複数の実体のうち対応するものからの情報を、前記第１のカノニカル規格に準拠する第１のフォームに変換し、前記メトリックに応じて前記変換された情報を検証し、
前記複数のコンテンツベースのルータの各々は、前記第１のカノニカル規格に準拠する情報を、前記コンテンツベースのルータが割り当てられている対応する実体の前記情報規格に準拠するフォームに変換するシステム。
【請求項２】
前記複数のコンテンツベースのルータは、前記ネットワークの他のコンテンツベースのルータへのブロードキャスト通信、および、前記ネットワークの他のコンテンツベースのルータへの直接ルーティングの通信の両方をサポートするよう構成される請求項１に記載のシステム。
【請求項３】
前記複数のコンテンツベースのルータの各々は、割り当てられた前記実体からの新たな通信を受信して、前記新たな通信への固有のネットワーク識別ラベルを取得するよう構成される請求項２に記載のシステム。
【請求項４】
前記複数のコンテンツベースのルータの各々は、当該コンテンツベースのルータを介して前記ネットワークと前記コンテンツベースのルータが割り当てられた前記実体との間で転送された各通信について、当該コンテンツベースのルータおよび対応する実体のうち少なくとも１つを識別するローカル識別ラベルを取得し、
前記ローカル識別ラベルを前記通信に関連付け、
前記通信のコピーと前記ローカル識別ラベルのコピーとを格納し、
前記ローカル識別ラベルを前記ネットワークの少なくとも１つの他のコンテンツベースのルータへ送信するよう構成される請求項３に記載のシステム。
【請求項５】
当該コンテンツベースのルータは、他のコンテンツベースのルータによる通信に関連付けられたローカル識別ラベルを受信して格納するよう構成される請求項４に記載のシステム。
【請求項６】
前記少なくとも１つの他のコンテンツベースのルータは、ａ）対応する割り当てられた実体と前記ネットワークとの間で前記通信を転送したコンテンツベースのルータ、または、ｂ）識別ラベルをキャッシュするネットワークコアの少なくとも１つである請求項４に記載のシステム。
【請求項７】
前記第１のカノニカル規格は、前記ネットワーク内のデータの構造的およびセマンティックな標準化または正規化を可能とする請求項１に記載のシステム。
【請求項８】
前記第１のカノニカル規格はヘルスケアを対象とする請求項７に記載のシステム。
【請求項９】
前記複数の実体はヘルスケアサービス実体であり、前記情報は患者のヘルスケア情報を含む請求項１に記載のシステム。
【請求項１０】
システムのネットワーク内のデータを正規化する方法であって、
複数のコンテンツベースのルータの各々を、各々が異なる情報規格に準拠している複数のデータベース実体のうち対応する１つに割り当てる段階と、
前記複数のコンテンツベースのルータ間にネットワークを形成する段階と、
前記複数のコンテンツベースのルータのうち、第１のコンテンツベースのルータが、対応する割り当てられた第１のデータベース実体から第１の通信を受信する段階と、
前記第１のコンテンツベースのルータが、前記第１の通信を第１のカノニカル規格に準拠する第１のフォームに変換する段階と、
前記第１のコンテンツベースのルータが、前記変換された第１の通信を、前記ネットワークの規格であるメトリックに応じて検証する段階と、
前記変換され、検証された通信を前記ネットワーク内に送信する段階と、
前記第１のコンテンツベースのルータが、前記第１のカノニカル規格に準拠したフォームの第２の通信を前記ネットワークから受信する段階と、
前記第１のコンテンツベースのルータが、前記受信した第２の通信を、前記第１のデータベース実体の情報規格に準拠するフォームに変換する段階と、
前記第１のコンテンツベースのルータが、前記変換された第２の通信を前記第１のデータベース実体に転送する段階とを備える方法。
【請求項１１】
前記第１のコンテンツベースのルータが、前記第１の通信のためのローカル識別ラベルとネットワーク識別ラベルとを生成する段階と、
前記ローカル識別ラベルと前記ネットワーク識別ラベルとを前記第１の通信に添付する段階と、
前記第１の通信、前記ローカル識別ラベル、および、前記ネットワーク識別ラベルのコピーを、前記第１のコンテンツベースのルータに関連付けられたキャッシュに格納する段階とを備える請求項１０に記載の方法。
【請求項１２】
前記第１のコンテンツベースのルータが、前記受信した第２の通信用の第２のローカル識別ラベルを生成する段階と、
前記第２の通信に関連付けられた前記第２のローカル識別ラベルを、前記第１のコンテンツベースのルータに関連付けられた前記キャッシュに格納する段階とを備える請求項１１に記載の方法。
【請求項１３】
前記第１のコンテンツベースのルータが、前記第２のローカル識別ラベルを、前記ネットワークを介して、前記第２の通信に関連付けられたローカル識別ラベルを有する各コンテンツベースのルータに送信する段階を備える請求項１２に記載の方法。
【請求項１４】
前記第１のコンテンツベースのルータが、前記ネットワークの他のコンテンツベースのルータが生成したローカル識別ラベルを受信して格納する段階を備える請求項１３に記載の方法。
【請求項１５】
前記第１のカノニカル規格は、前記ネットワーク内のデータの構造的およびセマンティックな標準化または正規化を可能とする請求項１０に記載の方法。
【請求項１６】
複数のネットワーク機器のネットワーク内の情報をトラッキングするコンピュータ実装された方法であって、前記複数のネットワーク機器の各々はローカルデータベースを持つローカル情報システムに接続し、前記方法は、
第１のネットワーク機器が、前記第１のネットワーク機器に接続された第１のローカル情報システムから、第１のイベントを記述して前記第１のイベントに関連付けられた第１のローカルシステム用の第１イベント識別子を含む第１のイベント情報パッケージを受信する段階と、
前記第１のネットワーク機器が、前記第１のイベントのための第１のネットワーク識別子を生成する段階と、
前記第１のネットワーク機器が、第１の機器用の第１のイベント関連パッケージを生成して、前記第１のネットワーク識別子と、前記第１のローカルシステム用の第１のイベント識別子と、前記第１のネットワーク機器の識別子とを、前記第１の機器の第１のイベント関連パッケージに追加して、前記第１の機器用の第１のイベント関連パッケージを格納する段階と、
前記第１のネットワーク機器が、前記第１のイベント情報パッケージと、前記第１の機器用の第１のイベント関連パッケージとを、第２のネットワーク機器に転送して、前記第２のネットワーク機器に接続された第２のローカル情報システムへ配信させる段階と、
前記第２のネットワーク機器が、前記第１のイベント情報パッケージを前記第２のローカル情報システムへ提供して、前記第２のローカル情報システムから第２のローカルシステム用の第１のイベント識別子を受信して、前記第１のイベントを識別する段階と、
前記第２のネットワーク機器が、第２の機器用の第１のイベント関連パッケージを生成して、前記第１のイベント関連パッケージの内容、前記第２のローカルシステム用の第１のイベント識別子、および、前記第２のネットワーク機器の識別子を、前記第２の機器用の第１のイベント関連パッケージに追加する段階と、
前記第２のネットワーク機器が、前記第２のローカルシステム用の第１のイベント識別子を前記第１のネットワーク機器に送る段階と、
前記第１のネットワーク機器が、前記受信した第２のローカルシステム用の第１のイベント識別子を前記第１の機器用の第１のイベント関連パッケージに追加する段階とを備える方法。
【請求項１７】
複数のローカル情報システムのネットワーク内の情報をトラッキングするコンピュータ実装された方法であって、前記複数のローカル情報システムの各々は、ローカルデータベースを持ち、少なくとも１つのネットワーク機器に直接接続されており、前記ネットワークの他のローカル情報システムと、複数のネットワーク機器それぞれを介して通信し、前記複数のネットワーク機器は互いにブロードキャストネットワークを介して接続し、前記方法は、
第１のネットワーク機器が、前記第１のネットワーク機器に接続されたローカル情報システムから、少なくともイベントを識別し前記イベントに関するイベント情報を受信する段階と、
前記第１のネットワーク機器が、前記イベントに固有のネットワーク識別子を生成する段階と、
前記イベント情報を、複数のローカル情報システム間で、前記複数のローカル情報システムにそれぞれ接続された前記複数のネットワーク機器を介して転送する段階と、
前記固有のネットワーク識別子に関連付けられた追跡情報を、前記イベント情報を前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々に格納させる段階とを備え、
前記追跡情報は、ａ）前記イベント情報を生成または受信する前記複数のローカル情報システムの各々が提供する前記イベントのローカル情報システム識別子、および、ｂ）前記イベント情報を、前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々の識別子を含む方法。
【請求項１８】
自身に接続された前記ローカル情報システムから第１のイベント用の第１のローカル情報識別子を受信した各ネットワーク機器が、前記第１のローカル情報識別子、および、前記第１のローカル情報識別子と、前記第１のイベント用の第１の固有のネットワーク識別子との関連付けを、他のネットワーク機器にブロードキャストする段階と、
前記ブロードキャストされた第１のローカル情報識別子を受信して、前記第１の固有のネットワーク識別子と関連付けて追跡情報を格納した各ネットワーク機器が、前記第１のローカル情報識別子を、前記第１の固有の識別子と関連付けて格納されている前記追跡情報に追加する段階とを備える請求項１７に記載の方法。
【請求項１９】
複数のローカル情報システムから前記複数のネットワーク機器の少なくとも１つに転送された全てのイベント情報を同じ規格に応じて検証する段階を備える請求項１７に記載の方法。
【請求項２０】
前記検証する段階は前記複数のネットワーク機器の少なくとも１つにより実行される請求項１９に記載の方法。
【請求項２１】
命令を備えるコンピュータ可読記憶媒体であって、前記命令はコンピュータに、
複数のコンテンツベースのルータの各々を、各々が異なる情報規格に準拠している複数のデータベース実体の対応するものに割り当てさせ、
前記複数のコンテンツベースのルータ間にネットワークを形成させ、
前記複数のコンテンツベースのルータのうち、第１のコンテンツベースのルータに、対応する割り当てられた第１のデータベース実体から第１の通信を受信させ、
前記第１のコンテンツベースのルータに、前記第１の通信を第１のカノニカル規格に準拠する第１のフォームに変換させ、
前記第１のコンテンツベースのルータに、前記変換された第１の通信を、前記ネットワークの規格であるメトリックに応じて検証させ、
前記変換され、検証された通信を前記ネットワーク内に送信させ、
前記第１のコンテンツベースのルータに、前記第１のカノニカル規格に準拠したフォームの第２の通信を前記ネットワークから受信させ、
前記第１のコンテンツベースのルータに、前記受信した第２の通信を、前記第１のデータベース実体の情報規格に準拠するフォームに変換させ、
前記第１のコンテンツベースのルータに、前記変換された第２の通信を前記第１のデータベース実体に転送させる媒体。
【請求項２２】
データは患者のヘルスケア情報を含み、前記媒体は、前記コンピュータに、
前記第１のコンテンツベースのルータに、前記第１の通信のためにローカル識別ラベルとネットワーク識別ラベルとを生成させ、
前記ローカル識別ラベルと前記ネットワーク識別ラベルとを前記第１の通信に添付させ、
前記第１の通信、前記ローカル識別ラベル、および、前記ネットワーク識別ラベルのコピーを、前記第１のコンテンツベースのルータに関連付けられたキャッシュに格納させ、
前記第１のコンテンツベースのルータに、前記受信した第２の通信用の第２のローカル識別ラベルを生成させ、
前記第２の通信に関連付けられた前記第２のローカル識別ラベルを、前記第１のコンテンツベースのルータに関連付けられた前記キャッシュに格納させ、
前記第２のローカル識別ラベルを、前記ネットワークを介して、前記第２の通信に関連付けられたローカル識別ラベルを有する各コンテンツベースのルータに送信させ、
前記第１のコンテンツベースのルータに、前記ネットワークの他のコンテンツベースのルータが生成したローカル識別ラベルを受信して格納させる命令を備える請求項２１に記載の媒体。
【請求項２３】
命令を備えるコンピュータ可読記憶媒体であって、前記命令はコンピュータに、
ローカルデータベースを持つローカル情報システムに各々が接続されている複数のネットワーク機器のネットワーク内の患者のヘルスケア情報をトラッキングさせ、
第１のネットワーク機器に、前記第１のネットワーク機器に接続された第１のローカル情報システムから、第１のイベントを記述して前記第１のイベントに関連付けられた第１のローカルシステム用の第１イベント識別子を含む第１のイベント情報パッケージを受信させ、
前記第１のネットワーク機器に、前記第１のイベントのための第１のネットワーク識別子を生成させ、
前記第１のネットワーク機器に、第１の機器用の第１のイベント関連パッケージを生成させ、
前記第１のネットワーク識別子と、前記第１のローカルシステム用の第１のイベント識別子と、前記第１のネットワーク機器の識別子とを、前記第１の機器の第１のイベント関連パッケージに追加させ、
前記第１の機器用の第１のイベント関連パッケージを格納させ、
前記第１のネットワーク機器に、前記情報パッケージと、前記第１の機器用の第１のイベント関連パッケージとを、第２のネットワーク機器に転送させ、前記第２のネットワーク機器に接続された第２のローカル情報システムへ配信させ、
前記情報パッケージを前記第２のローカル情報システムへ提供して、前記第２のローカル情報システムから第２のローカルシステム用の第１のイベント識別子を受信して、前記第１のイベントを識別させ、
第２の機器用の第１のイベント関連パッケージを生成して、前記第１のイベント関連パッケージの内容、前記第２のローカルシステム用の第１のイベント識別子、および、前記第２のネットワーク機器の識別子を、前記第２の機器用の第１のイベント関連パッケージに追加させ、
前記第２のローカルシステム用の第１のイベント識別子を前記第１のネットワーク機器へ送らせ、
前記第１のネットワーク機器に、前記受信した第２のローカルシステム用の第１のイベント識別子を、前記第１の機器用の第１のイベント関連パッケージへ追加させる媒体。
【請求項２４】
命令を備えるコンピュータ可読記憶媒体であって、前記命令はコンピュータに、
各々がローカルデータベースを持ち、少なくとも１つのネットワーク機器に直接接続し、互いにブロードキャストネットワークを介して接続する複数のネットワーク機器それぞれを介して前記ネットワークの他のローカル情報システムと通信する複数のローカル情報システムのネットワーク内の情報をトラッキングさせ、
第１のネットワーク機器に、前記第１のネットワーク機器に接続されたローカル情報システムから、少なくともイベントを識別し患者のヘルスケア情報を含み前記イベントに関するイベント情報を受信させ、
前記イベントの固有のネットワーク識別子を生成させ、
前記イベント情報を、複数のローカル情報システム間で、前記複数のローカル情報システムにそれぞれ接続された前記複数のネットワーク機器を介して転送させ、
前記固有のネットワーク識別子に関連付けられた追跡情報を、前記イベント情報を前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々に格納させる段階とを備え、
前記追跡情報は、ａ）前記イベント情報を生成または受信する前記複数のローカル情報システムの各々が提供する前記イベントのローカル情報システム識別子、および、ｂ）前記イベント情報を、前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々の識別子を含む媒体。
【請求項２５】
前記媒体は、前記コンピュータに、
各ネットワーク機器に、自身に接続された前記ローカル情報システムから第１のイベント用の第１のローカル情報識別子を受信させ、前記第１のローカル情報識別子、および、前記第１のローカル情報識別子と、前記第１のイベント用の第１の固有のネットワーク識別子との関連付けを、他のネットワーク機器にブロードキャストさせ、
各ネットワーク機器に、前記ブロードキャストされた第１のローカル情報識別子を受信させ、前記第１の固有のネットワーク識別子と関連付けて追跡情報を予め格納させ、前記第１のローカル情報識別子を、前記第１の固有のネットワーク識別子と関連付けて格納されている前記追跡情報に追加させ、
複数のローカル情報システムから前記複数のネットワーク機器の少なくとも１つに転送された全てのイベント情報を同じ規格に応じて検証させる命令を備える請求項２４に記載の媒体。
【請求項２６】
第１のコンテンツベースのルータであって、
前記第１のコンテンツベースのルータと関連付けられた第１の実体への第１の接続であって、前記第１の実体が患者のヘルスケア情報を持つデータベースを持つ、前記第１の接続と、
複数の他のコンテンツベースのルータへの複数の第２の接続であって、前記複数の他のコンテンツベースのルータの各々が、各他のコンテンツベースのルータに関連付けられた１つの他の異なる実体への接続を持ち、複数の実体の各々が、患者のヘルスケア情報を持つデータベースを持ち、それぞれ異なる情報規格に準拠している、前記複数の第２の接続と、
データが第１のカノニカル規格に準拠しているか否かを検証するメトリックとを備え、
前記第１のコンテンツベースのルータと前記複数の他のコンテンツベースのルータとの間の前記複数の第２の接続を介した全ての通信は、前記第１のカノニカル規格に準拠しており、
前記複数の他のコンテンツベースのルータの各々は、前記複数の実体のうち対応する関連付けられたものからの情報を、前記第１のカノニカル規格に準拠する第１のフォームに変換し、前記メトリックに応じて前記変換された情報を検証し、
前記複数の他のコンテンツベースのルータの各々は、前記第１のカノニカル規格に準拠する情報を、コンテンツベースのルータが割り当てられている対応する実体の前記情報規格に準拠するフォームに変換する第１のコンテンツベースのルータ。
【請求項２７】
前記第１のコンテンツベースのルータは、割り当てられた前記実体からの新たな通信を受信して、前記新たな通信への固有のネットワーク識別ラベルを取得するよう構成される請求項２６に記載のルータ。
【請求項２８】
前記第１のコンテンツベースのルータおよび前記複数の他のコンテンツベースのルータはネットワークを形成し、前記第１のコンテンツベースのルータは、
前記第１のコンテンツベースのルータを介して前記ネットワークと前記第１の実体との間で転送された各通信について、前記第１のコンテンツベースのルータおよび前記第１の実体のうち少なくとも１つを識別するローカル識別ラベルを取得し、
前記ローカル識別ラベルを前記通信に関連付け、
前記通信のコピーと前記ローカル識別ラベルのコピーとを格納し、
前記ローカル識別ラベルを前記ネットワークの前記複数の他のコンテンツベースのルータの少なくとも１つへ送信するよう構成される請求項２６に記載のルータ。
【請求項２９】
前記第１のコンテンツベースのルータは、ネットワークの複数の他のコンテンツベースのルータによる通信に関連付けられた複数のローカル識別ラベルを受信して格納するよう構成される請求項２８に記載のルータ。
【請求項３０】
前記第１のコンテンツベースのルータは、識別ラベルをキャッシュするネットワークコアである請求項２６に記載のルータ。
【請求項３１】
前記第１のカノニカル規格は、ネットワーク内のデータの構造的およびセマンティックな標準化または正規化を可能とする請求項２６に記載のルータ。
【請求項３２】
前記第１の実体および前記他の異なる複数の実体は、ヘルスケアサービス実体であり、前記情報は患者のヘルスケア情報を含む請求項２６に記載のルータ。
【請求項３３】
複数のローカル情報システムのネットワーク内の患者のヘルスケア情報をトラッキングするコンピュータ実装された方法であって、前記複数のローカル情報システムの各々は、ローカルデータベースを持ち、少なくとも１つのネットワーク機器に直接接続されており、前記ネットワークの他のローカル情報システムと、複数のネットワーク機器それぞれを介して通信し、前記複数のネットワーク機器は互いにブロードキャストネットワークを介して接続し、前記方法は、
第１のネットワーク機器が、前記第１のネットワーク機器に接続されたローカル情報システムから、少なくともイベントを識別し前記イベントに関するイベント情報を受信する段階と、
前記第１のネットワーク機器が、前記イベントに固有のネットワーク識別子を生成する段階と、
前記第１のネットワーク機器が、前記イベント情報を前記ネットワークへ転送して、複数のローカル情報システムにそれぞれ接続された前記複数のネットワーク機器を介した前記複数のローカル情報システム間で配信させる段階と、
前記第１のネットワーク機器が、前記ネットワークの複数の他のネットワーク機器のうち少なくとも１つから、前記少なくとも１つの他のネットワーク機器が提供した少なくとも１つの他の固有のネットワーク識別子を含むイベント情報を受信する段階と、
前記第１のネットワーク機器が、受信したイベント情報の各セットについて、追跡情報を格納する段階とを備え、
前記追跡情報は、前記受信したイベント情報に関連付けられた前記固有のネットワーク識別子、ａ）前記イベント情報を生成または受信する前記複数のローカル情報システムの各々が提供する前記イベントのローカル情報システム識別子、および、ｂ）前記イベント情報を、前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々の識別子を含む方法。
【請求項３４】
前記第１のネットワーク機器が、自身に接続された前記ローカル情報システムから第１のイベント用の第１のローカル情報識別子を受信して、前記第１のローカル情報識別子、および、前記第１のローカル情報識別子と、前記第１のイベント用の第１の固有のネットワーク識別子との関連付けを、他のネットワーク機器にブロードキャストする段階と、
前記第１のネットワーク機器が、他のネットワーク機器から、第２のイベントに関しており前記第２のイベントについての第２のローカル情報識別子と第２の固有の識別子とを含む第２の追跡情報を受信する段階と、
前記第１のネットワーク機器が、前記第２のイベントに対応する第２のローカル情報識別子を生成する段階と、
前記第１のネットワーク機器が、前記第２のローカル情報識別子に関連付けられた前記第２の追跡情報を格納する段階とを備える請求項３３に記載の方法。
【請求項３５】
命令を備えるコンピュータ可読記憶媒体であって、前記命令はコンピュータに、
各々がローカルデータベースを持ち、少なくとも１つのネットワーク機器に直接接続されており、互いにブロードキャストネットワークを介して接続する複数のネットワーク機器それぞれを介して前記ネットワークの他のローカル情報システムと通信する複数のローカル情報システムのネットワーク内の患者のヘルスケア情報をトラッキングさせ、
第１のネットワーク機器に、前記第１のネットワーク機器に接続されたローカル情報システムから、少なくともイベントを識別し前記イベントに関するイベント情報を受信させ、
前記第１のネットワーク機器に、前記イベントの固有のネットワーク識別子を生成させ、
前記第１のネットワーク機器に、前記イベント情報を前記ネットワークへ転送させて、複数のローカル情報システムにそれぞれ接続された前記複数のネットワーク機器を介した前記複数のローカル情報システム間で配信させ、
前記第１のネットワーク機器に、前記ネットワークの複数の他のネットワーク機器のうち少なくとも１つから、少なくとも１つの他のネットワーク機器が提供した少なくとも１つの他の固有のネットワーク識別子を含むイベント情報を受信させ、
前記第１のネットワーク機器に、受信したイベント情報の各セットについて、追跡情報を格納させ、
前記追跡情報は、前記受信したイベント情報に関連付けられた前記固有のネットワーク識別子、ａ）前記イベント情報を生成または受信する前記複数のローカル情報システムの各々が提供する前記イベントのローカル情報システム識別子、および、ｂ）前記イベント情報を、前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々の識別子を含む媒体。
【請求項３６】
命令を備えるコンピュータ可読記憶媒体であって、前記命令はコンピュータに、
第１のネットワーク機器に、複数のネットワーク機器の各々に接続されたローカル情報システムから第１のイベント用の第１のローカル情報識別子を受信させ、前記第１のローカル情報識別子、および、前記第１のローカル情報識別子と、前記第１のイベント用の第１の固有のネットワーク識別子との関連付けを、他のネットワーク機器にブロードキャストさせ、
前記第１のネットワーク機器に、他のネットワーク機器から、第２のイベントに関しており前記第２のイベントについての第２のローカル情報識別子と第２の固有の識別子とを含む第２の追跡情報を受信させ、
前記第１のネットワーク機器に、前記第２のイベントに対応する第２のローカル情報識別子を生成させ、
前記第１のネットワーク機器に、前記第２のローカル情報識別子に関連付けられた前記第２の追跡情報を格納させる媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の例示的な実施形態は、配信情報ネットワークのコンテンツベースのルーティングを含み、特に、ヘルスケア情報ネットワーク（ＨＩＮ）等のマルチパーティの情報ネットワークを考慮している。
【背景技術】
【０００２】
今日の多くのヘルスケア情報システムでは、セマンティックに正規化され集積された臨床データは、プラットフォームを超えて、または、ネットワークを越えて共有できる程度の利用可能性がなく、および／または十分な正規化がなされていない。これでは、患者の履歴または生命に関するデータ、有害な薬物相互作用、検査の重複、その他の不要なアドミッションについての不知識が不十分になり、医療ミス、診断ミスまたは処置ミスに繋がりかねない。患者の電子健康記録（ＥＨＲ）を処置時点で提供すること（つまり、正しいデータを正しい臨床士に適時に提供すること）により、処置の品質および効率は向上する。今までのところ、これは、個々のプロバイダが非常に複雑なシステムインテグレーションプロジェクトに投資するという稀なケースにしか達成されておらず、この場合においても、患者の記録は不完全な場合が多い。臨床上の決定は、主に市販のハードコピー、データレポジトリ、および、ばらばらの情報の「サイロ（silos）」の、人手のかかる、誤りの多い検索作業により行われ、患者の健康状態をつぎはぎ状態で構築している状態である。
【図面の簡単な説明】
【０００３】
本発明の非制限的および網羅的ではない実施形態を、以下の図面に基づいて記載する。図面では、図面全体にわたり、特に明記しない限りにおいて同様の参照番号は同様の部材を示している。
【０００４】
本発明の理解を促すべく、以下に好適な実施形態を記載するが、これは添付図面とともに読まれるべきである。
【０００５】
【図１】本発明の例示的な実施形態の構造全体を示す。
【０００６】
【図２】本発明の例示的な実施形態の機能の概略を示す。
【０００７】
【図３】図１の構造で利用可能な例示的なコンテンツベースのルータのソフトウェアコンポーネントを示す。
【０００８】
【図４】本発明の例示的な実施形態の構造的な側面を示す。
【図５Ａ】本発明の例示的な実施形態がサポートする配置モデルを示す。
【図５Ｂ】本発明の例示的な実施形態がサポートする配置モデルを示す。
【図５Ｃ】本発明の例示的な実施形態がサポートする配置モデルを示す。
【図６】本発明の例示的な実施形態のスーパピアトポロジーを示す。
【図７】本発明の例示的な実施形態に基づきデータ交換ネットワークを利用するケースを示す。
【図８】本発明の例示的な実施形態のＸＭＬ（eXtensible Markup Language）処理機能を示す。
【図９】本発明の例示的な実施形態によるカノニカル処理フローを示す。
【図１０】本発明の例示的な実施形態による研究所結果処理を示す。
【図１１】本発明の例示的な実施形態による長期的健康記録シナリオの基本的なアーキテクチャを示す。
【図１２】本発明の例示的な実施形態による長期的健康記録シナリオの患者の個人的な健康記録に記録されているイベントその他の要素に関する患者の健康記録および特記情報に関する情報を得る例示的な処理を示す。
【図１３】本発明の例示的な実施形態による長期的健康記録シナリオの患者の個人的な健康記録に記録されているイベントその他の要素に関する患者の健康記録および特記情報に関する情報を得る例示的な処理を示す。
【図１４】本発明の例示的な実施形態による長期的健康記録シナリオの患者の個人的な健康記録に記録されているイベントその他の要素に関する患者の健康記録および特記情報に関する情報を得る例示的な処理を示す。
【図１５】本発明の例示的な実施形態による長期的健康記録シナリオの患者の個人的な健康記録に記録されているイベントその他の要素に関する患者の健康記録および特記情報に関する情報を得る例示的な処理を示す。
【図１６】本発明の例示的な実施形態による長期的健康記録シナリオの患者の個人的な健康記録に記録されているイベントその他の要素に関する患者の健康記録および特記情報に関する情報を得る例示的な処理を示す。
【図１７】本発明の例示的な実施形態によるマルチプロバイダ処置シナリオにおいて情報を集積する基本的なアーキテクチャを示す。
【図１８】本発明の例示的な実施形態による図１７のマルチプロバイダ処置シナリオにおいて情報をトラッキングする例示的な処理フローを示す。
【図１９】「アウトサイドイン」の例示的なＣＲＵＤ（作成、読み出し、更新、削除）相互作用を示す。
【図２０】「インサイドアウト」の例示的なＣＲＵＤ相互作用を示す。
【図２１】図２０のアーキテクチャの例示的なベースラインのシーケンス線図を示す。
【図２２】Ｇｅｔ（）の例示的なシーケンス線図を示す。
【図２３】Ｐｕｔ（）の例示的なシーケンス線図を示す。
【図２４】Ｄｉｓｃａｒｄ（）の例示的なシーケンス線図を示す。
【図２５】Ｌｉｓｔ（）の例示的なシーケンス線図を示す。
【図２６】Ｄｅｓｃｒｉｂｅ（）の例示的なシーケンス線図を示す。
【図２７】Ｌｏｃａｔｅ（）の例示的なシーケンス線図を示す。
【図２８】Ｉｎｉｔｉａｌｉｚｅ（）の例示的なシーケンス線図を示す。
【図２９】ＣＭＶＴ（Controlled Medical Vocabulary Translation）を外部サービスとして実装する例示的なアーキテクチャを示す。
【図３０】ＥＭＰＩ（Enterprise Master Patient Index）を外部サービスとして実装する例示的なアーキテクチャを示す。
【図３１】ウェブサービスに基づくインタフェースを有するヘルスケア用途向けインテグレーションエンジン（ＨＣＩＥ）に対する緩い連結を提供する例示的なアーキテクチャを図示する。
【発明を実施するための形態】
【０００９】
以下の用語集は、本ドキュメントを通じて利用される定義を提供している。  「カノニカル」：データおよび機能の標準化された表現を示す用語である。この例には、患者、オーダ（Order）、外来診察（Encounter）、等が含まれる。  「ＣＢＲ」：コンテンツベースのルータまたは機器であり、アーキテクチャの実施形態でキーとなるソフトウェアコンポーネントを形成することができ、プラットフォームのＥＳＢおよびＸＭＬ促進およびファイヤウォール機能を提供しうる。  「ＣＢＲローカルサービス」：ＣＢＲ  Ｊａｖａ（登録商標）スタックに実装されるＷＳＤＬサービス実装を示す。  「ＣＢＲ外部サービス」：ＣＢＲランタイムの外に実装され、サポートされたＣＢＲトランスポート結合（例えばＳＯＡＰ，ＪＭＳ等）のいずれかにより呼び出されるＷＳＤＬサービス実装のことである。  「ＣＢＲワークフロー」：ＣＢＲランタイム内で定義および実行されるＢＰＥＬベースのワークフローのことである。ＣＢＲは、ＷＳＤＬ処理をワークフローにマッピングして実行に備えさせる。  「ＩｔｅｍＦｉｅｌｄ」：ＣＢＲに埋め込まれうる第三者の技術であり、カノニカルＸＭＬ表現にＨＬ７、Ｘ１２、ＣＣＲ，およびＮＣＰＤＰデータフォーマットをマッピングする変換機能を提供する。  「ＨＩＮ」：健康情報ネットワークであり、政府系機関、病院、研究所、医院、薬局、および保険会社間の連携であり、医療共同体全体の患者、臨床および経理上の情報を共有する。  「ＨＬ７」：臨床システムおよびヘルスケアビジネス処理全体のデータ相互運用性に特別に焦点を当てるヘルスケアの情報技術規格を定義するヘルスケア産業規格機関であるヘルスレベルセブンのことである。  「ＣＤＡ」：承認済みのＨＬ７規格である臨床ドキュメントアーキテクチャのことであり、ＸＭＬのＨＬ７の３．０バージョンの参照情報モデル（ＲＩＭ）を実装する。  「ＣＣＲ」：個人の個人健康記録を表すＡＴＳＭ（ＡＮＳＩ）規格である継続治療記録である。これは、患者の人口統計データ、医療履歴、および臨床専門家との関係（プライマリ医師／家庭医等）の標準化された定義を提供するＸＭＬ構造である。  「ＣＣＤ」：承認済みのジョイントＨＬ７およびＡＮＳＩ規格である継続治療ドキュメントであり、ＣＤＡ仕様におけるＣＣＲの内容を表す。  「ＮＣＰＤＰ」：電子薬物処方規格である。  「Ｘ１２」：請求、推薦、および請求に対する支払いを表す規格である。  「ＲＬＳ」：記録ロケータサービスである。  「ＣＲＵＤ」：作成、読み出し、更新および削除サービスのことである。  「ＥＭＰＩ」：Enterprise Master Patient Index Service（企業マスタ患者インデックスサービス）のことである。  「ＣＭＶＴ」：Controlled Medical Vocabulary Translation Service（制御された医療語彙翻訳サービス）のことである。  「ＸＦＲＭ」：変換を表す。
【００１０】
本発明の例示的な実施形態では、ヘルスケア情報ネットワーク（ＨＩＮ）は、それぞれ異なる実体（例えば、様々な病院、健康保険会社、診療所、州立または連邦政府系機関等）に属する別個のデータベース間をコンテンツベースのルータ（「ＣＢＲ」または「ＣＢＲルータ」）でリンクすることにより形成される。ＣＢＲルータは、様々な（外部）実体からの通信を共通の、または標準的なフォーマットまたはカノニカルに翻訳して、ＣＢＲルータ間でまたはＣＢＲルータを介して、様々な実体間で通信を送信およびトラッキングするＳＯＡ（Software Oriented Architecture）機器（例えば「ＣＢ機器」）として機能することができる。ＣＢ機器は、ネットワークに入退出する全ての通信をフィルタリングまたは検証して、ネットワーク内のデータの整合性を確かめ、ネットワークからデータを受信する実体に対して、一定のレベルの認証または信頼性を保証するネットワークの門番としての役割を果たすことができる。同様にして、ＣＢ機器はネットワークの外部の実体のアクセスを制限することによりネットワークのセキュリティを守ることができる。例示的な実施形態では、ＣＢ機器は、ネットワークに入ってくる、または出てゆく通信のトラッキングも行うので、特定のデータ（例えば、患者の記録または情報）に関する処理が追跡可能になる。
【００１１】
「Ｎ」個の異なる規格またはデータフォーマットがＨＩＮに参加する様々なデータベースで利用されているとすると、ネットワーク内で利用される中間、共通のフォーマットまたは規格にこれらを翻訳することにより、各フォーマットを直接各他のフォーマットに翻訳する場合、必要な翻訳機能スケーラビリティがＮ＊（Ｎ−１）個からＮ＋１個の翻訳に減らされ、効率が上がり、スケーラビリティの簡略化につながる。
【００１２】
各ＣＢＲルータは、（外部）実体またはデータベースのいずれかに割り当てられ、ＨＩＮに対するその実体のリンクまたはリエゾンとして機能する。ＣＢＲルータは、「パーティライン」として機能しうるオープンバスを利用して自身間で通信するが、ここではＣＢＲルータの全てがバス上の通信をリッスンして、バス上でメッセージをブロードキャストまたは送ることができる。このオープンバスは、インターネット経由で、ＣＢＲルータ間で通信をルーティングする仮想バスまたは「パーティライン」でありうる。バス上の通信にはヘッダ情報等の適切な情報が含まれてよく、これにより、他のＣＢＲルータは、バス上の通信の宛先、および、通信が、リッスンしている特定のＣＢＲルータに対するものであるか否か（例えば、特定のＣＢＲが、特定の主題、患者、地理的領域に関する全ての情報に関する全ての通信をアーカイブして、それが割り当てられている病院または機関に対して特定の主題の情報を検索できるようにするよう、割り当てられているまたは任務を持つ場合）を判断できるようにしてよい。加えて、ネットワーク内に直接ルーティングメカニズムを提供して、ＣＢ機器がネットワーク上の別の実体（例えば別のＣＢ機器）に直接通信を送信することができるようにしてもよい。当業者であれば理解するように、既存の直接ルーティングメカニズムを、この機能を行うよう利用または適合することができ、ネットワーク内に例えば１以上の「電話帳」等に類似したインデックスまたはレポジトリがあってよく、こうすることで、あるＣＢ機器は、ネットワーク内の別の実体の（または、他の実体に対応するＣＢ機器の）直接ルーティングアドレスまたはステータスを取得、更新、検証、また照合するよう参照を行うことができる。ネットワーク内のディレクトリは、さらに、ネットワークに参加しているＣＢ機器から利用可能な、またはこれらのＣＢ機器を通じて利用可能なサービスおよび／または情報を示しても良い。故に、１以上の中央ディレクトリをネットワーク内に提供して、ネットワークの参加者（例えばＣＢ機器）についての情報を含めることができ、さらには、これら機器が表す外部実体についての状態を含めることもでき、これら情報は、参加者のネットワークＩＤ、それらから得た検証要求、検証結果、ＤＢ機器から収集され、キャッシュされた処理追跡情報のコピー、サポートされるカノニカル（canonical）等を含みうる。
【００１３】
ＣＢＲルータは、各データベースからの全てのデータまたは通信を、共通のカノニカルフォームまたは規格に変換することにより、異種のデータベース間をリンクする。本質的に各ＣＢＲは、それが割り当てられたローカル実体からの通信またはデータを、他のＣＢＲルータへの共通の規格または通信に翻訳して、このローカル実体の代わりに受信する情報を、共通の規格からローカル実体の規格またはフォーマットに変換することで、ローカル実体とネットワークとの間のトランスレータとして機能する（故に、ローカル実体とそれらにローカルなＣＢＲルータの管轄の他の実体との間のトランスレータとして機能する）。翻訳は、データのフォーマットまたは構造の翻訳またはコンバージョンのみならず、データまたはメタデータのセマンティックスまたは意味の翻訳または変換をも含みうる。例えば、ブランド薬品のラベルは、総称名または技術名に翻訳または拡張され（例えば、Ｚｅｓｔｒｉｌ（登録商標）からリシノプリルへ）、「心臓発作」は、「心筋梗塞」に翻訳または相関付けられてよい、等である。各ローカル実体は、ＣＢＲルータに、ローカル実体のデータ記述規格およびＣＢＲルータ間で共有される情報の共通の規格またはカノニカルをマッピングする翻訳鍵またはマップを提供する責任がある。
【００１４】
ＣＢＲルータが、ローカル実体から通信を受信すると、ＣＢＲルータは、通信を共通の規格またはカノニカルに翻訳して、その後、さらに、検証メカニズムを適用して（または、翻訳された通信を、ネットワークコアノード等のネットワーク内の別のノードまたは局に転送して）、翻訳された通信を検証する。検証の例示的な実施形態は、特定のローカルサイトにおける特定のデベロッパのローカルな解釈のみならず、ネットワーク自身が保証する。これにより、設計時（マップ作成時）および／またはランタイム（メッセージ交換）時において検証を実行することのできるネットワーク上のサービスが確立する。本発明の例示的な実施形態による普遍的／ネットワークレベルの定義付けおよび検証の実行は、幾らかの非常に有利な点を提供する。検証とは、通信のシンタックス、セマンティックおよび／または、グラマーの正確さ、または、共通の規格またはカノニカルの公的な定義との適合性を照合することを意味する。検証に失敗すると、ＣＢＲルータは、ローカル実体に対して、その通信が検証に失敗したことを伝える（且つ、検証プロセスが提供する診断情報を伝送してもよい）。検証が失敗するということは、例えば、翻訳鍵またはマップにエラーまたは不正確な部分が含まれており、ローカル実体がその修正をする必要があることを意味する。検証メカニズムは、ネットワークの全てのＣＢＲルータで一律に適用されてもよく、こうすることで、ネットワークの中心の情報（つまり、ＣＢＲルータ間でやり取りされる情報）の信頼性を確かめ、利用が容易なものとなり、ＣＢＲルータによりネットワークに接続されている実体は、自身がネットワークからそのＣＢＲルータを介して受信する情報を信頼することができるようになる。同時に、これにより、各々が特定の規格および共通の規格の間のマッピングのみに責任を担う形となるので、ローカルまたは外部の実体の負担が最小化される（ネットワークの「外部」、というのも、これら外部の実体は、銘々割り当てられたＣＢＲルータのみを介してネットワークと通信するからである）。検証プロセスの記録は、ＣＢＲルータまたは検証を依頼した（ローカルに、または別個のまたは関連するデータ記憶装置にキャッシュした）ＣＢ機器が保持することができる、および／または、ネットワーク内の、またはネットワークに接続された中央実体（例えば、ＣＢＲルータが検証用の通信を送信したネットワークコアノード等の実体）が保持することができる。記録は、例えば、検証が要求された時間、要求対象の通信、検証結果等を示していてよい。
【００１５】
セキュリティは、ＣＢ機器を介してセキュリティ手順およびメカニズムを実装することにより提供されてよく、例示的な実施形態ではＣＢ機器は門番として機能してよい。例えばセキュリティは、例えばＰＫＩ（公開鍵インフラストラクチャ）を利用する証明書に基づいていてよく、各有効なＣＢ機器が証明書を有し、ネットワーク内の他のＣＢ機器との通信は、通信するＣＢ機器のそれぞれの証明書を利用することでタグ付けされる、または検証される。例示的な実施形態では、直接ネットワークと通信しようとしている実体が証明書を持たない場合、ネットワーク内の他のＣＢ機器はそれをリッスンしない。ＣＢ機器が表す外部実体も、デジタル署名を有することができ、ＣＢＲネットワークの特定のネットワークまたは領域は副証明書であってよく、これは例示的な実施形態では、ＣＢＲネットワークを所望の基準により領域（例えば地理的領域、表されるヘルスケア実体の種類等）へと効果的にオーガナイズするのに利用されうる。本発明の例示的な実施形態では、ネットワークアドレススキームとして知られている仮想プライベートネットワーク、およびその他の技術を利用して、セキュリティが提供されてよく、および／または、ＣＢＲネットワークのパーティラインおよび直接ルーティング通信を提供してよい。ＣＢＲネットワークにＣＢ機器を介してインタフェースする外部システムは、（例えばＰＫＩに準拠した）鍵を利用して、外部システムとそれぞれのＣＢ機器との間の通信へのアクセスをイネーブル、制御、および保護することができる。
【００１６】
例示的な実施形態では、各イベントまたは情報は、固有のネットワーク識別コードおよびそれを最初に提供したローカル実体が割り当てたローカル実体識別コードを提供される。このイベントまたは情報が、ネットワーク内の別の実体によりアクセス、視聴、保存、および／または修正されると、対応するローカル実体コードおよびＣＢＲルータ識別コードは、イベントに関連付けられることができ、あるいは、イベントの記録に追加することができ、ネットワーク内全体でイベントの履歴を辿ることができるようになる。例えば新たな関連付けを、ネットワーク内でブロードキャストして、および／または直接１以上の対象実体（例えば、ＣＢＲネットワーク内の中央レポジトリまたはキャッシュ、イベントに関わっているＣＢ機器等）へルーティングして、ネットワークに参加しているノード（例えばネットワークコアノード、関連タスクの達成を課されているＣＢＲルータ、および／または、対象のまたは責任を負うローカル実体）がイベントについての各々の記録を更新することができる。
【００１７】
例えば、イベント、処置、または対応するローカルシステムから情報の他のアイテム等の患者に関する情報をＣＢＲルータが最初に受信すると、この情報は、アイテムのローカルシステム識別子を含んでいる。ＣＢＲルータはその後、固有のネットワーク識別子を作成して、アイテムをラベル付けして、関連付ける。
【００１８】
各ＣＢＲルータまたは機器は、固有の物理識別子（例えばＴＣＰ／ＩＰアドレス）および／または固有の論理識別子（例えば固有の１２８ビットの文字コード、または他のより小さいまたは大きいサイズのコード）を有してよく、情報アイテムが含みうるネットワーク識別子は、カウントまたはＣＢ機器が生成した他の値とともに連結されたまたは組み合わせられたＣＢＲの識別子を含み、これにより異なるＣＢ機器が別個に固有のネットワーク識別子を生成することができる。例示的な実施形態では、その後、ＣＢ機器は、ネットワークで情報アイテムとともに移動する記録を作成することができ、ここで記録はローカル識別子、ＣＢ機器識別子、およびネットワーク識別子を含む。ＣＢ機器はさらに、この記録のコピーを維持することができ、記録のコピーを１以上のネットワークコアノードに転送して（例えば、各々が自分をネットワークにリンクさせるＣＢ機器を有する）、重複を生成することができる。情報アイテムが効果的に別のＣＢ機器をタッチする際、またはそのＣＢ機器にローカルなシステムにより利用されるまたはキャッシュされるＣＢ機器を通過する場合、そのＣＢ機器は自身の識別子を記録に追加して、さらに、対応するローカルシステムが生成する、さらなる新たなローカル識別子を追加することにより、記録の「追跡」を生成することができる。故に、情報アイテムに対応する記録は、ネットワーク識別子および元のローカルおよびＣＢＲ識別子だけではなくて、情報アイテムを利用またはそれにアクセスする他のローカルシステムおよびそれらのＣＢ機器の識別子をも含む。ＣＢ機器が新たなまたはさらなる識別子を、情報アイテムのネットワーク識別子と関連づけるとき、ネットワーク内にこれをブロードキャストして、情報アイテムにタッチする、または情報アイテムに「興味」を持つようタスクを課された他のＣＢＲがブロードキャストされたメッセージを受信して、情報アイテムについての自身の履歴／追跡記録のコピーを更新できるようにしてよい。ＣＢ機器も、自身が更新された関連情報（例えば、情報アイテム用にネットワーク識別子と関連付けられるべき新たな識別子）とともにネットワークに提供するメッセージ内の特定のノードを指定することができ、これにより、これらノードが更新を受信する、または気づく、およびこれに対応できるようにしてよい。これに加えてまたはこの代わりに、ＣＢ機器は、該ＣＢ機器がこの情報に興味があると知っているネットワークの１以上の実体へ直接更新をルーティングしてもよい。故に、情報アイテムの、ネットワークの部材との間での各処理は、追跡またはトラッキング用途用に記録またはキャッシュされてよい。これにより、様々なプライバシまたは制限アクセス規則に準拠させることが可能となり、誰がまたは何がこの情報アイテムに興味があるかを示すことができるようになり、病気のベクトル等を識別してトラッキングするメカニズムを提供することができるようになる。各ＣＢ機器は、自身のローカルキャッシュまたはデータ記憶装置を備えて、追跡記録、カノニカルの定義および規格、特別なタスクおよび関連する規則または実行すべきスクリプト等を記録することができる。ＣＢ機器用のデータ記憶装置は、ローカルでも排他的でも、遠隔であってもよく、多数のＣＢ機器に共有されても、多数のＣＢ機器に対して別個にサービスしてもよい。ＣＢ機器のキャッシュまたはデータ記憶装置は、このようにして、トレーサビリティデータおよびコアデータをアーカイブしてよく（例えば、通信および自身の追跡情報）、タイムアウトを行ったり定期的に通信をフラッシュしたりして、一方では、通信に関する追跡データを維持してよい。例えば、通信がＣＢ機器を通過した後、ある時間が経つと、機器のキャッシュから通信をフラッシュするまたは削除して、一方、通信に関するトレーサビリティまたは追跡情報（および通信の識別情報）については、無制限にまたは後の日付まで維持してよい。例えば、ＣＢ機器のキャッシュは、対応する通信よりも長い期間追跡情報を維持するよう構成されてよく、フラッシュまたは破棄される情報をオフロードまたはアップロードして、他所で（例えば、ＣＢ機器に関する別のデータ記憶装置に、または、ＣＢＲネットワーク内の、またはそれに接続される中央レポジトリまたは部分レポジトリに）セーブされるまたはアーカイブされうるようにしてよい。ネットワーク内のＣＢ機器キャッシュは、異なる様式で構成されてもよい（例えば、特定のキャッシュのサイズ、ＣＢ機器が伝送するトラフィック量および強度、伝送する通信の種類等を含む他の要素に応じて）。
【００１９】
ＣＢ機器に関連付けられたキャッシュまたはデータ記憶装置は、トレーサビリティ機能を提供できるのみならず、さらには、記録ロケータサービスを提供するのに利用することもできる。例えば、本発明の例示的な実施形態は、ヘルスケア記録位置について予め構築されているサービス、またはＲＬＳ（記録ロケータサービス）をサポートすることができる。ＲＬＳの目的は、健康情報ネットワーク（ＨＩＮ）（例えば、本明細書の随所に記載する、各々がＨＭＯ、病院等のヘルスケア実体に外部からリンクされるＣＢ機器のネットワーク）内のばらばらの位置に記憶されうる患者データを判断して集積するメカニズムを提供することである。より具体的には、患者データは、ある患者がある医者の元に行く頻度を知るべくクエリされたり、特定の期間における患者の活動のサマリを提供したりしてよく、情報を集積形態でまとめることもできる（例えば、全患者または外来診察履歴として）。ＲＬＳサービスはＣＢＲの単一のインスタンスには予め構築されたローカルサービスとして見えることがあるが、効果的にリソースを共有するネットワークの多数のＣＢＲインスタンスの「ネットワーク効果」に頼ることができる。さらに、予め構築されたＲＬＳサービスは、ヘルスケア配置の的確なニーズに合致するようカスタマイズ設計することができる。特に、ＲＬＳ記憶装置のローカルＷＳＤＬ（ウェブサービスデータ言語）サービスインタフェースおよびデータベーススキーマを特定の用途向けにカスタマイズすることができる。この形態においては、ＲＬＳサービスは「スタータ」サービスと捉えることができる。
【００２０】
ＲＬＳでは、多数のＣＢＲインスタンスまたはノードと称される機器／コンテキストベースのルータ間を区別することができる。健康情報交換（ＨＩＥ）ネットワークの場合には、例示的な実施形態では、レポジトリノードと称される１つのノードが、そこからデータをクエリする地点であってよく、他のＣＢＲインスタンスは、銘々が直接参加する患者データの記録のみを維持していればよい。高レベルな例においては、ＣＢＲネットワークを介して、医者ノード、研究所ノード、およびＨＩＮノードという３つのＣＢ機器またはインスタンスがリンクされている場合を考える。各ＣＢ機器は、関連するデータ記憶装置またはキャッシュを有し、例えば永続ＲＬＳデータ記憶装置を含む。例示的な実施形態では、ＲＬＳデータ記憶装置は、ＣＢ機器のメッセージキャッシュとは別個のインタフェースである（ここでは例えば、メッセージキャッシュが、ＣＢ機器および対応する外部ヘルスケア実体を横断する、または、これに関連する全てのメッセージのコピーをセーブして、且つ、ローカルおよびネットワーク識別子ラベル等の追跡情報をセーブする）。例示的な実施形態では、ＲＬＳデータ記憶装置は、より長い生存データを処理するよう設計される、という意味でメッセージキャッシュと対照的である。ＲＬＳデータ記憶装置はメッセージキャッシュとは別個であっても、例えば分割デバイス等のデータ記憶デバイス内のメッセージキャッシュとともに実装されてもよい。例示的な実施形態では、ＨＩＮ（健康情報ネットワーク）ノードは、全てのＲＬＳクエリをそこから行うメインレポジトリとして機能する。ＣＢＲ  ＲＬＳサービスは、非ＣＢＲノードと互換性を有してよいが、状況に応じては幾らかの特化開発が必要となる場合もある。例示的な実施形態では、ＲＬＳは、識別子を生成し、関連付け、対応するＣＢ機器のメッセージキャッシュは、実際のメッセージのローカル記憶装置として少なくとも機能する。例示的な実施形態では、ＲＬＳおよび／または生成され関連付けられる識別子は、各ＣＢ機器またはインスタンスの１つのデータベースのメッセージキャッシュまたはメッセージのローカル記憶装置とともに実装される。
【００２１】
本例では、ＨＩＮノードはレポジトリノードであり、患者データをクエリするべくＸＭＬウェブサービススタイルインタフェースを露呈させる（expose）。クエリツールは、例えばヘルスケア実体またはその実体のデータ機械を操作する許可を得た人員が利用可能なツールを有してよく、ヘルスケア実体はＨＩＮノードのＣＢ機器に接続されており、ＣＢ機器を介してネットワークに効果的にアクセスする。クエリツールは（自動的にまたは人であるオペレータの命令により）クエリを表す特定のＸＭＬクエリ構造をＣＢ機器に送ることができる。ＣＢ機器はこのクエリ構造を、一連の関係データベースクエリに変換して、そのＲＬＳデータ記憶装置を参照して、患者データをクエリツールへ戻す。
【００２２】
例示的な実施形態では、ＲＬＳサービスには、（ａ）患者データを如何に格納するか、またその格納場所および（ｂ）患者データを如何にクエリするか、またはどこでクエリするか、という２つの側面がある。これらを以下で詳述する。
【００２３】
本発明の例示的な実施形態によると、ヘルスケアのＣＢＲは、ヘルスケアドメインに見られるオーダ、外来診察、患者、ドキュメント、および他のアーチファクトを処理する特定の数のヘルスケアに特有のサービスを含んでよい。ＲＬＳは、これらサービスの実行中に患者データを集積することで動作してよい。ＨＩＮノード（またはレポジトリノード）の「ネットワーク効果」により、（ネットワークのＣＢ機器が表す）ローカルノードは、自身の通信をレポジトリノードに仲介させうる。こうなると、患者データは後の取得を想定して中央位置に格納されうる。患者データが集積され、ＲＬＳサービスにより後に取得される例を、患者の検査を研究所に依頼する医者を例にとって説明する。この利用例は上述のトポロジーに適合する。
【００２４】
利用例は、以下のステップを参照しながら説明することができる。１）医者は、例えば以下の関数／手順を用いて、識別子ｐを有する患者の識別子ｔを有する研究所検査を依頼する。Order.Initialize()により、医者ノードは、ＨＩＮノードのネットワークアドレスを見つける。関数Order.Put()は、ＨＩＮノードへ研究所依頼用のカノニカルフォームを送信する。２）ＨＩＮノードは、例えばローカルＲＬＳ記憶書き込みを利用して患者データを記録して、識別子ｔ、ｐ、およびその日付をメッセージキャッシュに格納する。３）次に、医者ノードは、例えばローカルＲＬＳ記憶書き込みを利用して患者データを記録して、識別子ｔ、ｐ、及びその日付をメッセージキャッシュに記録する。４）この時点で、医者は研究所検査を適切な研究所「ａ」に送信することを所望しているので、医者ノードは、関数Order.Put()を用いて、ＨＩＮノードをクエリして適切な研究所「ａ」のアドレスを探す。５）ＨＩＮノードはこの新たな患者データを記録する（例えば、ローカルＲＬＳ記憶書き込みを利用して、研究所「ａ」へのオーダを記録または格納する）。６）最後に、研究所ノードは、例えばローカルＲＬＳ記憶書き込みを利用して患者データを記録して、ローカルＲＬＳ記憶装置で依頼の受付をトラッキングさせ、ＣＢ機器間で利用されるカノニカルフォームを、適宜、その下の研究所システム、または、ネットワーク外であり、研究所ＣＢ機器を介して接続されている研究所システムに適したローカルなものに変換する。
【００２５】
このヘルスケアワークフローが完了すると、レポジトリノード（ＨＩＮノード）は、この特定の患者に起こったことに関する情報の全範囲を含むが、ローカルノードは、直接参加するワークフローの部分しか含まない。
【００２６】
例示的な実施形態では、ＲＬＳサービスは、以下のようにレポジトリノードでクエリされうる。患者データクエリに関しては、または、患者に関するアクセスデータの依頼に関しては、ＲＬＳサービスは、レポジトリノードでローカルＲＬＳ記憶装置をナビゲートしうるＷＳＤＬインタフェースを介して実装される、ＣＢＲシステムについて予め構築されたサービスであってよい。上述したように、ＲＬＳサービスは、メッセージキャッシュを利用して入ってくるまたは出てゆく患者データフローを追跡して、エンドツーエンドのメッセージフローを再構築する手段を提供する。ＣＢ機器またはＣＢＲのメッセージキャッシュは、患者の識別子、医者および研究所の識別子、記録識別子、日付、および、各処理の起こったノードのＩＰアドレス等の識別子を記録することができる。例示的な実施形態では、メッセージキャッシュは、ＸＭＬクエリ構造の利用によりアクセスされる関係データベースに患者データを格納する。つまり、ＲＬＳサービスは、このクエリ構造を入力とするＷＳＤＬを含むサービス呼び出しにより定義される。クエリは、クエリ構造自身のパラメータを操作することで定義されてよい。ＣＢＲシステム内では、このクエリ構造は適切な関係データベースクエリに変換されてよく、その結果をＸＭＬとして戻すことができる。これにより、ワークフローの要件によく整合するＸＭＬ要求および応答に基づき特化クエリツールを書き込むことができる。例示的なＣＢＲシステムは、基本的なクエリツールを含むことができ、さらには、適宜エンドユーザによりカスタマイズされることができる。
【００２７】
故に、ここに記載されるＣＢＲルータは、共通カノニカルと組み合わせられることで、ヘルスケア情報規格をより早く適用して、コストと複雑性とが低減され、維持可能なビジネスモデルの提供を可能とする計算可能なセマンティック相互運用性を可能とする、ヘルスケア用途に特化した相互運用プラットフォームまたは健康情報ネットワークの形成に利用可能である。
【００２８】
本発明の例示的な実施形態を利用して実装可能な高度のヘルスケア利用モデルは（例えば投薬管理、コンテキスト認識計算、臨床検査管理、および臨床決定サポート）、相互運用性の基本的な問題である場合がある。相互運用性は、ＳＯＡ（Service Oriented Architecture）およびウェブサービスを利用してＣＢＲルータおよび関連サービスを実装することにより提供されてよい。コアＣＢＲシステム特徴は、信用できるメッセージング（メッセージ）、ＸＭＬ（eXtensible Markup Language）の促進、セキュリティおよびルーティング、ＢＰＥＬ（Business Process Execution Language）の編成、セマンティック正規化、ローカルおよび外部サービスのパイプライン処理を有するサービスコンテナ、および集積設計時間、ランタイム、および管理環境を有する、ＥＳＢ（Enterprise Service Bus）（例えば、上述したＣＢＲルータ間の「パーティライン」または仮想通信バス）を含みうる。この基盤を利用することにより、本発明の例示的な実施形態は、例えばｖ３ＲＩＭ（Reference Information Model）（XMLカノニカル）に基づき、ウェブサービスにより露呈する一式のヘルスケアビジネスオブジェクトを定義することができる。様々な配置モデル（集中型、連邦、ハイブリッド）が、同時にサポートされてよく、さらにスケーラブルな性能（エッジ、地域の、またはスーパピアの処理量）を提供することで、スケールメリットおよび「将来を保証された」情報技術の投資を促すことができる。
【００２９】
故に、ＣＢＲルータを利用する本発明の例示的な実施形態は、ヘルスケア組織および株主等の異なるヘルスケア実体間で患者データの効率的フローを促進して、正規化された患者データを入手可能な形で作成および共有することを可能とする。このように、セマンティックに正規化され、かつ集積された臨床データが利用可能になることで、医療ミス、薬物相互作用、検査の重複および不要なアドミッションが低減されるので、これまでにない類の効率性が達成される。処置時点に正しいデータを持つ患者の電子健康記録（ＥＨＲ）を、正しい臨床士に適時に提供することで、処置の品質および効率が向上し、個々のプロバイダが、非常に複雑で、且つ、記録が大幅に不完全であることの多いシステムインテグレーションプロジェクトに投資する必要がなくなる。本発明の例示的な実施形態はさらに、臨床上の決定を、患者の健康状態を単につぎはぎ状態で構築するだけになってしまうことが多い、主に市販のハードコピー、データレポジトリ、および、ばらばらの情報の「サイロ（silos）」の、人手のかかる、誤りの多い調査に頼らず行うことを可能とする。
【００３０】
ネットワーク実体間の全ての通信をＣＢＲルータを通して行うことにより、共通の規格で一貫性を確保することができる、というのも、ＣＢＲルータは、情報を共通の規格またはカノニカルへ変換したり、またはそれから変換したりすることで、情報を検証することができるようになるからである。全てのネットワーク通信を１以上のＣＢＲルータを通すようにすることで、トレーサビリティを確保することができるようになる。故に、本発明の例示的な実施形態によると、全ての交換処理は、セキュアであり、柔軟性があり、監査可能であり、説明可能である。ローカルまたは遠隔の検証された産業サービス、プロバイダおよび機能は、シームレスにプラットフォームへ、「サービスアクチュエータ」あるいは機能サービスプロセスモデルとして「プラグイン」することができる。この方法により、臨床当事者２者間で交換されるデータがすべて適切に提供および制御され、処理パイプラインにおけるセマンティックな検証をサポートする交換モデルが作成される。
【００３１】
特に、ＣＢＲルータまたはＣＢ機器を組み込む本発明の例示的な実施形態は、相互運用ソリューションの展開における、産業のある種の「痛点（pain point）」を利用する。これは、先ず複雑性を低減させるという幾らかのメカニズムにより行われる。相互運用性の簡略化により、ヘルスケア交換においてインテグレーションにかかるコストおよび実装にかかる時間（time-to-implementation）が低減される。例示的な実施形態はこれを、システムレベルの材料とネットワークレベルのサービスおよびアプリケーションを作成して、市場の全ての局面に対してデータ翻訳（セマンティックな相互運用性）を行うプラットフォームベースのソリューションを提供することで行っている。総合的なアーキテクチャ、インフラストラクチャ、ソフトウェアおよびサービスも提供される。例示的な実施形態は、高速で柔軟性のある接続性およびレガシープラットフォームの経時的な進歩を可能とし、システムインテグレーションの垂直性（system integration plumbing）のかなりの部分（例えば７０％）を処理することができるので、ネットワークへの参加者を迅速に作成し、付加価値のあるサービスの消費、および営利目的の私企業であるネットワークサービスと、非営利の公的なネットワークデータ消費者との間の融合を可能とすることができる。全てのＣＢ機器／プラットフォームレベルの処理は暗号化、監査される可能性があり、公認のペイロード交換モデル（例えばＸＭＬカノニカル）を利用する可能性があるので、全ての機器レベルのピアは、例えば公認のエコシステムピアサービスを利用して、処理の一端（または両端）においてセマンティックにペイロードデータを検証（validate）することができる。故に、信用できる相互運用交換ネットワークを、ＣＢＲルータ／ＣＢ機器および関連するカノニカルを用いて形成することができる。例示的な実施形態ではさらに、プラットフォーム（例えばＣＢ機器および関連するカノニカル）をプロバイダ、支払い者または医師組織内部に拡張してエッジソリューションを拡張することにより、ヘルスケア組織内全体の相互運用性という課題に対して、総合的なソリューションを提供することもできる。さらに例示的な実施形態は、既存の投資を維持しながらも、組織の成長とともに規模を調節して、レガシーシステムの経時的な進歩をサポートする、という、小から大へのヘルスケア環境のスケーラビリティを可能としつつも、同時に最新のヘルスケア基準の適用を促す、または、加速化することもできる。故に、例示的なＣＢＲルータ／ＣＢ機器は、ＳＯＡ（Service Oriented Architecture）、ウェブサービスおよびＸＭＬ加速化、セキュリティおよびルーティングを高性能ＢＰＥＬスタイルのワークフローとともに提供し、これによりハード機器の管理容易性と、ハード機器に比して全体的にＴＣＯ（Total Cost of Ownership）が低いソフトウェアの柔軟性および仮想化機能とを組み合わせることができる。
【００３２】
アーキテクチャ面では、ＣＢ機器またはルータを含む例示的な実施形態は、コストおよび健康情報交換の複雑性を低減させるべく設計されるヘルスケア用途向け相互運用プラットフォームである。これらはエッジにおけるレガシー実装をサポートして、高度且つ高性能のサービスネットワークに参加するのに必要な労力のレベルを低減させる。これら特徴は、高度なＳＯＡ設計原理を組み込み、特にサービスプロバイダと消費者との間が契約上分離しているという問題を考慮に入れ、サービスネットワークエンドポイントの仮想化を組み込むことにより実行される。例示的な実施形態は、ビジネスプロセスを密に反映する標準ウェブサービスによりビジネスの目的を明らかにし、詳細なＸＭＬペイロードに関する性能曲線とセキュリティ面での課題を考慮し、開発の大半を特注の一回限りの実装から、再利用可能な設計時間構成にシフトさせ、ヘルスケア基準の採用を、平均的な開発者がよりアクセスし易くすることにより加速化し、管理部門の仕事量を、影響力を持つメッセージ、および用語の標準化に限定することで低減させ、ＥＤＩ（Electronic Data Interchange）からＸＭＬに切り替える際の学習曲線を低減させ、用語の標準化をヘルスケアビジネスという対象に正確に適用する際の産業特有の専門性を理解して成文化し、データの二次利用という価値命題を、セマンティックな相互運用性を可能とするスケーラブルなソリューションと結びつける。
【００３３】
図５Ａ、５Ｂ、５Ｃは、典型的なＨＩＥ（ヘルスケア情報交換）モデルを示し、これら全ては、本発明の例示的な実施形態に個々にまたは同時にサポートされうる。
【００３４】
特に、図５Ａは、ＨＩＥ５１０４が患者データ用に単一の記憶装置５１０６を利用し、マスター患者インデックス（ＭＰＩ）および記録ロケータサービス（ＲＬＳ）を、この中央位置からネットワークの他の実体またはノードに提供する集中型モデル５１０２を示し、これら他の実体またはノードの例は、ＩＰＡ（Independent Physicians Association）５１０８およびそのデータベース５１０９、診療所５１１０およびそのデータベース、病院５１１２およびそのデータベース、医療支払い者（例えば保険会社、政府系機関等）５１１４およびそのデータベース、処方薬または医薬プロバイダ５１１６、およびそのデータベース、および、研究所５１１８およびそのデータベースが挙げられる。集中型アーキテクチャは、患者の同意の面で優れたモデルを提供するとともに、患者データについて一貫性のあるセキュリティポリシーを可能とし、且つ、参加者全てについて単一の規格を強制することができる。さらに、集中型のモデルにより、直接的な臨床処置に加えて匿名のデータの分析をビジネスあるいは政府に利用可能にすることで、患者データの二次利用が可能となる。
【００３５】
図５Ｂは、連邦モデル５２０２を示し、ここでは、他の実体またはノード（例えば５１０８、５１１０、５１２、５１１２４、５１１６、５１１８）および関連ローカルデータベースが患者データおよび関連情報を記憶している。連邦モデルは、患者情報の発見に中央ＭＰＩ／ＲＬＳ（マスター患者インデックス／記録ロケータサービス）サービスを提供するが、臨床データは各ソースノードにローカルに格納されて続ける。連邦モデルは、高度なローカル制御を提供するが、各エンドポイントに性能の負担がかかる、というのも、要求される時点で利用可能としておく必要があるからである。最後に、さらなる課題は、全ての参加ノードで患者の同意およびプライバシの一貫性をサポートする必要があるということである。
【００３６】
図５Ｃは、ハイブリッドモデル５３０２を示し、ここでは幾らかのデータが中央記憶装置またはデータベース（例えば５３０６、５３０７、５３０８）に記憶されているが、他のデータは、ネットワークの他の実体またはノード（例えば５１０８、５１１０、５１２、５１１２４、５１１６、５１１８）に関連付けられているローカルデータベース格納されている。ハイブリッドモデルは、幾らかの患者情報を中央で保管し、他の患者情報を各ノードで保管する、というものである。ハイブリッドモデルはＭＰＩおよびＲＬＳサービスを中央から提供するが、実際のデータは中央とローカルの記憶装置間で分割して保管する。ハイブリッドモデルは、純粋に連邦のモデルよりも性能面で向上しており、且つ、一般的な患者の人口統計データおよび時折またはオプションとしては重要な処置情報等の幾らかのデータは中央で保管することができる。ハイブリッドモデルでは、ローカルノードは、特定の医療情報が必要なときにクエリされるので、連邦モデルと同様の可用度およびセキュリティが確保される。いずれのモデルを選んでも、ＨＩＥコストおよび複雑性の管理という最終的な目的は同じである。  図１は、サービスネットワークがハイブリッドＨＩＥモデルの参加者間で作成されている例示的な実施形態を示す。第１のノード（例えば１０２０）は、別のノード（例えば１１０２）に対してサービスを要求し、夫々のＣＢ機器（例えば１０２６、１０３６）が翻訳を行い、インターネット（１１０７）を通じて通信して、さらには、これもＣＢ機器（例えば１０４６）を持ち翻訳、トラッキング等の機能を有するネットワークコア（例えば１３０２）に対してサービスの提供を依頼したり、該ネットワークコアに対して中央で保管するべき情報を提供したりする。
【００３７】
特に、図１に示すように、ノード１０２０等のサービスリクエスタは、例えば病院、診療所、または医院であってよい。図１に示すように、ノードは、内部システム１０２２（例えば、データベースまたはデータ記憶機能を含みうる）、オプションの情報交換１０２４、コンテンツベースのルータまたはＣＢ機器１０２６および関連データベースまたはデータ記憶装置１０２８を含むことができ、さらに、リンク１４０２との関連で図１に示すＭＬＬＰ／ｆｔｐ／ｑｕｅｕｅ／ＨＴＴＰメッセージを介したＨＬ７／ＮＣＰＤＰ／ＡＳＣ  Ｘ１２等の同じデータフォーマットまたは規格を利用またはサポートするノード１０３０等の別のノードとの直接リンク１４０２通信を処理するローカル内部インタフェースを含むことができる。図１に示すように、ノード１０３２は、内部システム１０３２（例えば、データベースまたはデータ記憶機能を含みうる）、オプションの内部情報交換１０３４、コンテンツベースのルータまたは関連データベースまたはデータ記憶装置１０３８に接続されたＣＢ機器１０３６を含むサービスプロバイダであってよく、これは、研究所／薬局宛発行書またはメッセージ１４０４を、提携している研究所または薬局に直接発行することができる。サービスネットワークのノードは、例えばあるイベントにおいてはリクエスタになり、別のイベントではプロバイダになる、といった具合に、サービスリクエスタおよび／またはサービスプロバイダになることができる。図１はさらにヘルスケア情報ネットワークコア１３０２を示しており、これは、マスター患者インデックス（ＭＰＩ）サービス１３０４、記録／リソースロケータサービス１３０６、制御用語サービス１３０８（例えば、データの検証および／またはデータ用語の相関付けまたは解釈用）、臨床データレポジトリ１３１０および関連データベースまたはデータ記憶装置１３１２、オプションの内部情報交換１３１４、患者同意および承認サービス１３２０（例えば、様々な患者の代わりに、または彼らに関して提供された、現在有効な、および／または、過去の、同意または承認の記憶および／またはトラッキング用）、ポータルサーバ１３１８（例えば、インターネットその他の実体への接続用）、およびコンテンツベースのルータまたはＣＢ機器１０４６および関連データベースまたはデータ記憶装置１３１６を含む、またはサポートしてよい。各ＣＢ機器に接続および関連付けられているデータベースまたは記憶装置１０２８、１０３８、１３１６は、例えば、ネットワークで利用されるカノニカルおよび各ＣＢ機器によりネットワークに接続されている外部実体が利用するデータフォーマットまたは基準間のマッピングを格納して、データを、１つのイベントの固有のネットワーク識別子、またはイベントのローカル識別子等の情報に関連付けて格納する。図１はさらに、ネットワークの他のノードとの間で、リンク１１０８、１１０６を介してインターネット１１０７と通信しうる物理ポータルクライアント１２０２および患者ポータルクライアント１２０４を示している。さらに図１はＣＢ機器１０２６、１０３６、１０４６が、互いに、インターネット１１０７を通じて、ネットワーク内で利用される共通のカノニカル（例え���カノニカルＨＬ７／ＳＯＡＰ／ＨＴＴＰＳ、これは、例えば、単純なオブジェクトアクセスプロトコルおよびＸＭＬプロトコルをＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  Ｓｅｃｕｒｅを介して利用する標準ＨＬ７の認識されたあるいは所定のサブセットを利用するカノニカルを示しうる）と一貫した通信を伝送するリンク１１０２、１１０４、１１０５を介して通信することが示されている。
【００３８】
故に、図１に示す実施形態によると、ノード１０２０等のサービスリクエスタは、患者情報の幾らかがＨＩＥネットワークコア１３０２に配置され、幾らかが別のメンバーソースノード（例えば、サービスプロバイダ１０３０にある専門診療所の研究所検査）に配置されている患者履歴を要求することができる。ＨＩＥネットワークコア１３０２内では、キーインフラストラクチャサービス（例えばＥＩＳ、ＲＬＵＳ、ＣＴＳ，ＣＤＲ、ＰＣＡ，ＡＡＡ等）が仮想化されて、参加ノード（例えば１０２０、１０３０）へ戻ってよい。加えて、ＣＢＲシステムは、さらなる付加価値サービスに「プラグイン」する、あるいは、ネットワーク参加者に対して利用可能とする。付加価値サービスの例には、保険加入資格、請求処理および裁定、ｅ処方、処方コンプライアンス、薬物相互作用サービス、個人健康記録（ＰＨＲ）を含む消費者サービスが含まれる。
【００３９】
上述したように、例示的な実施形態は、ＨＩＥ配置モデル（集中型、連邦、ハイブリッド）３つの全てをサポートすることができ、特定のネットワーク配置または構成の性質またはモデルは、特定の産業の区分および採用されているワークフロー要件に応じて変化させることができる。例えば、厚生省または政府系配置モデルでは、データ交換要件はしばしば、サポートされている利用モデルのサブセットであり、公的および私的ネットワーク全体の階層化されたスーパーピア間で主にイベント主導型のものとなる。この配置モデルは、データ交換においては連邦またはハイブリッドモデルを示しており、より短期間でより少ない場所により少ない情報を維持する。情報が常に変わることにより、このモデルは、ネットワークのいずれの地点からでも「オンデマンド」でデータを監査、検証、および正規化する機能を有するロバストなネットワーク情報科学交換モデルを必要としうる。
【００４０】
例示的なＣＢＲネットワーク実施形態がローカルヘルスケア交換内で配置されるケース、あるいは州立の、地域の、または私営のネットワークレベルで配置されるケースにおいては、多量およびＩ／Ｏ（入出力）密度機能が必要とされうる。これら交換モデルは、データおよびビジネスの目的の種類においてさらなるバリエーションを必要とする場合があり、システム対システムの交換の代わりに同意共有レベルにより多数の産業組織間で多くのばらばらのレガシーシステム間の相互作用を必要とする可能性がある。このようなネットワークは、サービスの配置および消費においてワークフロー重視の方法を必要としうる。このシナリオでは、参加者は概して、構築されたデータおよびデータ添付物を生成および消費して、その後、同じ体系およびシンタックス様式を持つエンドポイント間で移動させる。これら実装例は、ＣＢ機器を集中型またはハイブリッドの配置モデルのバックボーンまたはコアのコンポーネントとして、およびネットワークの各参加機関またはノードのエッジに配置して、コアその他のエッジ構成物から臨床情報を収集、検証およびプッシュ／プルする。
【００４１】
例示的な実施形態では、ＣＢ機器は、患者と臨床士との間で日常的な医療処置およびやりとりの大多数（例えば８０％を超える）が行われる個人医院または小規模医療グループといった、産業トライアングルの最も広い基部に提供される。そこにおいては、体系的、シンタティック、およびセマンティックなサービス、ビジネスサービスおよび臨床プロトコルが効果的に適用されることで、アクセス向上、品質向上、および処置コストの低減の見込みがある。
【００４２】
図２は、例示的な実施形態の機能および特徴を示す。図２に示すように、ＣＢ機器を含む病院プロバイダ２００２は、キューおよびメッセージバスを含み、サービス要求（例えば２０１２）を実体から受信することができるが、実体の例としては、データ変換関数に関するサービスコンテナ（例えば病院プロバイダが利用する情報フォーマットまたは規格から、ネットワークで利用されるカノニカル等）、および、ビジネス規則、アルゴリズム、メタデータ記憶装置、データセキュリティ／ＡＡＡ（Authentication, Authorization, Accounting）、および、監査および監視または管理機能に関する専門医師２０１４、会計専門士２０１６、プライマリケア医師２０１８等が含まれる。ＣＢ機器は、ＸＭＬインタフェースおよびインターネット２０１０を通じてネットワークノード２００８と通信してよく、ここでノード２００８は、同様の機能を提供するＣＢ機器を有する。患者情報は、インターネット２０１０経由でネットワークに接続されたアクセスポータル２００６を介して見ることができ、情報は、患者閲覧コンテナの形態での閲覧またはパッケージングが可能であり、同様に、閲覧者の特権または権利に応じた制限または制約が可能である。ＵＤＤＩ（Universal Description, Discovery and Integration）機能を有する地域の健康情報組織（ＲＨＩＯ）サービスレジストリ２０３４も、ノード２００８との関連で提供されてよく、患者の同意２０２０、ＲＬＳ（記録ロケータサービス）２０２２、支払い者承認２０２４、データ分析２０２６、請求処理２０２８、プロバイダディレクトリ２０３０、ＲＨＩＯ記憶装置２０３２等の様々なサービスへリンクしたり、これを参照したりすることができる。例えば検索、承認、識別、ポリシーおよび合意管理、認証、ワークフロー、格納、監査、宣伝メッセージ、同意管理、医師コンシェルジュサービス等の、さらなるヘルスケア情報交換サービス２０４０も提供が可能である。
【００４３】
図３は、例示的なＣＢ機器３００２のソフトウェアコンポーネントを示す。図３に示すように、機器３００２は、ワークフローＧＵＩ（グラフィックユーザインタフェース）３００４、ワークフローエンジン３００６、管理ユーザインタフェース３０３２、およびオペレーション管理モジュール３０３０を含む。さらには、例えばデータをカノニカルフォーマットまたはコンプライアンスからコンバートする、またこれにコンバートするコンバージョンモジュ−ル３００８、データをカノニカル要件または標準（シンタックス、文法、および／または内容のうち１以上を含むがこれらに限定されない）に照らして検証する検証モジュール３０１０、セキュリティまたは信用レベルを決定しうるセキュリティおよび信用モジュール３０１２、フィルタリングモジュール３０１４、変換モジュール３０１６、ルーティングモジュール３０１８、メッセージ仲介モジュール３０２０、信用できるメッセージモジュール３０２２、データベースサービスモジュール３０２４、およびカスタマイズされたサービスモジュール３０２６が含まれている。さらには、外部サービス呼び出しフレームワークまたは仕様３０２８が含まれており、さらには、メッセージコンテキストモジュール３０３４、ＳＯＡＰ／ＷＳモジュール３０３６、ＸＭＬ／ＷＳセキュリティモジュール３０３８、ＸＭＬコアライブラリモジュール３０４０、ＡＡＡモジュール３０４２、メッセージおよび接続モジュール３０４４、アプリケーションインテグレーションフレームワーク３０４６、暗号化モジュール３０４８、およびサーバＯＳ（オペレーティングシステム）プラットフォーム３０５０およびインテルサーバハードウェアプラットフォーム３０５２を含む他のモジュールも含まれている。機器３００２の様々なコンポーネントは大量生産製品／既製品、第三者のコンポーネント、および／または、インテルのコンポーネントであってもよい。
【００４４】
本発明の例示的な実施形態のＣＢ機器またはルータが利用するカノニカルは、特定用途に向けたオブジェクトレベルの修正が容易である標準化されたオブジェクトである点に留意されたい。カノニカルは、特定のビジネスプロセスに関連する全ての情報を含む。カノニカルは、いずれのアプリケーションからも独立して、そこに実装される情報アーキテクチャおよび技術インフラストラクチャから独立して（別個に）構成され、メッセージ定義を正確にすることで、一貫した実装を確実に行い、ビジネスプロセスを駆動するデータを見通すことができ、特定のビジネスのニーズに応え、固有に適用することができ、常に変わる状況、標準への適用およびニーズ等をサポートする柔軟性を備える。
【００４５】
本発明の例示的な実施形態では、ＣＢ機器が利用するカノニカルフォームは、標準化情報モデル、つまり、細かく細分化された合成ウェブサービスのＸＭＬビジネスオブジェクトとして露呈されているＨＬ７  ｖ３参照情報モデル（ＲＩＭ）のサブセットを表す。これは、ＨＬ７、ＮＣＰＤＰ、ｘ１２メッセージフォーマットからの様々なレガシー実装からのシンタックス変換、および、ＳＮＯＭＥＤ  ＣＴ，ＬＯＩＮＣ、ＣＰＴ，ＩＣＤ９および１０等の用語規格へのセマンティック変換を含む。カノニカルフォームは、ＨＬ７臨床ドキュメントアーキテクチャ（ＣＤＡ）Ｒ２、ＡＳＴＭ臨床処置記録（ＣＣＲ）または調和ＣＣＤで表されてよい。そのフォーム自身およびＲＩＭ実装は、１）カノニカルの開発および生成中の情報モデルツールを適用すること、２）そのシブリングスキーマが、標準に対する情報科学モデルに対する変換および制限制御すること、および、３）レガシーデータマッピングインタフェースのエンベロープ全体への提供方法、により制限されうる。故に、ＣＢ機器に共通のカノニカルまたはカノニカルフォームは、予め検証されたＢＰＥＬ編成とともに、患者およびプロバイダ識別用の実体識別サービス（ＥＩＳ）、記録、配置、および更新サービス用のＲＬＳサービス、一式の用語サービスおよびセマンティックツーリング／マッピング、カノニカルの規格認証および承認メカニズム、監査、トレーサビリティ、永続性および管理、および、患者の合意および承認（ＰＣＡ）サービスの実装に利用することができる。
【００４６】
ネットワークでＣＢ機器による共通のカノニカルまたはカノニカルフォームを利用する、ということは、健康情報の各交換が、相互作用の共通セットを受けるということである。これにより、データの相互運用性が確かに行われ、データ品質を豊かにし、確かにし、メッセージをサービスネットワークを通過する際に完全に監査して資格を与える（qualify）ことができる。本発明の例示的な実施形態は、世界中のヘルスケアの現状維持を生み出しているように見えるコストの高い、一回限りの実装ではなくて、生成された（productized）フォームファクタの反復可能なオペレーションセットである単一のインスタンス化にこれら相互作用を検証および制限することで、このソリューションをスケーリングすることができる。
【００４７】
図４は、カノニカルを利用することで、必要な翻訳または変換が上述のＮ＋１のバリエーションに低減されるという恩恵をネットワークが受ける様子を示す簡略図である。図４に示すように、ネットワーク４０２内では、病院４１８、支払い者４２０、プロバイダ４２２、ＰＨＲ（公衆衛生上の地域）４１６、および医薬プロバイダ４１４がＣＢＲサービスネットワーク４２４に接続されており、各々がＣＢ機器を提供され（不図示）、共通のカノニカルへの翻訳を行い、ネットワークと通信して、カノニカルに適合したメッセージ（例えば４０８）がネットワーク内を通過するようにしてよい。セマンティックインテグレーションツールセット４０４はさらに、様々なサービス４１０および公認エコシステムサービス４１２（例えば、カノニカルに適合する必要のある任意のサービス、情報モデル４０６に格納可能であり、例えば検証目的に利用可能な、任意のさらなる要件を含みうる）同様、ネットワーク４０２との関連で提供される。共通のカノニカルが利用されるということから、各ネットワークノード（４３１８、４２０、４２２、４０８、４１６、４１４）は、各ローカルデータフォーマットから互いに他のローカルデータフォーマットへの多数の接続および多数のマップの代わりに、関連ＣＢ機器を介したネットワーク４２４への唯一の接続およびローカルデータフォーマットからカノニカルフォーマットへの１つのマッピングを利用することで、参加することができる。
【００４８】
図６は、例示的な実施形態のネットワークのうち、スーパピアトポロジーネットワークを示す。図６に示すように、別個のネットワーク６１４、６１６、および６１８は、互いにノードまたはコンステレーションとしてリンクされて、より大きなネットワーク６０２を形成しており、ここでネットワーク各々６１４、６１６、６１８は、互いに、共通サービスバス６０４沿いに、ＣＢ機器６０８、６１０、６１２を介して通信する。別個のネットワークはオプションとして、内部の共通のカノニカルを利用することができ、図示されているように、ネットワーク６１４、６１８はカノニカル（例えば、別個のネットワーク内で巡回するカノニカルメッセージまたはカノニカルに適合したメッセージ６１５、６１９）を用い、一方で、ネットワーク６１６はカノニカルを用いない。図６に示すように、ネットワーク６１４は退役軍人管理病院または実体６２２、および、国防省軍部ヘルスケアシステム実体６２０を含む。ネットワーク６１６は、病院ネットワークのカイザー・パーマネンテ６２６およびフロリダヘルス情報ネットワーク実体６２４を含み、ネットワーク６１８は、医療研究所／医薬供給所６２８および公衆衛生情報ネットワーク実体６３０（例えば、米国疾病対策センタが管理している）を含む。ネットワーク６０２およびオプションとしては参加者ネットワーク６１４、６１８は、公認エコシステムであってよく、ここではＣＢＲサービス６３４（例えば、ＣＢ機器機能および対応するカノニカルフォームまたは規格）が利用可能である（例えば、サービスコンテナ、信頼あるメッセージング、スキーマ検証、メッセージレベルセキュリティ、コンテンツベースのルーティング、監査、ＷＳ／ＳＣＡ産業規格コンプライアンス、ワークフロー編成、規則エンジン、ハイパーＥＳＢ（Enterprise Service Bus）、ヘルスケアアダプタまたはマップ（例えば、ローカルデータフォーマットと共通カノニカルとの間の）、および共通カノニカル）。エコシステムで、または、エコシステムがネットワーク全体およびサブネットワークの参加ノードを含むエコシステムのローカル地域でさらに利用可能または認識されているものは（例えば６１４、６２０、６２２、６１６、６２４、６２６等）、ローカルまたはＣＢ機器により供給されうる遠隔ウェブサービス６３６であり、例えば患者同意および承認、ポリシー、データ保護法および規定（および／または、例えば、ＣＢ機器を流れるデータに対するＣＢ機器による強制によって、その規定によりネットワークの情報の流れを統括する規則）、役割およびコンテキストベースのセキュリティ（これは、ＣＢ機器により、ＣＢ機器を流れるデータに対しても実装されうる）、決定サポート、臨床プロトコル（ライブラリおよび／または規則）、動的サービス発見および登録、サービスディレクトリ、プロバイダディレクトリ、ＭＰＩ／ＲＬＳ、用語サービス、教育上のコンテンツ等が含まれる。
【００４９】
図７は、本発明の例示的な実施形態による例示的なデータ交換ネットワーク利用のケースを示し、ここで、区別されていないネットワーク７０１４は、「プレシャスハート」医療センタ７００８、「ワーフ医療グループ」クリニック７０１０、および患者であるブルー・ウォータズ氏７００２の処置７００４を仲介する「Ｔｒｉｃａｒｅ保険」プロバイダ７０１２を含むＴｒｉｃａｒｅネットワーク７００６を含む。区別されていないネットワーク７０１４はさらに、フロリダヘルス情報ネットワーク７０１６、メキシコ湾州地域ヘルス情報組織７０１８、およびカリフォルニア地域ヘルス情報組織７０２０を含む。ネットワーク７０１４は、ＣＢＲ公認エコシステム７０２４との間で様々な相互作用７０２２を行うことができ、これには、例えば、患者の医療履歴情報の要求および受信、診断／研究所の結果の受信、検査および投薬のオーダ、請求処理、医療履歴記録の更新等が含まれうる。エコシステム７０２４は、ＣＢ機器または機器の集まり（例えば、単一の実体として透明に活動する多数のＣＢ機器のグループ）を含み、サービスコンテナ７０２８、信用できるメッセージ７０３０、スキーマ検証７０３２、メッセージレベルセキュリティ７０３４、コンテンツベースのルーティング７０３６、監査、ＷＳ／ＳＣＡ産業規格コンプライアンス７０３８、ワークフロー編成７０４０、規則エンジン７０４２、ハイパーＥＳＢ（Enterprise Service Bus）  ７０４４、およびヘルスケアアダプタ７０４６を含むサービス／機能を提供する。エコシステム７０２４は、例えば患者同意および承認７０５２、ポリシー７０５４、データ保護法および規定７０５６（および／または、ＣＢ機器を流れるデータに対するＣＢ機器による強制によって、その規定によりネットワークの情報の流れを統括する規則）役割およびコンテキストベースのセキュリティ７０５８（これは、ＣＢ機器により、ＣＢ機器を流れるデータに対しても実装されうる）、決定サポート７０６０、臨床プロトコル（ライブラリおよび／または規則）、動的サービス発見および登録７０６２、サービスディレクトリ７０６４、プロバイダディレクトリ７０６６、ＭＰＩ／ＲＬＳ７０６８、用語サービス７０７０、教育上のコンテンツ等のＣＢ機器等のローカルまたは遠隔ウェブサービスをサポートしうる。エコシステム７０２４は、さらに、開発されたネットワーク７０７２との間で様々な相互作用７０４８を行うことができ、これには、例えば認証／承認、患者記録の発見、患者記録の取得、データの正規化および集積化、患者の承認／合意をチェックすること、等が含まれてよい。開発されたネットワーク７０７２は、例えばデータベース７０７６と少なくとも１つの病院７０７８とを含む国防省軍部ヘルスケアシステム７０７４を含むことができ、さらに、医薬プロバイダ７０８０、１以上の研究所７０８２、および公衆衛生情報ネットワーク実体７０８４を含みうる。
【００５０】
図８は、本発明の一実施形態の例示的なＸＭＬ処理機能を示し、ここでＣＢ機器を含むノードはＳＯＡＰメッセージを交換する。特に図８は、インターネット８０８にリンク８０６、８１２をそれぞれ介して接続して、ＳＯＡＰメッセージ（例えばメッセージ８１６）を、リンクを介して送信するウェブサービス８０４およびウェブサービスクライアント８１４を示す。インターネット８０８は、リンク８１０を介して、ローカルエリアネットワークスイッチ８２０へルータ８１８を介してＳＯＡＰメッセージを伝送して、これらメッセージは次に、外部のファイヤウォール８２２を介してコンテンツスイッチ８２４へ渡され、さらにＣＢ機器８２６、８３０へ渡される。機器８２６は、ディレクトリに接続して、ディレクトリおよびＩＤサーバまたはデータ記憶装置８２８を識別して、ＳＯＡＰメッセージをＨＴＴＰリンク８３１を介して内部ファイヤウォール８３２を通じてウェブサーバ８３４へ送信して、さらに、ＳＯＡＰメッセージがアプリケーションサーバ８３８、およびデータベースまたはデータ記憶装置８３６へＨＴＴＰリンクを介して伝送される。このモデルにより、終了および開始、ＳＯＡＰ検証、認証／承認／監査、署名／検証、および暗号／復号を含むウェブサービスセキュリティ、証明書伝播／ＳＡＭＬ、ＸＭＬ進入防止、コンテンツベースのロードバランシング、プロトコルブローカ業務（ＭＱ、ＪＭＳ）、ｅｂＸＭＬセキュリティ、ＭＩＭＥ／ＤＩＭＥ処理、および添付操作が可能となる。
【００５１】
図９は、本発明の例示的な実施形態によるカノニカル処理フロー９００２を示すが、ここで元の臨床データソース「ａ」９００４および別の元の臨床データソース「ｂ」９００８は、ネイティブシステム情報９００６を、サービスバス９０１４のインタフェース／マッパ９０１０に提供する。マッパ９０１０は、情報をＲＩＭ制限ツール９０１２のカノニカル変換９０１６およびカノニカルスキーマ９０１８に提供して、さらにこれらが出力を制限ツール９０１２内の臨床ビジネス交換カノニカル９０２０に提供する。交換カノニカル９０２０は、出力を、コンテンツルータ９０２２のパイプラインプロセッサに提供する。コンポーネント９０１０−９０２２は全てＣＢ機器内にあってよい。コンテンツルータ９０２２は、処理済みのデータ（部材９０１０、９０１６、９０１８、９０２０が処理する）を、検証サービス９０２４に検証用に送ってよく、処理済データを暗号化されたカノニカルフォーム９０２８で、リンク９０２６を介してヘルス情報交換９０３０へ送ってよい。交換９０３０は、情報を暗号化されたカノニカルフォームで（例えば９０３２）、リンク９０３８を介して、部材９０１０−９０２２と同様の方法で配置または接続されたコンテンツルータ９０３４、交換カノニカル９０４０、カノニカル変換９０４２、カノニカルスキーマ９０４４、およびインタフェース／マッパ９０４６を含む別のＣＢ交換へ送ってよい。交換９０３０からの情報は、情報９００６が第１のＣＢ機器の部材９０１０−９０２２を流れる順序とは反対の順序で、部材９０３４−９０４６を流れてよく、ネーティブシステム情報９０５０として、要求元の臨床「ａ」データソース９０４８および／または要求元の臨床「ｂ」データソース９０５２へ提供される。
【００５２】
図１０は、本発明の一実施形態によるネットワークを介した研究所の結果の流れを示す。図１０に示すように、或る人１０１４がポータルインタフェース１０１６を介して研究所の検査結果を要求し、これに応じて対応する要求１０１８が要求サービス１００４に転送される。要求サービス１００４は、承認要求１０２０をセキュリティサービス１００６に送り、返信または受領確認１０２２を受信すると、要求１０２４をインデックスサービス１００８へ送り、所望の情報を有する研究所を探す、または特定する。インデックスサービス１００８は、患者を、要求された研究所検査に結びつけるマスター識別子１０２６を返し、要求サービス１００４はこの情報を利用してクエリ１０２８をロケータサービス１０１０へ送り、研究所検査結果の位置を探す。ロケータサービス１０１０は、返信１０３０を要求サービス１００４に送り、要求サービス１００４は返信中の情報を利用して、患者の研究所結果要求１０３２を生成して、ロケータサービス１０１０が、所望の研究所結果情報を所有するとして特定したソース位置１０１２に送る。要求１０３２は信用できる要求であってよく（例えば、健康情報交換が（またはその代わりに）ソース研究所に対して送った要求）、これはその後エッジで、またはＨＩＥのネットワークコアで監査されてよい（例えば研究所をＨＩＥネットワークに接続するＣＢ機器により）。ソース位置１０１２は、ローカルＥＭＰＩ（Enterprise master Patient Index）サービス機能によりサポートされてよく、患者の識別子をＨＩＥから受信して、適切な研究所検査結果記録を特定および発見することができる。ソース位置１０１２は、この要求に対して、研究所結果１０３４を要求サービス１００４に送ることで応答してよく、要求サービス１００４はこれに応じて、研究所結果情報をメッセージ１０３６のポータルインタフェース１０１６に中継する。インデックスサービス１００８は、健康情報交換レジストリまたはプロバイダに連合されても、関連付けられもよく、両端部で監査されてもよい（例えば、そこから要求を受信する実体により、および、要求を渡されるＨＩＥレジスタまたはプロバイダにより）。
【００５３】
図１１は、長期的健康記録（ＬＨＲ）（例えば、経時的な多数のエントリまたは時間関連データを含む患者の健康記録）の基本コンポーネントアーキテクチャ１１１０２を示す。図１１に示すように、臨床クライアントユーザ１１１０４は、「入手」または「リスト」といったコマンドを利用して、所望の記録を健康情報ネットワークデータベースまたはデータ記憶装置から発見することができ、患者のカノニカルを利用して、外来診察（患者がヘルスケアを受けた、および／または、健康情報を提供した、といったイベント）およびオーダ（例えば患者に提供または処方されたヘルスケアサービスまたは製品等）の関係を表したりコンテキストを提供したりする個人健康記録を取得することができる。臨床クライアントユーザ１１１０４はさらに、返信された、又は受信した記録ロケータサービスおよび記録識別子（例えば個人健康記録とともに受信された）を利用して、患者のヘルスケア履歴から外来診察またはオーダに関する詳細を取得または要求することができる。臨床クライアントユーザ１１１０４からのメッセージは（例えば、患者に医療行為を行おうとして、診断、処置、監視等に役立つ患者の情報を所望する診療所の医者）は、健康情報ネットワーク（ＨＩＮ）ドメイン１１１０６へ渡されるが、これは、要求を、ドメイン１１１０６のＣＢ機器またはルータ１１１１０に渡すＬＨＲポータル１１１０８を有し、これは、ドメイン１１１０６のデータ記憶装置１１１１６に接続された作成読み出し更新削除（ＣＲＵＤ）メカニズム１１１４に接続された患者カノニカル１１２に接続する。ドメイン１１１０６のＬＨＲポータル１１１０８はさらに、薬局Ｂドメイン１１１２４、研究所Ａドメイン１１１２２、病院Ｃドメイン１１１４６、および診療所Ｄドメイン１１１５８に接続する。故に、ＨＩＮドメイン１１１０６は、医薬オーダの要求１１１１８を薬局ドメイン１１１２４に転送して、研究所外来診察の要求１１１２０を研究所Ａドメイン１１１２２に転送して、病院外来診察の要求１１１１７を病院Ｃドメイン１１１４６に転送して、診療所外来診察の要求１１１１９を診療所Ｃドメイン１１１５８に転送してよい。研究所Ａドメイン１１１２２、薬局Ｂドメイン１１１２４、病院Ｃドメイン１１１４６、および診療所Ｄドメイン１１１５８は、それぞれ、ＣＢ機器１１１２６、１１１２８、１１１４８、１１１６０、外来診察またはオーダカノニカル１１１３０、１１１３２、１１１５０、１１１６２、ＣＲＵＤメカニズム１１１３４、１１１３６、１１１５２、１１１６６、およびＨＣ（ヘルスケア）アダプタ１１１３８、１１１４０、１１１５４、１１１６６、およびＨＬ７またはＮＣＰＤＰソース１１１４２、１１１４４、１１１５６、１１１６８を含む。ここで利用され図示されるＨＣアダプタは、異なる規格間を翻訳可能な部材またはモジュールであり、例えば、ＩｔｅｍＦｉｅｌｄ（登録商標）またはｉＷａｙ（登録商標）等の、大量生産される既製のデバイスまたはメカニズムであってよい。
【００５４】
図１２−１６は、本発明の例示的な実施形態による、長期的健康記録シナリオの、患者の個人健康記録に記録されている、患者の健康記録に関する情報、および、イベントその他の部材に関する特定の情報を取得する例示的な処理を示す。
【００５５】
図１２に示すように、医師または看護士は、患者に関する既知の情報（例えば名称、性別、誕生日、住所、電話番号等）をポータル１２１０４に入力する。ポータル１２１０４は、ＨＩＮ  ＣＢＲのPatient.Get()またはPatient.List()WSDLオペレーションを呼び出して、ＨＩＮを検索して、整合する患者のカノニカル記録があるかを検索する。結果はポータル１２１０４に、患者カノニカルを通じて返される。１を超える数の記録が戻された場合には、ポータルは、医師または看護士に対して、関連するカノニカルフィールドを見せて単一の記録選択を行うよう表示を行う（例えば体重等）。この時点では単一の患者カノニカル記録が医者または看護士により選択されており、ポータルはＸＭＬペイロードをディスプレイに表示することができる。特に図１２に示すように、検索結果１２１１８は、ポータル１２１０４からＨＩＮ患者カノニカル１２１０６へ進み（ここにはＣＣＤ  ＸＭＬカノニカル１２１１２が含まれている）、ここで読み出し（ＸＭＬ検索）要求をＨＩＮ患者ＣＲＵＤ１２１０８へと中継する（ここには、メタデータを介して発見されうるＳＱＬ−から−ＣＣＤへのＸＦＯＲＭアドレス１２１１４が含まれている）。ＣＲＵＤ１２１０８は、要求に対して、ＸＭＬ−ＳＱＬ（標準クエリ言語）変換を行い、要求（今はＳＱＬに準拠している）を、ＨＩＮ  ＳＱＬデータ記憶装置１２１１６を有するＨＩＮ  ＣＤＲデータ記憶装置１２１１０へ中継し、ここからＳＱＬ結果１２１２８がＨＩＮ患者ＣＲＵＤ１２１０８へ戻される。ＣＲＵＤ１２１０８は、受信したＳＱＬ結果をＸＭＬへ変換して戻し、この後、構造ＸＭＬカノニカル１２１２４の情報をＨＩＮ患者カノニカル１２１０６へ中継して戻し、ここではさらにこの情報をセマンティックＸＭＬカノニカル１２１２０でポータル１２１０４へと中継して、これにより、元の要求を満たす。
【００５６】
図１３に示すように、次の主要なステップは、関連する外来診察およびオーダを発見して表示することである。患者カノニカルは、患者情報の、人口統計データ、現在の保険、プライマリ医師の連絡先、持病、アレルギー、現在の投薬状況および予防接種状況の主要なまとめを提供する。このデータで、必要な臨床決定を行うのに十分な場合もあるが、不十分な場合は、ポータルは、「ドリルダウン」機能を医師または看護士に提供して、患者の健康記録のバージョンを見せる。この「ドリルダウン」機能を行うべく、ポータルは、記録ＩＤを患者カノニカルから抽出して、患者カノニカル記録ＩＤを利用してＨＩＮ  ＣＢＲのPersonalHeathProfile.Get()WSDLオペレーションを呼び出して、また、所望の場合には、XMLSearchFilterパラメータのキーフィルタ基準として日付範囲を呼び出す。ひとたび個人健康記録（ＰＨＲ）カノニカルＸＭＬ記録が取得されると、そのＸＭＬペイロードをディスプレイに表示する。その下にあるＨＩＮ臨床データレポジトリで利用可能な場合には、関連オーダ、外来診察、スケジュール、およびドキュメントの記録ＩＤであってよい。特に、図１３に示すように、ポータル１２１０４はまず、患者の個人健康記録のＸＭＬ要求１３０４を、ＨＩＮ  ＰＨＲカノニカル１２１０６へ送り、ここから検索要求１２１２２がＣＲＵＤ１２１０８へと渡される。ＣＲＵＤ１２１０８は、ＸＭＬからの結果をＳＱＬに変換して、変換された要求１２１２６を、データ記憶装置１２１１６を有するＨＩＮ  ＣＤＲ１２１１０に送り、これがＳＱＬ結果１２１２８を返信する。ＣＲＵＤ１２１０８は、ＳＱＬ結果をＸＭＬカノニカル１２１２４に変換して、ＨＩＮ  ＰＨＲカノニカル１２１０６へ送り、ここからセマンティックＸＭＬカノニカル１２１２０の情報がポータル１２１０４に送られ、これによりポータル要求についての患者の健康記録が提供される。
【００５７】
ポータルは、ＨＩＮから戻った個人健康記録ＸＭＬペイロードで利用可能な各取得オーダ、外来診察、スケジュール、およびドキュメントのハイパーリンクを提供する。集中型の配置では、ハイパーリンク（例えば「外来診察」）を選択すると、上述の個人健康記録から取得した記録ＩＤを利用してHIN CBR GET()WSDLオペレーションを呼び出して外来診察（または、オーダまたはドキュメント等）を取得する。
【００５８】
特に図１４に示すように、ポータル１２１０４は、特定のオーダまたは外来診察の要求１４０４を、適切な外来診察／オーダカノニカル１２１０７に送り、ここから、対応するＣＲＵＤ読み出し要求１２１２２がＨＩＮオーダ／外来診察ＣＲＵＤ１２１０９に中継され、ここで、ＸＭＬからの要求をＳＱＬに変換して、ＳＱＬ要求１２１２６を、データ記憶装置１２１１６を有するＨＩＮ  ＣＤＲ１２１１０に送る。ＨＩＮ  ＣＤＲ１２１１０は、ＳＱＬ結果１２１２８を返信し、ここで、ＣＲＵＤ１２１０９がＸＭＬに変換により戻されて、構造ＸＭＬカノニカルメッセージ１２１２４としてカノニカル部材１２１０７へ中継され、そこから、要求された情報がセマンティックＸＭＬカノニカル１２１２０としてポータル１２１０４へと中継される。
【００５９】
連合された、またはハイブリッドの配置では、ハイパーリンクが選択されると（例えば、オーダ）、HIN CBR Locate()WSDLオペレーションを呼び出して、記録の元のＣＢＲ（コンテンツベースのルータ、例えばＣＢ機器）ソースおよび関連するローカル記録ＩＤを見つける。ＨＩＮのこのＲＬＳエントリは、記録が最初にソースシステムに作成され、カノニカルのInitialize()オペレーションが実行されたときに構築されてよい。ひとたびLocate()が実行されると、ポータルは、Get()オペレーションを、ＣＢＲのネットワークアドレスおよびLocate()から戻された記録ＩＤを利用して呼び出す。
【００６０】
図１５に示すように、ポータル１２１０４は、特定の外来診察またはオーダの位置の要求１５１１８を、記録位置１５１０８を有するカノニカル１５１０６に送り、ここから発見要求１５１２２が、ＲＬＳ検索関数またはデータベース１５１１２を有するＨＩＮ  ＲＬＳ（記録ロケータサービス）１５１１０に送られる。ＲＬＳ１５１１０は、ＳＱＬ要求１５１２６を、ＲＬＳ  ＳＱＬデータ記憶装置１５１１６を有するＲＬＳデータベース１５１１４に送り、データベース１５１１４はＳＱＬ結果１５１２８をＲＬＳ１５１１０に戻す。ＲＬＳ１５１１０は、ＳＱＬ結果１５１２８に詳述された記録位置を、メッセージ１５１２４のカノニカル１５１０８へ戻し、カノニカル１５１０６が、位置情報をポータル１２１０４へ転送する。
【００６１】
最後のステップでは、元のソースから外来診察およびオーダの記録の詳細を取得する。集中型の配置では、Encounter,Order,Schedule or Document Get()WSDLオペレーションを呼び出すときには、ＬＨＲ利用が終了している。連邦またはハイブリッドの配置では、ポータルが、ひとたびEncounter,Order,Schedule or Document Get()WSDLオペレーションを、HIN Locate()で特定される対象ＣＢＲで呼び出すと、処理は、ローカルサイト（例えば病院、診療所、研究所等）のＣＢＲへ渡される。ネットワークのエッジのローカルＣＢＲ（例えば研究所のＣＢＲ）が、Encounter.Get()(またはOrder,Schedule,or Document)を、研究所のＣＢＲのカノニカルメタデータのインスタンス読み出すことで実行して、ローカルＣＲＵＤサービスのアドレスを取得して、これが、研究所の情報システムからカノニカルの読み出しを処理する（例えば、Ｍｙｓｉｓ  ＬＭＩＳまたは、ドキュメントの場合には、ＧＥ  ＰＡＣＳのＸ線から読み出し可能である）。
【００６２】
図１６の処理１６１０２に示すように、ポータル１２１０４は、図１５で戻された位置情報を利用してＲＬＳ位置を抽出して、その後にカノニカル記録を、メッセージ１６１２６を介して要求し、これがローカルカノニカルインタフェース１６１０６で受信される。ローカルインタフェース１６１０６は、読み出し要求１６１２８を、ルックアップＣＭＶＴ（Controlled Medical Vocabulary Translation service）およびＣＲＵＤサービスアドレス１６１１８を有するカノニカルマネージャ１６１０８に送り、マネージャ１６１０８は、インタフェース１６１０６にサービスアドレス１６１３２を返信する。インタフェース１６１０６はその後、ＸＭＬ読み出し要求１６３４を、ローカルＣＲＵＤ１６１１２へ送り、ここから、ＨＬ７  ＭＬＬＰメッセージ１６１３６が、ＨＬ７データソースまたは記憶装置１６１２４を有するローカルデータソース１６１１４へ送られる。ソース１６１１４は、要求された情報を有するＨＬ７メッセージ１６１３８を、ローカルＣＲＵＤ１６１１２へ返し、ここから、ＨＬ７からＸＭＬに変換された構造カノニカル１６１５０の情報が、インタフェース１６１０６へ送られ、ここから、この情報１６１４０が、医療コード翻訳機能または関数（function）１６１２０を有するＣＭＶＴ（Controlled Medical Vocabulary translation service）部材１６１１０へ中継される。部材１６１１０は、カノニカル対セマンティック変換を完全に形成し、完全形成カノニカル１６１４８をインタフェース１６１０６に提供し、ここから、カノニカルＸＭＬ記録１６１４２がポータル１６１０４へ提供される。インタフェース１６１０６はさらに、任意のエラーコード１６１４４および／またはカノニカル記録識別子１６１４６をポータル１６１０４へ提供することができる。
【００６３】
図１７は、本発明の例示的な実施形態によるマルチプロバイダケア（ＭＰＣ）構造またはモデル１７０２を示す。特に、図１７は、プライマリ医師ドメイン１７０４、ＨＩＮドメイン１７１６、専門医のドメイン１７３２、研究所ドメイン１７４４、薬局ドメイン１７４６を示す。これらドメインは、オーダ／スケジュール／外来診察情報または互いの間の流れを、リンクを介して通信または共有する。特に、リンク１７２６および１７２８は、プライマリ医師ドメイン１７０４を、専門医ドメイン１７３２およびＨＩＮドメイン１７１６と接続する。リンク１７３０は、ＨＩＮドメイン１７１６を、専門医ドメイン１７３２と接続して、リンク１７６３および１７６１は、ＨＩＮドメイン１７１６および専門医ドメイン１７３２を、研究所ドメイン１７４４および薬局ドメイン１７４６と接続する。ドメイン１７０４、１７１６、１７３２、１７４４、１７４６はそれぞれ、ＣＢＲまたはＣＢ機器１７０６、１７１８、１７３４、１７４８、１７６６、カノニカル１７０８、１７２０、１７３６、１７５０、１７６４、およびＨＬ７またはＨＩＮ  ＳＱＬ  ＣＲＵＤ１７１０、１７２２、１７３８、１７５２、１７６２を有する。ＨＩＮドメイン１７１６は、ＨＩＮ  ＣＤＲまたはデータ記憶装置１７２４を有し、ドメイン１７０４、１７３２、１７４４、１７４６はそれぞれ、ＨＣ（ヘルスケア）アダプタ１７１２、１７４０、１７５４、１７６０およびＨＬ７またはＮＣＰＤＰソース１７１４、１７４２、１７５６、１７５８を有する。ここで利用され図示されるＨＣアダプタは、異なる規格間を翻訳可能な部材またはモジュールであり、例えば、ＩｔｅｍＦｉｅｌｄ（登録商標）またはｉＷａｙ（登録商標）等の、大量生産される既製のデバイスまたはメカニズムであってよい。
【００６４】
図１７の構造がサポートするマルチプロバイダケアのシナリオの基本的且つ例示的なフローは、以下のアクションを含む。患者は、プライマリケアを受けたいと思いたつ（通常は、銘々のかかりつけ医またはプライマリ医師に行くが、ローカル診療所または病院である場合もある）。プライマリケアにおいて、診療を行う医師は、さらなる検査または専門医への外来が必要であるかを判断する。プライマリ医師は、専門医への外来をオーダし、患者は予約をとる。患者が専門医を訪れると、患者のプロフィールおよび関連医療履歴が、ＣＢＲネットワークを介して専門医のＥＭＲで利用可能になっている。患者は専門医を訪れ、専門医は患者が研究所検査および処方が必要であるかを判断する。処方および研究所の検査はＣＢＲネットワークを利用して電子的にオーダされる。患者は研究所に予約をして、検査を行う。結果は電子的に専門医のＥＭＲに、ＣＢＲネットワーク経由で提供される。専門医は自身のメモを外来サマリーに追加して、診断結果および推奨される事柄、研究所結果および医薬オーダをプライマリケアプロバイダへ電子的に戻す。
【００６５】
図１８は、高レベルコンテンツベースのルータまたはＣＢ機器およびカノニカルの観点からのフローおよび結果生じる相互作用を示す。特に、１８０４は、プライマリ医師から専門医への参照処理であり、ここではプライマリ医師１８０６がオーダ１８０８を健康情報ネットワーク（ＨＩＮ）１８１０へ転送して、ここからメッセージ１８１２が専門医１８１４に送られ、専門医はメッセージ１８１６を介してＨＩＮ１８１０と、メッセージ１８１８を介してプライマリ医師１８０６と通信を行い、患者または患者のデータ（例えば研究所検査結果、Ｘ線等）に対する応答外来診察をスケジュールする。専門医１８１４はさらに、要求１８４６を送って処方箋調合処理１８３６を行うことでサービスリクエスタとして機能することもできる。１８３６に示すように、サービスリクエスタ１８３８（専門医１８１４、プライマリ医師１８０６、またはその他の実体）は、オーダ１８４０をＨＩＮ１８４２に送り、これにより、処方箋を調合するメッセージ１８４４によりオーダが薬局１８４６へ（承認されてから）中継される。ブロック１８２０は、研究所の検査を要求する処理を示す。サービスリクエスタ１８２２（状況に応じて専門医１８１４であってもプライマリ医師１８０６であってもよい）が、何らかの種類の研究所検査（例えば、病理検査（anaysis of a specimen）またはＸ線）のオーダ１８２４をＨＩＮ１８２６に送る。ＨＩＮ１８２６は、オーダを（承認してから）メッセージ１８２８により研究所１８３０へと中継し、ここでは、ＨＩＮと、メッセージまたはリンク１８３４を介して通信を行い、および、メッセージまたはフロー１８３２を介してサービスリクエスタ１８２２と通信を行い、要求されたアクションのスケジューリングおよび実行が行われる。
【００６６】
まとめると、図１８は、LocalCBR.Order.Initialize()を実行するサービスリクエスタを含みうるカノニカル処理のパターンを示し、ここでは、HIN.Order.Put()が実行されて、ＨＩＮ  ＣＤＲおよびＲＬＳを同期させ、HIN.ServiceProvder.Get()を実行して、オーダの対象を見つけ、最後にTargetCBR.Order.Put()を実行して、オーダを対象のサービスプロバイダ（例えば専門医、研究所または薬局）に送る。ＨＩＮは、オーダ、スケジュール、および外来診察のコピーをＣＤＲに、カノニカルフォームで、処理全体の関係、およびそれらの患者の記録との関連付けを維持するＲＬＳを少なくとも介して記録することができる。
【００６７】
サービスプロバイダは、CBR.Order.Put()オペレーションによりオーダを受信して、それをローカルＥＭＲ／内部システムに、ＨＬ７  ＣＲＵＤを介して翻訳する。サービスプロバイダはさらに、（オプションの）スケジュールについて、HIN.Scheduling.Put()を実行することで、ＨＩＮ  ＣＤＲおよびＲＬＳを同期させ、HIN.ServiceProvder.Get()を実行して、オーダの対象を発見して、最後にOrderSourceCBR.SchedulingPut()を実行して、スケジューリング結果を依頼元のオーダサービスプロバイダ（例えばプライマリ医師または専門医）に戻す。
【００６８】
外来診察結果については、サービスプロバイダは、HIN.Encounter.Put()を実行して、ＨＩＮ  ＣＤＲおよびＲＬＳを同期させ、HIN.ServiceProvder.Get()を実行して、オーダの対象を発見して、最後に、OrderSourceCBR.Encounter.Put()を実行して、外来診察結果を依頼元のオーダサービスプロバイダ（例えばプライマリ医師または専門医）に戻す。シナリオの記載方法は以下に示すが、ポイントツーポイントに非同期的に通信して、完全なワークフローを完成させるエンドポイントＣＢＲの利用をアサートする。もっともこれが唯一の有効な配置法ではなく、他のオプションも可能である。
【００６９】
他の有効な配置オプションには、以下のようなものが含まれる。第一のオプションは、ＨＩＮ「hub-and-spoke」である。このオプションでは、ソースＣＢＲまたはＣＢ機器が、Initialize()要求を許諾するが、その直後に、ワークフローをディスパッチして、ソースＣＢＲ内ではなくてＨＩＮ内で実行する。第二のオプションは、Async/publish-and-subscribeである。このオプションは、ソースＣＢＲがInitialize()要求を許諾して、メッセージをＪＭＳキューへ入力する。このキューのリスナーは、その後、ローカルＲＬＳ、ＨＩＮ、および対象ＣＢＲの通信ステップを非同期的に、且つ並行して実行する。結果は、sourceCBRInitialize()関数がリッスンしており、呼び出しの出力を戻すのに利用される返信キューに入力される。
【００７０】
このキーとなる繰り返しパターンを考えると、この利用は、以下の７つの詳細なワークフローまたはステップに分割されうる。
【００７１】
ステップ１では、プライマリ医師が専門医のケアをオーダして（治療（procedure）または外来診察）、オーダ記録をプライマリ臨床医のＥＭＲに作成する。ＥＭＲは、イベント通知をプライマリ医師のＣＢＲに送り（ＪＭＳ、ＭＬＬＰ、ファイルドロップ等により）、オーダカノニカルの「インサイドアウト」のＣＲＵＤ処理を実行して、（１）ＨＬ７オーダをＣＤＡ  ＸＭＬに変換して、（２）Order canonical Initialize()オペレーションを呼び出す。
【００７２】
プライマリ医師のCBR Order.Initialize()ワークフローは、医療語彙データフィールド用にＣＭＶＴを利用して、ＨＩＮ記録ＩＤを患者およびサービスプロバイダフィールド参照に追加するＥＭＰＩ（Enterprise Master Patient Index）を利用することで、セマンティックにＸＭＬドキュメントコンテンツを正規化して、HIN.serviceProviderカノニカルを作成して、そのGet()オペレーションを呼び出すことで、そのオーダの専門医を表すＣＢＲを特定して、集中型またはハイブリッド配置では、HIN.Order.Put()を呼び出して、オーダをＨＩＮ  ＣＤＲおよびＲＬＳに登録して、その後、オーダを専門医のＥＭＲに送るSpecialistCBR.Order.Put()を呼び出して、オーダカノニカルをローカルＣＢＲ  ＲＬＳに登録して、プレースホールダ関係を専門医の結果と（オプションとして）スケジュールとに構築する。最後に、この長期間実行される処理が、以下のステップ７で専門医が外来診察を完了するまでに終了する。
【００７３】
ステップ２で、（オプションとして）専門医は、スケジュールカノニカル応答を返し、この時点では上述したステップ１でオーダ記録が専門医のＥＭＲに受信されている。このオーダ記録はステップ１から、SpecialistCBR.Order.Put()オペレーションの結果として、ＥＭＲのワークリスト／スケジューリングキューに配置される。患者は専門医のオフィスに電話をして、予約をとる。構成されている場合には、ＥＭＲは、スケジュール応答が準備できている旨のイベント通知を専門医のＣＢＲに送る。このスケジューリングカノニカルの「インサイドアウト」ＣＲＵＤ処理が実行され、（１）ＨＬ７スケジュールをＣＤＡ  ＸＭＬに変換して、（２）スケジューリングカノニカルのInitialize()オペレーションを呼び出す。他のInitialize()同様に、カノニカルはセマンティックに正規化され、ＨＩＮに記録され（ハイブリッドおよび集中型の配置において）、正しい宛先にルーティングされる（プライマリケアＣＢＲの場合）。さらに、このステップ２で、専門医は、患者のカノニカル、および、おそらくはＰＨＲカノニカルを、（ＬＨＲ等のＡＰＩシーケンスを利用して）ＨＩＮまたはプライマリケアＣＢＲのオーダの患者ＩＤフィールドから抽出したいと所望する。これにより、専門医のＥＭＲにローカルな患者履歴が自動的に作成され、患者の外来の準備が整う。
【００７４】
ステップ３で、専門医は、処方箋をオーダする（薬（substance）のオーダ）。このステップは上述のステップ１および以下のステップ４に類似している。オーダ記録は専門医の臨床ＥＭＲに作成されている。好適には、このオーダは、プライマリケアのオーダＩＤおよび専門医外来診察ＩＤの参照を維持する。ＥＭＲは、イベント通知を専門医の臨床ＣＢＲへ送る（ＪＭＳ、ＭＬＬＰ、ファイルドロップ等により）。この「インサイドアウト」のＣＲＵＤ処理をオーダカノニカルに対して実行して、（１）ＨＬ７オーダをＣＤＡ  ＸＭＬに変換して、（２）Order canonical Initialize()オペレーションを呼び出す。専門医の臨床医のCBR Order.Initialize()ワークフローは、医療語彙データフィールド用にＣＭＶＴを利用して、ＨＩＮ記録ＩＤを患者およびサービスプロバイダフィールド参照に追加するＥＭＰＩを利用することで、セマンティックにＸＭＬドキュメントコンテンツを正規化して、HIN.ServiceProviderカノニカルを作成して、そのGet()オペレーションを呼び出すことで、そのオーダの薬局を表すＣＢＲを特定する。
【００７５】
集中型またはハイブリッド配置では、HIN.Order.Put()を呼び出して、オーダをＨＩＮ  ＣＤＲおよびＲＬＳに登録する。そして、ワークフローは、PharmacyCBR.Order.Put()を呼び出して、オーダを薬局オーダ受信システムへ送る。最後に、薬オーダカノニカルをローカルＣＢＲ  ＲＬＳに登録する。
【００７６】
ステップ４で、専門医は、研究所検査（例えば病理検査またはＸ線）をオーダする。オーダ記録が専門医の臨床ＥＭＲに作成される。ＥＭＲは、イベント通知を専門医の臨床ＣＢＲへ送る（ＪＭＳ、ＭＬＬＰ、ファイルドロップ等により）。この「インサイドアウト」のＣＲＵＤ処理をオーダカノニカルに対して実行して、（１）ＨＬ７オーダをＣＤＡ  ＸＭＬに変換して、（２）Order canonical Initialize()オペレーションを呼び出す。専門医の臨床医のCBR Order.Initialize()ワークフローは、医療語彙データフィールド用にＣＭＶＴを利用して、ＨＩＮ記録ＩＤを患者およびサービスプロバイダフィールド参照に追加するＥＭＰＩを利用することで、セマンティックにＸＭＬドキュメントコンテンツを正規化して、HIN.serviceProviderカノニカルを作成して、そのGet()オペレーションを呼び出すことで、そのオーダの研究所を表すＣＢＲを特定する。集中型またはハイブリッド配置では、ワークフローも、HIN.Order.Put()を呼び出して、オーダをＨＩＮ  ＣＤＲおよびＲＬＳに登録する。そして、ワークフローは、LabCBR.Order.Put()を呼び出して、オーダを研究所ＥＭＲまたはＬＭＩＳに送る。そして、オーダカノニカルをローカルＣＢＲ  ＲＬＳに登録して、プレースホールダ関係を、研究所の結果と（オプションとして）スケジュールとに構築する。最後に、この長期間実行される処理が、以下のステップ６で研究所が結果を完了するまでに終了する。
【００７７】
ステップ５で、（オプションとして）研究所はスケジュールカノニカル応答を返す。このステップは上述のステップ２と類似している。この時点では上述のステップ４でオーダ記録が研究所ＥＭＲに受信されている。このオーダ記録はステップ４から、labCBR.Order.Put()オペレーションの結果として、ＥＭＲまたはＬＭＩＳのワークリスト／スケジューリングキューに配置される。患者は研究所のオフィスに電話をして、予約をとる。構成されている場合には、ＥＭＲは、スケジュール応答が準備できている旨のイベント通知を研究所のＣＢＲに送る。このスケジューリングカノニカルの「インサイドアウト」ＣＲＵＤ処理が実行され、（１）ＨＬ７スケジュールをＣＤＡ  ＸＭＬに変換して、（２）スケジューリングカノニカルのInitialize()オペレーションを呼び出す。
【００７８】
他のInitialize()同様に、カノニカルはセマンティックに正規化され、ＨＩＮに記録され（ハイブリッドおよび集中型の配置において）、正しい宛先にルーティングされる（専門医のＣＢＲの場合）。さらに、このステップ５で、研究所は、患者のカノニカル、および、おそらくはＰＨＲカノニカルを、（ＬＨＲ等のＡＰＩシーケンスを利用して）ＨＩＮまたは専門医ＣＢＲのオーダの患者ＩＤフィールドから抽出したいと所望する。これにより、研究所のＥＭＲまたはＬＭＩＳにローカルな患者履歴が自動的に作成され、患者の外来の準備が整う。
【００７９】
ステップ６で、研究所は、専門医に外来診察結果を戻す。この専門医と研究所との間で長期間実行される処理の完了段階では、先ず、外来診察結果記録を研究所ＥＭＲ／ＬＭＩＳに作成する。ＥＭＲ／ＬＭＩＳは、イベント通知を研究所のＣＢＲへ送る（ＪＭＳ、ＭＬＬＰ、ファイルドロップ等により）。この「インサイドアウト」のＣＲＵＤ処理を外来診察カノニカルに対して実行して、（１）ＨＬ７外来診察をＣＤＡ  ＸＭＬに変換して、（２）Encounter canonical Initialize()オペレーションを呼び出す。研究所のCBR Order.Initialize()ワークフローは、医療語彙データフィールド用にＣＭＶＴを利用して、ＨＩＮ記録ＩＤを患者およびサービスプロバイダフィールド参照に追加するＥＭＰＩを利用することで、セマンティックにＸＭＬドキュメントコンテンツを正規化して、HIN.serviceProviderカノニカルを作成して、そのGet()オペレーションを呼び出すことで、先に作成されたオーダにより研究所の外来診察を要求した専門医を表すＣＢＲを特定する。集中型またはハイブリッド配置では、ワークフローもHIN Encounter.Put()を呼び出して、外来診察をＨＩＮ  ＣＤＲおよびＲＬＳに登録する。そして、ワークフローは、SpecialistCBR. Encounter. Put()を呼び出して、元のオーダの外来診察結果を専門医のＥＭＲに送る。
【００８０】
そして、外来診察カノニカルをローカルＣＢＲ  ＲＬＳに登録して、結果生じる、オーダと外来診察と（オプションとして）スケジュールとの関係を構築する。最後に、この長期間実行される処理は、オーダ、（オプションとして）スケジュール、および外来診察が研究所、ＨＩＮおよび専門医に記録され、全てのＲＬＳエントリおよびデータの関係が確保されると終了する。
【００８１】
ステップ７では、専門医が、処方箋および研究所結果をプライマリ医師に送ることを含む外来診察を完了する。この専門医とプライマリ医師との間で長期間実行される処理の完了段階では、先ず、外来診察結果記録を専門医のＥＭＲに作成する。この記録は、薬局オーダ、研究所オーダ、および対応する研究所結果についての全ての参照を含むべきである。ＥＭＲは、イベント通知を専門医のＣＢＲへ送る（ＪＭＳ、ＭＬＬＰ、ファイルドロップ等により）。この「インサイドアウト」のＣＲＵＤ処理を外来診察カノニカルに対して実行して、（１）ＨＬ７外来診察をＣＤＡ  ＸＭＬに変換して、（２）Encounter canonical Initialize()オペレーションを呼び出す。専門医のCBR Encounter.Initialize()ワークフローは、医療語彙データフィールド用にＣＭＶＴを利用して、ＨＩＮ記録ＩＤを患者およびサービスプロバイダフィールド参照に追加するＥＭＰＩを利用することで、セマンティックにＸＭＬドキュメントコンテンツを正規化して、HIN.serviceProviderカノニカルを作成して、そのGet()オペレーションを呼び出すことで、先に作成されたオーダにより専門医の外来診察を要求したプライマリ医師を表すＣＢＲを特定する。集中型またはハイブリッド配置では、ワークフローも、HIN.Encounter.Put()を呼び出して、外来診察をＨＩＮ  ＣＤＲおよびＲＬＳに登録する。そして、ワークフローは、PrimaryCareCBR.Encounter.Put()を呼び出して、元のオーダの外来診察結果をプライマリ医師のＥＭＲに送る。そして、外来診察カノニカルをローカルＣＢＲ  ＲＬＳに登録して、結果生じる、オーダと外来診察と（オプションとして）スケジュールとの関係を構築する。これにより、この長期間実行される処理は、オーダ、（オプションとして）スケジュール、および外来診察が、プライマリ医師のＥＭＲ、ＨＩＮ  ＣＤＲおよび専門医のＥＭＲに記録され、全てのＲＬＳエントリおよびデータの関係が確保されると終了する。これには、イベント全てのチェーンの関係が含まれているべきである（全てがその患者に関連しており、互いに関連付けられた専門医のオーダ、薬局のオーダ、研究所のオーダ、研究所の外来診察の結果、専門医の外来診察の結果）。
【００８２】
セマンティック相互運用性を算出可能とし、およびカノニカルを設計することには、明らかな利点がある。本発明の例示的な実施形態によると、カノニカル設計は、情報構造およびフォーマットに制約を与えるだけでなく、用語および投薬を＜１０−１２個の異なり重複する産業標準の正しいサブセット中から選択する＞といった産業標準用語に翻訳する。セマンティックな相互運用性を確保することにより、つまり、人間だけではなくてコンピュータも正しく理解できる標準的な情報モデルに意味を翻訳することにより、ＣＢＲシステム（例えばＣＢ機器および対応するカノニカル）は、標準化された情報フローに基づく付加価値サービスの作成をサポートすることができる。あるサマリーが、「心臓発作」という用語を用いており、別のサマリーが「心筋梗塞」という用語を用いている場合、この情報は、先ず共通用語セットに翻訳されない限り、比較できない。同様に、リシノプリルを指す処方箋＜ＡＣＥ抑制剤（血圧治療薬）＞は、先ず、処方医薬の共通語に翻訳されない限り、そのブランド名Ｚｅｓｔｒｉｌとは比較できない。しかし、標準化された情報モデルでは、医者が、糖尿病をかかえ、最近安全性に問題が見つかった特定の投薬を処方された患者の人口サブセットを迅速に特定することが出来るようになる等、高度なヘルスケア利用モデルおよびクエリがサポートされうる。
【００８３】
例示的な実施形態によると、ＨＩＰＡＡ監査サービスが提供される。米国法は、ヘルスケア機関に、保護されたヘルスケア情報への全てのアクセスの監査証跡を残し、患者からの要請に応じて提供することを義務付けている。今はまだ、この法律要件は実現に至っていない。ＣＢＲシステムであれば、「インデックススキーム」、プラットフォーム上のビジネス規則およびコンテンツベースのルーティング機能により、全ての情報フローを把握し、このサービスを作成することができる。
【００８４】
本発明の例示的な実施形態によると、患者の同意および承認（ＰＣＡ）機構が提供される。今までのところ、健康情報の交換についての患者の同意は確実には得られておらず、産業に至っては、各ヘルスケア機関が患者の健康記録を患者のものではなくて自社のＩＰとして考えている例などに見られるように、一貫性がない。今日の２つの主要な実装モデルは（全ての一度限りのものであり、反復性はない）、患者が、特定のプロバイダネットワークの参加に同意すると、全アクセス権を譲り渡す「オプトイン／オプトアウト」、または、実際の情報源に対しては何も保護が与えられず、ＰＨＲブラウザアプリケーションからの直接のサマリーへのアクセスのみが「患者の制御および意図の下に」あるとされるＰＨＲモデルである。ＣＢＲシステムであれば、各々全てのサービス交換について別個のＰＣＡサービスが自動的に起動され、患者の同意ポリシーをチェックして、異なるサービスリクエスタに対する情報の許可／拒絶／適切なフィルタリングを、信頼性を持って行うことのできる、別個のＰＣＡサービスの作成およびサポートができるようになる。
【００８５】
本発明の例示的な実施形態では、特定解除サービスが提供される。ヘルスケアにおける多くの所謂「データの二次利用」は、保護された健康情報を取り扱う前に、データを先ず様々な方法により特定解除する、または、患者を特定する情報を解除してデータをデータの消費者に対して匿名とする必要がある。臨床試験、人口管理／バイオサーベイランス、薬理ゲノム法リサーチは全て、患者データが非常に重要であるが、プライバシ、公共政策、および／または、法的理由から特定解除されるべき例である。ＣＢＲシステムでは、既存の健康情報フローを容易に傍受して並行なルートメカニズムを作成して、対象のエンドポイントの必要性に応じて情報を別個にフォーマットすることができる。例えば、ＣＤＣ（米国疾病対策センタ）は、特定の研究所結果または「対象の研究所」に対して、自動的に特定解除されたフォーマットでの送信を要求する場合がある。州によっては、研究所結果は、先ず依頼元の医師に送らずに送信することはできなかったり、先ず研究所結果を依頼元の外来診察者と再関連付けせずには送信することができなかったりする。要件各々は自動的にＣＢＲシステムに合致していてよく、これにより、並行パイプライン処理メカニズムが呼び出されて、プラットフォーム上のビジネス規則により情報フローをばらばらにしたり、強化したりすることができる。通常は、特定解除サービスはローカル、州、地域、および連邦法、並びに各機関または団体に好適な報告フォーマットにより大幅に異なる。
【００８６】
本発明の例示的な実施形態では、規制コンプライアンスサービスが提供される。データ保護、プライバシおよびヘルスケア特有の法律および規制は、ローカル、州、地域、および国、世界により異なる。これら法律は、規則エンジンに成文化され、健康情報交換に加入者ベースで提供されて、公認の参加者間のデータフローの正しいルーティング、ブロッキング、フィルタリング、および強化が促進される。前にＣＤＣおよびバイオサーベイランスについての例を示したが、個人的には、多くのヘルスケア会議に参加した経験から、公衆衛生法的要件を知らない機関が多いという印象を持っている。報告要件は「対象の研究所」および特定の診断のタイプに関連するので、ＣＤＣはルーチンとして報告要件を更新する必要がある。同様に、ＥＵのプライバシおよびデータ保護法はより複雑であり、各加盟国がこれら法律を、例えばデータ登録および通知要件において銘々の解釈で実行している現状である。米国では、プライバシおよびデータ保護法は、そこまで厳しくはないが、かなり多様であり、場合によっては、本についての難解な法律があり、これは不本意にも健康情報交換を臨床ケアの一貫として合法的に共有する妨げとなっている。これら各々は、「規制コンプライアンスサービス」を利用してある領域で適切なデータ処理および保護を実行することにより、効果的で一貫して適用されうる規則およびポリシーの例である。
【００８７】
例示的な実施形態によりＣＢＲシステムに基づき（例えばＣＢ機器および対応する共通カノニカルフォームの利用に基づき）提供されうるサービスの例は、薬物相互作用チェックサービス、薬物副作用報告サービス、処方、投薬コンプライアンスサービス、臨床試験募集、管理サービス、請求処理、請求裁定サービス、慢性病管理サービス、臨床決定サポートサービス、能力給サービス（Pay for Performance Service）、医師照会、スケジューリング、および再処方サービスを含む。
【００８８】
以下に、ＣＢＲカノニカル定義の例示的な要件および関連設計仕様を示す。カノニカルとは、ヘルスケア産業セグメントで利用可能なコンテンツベースのルータを構成するデータおよび規則のコンテンツのことである。カノニカルは、アプリケーションおよび組織の境界を越えることのできる標準化されたヘルスケアデータ相互作用の再利用可能サービスおよびＸＭＬペイロード用のＷＳＤＬ（ウェブサービス記述言語）、ＡＰＩ（アプリケーションプログラムインタフェース）を定義する。
【００８９】
特に、ＣＢＲコンポーネントの例示的な構造および振る舞いを記載する。さらには、カノニカルおよびその他の主要なＣＢＲコンポーネントの例示的な相互作用も記載する。
【００９０】
カノニカル設計の各サブセクションは、読み手が元の要件までトレースして戻ることができるような、高レベルのＰＲＤ要件名および識別子を含む。さらに、各高レベルの要件からの例示的なキーとなるテキストがリストされており、要件のさらなる詳細を含むよう拡張され、ＣＢＲカノニカルのその側面を実装するよう設計される。
【００９１】
最後に、ＣＢＲおよびＣＢＲ  ＰＲＤにリストされているヘルスケア特有の要件が全てカノニカル実装（例えばハード機器要件）を満たすわけではないことに言及する。以下に、例示的なヘルスケア要件を述べるが、これらは特にヘルスケアアプリケーションおよび組織のデータフローへの提供が必要なデータ処理およびサービスと連動させることができる。
【００９２】
例示的な実施形態では、ＣＢＲカノニカルは、ＣＢＲプラットフォームのインスタンスとともに配信される予め構成されたコンテンツセットであり、ヘルスケアにおけるデータ相互運用性をサポートする。より詳しくは、カノニカルは、標準化された様式でヘルスケアデータを読み出し、書き込み、および処理するソフトウェアサービスのことを表していてよい。
【００９３】
ＣＢＲ（コンテンツベースのルーティング）では、ソフトウェアサービスは、１ＷＤＬオペレーションについて１または多数のＸＭＬペイロードを有する（１ＷＳＤＬオペレーションパラメータについて１ＸＭＬペイロードまで）ＷＳＤＬ  ＡＰＩのことを示す。このソフトウェアサービスの実装は、外部サービス、Ｊａｖａ（登録商標）ローカルサービス、またはＣＢＲワークフローとして生じうる。ＣＢＲカノニカルの場合には、多くの場合、ＣＢＲワークフローの実装は必要に応じて外部サービスおよびＪａｖａ（登録商標）ローカルサービスを利用して提供されることで、サービスの実装を表すワークフローを完成させる。
【００９４】
例示的な実施形態では、主要な利用モデルは、長期的健康記録（ＬＨＲ）モデル、マルチプロバイダケア（ＭＰＣ）モデル、および自動請求処理（ＡＣＰ）モデルを含む。
【００９５】
以下は、参照対象モデル、コア利用ケース、およびカノニカルメッセージ処理の追跡／監査実装方法を含む全てのカノニカルのフレームワーク全体の一例を詳述する。
【００９６】
例示的な実施形態では、最高位のカノニカル要件により、ＣＢＲプラットフォームがＭＲＤの特定された利用のケース全体のデータ要素および各データ要素のセマンティックスを標準化する、予め構成され、配置をカスタマイズ可能なデータ表現をサポートすると示される。このプラットフォームはさらに、患者の人口統計データ、医療記録（ＰＡＣＳを含む）、照会、処方箋、および請求処理をサポートする。これは、以下のさらなる詳細な副要件に分割することができる。先ず、カノニカルデータ表現は、臨床および管理および／または会計上の処理を共通のオブジェクトモデルでサポートする。ＨＬ７  ＲＩＭおよびＣＤＡ  ＸＭＬモデルは、カノニカル全体に利用される共通のデータ構造であり、例示的な実施形態では、これは将来の改訂版またはサイト特定配置（例えばＣＣＲまたはＯｐｅｎＥＨＲ）の他のＸＭＬ表現に拡張されることで利点を生じる。第二に、カノニカルデータ表現は、構造的およびセマンティックに正規化されている。第三に、例示的な実施形態では、カノニカルＷＳＤＬオペレーションの定義およびＸＳＤスキーマは、明白にタイピングされ、ドキュメント化されて、適切な利用を促す。第四に、例示的な実施形態では、カノニカルデータおよびオペレーションの表現は、拡張可能であり安全に変更されうる。第五に、例示的な実施形態では、カノニカルデータ表現は、ソースシステム、ＣＢＲ，または対象システムの位置に関わらず、読み出し、書き込み、または処理できる。処理フローは、エンドユーザの組織ポリシーがセットアップするファイヤウォールセキュリティおよびルーティング規則が許可するＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、およびインターネットを包括する。第六に、例示的な実施形態では、カノニカルデータ表現は、システムインタフェースまたはアプリケーションユーザインタフェースにより、同様の技術を用いたアクセスが可能である。ＸＭＬおよびＷＳＤＬがこの機能を提供するのに利用されてよい。
【００９７】
これら要件をサポートするには、各カノニカル対象に共通のフレームワークを実装することができる。
【００９８】
各カノニカル対象は、ＷＳＤＬインタフェースおよびＸＭＬペイロードを有して、自身の記録構造を記述してよい。カノニカルが表す構造および規則を定義するＸＭＬペイロードはさらに、「カノニカルシグニファイア」と称されうる。カノニカルシグニファイアは、ＸＳＤスキーマおよび、カノニカル定義に対するその他関連する種類の制約（例えばＨＬ７タイプＩＤの制約（HL7 typeid constraints））を記述するＸＭＬ構造である。カノニカルシグニファイアは、カノニカルのＸＳＤその他を含む。
【００９９】
例示的なＷＳＤＬおよびＸＭＬペイロードの一般的な構造を以下に説明し、データタイプ毎のデータタイプのカノニカルの詳細を以下に詳述する。
【０１００】
例示的な実施形態では、全てのカノニカルが一連の共有サービスおよびリソースを利用して、自身の処理をサポートする。これらサービスおよびリソースは、例えば、カノニカルのメタデータ構成を保持するＳＱＬ記憶装置、ログインおよび追跡処理用のＲＬＳおよび監査データ、および、（オプションとして）ＥＭＰＩおよびＣＭＶＴソース用のマッピングおよび構成テーブルを含みうる。加えて、ＲＬＳ（記録ロケータサービス）およびログインおよび追跡処理用の監査基本サービス（Audit underlying service）を含むこともできる。これらサービスのＳＱＬ構造に関する例示的な詳細を、ＷＳＤＬおよびオペレーションの詳細とともに、以下に詳述する。ＣＲＵＤ（作成、読み出し、更新、削除）ユーティリティサービスおよび関連クラスファクトリを含めることができる。これはカノニカルを、配置の様々な基本となるデータソースへのマッピングを可能とするよう動的に構成するメカニズムを提供する。
【０１０１】
カノニカルに関しては、共通アーキテクチャフレームワークに加えて、各カノニカルが共通の設計および実装特性セットを有することができるが、これを以下に詳述する。
【０１０２】
先ず、例示的な実施形態では、全てのカノニカルの全てのＷＳＤＬが少なくとも以下の標準的オペレーションを有する。  「Ｇｅｔ（）」は、「XMLSearchStruct」が提供するパラメータに基づくカノニカルの単一のインスタンスを取得するオペレーションであり、一意に単一の記録を識別する。  「Ｐｕｔ（）」は、ＣＢＲプラットフォームにカノニカルの１つのインスタンスを書き込むオペレーションである。これは挿入および更新オペレーションを含む。  「Ｄｉｓｃａｒｄ（）」は、破棄オペレーションである（基本となるソースから物理的にまたは論理的に記録を削除する）。  「Ｌｉｓｔ（）」は、「XMLSearchStruct」の内容に基づいて、「Ｇｅｔ（）」と一貫した様式で、且つ、基本となるソースから多くの記録を発呼側のクライアントに対してストリーミングするように、カノニカルのインスタンスのリストを戻すオペレーションである。  「Ｌｏｃａｔｅ（）」は、所望のカノニカル記録が見つかるＣＢＲ位置のリストを戻すオペレーションである。これはＲＬＳエンジンのカノニカルラッパーである。  「Ｄｅｓｃｒｉｂｅ（）」は、関連カノニカルの詳細なスキーマ定義を出力するのに利用されるオペレーションである。  「Ｉｎｉｔｉａｌｉｚｅ（）」は、記録の作成、更新、または削除イベントに呼応して、記録をソースシステムからＣＢＲネットワークへと送るのに利用されるオペレーションである。
【０１０３】
個々のカノニカルサービスは、特定のサービスに適用可能なこの基本セット以外にさらなるＷＳＤＬオペレーションを有してよいが、全てのカノニカルが少なくともこれら基本オペレーションを有して本質的なデータＩ／Ｏを処理する。
【０１０４】
例えばＣＢＲ機器および対応するカノニカル、検証等を含むＣＢＲシステムの例示的な実施形態では、ＣＢＲカノニカルデータペイロードの共有規格を実装する。
【０１０５】
例示的な実施形態では、「canonicalXML*」パラメータは、ＨＬ７ｖ３．０ＲＩＭに基づくＸＭＬドキュメントタイプである。例示的な実施形態では、適用可能な派生物、拡張、および制約とともに臨床ドキュメントアーキテクチャＲ２（ＣＤＡ  Ｒ２）規格が利用可能である。
【０１０６】
ＣＤＡ  Ｒ２ドキュメントフォーマットのコア構造は以下の通りである。
【表１】
2011501834.tif 000003
【０１０７】
例えばＷＳＤＬおよびＸＭＬその他、均等物、または許容範囲の規格に関して、カノニカルを拡張、カスタマイズ、および制約する共通のメカニズムを提供することもできる。
【０１０８】
カノニカルデータペイロードの場合には、ＣＤＡは、ＸＭＬ構造の制約およびカスタマイズ両方を目的として幾つかのクリーンメカニズムを提供する。これらメカニズムは以下を含みうる。ＣＤＡタイプＩＤセグメントは、識別子をＸＭＬセグメントに関連付けるのに利用されうる。セグメントと、それに関連付けられたタイプＩＤとを、スキーマトロン（schematron）またはＪａｖａ（登録商標）クラスに渡すことにより、非常に特殊な規則の適用が可能となりＸＭＬドキュメントが有効になる。この方法は、全てのＣＢＲカノニカルを制約するのに利用され、全てのカノニカルオペレーションのcanonicalSignifierパラメータで構造的な定義がなされている。canonicalSignifier構造は、ＸＭＬ  ＸＳＤスキーマおよび関連カノニカル準拠制約／アーチタイプ（archtype）のメタコンテナである。さらに、ＣＤＡは、データタイプの特注の名称スペースの利用により拡張可能である。例えば、特定の名称スペースおよびデータタイプを利用して、ＣＤＡ.ＸＳＤで現在サポートされていない増分情報を保持することができる。この技術は、継続治療のドキュメント規格を実装する際にPatientProfileカノニカルにより利用されてよく、これを以下に詳述する。加えて、カノニカルフレームワークは、ＸＭＬスキーマ定義をサポートすることができ、サポートするべきである。この例には、CDALab.XSD(研究所結果に対して)および医療従事者、組織、およびそれらの関係のレジストリを実装するServiceProviderカノニカル用のServiceProvider.XSDが含まれる。
【０１０９】
ＷＳＤＬの振る舞いをカスタマイズする場合には、３点を考えると好適である。先ず、カノニカルの特定のインスタンス（例えばオーダ）は、カノニカルを、カノニカルオペレーション（例えばＧｅｔ（）またはＰｕｔ（））の結果をカスタマイズすることのできる異なるＣＲＵＤ、ＲＬＳ、ＥＭＰＩ、またはＣＭＶＴサービスに向けるメタデータを銘々有してよい。例えば、１つのＣＢＲにおいては、構成オーダがＥＭＲに接続するＣＲＵＤサービスを提起しており、他のものがＳＱＬデータベースに直接通信するよう構成されていてよい。データカノニカルの公的なフォーマットは依然として同じであるが、メタデータ構成を利用することで、様々なソースからの読み出しおよび書き込みが可能となる。第二に、サービスは、銘々のＷＳＤＬ定義（ベースを超える）に増分的に追加されるオペレーションを有することができ、ワークフローおよび／またはＪａｖａ（登録商標）内部サービスがＷＳＤＬオペレーションに関連付けられることができる。第三に、既存のＷＳＤＬオペレーションのワークフローは、Ｊａｖａ（登録商標）内部サービスおよび／または外部ウェブサービス呼び出しから利用可能となる更なるステップおよび／または呼び出しアルゴリズムを含むよう変更することができる。
【０１１０】
例示的な実施形態では、共通のメタデータ構成を全てのカノニカルに提供することができる。最後に、メタデータ記憶装置のカノニカル構成を表す共通の方法が必要となる。全てのカノニカルは、配置時に構成されうる特定の情報を記述する必要がある場合がある。構成の殆どの主要なキーはＣＢＲ識別子（ＧＵＩＤ）／名称（または論理コンテンツベースのルータインスタンスを一意に識別することのできる任意の他のメカニズム）およびカノニカルデータタイプ（例えば患者またはオーダ）である。例示的な実施形態では、全てのメタデータを、そのキーに関連付けることができる。例としては、構成のキーにおけるAZHIN.stateofaz.gov,Patient;publicHW.goodhealthclinic.com,Order;publicHW.goodhealthclinic.com,Encounter;publicHW.goodhealthclinic.com,ServiceProviderが挙げられる。キーワード"*HW_ALL*"を利用することで、全てのＣＢＲ（ＣＢＲ識別子で利用される場合）または全てのカノニカルまたは両方のグローバル設定を表すメタデータ属性を分類することができる。
【０１１１】
例示的な実施形態では、カノニカルに関している必要のあるキー情報は以下を含む。カノニカルシグニファイアに対するＵＲＬまたはカノニカルシグニファイア自身を含むテキストとして表されるカノニカルデータタイプの拡張スキーマ定義を表すラベル「CANONICAL_SIGNIFIER」。カノニカルが記録ＩＤをセマンティックに正規化するのに利用するＥＭＰＩサービスのネットワークアドレスを表すラベル「EMPI_ADDRESS」。全てのＥＭＰＩサービスインスタンスのＷＳＤＬは、参照コラムにドキュメント化されているものと同じであるべきである。カノニカルがカノニカルデータタイプに基づいて適切なフィールドに医療語彙をセマンティックに正規化するのに利用するＣＭＶＴサービスのネットワークアドレスを表すラベル「CMVT_ADDRESS」。全てのＣＭＶＴサービスインスタンスのＷＳＤＬは、参照コラムにドキュメント化されているものと同じであるべきである。RLS_ADDRESSは、カノニカルがデータのネットワークソース、および、その他の処理との間の関係を記録するのに利用するＲＬＳサービスのネットワークアドレスを表すラベルである。全てのＲＬＳサービスインスタンスのＷＳＤＬは、参照コラムにドキュメント化されているものと同じであるべきである。CRUD_ADDRESSは、カノニカルが記録データ（ソース／宛先データ読み出しおよび書き込み）を構造的に正規化および非正規化するのに利用するＣＲＵＤサービスのネットワークアドレスを表すラベルである。全てのＣＲＵＤサービスインスタンスのＷＳＤＬは、参照コラムにドキュメント化されているものと同じであるべきである。AUDIT_LOGは、Audit Logと相互作用するべく利用されるオブジェクト識別子を表すラベルである。HIN_CBR_ADDRESSは、集中型またはハイブリッドのＣＢＲ配置のＨＩＮノードを表すＣＢＲのネットワークアドレスを表すラベルである。このパラメータは、完全に連合された配置においてヌルまたは空である。INITIALIZE_WORKFLOWは、カノニカルのInitialize()処理を表すＣＢＲワークフローの名称を表すラベルである。GET_WORKFLOWは、カノニカルのGet()処理を表すＣＢＲワークフローの名称を表すラベルである。LIST_WORKFLOWは、カノニカルのList()処理を表すＣＢＲワークフローの名称を表すラベルである。PUT_WORKFLOWは、カノニカルのPut()処理を表すＣＢＲワークフローの名称を表すラベルである。LOCATE_WORKFLOWは、カノニカルのLocate()処理を表すＣＢＲワークフローの名称を表すラベルである。EMPI_TRAIT_XSLは、カノニカルＸＭＬからＥＭＰＩ特徴構造を作成するＸＳＬ（パスまたはコンテンツ）を表すラベルである。EMPI_TRAIT_XSDは、カノニカルのＥＭＰＩ特徴スキーマを表すラベルである。
【０１１２】
例示的な実施形態では、このメタデータ構造は、直接添付されるＳＱＬデータベースからＣＢＲインスタンスへの、または、全サイト配置がサポートする共有ＳＱＬデータ記憶装置へホストされる、別個のスキーマとして配置可能である。
【０１１３】
さらに、HWCanonicalManagerおよびその基本となるＳＱＬデータベースは、ＣＢＲクラスタインスタンスとそのネットワークアドレスとを識別するＣＤＡ  ＧＵＩＤ間のマッピングを維持する。これは、"CBR_"+<GUID>+"_ADDRESS"=LABEL(例えば"CBR_76b242b9-1246-4691-bb1d-91bb7336e76f_ADDRESS")およびメタデータ値（例えば、"AZHIN.stateofaz.gov"）で表されるＣＢＲのネットワークアドレスとして表されるべきである。
【０１１４】
例示的な実施形態では、ＣＢＲローカルサービスを露呈しうるオブジェクトまたはワークフローは、ＡＰＩ読み出しおよび書き込みを、これらメタデータパラメータに提供することができる（HWCanonicalManager）。HWCanonicalManagerは、ＣＢＲワークフローのＷＳＤＬインタフェースを介してアクセス可能とすることで、カノニカルオペレーションの振る舞いをセットアップおよび方向付ける際に必要に応じて読み出し可能にするべきである。
【０１１５】
例示的な実施形態では、HWCanonicalManagerのＷＳＤＬ  ＡＰＩの署名は、ListCanonicals()であってよい。このオペレーションは、発呼者に、ＣＢＲインスタンスで定義されたカノニカルのリストを返す。  WriteCanonicalDef()は、カノニカルのユーティリティのオペレーションであり、および／または、カノニカル定義を作成する自動化された設置プログラムである。  RetireCanonicalDefinition()は、カノニカル定義を論理的に削除または機能させなくするのに利用されるオペレーションである。  ListCanonicalMetaDataLabels()は、構成ユーティリティユーザインタフェースを構築するのに利用することができ、且つ、サイト配置からの要請に応じてカノニカルメタデータパラメータの動的なカスタマイズをサポートする手段を提供するオペレーションである。  WriteCanonicalMetaData()は、特定されたカノニカルおよびＣＢＲにより対象ラベルにメタデータ値を関連付けるオペレーションである。  ReadCanonicalMetaData()は、カノニカルおよび／またはアプリケーションおよびワークフローの振る舞いを駆動するのに利用可能なメタデータ構成を読み出すオペレーションである。
【０１１６】
最後に、ＳＱＬスキーマおよびＷＳＤＬを有するＡＰＩに加えて、カノニカルメタデータは、適格の管理者またはデベロッパが設計時または配置時にこれらメタデータ構成パラメータを閲覧および編集する際に利用するＵＩユーティリティを含むことができる。例示的な実施形態では、ＣＢＲ管理ＵＩがこの機能を含んでよい。別の実施形態では、小さなウェブＵＲＬがＣＢＲ  Ｊａｖａ（登録商標）環境に提供されて、これを露呈してよい。他の実施形態も利用されてよい。
【０１１７】
例示的な実施形態では、ヘルスケアのＣＢＲプラットフォームは、永続的にヘルスケアデータのカノニカル表現を記憶することで、１を超える数のデータ実体の存在、参加、および検証を必要とする（例えば、患者がＨＬ７を許可する場合）、長期運用されるビジネストランザクションおよびＸＭＬ、ＮＣＰＤＰ、ＡＮＳＩ  Ｘ.１２およびＨＬ７メッセージ（または、他の規格に適合するメッセージ）のアセンブリをサポートする。データ永続性をサポートし、ユーザ開始メンテナンス機能を利用することで、キャッシュから不要な記録をトリム／削除する。この機能は例えば、コアＣＢＲプラットフォームがサポートする主要なＤＢＭＳベンダから提供されてよい。
【０１１８】
この要件を満たすには、ＣＢＲカノニカルアーキテクチャは、全ての入出力されるデータトラフィックを格納するための単純且つ柔軟性のあるＳＱＬスキーマ、ワークフローに対して、ＳＱＬスキーマおよび関連データ記憶装置と相互作用する手段を提供しうるＷＳＤＬインタフェース、および、実際のデータベースインスタンス上の読み書き関数を提供するＷＳＤＬインタフェースの実装を必要とする。
【０１１９】
ＳＱＬデータ記憶装置をサポートするべく、例示的な実施形態では、論理ＥＲ図および関連ＤＤＬを提供して、対象データベースプラットフォームをサポートする。
【０１２０】
ＷＳＤＬインタフェースから見ると、これは記録ロケータサービス（ＲＬＳ）を効果的に実装することができる。ＲＬＳの基本的なオペレーションは以下を含む。
"AddRLSEntry"− 単一のカノニカルインスタンスのＲＬＳログに１つのエントリを追加する。作成されたデータおよびタイムスタンプ、記録ｉｄｓ（ローカルおよびグローバル）、カノニカルのタイプ、カノニカルＸＭＬ記録インスタンス、および記録がそこから発生したＣＢＲ  ＧＵＩＤを記録する。
"DelteRLSEntry"−構築されたＲＬＳエントリを削除する。
"CreateRLSEntryRelationship"−カノニカルデータのタイプ間の関係を構築する（例えば、オーダ→スケジュール→結果→ドキュメント）。
"DeleteRLSEntryRelationship"−カノニカルデータのタイプ間の関係を削除する。
"LocateCBRSourceByFilter"−カノニカルタイプの属性によりＲＬＳ記録キャッシュを検索して、検索基準に整合する記録ＩＤおよび記録のＣＢＲ  ＩＤを見つける。
【０１２１】
ＷＳＤＬオペレーションの実装は、Ｊａｖａ（登録商標）ローカルサービスとして、または、ＣＢＲプラットフォーム上のワークフローとしての実装が可能であり、ベースラインコードセットは、サイトレベルの配置によりカスタマイズされうる参照実装として提供されうる（このようにすることで、カノニカルＸＭＬ記録内の基本的なヘッダ情報以上のものをＳＱＬに抽出することができ、より効果的に検索可能となる）。
【０１２２】
このモデルの利点は、全てのＣＢＲデータトラフィックを把握して、カノニカルオペレーションフローの一部として監視することが可能となることである。そして別個の独立したデータベース処理ジョブが、ＲＬＳデータを、データウェアハウスアプリケーションに抽出、変換、およびロードして、分析その他のＨＩＮ機能（例えば監査）に備えさせてよい。
【０１２３】
データソース、カノニカルのトランスポートおよび変換  ＣＢＲプラットフォームは、多くの基本となるソースおよび宛先データ記憶フォーマットおよりトランスポートを動的にサポートする方法を提供する。これを達成して、コアカノニカルセマンティック変換ロジックを、ソースまたは宛先フォーマットおよびトランスポートの詳細から隔離することを目的として、カノニカルフレームワークは、ＣＲＵＤ（作成、読み出し、更新および削除）と称されるコンポーネントを実装する。
【０１２４】
ＣＲＵＤに関するＰＲＤからの主要な要件は以下を含む。  ヘルスケア向けのＣＢＲプラットフォームは、ＨＬ７メッセージおよびこれに関連するデータ構造を受信、変換、ルーティング、および送信する手段を提供する。この要件は、１つまたは多数のヘルスケアＩＳＶを有するエコシステムが可能とするイニシアチブにより満たされる。ＥＤＩおよびＸＭＬ版のＨＬ７ＣＤＡおよび全てのＨＬ７バージョンのサポートは、３．０メッセージおよびＲＩＭを含む。ヘルスケア向けのＣＢＲプラットフォームはさらに、ケア記録（ＣＣＲ）メッセージおよび関連データ構造のＡＳＴＭ規格連続性を受信、変換、ルーティング、および送信するメカニズムを提供する。この要件は、１つまたは複数のヘルスケアＩＳＶを有するエコシステムが可能とするイニシアチブにより満たされる。ヘルスケア向けのＣＢＲプラットフォームはさらに、ＮＣＰＤＰメッセージおよび関連データ構造（電子処方）を受信、変換、ルーティング、および送信するメカニズムを提供する。この要件は、１つまたは複数のヘルスケアＩＳＶを有するエコシステムが可能とするイニシアチブにより満たされる。ヘルスケア向けのＣＢＲプラットフォームはさらに、ＨＩＰＰＡ  Ｘ．１２、ＡＳＣ  Ｘ１２、およびＡＳＣ  Ｘ１２Ｎメッセージおよび関連データ構造（保険加入資格、照会、請求および支払いに関する保険トランザクションの場合）を受信、変換、ルーティング、および送信するメカニズムを提供する。この要件は、１つまたは複数のヘルスケアＩＳＶを有するエコシステムが可能とするイニシアチブにより満たされる。ＣＢＲシステムはさらに、ＭＬＰ  Ｘ１２、ＮＣＰＤＰ、およびＨＬ７が必要とするＭＬＰトランスポートをサポートすることができる。例示的な実施形態では、ＣＢＲシステムはさらに、ヘルスケアバーチカル（healthcare vertical）で利用されるファイルベースのメッセージトランスポートをサポートする。例えばこの場合、最もよく利用されるプロトコルはＦＴＰである。これら要件は、先ずはＩｔｅｍＦｉｅｌｄ（登録商標）またはｉＷａｙ（登録商標）等の１以上のＨＣ（ヘルスケア）アダプタの利用により（例えば、ＨＬ７、ＣＣＲ，Ｘ１２、およびＮＣＰＤＰ）サポートされて、データを送受信する変換アダプタおよびＣＢＲトランスポート送受信機能として機能しうる。基本的には、ＣＲＵＤサービスは、これら低レベルの変換およびトランスポート機能の構成に対するＷＳＤＬ「ラッパー」として機能しうる。２つの主要なフローは、「アウトサイドイン」（クライアントがGet()、Put()、またはList()を呼び出す）または「インサイドアウト」（クライアントがInitialize()を呼び出す）である。
【０１２５】
例示的な実施形態では、以下のＣＲＵＤサービスの検査可能な参照サンプルが提供される。第一のものは、患者のプロフィール、オーダ、外来診察、スケジュールおよびドキュメントのＨＬ７  ２．３サンプルである。これは、ファイルシステムに作成され、インサイドアウト技術によりInitialize()に提出され、Put()カノニカルオペレーションがアウトサイドインメカニズムにより実行するＩｔｅｍＦｉｅｌｄ（登録商標）およびｉＷａｙ（登録商標）等のＨＣアダプタに変換されるＨＬ７ファイルを含む。第二のものは、患者、オーダ、および外来診察のGet()およびList()の「アウトサイドイン」アプリケーションを表すＨＣアダプタへのＭＬＬＰ接続を有するＨＬ７  ＥＭＲへのサンプル実用接続（sample working connection）である。第三のものは、インサイドアウトおよびアウトサイドインのワークフロー両方における全てのオペレーションのカノニカルを読み書きする全フローをサポートするＳＱＬ  ＣＲＵＤサービス実装（効果的にはＪＡＸＢからの／へのＪＤＢＣコンバージョンである）を有するServiceProviderの実用実装（working implementation）である。
【０１２６】
「アウトサイドイン」ＣＲＵＤのＷＳＤＬオペレーションは、自明であり、コアカノニカルオペレーションと同様のパラメータを含み、例えば以下を含む。
Create(input: putRequestSrcStruct, input: canonicalXMLRecord, output: errorCode, output: canonicalRecordID) 
Read (input:XMLSearchStruct,input:maxResultStreams,input:previousResultID,output:canonicalXMLRecordsList,output:errorCode,output:finishedFlag,output:resultID)
Update(input:putRequestSrcStruct,input:canonicalXMLRecord,output:errorCode,output:canonicalRecordID)
Delete(input:XMLSearchStruct,input:putRequestSrcStruct,output:errorCode)
【０１２７】
Create()オペレーションは、データ上に挿入する、または「アップサート（upsert）」を行うことができる。例示的な「アウトサイドイン」のＣＲＵＤ相互作用は、例えば図１９に示されている。
【０１２８】
例示的な「インサイドアウト」のＣＲＵＤ相互作用は、例えば図２０に示されており、ここでは「インサイドアウト」コンテナが、トランスポートおよびＨＣ（ヘルスケア）アダプタ結合（binding）、および「initialize()」への不干渉制御を行う。図２１は、図２０のアーキテクチャの例示的なベースラインシーケンス図を示す。
【０１２９】
個々のカノニカルのタイプによる特定の定義（例えば患者、オーダ、外来診察等）を以下に説明する。各カノニカルデータタイプについて、カノニカルのＣＤＡ  Ｒ２をシグニファイア／スキーマとして特別に実装する例を示す。上で定義した標準ＷＳＤＬオペレーション各々(Get(), Put(), List(), Describe(),Locate(),Initialize()等)のワークフローを示すシーケンス図についても説明するが、これは、ＲＬＳ、ＥＭＰＩ、ＣＭＶＴ，および監査ログサービスとカノニカルとの関係を含む。増分ＷＳＤＬオペレーションの例示的な定義を説明し、カノニカルがＣＢＲシステムの主要な対象利用ケースに適用されうる例を説明する。
【０１３０】
カノニカルスキーマ、ワークフローおよびＷＳＤＬについては、各カノニカルは、共通のオペレーション一式を共有する（例えば、上述したようなものである）。殆どのカノニカルについて、これらオペレーション各々の高レベルワークフローが共通であってよく、異なるのは、ＣＢＲの特定配置されるインスタンスの特定のカノニカル用に構成されるＥＭＰＩ、ＣＭＶＴ，およびＣＲＵＤサービスに関する規則である。
【０１３１】
標準カノニカルＷＳＤＬオペレーションに共通のワークフローが、図２２−２８にシーケンス図として例示されている。図２２は、Get()の例示的なシーケンス図を示す。図２３は、Put()の例示的なシーケンス図を示す。図２４は、Discard()の例示的なシーケンス図を示す。図２５は、List()の例示的なシーケンス図を示す。図２６は、Describe()の例示的なシーケンス図を示す。図２７は、Locate()の例示的なシーケンス図を示す。図２８は、Initialize()の例示的なシーケンス図を示す。
【０１３２】
ヘルスケア向けのＣＢＲプラットフォームの例示的な実施形態は、サービスプロバイダ（役割およびグループを含む組織、提携および関連）に、サービス機能を提供するデータおよび共通の機能を含むソフトウェアサービス定義を提供する。サービスの定義は、サービスが表すデータ構造の作成、読み出し、更新および削除機能を有するＨ７バージョン３．０ＲＩＭに準拠したデータ構造を含みうる。サービスプロバイダカノニカルは、ＣＢＲネットワークにアクセスを持つ医療専門家のディレクトリ、彼らの参加組織との関連付け（診療所、病院等）、および組織の識別子ＣＢＲインスタンス（ＧＵＩＤ）を表すので、非常に重要でありうる。このカノニカルにより、モデル内の全ての他のカノニカルの関係を適切なものにすることができる。実装は、ＳＱＬのＣＲＵＤ実装全体の高レベルＷＳＤＬから形成される完全実装であってよい。
【０１３３】
患者カノニカル（ヘルスケア特有の要件／サービス／ヘルスケアコア企業データサービス／患者）に関しては、ヘルスケア向けのＣＢＲプラットフォームの例示的な実施形態は、サービス機能を提供するデータよび共通の機能を含む患者のソフトウェアサービス定義を提供してよい。サービスの定義は、サービスが表すデータ構造の作成、読み出し、更新、および削除機能を有するＨ７バージョン３．０ＲＩＭに準拠したデータ構造を含みうる。
【０１３４】
患者カノニカルの例示的な増分ＷＳＤＬオペレーションは、カノニカルの呼び出しのレベルでＥＭＰＩ  ＡＰＩを効果的にラップしうる。これらのパラメータは、記録構造がフィールドおよび記録ＩＤについてＥＭＰＩに特有のデータ構造ではなくてカノニカルであることから、僅かに異なりうるが、これらの機能的な目的は依然として同じである。患者カノニカルの増分ＷＳＤＬオペレーションは、例えば、FindDuplicateDefinitions();LinkRecords();UnlinkRecords();MergeRecords();UnMergeRecords();InactivateRecord();およびReactivateRecord()を含みうる。
【０１３５】
ヘルスケア向けのＣＢＲプラットフォームの例示的な実施形態は、サービスプロバイダの「オーダ」カノニカルのソフトウェアサービス定義を提供し（ヘルスケア特有の要件／サービス／ヘルスケアコア企業データサービス／オーダ）、これは例えば、研究所、処置、医薬、等に関して利用可能である。例示的なオーダカノニカルは、サービス機能を提供するデータおよび共通関数を含みうる。対応するサービスの定義は、サービスが表すデータ構造の作成、読み出し、更新、および削除機能を有するＨ７バージョン３．０ＲＩＭに準拠したデータ構造を含みうる。
【０１３６】
例示的な実施形態では、６つの主要なオーダのタイプがあり、これらが対象利用ケースを可能とすべくサポートされてよい。例示的なオーダのタイプは、研究所での撮像（例えばＣＴスキャン）のオーダ、研究所での病理検査（例えばボールドテスト）のオーダ、医療治療のオーダ、投薬／医薬オーダ、医師／専門医の外来診察のオーダ、永続的な医療品（例えば車椅子または酸素ボンベ）のオーダを含みうる。
【０１３７】
オーダのカノニカルの別の例示的なスキーマの定義は（またはその関連箇所）、永続的な医薬品（例えば車椅子または酸素ボンベ）のオーダに関しており、これは、１以上の外来診察、医薬／投薬オーダ、調達オーダ等の１以上に関して上述した基本的な構造に類似している、またはそれらと同じ構造を有しうるが、例示的な実施形態では、さらに、ＣＤＡ供給セグメントを観察、薬の管理、または外来診察の代わりに、エントリとして利用することができる。
【０１３８】
オーダカノニカルの例示的な増分ＷＳＤＬオペレーションは、CancelOrder(input:orderID);DetectDuplicateOrders(input:byExampleCanonical,input:dateRange,output:listOfMatchingOrderCanonicals)を含みうる。DetectDuplicateOrders関数は、パターン整合を行って特定のオーダ範囲の同じもののオーダを識別する（例えば、最近９０日間のＣＴスキャンまたは最近２日間の電界パネル）。
【０１３９】
例示的な実施形態では、ヘルスケア向けのＣＢＲプラットフォームは、例えば臨床的な発見および推薦を処理するのに、またはこれに関して、ソフトウェアサービス定義または外来診察のカノニカル（ヘルスケア特有の要件／サービス／ヘルスケアコア企業データサービス／外来診察）を提供する。定義は、サービス機能を提供するデータおよび共通の関数を含みうる。サービス定義は、サービスが表すデータ構造の作成、読み出し、更新、および削除機能を有するＨ７バージョン３．０ＲＩＭに準拠したデータ構造を含みうる。
【０１４０】
外来診察は、医師の外来サマリーを含んでよく、研究所の結果（病理検査および撮像）および治療結果（outcome of procedures）を含んでよい。
【０１４１】
外来診察の増分ＷＳＤＬオペレーションは、TraceEpisodeOfCare(input:startingEncounterCanonical,input:dateRange,output:listofEncountersForEpisode)を含んでよい。
【０１４２】
このオペレーションは、関係する外来診察を作成する外来診察とオーダとの間の関係を追跡するものである。
【０１４３】
ヘルスケア向けのＣＢＲプラットフォームは、ドキュメント用のソフトウェアサービス定義を提供しうる（例えば、サービス機能を提供するデータおよび共通関数を含むＤＩＣＯＭ（Digital Imaging and Communications in Medicine）またはスキャンされた紙）。サービス定義は、サービスが表すデータ構造の作成、読み出し、更新および削除機能を有するＨ７バージョン３．０ＲＩＭに準拠したデータ構造を含みうる。
【０１４４】
カノニカルドキュメント（ヘルスケア特有の要件／サービス／ヘルスケアコア企業データサービス／ドキュメント）のスキーマ定義の例示的な実施形態は、関連する構造化されていないドキュメントへのリンクを戻すだけのために治療（procedure）の部分を利用する継続治療のドキュメント（continuity of care document）（ＣＣＤ）である。
【０１４５】
ドキュメントの例示的な増分ＷＳＤＬオペレーションは、ExtractDocumentPaths(input:documentCanonicalXML,output:key-value pair array<documentDesc,documentURL>)を含みうる。
【０１４６】
このオペレーションは効果的に撮像ＵＲＬおよびそれが直接対応する記述テキストをカノニカルＸＭＬから抽出して、基本的に以下のパターンを追従するセグメントを抽出することができる。
【表２】
2011501834.tif 000004
【０１４７】
ヘルスケア向けのＣＢＲプラットフォームの例示的な実施形態はデータおよびサービス機能を提供するデータおよび共通関数を含む健康記録（サマリーおよび全履歴）のソフトウェアサービス定義を提供する。サービス定義は、サービスが表すデータ構造の作成、読み出し、更新、および削除機能を有するＨ７バージョン３．０ＲＩＭに準拠したデータ構造を含みうる。
【０１４８】
カノニカルの健康記録（ヘルスケア特有の要件／サービス／ヘルスケアコア企業データサービス／個人健康記録）の例示的なスキーマ定義は、関連するタイムスケールを有する全てのセクションを利用する継続治療のドキュメント（continuity of care document）（ＣＣＤ）に関する。
【０１４９】
個人健康記録の例示的な増分ＷＳＤＬオペレーションは、RenderAsCCRWithID(input:patientRecordID,output:personalHealthRecordAsCCR)およびRenderAsCCRWithCCD(input:personalHealthRecordCanonicalAsCCD,output:personalHealthRecordAsCCR)を含みうる。
【０１５０】
例示的な実施形態では、これら追加のオペレーションは、異なるＣＲＵＤをロードして、再度ソースからデータを抽出ことにより（WithCCD）、またはＸＳＬＴ変換をオペレーション内で行うことにより（WithCCD）、別のＸＭＬフォーマットの個人健康記録を効果的に生成することができる。
【０１５１】
ヘルスケア向けのＣＢＲプラットフォームの例示的な実施形態は、サービス機能を提供するデータおよび共通関数を含む保険（請求および照会）のカノニカルのソフトウェアサービス定義を提供しうる。サービス定義は、サービスが表すデータ構造の作成、読み出し、更新、および削除機能を有するＨ７バージョン３．０ＲＩＭに準拠したデータ構造を含みうる。
【０１５２】
ヘルスケア向けのＣＢＲプラットフォームの例示的な実施形態は、さらに、サービス機能を提供するデータおよび共通関数を含むスケジューリングおよび予約のソフトウェアサービス定義を提供しうる。例示的なサービス定義は、サービスが表すデータ構造の作成、読み出し、更新、および削除機能を有するＨ７バージョン３．０ＲＩＭに準拠したデータ構造を含みうる。
【０１５３】
本発明の例示的な実施形態では、スケジュールは、オーダの中間応答として利用される。オーダが入ると、オーダを実行する時および場所を記載するスケジュールを生成する。オーダが実行されると、外来診察／結果を生成する。
【０１５４】
例示的な実施形態では、スケジュールはさらに、コアおよび増分ＷＳＤＬオペレーションが２つの別個の実装（つまり、１）スケジューリング（コアカノニカルオペレーションおよびＸＭＬペイロードの実装）および２）ScheduleDefinitionAndFulfillment（拡張ＷＳＤＬオペレーションの実装））で実装されうる、という点から固有のカノニカルである。
【０１５５】
スケジューリングカノニカルの例示的な増分オペレーションは、例えば、BookAppointment(input:patientRecordID,input:serviceProviderID,input:appointmentDateTime,input:schedulingNotes,output:errorCode,output:schedulingID)、ConfirmAppointment(input:patientRecordID,input:serviceProviderID,input:appointmentDateTime,input:schedulingNotes,output:errorCode,output:schedulingID)、RescheduleAppointment(input:patientRecordID,input:serviceProviderID,input:oldAppointmentDateTime,input:newAppointmentDateTime,input:schedulingNotes,output:errorCode,output:schedulingID)、CancelAppointment(input:patientRecordID,input:serviceProviderID,input:appointmentDateTime,input:schedulingNotes,output:errorCode,output:schedulingID)、および、ListAvailableSlots(input:serviceProviderID,output:arrayOf<availableDateTimes>,output:errorCode)を含む。
【０１５６】
これらオペレーションの１以上は、暫定的なデータ記憶装置またはスケジューリングアプリケーションのＡＰＩをラップするのに利用可能なオプションの実装を効果的に表すことができ、後にスケジューリングカノニカルの生成が可能である。例示的な実施形態では、これらＡＰＩは、これからアプリケーションがＨＩＮネットワークのスケジューリングを行うことのできる共通ＡＰＩを提供する。
【０１５７】
長期的な健康記録、マルチプロバイダケア、および自動請求処理に関するカノニカルの例示的な利用モデルについては、例えば図１０−１８を参照して上述した。例示的な実施形態では、これら３つの利用モデルおよび３つの配置モデルが実装される。各利用モデルは、３つの配置モデルのいずれかを利用して実装でき、これによりカノニカルを利用可能な９つの可能性ある実装例のマトリックスが生じる。
【０１５８】
他のカノニカルもさらに、またはオプションとして提供可能であり、これには例えば位置、会計、材料、イベントおよびＡＣＬが含まれる。例示的な実施形態では、ＥＭＲデータインテグレーション、長期的健康記録、マルチプロバイダケア、または自動請求処理の対象となる利用ケースのサポートにこれらオプションのカノニカルは不要である。発見機能は、サービスプロバイダカノニカルおよびＲＬＳサービスにモデリングされることで効果を生じえて、この場合、さらなるウェブサービスが不要になる。例示的な実施形態では、会計は対象となる利用ケースを満たす目的からは不要である。保険は、全ての請求処理要件をサポートするべくモデリングされうる。材料およびイベントは、オーダ、外来診察、および結果カノニカルでモデリングされることで、別のウェブサービスおよびＸＭＬペイロードを不要とすることができる。最後に、例示的な実施形態では、セキュリティ機能としてのＡＣＬ（例えばアクセスコントロールリスト）を、カノニカルとしてではなく、コアＣＢＲ機能と外部サービス（ＬＤＡＰ，ポータル認証等）との組み合わせとして実装することができる。
【０１５９】
上述したように、本発明の例示的な実施形態は、カノニカルをセマンティックに相互運用可能とし、サポートサービスを可能とする。特に、カノニカルの例示的なサポートサービスのＷＳＤＬオペレーションおよび高レベルのアーキテクチャについて説明を行い、制御医療語彙（ＣＭＴ）、ＥＭＰＩ（Enterprise Master Person Index）、および記録ロケータサービス（ＲＬＳ）について特に詳述する。
【０１６０】
ＣＭＴに関しては、ヘルスケア向けのＣＢＲプラットフォームの例示的な実施形態は、診断、病状、処置および投薬について制御された医療語彙間の定義、利用、解釈、および翻訳を行うメカニズムを提供することができる。例示的な実施形態では、これら制御された医療語彙は、カノニカルフォームのフィールドにマッピングされる構造化されたコードとして定義される。この要件は、例えばＡｐｅｌｏｎ等の、１つまたは複数のヘルスケアＩＳＶ（Independent Software Vendor）を有するエコシステムが可能とするイニシアチブにより満たされる。
【０１６１】
例示的な実施形態では、ＣＭＶＴ  ＷＳＤＬ定義は、少なくとも以下の機能を有する。属性を特定して、医療コード翻訳を要するカノニカルデータタイプに関連付ける機能（ローカルシステムからカノニカルへ、およびカノニカルからローカルシステムへ、の両方を含む）。有効なコードセットおよび各属性および各データフローの関連マッピングを特定する機能（ローカルシステムからカノニカルへ、およびカノニカルからローカルシステムへ）。明白なマッピングが見つからない場合にデフォルトコードを属性に関連付ける機能。明白なマッピングが見つからず、デフォルト利用前に「インテリジェント」に検索する手段を提供する機能（例えばセマンティックストリング検索）。コードセットを作成するＡＰＩ、ツールおよびＵＩ、マッピングおよびそのカノニカルデータタイプおよび属性との関連付けを提供する機能。
【０１６２】
これは、例えば、公認規格であるＨＳＳＰ（Healthcare Services Specification Project）制御された用語サービス（ＣＴＳ）ＷＳＤＬ定義を利用して実装可能である。
【０１６３】
例示的な実施形態では、ＡＰＩはＳＯＡＰウェブサービス実装であり（Ｊａｖａ（登録商標）ではない）、仕様について語彙およびマッピングＡＰＩの完全形成実装を持ち、メッセージＡＰＩのTranslateCode()実装を含み、メッセージＡＰＩのTranslatedCodeInBatch()拡張を追加する（これは、特におよび一般的にＣＴＳ規格ＡＰＩセマンティックス上にモデリングされうる）。
【０１６４】
例示的な実施形態ではＣＭＶＴは、図２９が示すようなアーキテクチャを持つ外部サービスとして実装される。
【０１６５】
または、ＡｐｅｌｏｎＤＴＳＪａｖａ（登録商標）ＡＰＩを呼び出すローカルサービスが実装されてよい。
【０１６６】
ＭＰＩに関しては、ヘルスケア向けのＣＢＲプラットフォームの例示的な実施形態は、システムを超えて関係データベース識別子を定義、利用、解釈、および正規化するメカニズムを可能とする、または提供する。故に、このシナリオでは、「メリー・ジョーンズ」という名称の患者および「ボブ・スミス」という名称の医者が一貫してデータベース、トランザクション、およびサービスの面で参照されている。この要件は、例えば、例えば会社のイニシエート等の１つまたは複数のヘルスケアＩＳＶ（Independent Software Vendor）を有するエコシステムが可能とするイニシアチブにより満たされる。
【０１６７】
例示的な実施形態では、ＥＭＰＩ  ＷＳＤＬ定義の実装には、少なくとも患者およびプロバイダカノニカルのクロスシステム記録ＩＤ関連付けを管理する能力を少なくとも含む。
【０１６８】
例示的な実施形態では、ＥＭＰＩは外部サービスとして実装されてよい。例示的なアーキテクチャを図３０に示す。例示的な実施形態では、ＥＭＰＩ外部サービスは、カノニカルワークフローおよびＷＳＤＬの実装にインテグレーションされて、ＥＭＰＩサービスよびカノニカル間のインテグレーションを検証する。または、Ｉｎｉｔｉａｔｅ（登録商標）Ｉｄｅｎｔｉｔｙ  Ｈｕｂ  Ｊａｖａ（登録商標）ＡＰＩを呼び出すローカルサービス実装が提供されてもよい。
【０１６９】
記録ロケータサービス（ＲＬＳ）に関しては、ヘルスケア向けのＣＢＲプラットフォームの例示的な実施形態が、プラットフォームの多数のインスタンス間の発見要求を発行して、患者の医療、保険、または投薬履歴を総合して、配信ＨＩＮアーキテクチャをサポートするメカニズムを可能とする、または提供する（例えば集中型のレポジトリを利用しない場合）。
【０１７０】
ＲＬＳオペレーションは例えば、Ｊａｖａ（登録商標）ローカルサービスまたはＣＢＲワークフロー、または２つの適切な組み合わせとして実装可能である。例示的な実施形態では、記録位置検索のサイト配置の必要性に応じて、ＲＬＳをカスタマイズして、カノニカルから、基本となるＳＱＬデータ記憶装置およびデータモデルへ、記録ＩＤ以上のものを抽出するメカニズムが提供される。
【０１７１】
例示的な実施形態においては、ＲＬＳ  ＡＰＩは、以下の機能または属性を有する。ＲＬＳ記録ＩＤは、ＩＤステートメントの前にリストされる"RLS:"flagを有するＩＤとしてカノニカルデータペイロードに配置されてよく、こうすると好適である。ＲＬＳは、突出したトランザクションを検出および管理するプレースホールダ関係をサポートしてよい。一実施形態では、CreateRLSRelationship()呼び出しのtargetRecordIDフィールドの「*hw_null*」は、プレースホールダを構築するのに利用される。UpdateRLSRelationship()は、実際のデータがひとたび構築されると（または構築された後で）、プレースホールダを、この実際のデータで上書きする方法を提供することができる。例示的な実施形態では、ＨＩＮ記録ＩＤおよびシステムＩＤは、全てのＲＬＳオペレーションにおいてオプションのパラメータである。例示的な実施形態では、全カノニカルＸＭＬ記録が、基本となるＲＬＳテーブルに格納される。このシナリオでは、ＲＬＳサービス実装は、カスタマイズにコードフックを提供して、これにより配置が、ＲＬＳに最終的に格納される前にカノニカルＸＭＬに増分処理を行うことができる。
【０１７２】
ビジネス規則拡張に関しては、ＣＢＲシステムの例示的な実施形態は、ヘルスケアトランザクションワークフローへ含めるべくカスタマイズ可能なビジネス規則処理拡張をサポートすることができ、ワークフローの各ステップにおいて、入力パラメータおよび条件付きの処理アクションのエンドユーザ／サイトの構成を提供することができる。ＣＢＲシステムは、条件付き処理の初めに、最後に、または中間の任意の時点において（if-then-else）、Ｊａｖａ（登録商標）コード拡張を書き込むことにより、構築されているワークフローを拡張するメカニズムを可能とする、または提供する。例示的な実施形態では、カノニカルのビジネス規則は以下を含む幾らかの形態で利用可能である。
【０１７３】
ＲＬＳ、ＣＲＵＤ、またはカノニカルサービスのワークフローの増分チェックまたはアルゴリズム。これら増分チェックまたはアルゴリズムは、ワークフロー処理の増分ステップで、または、Ｊａｖａ（登録商標）ローカルサービスにより実装可能である。
【０１７４】
カノニカル記録の検証プロセスに対する制約は、スキーマトロンの名称またはＷＳＤＬ（ローカルまたは外部サービス）のアドレスを特定して、カノニカル検証機能を実装することを含むことができる。全てのカノニカルオペレーションの初めに、canonicalSignifierXML（以下で詳しく定義する）をチェックすることで、以下のアクションを実行することができる。先ず、ＸＭＬドキュメントが、canonicalSignifier構造に記憶されているＸＳＤ定義に合致していることを確かめる。第二に、canonicalSignifierに<SchemaConstraintDef/>があるかどうかチェックする。<SchemaConstraintDef/>が定義されていない場合、唯一とられるアクションはＸＳＤスキーマ検証である。しかし<SchemaConstraintDef/>が定義されている場合には、例示的な実施形態では、カノニカルワークフローは、ExecuteSchematron(input:schemaTronLocation,input:canonicalXMLPayload,output:errorCode)を実装するローカルサービスを呼び出す、ValidateCanonicalSchema(input:canonicalXMLPayload,output:errorCode)を実装するローカルサービスを呼び出す、または、ValidateCanonicalSchema(input:canonicalXMLPayload,output:errorCode)を呼び出す。次に、<SchemaConstraintDef/>／<SchemaConstraintType/>は、スキーマトロン、ローカルサービス、または外部サービスを利用して制約のチェックを実行すべきであるか否かを示す。各カノニカルは、上で詳述したとおり、ベースライン制約定義により実装可能である。
【０１７５】
本発明の例示的な実施形態は、さらに、ＣＢＲシステムのカノニカルの非機能的な能力を提供する、または確かなものとすることができる。例示的なＣＢ機器またはＣＢＲは、高性能ＸＭＬまたはワークフロー処理エンジンを含んでよい。これに加えて、またはこの代わりに、例示的な実施形態では、カノニカル実装および関連するサポートサービスの性能、スケーラビリティ、およびリソース利用は最適化され、または向上させられる。
【０１７６】
特に、本発明の例示的な実施形態では、以下の性能ベンチマークを満たし、これを越えることができる。患者データ（プロフィール、医療記録、処方、請求、照会）を受け取ってから２４時間以内に処理する（ルーティング、変換、および記憶）ことができる。これは、例えば５００，０００人の患者をかかえる小さなＨＩＮから、五千万人の患者をかかえる大きなＨＩＮへと規模を調節することができる。例示的な実施形態では、ＣＢ機器および結果生じるＣＢＲシステムまたはネットワークおよび関連アーキテクチャは、受け取ってから２４時間以内に、１つのＨＩＮインスタンスの一年あたり平均１０個の患者のデータの処理を一人の患者について処理することができる。
【０１７７】
本発明の例示的な実施形態では、研究所、病院、支払い者等の「４つの壁」内のスケーラビリティの理由から、ＣＢ機器またはＣＢＲおよび関連カノニカルが、例えば以下に示すような他のインテグレーションプロダクトへの拡張インテグレーションをサポートすることができる。
【０１７８】
例示的な実施形態では、ＣＢ機器またはネットワークソリューションにより、ヘルスケア特有のインテグレーションエンジン（ＨＣＩＥ）とウェブサービスベースのインタフェースとの間に緩い連結を行うことができる。これは、コアランタイムの一部としてヘルスケアインテグレーションエンジンに何ら特有の要件がなくて好適であることを示している。インテグレーションエンジンの例にはＩｔｅｍｆｉｅｌｄ（登録商標）およびＱｕｏＶａｄｘ（登録商標）があり、このシナリオでは、ＩＥが変換アダプタを提供する。図３１はこのようなアーキテクチャの視覚的表現である。
【０１７９】
例示的な実施形態では、ＣＢＲベースのシステムの検証処理の一貫として、ＨＣ（ヘルスケア）アダプタのインテグレーションが可能とするＣＲＵＤサービスを、第三者インテグレーションエンジンを有する（最小限、ＨＬ７アクセレレータを有するＭＳ  ＢｉｚＴａｌｋまたはＱｕｏＶａｄａｘ）ＦＴＰまたはＭＬＬＰプロトコルを利用することで検証することができる。
【０１８０】
上述したように、ＣＢＲシステムの例示的な実施形態は、様々な利用モデルをサポートすることができ、これらモデルの１つに、患者のケアを、多数のトランザクションおよびサービスプロバイダの間で単一のヘルスケアイベントを効果的にサポートする多数のサービスプロバイダにより提供する、というものがある。各プロバイダは、幾らかの共通データを必要とし、各下流トランザクションが各上流トランザクションとの関係を構築する。ここで随所に示すように、ＣＢＲシステムの例示的な実施形態は、様々な長期的健康記録の利用をサポートすることができる。以下に、本発明の様々な局面と特定のシナリオとの関係を示し、示唆する例を示す。
【０１８１】
マルチプロバイダケアを示す第１の処理例は、プライマリケア医師の外来診察を受け、専門医に申し渡しされる。しかし、実際には、この利用モデルは家庭医、プライマリケア、ローカルな診療所、等に始まり、他の医者の下流における相互作用（診療所／ＥＲの初診であっても、その後のプライマリケアのフォローアップの診断であってもよい）またはサービスプロバイダ（研究所または薬局）に関している。
ベースラインのケースは、以下のステップまたはセグメントを有する。
１．患者がプライマリケア医師を尋ね、適性チェックを受ける。
２．プライマリケア医師が患者を専門医へ送る。
３．プライマリケアＥＨＲが専門医へ送られる。
４．プライマリケア医師が電子的に請求をファイルし、正当性チェックを行う。
５．患者が専門医に予約をとり、適性チェックを受ける。
６．患者が専門医を尋ねる。
７．専門医が患者の処方および研究所検査をオーダする。
８．専門医ＥＨＲがオーダを薬局および研究所に送る。
９．システムにより薬物相互作用をチェックする。
１０．システムが重複する研究所検査をチェックする。
１１．患者が研究所に予約をとる。
１２．患者による処方調合。
１３．薬局が電子的に請求をファイルし、正当性チェックを行う。
１４．薬局が専門医に処方調合した／しないを報告する。
１５．患者が研究所の検査を終了する。
１６．研究所が専門医ＨＥＲに結果を送る。
１７．研究所が電子的に請求をファイルし、正当性チェックを行う。
１８．専門医が研究所の結果を見直し、忠告を行う。
１９．専門医ＥＭＲの記録をプライマリケア医者に送る。
２０．専門医が電子的に請求をファイルし、正当性チェックを行う。
２１．支払い者が電子請求を処理して、プロバイダに支払う。
２２．患者が更新された健康記録および請求ステータスを電子上で確認する。
【０１８２】
長期的健康記録に関しては、６６歳で、フロリダ州のフォートメイヤーズビーチにある民営釣り会社フロリダグルーパ社に勤務している架空の患者ブルー・ウォータズ氏を例にとって説明する。ブルー・ウォータズ氏は、米国海軍（ノースカロライナ州のキャンプレジョンにあるＩＩ  ＭＥＦ（Marine Expeditionary Forces））を、中佐で、２２年の兵役の後に退役した。彼は米国および海外（日本およびイラクを含む）において幾らかのベースに駐留したことがある。ＯＩＦ（Operation Iraq Freedom）に所属していたとき、海軍で、ブルー・ウォータズ氏は放射線を利用する研究所業務に数多く携わり、これが原因の胃腸病が持病になった。胃食道逆流病（ＧＥＲＤ）およびBarrett's esophogitisが彼の診断結果として記載された。ブルー・ウォータズ氏は現在、フロリダ州ペンサコラにある海軍病院でＧＥＲＤ治療を受けている。ウォータズ氏は、ＴＲＩＣＡＲＥの生涯健康保険を持ち、殆どのプライマリケアをフロリダ州のフォートメイヤーズビーチの勤務地に近いウォーフ医療グループクリニックで受けている。
【０１８３】
ステップ０−話の前提  この話は、現在のイベントに関するさらなる背景情報から始まる。ブルー・ウォータズ氏は、息子をフロリダ州タンパに訪ねた。彼らが地元のレストランへ車で向かっている途中でウォータズ氏は胸の痛みを覚えた。ＰＨＭＣ（プレシャスハート医療センタ）の近くであったので、高速を降りてＰＨＭＣの緊急センタへ行った。ＰＨＭＣ緊急センタに入る際に、トリアージ係の看護士であるナンシー・ナイチンゲール氏がウォータズ氏に対して、彼の保険情報を尋ね、ＴＲＩＣＡＲＥの健康保険を有していることを聞き出した。
【０１８４】
医師エリック・エマージェンシがブルー・ウォータズ氏の対象の病気についての経緯および身体検査を含む診断を行う。ウォータズ氏に他の重要な過去の病歴について質問しているとき、海軍時代にＧＩに関する検査を幾度も行ったことを話した。かれはＨ２ブロッカの処方を受けており、これにより最初は彼のＧＩ症状が治まったが、近年ではこれが効かなくなってきている。バイタルサインは正常であった。ニトログリセリン舌下錠および鼻カニューラによる酸素吸入を処方して、今ではブルー・ウォータズ氏は胸の痛みがなくなった。心電図には急性心筋梗塞の兆候がみられない。
【０１８５】
ステップ１−ドキュメントリストのクエリ  エマージェンシ医師は、フロリダ健康情報ネットワーク（ＨＩＮ）にクエリを送り、ウォータズ氏の医療履歴について利用可能な情報を判断した。ウォーフ医療グループクリニックからの医療記録の他にも、ウォータズ氏の医療履歴へのリンクがあるのに気づいた。ウォータズ氏の了解を得て、エマージェンシ医師はこの利用可能なドキュメントをクエリした。
【０１８６】
ステップ２−ドキュメントリストへの応答  エマージェンシ医師のクエリにより、幾らかの関連ドキュメントが発見され、その報告がなされた。この中には、最近のウォーフ医療グループからの心電図のレポート、および２年前のペンサコラの海軍病院からの内視鏡および冠動脈造影図が含まれている。
【０１８７】
ステップ３−特定のドキュメントを同意の下にクエリする  エマージェンシ医師は、リストからドキュメントを選択し、選択されたドキュメント（またはその内容）へのアクセスを要求して受けた。この例では、エマージェンシ氏は、３つのドキュメント全てを選択して受けることができた。
【０１８８】
ステップ４−要求したドキュメントに応答する  エマージェンシ医師は、ウォーフ医療グループクリニックおよびペンサコラの海軍病院から得た臨床ドキュメントを見た。前の冠動脈造影図レポートから冠動脈系の病気の所見はなく、前の心電図も正常であった。エマージェンシ医師はブルー氏の記録を見て、患者が、胃食道逆流病（ＧＥＲＤ）の診断を含むデータが正しく、最近のものであると認めていることを確かめた。戻ってきた緊急センタのブルー・ウォータズ氏に関する研究所結果および胸部ｘ線結果も正常であった。エマージェンシ医師は、ブルー・ウォータズ氏のＧＥＲＤの再燃という診断を下し、心臓は正常であると伝えた。エマージェンシ医師は緊急センタから患者を送り出し、プロトンポンプ阻害薬を処方して、ブルー氏に対してプライマリケアプロバイダのフォローアップ診断を受けるよう勧告した。エマージェンシ医師は緊急センタの外来メモをＰＨＭＣ電子医療記録に記入した。
【０１８９】
ステップ５−新たなドキュメントの利用可能性  ２週間後に、ブルー・ウォータズ氏は、ウォーフ医療グループクリニックの彼のプライマリケアプロバイダであるビッグ・フィッシャー医師のもとを訪れた。ブルー・ウォータズ氏は、最近緊急センタを訪れ、投薬が変わったことを次げた。処方箋を持参するのを忘れ、新たな薬の名称を思い出せなかった。フィッシャー医師は、それがプロトンポンプ阻害薬という名称の新しい医薬であり、彼のＧＥＲＤには強いものであることを伝え、彼がプレシャスハート医療センタの緊急センタを受診した情報は、ＨＩＮのスタッフから、ウォータズ氏の今回の受診の折に連絡があった旨伝えた。ウォータズ氏は今では症状がないが、フィッシャー医師は、もう一度内視鏡検査を受けて、esophgitisの異形成変化ではないことを確かめるよう勧めた。彼は、ウォータズ氏が内視鏡検査を受けに行くときには、最新の医療情報をペンサコラの海軍病院の医師が見られる状態になっていると伝えた。
【０１９０】
本発明の例示的な実施形態では、上述のステップ０−５は、以下のようにして話に組み込まれ、可能とされる。ウォータズ氏がウォーフ医療グループクリニックを前に受診した際に、彼の身元がＨＩＮ  ＭＰＩを介した通信によりＨＩＮの他のプロバイダにマッチングされていた。彼の医療記録はゲートウェイおよびＭＰＩを介してＨＩＮに結び付けられている。
【０１９１】
ステップ１−ドキュメントリストのクエリ、に関しては、エマージェンシ医師はセキュアなＨＩＮシステムにログインして、過去２年のブルー・ウォータズ氏の全ての臨床ドキュメントのリストのクエリを提出した。
【０１９２】
ステップ２−ドキュメントリストへの応答、に関して、エマージェンシ医師からの利用可能なドキュメントの要求の一部として（例えば、ＨＩＮへのウェブポータルアクセス）、ウォーフ医療グループクリニックでのＩＤ整合があった。２年間のドキュメントクエリをこれら両方に送った。ウォーフ医療グループクリニックは、これに応答し、これはブルー・ウォータズ氏が心電図を最近とった、見ることはできるが持続的ではないデータを示しており、さらには研究所の結果、投薬プロフィール、および幾らかの進捗状況メモが見つかった。ゲートウェイは、ＥＭＲからの彼の医療サマリー、医療履歴、研究所結果、内視鏡報告および冠動脈造影図を示す、見ることはできるが持続的ではないデータの応答を送る。
【０１９３】
ステップ３−特定のドキュメントを同意の下にクエリする、に関しては、エマージェンシ医師は、ＨＩＮウェブページから、対象のドキュメントを選択する。エマージェンシ医師の選択に基づいて、ＨＩＮは、ウォーフ医療グループクリニックおよびウォーフ医療グループクリニック心電図のゲートウェイに、心電図の結果および内視鏡および冠動脈造影図報告をＥＭＲからクエリする。
【０１９４】
ステップ４−要求したドキュメントに応答する、に関しては、ウォーフ医療グループクリニックは、ＥＭＲから心電図結果を取得して、ドキュメントをＨＩＮ（見ることはできるが持続的ではない）に送る。ゲートウェイは、内視鏡及び冠動脈造影図報告をＥＭＲから取得し、これらドキュメントをＨＩＮ（見ることはできるが持続的ではない）に送る。ＨＩＮはこれらドキュメントを、ＨＩＮセキュアウェブページによりエマージェンシ医師が見ることができるようにする。ＨＩＮウェブページログアウト処理中に、ブルー・ウォータズ氏についての見ることができる健康データがＰＨＭＣでは存在しなくなる。
【０１９５】
ステップ５−新たなドキュメントの利用可能性、に関しては、ＰＨＭＣは、新たに入力された緊急外来メモを他の関連アイテム（例えば研究所結果）とともに、ウォータズ氏のＰＨＭＣ電子医療記録に登録し、さらに、これらドキュメントをＨＩＮゲートウェイに登録して、適宜、他のプロバイダによる取得に備えさせる（つまり、ウォーフ医療グループクリニックおよびペンサコラの海軍病院）。
【０１９６】
図面のフローチャートの各ブロックおよびフローチャートのブロックの組み合わせ、並びに、ここに記載される手順、オペレーションおよびコードは、異なるオーダまたはシーケンスで実装されることもでき、様々なローカル、遠隔、中央、または分散処理形態で、１以上のコンピュータまたはプロセッサで実行されるコンピュータプログラム命令により実装されることができる。これら命令は、１以上の揮発性および／または不揮発性メモリデバイスまたは他の記憶デバイスにより格納されうる。これらプログラム命令は、１以上のプロセッサに提供されることで機械を生成し、プロセッサ上で実行される命令に、フローチャートブロック（１または複数）が示すアクションを実装するメカニズムを作成させることができる。当業者であれば、機械は、ソフトウェアを実行するハードウェア、ソフトウェアおよび／または、ファームウェアを組み合わせたハードウェア、ＲＯＭ、その他のデータ記憶装置であってよいことを理解し、ここで記載する機能またはアクションの１以上を実行するよう構成されるハードウェアデバイスに実装可能であることを理解する。例えば、コンピュータプログラム命令は、プロセッサにより実行されることで、プロセッサが一連のオペレーションステップを実行して、コンピュータ実装された処理を生成し、これにより、プロセッサ上で実行されることで命令が、フローチャートブロック（１または複数）が示すアクションを実装するステップを提供してよい。コンピュータプログラム命令は、さらに、フローチャートのブロックが示すオペレーションステップおよび／またはここに示す処理の少なくとも幾らかを、並行して実行することもできる。さらに、ステップの幾らかを１を超える数のプロセッサにより実行してもよく、これはマルチプロセッサコンピュータシステムで起こりうる。加えて、フローチャート図またはコード記述の１以上のブロックまたはブロックの組み合わせは、他のブロックまたはブロックの組み合わせと同時に行うこともでき、本発明の範囲または精神から逸脱することなく示されたものと異なるシーケンスでの実行も可能である。故に、フローチャート図の、および／またはここで示す処理またはコードのブロックは、特定したアクション、特定したアクションを実行するステップの組み合わせ、および特定したアクションを実行するプログラム命令手段を実行するメカニズムの組み合わせをサポートする。さらに、フローチャート図および／またはここで示す処理およびコードの各ブロック、および、フローチャート図および／またはここで示す処理およびコードのブロックの組み合わせは、特定したアクションまたはステップ、または、特定用途ハードウェアベースシステム、または、特定用途ハードウェアおよびコンピュータ命令の組み合わせによる実装が可能である。本発明の様々な側面の幾らかまたは全ては、ハードウェア、ハードウェアで実行されるソフトウェア、またはハードウェアとソフトウェアとの任意の組み合わせにより実装されてよい。
【０１９７】
提供した例示は、本発明の実施形態を狭めるものとして解釈されるべきではなく、単により良い理解を提供することが意図されている。故に、本発明の範囲を逸脱せずに他のメカニズムを利用することもできる。
【０１９８】
上述の明細書、例示、およびデータは、本発明の構成の製造および利用の完全な記載を提供する。本発明の他の実施形態も本発明の精神および範囲から逸脱せずに可能でありえ、本発明は以下に添付する請求項である。
【図１】
2011501834.tif 000005
【図２】
2011501834.tif 000006
【図３】
2011501834.tif 000007
【図４】
2011501834.tif 000008
【図５Ａ】
2011501834.tif 000009
【図５Ｂ】
2011501834.tif 000010
【図５Ｃ】
2011501834.tif 000011
【図６】
2011501834.tif 000012
【図７】
2011501834.tif 000013
【図８】
2011501834.tif 000014
【図９】
2011501834.tif 000015
【図１０】
2011501834.tif 000016
【図１１】
2011501834.tif 000017
【図１２】
2011501834.tif 000018
【図１３】
2011501834.tif 000019
【図１４】
2011501834.tif 000020
【図１５】
2011501834.tif 000021
【図１６】
2011501834.tif 000022
【図１７】
2011501834.tif 000023
【図１８】
2011501834.tif 000024
【図１９】
2011501834.tif 000025
【図２０】
2011501834.tif 000026
【図２１】
2011501834.tif 000027
【図２２】
2011501834.tif 000028
【図２３】
2011501834.tif 000029
【図２４】
2011501834.tif 000030
【図２５】
2011501834.tif 000031
【図２６】
2011501834.tif 000032
【図２７】
2011501834.tif 000033
【図２８】
2011501834.tif 000034
【図２９】
2011501834.tif 000035
【図３０】
2011501834.tif 000036
【図３１】
2011501834.tif 000037
【手続補正書】
【提出日】平成22年3月10日(2010.3.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
システムであって、
各々がデータベースを有し、異なる情報規格に準拠している複数の実体と、
各々が前記複数の実体の少なくとも１つに割り当てられている複数のコンテンツベースのルータと、
第１のカノニカル規格と、
データが前記第１のカノニカル規格に準拠しているか否かを検証するメトリックとを備え、
前記複数のコンテンツベースのルータはネットワークを形成するよう接続され、
前記複数のコンテンツベースのルータ間の前記ネットワーク内の通信は前記第１のカノニカル規格に準拠しており、
前記複数の実体の各々は、前記ネットワークと、対応するコンテンツベースのルータを介して通信し、
前記複数のコンテンツベースのルータの各々は、前記複数の実体のうち対応するものからの情報を、前記第１のカノニカル規格に準拠する第１のフォームに変換し、前記メトリックに応じて前記変換された情報を検証し、
前記複数のコンテンツベースのルータの各々は、前記第１のカノニカル規格に準拠する情報を、前記コンテンツベースのルータが割り当てられている対応する実体の前記情報規格に準拠するフォームに変換するシステム。
【請求項２】
前記複数のコンテンツベースのルータは、前記ネットワークの他のコンテンツベースのルータへのブロードキャスト通信、および、前記ネットワークの他のコンテンツベースのルータへの直接ルーティングの通信の両方をサポートするよう構成される請求項１に記載のシステム。
【請求項３】
前記複数のコンテンツベースのルータの各々は、割り当てられた前記実体からの新たな通信を受信して、前記新たな通信への固有のネットワーク識別ラベルを取得するよう構成される請求項２に記載のシステム。
【請求項４】
前記複数のコンテンツベースのルータの各々は、当該コンテンツベースのルータを介して前記ネットワークと前記コンテンツベースのルータが割り当てられた前記実体との間で転送された各通信について、当該コンテンツベースのルータおよび対応する実体のうち少なくとも１つを識別するローカル識別ラベルを取得し、
前記ローカル識別ラベルを前記通信に関連付け、
前記通信のコピーと前記ローカル識別ラベルのコピーとを格納し、
前記ローカル識別ラベルを前記ネットワークの少なくとも１つの他のコンテンツベースのルータへ送信するよう構成される請求項３に記載のシステム。
【請求項５】
当該コンテンツベースのルータは、他のコンテンツベースのルータによる通信に関連付けられたローカル識別ラベルを受信して格納するよう構成される請求項４に記載のシステム。
【請求項６】
前記少なくとも１つの他のコンテンツベースのルータは、ａ）対応する割り当てられた実体と前記ネットワークとの間で前記通信を転送したコンテンツベースのルータ、または、ｂ）識別ラベルをキャッシュするネットワークコアの少なくとも１つである請求項４に記載のシステム。
【請求項７】
前記第１のカノニカル規格は、前記ネットワーク内のデータの構造的およびセマンティックな標準化または正規化を可能とする請求項１に記載のシステム。
【請求項８】
前記第１のカノニカル規格はヘルスケアを対象とする請求項７に記載のシステム。
【請求項９】
前記複数の実体はヘルスケアサービス実体であり、前記情報は患者のヘルスケア情報を含む請求項１に記載のシステム。
【請求項１０】
システムのネットワーク内のデータを正規化する方法であって、
複数のコンテンツベースのルータの各々を、各々が異なる情報規格に準拠している複数のデータベース実体のうち対応する１つに割り当てる段階と、
前記複数のコンテンツベースのルータ間にネットワークを形成する段階と、
前記複数のコンテンツベースのルータのうち、第１のコンテンツベースのルータが、対応する割り当てられた第１のデータベース実体から第１の通信を受信する段階と、
前記第１のコンテンツベースのルータが、前記第１の通信を第１のカノニカル規格に準拠する第１のフォームに変換する段階と、
前記第１のコンテンツベースのルータが、前記変換された第１の通信を、前記ネットワークの規格であるメトリックに応じて検証する段階と、
前記変換され、検証された通信を前記ネットワーク内に送信する段階と、
前記第１のコンテンツベースのルータが、前記第１のカノニカル規格に準拠したフォームの第２の通信を前記ネットワークから受信する段階と、
前記第１のコンテンツベースのルータが、前記受信した第２の通信を、前記第１のデータベース実体の情報規格に準拠するフォームに変換する段階と、
前記第１のコンテンツベースのルータが、前記変換された第２の通信を前記第１のデータベース実体に転送する段階とを備える方法。
【請求項１１】
前記第１のコンテンツベースのルータが、前記第１の通信のためのローカル識別ラベルとネットワーク識別ラベルとを生成する段階と、
前記ローカル識別ラベルと前記ネットワーク識別ラベルとを前記第１の通信に添付する段階と、
前記第１の通信、前記ローカル識別ラベル、および、前記ネットワーク識別ラベルのコピーを、前記第１のコンテンツベースのルータに関連付けられたキャッシュに格納する段階とを備える請求項１０に記載の方法。
【請求項１２】
前記第１のコンテンツベースのルータが、前記受信した第２の通信用の第２のローカル識別ラベルを生成する段階と、
前記第２の通信に関連付けられた前記第２のローカル識別ラベルを、前記第１のコンテンツベースのルータに関連付けられた前記キャッシュに格納する段階とを備える請求項１１に記載の方法。
【請求項１３】
前記第１のコンテンツベースのルータが、前記第２のローカル識別ラベルを、前記ネットワークを介して、前記第２の通信に関連付けられたローカル識別ラベルを有する各コンテンツベースのルータに送信する段階を備える請求項１２に記載の方法。
【請求項１４】
前記第１のコンテンツベースのルータが、前記ネットワークの他のコンテンツベースのルータが生成したローカル識別ラベルを受信して格納する段階を備える請求項１３に記載の方法。
【請求項１５】
前記第１のカノニカル規格は、前記ネットワーク内のデータの構造的およびセマンティックな標準化または正規化を可能とする請求項１０に記載の方法。
【請求項１６】
複数のネットワーク機器のネットワーク内の情報をトラッキングするコンピュータ実装された方法であって、前記複数のネットワーク機器の各々はローカルデータベースを持つローカル情報システムに接続し、前記方法は、
第１のネットワーク機器が、前記第１のネットワーク機器に接続された第１のローカル情報システムから、第１のイベントを記述して前記第１のイベントに関連付けられた第１のローカルシステム用の第１イベント識別子を含む第１のイベント情報パッケージを受信する段階と、
前記第１のネットワーク機器が、前記第１のイベントのための第１のネットワーク識別子を生成する段階と、
前記第１のネットワーク機器が、第１の機器用の第１のイベント関連パッケージを生成して、前記第１のネットワーク識別子と、前記第１のローカルシステム用の第１のイベント識別子と、前記第１のネットワーク機器の識別子とを、前記第１の機器の第１のイベント関連パッケージに追加して、前記第１の機器用の第１のイベント関連パッケージを格納する段階と、
前記第１のネットワーク機器が、前記第１のイベント情報パッケージと、前記第１の機器用の第１のイベント関連パッケージとを、第２のネットワーク機器に転送して、前記第２のネットワーク機器に接続された第２のローカル情報システムへ配信させる段階と、
前記第２のネットワーク機器が、前記第１のイベント情報パッケージを前記第２のローカル情報システムへ提供して、前記第２のローカル情報システムから第２のローカルシステム用の第１のイベント識別子を受信して、前記第１のイベントを識別する段階と、
前記第２のネットワーク機器が、第２の機器用の第１のイベント関連パッケージを生成して、前記第１のイベント関連パッケージの内容、前記第２のローカルシステム用の第１のイベント識別子、および、前記第２のネットワーク機器の識別子を、前記第２の機器用の第１のイベント関連パッケージに追加する段階と、
前記第２のネットワーク機器が、前記第２のローカルシステム用の第１のイベント識別子を前記第１のネットワーク機器に送る段階と、
前記第１のネットワーク機器が、前記受信した第２のローカルシステム用の第１のイベント識別子を前記第１の機器用の第１のイベント関連パッケージに追加する段階とを備える方法。
【請求項１７】
複数のローカル情報システムのネットワーク内の情報をトラッキングするコンピュータ実装された方法であって、前記複数のローカル情報システムの各々は、ローカルデータベースを持ち、少なくとも１つのネットワーク機器に直接接続されており、前記ネットワークの他のローカル情報システムと、複数のネットワーク機器それぞれを介して通信し、前記複数のネットワーク機器は互いにブロードキャストネットワークを介して接続し、前記方法は、
第１のネットワーク機器が、前記第１のネットワーク機器に接続されたローカル情報システムから、少なくともイベントを識別し前記イベントに関するイベント情報を受信する段階と、
前記第１のネットワーク機器が、前記イベントに固有のネットワーク識別子を生成する段階と、
前記イベント情報を、複数のローカル情報システム間で、前記複数のローカル情報システムにそれぞれ接続された前記複数のネットワーク機器を介して転送する段階と、
前記固有のネットワーク識別子に関連付けられた追跡情報を、前記イベント情報を前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々に格納させる段階とを備え、
前記追跡情報は、ａ）前記イベント情報を生成または受信する前記複数のローカル情報システムの各々が提供する前記イベントのローカル情報システム識別子、および、ｂ）前記イベント情報を、前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々の識別子を含む方法。
【請求項１８】
自身に接続された前記ローカル情報システムから第１のイベント用の第１のローカル情報識別子を受信した各ネットワーク機器が、前記第１のローカル情報識別子、および、前記第１のローカル情報識別子と、前記第１のイベント用の第１の固有のネットワーク識別子との関連付けを、他のネットワーク機器にブロードキャストする段階と、
前記ブロードキャストされた第１のローカル情報識別子を受信して、前記第１の固有のネットワーク識別子と関連付けて追跡情報を格納した各ネットワーク機器が、前記第１のローカル情報識別子を、前記第１の固有の識別子と関連付けて格納されている前記追跡情報に追加する段階とを備える請求項１７に記載の方法。
【請求項１９】
複数のローカル情報システムから前記複数のネットワーク機器の少なくとも１つに転送された全てのイベント情報を同じ規格に応じて検証する段階を備える請求項１７に記載の方法。
【請求項２０】
前記検証する段階は前記複数のネットワーク機器の少なくとも１つにより実行される請求項１９に記載の方法。
【請求項２１】
コンピュータに、
複数のコンテンツベースのルータの各々を、各々が異なる情報規格に準拠している複数のデータベース実体の対応するものに割り当てさせ、
前記複数のコンテンツベースのルータ間にネットワークを形成させ、
前記複数のコンテンツベースのルータのうち、第１のコンテンツベースのルータに、対応する割り当てられた第１のデータベース実体から第１の通信を受信させ、
前記第１のコンテンツベースのルータに、前記第１の通信を第１のカノニカル規格に準拠する第１のフォームに変換させ、
前記第１のコンテンツベースのルータに、前記変換された第１の通信を、前記ネットワークの規格であるメトリックに応じて検証させ、
前記変換され、検証された通信を前記ネットワーク内に送信させ、
前記第１のコンテンツベースのルータに、前記第１のカノニカル規格に準拠したフォームの第２の通信を前記ネットワークから受信させ、
前記第１のコンテンツベースのルータに、前記受信した第２の通信を、前記第１のデータベース実体の情報規格に準拠するフォームに変換させ、
前記第１のコンテンツベースのルータに、前記変換された第２の通信を前記第１のデータベース実体に転送させるためのプログラム。
【請求項２２】
データは患者のヘルスケア情報を含み、
前記コンピュータに、
前記第１のコンテンツベースのルータに、前記第１の通信のためにローカル識別ラベルとネットワーク識別ラベルとを生成させ、
前記ローカル識別ラベルと前記ネットワーク識別ラベルとを前記第１の通信に添付させ、
前記第１の通信、前記ローカル識別ラベル、および、前記ネットワーク識別ラベルのコピーを、前記第１のコンテンツベースのルータに関連付けられたキャッシュに格納させ、
前記第１のコンテンツベースのルータに、前記受信した第２の通信用の第２のローカル識別ラベルを生成させ、
前記第２の通信に関連付けられた前記第２のローカル識別ラベルを、前記第１のコンテンツベースのルータに関連付けられた前記キャッシュに格納させ、
前記第２のローカル識別ラベルを、前記ネットワークを介して、前記第２の通信に関連付けられたローカル識別ラベルを有する各コンテンツベースのルータに送信させ、
前記第１のコンテンツベースのルータに、前記ネットワークの他のコンテンツベースのルータが生成したローカル識別ラベルを受信して格納させる、請求項２１に記載のプログラム。
【請求項２３】
コンピュータに、
ローカルデータベースを持つローカル情報システムに各々が接続されている複数のネットワーク機器のネットワーク内の患者のヘルスケア情報をトラッキングさせ、
第１のネットワーク機器に、前記第１のネットワーク機器に接続された第１のローカル情報システムから、第１のイベントを記述して前記第１のイベントに関連付けられた第１のローカルシステム用の第１イベント識別子を含む第１のイベント情報パッケージを受信させ、
前記第１のネットワーク機器に、前記第１のイベントのための第１のネットワーク識別子を生成させ、
前記第１のネットワーク機器に、第１の機器用の第１のイベント関連パッケージを生成させ、
前記第１のネットワーク識別子と、前記第１のローカルシステム用の第１のイベント識別子と、前記第１のネットワーク機器の識別子とを、前記第１の機器の第１のイベント関連パッケージに追加させ、
前記第１の機器用の第１のイベント関連パッケージを格納させ、
前記第１のネットワーク機器に、前記情報パッケージと、前記第１の機器用の第１のイベント関連パッケージとを、第２のネットワーク機器に転送させ、前記第２のネットワーク機器に接続された第２のローカル情報システムへ配信させ、
前記情報パッケージを前記第２のローカル情報システムへ提供して、前記第２のローカル情報システムから第２のローカルシステム用の第１のイベント識別子を受信して、前記第１のイベントを識別させ、
第２の機器用の第１のイベント関連パッケージを生成して、前記第１のイベント関連パッケージの内容、前記第２のローカルシステム用の第１のイベント識別子、および、前記第２のネットワーク機器の識別子を、前記第２の機器用の第１のイベント関連パッケージに追加させ、
前記第２のローカルシステム用の第１のイベント識別子を前記第１のネットワーク機器へ送らせ、
前記第１のネットワーク機器に、前記受信した第２のローカルシステム用の第１のイベント識別子を、前記第１の機器用の第１のイベント関連パッケージへ追加させる、プログラム。
【請求項２４】
コンピュータに、
各々がローカルデータベースを持ち、少なくとも１つのネットワーク機器に直接接続し、互いにブロードキャストネットワークを介して接続する複数のネットワーク機器それぞれを介して前記ネットワークの他のローカル情報システムと通信する複数のローカル情報システムのネットワーク内の情報をトラッキングさせ、
第１のネットワーク機器に、前記第１のネットワーク機器に接続されたローカル情報システムから、少なくともイベントを識別し患者のヘルスケア情報を含み前記イベントに関するイベント情報を受信させ、
前記イベントの固有のネットワーク識別子を生成させ、
前記イベント情報を、複数のローカル情報システム間で、前記複数のローカル情報システムにそれぞれ接続された前記複数のネットワーク機器を介して転送させ、
前記固有のネットワーク識別子に関連付けられた追跡情報を、前記イベント情報を前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々に格納させ、
前記追跡情報は、ａ）前記イベント情報を生成または受信する前記複数のローカル情報システムの各々が提供する前記イベントのローカル情報システム識別子、および、ｂ）前記イベント情報を、前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々の識別子を含む、プログラム。
【請求項２５】
前記コンピュータに、
各ネットワーク機器に、自身に接続された前記ローカル情報システムから第１のイベント用の第１のローカル情報識別子を受信させ、前記第１のローカル情報識別子、および、前記第１のローカル情報識別子と、前記第１のイベント用の第１の固有のネットワーク識別子との関連付けを、他のネットワーク機器にブロードキャストさせ、
各ネットワーク機器に、前記ブロードキャストされた第１のローカル情報識別子を受信させ、前記第１の固有のネットワーク識別子と関連付けて追跡情報を予め格納させ、前記第１のローカル情報識別子を、前記第１の固有のネットワーク識別子と関連付けて格納されている前記追跡情報に追加させ、
複数のローカル情報システムから前記複数のネットワーク機器の少なくとも１つに転送された全てのイベント情報を同じ規格に応じて検証させる請求項２４に記載のプログラム。
【請求項２６】
第１のコンテンツベースのルータであって、
前記第１のコンテンツベースのルータと関連付けられた第１の実体への第１の接続であって、前記第１の実体が患者のヘルスケア情報を持つデータベースを持つ、前記第１の接続と、
複数の他のコンテンツベースのルータへの複数の第２の接続であって、前記複数の他のコンテンツベースのルータの各々が、各他のコンテンツベースのルータに関連付けられた１つの他の異なる実体への接続を持ち、複数の実体の各々が、患者のヘルスケア情報を持つデータベースを持ち、それぞれ異なる情報規格に準拠している、前記複数の第２の接続と、
データが第１のカノニカル規格に準拠しているか否かを検証するメトリックとを備え、
前記第１のコンテンツベースのルータと前記複数の他のコンテンツベースのルータとの間の前記複数の第２の接続を介した全ての通信は、前記第１のカノニカル規格に準拠しており、
前記複数の他のコンテンツベースのルータの各々は、前記複数の実体のうち対応する関連付けられたものからの情報を、前記第１のカノニカル規格に準拠する第１のフォームに変換し、前記メトリックに応じて前記変換された情報を検証し、
前記複数の他のコンテンツベースのルータの各々は、前記第１のカノニカル規格に準拠する情報を、コンテンツベースのルータが割り当てられている対応する実体の前記情報規格に準拠するフォームに変換する第１のコンテンツベースのルータ。
【請求項２７】
前記第１のコンテンツベースのルータは、割り当てられた前記実体からの新たな通信を受信して、前記新たな通信への固有のネットワーク識別ラベルを取得するよう構成される請求項２６に記載のルータ。
【請求項２８】
前記第１のコンテンツベースのルータおよび前記複数の他のコンテンツベースのルータはネットワークを形成し、前記第１のコンテンツベースのルータは、
前記第１のコンテンツベースのルータを介して前記ネットワークと前記第１の実体との間で転送された各通信について、前記第１のコンテンツベースのルータおよび前記第１の実体のうち少なくとも１つを識別するローカル識別ラベルを取得し、
前記ローカル識別ラベルを前記通信に関連付け、
前記通信のコピーと前記ローカル識別ラベルのコピーとを格納し、
前記ローカル識別ラベルを前記ネットワークの前記複数の他のコンテンツベースのルータの少なくとも１つへ送信するよう構成される請求項２６に記載のルータ。
【請求項２９】
前記第１のコンテンツベースのルータは、ネットワークの複数の他のコンテンツベースのルータによる通信に関連付けられた複数のローカル識別ラベルを受信して格納するよう構成される請求項２８に記載のルータ。
【請求項３０】
前記第１のコンテンツベースのルータは、識別ラベルをキャッシュするネットワークコアである請求項２６に記載のルータ。
【請求項３１】
前記第１のカノニカル規格は、ネットワーク内のデータの構造的およびセマンティックな標準化または正規化を可能とする請求項２６に記載のルータ。
【請求項３２】
前記第１の実体および前記他の異なる複数の実体は、ヘルスケアサービス実体であり、前記情報は患者のヘルスケア情報を含む請求項２６に記載のルータ。
【請求項３３】
複数のローカル情報システムのネットワーク内の患者のヘルスケア情報をトラッキングするコンピュータ実装された方法であって、前記複数のローカル情報システムの各々は、ローカルデータベースを持ち、少なくとも１つのネットワーク機器に直接接続されており、前記ネットワークの他のローカル情報システムと、複数のネットワーク機器それぞれを介して通信し、前記複数のネットワーク機器は互いにブロードキャストネットワークを介して接続し、前記方法は、
第１のネットワーク機器が、前記第１のネットワーク機器に接続されたローカル情報システムから、少なくともイベントを識別し前記イベントに関するイベント情報を受信する段階と、
前記第１のネットワーク機器が、前記イベントに固有のネットワーク識別子を生成する段階と、
前記第１のネットワーク機器が、前記イベント情報を前記ネットワークへ転送して、複数のローカル情報システムにそれぞれ接続された前記複数のネットワーク機器を介した前記複数のローカル情報システム間で配信させる段階と、
前記第１のネットワーク機器が、前記ネットワークの複数の他のネットワーク機器のうち少なくとも１つから、前記少なくとも１つの他のネットワーク機器が提供した少なくとも１つの他の固有のネットワーク識別子を含むイベント情報を受信する段階と、
前記第１のネットワーク機器が、受信したイベント情報の各セットについて、追跡情報を格納する段階とを備え、
前記追跡情報は、前記受信したイベント情報に関連付けられた前記固有のネットワーク識別子、ａ）前記イベント情報を生成または受信する前記複数のローカル情報システムの各々が提供する前記イベントのローカル情報システム識別子、および、ｂ）前記イベント情報を、前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々の識別子を含む方法。
【請求項３４】
前記第１のネットワーク機器が、自身に接続された前記ローカル情報システムから第１のイベント用の第１のローカル情報識別子を受信して、前記第１のローカル情報識別子、および、前記第１のローカル情報識別子と、前記第１のイベント用の第１の固有のネットワーク識別子との関連付けを、他のネットワーク機器にブロードキャストする段階と、
前記第１のネットワーク機器が、他のネットワーク機器から、第２のイベントに関しており前記第２のイベントについての第２のローカル情報識別子と第２の固有の識別子とを含む第２の追跡情報を受信する段階と、
前記第１のネットワーク機器が、前記第２のイベントに対応する第２のローカル情報識別子を生成する段階と、
前記第１のネットワーク機器が、前記第２のローカル情報識別子に関連付けられた前記第２の追跡情報を格納する段階とを備える請求項３３に記載の方法。
【請求項３５】
コンピュータに、
各々がローカルデータベースを持ち、少なくとも１つのネットワーク機器に直接接続されており、互いにブロードキャストネットワークを介して接続する複数のネットワーク機器それぞれを介して前記ネットワークの他のローカル情報システムと通信する複数のローカル情報システムのネットワーク内の患者のヘルスケア情報をトラッキングさせ、
第１のネットワーク機器に、前記第１のネットワーク機器に接続されたローカル情報システムから、少なくともイベントを識別し前記イベントに関するイベント情報を受信させ、
前記第１のネットワーク機器に、前記イベントの固有のネットワーク識別子を生成させ、
前記第１のネットワーク機器に、前記イベント情報を前記ネットワークへ転送させて、複数のローカル情報システムにそれぞれ接続された前記複数のネットワーク機器を介した前記複数のローカル情報システム間で配信させ、
前記第１のネットワーク機器に、前記ネットワークの複数の他のネットワーク機器のうち少なくとも１つから、少なくとも１つの他のネットワーク機器が提供した少なくとも１つの他の固有のネットワーク識別子を含むイベント情報を受信させ、
前記第１のネットワーク機器に、受信したイベント情報の各セットについて、追跡情報を格納させ、
前記追跡情報は、前記受信したイベント情報に関連付けられた前記固有のネットワーク識別子、ａ）前記イベント情報を生成または受信する前記複数のローカル情報システムの各々が提供する前記イベントのローカル情報システム識別子、および、ｂ）前記イベント情報を、前記複数のネットワーク機器の各々に接続されたローカル情報システムとの間でやりとりする前記複数のネットワーク機器の各々の識別子を含む、プログラム。
【請求項３６】
コンピュータに、
第１のネットワーク機器に、複数のネットワーク機器の各々に接続されたローカル情報システムから第１のイベント用の第１のローカル情報識別子を受信させ、前記第１のローカル情報識別子、および、前記第１のローカル情報識別子と、前記第１のイベント用の第１の固有のネットワーク識別子との関連付けを、他のネットワーク機器にブロードキャストさせ、
前記第１のネットワーク機器に、他のネットワーク機器から、第２のイベントに関しており前記第２のイベントについての第２のローカル情報識別子と第２の固有の識別子とを含む第２の追跡情報を受信させ、
前記第１のネットワーク機器に、前記第２のイベントに対応する第２のローカル情報識別子を生成させ、
前記第１のネットワーク機器に、前記第２のローカル情報識別子に関連付けられた前記第２の追跡情報を格納させる、プログラム。
【国際調査報告】
2011501834.tif 000038
2011501834.tif 000039