JP2013537669A - 匿名ヘルスケアおよびレコードシステム - Google Patents

Abstract

本明細書で説明されるのは、インシュアラーおよびファーマシーに関係する支払い請求を処理するときに、暗号化技術（匿名プルーフシステム）を使用して、ヘルスレコードの匿名性を保証することである。患者がインシュアラーから患者のトークンを受信することにより、患者はヘルスケアプロバイダーにデリゲートする。デリゲートされたトークンを処理して、ヘルスケアプロバイダーおよび提供される医療サービスを識別する、患者を直接識別可能な情報を含まない匿名トークンにする。匿名トークンは、インシュアラーがトークンを認証するデータを含む。処方のために、患者についてのエンドースメントおよびファーマシーに送信されるアンエンドースドトークンとして匿名トークンを生成することができる（例えば、印刷されたバーコード）。ファーマシーはエンドースメントのデータとアンエンドースドトークンを結合して、支払のためにインシュアラーへ送信される匿名結合トークンにする。

Description

本発明は、インシュアラー（insurer）およびファーマシー（pharmacy）に関係する支払い請求を処理するときに、暗号化技術（匿名プルーフシステム）を使用して、ヘルスレコードの匿名性を保証する方法に関する。

医療問題を扱うときに、患者のプライバシーは重要な懸案事項である。医療レコードが電子フォームに変換される際に、当該電子フォーマットは患者のデータの悪用を容易にするので、患者のプライバシーが漏れるリスクが著しく増大する。

同時に、このようなデータは、もしあればこのデータをこれ以上必要としない多くの関係者にアクセス可能となる。例えば、インシュアラーおよびファーマシーは積極的には患者のケアに関わらない。しかしながら保険をかけられている患者は、保険給付金を受けるために、患者の医療の全体レコードをインシュアラーと共有することが要求され、それらの患者はインシュアラーおよびその従業員が上記レコードを秘密裏に保持することを希望ことしかできない。同様に、ファーマシーは各患者に調剤されたすべての処方箋など、患者の処方箋に関するデータを保管することができる。

実際に、これらの関係者にとってこの情報を持つことの医療的な理由は存在しない。例えば、インシュアラーのみが十分な情報を必要とすることにより、不正を防ぎ、提供された治療が患者のポリシーの下、隠蔽されることを証明することができる。ファーマシーのみが、調剤された薬剤について患者が妥当な処方箋を有しているかを知ることが必要となる。

米国特許第５５２１９８０号 米国特許第５６０４８０５号

M. Belenkiy, J. Camenisch, M. Chase, M. Kohlweiss , A. Lysyanskaya and Hovav Shacham, 「P-signatures and Noninteractive Anonymous Credentials」 Crypto 2008 M. Belenkiy, J. Camenisch, M. Chase, M. Kohlweiss, A. Lysyanskaya, and H. Shacham, 「Randomizable proofs and delegatable anonymous credentials」 Crypto 2009 J. Camenisch and A. Lysyanskaya, 「A signature scheme with efficient protocols」 SCN'02 D. Chaum, 「Security without identification: Transaction systems to make big brother obsolete」 Communications of the ACM, 28(10):1030-1044, Oct. 1985 J. Camenisch and A. Lysyanskaya. 「Dynamic accumulators and application to efficient revocation of anonymous credentials」 Crypto SCN'02

この「発明の概要」は、以下の「発明を実施するための形態」でさらに述べられている概念の中から選択したものを簡略した形式で紹介するものである。この「発明の概要」は、特許請求の範囲に記載された内容の重要な特徴または本質的な特徴を特定することを意図としたものではなく、特許請求の範囲に記載された内容の範囲を判定するための補助として使用されることを意図したものでもない。

つまり、本明細書で説明される主題事項の様々な側面は、インシュアラーおよびファーマシーへの支払請求を処理するときに、暗号化技術（匿名プルーフ（proof）システム）を使用して、ヘルスレコードの匿名性を保証することに関する。一つの態様では、機構（例えば、ヘルスケアプロバイダーにおいて）は、患者の属性およびインシュアラーのデータを含むデリゲートされた患者トークンを入力する。インシュアラーは上記属性およびインシュアラーのデータにより、当該患者トークンに対応する別のトークンを認証することができる。デリゲートされたトークンを処理して、ヘルスケアプロバイダー（またはファーマシー）を識別し、インシュアラーからの払い戻しが求められる１つまたは複数の補償範囲内の医療サービスまたは製品を識別する匿名トークンにする。匿名トークンは、患者を直接識別することが可能であり、支払のためにインシュアラーへ送信される情報を含まない。

一つの態様では、患者に関して施された医療手順に対応する暗号化された患者レコードが、例えばヘルスシステム／サービスにおいて保持される。別の態様では、患者に関して施された医療手順に対応する匿名データが、医療調査における使用などのために、データアグリゲーターに送信される。

処方については、患者に関連付けられたエンドースメント（endorsement）（例えば、ヘルスケアプロバイダーにより印刷されたバーコードとして患者に与えられる）、および当該ヘルスケアプロバイダーからファーマシーに送信されるアンエンドースド（unendorsed）トークンを含む２つの部分において匿名トークンを生成することができる。ファーマシーはアンエンドースドトークンに対応するデータを、エンドースメントに対応するデータと結合して、匿名結合トークンとし、当該匿名結合トークンを、支払のための適切な受信者（例えば、インシュアラー）に送信する。

その他の利点は、図面を併用して以下の詳細な説明から明らかになるであろう。

本発明は、添付図面にて例示の方法により説明されるが、それに限定されない。類似する参照符号は類似の要素を示す。

匿名ヘルスケアシステムおよびレコードシステムを含むヘルスケア環境の関係者およびその他の態様を示すブロック図である。 匿名ヘルスケアおよびレコード環境を提供するためにとり得る例示的なステップを示すフローチャートである。 どのようにトークンを使用して、医療サービスを提供することを含む匿名ヘルスケアおよびレコードシステム／環境を促進するかを示すブロック図である。 どのようにトークンを使用して、処方された製品を提供することを含む匿名ヘルスケアおよびレコードシステム／環境を促進するかを示すブロック図である。 本発明の様々な態様が組み込まれるコンピューティング環境の例を示す図である。

本明細書において説明される技術の様々な態様は、一般に、患者ＩＤをインシュアラーまたはファーマシーに公開することなく、サービスおよび／または調剤製品に対する支払いが達成される技術に関する。一実施態様では、互いにリンク可能な同一の患者による別々の訪問をすることなしに、これを達成することができる。さらに、患者レコードの匿名バージョンを、医療調査などの目的に、データアグリゲーターにアップロードすることができる。

この目的のために、様々な関係者（ヘルスケアプロバイダー、インシュアラー、患者およびファーマシー）が公開鍵基盤においてＩＤを有することができる。本明細書で説明するように、患者はインシュアラーとインシュアランスポリシーを締結し、インシュアラーと双方向のプロトコルを実行することにより、患者は電子著名されたプルーフステートメント（proof statement）（トークン）を保有することになる。当該プルーフステートメントは、患者がある特性との有効なインシュアランスポリシーを保有することを示す。このトークンはヘルスケアプロバイダー（例えば、医者または病院）に提示され、匿名な、かつリンク不可能な署名された承認ステートメントを生成するために使用される。当該承認ステートメントは支払のためにインシュアラーに提示される。類似の方法において、患者のＩＤを知ることなく、ファーマシーはインシュアラーから処方箋のための支払を受ける。

本明細書における例は、一般的な医療のシナリオに関するが、本明細書のいかなる例は限定的なものではなく、その他のシナリオも本明細書で説明される技術から利益を得ることができることを理解されるであろう。このように、本発明は、本明細書で説明されるいかなる特定の実施形態、態様、概念、構造、機能または例に限定されない。むしろ、本明細書で説明される実施形態、態様、概念、構造、機能または例は限定的でなく、概してコンピューティングおよびプライバシーに利益および有利な点を提供する様々な方法で使用することができる。

図１はヘルスケア環境における様々な関係者を表すブロック図を示す。ヘルスケア環境は、患者１０２がコンシューマーヘルスシステム１０４（例えば、マイクロソフトＡＭＡＬＧＡ（登録商標））などを介してヘルスケア環境にアクセスすることを含む。ある相当の時期において、患者１０２（または患者の使用者など）はインシュアラー１０６とインシュアランスポリシーを締結する。匿名認証情報（プルーフ）システムを使用することで、患者１０２は１つまたは複数のトークンをインシュアラー１０６から受信する。これらはスマートカード、および必要に応じて（例えば、インターネットを介して）アクセスすることができる電子証明書などにおけるデータの形式であってもよい。本明細書で「トークン」を使用する場合、匿名認証情報システム技術に基づく任意の適切なデータ構造における任意の適切なデータのセットに言及する。このような匿名認証情報システムは、本明細書にて参照により組み込まれる文献（特許文献１および特許文献２）において説明されるように公知となっている。その他の文献は、非特許文献１および非特許文献２を含む。Ｉｄｅｍｉｘは、非特許文献３および非特許文献４により説明される技術として、別の適切な匿名認証情報システム技術である。

概して本明細書で説明するように、ヘルスケアプロバイダー１０８とともに、後にトークンを使用して、サービスに対する支払のためにインシュアラー１０６に再び提示する匿名トークンを作成する。インシュアラーは、例えば患者／組織がポリシーをキャンセルし、さもなければ保険料の支払を停止する場合に、トークンを取り消しにする必要があることに留意されたい。取り消しは、非特許文献５で説明されるような既存の匿名認証情報取り消し技術を使用して行われる。

匿名トークンでは、ヘルスレコードをインシュアラー１０６またはファーマシー１１０と共有するときに、患者と関連付けない。代わりに、患者１０２がヘルスケアプロバイダー１０８を訪問するときに、治療のプライベートレコードを生成して、患者の機密ヘルスレコードに格納する。一の例示的なシナリオでは、患者１０２がヘルスケアプロバイダー１０８により治療を受けるときに、ヘルスケアプロバイダー１０８はこの訪問のレコードを生成し、患者の機密個人クリニカルヘルスレコードに安全な方法でアップロードする（例えば、コンシューマーヘルスシステム１０４に保持される）。患者のプライベートレコードは暗号化されて保持され、明確な承諾および適切な秘密鍵なしに、コンシューマーヘルスシステム１０４またはその他のいかなる者によっては閲覧することができない。

以下で説明するように、ヘルスケアプロバイダー１０８はインシュアラー１０６に支払の請求を行い、インシュアラー１０６がどの患者の支払が行われたかを知ることなく、支払が処理される。

別の主たるシナリオでは、ヘルスケアプロバイダー１０８が患者に対して薬剤を処方する場合、ヘルスケアプロバイダー１０８はファーマシー１１０に関連する情報を含むトークン（または以下に説明する部分トークン）を送信する。このトークンは患者を識別することができる情報を含まず、患者に対して薬剤を処方する国家によりプロバイダー（医者）が認証されることを示す署名された承認ステートメント（可能であれば公的給付データ）を含む。送信は電子メールによるものでもよく、トークンを特定のサイトなどにアップロードする。

また、以下に説明するように、ヘルスケアプロバイダー１０８は追加的に患者についてのデジタル著名された処方箋トークン（例えば、印刷されたバーコード形式で）を生成し、これをファーマシー１１０へ持っていき、処方箋を手に入れる。物理的なプリントアウトは必ずしも提供されず、例えば、バーコードが患者の携帯電話またはファーマシーにおいてスキャンすることができるその他のデバイスにダウンロードされてもよいことに留意されたい。

図１は、患者のレコードの匿名バージョンが生成され（随意に）、調査データ１１４にアグリゲートするなど、アグリゲーター１１２へアップロードするメカニズムをさらに示す。このようなデータを匿名にする様々な方法が知られている。しかしながら、匿名性を後に取り消しにする必要がある場合に、信頼できる第三者の使用を含めるなどのソリューションを採用することができる。

このようにして、ヘルスケアプロバイダー１０８は、インシュアランス１０６およびファーマシー１１０との取引における患者１０２の信頼できる代理としての役割を果たすことができる。特に、ヘルスケアプロバイダー１０８は、ファーマシー１１０と対話し、匿名の、デリゲートすることができ、かつリンク不可の認証情報システムにおいてトークンを使用して、患者１０２の代わりにインシュアラー１０６に支払の請求をする。以下で説明するように、セーフガードを使用してこのようなトークンが悪用されないことを保障する（例えば、複数の使用についてはその他へ回す）。

図２は、匿名の認証情報を含む暗号化ツールに基づいた匿名ヘルスケアおよびレコード技術の態様を要約したものであり、ステップ２０２から始まり、そこでは患者はインシュアラーからインシュアランスポリシーを取得し、匿名プルーフシステムを使用してトークンを受信する。概して、このトークンは、所与のポリシーに準じて患者の治療が隠蔽されることを証明する。

ステップ２０４は、妥当なインシュアランスポリシーを表すトークンを受理する医者／病院を訪れる患者を表す。患者は当該ポリシーの関連部分を公開し、この訪問についてのトークンをヘルスケアプロバイダーに送り、当該トークンが処理されて匿名トークンになる。以下に説明するように、医者と患者との間のいくつかの対話が要求されて、訪問についてインシュアラーに提示される匿名トークンを生成することができる。一実施形態では、医者／病院は、この訪問により生成されるいかなるレコードまたはデータに関して、患者により全面的に信頼されると仮定する。

ステップ２０６は、訪問についての患者レコードを暗号化して、当該レコードをコンシューマーヘルスシステムにアップロードする医者／病院を表す。医者／病院は随意に、患者の訪問／ヘルスレコードの匿名バージョンをデータアグリゲーターシステムにアップロードすることもできる（ステップ２０８）。

ステップ２１０では、医者／病院は有効な、匿名の、リンク不可のトークンを使用して、インシュアラーに支払の請求を行う。医者は、保険請求が患者のポリシーの下、有効であるかをチェックし（可能であれば治療前に）、匿名トークンを、提供されるサービスの詳細を含むインシュアラーに送信する。インシュアラーはこのトークンをチェックし、当該請求の払い戻しを行う。すなわち、医者／病院は、インシュアラーがこのトークンの有効性をチェックした後に、支払いを受ける。患者についてのいかなる手順を実行する前に、医者／病院は、トークンが所望の手順に対して少なくとも部分的に有効であることをチェックするメカニズムを有することができることに留意されたい（いかなる相違も患者に責任がある）。

ステップ２１２および２１４は、様々な医者／患者／ファーマシーのオペレーションを表す。概して、ステップ２１２では、医者は患者に対して１つまたは複数の薬剤を処方する。この情報は、訪問に関する患者のレコードに含まれる。いったんこの情報が電子的に格納されると、薬剤のやり取りが自動的にエラーとなり得、ファーマシーはこの処理においては大きな役割を果たす必要がない。処方箋をファーマシーに伝達するために、医者／病院は処方する権利を証明する国家により発行された認証情報を使用して、保険が当該薬物を補償することを示す匿名トークンを介して、特定の患者と結び付けられた署名された処方箋を生成する。したがって、ファーマシーに与えられた情報は、処方箋の詳細と、保険の補償範囲の支払／証明のためにインシュアラーに提示するのにファーマシーが使用することができる１つまたは複数のトークンとを含む。

ステップ２１４により示されるように、手書きにより署名された処方箋を発行することに代えて、医者は印刷するか、または患者に付与し、ファーマシーに持ち込むデジタル著名された処方箋（バーコードの形式とすることができる）を含むトークン（例えば、部分的トークン）を生成することができる。次に、患者は、当該患者から受信されたトークンを照合する、対応するファーマシーに行き、医者は事前に適切な薬物の調剤を行う。払い戻しのために、患者により確かに受け取られた医療製品の請求を証明することとして、ファーマシーは医者からのトークンと患者からのトークンを結合して、その証明および請求の払い戻しを照合するインシュアラーにその結果を提示する。

この方法では、患者ＩＤをインシュアラーやファーマシーに公開することなく、かつリンク可能な同一の患者により別々の訪問がされなくとも、サービスや医療製品に関する支払を達成することができる。これは、匿名認証情報システムが、ユーザーが組織から認証情報を取得し、必要な認証情報を保持することを証明するトークンを生成している間に、リソース／サービスにアクセスすることを可能にするからである。これらのトークンは患者に関する情報を公開しないという点で匿名であり、それらは初期の保険に再びリンクすることができず、同一の認証情報を使用して、２つのトークンが生成されることを区別することも不可能である。

一実施形態におけるトークンの様々な態様に目を向けると、図３で示すように患者１０２は１つまたは複数の属性の組を含む認証情報３２０をインシュアラー１０６から受信する。当該属性から１つまたは複数のトークンの組を発行することができる。患者１０２が所与の属性を有することを証明する、１つまたは複数のステートメントに対応するトークンの組は、所与の属性を有しておらず、所与の範囲内で属性、またはこのようなステートメントの任意の組み合わせを有する（または有さない）。

認証情報／トークン３２０を備える患者は、デリゲートされたトークン３２２を別の関係者、すなわち、ヘルスケアプロバイダー１０８に発行することができる。患者１０２はまた、例えば、ある属性を修正することが可能なトークンエディター３２４（例えば、ソフトウェアプログラム）を介して、デリゲートされたトークン３２２に含まれるこの属性のいずれかを選択することができる。デリゲートされたトークン３２２によって、ヘルスケアプロバイダー１０８は、組織からの有効な認証情報を備えるいずれかの人によって発行された認証情報の所有権を証明することが可能になる（この仲介ユーザーに関する情報を公開することなしに）。

したがって、一実施形態では、患者１０２に関するトークン３２０は、ポリシーが標準化された形式を有すると仮定して、当該ポリシーの属性を含む単一の認証情報を備えることができる。ヘルスケアプロバイダー１０８に関するトークンは、ハードコード化された訪問日などを有するデリゲートトークン３２２を備えることができる。トークンエディター３２４を介して、患者は、施された治療に関連しない場合のいくつかのフィールドを除去することを選択することができる。例えば、患者の主要な担当医を訪問すると、医療認証情報を除去することができる。代わりに、請求されている各治療を承認するのに必要であるなど、このプロセスに患者をより関与させることができる。

インシュアラー１０６についての匿名トークン３２６に関しては、ヘルスケアプロバイダー１０８はデリゲートトークン３２２を使用して、請求される手順および／またはサービスが確かに補償されることの証明を生成する（匿名トークンジェネレーター３２８、例えばソフトウェアプログラムを介して）。匿名トークン３２６の生成において、患者１０２はヘルスケアプロバイダー１０８をともに作用することができることに留意する。次に、支払い３３０は、上記説明のようにヘルスケアプロバイダー１０８に送信される。

あるケースでは、同一の設定において２回以上、認証情報を使用しないことを保証することが重要になる。このケースでは、患者１０２は各設定に対して使い捨てトークンを提供する。患者１０２が同一の設定に対して２以上のトークンを生成する場合、より容易に当該トークンを検出することができるが、しかしながらそれぞれの使用が異なる設定である限り、同一の患者１０２により複数のトークンが生成されたことを区別する手法が存在しない。したがって、匿名トークン３２６を、患者および日付に関する使い捨てラベルに結合することができ、それにより同一の手順に対する複数の請求を防止することができる。

インシュアラーのポリシーがより複雑である場合は、トークン内のデータを介してその他の特徴（既存の技術により達成可能な）を提供することができる。例えば、１週間ごとに１つのリハビリ手順のみを行うなどのある手順の間で必要とされる時間差であってもよく、それをトークン内のデータとして含めることができる。インシュアラーのトークンのその他の特徴は、先行手順が既に払い戻しを受けたことを証明すること、患者の生涯または年間の上限が超過していないことを証明すること、およびこの患者についての研究からの署名された結果の証明などに向けられる。

図４は、患者／医者／ファーマシー／インシュアラーの対話の様々な態様を示す図である。２つの部分においてトークンを生成することができ、他方がいなければ有効にならないことに留意されたい。トークンのこれらの部分は、本明細書においてはアンエンドースドトークンおよびエンドースメント（endorsement）として言及される。エンドースメントは、証明されるステートメントの長さにもかかわらず、非常に短くすることができる特徴を有している。

ファーマシー１１０にとって、医者４０８がデリゲートトークン４２２を与えられるときに、一実施形態では、医者４０８は、請求を照合するのに必要ないかなる情報を備えるエンドースド（endorsed）デリゲートトークン４４０を生成する（エンドースドデリゲートトークンジェネレーター、ソフトウェアプログラムなどを介して）。このことは、基本的にはインシュアラー１０８についての匿名トークンのエンドースドバージョンであり、処方する医者が認証されることのみを公開する。アンエンドースドトークン（部分）４４１は、印刷され、もしくは何らかの方法で電子的に生成され（例えば、１次元または２次元バーコードとして）、患者１０２に関連付けられた（例えば、与えられた）エンドースメント４４２とともに、ファーマシーに送信、または送られる。上記説明したように、患者１０２または患者の代表は、エンドースメント４４２をファーマシー１１０に提供して、それにより当該エンドースメントはアンエンドースドトークン４４１と再結合され、匿名にされて（例えば、匿名トークンコンバイナー（combiner）／ジェネレーターソフトウェアプログラム４２８を介して）、支払い４３０のためにインシュアラー１０６に提供される匿名結合トークン４２６となる。

別の態様に目を向けると、匿名性を取り消して、許可監査が必要となる状況がある場合がある。したがって、例えば監査の場合などに、治療情報および各患者のＩＤを検索する方法が提供される。１つのオプションは、復号キーを保持し、または復号キーを共有する１つの（または複数の）信頼された関係者を有することである。トークンが形成されてインシュアラーに送信されるときに、医者はまた、このキーを基に暗号化されたデータを含むことができ、当該データは治療情報（この情報についての当該医者の署名とともに）を含む。監査が必要な場合に、インシュアラーは信頼された関係者に問い合わせを行い、復号化を実行することができる。虚偽が発見された場合、医者はそれから責任を負うことができる。

トークンの共有を防止することに関しては、インシュアラーは、患者が他人（例えば、共同で保険をかけられた家族以外）とポリシーを共有することを望まないであろう。１つの解決策は、関係者（患者を含む）が公開鍵基盤において証明可能なＩＤを有すると仮定することである。やや劣るが別の解決策は、患者が当該患者の権利を共有して、別の誰かによるポリシーの使用を許可することを要求することである。さらに別の解決策は、発行されたポリシートークンおよび患者が医者に示すデリゲートトークン（しかし匿名トークンではない）に患者名を含ませることであり、医者は患者のＩＤを証明することに責任を負う。

図５は、図１乃至４の例を実装することができる適切なコンピューティングおよびネットワーク環境５００の例を示す。コンピューティングシステム環境５００は、適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲に関していかなる限定を示唆することを意図するものではない。また、コンピューティング環境５００は、例示的な動作環境５００において示されるコンポーネント内の任意の１つまたは組み合わせに関していかなる依存もしくは要件がないと解釈されるべきである。

本発明は、多くのその他の汎用もしくは専用コンピューティングシステム環境もしくは構成により動作可能である。本発明により使用されるのに適切となり得る既知のコンピューティングシステム、環境および／または構成の例は、パーソナルコンピューター、サーバーコンピューター、ハンドヘルドデバイスもしくはラップトップデバイス、タブレットデバイス、マルチプロセッサーシステム、マイクロプロセッサーベースシステム、セットトップボックス、プログラミング可能な家庭用電化製品、ネットワークＰＣ、ミニコンピューター、メインフレームコンピューター、および上記システムもしくはデバイスのうちのいずれかを含む分散コンピューティング環境などを含むが、これらに限定されない。

本発明は、コンピューターにより実行されるプログラムモジュールなどのコンピューターにより実行可能な命令の一般的なコンテキストにおいて説明することができる。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造などを含む。本発明はまた、通信ネットワークを通じてリンクされるリモート処理デバイスによりタスクが実行される分散コンピューティング環境において実施することができる。分散コンピューティング環境においては、プログラムモジュールを、メモリー記憶装置を含むローカルおよび／またはリモートコンピューター記憶媒体に位置させることができる。

図５を参照すると、本発明の様々な態様を実装するための例示的なシステムは、コンピューター５１０の形式で汎用コンピューティングデバイスを含むことができる。コンピューター５１０のコンポーネントは、プロセシングユニット５２０、システムメモリー５３０、およびシステムメモリー５３０からプロセシングユニット５２０までを含む様々なシステムコンポーネントを結合するシステムバス５２１を含むが、それらに限定されない。システムバス５２１は、メモリーバス、メモリーコントローラー、周辺機器用バス、および種々のバスアーキテクチャーのうちのいずれかを使用したローカルバスを含む様々なタイプのバス機構のうちのいずれかであってもよい。例として、このようなアーキテクチャーは、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）バス、およびメザニン（Mezzanine）バスとしても知られるＰＣＩ（Peripheral Component Interconnect）バスを含むが、これらに限定されない。

コンピューター５１０は、主として、種々のコンピューター可読媒体を含む。コンピューター可読媒体は、コンピューター５１０によりアクセスすることができる任意の利用可能な媒体であることができ、揮発性および不揮発性、ならびに着脱可能および着脱不能媒体を含むことができる。例として、コンピューター可読媒体は、コンピューター記憶媒体および通信媒体を含むことができるが、これらに限定されない。コンピューター記憶媒体は、コンピューター可読命令、データ構造、プログラムモジュールもしくはその他のデータなどの情報を記憶するための任意の方法もしくは技術において実装される揮発性および不揮発性、着脱可能および着脱不能媒体を含む。コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリーもしくはその他のメモリー技術、ＣＤ−ＲＯＭ、ＤＶＤ（digital versatile disk）もしくはその他の光学ディスク装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくはその他の磁気記憶装置、または所与の情報を記憶するのに使用することができ、コンピューター５１０によりアクセスすることができるその他の任意の媒体を含むが、これらに限定されない。通信媒体は、主として、搬送波もしくはその他の搬送メカニズムなどの変調データ信号において、コンピューター可読命令、データ構造、プログラムモジュールもしくはその他のデータを具体化し、かつ任意の情報配信媒体を含む。用語「変調データ信号」は、信号内の情報をエンコードするような方法において、設定されまたは変更された１つまたは複数の特性を有する信号を意味する。例として、通信媒体は有線ネットワークもしくは直接配線接続などの有線媒体、ならびに音声、ＲＦ、赤外線およびその他の無線媒体などの無線媒体を含むが、これらに限定されない。上記いずれの組み合わせはまた、コンピューター可読媒体の範囲内に含まれてもよい。

システムメモリー５３０は、ＲＯＭ（read only memory）５３１およびＲＡＭ（random access memory）５３２などの揮発性および／または不揮発性メモリーの形式のコンピューター記憶媒体を含む。スタートアップ中など、コンピューター５１０内の要素間において情報を転送するのに役立つ基本ルーチンが含まれるＢＩＯＳ（basic input/output system）５３３は、主として、ＲＯＭ５３１に格納される。ＲＡＭ５３２は主として、データ、および／またはプロセシングユニット５２０により直接アクセス可能であり、および／またはプロセシングユニット５２０上で間もなく動作するプログラムモジュールを含む。例として、図５はオペレーティングシステム５３４、アプリケーションプログラム５３５、その他のプログラムモジュール５３６およびプログラムデータ５３７を示すが、これらに限定されない。

コンピューター５１０はまた、その他の着脱可能／着脱不能、揮発性／不揮発性コンピューター記憶媒体を含んでもよい。ほんの一例として、図５は着脱不能、不揮発性磁気媒体から読み取り、もしくはそれらに書き込むハードディスクドライブ５４１、着脱可能、不揮発性磁気ディスク５５２から読み取り、もしくはそれらに書き込む磁気ディスクドライブ５５１、およびＣＤ−ＲＯＭもしくはその他の光学媒体などの着脱可能、不揮発性光学ディスク５５６から読み取り、もしくはそれらに書き込む光学ディスクドライブ５５５を示す。例示的な動作環境で使用することができるその他の着脱可能／着脱不能、揮発性／不揮発性コンピューター記憶媒体は、磁気テープカセット、フラッシュメモリーカード、ＤＶＤ、デジタルビデオテープ、ソリッドステートＲＡＭ、およびソリッドステートＲＯＭなどを含むが、これらに限定されない。ハードディスクドライブ５４１は主として、インタフェース５４０などの着脱不能メモリーインタフェースを通じてシステムバス５２１に接続され、磁気ディスクドライブ５５１および光学ディスクドライブ５５５は主として、インタフェース５５０などの着脱可能メモリーインタフェースによりシステムバス５２１に接続される。

上記説明され、図５で示されたドライブおよびそれに関連するコンピューター記憶媒体は、コンピューター５１０に関するコンピューター可読命令、データ構造、プログラムモジュールおよびその他のデータのストレージを提供する。図５では、例えば、ハードディスクドライブ５４１が、オペレーティングシステム５４４、アプリケーションプログラム５４５、その他のプログラムモジュール５４６およびプログラムデータ５４７を格納するものとして示される。これらのコンポーネントは、オペレーティングシステム５３４、アプリケーションプログラム５３５、その他のプログラムモジュール５３６およびプログラムデータ５３７と同一かあるいは別のものであってもよいことに留意されたい。オペレーティングシステム５４４、アプリケーションプログラム５４５、その他のプログラムモジュール５４６およびプログラムデータ５４７は、本明細書では異なる番号が付与され、最低限、それらが様々な複製であることを示す。ユーザーはタブレットもしくは電子デジタイザー５６４、マイクロフォン５６３、キーボード５６２および一般にマウスと称されるポインティングデバイス５６１、トラックボールもしくはタッチパッドなどを通じてコマンドおよび情報を入力することができる。図５では示されないその他の入力デバイスは、ジョイスティック、ゲームパッド、サテライトディッシュ、またはスキャナーなどを含んでもよい。これらおよびその他の入力デバイスは、システムバスに結合されたユーザー入力インタフェース５６０を通じてプロセシングユニット５２０に接続されることが多いが、パラレルポート、ゲームポートまたはＵＳＢなどのその他のインタフェースおよびバス機構により接続されてもよい。モニター５９１またはその他のタイプのディスプレイデバイスはまた、ビデオインタフェース５９０などのインタフェースを介してシステムバス５２１に接続される。モニター５９１はまた、タッチスクリーンパネルなどと一体化されてもよい。モニターおよび／またはタッチスクリーンパネルは、コンピューティングデバイス５１０がタブレットタイプのパーソナルコンピューターなどに組み込まれる、ハウジングに物理的に結合されてもよいことに留意されたい。加えて、コンピューティングデバイス５１０などのコンピューターはまた、周辺出力インタフェース５９４などを通じて接続され得るスピーカー５９５およびプリンター５９６などのその他の周辺出力デバイスを含んでもよい。

コンピューター５１０はリモートコンピューター５８０などの１または複数のリモートコンピューターへの論理接続を使用して、ネットワーク環境において動作してもよい。リモートコンピューター５８０は、パーソナルコンピューター、サーバー、ルーター、ネットワークＰＣ、ピアデバイスもしくはその他の共通ネットワークノードであってもよく、図５ではメモリーストレージデバイス５８１だけが示されたが、主として、コンピューター５１０と比較して上記説明した要素の多くもしくはすべてを含んでもよい。図５で示した論理接続は、１つまたは複数のＬＡＮ（local area network）５７１および１つまたは複数のＷＡＮ（wide area network）を含むが、また、その他のネットワークを含んでもよい。このようなネットワーク環境は、オフィス、企業規模のコンピューターネットワーク、イントラネットおよびインターネットにおいて一般的となっている。

ＬＡＮネットワーク環境において使用されるときに、コンピューター５１０はネットワークインタフェースもしくはアダプター５７０を通じてＬＡＮ５７１に接続される。ＷＡＮネットワーク環境において使用されるときに、コンピューター５１０は主として、モデム５７２もしくはインターネットなどのＷＡＮ５７２上で通信を確立するその他の手段を含む。内部もしくは外部であり得るモデム５７２は、ユーザー入力インタフェース５６０もしくはその他の適切なメカニズムを介して、システムバス５２１に接続されてもよい。インタフェースおよびアンテナなどを含む無線ネットワークコンポーネントは、アクセスポイントもしくはピアコンピューターなどの適切なデバイスを通じてＷＡＮもしくはＬＡＮに結合されてもよい。ネットワーク環境では、コンピューター５１０と比較して示されたプログラムモジュール、もしくはその一部がリモートメモリー記憶装置に格納されてもよい。例として、図５はメモリーデバイス５８１内に存在するリモートアプリケーションプログラム５８５を示す。示されるネットワーク接続は例示的であり、コンピューター間で通信リンクを確立するその他の手段を使用してもよいことが理解できるであろう。

補助的サブシステム５９９（例えば、コンテンツの補助的な表示）は、コンピューターシステムの主要な部分が低電力状態にある場合でも、ユーザーインタフェース５６０を介して接続されてもよく、プログラムコンテンツ、システムステータスおよびイベント通知などのデータをユーザーに提供することを可能にする。補助的なサブシステム５９９は、モデム５７２および／またはネットワークインタフェース５７０に接続されてもよく、それによりメインプロセシングユニット５２０が低電力状態にある間に、これらのシステム間における通信を可能にする。

本発明は、種々の変形および代替の構造が可能であり、本明細書で説明したある実施形態を図面において示し、上記詳細に説明してきた。しかしながら、本発明を開示された特定の形態に限定する意図はなく、むしろ、本発明は、本発明の精神および範囲内でのすべての変形、代替構成および同等のものをカバーするものである。

Claims (15)

1. コンピューティング環境において、少なくとも１つのプロセッサー上の少なくとも一部で実行される方法であって、
   患者の属性を含むデリゲートされた患者トークンを入力するステップと、
   前記患者トークンを処理して、前記患者を直接識別することが可能な情報を含むことなく、ヘルスケアプロバイダーもしくはファーマシー（pharmacy）を識別し、インシュアラー（insurer）からの払い戻しが望まれる１つまたは複数の補償された医療サービスもしくは製品を識別する、匿名トークンにするステップと
   を備えることを特徴とする方法。
2. 前記匿名トークンを支払の受領者に送信するステップをさらに備えることを特徴とする請求項１に記載の方法。
3. 前記患者のトークンを処理して前記匿名トークンにするステップは、前記患者について施された少なくとも１つの医療手順に対応する情報を含めることを含むことを特徴とする請求項１に記載の方法。
4. 前記患者について施された少なくとも１つの医療手順に対応する暗号化された患者レコードを保持するステップ、
   前記患者について施された少なくとも１つの医療手順に対応する匿名データを、データアグリゲーターに送信するステップ、または
   前記患者について施された少なくとも１つの医療手順に対応する暗号化された患者レコードを保持することと、前記患者について施された少なくとも１つの医療手順に対応する匿名データを、データアグリゲーターに送信することとの両方を行うステップ
   をさらに備えることを特徴とする請求項３に記載の方法。
5. 前記患者のトークンを処理して前記匿名トークンにするステップは、前記患者に提供される少なくとも１つの処方箋に対応する情報を含めること、前記患者に関連付けられたエンドースメント（endorsement）からのデータを、ヘルスケアプロバイダーから受信されたアンエンドースド（unendorsed）トークンに結合すること、または前記患者に提供される少なくとも１つの処方箋に対応する情報を含めることと、前記患者に関連付けられたエンドースメントからのデータを、ヘルスケアプロバイダーから受信されたアンエンドースドトークンに結合することとの両方を備えることを特徴とする請求項１に記載の方法。
6. インシュアラーにより患者へ提供される患者トークンからデリゲートトークンを生成するメカニズムであって、前記患者トークンは患者の属性および前記インシュアラーのデータを含むことと、
   前記デリゲートトークンから匿名トークンを生成するメカニズムであって、前記匿名トークンは、前記インシュアラーが前記匿名トークンに対応する前記患者トークンを発行したことを示すデータ、および前記患者を直接識別することが可能な情報を含むことなく、前記患者が医療サービスもしくは製品を受領したことを示すデータを含むことと
   を備えることを特徴とするシステム。
7. 前記デリゲートトークンを生成するメカニズムは、前記患者トークンにおける１つまたは複数の患者の属性を追加、削除もしくは修正することが可能なトークンエディターを備えることを特徴とする請求項６に記載のシステム。
8. 前記匿名トークンは、前記患者に医療サービスを提供したヘルスケアプロバイダーから前記患者へ送信され、または前記匿名トークンは、前記患者に医療製品を提供した薬局により前記インシュアラーへ送信されることを特徴とする請求項６に記載のシステム。
9. 薬局が、匿名エンドースメント（endorsement）を含むエンドースド（endorsed）デリゲートトークン、および匿名アンエンドースド（unendorsed）トークンを備える匿名トークンを受信し、前記受信されたトークンから前記匿名トークンを生成する前記メカニズムは、前記患者に関連付けられた前記エンドースメントとヘルスケアプロバイダーからのアンエンドースドトークンとを結合するメカニズムを備えることを特徴とする請求項６に記載の方法。
10. 暗号化された患者レコードをストレージサービスにアップロードする手段、
    患者レコードの匿名バージョンをデータアグリゲーターサービスにアップロードする手段、または
    暗号化された患者レコードをストレージサービスにアップロードする手段と、患者レコードの匿名バージョンをデータアグリゲーターサービスにアップロードする手段との両方
    をさらに備えることを特徴とする請求項６に記載のシステム。
11. 前記匿名トークンは、信頼された関係者が暗号化された患者レコードを復号することができる情報を含むことを特徴とする請求項６に記載のシステム。
12. コンピューターにより実行可能な命令を有する１つまたは複数のコンピューター可読媒体であって、実行されると、
    患者およびインシュアラーに関連付けられた患者トークンに対応する匿名トークンを生成するステップであって、前記匿名トークンはヘルスケアプロバイダーおよび前記患者に提供される１つもしくは複数の医療サービスを、前記患者を直接識別することが可能な情報を含むことなく識別することと、
    前記１つもしくは複数の医療サービスに基づいて患者レコードを暗号化して、ストレージサービスにアップロードするステップと、
    前記匿名トークンを支払の受領者に送信するステップと
    を備える処理を実行することを特徴とする１つまたは複数のコンピューター可読媒体。
13. 処方箋に対応する情報を含む匿名エンドースド（endorsed）トークンを生成するステップであって、前記匿名エンドースドトークンは、患者と関連付けられた匿名エンドースメント（endorsement）および薬局の受領者に送信される匿名アンエンドースド（unendorsed）トークンを含むことと、
    前記エンドースメントの表示を印刷または出力するステップと
    をさらに備える処理を実行することを特徴とする請求項１２に記載の１つまたは複数のコンピューター可読媒体。
14. 前記アンエンドースドトークンに対応するデータを、前記エンドースメントに対応するデータに結合して匿名結合トークンにするステップと、前記匿名結合トークンを支払の受領者に送信するステップとをさらに備える処理を実行することを特徴とする請求項１３に記載の１または複数のコンピューター可読媒体。
15. 前記患者レコードを監査の一部として復号するステップをさらに備える処理を実行することを特徴とする請求項１２に記載の１または複数のコンピューター可読媒体。

Images