(57)【要約】長期のデータベースにおいて、個々のマルチ・ソース型の患者ヘルスケア・トランザクションデータ記録を統合する、ソフトウェアアプリケーションが提供される。データ記録は、データ記録における患者識別属性を暗号化することによって、それによってアクセス不能な機密の個人情報を与えるように、個人プライバシを保護する態様で処理される。共通のフレームワーク・コンポーネントを用いてモジュールとして構成させることができるアプリケーションは、データ供給者サイトで、及び、共通のデータベースアセンブリ装置で、マルチ・ソース型のデータ記録を処理するように構成される。本アプリケーションは、データ供給者サイト及びデータベース装置に、属性の取得、形式の標準化、暗号鍵の生成、及び、データ記録内の属性の暗号化及び解読のための方法を提供する。暗号化アプリケーションは、データ供給者に対して特定の鍵及びデータデースに対して特定の鍵を用いて、データ供給者サイトでのデータ記録を二重暗号化する方法を提供する。
2008500612.tif 000002
【特許請求の範囲】
【請求項１】
長期リンク化データベースにおいてアセンブリするためのデータファイルに含まれる、個々の患者のヘルスケア・トランザクションデータ記録を含むコンピュータ読取り可能な記録媒体であって、
属性取得モジュールと、
標準化モジュールと、
暗号鍵生成モジュールと、
暗号化モジュールとを備え、
前記属性取得モジュールが、前記データファイルに含まれる前記データ記録から属性を検索する方法を含み、前記属性が、選択した患者識別属性及び／又は非識別属性を含み、
前記標準化モジュールが、前記検索した属性を標準化形式にする方法を含み、
前記暗号鍵生成モジュールは、長期のデータベース装置に対して特定のデータ供給者・長期・暗号鍵（K1）及びデータ供給者に対して特定のデータ供給者・暗号鍵（K2）を生成する方法を含み、
前記暗号化モジュールが、鍵K1及びK2を用いて1つ以上の検索した患者識別属性を二重暗号化する方法を含む、コンピュータ読取り可能な記録媒体。
【請求項２】
前記標準化モジュールが、患者の生年月日、患者の性別、カードホルダID、記録番号、患者のジップコード、患者の名、患者の姓、データ供給者の患者ID、及び、患者の住所の属性のうち、少なくとも１つを、標準化形式にする方法を更に含む請求項1に記載のコンピュータ読取り可能な記録媒体。
【請求項３】
選択した患者識別属性を、HIPAAコンプライアンス形式にする方法を含むHIPAAコンプライアンス・モジュールを更に備える請求項1に記載のコンピュータ読取り可能な記録媒体。
【請求項４】
前記HIPAAコンプライアンス・モジュールが、患者の生年月日の属性及び患者のジップコードの属性のうち少なくとも1つを、HIPAAコンプライアンス形式にする方法を含む請求項3に記載のコンピュータ読取り可能な記録媒体。
【請求項５】
前記暗号鍵生成モジュールが、長期のデータベース装置に対して特定のデータ供給者・長期・暗号鍵（K1）及びデータ供給者に対して特定のデータ供給者・暗号鍵（K2）を生成する方法を含む請求項1に記載のコンピュータ読取り可能な記録媒体。
【請求項６】
前記暗号鍵生成モジュールが、鍵K1及びk2を暗号化するように構成される鍵を生成する方法を含む請求項1に記載のコンピュータ読取り可能な記録媒体。
【請求項７】
前記暗号鍵生成モジュールが、鍵K1及びk2を、それぞれの鍵ファイルに保存する方法を含む請求項1に記載のコンピュータ読取り可能な記録媒体。
【請求項８】
前記暗号化モジュールが、鍵K1及びk2を用いて、選択したデータ属性を連続的に二重暗号化する方法を含む請求項1に記載のコンピュータ読取り可能な記録媒体。
【請求項９】
前記選択したデータ属性が、患者の生年月日、カードホルダID、記録番号、患者のジップコード、患者の名、患者の姓、データ供給者の患者ID、及び、患者の住所の属性のうち、少なくとも１つを含む請求項8に記載のコンピュータ読取り可能な記録媒体。
【請求項１０】
前記暗号化モジュールが、前記暗号化したデータ属性を符号化する方法を含む請求項1に記載のコンピュータ読取り可能な記録媒体。
【請求項１１】
監査方法、ロギング方法、及び、例外／エラー処理方法のうち少なくとも1つを更に備える請求項1に記載のコンピュータ読取り可能な記録媒体。
【請求項１２】
複数のデータ供給者から得られる個々の患者のヘルスケア・トランザクションデータ記録を長期にリンクするシステムに設けられるコンピュータ読取り可能な記録媒体であって、
データ供給者ロケーションで、
患者識別属性及び非識別属性を有するデータ記録を取得するように構成され、
前記鍵生成モジュールによって生成される鍵K1及びK2で、前記データ記録内の前記患者識別属性を二重暗号化するように構成される、第1のコンポーネントと、
LDFで、
前記複数のデータ供給者から、二重暗号化したデータ記録を受信するように構成され、
前記患者識別属性が、前記第1の暗号鍵K1による前記暗号化を保持するように、前記受信したデータ記録を部分的に解読するように構成される、第2のコンポーネントと、
第3のコンポーネントであって、
前記暗号化したデータ記録の属性をマッチングすることにより、前記暗号化したデータ記録に、LDF識別子（ID）を割り当てるように構成され、
ID毎に前記暗号化したデータ記録をリンクし、長期のデータベースを形成するように構成される、前記第3のコンポーネントと、
を備える前記システムに設けられる請求項1に記載のコンピュータ読取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願）
この出願は、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規制又は他のプライバシ規則の組に従って標準化された形式における、個人的な健康情報を収集及び使用するシステム及び方法について、記載されている。
【０００５】
患者のプライバシの侵害についてのリスクを更に最小化するために、長期のデータベースを構成するように用いられる患者記録から、全ての患者識別情報を分離又は除去することが望ましいと考えられる。しかしながら、患者識別情報をデータ記録から分離し、患者識別情報を完全に匿名にすることは、格納されたデータ記録が、患者毎にリンク可能でなければならない長期のデータベースの構成と互換性がなくなる場合がある。
【０００６】
同日に出願された、共同発明及び共同割り当ての米国特許出願第_______号明細書（代理人整理番号AP36247）の内容は、本明細書の内容に取り込まれ、複数のソースから取得した患者データ記録が、患者プライバシの侵害の如何なるリスクも生じさせることなく、患者毎（即ち、個人毎に）に長期のデータベースへと統合されることを可能とするシステムについて開示する。
【０００７】
取り込まれた特許出願第_______号明細書に開示されるシステムは、複数の暗号鍵を用いて2ステップの暗号化手順を用いる。本システムは、データ・ソース、即ちデータ供給者（“DS”）、長期のデータベース装置、及び、第三者実装パートナー（“IP”）を包含する。IPは、暗号鍵管理人としても機能し、装置コンポーネントサイトで動作する。データ供給者サイトで、各DSは、患者記録において選択したデータ・フィールド（例えば、患者識別属性及び／又は他の標準化した属性データ・フィールド）を暗号化し、患者記録を第1の“匿名型”形式に変換する。各DSは、選択したデータ・フィールドを2重暗号化するように、2つの鍵（即ち、ベンダー特定鍵と、特定のLDFで関連付けられた共通の長期鍵）を用いる。2重暗号化したデータ記録は、装置コンポーネントサイトに送信される。ここで、IPは、更に。2重暗号化したデータ記録を処理できる。データ記録は、第2の匿名型形式へと処理され、第2の匿名型形式は、データ記録が元の暗号化していない患者の識別情報を回復することなく、個々の患者毎にリンクされることを可能とするように構成される。このため、DSから受信した患者記録の二重暗号化したデータ・フィールドは、特定のベンダー鍵を用いて部分的に解読される（二重暗号化したデータ・フィールドは、共通の長期鍵暗号化を保持している）。第3の鍵（例えば、トークン・ベースの鍵）は、長期のデータベースにおいて用いられる、新たな単一の（共通の長期鍵で）暗号化したデータ・フィールド及び属性を更に作成するように用いることができる。長期のデータベースに対して内部的となる長期の識別子（ID）又はダミーラベルは、データ記録をタグ付けするように用いることができ、これにより、データ記録は、元の暗号化していない患者の識別情報の知識なく、長期のデータベースにおいて個々のID毎にマッチングされ、リンクされることができる。
【０００８】
マルチ・ソース型のデータ記録を、長期のデータベースへとアセンブリする二重暗号化／マッチングの解決策の構成について、更なる考慮がここに与えられる。特に、特定の暗号化アプリケーションの構成に配慮が払われる。所望の暗号化アプリケーションは、他のデータ処理アプリケーションと統合できるアプリケーションであり、患者プライバシを保護するプライベートインチシアティブ規格に準拠する形式においてデータ処理することを可能とする。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、個々の暗号化技法及びデータ記録のコンテンツにおいて、データ・ソース変化に対策するためにマルチ・ソース型の患者データ記録を暗号化するソフトウェア・アプリケーションを提供する。本ソフトウェアアプリケーションは、複数のデータ・ソース又は供給者から受信した非識別型のデータ記録が、市場調査又は他の分析のために、長期のデータベースにアセンブリされることを可能とする。本ソフトウェア・アプリケーションは、患者プライバシに関する業界規格又は他の規格と準拠した患者プライバシを確実にする処理を実現するように構成される。
【課題を解決するための手段】
【００１０】
本ソフトウェア・アプリケーションは、コンピュータ読取り可能な記録媒体に設けられ、複数のデータ供給者を包含するデータベース・アセンブリ処理において、及び、共通の長期のデータベース装置において、利用することができる。データ処理ステップは、データを標準化するステップ、データ属性を修正し、又は、取得するステップ、及び、監査カウント及び監査報告を生成するステップとを含むことができ、更に、選択したデータの暗号化／解読するステップ、及び、データ処理の種々のステージ又はロケーションで暗号化の安全な環境とするステップを含む。
【００１１】
本発明の一実施例では、個々の患者ヘルスケア・トランザクション・データ記録を含むコンピュータ読取り可能な記録媒体は、方法又は機能のモジュール収集として構成される。例えば、コンピュータ読取り可能な記録媒体は、属性取得モジュール、標準化モジュール、暗号鍵生成モジュール、及び、暗号化モジュールを含む。データ供給者サイト又は長期のデータベース装置でインストールされたデータ処理アプリケーションは、データ処理のために、これらモジュールの個々の方法を呼び出すことができる。
【００１２】
属性取得モジュールは、データファイルから呼び出しアプリケーションまで、データ属性を検索又は取得する方法を含むことができる。標準化モジュールは、データ属性（例えば、患者の生年月日、患者の性別、カードホルダID、記録番号、患者のジップコード、患者の名、患者の姓、データ供給者・患者ID、及び、患者の住所）の標準化のための方法を含むことができる。
【００１３】
暗号鍵生成モジュールは、データ属性の暗号鍵を生成する方法を含むことができ、安全なストレージ又は伝送のために、データ属性の暗号鍵自体を更に暗号化する方法を含むことができる。データ属性の暗号鍵は、長期のデータベースに対して特定のデータ供給者の長期の暗号鍵（K1）及びデータ供給者によって特定のデータ供給者の暗号鍵（K2）を含む。更に、暗号鍵生成モジュールは、データアセンブリの様々なステージで、データ属性の更なる暗号化に対してトークン・ベースの鍵を生成できる。暗号化モジュールは、データ供給者サイトで、鍵K1及びK2を用いて、1つ以上の検索された患者識別属性を二重暗号化する方法を含む。また、暗号化モジュールは、長期データベース装置で、二重暗号化したデータ属性を部分的に解読する方法を含む。また、暗号化モジュールは、同一の装置で、第3の鍵（例えば、トークン・ベースの鍵）を用いて、データ属性を任意で再暗号化する方法を含む。
【００１４】
また、コンピュータ読取り可能な記録媒体は、選択した患者識別属性をHIPAAコンプライアンス形式にする方法を有するHIPAAコンプライアンス・モジュールを含むことができる。更に、コンピュータ読取り可能な記録媒体は、共通の監査方法、ロギングする方法、及び、例外／エラー処理する方法を含むことができる。
【００１５】
本発明の更なる特徴、本質、及び様々な利点は、図面、及び以下の詳細な説明から明らかになる。
【００１６】
ここで、説明の利便性のため、頭文字表現と略語表現で使用をすることができる。幾つかの頭文字表現と略語表現は、以下の表で示される。
PPS： 個人プライバシ規格
HIPAA：医療保険の相互運用性と説明責任に関する法律
LDF： 長期のデータベース装置
NCPDP：処方薬プログラムに関する国際標準化機構
AES： 次世代暗号化標準
JCE：Java（登録商標）暗号拡張子
SHA1： 安全なハッシュアルゴリズム1
DOB： 生年月日
HMAC：ハッシュ（鍵）メッセージ認証コード
【発明を実施するための最良の形態】
【００１７】
暗号化アプリケーションは、データ供給者サイトで、及び、長期のデータベース装置（“LDF”）で、二重暗号化の機能性を設けるように構成されている。非識別型の患者記録から長期のデータベースを構成するという問題に対して二重暗号化／マッチングの解決策を提供するために、暗号化アプリケーションは、他のソフトウェアアプリケーションと統合できる。暗号化アプリケーションは、受信するデータ記録が、LDF又は他のサイトで、患者情報の不注意又は故意の誤運用の全てのリスクを排除するための特定のプライベート・イニシアティブ要求と矛盾しない方法で処理されるように、構成されている。
【００１８】
暗号化アプリケーションの組の一例は、患者属性が業界で受け入れられる安全な暗号化形式でフォーマットされる、二倍暗号化したデータ記録（トランザクション記録）を、データ供給者が提供することを可能にするように構成されている。更に、暗号化アプリケーションは、データ属性が暗号化形式を有するように構成されており、その暗号化形式は、LDFが個々にマルチ・ソース型のデータ記録をリンクすることを許容するが、LDFが個人に関連する身元又は何らかの他の機密の個人情報を学習することを排除するものである。
【００１９】
暗号化アプリケーションの組の一例は、データ供給者の暗号化アプリケーション、LDFの暗号化アプリケーション、鍵生成アプリケーション、及び報告生成アプリケーションを含んでいる。本アプリケーションは、何らかの好適なコンピュータプログラミング言語で書くことができ、データ供給者サイト及びLDFに跨ってした動作のための何らかの好適なコンピュータ又はネットワークハードウェアシステム上で実現できる。 (例えば、図1参照。)
【００２０】
各々のアプリケーションは、好適な入力データファイルを受け入れるように、及び、好適な出力データファイルを生成するように、構成させることができる。例えば、データ供給者の暗号化アプリケーションは、データ供給者・暗号化出力ファイルを生成するように、データ供給者・入力ファイルを処理するように用いることができる。（図2a(図2a−1〜2a−5)及び図2b(図2b−1〜2b−5)を参照）。同様に、LDF暗号化アプリケーションは、LDF供給者・暗号化出力ファイルを生成するように、LDF入力ファイルを処理するように用いることができる。（図2c(図2a−1〜2a−2)及び図2dを参照）。入力データファイルは、標準化した固定長形式を有することができる。入力ファイルは、ヘルスケア・トランザクションに関するデータ記録及び個人的な患者情報からなることができる。標準化形式を有するデータ記録で、個人情報に関するデータ・フィールド及び又は属性は、データ記録の終わりにおけるケア・トランザクションデータの後部に置くことができる。形式の一変形例において、例外として、“患者の性別”属性は、データ記録の中央におけるケア・トランザクションデータ中に置くことができる。本アプリケーションは、個人情報属性（例えば、これら個人情報属性は、データ記録の終わりで又はデータ記録の中間に置かれている）が読み取られ、標準化され、HIPAAコンプライアンス化され、及び、二重暗号化されるように、入力データファイルを処理するように構成することができる。
【００２１】
暗号化アプリケーションからの出力は、固定長形式ファイルへと書かれる。暗号化した属性は、トランザクションデータを含むデータ記録の終わりに置かれることができる。（図2c及び2d参照）。入力データ・フィールドに置かれた暗号化した属性は、必要であれば、暗号化した属性のサイズを増大するため、標準化したデータ記録形式のその属性のために指定されたデータ・フィールドサイズをマッチングするように補充できる。
【００２２】
アプリケーションの組のバージョンは、1組のクラス又はモジュールとして構成される方法及び機能を利用するように構成される。本アプリケーションは、入力ファイルから読み取られたデータ属性を変換する方法及び機能を利用する。このモジュールの組は、以下のように命名されたモジュールを含むことができる。
・コンフィグレーション
・属性取得
・鍵の導出及び保全チェック
・標準化
・HIPAAコンプライアンス
・暗号化
・安全な監査生成
・ファイル出力
【００２３】
共通のフレームワーク・コンポーネントは、これら1つ以上のモジュールを跨って用いることができる。例えば、共通のフレームワーク・コンポーネントは、監査、抜き取り、及び、例外／エラー処理のルーチンを含むことができる。更に独立の報告ツール／ユーティリティを、監査報告を生成するアプリケーションと関連することができる。図示するために、これらモジュールの幾つかの特徴例を以下に説明する。
【００２４】
コンフィグレーション・モジュールは、コンフィグレーション・ファイルからシステム及びデータ情報を読み取るように、及び、後にアプリケーション内の使用のためのメモリにそのような情報をロードするように構成される。コンフィグレーション・ファイルの一例は、以下の情報を含むことができる。入力属性名、開始及び終了位置、所望のログレベル、形式表示、データ供給者ID、暗号化及び標準化を示すオプション、HIPAAコンプライアンスの必要性を示すオプション、記録デリミタ、及び、ファイルの名前及び位置。
【００２５】
コンフィグレーション・モジュールは、変数を初期化する機能／方法、及び、呼び出しアプリケーション又はプログラムに対して情報（例えば、位置及び値）を検索するデータアクセス方法を含むことができる。付録Aは、コンフィグレーション・モジュールに含むことができる方法の組の一例をリストしている。
【００２６】
属性取得モジュールは、データアクセス方法を含み、データアクセス方法は、更なる処理のためにデータファイルから属性を検索する。標準化、HIPAAコンプライアンス化、及び、暗号化のモジュールは、各動作の後に、属性に対して値を検索又は設定するように、属性取得モジュールの1組の規定したデータアクセス方法を用いることができる。PPSの様々な文脈は、値を取得する、必要な動作を実行する（例えば、標準化、HIPAAコンプライアンス化又は暗号化）、及び、値を設定する、これらモジュールの各々によって用いられる。コンフィグレーション・モジュールのような、これらモジュールは、変数を初期化する方法、及び、呼び出しアプリケーション又はプログラムに対して情報（例えば、位置及び値）を取得するデータアクセス方法を含むことができる。付録Bは、標準化、HIPAAコンプライアンス化又は暗号化のモジュールに利用できる方法の組の一例をリストしている。
【００２７】
別の組のモジュール（例えば、PPS処理クラスの機能（Class PPSProcessor function））
は、アプリケーション・モジュールにおいて、標準化され、HIPAAコンプライアンス化され、又は暗号化されるべき属性の対象入力ファイルを分析するように用いることができる。読み取られるべき属性の名前の情報、及び、これらの属性の位置は、クラス・PPS処理機能の方法を用いることによって、コンフィグレーション・モジュールから取得される。
【００２８】
代表的な処理フローにおいて、入力ファイルからのデータ記録は、効率化のために、大きなチャンクで読み取ることができ、コンピュータメモリへとロードすることができる。個人情報に関する属性は、個別に処理するため、データ記録から抽出できる。付録Cは、標準化、HIPAAコンプライアンス化又は暗号化のモジュールに含めることができる、PPSクラスの様々なデータアクセスの方法の組の一例をリストしている。標準化されるべき全ての属性（例えば、適用可能な個人プライバシ規格の下で識別される属性）は、それぞれの標準化処理を通過する。次に、HIPAAコンプライアンスを要求するこれら属性のために、HIPAAコンプライアンス化の方法を呼び出すことができる。最後に、暗号化されるべき、これら属性のために、暗号化の方法を呼び出すことができる。付録Dは、標準化、HIPAAコンプライアンス化又は暗号化のモジュールに利用可能とされる属性取得モジュールにおけるPPS処理クラスの方法の特徴例をリストしている。
【００２９】
このクラス（例えば、public void処理（PPSConfig））における初期化の方法は、PPSConfigクラスに対して処理を与える。初期化の方法は、対象データファイルにおいて与えられている、全ての属性を読み取る。更に、初期化の方法は、対応する属性名で、変数を設定するために、PPSConfigからデータ取得の方法を呼び出すことができる。
【００３０】
鍵の導出及び保全のチェックのモジュールは、暗号化アプリケーションによる使用のために、データ供給者・長期・暗号鍵（例えば、鍵K1、図１参照）及びデータ供給者・暗号鍵（例えば、鍵K2、図１参照）の暗号化バージョンを生成する特定の方法（例えば、PPSの鍵生成クラス(Class PPSGenerateKey)）を含むことができる。付録Eは、鍵の導出モジュールにおけるClass PPSGenerateKey( )の方法及び他の方法の特徴例をリストしている。このクラスは、暗号鍵を読み取り、暗号化アプリケーションによる使用のための鍵を解読する。また、このクラスは、MOL鍵導出モジュール(MOL derive key module)において導出した鍵を用いて、安全な暗号鍵を作成する。これらのほうほうの１つ（例えば、PPSの鍵導出クラス(Class PPSDeriveKey)）は、データ供給者・長期・暗号鍵K1及びデータ供給者・暗号鍵K2を暗号化するように用いることができる鍵を導出するように用いることができる。他の方法（例えば、PPSの安全な暗号鍵クラス(Class PPSSecure Encryption Key)）は、其々の鍵ファイルに鍵K1及びK2を安全に保存するように用いることができる。更に、PPSの鍵生成クラス(Class PPSKey Generater)）は、鍵K1及び／又はK2の暗号化バージョンを生成するように利用可能とできる。
【００３１】
また、鍵・導出モジュールは、他のモジュール又はアプリケーションが、PPSの暗号化（PPSEncrypt）クラス及びPPSの解読(PPSDecrypt)クラスにおいて規定される暗号化方法を用いることを可能とするパブリック方法（例えば、パブリック・ユーティリティ・クラス（Class Public Utility））を含む。例えば、暗号化モジュールは、鍵K1及びK2の暗号化及び／又は解読のためのパブリック・ユーティリティ・クラス（Class Public Utility）の方法を用いることができる。図3は、鍵・導出モジュールにおける方法を用いて、生成される様々な暗号鍵の構造及び軽視の一例を示す。
【００３２】
標準化モジュール（例えば、PPSの標準化クラス(Class PPSStandardize)）は、呼び出しアプリケーションによって、入力データ記録の属性を標準化するように用いることができる方法を含む。例えば、標準化できるデータ属性の組は、患者の生年月日、患者の性別、カードホルダID、記録番号、患者のジップコード、患者の名、患者の姓、データ供給者の患者ID、患者の住所を含む。標準化した属性は、標準化処理の出力で、利用可能である。付録Fは、このクラスの方法の特徴例をリストする。
【００３３】
HIPAAコンプライアンス・モジュールの方法（例えば、PPSのHIPAA化クラス(Class PPSHipaa)）は、患者の生年月日及び患者のジップコードの属性のHIPAAコンプライアンスを作成するように構成される。例えば、患者の生年月日及び患者のジップコードの属性のHIPAAコンプライアンス化が、特定のデータ供給者の方で要求され又は消耗されるときに、このモジュールの方法を、呼び出すことができる。本アプリケーションは、この情報を取得し、これら属性の１つ又は双方を、要求され又は所望されるHIPAAコンプライアンス化させる。付録Gは、HIPAAコンプライアンス・モジュールに含めることができるコンプライアンス化の方法の特徴例をリストする。
【００３４】
暗号化モジュールは、暗号化のために選択した属性を暗号化し、また、暗号化した属性を符号化する方法（例えば、PPSの暗号化クラス（Class PPSEncrypt））を含む。暗号化処理は、暗号鍵（例えば、鍵K1及びK2）及び入力として、暗号化されるべきデータを取り出す。データは、まず、データ供給者・長期・暗号鍵(K１)で暗号化を受ける。次に、暗号化した結果は、データ供給者・暗号鍵(K2)で、別のラウンドの暗号化を受ける。次に、最終的に二重暗号化された結果が、符号化される。符号化は、2値データであり、ストレージ又は伝送に好適な形式へと、暗号化の結果を変換することが好ましい。
【００３５】
好適な対象鍵アルゴリズムは、暗号化メカニズムとして用いることができる。例えば、連邦情報処理基準である次世代暗号化標準（AES）アルゴリズムは、暗号化メカニズムを用いることができる。二重暗号化出力は、ベース64符号化メカニズムを用いることができる。暗号化した属性は、患者の生年月日、カードホルダID、記録番号（必要であれば）、患者のジップコード、患者の名、患者の姓、データ供給者の患者ID、患者の住所を含むことができる。
【００３６】
また、暗号化モジュールは、解読のための方法を含むことができる。例えば、解読のための方法を、鍵導出モジュールで生成したAES暗号鍵の解読のために利用できる。付録Hは、暗号化モジュールに含めることができる暗号化及び解読の方法の特徴例をリストする。
【００３７】
データ記録を処理するアプリケーションの代表的なコンフィグレーションにおいて、標準化を必要とするときに識別される、データ属性又はデータ・フィールドのリスト、HIPAAコンプライアンス化、及び暗号化は、アプリケーション内に固定される。標準化、HIPAAコンプライアンス化及び暗号化が、実際の入力データ記録において要求されないときは、固定した属性のこのリスト外に、如何なる番号の属性も除去される。しかしながら、固定した属性以外の新たな又は追加の属性は、3つの処理（標準化、HIPAAコンプライアンス化及び暗号化）を経て、アプリケーションで処理されることはない。
【００３８】
安全・監査・生成モジュール（例えば、PPSの監査クラス（Class PPSAudit））は、全ての監査カウンタ、監査ファイル、及びそのデータ保全を維持する方法を含む。このクラスは、初期化をしている間にファイル保全をチェックする。標準化、HIPAAコンプライアンス化及び暗号化のモジュールは、監査及びデータ保全のチェックのためにこのクラスの方法を用いる。このクラスの一例のみが、暗号化アプリケーション処理の全寿命を経て存在することができる。付録Iのリストは、安全・監査・生成モジュールにおいて含めることができる方法の特徴例をリストする。図4a（図4a−1〜4a−3）及び5aは、それぞれ、データ供給者・監査ファイル例の形式と、安全・監査・生成の方法を用いて生成させることができる暗号化カウント監査ファイルの形式を示す。
【００３９】
ファイル出力モジュールは、監査ファイルから読み取り、監査報告を出力ファイルへと出力する方法（例えば、PPSの報告クラス(Class PPSReport)）を含む。報告生成ユーティリティ（例えば、PPSの報告生成部クラス(Class PPSReportGenerator)）は、監査報告を生成するように用いることができる。付録Jは、ファイル出力モジュールにおいて含めることができる方法の特徴例をリストする。図4b及び4cは、患者データ記録を処理するソフトウェア・アプリケーションによって生成されるデータ・ソース監査報告例の形式を示す。同様に、図5b及び5cは、ファイル出力の方法によって生成させることができるLDF監査報告例の形式を示す。
【００４０】
更に、本アプリケーションの実行中に生じうる全ての例外を処理するように、例外の方法のクラスを、本アプリケーションに含めることができる。このクラスは、アプリケーション及び／又は例外メッセージに対応するストリングによって組み込み例外を保つことができるオブジェクトを作成することができる。付録Kは、アプリケーションに含めることができる一例の例外方法をリストする。
【００４１】
一実現例では、本アプリケーション／モジュールは、処理がランしている間に200万以上のデータ供給者の記録を処理することが可能なように構成される。前述したように、全て又は幾つかのアプリケーション・モジュールに跨って用いられる共通のフレームワーク・コンポーネントは、以下を含む。
１．監査するフレームワーク
２．ロギングするフレームワーク
３．例外／エラーを処理するフレームワーク
【００４２】
本発明によれば、前述の方法又は機能を、コンピュータ読み取り可能な記録媒体に設けることができる。各々の方法（本発明に従って上述されている）、及び、それら方法の組み合わせは、コンピュータプログラムの命令によって実現できる。コンピュータ上、又は、他のプログラマブル装置上で実行する命令が、前述の方法又は機能を実現する手段を作成するように、これらコンピュータ・プログラムの命令は、マシンを形成するように、コンピュータ又は他のプログラマブル装置にロードできる。また、これらコンピュータプログラムの命令を、コンピュータ読取り可能なメモリに保存でき、コンピュータ読取り可能なメモリに保存された命令は、方法又は機能を実現する命令手段を含む製品を形成するように、コンピュータ読取り可能なメモリは、コンピュータ又は他のプログラマブル装置が、特定の態様で機能するように方向付けることができる。また、コンピュータ又は他のプログラマブル装置で実行される命令が、方法又は機能を実現するステップを与えるように、コンピュータで実現される処理を与えるため、コンピュータ又は他のプログラマブル装置で実行されるべき一連の動作ステップを生じさせるように、コンピュータ・プログラムの命令を、コンピュータ又は他のプログラマブル装置にロードできる。また、前述したアプリケーション、方法、及び機能を実現する命令が与えられているコンピュータ読取り可能な記録媒体が、制限することなく、ファームウェア、マイクロコントローラ、マイクロプロセッサ、集積回路、ASIC、及び他の利用可能な記録媒体を含むことは明らかである。
【００４３】
前述の説明は、本発明の原理を単に示したものである。前述した実施例に対して様々な変形及び代替が実現できることは、当業者に明らかである。従って、前述の説明で明らかに記載されていない場合でも、本発明の趣旨及び範囲内で、当業者が本発明の原理を用いて、実施するための多数の技術を工夫できることは明らかである。
【００４４】
2008500612.tif 000003
【００４５】
2008500612.tif 000004
【００４６】
2008500612.tif 000005
【００４７】
2008500612.tif 000006
【００４８】
2008500612.tif 000007
【００４９】
2008500612.tif 000008
【００５０】
2008500612.tif 000009
【００５１】
2008500612.tif 000010
【００５２】
2008500612.tif 000011
【００５３】
2008500612.tif 000012
【００５４】
2008500612.tif 000013
【００５５】
2008500612.tif 000014
【００５６】
2008500612.tif 000015
【００５７】
2008500612.tif 000016
【００５８】
2008500612.tif 000017
【００５９】
2008500612.tif 000018
【００６０】
2008500612.tif 000019
【００６１】
2008500612.tif 000020
【００６２】
2008500612.tif 000021
【００６３】
2008500612.tif 000022
【００６４】
2008500612.tif 000023
【００６５】
2008500612.tif 000024
【００６６】
2008500612.tif 000025
【００６７】
2008500612.tif 000026
【００６８】
2008500612.tif 000027
【００６９】
2008500612.tif 000028
【００７０】
2008500612.tif 000029
【００７１】
2008500612.tif 000030
【００７２】
2008500612.tif 000031
【００７３】
2008500612.tif 000032
【００７４】
2008500612.tif 000033
【００７５】
2008500612.tif 000034
【００７６】
2008500612.tif 000035
【００７７】
2008500612.tif 000036
【００７８】
2008500612.tif 000037
【００７９】
2008500612.tif 000038
【００８０】
2008500612.tif 000039
【００８１】
2008500612.tif 000040
【００８２】
2008500612.tif 000041
【００８３】
2008500612.tif 000042
【００８４】
2008500612.tif 000043
【００８５】
2008500612.tif 000044
【図面の簡単な説明】
【００８６】
【図１】米国特許出願第________号明細書から再現される、マルチ・ソース型の患者データ記録から長期のデータベースをアセンブリするシステム例のブロック図であり、同図のシステムにおいて、上述の暗号化アプリケーションは、本発明の原理に従って実現できる。
【図２ａ−１】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ａ−２】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ａ−３】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ａ−４】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ａ−５】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ｂ−１】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ｂ−２】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ｂ−３】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ｂ−４】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ｂ−５】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ｃ−１】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ｃ−２】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図２ｄ】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するように用いられるソフトウェアアプリケーションによって要求される形式に従うデータ供給者の入出力ファイル形式例を示す図である。
【図３】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するソフトウェアアプリケーションにおいて用いられる様々な暗号鍵の構造及び形式の例を示す図である。
【図４ａ−１】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するソフトウェアアプリケーションによって生成されるデータ・ソース監査ファイル形式及び監査報告の例を示す図である。
【図４ａ−２】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するソフトウェアアプリケーションによって生成されるデータ・ソース監査ファイル形式及び監査報告の例を示す図である。
【図４ａ−３】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するソフトウェアアプリケーションによって生成されるデータ・ソース監査ファイル形式及び監査報告の例を示す図である。
【図４ｂ】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するソフトウェアアプリケーションによって生成されるデータ・ソース監査ファイル形式及び監査報告の例を示す図である。
【図４ｃ】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するソフトウェアアプリケーションによって生成されるデータ・ソース監査ファイル形式及び監査報告の例を示す図である。
【図５ａ】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するソフトウェアアプリケーションによって生成される監査ファイル形式及び監査報告の例を示す図である。
【図５ｂ】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するソフトウェアアプリケーションによって生成される監査ファイル形式及び監査報告の例を示す図である。
【図５ｃ】米国特許出願第________号明細書から再現される、本発明の原理に従って、患者データ記録を処理するソフトウェアアプリケーションによって生成される監査ファイル形式及び監査報告の例を示す図である。
【図１】
2008500612.tif 000045
【図２ａ−１】
2008500612.tif 000046
【図２ａ−２】
2008500612.tif 000047
【図２ａ−３】
2008500612.tif 000048
【図２ａ−４】
2008500612.tif 000049
【図２ａ−５】
2008500612.tif 000050
【図２ｂ−１】
2008500612.tif 000051
【図２ｂ−２】
2008500612.tif 000052
【図２ｂ−３】
2008500612.tif 000053
【図２ｂ−４】
2008500612.tif 000054
【図２ｂ−５】
2008500612.tif 000055
【図２ｃ−１】
2008500612.tif 000056
【図２ｃ−２】
2008500612.tif 000057
【図２ｄ】
2008500612.tif 000058
【図３】
2008500612.tif 000059
【図４ａ−１】
2008500612.tif 000060
【図４ａ−２】
2008500612.tif 000061
【図４ａ−３】
2008500612.tif 000062
【図４ｂ】
2008500612.tif 000063
【図４ｃ】
2008500612.tif 000064
【図５ａ】
2008500612.tif 000065
【図５ｂ】
2008500612.tif 000066
【図５ｃ】
2008500612.tif 000067
【国際調査報告】
2008500612.tif 000068