(57)【特許請求の範囲】
【請求項１】
コンピュータを用いて、長期リンクのタグを、対象のデータ記録に割り当てる方法であって、前記対象のデータ記録のデータ属性は、英数字の識別コード属性、第三者属性及び／又は患者ヘルスケア・トランザクションに関するデモグラフィック属性のうち少なくとも幾つかを含む方法において、
(a) 前記コンピュータのプロセッサを用いて、マッチングレベルの階層構造を規定するステップであって、前記マッチングレベルの各々は、既知の長期リンクのタグと関連付けされた参照データ記録との比較のための指定組のデータ属性によって規定されており、前記マッチングレベルの階層構造は、各々の前記マッチングレベルにおける前記データ属性のマッチングの有効性に応じて編成され、前記マッチングレベルの階層構造は、指定組の英数字の識別コード属性によって各々のマッチングレベルが規定される第１の組のマッチングレベル、及び、デモグラフィック属性を含む指定組の属性によって各々のマッチングレベルが規定される第２の組のマッチングレベルを含むステップと、
(b) 前記コンピュータのプロセッサを用いて、マッチングする参照データ記録を見つける試みにおいて、当該プロセッサを用いて、前記第１の組のマッチングレベルで、前記対象のデータ記録及び前記参照データ記録における前記指定組のデータ属性の値をレベル毎に比較するステップと、
(c) マッチングする参照データ記録が、前記ステップ(b)で見つけられない場合に、前記コンピュータのプロセッサを用いて、少なくとも関連するデモグラフィック属性が、前記対象のデータ記録に与えられていることを確かめるステップと、
(d) 少なくとも前記関連するデモグラフィック属性が、前記対象のデータ記録に与えられている場合に、前記コンピュータのプロセッサを用いて、マッチングする参照データ記録を見つける試みにおいて、当該プロセッサを用いて、前記対象のデータ記録及び前記参照データ記録における前記指定組のデータ属性の値を、前記第２の組のマッチングレベル毎に比較するステップと、
(e) マッチングする参照データ記録が見つけられる場合に、前記コンピュータのプロセッサを用いて、前記参照データ記録と関連付けられている長期リンクのタグを、前記対象のデータ記録に割り当てるステップと、
を含む方法。
【請求項２】
(f) 前記ステップ(b)〜(e)で、前記参照データ記録が、前記対象のデータ記録と首尾よくマッチングしない場合に、前記コンピュータのプロセッサを用いて、新規に長期リンクのタグを生成し、前記タグを前記対象のデータ記録に割り当てるステップを更に含む、請求項１に記載の方法。
【請求項３】
前記第１の組のマッチングレベルにおける少なくとも１つのマッチングレベルが、供給者の患者ＩＤ、供給者ＩＤ、小売店ＩＤ、Ｒｘ番号、ＮＣＰＤＰ資格付与者、ＮＣＰＤＰ ＩＤの属性及びそれらのいずれかの組み合わせからなるグループから選択した一組の属性によって規定されている、請求項１に記載の方法。
【請求項４】
前記ステップ(c)において、前記関連する属性が、ＤＯＢ属性である、請求項１に記載の方法。
【請求項５】
前記第２の組のマッチングレベルにおける少なくとも１つのマッチングレベルが、保険カード番号、ＤＯＢ、性別、患者のジップコード、姓、名、アドレス番号及びそれらのいずれかの組み合わせからなるグループから選択した一組のデモグラフィック属性によって規定されている、請求項１に記載の方法。
【請求項６】
(g) 前記コンピュータのプロセッサを用いて、前記対象のデータ記録、及びステップ(b)で見つけたマッチングする参照データ記録におけるデモグラフィック属性の値を比較して、前記２つの記録についてのマッチングを確認するステップを更に含み、
前記マッチングレベルは、当該マッチングレベルの各々を規定する前記指定組のデータ属性について経験的に定められたマッチングの有効性のランクに応じて、階層的な順序に配列されている、請求項１に記載の方法。
【請求項７】
前記ステップ(g)が、前記対象のデータ記録及び前記マッチングする参照データ記録におけるＤＯＢ及び性別の属性の値を比較して、前記２つの記録についてのマッチングを確認するステップを含む、請求項６に記載の方法。
【請求項８】
前記ステップ(g)が、前記対象のデータ記録及び前記マッチングする参照データ記録における姓及びジップコードの属性の値を比較して、前記２つの記録についてのマッチングを確認するステップを含む、請求項６に記載の方法。
【請求項９】
前記マッチングレベルが、当該マッチングレベルの各々を規定する前記指定組のデータ属性について経験的に定められたマッチングの有効性のランクに応じて、階層的な順序に配列されている、請求項１に記載の方法。
【請求項１０】
コンピュータによって実行される命令を含むコンピュータ読取り可能なメディアであって、前記コンピュータは、前記命令を実行することによって、
前記コンピュータのプロセッサを用いて、長期リンクのタグを、対象のデータ記録に割り当てる方法を実行し、前記対象のデータ記録のデータ属性は、英数字の識別コード属性、第三者属性及び／又は患者ヘルスケア・トランザクションに関するデモグラフィック属性のうち少なくとも幾つかを含み、前記方法は、
(a) 前記コンピュータのプロセッサを用いて、マッチングレベルの階層構造を規定するステップであって、前記マッチングレベルの各々は、既知の長期リンクのタグと関連付けされた参照データ記録との比較のための指定組のデータ属性によって規定されており、前記マッチングレベルの階層構造は、各々の前記マッチングレベル内の前記データ属性のマッチングの有効性に応じて編成され、前記マッチングレベルの階層構造は、指定組の英数字の識別コード属性によって各々のマッチングレベルが規定される第１の組のマッチングレベル、及び、デモグラフィック属性を含む指定組の属性によって各々のマッチングレベルが規定される第２の組のマッチングレベルを含むステップと、
(b) 前記コンピュータのプロセッサを用いて、マッチングする参照データ記録を見つける試みにおいて、当該プロセッサを用いて、前記第１の組のマッチングレベルで、前記対象のデータ記録及び前記参照データ記録における前記指定組のデータ属性の値をレベル毎に比較するステップと、
(c) マッチングする参照データ記録が、前記ステップ(b)で見つけられない場合に、前記コンピュータのプロセッサを用いて、少なくとも関連するデモグラフィック属性が、前記対象のデータ記録に与えられていることを確かめるステップと、
(d) 少なくとも前記関連するデモグラフィク属性が、前記対象のデータ記録に与えられている場合に、前記コンピュータのプロセッサを用いて、マッチングする参照データ記録を見つける試みにおいて、前記対象のデータ記録及び前記参照データ記録における前記指定組のデータ属性の値を、前記第２の組のマッチングレベル毎に比較するステップと、
(e) マッチングする参照データ記録が見つけられる場合に、前記コンピュータのプロセッサを用いて、前記参照データ記録と関連付けられている長期リンクのタグを、前記対象のデータ記録に割り当てるステップと、
を含む、コンピュータ読取り可能なメディア。
【請求項１１】
コンピュータ読取り可能なメディア上に符号化された長期リンクのタグを割り当てられた、少なくとも１つの対象のデータ記録を含む長期のデータベースであって、
前記少なくとも１つの対象のデータ記録は、英数字の識別コード属性、第三者属性及び／又はデモグラフィック属性のうち少なくとも幾つかを含み、
マッチングレベルの階層構造が規定され、前記マッチングレベルの各々は、既知の長期リンクのタグと関連付けされた参照データ記録との比較のための指定組のデータ属性によって規定されており、前記マッチングレベルの階層構造は、各々の前記マッチングレベルにおける前記データ属性のマッチングの有効性に応じて編成され、前記マッチングレベルの階層構造は、指定組の英数字の識別コード属性によって各々のマッチングレベルが規定される第１の組のマッチングレベル、及び、デモグラフィック属性を含む指定組の属性によって各々のマッチングレベルが規定される第２の組のマッチングレベルを含み、
前記長期のデータベースにリンクされる新規の対象のデータ記録の各々は、まず、前記第１の組のマッチングレベルにおけるレベル毎に、既存の参照データ記録と比較され、マッチングする参照データ記録が見つけられる場合に、前記参照データ記録と関連付けられている長期リンクのタグを割り当てられ、
前記第１の組のマッチングレベルにおいて、マッチングする参照データ記録が見つけられず、かつ、少なくとも関連するデモグラフィック属性が、前記新規の対象のデータ記録に与えられている場合に、前記新規の対象のデータ記録の各々は、前記第２の組のマッチングレベルにおけるレベル毎に、既存の参照データ記録と比較され、マッチングする参照データ記録が見つけられる場合に、前記参照データ記録と関連付けられている長期リンクのタグを割り当てられ、
前記第２の組のマッチングレベルにおいて、マッチングする参照データ記録が見つけられないか、関連するデモグラフィック属性が、前記新規の対象のデータ記録に与えられていない場合に、前記新規の対象のデータ記録の各々は、新規の長期リンクのタグを割り当てられる、長期のデータベース。
【請求項１２】
前記新規の対象のデータ記録が、指定組のデモグラフィック属性の比較において前記第２の組のマッチングレベルのみで前記参照データ記録と首尾よくマッチングし、前記首尾よくマッチングした前記参照データ記録と関連付けられている前記長期リンクのタグを割り当てられる、請求項１１に記載の長期のデータベース。
【発明の詳細な説明】
【技術分野】
【０００１】
この出願は、２００４年７月２８日に出願された米国特許仮出願第６０／５９１，７３４号明細書、及び関連する米国特許出願第１１／１２２，５８９号明細書、米国特許出願第１１／１２２，５８１号明細書、米国特許出願第１１／１２２，５６４号明細書、及び、米国特許出願第１１／１２２，５６５号明細書（全て２００５年５月５日に出願された出願）の利益を主張するものであり、これら全ての出願の内容は、本出願の明細書の内容に取り込まれる。
【０００２】
本発明は、個々において、個人の健康情報又はデータについての管理に関する。特に、本発明は、個人のプライバシを保持しながら、長期のデータベースにおける、そのようなデータのアセンブリ及び使用に関する。
【背景技術】
【０００３】
患者の健康記録の電子データベース化は、商業利用及び非商業的利用の双方に役立つものである。例えば、長期（寿命期間）の患者記録データベースは、疫学的に、又は、時間傾向、因果関係、又は、ある母集団における健康事象の発生率の分析として他の母集団ベースの研究に用いられる。長期のデータベースでアセンブリされた患者記録は、複数のソースから、様々なフォーマットで収集されることが考えられる。患者健康記録の明白なソースは、現代においては健康保険業界であり、その業界は、医療サービスプロバイダに対して保険金を与えるために、電子通信化した患者のトランザクション記録を広く頼りにしている。医療サービスプロバイダ（例えば、薬局、病院または診療所）、又は、医療サービスプロバイダのエージェント（例えば、データクリアリングハウス、プロセッサ又はベンダー）は、個別に特定された患者トランザクション記録を、補償金のために保険業界に供給する。患者トランザクション記録は、個人情報データのフィールド、即ち属性に加えて、例えば、診断、処方箋、治療内容又は治療結果などの他の情報を含むことができる。複数のソースから取得したそのような情報は、長期の研究に対して貴重となる場合がある。しかしながら、個人のプライバシを保護するために、長期のデータベース装置に統合される患者記録を、“匿名化”、即ち“非識別化”することが重要である。
【０００４】
データ供給者、即ちデータ・ソースは、転送前に患者プライバシを保護するために、患者トランザクション記録の個人情報データのフィールド、即ち属性（例えば、名前、社会保障番号、住所、ジップコードなど）を除去又は暗号化できる。患者プライバシを保護するために、ある個人情報データのフィールドの暗号化又は標準化は、現在、法令と政令によって規制されている。個人の民事的権利に対する関心事は、電子取引における、個人情報の収集についての政府規制と個人の健康データの使用に向けられている。例えば、「医療保険の相互運用性と説明責任に関する法律（１９９６年）（ＨＩＰＡＡ法）」の下で発行された規制は、個人的な健康情報のセキュリティ及び秘匿性をセーフガードするように、緻密な規則を含む。ＨＩＰＡＡ規制は、健康保険プラン、ヘルスケア・クリアリングハウス、及び、ある財政用及び管理用のトランザクション（例えば、登録、支払い、及び適正検査）を電子的に行うヘルスケア・プロバイダなどのエンティティをカバーしている。(例えば、http://www.hhs.gov/ocr/hipaa 参照)。２００４年７月１５日に出願された、米国特許出願第１０／８９２，０２１号明細書は、本出願の明細書の内容に取り込まれるものであるが、政令のＨＩＰＡＡ規制又は他の組のプライバシ規則に従って標準化されたフォーマットで個人的な健康情報を収集及び使用するシステム及び方法について、説明されている。
【０００５】
患者のプライバシの侵害についてのリスクを更に最小化するために、長期のデータベースを構成するように用いられる患者記録から、全ての患者識別情報を分離又は除去することが望ましいとも考えられる。しかしながら、患者識別情報をデータ記録から分離し、患者識別情報を完全に“匿名化”することは、格納されたデータ記録又はフィールドが、患者毎に必ず更新される長期のデータベースの構成に対して、互換性がなくなる場合がある。
【０００６】
２００５年５月５日に出願された、共通して所有される米国特許出願第１１／１２２，５８９号明細書の内容は、本明細書の内容に取り込まれ、複数のソースから取得した患者データ記録が、患者プライバシの侵害の如何なるリスクも生じさせることなく、個々の患者毎に長期のデータベースへと統合されることを可能とする解決策について開示されている。
【０００７】
米国特許出願第１１／１２２，５８９号明細書に開示される解決策は、複数の暗号鍵を用いて２ステップの暗号化手順を用いる。その手順は、データ・ソース、即ちデータ供給者（“ＤＳ”）、長期のデータベース装置（“ＬＤＦ”）、及び、第三者実装パートナー（“ＩＰ”）を包含する。ＩＰは、暗号鍵管理人としても機能し、装置コンポーネントサイトで動作することができる。第１のステップで、各ＤＳは、患者記録において選択したデータ・フィールド（例えば、患者識別属性及び／又は他の標準的な属性データ・フィールド）を暗号化し、患者記録を第１の“匿名化した”フォーマットに変換する。各ＤＳは、２つの鍵（即ち、ベンダー特定鍵と、特定のＬＤＦで関連付けられた共通の長期鍵）を用いて、選択したデータ・フィールドを二重暗号化する。二重暗号化したデータ記録は、装置コンポーネントサイトに送信される。ここで、ＩＰは、更に、二重暗号化したデータ記録を処理できる。データ記録は、第２の匿名化したフォーマットへと処理され、第２の匿名化したフォーマットは、データ記録が元の暗号化していない患者の識別情報を復元することなく、個々の患者毎にリンクされることを可能とするように構成される。このため、ＤＳから受信した患者記録の二重暗号化したデータ・フィールドは、特定のベンダー鍵を用いて部分的に解読される（この際に、二重暗号化したデータ・フィールドは、共通の長期鍵暗号化をまだ保持している）。第３の鍵（例えば、トークン・ベースの鍵）は、長期のデータベースにおいて用いられる、新たな単一の（共通の長期鍵で）暗号化したデータ・フィールド、即ち属性を更に作成するように用いることができる。長期のデータベースに対して内部的となる長期の識別子（ＩＤ）又はダミーラベルは、データ記録をタグ付けするように用いることができ、これにより、データ記録は、元の暗号化していない患者の識別情報の知識なく、長期のデータベースにおいて個々のＩＤ毎にマッチングさせ、リンクさせることができる。（図１参照）
【０００８】
マッチングアルゴリズムについて開示されている２００５年５月５日に出願された、共通に所有される米国特許出願第１１／１２２，５６４号明細書は、本明細書の内容に取り込まれ、本マッチングアルゴリズムは、新規又は前に規定したＩＤが一組の暗号化したデータ属性に割り当てられるべきであるか否かを決定するように用いることができる。一旦、新規又は前に規定したＩＤが割り当てられると、そのＩＤは、詳細なトランザクション情報を含んでいる完全なデータ記録にタグ付けし直してリンクさせるように用いることができる。本マッチングアルゴリズムは、患者データ記録を参照データ記録とマッチングさせることにより、長期リンクのタグを非識別化した患者データ記録に割り当てる。非識別化した患者データ記録は、暗号化及び非暗号化したデータ属性の双方を含むことができる。データ属性の種々に組み合わせ可能なサブセットは、階層構造のレベルでカテゴリ化することができる。データ・フィールド値のサブセットは、１回当たり１レベルずつ参照データ記録と比較される。データ・フィールド値のサブセットについての首尾よい比較、即ちマッチングに基づいて、マッチングした参照データ記録と関連付けられる、長期リンクのタグは、割り当てられる非識別化したデータ記録に割り当てられる。マッチングが見つからない場合、新規の長期リンクのタグを作成し、非識別化したデータ記録に割り当てる。新規のタグ、及び対応するデータ記録の各属性は、更なるマッチング動作のために参照データ記録に加えられる。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
様々なデータ・ソースから生成又は受信した患者データをマッチングする処理に対して、更なる考慮がここに与えられる。例えば、患者のデータ記録のリンク化が、異なる薬局に渡って同一の患者にサービスすることを可能とするマッチング処理及びロジックに対して注意を向けている。
【課題を解決するための手段】
【００１０】
本発明は、マルチソースの患者ヘルスケア・トランザクション記録から長期のデータベースをアセンブリするマッチング処理及びマッチングアルゴリズムを提供する。患者ヘルスケア・トランザクション記録は、患者の識別性又は個人情報について、無許可又は不注意の開示を防ぐために、非識別化される。非識別化した患者ヘルスケア・トランザクションデータ記録は、１つ以上のデータ属性を含むことができ、例えば、英数字の識別コード属性、第三者属性、及び／又は、患者ヘルスケア・トランザクションに関するデモグラフィック属性などを含むことができる。
【００１１】
マッチング処理及びマッチングアルゴリズムは、入ってくるデータ記録に与えられている選択組のデータ属性（デモグラフィック属性の組を含むことができる。）を、既存の参照データ記録における対応する組のデータ記録と、逐次的に比較するように構成している。マッチングする参照データ記録が見つけられる場合には、マッチングする参照データ記録と関連付けられている長期リンクのタグが、入ってくるデータ記録に割り当てられる。
【００１２】
マッチング処理では、入ってくる非識別化した患者記録（対象のデータ記録）を、階層構造のマッチングレベルで参照データ記録に対してマッチングさせる試みが為される。各マッチングレベルでは、指定組のデータ属性が評価される。各マッチングレベルは、対象のマッチング記録に含めることができる英数字の識別コード（例えば、供給者の患者ＩＤ、供給者ＩＤ、小売店ＩＤ及びＲｘ番号）の比較を含む。対象のデータ記録が、早めのマッチングレベルで、参照データ記録に対してマッチングしない場合には、後のマッチングレベルは、対象のマッチング記録に含めることができる１つ以上のデモグラフィック属性（例えば、保険カード番号、ＤＯＢ、性別、患者ジップ（Ｚｉｐ）、姓、名、アドレス番号など）の比較を含むことができる。
【００１３】
階層構造のマッチングレベル及び比較のために指定される関連組の属性は、特定のデータ属性又はデータ属性の組について、マッチングの有効性を考慮して選択される。特定のデータ属性又はデータ属性の組についてのマッチングの有効性は、テスト的なデータ記録を用いた、試し動作（trial run）で経験的に定めることもできる。
【００１４】
好適なコンピュータプログラムで実現可能なマッチング処理例は、階層構造のレベル（例えば１〜１３）で行なわれる。これらのうち１１個のレベル（例えば、レベル１〜４及び６〜１２）で、本処理は、データ属性値を比較することにより、非識別化した患者記録を参照データ記録に対してマッチングを試みる。マッチングが見つかれば直ちに、マッチングした記録の長期の患者ＩＤを入ってくる記録に割り当て、マッチング処理を継続させない。中間レベル（例えば、レベル５）では、マッチング処理は、入ってくるデータ記録を評価して、ほぼマッチングするレベルでマッチング成功の見込み度を示すことができる、関連するデモグラフィックデータ属性（例えば、ＤＯＢ）の存在を確かめることができる。そのような関連するデモグラフィック属性が存在する場合、残りのマッチングレベルで、マッチング処理を継続させることができる。入ってくるデータ記録が、如何なる既存の参照データ記録ともマッチングしない場合には、入ってくるデータ記録に新たに生成した内部的な識別子を割り当てることができる（例えば、レベル１３で）。
【００１５】
本発明のマッチング処理は、ヘルスケア又は製薬の業界で用いられる長期の患者データベース（例えば、ＬＲｘデータベース）の情報量を豊かにできる。例えば、２つの薬局間で流通する、非識別化した患者についての非識別化したＲｘ記録は、同一のＩＤに対して認識又はリンクさせることができる。以前、これらのＲｘ記録は、二人の異なる者に対してリンクされていたはずである。ここで、ＬＲｘデータベースは、ビジネスのソース（例えば、新スタート、再スタート、継続患者など）、治療パターン（例えば、単剤療法（mono therapy）、併用療法(combination therapy)、及び追加併用療法(add-on therapy)）、及びセラピー・進行状況（例えば、第１、第２及び第３ライン、療法の長さ、過去の療法(lapsed therapy)／中止した療法の使用、残留性（persistency）及びコンプライアンス(compliance)、タイトレーション(titration)及び薬剤投与(dosing)、及び一般的な患者の特徴）など患者中心の基準を含むように好適にアップグレードできる。
【００１６】
本発明の更なる特徴、その本質、及び様々な利点は、以下の詳細な説明及び図面か明らかとなり、ここに、同様な参照番号は、同様の要素を示している。
【発明を実施するための最良の形態】
【００１７】
内部的な長期リンクの識別子又はタグを、非識別化した患者トランザクションデータ記録に割り当てるマッチングアルゴリズムを提供する。割り当てられた長期リンクの識別子でタグ付けしたデータ記録は、識別子毎に容易にリンクさせることができ、個々の患者を識別し得る個人情報をアクセスすることなく、長期のデータベースをアセンブリすることができる。マッチングアルゴリズムは、新規又は前に規定したＩＤを一組の暗号化したデータ属性に割り当てるべきか否かを決定するように用いることができる。一旦、新規又は前に規定したＩＤが割り当てられると、そのＩＤは、詳細なトランザクション情報を含む完全なデータ記録にタグ付けし直してリンクさせるように用いることができる。
【００１８】
長期のデータベースのアセンブリに関して、まず、患者トランザクションデータ記録は、データ記録のデータ・フィールドが標準化した共通のフォーマットとなるように処理され、次に暗号化される。データ記録は、選択組のデータ属性に対応する少なくとも１つ以上のデータ・フィールドを含む。選択組のデータ属性は、暗号化されていないときに患者識別となるトランザクション属性、更に患者識別とならない他のトランザクション属性を含むことができる。本発明のマッチングアルゴリズムは、データ記録内の暗号化した属性の値を評価し、それに応じて内部的な長期リンクの識別子をデータ記録に割り当てる。そのような評価には、好適な長期リンクの識別子を割り当てるために、繰り返し評価、参照比較、確率論的又は他の統計学的な技法を含めることができる。評価される選択組のデータ属性は、適切な長期リンクの識別子をデータ記録に割り当てる際に生じる誤差を低減する観点から選択される。
【００１９】
本発明のマッチングアルゴリズムを（本明細書の内容に取り込まれる米国特許出願第１１／１２２，５８９号明細書に説明される）有効な解決策の内容に関して、以下説明する。本発明のマッチングアルゴリズムは、マルチソース化した患者データ記録を、個々の患者ごとに、患者のプライバシの侵害のリスクを生じることなく、長期のデータベースに統合する。尚、その解決策は、図示のためにのみに参照されるべきものであり、本発明のマッチングアルゴリズムは、非識別化したデータ記録を長期のデータベースに統合する他の解決策のアプリケーションを容易に見出すことができるものであることは明らかである。
【００２０】
以下に説明する本発明について、完全に理解するために、米国特許出願第１１／１２２，５８９号明細書に説明されている解決策の詳細な説明を、以下に説明する。米国特許出願第１１／１２２，５８９号明細書で表される図１は、マルチソース化した患者データ記録から長期のデータベースをアセンブリする一例の解決策１００のシステムコンポーネント及び処理を示す。複数の暗号鍵を用いる２ステップの暗号化手順が、患者データ記録を非識別化するために用いられる。解決策５００は、データ・ソース、即ちデータ供給者（“ＤＳ”）、長期のデータベース装置（“ＬＤＦ”）、及び第三者実装パートナー（“ＩＰ”）及び／又は鍵管理人を含む。第１のステップで、各ＤＳは、患者記録の選択したデータ・フィールド（例えば、患者を識別する属性及び／又は他の標準的な属性のデータ・フィールド）を暗号化し、その患者記録を第１の“匿名化した”フォーマットへと変換する。各ＤＳは、２つの鍵（即ち、ベンダー特定鍵、及び特定のＬＤＦと関連付けられる共通の長期鍵）を用い、その選択したデータ・フィールドを二重暗号化する。二重暗号化したデータ記録は、装置コンポーネントサイトに送信される。ここで、二重暗号化したデータ記録は更に処理される。データ記録は、第２の匿名化したフォーマットへと処理され、第２の匿名化したフォーマットは、データ記録を、元の暗号化していない患者識別情報を復元することなく、個々の患者毎に効果的にリンクさせることができるように構成される。
【００２１】
このため、ＤＳから受信した患者記録の二重暗号化したデータ・フィールドは、特定のベンダー鍵を用いて、部分的に解読する（二重暗号化したデータ・フィールドが、まだ共通の長期鍵の暗号化を保持するように）。更に、長期のデータベースにおいて使用するための、新たな単一の（共通の長期鍵で）暗号化したデータ・フィールド又は属性を作成するように、第３の鍵（例えば、トークン・ベース鍵）を用いることができる。ＬＤＦに対して内部的となる、長期の識別子（ＩＤ）又はダミーラベルは、データ記録をタグ付けするように用いることができ、タグ付けしたデータ記録は、元の暗号化されていない患者識別情報の知識無く、長期のデータベースにおいて個々の患者毎にマッチングさせ、リンクさせることができる。
【００２２】
好適なマッチングアルゴリズムは、前に規定したＩＤ又は新規のＩＤを、一組の暗号化した属性に対して割り当てるべきか否か決定するように用いることができる。一旦、ＩＤが決定されると、そのＩＤは、暗号化した属性を伴う処理を通過した一組の認証されたマッチングする属性を用いて、データ供給者からの詳細なトランザクションデータに対してリンクし戻される。次に、暗号化したデータ属性及び割り当てたＩＤは、更なるマッチング処理における使用のために参照データベース内に格納される。
【００２３】
本発明によれば、データ記録における、ある選択組の属性／フィールドは、入ってくるデータ記録に対してＩＤを割り当てるために、その入ってくるデータ記録を、長期の参照データベースに格納される参照データ記録とマッチングさせるのに用いられる。マッチング・ルール及びマッチング処理は、入ってくるデータ記録を、増加的にレベル毎に（即ち、属性毎に）マッチングするように設けられる。マッチング・ルール及びマッチング処理は、無関係の薬局又はベンダーから受信した患者の記録をリンクさせることを可能とする。
【００２４】
暗号化した患者の変数のわずか（例えば、小売店（例えば、開業されている薬局）、患者の性別及び患者の生まれた年、から非識別化した患者ＩＤ）を用いる従来のマッチング処理は、非識別化した患者ＩＤのみのマッチングによって、患者記録を小売店内でリンクするように用いることができる。本発明のマッチング処理は、追加数となる、現在利用可能な暗号化した非識別化した患者データ属性（例えば、完全な生年月日、保険カードＩＤ、姓、名、ジップコードなど）を用いる。これらの暗号化した変数は、小売店、供給者、及び他のデータ・ソースを渡って、非識別化した患者記録のリンクを可能とする。本発明のマッチング処理は、患者が引越し又は患者の姓が変更になった場合でさえ、患者のデータ記録を識別し、リンクすることができる。
【００２５】
マッチング処理の一例において、入ってくる非識別化した患者記録を、参照データベース内の既存のデータ記録とマッチングさせる試みが為される。その試みは、階層構造のマッチングレベル（例えば、１３レベル）で逐次的に為される。階層構造の一例の１３レベルの各々で、入ってくる非識別化したデータ記録を、参照データベース内の記録に対してマッチングさせる試みが為される（即ち、入ってくる非識別化したデータ記録を、既存の長期ＩＤと関連付けるためである）。首尾よくマッチングするものがあれば、非識別化した患者記録は、マッチングした参照データ記録と関連付けられるＩＤが割り当てられる。首尾よくマッチングするものが無ければ、非識別化した患者記録は、新たな患者ＩＤ（“長期のＩＤ”）を割り当てることができる。マッチングレベルの各々は、長期のＩＤに対する非識別化した患者記録をリンク又はマッチングさせるために、種々の組み合わせのデータ属性を用いる。表１は、ＩＤを割り当て、本処理によってリンクすることが可能な患者記録・データ記録に含めることができる製薬上のデータ属性の一例の組をリストしたものである。
【００２６】
【表１】
0005401037.tif 000002
【００２７】
表１にリストする１３個のデータ属性の幾つか（例えば、供給者の患者ＩＤ、供給者ＩＤ、小売店及びＲｘ＃）は、患者識別情報について、明らかとならないものであるか、或いは少なくとも直接的に明らかとならない属性とできる。これらの属性の値は、データ記録において暗号化される必要はない。他の属性は、機密の患者識別情報（例えば、ＮＣＰＤＰ ＩＤ、患者の完全な生年月日（ＤＯＢ）、患者の保険カードＩＤ、患者の性別、患者のジップ（５桁）、患者の姓、患者の名、及び患者のアドレス番号）に関連するものとできる。そのような属性の値は、データ記録において暗号化される。全ての暗号化したデータ・フィールド／属性は、暗号化される前では、好適な標準のフォーマットとすることができる。例えば、欠落及び無効となる値を識別でき、それぞれキャラクタ“Ｂ”と“Ｉ”でコード化することができる。“＆”、“％”、“｛”、及び“＾”などの特別なキャラクタは、データ記録から除去できる。先行する空白又はゼロを除去でき、データ・フィールドの左右揃えをすることができる。更に、全てのキャラクタを大文字（又は小文字）に置換できる。
【００２８】
図２a及び２ｂは、“供給者内”のマッチング処理２００及び２００’の一例のステップを示し、各処理は、ＩＤをデータ供給者から取得した患者トランザクションデータ記録に割り当てるように用いることができる。供給者ＩＤ番号（例えば、供給者ＩＤ ２１０）は、特定のデータ供給者を識別するように用いることができる。マッチング処理２００及び２００’は、長期のデータベース（例えば、解決策１００、図１）をアセンブリするのに好適ないずれかの解決策の構成内で実現することができる。マッチング処理２００及び２００’は、データ供給者の暗号化した属性及び他のデータ供給者の標準化した属性を含めることができる、入ってくる患者トランザクションデータ記録を処理するように構成される。その入ってくる患者トランザクションデータ記録は、表１に示す１３の個の属性の幾つか又は全てを含めることができ、更に、表１に示されていない他の属性を含めることができる。データ記録に含められる特定の属性は、データ供給者の採択又は能力に依存するものとできる。マッチング処理２００及び２００’は、入ってくるデータ記録を参照データベースに格納されている参照データ記録と比較する。入ってくるデータ記録における統計的にかなりの数のデータ属性／フィールドが、特定の参照記録における対応するデータ属性／フィールドとマッチングする場合には、入ってくるデータ記録には、特定の参照記録と関連付けられたＩＤを割り当てる。
【００２９】
マッチング処理２００及び２００’は、表２と関連して図２ａから理解することができる。表２は、参照データベース内の参照データ記録の対応する組み合わせと比較可能な、入ってくるデータ記録の属性の１３個の組み合わせの一例（マッチングレベル１〜１３）をリストしている。各レベルは、データ記録が統計的に有効な方法でマッチングさせることができるように構成される。レベル１〜４は、データ記録において、個々の患者、データ供給者、販売店及び他の当事者を指定するように用いられる固有の数字又は英数字の識別コードなどの属性値でマッチングを試みる。レベル１〜３は、個々のデータ供給者の患者内でマッチングを試みることができる。レベル４は、データ供給者内の場合、及び、横断するデータ供給者の場合の双方でマッチングを試みることができる。レベル５は、マッチング処理を続けるために、入ってくる記録が、十分なデモグラフィックデータ又は情報を含むか否かを確かめることができる。入ってくる記録が、十分なデモグラフィックデータ又は情報を含んでいなければ、マッチングの試みを中止して、新規な長期のＩＤを入ってくる記録に割り当てることができる。入ってくる記録が、十分なデモグラフィックデータを含んでいれば、より高いマッチングレベルへと進む。レベル６〜１２は、様々な組み合わせのデモグラフィック変数に基づいて、横断するデータ供給者に対するマッチングの試みを含んでいる。これらのレベルのほとんどに対して、入ってくる記録は、少なくとも５〜７のデモグラフィック変数でマッチングしなければならない。唯一の例外はレベル７であり、レベル７では、入ってくるデータ記録が、３つの変数のみでマッチングさせることができる。なぜなら、レベル７は、他のデモグラフィック変数よりも、より固有なものとなる保険カードを利用するためである。入ってくる非識別化した患者記録が、レベル１２で首尾よくマッチングしない場合には、その非識別化した患者記録に、新規の長期／患者ＩＤを割り当て、又は関連付けることができる。
【００３０】
【表２−１】
0005401037.tif 000003
【００３１】
【表２−２】
0005401037.tif 000004
【００３２】
データ属性は、マッチングが見つかるまでの階層的な系列で組み合わせ毎に（即ち、レベル毎に）、評価した組み合わせとできる。表１にリストされる特定の組み合わせの属性は、一例を示すものであることは明らかである。データ記録のマッチング処理について様々な実現例では、これらの組み合わせの幾つか又は全て、及び／又は他の所望される又は適切な組み合わせを用いることができる。
【００３３】
図２ａを参照して、マッチング処理２００の予備のステップで、入ってくる“対象の”データ記録内の符号化した供給者ＩＤの属性は、特定のデータ供給者ＩＤと関連付けられる供給者ＩＤ ２１０と比較される。対象のデータ記録が、供給者ＩＤ ２１０で符号化されていない場合、対象のデータ記録は、マッチング処理３００（図３ａ）に転送される。マッチング処理３００は、異なるデータ供給者に渡って患者記録をマッチングさせることができる。
【００３４】
対象のデータ記録が、供給者ＩＤ ２１０で符号化される場合、ステップ２２０で、処理２００は、データ供給者（即ち、供給者ＩＤ ２１０）によって対象のデータ記録に含めることができる、何らかの患者識別番号を評価する。データ供給者は、患者データ記録を識別するために、普遍的な、即ち“横断する供給者”の患者識別番号、又は他の固有の識別番号を含めることができる。普遍的な患者識別番号が、対象のデータ記録内に与えられている場合に、参照データ記録内の患者識別番号と比較される。普遍的な患者識別番号が、参照データ記録内の患者識別番号とマッチングする場合、レベル１のマッチングが宣言される。データ供給者が、普遍的な患者識別番号の代わりに、小売店の特定の患者識別番号を含める場合、ステップ２２０で、対象のデータ記録内のその小売店の特定の患者識別番号及び小売店の属性が、参照データ記録内のそれらと比較される。これら２つのデータ属性について首尾よくマッチングした場合には、レベル２のマッチングが宣言される。或いは又、ステップ２２０で、対象のデータ記録にて普遍的な患者識別番号又は小売店の特定の患者識別番号の、いずれも使用しない供給者からのデータに対して、本処理２００は、対象のデータ記録内の小売店及び処方箋番号の属性と、参照データ記録内のそれらとの比較による首尾よいマッチングに基づいて、ステップ２２０で、レベル３のマッチングを宣言するように構成させることができる。首尾よいレベル１、２及び３のマッチングで、対象のデータ記録には、マッチングした参照データ記録と関連付けられる長期のＩＤが割り当てられる。参照データ記録に対するマッチングが、ステップ２２０で全く得られない場合には、処理２００は、より高いレベルのマッチングを試みる。
【００３５】
ステップ２３０で、処理２００は、対象のデータ記録に与えることができる、何らかのＮＣＰＤＰの患者ＩＤについてのＮＣＰＤＰ資格付与者を調べる。ＮＣＰＤＰ資格付与者が、標準の保険タイプ０１、０２又は０３（例えば、社会保障番号、軍事ＩＤ番号、又は、運転ライセンス番号のそれぞれに対応する）であれば、ステップ２４０で、処理２００は、対象のデータ記録内に与えられるＮＣＰＤＰ患者ＩＤと、参照データ記録内のそれらとを比較する。処理２００は、対象のデータ記録内のＮＣＰＤＰ患者ＩＤと参照データ記録内のそれとを比較して首尾よいマッチングに基づいて、レベル４のマッチングを宣言するように構成させることができる。ステップ２３０で、処理２００が、ＮＣＰＤＰ患者ＩＤが与えられていない、又は、標準の保険タイプ０１、０２又は０３のものではないと決定する場合、処理２００は、ステップ２５０へと進み、対象のデータ記録に与えることができる追加のデータ属性（例えば、ドモグラフィックデータ属性）を評価することができる。例えば、ステップ２５０で、対象のデータ記録に与えられている３つの属性（例えば、保険カード番号、生年月日（ＤＯＢ）、及び性別の属性）からなる組を、参照データ記録内のそれらと比較することができる。処理２００は、対象のデータ記録に与えられているこれら３つの属性と参照データ記録内のそれらと比較して首尾よくマッチングに基づいて、レベル７のマッチングを宣言するように構成させることができる。処理２００は、予備のステップ（図示せず）で、まだマッチングしていない対象のデータ記録が、関連する又は重要な追加のデータ属性（例えば、ＤＯＢ属性）を含んでいることを確認した後にのみ、ステップ２５０へと進み、追加のデータ属性を評価することができる。
【００３６】
ステップ２５０で用いられる３つの属性の組は、保険カード番号及びＤＯＢなどの、数値を有する属性を含む。これらの属性のうち１つを含んでいない対象のデータ記録（即ち、保険カード番号が欠落）を処理するために、処理２００は、データ供給者から取得した患者トランザクションデータ記録にこの時点で共通して含まれている追加のデータ属性に基づいて、対象のデータ記録のマッチングを試みる。ステップ２６０で、処理２００は、対象のデータ記録に与えることが可能な５つのデモグラフィック属性の組の値を、参照データ記録内のそれらと逐次的に比較することにより、対象のデータ記録のマッチングを試みる。５つのデモグラフィック変数の組の例は、共通して３つの属性（即ち、ＤＯＢ、性別、姓の属性）、及び、４つの属性（名、ジップコード、処方者名、アドレス番号）のグループから選択した２つの追加の属性を含む。図２ａは、対象のデータ記録のマッチングに逐次的に用いられる５つのデータ属性についての６つのそのような組を示す。本処理２００は、対象のデータ記録に与えられている５つのデータ属性のそのようないずれかの組と、参照データ記録内のそれらと比較して首尾よいマッチングに基づいて、マッチング（例えば、レベル８〜１２又はそれ以上の高いレベル）を宣言するように構成させることができる。
【００３７】
或いは又、処理２００は、変更したステップ２６０’で、対象のデータ記録に与えることが可能な４つのデモグラフィック属性の値と参照データ記録内のそれらとの逐次的な比較によって、対象のデータ記録をマッチングするように構成させることができる。４つのデモグラフィック変数の組の例は、共通して、３つの属性（ＤＯＢ、性別、及び姓）、及び、４つの属性（名、ジップコード、処方者名、及びアドレス番号）のグループから選択した１つの追加の属性を含んでいる。図２ａは、対象のデータ記録をマッチングするのに逐次的に用いる、４つのデータ属性の４つのそのような組を示す。処理２００は、対象のデータ記録に与えられる４つのデータ属性のそのようないずれかの組と、参照データ記録内のそれらと比較して首尾よいマッチングに基づいて、マッチングを宣言するように構成させることができる。
【００３８】
ステップ２１０〜２６０又は２６０’で、首尾よいマッチングが見つけられない場合には、処理２００は、新規な患者に属するとして、対象のデータ記録を認識するように構成され、それに従い、新規なＩＤタグを対象のデータ記録に割り当てるように構成される。新規なＩＤタグは、対象のデータ記録を、長期のデータベースの逐次的にマッチングしたデータ記録にリンクさせるように用いることができる。
【００３９】
本処理２００にて、数字又は英数字の識別コードの属性に基づくマッチングを含むステップ２１０〜２３０は、低リスクの誤検知の結果を与える。第三者データ（例えば、保険カード番号）に基づくマッチングを含むステップ２５０は、適度のリスクの誤検知の結果を与える。デモグラフィックデータに基づくマッチングを含むステップ２６０は、増大したリスクの誤検知の結果を与える。マッチング処理２００は、データ処理のステージなしで、ＬＤＦ（又は任意の他の無許可のエンティティ）が患者識別可能なデータを見ることができるような、プライバシ要件と互換性がある。例えば、ＬＤＦは、ある患者（例えば、Mr. XXY&^%FR21gywt30Jjokiau76gfs545aなどの長期ＩＤによってのみ識別される患者）が複数の薬局又は販売店に通っていたことを知ることができる。しかしながら、ＬＤＦは、複数の販売店に通っていた特定の“Mr. John Smith”を知ることはなく、識別することはできない。
【００４０】
図２ｂは、長期のデータベースに包含させる対象のデータ記録を処理するように用いることができる別のマッチング処理２００’を示す。本処理２００’は、ＩＤを対象のデータ記録に割り当てることについて、処理２００とは、デモグラフィックデータ属性の異なる組み合わせを用い、異なる論理的フローのマッチングステップを用いる。処理２００のように、本処理２００’は、特定のデータ供給者（例えば供給者ＩＤ ２１０）からデータ記録を処理するように構成されるが、首尾よいマッチングを確かめるために、追加のステップを含む。処理２００’のステップ２１０〜２４０にて、処理２００と同様なステップは、値として英数字の識別コードを有するデータ属性の検討を含むが、確認するステップ２７０が後に続く。ステップ２１０〜２４０で、参照データ記録に対する対象のデータ記録の如何なる首尾よいマッチングも、対象データ記録のＤＯＢ及び性別の属性が、マッチングした参照データ記録内のそれらと同一であることをチェックすることにより、ステップ２７０で確かめられる。
【００４１】
更に、本処理２００’のステップ２３０は、ＮＣＰＤＰ患者ＩＤが与えられておらず、標準の保険タイプ０１、０２又は０３のものではないと決定する場合、本処理２００’は、ステップ２４５〜２９５、２６０及び２６０’に進み、対象のデータ記録に与えられうるデータ属性の追加の組を評価する。ステップ２４５〜２９５、２６０及び２６０’で検討したデータ属性の組は、処理２００のステップ２５０〜２６０’で検討したそれらとは異なるものとできる。ステップ２４５で、本処理２００’は、対象のデータ記録に与えられうる小売店識別の属性及び販売店特定の患者識別の属性についてマッチングを試みる。ステップ２５５で、本処理２００’は、対象のデータ記録の患者に与えられうる小売店識別の属性及び処方箋番号の属性についてのマッチングを試みる。双方のステップでの首尾よいマッチングは、更に、首尾よいマッチングが宣言される前に、確認するステップ２７０で確かめられる。
【００４２】
更に、小売店識別の属性及び処方箋番号の属性について少なくとも１つを含まない対象のデータ記録を処理するために、本処理２００’のステップ２８０は、３つの属性（保険カード番号、ＤＯＢ、及び性別）の組を評価することによって、対象のデータ記録のマッチングを試みる。参照データ記録で如何なるマッチングも見つけられない場合には、処理２００’のステップ２９０は、首尾よいマッチングを宣言する前に、マッチングする参照データ及び対象のデータ記録が同一の姓及びジップコードの属性を有することを確認する。
【００４３】
対象のデータ記録が、保険カード番号の属性を含んでいない場合では、本処理２００’は、対象のデータ記録に与えられうる追加のデモグラフィック属性に基づいて対象のデータ記録のマッチングを試みることができる。ステップ２９５で、本処理２００’は、６つのデータ属性（例えば、ジップコード、ＤＯＢ、名、姓、アドレス番号及び性別）の組の値を比較することにより、参照データ記録に対して対象のデータ記録のマッチングを試みる。ステップ２６０及び２６０’で、本処理２００’は、処理２００のように、５つ又は４つのデータ属性の組の値のそれぞれについて比較することにより、参照データ記録に対して、対象のデータ記録のマッチングを試みる。ステップ２６０での５つのデータ属性の組は、共通して、３つのデータ属性、即ちジップコード、ＤＯＢ及び性別の属性を含んでいる。５つのデータ属性の組のうち、残りの２つの属性は、名、姓及びアドレス番号の属性からの一対の属性として選択される。ステップ２６０’での４つの属性の組は、共通して、２つのデータ属性、即ちＤＯＢ及び性別を含んでいる。４つのデータ属性のうち、他の対となる属性は、（ジップコード、姓）、（ジップコード、アドレス番号）又は（名、姓）のうちいずれかの対の１つとして選択される。
【００４４】
マッチング処理２０００及び２００’は、特定のデータ供給者から受信した対象のデータ記録を処理するように構成される。また、マッチング処理は、如何なる数のデータ供給者からも受信できる複数のソースの対象のデータ記録（に対して処理し、好適な長期ＩＤを割り当てるように構成させることができる。図３ａ及び３ｂは、“横断する供給者”の場合のマッチング処理３００及び３００’のステップ例をそれぞれ示す。マッチング処理３００及び３００’は、処理２００及び２００’のそれぞれと連結して、又は拡張して動作させることができる。
【００４５】
処理３００及び３００’は、処理２００及び処理２００’の予備ステップ２１０において、対象のデータ記録が特定の供給者の供給者ＩＤ ２１０で符号化されていないことを示すときに、開始することができる。処理２００及び２００’とは異なり、“横断する供給者”の場合のマッチング処理３００及び３００’は、供給者の特定の患者識別の属性を比較することによって（例えば、処理２００及び２００’参照）、参照データ記録に対して対象のデータ記録のマッチングを試みることはしない。この相違点とは別にして、処理３００は、参照データ記録に対する対象のデータ記録のマッチングの試みにおいて、処理２００（例えば、ステップ２３０〜２６０及び２６０’）と同一又は同様の属性の逐次的な組み合わせ又はレベルを用いることができる。同様に、処理３００’は、参照データ記録に対する対象のデータ記録のマッチングの試みにおいて、処理２００’（例えば、ステップ２３０〜２９５、２６０及び２６０’）と同一又は同様の属性の逐次的な組み合わせ又はレベルを用いることができる。
【００４６】
デモグラフィック属性を含む複数組の属性の組み合わせに基づいている、階層構造のマッチング処理（例えば、処理２００、２００’、３００及び３００’）は、長期の処方箋データベース（例えば、ＬＲｘデータベース）の情報コンテンツを拡張するために有利に用いることができる。例えば、２つの薬局間を通う非識別の患者についての非識別化したＲｘ記録は、現時点で、同一のＩＤに対して認識又はリンクさせることができるものとなっている。以前、これらのＲｘ記録は、２人の異なる者に対してリンクされていたはずのものである。ここで、ＬＲｘデータベースは、ビジネスのソース（例えば、新スタート、再スタート、継続患者など）、治療パターン（例えば、単剤療法、併用療法、及び追加併用療法、及びセラピー・進行状況（例えば、第１、第２及び第３ライン、療法の長さ、過去の療法／中止したセラピー使用、残留性及びコンプライアンス、タイトレーション及び薬剤投与、及び一般的な患者の特徴）など患者中心の基準を含むように好適にアップグレードできる。階層的なマッチング処理に用いられる、マッチングロジック及び追加の暗号化した属性は、複数の薬局及びヘルスケア・ファシリティ間を通う非識別の患者をリンクすることにより、患者中心の基準の精度を改善させる。本発明のマッチング処理は、プライバシ要件と互換性がある。本マッチング処理は、データ処理のステージなしで、ＬＤＦ（又は任意の他の無許可のエンティティ）が患者識別可能なデータを見ることができるように構成される。例えば、ＬＤＦは、ある患者（例えば、Mr. XXY&^%FR21gywt30Jjokiau76gfs545aなどの長期ＩＤ又はコードによってのみ識別される患者）が複数の販売店に通っていたことを知ることができる。しかしながら、ＬＤＦは、複数の販売店に通っている特定の“Mr. John Smith”を知ることはなく、識別することはできない。
【００４７】
本発明の原理に従って、属性の組み合わせ、階層構造のマッチングレベル、及びマッチング処理に用いられるマッチングロジックは、特定のデータ処理要件又は事情に適切に適合させながら、好適に変更又は変化させることができる。また、マッチングレベルの階層構造のレベルの数は、変更可能である。あるレベルが非効率的であると決定される場合（即ち、多数の非識別の患者をリンクしない）又は異なる順序でマッチングレベルを処理することがより効果的な処理をもたらすことを決定される場合、マッチングロジック及びマッチングレベルの数を変更（例えば、減少）できる。
【００４８】
特定のデータ処理要件又は事情に適合する好適なマッチング処理又はマッチングアルゴリズムの開発は、最善のマッチングアルゴリズム、又はデータ記録における選択組のデータ属性を与えられるマルチソース化したデータ記録から、個々の患者を固有に識別する最善の方法を決定する問題として定性化させることができる。例えば、マッチング処理２００、２００’、３００及び３００’の開発において、１２個のデータ属性の開始組を、参照データ記録に対してマッチングさせる対象のデータ記録において、ユーティリティ用に、及び効率化のために選択し、テストした。１２個のデータ属性の開始組は、標準化したデータ属性、例えば、カードホルダＩＤ、完全な生年月日（ＤＯＢ）、性別、名、姓、アドレス（クリーンにし、標準化したもの）、ジップコード（５桁）、ＮＣＰＤＰ ＩＤ及びＮＣＰＤＰ資格付与者、Ｒｘ番号、小売店、供給者ＩＤ、患者ＩＤ（薬局からのもの）を含ませた。幾つかのデータ属性（例えば、名、姓、アドレス及び患者ＩＤ）は、ヘルスケア・データ供給者から取得されるデータ記録において、ルーチン的(routinely)に暗号化される。当該分野の展開させるためのマッチング処理の評価及び開発は、供給者及び他のデータ暗号化処理の有効性の決定、並びに、アドレス番号の属性を、肯定的な結果を有する完全なアドレス属性の代わりに用いることができるか否かを見るための検討を含むものであった。更に、マッチング処理は、二人の個人としてではなく、一人の個人として、供給者内又は横断する供給者について、２つの異なる薬局又は小売店からの処方薬を購入する患者を識別するように構成される。
【００４９】
マッチング処理のフィールド実現例について、属性又はマッチングレベルの特定の組み合わせ、階層構造のマッチングレベル、及び展開されるマッチングロジックは、論理的又は経験的な考慮に基づいて選択することができる。マッチングで利用される属性の組み合わせ及びタイプは、例えば、参照データ記録とマッチングする対象のデータ記録におけるそれらのポテンシャルに従って選択することができる。処理２００、２００’、３００及び３００’で利用されるマッチングレベル又は属性の組み合わせは、そのような考慮に基づいて選択した。表３及び表４は、長期の処方箋データベース（ＬＲｘ）の場合に、参照データ記録に対する対象のデータ記録のマッチングにおいて、経験的に決定したマッチングの有用性又は有効性を有する、処理２００、２００’、３００及び３００’で用いられる属性の組についてリストしている。表３は、“供給者内”の場合のデータ記録のマッチングに関するものであり（例えば、マッチング処理２００及び２００’）、表４は、“横断する供給者”の場合のデータ記録のマッチングに関するものである（例えば、マッチング処理３００及び３００’）。双方の表において、マッチング処理において用いられるデータ属性及び属性の組み合わせは、マッチング・ポテンシャルに従ってランク付けさせている（例えば、マッチングランクのベスト・マッチング＝１、ワースト・マッチング＝９）。
【００５０】
【表３】
0005401037.tif 000005
【００５１】
【表４】
0005401037.tif 000006
【００５２】
決定論的又は確率論的なマッチング基準又は論理のいずれかをマッチング処理に用いることができ、２つのデータ記録間で比較し、首尾よくマッチングしたことを宣言させる。処理に利用可能なヘルスケア・データ記録では、ほとんどの患者デモグラフィック属性は暗号化されている。更に、ある属性（例えば、姓）が、同一であるべき別の属性（例えば、Smith とSmyth）に対する値において十分に“近い”という状況を判断することは難しい。そのような状況では、対象のデータ記録を参照データ記録と比較する確率論的マッチングロジックを用いることは、誤検知に通じうる。それ故、マッチング処理（例えば、処理２００、２００’、３００及び３００’）は、データ属性を比較するために、正確な、即ち決定論的なマッチングロジックを用いるように構成させることができる。そのようなロジックの下で、２つの患者データ記録を、２値形式でマッチングするか否かを表す。決定論的ロジックを用いて得られる、明確な２値による正又は否の結果は、マッチング処理の実用上の実現に対して有利である。更に、データ記録の比較に関して、完全なアドレス属性の代わりにアドレス番号の属性を用いることは、データ記録のマッチングに有利であることを検討により示された。アドレス番号の使用は、データ記録に完全なアドレスを入力する際に生じうるデータエントリ・エラーを低減させることもできる。
【００５３】
マッチング処理（例えば、処理２００、２００’、３００及び３００’）におけるマッチングレベルの階層構造は、特定のデータ属性（又は属性の組み合わせ）を選択することにより構成させることができ、一致する際に最善の患者マッチングをもたらす。より優れた患者マッチングは、誤検知のより低い見込み度に対応する。階層構造のマッチングレベルは、最小数のデータ属性を要求し、各レベルでテストするように構成させることができる。対象の患者データ記録が、或るレベルで参照データ記録とのマッチングに失敗する場合、マッチング処理は、次のレベルへと移行し、マッチングを検索する。これは、より低いマッチングレベル番号の首尾よいマッチングが、より良いマッチングとなることを意味している。表３及び４は、処方箋データ記録（ＬＲｘデータベース）の場合に“供給者内”及び“横断する供給者”の場合のそれぞれについての首尾よいデータ記録マッチングを宣言する最小のマッチング要件となるように見つけられた、特定の組み合わせの属性を区別して表している。追加の、又は、代わりの属性の組み合わせは、他の状況又は事情で好適に見つけることができる。例えば、処方箋データ記録をリンクするマッチング処理では、マッチングする属性として、“医師”を考慮することが役立つ。
【００５４】
マッチング処理は、マッチングしない状況とは対照的に、データ属性／フィールドが対象データ記録から無効又は欠落しているデータ処理状況をアカウントするように好適に構成させることができる。テーブル５は、２つのデータ記録が同一又は一致する患者に属するときでさえ、２つのデータ記録のデータ属性の値が同一である必要はない（即ち、マッチングしない状況）場合のデータ属性のリスト例である。また、テーブル５には、同一又は一致する患者に属する、２つの対象のデータ記録におけるデータ属性が異なることについて、可能性ある理由を示している。
【００５５】
0005401037.tif 000007
【００５６】
マッチング処理を、コンピュータプログラムとして実現させることができる。本発明によれば、前述したマッチング処理を実現するソフトウェア（即ち、コンピュータプログラム命令）をコンピュータ読取り可能なメディアで提供することができる。各ステップ（本発明に従って前述した）については、これらステップの如何なる組み合わせも、コンピュータプログラム命令によって実現させることができることは明らかである。如何なる好適なコンピュータプログラム言語も本目的のために用いることができる。図４は、患者データ記録を処理するコンピュータ・サブルーチン例４００としてのマッチングアルゴリズムの実現例を示す。サブルーチン４００にて、マッチング・ルールは、一連のネストされたIF-ELSE IF-THENの条件文として、選択組のデータ属性に適用されており、その各々は、あるレベル、即ちテストしたデータ記録（例えば、表１参照）におけるデータ属性の組み合わせに対応している。マッチングアルゴリズムは、９個のレベルの階層構造において１３個の変数を用いる（１３個の変数の組み合わせ）。
【００５７】
コンピュータプログラム命令を、コンピュータ又は他のプログラム可能な装置にロードさせ、マシンを構成させることができ、これにより、コンピュータ又は他のプログラム可能な装置で実行させるコンピュータプログラム命令は、前述したマッチング処理の機能を実現するための手段を作り出す。また、これらのコンピュータプログラム命令をコンピュータ読取り可能なメモリに格納することができ、コンピュータ又は他のプログラム可能な装置を特定の態様で機能するように方向付けることができ、これにより、コンピュータ読取り可能なメモリに格納されるコンピュータプログラム命令は、前述した分布型の推測統計学的なコントローラ及びシステムの機能を実現する命令手段を有する製造物を生成させる。また、コンピュータプログラム命令をコンピュータ又は他のプログラム可能な装置にロードさせ、コンピュータ又は他のプログラム可能な装置で実現させるべき一連の動作ステップを生じさせ、コンピュータ又は他のプログラム可能な装置で実行するコンピュータプログラム命令が、前述したマッチングアルゴリズム及びマッチング処理の機能を実現するステップを与えるように、コンピュータで実現される処理を可能とする。また、前述したマッチングアルゴリズム及びマッチング処理を実現する命令が与えられるコンピュータ読取り可能なメディアは、そのように限定するものではなく、ファームウェア、マイクロコントローラ、マイクロプロセッサ、集積回路、ＡＳＩＣ、及び他の利用可能なメディアを含むことは明らかである。
【００５８】
サブルーチン例４００のプログラムロジックは、対象の入ってくる患者記録が、参照データベースに格納できる参照データ記録と比較されることが想定されている。各マッチングレベル（例えば、比較のために指定されるデータ属性の組）で、サブルーチン４００は、参照データベースをスキャンし、マッチングする参照データ記録を検索する。指定したマッチングレベルのいずれにおいてもマッチング参照データ記録が見つからなければ、サブルーチン４００は、対象の入ってくる患者記録が新規の患者又は新規ＩＤと関連付ける必要があることを決定できる。
【００５９】
本発明のマッチング処理における他のプログラム実現例は、図４に示されているものより、少ないレベル又は多いレベルを含むことができる。例えば、レベル１２は、サブルーチン４００の幾つかのフィールド実現例から除去した。更に、本プログラム実現例は、入ってくるデータ記録の整数をチェックするように構成させた好適なルーチンを含めることができる。例えば、サブルーチン４００は、入ってくるデータ記録におけるデータ属性の無効又は欠落を識別するステップを含むように、変更又は拡張できる。更に、本プログラム実現例は、種々のマッチングロジックで共通のデータ処理する事項を処理するように構成させることができる。例えば、本プログラム実現例のマッチングロジックは、女性患者の姓の変更を許容でき、女性患者の変更した姓を有するデータ記録を、元の姓を有するデータ記録で肯定的にマッチングさせることができる。
【００６０】
本発明のマッチング処理における本プログラム実現例について、データ供給者又はベンダーからのテストデータを用いて、テストし、評価し、最適化することができる。単一のデータ供給者／ベンダー（例えば、McKesson）からのテストデータを用いて、あるプログラム実現例のマッチングロジックについて、以下のようにテストすることができる。
最もマッチングするレベルの判断、及び、マッチング処理のスピードアップのために必要とされるマッチングレベルの階層構造の変更。
各データ属性が、如何に多くＢ、Ｓ又はＩと等しくなるかの判断。
人コード／関係コードがマッチング処理の助けとなるか否かの判断。
各要素から作成されたある長期鍵と対照したものとして、個々の要素でのマッチングにより得られるマッチングがどれほど多く得られるかの判断。
入ってくる記録が、如何に多く参照患者マッチングデータベースにおける１つ以上の記録にマッチングするかの判断。これは、如何に多くＬＤＦが“クリーンアップ”を実行するべきかについて明確な助けとなる。
姓、カードＩＤ、アドレス、及びジップの属性が、或る期間内で単一の患者に対し、如何に多く変更するかの判断。
【００６１】
第２のデータ供給者／ベンダー（例えば、Pharmacy Benefit Management (PBM)データ供給者）からの追加のテストデータを用いて、プログラム実現例のマッチングロジックを、更に以下のようにテストすることができる。
患者が、ある地理的範囲内で、如何に多く第１及び第２のデータ供給者／ベンダー販売店の間を通うかの判断。
この数が、現実的であるか？
他の患者による通いの学習結果から得られたデータと同様であるか？
【００６２】
ＰＢＭから受信したスクリプトデータ（Ｒｘスクリプト）を、プログラム実現例の評価のテスト前に、処理し、間引き、クリーンにできる。スクリプトデータを区別するのに必要なデータは、供給者ＩＤ、小売店番号、保険会社、保険カード番号、ＤＯＢ、姓（オプション）、名（オプション）、性別、及び（Ｒｘ番号、完了日、医師）又は（薬番号、完了日、医師）などの属性を含むことができる。ＰＢＭデータの利用（例えば、薬局を横断する患者のマッチング用）は、ＰＢＭで供給されたデータ属性に依存するものとできる。例えば、ＰＢＭは、小売店の特定のＲｘ番号、完了日、医師、従属のＤＯＢ、性別のデータ属性を供給することができる。従って、プログラム実現例で用いられるマッチングロジックは、そのようなデータ属性に基づくものとできる。実用上、データ供給者に渡って患者マッチングの有用性を判断するために、特定組の属性（例えば、州（State）、国、ＭＳＡ、ジップコード（５桁）及びジップコード（３桁））に注意を向けることができる。また、薬局を横断する患者のマッチング結果は、小売店が、１日に一回以上、同一のＲｘ番号を発行できるか否かに依存するものとできる。
【００６３】
試し動作では、本発明のマッチングアルゴリズム（例えば、サブルーチン４００）は、テストデータセット（即ち、データ供給者ＰＤＸ及びMcKessonから得られる暗号化したデータ記録）に対して評価してみた。表５〜７及び図８A〜８Eは、試し動作の結果を示す。
【００６４】
表５は、LRｘ患者IDを割り当てる最小のマッチング要件として、試し動作で用いたデータ属性の様々な組み合わせに対する効率的なマッチングランクを示す。表６及び７は、共通のデータ処理状態又はシナリオの下で、２つのデータ記録間でのマッチングを見つけるためのポテンシャルベースとして、データ属性の様々な組み合わせの検討及びテストの結果を示す。
【００６５】
【表５】
0005401037.tif 000008
【００６６】
【表６】
0005401037.tif 000009
【００６７】
【表７】
0005401037.tif 000010
【００６８】
表８A〜８Eは、テストデータ記録が特定のタイプのデータ属性を含んでいた又は除外していた種々のシナリオの下で、データ属性の様々な組み合わせに対するマッチング結果を示す。表８Aは、保険カード、DOB及び性別の情報を含んでいたテストデータ記録に対するテスト結果を示す。表８Bは、保険カード、DOBの情報を含むが、性別情報は欠いていたテストデータ記録のテスト結果を示す。表８Cは、保険カード情報は含むが、DOB情報は欠いていたテストデータ記録のテスト結果を示す。更に、表８Dは、DOB情報は含むが、保険カード情報は欠いていたテストデータ記録のテスト結果を示す。表８Eは、DOB情報及び保険カード情報の双方を欠いていたテストデータ記録のテスト結果を示す。
【００６９】
【表８Ａ】
0005401037.tif 000011
【００７０】
【表８Ｂ】
0005401037.tif 000012
【００７１】
【表８Ｃ】
0005401037.tif 000013
【００７２】
【表８Ｄ】
0005401037.tif 000014
【００７３】
【表８Ｅ−１】
0005401037.tif 000015
【００７４】
【表８Ｅ−２】
0005401037.tif 000016
【００７５】
表８A〜８Eに示すようなテスト結果の分析は、効率的なマッチング処理実現のために、特定組のデータ属性及びレベルを推奨又は選択する経験的な基礎をもたらす。
【００７６】
更に、他のデータ処理状況又は事情に対するマッチングロジックを洗練させるために、分析又はテストを実行することができる。例えば、“横断する供給者”の場合のマッチング処理に関して、“販売店の普遍性”データファイルを分析して、２つのデータ供給者（例えば、McKesson及びPDX）が如何に多く同一の地理的範囲内に販売店を有するかについて判断することができる。この分析は、例えばMcKesson及びPDXの患者間で、通い患者のマッチング期待度の判断を助ける。分析で考慮されうるデータ属性は、例えば、州、国、ＭＳＡ、ジップコード（５桁）及びジップコード（３桁）を含むことができる。
【００７７】
前述の例は、本発明の概略的な原理を示したものに過ぎず、本発明の範囲及び趣旨から逸脱することなく、当業者であれば様々な変更が可能であることは明らかであり、本発明は、特許請求の範囲によってのみ制限される。
【図面の簡単な説明】
【００７８】
【図１】本発明の原理に従って、米国特許出願第１１／１２２，５８９号明細書から再現される、マルチソースの患者データ記録から長期のデータベースをアセンブリするシステム例のブロック図であり、本システムで実現できるマッチングアルゴリズムは、図２a、２ｂ、３ａ及び３ｂに示される。
【図２ａ】本発明の原理に従って、データ記録の属性をレベル毎にマッチングし、特定のデータ供給者によって供給されるデータ記録に、長期リンクの識別子を割り当てるステップ例を示す概略的な処理フロー図である。
【図２ｂ】本発明の原理に従って、データ記録の属性をレベル毎にマッチングし、特定のデータ供給者によって供給されるデータ記録に、長期リンクの識別子を割り当てるステップ例を示す概略的な処理フロー図である。
【図３ａ】本発明の原理に従って、データ記録の属性をレベル毎にマッチングし、複数のデータ供給者によって供給されるデータ記録に、長期リンクの識別子を割り当てるステップ例を示す概略的な処理フロー図である。
【図３ｂ】本発明の原理に従って、データ記録の属性をレベル毎にマッチングし、複数のデータ供給者によって供給されるデータ記録に、長期リンクの識別子を割り当てるステップ例を示す概略的な処理フロー図である。
【図４−１】本発明の原理に従って、米国特許出願第１１／１２２，５８９号明細書から再現される、図２a、２ｂ、３ａ及び３ｂに示されるマッチング処理の実現に関するソフトウェア・サブルーチンのロジックを示す図である。
【図４−２】本発明の原理に従って、米国特許出願第１１／１２２，５８９号明細書から再現される、図２a、２ｂ、３ａ及び３ｂに示されるマッチング処理の実現に関するソフトウェア・サブルーチンのロジックを示す図である。
【図１】
0005401037.tif 000017
【図２ａ】
0005401037.tif 000018
【図２ｂ】
0005401037.tif 000019
【図３ａ】
0005401037.tif 000020
【図３ｂ】
0005401037.tif 000021
【図４−１】
0005401037.tif 000022
【図４−２】
0005401037.tif 000023