特表 2024-503065 ヘルスケアの相互運用性のためのシステム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-01-24

(54)【発明の名称】ヘルスケアの相互運用性のためのシステム及び方法

(51)【国際特許分類】

   G16H 50/20 20180101AFI20240117BHJP

【ＦＩ】

G16H50/20

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023542711

(86)(22)【出願日】2022-01-11

(85)【翻訳文提出日】2023-08-23

(86)【国際出願番号】 EP2022050440

(87)【国際公開番号】W WO2022152695

(87)【国際公開日】2022-07-21

(31)【優先権主張番号】17/149,703

(32)【優先日】2021-01-14

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＢＬＵＥＴＯＯＴＨ

２．イーサネット

(71)【出願人】

【識別番号】397060175

【氏名又は名称】ヤンセン ファーマシューティカ エヌ．ベー．

(74)【代理人】

【識別番号】100092783

【弁理士】

【氏名又は名称】小林 浩

(74)【代理人】

【識別番号】100095360

【弁理士】

【氏名又は名称】片山 英二

(74)【代理人】

【識別番号】100093676

【弁理士】

【氏名又は名称】小林 純子

(74)【代理人】

【識別番号】100120134

【弁理士】

【氏名又は名称】大森 規雄

(74)【代理人】

【識別番号】100141025

【弁理士】

【氏名又は名称】阿久津 勝久

(72)【発明者】

【氏名】リ，ジェシカ

(72)【発明者】

【氏名】森村 純

(72)【発明者】

【氏名】ヴィグ，ジョン

(72)【発明者】

【氏名】ケサダ，マーヴィン

(72)【発明者】

【氏名】モスケッティ，マイケル

【テーマコード（参考）】

5L099

【Ｆターム（参考）】

5L099AA03

(57)【要約】

実施形態は、相互運用性及びヘルスケアコストの安全な決定を容易にする。エンティティは、患者医療保険適用範囲情報及び第１の治療を有する第１の電子健康レコード（ＥＨＲ）サブブロックを受信し得、各第１の治療に対応する第１の治療クラスと、各第１の治療クラスに対応する第１の治療クラスメンバと、対応する第１の治療クラスメンバコスト情報と、を含む、第１のデバイス薬物情報（ＤＩＲ）サブブロックを送信し得る。それに応答して、エンティティは、第２の治療を含む第２のＥＨＲサブブロックを受信し得、第２の治療は各々、対応する第１の治療に関連付けられ、対応する第１の治療クラスメンバから選択される。トランザクション確認を受信すると、エンティティは、多次元ブロックチェーンを、第２の治療情報を含むＤＩＲブロックと、第２のＥＨＲサブブロックに基づく情報を含むＥＨＲブロックと、トランザクションブロックと、をリンクすることによって形成された多次元ブロックで拡張し得る。第２のＥＨＲブロックから決定された支払い支援情報は、患者に送信され得る。

【特許請求の範囲】

【請求項1】

第１のエンティティにおけるプロセッサにより実行される方法であって、
前記第１のエンティティによって復号可能な、少なくとも１つの暗号化された第１の電子健康レコード（ＥＨＲ）サブブロックを受信することであって、前記少なくとも１つのＥＨＲサブブロックが、患者及び１つ又は２つ以上の第１の治療に関する、患者医療保険適用範囲情報を含む、受信することと、
前記第１のＥＨＲサブブロックに応答して、少なくとも１つの対応する第２のエンティティによって復号可能な、少なくとも１つの暗号化された第１のデバイス薬物情報（ＤＩＲ）サブブロックを送信することであって、前記少なくとも１つの第１のＤＩＲサブブロックが、前記１つ又は２つ以上の第１の治療の各々について、対応する第１の治療クラスと、各対応する第１の治療クラスに関連付けられた１つ又は２つ以上の対応する第１の治療クラスメンバと、各第１の治療クラスメンバについて、対応する第１の治療クラスメンバコスト情報と、を含む、送信することと、
前記第１のＤＩＲサブブロックに応答して、前記第１のエンティティによって復号可能な暗号化された第２のＥＨＲサブブロックを受信することであって、前記第２のＥＨＲサブブロックが、１つ又は２つ以上の第２の治療を含み、前記１つ又は２つ以上の第２の治療の各々が、対応する第１の治療に関連付けられ、各第２の治療が、前記対応する第１の治療に関連付けられた前記対応する第１の治療クラスメンバから選択される、受信することと、
トランザクション確認に応答して、多次元ブロックチェーンを拡張することであって、前記多次元ブロックチェーンが、前記１つ又は２つ以上の第２の治療に関連付けられた情報を含むＤＩＲブロックと、前記第２のＥＨＲサブブロックに関連付けられた情報を含むＥＨＲブロックと、トランザクションブロックと、をリンクすることによって形成された多次元ブロックで拡張される、拡張することと、を含む、プロセッサにより実行される方法。

【請求項2】

前記第１のＥＨＲサブブロックを受信すると、前記方法が、
前記１つ又は２つ以上の第１の治療の各々について、前記対応する第１の治療クラスを決定することであって、各対応する第１の治療クラスが、前記１つ又は２つ以上の対応する第１の治療クラスメンバを含む、決定することと、
各対応する第１の治療クラスについて、前記１つ又は２つ以上の対応する第１の治療クラスメンバコスト情報を決定することと、を更に含む、請求項１に記載のプロセッサにより実行される方法。

【請求項3】

各第１の治療クラスについての前記対応する第１の治療クラスメンバコスト情報に基づいて、前記１つ又は２つ以上の第１の治療、又は前記１つ又は２つ以上の第２の治療、又はそれらの組み合わせ、のうちの少なくとも１つに基づいて、集約コストメトリックを決定することを更に含む、請求項２に記載のプロセッサにより実行される方法。

【請求項4】

前記第１のＥＨＲサブブロックが、患者固有パラメータを含み、前記少なくとも１つの治療クラスが、前記患者固有パラメータに基づいて決定される、請求項１に記載のプロセッサにより実行される方法。

【請求項5】

前記患者固有パラメータが、患者の併存疾患情報を含む、請求項４に記載のプロセッサにより実行される方法。

【請求項6】

前記患者固有パラメータが、投与経路情報を含む、請求項４に記載のプロセッサにより実行される方法。

【請求項7】

前記患者固有パラメータが、安全性及び有効性情報を含む、請求項４に記載のプロセッサにより実行される方法。

【請求項8】

前記患者固有パラメータが、患者位置情報を含む、請求項４に記載のプロセッサにより実行される方法。

【請求項9】

各第１の治療について、各治療クラスメンバについての前記対応する第１の治療クラス及び前記１つ又は２つ以上の対応する第１の治療クラスメンバコスト情報が、前記患者医療保険適用範囲情報に基づいて決定される、請求項１に記載のプロセッサにより実行される方法。

【請求項10】

前記１つ又は２つ以上の対応する第１の治療クラスメンバコスト情報が、患者位置の指定された距離内に位置する提供者に更に基づいて決定され、前記患者についての位置情報が、前記第１のＥＨＲサブブロックに含まれる、請求項９に記載のプロセッサにより実行される方法。

【請求項11】

前記１つ又は２つ以上の対応する第１の治療クラスメンバコスト情報が、
対応する治療単位についての各対応する第１の治療クラスメンバに対応する、患者固有の自己負担コスト、又は
典型的な治療期間についての各対応する第１の治療クラスメンバに対応する、患者固有の推定された総自己負担コスト、又は
前記患者に関連付けられた医療保険適用範囲プランの残りの期間についての各対応する第１の治療クラスメンバに対応する、患者固有の推定された総自己負担コスト、のうちの１つ又は２つ以上を含む、請求項１に記載のプロセッサにより実行される方法。

【請求項12】

前記第２のＥＨＲサブブロックを受信すると、前記方法が、
前記１つ又は２つ以上の第２の治療のうちの少なくとも１つについての支払い支援情報を決定することと、
患者に、トランザクション確認を伴う前記支払い支援情報を送信することと、を更に含む、請求項１に記載のプロセッサにより実行される方法。

【請求項13】

前記患者に、支払い支援情報とともに、前記１つ又は２つ以上の第２の治療のための少なくとも１つの処方を含むトランザクション確認を送信することを更に含む、請求項１に記載のプロセッサにより実行される方法。

【請求項14】

第１のエンティティのためのコンピューティングデバイスであって、
メモリと、
通信インターフェースと、
前記メモリ及び前記通信インターフェースに結合されたプロセッサと、を備え、前記プロセッサが、
前記第１のエンティティによって復号可能な少なくとも１つの暗号化された第１の電子健康レコード（ＥＨＲ）サブブロックを受信することであって、前記少なくとも１つのＥＨＲサブブロックが、患者及び１つ又は２つ以上の第１の治療に関する、患者医療保険適用範囲情報を含む、受信することと、
前記第１のＥＨＲサブブロックに応答して、少なくとも１つの対応する第２のエンティティによって復号可能な少なくとも１つの暗号化された第１のデバイス薬物情報（ＤＩＲ）サブブロックを送信することであって、前記少なくとも１つの第１のＤＩＲサブブロックが、前記１つ又は２つ以上の第１の治療の各々について、対応する第１の治療クラスと、各対応する第１の治療クラスに関連付けられた１つ又は２つ以上の対応する第１の治療クラスメンバと、各第１の治療クラスメンバについて、対応する第１の治療クラスメンバコスト情報と、を含む、送信することと、
前記第１のＤＩＲサブブロックに応答して、前記第１のエンティティによって復号可能な暗号化された第２のＥＨＲサブブロックを受信することであって、前記第２のＥＨＲサブブロックが、１つ又は２つ以上の第２の治療を含み、前記１つ又は２つ以上の第２の治療の各々が、対応する第１の治療に関連付けられ、各第２の治療が、前記対応する第１の治療に関連付けられた前記対応する第１の治療クラスメンバから選択される、受信することと、
トランザクション確認に応答して、多次元ブロックチェーンを拡張することであって、前記多次元ブロックチェーンが、前記１つ又は２つ以上の第２の治療に関連付けられた情報を含むＤＩＲブロックと、前記第２のＥＨＲサブブロックに関連付けられた情報を含むＥＨＲブロックと、トランザクションブロックと、をリンクすることによって形成された多次元ブロックで拡張される、拡張することと、を行うように構成されている、コンピューティングデバイス。

【請求項15】

前記第１のＥＨＲサブブロックを受信すると、前記方法が、
前記１つ又は２つ以上の第１の治療の各々について、前記対応する第１の治療クラスを決定することであって、各対応する第１の治療クラスが、前記１つ又は２つ以上の対応する第１の治療クラスメンバを含む、決定することと、
各対応する第１の治療クラスについて、前記１つ又は２つ以上の対応する第１の治療クラスメンバコスト情報を決定することと、を更に含む、請求項１４に記載のコンピューティングデバイス。

【請求項16】

各第１の治療クラスについての前記対応する第１の治療クラスメンバコスト情報に基づいて、前記１つ又は２つ以上の第１の治療、又は前記１つ又は２つ以上の第２の治療、又はそれらの組み合わせ、のうちの少なくとも１つに基づいて、集約コストメトリックを決定することを更に含む、請求項１５に記載のコンピューティングデバイス。

【請求項17】

前記第１のＥＨＲサブブロックが、患者固有パラメータを含み、前記少なくとも１つの治療クラスが、前記患者固有パラメータに基づいて決定される、請求項１に記載のコンピューティングデバイス。

【請求項18】

前記１つ又は２つ以上の対応する第１の治療クラスメンバコスト情報が、
対応する治療単位についての各対応する第１の治療クラスメンバに対応する、患者固有の自己負担コスト、又は
典型的な治療期間についての各対応する第１の治療クラスメンバに対応する、患者固有の推定された総自己負担コスト、又は
前記患者に関連付けられた医療保険適用範囲プランの残りの期間についての各対応する第１の治療クラスメンバに対応する、患者固有の推定された総自己負担コスト、のうちの１つ又は２つ以上を含む、請求項１４に記載のコンピューティングデバイス。

【請求項19】

前記第２のＥＨＲサブブロックを受信すると、前記方法が、
前記１つ又は２つ以上の第２の治療のうちの少なくとも１つについての支払い支援情報を決定することと、
患者に、トランザクション確認を伴う前記支払い支援情報を送信することと、を更に含む、請求項１４に記載のコンピューティングデバイス。

【請求項20】

実行可能命令を含む非一時的コンピュータ可読媒体であって、前記実行可能命令が、プロセッサを、
前記第１のエンティティによって復号可能な少なくとも１つの暗号化された第１の電子健康レコード（ＥＨＲ）サブブロックを受信することであって、前記少なくとも１つのＥＨＲサブブロックが、患者及び１つ又は２つ以上の第１の治療に関する、患者医療保険適用範囲情報を含む、受信することと、
前記第１のＥＨＲサブブロックに応答して、少なくとも１つの対応する第２のエンティティによって復号可能な少なくとも１つの暗号化された第１のデバイス薬物情報（ＤＩＲ）サブブロックを送信することであって、前記少なくとも１つの第１のＤＩＲサブブロックが、前記１つ又は２つ以上の第１の治療の各々について、対応する第１の治療クラスと、各対応する第１の治療クラスに関連付けられた１つ又は２つ以上の対応する第１の治療クラスメンバと、各第１の治療クラスメンバについて、対応する第１の治療クラスメンバコスト情報と、を含む、送信することと、
前記第１のＤＩＲサブブロックに応答して、前記第１のエンティティによって復号可能な暗号化された第２のＥＨＲサブブロックを受信することであって、前記第２のＥＨＲサブブロックが、１つ又は２つ以上の第２の治療を含み、前記１つ又は２つ以上の第２の治療の各々が、対応する第１の治療に関連付けられ、各第２の治療が、前記対応する第１の治療に関連付けられた前記対応する第１の治療クラスメンバから選択される、受信することと、
トランザクション確認に応答して、多次元ブロックチェーンを拡張することであって、前記多次元ブロックチェーンが、前記１つ又は２つ以上の第２の治療に関連付けられた情報を含むＤＩＲブロックと、前記第２のＥＨＲサブブロックに関連付けられた情報を含むＥＨＲブロックと、トランザクションブロックと、をリンクすることによって形成された多次元ブロックで拡張される、拡張することと、を行うように構成されている、非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の相互参照）
本出願は、２０１９年１月１８日に出願された「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＨＥＡＬＴＨＣＡＲＥ ＳＥＣＵＲＩＴＹ ＡＮＤ ＩＮＴＥＲＯＰＥＲＡＢＩＬＩＴＹ」と題された米国特許出願第１６／２５１，９８０号（現在は米国特許第１０，５４１，８０７号）の継続出願である、２０１９年１２月４日に出願された「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＨＥＡＬＴＨＣＡＲＥ ＳＥＣＵＲＩＴＹ ＡＮＤ ＩＮＴＥＲＯＰＥＲＡＢＩＬＩＴＹ」と題された米国特許出願第１６／７０３，８４８号（現在は米国特許第１０，９３１，４３７号）の一部継続出願である、２０２１年１月１４日に出願された「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＨＥＡＬＴＨＣＡＲＥ ＳＥＣＵＲＩＴＹ ＡＮＤ ＩＮＴＥＲＯＰＥＲＡＢＩＬＩＴＹ」と題された米国特許出願第１７／１４９，７０３号の利益及び優先権を主張する。上記で特定した出願は、それらの全体が参照により本明細書に組み込まれる。

【0002】

（発明の分野）
本明細書で開示される主題は、ヘルスケアシステムのセキュリティ及び相互運用性に関し、同時にコスト決定における治療選択及び透明性を促進するものである。

【背景技術】

【0003】

ヘルスケア情報システムは、相互運用性を制限するコンプライアンス問題に直面している。例えば、記憶された情報は、医療保険の携行性及び責任に関する法律（Health Insurance Portability and Accountability Act、ＨＩＰＡＡ）などの様々なプライバシー規制の対象となる場合がある。ＨＩＰＡＡ下のプライバシールールは、ヘルスケアトランザクションが電子的に行われるときの、個人の医療レコード及び他の個人的健康情報を保護するための国内標準規格を定める。これらの規制は、プライバシー（例えば、どのエンティティが情報へのアクセスを有するか）、コンテンツ（認可されたエンティティがどのような情報にアクセスされ得るか）、セキュリティ（情報が、記憶されるとき、及び電子通信の最中に、認可されていないアクセスからどのように保護されるのか）、並びに完全性（情報の正確さ及び信頼性）に及び得る。更に、商業上の貴重な情報は、（例えば、企業秘密として、かつ／又はビジネス若しくは商業上の理由のために）当該情報を第三者と共有することを制限し得る組織的な方針の下で保護され得る。欧州連合（European Union、ＥＵ）一般データ保護規制（General Data Protection Regulation、ＧＤＰＲ）及び国の規制などの規制もまた、情報収集、記憶、共有、及び通信にも大きな影響を及ぼし得る。これらの規制は、ヘルスケア市場参加者に利用可能な情報に影響を及ぼし、エンティティに利用可能な情報が、それが全体的に（例えば、別の非競争的なエンティティにとって）有用である場合であっても、切り離されている組織的な「データ貯蔵庫」の作成につながる。情報のそのような区画化は、システムコストの増大（例えば、治療の別の選択肢のコスト、治療場所等を考慮する患者又は医療提供者による）、患者リスクの上昇（例えば、薬物の相互作用、処方薬の乱用等からの）をもたらし、かつ医療的治療又は修復への成果ベースのアプローチの有効性を限定的なものにしている（例えば、所望の成果がいつ達成されたかを判定すること、又は同様の成果を達成するアプローチのメトリックを比較することを、より困難かつ高価にしている）。

【発明の概要】

【発明が解決しようとする課題】

【0004】

したがって、市場参加者間の相互運用性を促進しながら、ヘルスケア情報セキュリティを容易にすることに役立ち得る、上記の問題のうちの１つ又は２つ以上に対処するシステム及び技術が望まれている。

【課題を解決するための手段】

【0005】

いくつかの実施形態では、プロセッサにより実行される方法は、第１のエンティティによって復号可能な、少なくとも１つの暗号化された第１の電子健康レコード（Electronic Health Record、ＥＨＲ）サブブロックを受信することであって、少なくとも１つのＥＨＲサブブロックが、患者及び１つ又は２つ以上の第１の治療に関する、患者医療保険適用範囲情報を含む、受信することと、第１のＥＨＲサブブロックに応答して、少なくとも１つの対応する第２のエンティティによって復号可能な、少なくとも１つの暗号化された第１の薬物／デバイス情報（Drug/Device Information、ＤＩＲ）サブブロックを送信することであって、少なくとも１つの第１のＤＩＲサブブロックが、１つ又は２つ以上の第１の治療の各々について、対応する第１の治療クラスと、各対応する第１の治療クラスに関連付けられた１つ又は２つ以上の対応する第１の治療クラスメンバと、各第１の治療クラスメンバについて、対応する第１の治療クラスメンバコスト情報と、を含む、送信することと、第１のＤＩＲサブブロックに応答して、第１のエンティティによって復号可能な暗号化された第２のＥＨＲサブブロックを受信することであって、第２のＥＨＲサブブロックが、１つ又は２つ以上の第２の治療を含み、１つ又は２つ以上の第２の治療の各々が、対応する第１の治療に関連付けられ、各第２の治療が、対応する第１の治療に関連付けられた対応する第１の治療クラスメンバから選択される、受信することと、トランザクション確認に応答して、多次元ブロックチェーンを拡張することであって、多次元ブロックチェーンが、１つ又は２つ以上の第２の治療に関連付けられた情報を含むＤＩＲブロックと、第２のＥＨＲサブブロックに関連付けられた情報を含むＥＨＲブロックと、トランザクションブロックと、をリンクすることによって形成された多次元ブロックで拡張される、拡張することと、を含み得る。

【0006】

別の態様では、第１のエンティティのためのコンピューティングデバイスは、メモリと、通信インターフェースと、メモリ及び通信インターフェースに結合されたプロセッサと、を備え得る。いくつかの実施形態では、プロセッサは、第１のエンティティによって復号可能な、少なくとも１つの暗号化された第１の電子健康レコード（ＥＨＲ）サブブロックを受信することであって、少なくとも１つのＥＨＲサブブロックが、患者及び１つ又は２つ以上の第１の治療に関する、患者医療保険適用範囲情報を含む、受信することと、第１のＥＨＲサブブロックに応答して、少なくとも１つの対応する第２のエンティティによって復号可能な、少なくとも１つの暗号化された第１の薬物／デバイス情報（ＤＩＲ）サブブロックを送信することであって、少なくとも１つの第１のＤＩＲサブブロックが、１つ又は２つ以上の第１の治療の各々について、対応する第１の治療クラスと、各対応する第１の治療クラスに関連付けられた１つ又は２つ以上の対応する第１の治療クラスメンバと、各第１の治療クラスメンバについて、対応する第１の治療クラスメンバコスト情報と、を含む、送信することと、第１のＤＩＲサブブロックに応答して、第１のエンティティによって復号可能な暗号化された第２のＥＨＲサブブロックを受信することであって、第２のＥＨＲサブブロックが、１つ又は２つ以上の第２の治療を含み、１つ又は２つ以上の第２の治療の各々が、対応する第１の治療に関連付けられ、各第２の治療が、対応する第１の治療に関連付けられた対応する第１の治療クラスメンバから選択される、受信することと、トランザクション確認に応答して、多次元ブロックチェーンを拡張することであって、多次元ブロックチェーンが、１つ又は２つ以上の第２の治療に関連付けられた情報を含むＤＩＲブロックと、第２のＥＨＲサブブロックに関連付けられた情報を含むＥＨＲブロックと、トランザクションブロックと、をリンクすることによって形成された多次元ブロックで拡張される、拡張することと、を行うように構成され得る。

【0007】

更なる態様では、装置は、第１のエンティティによって復号可能な、少なくとも１つの暗号化された第１の電子健康レコード（ＥＨＲ）サブブロックを受信するための手段であって、少なくとも１つのＥＨＲサブブロックが、患者及び１つ又は２つ以上の第１の治療に関する、患者医療保険適用範囲情報を含む、手段と、第１のＥＨＲサブブロックに応答して、少なくとも１つの対応する第２のエンティティによって復号可能な、少なくとも１つの暗号化された第１の薬物／デバイス情報（ＤＩＲ）サブブロックを送信するための手段であって、少なくとも１つの第１のＤＩＲサブブロックが、１つ又は２つ以上の第１の治療の各々について、対応する第１の治療クラスと、各対応する第１の治療クラスに関連付けられた１つ又は２つ以上の対応する第１の治療クラスメンバと、各第１の治療クラスメンバについて、対応する第１の治療クラスメンバコスト情報と、を含む、手段と、第１のＤＩＲサブブロックに応答して、第１のエンティティによって復号可能な暗号化された第２のＥＨＲサブブロックを受信するための手段であって、第２のＥＨＲサブブロックが、１つ又は２つ以上の第２の治療を含み、１つ又は２つ以上の第２の治療の各々が、対応する第１の治療に関連付けられ、各第２の治療が、対応する第１の治療に関連付けられた対応する第１の治療クラスメンバから選択される、手段と、トランザクション確認に応答して、多次元ブロックチェーンを拡張するための手段であって、多次元ブロックチェーンが、１つ又は２つ以上の第２の治療に関連付けられた情報を含むＤＩＲブロックと、第２のＥＨＲサブブロックに関連付けられた情報を含むＥＨＲブロックと、トランザクションブロックと、をリンクすることによって形成された多次元ブロックで拡張される、手段と、を含み得る。

【0008】

いくつかの実施形態では、非一時的コンピュータ可読媒体は、実行可能な命令を含み得、実行可能な命令は、プロセッサを、第１のエンティティによって復号可能な、少なくとも１つの暗号化された第１の電子健康レコード（ＥＨＲ）サブブロックを受信することであって、少なくとも１つのＥＨＲサブブロックが、患者及び１つ又は２つ以上の第１の治療に関する、患者医療保険適用範囲情報を含む、受信することと、第１のＥＨＲサブブロックに応答して、少なくとも１つの対応する第２のエンティティによって復号可能な、少なくとも１つの暗号化された第１の薬物／デバイス情報（ＤＩＲ）サブブロックを送信することであって、少なくとも１つの第１のＤＩＲサブブロックが、１つ又は２つ以上の第１の治療の各々について、対応する第１の治療クラスと、各対応する第１の治療クラスに関連付けられた１つ又は２つ以上の対応する第１の治療クラスメンバと、各第１の治療クラスメンバについて、対応する第１の治療クラスメンバコスト情報と、を含む、送信することと、第１のＤＩＲサブブロックに応答して、第１のエンティティによって復号可能な暗号化された第２のＥＨＲサブブロックを受信することであって、第２のＥＨＲサブブロックが、１つ又は２つ以上の第２の治療を含み、１つ又は２つ以上の第２の治療の各々が、対応する第１の治療に関連付けられ、各第２の治療が、対応する第１の治療に関連付けられた対応する第１の治療クラスメンバから選択される、受信することと、トランザクション確認に応答して、多次元ブロックチェーンを拡張することであって、多次元ブロックチェーンが、１つ又は２つ以上の第２の治療に関連付けられた情報を含むＤＩＲブロックと、第２のＥＨＲサブブロックに関連付けられた情報を含むＥＨＲブロックと、トランザクションブロックと、をリンクすることによって形成された多次元ブロックで拡張される、拡張することと、を行うように構成され得る。

【0009】

更に、別の態様では、プロセッサにより実行される方法は、第１のエンティティによって復号可能な、少なくとも１つの暗号化された第１の健康トランザクションレコード（Health Transaction Record、ＨＴＲ）サブブロックから、ある時間期間にわたる患者についての第１の治療の第１のセットを取得することであって、各第１の治療が第１の診断コード及び第１の治療コードを含む、取得することと、第１のセットに基づいて、（ａ）第２の治療の１つ又は２つ以上の第２のセットであって、各対応する第２の治療が、第１のセット内の異なる第１の治療に関連付けられた、第２の治療の１つ又は２つ以上の第２のセットと、（ｂ）各第２の治療に対する対応する再発数と、を取得することと、患者に利用可能な、利用可能な保険プランのセットと、各利用可能な保険プランについての対応する保険適用範囲関連情報と、を取得することと、第２の治療のセットと各保険プランの対応する保険適用範囲関連情報とに基づいて、患者のプラン固有の対応する推定コストメトリックを取得することと、少なくとも１つの第２のエンティティによって復号可能な第１の暗号化された薬物／デバイス情報レコード（ＤＩＲ）サブブロックを送信することであって、ＤＩＲサブブロックが、患者のプラン固有のコストメトリックを含む、送信することと、を含み得る。

【0010】

いくつかの実施形態では、第１のエンティティのためのコンピューティングデバイスは、メモリと、通信インターフェースと、メモリ及び通信インターフェースに結合されたプロセッサと、を備え得る。いくつかの実施形態では、プロセッサは、第１のエンティティによって復号可能な、少なくとも１つの暗号化された第１の健康トランザクションレコード（ＨＴＲ）サブブロックから、ある時間期間にわたる患者についての第１の治療の第１のセットを取得することであって、各第１の治療が、第１の診断コード及び第１の治療コードを含む、取得することと、第１のセットに基づいて、（ａ）第２の治療の１つ又は２つ以上の第２のセットであって、各対応する第２の治療が、第１のセット内の異なる第１の治療に関連付けられた、第２の治療の１つ又は２つ以上の第２のセットと、（ｂ）各第２の治療に対する対応する再発数と、を取得することと、患者に利用可能な、利用可能な保険プランのセットと、各利用可能な保険プランについての対応する保険適用範囲関連情報と、を取得することと、第２の治療のセットと各保険プランの対応する保険適用範囲関連情報とに基づいて、患者のプラン固有の対応する推定コストメトリックを取得することと、少なくとも１つの第２のエンティティによって復号可能な第１の暗号化された薬物／デバイス情報レコード（ＤＩＲ）サブブロックを送信することであって、ＤＩＲサブブロックが、患者のプラン固有のコストメトリックを含む、送信することと、を行うように構成され得る。

【0011】

更なる態様では、装置は、第１のエンティティによって復号可能な少なくとも１つの暗号化された第１の健康トランザクションレコード（ＨＴＲ）サブブロックから、ある期間にわたる患者についての第１の処置の第１のセットを取得するための手段であって、各第１の治療が第１の診断コード及び第１の治療コードを含む、手段と、第１のセットに基づいて、（ａ）第２の治療の１つ又は２つ以上の第２のセットであって、各対応する第２の治療が、第１のセット内の異なる第１の治療に関連付けられた、第２の治療の１つ又は２つ以上の第２のセットと、（ｂ）各第２の治療に対する対応する再発数と、を取得するための手段と、患者に利用可能な、利用可能な保険プランのセットと、各利用可能な保険プランについての対応する保険適用範囲関連情報と、を取得するための手段と、第２の治療のセットと各保険プランの対応する適用範囲関連情報とに基づいて、患者のプラン固有の対応する推定コストメトリックを取得するための手段と、少なくとも１つの第２のエンティティによって復号可能な第１の暗号化された薬物／デバイス情報レコード（ＤＩＲ）サブブロックを送信するための手段であって、ＤＩＲサブブロックが、患者のプラン固有のコストメトリックを含む、手段と、を含み得る。

【0012】

いくつかの実施形態では、非一時的コンピュータ可読媒体は、実行可能な命令を含み得、実行可能な命令は、プロセッサを、第１のエンティティによって復号可能な、少なくとも１つの暗号化された第１の健康トランザクションレコード（ＨＴＲ）サブブロックから、ある時間期間にわたる患者についての第１の治療の第１のセットを取得することであって、各第１の治療が、第１の診断コード及び第１の治療コードを含む、取得することと、第１のセットに基づいて、（ａ）第２の治療の１つ又は２つ以上の第２のセットであって、各対応する第２の治療が、第１のセット内の異なる第１の治療に関連付けられた、第２の治療の１つ又は２つ以上の第２のセットと、（ｂ）各第２の治療に対する対応する再発数と、を取得することと、患者に利用可能な、利用可能な保険プランのセットと、各利用可能な保険プランについての対応する保険適用範囲関連情報と、を取得することと、第２の治療のセットと各保険プランの対応する保険適用範囲関連情報とに基づいて、患者のプラン固有の対応する推定コストメトリックを取得することと、少なくとも１つの第２のエンティティによって復号可能な第１の暗号化された薬物／デバイス情報レコード（ＤＩＲ）サブブロックを送信することであって、ＤＩＲサブブロックが、患者のプラン固有のコストメトリックを含む、送信することと、を行うように構成され得る。

【0013】

開示される方法は、コンピュータ可読媒体又はコンピュータ可読メモリを使用して、サーバ、クラウドベースシステム等を含むモバイルコンピューティングデバイス、コンピュータのうちの１つ又は２つ以上によって実施され得る。

【図面の簡単な説明】

【0014】

本発明の実施形態は、図面を参照して、例を介してのみ説明されるであろう。

【図1】従来のヘルスケア情報システムに関連付けられたいくつかのエンティティ間のインタラクションを示す概略ブロック図を示す。

【図2】レコード内のいくつかの例示的なデータフィールドを示す例示的な電子健康レコードを示す。

【図3A】薬物のための例示的な薬物／デバイス情報レコード（ＤＩＲ）の一部分を示す。

【図3B】薬物のための例示的な薬物／デバイス情報レコード（ＤＩＲ）の一部分を示す。

【図3C】最初の提案された処方から、コスト情報とともに患者及び／又はＨＣＰに提示され得る選択肢への、例示的なデータフローを示す。

【図4】薬局給付管理者によって維持され得る、例示的な薬局給付レコード（Pharmacy Benefits Record、ＰＢＲ）の一部分を示す。

【図5】ｐ薬局などのエンティティによって維持され得る例示的な薬局処方レコードを示す。

【図6】例示的な健康トランザクションレコードを示す

【図7A】ヘルスケアコスト決定、ヘルスケア情報セキュリティを容易にし、複数のエンティティ間の相互運用性を容易にするための例示的なプロセスフローを示すフロー図を示す。

【図7B】ヘルスケアシステムのセキュリティ及び相互運用性を容易にするための例示的なプラットフォームに関連付けられたエンティティ及びレイヤを示す。

【図8】患者治療選択と治療コストの透明性とを促進しながらヘルスケア情報セキュリティ及び相互運用性を促進するための、例示的な方法のフローチャートを示す。

【図9】ヘルスケア情報セキュリティを維持し、複数のエンティティ間の相互運用性を容易にしながら、ヘルスケア保険選択及びコスト決定を容易にするための例示的なプロセスフローを示すフロー図を示す。

【図10A】ヘルスケア情報セキュリティを維持しながら、ヘルスケア保険選択及びコスト決定を容易にし、複数のエンティティ間の相互運用性を容易にするための例示的な方法のフローチャートを示す。

【図10B】ヘルスケア情報セキュリティを維持しながら、ヘルスケア保険選択及びコスト決定を容易にし、複数のエンティティ間の相互運用性を容易にするための例示的な方法のフローチャートを示す。

【図11】ヘルスケアシステムのセキュリティを容易にし、相互運用性を促進することが可能な例示的コンピュータ又はコンピューティングデバイスの概略図を示す。

【0015】

図において、特定の例示的な実施形態を描写する様々な図における同様の参照番号及び記号は、同様の要素を示す。例えば、同様の情報を有するサブブロックは、同じ参照番号を用いて参照される。加えて、ある要素の複数のインスタンスは、その要素に対する第１の数字に文字又はハイフン、及び第２の数字が続くことによって示され得る。例えば、要素２８０の複数のインスタンスは、２８０－１、２８０－２等として示され得る。第１の数字のみを使用してそのような要素に言及する場合、その要素の任意のインスタンスが理解されるべきである（例えば、前の例における要素２８０は、要素２８０－１、２８０－２．．．及び／又は２８０－Ｎに言及するであろう）。更に、以下の図において、参照番号に関連付けられたアスタリスク記号（「＊」）は、その要素（又はその一部分）が（例えば、その要素の各インスタンスについて）繰り返され得ることを示す。例えば、処方は、いくつかの薬物インスタンスを含み得、投与量フィールドは、各薬物インスタンスに対して繰り返され得る。

【0016】

以下の図はまた、フィールド及びサブフィールドを含み得るレコードの階層を示す。レコードは、レコードの一部である任意のフィールド（及びサブブロックの一部又は全部）を含む。同様に、フィールドは、任意のサブフィールドを含む。サブフィールドは、追加のサブフィールドを含み得る。

【発明を実施するための形態】

【0017】

開示される実施形態は、ヘルスケアシステムの完全性、相互運用性、治療選択、及びコストの透明性を促進しながら、ヘルスケアシステムのセキュリティを容易にする。

【0018】

図１は、従来のヘルスケア情報システム１００に関連付けられたいくつかのエンティティ間のインタラクションを示す概略ブロック図を示す。ヘルスケアトランザクションには、いくつかのエンティティが関与し得、ここで、各エンティティは、そのトランザクション関連のいくつかの情報を有し得、それらの情報は、トランザクションを完了させるために使用され得る。したがって、従来のシステムでは、トランザクションを完了するために、いくつかの限定された情報（例えば、規制、コントラクト、プライバシー考慮事項、機密性によって、かつ／又は競合的理由で限定される）が、トランザクションエンティティ間で交換され得る。本明細書で使用されるときの「エンティティ」という用語は、個人（患者若しくは患者群など）又は組織若しくはヘルスケア市場に参加するもの、並びに／あるいは個人／グループ／組織の代理としてヘルスケア市場に参加し得る、個人／グループ／組織に関連付けられたコンピューティングシステム及び情報システム（例えばハードウェア及び／又はソフトウェア）を指し得る。例えば、１つのエンティティに関連付けられたコンピューティングシステムは、他のエンティティに関連付けられたコンピューティングシステムを用いて、情報を処理及び／又は交換され得る。エンティティ間の情報の交換は、安全な通信ネットワークを介して行うことができ、並びに／又はインターネットを介した、及び／若しくは電子プラットフォーム上で（例えば、情報交換及び／又はトランザクション交換など）、安全な方法で（例えば、暗号化を使用して）行うことができる。

【0019】

患者などのエンティティ（図１には示さず）は、患者を悩ましている病状について、ヘルスケア提供者（Healthcare Provider、ＨＣＰ）１２０などの別のエンティティの治療を求めることができる。ＨＣＰ１２０は、健康情報（health information、ＨＩ）データベース１２５を使用して患者治療情報及び患者保険を決定され得、健康情報（ＨＩ）データベース１２５は、ＨＣＰ１２０によって維持され、患者保険適用範囲関連情報１２４を含み得る。更に、ＨＣＰ１２０は、患者の病状に対する治療を提案され得る。処方すべき治療を提案する場合、ＨＣＰ１２０は、治療情報１２３を医薬品提供者及び／又は医療デバイス提供者（Pharmaceutical Provider and/or Medical Device Provider、ＰＭＤＰ）１３０に送信され得る。ＰＭＤＰ１３０に送信される治療情報１２３は、任意の患者の個人識別可能情報（personally identifiable information、ＰＩＩ）を含まない場合がある。

【0020】

個人識別可能情報（ＰＩＩ）は、特定の個人を識別するために使用される可能性のある任意のデータである。「非ＰＩＩ」という用語は、本明細書では、ＰＩＩを含まない情報を修飾するために使用される。例えば、（ＰＩＩを有する）患者データレコードは、健康関連情報とともに、患者の名前、完全な住所、他の識別子（例えば、保険識別子、運転免許証番号、社会保障番号、及び／又は他の識別情報）を含み得る。患者のデータレコード内のＰＩＩを除去して、（名前、完全な住所、及び他の識別情報を含まない）非ＰＩＩ患者データレコードを得ることができる。例えば、非ＰＩＩ患者データレコードは、年齢、性別、医療履歴（例えば、患者が罹患している病状、患者によって使用されている他の薬剤等）、治療、並びに任意選択で（例えば、適切な場合）都市、州、及び／又は郵便番号を含み得、ＨＣＰ１２０の完全な住所（ケアが送達された場所）を含み得る。

【0021】

それに応答して、ＰＭＤＰ１３０は、薬物／デバイス情報レコード（ＤＩＲ）データベース１３５内の情報に基づいて、薬物／デバイスプロファイル及び安全性情報１３３をＨＣＰ１２０に送信され得る。ＤＩＲデータベース１３５は、薬物／デバイスプロファイル及び安全性情報１３３を含み得る。薬物／デバイスプロファイル及び安全性情報１３３としては、投与量、投与様式、吸収、代謝、作用持続時間、毒性、及び食品又は他の薬剤との相互作用などの薬物特性についての情報が挙げられ得る。薬物／デバイスプロファイル及び安全性情報１３３を受信すると、ＨＣＰは、１つ又は２つ以上の薬物及び／若しくは医療デバイス及び／若しくは処置を処方され得、又は薬物／デバイスプロファイル及び安全性情報１３３に基づいて、その処方を修正され得る。

【0022】

図１に示すように、ＨＣＰ１２０はまた、記憶された、患者の保険及び治療（例えば、医療処置関連）情報１２４を支払人／保険業者（以下、「支払人」）１４０に、処方情報１２７を薬局１６０に、安全に送信し得る。処方情報１３２は、患者ＩＤ及び治療（例えば、薬物及び／又はデバイス）情報を含み得る。保険関連及び治療情報１２４は、患者識別（identification、ＩＤ）情報、保険プラン情報、グループＩＤ情報、提案された治療情報（例えば、医療処置関連情報、薬物関連情報、医療デバイス関連情報等のうちの１つ又は２つ以上）を含み得る。保険関連及び治療情報１２４は、何らかの個人識別可能情報（ＰＩＩ）を含み得るが、共有されるＰＩＩ情報は制限され得る。例えば、患者の保険及び治療情報１２４は、患者の家族歴及び／又は他の患者情報（ＨＩデータベース１２５の一部であり得る）を含まない場合があるが、保険適用範囲決定及び／又はコスト決定に関連しない場合があり、かつ／又は（例えば、法律／規制によって）支払人１４０と共有されないようにされ得る。

【0023】

薬局１６０は、受信した患者処方情報１２７を使用して、患者処方情報（Patient-Prescription information、ＰＰＩ）データベース１５５に入力及び／又はそれを更新し得、患者保険適用範囲及び治療関連情報１６３を薬局給付管理者（Pharmacy Benefit Manager、ＰＢＭ）１５０に送信し得る。

【0024】

ＰＢＭ１５０は、医薬品（薬物及び／又はデバイス）への患者アクセスにおいて役割を果たすエンティティである。ＰＢＭ１５０は、ＰＢＭ１５０に基づいて薬価を決定し、医薬品の小売価格を設定又は決定し、特定の製品又は製品のバスケットの販売量に基づいて製造業者から支払い又は割り戻しを取得し、また場合によっては、支払人１４０のための「処方集」上の薬局から販売後価格譲渡及び支払いを取得することもできる。処方集は、患者に利用可能な薬物を、その薬物の保険適用範囲と薬物コストの配分（例えば、保険適用される各薬物に対する、患者によって行われる支払いの割合及び支払人１４０によって支払われる割合）とに基づいて決定し得る。更に、処方集は、典型的に、薬物を複数のコスト負担区分のうちの１つに割り当てる。処方された薬物及び薬物のコスト負担区分（両方とも患者の健康又は処方保険適用範囲に依存し得る）は、薬局における患者の自己負担コストを決定し得る。例えば、好ましい区分の薬物は、より低いコスト負担要件（例えば、より低い共同保険額）を有し得る。

【0025】

したがって、薬局における患者の薬物のコストの最終的な負担は、（ａ）プランの免責額（支払人のコストが負担される前に患者によって各プラン期間に支払われる特定の額）、（ｂ）自己負担金（患者の医療保険によって指定された各トランザクションに対する固定の自己負担支払い）、及び（ｃ）共同保険（免責額要件及び自己負担金要件が満たされた後に患者が負担する薬物コストの割合）に依存し得る。場合によっては、患者資格情報に基づいて、医薬品／医療デバイス提供（ＰＭＤＰ）１３０は、前払いの支払い支援を患者に提供され得る。患者資格情報は、健康保険適用範囲情報、患者の自己負担コスト（個々の処方又はある時間期間にわたる自己負担金、共同負担、及び免責額のうちの１つ又は２つ以上を含み得る）、及び患者に関連付けられた人口統計情報（例えば、患者の場所、年齢、障害情報、収入、処方コスト等のうちの１つ又は２つ以上）のうちの１つ又は２つ以上を含み得る。従来、患者支払い支援は、患者の自己負担コストに適用される物理的な患者固有の割引カードとして提供され得る。患者支払い支援は、患者アクセスプログラムを通してＰＭＤＰ１３０によって提供され得、これは、場合によっては、適用される法律及び規制に従って別個に管理され得る。関与するエンティティの数及びエンティティによるデータ区画化に起因するコスト決定の複雑さに部分的に起因して、患者コスト情報は、典型的には、ＨＣＰによる処方時にＨＣＰ１２０及び／又は患者に利用可能ではない（薬局１６０及び／又はＰＢＭ１５０が患者コスト負担を決定した後にのみ利用可能であり得る）。

【0026】

医療処置の場合、支払人１４０は、受信した患者保険適用範囲関連情報１２４を、プラン／保険適用範囲データベース１４５内の情報と比較して、患者の保険適用範囲を判定され得る。その保険適用範囲情報に基づいて、支払人１４０は、トランザクション情報データベース１４７を更新し、確認及び／又は追加／更新された患者保険適用範囲関連情報１２４をＨＣＰ１２０に返信され得る。患者保険適用範囲関連情報１２４としては、承認／否認情報、提案される治療に関連する保険適用範囲情報、並びに患者の自己負担金、請求書コード等のコスト及び支払関連情報を挙げることができる。支払人が承認を保留し、又は提案される治療の保険適用範囲が不適当であり、かつ／若しくは患者のコスト基準を満たさない場合、ＨＣＰ１２０は、修正を提案し得、その修正は、ＨＣＰ１２０と支払人１４０との間の情報の更なる交換をもたらし得る。ＨＣＰ１２０、支払人１４０と、ＰＭＤＰ１３０との間のインタラクションは、ＨＣＰ１２０が、（ａ）患者にとって許容可能であり、（ｂ）安全性及び有効性の考慮事項を満たし、（ｃ）支払人１４０によって負担され得、かつ／又は承認され得る、治療計画を最終承認するまで、継続され得る。

【0027】

薬物及び／又はデバイスに関して、ＰＢＭ１５０は、患者（又はＨＣＰ）から受信された保険適用範囲関連情報を薬局給付情報（Pharmacy Benefit Information、ＰＢＩ）データベース１５５内の情報とともに使用して、患者保険適用範囲、処方された薬物が保険適用されるかどうか、自己負担の患者薬物コスト、薬物コストの保険負担等を判定し得る。治療（例えば、薬物及び／又はデバイス）が保険適用されると、ＰＢＭ１５０は、コスト情報１５３を薬局１６０に送信し得る。コスト情報１５３（患者の自己負担コスト、保険コスト、コスト内訳、及び／又は他の情報のうちの１つ又は２つ以上を含み得る）は、薬局１６０に送信され得、薬局１６０は、受信したコスト情報１５３を使用して、ＰＰＩデータベース１５５を更新し得る。患者が、後に処方を（例えば薬局１６０から患者によって取得された自己負担コスト情報に基づいて、異なる又はより低いコストの薬物に）変更したい場合、プロセスは繰り返される必要があり得、これは、患者、ＨＣＰ１２０、薬局１６０、及び／又はＰＢＭ１５０、の間の更なる情報交換につながり得る。コスト情報は、従来、ＨＣＰによる処方時にＨＣＰ１２０及び／又は患者に利用可能ではないので、患者及び／又はＨＣＰ１２０は、自己負担コストが薬局１６０によって（例えば、ＰＢＭ１５０によって提供される情報に基づいて）判定されるまで、処方のコスト関連側面に気付かない場合がある。したがって、患者にとってコストが許容可能でない場合、処方された治療は変更される必要があり得（又は履行されないままになり得）、それによって、システムの非効率性及び不十分な資源利用につながる。

【0028】

加えて、例えば、支払人１４０とＰＢＭ１５０との間で、患者の保険適用範囲（例えば、患者が現在保険適用されている否か）、支払情報（例えば、残りの患者免責額等）を交換／検証するための他の情報交換が存在し得る。ＰＢＭ１５０は、患者保険適用範囲情報１４２を支払人１５０に送信し、保険適用範囲が現在のものであるかどうかの確認及び免責額関連情報を受信し得、これは、ＰＢＭが自己負担患者コストを決定するために使用され得る。更に、ＰＭＤＰ１３０及びＰＢＭは、販売及び割り戻し関連情報１３２を交換し得、ＰＭＤＰ１３０及び支払人１４０は、コントラクト関連情報及び／又は薬物／デバイス価格設定関連情報１３７を交換し得る。

【0029】

したがって、従来のヘルスケア情報システムは、いくつかの欠点を抱えている。各エンティティは、そのビジネスを運用するのに関連し得る情報を取得及び維持するが、その情報のうちの極めてわずかしか共有され得ず（例えば、法律上、プライバシー、及び／又はビジネス上の考慮事項に起因して）、情報が共有されたときには、その情報は、断片的で、脈絡に欠け、タイムリーではなく、意思決定／計画の目的には有用でない場合がある。例えば、ＨＣＰ１２０及び／又は患者は、処方時に治療に関連するコスト情報を有していない場合がある。別の例として、治療代替物及び様々な治療代替物のコストは、処方又は治療計画が開発されている時期には、患者又はＨＣＰ１２０にとって利用不可能である場合がある。

【0030】

別の例として、ＨＣＰ１２０は、患者によってＰＭＤＰ１３０に報告され得る有害薬物効果の詳細を提供しないことがある（例えば、プライバシーの懸念のため）。別の例として、有害薬物効果情報がＨＣＰ１２０によってＰＭＤＰ１３０に提供された場合、その情報は、非ＰＩＩ人口統計情報（例えば、ここでもプライバシーの懸念のため、患者の年齢、場所、病状等を）含まない場合があり、その結果、その情報は、ＰＭＤＰ１３０にとって限定された値となり得る。加えて、場合によっては、有害薬物効果がエンティティ（例えば、患者）によって報告される場合、その有害薬物効果の検証は、しばしば別のエンティティによって実施されて、その有害事象が所定の薬物に起因し得るかどうかを判定され得る。検証は、追加のエンティティを必要とし得、報告を更に遅らせ、かつ／又は追加の貯蔵庫を作成し得る追加の複雑さを導き出し得、それによって、その情報の有用性を更に制限し得る（例えば、ＰＭＤＰ１３０にとって）。

【0031】

更に、交換された情報は区画化され得、その場限りで提供され得るため、その受信した情報を、受信側エンティティによって記憶される情報とともに集約することは、煩雑であり得る。更に、各エンティティがその情報を異なるものとして索引を付け得るため、受信側エンティティ（又は送信側エンティティ）が、受信した（送信した）情報を、送信側エンティティによって記憶された（又は受信側エンティティによって記憶された）情報レコードに結び付けることは、困難又は不可能であり得る。例えば、ＨＣＰ１２０がある時点で有害薬物効果情報をＰＭＤＰ１３０に提供する場合、その情報が法律上共有され得る場合であっても、ＨＣＰ１２０及び／又はＰＭＤＰ１３０が、有害薬物効果に関連する追加の患者又は患者病状情報を取得することは困難であり得る。例えば、情報の区画化により、ＰＭＤＰ１３０によるアクセスを防止又は制限して、調整する薬物利用に使用され得る人口統計情報を集約し得る。更なる例として、ＨＣＰ１２０及び／又は支払人１４０が患者による処方薬の乱用を判定することは、困難であり得る。

【0032】

多くの現代の機械学習（machine learning、ＭＬ）及び他の人工知能（artificial intelligence、ＡＩ）システムは、大量のデータを処理して、危険性を判定し、所望の成果等につながり得るパターンを識別することができ、それらのパターンにより、効率の増大、更なる低コスト、及び／又はより良好な成果をもたらし得る。情報の貯蔵及び区画化はまた、そのようなＭＬ及びＡＩ技術の適用性も制限し、それによって、更なる非効率性の一因となる。

【0033】

効率性をヘルスケア送達に導入するためのいくつかの取り組みが、成果ベースのアプローチに焦点を当てている。支払人１４０は、成果について合意されたいくつかの達成に対して償還を結び付け得る。例えば、成果ベースのコントラクトは、ＨＣＰ１２０が、ある期間内のある規定された範囲まで患者の血圧を低減することに基づく速度に関して合意されたある速度で償還され得ることを明記し得る。そのような成果ベースのコントラクトを追跡及び管理することは、いくつかの情報交換が、各交換が法律上、規制上、プライバシー、及びビジネス上関連するガイドラインに従っている、ＨＣＰ１２０と支払人１４０との間で生じる必要があり得るため、従来のシステムでは、よくない意味で知られているように、困難であり得る。

【0034】

健康関連情報を記憶するためのブロックチェーンの使用は、記憶された情報の完全性及び信頼性の保証を容易にすることができるが、従来の技法は、情報区画化を減少させながらデータプライバシーを維持するなど、トランザクション及び規制の複雑さが増大する環境におけるエンティティ間のデータ共有によって生じる問題に対処していない。更に、従来の技法はまた、トランザクション最終承認を容易にするために、（例えば、法的上及び規制上の義務に準拠した様式で１つ又は２つ以上のエンティティに対する）タイムリーな情報の利用可能性を保証しない。更に、従来の技法は、完了したトランザクションの整合性のとれた一貫した閲覧をエンティティが有することを保証しない。エンティティにわたる完了したトランザクションの整合性のとれた一貫した閲覧の欠如は、相互運用性、データ利用性、及び動作効率性の向上の追求を制約する場合がある。加えて、顧客（例えば、患者）が意思決定を（例えば、ＨＣＰから独立して、又はＨＣＰと連携して）支援又は強化するための情報をリクエストすることは、対応することが困難であり得るため、相互運用性に対する制約は、しばしば、顧客中心の焦点を維持する組織能力を制限する。

【0035】

開示される実施形態は、ヘルスケアシステムの完全性、相互運用性を促進しながらヘルスケアシステムのセキュリティを容易にし、ヘルスケアコストの透明性を促進する。いくつかの開示された技術は、適切なエンティティ（例えば、トランザクションに関連付けられた認可されたエンティティ）への適切なデータ（例えば、法的、プライバシー、及びビジネスガイドラインに準拠している）の交換（例えば、トランザクションの時点での）をタイムリーに容易にし、同時にヘルスケア市場エンティティにわたって情報の一貫して整合性のとれた閲覧を容易にする。

【0036】

相互運用性は、部分的に容易にされる。なぜなら、トランザクションに関連付けられた複数のエンティティが、基準に基づく合意を使用して、トランザクション中に共有された適切な関連情報を完了したトランザクションに結び付けることを可能にし得るからである。ローカルに記録されたデータ（例えば、エンティティにおいてローカルに）は、基準データ（例えば、共有プラットフォーム上に維持される）に対応し得、基準データの各エンティティの閲覧（又はエンティティによって閲覧可能な基準データの一部分）が、データの別の認可されたエンティティの閲覧（及び／又は他の認可されたエンティティのローカルに記録されたデータ）と一貫し得るので、一貫性及び整合性が容易になる。いくつかの実施形態では、基準データは、分散台帳に基づき得、かつ／又は分散台帳の形態をとることができる。いくつかの実施形態では、分散台帳は、認可されたエンティティにアクセス可能であり得、分散台帳の各エンティティの閲覧は、法的、プライバシー、ビジネス、及び／又は契約義務に準拠し得る。更に、効率性が促進される。なぜなら、意思決定に関連する情報がトランザクションサイクルの早期にエンティティに利用可能にされて代替案の早期検討を容易にし、それによりトランザクション最終承認の可能性とトランザクション最終承認に関連する非効率性とを減少させ、意思再検討を減少させるからである。

【0037】

いくつかの実施形態では、第１のエンティティ（例えば、ＰＭＤＰ１３０）は、第１のエンティティによって復号可能である少なくとも１つの暗号化された（例えば、患者についての）第１の電子健康レコード（ＥＨＲ）サブブロックを受信し得る。第１のＥＨＲサブブロックは、Ｆ＿ｐ、１≦ｐ≦Ｐによって表される、患者及び１つ又は２つ以上の第１の治療（例えば、提案された薬物及び／又はデバイスについての患者医療保険適用範囲情報を含み得る。暗号化された第１のＥＨＲサブブロックは、現在のトランザクションについてのトランザクションＩＤとともに（例えば、ＰＭＤＰ１３０によって）受信され得、場合によっては、患者についてのＰＩＩ情報を含まない場合がある。他の場合（例えば、認可されたとき、かつ／又はＰＭＤＰ１３０が、ＰＭＤＰ１３０によって管理される支払い支援プログラムに対する患者の適格性を判定若しくは使用するとき）、暗号化された第１のＥＨＲサブブロックは、現在のトランザクションについてのトランザクションＩＤとともに（例えば、ＰＭＤＰ１３０によって）受信され得、患者についてのＰＩＩ情報を更に含み得る。患者ＰＩＩ情報が（例えば、ＰＭＤＰ１３０によって）受信される状況では、ＰＭＤＰ１３０は、支払い支援プログラムを管理し、それに資金供給し得、開示される実施形態と一致するローカルに維持されたブロックチェーンを使用して、患者ＰＩＩ情報へのアクセスがプログラム管理者及び／又は認可された人員に制限されるように、ＰＭＤＰの代理として患者プライバシーを維持し得る。ＰＩＩ情報を提供するための認可は、患者から（例えば、ＨＣＰ１２０又はＰＭＤＰ１３０又は別のエンティティによって事前に）取得され得る。いくつかの実施形態では、第１のＥＨＲサブブロックは、患者が、臨床試験参加適格性を判定するために第１のＥＨＲサブブロック内の情報を使用することに同意したことを更に示すことができる。

【0038】

第１のエンティティ（例えば、ＰＭＤＰ１３０）は、第１のＥＨＲサブブロックに応答して、少なくとも１つの対応する第２のエンティティ（例えば、ＨＣＰ１２０）によって復号可能な、少なくとも１つの暗号化された第１のデバイス薬物情報（ＤＩＲ）サブブロックを送信し得、ＤＩＲサブブロックは、１つ又は２つ以上の第１の治療（Ｆ＿ｐ、１≦ｐ≦Ｐ）の各々について、対応する第１の治療クラス（例えば、Ｆ＿ｐと同じクラスにある薬物／デバイスを表すＫ＿ｐ）を含む。各治療クラスＫ＿ｐは、１つ又は２つ以上の対応する第１の治療クラスメンバ（Ｃ＿ｐｄ、（１≦ｐ≦Ｐ、１≦ｄ≦Ｄ＿ｐで表される個々の薬物／デバイス）を含み得、各第１の治療クラスメンバ（Ｃ＿ｐｄ）は、対応する第１の治療クラスメンバコスト情報（Ｍ＿ｐｄ）に関連付けられ得る。対応する第１の治療クラスメンバ（Ｃ＿ｐｄ）についての第１の治療クラスメンバコスト情報（Ｍ＿ｐｄ）は、自己負担コスト、予想される治療期間にわたる総コスト、治療、何らかの指定された時間期間にわたるコスト等を含み得る）。Ｄ＿ｐは、治療クラスＫ＿ｐ内のクラスメンバの数を表し得る。

【0039】

例えば、第１のＥＨＲサブブロックを受信すると、第１のエンティティ（例えば、ＰＭＤＰ１３０）は、１つ又は２つ以上の第１の治療（Ｆ＿ｐ）のそれぞれについて、対応する第１の治療クラス（Ｋ＿ｐ）を決定し得る。更に、いくつかの実施形態では、第１のＥＨＲサブブロックは、患者固有パラメータを含み得、対応する第１の治療クラスは、患者固有パラメータに基づいて決定され得る。患者固有パラメータは、患者の併存疾患情報、投与経路情報、安全性及び有効性情報、並びに／又は患者の位置情報のうちの１つ又は２つ以上を含み得る。したがって、対応する第１の治療クラス（治療Ｆ＿ｐに対応するＫ＿ｐ）内のメンバＣ＿ｐｄは、患者固有パラメータに基づいて（例えば、第１のエンティティによって）決定され得る。

【0040】

各第１の治療クラス（Ｋ＿ｐ）は、１つ又は２つ以上の対応する第１の治療クラスメンバ（Ｃ＿ｐｄ）を含み得る。更に、第１のエンティティは、１つ又は２つ以上の第１の治療クラスメンバ（Ｃ＿ｐｄ）の各々について、１つ又は２つ以上の対応する第１の治療クラスメンバコスト情報（Ｍ＿ｐｄ）を決定し得る。次いで、第１のエンティティ（例えば、ＰＭＤＰ１３０）は、少なくとも１つの対応する第２のエンティティ（例えば、ＨＣＰ１２０）によって復号可能な暗号化された第１のＤＩＲサブブロックを送信し得る。

【0041】

１つ又は２つ以上の対応する第１の治療クラスメンバコストメトリック（Ｍ＿ｐｄ）は、対応する治療ユニットについての各対応する第１の治療クラスメンバ（Ｃ＿ｐｄ）に対応する患者固有の自己負担コスト、又は典型的な若しくは処方された治療期間についての、各対応する第１の治療クラスメンバに対応する患者固有の推定される総自己負担コスト、又は患者に関連付けられた医療保険適用範囲プランの残りの持続時間の間の各対応する第１の治療クラスメンバ（Ｃ＿ｐｄ）に対応する患者固有の推定される総自己負担コスト、又はそれらの組み合わせのうちの１つ又は２つ以上を含む。

【0042】

第１のエンティティ（例えば、ＰＭＤＰ１３０）は、送信された第１のＤＩＲサブブロックに応答して、第１のエンティティによって復号可能な暗号化された第２のＥＨＲサブブロックを受信し得、第２のＥＨＲサブブロックは、１つ又は２つ以上の第２の治療（例えば、１つ又は２つ以上の選択された薬物／デバイス、Ｓ＿ｐ、１≦ｐ≦Ｐ）を含み、１つ又は２つ以上の第２の治療Ｓ＿ｐの各々は、対応する第１の治療クラス（Ｋ＿ｐ）に関連付けられた対応する第１の治療クラスメンバ（Ｃ＿ｐｄ）から選択される。例えば、第２の治療Ｓのセットは、各第１の治療クラス（第１の治療Ｆ＿ｐに対応するＫ＿ｐ）に対して、１つの選択された対応する第１の治療クラスメンバ（Ｃ＿ｐｄ）を含み得る。例えば、第２のＥＨＲサブブロックは、１つ又は２つ以上の選択されたデバイス／薬物を含み得、各選択されたデバイス／薬物Ｓ＿ｐは、異なる対応するクラスＫ＿ｐに関連付けられる。一例として、第１のＥＨＲサブブロックは、第１の治療（Ｆ＿１、Ｆ＿２、Ｆ＿３）を含み得、第２のＥＨＲブロックは、第２の治療Ｇ＿１、Ｆ＿２、Ｈ＿４｝を含み得、ここで、Ｇ＿１及びＦ＿１は両方とも治療クラスＫ＿１にあり、Ｆ＿２は治療クラスＫ＿２にあり、Ｆ＿３及びＨ＿４は治療クラスＫ＿３にある。上で概説したように、各治療クラスは、１つ又は２つ以上のメンバを含み得る。いくつかの実施形態では、１つ又は２つ以上の第２の治療（Ｓ＿ｐ）の選択は、患者固有のコストメトリックに基づき得る。

【0043】

いくつかの実施形態では、第１のエンティティ（例えば、ＰＭＤＰ１３０）は、次いで、多次元ブロックチェーンを拡張し得、多次元ブロックチェーンは、１つ又は２つ以上の第２の治療に関連付けられた情報を含むＤＤ１ブロックと、第２のＥＨＲサブブロックに関連付けられた情報を含むＥＨＲブロックと、トランザクションＩＤを含み得るトランザクションブロックとをリンクすることによって形成された多次元ブロックで拡張される。

【0044】

いくつかの実施形態では、第２のＥＨＲサブブロックを受信すると、第１のエンティティ（例えば、ＰＭＤＰ１３０）は、トランザクションブロックをトランザクション確認とともに送信し得、トランザクションブロックは、１つ又は２つ以上の対応する指定された第２の治療場所における１つ又は２つ以上の第２の治療のための少なくとも１つの処方を含む。いくつかの実施形態では、トランザクションブロックは、指定された患者コストでの指定された場所における第２の治療のための処方を含み得る。いくつかの実施形態では、第１のエンティティは更に、（例えば、第１のＥＨＲサブブロック及び第２のＥＨＲサブブロックに関連付けられた）少なくとも１つの処方とともにトランザクションの確認を患者に送信し得る。

【0045】

サブブロックという用語は、データレコード又はブロックの一部分を示す。これは（暗号化されている場合）ある特定のエンティティ又は複数のエンティティによって復号可能であり得る（が、他のエンティティによって復号可能ではない）。特定のエンティティ（又は複数のエンティティ）によって復号されたサブブロック内の情報は、トランザクションが最終承認されたときに、その特定のエンティティ（又は複数のエンティティ）によって維持されているデータレコード（又はブロックチェーン内のデータブロック）に組み込まれ得る。例えば、トランザクションＩＤＵを有するトランザクションは、エンティティＡ、Ｂ、Ｃ、及びＤを含み得、これらのエンティティは、それぞれ多次元ブロックチェーン内のデータレコードＷ、Ｘ、Ｙ、及びＺの所有者であり得る。上の例では、トランザクションＵに関連するデータレコードＷ（Ａによって所有される）は、所有エンティティＡによって暗号化され、読み取り可能であり得る（が、他のエンティティによって暗号化、読み取り可能ではない）。しかしながら、データレコードＷは、（トランザクションＩＤＵに加えて）他のデータレコード内の情報の一部分（例えば、エンティティＡによって読み取り可能でない場合があるデータレコードＸ、Ｙ、及び／又はＺ）を含み得る。例えば、Ｗ内に存在する１つ又は２つ以上の他のデータレコード（例えば、データレコードＸ、Ｙ、及び／又はＺ）からのデータは、復号可能なサブブロックとしてトランザクション最終承認の前に（例えば、エンティティＡによって）受信され得る。同様に、他のエンティティＢ～Ｄもまた、（トランザクションＩＤＵに加えて）所有されていないデータレコードに存在するトランザクション関連情報を含み得る。例えば、エンティティＢの場合、データレコードＷ、Ｙ及び／又はＺのうちの１つ又は２つ以上に存在する情報は、トランザクション最終承認の前にエンティティＢによって復号可能なサブブロックの形態で受信され得る。したがって、各エンティティＡ、Ｂ、Ｃ、及びＤは、それらのそれぞれのブロックチェーン内のブロックとして（トランザクションＵの）データレコードＷ、Ｘ、Ｙ、及びＺをそれぞれ含む、異なる独立したブロックチェーンを維持し得る。トランザクションＵに関連付けられたデータレコード（又はブロック）Ｗ、Ｘ、Ｙ、及びＺは、多次元ブロックチェーン内の多次元ブロックを集合的に形成し得る。したがって、トランザクションの整合性のある一貫した閲覧は、法的、プライバシー、及び／又は他の規制／ビジネス上の考慮事項の準拠を維持し、かつデータ完全性を促進しながら、トランザクションに関連付けられ得る全ての市場エンティティにとって利用可能である。

【0046】

本明細書で使用されるときの「ブロックチェーン」という用語は、ブロックが暗号技術を使用してリンクされるレコード又は「情報ブロック」又は「ブロック」の生長可能なリストを指す。各ブロックは、先行のブロックの暗号ハッシュ、タイムスタンプ、及びトランザクションデータを含む。ブロックチェーンに追加されている現在のブロックはまた、ブロックチェーンのヘッドとも呼ばれる。暗号ハッシュ関数が、任意のサイズのデータを、「ハッシュ」と呼ばれる、固定サイズのビット列にマッピングする。ハッシュ関数は、決定論的であり得（同じ入力は、同じ出力を生成することになる）、反転する（すなわち、ハッシュ値から入力された元のデータを判定する）ことが不可能である一方向関数であり得る。ブロックのトランザクションデータは、マークル木ルートハッシュとして表され得る。「マークル木」又は「ハッシュ木」という用語は、木を指すために使用され、全ての葉ノードが、トランザクションデータのハッシュを用いてラベル付けされ、各非葉ノードが、その子ノードに関連付けられたラベルの暗号ハッシュを用いてラベル付けされる。ブロックチェーンに追加されるブロックのブロックヘッダは、先行のブロックヘッダに対するハッシュ基準、及びトランザクションデータを包含するマークル木のルートに対するハッシュ基準を含み得る。ブロックチェーンは、ブロックチェーン内のデータへの変更がハッシュ基準のうちの１つ又は２つ以上に不一致をもたらすため、データ完全性を促進する。レコード又はデータレコードという用語はまた、ブロックチェーンに追加される予定である非最終データを示すためにも使用される。データレコードが検証されて最終承認されると、そのデータレコードは、ブロックチェーンに追加され得、ブロックチェーン内のブロックを形成し得る。

【0047】

「多次元ブロックチェーン」という用語は、一連の多次元レコード（また、多次元ブロックとも呼ばれる）を指すために使用され、その場合、各多次元レコードは、２つ又はそれ以上のデータレコードを含む。場合によっては、多次元ブロックチェーンの次元を形成する際に閲覧され得るデータレコードの各々はまた、あるエンティティに関連付けられた異なるブロックチェーン内にブロックを形成し得る。したがって、いくつかの実施形態では、多次元ブロックが、各次元内にデータレコードを含み得、その場合、次元に対応するデータレコードは、対応するエンティティに関連付けられた異なる従来のブロックチェーン内にブロックを形成し得る。例えば、多次元ブロックは、ＥＨＲデータレコードを一次元として、ＤＩＲデータレコードを別の次元として、またトランザクションデータレコードを第３の次元として含み得る。更に、場合によっては、多次元ブロック（多次元ブロックチェーン内の）に関連付けられたＥＨＲデータレコードは、異なるＥＨＲブロックチェーン（すなわち、多次元ブロックチェーンとは異なる）内にブロックを別個に形成し得る。同様に、場合によっては、多次元ブロックに関連付けられたＤＩＲデータレコード及びトランザクションデータレコードの各々は、それぞれ、異なるＤＩＲブロックチェーン（例えば、ＰＭＤＰ１３０に関連付けられた）、及びトランザクションレコードブロックチェーン（例えば、支払人１４０に関連付けられた）内にブロックを形成し得る。したがって、場合によっては、多次元ブロックチェーンの文脈におけるデータレコードは、異なる従来のブロックチェーン内のブロックに対応し得る。場合によっては、多次元ブロック内の各データレコード（例えば、次元に関連付けられた）は、異なる従来のブロックチェーン内の対応するブロックに対応し、それらの一部を形成し、かつ／又はそれらに由来し得る。多次元ブロックは、先行の多次元ブロック、タイムスタンプ、及びデータの暗号ハッシュを含み得る。多次元ブロックのデータは、多次元ブロックを作り上げる個々のデータレコードのハッシュを含み得る。いくつかの実施形態では、エンティティ間の合意メカニズムを使用して、提案された多次元ブロック内のデータの正当性を、その多次元ブロックがコミットされロックされる前に確認し得る。

【0048】

したがって、多次元ブロックは、２つ又はそれ以上の暗号化されたデータレコードを含み得、その場合、各暗号化されたデータレコードは、異なるエンティティ（例えば、ヘルスケア市場内の）に関連付けられ得る。上で概説したように、多次元ブロック内のデータレコードは、異なるブロックチェーン内にブロックを別個に形成し得、その場合、ブロックチェーンの各々は、異なるエンティティに関連付けられ得る。各暗号化されたデータレコードは、対応する関連したエンティティ（例えば、データレコード所有者）によって解読され得る。更に、暗号化されたデータレコードは、暗号化されたデータレコード所有者に加えて、少なくとも１つの他の特定のエンティティによって復号されている場合がある部分（「サブブロック」と呼ばれる）を含み得る。例えば、このサブブロックは、対応する多次元ブロックが形成された時点で、（データレコード所有者に加えて）少なくとも１つの他の異なるエンティティによって復号されている場合がある。いくつかの実施形態では、多次元ブロック形成の前又は形成の時点に、サブブロックは、別個に暗号化され、サブブロックを復号するための情報とともに、別のエンティティに対して利用可能にされている場合がある。したがって、多次元ブロックは、認可された市場エンティティへの、データの整合性のある一貫した閲覧を提供し、プライバシー及び／若しくはデータ共有規制、ビジネスガイドライン、並びに／又は契約義務に準拠し、データ完全性を促進しながら、ヘルスケア市場に関連付けられた複数のエンティティに対するトランザクションデータの利用可能性を容易にし得る。エンティティはまた、ローカルに維持されたブロックチェーン内の対応するブロックとのデータ相関性（例えば、多次元ブロックチェーン内の多次元ブロックの次元に関連付けられたレコードの）を保証することもできる。いくつかの実施形態では、情報が、サブブロックを使用して２つのエンティティ間で交換されるときに、解読可能なサブブロックを介して交換される情報は、２つのエンティティ間の情報インターフェースに基づき得る。いくつかの実施形態では、情報を交換するときに（例えば、多次元ブロック形成の時点で）、各エンティティは、他のエンティティによって解読可能であるサブブロックを生成しながら、エンティティによって維持されるローカルなブロックチェーンに関連付けられたブロックを暗号化し得る。情報インターフェースは、ブロックチェーンに関連付けられたスマートコントラクトに基づき得る。

【0049】

「スマートコントラクト」という用語は、場合によってはブロックチェーン又はブロックチェーンプラットフォームに関連付けられ得る、プログラムコード又はロジックを指すために使用される。この「スマートコントラクト」は、データ共有、トランザクション、アクセス、コントラクト履行等に関連して、２つ又はそれ以上のエンティティ間のルール又は合意を符号化し得る。スマートコントラクトは、多次元ブロックチェーンプラットフォームに関連する２つ又はそれ以上のエンティティ及び／又は合意との間のコントラクトに基づき得る。例えば、多次元ブロックチェーンに関連付けられた「スマートコントラクト」プログラムコードが、トランザクションリクエストを処理し、プログラムロジックに基づいてトランザクションの妥当性を判定し得る。

【0050】

図２は、レコード内のいくつかの例示的なデータフィールドを例示するＥＨＲ２００を示す。いくつかの実施形態では、ＥＨＲ２００は、患者に関する情報を含み得、ＨＣＰ１２０によって所有され維持され得る（例えば、ＨＩデータベース１２５内で）。いくつかの実施形態では、ＥＨＲ２００内のデータフィールドは、患者から受信された情報に部分的に基づいて、ＨＣＰ１２０によって追加及び／又は維持され得る。ＥＨＲ２００はまた、他のエンティティから（例えばサブブロックとして）受信されたデータを含み得る。ＥＨＲ２００に示されたフィールドは、単なる例示であり、ＥＨＲ２００は、法律、標準規格、ＨＣＰ慣習、及び／又は業界慣習等に基づいて、様々な他の追加のフィールドを含み得る。ＥＨＲは、例示的なＥＨＲ２００に関連して示されたフィールドとは（多かれ少なかれ）異なるフィールドを含み得る。

【0051】

ＥＨＲ２００は、ＨＣＰ１２０に関連する情報（例えば、ＨＣＰ識別、登録及び／又はライセンス情報、アドレス、関連付けられた医療専門家、医療専門家識別／登録情報等）を記憶し得るＨＣＰプロファイルフィールド２９５に関連付けられ得る。いくつかの実施形態では、ＨＣＰプロファイル２９５内の情報の一部又は全ては、トランザクションに関連して他のエンティティと共有され得る。例えば、ＨＣＰプロファイル２９５の一部分は、ＰＭＤＰ１２０、支払人１４０、ＰＢＭ１５０、及び／又は薬局１６０などの１つ又は２つ以上のエンティティに（例えば、指定された受信側エンティティによって復号可能であり得る暗号化されたサブブロックの一部として）送信され得る。

【0052】

例えば、図２に示すように、ＥＨＲ２００は、患者についての基本プロファイル情報２３０を含み得、その情報は、比較的希に変化し得る。基本プロファイル情報２３０は、患者名、患者ＩＤ、家族歴２０５、出生日（Date of Birth、ＤＯＢ）２２０、血液型２２５等が含まれ得る。家族歴２０５には、母方既往歴２１０及び父方既往歴２１５が含まれ得る。基本プロファイル情報２３０はまた、患者に関連付けられた他の以前又は現在の病状についての情報を含み得る、医療履歴２３２を含み得る。

【0053】

ＥＨＲ２００は、診断２３５（例えば、現在の疾患）、診断用に標準化されたコード（国際疾病分類（International Classification of Diseases、ＩＣＤ）コードなど）であり得る診断コード２４０、治療を記載するための標準化されたコード（例えば、最新専門用語集（Current Procedural Terminology、ＣＰＴ）コードなど）であり得る治療コード２４５、各処方を一意に識別する役割を果たし得る、各処方の処方コード２５０など、他のデータフィールドを更に含み得る。処方コード２５０は、本明細書では処方２５０とも称される。

【0054】

いくつかの実施形態では、（処方用の）処方コード２５０は、処方された薬物フィールド２５５－ｐ、１≦ｐ≦Ｐ（例えば、医療デバイス用の薬物ＩＤ及び／又は分類製品コード（Classification Product Code、ＣＰＣ））、投与量２６０－ｐ（強度及び頻度）、及び持続時間２６５－ｐ（薬物が服用される時間の長さ）などの１つ又は２つ以上のサブフィールドを（例えば、処方箋で処方されている各薬物／デバイスについて）更に含み得る。場合によっては、ＥＨＲ２００はまた、処方が新たな処方であるか又は補充であるかどうかの指示などの他のフィールド及び／又はサブフィールドを含むこともできる。ＥＨＲ２００はまた、医療デバイスレポート（Medical Device Report、ＭＤＲ）有害事象コード、又は有害薬物効果を文書化するための他の（例えば、ＩＣＤ－１０）コードを含み得る。ＥＨＲ２００はまた、患者基準２９７を含み得、これは、患者によって提供され得る薬物／デバイス選択及び／又はコストメトリック決定のための１つ又は２つ以上の基準を指定し得る。例えば、患者基準２９７は、好ましい投与方法（例えば、局所、摂取、吸入等）、好ましい薬局、処方された薬物／デバイスが入手される領域又は場所、所望のコストメトリックのタイプ等を指定し得る。

【0055】

いくつかの実施形態では、患者についてのＥＨＲ２００は、例えば、ＨＣＰ１２０によって、ブロックチェーンとして記憶され得、ＨＣＰ１２０、及び患者、及び／又は別のエンティティの間の各トランザクションは、ＥＨＲブロックチェーン内のＥＨＲ情報ブロックの部分を形成し得る。トランザクションに関連付けられたＥＨＲブロックがブロックチェーンに記憶される場合、記憶される情報は、場合によっては、トランザクションを一意に識別する役割を果たし得るトランザクションＩＤ６９５に関連付けられ得る。いくつかの実施形態では、トランザクションＩＤ６９５は、トランザクションに関連付けられたエンティティに共通であり得る（例えば、トランザクションに関連付けられた全てのエンティティが同じトランザクションＩＤを使用し得る）。いくつかの実施形態では、トランザクションイニシエータ及び／又は許可型ブロックチェーンプラットフォームのコンポーネントは、トランザクションＩＤ６９５などのトランザクション情報を、トランザクションに関連付けられた１つ又は２つ以上のエンティティに提供し得る。したがって、エンティティによって送信又は受信されたサブブロックは、トランザクションに関連付けられているものとして識別され、適切に処理されることができる。いくつかの実施形態では、トランザクションＩＤ６９５のフォーマット及び内容は、トランザクションプラットフォームに関連付けられたエンティティによって事前に決定及び／若しくは合意され得、かつ／又はトランザクションプラットフォームによって提供され得る。他のトランザクション情報関連フィールド（図２には示さず）は、送信及び／又は受信されたサブブロック内の情報を決定及び処理し、適切な応答を決定するためにエンティティによって使用され得るトランザクションタイプを含み得る。例えば、トランザクションタイプは、サブブロック２８０が処方に関連付けられたコストメトリックを取得するために提供されていることを示し得る。

【0056】

以下の説明では、ＥＨＲがブロックチェーンとして（例えばＨＣＰ１２０によって）維持される場合、ＥＨＲ情報レコード２００はまた、ＥＨＲブロック２００とも称され得る。したがって、ＥＨＲブロック２００は、ＥＨＲブロックチェーン内にブロックを形成し得る。ＥＨＲブロック２００がＥＨＲブロックチェーンに追加され得る場合、ＥＨＲブロックチェーンに追加されるＥＨＲブロック２００内のいくつかのデータは、他のエンティティに依存し得る。例えば、治療（例えば、診断コード２４０によって記述される診断について治療コード２４５で指定される）は、支払人１４０及び／又はＰＢＭ１５０（図２には示さず）による承認を受け得、承認時にＥＨＲの一部として含まれ得る。別の例として、ＥＨＲブロック２００がＥＨＲブロックチェーンに追加される前に、ＥＨＲブロック２００の部分を形成し得る薬物警告ラベル（図２には示さず）が、ＰＭＤＰ１３０からの入力を使用して、この警告ラベル内の情報を完成、検証、及び／又は更新し得る。

【0057】

いくつかの実施形態では、患者基準２９７と、診断２３５と、診断コード２４０と、治療コード２４５と、データフィールドである処方された薬物／デバイス２５５－ｐ、投与量２６０－ｐ、及び持続時間２６５－ｐ、１≦ｐ≦Ｐを伴う処方コード２５０と、を使用して、サブブロック２８０を形成し得る。いくつかの実施形態では、サブブロック２８０は、基本プロファイル情報２３０、患者保険適用範囲関連情報２７２、及び／又は患者によって加入された保険プラン（例えば、健康保険プラン、薬局給付プラン、処方保険適用範囲等）を識別する役割を果たし得るプランＩＤ２７０のうちの１つ又は２つ以上を更に含み得る。いくつかの実施形態では、（文脈、適用される法律、及び／又は患者認可に応じて）サブブロック２８０はまた、本明細書に記載されるサブブロック２８２及び／又は２８４内の情報の一部又は全てを含み得る。サブブロック２８０内の情報の一部又は全ては、１つ又は２つ以上の他のエンティティと共有され得、トランザクションに関連付けられた他のレコード／ブロックの一部を形成し得る。

【0058】

処方２５０は、１つ又は２つ以上の処方された薬物／デバイス２５５－ｐ、１≦ｐ≦Ｐを含み得、ここで、Ｐは、処方２５０に関連付けられた薬物の数を表す。したがって、いくつかの実施形態では、サブブロック２８０は、処方２５０内の各処方された薬物／デバイス２５５－ｐについてのレコードを備え得る。サブブロック２８０は、別の特定のエンティティと共有され得るいくつかの情報を例示する単なる例である。例えば、サブブロック２８０は、（例えば、薬物、デバイス、及び／又は治療の同等のクラス並びに対応するコストメトリックを取得するために）暗号化され、ＰＭＤＰ１３０に送信され得、ＰＭＤＰ１３０によって復号可能であり得る。

【0059】

概して、データレコード又はブロック内の任意の適切なフィールド又はフィールドの組み合わせ内の情報は、サブブロックに集約され得、サブブロックは、何らかの他の特定のエンティティ又は複数のエンティティ（例えば、１つ又は２つ以上の第２のエンティティ）によって復号可能であるように、（例えば、第１のエンティティによって）暗号化され得る。暗号化されたサブブロックは、（例えば、第１のエンティティによって、）他の指定されたエンティティ又は複数のエンティティ（例えば、１つ又は２つ以上の第２のエンティティ）に送信され得、他の指定されたエンティティ又は複数のエンティティ（例えば、１つ又は２つ以上の第２のエンティティ）は、受信された情報を復号し、（例えば、トランザクションタイプに基づいて）適切に動作し得る。第１のエンティティによってローカルに維持されるブロックチェーン（例えば、ＥＨＲブロックチェーン）内のデータレコード若しくはブロックからサブブロックを形成するために使用され、別の（第２の）エンティティと共有される情報は、規制（例えば、ヘルスケア及び／又はプライバシー）、情報共有を管理する法律（例えば、特定のエンティティ間で共有され得る又は共有され得ない情報を決定し得る）、ビジネスガイドライン（例えば、企業秘密若しくは機密情報の共有／保護を管理し得る）及び／又は契約義務（例えば、情報を共有するエンティティ間又はそれらエンティティに関連する）及び／又は合意（例えば、電子トランザクションプラットフォームへのサブスクリプションの一部として）に依存し得る。

【0060】

別の例として、サブブロック２８２内の情報は、保険適用範囲関連情報２７２、プランＩＤ２７０、自己負担金情報２７５等を含み得る。サブブロック２８２内のいくつかの情報は、患者から直接取得され得るが、他の保険適用範囲関連情報は、トランザクションＩＤ６９５によって指定されたトランザクションに関連して（例えば、コスト対効果の高い治療を決定するために）、支払人１４０及び／若しくはＰＢＭ１５０から取得され、かつ／又は支払人１４０及び／若しくはＰＢＭ１５０によって確認され、ＨＣＰ１２０によって（例えば、適切なエンティティから受信されＨＣＰ１２０によって復号された、図２には示されていない１つ又は２つ以上の暗号化されたサブブロックに基づいて）復号され得る。例えば、トランザクションタイプは、サブブロック２８２が、保険適用範囲関連情報２７２を取得、確認、又は完了するために提供されていることを示し得る。

【0061】

更に、いくつかの状況では、ＥＨＲ情報２００の一部分、例えば、基本プロファイル情報２３０、ＤＯＢ２２０、血液型２２５、及び医療履歴２３２のある部分は、サブブロック２８４としてＨＣＰ１２０によって暗号化され、ＰＭＤＰ１３０に送信され得、ＰＭＤＰ１３０は、次いで、トランザクションＩＤ６９５によって指定されるトランザクションに関連してサブブロック２８４を復号化し得る（例えば、支払い支援のレベルを決定するために）。更なる例として、サブブロック２８４に含まれる基本プロファイル情報２３０の部分は、患者に関連する非ＰＩＩ（例えば、名前、識別番号等を除く）であり得る。したがって、医療情報は、患者のプライバシーを損なうことなく、別の特定のエンティティと安全に共有され得る（例えば、有害反応、医療デバイスの機能不全等を判定するために）。別の場合では、ＰＩＩ情報の開示が（例えば、患者によって）許可及び認可される場合、サブブロックは、（例えば、ＰＭＤＰ１３０が支払い支援のための患者の適格性を判定するためのＰＩＩ情報、又は（薬局１６０が患者の識別を確立するための）処方に関連するＰＩＩ情報を含み得る。例えば、サブブロック２８２及び／又は２８４に存在する情報の一部又は全てを、（コンテキスト、トランザクションタイプ、適用される法律、及び／又は患者認可に応じて）サブブロック２８０に組み込むこともできる。

【0062】

更なる例として、サブブロック２８０内のデータは、ＨＣＰ１２０などのエンティティによって、支払人１４０などの別のヘルスケア市場エンティティと共有して、トランザクションを完了させることができる。しかしながら、基本プロファイル情報２３０に関連付けられた患者プロファイル情報（例えば、家族歴２０５、母方既往歴２１０、及び／又は父方既往歴２１５）は、（例えば、患者の指示／プライバシー、法律、及び／又はビジネスガイドラインに基づいて）プライベートと見なされ得、第１のエンティティ（例えば、ＨＣＰ１２０）は、家族歴２０５を共有しない場合があるか、又は共有される基本プロファイル情報２３０の部分を制限し得る。

【0063】

したがって、いくつかの実施形態では、エンティティによって送信されるか又は別のエンティティから受信されるサブブロックを形成するために使用されるデータは、エンティティと、データが共有されているコンテキスト（例えば、トランザクションのタイプ又は性質）との両方に依存し得る。いくつかの実施形態では、任意の２つのエンティティ間の情報インターフェースは、トランザクションタイプ及び／又はコンテキストに依存し得る。いくつかの実施形態では、１つ又は２つ以上のプロトコル（例えば、エンティティによって合意／事前配置され、並びに／又は許可型ブロックチェーンプラットフォームによって、かつ／若しくは何らかの規格に基づいて設定される）は、トランザクションタイプと、各トランザクションタイプについてエンティティによって送信／受信されるサブブロック内に存在する情報とを指定し得る。いくつかの実施形態では、トランザクションタイプに関連してエンティティ間で共有されるサブブロックに含まれるデータフィールドは、必須、条件付き、任意選択、リクエスト時、等として（例えば、プロトコルによって、かつ／又は標準に基づき合意されて）示され得る。

【0064】

サブブロック（例えば、サブブロック２８０）中のデータは、別個に暗号化され得、認可されたエンティティによってのみ復号可能であり得る。いくつかの実施形態では、サブブロック（例えば、サブブロック２８０）を形成するデータの暗号化は、任意の適切な暗号方式に基づき得、その暗号方式には、次世代標準暗号方式（Advanced Encryption Standard、ＡＥＳ）ベース技術又はそのバリエーションなどの対称鍵暗号化技術（その場合、ＨＣＰ１２０及び支払人１４０などのエンティティは、秘密鍵を共有する）が含まれる。サブブロック２８０は、他のエンティティ（例えば、支払人１４０）と共有される前に、（例えば、ＨＣＰ１２０によって）暗号化され得る。他のエンティティ（例えば、支払人１４０）は、例えば、共有鍵を使用して、サブブロック２８０を解読することが可能であり得る。

【0065】

更に、ＥＨＲ２００内のデータは、ブロックチェーンに追加される（例えば、ＨＣＰ１２０によって維持される、かつ／又は電子トランザクションプラットフォームによって維持される）前に、ＥＨＲブロック２００を形成するために、任意の安全な暗号化技術を使用してＨＣＰ１２０によって別個に暗号化され得る。例えば、ＥＨＲブロック２００内のデータは、プライベート鍵（例えば、ＨＣＰ１２０に対してプライベート）を使用して別個に暗号化され得、その結果、データは、ＨＣＰ１２０によって復号可能であり、ＨＣＰ１２０に対して利用可能であるが、任意の他のエンティティに対しては利用不可能及び／又は閲覧不可能である。

【0066】

図３Ａ及び図３Ｂは、ＤＩＲデータベース１３５に記憶され得る、薬物のための例示的な薬物／デバイス情報レコード（ＤＩＲ）３００の一部分を示す。いくつかの実施形態では、ＤＩＲ３００は、薬物、デバイス、及び／又は処置などの、治療（例えば、薬物及び／又は医療デバイス）に関する情報を含み得る。ＤＩＲ３００に示したフィールドは、単に例示的なものであり、ＤＩＲ３００は、法律、標準規格、業界慣習等に基づいて、様々な他のフィールドベースを含み得る。加えて、ＤＩＲは、例示的なＤＩＲ３００に関連して示されたフィールドとは（多かれ少なかれ）異なるフィールドを含み得る。

【0067】

ＤＩＲ３００は、ＰＭＤＰ１２０に関連する情報（例えば、ＰＭＤＰ識別、連絡先情報、アドレス等）を記憶し得るＰＭＤＰプロファイルフィールド３９５に関連付けられ得る。いくつかの実施形態では、ＰＭＤＰプロファイル３９５内の情報の一部又は全ては、任意選択で、トランザクションに関連して他のエンティティと共有され得る。例えば、ＰＭＤＰプロファイル３９５の一部分は、支払人１４０、ＰＢＭ１５０、及び／又は薬局１６０などの１つ又は２つ以上のエンティティに（例えば、指定された受信側エンティティによって復号可能であり得る、暗号化されたサブブロックの一部として）送信され得る。

【0068】

図３Ａを参照すると、ＰＭＤＰ１３０は、（例えば、サブブロック２８０の一部として受信された）処方された薬物／デバイスフィールド２５５－ｐ内の情報を使用して、（例えば、処方コード２５０に関連付けられた各薬物／デバイス２５５－ｐについて）対応する薬物／デバイスクラス３３７－ｐを決定し得る。薬物／デバイスクラス３３７フィールドは、薬物／デバイス２５５に関連付けられた１つ又は２つ以上の薬物／デバイスクラスを指定し得る。いくつかの実施形態では、サブブロック２８０はまた、サブブロック２８２及び／又は２８４中の情報の一部又は全てを含むこともできる。

【0069】

薬物／デバイスクラスは、同じ病状を処置するために使用され得る薬物／デバイスのセットであり得る。薬物クラス内の薬物は、類似の化学構造、及び／又は類似若しくは関連する作用機序（例えば、同じ標的に作用若しくは結合し得る）、及び／又は関連する作用様式（類似の生物学的若しくは機能的効果を誘導する）を有し得、かつ／あるいは同じ疾患を処置するために使用され得る。例えば、薬物デバイスクラスには、有名ブランドの薬物／デバイス及び後発薬物／デバイス、並びに／又はブランドの生物学的製剤及びバイオシミラー、並びに／又は同じ治療の異なる投与量等もまた含まれ得る。図３Ａ～図３Ｃでは、個々の薬物／デバイスクラス３３７－ｐ内の薬物は、薬物／デバイス３０２－ｐｄによって示され、ここで、１≦ｄ≦Ｄ＿ｐであり、ここで、Ｄ＿ｐは、薬物／デバイスクラス３３７－ｐ内の薬物の数である。

【0070】

いくつかの実施形態では、薬物／デバイスクラス３３７－ｐフィールドは、薬物デバイスが治療する器官若しくは生物系、及び／又は繰り返される指示サブフィールド３６２－ｐｄ１、３６２－ｐｄ２．．．を含む治療領域フィールド３６０－ｐｄによって指定され得る治療領域と、対応する指示について繰り返される投与量サブフィールド３６４－ｐｄ１、３６４－ｐｄ２．．．と、ＭＯＡフィールド３４０－ｐｄによって指定され得る、作用機序及び／又は作用様式と、化学データフィールド３５０－ｐｄによって指定され得、薬物の化学成分を記述するサブフィールド分子式フィールド３５３－ｐｄ及び化学構造サブフィールド３５５－ｐｄを更に含み得る、薬物の一般的な化学特性と、のうちの１つ又は２つ以上を示し得る。

【0071】

図３Ａを参照すると、ＤＩＲ３００は、薬物／デバイスＩＤ３０２－ｐｄのための薬物名３０４－ｐｄ、有効性３２７－ｐｄ（病状に対する治療効果の尺度であり得る）、投与経路３３５－ｐｄ（例えば、局所、経口、静脈内等）、副作用サブフィールド３４５（例えば、副次効果）を含み得る安全性３３０－ｐｄ（例えば、薬物相互作用、毒性、禁忌等）、及びを含む、様々な他のデータフィールドを備え得る。有害事象サブフィールド３３３－ｐｄ（例えば、薬物について報告された有害事象）。ＤＩＲ３００はまた、薬物／デバイスに関連する様々な他のフィールドを含み得る。

【0072】

いくつかの実施形態では、薬物／デバイスＩＤ３０２－ｐｄ、薬物／デバイス名３０４－ｐｄ、安全性３３０－ｐｄ（及びサブフィールド）、及び有効性３２７－ｐｄ、薬物／デバイスクラス３３７－ｐ、治療領域３６０－ｐ、指示３６２－ｐｄｈ（例えば、指示３６２－ｐｄ１、指示３６２－ｐｄ２等）、及び対応する投与量３６４－ｐｄｈ（例えば、投与量３６４－ｐｄ１、投与量３６４－ｐｄ２等）は、サブブロック３８０の一部を形成し得る。サブブロック３８０（及び任意の他のサブブロック）内の情報は、エンティティ間で事前に配置され得、プロトコルによって決定され得、かつ／又はプラットフォームによって指定され得る（例えば、法律、規制、認可、及び／又は契約義務に基づいて）。したがって、サブブロック３８０（及び任意の他のサブブロック）内の情報は、例示的なサブブロック（例えば、例示的なサブブロック３８０）に対して示されたものよりも多く又は少なくあり得、トランザクションタイプ、トランザクションコンテキスト、及びインタラクトするエンティティに依存し得る。サブブロック３８０は、任意選択で、投与経路３３５－ｐｄ、ＭＯＡ３４０－ｐｄ、化学データ３５０－ｐｄ、及び他の関連するフィールド／サブフィールドを更に含み得る。図３Ａでは、例示的なサブブロック３８０に関連付けられたフィールドが、破線の外周内に囲まれて示されている。

【0073】

ＤＩＲサブブロック３８０は、トランザクション（例えば、トランザクションＩＤ６９５によって識別される）に関連して、ＰＭＤＰ１３０によって別のエンティティ（例えば、ＨＣＰ１２０）に提供され得る。いくつかの実施形態では、ＤＩＲサブブロック３８０は、薬物／デバイスクラス３３７－ｐの一部を形成するか、又は１つ又は２つ以上の特性を共有する（例えば、同じ病状を治療する、かつ／又は同様の作用機序若しくは作用様式を有する、かつ／又は同様の化学構造を有する）、複数の薬物／デバイスに関する情報を含み得る。いくつかの実施形態では、サブブロック３８０内の情報は、トランザクション（例えば、トランザクションＩＤ６９５及びトランザクションタイプによって識別される）に関連付けられ得、トランザクション中、及び／又はトランザクション最終承認の前に、暗号化され、ＰＭＤＰ１２０によって別のエンティティ（例えば、ＨＣＰ１２０）に送信され得る。

【0074】

いくつかの実施形態では、ＤＩＲレコード３００は、トランザクション（例えば、トランザクションＩＤ６９５によって指定される）に関連付けられ得、トランザクションが最終承認されると、ＰＭＤＰ１３０などのエンティティによって、ＤＩＲブロックチェーンのＤＩＲブロックとして記憶され得る。以下の説明では、ＤＩＲレコード３００がブロックチェーンの一部を形成する場合、ＤＩＲ情報レコード３００は、ＤＩＲブロック３００とも呼ぶことができる。したがって、ＤＩＲブロック３００は、ＤＩＲブロックチェーン内にブロックを形成し得る。

【0075】

２つ又はそれ以上のエンティティ（例えば、患者、ＨＣＰ１２０、ＰＭＤＰ１３０、支払人１４０、ＰＢＭ１５０、及び／又は薬局１６０）間のトランザクション（例えば、トランザクションＩＤ６９５によって指定される）は、別のエンティティによって維持される（又は所有される）情報（例えば、薬物／デバイスに関連する）を伴い得る。例えば、ＨＣＰ１２０は、ＰＭＤＰ１３０に情報をリクエストし得る。トランザクション確認の前に、他のエンティティ（すなわち、ＰＭＤＰ１３０以外）によって維持されるレコードに統合されている（例えば、ＤＩＲ情報ブロック３００内のＰＭＤＰ１２０によって維持される）データのいくつかは、ＰＭＤＰ１３０からの入力、それによる検証、及び／又はそれによる確認に依存し得る。逆に、ＰＭＤＰ１３０は、サブブロックの形態で別のエンティティ（例えば、ＨＣＰ１２０及び／又は支払人１４０及び／又はＰＢＭ１５０）からの入力を受信し得る。受信された情報の一部又は全ては、ＤＩＲレコード３００に組み込まれ得、かつ／又はＤＩＲレコード３００内の情報を決定するために使用され得る。

【0076】

例えば、ＨＣＰ１２０は、サブブロック２８０をＰＭＤＰ１３０に送信し得る。ＰＭＤＰ１３０は、サブブロック２８０内の情報（例えば、処方された薬物２５５－ｐ）を使用して、対応する薬物／デバイスクラス３３７－ｐを決定し、サブブロック３８０内の情報を取得し得、この情報は、支払人１４０及び／又はＰＢＭ１５０に送信され得る。加えて、ＰＭＤＰ１３０は、ＤＩＲレコード３００の一部として、トランザクション最終承認の前に、現在の（例えば、最後に受信した）サブブロック２８０に情報の一部を記憶し得る。例えば、診断（例えば、診断コード２４０）、投与量（例えば、用量２６０）等に関連する情報は、部分ＤＩＲレコード３００として記憶され得、薬物／デバイスＩＤフィールド内の薬物が処方されている（例えば、トランザクション確認時にサブブロック２８０内の処方された薬物フィールド２５５の値によって示され得る）ことが（例えば、ＨＣＰ１２０から）確認されると、対応する薬物／デバイスＩＤ３０２－ｐと関連付けられ得る。

【0077】

したがって、トランザクションに関する（例えば、薬物／デバイスに関連する）情報がリクエストされるとき、所有者（例えば、ＰＭＤＰ１３０）は、リクエスト側エンティティ（例えば、ＨＣＰ１２０）に情報（例えば、サブブロック３８０内の）を送信することによって応答し得る。（例えば、サブブロック３８０内の）情報は、送信前に、（例えば、ＰＭＤＰ１３０によって）暗号化され得、サブブロック３８０内の情報がリクエスト側エンティティ（ＨＣＰ１２０）と送信側エンティティ（ＰＭＤＰ１３０）との間でプライベートであるように、リクエスト側エンティティ（例えば、ＨＣＰ１２０）によって復号可能であり得る。加えて、エンティティ間で交換されるサブブロック内の情報は、共有される情報が、既存の規制、プライバシー法、契約義務、及び／又は情報の指定された所有者（例えば、患者）から受信される認可に準拠するように、制限され得る。

【0078】

図３Ｂは、トランザクションに関連してＤＩＲレコード３００に含まれ得るいくつかの追加情報を有する例示的なＤＩＲレコード３００を示す。図３Ｂでは、サブブロック２８０及び３８０は、破線の輪郭を有するブロックによって示される。説明を簡単かつ容易にするために、サブブロック２８０及び３８０内の情報は示されていない。先に概説したように、サブブロック２８０内の情報の一部又は全ては、ＤＩＲレコード３００の一部を形成し得る。

【0079】

図３Ｂに示すように、ＤＩＲ３００は、処方集４０５を更に含み得、処方集４０５は、治療クラスに関連する承認された処方箋薬（例えば、後発医薬品名及びブランド名）のリストを含み得る。薬物処方集は、薬物プラン及び／又は保険プランによって保険適用される薬物及び／又はデバイスを識別するために使用され得る。処方集は、定期的に更新され得る、かつ／又は公開され得る。例えば、法律、規制機関、健康保険取引所、及び／又は個人雇用主は、利用可能な／承認された保険プランのための処方集が、指定された時間に公開及び更新されることを指定し得る。したがって、場合によっては、様々なプランのための処方情報は、公的に入手可能であり得、かつ／又はプラン加入者（例えば、組織のメンバ／従業員の代理としてプランに加入している組織）に利用可能であり得、かつ／又は他のエンティティ（例えば、規制機関、健康取引所等）から入手可能であり得る。

【0080】

処方集は、治療を「区分（tier）」に分割することによって製品間を区別し得る。各区分では、患者コスト負担のレベルが異なり得る。例えば、好ましい区分の薬物／デバイスの場合、患者コスト負担は、０ドルであり得るか、又は患者の保険プランにおいて指定された自己負担金（免責額対象）に限定され得る。好ましくない区分の薬物／デバイスは、しばしば「共同負担」と呼ばれる追加の患者コスト負担の対象となり得る。例えば、好ましくない薬物を処方された患者は、薬物価格のある割合（例えば、３０％）を、自己負担金に加えて共同負担として支払う場合がある。共同負担の額は、区分に依存し得る。同様の「区分」は、デバイス及び／又は他の医療的治療にも適用され得る。

【0081】

したがって、処方集４０５には、各々が対応する支払人ｉに関する情報を有する支払人－ｉフィールド４１０－ｉ（１≦ｉ≦ｎ）が含まれ得る。更に、処方集４０５には、各支払人－ｉ４１０－ｉについて、繰り返される区分－ｊフィールド４１０－ｊ（１≦ｊ≦Ｔ＿ｉ）に現れ得る、対応する薬物区分に関する情報が含まれ得る。ここで、Ｔ＿ｉは、支払人－ｉに関連付けられた区分の数である。薬物に関連付けられた区分は、その薬物が使用されている指示（例えば、指示フィールド４２０－ｋに列挙される）、及び支払人－ｉ４１０－ｉに依存し得る。例えば、薬物に関するＤＩＲレコード３００内の処方集４０５は、（例えば、支払人１ ４１０－１及び何らかの指示３２０－ｋについて）、第１の後発薬物が区分１ ４１５－１であり、より高価な第２の後発薬物が区分２ ４１５－２薬物であり、ブランド薬物が区分３ ４１５－３薬物であると指定し得る。更に、各区分－ｊフィールド４１０－ｊは、繰り返される指示－ｋフィールド４２０－ｋ（１≦ｋ≦ｓ）を含み得る。区分の下の指示－ｋフィールド４２０－ｋは、処方集が治療として（例えば、支払人１ ４１０－１及び／又はＰＢＭ１５０によって）承認されている病状（指示）を指定し得る。

【0082】

したがって、患者の自己負担コスト（例えば、共同負担）は、病状に対する医療的治療ガイドライン、利用可能な治療選択肢、患者又はＨＣＰ１２０によって最終的に選択される治療レジメン、選択された治療に関連付けられた区分４１５、選択された治療のための指示４２０、並びに支払人１４０及び／又はＰＢＭ１５０、のうちの１つ又は２つ以上に応じて変動し得る。しかしながら、そのような自己負担コスト情報は、多くの場合、処方時に患者及び／又はＨＣＰ１２０にとって取得することが困難であるか又は利用不可能であり、この結果として、（例えば、より安価な治療選択肢が利用可能である場合は）患者に対するより高い継続コストをもたらし得、かつ／又は処方／治療の変更、並びに／又はＨＣＰ１２０及び患者による治療決定の再検討などの追加のトランザクションをもたらし得る。更に、全体として見ると、準最適な決定及び／又はトランザクションオーバーヘッドは、全体的なシステムコスト及び効率に悪影響を及ぼす。

【0083】

図３Ｂに示すように、ＤＩＲ３００は、治療（例えば、薬物又はデバイス）が利用可能にされている価格を列挙し得る価格４２５－ｐｄを含む、様々な他のデータフィールドを含み得る。価格４２５－ｐｄは、（現在の患者保険適用範囲情報に基づいて支払人１４０／ＰＢＭ１５０によって見られるような）患者コストの、支払人１４０若しくはＰＢＭ１５０提供の推定額であり得る。（支払人１４０／ＰＢＭ１５０によって推定されるような）患者コストは、任意の満たされていない免責額、患者自己負担金、（例えば、区分４１５に基づく）共同負担、（例えば、支払人１４０からの）コスト負担、及び（例えば、支払人１４０／ＰＢＭ１５０とＰＭＤＰ１２０／薬局１６０との間の）薬物／デバイスの交渉された価格、の関数であり得る。上で概説したように、特定の支払人及び治療について、区分４１５は、その治療に関連付けられた指示４２０に依存し得る。別の例として、価格４２５－ｐｄは、（例えば、ＰＭＤＰ１２０及び／又は薬局１６０及び／又は別のエンティティと）交渉された価格を反映し得、追加のコスト内訳（．ｇ．自己負担金４２１、免責額４２３、情報は、患者の自己負担コストに関連して提供され得る。

【0084】

いくつかの状況では、処方集４０５（サブフィールドを含む）及び関連情報は、処方集サブブロック４８０として（例えば、支払人１４０及び／又はＰＢＭ１５０及び／又は健康取引所などの別のエンティティから）取得され得る。いくつかの実施形態では、価格４２５、自己負担金４２１、免責額４２３、及び共同負担４２９などのサブブロック４８０の一部分は、トランザクション中及び／又はトランザクション最終承認の前に、更新された処方集４０５とともに（例えば、支払人１４０及び／又はＰＢＭ１５０から）取得され得る。したがって、サブブロック４８０内の情報は、トランザクション時に最新であり得る（又は最新にされて／更新され得る）。（例えば、サブブロック２８０の一部として）ＨＣＰ１２０から受信された保険適用範囲関連情報２７２及び／又はプランＩＤ２７０に基づいて、（例えば、１つ又は２つ以上のサブブロック４８０の一部であり得る）データフィールド価格４２５、自己負担金４２１、免責額４２３、及び共同負担４２９が、対応する薬物／デバイス３０２に提供され得る。

【0085】

場合によっては（例えば、サブブロック２８０が保険適用範囲関連情報２７２及び／又はプランＩＤ２７０を含まない場合）、支払人１４０及び／又はＰＢＭ１５０並びに支払人１４０及び／又はＰＢＭ１５０は、サブブロック４８０において、価格４２５、自己負担金４２１、免責額４２３、及び共同負担４２９を決定し、その情報をＰＭＤＰ１３０に提供し得る。例えば、支払人１４０及び／又はＰＢＭ１５０は、トランザクションＩＤ６９５及びトランザクションタイプを使用して、情報についてのＰＭＤＰ１２０に対するリクエストを、ＨＣＰ１２０から受信された（例えば、サブブロック２８０及び／又は２８４内の）以前の情報と相関させることによって、サブブロック４８０内の価格４２５、自己負担金４２１、免責額４２３、及び共同負担４２９、及び／又は他の情報を決定し得る。

【0086】

いくつかの実施形態では、ＰＭＤＰ１３０は、価格４２５－ｐｄ、自己負担金４２１－ｐｄ、免責額４２３－ｐｄ、及び共同負担４２９－ｐｄを含むブロック４８０内の情報を使用して、（例えば、薬物／デバイスＩＤフィールド３０２－ｐｄによって指定される）薬物／デバイスに対する支払い支援３９１－ｐｄを決定し得る。ＰＭＤＰ１３０は、（例えば、ＰＭＤＰ１３０によって製造及び／又は供給される薬物／デバイスについて）支払い支援３９１－－ｐｄを提供して、手頃な価格を増加させ、かつ／又は患者の自己負担コストを相殺することが多い場合がある。ＰＭＤＰ１３０によって（又はＰＭＤＰ１３０の代理として）提供される支払い支援は、様々な患者適格性基準に基づき得る。したがって、更新された患者コスト内訳が、処方のコストメトリック３９５とともに提供され得る。更新された患者コスト内訳は、対応する薬物／デバイス３０２－ｐｄに関して、（ａ）患者自己負担コストである自己負担３９２－ｐｄ、（ｂ）支払い支援３９１－ｐｄ、（ｃ）上記（ａ）の自己負担コストが適用可能である薬局ＩＤ３９４－ｌ、及び（ｄ）１つ又は２つ以上の他の任意選択フィールドを含み得る。

【0087】

場合によっては（例えば、患者が支払い支援を利用したいとき）、患者認可時に、ＨＣＰ１２０は、患者のＰＩＩ情報を保険適用範囲情報とともに提供し得（例えば、サブブロック２８０において）、保険適用範囲情報は、支払人１４０及び／又はＰＢＭ１５０によって提供される患者保険プラン情報（例えば、サブブロック４８０において）及び患者アプリケーション情報（例えば、患者によってＰＭＤＰ１３０及び／又はＰＭＤＰ１３０の代理として振る舞う提携エンティティに別々に提供されたものであり得る）と相関させて、薬物／デバイスの適格性及び支払い支援３９１－－ｐｄを決定し得る。処方２５０は複数の薬物／デバイスを含み得るので、支払い支援３９１－ｐｄは、支払い支援が適用可能である処方２５０内の各対応する薬物／デバイス３０２－ｐｄ毎に決定され得る。

【0088】

いくつかの実施形態では、ＰＭＤＰ１３０及び／若しくは別のエンティティ、並びに／又はユーザ（例えば、患者）アプリケーション（例えば、スマートフォン、ハンドヘルドコンピューティングデバイス、タブレットなどのモバイルデバイス上で実行される）は、複数のＰＭＤＰ１３０から支払い支援情報を取得して、処方コード２５０によって識別される処方内の各薬物／デバイス３０２に関連付けられたコスト情報３９５を決定し得る。例えば、アプリケーションは、コストメトリック３９５を決定するために、１つ又は２つ以上のＰＭＤＰ１３０（又は１つ又は２つ以上のＰＭＤＰ１３０と提携しているエンティティ）から受信された任意の支払い支援３９１－ｐｄを集約し得る。エンティティ支払い支援プログラムが、ＰＭＤＰ１３０以外のエンティティによって（すなわち、アフィリエート、患者アクセスプログラムプロバイダ／コーディネータ、地域の機関、非営利団体、政府、又は他のエンティティによって）調整及び／又は管理され得る事例では、支払い支援情報は、（例えば、サブブロック３９０に反映されるように）各ＰＭＤＰ１３０から受信される情報に基づいて、管理エンティティによって（例えば、患者のモバイルコンピューティングデバイス上のアプリケーションを介して）提供され得る。いくつかの実施形態では、患者のモバイルコンピューティングデバイス上のアプリケーションは、許可型ブロックチェーンプラットフォームに関連付けられたエンティティ（例えば、ＨＣＰ１２０及び／又は患者アクセスプログラムコーディネータ及び／又は健康取引所及び／又はＰＭＤＰ１３０）によって認可され得、アプリケーションを認可／提供するエンティティと安全なチャネルを介して通信して、許可型ブロックチェーンプラットフォームに関連付けられたエンティティと情報を交換し得る。

【0089】

コスト情報３９５は、コスト情報３９５を決定するために使用される基準又は選好（処方が記入される場所、好みの薬局等）を指定し得る患者基準２９７に基づいてい得る。コストメトリック３９５は、３９５＿ｐｄによって示される薬物レベル（例えば、特定の薬物／デバイス３０２＿ｐｄのコスト内訳、特定の薬物／デバイス３０２－ｐｄが取得され得る最低コスト薬局、治療の持続時間及び／又は保険適用範囲の期間などの指定された期間にわたるクラス３０２－ｐにおける最低コスト薬物３３７－ｐｄ）であり得、かつ／又は３９５＿ｐによって示される処方レベル（例えば、１つ又は２つ以上の特定の薬物／デバイス３０２が選択されるときに処方を満たす最低コスト、選択された場合に処方を満たすために最低コストを提供するであろう薬物／デバイス３０２のセット、処方に対する治療の持続時間にわたって最低コストを提供するであろう薬物／デバイス３０２のセット、現在の保険／給付金補償期間などの特定の期間にわたって最低コストを提供するであろう薬物／デバイス３０２のセット等）であり得る。

【0090】

図３Ｃは、（第１のＥＨＲサブブロック２８０の一部であり得る）最初の提案された処方２５０から、治療選択を容易にするためにコスト情報３９５とともに患者／ＨＣＰ１２０に提示され得る、（例えば、ＤＩＲサブブロック３８０及び／又は３９０における）選択肢への例示的なデータフローを示す。

【0091】

上で概説したように、いくつかの実施形態では、最初の提案された処方２５０に関連する情報は、第１のＥＨＲサブブロック２８０を介して（例えば、ＰＭＤＰ１３０及び／又は別のエンティティによって）取得され得る。ＥＨＲサブブロック２８０は、他の情報（例えば、患者医療保険適用範囲情報）も含み得る。図３Ｃに示すように、例示的な提案された処方２５０は、複数の第１の治療（例えば、提案された薬物／デバイス２５５－ｉ、（１≦ｉ≦Ｎ）を含み得る。サブブロック２８０は、ＰＭＤＰ１３０及び／又は別の認可されたエンティティによって暗号化され得、かつ復号可能であり得る。

【0092】

いくつかの実施形態では、薬物／デバイスクラス３３７－ｐ（１≦ｐ≦Ｐ）は、提案された処方２５０内の１つ又は２つ以上の薬物／デバイス２５５－ｐ、（１≦ｐ≦Ｐ）に対応して決定され得る。図３Ｃに示すように、各薬物／デバイスクラス３３７－ｐに対応する薬物／デバイス３０２＿ｐｄ（１≦ｄ≦Ｄ＿ｐ、ここでＤ＿ｐは、クラスｐにおける選択された薬物／デバイスの数である）が決定され得る。

【0093】

薬物／デバイスクラス３３７－ｐ内の各薬物／デバイス３０２＿ｐｄについて、患者の自己負担コスト３９２＿ｐｄ、支払い支援３９１＿ｐｄ、コスト内訳３９７＿ｐｄ、及び薬局情報（例えば、患者自己負担コスト３９２＿ｐｄが適用可能である薬局ＩＤ３９４＿ｌ等）、及び（薬物３０２＿ｐｄのレベルの）コスト情報３９５＿ｐｄが決定され得る。コスト情報３９５＿ｐｄは、患者保険適用範囲情報、並びに／又はＰＢＭ１５０及び／若しくは支払人１４０及び／若しくは別のエンティティから受信された情報に基づいて決定され得る。いくつかの実施形態では、薬局ＩＤ３９４＿１は、（例えば、ブロック２８０で提供される）患者基準２９７に基づいて決定され得る。薬局ＩＤ３９４＿ｌは、薬局関連情報を含み得る、かつ／又は薬局関連情報を検索するために使用され得る。いくつかの実施形態では、上記の情報は、ＨＣＰ１２０、患者、及び／又は別のエンティティに提供され得る。例えば、上記の情報は、サブブロック３９０において暗号化され得、認可された受信側エンティティによって復号され読み取られ得る。一例として、ＨＣＰ１２０及び／又は患者は、上記の情報を、スマートフォン又は他のモバイルコンピューティングデバイス上で実行されるアプリケーションにおいて受信し得る。

【0094】

いくつかの実施形態では、薬物／デバイス３０２＿ｐｄのコスト情報は、（処方２５５＿ｐのレベルの）コストメトリック３９５＿ｐを決定するために、１つ又は２つ以上のユーザ（例えば、患者）が指定した基準に基づいて集約され得る。一例として、処方レベルの（潜在的な）コスト情報３９５－ｐは、例えば、薬物／デバイス３０２－ｐｄ及び／又は１つ又は２つ以上の薬物／デバイス３０２が選択され得ると仮定することに基づき得る。

【0095】

別の例として、潜在的に等価な処方に関連付けられたコスト情報を分析して、位置（例えば、現在の又は提供された場所）の何らかの閾値距離内の単一の薬局において潜在的に等価な処方を満たすための最低総コストなどのコストメトリック３９５＿ｐを決定し得る。更なる例として、潜在的な等価な処方に関連付けられたコスト情報を分析して、処方を履行するために使用される薬局の数に関わらず、位置（例えば、現在の場所、又は郵便番号若しくは住所など提供された場所）の何らかの閾値距離内の潜在的な処方についての最低総コストなどのコストメトリック３９５＿ｐを判定し得る。追加の例として、潜在的に等価な処方に関連付けられたコスト情報を分析して、場所（例えば、現在の場所、又は郵便番号若しくは住所などの提供された場所）の何らかの閾値距離内の処方の総コストが、処方の履行を使用される薬局の数を制限しながら、最低コスト処方の何らかのユーザ指定閾値内にあるように、コストメトリック３９５＿ｐを決定し得る。別の例として、処方に関連付けられたコスト情報を分析して、予想される治療期間にわたる、かつ／又は何らかの指定された時間期間にわたる（例えば、現在又は残りの保険期間の）治療の総コストなどのコストメトリック３９５＿ｐを決定し得る。患者基準２９７はまた、コストメトリック、自己負担コスト等を決定する際に使用され得る、好みの薬局、通信販売オプション等の他の考慮事項を指定し得る。例えば、通信販売が許容可能であることをユーザが指定した場合、サブブロックには、地域内の薬局１６０に加えて通信販売薬局に関連付けられたコストを含み得る。

【0096】

ＤＩＲブロック３００がＤＩＲブロックチェーンに追加され得る場合、ＤＩＲ情報ブロック３００内の一部のデータは、他のエンティティからの入力、他のエンティティによる検証、及び／又は他のエンティティによる確認に依存し得る。例えば、支払人に関連する処方集４０５内の情報（例えば、支払人ｉ４１０－ｉ内で指定される支払人１４０）は、ＤＩＲブロック３００の一部を形成し得、支払人（例えば、支払人１４０）による検証に依存し得る。検証が提供され、トランザクション確認が受信されると、ＤＩＲブロック３００がＤＩＲブロックチェーンに追加され得る。検証は、支払人１４０からサブブロック（例えばサブブロック４８０）の形態で取得され得る。サブブロック４８０内の情報は、（例えば、トランザクションＩＤ６９５によって識別されるような）トランザクションに固有であり得、支払人１４０によって暗号化され得、またＰＭＤＰ１２０によって復号可能であり得る。場合によっては、暗号化されたサブブロック４８０（又はサブブロック４８０中に存在する情報）は、特にＰＭＤＰ１２０を対象としたものであり得、ＰＭＤＰ１２０以外のエンティティによって復号不可能であり得る。

【0097】

いくつかの実施形態では、ある時点でのトランザクションについて、データフィールド処方集４０５、支払人１ １４０－１内の情報、支払人１ １４０－１内の支払人に関連付けられた区分－ｊフィールド４１５－ｊの各々内の区分情報、各区分－ｊフィールドに関連付けられた指示－ｋフィールド４１０－ｋの各々内の情報は、支払人１ １４０－１から受信されたサブブロック４８０の一部であり得る。しかしながら、任意の他の支払人に関連する情報は、これらの支払人がトランザクションの当事者ではない場合があるため、サブブロック４８０の一部を形成しない場合がある。したがって、単一の支払人（例えば、支払人１ １４０－１）が関与するトランザクションでは、ＤＩＲレコード３００は、その特定の支払人についての情報を（例えば、サブブロック４８０内に）含み得る。

【0098】

複数の支払人がトランザクションに関与する場合、暗号化された複数の（例えば、各々が対応する支払人１４０－ｉからの）サブブロックは、ＰＭＤＰ１３０によって受信され、ＰＭＤＰ１３０によってＤＩＲレコード３００に統合され得る。支払人－ｉから受信された各サブブロック内の情報は、ＰＭＤＰ１３０と対応する支払人－ｉとの間でプライベートであり得る。サブブロック４８０は、別の特定のエンティティと共有され得る何らかの情報を示す単なる例に過ぎない。一般に、ローカルに維持されたブロックチェーン（例えば、ＤＩＲ３００）内にデータレコード又はブロックからサブブロックを形成するために使用される情報は、規制（例えば、ヘルスケア及び／又はプライバシー）、情報共有を規定する法律（例えば、エンティティが共有することができるか又はできない情報を判定する）、ビジネスガイドライン（例えば、企業秘密若しくは機密情報）及び／又は契約義務（例えば、情報を共有するエンティティの間又はそのエンティティに関連する）に依存し得る。

【0099】

したがって、いくつかの実施形態では、ＰＭＤＰ１３０に送信されるサブブロック内のデータは、対応する送信側エンティティ（例えば、支払人－ｉ １４０－ｉ）によって別個に暗号化され得、ＰＭＤＰ１３０によって復号可能であり得、また認可されていないエンティティに利用不可能であり得る。いくつかの実施形態では、（例えば、ＰＭＤＰ１３０によって受信された）サブブロック内のデータの暗号化は、対称鍵暗号法を含む任意の適切な暗号化技術に基づき得る。暗号化は、例えば、エンティティ（例えば、支払人１ １４０－１フィールド及びＰＭＤＰ１３０で識別される支払人１４０－ｉ）の間で共有される秘密鍵に基づき得る。受信側エンティティ（例えば、ＰＭＤＰ１３０）は、例えば、秘密共有鍵に基づいて、受信したサブブロックを復号することが可能であり得る。

【0100】

更に、ブロックチェーンに追加される前に、ＤＩＲブロック３００内のデータはまた、任意の安全な暗号化技術を使用して、第１のエンティティ（例えば、ＰＭＤＰ１３０）によって別個に暗号化され得、その結果、そのデータは、第１のエンティティ（例えば、ＰＭＤＰ１３０）によって復号可能かつ利用可能であるが、他のエンティティ（例えば、ＨＣＰ１２０及び／又は支払人１４０）によっては、閲覧することができない。

【0101】

図４は、ＰＢＭ１５０によって維持され得る、例示的な薬局給付レコード（ＰＢＲ）４００の一部分を示す。ＰＢＭという用語は、支払人（例えば、支払人１４０）の代理として給付金の一部分（例えば、医薬品及び／又は医療デバイスの処方）を管理する役割を果たす任意のエンティティを指すために使用される。場合によっては、ＰＢＭは、保険業者／支払人と提携し得る。場合によっては、保険業者／支払人は、薬物／デバイス給付金を直接管理し得るため、支払人１４０及びＰＢＭ１５０は単一のエンティティと見なされ、以下の説明の一部分は、単一の（支払人＋ＰＢＭ）エンティティにも適用可能であり得る。

【0102】

ＰＢＲ４００は、支払人及び関連付けられた給付プラン、利用可能な給付金、患者／加入者情報、支払人薬物／デバイス区分、コスト負担等に関連する情報を含み得、ＰＢＭ１５０によって（例えば、ＰＢＩデータベース１５５内に）所有及び維持され得る。いくつかの実施形態では、ＰＢＲ４００内のデータフィールドは、患者／ＨＣＰ１２０及び／又は支払人１４０及び／又は他のエンティティから受信された情報に部分的に基づいて、ＰＢＭ１５０によって追加及び／又は更新され得る。ＰＢＲ４００はまた、他のエンティティから（例えば、サブブロックとして）受信されたデータも含み得る。ＰＢＲ４００に示されたフィールドは、単なる例示であり、ＰＢＲ４００は、法律、標準規格、ＰＢＭ慣習、及び／又は業界慣習等に基づいて、様々な他の追加のフィールドを含み得る。ＰＢＲは、例示的なＰＢＲ４００に関連して示されたフィールドとは（多かれ少なかれ）異なるフィールドを含み得る。

【0103】

ＰＢＭは、処方された薬物の薬物区分を決定し得、これが共同負担額を決定し得る。ＰＢＭはまた、医薬品の小売価格を設定又は決定し得、特定の製品又は製品のバスケットの販売量に基づいて、製造業者から支払い又は割り戻しを取得し得、場合によっては、処方集の薬局から販売後価格譲渡及び支払いを取得し得る。したがって、ＰＢＲ４００は、販売情報フィールド４９７を含み得、これは、各薬物についてのトランザクション及び他の販売情報を記憶し得る。ＰＢＲ４００はまた、薬物／デバイス、割引／割り戻し情報等のための支払人固有及び薬局固有の販売量の集計を追跡するための様々な他のフィールド（図４には示さず）を含み得る。ＰＢＭ１５０は、（例えば、暗号化されたサブブロックを介して、ＨＣＰ１２０、支払人１４０及び／又は薬局１６０及び／又はＰＭＤＰ１３０と）情報を交換し得る。

【0104】

いくつかの実施形態では、ＰＢＲ４００は、ＰＢＭ１５０に関連する情報（例えば、ＰＢＭ識別、連絡先情報、住所等）を記憶し得る、ＰＢＭプロファイルフィールド４９５に関連付けられ得る。いくつかの実施形態では、ＰＢＭプロファイル４９５内の情報の一部又は全ては、任意選択で、トランザクションに関連して他のエンティティと共有され得る。例えば、ＰＢＭプロファイル４９５の一部分は、（例えば、指定された受信側エンティティによって復号可能であり得る、暗号化されたサブブロックの一部として）ＰＭＤＰ１３０、支払人１４０、及び／又は薬局１６０などの１つ又は２つ以上のエンティティに送信され得る。

【0105】

図４に示すように、ＰＢＲ４００は、（破線の境界で囲まれて示されている）サブブロック２８０中の情報の一部分を含み得る。いくつかの実施形態では、サブブロック２８０内のいくつかである情報は、ＨＣＰ１２０から受信され、ＰＢＭ１５０によって更新及び／又は検証され得る。いくつかの実施形態では、ＰＢＭ１５０は、サブブロック２８０内の情報の一部又は全てをＰＭＤＰ１３０から（例えば間接的に）受信し得る。いくつかの実施形態では、サブブロック２８０は、サブブロック２８４及び／又は２８４内の情報の一部又は全てを含み得る。

【0106】

したがって、図４に示すように、いくつかの実施形態では、１つ又は２つ以上の暗号化されたサブブロック２８０は、保険適用範囲関連情報２７２（例えば、ＨＣＰ１２０によって最初に取得された情報に基づく）、診断２３５、診断コード２４０、指示２４２、診断コード２４０、治療コード２４５、及び処方コード２５０を含み得る。更に、ＰＢＲ４００はまた、ＰＢＭ１５０へのトランザクションＩＤ６９５とともに、実際の処方された薬物／デバイス２５５－ｐｓ（例えば、薬物／デバイスクラス３３７－ｐから選択された薬物／デバイス３０２－ｐｄに対応する）、用量２６０－ｐｓ、及び／又は持続時間２６５－ｐｓのうちの１つ又は２つ以上を含み得、ここで、１≦ｐ≦Ｐであり、各薬物／デバイスクラスｐについては、１≦ｓ≦Ｄ＿ｐである。サブブロック２８０内の処方コード及び関連する処方された薬物／デバイス２５５－ｐｓ、用量２６０－ｐｓ、及び／又は持続時間２６５－ｐｓ等は、薬物／デバイス３０２－ｐｄの評価後の薬物／デバイスの選択（例えば、患者によって選択されたもの、及び／又はＨＣＰ１２０によって処方されたもの）を表し得る。例えば、ＨＣＰ１２０及び／又は（ＨＣＰ１２０と相談している）患者は、各薬物／デバイスクラス３３７－ｐから１つの薬物／デバイス３０２－ｐｓ≡２５５－ｐｓを選択し得、選択された薬物／デバイス２５５－ｐｓは、最終の／選択された処方２５０－ｓに関連付けられ得る。ＰＢＭ１５０は、サブブロック２８０内の情報の一部又は全てをＰＢＲ４００に（例えば、トランザクション確認／最終承認の時点で）組み込み得る。エンティティ間のトランザクションを一意に識別し得るトランザクションＩＤ６９５は、エンティティ間の情報交換及び調整を容易にし得る。例えば、トランザクションの当事者であるエンティティ間で共有される一意のトランザクションＩＤ６９５は、１つ又は２つ以上のエンティティから受信された情報を、ローカルに記憶された情報及び／又は他のエンティティから受信された情報と相関させ、集約し、検証し、処理するために使用され得る。いくつかの実施形態では、（例えば、ＨＣＰ１２０からの第２のサブブロック２８０内の）最終承認された処方２５０－ｓは、（薬物／デバイス３０２－ｐｄを有する）ＤＩＲサブブロック３８０に続いて送信され得る。

【0107】

ＰＢＲ４００はまた、トランザクションＩＤ６９５とともにＰＭＤＰ１３０から受信され得るサブブロック３８０中の情報の一部分も含み得る。例えば、いくつかの実施形態では、ＰＭＤＰ１３０は、薬物／デバイスクラス３３７－ｐに対応する薬物／デバイス３０２－ｐｄを（例えば、１つ又は２つ以上の暗号化されたサブブロック３８０内で）送信し得る（この場合、各薬物／デバイスクラス３３７－ｐは、少なくとも１つの処方された薬物２５５－ｐに関連付けられ得る（例えば、ＰＭＤＰ１３０に送信された最初の処方２５０内で）。ＰＢＲ４００は更に、薬物／デバイス３０２－ｐｄに対応する（サブブロック３８０ の一部として受信され得る）薬物／デバイス名３０４－ｐｄを含み得る。ＰＢＭ１５０は、サブブロック３８０内の情報を処理し、承認された薬物、区分、コスト等のリストを（例えば、サブブロック４８０内で）返し得る。

【0108】

いくつかの実施形態では、トランザクションＩＤ６９５は、サブブロック２８２及び３８０が同じトランザクションに関連付けられていることを決定するために、ＰＢＭ１５０によって使用され得る。次いで、ＰＤＭ１５０は、サブブロック２８０内の保険適用範囲関連情報２７２を使用して、サブブロック４８０内の情報（例えば、処方集、試験者等）を決定し得る。いくつかの実施形態では、サブブロック３８０はまた、サブブロック４８０内の情報を決定するＰＢＭ１５０によって使用され得る、プランＩＤ２７０及び保険適用範囲関連情報２７２を（例えば、ＰＭＤＰ１２０に提供されるときに）含み得る。例えば、ＰＢＭ１５０は、（患者及び支払人１４０－ｉについての）保険適用範囲関連情報２７２を、（支払人ｉ４１０－ｉからローカルに維持及び／又は取得され得る）追加の患者保険適用範囲情報４９５とともに使用して、サブブロック４８０内の情報を決定し得る。

【0109】

図４に示すように、ＰＢＲ４００内のサブブロック２８０は、（例えば、保険適用範囲情報２７２及び／又はプランＩＤ２７０に基づいて決定される）支払人１４０－ｉ、及び（例えば、サブブロック３８０に基づいて決定される）薬物／デバイス３０２－ｐｄについての、区分情報４１５－ｊと指示４２０－ｋとを含む、処方集４０５を含み得る。いくつかの実施形態では、サブブロック４８０は、診断２３５、診断コード２４０、指示２４２、治療コード２４５、処方コード２５０、処方された薬物／デバイス２５５、対応する用量２６０、及び／又は持続時間２６５（例えば、サブブロック２８０に基づいて決定される）のうちの１つ又は２つ以上を更に含み得る。ＰＢＲ４００はまた、トランザクションＩＤ６９５も含み得る。ＰＢＭ１５０は、サブブロック２８０及び／又は３８０内の情報の何らかの部分を、（例えば、トランザクション確認／最終承認の時点で）ＰＢＲ４００に組み込み得る。

【0110】

いくつかの実施形態では、ＰＢＭ１５０は、価格４２５を含む様々な他のデータフィールドを（例えば、サブブロック４８０の一部として）更に含み得、様々な他のデータフィールドは、治療（例えば、薬物又はデバイス３０２－ｐｄ）が利用可能にされている価格を（プラン、区分、及び指示情報毎に）列挙し得る。価格４２５－ｐｄは、支払人１４０若しくはＰＢＭ１５０が提供する患者コストの見積もり（薬物／デバイス３０２－ｐｄに対して支払人１４０／ＰＢＭ１５０によって見られる）であり得るか、又は（例えば、ＰＭＤＰ１２０及び／若しくは薬局１６０及び／若しくは別のエンティティと交渉されるような）交渉価格であり得る。いくつかの実施形態では、追加のコスト内訳（．ｇ．自己負担金４２１－ｐｄ、免責額４２３－ｐｄ、共同負担４２７－ｐｄ、薬物／デバイス３０２－ｐｄに対する患者の自己負担コストがサブブロック４８０の一部として提供され得る。

【0111】

上で概説したように、ＰＢＭ１５０によって受信又は送信されるサブブロック内の情報は暗号化され得る。受信されたサブブロックは、ＰＢＭ１５０を宛先としたときはＰＢＭ１５０によって復号され得るが、ＰＢＭ１５０によって送信されたサブブロックは、宛先である受信者によって復号可能であり得る。

【0112】

図５は、薬局１６０などのエンティティによって維持され得る、例示的な薬局処方レコード（Prescription Record、ＰＰＲ）５００を示す。薬局とは、ＨＣＰ１２０などの医療提供者によって書かれた処方を履行する任意のエンティティ（物理的、仮想的、又は通信販売）を指す。薬局は、ＨＣＰ１２０から処方を受け取り、支払人１４０及び／又はＰＢＭ１５０との間で患者保険適用範囲情報を検証し、患者と対話して処方を履行し、支払人１４０／ＰＢＭ１５０とのコントラクト及び／又は支払い協定に従って（例えば、薬物／デバイスについての交渉価格、自己負担金、免責額、共同負担等のうちの１つ又は２つ以上を収集することによる保険適用範囲に基づいて）、患者から支払いを受け取ることができる。

【0113】

いくつかの実施形態では、ＰＰＲ５００は、薬局１６０によって（例えば、ＰＰＩデータベース１６５内に）所有及び維持され得る。いくつかの実施形態では、ＰＰＲ５００内のデータフィールドは、患者／ＨＣＰ１２０及び／又は支払人１４０及び／又は他のエンティティから受信された情報に部分的に基づいて、薬局１６０によって追加及び／又は更新され得る。ＰＰＲ５００はまた、他のエンティティから（例えば、サブブロックとして）受信されたデータも含み得る。ＰＰＲ５００に示されたフィールドは、単なる例示であり、ＰＰＲ５００は、法律、標準規格、薬局慣習、及び／又は業界慣習等に基づいて、様々な他の追加のフィールドを含み得る。ＰＰＲは、例示的なＰＰＲ５００に関連して示されたフィールドとは（多かれ少なかれ）異なるフィールドを含み得る。

【0114】

いくつかの実施形態では、ＰＰＲ５００は、薬局１６０に関連する情報（例えば、薬局識別、連絡先情報、住所等）を記憶し得る、薬局プロファイルフィールド５９５を含み得る。いくつかの実施形態では、薬局プロファイル５９５内の情報の一部又は全ては、任意選択で、トランザクションに関連して他のエンティティと共有され得る。例えば、薬局プロファイル５９５の一部分は、（例えば、指定された受信側エンティティによって復号可能であり得る、暗号化されたサブブロックの一部として）ＰＭＤＰ１３０、支払人１４０、及び／又は薬局１６０などの１つ又は２つ以上のエンティティに送信され得、かつ／又は患者と共有され得る。

【0115】

いくつかの実施形態では、ＰＰＲ５００は、サブフィールド患者名２０４、ＤＯＢ２２０、患者保険適用範囲情報５７２、ＰＢＭ情報５８２、及び患者自己負担金４２１－ｐｄを含み得る、患者情報フィールド５１０を含み得る。ＰＰＲ５００はまた、処方２５５－ｐの処方コード２５０、処方２５５－ｐの処方側エンティティに関連付けられたＨＣＰプロファイル２９５（例えば、ヘルスケア提供者ＩＤ、登録番号、連絡先情報等）、処方２５５－ｐに関連付けられた処方された薬物／デバイス２５５－ｐｓ、持続時間２６５－ｐｓ、及び投与量２６０－ｐｓを含み得る。いくつかの実施形態では、ＰＰＲ５００は、処方日、履行状況（例えば、集荷の準備ができているか、集荷されたか、及び／又は患者に配送されたか、等）などの様々な他のフィールド（図５には示さず）を含み得る。

【0116】

いくつかの実施形態では、（サブフィールド患者名２０４、ＤＯＢ２０６、患者保険適用範囲情報５７２の一部分、処方コード２５０、処方された薬物／デバイス２５５－ｐｓ、持続時間、投与量、及びＨＣＰプロファイル情報を含む患者情報５１０は、処方の確定時に薬局１６０によって復号可能な暗号化されたサブブロック２９０として、ＨＣＰ１２０から薬局１６０によって受信され得る。例えば、ＨＣＰ１２０及び／又は患者は、各薬物／デバイスクラス３３７－ｐから１つの薬物／デバイス２５５－ｐｓを選択し、選択された薬物／デバイス２５５－ｐｓをサブブロック２９０の一部として薬局１６０に提供し得る。

【0117】

いくつかの実施形態では、サブブロック２９０を受信及び復号すると、薬局１６０は、患者保険適用範囲関連情報（例えば、サブブロック２９０の一部として受信され得る保険適用範囲関連情報２７２）を使用して、処方に関連付けられたＰＢＭ及び／又は支払人を決定し得る。

【0118】

いくつかの実施形態では、薬局は、サブブロック２９０内の情報の一部又は全てを、（例えば、任意の一般的な規制に従って）支払人１４０及び／又はＰＢＭ１５０に送信し得る。薬局１６０によって支払人１４０及び／又はＰＢＭ１５０に送信される情報は、指定されたエンティティ（例えば、支払人１４０及び／又はＰＢＭ１５０）によって復号可能な、暗号化されたサブブロック（図５には示さず）の形態であり得る。これに応答して、薬局１６０は、支払人１４０及び／又はＰＢＭ１５０からの暗号化されたサブブロック４９０を受信し、復号し得る。サブブロック４９０は、患者保険適用範囲情報５７２を検証及び更新し、ＰＢＭ情報５８２を更新するために薬局１６０によって使用され得る、検証情報（例えば、患者保険適用範囲に関する）を含み得る。いくつかの実施形態では、ＰＢＭ１５０及び／又は支払人１４０は、処方２５０－ｓに関連付けられた処方された薬物／デバイス２５５－ｐｓについての自己負担金情報４２１－ｐｓを更に含み得る。

【0119】

いくつかの実施形態では、ＰＰＲ５００は、トランザクション情報５１５を更に含み得、これは、トランザクションに関連する情報、例えば、患者コスト５１５（薬局１６０によって見られるような共同負担４２１－ｐｓなど）、支払人コスト５２５（例えば、支払人１４０及び／又はＰＢＭ１５０に請求される金額／請求され得る金額）、及び支払い様式（例えば、患者によって使用される）を記憶し得る。例えば、ＰＭＤＰ１２０が、自己負担金（又は他の自己負担患者コスト）とともに、（例えば、患者支援プログラムの一部として）患者支援を提供する場合では、ＰＭＤＰ１２０（又はＰＭＤＰ１２０の代理として振る舞うエンティティ）は、支払いとして薬局１６０に提示され、支払いフィールドの様式５３０に記録され得る、割引カード、割引コード、又はプリペイドカードを提供し得る。

【0120】

図６は、例示的な健康トランザクションレコード（ＨＴＲ）６００を示す。図６に示すように、ＨＴＲ６００は、患者に関連付けられたトランザクションについての治療及びコスト関連情報を含み得る。ＨＴＲ６００に示したフィールドは、単に例示的なものに過ぎず、ＨＴＲ６００は、法律、標準規格、業界慣習等に基づいて、様々な他のフィールドを含み得る。加えて、ＨＴＲが、例示的なＨＴＲ６００と関連して示されるものとは（多かれ少なかれ）異なるフィールドを含み得る。いくつかの実施形態では、ＨＴＲ６００は、トランザクションに関連付けられた１つ又は２つ以上のエンティティへのトランザクション承認及び／又は支払いを担い得る、支払人１４０（例えば、健康保険業者及びトランザクション情報データベース１４７の一部の形態）などのエンティティによって所有及び維持され得る。

【0121】

ＨＴＲ６００は、患者プロファイル１９５、ＨＣＰプロファイル２９５、ＰＭＤＰプロファイル３９５、ＰＢＭプロファイル４９５、及び薬局プロファイル５９５を含む、支払人１４０に関連付けられ、かつ／又はそれと取引するよう認可されたエンティティに関する情報を含む、様々なデータフィールドを備え得る。記憶されたプロファイルは、エンティティ間のトランザクション（例えば、支払い、割り戻し、保険適用範囲の検証、治療／処方の認可等）を実行するための情報を含み得る。

【0122】

ＨＴＲ６００は、トランザクションに関連付けられたコストの支払人の見解を含み得る、コスト情報６０５を含み得る。例えば、コスト情報６０５は、支払人コスト６１０を含み得、支払人コスト６１０は、トランザクションについての支払人１４０への正味コストを記録し得る。支払人コスト６１０は、ＰＢＭコスト６１２、薬局コスト６１５（例えば、薬局１６０によって支払人１４０に請求される価格）、ＰＭＤＰコスト６２０（例えば、支払人１４０とＰＭＤＰ１２０との間で交渉された価格）、割り戻し６２２（例えば、ＰＭＤＰ１２０から支払人１４０によって受け取られる）、ＨＣＰ治療コスト６２５（例えば、診断に関連してＨＣＰ１２０によって提供される治療のコスト）、及び患者コスト６３０（例えば、治療及び処方に対する患者自己負担金６３２、免責額６３７、及び共同負担６３９を含み得る、プランの下で支払人１４０によって見られるような患者自己負担コスト６３５）のうちの１つ又は２つ以上の関数であり得る。コスト情報６０５に関連付けられた情報の一部は、（例えば、コントラクト等に基づいて）支払人１４０に利用可能であり得るか、一方、一部のコスト情報６０５は、トランザクション最終承認の前に（例えば、支払人１４０によって復号可能な暗号化されたサブブロックを介して）他のエンティティによって提供され得る。例えば、ＰＢＭコスト情報６１２は、ＰＢＭ１５０によって支払人１４０に送信され得る、暗号化されたサブブロック４８０に含まれる情報を復号することによって決定され得る。

【0123】

別の例として、ＨＣＰ１２０は、保険適用範囲関連情報２７２、プランＩＤ２７０、及び／又はＨＣＰプロファイル２９５、を有する暗号化されたサブブロック２８２を支払人１４０に送信し得る。支払人１４０は、情報サブブロック２８２を復号し、追加の患者保険適用範囲情報６９８を使用して患者保険適用範囲を検証し得る。患者保険適用範囲の検証は、検証情報とともに、ＨＣＰ１２０によって復号可能な暗号化されたサブブロックをＨＣＰ１２０に送信することによって、ＨＣＰ１２０に提供され得る。追加の患者保険適用範囲情報６９８の一部又は全てはまた、ＰＢＭ１５０による（例えば、治療についての）患者保険適用範囲の検証を容易にするために、（例えば、ＰＢＭ１５０によって復号可能な暗号化サブブロックとして）ＰＢＭ１５０に送信され得る。

【0124】

更なる例として、暗号化されたサブブロック２８０（場合によっては、サブブロック２８２内の情報を含み得る）は、検証及びトランザクション承認のために、ＨＣＰ１２０によって（例えば、処方が最終承認されると）支払人１４０に送信され得る。いくつかの実施形態では、暗号化されたサブブロック２８０は、支払人１４０によって復号され得、支払人１４０は、１つ又は２つ以上の確認メッセージを（例えば、ＨＣＰ１２０及び／又は他のエンティティに）送信することによって、トランザクションを承認し得る。

【0125】

いくつかの実施形態では、トランザクションが最終承認されると、ＥＨＲ６００は、支払人１４０によって維持され、支払人１４０にアクセス可能なローカルブロックチェーンの一部として記憶され得る。暗号化された形態の（かつ支払人１４０によって復号可能な）ＥＨＲ６００は、多次元ブロック内の多次元ブロックの一部を形成し得る。多次元ブロックチェーンのＥＨＲブロック６００内にない情報は、他のエンティティによって暗号化され得、支払人１４０によって復号可能でない場合がある。逆に、多次元ブロック内のＥＨＲブロック６００は、支払人１４０及び／又はプラットフォームに関連付けられた他のエンティティによって復号可能でない場合がある。したがって、各エンティティは、多次元ブロックチェーン内の多次元ブロックとして記録されるトランザクションの一貫した閲覧を有するが、エンティティは、他のエンティティによって所有される（多次元ブロックの一部として記憶される）ブロック内の情報を閲覧することができない。したがって、第１のエンティティを所有する（多次元ブロックの一部として記憶された）ブロック内の情報は、他の第２のエンティティによる閲覧から安全に保護される。

【0126】

図７Ａは、ヘルスケアコスト決定、ヘルスケア情報セキュリティを容易にし、複数のエンティティ間の相互運用性を容易にするためのプロセスフロー７００を示すフロー図を示す。いくつかの実施形態では、プロセスフロー７００の部分は、加入しているエンティティ及び／又は認可されたエンティティに対して利用可能にされ得る、許可型ブロックチェーンプラットフォーム上で行われ得る。いくつかの実施形態では、フロー７００の一部又は全ては、エンティティに関連付けられたコンピューティングデバイス上で実行されるアプリケーションを使用して実装され得る。フロー図７００では、説明を容易にするために、一部のルーチンメッセージ（例えば、患者保険適用範囲検証等）が示されていない。

【0127】

一例として、患者１７０は、モバイルコンピューティングデバイス（例えば、スマートフォン、タブレット、ラップトップ等）上で実行されるアプリケーションを使用して、トランザクションを開始し得る。いくつかの実施形態では、アプリケーションは、許可型ブロックチェーンプラットフォームに関連付けられたエンティティによって提供及び／又は認可され得る。例えば、アプリケーション（例えば、患者１７０に関連付けられたモバイルコンピューティングデバイス上で実行される）は、第１のエンティティ（例えば、ＨＣＰ１２０、ＰＭＤＰ１３０、健康取引所、及び／又は患者アクセスプログラム（図７には示さず））によって提供されている場合があり、アプリケーションプログラミングインターフェース（Application Programming Interface、ＡＰＩ）及び／又は他のネットワーク並びに通信プロトコルを使用して、第１のエンティティと通信し得る。

【0128】

いくつかの実施形態では、７０５において、患者１７０は、プロファイル及び保険適用範囲情報を、ＨＣＰ１２０、薬局１６０、及び任意選択でＰＭＤＰ１３０、及び／又は１つ又は２つ以上の他のエンティティ、のうちの１つ又は２つ以上に提供し得る。例えば、患者１７０は、患者プロファイル及び保険適用範囲関連情報を、治療を受ける時又はその前にＨＣＰ１２０に、かつ／又は処方を履行する時又はその前に薬局１６０に、提供し得る（又は以前に提供している場合がある）。場合によっては、患者１７０は、患者プロファイル及び保険適用範囲情報を、支払い支援に参加するために、かつ／又は支払い支援を取得するために、ＰＭＤＰ１３０に提供し得る。上で概説したように、患者プロファイル及び保険適用範囲情報は、許可型ブロックチェーンプラットフォーム上で取引するよう認可されたエンティティと相互作用するかつ／又はそれに関連付けられたモバイルデバイス上のアプリケーションを使用して提供され得る（又は提供されている場合がある）。

【0129】

いくつかの実施形態では、ＨＣＰ１２０は、それぞれの受信側エンティティによって復号可能であり得る、暗号化されたサブブロック２８２（図７Ａには示さず）において、保険適用範囲関連情報２７２及びプランＩＤ２７０を、支払人１４０及び／又はＰＢＭ１５０に提供し得る。支払人１４０及び／又はＰＢＭ１５０は、患者保険適用範囲を検証するＨＣＰ１２０によって復号可能な追加の暗号化されたサブブロック（図７Ａには示さず）で応答し得る。

【0130】

いくつかの実施形態では、７１０において、ＨＣＰ１２０は、診断２３５を決定し得、最初に、対応する診断コード２４０及び指示２４２、診断された症状に対する治療に関連付けられた治療コード２４５、並びに処方２５０（例えば、薬物／デバイス２５５－ｐ、各々が対応する持続時間２６５－ｐに関連付けられた対応する用量２６０－ｐ）を提供し得る。いくつかの実施形態では、ＨＣＰは更に、（トランザクションの開始者として）トランザクションＩＤ６９５を取得又は決定し得る。いくつかの実施形態では、上で概説した情報は、患者基準２９７、ＨＣＰプロファイル２９５、プランＩＤ２７０、及び任意選択で保険適用範囲情報２７２とともに、ＰＭＤＰ１３０によって復号可能な暗号化されたＥＨＲサブブロックとしてＰＭＤＰ１３０に送信され得る。例えば、保険適用範囲情報２７２は、患者によって認可されたとき（例えば、患者が参加しているとき、又はＰＭＤＰ１３０に関連付けられた支払い支援プログラムに適用したいとき）に、（ＥＨＲサブブロック２８０内で）ＰＭＤＰ１３０に送信され得る。

【0131】

いくつかの実施形態では、ステップ７１５において、ＰＭＤＰ１３０は、処方２５０内の各薬物／デバイス２５５－ｐについて、対応する薬物クラス３３７－ｐを決定し得る。更に、ＰＭＤＰ１３０は、各クラス３３７－ｐに関連付けられた１つ又は２つ以上の薬物／デバイス３０２－ｐｄを決定し得る。

【0132】

７２０において、ＰＭＤＰ１３０は、クラスメンバ薬物／デバイス３０２－ｐｄを有する暗号化されたＤＩＲサブブロック３８０（又はその一部分）を、診断２３５（並びに対応する診断コード２４０及び指示２４２、治療コード２４５などの関連するフィールド）及びトランザクションＩＤ６９５とともに、ＰＢＭ１５０に送信し得る。ＤＩＲサブブロック３８０は、（例えば、図３Ａ～図３Ｃに関連して上述したように）各薬物／デバイス３０２－ｐｄについての情報を更に含み得る。状況によっては（例えば、支払人１４０がＰＢＭ１５０の機能を実行するとき、及び／又はＰＢＭが使用されないとき）、ＤＩＲサブブロック３８０は支払人１４０に送信され得る。ＤＩＲサブブロックは、指定された受信側エンティティによって復号可能であり得る。

【0133】

７２５において、ＰＢＭ１５０（又は支払人１４０）は、暗号化されたＰＢＲサブブロック４８０でＰＭＤＰ１３０に応答し得、ＰＢＲサブブロック４８０には、支払人１４０に対する処方集４０５、各薬物／デバイス３０２－ｐｄに関連付けられた区分４１５－ｊ、各薬物／デバイス３０２－ｐｄの価格設定情報についての情報を含み得、自己負担金４２１－ｐｄ、共同負担４２３－ｐｄ、免責額４２３－ｐｄ、及び価格４２５－ｐｄのうちの１つ又は２つ以上を含む。サブブロック４８０は、トランザクションＩＤ６９５を参照し得る。例えば、ＰＢＭ１５０（又は支払人１４０）は、ＤＩＲサブブロック３８０内のプラン情報（プラン１Ｄ２７０及び／又は保険適用範囲関連情報２７２）に基づいて、かつ／又はトランザクションＩＤ６９５及びトランザクションタイプを使用して患者１７０に関連付けられた保険適用範囲情報を検索することによって、サブブロック４８０内の情報を判定し得る。ＰＢＲサブブロック４８０は、ＰＭＤＰ１３０によって復号可能であり得る。

【0134】

ステップ７３０において、ＰＭＤＰ１３０は、ＰＢＲサブブロック４８０を復号し、患者基準（例えば、場所、薬局の数、時間期間等）とともに、各薬物３０２－ｐｄについての区分４１５－ｊ及び価格設定情報（例えば、自己負担金４２１－ｐｄ、共同負担４２３－ｐｄ、免責額４２３－ｐｄ、及び価格４２５－ｐｄのうちの１つ又は２つ以上）を使用して、処方に関連付けられたコスト情報３９５を判定し得る。コスト情報３９５は、支払い支援プログラムを通じて（適格であるときに）患者によって受け取られる任意の支払い支援を考慮に入れることができる。いくつかの実施形態では、コストメトリック３９５は、各薬物／デバイス３０２－ｐｄに対する患者自己負担コストであり得るコスト内訳３０７－ｐｄを含み得る。

【0135】

７３５において、ＰＭＤＰ１３０は、暗号化されたＤＩＲサブブロック３８０及び３９０を、コスト情報とともにＨＣＰ１２０に送信し得る。ＤＩＲサブブロック３８０及び／又は３９０は、トランザクションＩＤ６９５と、処方コード２５０と、最初の処方内の（例えば７１０における）各薬物／デバイス２５５－ｐに対応する薬物／デバイスクラス３３７－ｐと、各薬物／デバイスクラス３３７－ｐに対応する薬物／デバイス３０２－ｐｄと、を含み得る。

【0136】

７４０において、ＨＣＰ１２０は、処方のＨＣＰ承認を示すトランザクションタイプを有するトランザクションＩＤ６９５を有する暗号化されたサブブロック２８０－２を、ＨＣＰ１２０、ＰＢＭ１３０、及び／又は支払人１４０のうちの１つ又は２つ以上に送信し得る。暗号化されたサブブロック２８０－２は、選択された薬物デバイス２５５－ｐｓを更に含み得、ここで、１≦ｐ≦Ｐであり、各薬物／デバイスクラスｐについて、１≦ｓ≦Ｄ＿ｐである。例えば、１つの薬物／デバイス２５５－ｐｓが、各薬物／デバイスクラス３３７－ｐから選択され得る。いくつかの実施形態では、暗号化されたＥＨＲサブブロック２８０－２。各暗号化されたＥＨＲサブブロック２８０－２は、指定された受信側エンティティによって復号化され得る。暗号化されたサブブロック２８０－２内の情報は、サブブロック２８０（例えば、図２のもの）と同様であり得る。

【0137】

７４５において、支払人１４０及び／又はＰＢＭ１５０によって承認されると、プラットフォーム（例えば、プライベート許可型ブロックチェーンプラットフォーム）は、トランザクションＩＤ６９５と、トランザクション確認を示すトランザクションタイプとを、トランザクションに関連付けられたエンティティに送信し得る。確認を受信すると、各エンティティは、そのそれぞれの暗号化されたレコード（例えば、ＨＣＰ１２０に対するＥＨＲ２００、ＰＭＤＰ１２０に対するＤＩＲレコード、ＰＢＭ１４０からのＰＢＲ、薬局１６０に対するＰＰＲ、及び支払人１４０に対するＨＴＲ）を、ローカルブロックチェーンに追加し得る。加えて、上記の暗号化されたレコードのうちの２つ又は３つ以上が、多次元ブロックチェーン（図７Ａには示さず）内の多次元ブロック７５０の一部を形成し得る。多次元ブロック内の暗号化されたブロック（例えば、ＨＣＰ１２０に対するＥＨＲ２００、ＰＭＤＰ１２０に対するＤＩＲ３００、ＰＢＭ１４０に対するＰＢＲ４００、薬局１６０に対するＰＰＲ５００、及び支払人１４０に対するＨＴＲ６００）は、ブロックを暗号化するエンティティによって復号され得、他のエンティティによって復号されない場合がある。したがって、各ブロックは、トランザクションのエンティティの閲覧を表すが、各ブロックは、トランザクション最終承認時に他の関連エンティティからの承認された情報を（受信されたサブブロックを介して）含むので、閲覧は、同じトランザクションに関する他のエンティティの閲覧と一致する。加えて、多次元ブロックチェーン内の各多次元ブロックは、トランザクションの当事者であるエンティティによって見られるような最終承認されたトランザクションのスナップショットを表すが、特定のエンティティ（例えば、図７ＡのＨＣＰ１２０、ＰＭＤＰ１２０、ＰＢＭ１４０、薬局１６０、又は支払人１４０のうちの１つ）によって所有され暗号化される任意の単一の暗号化されたブロック（例えば、図７ＡのそれぞれＥＨＲ２００、ＤＩＲ３００、ＰＢＲ４００、ＰＰＲ５００、又はＨＴＲ６００のうちの１つ）内の情報は、非所有エンティティから保護される。図７Ａに示すように、多次元ブロック７５０は、立方体（多次元ボリューム）として視覚化され、立方体の各面は、トランザクションの当事者であるエンティティに関連付けられたブロックを表す。トランザクションがＰＢＭ１５０及び／又は支払人１４０及び／又は別のエンティティによって承認されない場合、ステップ７１５～７４０のうちの１つ又は２つ以上が繰り返され得る。

【0138】

７５５において、ＰＭＤＰ１３０又はプラットフォームは、患者１７０に、（例えば、患者に関連付けられたモバイルコンピューティングデバイス上のアプリケーションを介して）支払い支援情報を送信し得る。支払い支援情報は、電子クレジット、コード、又は患者の自己負担コストの一部又は全てをカバーするために使用され得る任意の他の支払いタイプ（例えば、仮想デビット／クレジットカード、物理的デビット又はクレジットカード等）の形態をとり得る（例えば、処方における１つ１つ又は２つ以上の特定の薬物／デバイス２５５－ｐｓ及び／又は処方全体について）。

【0139】

７６０において、薬局１６０は、患者１７０に、（例えば、アプリケーション及び／又は安全なテキストメッセージ、安全な電子メールなどの任意の他の許容可能な通信を介して）処方の受領及び／又は利用可能性を示す処方確認を送信する。いくつかの実施形態では、（例えば、直接、オンライン等で）処方を取得するとき、患者１７０は、自己負担を低減するために支払い支援情報を提示し得る

【0140】

図７Ｂは、ヘルスケアシステムのセキュリティ及び相互運用性を容易にするための例示的なプラットフォームに関連付けられたエンティティ及びレイヤを描写する。いくつかの実施形態では、様々なエンティティＨＣＰ１２０、ＰＭＤＰ１３０、支払人１４０等は、許可型ブロックチェーンプラットフォームの部分を形成し得る。許可型ブロックチェーンプラットフォームでは、信頼されたエンティティが、プラットフォームを形成し、他の信頼されたエンティティを誘って、ネットワークに参加し得る。いくつかの実施形態では、許可型ブロックチェーンプラットフォームはまた、（例えば、招待された、かつ／及び認可されたエンティティに対して）プライベートであり得る。いくつかの実施形態では、許可型ブロックチェーンプラットフォームは、多次元ブロックチェーンをサポートし得る。多次元ブロックチェーンへのアクセス及びブロックの追加に関連するルール、エンティティ間のコントラクト（例えば、スマートコントラクト）を判定するためのプログラムコード、（例えば患者１７０の代理として）プラットフォーム機能を活用するアプリケーション、更新の検証等は、許可型ブロックチェーンプラットフォームに関連付けられたエンティティによって判定及び／又は認可され得る。

【0141】

いくつかの実施形態では、許可型ブロックチェーンプラットフォームは、クラウドベースシステムの形態をとり得る。クラウドベースシステムは、ネットワーク（例えば、インターネット）上で利用可能にされ得るインフラストラクチャ、アプリケーション、サービス、及び／又は他のリソース（ハードウェアリソースを含む）を指す。クラウドベースシステムは、基盤となるハードウェア及びソフトウェアリソースに基づき得、パブリック型（例えば、料金方式であらゆる場所に対して利用可能である）、プライベート型（例えば、組織に限定される）、又はハイブリッド型（パブリック型及びプライベート型クラウドのいくつかの組み合わせを使用する）であり得る。いくつかの実施形態では、プラットフォームに関連付けられたこれらのエンティティは、サーバ（ハードウェア及び／又はソフトウェア）によって表され得、それらのサーバは、場合によっては、クラウドベースであり得る。例えば、ＨＣＰ１２０、ＰＭＤＰ１３０、及び／又は支払人１４０は、サーバで実行されるエージェントを含み得、かつ／又は仮想マシン（virtual machine、ＶＭ）を含むクラウドベースプラットフォーム上で実行されるエージェントを含み得る。

【0142】

いくつかの実施形態では、許可型ブロックチェーンプラットフォームによって与えられる機能へのアクセスは、プラットフォームに関連付けられたレイヤ又はＡＰＩを介して容易にされ得る。例えば、患者１７０及び／又は患者の代理として振る舞う別の認可されたエンティティ（例えば、ＰＭＤＰ１３０によって提供される支払い支援プログラムへのアクセスを容易にするエンティティ）は、（ａ）患者基準２９７に基づく患者１７０についての患者選択及び（例えば、図７Ａのサブブロック２８０－１内のデータによって示されるような）最初の処方に関連付けられた関連コストメトリックの決定、及び（ｂ患者１７０への支払い支援の送達と併せた（例えば、図７Ａのサブブロック２８０－２内のデータによって示されるような）処方確定を容易にするために、クラウドベースの許可型ブロックチェーンプラットフォームと対話するモバイルアプリケーション（例えば、スマートフォン又は他のモバイルコンピューティングデバイス上で実行される）を提供し得る。

【0143】

図７Ｂに示すように、多次元ブロック７５０は、ＥＨＲ情報ブロック２００、ＤＩＲ情報ブロック３００、ＰＢＲ情報ブロック４００、ＰＰＲ情報ブロック５００、及びＨＴＲ情報ブロック６００を含む。いくつかの実施形態において、多次元ブロック７５０は、多次元ブロックチェーンの一部を形成し得る。多次元ブロック７５０において、ＥＨＲ情報ブロック２００、ＤＩＲ情報ブロック３００、ＰＢＲ情報ブロック４００、ＰＰＲ情報ブロック５００、及びＨＴＲ情報ブロック６００は、それぞれ、ＨＣＰ１２０、ＰＭＤＰ１３０、ＰＢＭ１５０、薬局１６０、及び支払人１４０によって暗号化され復号可能であり得る。

【0144】

更に、ＥＨＲ情報ブロック２００、ＤＩＲ情報ブロック３００、ＰＢＲ情報ブロック４００、ＰＰＲ情報ブロック５００、及びＨＴＲ情報ブロック６００は、それぞれ、ＥＨＲブロックチェーン７７２、ＤＩＲブロックチェーン７７３、ＰＢＲブロックチェーン７６４、ＰＰＲブロックチェーン７７５、及びＨＴＲブロックチェーン７６６内のブロックを形成し得る。図７Ｂに示すように、ＥＨＲブロックチェーン７７２、ＤＩＲブロックチェーン７７３、ＰＢＲブロックチェーン７６４、ＰＰＲブロックチェーン７７５、及びＨＴＲブロックチェーン７６６は、それぞれ、ＨＣＰ１２０、ＰＭＤＰ１３０、ＰＢＭ１５０、薬局１６０、及び支払人１４０によって所有され、ローカルに維持され得る。図７Ｂはまた、サブブロック２８０（ＥＨＲブロック２００の一部を形成する）、サブブロック３８０及び３９０（ＤＩＲブロック３００の一部を形成する）、並びにサブブロック４８０（ＰＢＲブロック４００の一部を形成する）も描写する。上で概説したように、サブロック内の情報は、トランザクション最終承認前にトランザクションに関連付けられたエンティティのうちのいくつかの間で共有されている場合があり、（トランザクション最終承認の時点で）多次元ブロック７５０の一部を形成する複数のブロックにわたって一貫し得る。いくつかの実施形態では、情報ブロック２００、３００、４００、５００及び／又は６００に関連付けられた各フィールドは、一意のグローバルフィールドｉｄを有し得、そのｉｄは、フィールドに関連する情報がエンティティ間で共有されている場合、そのフィールドを、多次元ブロックチェーンシステム内で、かつ／又は関連するエンティティに対して一意に識別し得る。多次元ブロックは、データ及びタイムスタンプを含み得る。タイムスタンプは、多次元ブロックが（完了されたときに）リンクされる順番を決定し得る。

【0145】

図７Ｂに示すように、ＨＣＰ１２０、ＰＭＤＰ１３０、ＰＢＭ１５０、薬局１６０、及び支払人１４０は、認証レイヤ７７０とインタラクトし得る。認証レイヤ７７０は、許可型ブロックチェーンプラットフォームによって提供される機能を使用する（又は使用をリクエストする）システムエンティティ及び／又はアプリケーション（例えば、モバイルアプリケーション）の識別及び管理（追加、登録、認可、及び削除）のための機能を含み得る。加えて、認証レイヤは、（ａ）多次元ブロックチェーンに関与する動作（新たなブロックを追加すること、リンクを作成すること、等）、（ｂ）トランザクションタイプに関与する動作（例えば、エンティティが特定のトランザクションタイプを開始できるかどうか又は特定のトランザクションタイプに参加できるかどうか）等に関連する許可を検証するための機能を含み得る。認証レイヤ７７０は、トランザクションの順序を決定し、多次元ブロック７５０に関連するトランザクションのセットの正当性を検証する機能を含み得る合意レイヤ７８０とインタラクトし得る。

【0146】

いくつかの実施形態では、合意レイヤ７８０は、多次元ブロックを構成するトランザクションの正当性を確認し得る。トランザクション最終承認の時点で、合意レイヤ７８０によって適用される合意技術は、多次元ブロックを構成するトランザクション（エンティティ間の共有データを含む）の正当性を確認し得る。いくつかの実施形態では、ビザンチンフォールトトレランス（Byzantine Fault Tolerance、ＢＦＴ）などの合意技術、又は冗長ＢＦＴ、高速ビザンチン合意、動的クォーラムなどのその変形、又は何らかの他の投票ベースの合意技術が、多次元ブロック７５０がコンポーネントブロック（例えば、ＥＨＲ情報ブロック２００、ＤＩＲ情報ブロック３００、ＰＢＲ情報ブロック４００、ＰＰＲ情報ブロック５００、及びＨＴＲ情報ブロック６００）を使用して形成され得るかどうかを決定するために使用され得る。認可されたエンティティ（例えば、支払人１４０又はトランザクション／トランザクションタイプに対して指定された権限のあるエンティティ）、又は何らかの特定の数（例えば、全て又は過半数）のエンティティがトランザクション又はブロックを検証したときに、合意が達成される。合意又はトランザクション検証の決定は、トランザクションタイプに応じて変動し得る。

【0147】

そのトランザクションが合意技術によって正しいものと確認された場合、ロック解除された多次元ブロック７５０の第１のインスタンスが形成され得る。図７Ｂに示すように、ロック解除された多次元ブロック７５０は、トランザクションが最終承認されたときにロックされ、多次元ブロックに追加され得る。いくつかの実施形態では、多次元ブロック７５０の一部を形成するブロック（例えば、ＥＨＲ情報ブロック２００、ＤＩＲ情報ブロック３００、ＰＢＲ情報ブロック４００、ＰＰＲ情報ブロック５００、及びＨＴＲ情報ブロック６００）はまた、トランザクション最終承認時及び多次元ブロック７５０のロック時に、それぞれのローカルブロックチェーン（例えば、それぞれＥＨＲブロックチェーン７７２、ＤＩＲブロックチェーン７７３、ＰＢＲブロックチェーン７６４、ＰＰＲブロックチェーン７７５、及びＨＴＲブロックチェーン７６６）にブロックとして追加され得る。したがって、ローカルに記憶されたブロック（例えば、ＥＨＲ情報ブロック２００、ＤＩＲ情報ブロック３００、ＰＢＲ情報ブロック４００、ＰＰＲ情報ブロック５００、及びＨＴＲ情報ブロック６００）内の情報もまた、多次元ブロック７５０内の情報と一致する。

【0148】

これに反して、例えば、サブブロック４８０内で患者ＩＤ４２５と識別された患者が患者ＩＤ（例えば、サブブロック２８０内で）と一致しない場合、そのトランザクションは、正しくないと見なされ、ブロック追加リクエストは、拒否され得る。いくつかの実施形態では、プラットフォーム、又は各エンティティは、トレーサビリティー及びデバッギングのために拒否されたトランザクションのログを維持し得る。このログは、トランザクション拒否に関連付けられた理由及びコードを示すことができる。

【0149】

いくつかの実施形態では、合意レイヤ７８０は、合意技術を適用し得、スマートコントラクトレイヤ７９０とインタラクトして、トランザクションの正当性及び／又は妥当性を確立し、更なる動作を開始し得る。スマートコントラクトレイヤ７９０は、ブロックチェーンに関連するロジックを実装するプログラムコードを含み得る。例えば、多次元ブロックチェーンに関連付けられた「スマートコントラクト」プログラムコードが、トランザクションリクエストを処理し、プログラムロジックに基づいてトランザクションの妥当性を判定し得る。このロジックは、ブロックチェーンに関連するトランザクションについてのエンティティによって合意されたルールに左右され得る。例えば、スマートコントラクトレイヤ７９０は、患者に処方された２つ又はそれ以上の薬物間の不適合性により、トランザクションを（例えば、ＨＣＰ１２０から）拒否し得る。スマートコントラクトは、検証時間に、並びにブロックがロック及び／又はコミットされる前のコミット時間に動作し得る。いくつかの実施形態では、スマートコントラクトレイヤ７９０は、データ共有、トランザクション等に関係して、２つ又はそれ以上のエンティティ間のルール又は合意を符号化し得、これらは、エンティティ間の実世界のコントラクトに基づき得る。いくつかの実施形態では、従来のブロックチェーン（例えば、ＥＨＲブロックチェーン７７２、ＤＩＲブロックチェーン７７３、ＰＢＲブロックチェーン７６４、ＰＰＲブロックチェーン７７５、又はＨＴＲブロックチェーン７６６のうちの１つ）上の各更新は、プラットフォームに関連付けられたスマートコントラクトプログラムコードによって検証され得る。このスマートコントラクトプログラムコードは、データ共有、認証、決済等に関連するエンティティ間の合意を反映させ得る。スマートコントラクトレイヤは、手動での関与を行うことなく、エンティティ間のインタラクションを容易にする自動ツールと見なされ得る。いくつかの実施形態では、スマートコントラクトレイヤは、１つ又は２つ以上のコントラクトに関連付けられたルールに基づいて、それらのルールが満たされたときに、動作を開始し得る。多次元ブロックチェーンに対する各更新、及び／若しくは時間の経過、並びに／又は他のイベント及び／若しくはコントラクトに関連する特定のリクエスト（例えば、コントラクトＩＤによって識別される）が、スマートコントラクトレイヤによる動作を起動し得る。

【0150】

更新されたレコード（例えば、更新されたレコード５２０及び更新されたレコード５４０）のリンクは、エンティティ（例えば、ＨＣＰ１２０及び支払人１４０）によって合意された事前定義されたルールに基づいて実行され得る。いくつかの実施形態では、ブロック（例えば、更新されたブロック５２０及び更新されたブロック５４０）のリンクは、多次元ブロックチェーンに関連付けられたスマートコントラクトに基づいて実行され得る。リンク後、更新されたブロック５２０及び更新されたブロック５４０は、再ハッシュされ得る。上で概説したように、このリンクにより、エンティティが、別のエンティティにより維持されたブロックチェーン内の情報と、そのブロックチェーン内の情報との相関をとることを可能にし得る。加えて、それらのエンティティは、そのエンティティによって維持された特定のブロック内の情報に関連付けられたトランザクション又は複数のトランザクションを判定することが可能であり得る。したがって、２つ又はそれ以上のエンティティが、異なるブロックチェーン内のブロックに関連付けられたトランザクションの整合性のある一貫した閲覧を有し得る。形成プロセス中、多次元ブロック７５０は、（少なくとも最初は）完全に形成されていない（又は進行中の多次元ブロックである）場合があり、したがって、他のエンティティから受信されたブロックは、別の次元を追加することによって、現在進行中の（完全に形成されていない）多次元ブロックを変換し得る。例えば、完了したＨＴＲ２００（ＨＣＰ１２０からの処方を有する）は、次元として、現在進行中の多次元ブロックに追加され得る。次いで、進行中の多次元ブロックに別の次元、例えば、ＰＰＲ５００を有する次元（処方情報を有する）が追加され得る。プロセスは、多次元ブロックが完全に形成される（例えば、トランザクションに対する全ての関連当事者からの次元を含む）まで継続し得る。

【0151】

多次元ブロック（及びそのコンポーネントレコード）は、更なる修正を防止し、一貫性のある閲覧を保証するために、トランザクションの最終承認時にロックされ得る。その後の任意の修正により、新たな多次元ブロックが多次元ブロックチェーンに追加される結果となり得る。例えば、新たな多次元ブロックが、単一次元のデータレコードに対する更新で形成され得、一方では、他の次元に関連付けられた実質的な情報が変化しないままであり得る。例えば、患者に処方された薬物に関連付けられた薬物関連情報（例えば、新たな禁忌）は、他の記録を更新することなく、新たな多次元ブロック内で（例えば、ＰＭＤＰ１３０によって）更新され得る。

【0152】

多次元ブロックは、コンポーネントデータレコード（例えば、ＥＨＲ２００、ＤＩＲレコード３００、ＰＢＲ４００、ＰＰＲ５００、及びＨＴＲ６００）を含む多次元ブロックチェーンに関連付けられたマークル木の形態をとり得る。先に概説したように、データレコードはまた、異なる個々のブロックチェーンに関連付けられ得る。

【0153】

したがって、異なる個々のブロックチェーン（７７２、７７３、７６４、７７５、及び７６６）内の個々のレコードの暗号ハッシュ（例えば、それぞれ、ＥＨＲ２００、ＤＩＲレコード３００、ＰＢＲ４００、ＰＰＲ５００、及びＨＴＲ６００の別個の暗号ハッシュ（又は「ハッシュ」））は、エンティティによって所有されるレコードが他のエンティティに復号可能又は可視でないように、異なる暗号ハッシュ関数を使用して取得され得る。別個の暗号関数（例えば、許可型ブロックチェーンプラットフォームに関連付けられたエンティティに既知であり得る）が、レコードの組み合わせの暗号ハッシュを取得するために使用され得、それにより、トップハッシュが多次元ブロックに全体として関連付けられる。いくつかの実施形態では、各多次元ブロックは、タイムスタンプを有するブロックヘッダ、トップハッシュ、先行ブロックに関連した情報、マークル木のルートへのポインタ、及び他の適切な情報を含み得る。ハッシュ基準は、プライベート許可型ブロックチェーンプラットフォーム及び／又はローカル（エンティティ固有）アドレス上の、ユニフォームリソースロケータ（uniform resource locator、ＵＲＬ）の形態をとり得る。

【0154】

図７Ｂは、コミットされロックされた多次元ブロック７５０を示し、そこでは、サブブロック４８０、２８０、３８０、及び３９０からの情報が、対応する認可された関連エンティティ間で共有されている。加えて、多次元ブロック７５０は、個々のコンポーネントブロック間のリンケージを含む。多次元ブロック７５０は、ある時点で、部分的に、トランザクションの全体論的な視界を表すことができ、その理由は、その多次元ブロックが薬物（投与量、効果等）、患者（病状、治療、効果、等）、及びその時点でのコストに関連付けられた実世界の肉体的な状態を含み得るからである。また、多次元ブロック７５０は、ブロックチェーン内で先行ブロックへのリンクを含むこともできる。検証及び最終承認された多次元ブロック７５０は、最終承認されたデータレコード２００、３００、４００、５００及び６００を含み得、そのデータレコートは、対応する異なるローカルブロックチェーン７７２、７７３、７６４、７７５、及び７６６内の、最終承認された情報ブロック２００、３００、４００、５００及び６００にそれぞれ対応し得る。

【0155】

図８は、患者治療選択と治療コストの透明性とを促進しながらヘルスケア情報セキュリティ及び相互運用性を促進するための、例示的な方法８００のフローチャートを示す。いくつかの実施形態では、方法８００は、多次元ブロックチェーンを使用し得、それは、システム内に個々のエンティティによって維持される異なるブロックチェーンに基づき得る。いくつかの実施形態では、方法８００は、（少なくとも部分的に）プライベート許可型ブロックチェーンプラットフォーム上で実行され得、それは、場合によっては、クラウドベースシステムの形態をとり得る。方法８００はまた、プロセッサ、コンピュータ、又は分散コンピューティングシステムなどのコンピュータのネットワーク、アプリケーションサーバを含むサーバ（ハードウェア及びソフトウェア）、モバイルコンピューティングデバイス（例えば、スマートフォン、スマートウェアラブルデバイス、ハンドヘルドコンピュータ、タブレット、ラップトップ等）、並びにクラウドベースのシステムによって実行され得る。

【0156】

いくつかの実施形態では、方法８００は、第１のエンティティで実行され得る。例えば、第１のエンティティは、少なくとも１つのサーバ、又はＰＭＤＰ１３０などの医薬品提供者若しくは医療デバイス提供者のうちの少なくとも１つに関連付けられたコンピュータシステムを含み得る。いくつかの実施形態では、第１のエンティティは、１つ又は２つ以上の第２のエンティティとインタラクトし得る。第２のエンティティは、ＨＣＰ１２０、ＰＢＭ１５０、薬局１６０などのヘルスケア提供者に関連付けられた１つ又は２つ以上のサーバ若しくはコンピュータシステム、又は支払人１４０などの保険提供者、又は患者１７０を含み得る。いくつかの実施形態では、第１のエンティティ、及び１つ又は２つ以上の第２のエンティティは、分散コンピューティングシステム内にコンピューティングノードを形成し得、多次元ブロックチェーンは、許可型プライベートブロックチェーンプラットフォームなどの許可型プライベートブロックチェーンプラットフォームの部分を形成し得る。

【0157】

いくつかの実施形態では、方法７００は、第１のエンティティなどのエンティティがトランザクション（例えば、トランザクションＩＤ及び又はトランザクションタイプを有する）を開始してローカルに維持されたブロックチェーンにブロックを追加したときに、呼び出され得る。ローカルブロックチェーンにブロックを追加することにより、１つ又は２つ以上の他のエンティティからの入力を呼び出し得、許可型プライベートブロックチェーンプラットフォームは、方法８００を呼び出し得る。

【0158】

いくつかの実施形態では、ステップ８１０において、第１のエンティティは、第１のエンティティによって復号可能な、少なくとも１つの暗号化された第１の電子健康レコード（ＥＨＲ）サブブロック（例えば、サブブロック２８０－１）を受信し得、少なくとも１つのＥＨＲサブブロックは、患者及び１つ又は２つ以上の第１の治療（薬物／デバイス（第１の治療）２５５－ｐ、１．≦ｐ≦Ｐを伴う処方２５０）に関する、患者医療保険適用範囲情報を含む。例えば、１つ又は２つ以上の第１の治療は、薬物Ｄ１、Ｄ２、Ｄ３、及びＤ４を含み得る。

【0159】

ステップ８２０において、第１のエンティティは、第１のＥＨＲサブブロックに応答して、少なくとも１つの対応する第２のエンティティ（例えば、ＨＣＰ１２０）によって復号可能な、少なくとも１つの暗号化された第１のデバイス薬物情報（ＤＩＲ）サブブロック（例えば、ＤＩＲサブブロック３９０）を送信し得、少なくとも１つの第１のＤＩＲサブブロックは、１つ又は２つ以上の第１の治療（２５５～ｐ）の各々について、対応する第１の治療クラス（３３７～ｐ）と、各々が対応する第１の治療クラスに関連付けられた１つ又は２つ以上の対応する第１の治療クラスメンバ（３０２－ｐｄ、１≦ｄ≦Ｄ＿ｐ）と、各第１の治療クラスメンバ（３０２－ｐｄ）について、対応する第１の治療クラスメンバコスト情報（３９５、３９７－ｐｄ）と、を含む。

【0160】

例えば、第１の治療クラスは、薬物Ｄ１、Ｄ２、Ｄ３、及びＤ４にそれぞれ対応する、クラスＣ１、Ｃ２、Ｃ３及びＣ４を含み得る。更に、各クラスは、以下に概説するようなメンバ、すなわち、Ｃ１＝｛Ｄ１１，Ｄ１２｝、Ｃ２＝｛Ｄ２１｝、Ｃ３＝｛Ｄ３１，Ｄ３２，Ｄ３３，Ｄ３４｝、及びＣ４＝｛Ｄ４１，Ｄ４２，Ｄ４３｝を含み得、式中、Ｄ１∈Ｃ１、Ｄ２∈Ｃ２、Ｄ３∈Ｃ３、及びＤ４∈Ｃ４である。コスト情報は、各クラスメンバに対して（例えば、コスト内訳３９７－ｐｄにおけるように個々に、かつコストメトリック３９５におけるように総計で）提供され得る。

【0161】

ステップ８３０において、第１のエンティティは、第１のＤＩＲサブブロックに応答して、第１のエンティティによって復号可能な暗号化された第２のＥＨＲサブブロック（例えば、サブブロック２８０－２）を受信し得、第２のＥＨＲサブブロックは、１つ又は２つ以上の第２の治療（例えば、治療３０２－ｐｄから選択される治療２５５－ｐｓ）を含み、１つ又は２つ以上の第２の治療（２５５－ｐｓ）の各々は、対応する第１の治療（３０２－ｐｄ）に関連付けられ、各第２の治療（２５５－ｐｓ）は、対応する第１の治療（２５５－ｐ）に関連付けられた対応する第１の治療クラスメンバ（３３７－ｐｄ）から選択される。例えば、第２の治療は、それぞれクラスＣ１、Ｃ２、Ｃ３、及びＣ４から選択される第２の治療Ｄ１２、Ｄ２１、Ｄ３１、及びＤ４３を含み得、第２の治療Ｄ１２、Ｄ２１、Ｄ３１、及びＤ４３は、第１の治療（例えば、最初の処方）における対応する第１の治療クラスメンバ（それぞれＤ１、Ｄ２、Ｄ３、及びＤ４）と（例えば、それぞれクラスＣ１、Ｃ２、Ｃ３及びＣ４を介して）関連付けられる。いくつかの実施形態では、第２のＥＨＲブロックにおける１つ又は２つ以上の第２の治療は、患者固有のコストメトリックに基づき得る。

【0162】

ブロック８４０において、第１のエンティティは、多次元ブロックチェーンを拡張し得、多次元ブロックチェーンは、１つ又は２つ以上の第２の治療に関連付けられた情報を含むＤＩＲブロック（例えば、ＤＩＲブロック３００）と、第２のＥＨＲサブブロック（例えば、サブブロック２８０－２）に関連付けられた情報を含むＥＨＲブロック（例えば、ＥＨＲブロック２００）と、トランザクションブロック（例えば、ＨＴＲ６００）とをリンクすることによって形成される多次元ブロック（例えば、多次元ブロック７５０）で拡張される。いくつかの実施形態では、トランザクションブロックは、指定された患者コストでの指定された場所における第２の治療のための処方を含み得る。

【0163】

いくつかの実施形態では、（例えば、ステップ８１０において）第１のＥＨＲサブブロックを受信すると、第１のエンティティは、１つ又は２つ以上の第１の治療（２５５－ｐ、例えばＤ１、Ｄ２、Ｄ３、及びＤ４）の各々について、対応する第１の治療クラス（３３７－ｐ、例えばそれぞれクラスＣ１、Ｃ２、Ｃ３及びＣ４）を決定し得、各対応する第１の治療クラスは、１つ又は２つ以上の対応する第１の治療クラスメンバ（３０２－ｐｄ、それぞれ少なくともＤ１、Ｄ２、Ｄ３及びＤ４を含むＣ１、Ｃ２、Ｃ３及びＣ４のメンバ）を含む。更に、第１のエンティティは、各対応する第１の治療クラス（３３７－ｐ、例えばＣ１、Ｃ２、Ｃ３、及びＣ４）について、第１の治療クラスに関連付けられた１つ又は２つ以上の対応する第１の治療クラスメンバに対する１つ又は２つ以上の対応する第１の治療クラスメンバコスト情報（（例えば、Ｃ１、Ｃ２、Ｃ３、及びＣ４内の各薬物に対するコスト内訳３９７－ｐｄのように個々に、かつ／又はコストメトリック３９５のように総計で）を決定し得る。

【0164】

いくつかの実施形態では、第１のＥＨＲサブブロック（例えば、２８０－１）は、患者固有パラメータ（例えば、患者基準２９７を含む）を含み得、少なくとも１つの治療クラスは、患者固有パラメータに基づいて決定される。患者固有パラメータは、患者の併存疾患情報、投与経路情報（３３５－ｐｄ）、安全性（３３０－ｐｄ）及び有効性（３３７－ｐｄ）情報、並びに／又は患者位置情報のうちの１つ又は２つ以上を含み得る。

【0165】

いくつかの実施形態では、各第１の治療（２５５－ｐ）について、対応する第１の治療クラス（３３７－ｐ）及び各治療クラスメンバ（３０２－ｐｄ）に対する対応する第１の治療クラスメンバコスト情報（３９５、３９７－ｐｄ）は、患者医療保険適用範囲情報に基づいて決定され得る。例えば、コスト情報は、（ａ）患者位置の指定された距離内に位置する提供者（例えば薬局１６０）であって、患者についての位置情報が第１のＥＨＲサブブロック（例えば、保険適用範囲関連情報２７２、並びに／又はサブブロック２８２及び／若しくは２８４内の情報を含み得るサブブロック２８０内の患者プロファイル２３０の一部分）に含まれる、提供者、及び／又は（ｂ）対応する治療単位（（例えば、用量及び／又は持続時間）についての各対応する第１の治療クラスメンバ（３０２－ｐｄ）に対応する、患者固有の自己負担コスト、及び／又は（ｃ）典型的な治療期間についての、各対応する第１の治療クラスメンバ（３０２－ｐｄ）に対応する患者固有の推定される総自己負担コスト（３９２－ｐｄ）、及び／又は（ｄ）患者に関連付けられた医療保険適用範囲プランの残りの期間（例えば、現在の患者保険適用範囲が終了する日まで）についての、各対応する第１の治療クラスメンバ（３０２－ｐｄ）に対応する患者固有の推定される総自己負担コスト、のうちの１つ又は２つ以上に更に基づいて決定され得る。

【0166】

いくつかの実施形態では、（例えば、ステップ８３０において）第２のＥＨＲサブブロックを受信すると、第１のエンティティは、１つ又は２つ以上の第２の治療のうちの少なくとも１つについての支払い支援情報を決定し得、患者に、トランザクション確認を伴う支払い支援情報を患者に送信し得る。いくつかの実施形態では、（例えば、ステップ８３０において）第２のＥＨＲサブブロックを受信すると、第１のエンティティは、患者に、支払い支援情報とともに、１つ又は２つ以上の第２の治療のための少なくとも１つの処方を含むトランザクション確認を送信し得る。

【0167】

支払い支援情報は、電子クレジット、コード、又は患者の自己負担コストの一部又は全てをカバーするために使用され得る任意の他の支払いタイプ（例えば、仮想デビット／クレジットカード、物理的デビット又はクレジットカード等）の形態をとり得る（例えば、処方における１つ又は２つ以上の特定の薬物／デバイス２５５－ｐｓ及び／又は処方全体について）。したがって、場合によっては、支払い支援情報は、患者１７０及び／又は薬局１６０への実際の金銭支払を含み得る。例えば、場合によっては、支払い支援は、支払い支援が使用され得る薬物及び／又は薬局（又は薬局会社）を指定し得る。

【0168】

図９は、ヘルスケア情報セキュリティを維持し、複数のエンティティ間の相互運用性を容易にしながら、ヘルスケア保険選択及びコスト決定を容易にするためのプロセスフロー９００を示す流れ図を示す。いくつかの実施形態では、プロセスフロー９００の部分は、加入しているエンティティ及び／又は認可されたエンティティに対して利用可能にされ得る、許可型ブロックチェーンプラットフォーム上で行われ得る。いくつかの実施形態では、フロー７００の一部又は全ては、エンティティに関連付けられたコンピューティングデバイス上で実行されるアプリケーションを使用して実装され得る。フロー図９００では、説明を容易にするために、一部のルーチンメッセージが示されていない。

【0169】

一例として、患者１７０は、モバイルコンピューティングデバイス（例えば、スマートフォン、タブレット、ラップトップ等）上で実行されるアプリケーションを使用して、トランザクションを開始し得る。いくつかの実施形態では、アプリケーションは、許可型ブロックチェーンプラットフォームに関連付けられたエンティティによって提供及び／又は認可され得る。例えば、アプリケーション（例えば、患者１７０に関連付けられたモバイルコンピューティングデバイス上で実行される）は、第１のエンティティ（例えば、ＨＣＰ１２０、ＰＭＤＰ１３０、及び／又は患者アクセスプログラム（図９には示さず））によって提供されている場合があり、アプリケーションプログラミングインターフェース（ＡＰＩ）及び／又は他のネットワーク並びに通信プロトコルを使用して、第１のエンティティと通信し得る。いくつかの実施形態では、患者１７０は、（図９に示すような）ＰＭＤＰ１３０、又は許可型ブロックチェーンプラットフォームに関連付けられる患者支援プログラム、患者アクセスプログラム等のエンティティと通信するアプリケーションを呼び出し得る。したがって、いくつかの実施形態では、アプリケーションは、エンティティ（例えば、ＰＭＤＰ１３０）の代理として振る舞うことができ、アプリケーションに関連する有効かつ認可されたトランザクション、通信等は、あたかもエンティティ（例えば、ＰＭＤＰ１３０）がトランザクションを実行しているかのように見え得るか、又はエンティティ（例えば、ＰＭＤＰ１３０）によって（認可、検証、及び適切な処理／符号化の後に）転送され得る。

【0170】

以下の説明のために、ＰＭＤＰ１３０が例として使用されてきた。しかしながら、プロセスフロー９００はまた、患者支援プログラム及び／又は患者アクセスプログラムなどの他のエンティティによって実施され得、これらは、患者１７０がヘルスケア保険適用範囲を取得すること及び／又は患者支援の資格を得ることを支援し得る。上で概説したように、アプリケーション（例えば、患者１７０によって使用される）は、エンティティの代理として患者１７０に対して透過的に振る舞い得る。したがって、場合によっては、図９において患者１７０によって実行されているものとして示される動作は、別のエンティティ（例えば、ＰＭＤＰ１３０）を通して行われ得、かつ／又は別のエンティティに帰属させられ得る。いくつかの実施形態では、いくつかの保険プランの選択肢を提供する個人エンティティは、適切な保険適用範囲の選択を容易にするために、プロセスフロー９００を実装するアプリケーションを潜在的加入者（例えば、図９の患者１７０として示される）に提供し得る。

【0171】

多くの状況において、患者は、多くの場合、治療（薬物、デバイス、及び／又は処置）を反復的に必要とするか、又は使用する。本明細書で使用される再発治療という用語は、長期間（例えば、数週間、数ヶ月、又は数年）にわたって存在する（進行中の）、かつ／又は慢性の、かつ／又は発生する可能性がある、かつ／又は（例えば推奨される治療をしないと）再発する／現れる病状に対して、患者に処方された薬剤、デバイス、及び／又は処置を指すために使用される。例えば、様々な症状（例えば、糖尿病、血圧、心疾患、透析を必要とする腎疾患等、及び／又は他の慢性疾患）は、治療が適用又は処方される長期間を必要とし得る。これらの状況においては、薬物（例えば、薬剤）、デバイス（例えば、薬物送達デバイス）、又は治療（例えば、理学療法、透析等）が、長期間にわたって繰り返し使用及び／又は処方される場合がある。しかしながら、保険プラン選択時には、患者は典型的には、総医療費（プランのために支払われた保険料、支払われた免責額、支払われた自己負担金、支払われた共同負担額、受け取った支払い支援を差し引いたもの）が、プランの選択、及び／又は薬物／デバイスの選択によってどのように影響を受けるかについての情報を有していない。いくつかの実施形態では、プロセスフロー９００を利用し得るいくつかの開示される実施形態は、本明細書で記載されるように、適切な治療レベルを維持しながら、コストを低減するための知的なプラン選択を容易にすることができる。

【0172】

９０５において、患者１７０は、患者再発治療情報（例えば、進行中／再発ベースで患者１７０によって使用されている薬物／デバイス）及び／又は保険適用範囲関連情報２７２のうちの１つ又は２つ以上の送信を開始し得る。例えば、患者１７０は（例えばモバイルコンピューティングデバイス上のアプリケーションを使用して）、記憶された保険適用範囲関連情報２７２、及び一部の（例えば、患者１７０によって選択された）又は全ての処方に関連する記憶された処方情報が、ＰＭＤＰ１３０などのエンティティに送信される、かつ／又は（例えば、デバイスにローカルにかつ／若しくはクラウドに記憶される、及び／又はエンティティによって記憶される）ことを示し得る。一例として、患者の処方及び保険適用範囲情報を追跡及び記憶し得る患者アプリケーションは、患者１７０による認可時に、ローカル又はクラウドベースの保険適用範囲情報及び処方情報を、ＰＭＤＰ１３０に送信し得るか又は送信を開始し得る。いくつかの実施形態では、そのアプリケーションは、健康管理アプリケーションの形態をとり得、患者の処方を追跡すること、保険料の支払い／更新の期限が来たときを示すこと、支払いを行うこと、処方された治療が行われるときを示すこと、補充のリマインダを提供すること、処方／補充を自動的に再注文すること、コストを追跡すること、予約のリマインダをスケジュールし提供すること、等の１つ又は２つ以上の他の機能を含み得る。アプリケーションが保険適用範囲関連情報２７２及び処方情報をＰＭＤＰ１３０に送信した場合、イベント９１０及び９１５は発生しない場合がある。

【0173】

いくつかの実施形態では、保険適用範囲関連情報２７２及び／又は再発治療情報の送信はまた、処方データをＰＭＤＰ１３０に送信するための認可を、（例えば、支払人１４０及び／又はＰＢＭ１５０に、かつ／又は患者健康関連情報を記憶し得る１つ又は２つ以上のエンティティに）提供することによって開始され得る。例では、認可が提供され、保険適用範囲関連情報２７２及び／又は再発治療情報が１つ又は２つ以上の（支払人１４０及び／又はＰＢＭ１５０などの）外部エンティティによって提供される場合、９１０において、ＰＭＤＰ１３０は、１つ又は２つ以上の支払人１４０－ｖ（１≦ｖ≦Ｖ）及び／又はＰＢＭ１５０－ｕに、保険適用範囲関連情報２７２及び／又は再発治療情報を取得するための患者認可を求めるＨＴＲリクエストを送信し得る。（１≦ｕ≦Ｕ）。９１５において、支払人１４０－ｖ（１≦ｖ≦Ｖ）及び／又はＰＢＭ１５０－ｕ。（１≦ｕ≦Ｕ）は、患者１７０に関連するリクエストされた情報とともに（例えば、ＰＭＤＰ１３０に）応答し得る。

【0174】

ブロック９２０において、ＰＭＤＰ１３０は、患者によって使用されている再発治療を決定し得る。再発治療という用語は、保険適用期間中に長期間（例えば、数日、数週間、又は数ヶ月）にわたって発生する可能性がある、又は存在することになる病状に対して患者に処方された薬剤、デバイス、及び／又は治療を指すために使用される。再発治療は、１回の治療とは異なる（例えば、日和見的／予測困難な感染を治癒するための１回／短時間の抗生物質レジメンなどの孤立した病状の場合）。いくつかの実施形態では、ＨＴＲサブブロック内の情報を分析して、ＨＴＲサブブロックに含まれる（例えば、治療コード２４５、処方された薬物／デバイス２５５－ｐ、用量２６０－ｐ、及び持続時間２６５－ｐを介して）再発する患者治療を決定し得る。患者治療情報が（例えば、患者１７０によって使用されるアプリケーションを介して）利用可能である場合、患者治療は、アプリケーションによって提供され得、ＰＭＤＰ１３０は、提供された情報に基づいて、（例えば、ステップ９２０において）再発する患者治療を決定し得る。

【0175】

いくつかの実施形態では、９２５において、ＰＭＤＰ１３０は、利用可能なプラン情報のリクエストを健康取引所（Health Exchange、ＨＥＸ）１８０に送信し得る。ＨＥＸ１８０は、消費者向けの加入のプランを提供する任意のエンティティであり得る。例えば、ＨＥＸ１８０は、Ａｆｆｏｒｄａｂｌｅ Ｃａｒｅ Ａｃｔ（ＡＣＡ）の下でプランを提供する政府認可エンティティ、又は選択／登録のために（例えば、オープン登録期間中に）従業員に複数のプランを提供する個人雇用者と提携する部門若しくは請負業者であり得る。プラン情報のリクエストは、患者１７０に関連するＰＩＩ情報を含まない場合があり、リクエストされる情報のタイプを指定し得る。いくつかの実施形態では、プラン情報のリクエストは、患者１７０によって指定された場所においてプランを提供する支払人１４０－ｖ及びＰＢＭ１５０－ｕのリスト、並びに各提供されたプランに対するプラン識別（例えば、プランＩＤ及び／又はグループＩＤ）をリクエストし得る。場合によっては、支払人１４０－ｖ及びＰＢＭ１５０－ｕのリスト並びにプラン識別情報が、（例えば、公開された情報を介して）公的に入手可能である場合、公開された情報は、ＰＭＤＰ１３０リクエスト（９２５において）及びＨＥＸ１８０応答（９３０において）を伴わずに、その情報を取得するためにＰＭＤＰ１３０によってアクセスされ得る。

【0176】

いくつかの実施形態では、９３０において、ＨＥＸ１８０は、患者１７０によって指定された場所でプランを提供する支払人１４０－ｖ及びＰＢＭ１５０－ｕのリスト、並びに各提供されたプランについてのプラン識別（例えば、プランＩＤ及び／又はグループＩＤ）とともに応答し得る（又は代替的に、上記の情報が、上で概説したような公的に入手可能な情報を使用してＰＭＤＰ１３０によって決定され得る）。

【0177】

いくつかの実施形態では、ステップ９３３において、ＰＭＤＰ１３０は、患者１７０に関連付けられた各再発治療（薬物、デバイス及び／又は処置）２５５－ｒについて、治療クラス３３７－ｒ、及び治療クラスメンバ３０２－ｒｄを決定し得、ここで、１≦ｄ≦Ｄ＿ｒであり、Ｄ＿ｒは、治療クラス３３７－ｒ内のクラスメンバの数である。治療クラス３３７－ｒ内の薬物／デバイス３０２－ｒｄは、（ａ）同様の治療領域３６０－ｒを治療し得、かつ／又は（ｂ）同様の作用様式／作用方法３４０－ｒを有し得、かつ／又は（ｃ）同様の化学構造３５０－ｒを有し得る。加えて、治療クラス３３７－ｒ内の薬物／デバイス３０２－ｒｄはまた、投与経路３３５－ｒｄを共有し、他の患者基準２９７を満たし得る。医療処置の場合、治療クラス３３７－ｒのメンバ３０２－ｒｄは、（ａ）同様の症状を治療し得、かつ／又は（ｂ）同じ／同様の治療を（潜在的に異なる価格であっても）受けられる代替施設を（例えば、ある場所で）指定し得る。

【0178】

ステップ９３５において、ＰＭＤＰ１３０は、１つ又は２つ以上のＰＢＭ１５０－ｕ及び／又は支払人１４０－ｖに、ＤＩＲサブブロック（例えば、ブロック２８０内の治療コード２４５及び／又は他の情報を含むＤＩＲサブブロック３８０）を、プラン識別情報（例えば、プランＩＤ及び／又はグループＩＤ）とともに、価格設定及び保険適用範囲情報（例えば、治療が、（例えば、患者１７０に利用可能な）対応するプランによって保険適用されるかどうかのリクエストの一部として送信し得る。

【0179】

９４０において、いくつかの実施形態では、ＰＢＭ１５０－ｕ及び／又は支払人１４０－ｖは、各プラン（例えば、サブブロック４８０におけるような）及び／又は（例えば、処置のために）認可された提供者についての処方集情報とともに応答し得る。

【0180】

代替的に、いくつかの実施形態では。（例えば、サブブロック４８０におけるような）各プラン及び／又は（例えば、処置のための）認可された提供者についての処方集情報が公的に入手可能である（かつ／又はＨＥＸ１８０を通して入手可能である）場合、公的に入手可能な情報が使用され得、かつ／又は情報がＨＥＸ１８０から取得され得る。例えば、規則は、プラン（支払人１４０及び／又はＰＢＭ１５０）が、処方集及び他の保険適用範囲情報を公開及び更新することを要求し得、したがって、各プラン（例えば、サブブロック４８０におけるような）及び／又は（例えば、処置のために）認可された提供者についての処方集情報を判定するために、最新の公開された情報又は更新情報が使用され得る。したがって、いくつかの実施形態では、イベント９３５及び９４０は、プロセスフロー９００の一部を形成しない場合があり、ＰＭＤＰ１３０は、ステップ９３３の一部として、ステップ９３３と９４５との間の別個の中間ステップとして、かつ／又はステップ９４５の一部として、各プラン（例えば、サブブロック４８０におけるような）及び／又は（例えば、処置のために）認可された提供者についての処方集情報を判定し得る。

【0181】

いくつかの実施形態では、ステップ９４５において、ＰＭＤＰ１３０は、各プランに関連付けられた全体的な患者固有コスト情報を決定し得る。例えば、コストＣ＿ｈｓは、各プランｈに割り当てられ得、各治療クラス３３７－ｒから１つの治療３０２－ｒｓを選択することに基づき得る。例えば、（例えば、ステップ９２０で決定された）再発治療が、各治療クラス３３７－ｒ内に１つ又は２つ以上の治療を有する４つの治療クラスに関連付けられているプランｈの場合、その４つの治療クラスの各々から１つの治療３０２－ｒｓを選択して、そのプラン及び選択された治療に関連付けられた患者固有コストＣ＿ｈｓを決定し得る。一例として、

【0182】

【数1】

【0183】

いくつかの実施形態では、各プランｈにおける治療の様々な選択に対して患者固有コストＣ＿ｈｓが提供され得る。したがって、患者１７０及び／又はＨＣＰ１２０は、プラン選択の前に、プランに関連付けられた潜在的な又は可能性のあるコストを決定することが可能であり得る。支払い支援は、ＰＭＤＰ１３０によって、かつ／又は他のエンティティによって（例えば、ＡＣＡの下で保険料に対する政府によって、又は非営利団体によって、ＰＭＤＰ１３０と提携する組織／プログラムによって、かつ／又は税金割り戻し等によって）提供され得る。

【0184】

いくつかの実施形態では、情報は、以下の表１に示すようなテーブル（又はデータベース）の形態で提供され得る。テーブルは、プランｈ、選択された治療セット、コストＣ＿ｈｓ、及び各選択された治療３０２－ｒｓの提供者（例えば、薬局、場所等）に関する情報を含み得る。いくつかの実施形態では、コストＣ＿ｈｓは、治療セット内の各選択された治療３０２－ｒｓのコスト内訳（自己負担金、共同負担等）を更に含み得る。

【0185】

【表1】

【0186】

いくつかの実施形態では、９５０において、患者１７０に、コスト情報Ｃ＿ｈｓ及び他のコストメトリックが、直接又は間接的に（例えば、破線によって示されるように、ＨＥＸ１８０を介して）送信され得る。いくつかの実施形態では、患者１７０は、ＨＣＰ１２０と共有される治療及びコスト情報を共有するようＰＭＤＰ１３０を認可し得、かつ／又は患者１７０は、任意選択で、ＨＣＰ１２０と治療情報を共有及び議論し得る。

【0187】

９５５において、ＨＣＰ１２０は、必要に応じて治療セットのうちの１つを推奨し得、患者１７０は、（例えば、モバイルデバイス画面上に示されたプランを選択することによって）プラン選択を行い、その選択を確認し得る。患者１７０によって選択されたプランは、ＨＣＰ１２０によって推奨されるプラン及び／又は任意の他の利用可能なプランと同じであり得る。９５５において、確認されると、プラン選択はＨＥＸ１８０に送信され得る。

【0188】

９６０において、支払人１４０及び／又はＰＢＭ１５０によって承認されると、プラットフォーム（例えば、プライベート許可型ブロックチェーンプラットフォーム）は、トランザクション確認を、トランザクションに関連付けられたエンティティに示し得る。確認を受信すると、各エンティティは、そのそれぞれの暗号化されたレコード（例えば、ＰＢＭ１４０に対するＰＢＲ、支払人１４０に対するＨＴＲ、及び対応するＨＥＸレコード（図９には示さず））を、ローカルブロックチェーンに追加し得る。いくつかの実施形態では、認可されると、支払い支援プログラムへの参加及びそれからの給付金の支払いを容易にするために、トランザクション確認もまたＰＭＤＰ１３０に送信され得る。いくつかの実施形態では、９６０において、プラットフォーム（例えば、プライベート許可型ブロックチェーンプラットフォーム）は、プラン加入確認を患者１７０に送信することによってトランザクション確認を示し得る。加えて、上記の暗号化されたレコードのうちの２つ又は３つ以上は、多次元ブロック９６５の一部を形成し得、それによって多次元ブロックチェーンを拡張する。

【0189】

図１０Ａ及び図１０Ｂは、ヘルスケア情報セキュリティを維持しながら、ヘルスケア保険選択及びコスト決定を容易にし、複数のエンティティ間の相互運用性を容易にするための例示的な方法１０００のフローチャートを示す。いくつかの実施形態では、方法１０００は、多次元ブロックチェーンを使用し得、それは、システム内に個々のエンティティによって維持される異なるブロックチェーンに基づき得る。いくつかの実施形態では、方法１０００は、少なくとも部分的に、プライベート許可型ブロックチェーンプラットフォーム上で実行され得、それは、場合によっては、クラウドベースシステムの形態をとり得る。方法１０００はまた、プロセッサ、コンピュータ、又は分散コンピューティングシステムなどのコンピュータのネットワーク、アプリケーションサーバを含むサーバ（ハードウェア及びソフトウェア）、モバイルコンピューティングデバイス（例えば、スマートフォン、スマートウェアラブルデバイス、ハンドヘルドコンピュータ、タブレット、ラップトップ等）、並びにクラウドベースのシステムによって実行され得る。

【0190】

いくつかの実施形態では、方法１０００は、第１のエンティティで実行され得る。例えば、第１のエンティティは、ＰＭＤＰ１３０などの医薬品提供者及び／又は患者によって使用される（例えば、ＰＭＤＰ１３０又は別のエンティティによって提供される）アプリケーション（ＰＭＤＰ１３０及び／又は他のエンティティの代理として認可されたときに許可型ブロックチェーンプラットフォームによって提供される機能と対話し、それを利用され得る）のうちの少なくとも１つに関連付けられた少なくとも１つのサーバ若しくはコンピュータシステムを含み得る。いくつかの実施形態では、第１のエンティティは、１つ又は２つ以上の第２のエンティティとインタラクトし得る。第２のエンティティは、ＨＥＸ１８０などのヘルスケア取引所、ＰＢＭ１５０－ｕなどの薬局給付管理者、支払人１４０－ｖなどの保険提供者、又は患者１７０、に関連付けられた１つ又は２つ以上のサーバ若しくはコンピュータシステムを含み得る。いくつかの実施形態では、第１のエンティティ、及び１つ又は２つ以上の第２のエンティティは、分散コンピューティングシステム内にコンピューティングノードを形成し得、多次元ブロックチェーンは、許可型プライベートブロックチェーンプラットフォームの部分を形成し得る。

【0191】

いくつかの実施形態では、方法１０００は、第１のエンティティなどのエンティティがトランザクション（例えば、トランザクションＩＤ及び／又はトランザクションタイプ）を開始してローカルに維持されたブロックチェーンにブロックを追加するときに、呼び出すことができる。ローカルブロックチェーンにブロックを追加することにより、１つ又は２つ以上の他のエンティティからの入力を呼び出すことができ、許可型プライベートブロックチェーンプラットフォームは、方法１０００を呼び出すことができる。

【0192】

図１０Ａを参照すると、ステップ１０１０において、第１のエンティティ（例えば、ＰＭＤＰ１３０並びに／又はスマートフォン及び／若しくは別のエンティティなどの患者コンピューティングデバイスを実行するアプリケーション）は、第１のエンティティによって復号可能な、少なくとも１つの暗号化された第１の健康トランザクションレコード（ＨＴＲ）サブブロック（例えば、サブブロック２８０及び／又はＨＴＲ６００内の他の治療関連情報）から取得し得る。いくつかの実施形態では、ＨＴＲサブブロックは、患者認可を含むリクエストに応答して受信され得る。第１のエンティティは、ある時間期間にわたる患者についての第１の治療の第１のセットを（例えば、少なくとも１つの第１のＨＴＲサブブロック内の情報に基づいて）取得し得、各第１の治療は、第１の診断コード（例えば、診断コード２４０）及び第１の治療コード（例えば、治療コード２４５）を含む。いくつかの実施形態において、第１のＥＨＲサブブロックは、第１の（再発）治療２５５－ｐに関連付けられた治療コード２４５、処方された薬物／デバイス２５５－ｐ、用量２６０－ｐ、及び持続時間２６５－ｐを含み得る。いくつかの実施形態では、時間期間は、いくつかの以前の保険適用範囲期間を含み得、複数の支払人１４０－ｖを含み得、これにより再発及び進行中の治療の決定を容易にし得る。

【0193】

いくつかの実施形態では、第１の治療の第１のセットは、ＨＴＲサブブロックに含まれる治療コード２４５－ｐ、処方された薬物／デバイス２５５－ｐ、用量２６０－ｐ、及び持続時間２６５－ｐのうちの１つ又は２つ以上に基づいて決定され得る。第１の治療は、指定された期間にわたって処方されている場合があり、かつ／又は処方される可能性が高い、薬物、デバイス、及び／又は処置２５５－ｐなどの再発治療を含み得る。いくつかの実施形態では、（例えば、第１のエンティティによって受信された）少なくとも１つの第１のＨＴＲサブブロック内の情報を（例えば、数学的及び／又は統計的に）分析して、第１の治療の第１のセット（例えば、再発患者治療）を決定し得る。例えば、毎月の処方は、（例えば、持続時間２６５－ｐ、決定又は予測された頻度に基づいて）指定された時間期間の終了まで継続するように予測され得る。いくつかの実施形態では、予測及び／又は決定された再発治療は、患者確認の対象となり得る。いくつかの実施形態では、ローカルに記憶されたデータ（例えば、健康管理アプリケーションの一部として）は、第１の治療の第１のセットを取得するために使用され得る。

【0194】

いくつかの実施形態では、慢性又は持続性であることが知られている特定の病状（例えば、診断コード２４０によって識別可能）に関連付けられた治療は、再発治療として自動的に識別され得る。他の例では、その時間期間にわたって繰り返し行われる治療は、再発治療であると判定され得る。別の例として、治療は、提供者との特定の診断コードに対するスケジュールされた予約のパターンを示す患者のカレンダー（例えば、健康管理アプリケーションの一部として）などの追加情報に部分的に基づいて、再発であると判定され得る。アプリケーション（例えば、健康管理又は他のアプリケーション）が患者治療及び／又は予約情報を記憶する場合、再発患者治療情報は、記憶された患者治療及び／又は予約情報に基づいて決定され得る。第１の治療の第１のセットは、支払人１４０及び／又はＰＢＭ１５０ ＰＢＲ４００によって維持されるＨＴＲ６００から取得され得、これは、長期間にわたる治療の記録を含み得る。いくつかの実施形態では、患者によって（例えば、指定された何らかの時間期間にわたって）使用される複数の支払人１４０－ｖ及び／又はＰＢＭ１５０－ｕは、第１のＨＴＲサブブロック内の情報を取得するためにコンタクトされ得る。

【0195】

いくつかの実施形態では、ステップ１０１５において、第１のエンティティ（例えば、ＰＭＤＰ１３０）は、第１のセットに基づいて、（ａ）１つ又は２つ以上の第２のセットであって、各第２のセットが、対応する第２の治療を含み、各対応する第２の治療が、第１のセット内の異なる第１の治療に関連付けられている、第２のセットと、（ｂ）（例えば、意図された保険適用範囲の持続時間などの指定された時間期間にわたる）対応する再発の数とを決定し得る。再発の数は、コストを決定するために使用され得る（例えば、治療当たりのコストに、ある時間期間にわたる比例配分された又は正規化された再発の数を乗算することによって）。いくつかの実施形態では、アプリケーション（例えば、スマートフォンなどの患者コンピューティングデバイスを実行する）は、１つ又は２つ以上の第２のセット、対応する第２の治療、及び各第２の治療に対応する再発を、ＰＭＤＰ１３０から（例えば、安全なＡＰＩを介して）取得し得る。

【0196】

一例として、第１の治療のセット内の各第１の治療（２５５－ｐ）は、対応する第１の治療クラス（３３７－ｐ）に関連付けられ得る。各治療クラス（３３７－ｐ）は、１つ又は２つ以上の治療クラスメンバ（３０２－ｐｄ、１≦ｄ≦Ｄ＿ｐ）を含み得る。各第２のセットは、第１の治療クラス（３３７－ｐ）を介して異なる第１の治療（２５５－ｐ）に関連付けられた対応する第２の治療（３０２－ｐｄ）を含み得る。したがって、一例として、対応する第２のセットは、（第１の治療２５５－ｐに対応する）各治療クラス（３３７－ｐ）からの１つの治療クラスメンバ（３０２－ｐｄ）を含み得る。ステップ１０１５は、患者１７０に対して現在処方されている再発治療のセットを、利用可能な治療の同様のクラスに拡張するものとして見ることができる。

【0197】

ステップ１０２０において、患者に利用可能な利用可能な保険プラン（例えば、プランＩＤ、グループＩＤ等）のセット、及び各利用可能な保険プランについての対応する保険適用範囲関連情報（例えば、保険料、免責額、自己負担金、共同負担、処方集情報等）が、（例えば、ＰＭＤＰ１３０及び／又はスマートフォンなどの患者コンピューティングデバイスを実行するアプリケーションによって）取得され得る。利用可能な保険プラン及び保険適用範囲関連情報は、ＨＥＸ１８０、及び／又は支払人１４０－ｖ、及び／又はＰＢＭ１５０－ｕ、及び／又は雇用主から（例えば、プランが雇用主が資金提供したものである場合）、及び／又は公的に入手可能な情報から（例えば、政府又は他の公的ソースから入手可能な公開情報によって）取得され得る。利用可能な保険プランのセット及び対応する保険適用範囲関連情報は、場所（国、州、郡、都市、郵便番号）、年齢等のような、患者に関連付けられた非個人情報に基づいて（例えば、患者のＰＩＩを提供せずに）取得され得る。いくつかの実施形態では、アプリケーション（例えば、スマートフォンなどの患者コンピューティングデバイスを実行する）は、公開された情報を使用することによって、かつ／又は（例えば、ＡＰＩを介して）ＰＭＤＰ１３０から、利用可能な保険プランのセット及び対応する保険適用範囲関連情報を取得し得る。

【0198】

ステップ１０２５において、１つ又は２つ以上の利用可能な保険計画について、患者についての対応するプラン固有コスト情報が、（ａ）第２の治療の１つ又は２つ以上のセット、及び（ｂ）対応する保険適用範囲関連情報に基づいて決定され得る。いくつかの実施形態では、患者についての対応するプラン固有コスト情報は、第２のセット毎に適用可能な支払い支援を反映し得る。例えば、利用可能なプランについては、各第２のセットにおける再発治療に基づいて患者１７０についてのプラン固有コスト情報が決定され得る。いくつかの実施形態において、コスト情報は、（例えば、最も高い予測コストから最も低い予測コストに）ランク付けされ得る。いくつかの実施形態では、ステップ１０１５はスキップされ得、ブロック１０２５において、第１の治療の第１のセットに基づいて患者についてのプラン固有コスト情報が決定され、それによって、患者によって使用される既存の治療についてのプラン固有コスト推定値を提供し得る。いくつかの実施形態では、アプリケーション（例えば、患者１７０に関連付けられたスマートフォン又は他のモバイルコンピューティングデバイス上の）は、プラン固有コスト情報を決定し、患者１７０に、コスト又は他の患者基準２９７によってランク付けされ得るプランオプションのリストを提供し得る。いくつかの実施形態では、患者についてのプラン固有コスト情報は、ＰＭＤＰ１３０から（例えば、安全なＡＰＩを介して）アプリケーションによって受信され得る。

【0199】

いくつかの実施形態では、任意選択でステップ１０３０において、ＰＭＤＰ１３０によって判定されると、プラン固有コスト情報は、任意選択で、第２のエンティティ（例えば、患者１７０によって承認されたＨＣＰ１２０）に（例えば、ＤＩＲサブブロック３８０及び３９０内の情報並びに／又はＤＩＲ記録３００内の他の情報を含む、ＤＩＲサブブロック内のＰＭＤＰ１３０によって）伝送され得る。いくつかの実施形態では、（例えば、ＤＩＲサブブロック内の）プラン固有コスト情報また、安全なＡＰＩを介して、（例えば、患者１７０に関連付けられたスマートフォン又は他のモバイルコンピューティングデバイス上の）アプリケーションに提供され得る。

【0200】

例えば、コスト情報は、集約コストメトリック３９５－ｐ（例えば、対応する第２のセット内の治療３０２－ｐｒに関連付けられた集約プラン固有コスト情報）を含み得る。例えば、（表１に示すように）、ＤＩＲサブブロック（例えば、３８０及び／又は３９０）は、プランｈ、選択された治療セット、コストＣ＿ｈｓ、及び対応する第２のセット内の各選択された治療３０２－ｒｓの提供者（例えば、薬局、場所等）に関する情報を含み得る。いくつかの実施形態では、コストＣ＿ｈｓは、治療セット内の各選択された治療３０２－ｒｓのコスト内訳（自己負担金、共同負担等）を更に含み得る。いくつかの実施形態では、アプリケーション（例えば、患者１７０に関連付けられたスマートフォン又は他のモバイルコンピューティングデバイス上の）は、プラン固有コスト情報を決定し、患者１７０に、コスト又は他の患者基準２９７によってランク付けされ得るプランオプションのリストを提供し得る。

【0201】

図１０Ｂを参照すると、ステップ１０３５において、患者のプラン固有コスト情報に基づいて、利用可能な保険プランのセットから少なくとも１つの利用可能な保険プランが取得され得る。例えば、患者は、利用可能な保険プランのセットから少なくとも１つの利用可能な保険プランを選択し得る。別の例として、ＰＭＤＰ１３０は、安全なＡＰＩを介して、アプリケーション（例えば、患者１７０に関連付けられたスマートフォン又は他のモバイルコンピューティングデバイス上の）から少なくとも１つの選択された利用可能な保険プランを受信し得る。

【0202】

任意選択のステップ１０４０において、ＰＭＤＰ１３０は、ＰＭＤＰ１３０によって復号可能な第２の暗号化された健康トランザクションレコード（ＨＴＲ）サブブロックを更に受信し得、ＨＴＲサブブロックは、利用可能な保険プランのセットから選択された、選択された保険プランを含む。

【0203】

次いで、（ＰＭＤＰ１３０がステップ１０４０においてＨＴＲサブブロックを受信したとき、及び／又はトランザクションの当事者であると見なされたときに実行され得る）任意選択のステップ１０４５において、ＰＭＤＰ１３０は、多次元ブロックチェーンを、第２のＨＴＲサブブロックに関連付けられた情報を含むＨＴＲブロック、及び第２の治療情報を含むＤＩＲブロックと、選択された保険プランのプラン固有コストメトリックと、トランザクションブロックとをリンクすることによって形成された多次元ブロックで拡張し得る。いくつかの実施形態では、多次元ブロックチェーンは、（例えば、ＨＥＸ１８０及び／又は支払人１４０及び／又はＰＢＭ１５０から）受信されたトランザクションブロックに応答して、保険プラン選択を含むトランザクション確認で拡張され得る。

【0204】

ブロック１０５０において、（例えば、患者１７０に関連付けられたスマートフォン又は他のモバイルコンピューティングデバイス上の）アプリケーションは、少なくとも１つの選択されたプランへの登録の確認を（例えば、ＨＥＸ１８０、及び／若しくは支払人１４０、及び／若しくはＰＢＭ１５０からの安全なメッセージを介して、並びに／又は安全なＡＰＩを介してＰＭＤＰ１３０から）受信し得る。

【0205】

図１１は、ヘルスケアシステムのセキュリティを容易にし、相互運用性を促進することができる例示的なコンピュータ１１００又はコンピューティングデバイスの概略図を示す。いくつかの実施形態では、コンピュータ１１００は、許可型プライベートブロックチェーンプラットフォームをホストし得、かつ／又は許可型プライベートブロックチェーンプラットフォームとインタラクトし得る。コンピュータ１１０は、エンティティ（例えば、ＨＣＰ１２０、ＰＭＤＰ１３０、支払人１４０、ＰＢＭ１５０、薬局１６０、及び／若しくはＨＥＸ１８０）及び／又は患者１７０に関連付けられたコンピューティングデバイスであり得、かつ／あるいは許可型ブロックチェーンプラットフォームを実装するために使用され得る。コンピュータ１３０は、単なる例に過ぎず、いくつかのコンピュータは、本明細書に開示される方法及びプロセスフローを実装するために、ネットワーク化及び／又は分散された様式で使用され得る。

【0206】

いくつかの実施形態では、例示的なコンピュータ１１００は、１つ又は２つ以上のエンティティ（ＨＣＰ１２０、ＰＭＤＰ１３０、支払人１４０、ＰＢＭ１５０、薬局１６０、及び／又はＨＥＸ１８０など）のための（物理的）サーバを含み得るか、又はサーバ（例えば、アプリケーションサーバ）を実行し得る。いくつかの実施形態では、１つのコンピュータ１１００が、図７～図１０のものを含む、本明細書に開示されるプロセスフロー及び／又は方法及び／又は他の技術の一部又は全てを実装し得る。いくつかの実施形態では、コンピュータ１１００は、分散コンピューティングシステムの部分を形成し得、許可型プライベートブロックチェーンプラットフォームを実装し得る。いくつかの実施形態では、分散コンピューティングシステム及び／又はコンピュータ１１００は、クラウドベースであり得る。いくつかの実施形態では、コンピュータ１１００は、他のコンピュータ１１００及び／又は本明細書に開示される技術を実装するための他のアプリケーションと相互作用するアプリケーションを実行し得る、スマートフォン、タブレット、ハンドヘルド、ノートブック、及び／又はラップトップ等のモバイルコンピューティングデバイスであり得る。

【0207】

いくつかの実施形態では、コンピュータ１１００／プロセッサ１１５０は、トランザクションリクエストを処理することが可能であり得、そのリクエストには、ブロックチェーンへのブロックの追加に関連するリクエストを含み、多次元ブロックチェーンを含む。更に、コンピュータ１１００／プロセッサ１１５０は、暗号化及び／又は復号アルゴリズムを走らせ、情報ブロックのハッシュを取得し、ハッシュを検証し、デジタル署名を実行することが可能であり得、様々な方法を実行及び／又はサポートして、セキュリティ及び認証を促進することを可能にし得る。認証とは、記憶された情報の完全性の検証（例えば、任意の認可されていない改変を判定するためのブロックチェーン内のブロック内での）、及び許可型プライベートブロックチェーンプラットフォームにアクセスするエンティティが信頼でき、任意のリクエストされたトランザクションを実行するための許可を有することを保証することの両方を指し得る。いくつかの実施形態では、コンピュータ１１００／プロセッサ１１５０はまた、新たなブロックを用いてブロックチェーンを拡張（作成又は追加）することもできる（多次元ブロックを用いて多次元ブロックチェーンを拡張させることを含む）。

【0208】

いくつかの実施形態では、コンピュータ１１００／プロセッサ１１５０はまた、ブロックチェーンに関連付けられたスマートコントラクトを記憶及び実行して、エンティティ（例えば、ＨＣＰ１２０、ＰＭＤＰ１３０、支払人１４０、及び／又は患者）間のプライバシー、情報共有、コントラクトの実行等に関連する合意を実装し得る。

【0209】

いくつかの実施形態では、コンピュータ１１００／プロセッサ１１５０は、治療に関連付けられた治療クラス（例えば、薬物クラス、デバイスクラス、及び／又は処置クラス）を決定すること、治療クラスからの治療に関連付けられたコストメトリックを個々に及び全体として決定すること、並びに患者基準を使用して選択をフィルタリング及び／又は絞り込むことを含む、健康関連データを数学的に分析し、統計的にコンパイルすることが可能であり得る。いくつかの実施形態では、コンピュータ１１００／プロセッサ１１５０はまた、（例えば、グラフィカルユーザインターフェース（Graphical User Interface、ＧＵＩ）を使用してスマートフォン上の情報の（例えば、表示装置１１７０上の）表示を開始することが可能であり得る。いくつかの実施形態では、コンピュータ１１００／プロセッサ１１５０はまた、機械学習技術を使用して、様々な健康パラメータ間の関係を判定することも可能であり得る。例えば、コンピュータ１１００／プロセッサ１１５０は、１つ又は２つ以上のニューラルネットワークプロセッサ、及び／又はニューラルネットワークとして構成され得る分散プロセッサを含み得、かつ／又はニューラルネットワークをモデル化及び／又はシミュレーションするためのソフトウェアを実行することが可能であり、そのソフトウェアを使用して、機械学習を実装し得る。例えば、ＰＭＤＰ１３０が、多次元ブロックを通じて利用可能な機械学習技術ベースＲＷＥ情報（例えば、人口統計情報、副作用、特定の関心薬物を組み合わせて使用される薬物、治療成果等）を使用して、薬物の使用法を調整し得る。例えば、機械学習を使用して、有効投与量を決定し、人口統計に基づいて薬物を標的化し、薬物相互作用情報を改善し、安全性を高め、投与の様々な様式の相対的有効性を決定すること等を行い得る。

【0210】

いくつかの実施形態では、コンピュータ１１００は、通信／ネットワークインターフェース１１０２を使用して他のコンピュータに結合し得、そのインターフェースは、有線（例えば、ギガビットイーサネットを含むイーサネット）及び無線インターフェースを含み得る。無線インターフェースは、３Ｇ、４Ｇ、及び５Ｇ標準規格を含むセルラー式標準規格などの無線ワイドエリアネットワーク（Wireless Wide Area Network、ＷＷＡＮ）標準規格、Ｗｉ－Ｆｉとして広く知られているＩＥＥＥ ８０２．１１ｘ標準規格。及び／又は無線パーソナルエリアネットワーク（例えば、Ｂｌｕｅｔｏｏｔｈ、近距離無線通信（Near Field Communication、ＮＦＣ）等）に基づき得る。いくつかの実施形態では、コンピュータ１１０は、（例えば、患者の）位置を自動的に判定するために、全地球測位システム及び／又は位置判定ユニットを含み得、これは、図７～図１０に開示される技術と併せて使用され得る。

【0211】

コンピュータ１１００は、メモリ１１０４を含み得、それには、読み出し専用メモリ（Read Only Memory、ＲＯＭ）、プログラマブル読み出し専用メモリ（Programmable Read Only Memory、ＰＲＯＭ）、様々なタイプのランダムアクセスメモリ（Random Access Memory、ＲＡＭ）、不揮発性ＲＡＭ等のうちの１つ又は２つ以上が含まれ得る。メモリ１１０４は、プロセッサ１１５０内部、又はプロセッサ１１５０の外部に実装され得る。本明細書で使用されるとき、「メモリ」という用語は、任意のタイプの長期、短期、揮発性、不揮発性、又は他のメモリを指し、いかなる特定のタイプのメモリ、若しくはメモリ数、又はメモリが記憶される媒体の種類にも限定されない。

【0212】

メモリは、キャッシュメモリ、一次メモリ、及び二次メモリを含み得る。二次メモリは、コンピュータ可読媒体１１２０を含み得る。コンピュータ可読媒体は、磁気及び／又は光学媒体を含み得、それらは、場合によっては、取り外し可能媒体であり得る。取り外し可能媒体は、コンパクトディスク（compact-disc、ＣＤ）、レーザディスク、デジタルビデオディスク（digital video disc、ＤＶＤ）、ブルーレイディスク、及び他の光学媒体などの光ディスクを含み得、更にＵＳＢドライブ、フラッシュドライブ、ソリッドステートドライブ、メモリカード等を含み得る。コンピュータ１１００は、更に記憶装置１１６０を含み得、それらには、ハードドライブ、ソリッドステートドライブ（solid state drive、ＳＳＤ）、フラッシュメモリ、他の不揮発性記憶装置、及びクラウドベース記憶装置を含み得る。

【0213】

通信／ネットワークインターフェース１１０２、記憶装置１１６０、メモリ１１０４、及びコンピュータ可読媒体１１２０は、接続１１０６を使用してプロセッサ１１５０に結合され得、その接続は、バス、ライン、ファイバ、リンク等の形態をとり得る。

【0214】

本明細書に記載されている方法は、アプリケーションに応じて様々な手段によって実装され得る。例えば、これらの方法は、ハードウェア、ファームウェア、ソフトウェア、又はそれらの任意の組み合わせで実装され得る。ハードウェア実装の場合、プロセッサ１１５０は、１つ又は２つ以上の特定用途向け集積回路（application specific integrated circuit、ＡＳＩＣ）、デジタル信号プロセッサ（digital signal processor、ＤＳＰ）、ニューラルネットワークプロセッサ（neural network processor、ＮＮＰ）、デジタル信号処理デバイス（digital signal processing device、ＤＳＰＤ）、プログラマブルロジックデバイス（programmable logic device、ＰＬＤ）、フィールドプログラマブルゲートアレイ（field programmable gate array、ＦＰＧＡ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子デバイス、本明細書に記載されている機能を実行するように設計された他の電子ユニット、又はそれらの組み合わせに実装され得る。

【0215】

ファームウェア及び／又はソフトウェア実装の場合、その方法は、本明細書に記載されている機能を実行するマイクロコード、プロシージャ、関数などを用いて実装され得る。命令を明確に具現化する任意の機械可読媒体が、本明細書に記載されている方法を実装する際に使用され得る。例えば、ソフトウェアは、記憶装置１１６０内に、かつ／又は取り外し可能コンピュータ可読媒体上に記憶され得る。プログラムコードは、コンピュータ可読媒体１１２０、記憶装置１１６０、及び／又はメモリ１１０４に常駐し得、プロセッサ１１５０によって読み出し及び実行され得る。

【0216】

ファームウェア及び／又はソフトウェアで実装される場合、その機能はまた、１つ又は２つ以上の命令若しくはコードコンピュータ可読媒体１１２０、記憶装置１１６０、及び／又はメモリ１１０４として記憶され得る。例としては、データ構造及びコンピュータプログラムを用いて符号化されたコンピュータ可読媒体が挙げられる。例えば、コンピュータ可読媒体１１２０は、その上に記憶されたプログラムコードを含み得、ヘルスケアシステムセキュリティを容易にし、システム相互運用性を促進するための方法をサポートするためのプログラムコードを含み得、多次元ブロックチェーン、スマートコントラクト、合意判定をサポートし、本明細書に記載されているように、許可型プライベートブロックチェーンプラットフォームに関連付けられた他の機能を実行することを含む。

【0217】

プロセッサ１１５０は、ハードウェア、ファームウェア、及びソフトウェアの組み合わせを使用して実装され得る。いくつかの実施形態では、コンピュータ１１００は、表示装置に結合されて、ＧＵＩの閲覧、並びに管理者及び他のユーザとのインタラクションを容易にし得る。

【0218】

本開示は、指導上の目的で特定の実施形態とからめて説明されているが、本開示は、これらに限定されない。本発明の範囲から逸脱することなく、様々な適合及び修正を本開示に行うことができる。したがって、添付の請求項の趣旨及び範囲は、前述の説明に限定されるべきではない。

【図1】

【図2】

【図3A】

【図3B】

【図3C】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8】

【図9】

【図10A】

【図10B】

【図11】

【国際調査報告】