(57)【要約】長期のデータベースの非識別型の患者ヘルスケア・データ記録をアセンブリするシステム及び方法を提供する。本システム及び方法は、患者プライバシを保証する間、複数のデータ供給者と共通のデータベース装置上で実現することができる。データ供給者ロケーションでは、データ記録の患者識別属性は、コネ標準化した形式で置かれ、共通のデータベース装置に送信する前に、1対の暗号鍵を用いて、二倍暗号化される。１対の暗号鍵は、データ供給者に対して特定の鍵と、共有のデータベース装置に対して特定の鍵を含む。マルチ・ソース型のデータ記録が、共通のデータベース暗号化のみ有するように、共通のデータベース装置では、データ供給者に対して特定の暗号化は取り除かれる。患者の識別情報に直接アクセスすることなく、暗号化したデータ記録は、ダミーラベル又はタグが割り当てられ、これにより、データベースで、データ記録を長期にリンクすることができる。タグは、タグの参照データベースにより、選択組の暗号化したデータ属性の値についての統計的なマッチングに基づいて割り当てられ、暗号化したデータ属性値に関連付けられる。
2007536833.tif 000002
【特許請求の範囲】
【請求項１】
個々の患者のヘルスケア・トランザクション・データ記録から長期リンク化データベースをアセンブリする方法であって、
データ供給者ロケーションで、
(a) 患者識別属性、及び非識別属性を有するデータ記録を取得するステップと、
(b) 中央装置(LDF)に対して特定の第１の暗号鍵を用いて、前記データ記録の前記患者識別属性を暗号化するステップと、
(c) 前記データ供給者ロケーションに対して特定の第2の暗号鍵で、前記ステップ（b）において暗号化した前記データ記録の前記患者識別属性を暗号化するステップと、
前記LDFで、
(d) 前記ステップ(b)及び(c)において暗号化した前記データ記録を受信するステップと、
(e) 前記患者識別属性が、前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(b)の暗号化のみ保持するように、前記受信したデータ記録を部分的に解読するステップと、
(f) 前記データ記録に対して LDF識別子(ID)を割り当てるように属性マッチング・アルゴリズムを用いるステップと、
(g) 前記暗号化したデータ記録のID毎にリンクし、長期リンク化データベースを形成するステップとを含む方法。
【請求項２】
第3のLDF暗号鍵を用いて、前記属性を暗号化するステップを更に含む請求項1に記載の方法。
【請求項３】
前記暗号化したデータ記録のデータ・フィールドを標準化したコンテンツ形式にするように、前記取得したデータ記録を処理するステップを更に含む請求項1に記載の方法。
【請求項４】
前記データ記録において前記患者識別属性と前記非識別属性とを分離するステップを更に含み、前記ステップ(c)及び(d)が、前記分離した患者識別属性を暗号化するステップを更に含む請求項1に記載の方法。
【請求項５】
前記データ記録において、前記暗号化した患者識別属性を、前記分離した非識別属性とマージするステップを更に含む請求項2に記載の方法。
【請求項６】
前記ステップ(d)が、前記データ記録において、前記暗号化した患者識別属性と前記非識別属性とを分離するように、前記受信したデータ記録を処理するステップを更に含み、前記ステップ(c)が、前記分離した患者識別属性を部分的に解読するステップを更に含む請求項1に記載の方法。
【請求項７】
前記ステップ(e)が、前記データ記録において、前記部分的に解読した患者識別属性を、前記分離した非識別属性とマージするステップを更に含む請求項6に記載の方法。
【請求項８】
前記属性マッチング・アルゴリズムが、選択組のデータ属性の統計的なマッチングに基づいて、IDを、暗号化したデータ記録に割り当てる請求項1に記載の方法。
【請求項９】
前記選択組のデータ属性が、患者の生年月日、カードホルダ識別、記録番号、郵便番号、名、姓、住所、及び業界標準の患者識別子のうち少なくとも1つを含む請求項8に記載の方法。
【請求項１０】
前記属性マッチング・アルゴリズムが、ID及び対応する属性のクロスデータベースを参照することにより、暗号化したデータ記録に、IDを割り当てる請求項１に記載の方法。
【請求項１１】
前記ステップ(d)及びステップ(e)が、前記データ記録の患者識別属性情報に対する不正アクセスを制限する安全な環境で実行される請求項1に記載の方法。
【請求項１２】
複数のデータ供給者から得られた個々の患者ヘルスケア・トランザクション・データ記録を、長期にリンクするシステムであって、
データ供給者ロケーションで、
患者識別属性と非識別属性を有するデータ記録を取得するように構成され、
中央装置(LDF)に対して特定の第１の暗号鍵、及び、前記データ供給者に対して特定の第2の暗号鍵により、前記データ記録の前記患者識別属性を二重暗号化するように構成される第１のコンポーネントと、
LDFで、
前記複数のデータ供給者から二重暗号化したデータ記録を受信するように構成され、
前記患者識別属性が、前記LDFに対して特定の前記第1の暗号鍵による暗号化を保持するように、前記受信したデータ記録を部分的に解読するように構成され、
暗号化の追加層を実行するように構成される第2のコンポーネントと、
第3のコンポーネントであり、
前記暗号化したデータ記録において、属性をマッチングすることにより、LDF識別子（ID）を、前記暗号化したデータ記録に割り当てるように構成され、
長期のデータベースを形成するために、前記暗号化したデータ記録のID毎にリンクするように構成される前記第3のコンポーネントと、
を備えるシステム。
【請求項１３】
前記第1のコンポーネントが、前記データ記録において、前記患者識別属性と前記非識別属性とを分離し、前記分離した患者識別属性を暗号化するように更に構成される請求項12に記載のシステム。
【請求項１４】
前記第1のコンポーネントが、前記データ記録において、前記暗号化した患者識別属性を、前記非識別属性とマージするように更に構成される請求項13に記載のシステム。
【請求項１５】
前記第1のコンポーネントが、前記暗号化したデータ記録のデータ・フィールドを標準書式にするように、前記取得したデータ記録を処理するように更に構成される請求項12に記載のシステム。
【請求項１６】
前記第2のコンポーネントが、前記受信したデータ記録において、前記暗号化した患者識別属性と前記非識別属性とを分離し、前記分離した患者識別属性を部分的に解読するように更に構成される請求項12に記載のシステム。
【請求項１７】
前記第2のコンポーネントが、前記データ記録において、前記部分的に解読した患者識別属性を、前記非識別属性とマージするように更に構成される請求項12に記載のシステム。
【請求項１８】
前記第3のコンポーネントが、LDF識別子（ID）を、選択組のデータ属性の統計的なマッチングに基づいて、前記暗号化したデータ記録に割り当てるように更に構成される請求項12に記載のシステム。
【請求項１９】
前記選択組のデータ属性が、患者の生年月日、カードホルダ識別、記録番号、郵便番号、名、姓、住所、及び業界標準の患者識別子のうち少なくとも1つを含む請求項18に記載のシステム。
【請求項２０】
前記第3のコンポーネントが、LI 及び対応する属性のクロスデータベースを参照することにより、LDF識別子（LI）を、前記暗号化したデータ記録に割り当てるように更に構成される請求項12に記載のシステム。
【請求項２１】
前記第2のコンポーネントが、前記データ記録の患者識別属性情報に対する不正アクセスを制限する安全な環境で動作するように構成される請求項12に記載のシステム。
【請求項２２】
システムの各機能が、ソフトウェア・アプリケーションを用いて実現される請求項12のシステム。
【請求項２３】
個々の患者ヘルスケア・トランザクション・データ記録からアセンブリされる長期リンク化データベースであって、
患者識別属性が、患者のプライバシを保護するために暗号化されるマルチ・ソース型のデータ記録を備え、各暗号化したデータ記録が、選択組のデータ属性の統計的なマッチングに基づく識別子を、参照する組の値で割り当てられ、前記データ記録が、前記割り当てられた識別子によりリンクされる長期リンク化データベース。
【請求項２４】
前記選択組のデータ属性が、患者の生年月日、カードホルダ識別、記録番号、郵便番号、名、姓、住所、及び業界標準の患者識別子のうち少なくとも1つを含む請求項23に記載の長期リンク化データベース。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願）
この出願は、2004年5月5日に出願された米国特許仮出願第60/568,455号明細書、2004年5月17日の出願された米国特許仮出願第60/572,161号明細書、2004年5月17日の出願された米国特許仮出願第60/571,962号明細書、2004年5月17日に出願された米国特許仮出願第60/572,064号明細書、及び、2004年5月17日に出願された米国特許仮出願第60/572,264号明細書の利益を主張するものであり、これら全ての仮出願の内容は、本出願の明細書の内容に取り込まれる。
【０００２】
本発明は、個々において、個人の健康情報又はデータについての管理に関する。特に、本発明は、個人のプライバシを保持する方法に係る、長期のデータベースにおいて、そのようなデータのアセンブリと使用に関する。
【背景技術】
【０００３】
患者の健康記録の電子データベース化は、商業利用及び非商業的利用の双方に役立つものである。例えば、長期（寿命期間）の患者記録データベースは、疫学的に、又は、時間傾向、因果関係、又は、ある母集団における健康事象の発生率の分析としての母集団ベースの研究として用いられる。長期のデータベースでアセンブリされた患者記録は、複数のソースから、様々な形式で収集させられるようである。患者健康記録の明白なソースは、現代においては健康保険業界であり、その業界は、医療サービスプロバイダに対して保険金を与えるために、電子通信型の患者のトランザクション記録を広く頼りにしている。医療サービスプロバイダ（例えば、薬局、病院または診療所）、又は、医療サービスプロバイダのエージェント（例えば、データクリアリングハウス、プロセッサ又はベンダー）は、個別に特定された患者トランザクション記録を、補償金のために保険業界に供給する。患者トランザクション記録は、個人情報データのフィールド、即ち属性に加えて、例えば、診断、処方箋、治療内容又は治療結果などの他の情報を含むことができる。複数のソースから取得したそのような情報は、長期の研究に対して貴重となる場合がある。しかしながら、個人のプライバシを保護するために、長期のデータベース装置に統合される患者記録は、“匿名型”、即ち“非識別型”とされることが重要である。 
【０００４】
データ供給者、即ちデータ・ソースは、転送前に患者プライバシを保護するために、患者トランザクション記録の個人情報データのフィールド、即ち属性（例えば、名前、社会保険番号、住所、郵便番号など）を除去又は暗号化できる。患者プライバシを保護するために、ある個人情報データのフィールドの暗号化又は標準化は、現在、法令と政令によって規制されている。個人の民事的権利に対する関心事は、電子取引における、患者記録の収集についての政府規制と個人的な健康データの使用に向けられている。例えば、「医療保険の相互運用性と説明責任に関する法律（1996年）（HIPAA法）」の下で発行された規制は、個人的な健康情報のセキュリティ及び秘匿性をセーフガードするように、緻密な規則を含む。HIPAA規制は、保健保険プラン、ヘルスケア・クリアリングハウス、及び、ある財政用及び管理用のトランザクション（例えば、登録、支払い、及び適正検査）を電子的に行うヘルスケア・プロバイダなどの実体をカバーしている。(例えば、http://www.hhs.gov/ocrhxipaa 参照)。2004年7月15日に出願された、共通に発明され、共に譲渡された、“Data Privacy management Systems and Methods”と題される特許出願第10/892,021号明細書（代理人整理No.AP35879）は、本出願の明細書の内容に取り込まれるものであるが、政令のHIPAA規制又は他のプライバシ規則の組に従って標準化された形式における、個人的な健康情報を収集及び使用するシステム及び方法について、記載されている。
【０００５】
患者のプライバシの侵害についてのリスクを更に最小化するために、長期のデータベースを構成するように用いられる患者記録から、全ての患者識別情報を分離又は除去することが望ましいと考えられる。しかしながら、患者識別情報をデータ記録から分離し、患者識別情報を完全に匿名にすることは、格納されたデータ記録が、患者毎にリンク可能でなければならない長期のデータベースの構成と互換性がなくなる場合がある。
【０００６】
ここでは、長期のデータベースにおける様々なデータ・ソースからの患者記録を“匿名型”又は“非識別型”を統合することに対して考慮を払っている。尚、データ・ソースには、種々の暗号技術を用いることができ、暗号技術は、長期リンクの患者記録を、正確に防止又は禁止にすることができる。個々の患者についてのプライバシの保護を確実にし、業界のプライバシ規制に従う態様で、マルチ・ソース型の長期データを統合する効率的な処理について、特に関心が向けられている。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、長期のデータベースでの非識別型の患者データ記録をアセンブリするシステム及び方法を提供する。本発明の目的は、個々の暗号技術及びデータ記録の内容で変化するデータ・ソースに対して対策するために、マルチ・ソースの患者データ記録を暗号化する方法を提供することである。本発明によるシステム及び方法は、複数のデータ・ソース又は供給源から受信した非識別型のデータ記録が、市場調査用又は他の分析のために長期のデータベースに組み合わせられることを許容するものである。本発明によるシステム及び方法は、患者プライバシに関する業界及び他の規制と整合した患者プライバシを確実にする。
【課題を解決するための手段】
【０００８】
長期のデータベースをアセンブリするシステム例は、連続的であり、統合的な3つのコンポーネントを含むことができる。 第１のコンポーネントは、複数のデータ・ソース又はベンダーのロケーションの各々で実現させることができ、データ・ソースによって生成又は収集された、患者又はヘルスケアのデータ記録について、重要となるデータ暗号化を実行するように構成される。データ記録内で患者を特定する属性は、本発明による方法で暗号化及び符号化される。患者を特定する属性を、2つ以上の暗号鍵を用いて暗号化することができる。各属性は、データ・ソース・ロケーションにあるのみである長期の暗号鍵、及び、暗号処理に関わる各データ・ソースに対して固有の、第2のデータ・ソース用の暗号鍵を用いて暗号化される。本発明による方法は、暗号化する前に、整合した暗号化を確実にするために入力データを標準化する。暗号化したデータ記録は、共通の“中央装置”に確実に送信され、中央装置は、長期のデータベースについてのアセンブリのために、複数のデータ・ソース又はベンダーから、データ記録を受信することができる。
【０００９】
前述のシステム例における第2のコンポーネントは、共通の中央装置で実現させることができ、複数のデータ・ソース又はベンダーのロケーションから、暗号化されたデータ記録を受信する。様々なデータ・ソース又はベンダーは、長期の暗号鍵とデータ・ソースを特定する暗号鍵とを別々に用いて送信されたデータ記録を暗号化することができる。従って、システム例における第2のコンポーネントは、受信したデータ記録を標準の暗号形式で更に処理するように構成される。本発明による方法は、長期に暗号化したレベルに対して、データ・ソースを特定する暗号についての部分的な復号化を含み、データの使用前に、“中央装置”の暗号鍵（例えば、トークン・ベースの鍵）を用いて、暗号化保護の追加層をデータに追加するように、受信したデータ記録の再暗号化を更に含むことができる。データ記録は、第2のコンポーネントで、データ記録が長期に（第3のシステムのコンポーネントで）リンクされるのを許容する共通の暗号形式で処理される。第2のコンポーネントの処理は、処理されたデータ記録の属性、即ちフィールドが、患者を特定する元の属性値を明確にする如何なる状況下でも解読されないように、非可逆となるように設計される。
【００１０】
システム例における第3の（即ち、最後の）コンポーネントは、中央装置、又は、他の適切な長期のデータベース装置で実現させることができ、長期のデータベース内で、処理したデータ記録をアセンブリする。このコンポーネントは、架空の（即ち、疑似の）“長期患者”の好適な識別子を決定するために、処理したデータに対してマッチング・アルゴリズム（データ・ソースの特定に従って構成させることができる）を適用することができ、好適な識別子を、（第2のコンポーネントで処理された、）暗号化したデータ記録をラベル付けする、即ちタグ付けするように用いることができる。例えば、2つのコンポーネントで暗号化したデータ記録を、“長期の患者識別子(LI)”を有する特有の非識別型の中央装置で、関連付け、又はタグ付けすることができる。好適な統計的マッチング・アルゴリズム（カスタマイズ可能である）は、暗号化したデータ記録で、LIを関連付けるように用いられる。それぞれタグ付けされたデータ記録LIを長期にリンクするように、LIを用いることができる。即ち、LI毎に、長期のデータベースをアセンブリする。
【００１１】
本発明によるシステム及び方法によってアセンブリされた長期のデータベースは、個々の患者プライバシを保護しながら、マルチ・ソース型の長期のデータ分析として要求される製薬及びヘルスケアの業界で扱うことができる。本発明のデータ暗号化処理は、複数の暗号鍵を使用することにより、データ・ソース（供給者又はベンダー）が、HIPAA規制又は他のプライバシ要求の信用を低下させるおそれなく、長期のデータベース装置に対して患者レベルのデータを与えることを可能とする。更に、本発明による2つのコンポーネントの暗号化処理は、ユーザ又は侵入者に対して、暗号化したデータ記録における如何なる個々の患者の個性についても発見する能力を制限させる。従って、長期のデータベース装置は、個々の患者プライバシを侵害するリスクなく、複数の、且つ、独立したデータ・ソースから受信したデータ記録を安全に分析できる。
【００１２】
本発明の更なる特徴、本質、及び様々な利点は、図面、及び以下の詳細な説明から明らかになる。
【００１３】
本発明について、詳細に図を参照して説明するが、説明に役立つ実施例に関して図示している。
【発明を実施するための最良の形態】
【００１４】
本発明は、患者のデータ記録を統合する解決策を提供するものであり、患者のデータ記録は、長期のデータベースへの複数のソースから取得できる。患者のデータ記録は、少なくとも統計的に、個々の患者ごとに、如何なる個々の患者のプライバシも侵害する如何なるリスクもなく、長期のデータベースへと統合される。
【００１５】
一解決例は、複数の暗号鍵を使用することにより、患者のデータ記録が、少なくとも二度暗号化される、複数のデータを処理するステップに係るものである。本解決例は、データ処理システムで実現することができ、データ処理システムは、1つ以上の実体 （例えば、データ・ソースベンダー供給者(“DS”)、長期のデータベース装置(“LDF”)、第三者の実現パートナー(“IP”)、及び、暗号鍵の管理者に係る、又は関するものである。IP（暗号鍵の管理者として機能することもできる）を、LDFコンポーネントサイトで動作するように認可することができる。
【００１６】
本解決例の第1のステップで、各DSは、LDFに対して安全な送信をするためのデータ記録を作成する。DSは、その患者のデータ記録を第1の“匿名型”の形式に変換するように、患者のデータ記録内で選択したデータのフィールド（例えば、患者の特定する属性及び／又は他の標準の属性データについてのフィールド）を標準化し、暗号化する。各DSは、選択したデータ・フィールドを二重に暗号化するために、2つの鍵（即ち、ベンダーの特定鍵と特定のLDFに関連付けされた共通・長期鍵）を使用する。二重に暗号化したデータ記録は、LDFコンポーネントサイトに送信され、ここで、IPは、更にデータ記録を処理できる。受信したデータ記録は、LDFコンポーネントサイトで、第2の“匿名型”の形式へと更に処理される。暗号化されていない元の患者識別情報に戻すことなく、データ記録が患者ごとに (統計的に) リンクされることを可能とするように、第2の“匿名型”の形式は構成される。このために、DSから受信した患者記録における、二重に暗号化したデータのフィールドは、ベンダーの特定鍵を用いて部分的に解読される（ここで、二重に暗号化されたデータのフィールドは、共通・長期鍵によって暗号化はまだ、保持している）。長期のデータベースでの使用のために、新たに単独で暗号化した（即ち、共通の長期鍵で暗号化した）データのフィールドを更に作成するように、第3の鍵（例えば、トークン・ベースの鍵）を用いることができる。長期の識別子（ID）、又は、LDFに対して内部にあることのダミーラベルについては、データ記録をタグ付けするように用いることができ、これにより、暗号化されていない元の患者識別情報の知識なく、長期のデータベース内のID毎に、データ記録をリンクさせることができる。統計的なマッチング・アルゴリズムは、IDをデータ記録と関連付けるように使用される。
【００１７】
図1は、一実施例のデータ処理システム100のコンポーネント110a、110b及び110cを示す。各コンポーネントは、長期のデータベース装置130で、長期のデータベース200に、マルチ・ソースの患者のデータ記録をアセンブリするように用いることができる。
【００１８】
コンポーネント110aは、1つ以上のデータ・ソース・ロケーション116（例えば、データ供給者又はベンダー、薬局、病院など）でのデータ処理機能に関連する。これらデータ・ソース・ロケーションで、生の転送データ記録 (例えば、患者の処方箋記録) が、LDFへの送信のために作成される。その生のデータ記録は、患者を特定する属性112と、特定情報ではない他の属性（例えば、を含むことができる。コンポーネント110は、生のデータ記録において、患者を特定する属性を2重暗号化及び符号化に用いられる、2重鍵暗号アプリケーションを含んでいる。この2重暗号化は、長期の装置の暗号鍵“K1”と、データ供給者の個人の暗号鍵“K2 ”を用いて実行させることができる。その結果として生じる2重暗号化されたデータの属性112eは、好適なマージ・アプリケーションによってデータ記録内の対応する処方箋の属性114でマージされる（例えば、アプリケーション118b）。マージしたデータ記録は、2重暗号化されたデータ記録としてデータファイル121内にアセンブリされ、或いは他の好適な形式として長期のデータベース装置（例えば、LDF130）に安全に送信するためにアセンブリされる。
【００１９】
コンポーネント110b及び110cは、LDF130でのデータ処理機能に関する。コンポーネント110bは、データ記録からデータ・ソースの特定の特徴を除去するように構成される。これは、例えば、個々のデータ・ソースから受信したデータ記録の2重暗号化したデータの属性についての部分的な復号化により達成させることができる。この目的のために、好適な復号化アプリケーション122は、コンポーネント110bに含まれている。LDF130で受信したデータファイル121内のデータ記録は、まず、2重暗号化したデータの属性112eと処方箋の属性114とを切り離すために、分離処理アプリケーション126で処理される。次に、2重暗号化したデータの属性112eは、復号化アプリケーション122で処理される。復号化アプリケーション122は、2重暗号化したデータの属性112eに対して部分的に解読するために、公開鍵K2’ （データ供給者の個人の暗号鍵K2に対して相補性である）を用いることができ、これにより、単独で暗号化されたデータの属性112aを元に戻すことができる。単独で暗号化されたデータ記録は、長期の装置の暗号鍵K1によって、単独で暗号化される生のデータ記録の属性に対応している。また、コンポーネント110bは、特定のLDF130に対して特定の態様で、この単独で暗号化されたデータ属性112aを更に暗号化するように、別の暗号化アプリケーション124を含むことができる。例えば、暗号化アプリケーション124は、データ属性112aを暗号化して、LDFで暗号化した属性112fを生成するように、トークン・ベースの鍵K3を用いることができる。
【００２０】
LDF130のコンポーネント110cは、データ取得プロセス115aを含み、データ取得プロセス115aは、処方箋の属性処方箋の属性114を、2つのカテゴリである、(1)１組の標準化した処方箋の属性114a、及び、(2)１組のマッチングの属性114bへと分けるように機能する。その後者の属性は、リンク処理アプリケーション115bにおいて用いることができ、リンク処理アプリケーション115bによって、暗号化したデータ記録は、固有の長期の患者識別子（ID）と関連付けられ、又は、割り当てられる。また、コンポーネント110cは、長期のIDの相互参照表又はデータベース113を含むことができ、その割り当て処理の間、リンク処理アプリケーション115bによって、その相互参照データベース113を参照することができる。相互参照データベース113は、ID、及び対応するデータの属性値の組についてのリストを含むことができる。リンク処理アプリケーション115bは、好適なマッチング・アルゴリズムを含むことができ、マッチング・アルゴリズムは、固有の長期患者識別子(ID)を、参照する属性値を有する暗号化したデータ記録において属性をマッチングすることによって、統計的な、及び／又は、決定論的なベースで、暗号化したデータ記録に割り当てる。 代表的なマッチング・アルゴリズムは、共同発明、且つ、共同に係属する、同日に出願された米国特許第______号明細書に記載されている。割り当てられたIDは、IDデータベース117に保存できる。コンポーネント110cは、マージ処理アプリケーション119を更に含むことができ、マージ処理アプリケーション119は、割り当てられたID 117で標準化した処方箋記録114aを、長期のデータベース200にマージする。
【００２１】
リンク処理アプリケーション115bの確率論的な、及び／又は、決定論的な、マッチング・アルゴリズムは、長期の患者識別子（ID）の有効な割り当てのために、少数組の暗号化した患者識別のデータ属性のみを利用するように構成されている。一実現例では、長期の患者識別子（ID）の割り当ては、数個の暗号化した患者識別のデータ属性で選択組に基づくことができる。（例えば、患者の生年月日、カードホルダ識別、記録番号、郵便番号、名、姓、住所、及び、業界標準患者識別子などの8つの属性のみまでとできる。例えば、業界標準患者識別子は、処方薬プログラムに関する国際標準化機構（National Council for Prescription Drug Programs :NCPDP）規格に従う患者識別子とできる)。
【００２２】
データ記録の選択組のデータ属性は、まず、好適な標準化アルゴリズムも用い、標準形式にすることができ、次に、例えば、データベース又はファイル112に保存できる。選択組のデータ属性は、２鍵（two-key）・暗号化アプリケーション118aを用いて二度、暗号化される。２鍵・暗号化アプリケーション118aは、長期の暗号鍵K1と、ベンダーの特定の暗号鍵K2を含む。特に、その選択組のデータ属性の各々は、データ・ソース116で、独立して二度、暗号化される。まず、普遍的な長期の暗号鍵K1（暗号鍵K1は、データ供給者側でのみ利用可能であり、LDF130で利用可能ではない）は、データ属性を暗号化するのに用いられる。次に、ベンダーの特定の鍵K2は、再びデータ属性を暗号化するのに用いられる。データ記録内の二度暗号化されたデータ属性及び処方箋の属性の組は、好適な電子ファイル（例えば、ファイル121）で、LDF 130に送信される。
【００２３】
LDF130は、第三者の実装パートナー(IP)で、取得処理、暗号化処理、送信処理を規定及び実装して、データ供給者、即ちデータ・ソースを補助するように構成させることができる。 更に、LDF130は、送信されたデータファイル122を受信し、処理するための安全処理環境133を含むことができる。安全処理環境133は、LDFに関するパーソネル、即ち処理で、患者プライバシの侵害の危険を最小化するように、又は、避けるように、第三者のIPに対してのみアクセス可能とできる。安全処理環境133は、データをLDF 130に供給するのに関わる全てのデータ・ソースに対応する、ベンダーの特定の鍵K2−K2’のリストを含むことができる。これらの鍵は、IPによって、二度暗号化したデータ属性の組を部分的に解読するように用いることができる。また、安全処理環境133は、各データ・ソース116に対してアカウントし、又は、監査記録するように、好適なカウント処理を含むことができる。全てのアクティビティについて追跡可能な監査記録を与えるように、同様なカウント処理をコンポーネントの110b及び110cで行うことができる。追跡可能な監査記録は、生じうるデータ品質問題を識別して、解決することに役立たせることができる。
【００２４】
別の態様として、本発明については、データ処理システム100のソフトウェア実装の観点から説明できる。様々なソフトウェア・アプリケーションを、データ処理システム100のコンポーネント110a〜110cにおいて、種々のデータ処理（例えば、処理118a、118b、122 124、126、115a、115b、及び119）を行うように利用できる。前処理部（LDF、データ供給者及びLDFの環境の双方において用いられる暗号鍵の生成及び管理に対して責任ある鍵管理者、及び、実行環境のインストール／メンテナンスに対して責任を有することができる実装パートナー(IP)）によって個々に又は選択的に、それら処理を動作させることができるように、そのソフトウェア・アプリケーションを構成させることができる。IP及び鍵管理人は、同一の処理部とできる。
【００２５】
特定のプライベート・イニシアティブ・プライバシ規格、政府規制、及び、業界標準のデータ形式要求に適合するように、別々のソフトウェア・アプリケーションを構成させることができる。別々のソフトウェア・アプリケーション（以下、総括的に“ソフトウェア・システム”と称する）は、データ処理システム100において、統合した態様で動作する。
【００２６】
ソフトウェア・システム及びそのアプリケーションは、形式化したデータ記録で長期のデータベースを構成するように、本発明の二重暗号化／マッチングの解決策における様々なステージのステップで、様々な機能を提供する。認証ユーザは、そのような機能を呼び出し、又は、動作させることができる（例えば、１つ以上の4つの処理部（LDF、DS、IP、及び／又は鍵管理人））。 
【００２７】
その暗号化アプリケーションによるソフトウェア・システムは、複数のデータ供給者が、LDFに、業界で許容される安全な暗号化形式での患者属性を有するデータ記録を供給することを可能にする。LDFが、暗号化した属性を、マルチ・ソース型のトランザクション記録を個々にリンクすることを可能とする形式にすることができる。暗号化した属性の形式は、LDFが、個々の識別を学習する必要がないようなものである。しかしながら、その形式は、個々の識別を学習する必要性無く、好適な統計的マッチングアプリケーションを用いて、LDFがマルチ・ソース型のトランザクション記録を個々に連結することを許容する。また、ソフトウェア・システムは、他の機能を実行する他のアプリケーション又はルーチンを含むことができ、例えば、データの標準化、データ属性の再形式化又は取得、及び、監査カウント又は監査報告などである。
【００２８】
ソフトウェア・システムは、少なくともLDF暗号化アプリケーション及びDS暗号化アプリケーション、及び少なくとも1つの鍵管理（IP）アプリケーションを含む。DS暗号化アプリケーションは、データ記録又は属性を取得し、必要であればデータ属性のHIPAA化を含むデータ属性を標準化し、患者の識別情報を二重暗号化するように構成される1つ以上のルーチンを含む。DS暗号化アプリケーションは、暗号鍵を生成し、暗号鍵を暗号化するためのルーチンを含むことができる。 暗号鍵のために、安全なストレージが設けられる。また、DS暗号化アプリケーションは、監査し、監査のデータ管理（ファイルに書かれている監査データ）及び監査報告を安全にするルーチンを含むことができる。更に、DS暗号化アプリケーションは、参照ファイルの統合（HOPAA、郵便番号／名前の標準化ファイルなど）のためのルーチンを含むことができる。
【００２９】
LDF暗号化アプリケーションは、データ供給者鍵及びLDF暗号鍵のそれぞれを用いて、データ供給者の暗号化した属性について、復号及び暗号化を許容する。暗号鍵のために、安全なストレージが設けられる。また、LDFアプリケーションは、監査し、監査のデータ管理（ファイルに書かれている監査データ）及び監査報告を安全にするルーチンを含むことができる。安全な監査データ管理は、処理部（LDFなど）が、監査ファイルが変更されていないことを示す、又は検証することを、好適に可能とする。安全な監査データ管理は、監査ファイル又は監査報告の変更及び／又はタンパー化を検出する能力を含むことができる。好適なハードウェア・セキュリティ・モジュール（例えば、nCipherHSM）でLDFアプリケーションを配置することができる。
【００３０】
鍵管理アプリケーションは、暗号鍵の生成するルーチン、暗号鍵の安全なストレージの解決策のための解決策、及び、データ供給者、LDF及びIPに対して暗号鍵を配布する処理を含むことができる。図3は、暗号鍵の形式の一例と特性を示す（例えば、K1、K2及びK3）。
【００３１】
ソフトウェア・システムの一実現例において、3つの処理部（DS、LDF及びIP）で、各々によって、又は、外部の技術サポートの助けによって、ソフトウェア・アプリケーション及び暗号鍵をインストールできる。特に、様々なハードウェア又はソフトウェア環境、又はプラットホームで動作するように、ソフトウェア・システムを構成させることができる。そのようなアプリケーションにおける報告ルーチンは、カスタマイズされたGUIを含むことができる。そのようなアプリケーションは、受信した入力データが、欠損したデータ・フィールド（空白、スペース、ゼロ）を有している場合、空白を埋めるためのサブルーチン（例えば、属性のデータ・フィールドに“B”キャラクタを書き込む）を含むことができる。同様に、そのようなアプリケーションは、データ・フィールドが無効である場合（例えば、図6参照）、マークすることができる（例えば、属性の内容に“I”を書き込む）。
【００３２】
LDFが、LDF暗号化アプリケーション・ソフト、暗号鍵、又は何らかの暗号化ハードウェアに対してアクセスさせないように、ソフトウェア・システムを構成させることができる。ソフトウェア・システムの好適な実現例では、安全なハードウェア・プラットホームで、LDF暗号化アプリケーションと暗号鍵を保持し、動作させることができ、安全なハードウェア・プラットホームは、スマートカード又は他の制限されたアクセス・メカニズムを用いた場合のみ、アクセスすることができる。好適なハードウェア・プラットホームは、nCipher社のnShieldハードウェア・セキュリティーモジュール(nCipher’s nShield Hardware Security Module)とできる。
【００３３】
ソフトウェア・システムの好適な一実施例では、様々な入力ファイル形式を受け入れるのに十分な一般化するように構成させることができる。例えば、あるデータ供給者は、別ファイルとして、患者識別属性及び非識別のトランザクション属性を送信するように選択でき、一方では、他のデータ供給者が、単一ファイルで、その双方を共に送信するようにできる。いずれかの形式で動作するように、暗号化アプリケーションを構成させることができる。データ供給者及びLDFによって、個々のデータ供給者のファイル形式を、予め承認させておくことができる。データ供給者からデータの受け取り次第、LDFは、受信した暗号化した属性を、LDFデータ暗号化アプリケーションの標準形式へとマップすることができる。一般のデータ供給者は、通常、同一の記録にトランザクションデータ及び患者データを含むデータファイルを提供するので、暗号化及び非暗号化のデータ属性の分離／マージは、必要ではなく、ほとんどの場合、任意のものとできる。暗号化される必要があるデータ属性を取得及び暗号化し、次にデータ記録の終端で他の非暗号化トランザクションの属性に追加するように、ソフトウェア・システムアプリケーションを構成させることができる。
【００３４】
ソフトウェア・システムの様々なアプリケーションの入力及び／又は出力ステージで、データファイル、データ記録、及び、報告の形式を標準化できる。例えば、データファイル又はデータ記録は、固定長のデータ・フィールドを有する規定した構造を有することができる。図2a〜図2d（図2a−1〜2a−5、図2b−1〜2b−5、図2c−1及び2c−2、図2d）は、データ暗号化アプリケーション(DS)の入力記録及び出力記録、データ暗号化アプリケーション(LDF)の入力ファイル及び出力ファイルにおける形式例を示す。図4a〜図4c（図4a−1〜4a−3、図4b、図4c）は、データ供給者監査ファイル形式例を示し、図5a〜図5cは、LDF監査ファイル形式例を示す。
【００３５】
図2aを参照して、データ供給者の暗号化入力ファイル2001のデータ記録は、標準化した固定長、例えば1〜634バイト長に有することができる。入力データ記録の各データ・フィールドは、指定したデータ属性（例えば、処方箋又は患者識別属性）のためにリザーブとされる。選択組の指定した属性は、暗号化のために意図したものとできる（例えば、患者の生年月日、郵便番号などの機密の個人情報を含む、バイト501〜632における8つのデータ・フィールド）。
【００３６】
図2bを参照して、データ供給者暗号化出力ファイル2002は、バイト512〜923で、選択組の8つの指定した属性の暗号化したバージョンを示す。また、出力ファイル2002は、データ供給者及び処理の日付を識別する属性を含む（例えば、バイト471〜481）。これらの属性は、監査又は追跡の目的に役立つ。出力ファイル2002は、患者の郵便番号及び誕生日のHIPAAバージョンに対応する任意の属性を含むことができる（例えば、バイト926〜938で）。
【００３７】
図2cを参照して、LDF暗号化入力ファイル2003のデータ記録は、データ供給者の暗号化した組の８つの指定した属性を含む（バイト44〜455）。また、入力ファイル2003は、患者の性別（バイト 1）、データ供給者識別子（バイト2〜5）、処理する日付（バイト6〜13）、及び、マッチング属性（バイト14〜43）を識別する任煮のデータ・フィールドを含む。マッチング属性データ・フィールドは、好適なパラメータ（例えば、ID）を保持するように用いることができ、好適なパラメータは、暗号化した属性の内容を、データ供給者の固有のトランザクション属性に適合し戻すように用いることができる。図2dは、データ供給者の暗号化した組の8つの指定した属性（ファイル2003における属性）がLDF暗号化アプリケーション（例えば、トークン・ベースのアプリケーション）によって更に暗号化さている場合の出力ファイル2004の形式例を示す。
【００３８】
システム・ソフトウェア及びそのアプリケーションは、形式化したデータ記録で長期のデータベースを構成する、本発明の二重暗号化／マッチング解決策の様々なステージで、様々な機能を提供する。そのような機能は、認証したユーザ（即ち、1つ以上の関連した処理部（LDF、DS、又はIP／Key管理者）によって、呼び出し又は動作させることができる。ソフトウェア・システムは、データ属性を取得しデータ属性を標準化し、データHIPAAプライバシ・コンプライアントを生成し、データ属性を暗号化し、データ供給者ロケーション（例えばコンポーネント110a）での方向をカウントする特定の機能、及び、データ供給者の暗号化したデータ属性を取得し、データ属性を暗号化し、LDFロケーションで監査カウント報告を要求する特定機能を含むことができる。また、ソフトウェア・システムは、鍵管理者、鍵セキュリティ、及び、監査ストレージのための機能を含むことができる。システム・ソフトウェア構成の様々な機能の適用例及び技術例は、付録A〜Kにおいて、表にして示される。
【００３９】
前述の説明は、本発明の原理を単に示したものである。前述した実施例の様々な変形及び代替が、当業者に明らかである。従って、本明細書に明らかに記載されていない場合でも、本発明の趣旨及び範囲内で、当業者が本発明の原理を用いて、実施するための多数の技術を工夫できることは明らかである。
【００４０】
2007536833.tif 000003
【００４１】
2007536833.tif 000004
【００４２】
2007536833.tif 000005
【００４３】
2007536833.tif 000006
【００４４】
2007536833.tif 000007
【００４５】
2007536833.tif 000008
【００４６】
2007536833.tif 000009
【００４７】
2007536833.tif 000010
【００４８】
2007536833.tif 000011
【００４９】
2007536833.tif 000012
【００５０】
2007536833.tif 000013
【００５１】
2007536833.tif 000014
【００５２】
2007536833.tif 000015
【００５３】
2007536833.tif 000016
【００５４】
2007536833.tif 000017
【００５５】
2007536833.tif 000018
【００５６】
2007536833.tif 000019
【００５７】
2007536833.tif 000020
【００５８】
2007536833.tif 000021
【００５９】
2007536833.tif 000022
【００６０】
2007536833.tif 000023
【００６１】
2007536833.tif 000024
【図面の簡単な説明】
【００６２】
【図１】本発明の原理に従って、マルチ・ソース型の患者データ記録から長期のデータベースをアセンブリするシステム・コンポーネント及び処理を示すブロック図である。
【図２ａ−１】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ａ−２】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ａ−３】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ａ−４】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ａ−５】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ｂ−１】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ｂ−２】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ｂ−３】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ｂ−４】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ｂ−５】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ｃ−１】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ｃ−２】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図２ｄ】本発明の原理に従って、マルチ・ソース型の患者データ記録に用いられるソフトウェア・アプリケーションに適応する、データ供給者の入出力ファイル形式例を示す図である。
【図３】本発明の原理に従って、マルチ・ソース型の患者データ記録を処理するソフトウェア・アプリケーションにおいて用いられる様々な暗号鍵の構造及び形式の一例を示す図である。
【図４ａ−１】本発明の原理に従って、マルチ・ソース型の患者データ記録を処理するソフトウェア・アプリケーションによって生成されるデータ・ソースの監査ファイル形式及び監査報告の一例を示す図である。
【図４ａ−２】本発明の原理に従って、マルチ・ソース型の患者データ記録を処理するソフトウェア・アプリケーションによって生成されるデータ・ソースの監査ファイル形式及び監査報告の一例を示す図である。
【図４ａ−３】本発明の原理に従って、マルチ・ソース型の患者データ記録を処理するソフトウェア・アプリケーションによって生成されるデータ・ソースの監査ファイル形式及び監査報告の一例を示す図である。
【図４ｂ】本発明の原理に従って、マルチ・ソース型の患者データ記録を処理するソフトウェア・アプリケーションによって生成されるデータ・ソースの監査ファイル形式及び監査報告の一例を示す図である。
【図４ｃ】本発明の原理に従って、マルチ・ソース型の患者データ記録を処理するソフトウェア・アプリケーションによって生成されるデータ・ソースの監査ファイル形式及び監査報告の一例を示す図である。
【図５ａ】本発明の原理に従って、マルチ・ソース型の患者データ記録を処理するソフトウェア・アプリケーションによって生成される監査ファイル形式及び監査報告の一例を示す図である。
【図５ｂ】本発明の原理に従って、マルチ・ソース型の患者データ記録を処理するソフトウェア・アプリケーションによって生成される監査ファイル形式及び監査報告の一例を示す図である。
【図５ｃ】本発明の原理に従って、マルチ・ソース型の患者データ記録を処理するソフトウェア・アプリケーションによって生成される監査ファイル形式及び監査報告の一例を示す図である。
【図６】本発明の原理に従って、本ソフトウェア・アプリケーションによって処理されるファイルの幾つかのキャラクタ用の形式及び標準化したデータ・フィールドを示す図である。
【図１】
2007536833.tif 000025
【図２ａ−１】
2007536833.tif 000026
【図２ａ−２】
2007536833.tif 000027
【図２ａ−３】
2007536833.tif 000028
【図２ａ−４】
2007536833.tif 000029
【図２ａ−５】
2007536833.tif 000030
【図２ｂ−１】
2007536833.tif 000031
【図２ｂ−２】
2007536833.tif 000032
【図２ｂ−３】
2007536833.tif 000033
【図２ｂ−４】
2007536833.tif 000034
【図２ｂ−５】
2007536833.tif 000035
【図２ｃ−１】
2007536833.tif 000036
【図２ｃ−２】
2007536833.tif 000037
【図２ｄ】
2007536833.tif 000038
【図３】
2007536833.tif 000039
【図４ａ−１】
2007536833.tif 000040
【図４ａ−２】
2007536833.tif 000041
【図４ａ−３】
2007536833.tif 000042
【図４ｂ】
2007536833.tif 000043
【図４ｃ】
2007536833.tif 000044
【図５ａ】
2007536833.tif 000045
【図５ｂ】
2007536833.tif 000046
【図５ｃ】
2007536833.tif 000047
【図６】
2007536833.tif 000048
【国際調査報告】
2007536833.tif 000049