JP2007531124A

JP2007531124A - 患者医療データ記録のアクセス及び利用を制御するためのシステム及び方法

Info

Publication number: JP2007531124A
Application number: JP2007505257A
Authority: JP
Inventors: ランバートピーオヌマ; アランエスイトー; ブラッドレージェイモスマン; ロバートアールアルバートソン; ヒルトンシャーリーエスエスパイ
Original assignee: コンヴァージェンスシーティー
Priority date: 2004-03-26
Filing date: 2005-03-28
Publication date: 2007-11-01
Also published as: WO2005098736A3; WO2005098736A2; EP1728189A2; US20050236474A1

Abstract

【課題】規制適合のため患者の保険情報（ＰＨＩ）の機密性を守るＰＨＩ処理システムを提供する。
【解決手段】ＰＨＩは患者の医療データと関連する患者識別データを含んでいる。匿名化エージェントは患者の医療データを抽出し、匿名の患者データを作成するため全ての識別データから区別する。鍵は患者識別データと患者医療データの以降の再関連付けを許可するために生成される。匿名の患者のデータベースは患者のスクリーニング目的で照会することが可能である。患者照会は研究又は患者のスクリーニングが内部審査委員会のような，適任の官庁によって認可を得られたときにのみ、処理される。医学的な特徴が患者照会と一致する患者は利用可能な研究が選択される。もし選ばれた患者の再認識が必要ならば、認可され、鍵は必要な再関連付けを規定する為に利用可能である。データログは患者データへの全てのアクセスを記録する。
【選択図】図３

Description

本発明は、コンピュータ上の記録管理、より具体的には、患者医療データ記録のアクセスおよび利用を制御するためのシステムおよび方法に関する。

患者の医療データ記録などの記録を格納するためにはコンピュータの利用がよく知られている。通常は、患者の医療記録への不正アクセスを防止するためにユーザーパスワードなどの従来のセキュリティ対策が使用されている。ユーザーが適切なパスワードを有している場合、ユーザーは極秘の保護された保健情報を含む医療データ記録にアクセス可能となる。患者に適切な医療を提供するためにこうしたアクセスを指示することがある。しかし、場合によっては患者情報へのアクセスを制限したりアクセスを全体的に禁止したりすることが望ましい。

ある例では、ＨＩＰＡＡと呼ばれる１９９６年のＨｅａｌｔｈＩｎｓｕｒａｎｃｅＰｏｒｔａｂｉｌｉｔｙａｎｄＡｃｃｏｕｎｔａｂｉｌｉｔｙＡｃｔでは、病院などの組織による保護された保健情報のセキュリティを義務付けている。大学や研究所などの大規模な研究機関は、通常、ＨＩＰＡＡへの適合を保証するために一人以上のスタッフを雇用することができる。しかし、多くの組織では、ＨＩＰＡＡへの適合を保証するために専門の人員を利用するのに十分な予算があるわけではない。

その他の状況では、規制事項とは別に患者データ記録へのアクセスを制限することが望ましい。そのため、病院の業務および研究環境における保護された保健情報へのアクセスを制御するシステムおよび方法へのニーズが高まっている。本発明は、以下の詳細な説明および添付の図面から明らかになるように、これおよびその他の利点を提供するものである。

典型的な実施例において、本教示によって構成されたシステムは、患者識別データおよび関連する患者医療データを格納する保護された保健情報（ＰＨＩ）格納構造へのアクセスを制御する。システムは、患者識別データとは関連付けられないよう患者医療データを格納する匿名データ構造を含む。鍵ファイルには、非関連の患者識別データと患者医療データを相関付けるデータを含む。認証コントローラは、データアクセスリクエストを処理する。認証コントローラがアクセスリクエストを受信すると、受信されたアクセスリクエストは所定のデータアクセス認証と比較され、受信されたアクセスリクエストが所定のデータアクセス認証と適合する場合、患者医療データへのアクセスが許可される。

システムは、患者識別データおよび関連する患者医療データを処理することで患者医療データおよび患者識別データを非関連にすることで非関連の患者医療データを生成する匿名化エージェントをさらに含む。匿名化エージェントは患者識別データおよび関連する患者医療データに関連する鍵を生成することで非関連の患者医療データと患者識別データの以降の再関連付けを許可する。鍵は鍵ファイルに格納され、一実施例では、ランダム鍵とすることもできる。
システムは、受信したアクセスリクエストがこうした関連付けを必要とする場合に、鍵ファイルのデータを処理するための再識別エージェントをさらに含み、患者医療データと患者識別データの再関連付けを行うことで再関連付けされた患者医療データを生成することができる。典型的な実施例において、再識別された患者医療データの受信したアクセスリクエストは認証プロセッサによって処理され、再識別エージェントは、所定のデータアクセス認証によってこうした再関連付けが可能になる場合にのみ患者医療データおよび患者識別データを再関連付けする。
システムはさらに、患者医療データを照会しユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するよう構成されている、ユーザーが選択可能な患者選択基準を有する患者照会エージェントを含む。典型的な実施例では、患者照会エージェントは、匿名データ格納構造において非関連の患者医療データを照会するよう構成されている。典型的な実施例では、選択基準に合致する特徴を有する患者から選択した患者医療データは匿名の照会データ格納構造に格納される。

一実施例において、受信されたアクセスリクエストは、必要なデータの種類および必要なデータの利用に関連付けられた目的を示す。認証プロセッサは、患者識別データに関連付けられた匿名化患者医療データまたは患者医療データへのアクセスを許可するための審査委員会の認証に基づいて認証入力を受け入れる。
認証プロセッサは、アクセスが許可された患者医療データの以降の利用を制御することもできる。一実施例において、認証プロセッサは、所定の期間に限定して医療データの今後の利用を許可する。別の実施例において、認証プロセッサはアクセスが許可された患者医療データの印刷を禁止する。さらに別の実施例において、認証プロセッサはアクセスが許可された患者医療データのコピーを禁止する。ログにより患者医療データへのアクセスが監視され、これに関するレポートを作成可能である。

別の実施例において、システムは、各医療機関がＰＨＩ格納構造を有する複数の医療機関環境において実施可能である。この実施例において、複数の医療機関は、匿名データ格納構造を共有できる。医療機関は、匿名化エージェントも共有できる。あるいは、匿名化エージェントを複数の医療機関の選択された一つに送り、複数の医療機関の選択された一つのＰＨＩ格納構造の関連する患者医療データの患者識別データを処理することが可能である。この実施例において、送られた匿名化エージェントは患者医療データを配信したり、匿名データ格納構造に概略的な患者医療データを配信するのみにすることができる。

本明細書に詳細に説明されているように、本明細書で説明されているコンピュータシステムおよび動作方法を利用して、患者データへの複数レベルのセキュリティおよびアクセスを提供することができる。患者データの利用は、臨床実験、患者のスクリーニング、疫学的調査およびその他の研究において重要である。患者のプライバシーに対する懸念は従来からの課題であったが、１９９６年の新しいＨｅａｌｔｈＩｎｓｕｒａｎｃｅＰｏｒｔａｂｉｌｉｔｙａｎｄＡｃｃｏｕｎｔａｂｉｌｉｔｙＡｃｔ（ＨＩＰＡＡ）は、研究目的の患者レベルのデータの利用に大きく影響する。

本明細書で使用されているように、「保護された保健情報」（ＰＨＩ）という用語は、極秘と考えられる患者情報を指し、保護が必要である。ＰＨＩデータに関連付けられる保護レベルは、用途に応じて変えることができる。一実施例において、ＰＨＩのデータセキュリティのレベルはＨＩＰＰの要件に準拠する。別の実施例において、ＰＨＩのセキュリティレベルはＨＩＰＡＡの要件によって指定されるレベルよりも高くしたり、または低くしたりすることができる。
病院の業務および患者への医療行為へのＰＨＩの利用は、本明細書で説明されている様々なセキュリティレベル下におくことができる。業務、マーケティングまたは研究におけるＰＨＩの利用には、ＨＩＰＡＡへの適合が必須である。以下でより詳細に説明するように、本教示によって構成されるシステムは、データをリクエストする個人に付与される認証レベルに基づいてデータへの様々なアクセスレベルを可能にする。システムによってデータへの安全なアクセスが実現し、データの利用に対して制限が課される。
個々の患者のデータ記録は、従来技術を利用して様々な異なる公知の方法で格納可能である。しかし、ＰＨＩを利用するデータベースの作成は、ＨＩＰＡＡ適合の目的のための研究と考えられる。研究におけるＰＨＩの利用は、ＰＨＩの利用およびデータの利用をリクエストする個人のアイデンティティによって、現在では様々な承認を必要とする。以下に詳細に説明するように、本明細書で説明するシステムに固有の適合プロセスは、認証プロセスの自動化、認証およびデータアクセスの様々なレベルの追跡、および認証された個人に限定したアクセスの許可に役立つ。
ＰＨＩへの制限されたアクセスだけでなく、ＰＨＩの全ての開示事項を追跡する必要がある。ＨＩＰＡＡなどの規制の対象となっている病院やその他の組織は、リクエストに応じて患者に情報開示できる態勢を整えておく必要がある。本明細書で説明されているシステムは、ＰＨＩへの全てのアクセスを追跡し、ログレポートを容易に生成することが可能である。

一例において、本発明は、クライアント−サーバー型のアーキテクチャという背景において最も容易に理解されるシステム１００において実現される。しかし、当業者には明らかであるように、いかなる便利なコンピュータアーキテクチャでもシステム１００を実現するために利用可能である。システム１００は、クライアント−サーバー型のアーキテクチャに制限されるものではない。

図１において、システム１００は、クライアント１０２とサーバー１０４とを含む。クライアント１０２は、クライアントコンピュータ１０６を含む。便宜上、クライアントコンピュータ１０６を実施するために使用されるディスクドライブ、キーボード、モニター、カーソル制御デバイスなどの従来のコンポーネントは図示していない。さらに、こうした従来のコンピュータコンポーネントの動作は当分野において公知であるため、本明細書では説明しない。
クライアントコンピュータ１０２はさらに、ＰＨＩのアクセスおよび利用における条件および制限について定めるドキュメントである、ユーザーライセンス１０８を含む。ユーザーライセンス１０８は、データへのアクセスをリクエストする個人（研究者など）に渡されるハードコピーの紙にしたり、またはクライアントコンピュータ１０６へと電子的に送信したりすることができる。特定のクライアントコンピュータは、一つ以上のユーザーライセンス１０８を含むことができる。ライセンスドキュメントは、データへのアクセスおよびそのデータのそれ以降の利用についての制限に関する情報をユーザーに提供する。ユーザーライセンス１０８はデータの利用に関するドキュメンテーションを提供する場合もあるが、システム１００はＰＨＩの利用が付与されたライセンスに沿ったものであることを保証するために一連の安全なプロセスによってＰＨＩのアクセスおよび利用を自動的に制御する。患者の医療データまたは記録へのアクセスを許可する安全なプロセスについては、以下により詳細に説明する。
クライアントコンピュータ１０２は、ネットワークインターフェースコントローラー（ＮＩＣ）１１０も含む。ＮＩＣ１１０はクライアントコンピュータ１０２とネットワーク１１４との間の通信を制御する。ＮＩＣ１１０の実施例は、ネットワーク１１４の形式によって変化する。例えば、ネットワーク１１４はローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）にすることができる。ネットワーク１１４は高速接続（例：イーサネット接続）またはダイヤルアップモデム接続にすることが可能である。従って、ＮＩＣ１１０は、ネットワーク１１４と通信するために従来の技術を利用する。一例において、ＮＩＣ１１０は、ネットワーク１１４との高速接続を可能にする高速ネットワークインターフェースである。従って、ＮＩＣ１１０は、ネットワーク１１４との低速通信を可能にする従来の電話モデムとすることが可能である。

図１は、バスシステム１１２によって共に接続されるクライアントコンピュータ１０２の様々なコンポーネントを示す。バスシステム１１２は、インターフェースケーブルやその組み合わせなどの、内部バスおよび／または外部バスにすることが可能である。バスシステム１１２は、データバス、アドレスバス、パワーバス、コントロールバスなどにすることが可能である。便宜上、様々なバスを図１にバスシステム１１２として示す。
サーバー１０４は、通常、病院、研究診療機関、またはＰＨＩを有するその他の医療機関のコンピュータシステムの一部となるサーバーコンピュータ１２０を含む。クライアントコンピュータ１０２について上記に説明したように、サーバーコンピュータ１２０は、本明細書では説明しない多くの従来のコンポーネントを有している。こうしたコンポーネントには、一例として、メモリ、ディスク格納デバイス、モニター、キーボード、カーソルコントローラーなどを含む。サーバーコンピュータ１２０を実施するために使用される様々な従来のコンポーネントは当分野において公知であるため、本明細書では説明しない。さらに、サーバーコンピュータ１２０を実施するために従来のコンポーネントを様々な組み合わせで利用することができる。システム１００は、サーバーコンピュータ１２０を実施するために使用する従来のコンポーネントの種類または数量によって制限されない。
サーバー１０４は、さらに、データ格納構造１２２も含む。本明細書においてより詳細に説明するように、データ格納構造１２２は患者医療データ記録を含む。一実施例において、データ格納構造１２２は、ＰＨＩが格納されているデータベースとして実施可能である。ＨＩＰＡＡなどの規制事項に従って処理されるデータ記録は、データ格納構造１２２内に格納することも可能である。典型的な実施例において、ＨＩＰＡＡ要件に従って処理された患者医療データ記録は、本明細書でより詳細に説明するように、別の患者データベースに格納することが可能である。一つ以上のデータベースとして説明されているが、データ格納構造１２２は、公知の様々な技術を利用して実施することが可能である。データ格納構造１２２の特定の形式を、システム１００を制限するものとして解釈するべきではない。
サーバー１０４は、ネットワークインターフェースコントローラー（ＮＩＣ）１２３も含む。ＮＩＣ１１０について説明されているように、ＮＩＣ１２３は、ネットワーク１１４の特定の形式およびサーバー１０４の望ましい実施例によって、様々な異なる方法で実施可能である。また、システム１００はＮＩＣ１２３の特定の実施例によって制限されない。

図１は、バスシステム１３０によって共に接続されるサーバー１０４の様々なコンポーネントを示す。バスシステム１３０は、インターフェースケーブルやその組み合わせなどの、内部バスまたは外部バスにすることが可能である。バスシステム１３０は、アドレスバス、データバス、パワーバス、コントロールバスにすることが可能である。便宜上、こうした様々なバスをバスシステム１３０として図１に示す。
システム１００は、セキュリティサービスモジュール１２４を含むこともできる。セキュリティサービスモジュールは、サーバー１０４に統合可能である。しかし、多くの病院またはその他の医療機関は既に既存のコンピュータシステムを備えている。そのため、典型的な実施例において、セキュリティサービスモジュール１２４は、医療機関の既存のコンピュータインフラストラクチャと共存できる、またはこれに追加できる別のライセンスサーバーコンピュータ１２５で実施することができる。これにより、既存のコンピュータインフラストラクチャ全体を入れ替える必要性がなくなるとともに、利点として病院またはその他の医療機関にＰＨＩへのアクセスを制御させることができるようになる。ライセンスサーバーコンピュータ１２５は、病院に設置するか、または別の場所に設置することが可能である。当業者は、この分散型ネットワークにおいてはコンピュータシステムを物理的に同一の場所に設置する必要がないことを理解されるであろう。システム１００は特定のコンピュータアーキテクチャまたはシステムの様々なコンポーネントの特定の位置に制限されない。

以下により詳細に説明するように、セキュリティサービスモジュール１２４はＰＨＩへの全アクセスおよびその利用を制御する。当業者はＰＨＩの利用はＨＩＰＡＡによって厳格に規制されており、これは州、地方自治体、または組織の規則によってさらに規制されることがあることを理解するであろう。全ての患者識別データと非関連の患者医療データはＨＩＰＡＡの規制対象ではないことが公知である。一実施例において、セキュリティサービスモジュール１２４は、ＰＨＩを匿名にする働きがあるため、関連づけられている患者識別データから患者医療データを非関連にする。セキュリティサービスモジュール１２４は、必要な場合、以降、再識別を可能にするようにこれを実行する。匿名化されたデータの利点は、これはＨＩＰＡＡによって規制されず、ＨＩＰＡＡ規制から制限を課されることなく利用できるということである。匿名化されたデータの利用についてのその他の政府または組織による制限は、その場合でも適用される場合がある。
研究上のニーズによって、多くの場合、研究または臨床調査において患者の参加が必要になることがある。こうした参加には、患者の再識別および医療情報の利用のためのＨＩＰＡＡへの適合が必要になる。セキュリティサービスモジュール１２４は、匿名化されたデータの生成において使用される非関連化プロセス中に鍵を生成する。この鍵は、この後、患者医療データとこの非関連の患者識別データを再関連付けするためにセキュリティサービスモジュール１２４によって使用することが可能である。セキュリティサービスモジュール１２４のその他の機能および様々なコンポーネントについて以下に説明する。

ログファイル１２６は、患者医療データ記録の全ての利用を追跡する。以下により詳細に説明するように、ログファイル１２６はデータアクセスのレポートを生成するために容易に使用できるため、規制の適合に役立つ。
サーバー１０４は、ネットワークインターフェースコントローラー（ＮＩＣ）１２８も含む。ＮＩＣ１２８は、ネットワーク１１４によって、セキュリティサービスモジュール１２４とサーバーコンピュータ１０４との便利な結合を可能にする。ＮＩＣ１１０およびＮＩＣ１２３について説明されているように、ＮＩＣ１２８は、ネットワーク１１４の特定の形式によって、様々な異なる方法で実施可能である。例えば、ＮＩＣ１２８は、ダイヤルアップモデムまたはイーサネット接続などの高速ネットワークインターフェース接続にすることが可能である。このため、システム１００はＮＩＣ１２８の特定の実施例によって制限されることはない。

図２は、システム１００の実施例を示す。図２に示されるように、病院は、データベースまたはその他の便利な格納デバイスとしてデータ格納構造１２２に格納が可能な、ＰＨＩ１３８を含む。上記に説明するように、ＰＨＩ１３８は、ＨＩＰＡＡのガイドラインまたはその他の規制ガイドライン下で利用する必要のある極秘の患者識別データを含む。ＨＩＰＡＡの様々な規制のガイドラインは当業者には公知であるため、本明細書では詳細に説明しない。しかし、システム１００では、ＰＨＩの利用に関するＨＩＰＡＡまたはその他の州、地方自治体または組織の規制の規制事項に適合するためにコンピュータによってＰＨＩのアクセスおよび利用を制御することが可能である。ＰＨＩを処理可能な方法とは、全ての患者識別データが患者医療データから非関連になる匿名化プロセスである。ＨＩＰＡＡ規制は、匿名化データの作成のためにどの患者識別データを除外すべきかということを指定する。以前に説明したように、匿名化データはＨＩＰＡＡの規制を受けない。
図２に示すように、データがデータセット作成プロセスにおいて病院のＰＨＩから抽出され、全ての識別データから無関連となる。匿名化患者データは匿名化患者データベース１４０に格納される。匿名化患者データベース１４０は、データ格納構造１２２の一部としても格納可能であるか、または別のデータ格納構造に格納可能である。例えば、匿名化データベース１４０は、ライセンスサーバーコンピュータ１２５内のデータ格納構造に格納することもできる（図１を参照）。

匿名化患者データベース１４０は、医学研究などのための主題を選択するために研究者によって利用可能な情報を含む。例えば、研究ワークフローの一貫として、研究者は、選択した年齢層の女性の被験者かつ所定の医学的な特徴を有する被験者グループを必要とする場合がある。こうした種類のデータは、匿名化患者データベース１４０で利用可能である。しかし、匿名化患者データベース１４０には、特定の被験者を識別するための追跡可能なデータが含まれていない。
匿名化患者データベース１４０は、上記で説明するように、患者情報を照会したり、患者スクリーニングに利用したりすることが可能である。照会に基づいて、匿名化された患者を匿名化患者データベース１４０から選択することが可能であり、これは一つ以上の特定データセット１４２として格納される。特定データセット１４２には、照会の選択基準と一致する患者医療データ記録が含まれる。以前に説明したように、ＰＨＩ１３８は、通常、病院のコンピュータシステムの一部となっている。特定データセット１４２は、別のデータベースとして格納可能であり、データ格納構造１２２の一部とするか、または別の格納構造の一部にすることができる。例えば、特定データセット１４２は、ライセンスサーバーコンピュータ１２５の一部とすることができる（図１を参照）。
場合によって、特定データセット１４２は、個々の医療データ記録と関連付けられた特定の患者を再識別せずに利用することが可能である。また別の場合では、患者の再識別が必要になることがある。再識別された特定データセット１４２からのデータは、特定のＰＨＩデータセット１４４に格納可能である（図３を参照）。特定のＰＨＩデータセット１４４のデータは、以前に説明した照会に基づいて、選択基準に一致するが、再識別されて患者識別データを含んでいる。
匿名化患者データベース１４０は識別情報を含んでいないが、セキュリティサービスモジュール１２４のデータを利用して、患者を再識別することが可能である（図１を参照）。再識別プロセスにおいて、図３に示すように、ランダム鍵が匿名化されたデータ記録のそれぞれに割り当てられ、鍵および識別情報は鍵ファイル１８２に格納される。鍵ファイル１８２は、データ格納構造１２２の一部またはその他のデータ格納構造の一部とすることが可能である。鍵ファイル１８２は、セキュリティサービスモジュール１２４の一部として、またはこれに関連して格納することが可能である（図１を参照）。

鍵ファイル１８２は、特定の研究プロジェクトに必要となることがある匿名化された記録を再識別するために使用される。以下により詳細に説明するように、情報のリクエストが認証されており、データ記録へのリクエストされたアクセスが内部規則および外部規制（例：ＨＩＰＡＡ）に適合するものであることを確認するために、あらゆるアクションの前に、セキュリティサービスモジュール１２４において情報に対する認証がチェックされる。
患者医療データへの全アクセスはログファイル１２６において記録される（図１を参照）。これには、ＰＨＩ１３８、匿名化データベース１４０、特定データセット１４２、または特定のＰＨＩデータセット１４４へのアクセスが含まれる。このため、患者医療データのソースへの全アクセスはログファイル１２６において記録される。ログファイル１２６はデータへのアクセスを追跡し、特定データセット１４２へのアクセスを示すレポートの容易な生成を可能にすることによって、別の重要な規制事項に適合する。ＰＨＩのコピーおよび印刷は、セキュリティサービスモジュール１２４によって制御される（図１を参照）。ＰＨＩのコピーおよび印刷は、さらに、ログファイル１２６において監視および格納可能である。

図３は、一つの病院環境などの典型的な医療機関の環境におけるシステム１００の動作を示す。図３によると、極秘のＰＨＩ１３８は、安全な格納領域に格納される。これは、一例として、図１のデータ格納構造１２２にすることが可能である。または、ＰＨＩ１３８は、データベースまたは別の従来のデータ構造の形式で別の場所に格納することが可能である。図３に示すように、ＰＨＩ１３８は、通常、病院のコンピュータシステムの一部となっている。病院は、暗号形式にてＰＨＩを格納可能である。システム１００は、ＰＨＩ１３８の不正アクセスを防止するためにデータ暗号化技術を使った動作が可能である。
ＰＨＩ１３８は、データ抽出および匿名化エージェント１８０によって処理される。典型的な実施例において、データ抽出および匿名化エージェント１８０はセキュリティサービスモジュール１２４の一部にすることができる。典型的な実施例において、データ抽出および匿名化エージェント１８０は、メモリに格納されるコンピュータ命令セットとして実行することが可能であり、また、セキュリティサービスモジュール１２４に関連付けられるコンピュータによって実行することが可能である（図１を参照）。匿名化プロセスには、匿名化された患者データそのものを患者を一意に識別するために使用できないように、患者を一意に識別することが可能な情報の除外または非関連化を必要とする。ＨＩＰＡＡ手順に従って、患者名、住所、保険情報、医療行為実施日などを匿名化エージェント１８０のデータ抽出により除外する。

データ抽出および匿名化エージェント１８０は、関連付けられた患者と匿名化された患者データを一致させる再識別プロセスに使用されるランダム鍵を生成する。簡単な例として、データ抽出および匿名化エージェント１８０は値１２３を有するランダム鍵を生成可能である。そのランダム鍵は、識別データに関連して鍵ファイル１８２に格納される。このランダム鍵は、必要な場合に以降の再識別を可能にするために匿名化患者データとも関連付けられる。当業者は、実際の業務におけるランダム鍵はより大きな桁数で成り、英数字データを含むことが可能であることを理解されるであろう。患者数の少ない小規模な医療機関は、例えば鍵として１６桁の英数字を利用し、大規模な医療機関では、例えば、３２桁の英数字を利用することが考えられる。鍵の特定の形式は、望ましいセキュリティレベルを実現するために最適化することが可能である。鍵のデータは鍵ファイル１８２に格納される。鍵ファイル１８２は、研究者またはその他の個人はアクセス不可能な安全なデータ格納領域である。再識別が必要になる場合、システム内の安全なプロセスは、再識別された患者医療記録データと患者識別データを再び関連付けするために、鍵ファイル１８２に自動的にアクセスする。
匿名化患者データは匿名化患者データベース１４０に格納される。当業者は理解されるであろうが、匿名化された患者データベースは、全ての識別データが除外されているため、ＨＩＰＡＡ規制事項の対象とはならない。このため、上記で説明したように、患者のスクリーニングのために研究者は匿名化患者データベースを利用可能である。
なお、ライセンスサーバーコンピュータ１２５内に格納された全てのデータは、従来の暗号技術を使って暗号形式で格納される。典型的な実施例において、ＡＥＳデータ暗号化は、匿名化データベース１４０、特定データセット１４２、特定のＰＨＩデータセット１４４、および鍵ファイル１８２に利用される。さらに、システム１００ではデータ暗号化またはデータセキュリティのその他の公知の形式を利用可能である。

患者照会エージェント１８４は、患者選択基準に一致する医療データ記録の匿名化患者データベース１４０を照会するために研究者またはその他の人によって利用されるプロセスである。例えば、患者照会エージェント１８４は、選択した年齢層の男性ＨＩＶ感染患者を選択するために匿名化患者データベース１４０を照会することが可能である。照会の結果は患者照会レポート１８６の形式で提供される。当業者は、患者照会レポート１８６は電子的にまたは紙媒体のレポートの形式で送ることが可能であることを理解されるであろう。システム１００はＮＩＣ１８６の特定の実施例によって制限されることはない。
患者照会エージェント１８４は、ライセンスサーバーコンピュータ１２５によって実行されるコンピュータソフトウェア命令の形式で容易に実施可能である。患者照会エージェント１８４の形式は、匿名化患者データベース１４０の形式に依存することが可能である。例えば、匿名化患者データベース１４０は、構造化照会言語（ＳＱＬ）データベースとして実行可能である。こうした実施例において、患者照会エージェント１８４は、ＳＱＬデータ照会の形式にすることが可能である。当業者は、データベースソフトウェアのその他の形式を匿名化患者データベース１４０および対応する患者照会エージェント１８４を実施するために利用可能であることを理解されるであろう。

図４から図９は、照会の作成および編集におけるシステム１００の動作を示す。図４では、特定の処置を受けた年齢６０歳から６４歳までの男性患者を識別するために新しい照会が作成される。当業者は、様々な医療処理が分類分けされ、図４に示す数値などの、数値によって識別可能であることを理解されるであろう。患者照会エージェント１８４は、匿名化患者データベース１４０に照会を提出する（図３を参照）。照会の結果は患者照会レポート１８６の形式で提供される。患者照会レポートの例を図５に示す。
この例に見られるように、三人の患者が選択基準に一致するものとして識別された。図５の照会結果セットはさらに、照会の結果として選択された患者に関係する医師の数および照会の一部として選択された患者に関連する診察回数に関する情報を提供する。こうした手順の照会および研究結果の一部として選択された患者に関する診察において実行される手順の数も、照会結果セットで提供される。照会の一部として選択された患者に関する診察における異なる診断の数および患者に提供された処方も含まれる。当業者は、さらなるデータによって、研究者は、研究調査または臨床実験における適合性について患者をスクリーニングすることが可能であることを理解されるであろう。図５に示される適切なアクションをクリックすることで、照会結果を表示可能である。

図６は、照会に基づいて匿名化患者データベース１４０からスクリーニングした選択された患者を示す典型的な表示である。患者ＩＤは以前に説明したランダム患者鍵である。
初めの結果に基づいて照会範囲を拡大または縮小することが可能である。図７は、患者の年齢層を５５歳から７５歳までに拡大した、患者照会範囲の拡大例を示す。拡大検索結果は、図８に示される新しい照会結果セットとして提供される。拡大された照会結果セットには、図９において選択された患者がリスト表示される。各照会の結果は便利な方法で格納可能である。典型的な実施例において、照会検索結果はデータ格納構造１２２などの安全な位置に格納可能である（図１、サーバー１０４を参照）。
こうした照会に基づいて、患者医療データ記録は匿名化患者データベース１４０から抽出され、臨床目的または研究目的で利用可能である。特定データセット作成エージェント１９０は、患者照会レポートの結果を利用して特定データセット１４２を構成する。つまり、研究者は、条件を満たす被験者グループを確立するために一つ以上の患者照会に基づいて多くの患者を選択する。特定データセット作成エージェントは、特定の匿名データセット１４２を作成するために患者照会選択基準を利用して患者医療データ記録をアセンブルする。システム１００は複数の研究者を受け入れ可能であり、各個人の研究のニーズに応じて複数の特定の匿名データセット１４２を作成可能である。
研究によっては、特定の患者識別データは不要となる。この実施例において、研究者は、必要な研究を実行するために特定の匿名データセット１４２を利用することが可能である。

患者の識別が必要な研究において、再識別エージェント１９２は、特定の匿名データセット１４２において選択および格納された患者を再識別するために鍵ファイル１８２にアクセスする。図９の例において、患者の照会に基づいて匿名化患者データベース１４０から７人の患者が選択された。再識別プロセスにおいて、無作為に選択された鍵に対応する患者ＩＤを鍵ファイル１８２にアクセスするために利用して、特定の匿名データセット１４２の匿名患者データ記録に患者識別データを再び関連付ける。このプロセスにより、特定のＰＨＩデータセット１４４の作成が行われる。研究者に付与された認証の種類に基づいて、特定の匿名データセット１４２および／または特定のＰＨＩデータセット１４４を利用することが可能である。
特定データセット１４２から１４４が作成されると、特定データセット（特定の匿名患者データセット１４２または特定のＰＨＩデータセット１４４）へのアクセスはログファイル１２６で記録され、管理レポート２０２の形式で利用可能となる。
サービスハブ２００は特定の匿名データセット１４２および特定のＰＨＩデータセット１４４、さらに特定のデータセット作成エージェント１９０および再識別エージェント１９２へのアクセスを制御する。以下により詳細に説明するように、システム１００によるアクションの前に、サービスハブ２００はリクエストされたアクションを承認するためにライセンスサーバーとして機能する。例えば、特定データセット１４２または特定のＰＨＩデータセット１４４へのアクセスには適切な承認が必要である。このため、サービスハブ２００は、患者医療データへのアクセスが必要になるたびに、認証プロセッサとして実行する。適切な承認および認証がされてない場合、患者医療データは提供されない。

図１０は、患者医療データ記録（ＰＨＩ）の必要なセキュリティを提供するためのシステム１００の動作を示す。プロセスには、研究者および医療機関（例：病院）の間のやりとりが含まれる。このやりとりは一般的に、研究者のコンピュータおよび医療機関のコンピュータ間の電子的な通信の形態である。
ステップ１において、研究者は、病院またはその他の研究機関への研究リクエストを行う。これらのリクエストは、一般的に、必要なデータの性質、データ要件の目的、政府によるサポート（研究助成金など）などに関する詳細な情報を含む。例えば、サポートドキュメントには、研究の内容、遵守すべき特定のプロトコル、および研究に参加する資格のある個人の試験対象患者基準および／または試験除外基準を含むことが可能である。この情報により、医療機関はＰＨＩ１３８へのアクセスのニーズを評価できる。
病院は、この後、研究リクエストを承認する必要がある。典型的な実施例において、承認プロセスは組織の審査委員会（ＩＲＢ）によって実行される。承認プロセスは人によるものであるが、システムはＩＲＢによって使用される添付ドキュメントを自動的に生成可能である。例えば、研究提案書または助成金のコピーは、研究リクエストに添付可能である。システム１００は、審査プロセスを単純化するためにサポートドキュメントのコピーを自動的に格納可能である。ＩＲＢによって承認されると、セキュリティ担当者またはその他の同等の権限を有する個人が、研究者が患者医療データ記録にアクセスすることができる条件を定めるライセンスを生成する。ステップ３において、ライセンスが発行され、ライセンスサーバーに格納される。典型的な実施例において、ライセンスサーバーはサービスハブ２００に組み込まれ（図３を参照）、これは、ライセンスサーバーコンピュータ１２５において実行されるものとして図１のセキュリティサービスモジュール１２４の一部にすることが可能である。ライセンスの条件について述べるドキュメントは紙媒体の形式で研究者に送付可能であるか、またはユーザーライセンス１０８としてクライアントコンピュータ１０６に電子的に送付可能である（図１を参照）。しかし、ユーザーライセンス１０８は患者医療データ記録へのアクセスは制御しない。ライセンスサーバー（例：図１のセキュリティサービスモジュール１２４）は、患者医療データ記録への全てのアクセスを制御する。
セキュリティ担当者がライセンスを発行し、ライセンスをライセンスサーバーに格納すると、ステップ４において承認通知も研究者に提供される。認証通知は、医療データの利用についての条件を述べることも可能である。認証通知を受信すると、研究者はユーザーアカウントへアクセスするためのパスワードを利用して、ライセンス規約の条件に従って医療記録へアクセスする。

ステップ５において、研究者はデータセットを開き、システム１００は安全なデータベースドライバを確立する。以下により詳細に説明するように、安全なデータベースドライバは患者医療データの受信および暗号化の機能を実行する。また、安全なデータベースドライバは、データの利用がライセンスの条件に適合するように、復号化した患者医療データに実行可能な処理の種類を制限する。
ステップ６において、安全なデータベースドライバは匿名化患者データベース１４０または特定データセット（匿名の特定データセット１４２または特定のＰＨＩデータセット１４４）から暗号化データを読み込む。上記で説明するように、全ての患者医療データ記録は暗号化の形式で格納される。解読プロセスの前に、安全なデータベースドライバは、ライセンスをチェックして、データへのアクセスが病院によって承認された特定のライセンスで認証されていることを保証するため、ステップ７において、ライセンスサーバにアクセスする。データアクセスが認証される場合、ライセンスサーバーはステップ８においてプライベート鍵を送信する。安全なデータベースドライバはプライベート鍵を利用してデータの解読を行い、ステップ９において解読されたデータを提供する。

典型的な実施例において、研究者の業務および安全なデータベースドライバの業務は、クライアントコンピュータ１０６によって実行される（図１を参照）。病院業務は、通常、サーバーコンピュータ１２０によって実行可能である。ライセンスサーバーはサーバーコンピュータ１２０の一部にすることができるか、または、セキュリティの向上のために別のコンピュータによって実行可能である。当業者は、この分散型コンピュータシステムにおいては図１０に示される様々なプロセスの実施例が可能になることを理解されるであろう。例えば、安全なデータベースドライバはクライアントコンピュータ１０６の一部とするか、または別なコンピュータによって実行することが可能である。従って、システム１００は、特定のコンピュータアーキテクチャまたはシステム１００内のコンピュータによって図１０で示される様々なプロセスの実施例に限定されない。
研究者は、ライセンス規約の条件に沿ってデータを利用可能である。特定の状況において、ライセンス規約はデータの閲覧のみを認証することができ、また、患者医療記録データのコピーまたは印刷をできないようにすることができる。また別の条件では、ライセンスサーバーは限定された期間（例：３０日）においてのみデータのアクセスを提供することが可能である。

ライセンス規約の条件の適切な実施を保証するために安全なデータベースドライバを利用可能である。一実施例において、安全なデータベースドライバは、オープンデータベース接続（ＯＤＢＣ）ドライバにすることができる。ＯＤＢＣは、当分野においてネットワーク上のデータベースにアクセスするために特定の用途のための共通言語を提供するインターフェースとして公知である。安全なデータベースドライバがＯＤＢＣドライバである場合、これはプリンタドライバおよびデータファイルのコピーを可能にするドライバを含むことができる。こうしたドライバを有効または無効にすることで、ライセンスサーバーは患者データの必要なセキュリティレベルを実現可能である。当業者はさらに、ＡｃｃｅｓｓまたはｄＢＡＳＥなどの様々なデータベースプログラムおよび構造化照会言語（ＳＱＬ）サーバーなどのデータベース管理システムはそれぞれ異なるドライバを有することを理解されるであろう。図１０の安全なデータベースドライバの実際の実施例は匿名化患者データベース１４０および特定データセット（特定の匿名化データセット１４２または特定のＰＨＩデータセット１４４）の特定の実施例による。ＯＤＢＣドライバは、印刷およびコピーを防止可能であり特定の機能を有効または有効にするためのシステムレベルのドライバである。こうしたドライバの動作は当分野において公知であるため、本明細書では説明しない。

図１１は、患者データセットの生成および患者データセットの利用におけるワークフローによる製品概要を示す。患者データセットの生成は、患者データセットのリクエストによって、２２０で開始される。患者が病院、診療施設、またはその他の組織を訪問すると、患者の治療に必要な医療データを収集するために認証が得られる。こうした医療データのアクセスおよび利用は厳密に制御される。部分権利放棄リクエストまたは研究準備リクエスト（ＲＰＲ）に対しては、ＩＲＢによって承認を与えることが可能である。場合によっては、病院またはその他の機関は、ＰＨＩ１３８の直接の利用を可能にするその他の機関とのビジネス取引規約またはデータ利用規約を有する場合がある。これらの関係機関は、ＨＩＰＡＡの規制またはその他の規制形態下において運営されている。例えば、放射線医学部署または研究サービス部署は医療機関内に配置することが可能であるが、別の企業形態として形成されている。ビジネス取引規約は、ＰＨＩ１３８を利用する別の組織を認証する。
必要な認証プロセス後に、匿名化患者データベース１４０がステップ２２４にて作成され、ここではＰＨＩ１３８がデータ抽出および匿名化エージェント１８０によって処理されて（図３参照）、上記のように匿名化患者データベース１４０を作成する。

患者データセットの利用も、２３０で研究リクエストが生成される図１１に示されている。研究リクエストには通常、リクエストされたデータの種類と研究のために得られたデータの利用とを示す研究規約を含む。研究リクエストのＩＲＢ承認のプロセスは、図１０を参照して以前に説明されている。ステップ２３２では、患者データセット利用認証を得ることが必要である。研究者は、ＩＲＢによって審査が行われる、臨床研究権利放棄リクエストの形式で患者データセット利用承認を提出する場合がある。なお、患者データセット生成（図３の特定データセット１４２の生成）には、ＩＲＢによる承認レベルが必要となる。患者の再識別が必要な患者データセット利用には、ＩＲＢの別の承認が必要となる。
上記で説明しているように、サービスハブ２００（図３を参照）は、患者データセット生成および利用に必要な多くのタスクの自動的な開始を実行する。例えば、利用の承認などのタスクの自動開始は、サービスハブ２００によって開始可能である。サービスハブ２００は、ＩＲＢによる承認のための臨床研究権利放棄リクエストを自動的に生成可能である。典型的な実施例において、サービスハブ２００は、ＨＩＰＡＡまたはその他の政府機関などで必要とされる（例：ＮＩＨフォーム）ものなどの標準的なフォームを利用可能であるか、または認証プロセスの一部として病院の特定のフォームおよびドキュメントをロードすることが可能である。自動承認、認証および確認のチェックも、サービスハブ２００で行われる。つまり、サービスハブ２００は、リクエスト（例：臨床研究権利放棄リクエスト）が以前に提出および承認されているかどうかを確認するためにチェックする。

患者を再識別する必要がある場合、特定の匿名データセットは、関連付けられた患者医療記録データと患者識別データを再関連付けするためにサービスハブ２００と再識別エージェント１９２（図３を参照）によって処理される。
さらに、ステップ２３２には、患者との連絡を作成するためのプロセスが示されている。患者が研究または臨床試験に参加することに関心があるかどうかを決定するために、プライマリーケアの医師によって、手紙またはその他の連絡方法によって患者との連絡を行うことが可能である。システム１００は、プライマリーケアの医師による手紙に添付するための必要なフォームを自動的に生成可能である。別の実施例において、システム１００は患者の参加の意思を判断するための患者への全ての連絡を自動的に生成可能である。患者が研究対象から除外される場合、その患者は、ＰＨＩデータへの以降のアクセスを防止するためにシステム１００においてリストに載せられる。しかし、一実施例において、患者の除外は、以前に得られた患者の医療データの利用を禁止するものではない。
ステップ２３４において、システム１００は患者訪問時間を生成可能である。尚、この時点より収集された一切の患者医療データはＨＩＰＡＡの対象となり、患者の承認によって収集される。匿名化患者データベース１４０へのアクセスは、これより通常、不要となる。しかし、匿名化患者データベース１４０または特定データセット１４２から１４４へのアクセスは、依然として、サービスハブ２００に制御される。このため、システム１００はデータセット生成およびデータセット利用のプロセスに対してワークフロー制御を実行しており、両方のプロセスの適切な規制への適合を実行する。

図１２Ａおよび１２Ｂは、共に、データセット生成のためのシステム１００の動作を示すフローチャートを形成する。プロセスは、患者データセットを作成するために病院業務によって３００で開始される。以前に述べたように、関連組織または取引先は、３０２で述べたように、病院との規約を結ぶことができる。決定３０４において、システム１００は、ビジネス取引先の関係が存在せず、決定３０４の結果がＮＯである場合にビジネス取引先の関係があるかどうかを決定し、決定３０６において、システム１００は特定の医療機関が研究準備リクエスト（ＲＰＲ）承認プロセスを許可するかどうか、または部分権利放棄承認を必要とするかどうかを決定するためにチェックを行う。ＲＰＲ承認プロセスが許可されない場合、決定３０６の結果はＮＯであり、３０８において、研究者またはリクエスト組織は部分権利放棄リクエストを提出する。以前に説明したように、部分権利放棄リクエストには、必要な患者データの種類、データの目的または利用などの詳細を含む。部分権利放棄リクエストは、さらに、政府サポート（例：研究助成金）などのドキュメンテーションを含む場合がある。病院のＩＲＢは、３１０において部分権利放棄リクエストを審査し、３１２においてＩＲＢ部分権利放棄を実行する。
決定３０６に戻り、ＲＰＲプロセスが病院ＩＲＢによって許可される場合、決定３０６の結果はＹＥＳである。この場合、ステップ３２０においてシステム１００はＲＰＲリクエストを生成する。ＲＰＲリクエストの生成後、システム１００はＲＰＲ検証を受信する。

既に述べたように、病院は、関係または連携先のビジネス取引先を有する場合がある。患者データへのアクセスをリクエストする組織がビジネス取引先である場合、決定３０４の結果はＹＥＳである。決定３３０において、システムは、ビジネス取引先の規約が存在するかどうかを決定する。ビジネス取引先の規約が存在しない場合、決定３３０の結果はＮＯであり、ステップ３３２においてシステム１００はビジネス取引先規約（ＢＡＣ）を生成する。必要な承認プロセス後、システム１００はステップ３３４においてＢＡＣ検証を受信する。ＢＡＣが既に存在する場合、決定３３０の結果はＹＥＳである。
必要な認証の検証の完了後（ステップ３１２におけるＩＲＢ部分権利放棄の受信、ステップ３２２におけるＲＰＲ検証の受信、決定３３０によるＢＡＣの存在の検証、またはステップ３３４におけるＢＡＣ検証の受信）、システム１００は、図１２Ｂに示す決定３４０に進み、リクエストがＰＨＩ１３８へのアクセスが必要かどうかを判断する（図２を参照）。ビジネス取引先が医療機関と連携関係にあるような、いくつかの設定において、ビジネス取引先は、ＰＨＩ１３８へのアクセスを得ることが可能である。別の設定において、ビジネス取引先がＰＨＩ１３８内へのアクセスを得られるようにすることが望ましい場合がある。ＰＨＩアクセスが必要または許可される場合、決定３４０の結果はＹＥＳであり、ステップ３４２においてシステム１００はＰＨＩ１３８にアクセスし、ＰＨＩデータベース３４３を生成する。ＰＧＩ患者データベース３４３はＰＨＩ１３８の全てまたは一部を構成する場合がある。ＰＨＩ患者データベース３４３はＨＩＰＡＡの規制事項の対象であることが理解されるであろう。このため、システム１００を、ＰＨＩ患者データベース３４３および本データベースにおけるデータの利用に対するアクセスを制御するために利用可能である。

ＰＨＩデータアクセスが必要でない場合、決定３４０の結果はＮＯである。この場合、システムは決定３４４に進み、リクエストに限定されたデータセットが含まれるかどうかを決定する。限定されたデータセットが必要でない場合、決定３４４の結果はＮＯである。その場合、システム１００はＰＨＩにアクセスしてデータ抽出および匿名化エージェント１８０（図３を参照）を利用可能であり、ステップ３４６において匿名化患者データベース１４０を生成する。匿名化患者データベース１４０を生成するためのプロセスの一部として、データ抽出および匿名化エージェント１８０も鍵ファイル１８２を生成する。
限定されたデータセット生成が必要である場合、決定３４４の結果はＹＥＳである。この場合、システム１００は決定３５０に進み、データ利用規約が既に生成されているかどうかを決定する。データ利用規約が生成されていない場合、決定３５０の結果はＮＯであり、ステップ３５２においてシステムはデータ利用規約を生成する。システム１００はステップ３５４においてデータ利用規約検証を受信する。
データ利用規約が以前に承認されている場合、決定３５０の結果はＹＥＳである。この場合、またはステップ３５４においてデータ利用規約検証が受信された場合、システム１００はステップ３５６において限定されたデータセットを生成する。限定されたデータセット３６０は、医療行為実施日、医療行為実施場所などの部分的な患者識別情報を含むことがある。限定されたデータセットは、一般的に、特定の患者識別データを含まない。しかし、限定されたデータセットは、いくつかの患者識別データを含んでいるため、ＨＩＰＡＡの規制ガイドライン対象となる。

図１２Ａおよび１２Ｂは、データセット生成のためのシステム１００のある考えられる動作を示すために図示されている。当業者は、必要なデータセットを生成するためにその他の技術が利用可能であることを理解されるであろう。例えば、図１２Ａから図１２Ｂは、ＰＨＩ１３８から直接特定のＰＨＩデータセット１４４を生成することを示す。こうした動作は、匿名化患者データへのアクセスが必要でない一つの病院環境において利用される場合に実施可能である。あるいは、システム１００は、図３に示すプロセスなどのプロセスを利用して、匿名化患者データベース１４０を生成する中間プロセスを実施可能である。様々な実施例において、ＨＩＰＡＡの規制制約および／またはその他のデータ利用制約をシステム１００により実行して、患者医療記録データの不正な利用を防止する。図１２Ａから図１２Ｂに示されるフローチャートにおいて、システム１００は、極秘の患者情報へのアクセス前に適切な規約および検証が行われるように、多数のチェックおよびバランスも含む。

図１３Ａおよび図１３Ｂは、患者の採用およびデータ利用のためのシステム１００のある動作を示すフローチャートである。開始４００において、製薬会社などの研究機関は、臨床または研究目的で患者データ記録にアクセスすることを希望する。ステップ４０２において、研究者からのリクエストにおいて試験情報またはその他の研究の詳細内容が提供される。リクエストが外部の組織によるものである場合、スタッフの医師または医療研究者などの内部のリクエスト者も、ステップ４０４のリクエストに含まれる。
ステップ４０６において、システム１００は、研究のための考えられる候補者を選択するために匿名化患者データベース１４０からのデータなどの患者データをスクリーニングする。ステップ４０８において、システム１００は、一例として、患者照会エージェント１８４（図３を参照）によって実行される患者照会に対する情報を生成および提示する。
決定４１０において、研究者は、研究プロセスを進めるかどうかを決定することが可能である。適した候補者がいないか、または適した候補者が必要な数だけいない場合には、決定はＮＯとなり、研究は停止する。プロセスが先に進む場合、決定４１０の結果はＹＥＳである。ステップ４１２において、患者照会の範囲を広げるまたは狭めるために、患者データを再スクリーンする必要がある場合がある。再スクリーニングが必要な場合、ステップ４０６からステップ４１０を一度以上繰り返すことが可能である。

さらなる再スクリーニングが不要な場合、システム１００は決定４２０に進み、患者データのさらなる利用のために規約が必要かどうかを決定する。例えば、ビジネス取引先はＰＨＩ１３８へのアクセスのための規約が不要である。規約が不要な場合、決定４２０の結果はＹＥＳであり、ステップ４２２においてシステム１００は研究規約を生成する。ステップ４２４において、システムは規約検証を受信する。規約が必要でない場合、決定４２０の結果はＮＯである。その場合、またはステップ４２４において規約検証を受信した場合、システム１００はステップ４２６において、図１３Ｂで示される臨床検査のためのＩＲＢリクエストの必要なドキュメントを生成する。以前に説明したように、システム１００は審査プロセスに必要なデータの大部分を自動的に生成可能である。例えば、患者の種類、データの利用などをリストするドキュメントを、ステップ４２８においてシステム１００によって自動的に生成可能である。さらに、システム１００は、審査プロセスにさらに利用可能な、政府のサポートなどのさらなるサポート文書などを提供可能である。ステップ４３０において病院の審査が実施され、決定４３２において承認が付与されるか、または拒否される。承認が受信されない場合、決定４３２の結果はＮＯであり、プロセスは決定４３４に進んで、その手順への修正によって必要な承認を得ることができるかどうかを決定する。修正ができない場合には、決定４３４の結果はＮＯであり、患者医療記録へのアクセスが拒否されて、プロセスは４３６で停止する。修正が可能な場合、決定４３４の結果はＹＥＳであり、システム１００は修正を分析可能な図１３Ａに示されるステップ４３８に進む。修正分析の結果により、ステップ４１２における患者データの再スクリーニング、およびステップ４０６からステップ４１０までの以降の繰り返しが必要になることがある。
病院ＩＲＢによって研究の承認が受信されていない場合、決定４３２の結果はＹＥＳであり、ステップ４５０においてシステム１００はＩＲＢ承認の認証を受信する。以前に説明しているように、病院ＩＲＢによる研究の承認によって、ライセンスサーバー（図１０を参照）に格納されているライセンスが生成される。ライセンスサーバーによって、患者データへのアクセスはライセンス規約の条件に厳格に沿うことが保証される。上記に説明するように、これらには、研究者に提供されるデータの種類、データの利用（例：データのコピーまたは印刷）および患者データへのアクセスに関する時間的な制約についての制約を含むことがある。

図１３Ａから図１３Ｂにおいて示されているような製薬臨床実験において、匿名化患者データベース１４０からスクリーニングプロセスにおいて選択された患者を再識別することが必要である。ステップ４５２において、サービスハブ２００（図３を参照）および再識別エージェント１９０は、患者を再識別するために特定の匿名化データセット１４２を処理する。
ステップ４５４において、選択基準との適切な一致を保証するために再識別された患者について第二のスクリーニングを実行可能である。ステップ４５６において、システム１００は患者への手紙を生成する。以前に説明したように、システム１００は必要な全ての承認フォームを自動的に生成可能であり、また、患者の署名のためにフォームを完了することが可能である。ステップ４５８において手紙が患者に送られ、研究に参加を希望する患者はステップ４６０においてコールセンターに連絡することが可能である。ＰＨＩ１３８に関してセキュリティをさらに高めるため、コールセンターは、通常、極秘の患者情報は取り扱わない。しかし、患者および患者への連絡が行われる特定の研究を識別するために患者名または識別番号（鍵ファイル１８２（図３）に格納される鍵とは無関係）をコールセンターに提供可能である。
ステップ４６６において、システム１００は患者インタビューのスケジュールを生成可能である。患者インタビューの一部として、ステップ４６８において最終的なスクリーニングを実施し、ステップ４７０において患者から適切な認証を得ることが必要になる場合がある。このため、システム１００は、極秘の患者データへのアクセスを制限し、全ての規制プロセスが実行されたことを保証するよう、さらなるチェックおよびバランスを実行する。

図１３Ａから図１３Ｂは、患者の採用のためにＰＨＩへのアクセスおよびその利用を制御するためのシステム１００の動作を示す。図１４Ａから図１４Ｂは、患者の研究目的でＰＨＩへのアクセスおよびその利用を制御するためにシステム１００が利用する同様のプロセスを示すフローチャートを形成する。図１３および図１４のフローチャートにおける主な違いは、研究には実際の患者の参加が不要である場合がある、ということである。患者医療情報へのアクセスのリクエストは、病院の研究リクエスト５００または内部リクエスト者（例：医療機関における研究者）からのものにすることができる。内部ガイドライン後に、内部研究者５０２は、ステップ５０８において患者データセットを直接スクリーニングすることが可能である。患者データセットのスクリーニングのリクエストが病院の研究５００によるものである場合、研究者からのリクエストには、患者データおよびその提案された利用のニーズに関して上記に説明する情報を含む。ステップ５０８において、システム１００は患者データセットをスクリーニングする。上記のように患者照会は、匿名化患者データベース１４０から候補の患者を選択するために利用可能である。ステップ５１０において、システムは、特定データセット１４２（図３を参照）の形態にすることが可能な情報を生成および提示する。決定５１２において、研究者は、先に進むために十分な患者数があるかどうかを決定する。患者の選択が不適切である場合、決定５１２の結果はＮＯであり、プロセスは５１４で停止する。患者照会の結果、選択された患者数が十分である場合、決定５１２の結果はＹＥＳである。

選択された患者数が十分である場合、プロセスは決定５１６に進み、規約が必要かどうかを決定する。以前に説明したように、ビジネス取引先からは規約は不要である。規約が必要な場合、決定５１６の結果はＹＥＳであり、ステップ５２０においてサービスハブ２００（図３を参照）は規約を生成する。規約の様々な面について既に説明しているため繰り返さない。ステップ５２２において、システム１００は規約の受信を検証する。
ステップ５２２において規約受信を検証後、または規約が不要な場合（決定５１６の結果がＮＯである場合）、システム１００は、図１４Ｂに示されている決定５２４に進み、患者医療情報および患者識別情報をリクエストする組織が対象の組織であるかどうかを決定する。医学研究手順に通じた人であれば、複数の病院が何度も臨床研究に参加することを理解されるであろう。臨床研究の場所となっている病院は、図１４Ａから図１４Ｂにおいて、「対象組織」と呼ばれる。臨床研究の場所となっていない医療機関（対象組織でない）に対して患者情報のリクエストがなされる場合、その病院が患者に関する情報を発表する前にその病院の内部審査機関の承認を得ることが必要である場合がある。決定５２４に関して、患者医療情報および患者識別情報が、対象組織以外の医療機関からリクエストされる場合、決定５２４の結果はＮＯであり、プロセスは、臨床研究のＩＲＢ権利放棄リクエストをドキュメントするためにステップ５２８に進む。以前説明したように、臨床試験権利放棄のリクエストは、病院ＩＲＢ５３０として図１４Ｂで示される個人または委員会によって承認される必要がある。ステップ５３２において、システムは権利放棄の受信を検証し、ステップ５３４において、上記の事柄において患者を再識別する。あるいは、情報のリクエストが研究を実施する医療機関（対象組織）から行われる場合、患者医療データおよび患者識別データの利用の承認は既に付与されている。この場合、決定５２４の結果はＹＥＳであり、システム１００は直接ステップ５３４に進み、匿名化患者データベース１４０への以前の照会の結果として選択された患者を再識別する。

いくつかの研究では、患者の再識別後に第二のスクリーニングが必要な場合がある。その場合、システム１００はステップ５３８において第二のスクリーニングを許可する。これは、上記で説明した事柄において実行可能なさらなる患者照会の形態にすることが可能である。二度目のスクリーニング後、決定５４０において患者連絡先が必要かどうかを決定可能である。患者連絡先が不要な場合、決定５４０の結果はＮＯであり、システム１００は特定のＰＨＩデータセット１４４からリクエストされたＰＨＩを生成および提示する（図３を参照）。
患者の連絡先が必要な場合、決定５４０の結果はＹＥＳであり、ステップ５４６においてシステム１００は患者がＰＨＩデータへ認証されたアクセス権があるかどうかを決定する。アクセスが承認されていない場合、決定５４６の結果はＮＯであり、ステップ５４８において、サービスハブ２００は以前に述べたように必要な患者への手紙を生成し、システム１００はさらに、全ての必要な承認フォームを生成して患者の署名のためにフォームを完了する。認証の手紙が５５０において患者に送られる。研究に参加を希望する患者はステップ５５４においてコールセンターに連絡可能である。または、患者は５５４においてコールセンターに連絡して、研究対象外としてもらうことが可能である。研究から除外された患者は、上記のように進む。ステップ５５６において、システム１００は患者のインタビューをスケジュールする。患者へのインタビュー後、または患者の参加が既に認証されている場合（決定５４６の結果がＹＥＳである場合）、ステップ５５８において最終的な患者スクリーニングが実施され、ステップ５６０において適切な認証および同意が患者から得られる。

システム１００は、一つの病院環境における単純な実施例について以前に説明されている。しかし、システム１００は複数の病院を利用して容易に実施可能である。複数の病院のためのシステム１００の実施例は図１５に示されており、ここで、病院Ａから病院Ｄはそれぞれ匿名化患者データベース１４０を有しており、各病院は、併合された匿名化患者データベース１５０に対してその匿名化患者データベースを提供可能である。患者照会エージェント１８４は、患者照会レポート１８６を生成するために一つの匿名化患者データベース１４０へのレポートに関して以前説明したように動作可能である。このように、スクリーニングの目的でより多くの患者を含むよう匿名化患者データを有利に併合することが可能である。異なる病院は異なる形式でＰＨＩを格納している可能性があるため、正規化エージェントを利用して、併合された匿名化患者データベース１５０に均一性を与えるためにデータを修正するために利用可能である。図１５の例において、正規化エージェント１８８Ｂは、匿名化患者データベース１４０Ｂおよび併合された匿名化患者データベース１５０の間の形式またはデータ構造を変更するために匿名化患者データベース１４０Ｂからのデータを変換する。一例として、ある病院は、それぞれ「Ｍ」および「Ｆ」によって男性および女性の患者をリストするが、別の病院は、それぞれ「１」および「２」を使用して男性患者と女性患者をリストする場合がある。正規化エージェントは、併合された匿名化患者データベース１５０に格納されているデータを均一にするために必要な変更を加えるために、病院の匿名化患者データベースを審査するよう構成可能である。正規化エージェント１８８Ｄは、匿名化患者データベース１４０Ｄにおいて同様の動作を行う。

当業者は図１５に示されるシステムにおいて様々な実施例を利用可能であることを理解されるであろう。例えば、図１５は患者照会エージェント１８４Ａおよび患者照会エージェント１８４Ｃを示す。上記で説明したように、患者照会エージェント１８４などのエージェントは、通常、メモリに格納されプロセッサで実行されるコンピュータ命令セットとして実行される。図１５に示される例において、患者照会エージェント１８４Ａは中央位置から病院Ａに送信されて、病院Ａにおける匿名化患者データベース１４０を分析することが可能である。このプロセスにより、併合された匿名化患者データベース１５０に対して匿名化患者データ記録の全てを送る必要がなくなる。この実施例において、患者照会エージェント１８４は匿名化患者データベース１４０Ａから患者データ記録を抽出し、患者照会レポート１８６の形式でフィルタされた結果を提示する。患者照会エージェント１８４Ａは、さらに、匿名化患者データベース１４０Ａからのデータを利用して、特定データセット１４２（図３を参照）へデータを送信可能である。
同様に、患者照会エージェント１８４Ｃは、研究者により作成される照会に含まれる患者選択基準と患者データ記録を一致させるために匿名化患者データベース１４０Ｃを直接照会する。患者照会エージェント１８４Ａおよび患者照会エージェント１８４Ｃなどの患者照会エージェントの送信により、全てのデータを共有しないことを希望する病院に対してより高いセキュリティが提供可能である。図１５に示される例において、病院Ｂは、匿名化患者データベース１４０Ｂから併合された匿名化患者データベース１５０へ全ての匿名化患者データを共有してもよい。同時に、病院Ａによって課されるさらなる制約により、こうした完全な共有が防止される。併合された患者データベース１５０に全ての記録を送信せずに、患者照会エージェント１８４Ａの病院Ａへの送信によって、匿名化患者データベース１４０Ａの直接の照会が可能になる。

システム１００の別の実施例において、患者照会エージェント１８４Ｃなどの患者照会エージェントを病院に送信し、概略的な情報のみを提供することが可能である。この例において、病院Ｃは、概略的なデータを除く匿名化された患者データの送信を防止するためにさらなる制約を課すことが可能である。例えば、概略的なデータには、糖尿病患者でありＭｅｔｆｏｒｍｉｎの投薬を受けている４０歳から６５歳までの男女の数を含むことが可能である。この例における概略的なデータは、特定の患者についての情報（たとえ特定できない形式であっても）を提供することはない。病院Ｃに課される制限に沿って、患者照会エージェント１８４Ｃは病院Ｃに送信され、匿名化患者データベース１４０Ｃに照会を行う。しかし、患者照会エージェント１８４Ｃは、病院Ｃによって課される制約に沿って概略的なデータを送信するのみである。このため、複数病院環境において、各病院では、その独自の規制プロセスが満たされていること、および、そのポリシーに厳格に適合しているだけでなく全ての政府の規制要件に適合して、データのみが送信されることを保証することが可能である。

発明の特定の実施例を説明のためにここで記載したが、上記から、本発明の精神および範囲から逸脱しない限り様々な変更を実施できることが理解されるであろう。例えば、本明細書は、病院という環境を用いた数多くの例について記載している。しかし、当業者は、病院、診療機関、研究所、大学、製薬会社、政府組織などのあらゆる医療機関は、各医療機関にとってＰＨＩのシステムおよび制御により恩恵を受けられることを理解されるであろう。従って、本発明は、病院という環境に制限されない。
上記で説明した実施例は、様々なその他のコンポーネント内における、またはこれと関連する異なるコンポーネントについて説明している。これらの説明されたアーキテクチャは単なる一例のものであり、実際には、同じ機能性を実現する多くの他のアーキテクチャを実施可能であることを理解されたい。概念的な意味において、同じ機能性を実現するコンポーネントの組み合わせは、望ましい機能性が実現されるよう効率的に「関連付けられる」。このため、特定の機能性を実現するために組み合わせられる本明細書におけるいずれかの二つのコンポーネントは、アーキテクチャまたは中間コンポーネントとは関係なく望ましい機能性が実現されるように、互いに「関連付けられている」とみなすことができる。同様に、このように関連付けられている二つのコンポーネントは、望ましい機能性を実現するために、互いに「動作可能に接続され」または「動作可能に結合され」ているとみなすこともできる。

本発明の特定の実施例が図示および説明されているが、当業者には、本明細書の教示に基づいて、本発明およびその広範な内容から逸脱しない限り、変更および修正を実行することが可能であることが明らかであるため、添付された請求項は、本発明の真の精神および範囲以内としてこうした変更および修正の全てをその範囲に含有するものとする。さらに、本発明は、添付の請求項によってのみ定義されることを理解されたい。当業者には、一般的に、本明細書および特に添付の請求項（例：添付の請求項の本文）で使用される用語は、「オープンな」用語として意図されている（例：「を含む」という用語は「これを含むが限定されない」と解釈されるべきであり、「を有する」は「少なくともこれを含む」と解釈されるべきであり、「を含む」という用語は「これを含むが限定されない」と解釈されるべきである等）。さらに、当業者には、特定の数の導入された請求項の列挙が意図されている場合、こうした意図は請求項において明示的に列挙され、こうした列挙がない場合にはかかる意図は存在しないことを理解されるであろう。例えば、便宜上、以下の添付の請求項は、請求項の列挙を導入するために「少なくとも一つの」および「一つ以上の」という導入句を使用する場合がある。しかし、こうした導入句の利用は、同じ請求項に「一つ以上の」または「少なくとも一つの」という導入句または「ａ」または「ａｎ」などの不定冠詞が含まれる場合でも（例：「ａ」および／または「ａｎ」は通常、「少なくとも一つの」または「一つ以上の」を意味するよう解釈されるべきである）、また請求項の列挙を導入するために使われる不定冠詞の利用に同じことが言える場合でも、不定冠詞「ａ」または「ａｎ」による請求項の列挙の導入が、こうした一つの列挙のみを含む発明に対してこうした導入された請求項を含む特定の請求項を制限するという意味を含むと解釈すべきではない。さらに特定の数の導入された請求項の列挙が明示的に列挙されている場合でも、当業者は、こうした列挙は少なくとも列挙された数を意味するよう通常は解釈されるべきであることを理解されるであろう（例：他の修正語句なしの「二つの列挙」の単なる列挙は、通常、少なくとも二つの列挙、または二つ以上の列挙を意味する）。

本発明の教示によるコンピュータネットワーク実施例の機能ブロック図である。本教示によって実施されるシステムにおける情報の流れの概要を示すフローチャートである。一つの病院環境におけるデータの流れを示すフローチャートである。新しい照会を作成するためのシステムの動作を示す。図４の照会の結果として生成される結果セットの例を示す。図５の結果セットのさらなる詳細を示す。拡大された照会の例を示す。図７の拡張された照会の結果セットを示す。拡張された照会の結果セットによって提供されるさらなるデータを示す。本発明のシステムによって実施されるセキュリティ手順を示す状態図である。ワークフローによる製品概要である。データセット生成のためのシステムの動作を示すフローチャートを形成する。データセット生成のためのシステムの動作を示すフローチャートを形成する。患者採用データ利用のためのシステムの動作を示すフローチャートを形成する。患者採用データ利用のためのシステムの動作を示すフローチャートを形成する。患者の研究データ利用の動作を示すフローチャートを形成する。患者の研究データ利用の動作を示すフローチャートを形成する。複数の病院環境における患者照会プロセスを示すフローチャートである。

Claims

患者識別データおよび関連する患者医療データを格納する保護された保健情報（ＰＨＩ）格納構造へのアクセスを制御するシステムであって、
患者識別データとは非関連の方式で患者医療データを格納する匿名データ格納構造と、
非関連の患者識別データおよび患者医療データを相関づけるデータを含む鍵ファイルと、
アクセスリクエストを受信し、所定のデータアクセス認証と受信したアクセスリクエストを比較し、受信したアクセスリクエストが所定のデータアクセス認証に適合する場合に患者医療データへのアクセスを許可する、データアクセスリクエストを処理するための認証コントローラとを備えるシステム。
患者識別データおよび関連する患者医療データを処理することで患者医療データおよび患者識別データを非関連にすることで非関連の患者医療データを生成する匿名化エージェントをさらに含む、請求項１に記載のシステム。
匿名化エージェントは患者識別データおよび関連する患者医療データを関連付けるための鍵を生成することで非関連の患者医療データの患者識別データとの以降の再関連付けを許可する、請求項２に記載のシステム。
匿名化エージェントは鍵ファイルに格納されるランダム鍵を生成する、請求項３に記載のシステム。
鍵ファイルのデータを処理して患者医療データおよび患者識別データを再び関連付けることで再び識別された患者医療データを生成する再識別エージェントをさらに含み、受信したアクセスリクエストは患者識別データおよび患者医療データの関連付けを必要とする、請求項１に記載のシステム。
再識別された患者医療データのための受信したアクセスリクエストは認証プロセッサによって処理され、所定のデータアクセス認証によって患者医療データおよび患者識別データの再関連付けが可能になる場合にのみ、再識別エージェントは患者医療データおよび患者識別データを再関連付けするために鍵ファイルのデータを処理する、請求項５に記載のシステム。
ユーザーが選択可能な患者選択基準を有し、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するために患者医療データを照会するよう構成されている患者照会エージェントをさらに含む、請求項１に記載のシステム。
患者照会エージェントは、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するために匿名データ格納構造の非関連の患者医療データを照会するよう構成されている、請求項７に記載のシステム。
ユーザーが選択可能な患者選択基準に合致する特徴を有する患者から選択した患者医療データは匿名の照会データ格納構造に格納される、請求項８に記載のシステム。
受信したアクセスリクエストが所定のデータアクセス認証に適合する場合にのみ、患者照会エージェントは認証プロセッサと動作可能に通信を行い、患者医療データを照会する、請求項７に記載のシステム。
ユーザーが選択可能な患者選択基準に合致する特徴を有する患者から選択した患者医療データは照会データ格納構造に格納される、請求項７に記載のシステム。
受信したアクセスリクエストは必要なデータの種類およびデータの利用に関連付けられた目的を示し、認証プロセッサは匿名の患者医療データまたは患者識別データに関連付けられた患者医療データへのアクセスを許可するために審査委員会の認証に基づいて認証入力を受け入れる、請求項１に記載のシステム。
患者医療データへのアクセスログを記録するためのロギングシステムをさらに含む、請求項１に記載のシステム。
認証プロセッサはアクセスが許可された患者医療データの以降の利用を制御する、請求項１に記載のシステム。
認証プロセッサは所定の期間に限定してアクセスが許可された患者医療データの以降の利用を許可する、請求項１４に記載のシステム。
認証プロセッサはアクセスが許可された患者医療データの印刷を禁止する、請求項１４に記載のシステム。
認証プロセッサはアクセスが許可された患者医療データのコピーを禁止する、請求項１４に記載のシステム。
各医療機関の患者識別データおよび関連する患者医療データを格納する複数の各医療機関における保護された保健情報（ＰＨＩ）格納構造へのアクセスを制御するシステムであって、
患者識別データとは非関連の方式で患者医療データを格納する匿名データ格納構造と、
非関連の患者識別データおよび患者医療データを相関づけるデータを含む鍵ファイルと、
アクセスリクエストを受信し、所定のデータアクセス認証と受信したアクセスリクエストを比較し、受信したアクセスリクエストが所定のデータアクセス認証に適合する場合に患者医療データへのアクセスを許可する、データアクセスリクエストを処理するための認証コントローラとを備えるシステム。
匿名データ格納構造は複数の医療機関のうち二つ以上からの患者医療データを格納するよう構成されている、請求項１８に記載のシステム。
匿名データ格納構造は複数の医療機関の二つ以上からの患者医療データを格納するよう構成されている単一のデータ格納構造である、請求項１９に記載のシステム。
患者識別データおよび関連する患者医療データを処理して患者医療データおよび患者識別データを非関連にすることで非関連の患者医療データを生成する匿名化エージェントをさらに含む、請求項１８に記載のシステム。
単一の匿名化エージェントは複数の医療機関の二つ以上のＰＨＩ格納構造において患者識別データと関連する患者医療データを処理する、請求項２１に記載のシステム。
単一の匿名化エージェントは複数の医療機関の選択された一つのＰＨＩ格納構造で患者識別データと関連する患者医療データを処理するために複数の医療機関の選択された一つに送られる、請求項２１に記載のシステム。
複数の医療機関の選択されたものに送られる匿名化エージェントは複数の医療機関の選択された一つのＰＨＩ格納構造の患者識別データと関連する患者医療データを処理し、匿名データ格納構造に概略的な患者医療データしか提供しない、請求項２３に記載のシステム。
匿名化エージェントは患者識別データおよび関連する患者医療データを関連づけるための鍵ファイルに格納されている鍵を生成することで非関連の患者医療データの患者識別データとの以降の再度の関連付けを許可する、請求項２１に記載のシステム。
受信したアクセスリクエストは患者識別データおよび患者医療データの関連付けを必要とし、鍵ファイルのデータを処理するための再識別エージェントを含み患者医療データおよび患者識別データを再び関連付けることで再び識別された患者医療データを生成する、請求項１８に記載のシステム。
再識別された患者医療データのための受信したアクセスリクエストは認証プロセッサによって処理され、所定のデータアクセス認証によって患者医療データおよび患者識別データの再関連付けが可能になる場合にのみ、再識別エージェントは患者医療データおよび患者識別データを再関連付けするために鍵ファイルのデータを処理する、請求項２６に記載のシステム。
ユーザーが選択可能な患者選択基準を有し、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するために患者医療データを照会するよう構成されている患者照会エージェントをさらに含む、請求項１８に記載のシステム。
患者照会エージェントは、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するために匿名データ格納構造の非関連の患者医療データを照会するよう構成されている、請求項２８に記載のシステム。
匿名データ格納構造は複数の医療機関の二つ以上からの患者医療データを格納するよう構成されており、患者照会エージェントはユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するために匿名データ格納構造において非関連の患者医療データを照会するよう構成されている、請求項２８に記載のシステム。
受信したアクセスリクエストが所定のデータアクセス認証に適合する場合にのみ、患者照会エージェントは認証プロセッサと動作可能に通信を行い、患者医療データを照会する、請求項２８に記載のシステム。
受信したアクセスリクエストは必要なデータの種類およびデータの利用に関連付けられた目的を示し、認証プロセッサは匿名の患者医療データまたは患者識別データに関連付けられた患者医療データへのアクセスを許可するために審査委員会の認証に基づいて認証入力を受け入れる、請求項１８に記載のシステム。
患者医療データへのアクセスログを記録するためのロギングシステムをさらに含む、請求項１８に記載のシステム。
認証プロセッサはアクセスが許可された患者医療データの以降の利用を制御する、請求項１８に記載のシステム。
認証プロセッサは所定の期間に限定してアクセスが許可された患者医療データの以降の利用を許可する、請求項３４に記載のシステム。
認証プロセッサはアクセスが許可された患者医療データの印刷を禁止する、請求項３４に記載のシステム。
認証プロセッサはアクセスが許可された患者医療データのコピーを禁止する、請求項３４に記載のシステム。
患者識別データおよび関連する患者医療データを格納するために保護された保健情報（ＰＨＩ）格納構造に格納された患者医療データへのアクセスを制御する方法であって、
患者識別データから患者医療データを非関連にするように匿名データ構造で患者医療データを格納するステップと、
非関連の患者識別データおよび患者医療データを相関づけるデータを格納するステップと、
患者医療データにアクセスするためのアクセスリクエストを受信するステップと、
所定のデータアクセス認証と受信したアクセスリクエストを比較するステップと、
受信したアクセスリクエストが所定のデータアクセス認証に適合する場合に患者医療データへのアクセスを許可するステップとを含む方法。
患者識別データおよび関連する患者医療データを処理することで患者医療データおよび患者識別データを非関連にすることで非関連の患者医療データを生成するステップをさらに含む、請求項３８に記載の方法。
患者識別データおよび関連する患者医療データを関連付けるための鍵を生成することで患者識別データと非関連の患者医療データとの以降の再度の関連付けを許可するステップをさらに含み、非関連の患者識別データと患者医療データを相関付けるデータの格納には鍵を格納するステップを含む、請求項３９に記載の方法。
受信したアクセスリクエストは患者識別データおよび患者医療データの関連付けを必要とし、方法には、非関連の患者識別データと患者医療データを相関付ける格納されたデータを処理するステップをさらに含むことで、患者医療データおよび患者識別データを再び関連付けして再識別された患者医療データを生成する、請求項３８に記載の方法。
ユーザーが選択可能な患者選択基準を有する患者照会を受信するステップと、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するための患者医療データの照会ステップとをさらに含む、請求項３８に記載の方法。
患者照会には、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するために匿名データ格納構造の非関連の患者医療データを照会するステップを含む、請求項４２に記載の方法。
受信したアクセスリクエストは必要なデータの種類およびデータの利用に関連付けられた目的を示し、匿名の患者医療データまたは患者識別データに関連付けられた患者医療データへのアクセスを許可するために審査委員会の認証に基づいて認証入力を受け入れるステップをさらに含む、請求項３８に記載の方法。
患者医療データへのアクセスログの記録ステップをさらに含む、請求項３８に記載の方法。
アクセスが許可された患者医療データの以降の利用を制御するステップをさらに含む、請求項３８に記載の方法。
以降の利用の制御には所定の期間に限定してアクセスが許可された患者医療データの以降の利用を許可するステップをさらに含む、請求項４６に記載のシステム。
以降の利用の制御には、アクセスが許可された患者医療データの印刷を禁止するステップを含む、請求項４６に記載の方法。
以降の利用の制御には、アクセスが許可された患者医療データのコピーを禁止するステップを含む、請求項４６に記載の方法。
患者識別データおよび関連する患者医療データを格納するために複数の各医療機関の保護された保健情報（ＰＨＩ）格納構造に格納された患者医療データへのアクセスを制御する方法であって、
患者識別データから患者医療データを非関連にするように匿名データ構造で患者医療データを格納するステップと、
非関連の患者識別データおよび患者医療データを相関づけるデータを格納するステップと、
患者医療データにアクセスするためのアクセスリクエストを受信するステップと、
所定のデータアクセス認証と受信したアクセスリクエストを比較するステップと、
受信したアクセスリクエストが所定のデータアクセス認証に適合する場合に患者医療データへのアクセスを許可するステップとを含む方法。
匿名データ格納構造の患者医療データの格納には複数の医療機関の二つ以上からの患者医療データを格納するステップを含む、請求項５０に記載の方法。
患者識別データおよび関連する患者医療データを処理して患者医療データおよび患者識別データを非関連にすることで非関連の患者医療データを生成するステップをさらに含む、請求項５０に記載の方法。
患者識別データおよび関連する患者医療データの処理には、複数の医療機関の選択された一つのＰＨＩ格納構造の患者識別データと関連する患者医療データを処理するステップと、匿名データ格納構造に概略的な患者医療データだけを提供するステップとを含む、請求項５２に記載のシステム。
患者識別データおよび関連する患者医療データを関連付けるための鍵を生成することで患者識別データと非関連の患者医療データとの以降の再度の関連付けを許可するステップをさらに含み、非関連の患者識別データと患者医療データを相関付けるデータの格納には鍵を格納するステップを含む、請求項５２に記載の方法。
受信したアクセスリクエストは患者識別データおよび患者医療データの関連付けを必要とし、方法には、非関連の患者識別データと患者医療データを相関付ける格納されたデータを処理するステップをさらに含むことで、患者医療データおよび患者識別データを再び関連付けして再識別された患者医療データを生成する、請求項５０に記載の方法。
ユーザーが選択可能な患者選択基準を有する患者照会を受信するステップと、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するための患者医療データの照会ステップとをさらに含む、請求項５０に記載の方法。
患者照会には、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するために匿名データ格納構造の非関連の患者医療データを照会するステップを含む、請求項５０に記載の方法。
匿名データ格納構造は複数の医療機関の二つ以上からの患者医療データを格納するよう構成されており、患者照会エージェントはユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するために匿名データ格納構造において非関連の患者医療データを照会するよう構成されている、請求項５０に記載の方法。
受信したアクセスリクエストは必要なデータの種類およびデータの利用に関連付けられた目的を示し、匿名の患者医療データまたは患者識別データに関連付けられた患者医療データへのアクセスを許可するために審査委員会の認証に基づいて認証入力を受け入れるステップをさらに含む、請求項５０に記載の方法。
患者医療データへのアクセスログの記録ステップをさらに含む、請求項５０に記載の方法。
アクセスが許可された患者医療データの以降の利用を制御するステップをさらに含む、請求項５０に記載の方法。
コンピュータが、
患者識別データから患者医療データを非関連にするよう匿名データ構造で患者医療データを格納し、
非関連の患者識別データおよび患者医療データを相関づけるデータを格納し、
患者医療データにアクセスするためのアクセスリクエストを受信し、
所定のデータアクセス認証と受信したアクセスリクエストを比較し、
受信したアクセスリクエストが所定のデータアクセス認証に適合する場合に患者医療データへのアクセスを許可するようにすることで、患者識別データおよび関連する患者医療データを格納するために保護された保健情報（ＰＨＩ）格納構造に格納された患者医療データへのアクセスを制御するためのコンピュータで読み込み可能な媒体。
コンピュータに、患者識別データおよび関連する患者医療データを処理することで患者医療データおよび患者識別データを非関連にすることで非関連の患者医療データを生成させる命令をさらに含む、請求項６２に記載のコンピュータで読み込み可能な媒体。
コンピュータに患者識別データおよび関連する患者医療データを関連づけるための鍵を生成させることで患者識別データと非関連の患者医療データとの以降の再度の関連付けを許可する命令をさらに含み、非関連の患者識別データおよび患者医療データを相関づけるデータの格納には鍵を格納するステップを含む、請求項６３に記載のコンピュータで読み込み可能な媒体。
受信したアクセスリクエストは患者識別データおよび患者医療データの関連付けを必要とする請求項６２に記載のコンピュータで読み込み可能な媒体であって、該コンピュータで読み込み可能な媒体には、コンピュータに非関連の患者識別データと患者医療データを相関付ける格納されたデータを処理させる命令をさらに含むことで、患者医療データおよび患者識別データを再び関連付けして再識別された患者医療データを生成する、媒体。
コンピュータにユーザーが選択可能な患者選択基準を有する患者照会を受信させ、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するための患者医療データを照会させるためのコンピュータ命令をさらに含む、請求項６２に記載のコンピュータで読み込み可能な媒体。
患者照会には、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するために匿名データ格納構造の非関連の患者医療データを照会するステップを含む、請求項６６に記載のコンピュータで読み込み可能な媒体。
受信したアクセスリクエストは必要なデータの種類およびデータの利用に関連付けられた目的を示し、匿名の患者医療データまたは患者識別データに関連付けられた患者医療データへのアクセスを許可するためにコンピュータに審査委員会の認証に基づいて認証入力を受け入れさせるコンピュータ命令をさらに含む、請求項６２に記載のコンピュータで読み込み可能な媒体。
患者医療データへのアクセスログをコンピュータに記録させるためのコンピュータ命令をさらに含む、請求項６２に記載のコンピュータで読み込み可能な媒体。
アクセスが許可されている患者医療データの以降の利用をコンピュータに制御させるためのコンピュータ命令をさらに含む、請求項６２に記載のコンピュータで読み込み可能な媒体。
以降の利用の制御には所定の期間に限定してアクセスが許可される患者医療データの以降の利用を許可するステップをさらに含む、請求項７０に記載のコンピュータで読み込み可能な媒体。
以降の利用の制御には、アクセスが許可される患者医療データの印刷を禁止するステップを含む、請求項７０に記載のコンピュータで読み込み可能な媒体。
以降の利用の制御には、アクセスが許可される患者医療データのコピーを禁止するステップを含む、請求項７０に記載のコンピュータで読み込み可能な媒体。
請求項６２に記載のコンピュータで読み込み可能な媒体であって、患者の医療データは複数の各医療機関において保護された保健情報（ＰＨＩ）格納構造に格納されており、コンピュータに匿名データ格納構造の患者医療データを格納するようにしたコンピュータ命令には複数の医療機関の二つ以上から患者医療データを格納するステップを含む、媒体。
コンピュータに、患者識別データおよび関連する患者医療データを処理させることで患者医療データおよび患者識別データを非関連にすることで非関連の患者医療データを生成させるコンピュータ命令をさらに含む、請求項７４に記載のコンピュータで読み込み可能な媒体。
患者識別データおよび関連する患者医療データの処理には、複数の医療機関の選択された一つのＰＨＩ格納構造の患者識別データと関連する患者医療データを処理するステップと、匿名データ格納構造に対して概略的な患者医療データだけを提供するステップとを含む、請求項７５に記載のコンピュータで読み込み可能な媒体。
匿名データ格納構造は複数の医療機関の二つ以上からの患者医療データを格納するよう構成されており、コンピュータに、ユーザーが選択可能な患者選択基準に合致する特徴を有する患者を選択するために匿名データ格納構造の非関連の患者医療データを照会させるためのコンピュータ命令をさらに含む、請求項７４に記載のコンピュータで読み込み可能な媒体。
患者医療データへのアクセスログをコンピュータに記録させるためのコンピュータ命令をさらに含む、請求項７４に記載のコンピュータで読み込み可能な媒体。
アクセスが許可されている患者医療データの以降の利用をコンピュータに制御させるためのコンピュータ命令をさらに含む、請求項７４に記載のコンピュータで読み込み可能な媒体。