JP2012513633A - データを交換する方法 - Google Patents

Abstract

本発明は、ゲートウェイを用いて少なくとも２つのサーバ間でデータを交換する方法に関する。好ましくは、この方法は、ヘルスケアシステムに適用される。各サーバは、固有のフェデレーテッド識別子を保持する。この識別子は、単一の患者Ｐを識別する。こうして、患者の本当の識別子を明らかにすることなく、サーバが互いに通信することが可能である。関連する患者データを保持する提供サーバ１２及び要求サーバ１０の各ペアに対して１つのセッション偽名を作成することにより、及び各セッション偽名に対して、要求サーバに関連付けられるインバウンドセッション識別子と、提供サーバに関連付けられるアウトバウンドセッション識別子とをフォーマット化することにより、このサーバは、互いに匿名データを通信することができる。患者データは、少なくとも１つの提供サーバから要求サーバへと転送され、すべてのセッション偽名は、要求サーバにおいて、患者Ｐに関する要求サーバの識別子で置換される。

Description

本発明は、ゲートウェイを用いて少なくとも２つのサーバ間でデータを交換する方法に関する。

多くの用途において、ネットワークにおける異なるサーバ間でデータが交換されるとき、中央の通信端末はゲートウェイとして機能する。例としては、例えばＷｅｂＭＤ、ＤＯＳＳＩＡ、マイクロソフトＨｅａｌｔｈＶａｕｌｔといったパーソナルヘルスレコード（ＰＨＲ）アーキテクチャ、例えばオランダにおけるＮＩＣＴＩＺ及びカナダにおけるＩｎｆｏｗａｙといった電子ヘルスレコード（ＥＨＲ）アーキテクチャ、及び例えば電子商取引といったウェブサービスを含む。ゲートウェイは単に、データを中継するか、又はデータを集約する。これは、典型的なＰＨＲ又はＥＨＲ用途において当てはまる。ゲートウェイの別の使用は、データを直接中継又は集約することなしに、識別子を解決する参照インデックスとして関与する。

全ての種類の医療記録という話になるときの特殊な状況は、異なるサーバ間で情報を交換するとき患者の匿名性及びリンク可能性を維持する必要がある点にある。これは、異なるサーバ間での交換の間、特定のデータを特定したくない他のシステムに関してももちろん言えることである。

しばしばＳＡＭＬ、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ又はＷＳ−Ｆｅｄｅｒａｔｉｏｎといった標準を採用することにより、これらの用途は通常、フェデレーテッド（federated：同盟化された）ＩＤ管理と呼ばれる概念を使用する。これは、例えば患者又は顧客といった同じ対象に関して、各通信相手が自身の識別子及び他の識別情報を保持することを意味する。これらの識別子は、中間のゲートウェイサービスプロバイダにおいて、論理的にリンクされる、即ちフェデレートされる。このプロバイダは、ＥＨＲ、電子商取引ゲートウェイ等とすることができる。

ＩＤフェデレーションフレームワーク（ＩＤ−ＦＦ）は、ウェブサービスを介して複数の企業間のＩＤフェデレーションを可能にするＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔにより構築される標準である。Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅフェデレーション・フレームワーク・アーキテクチャは、偽名ベースのソリューションを与える。これは、企業間のフェデレーテッドアカウントをリンクする鍵として偽名を使用する。その結果、ある企業は、別の企業におけるユーザの実際の識別子を知る必要がない。これは、偽名に関するサポートに沿って、個別のユーザのプライバシー決定とプライバシー法規とを厳守することができる柔軟な同盟の構築を可能にする。

Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅソリューションにおいて、ゲートウェイは通常、ＩＤ管理人の役割を持ち、一方要求サーバ及び提供サーバは、サービス実行の役割を持つ。

http://www.connectingforhealth.org/resources/f?nal_phwg_reportl.pdfにある文書「Connecting for health」は、典型的なＰＨＲ用途を説明する。この場合、仲介のゲートウェイが、ＰＨＲにおける個人の健康情報を収集及び組織化するのを助ける。このアーキテクチャは、ＰＨＲの内外でのデータの交換を可能にする。このモデルの２つの主要な変形例が存在する。

Ｉｎｄｅｐｅｎｄｅｎｔ Ｖｅｎｄｏｒ Ｉｎｔｅｇｒａｔｉｏｎモデルにおいて、スポンサーは、中央データベースを確立する。このデータベースを介して、ＰＨＲデータが、データソース（診療室、薬局、研究室等）からＰＨＲへと、又はその逆へと送信される。ＰＨＲレポートは、個別のユーザによる使用のため、及び許可があればプロバイダ及び他の信頼できる実体（例えば、子供の学校、薬局、専門家等）による使用のため、要求に応じて、又は特定の間隔で自動的に中央データベースから生成されることができる。このモデルは、個人の代わりに様々なソースからデータを集めることを容易にする。このモデルは、人々にとって使いやすいものである。なぜなら、彼らが自分たちでＰＨＲを確立及び維持する必要がないからである。しかしながら、個人の健康情報のセキュリティに関する懸念及び全ての情報の解放がユーザ制御によりできてしまう機構に関する懸念が存在する。第三者がスポンサーとなるシステムについての人々の信頼及び受け入れ度に関する追加的な調査が必要とされる。プロバイダは、共同体に広がるデータ標準を用いて、又はベンダーにより処理される「変換」プロトコルを用いて、このシステムとインタフェースする能力を持つ必要がある。

Ｉｎｄｅｐｅｎｄｅｎｔ Ｖｅｎｄｏｒ Ｉｎｔｅｇｒａｔｉｏｎモデルに対する変形例は、中央化された個人健康情報データベースではなく、個人に関する情報を特定するレポジトリと、共同体における関連付けられるデータソースの全てに対して識別子をマッピングするシステムとを確立することである。このモデルにおいて、レポートは、要求に応じて、又は、特定の間隔で生成される。しかし、リンク付けられたデータがシステムにおいて保持されるものではない。このモデルは、消費者によるアクセスのし易さ及び使用の容易さという点で同様の利点を持つ。プロバイダシステムの必要条件は最小化される。なぜなら、現在存在するいかなる形式においても、データが取得されるからである。臨床意思決定支援ツール及びこの分散されたデータ環境にわたるリアルタイム解析プロトコルの適用は複雑であり、時系列データの編集は、各データ供給元が共通のアーカイブプロトコルに従うことを必要とする。

既知の匿名化アーキテクチャに伴う問題は、それらが、偽名を反復的に解決及び置換しなければならないというゲートウェイ上での高い処理負荷をもたらす点にある。大部分のＥＨＲソリューションは、ＨＬ７といったデータ交換にＸＭＬを使用する標準に基づかれるので、特に偽名がＸＭＬ文書内の任意の位置に配置される場合、これは重い処理である。ウェブ−サービスにおける大部分の処理時間は、ＸＭＬ構造のデコード及び処理に費やされる。

それゆえに、プライバシーを保護しつつ効率を増加させることを可能にするデータ交換に関する改良された方法が有利である。

従って、本発明は好ましくは、添付の特許請求の範囲に基づきデータを交換する方法を与えることにより、単独で又は任意の組合せにおいて、従来における上述の不足及び不利な点の１つ又は複数を緩和、軽減又は除去しようとするものであり、少なくとも上述した問題を解決するものである。

いくつかの実施形態による目的は、プライバシーを維持すると共に、少なくとも２つのサーバ間でデータを交換するための効率的な方法を提供することである。

この問題は、ゲートウェイを用いて少なくとも２つのサーバ間でデータを交換する方法により解決される。ここで、各サーバは、固有のフェデレーテッド識別子を保持する。この識別子は、単一の患者を識別する。各サーバは、要求サーバ又は提供サーバの両方として機能することができる。この方法は、上記要求サーバから上記ゲートウェイへと上記患者のデータを要求するオリジナルのリクエストを送信するステップと、上記ゲートウェイを用いてフェデレーテッド識別子を解決するステップと、上記ゲートウェイにより、関連する患者のデータを保持する提供サーバ及び要求サーバの各ペアに関して１つのセッション偽名を作成するステップと、各セッション偽名に対して、上記要求サーバに関連付けられるインバウンド識別子アレイと上記提供サーバに関連付けられるアウトバウンド識別子アレイとをフォーマット化するステップと、各サーバに対してそれぞれ上記識別子アレイを中継するステップと、各提供サーバにより、上記アウトバウンド識別子アレイで上記患者の上記識別子を置換するステップと、上記少なくとも１つの提供サーバから上記要求サーバへと上記患者のデータを転送するステップと、上記要求サーバにおいて、上記患者に関する上記要求サーバの上記識別子ですべてのセッション偽名を置換するステップとを有する。

異なるＥＭＲシステムのユーザがどのようにゲートウェイサーバを介して互いに接続されるかを示す図である。 本発明による方法の第１の実施形態の異なるステップを示す図である。 本発明による方法の第２の実施形態の異なるステップを示す図である。 本発明による方法の第３の実施形態の異なるステップを示し、要求サーバが、提供サーバに帯域外要求を再送信するためにＵＲＬを使用する様子を示す図である。

本発明のこれら及び他の側面、特徴及び利点が、本発明の実施形態に関する以下の説明から明らかとなり、対応する図面を参照して説明されることになる。

図１は、ゲートウェイサーバ２を介して互いに接続される個別の電子医療記録（ＥＭＲ）システムを持つユーザから構築されるＥＨＲシステムを示す。図１におけるユーザは、一般開業医（ＧＰ）４、薬局６及び専門病院８である。図１は更に、患者Ｐを示す。患者の医療記録は、ＥＭＲシステムの一部又は全てに格納されることができる。ＥＭＲシステムは、すべてのユーザに対して同じタイプとすることができるが、通常は異なるタイプである。上記とは関係なく、各ＥＭＲシステムは、患者Ｐに関する自身の識別子を持つ。ゲートウェイサーバ２は、その登録を保つことにより、すべての既存の同盟関係にある識別子を解決することができる。

ある方法の第１の実施形態が以下、図２を参照して詳細に説明されることになる。この実施形態は、電子健康記録（ＥＨＲ）システムと連動して説明されることになる。しかしながら、各サーバが同じ１人の患者に関する一意なフェデレーテッド識別子を保持するような任意のサーバゲートウェイシステムにおいて使用されることができる。

ＥＨＲは、デジタルフォーマットにおいて１人の個人の１つの医療記録を参照する。ＥＨＲシステムは、個別のＥＨＲのコンピュータ支援による格納及び検索を調整する。ＥＨＲは、多くのプロバイダからの電子医療記録（ＥＭＲ）から作られる。こうして、様々なタイプの健康関連の情報が、格納及びアクセスされることができる。

例えば一般開業医（ＧＰ）、歯科医、薬剤師又は実際の患者Ｐとすることができるエンドユーザが、患者Ｐに関する特定のデータを要求するとき、ローカルＥＭＲサーバは、患者Ｐのローカルのフェデレーテッド識別子を有するリクエストを作る。このリクエストは更に、必要とされるデータの所望のタイプの明細を有することができる。歯科医は、免疫化記録より歯の記録に興味を持つであろう。このリクエストが特定のデータに対する要求を含む場合であっても、アクセス制御の設定によって、データがアクセス可能であるとは仮定されない点に留意されたい。このリクエストは更に、この方法の実現に適用可能な他の適切なパラメータを有することができる。

この方法の一実施形態によれば、ローカルＥＭＲサーバが呼び出され、図２において符号１０で示される要求サーバとして機能する。図２は更に、ゲートウェイ２及び３つの提供サーバ１２を示す。これは、要求されたデータを保持する異なるプロバイダのＥＭＲシステムに対応する。

別の実施形態では、代わりに、要求サーバが、提供サーバに接続される内蔵ＰＣであってもよい。

いずれの方法でも、ＥＨＲシステムゲートウェイ２に対して、矢印１００により示されるリクエストが送信される。このゲートウェイは、矢印１０２により参照されるように、患者Ｐに関連付けられるフェデレーテッド識別を解決し、関連する患者データを保持する提供サーバ１２と要求サーバ１０との各ペアに対して１つのセッション偽名を作る。

その後、ゲートウェイ２は、各セッション偽名に対して、要求サーバに関連づけられる患者Ｐに関するインバウンド識別子アレイと、提供サーバに関連づけられる患者Ｐに関するアウトバウンド識別子アレイとをフォーマット化する。こうして、各セッション偽名は、要求サーバに関する患者識別子とペアにされ、要求サーバに関するインバウンド識別子アレイに含まれ、提供サーバに関する患者識別子とペアにされ、提供サーバに関するアウトバウンド識別子アレイに含まれる。その後、各提供サーバ１２に対して、ゲートウェイ２は、個別のセッション偽名を有するアウトバウンドリクエストを準備する。要求サーバの元の識別子がセッション偽名で置換される点にも留意されたい。更に、ゲートウェイ２は、個別のアウトバウンド識別子アレイを追加して、矢印１０４で示されるように、各提供サーバ１２に対して各リクエストをそれぞれ中継する。

リクエストを受信すると、提供サーバ１２は、リクエストからセッション偽名を抽出して、提供サーバ１２に関する対応する識別子を選択するため、添付されたアウトバウンド識別子アレイを使用する。更に、提供サーバは、要求されたデータを取得して、矢印１０６で示されるように、セッション偽名へのリファレンスを有するレスポンスにおいて、ゲートウェイ２へとこのデータを送り返す。しかし、このレスポンスは、提供サーバ１２に関する識別子へのいかなるリファレンスも含まない。

ゲートウェイ２は、矢印１０８により示されるように、元のリクエストにより促されるすべてのレスポンスデータを待ち、１つのレスポンスへとこれを集める。その後、ゲートウェイは、インバウンド識別子アレイをレスポンスに追加して、矢印１１０に示されるように、要求サーバ１０にこれを戻す。要求サーバ１０はその結果として、矢印１１２に示されるように、患者ＰのＥＭＲを処理する前に元の識別子ですべてのセッション偽名を置換し、例えば、もともとこのデータを要求したエンドユーザにこれを表示する。

この実施形態の変形例において、ゲートウェイ２は、インバウンド識別子アレイをレスポンスに追加し、要求サーバ１２に直接これを中継する。要求サーバ１２は、ゲートウェイ２の代わりに１つのレスポンスへと集約する。この実施形態は、ゲートウェイ２から離れた所により多くの処理作業を動かし、このアーキテクチャの柔軟性という更なる利点を提供する。多くの小さなデータレコードにインバウンド識別子アレイを追加し、これを送信することに対して、１つの大きなデータレコードに集約し、これを送信することの処理の複雑さを評価する機能が例えば提供されることができる。

図３に示されるこの方法の第２の実施形態において、第１のセッション偽名の作成及びその対応するインバウンド識別子アレイのフォーマット化は、要求サーバ１０においてすでに実行される。矢印２００により示される中継されたリクエストは、患者Ｐのローカルのフェデレーテッド識別子に対してではなく、セッション偽名に対するリファレンスを有する。このインバウンド識別子アレイは、リクエストに追加される。

矢印２０２に示されるように、ＥＨＲシステムゲートウェイ２は、インバウンド識別子アレイを解決する。この解決は、インバウンド識別子アレイから要求サーバ上で患者Ｐに関する患者識別子を抽出し、提供サーバに関して対応する患者識別子を調べ、後者の識別子をセッション偽名に関連付けることを含む。このセッション偽名も、インバウンド識別子アレイから抽出される。１つ以上の提供サーバ１２がある場合、ゲートウェイ２は、各追加的な提供サーバ１２に関して１つの追加的な固有のセッション偽名をつくる。矢印２０４に示されるように、各提供サーバ１２にリクエストを中継する前に、ゲートウェイ２は、提供サーバの患者識別子及びセッション偽名ペアを用いて、各提供サーバ１２に関して１つのアウトバウンド識別子アレイをフォーマット化し、その個別のリクエストにこれを追加する。

リクエストを受信すると、各提供サーバ１２は、提供サーバ１２において患者Ｐの識別子を解決するため、添付されたセッション識別子を使用する。更に、提供サーバ１２は、要求されたータを取得し、セッション偽名を有するレスポンスにおいてゲートウェイ２にこれを送信する。ここで、提供サーバの患者識別子のすべての発生が個別のセッション偽名で置換される。

ゲートウェイ２は、元のリクエストにより促されるすべてのレスポンスデータを待ち、１つのレスポンスへとこれを集める。その後、ゲートウェイは、要求サーバ１０にこれを中継する。要求サーバ１０はその結果として、患者ＰのＥＭＲを処理する前に元の識別子ですべてのセッション偽名を置換し、例えば、もともとこのデータを要求したエンドユーザにこれを表示する。

この実施形態の変形例において、矢印２０６により示されるように、ゲートウェイは、インバウンド識別子アレイをレスポンスに追加し、要求サーバ１２に直接これを中継する。要求サーバ１２は、その後集約を行う。

図４に示される第３の実施形態において、矢印３００に示されるように、要求サーバは、ゲートウェイ２にリクエストを送信する。このゲートウェイは、インバウンドフェデレーテッド識別子を解決し、各提供サーバ１２に対して１つのセッション偽名を作り、提供サーバ１２において患者Ｐに関する識別子を暗号化する。その結果、この識別子は、その個別の提供サーバ１２によってのみ復号化される。その後、ゲートウェイ２は、矢印３０２により示されるように、各提供サーバ１２に対して、セッション偽名と、要求サーバ１０自身に関する識別子と、提供サーバ１２上での患者Ｐに関する暗号化された識別子と、例えば各提供サーバ１２に関する１つのユニフォーム・リソース・ロケータ（ＵＲＬ）といったアドレスとを有する１つの中間レスポンスを返信する。

中間レスポンスを受信すると、要求サーバ１０は、矢印３０４により示されるように、各提供サーバ１２にそれぞれ帯域外リクエストを再送信するため、アドレス、例えばＵＲＬを使用する。このリクエストは、提供サーバ上の患者Ｐに関するセッション偽名及び暗号化された識別子を有する。

帯域外リクエストを受信すると、提供サーバは、暗号化された識別子を復号化し、ＥＭＲを取得し、及びセッション偽名を参照して直接要求サーバ１０にレスポンスとしてこれを送信する。

要求サーバ１０は結果的に、患者ＰのＥＭＲを処理する前にすべてのセッション偽名を元の識別子で置換し、すべてのＥＭＲを１つのＥＭＲへと集約する。集約結果は例えば、もともとこのデータを要求したエンドユーザに表示される。

この実施形態は、ゲートウェイ・データ・ボトルネック問題に対処し、プライバシーを維持しつつ、ゲートウェイ２を介してデータを送信することなく、要求サーバ１０から提供サーバ１２への直接のデータフローを可能にする。

要求サーバ及び提供サーバとして上述された異なるサーバが、機能を入れ替えることができる点を理解されたい。こうして、環境に応じて、ある状況では、このサーバが、要求サーバとして機能し、別の状況では、提供サーバとして機能する場合がある。特定のサーバが、これらをゲートウェイとして機能することを可能にするゲートウェイ機能を持つことができる点も理解されたい。典型的なサーバは、ＥＨＲサーバである。

更に、本発明が特定の特徴を持つ好ましい実施形態を用いて説明されているが、ある実施形態における個別の特徴が、他の実施形態と共に、又は他の実施形態における個別の特徴と共に組み合わせられることができる点が当業者には明らかであることを理解されたい。

本発明が特定の実施形態を参照して上で説明されたが、これは、本書に記載される上記特定の形式に本発明が限定されることを目的とするものではない。むしろ、本発明は添付の請求項によってのみ限定され、上述した特定の実施形態以外の、これらの添付した請求項の範囲に含まれる実施形態が同様に可能である。

特許請求の範囲において、「有する」という用語は、他の要素又はステップの存在を排除するものではない。更に、個別的に記載されていても、複数の手段、要素又は方法ステップが、例えば単一のユニット又はプロセッサにより実現されることもできる。更に、個別の特徴が異なる請求項に含まれることができるが、これらは可能であれば有利に結合されることができる。異なる請求項に含まれることは、これらの特徴の組み合わせが、実現できない及び／又は有利でないことを意味するものではない。更に、単数形の参照は、複数性を排除するものではない。「ａ」、「ａｎ」、「第１の」、「第２の」等の用語は、複数性を排除するものではない。請求項における参照符号は、単に明確化のための例として与えられ、請求項の範囲をいかなる態様でも限定するものとして解釈されるべきではない。

Claims (9)

1. ゲートウェイを用いて少なくとも２つのサーバ間でデータを交換する方法において、各サーバが、固有のフェデレーテッド識別子であって、単一の患者を識別するフェデレーテッド識別子を保持し、要求サーバ又は提供サーバとして機能することができ、前記方法は、
   前記患者のデータを要求するオリジナルのリクエストを前記要求サーバから前記ゲートウェイに送信するステップと、前記ゲートウェイを用いて前記患者に関連づけられるフェデレーテッド識別子を解決するステップと、
   前記ゲートウェイにより、関連する患者データを保持する提供サーバ及び要求サーバの各ペアに関して１つのセッション偽名を作成するステップと、
   各セッション偽名に対して、前記要求サーバに関連付けられるインバウンド識別子アレイと前記提供サーバに関連付けられるアウトバウンド識別子アレイとをフォーマット化するステップと、
   各サーバに対してそれぞれ前記識別子アレイを中継するステップと、
   各提供サーバにより、前記セッション偽名で前記患者の前記識別子を置換するステップと、
   前記少なくとも１つの提供サーバから前記要求サーバへと前記患者データを転送するステップと、
   前記要求サーバにより、前記患者に関する前記要求サーバの前記識別子ですべてのセッション偽名を置換するステップとを有する、方法。
2. 前記オリジナルリクエストは、前記患者に関する第１のフェデレーテッド識別子を有する、請求項１に記載のデータを交換する方法。
3. 前記オリジナルリクエストは、所望のタイプの前記患者データの明細を有する、請求項１又は２に記載のデータを交換する方法。
4. 前記セッション偽名の作成ステップが、前記要求サーバによりなされ、前記前記識別子アレイの中継ステップは、前記提供サーバ及び前記ゲートウェイに対してのものである、請求項１乃至３のいずれかに記載のデータを交換する方法。
5. 前記中継ステップが更に、
   各提供サーバに関するアウトバウンドリクエストを準備するステップと、
   前記リクエストに前記アウトバウンド識別子アレイを追加するステップと、
   個別の提供サーバに前記リクエストを中継するステップとを有する、請求項１乃至４のいずれかに記載のデータを交換する方法。
6. 前記解決及び中継ステップが更に、
   それぞれ前記ゲートウェイ及び前記提供サーバによってのみデコード可能な態様で、各提供サーバに関する前記フェデレーテッド識別子を暗号化するステップと、
   前記セッション偽名、前記要求サーバ識別子、前記暗号化された識別子及び各提供サーバのアドレスを参照して、アウトバウンドレスポンスを準備するステップと、
   前記要求サーバに前記レスポンスを送信するステップとを有する、請求項３に記載のデータを交換する方法。
7. 第１のレスポンスを受信すると前記要求サーバが、個別のセッション偽名、前記要求サーバ識別子及び前記暗号化された識別子を参照して個別の提供サーバに直接、帯域外の患者データに関する前記リクエストを送信する、請求項６に記載のデータを交換する方法。
8. リクエストを受信すると前記提供サーバが、前記識別子を解決し、前記暗号化された識別子を介して、前記要求された患者データを取得し、前記セッション偽名を参照してレスポンスにおいて前記取得されたデータを送信する、請求項７に記載のデータを交換する方法。
9. 前記要求及び提供サーバが、電子機器医療記録システムにより構成される、請求項１に記載のデータを交換する方法。

Images