(57)【要約】  分散型自律医療経済プラットフォームのためのシステム及び方法を提供する。システム及び方法は、医療データの全てをグローバルなグラフ理論トポロジに集約して、ハイブリッド連合型及びピアツーピア分散型の処理アーキテクチャを介してデータを処理する。【選択図】図１
2018533103.tif 000002
【特許請求の範囲】
【請求項１】
分散型自律医療のためのシステムであって、
コンピュータシステムと、
前記コンピュータシステム上に実装された複数のヘルスブロックチェーンネットワーク構成要素と、
を含み、
前記ヘルスブロックチェーンネットワーク構成要素の各々は、医療トランザクションプロトコルを用いて医療トランザクションを実行する能力がある、システム。
【請求項２】
ピアツーピアネットワークを形成する複数のコンピュータシステムを更に含む、請求項１に記載のシステム。
【請求項３】
前記医療トランザクションプロトコルを用いて前記医療トランザクションの実行を要求する、前記ヘルスブロックチェーンネットワーク構成要素の各々から遠隔のアプリケーションを更に含む、請求項１に記載のシステム。
【請求項４】
前記医療トランザクションは、Ｘ１２ヘルストランザクションである、請求項１に記載のシステム。
【請求項５】
分散型自律医療システムを提供するための方法であって、
コンピュータシステム、及び前記コンピュータシステム上に実装された複数のヘルスブロックチェーンネットワーク構成要素を提供する段階と、
前記ヘルスブロックチェーンネットワーク構成要素の各々を用いて、医療トランザクションプロトコルを用いて医療トランザクションを実行する段階と、
を含む方法。
【請求項６】
ピアツーピアネットワークを形成する複数のコンピュータシステムを提供する段階を更に含む、請求項５に記載の方法。
【請求項７】
前記ヘルスブロックチェーンネットワーク構成要素の各々から遠隔のアプリケーションを用いて、前記医療トランザクションプロトコルを用いる前記医療トランザクションの実行を要求する段階を更に含む、請求項５に記載の方法。
【請求項８】
前記医療トランザクションは、Ｘ１２ヘルストランザクションである、請求項５に記載の方法。
【請求項９】
全てが分散型処理システムを提供する、コンピュータシステム上に実装された複数のヘルスブロックチェーンネットワーク構成要素を備えるシステムであって、
前記ヘルスブロックチェーンネットワーク構成要素の各々は、動的ゲーム理論を用いてアセットの価格を設定する能力があるシステム。
【請求項１０】
ピアツーピアネットワークを形成する複数のコンピュータシステムを更に含む、請求項９に記載のシステム。
【請求項１１】
医療トランザクションプロトコルを用いて前記アセット価格設定に参加する、前記ヘルスブロックチェーンネットワーク構成要素の各々から遠隔のアプリケーションを更に含む、請求項９に記載のシステム。
【請求項１２】
前記医療トランザクションプロトコルは、Ｘ１２ヘルストランザクションである、請求項９に記載のシステム。
【請求項１３】
全てが分散型処理システムを提供する、コンピュータシステム上に実装された複数のヘルスブロックチェーンネットワーク構成要素を備えるシステムであって、
前記ヘルスブロックチェーンネットワーク構成要素の各々は、合意に関してアセットの価格の設定を通じて前記合意を処理する能力があるシステム。
【請求項１４】
前記ヘルスブロックチェーンネットワーク構成要素の各々は、動的ゲーム理論を用いてアセットの価格を設定する能力がある、請求項１３に記載のシステム。
【請求項１５】
ピアツーピアネットワークを形成する複数のコンピュータシステムを更に含む、請求項１３に記載のシステム。
【請求項１６】
医療トランザクションプロトコルを用いて前記アセット価格設定に参加する、前記ヘルスブロックチェーンネットワーク構成要素の各々から遠隔のアプリケーションを更に含む、請求項１３に記載のシステム。
【請求項１７】
前記医療トランザクションプロトコルは、Ｘ１２ヘルストランザクションである、請求項１３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般に医療システムに関する。
【背景技術】
【０００２】
現在、医療産業には解決する必要がある多くの問題があり、
・基本トランザクションが健康情報ネットワークで発生する速度、
・これらの健康情報ネットワーク内に含まれる情報のサイロ的性質、
・消費者がこれらのネットワーク内に含まれる健康情報のフローにアクセスする能力、
・健康情報ネットワーク内でのトランザクションの信頼性及びトレーサビリティ
が含まれている。
【０００３】
健康産業内でのシームレスな相互運用性の必要性は、最大の懸案事項である。これは、消費者、支払人、及び医療提供者情勢の全ての態様を含む。医療企業アプリケーション（例えば、電子化診療記録（Ｅｌｅｃｔｒｏｎｉｃ  Ｍｅｄｉｃａｌ  Ｒｅｃｏｒｄ）システム（ＥＭＲ）、電子化健康記録（Ｅｌｅｃｔｒｏｎｉｃ  ＨｅａｌｔｈＣａｒｅ  Ｒｅｃｏｒｄ）（ＥＨＲ）、Ｐｒａｃｔｉｃｅ  Ｍａｎａｇｅｍｅnｔ  （診療管理）システム（ＰＭ）、及び支払人ソリューション）が、恐らくは特定のエンドユーザ（消費者）の要件に対応するために、医療情報技術の多くの分野内で生み出されてきた。しかしながら、これらのアプリケーションは、データ操作の相互運用性及び透明性は可能にしない。
【０００４】
例えば、ＥＭＲは、大量の製品提供の間にほとんど又は全く連結性を有さない孤立した情報として存在する。これは更に、ＡＳＣ４０１０／５０１０  Ｘ１２（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐ：／／ｗｗｗ．ｘ１２．ｏｒｇ／に見出される）等の電子データ交換「標準規格」の使用により悪化してきた。更に、処理は、同じ病院システム内で深化して、どのような連結性が実施されたかは主として手動労力であり、実施及び保守に多大なコストを伴うため、更に状況を悪化させる。このシナリオは、ＲＥＳＴベースでマルチテナンシーであるアプリケーションプログラミングインタフェース（ＡＰＩ）システムに取って代わる。マルチテナンシーとは、ソフトウェアアプリケーションの単一インスタンスが複数の顧客にサービスを提供するアーキテクチャである。各顧客がテナントと呼ばれる。マルチテナンシーにより、スケーリングは、ベンダにとって非常にわずかなインフラストラクチャ上の意味しか持たない（アプリケーションのサイズ及び要求されるインフラストラクチャ量による）。更に、マルチテナントソフトウェアシステムは、単一アプリケーションインスタンス内であらゆる数の顧客をサポートするシステムである。通常、この単一インスタンスは、共有データセットを利用するが、この場合、顧客のデータは、他の顧客のデータと厳密に分離される。データ分離は、マルチテナントアプリケーションの重要な側面であるが、全顧客データ（又はこれらのいずれかの一部分）の開示を必要とするシステムワイド（例えば、グローバル）な計算が存在する場合がある。このようなグローバル操作が必要ない場合、マルチテナントアプリケーションは、代わりにマルチインスタンスアプリケーションとなり、この場合は各顧客のデータが自身の隔離されたサイロ内に含まれる。
【０００５】
医療情報管理システム学会（ＨＩＭＳＳ）（詳細については、引用により本明細書に組み込まれたｈｔｔｐ：／／ｗｗｗ．ｈｉｍｓｓ．ｏｒｇ／にある）という分析機関によれば、ＨＩＭＳＳ  Ａｎａｌｙｔｉｃｓ  Ｅｕｒｏｐｅの個人通信機関のＵｗｅ  Ｂｕｄｄｒｕｓによると、大国（米国、カナダ、ドイツ、フランス、イタリア、及びスペイン等）は、最高レベルのペーパーレスデータ共有、格納、及び決定のサポートに達する上で、いくつかのヨーロッパの小国（デンマーク、オランダ、及びスウェーデン等）に出遅れている。医療における１年あたりのファックス数は米国だけで、毎年、１５００万に近い。紙による対話を低減して、より流動的な電子フォーマットに移行するための強硬な要件が存在する。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】ｈｔｔｐ：／／ｗｗｗ．ｘ１２．ｏｒｇ／
【非特許文献２】ｈｔｔｐ：／／ｗｗｗ．ｈｉｍｓｓ．ｏｒｇ／
【非特許文献３】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｐｅｅｒ−ｔｏ−ｐｅｅｒ
【非特許文献４】ｈｔｔｐ：／／ｗｗｗ．ｈｌ７．ｏｒｇ／
【非特許文献５】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＣＥＮ／ＴＣ＿２５１
【非特許文献６】ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｅｈｒ．ｏｒｇ／
【非特許文献７】ｈｔｔｐ：／／ｗｗｗ．ｘ１２．ｏｒｇ／ｘ１２ｏｒｇ／ｄｏｃｓ／ＥＤＩＴｒａｎｓａｃｔｉｏｎｓ．ｐｄｆ
【非特許文献８】ｈｔｔｐ：／／ｗｗｗ．ｎｌｍ．ｎｉｈ．ｇｏｖ／ｒｅｓｅａｒｃｈ／ｕｍｌｓ／Ｓｎｏｍｅｄ／ｓｎｏｍｅｄ  ｍａｉｎ．ｈｔｍｌ
【非特許文献９】ｈｔｔｐ：／／ｗｉｋｉ．ｈｌ７．ｏｒｇ／ｉｎｄｅｘ．ｐｈｐ？ｔｉｔｌｅ＝ＦＨＩＲ
【非特許文献１０】ｈｔｔｐ：／／ｃ２．ｃｏｍ／ｃｇｉ／ｗｉｋｉ？ＡｃｔｏｒＶｓＡｇｅｎｔ
【非特許文献１１】ｈｔｔｐｓ：／／ｅｎ．ｂｉｔｃｏｉｎ．ｉｔ／ｗｉｋｉ／Ｗａｌｌｅｔ
【非特許文献１２】ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ３９８６
【非特許文献１３】ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ＯｐｅｎＡｓｓｅｔｓ／ｏｐｅｎ−ａｓｓｅｔｓ−ｐｒｏｔｏｃｏｌ／ｂｌｏｂ／ｍａｓｔｅｒ／ｓｐｅｃｉｆｉｃａｔｉｏｎ．ｍｅｄｉａｗｉｋｉ＃ｐｒｏｔｏｃｏｌ−ｏｖｅｒｖｉｅｗ
【非特許文献１４】ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９＃ｓｅｃｔｉｏｎ−１．３
【非特許文献１５】ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ＯｐｅｎＡｓｓｅｔｓ／ｏｐｅｎ−ａｓｓｅｔｓ−ｐｒｏｔｏｃｏｌ／ｂｌｏｂ／ｍａｓｔｅｒ／ｓｐｅｃｉｆｉｃａｔｉｏｎ．ｍｅｄｉａｗｉｋｉ
【非特許文献１６】ｈｔｔｐｓ：／／ｅｎ．ｂｉｔｃｏｉｎ．ｉｔ／ｗｉｋｉ／Ｃｏｌｏｒｅｄ＿Ｃｏｉｎｓ
【非特許文献１７】ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ｗｉｋｉ／ｗｉｋｉ／Ｗｈｉｔｅ−Ｐａｐｅｒ
【図面の簡単な説明】
【０００７】
【図１】ピアツーピアアーキテクチャを有する分散型医療のためのシステム１００を示す。
【図１Ｂ】分散型システムのコンピュータシステムの実施例を示す。
【図２】分散型システムの一部分である医療ブロックチェーンアプリケーションの実施例を示す。
【図３】医療ブロックチェーンの実施例を示す。
【図４】分散型医療ブロックチェーンシステムのリファラルワークフローの実施例を示す。
【図５】患者行動医療保険のための処理の実施例を示す。
【図６】分散型医療ブロックチェーンシステムの患者及び医療提供者のデータ共有処理を示す。
【図７】分散型システムを用いた患者データ共有データフローを示す。
【発明を実施するための形態】
【０００８】
以下で説明するシステム及び方法は、医療データの全てをグローバルなグラフ理論トポロジに集約して、ハイブリッド連合型及びピアツーピア分散型の処理アーキテクチャ（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｐｅｅｒ−ｔｏ−ｐｅｅｒ及びｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｐｅｅｒ−ｔｏ−ｐｅｅｒに見出される）を介してデータを処理する。これらの処理に含まれるデータの一部は、限定ではないが、以下を含むことができる：
・マルチテナント電子化健康記録システム内の患者記録は、患者の機密保持を保証するために分離することができる。しかしながら、データアナリスト／科学者は、人口全体の健康問題を研究できるように、集合的な非特定化統計をグローバルデータセットから収集することができる。すなわち、
・請求、給付金、及びリファラル情報
・ＢＭＩ及び心拍等のウェアラブルデータ
・それぞれの法人のトランザクションに関する請求可能額又は請求先情報
・単一の永続的な元帳記載識別子管理システムを介して自身の診療及び健康情報を真に制御するための能力を消費者に与えること
である。
【０００９】
システム及び方法は、電子データ交換（ＥＤＩ）のモデルをＡＳＣ  Ｘ１２の下でいくつかの異なる方法及びプログラム的方法論で実施することができる。以下は、ハードルの一部である：
・ほとんどの病院が、重要アプリケーションとして実行中の旧型又は専用の標準規格又はプロトコルを依然として有する
・医療標準規格は、持続的な開発及び改善の途中である
・発散的で収束しない医療標準規格は、以下のようなものである：
・ＨＬ７  ｖ２．ｘ、ｖ３（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐ：／／ｗｗｗ．ｈｌ７．ｏｒｇ／に記載される）
・ＣＥＮ  ＴＣ／２５１（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＣＥＮ／ＴＣ＿２５１に記載される）
・ｏｐｅｎＥＨＲ（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｅｈｒ．ｏｒｇ／に記載される）
・ＡＳＣ  Ｘ１２  ４０１０／５０１０（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐ：／／ｗｗｗ．ｘ１２．ｏｒｇ／ｘ１２ｏｒｇ／ｄｏｃｓ／ＥＤＩＴｒａｎｓａｃｔｉｏｎｓ．ｐｄｆに記載される）
・ＳＮＯＷ−ＭＥＤ（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐ：／／ｗｗｗ．ｎｌｍ．ｎｉｈ．ｇｏｖ／ｒｅｓｅａｒｃｈ／ｕｍｌｓ／Ｓｎｏｍｅｄ／ｓｎｏｍｅｄ  ｍａｉｎ．ｈｔｍｌに記載される）
・ＦＨＩＲ（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐ：／／ｗｉｋｉ．ｈｌ７．ｏｒｇ／ｉｎｄｅｘ．ｐｈｐ？ｔｉｔｌｅ＝ＦＨＩＲに記載される）
・これらの標準規格の全てが、意図されたセマンティクスを有するが、データ構造の意味に関しては標準規格に従わないので、前記標準規格の目的を、従って相互運用性を無効化する。例えば、データは、所定のデータ要素及び構造を用いることなく、コメントフィールドに非構造化方式で埋め込まれる。
・拡張可能マークアップ言語（ＸＭＬ）及びＸＳＤでフォーマットされた医療標準規格は、構文（シンタックス）レベルでの統合又は相互運用性の問題は解決するが、有意義な統合を達成するためには、領域特化型のソリューションが必要とされ、しかしながら、実際の交換、保守性、及びスケーリングは準最適である。これらはまた、スケーラブルではない。
【００１０】
ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）が、より理解しやすい標準規格をもたらしたが、上記の標準規格からのデータモデル及びスキーマは、絶えず変化している。
【００１１】
従って、現在の医療企業アプリケーションは、全レベル−データ、処理、サービス、及び支払での医療システムの多様性という課題に対応するために、より多大な柔軟性及び拡張性（スケーラビリティ）を必要とする。いずれかの統合システムのアーキテクチャが、動的で、柔軟性があり、拡張可能なソリューションを提供するための鍵を握る。
【００１２】
本システム及び方法は、データ処理及び観測にエージェント／アクターモデルを使用する（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐ：／／ｃ２．ｃｏｍ／ｃｇｉ／ｗｉｋｉ？ＡｃｔｏｒＶｓＡｇｅｎｔに記載される）。エージェント／アクターモデルは、ベンダ、標準規格、レガシーシステム、及び情報システムを含み、医療サービスを提供するためには、これらの全てが相互運用しなければならない。システム及び方法は、既存の又は提案される医療システムに対していずれの制約も課すことなく、相互運用性ソリューションを提供する。本出願人の手法の主な利点は、これが、回復力があって自律的であり、医療（ＨｅａｌｔｈＣａｒｅ）ネットワークに参加するために事前承認された又は管理上のオーバーヘッドを必要としない、ハイブリッド連合及び分散型システムである点である。更に、消費者の同意を前提として、支払人、医療提供者、及び消費者に、消費者のデータにアクセスする能力を提供し、並びに、パーソナルヘルスレコード（ＰＨＲ）のリアルタイムアクセス及び制御を維持する能力を消費者にもたらす。
【００１３】
理想的には、ＥＨＲ／ＥＭＲが、経時的に、治療の全局面についてのデータをキャプチャして統合し、データは、関連するデータ構造に従って表され、リアルタイムで消費者のＰＨＲへのアクセスを可能にする。現在はそうではない。システム及び方法、並びにその処理アーキテクチャ及びデータアクセスのモデルは、正確なデータがシステム内を流れることを可能にして、システムを越えて透過的な挙動及びアクセスを与えることになる。
【００１４】
ＥＨＲ／ＥＭＲシステムでキャプチャされるデータの多くが、病院の取組み及び実績の監視、及び政府又は保険の償還等の管理目的の役目を果たす。単純なＥＨＲ／ＥＭＲシステムでさえ、通常は年齢、性別、人種、及び住所等の人口統計的な患者情報、並びに日付及びＣＰＴ（医師診療行為用語）及びＩＣＤ（国際疾病分類）で符号化されたサービス及び診断（入院患者及び通院患者の両方に関して請求コードと呼ばれることが多い）の形式の所定の受診についての構造化された情報を取得することになる。多くの場合、これらのコーディングスキーマは、自動化されておらず、ユーザエラー及び二重徴収処理が起きやすい。この二重徴収処理は、請求情報処理時の問題の原因である。更に、元帳における二重徴収はまた、過去の電子金融システム内の処理の人為的な結果及び誤りでもあるが、元帳は、記録元帳を重複排除しない。
【００１５】
本システム及び方法は、消費者のＰＨＲへの迅速なアクセスを可能にする識別子管理を提供して使用するが、ＰＨＲは、様々な異なるヘルスアプリケーション、例えば、Ｆｉｔ−Ｂｉｔ、Ｊａｗｂｏｎｅ、Ａｐｐｌｅ  Ｈｅａｌｔｈ  Ｋｉｔ又はＰａｙＰａｌ等と統合可能である。システム及び方法はまた、ピアツーピアの自律的で正確な健康情報交換及びトランザクション処理を提供し、リアルタイム処理並びに迅速なアクセス及び相互運用性を可能にすることになる。
【００１６】
例示的な実装の概説
図１は、ピアツーピアアーキテクチャを有する分散型医療のためのシステム１００を示している。機能グラフトポロジは、それぞれのシステム間の対話に必要なセマンティクスを、医療標準規格内の対話イベントに基づいて記述しており、この場合の標準規格は、ＨＬ７、ＳＮＯＷ−ＭＥＤ、ｏｐｅｎＥＨＲ、ＦＨＩＲ、及びＡＳＣ  Ｘ１２  ４０１０／５０１０等の、システム間の領域ベースのワークフローを提供するための様々な標準データ構造である。ピアツーピア分類基準は、種々のシステム間のデータ相互運用性のために交換される必要がある医療メッセージ及び対話に関連するトランザクション・セマンティクスを定義する。これらの仕様における差異は、以下で説明するようなピアツーピアマッピング技術によって解決される。アダプタフレームワークが、設計時に開発されて実行時に裁定方式で実行される起源ルールを受信する。このモデルを定義するアーキテクチャが、「ブロックチェーン」と呼ばれる。ブロックチェーンが最初に話題になったのは、ビットコイン：Ｓａｔｏｓｈｉ  Ｎａｋａｍｏｔｏによるピアツーピア電子キャッシュシステム（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐｓ：／／ｅｎ．ｂｉｔｃｏｉｎ．ｉｔ／ｗｉｋｉ／Ｗａｌｌｅｔに記載される）という論文においてである。システムは、信託の代わりに暗号証明に基づく電子支払システムのモデルを有し、あらゆる自発的な２当事者が、信頼できる第三者を必要とせずに、相互に直接取引できるようにする。本システムは、この基本概念を利用し、これによりシステムは、以下の４つの基本方式でブロックチェーントポロジを利用できるようになる。すなわち、
・事業提携契約書（Ｂｕｓｉｎｅｓｓ  Ａｓｓｏｃｉａｔｅ  Ａｇｒｅｅｍｅｎｔ）ＨＩＰＡＡ準拠の全情報データが、ブロックチェーン元帳処理によって更新される
・ブロックチェーン内で参照されたデータ構造が、分散型ファイル処理によって記述されて更新される
・パーソナルヘルスレコード情報が、個人の「ビットコインベースの」ウォレットアーキテクチャ内に格納される
・それぞれのデータモジュールがエージェントベースのソリューションから必要とする、サービスへのつながりについての裁定又はビッド／アスク機構
である。
【００１７】
図１に示すように、システム１００は、通信経路１０６を通ってバックエンドシステム１０４にアクセスする必要がある１又は２以上のアプリケーション１０２を有することができ、バックエンドシステム１０４は、例えば、１又は２以上のヘルスブロックチェーンネットワーク構成要素１０４Ａ、１０４Ｂ、．．．、１０４Ｎを有することができ、１又は２以上のアプリケーションは、１又は２以上のヘルスブロックチェーンネットワーク構成要素にアクセスする。各アプリケーション１０２は、コンピューティングデバイスによって実行することができ、各コンピューティングデバイスは、公知の通信及びデータプロトコル及びＡＰＩを用いて、通信経路１０６を通ってバックエンドシステム１０４に接続してこれと対話することができるプロセッサベースのデバイスとすることができる。例えば、各コンピューティングデバイスは、Ａｐｐｌｅ  ｉＰｈｏｎｅ（登録商標）又はＡｎｄｒｏｉｄオペレーティングシステムベースのデバイス等のスマートフォンデバイス、パーソナルコンピュータ、ラップトップコンピュータ、サーバコンピュータ、端末、及びアプリケーション１０２を実行してヘルスブロックチェーンネットワーク構成要素との対話を実行することができる同様のものとすることができる。
【００１８】
バックエンド１０４及びヘルスブロックチェーンネットワーク構成要素は、サーバコンピュータ、ブレードサーバ、メインフレームコンピュータ、プロセッサ、メモリ、ストレージデバイス、及び同様のもの等の１又は２以上のコンピューティング資源を用いて実施することができる。バックエンド１０４及びヘルスブロックチェーンネットワーク構成要素は、通信経路１０６を通って１又は２以上のヘルスデータソース１０８に結合することができる。バックエンド１０４及びヘルスブロックチェーンネットワーク構成要素は、各データソースのための標準規格、プロトコル、及び／又はＡＰＩを用いて、ヘルスデータソースと通信することができる。図１の実施例において、ヘルスデータソースは、ＰＨＲシステム、ＨＥＲ／ＥＭＲシステム、及びＸ１２ベースのシステムとすることができる。
【００１９】
上述のように、ホストアプリケーション等の１又は２以上のアプリケーション１０２は、Ｈｅａｌｔｈ  ＢｌｏｃｋＣｈａｉｎ  Ｎｅｔｗｏｒｋ（ヘルスブロックチェーンネットワーク）構成要素１０４Ａ−１０４Ｎにアクセスすることができる。ネットワークは、処理の観点からは本質的に多種多様とすることができるが、以下の３つの主要な処理領域に重点的に取り組む。（１）支払人に関しては、価格データ、適格性、請求、及び給付金処理データを処理する必要性があり、（２）医療提供者に関しては、電子診療／健康記録、スケジューリング及び臨床、診断、及び支払データの必要性があり、（３）消費者に関しては、パーソナルヘルスレコード、スケジューリング情報及び支払データの必要性がある。これについては、上記のシナリオを包含することができるホストアプリケーション１０２、及びハイブリッド連合型及び分散型のブロックチェーン処理、及び本質的に分散型であるファイルシステムを通じて例証される。
【００２０】
図１Ｂは、分散型システムのコンピュータシステム１００の実施構成を示している。分散型ピアツーピア医療システム及び方法は、サーバコンピュータ、ブレード資源、データベースサーバ、アプリケーションサービス、ブレードサーバ、及びプロセッサ、メモリ、ストレージ機能、通信機能、及び同様のものを含むいずれかの他のコンピューティング資源を含む様々な異なるタイプのコンピューティング資源を用いて実施することができる。
【００２１】
図１Ｂに示すように、各コンピュータシステム１０４は、相互接続することができ、各アプリケーション１０２は、いずれかのコンピュータシステム１０４の種々のセキュア及び非セキュア接続及びデータプロトコルに結合してこれと通信することができる。記載されるように、各コンピュータシステム１０４は、以下で説明するように動作する１又は２以上のＨｅａｌｔｈ  ＢｌｏｃｋＣｈａｉｎ  Ｎｅｔｗｏｒｋ（ヘルスブロックチェーンネットワーク）構成要素１０４Ａ−１０４Ｎを有することができる。
【００２２】
ヘルスブロックチェーンネットワークを利用するアプリケーション１０２は、ヘルスデータ、ＰＨＲ／ＥＨＲ／ＥＭＲ、並びにヘルストランザクション、Ｘ１２／Ｃｌｉｎｉｃａｌのアクセス、格納、及び配布を促進にすることになり、ヘルスブロックチェーンアプリケーションとして知られている。各アプリケーション１０２のアプリケーションスタックの実施例を図２に示す。各アプリケーションスタックは、アプリケーションレイヤ１０２Ａと、サービスレイヤ１０２Ｂと、データレイヤ１０２Ｃとを含む。資源識別子（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ３９８６に記載される）、アセットシグネチャ（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ＯｐｅｎＡｓｓｅｔｓ／ｏｐｅｎ−ａｓｓｅｔｓ−ｐｒｏｔｏｃｏｌ／ｂｌｏｂ／ｍａｓｔｅｒ／ｓｐｅｃｉｆｉｃａｔｉｏｎ．ｍｅｄｉａｗｉｋｉ＃ｐｒｏｔｏｃｏｌ−ｏｖｅｒｖｉｅｗに記載される）、及び認可承諾（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９＃ｓｅｃｔｉｏｎ−１．３に記載される）のみがヘルスブロックチェーン内に格納されるので、資源自体及び資源へのアクセスは、関与するアプリケーションによって処理される。アプリケーションの範囲に応じて、特定の実施シナリオに関して、識別された構成要素のうちのより小さなサブセットを実施することができる。図２に示す実施例において、アプリケーションレイヤ１０２Ａは、ＡＰＩレジストリと、アクターレジストリと、サービスレジストリと、製品レジストリと、データレジストリ及び変換と、イベントと、ワークフローと、認可及び委任とを含むことができる。サービスレイヤ１０２Ｂは、ブロックチェーントランザクションと、データ配布要素と、ネットワークノード管理と、アクセス制御とを含むことができる。データレイヤ１０２Ｃは、ピアツーピアファイル転送と、グラフデータ格納と、識別子管理と、暗号化及び鍵管理要素とを含むことができる。
【００２３】
ヘルスブロックチェーン自体は、絶えず増加し続けるリンク付きリスト内の、データブロックの分散型データベース又は複製された共有元帳としてとして編成され、各ブロックは、ネットワーク上の複数のノードによって暗号的に検証される。ブロックデータベースの構造及び関係を図３に示す。図示するように、各ブロックヘッダ３００は、分散型データベースのデータの一部分、及びブロックハッシュ、及びマークル・ルートを保持する。各ブロックヘッダは、ブロックトランザクション及びこれのデータに結び付けられる。
【００２４】
ブロック構造のためのデータ構造を以下の表１．０及び表１．１に示す。
【表１．０】
2018533103.tif 000003
【００２５】
入力が認可されたことを検証して参照される出力の値を収集するために、組込みのスクリプト言語が使用される。このスクリプト言語は、チューリング完全で、スタックベースであり、左から右に処理される。スクリプト言語は通常、高水準言語（例えば、ソリディティ（ｓｏｌｉｄｉｔｙ）、ｈｔｔｐｓ：／／ｅｔｈｅｒｅｕｍ．ｇｉｔｈｕｂ．ｉｏ／ｓｏｌｉｄｉｔｙ／ｄｏｃｓ／ｈｏｍｅ／）で記述され、その後、ブロックチェーントランザクション内に含まれる生のオペレーションコードにコンパイルされる（この高水準言語を表す疑似コードが、例示的なランザクションにおいて本明細書全体にわたって使用される）。トランザクション入力は、実行したスクリプトがｔｒｕｅ（真）を返す場合に認可される。スクリプトシステムを通じて、送信者は、システム内のアクターが出力を要求するために満たさなければならない非常に複雑な条件を作成することができる。このようにして、チェック、認可、アクション、又はまさに外部イベントのいずれかの自動化システムが、トランザクションの一部として含まれて、妥当性確認することができる。
【００２６】
トランザクションデータは、ＯＰ＿ＲＥＴＵＲＮ演算子を用いた、Ｏｐｅｎ  Ａｓｓｅｔｓ（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ＯｐｅｎＡｓｓｅｔｓ／ｏｐｅｎ−ａｓｓｅｔｓ−ｐｒｏｔｏｃｏｌ／ｂｌｏｂ／ｍａｓｔｅｒ／ｓｐｅｃｉｆｉｃａｔｉｏｎ．ｍｅｄｉａｗｉｋｉに記載される）に基づく、カラードコイン実施構成（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐｓ：／／ｅｎ．ｂｉｔｃｏｉｎ．ｉｔ／ｗｉｋｉ／Ｃｏｌｏｒｅｄ＿Ｃｏｉｎｓに記載される）から成ることができる。メタデータがブロックチェーンからリンクされてウェブ上に格納され、資源識別子によってデリファレンスされて、公開トレントファイル上で配布される。カラードコイン仕様は、デジタルアセット及びスマートコントラクトの分散型管理のための方法を提供する（更なる詳細については、引用により本明細書に組み込まれたｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ｗｉｋｉ／ｗｉｋｉ／Ｗｈｉｔｅ−Ｐａｐｅｒに記載される）。本出願人の目的において、スマートコントラクトは、状態により、ブロックチェーン上で実行されてブロックチェーン上でアセットを操作することができるイベントドリブンのコンピュータプログラムとして定義される。従って、スマートコントラクトは、コントラクトの条件（スクリプトコード）を履行（入力を妥当性確認）するために、ブロックチェーンスクリプト言語で実施される。
【００２７】
デジタルアセットは、スマートコントラクトで管理、転送され、又はそこに含まれる。支払人は、給付金データ又は適格性情報等のアセットを発行する。医療提供者は、臨床文書、健康記録のアセットを発行し、消費者は、スマートコントラクトの使用を通じてこれらを受信して、これらへのアクセスを許可することができる。
【表１．１】
2018533103.tif 000004
トランザクションペイロードは、以下のデータタイプ及びフィールドを含むことができる：
2018533103.tif 000005
【００２８】
使用シナリオ
図１、２、及び３に示した上記のブロックチェーン処理及びシステムを用いて、種々のヘルスデータ及びヘルストランザクションを処理することができる。
【００２９】
システムは、具体的には、「サイドチェーン」を利用して、販売者と購入者との間のプライベート又は準プライベートのスマートコントラクトの処理を扱う。サイドチェーンとは、他のブロックチェーンからのデータを妥当性確認するブロックチェーンである。これらは、「ペグ」を通じて実施される。ペグされたサイドチェーンとは、他のチェーンからアセットをインポートしてそこに戻すことができるサイドチェーン、すなわち、双方向ペグのアセットをサポートするサイドチェーンである。双方向ペグとは、（この場合には）アセットが、固定のさもなければ決定論的交換レートで、サイドチェーン間で転送されて戻るための機構を指し、交換レートは、我々の取引又は裁定アセット環境における状況的転送レート又は値に基づく。
【００３０】
システム及び方法の実施構成の具体的内容は、「ヘルスブロックチェーン」分散型処理に入力されるネットワーク化グラフベースの構造に基づく。このネットワーク化環境はまた、交換理論に基づく交換モデルの基礎も可能にする。アルゴリズムは、分散型ネットワークのグラフをサブグラフに下位分割して、販売者セットがより大きい購入者セットにまとめてリンクされて（販売者は、ゲーム理論的意味で１に近いペイオフを得る）、購入者は０に近いペイオフを受け取り；販売者セットが同じサイズの購入者セットにリンクされ（各々がおよそ１／２のペイオフを受け取る）、販売者が購入者の数を上回る（販売者が０に近いペイオフを受け取り、購入者が１に近いペイオフを得る）。
【００３１】
アーキテクチャ及びデータ処理に関して、システムは、Ｃｏｒｏｍｉｎａｓ−Ｂｏｓｃｈによるかつての研究に基づく交換処理を用いて更新して、処理交換メカニクスのリンクパターンが潜在的なトランザクションを表すが、トランザクション及び価格は、交渉よりもむしろ競売によって決まる。一般的なモデルの場合、同種の商品のｎ人の販売者及びｍ人の購入者が存在し、この場合、全販売者が予約値０を有し、全購入者が予約値１を有する。各購入者は、ただ１個の商品のみを所望し、各販売者は、ただ１個のみを供給することができる。価格は、ｎ及びｍの相対的サイズのみに依存するか？及び全取引が同じ価格で行われるか？ここで、購入者（販売者）は、全販売者（購入者）のうちの事前に割り当てられたサブセットと交渉する。リンクは、無方向性であり、つまり、ＢがＡにリンクされる場合かつその場合に限り、ＡがＢにリンクされることを意味する。いずれの購入者も、複数の販売者につながることができ、逆も然りである。ネットワーク構造は、共通情報であり、全ての提案及び許諾も同様である。実施化の場合、我々の同種の商品は、それぞれのつながり、商取引の合意、又はブロックチェーン内のデータへのアクセスに関するサービスレベルの合意である。
【００３２】
特に、価格は、全販売者にわたって同時に上昇する。購入者は、価格が自己の査定額を超えると（英語又は競り上げ口頭オークションで行われるように）、ドロップアウトする。購入者がドロップアウトすると、これらの販売者に依然としてリンクされた残りの購入者が出現し、これらの販売者は販売者セットを下回る。これらの販売者は、自身にまだリンクされている購入者と取引する。リンクパターンを前提として、誰が誰と取引するかの正確なマッチングを慎重に行って、トランザクションの数を最大限にする。これらの販売者及び購入者は、マーケットから除外されて、価格は、残りの販売者の間で上昇し続け、処理は繰り返す。市場価格が消去されると、エージェントがグラフ又はサブグラフを更新して、ブロックチェーン内の１又は複数の元帳が更新される。メインエージェントベースのグラフ処理が、リンクをサブグラフに分割して、より迅速な処理を可能にし、ネットワークにおけるペイオフは、以下のようにゲーム理論確率に基づく。
【００３３】
ステップ１ａ：同じ見込み客に全てリンクされた２又は３以上の販売者の識別。グラフ内の購入者の他のリンクに関わらず、方法は、この販売者セット及び購入者を削除して、次に購入者は、ペイオフ又は１を取得して、販売者は、０のペイオフを受け取る。
【００３４】
ステップ１ｂ：残りのネットワークから、ステップ１ａを繰り返して、ネットワークのバランスを取るために購入者及び販売者が反転される。
【００３５】
ステップｋ：誘導的にｋに進み、少なくともｋ人の販売者のサブセットのサブグラフ内で識別確認をするたびに、ｋ人未満の購入者のセットの一部に、又はグラフ内でｋ人未満の販売者のセットの一部にリンクされた少なくともｋ人の購入者のサブセットにまとめてリンクされる。ｋは、この場合のネットワークノード処理の最大数である。
【００３６】
終了：方法が反復して、サブグラフの全てを識別してこれらを削除する場合、残りのネットワーク内の購入者及び販売者は、販売者及び購入者のあらゆるサブセットができるだけ多くの購入者にリンクされ、その逆も行われるようになっており、サブネットワーク内の購入者及び販売者が合意に達して、サブネットワーク内で１／２のペイオフのナッシュ均衡をそれぞれ取得する。また、これはパレート最適につながると考えている。
【００３７】
我々のネットワークに関して、元帳がクリアになり、我々の場合の市場価格を作り出すように、市場における均衡を見出すための非常に簡単な処理を有する。
【００３８】
複数の販売者から購入する購入者は、それぞれの販売者の各々からの同じ価格を見込む。
【００３９】
所与の販売者の価格は、購入者ごとに、この販売者に由来する購入者の総購入のファクション（ｆａｃｔｉｏｎ）を計算して、次に購入者にわたって合計することによって見出される。
【００４０】
所与の販売者の価格は、ネットワーク内の販売者の次数中心性ほど高くなく、販売者と関連する１／ｍｉｎ次数（ｎｕｍ＿ｂｕｙｅｒｓ）ほど低くない。
【００４１】
医療ＥＤＩトランザクション（ＡＳＣ  Ｘ１２  ４０１０／５０１０）
医療トランザクションの処理は、現在、ポイント−ポイントソリューションをカバーする手動合意から成る。これらの関連付けは、セットアップ及び保守するのに技術担当者及び管理担当者の著しい努力を要する。このシナリオでは、提案する公開ブロックチェーンソリューションが、トランザクションをカバーする自動スマートコントラクト、並びに要求を満たす取引相手の自動のサービスレベル合意ベースの選択を助長することができる。
【００４２】
リファラルの一般的なワークフロー例を図４に示す。このシナリオは、複数のブロックチェーントランザクションによって実現され、個人のパーソナルヘルスレコード（ＰＨＲ）のアセット及び適格性チェック及び応答（Ｘ１２  ２７０／２７１）が、リファラル（Ｘ１２  ２７８）への入力として、医療提供者の専門性と組み合わされる。ヘルスブロックチェーンネットワークを用いれば、これらのトランザクションは、未完了の入力を含むトランザクションとして通知することができる。ネットワークに参加中の医療提供者は、必要な専門性を有する適切な医療提供者（アセット）で、未完了の入力を満たすことができる。支払人、又は支払人の代わりにスマートコントラクトの下で機能するクリアリングハウスが、必要な適格性入力（アセット）の未完了の入力を満たすことができる。未完了の入力が全て満たされると、トランザクションは妥当性確認されて、永続的ブロックチェーン元帳内の次のブロックに委任されることになる。
【００４３】
一般的なＡＳＣ  Ｘ１２リファラルトランザクションを実施するためのスマートコントラクトの疑似コードは以下の通り：
適格性トランザクション
2018533103.tif 000006
ＰＨＲトランザクション
2018533103.tif 000007
リファラルトランザクションは、適格性トランザクション及びＰＨＲトランザクションからの出力の入力を受け取る
2018533103.tif 000008
【００４４】
患者行動及びリスクプール格付けされた医療保険
パーソナルヘルストラッカーの出現により、新規の医療保険は、消費者の健康において積極的な役割を担うために消費者に報酬を与える。運転監視装置、例えば、Ｐｒｏｇｒｅｓｓｉｖｅ  Ｓｎａｐｓｈｏｔ（登録商標）(ｈｔｔｐｓ：／／ｗｗｗ．ｐｒｏｇｒｅｓｓｉｖｅ．ｃｏｍ／ａｕｔｏ／ｓｎａｐｓｈｏｔ／)の設置に関して値引きを提供する車両保険プランと同様に、これらのプランは、通常、フィットネストラッキングデバイスの製造業者によって促進され、パートナーシップ、例えば、Ｆｉｔｂｉｔ  Ｗｅｌｌｎｅｓｓ  Ｐａｒｔｎｅｒｓ(ｈｔｔｐ：／／ｗｗｗ．ｆｉｔｂｉｔ．ｃｏｍ／ｆｉｔｂｉｔ−ｗｅｌｌｎｅｓｓ／ｐａｒｔｎｅｒｓ)が形成されている。ヘルスブロックチェーンネットワークは、消費者の健康データのよりオープンな配布を助長し、ＰＨＲと同様にこれを保護し、従って、消費者、医療提供者、及び支払人の、特定のデバイス技術又は医療保険への固定化を防ぐことになる。特に、ＰＨＲデータはブロックチェーン上で管理されるので、消費者及び／又は企業は、このデータへのアクセスを支払人に許可することができ、支払人は、個人ベースで又は個人の健康データを含む企業全体の従業員ベースでグループ分析を実行して、個人及び／又は組織のリスクスコアを生成することができる。この情報をもつことで、その後、支払人は、特定の組織用に作成された医療保険に入札することができる。次に、同様にブロックチェーン上で管理される登録が、現在のところ一般的な毎年の管理オーバーヘッド処理の代わりに、図５に示すようなリアルタイムの裁定処理になることができる。
【００４５】
患者行動ベースの医療保険を実施するためのスマートコントラクトの疑似コードは以下の通り。
2018533103.tif 000009
【００４６】
患者及び医療提供者のデータ共有
患者のヘルスブロックチェーンウォレットは、全アセットを格納し、次にこれが、臨床文書がＨＬ７又はＦＨＩＲフォーマットのいずれであろうと、実際のデータへの参照ｉｄ、行動及び睡眠周期の健康メトリクス、又は請求及び登録情報を格納する。これらのアセット及びアセットへのアクセス許可の制御は、患者にのみ与えられる。ヘルスブロックチェーンのオープンな配布を前提とすれば、参加するいずれの医療提供者にも、スマートコントラクトへの強制力のある制約を用いて、データへのフルアクセス又は部分アクセスを即時的かつ自動的に与えることができる。
【００４７】
新規の患者が初めて受診する今日の典型的な診察シナリオにおいて、担当医は、待っている間に患者によって記入された手続き書類以外の過去の履歴をもたない。これは時間の浪費であり、診察の効果を減ずる。
【００４８】
ヘルスブロックチェーンを利用すれば、患者のＰＨＲへのアクセスを、診療予約の一環として、リファラルトランザクション中に、又は診療到着時に許可することができる。また、アクセスは、完全な患者の制御の下で容易に解除することができる。
【００４９】
医院への到着時に、患者のヘルスブロックチェーンウォレットのプロキシであるパーソナルブルートゥース（登録商標）対応デバイス上でモバイルアプリケーションを実行中の患者を、ブルートゥース近接センサが識別することができるシナリオを図６に示す。このモバイルウォレットプロキシは、到着を医療提供者の医院に自動的に通知して、患者のＰＨＲへのアクセスを許可するように構成することができる。この時点で、担当医は、患者の既往歴全体へのアクセスを有することになる。
【００５０】
患者及び医療提供者のデータ共有を実施するためのスマートコントラクトの疑似コードは、以下の通り。
2018533103.tif 000010
【００５１】
患者データの共有
患者のＰＨＲデータは、最適な医療提供のために必要な情報を医療提供者（医者）に与えるために、患者のパーソナルヘルスプロファイルにとって貴重な情報である。加えて、この臨床データはまた、臨床研究の集約シナリオにおいても貴重であり、この場合、この情報が、診断、治療、及び予後のために分析される。現在のところ、情報のソイル型格納及び患者の許可を得る困難性に起因して、この情報は取得が難しい。
【００５２】
実際のデータへの参照ｉｄとして全アセットを格納する患者のヘルスブロックチェーンウォレットを考慮する。これらのアセットは、臨床研究参加のための自動スマートコントラクト、或いは患者によって許容されるいずれかの他のデータ共有合意に含めることができる。アセットは、１回使用の透かし又はシリアルナンバーと同様に、ランダムな識別子又はノンスを文書に付加することによってインスタンス共有として共有することができ、次に、（元のソースから導出された）一意のアセットが特定のアクセス要求に関して生成されて、患者の健康記録情報に対する特定の要求のための入力としてスマートコントラクト内に含まれる。患者は、ＰＨＲへのアクセスのための支払い、許容可能なアクセスの時間枠、共有するＰＨＲデータのタイプ、共有したい病歴の長さ、非特定化閾値又は基本設定、評判、所属、目的、又は患者によって要求されるいずれの他の制約等の信頼属性に関するデータの消費者の特定の属性に関して、許容可能な条件をスマートコントラクトに指定することができる。患者のデータの属性はまた、利用可能な診断及び治療のタイプに関する、スマートコントラクトの特性として通知又は要約することができる。患者が、スマートコントラクトによって指定される一定の条件下でデータの共有を所望することを通知すると、これは患者の条件及び必要なＰＨＲのタイプへの関連性を満たすいずれかの消費者によって自動的に満足させることができ、結果として、関連するＰＨＲの分析用に使用するために、臨床研究のための自動的で効率的な分散型手段がもたらされる。図７に示すこの処理は、いずれかの所望の期間中に臨床研究をヘルスブロックチェーン上の自動実行に変化させ、要求され達成される重要性レベル又は財政的制限の許容可能な統計結果に終結することになる。
【００５３】
自動患者データ共有を実施するためのスマートコントラクトの疑似コードは、以下の通り。
2018533103.tif 000011
【００５４】
ヘルスブロックチェーンのデータ要素
ブロックチェーン上に格納された実際のデータ、アセット、コントラクト、ＰＩＩ等は、実際には、図１に示すようなデータ、場所、及びアクセスを一意に識別する資源識別子である。ヘルスブロックチェーンに参加するアプリケーションで、特徴の全てを完全に実施して、資源識別子によって示される実際のデータ要素を格納して配布するアプリケーションを図２に示す。また、このヘルスブロックチェーンアプリケーションスタックは、アグリゲーション方法を通じて、資源ｉｄへのアクセスをプロキシすることができ、この場合、データは、レガシーＰＨＲ／ＰＭ／ＥＭＲ／ＥＨＲ及びＸ１２  ＥＤＩシステム内に格納される。ブロックチェーンのデータ構造の実施例は以下の情報に帰着する。
患者
基本人口統計
・名
・姓
・ミドルネーム
・プリフィックス（Prefix）
・サフィックス（Suffix）
・性別
・誕生日
・住所
・電話
・電子メール
保険情報
・メンバーＩＤ
・グループＩＤ
・全免責金額
・残りの免責金額
・扶養家族
健康記録
・継続的診療文書（Ｃｏｎｔｉｎｕｉｔｙ  ｏｆ  Ｃａｒｅ  Ｄｏｃｕｍｅｎｔ）
・診察記録
・退院要約
・病歴及び健康診断記録
・手術記録
・治療記録
・経過記録
・非構造化文書
・請求履歴
・適格性履歴
マーケットプレイスとの対話
・検索済み専門性
・検索済み条件
・購入済み
・ログイン頻度
・格付けされた／レビューされた医療提供者
ウェアラブルＡＰＩを介して自己報告される健康統計値
・ＢＭＩ
・喫煙者状況
・活動レベル
・ウェルネス制度メンバーシップ
財政情報
・ＦＩＣＯクレジットスコア
・クレジットレポート
・資産／債務
・レンディングクラブ（Ｌｅｎｄｉｎｇ  Ｃｌｕｂ）からの融資データ
ソーシャルネットワーク・インタラクションデータ
ソーシャルネットワーク対話データ
・ツイッター（登録商標）、フェイスブック、リンクト（ｌｉｎｋｅｄ）
ウェアラブルＡＰＩデータ
・測定された活動レベル
・睡眠周期
医療提供者
医療提供者の人口統計
・名
・姓
・ミドルネーム
・プリフィックス（Prefix）
・サフィックス（Suffix）
・性別
・誕生日
・住所
・電話
・電子メール
・ライセンス付与
医学教育
・メディカルスクールの場所及び在籍時期
・卒業日
・研修医期間／特別研究員の場所と時期
・専門性
・資格
・検定
・契約先病院
価格設定
・メディケアからの提示及び支払価格
・現金価格
・マーケットプレイスにリストされたサービス
・見積依頼への回答
格付け、レビュー、評価
・マーケットプレイスからのレビュー及び格付け
・米国医師会から受け取る、国家免許交付組織からの医療過誤制裁
・格付け及びレビュー
請求統計
・治療あたりの提出された請求数、提示価格、補償された価格
・治療あたりの拒否された請求数
支払人（別名  保険業者、取引相手）
Ｘ１２ヘルストランザクションの処理により、システムは、以下の情報を容易に取得することができる：
・支払統計：支払人Ｘは、治療Ｙに関して平均でいくら支払うか？
・請求処理にかかる時間についての統計（すなわち、平均処理時間、治療あたりの平均時間、等）
・拒否された請求についての統計。一般的な請求及び支払人によって区分された請求を分析することで、請求が拒否されるであろう確率を判断するための予測モデルを構築できるようになる。
【００５５】
上記の記述は、説明目的のために、特定の実施形態を参照しながら説明されている。しかしながら、上記の例証的な議論は網羅的なものではなく、又は開示された厳密な形態に本開示を限定するものではない。上記の教示に照らして、多くの修正及び変形が可能である。実施形態は、本開示の原理及びその実際の応用を最も良く説明するために選択されて記載されており、これにより、当業者は、想定される特定の使用に適するような様々な修正と共に本開示及び種々の実施形態を最も良く利用できるようになる。
【００５６】
本明細書に開示するシステム及び方法は、１又は２以上の構成要素、システム、サーバ、電気製品、他の従部品を通じて実施することができ、或いはこのような要素間に分散させることができる。システムとして実施される場合、このようなシステムは、とりわけ、汎用コンピュータ内に見られるソフトウェアモジュール、汎用ＣＰＵ、ＲＡＭ等の構成要素を含むこと及び／又は伴うことができる。サーバ上にイノベーションが存在する実施構成では、このようなサーバは、汎用コンピュータ内に見られるような、ＣＰＵ、ＲＡＭ等の構成要素を含むこと又は伴うことができる。
【００５７】
付加的に、本明細書のシステム及び方法は、上記で説明するもの以外の異種の又は全く異なるソフトウェア、ハードウェア、及び／又はファームウェア構成要素による実施を通じて実現することができる。このような他の構成要素（例えば、ソフトウェア、処理構成要素等）及び／又は本発明に関連する又はこれを具現化するコンピュータ可読媒体に関しては、例えば、本明細書のイノベーションの態様は、数多くの汎用又は専用コンピューティングシステム又は構成と一致して実施可能である。本明細書のイノベーションと共に使用するのに適した種々の例示的なコンピューティングシステム、環境、及び／又は構成は、限定ではないが、パーソナルコンピュータ内の又はパーソナルコンピュータ上で具現化されたソフトウェア又は他の構成要素、ルーティング／接続構成要素等のサーバ又はサーバコンピューティングデバイス、ハンドヘルド又はラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、消費者電子デバイス、ネットワークＰＣ、他の既存のコンピュータプラットフォーム、上記のシステム又はデバイス等の１又はそれ以上を含む分散型コンピューティング環境を含むことができる。
【００５８】
一部の例では、システム及び方法の態様は、例えば、このような構成要素又は回路に関連して実行される、プログラムモジュールを含む論理及び／又は論理命令を通じて実現し又はこれらによって実行することができる。一般に、プログラムモジュールは、本明細書の特定のタスクを実行し又は特定の命令を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含むことができる。本発明はまた、分散型ソフトウェア、コンピュータ、又は通信バス、回路、又はリンクを通じて回路が接続される回路設定との関連でも実施可能である。分散型設定では、制御／命令は、メモリストレージデバイスを含むローカル及びリモートの両方のコンピュータストレージ媒体から行うことができる。
【００５９】
本明細書のソフトウェア、回路、及び構成要素はまた、１又は２以上のタイプのコンピュータ可読媒体を含むこと及び／又は利用することもできる。コンピュータ可読媒体は、このような回路及び／又はコンピューティング構成要素上に常駐し、これらに関連付けられ、又はこれらによってアクセスすることができるいずれかの利用可能な媒体とすることができる。実施例として、限定ではないが、コンピュータ可読媒体は、コンピュータストレージ媒体及び通信媒体を含むことができる。コンピュータストレージ媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータ等の情報の格納のためのいずれかの方法又は技術で実施される揮発性及び不揮発性、取り外し可能及び取り外し不可の媒体を含む。コンピュータストレージ媒体は、限定ではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）又は他の光学式ストレージ、磁気テープ、磁気ディスクストレージ又は他の磁気ストレージデバイス、或いは所望の情報を格納するために使用可能でコンピューティング構成要素によってアクセス可能ないずれかの他の媒体を含む。通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、及び／又は他の構成要素を含むことができる。更に、通信媒体は、有線ネットワーク又はダイレクト有線接続等の有線媒体を含むことができるが、本明細書のいずれのこのようなタイプの媒体も、一時的媒体は含まない。上記のいずれかの組合せもまた、コンピュータ可読媒体の範囲内に含まれる。
【００６０】
本説明において、構成要素、モジュール、デバイス等の用語は、様々な方法で実施可能ないずれかのタイプの論理的又は機能的ソフトウェア要素、回路、ブロック及び／又はプロセスを指すことができる。例えば、種々の回路及び／又はブロックの機能を相互に組み合わせて、いずれかの他の数のモジュールにすることができる。各モジュールは、有形メモリ（例えば、ランダムアクセスメモリ、読み取り専用メモリ、ＣＤ−ＲＯＭメモリ、ハードディスクドライブ等）上に格納されたソフトウェアプログラムとして実施することさえ可能であり、これは、本明細書のイノベーションの機能を実施するために中央処理ユニットによって読み出される。或いは、モジュールは、汎用コンピュータに又は伝送搬送波を介して処理／グラフィックスハードウェアに送信されるプログラミング命令を含むことができる。また、モジュールは、本明細書のイノベーションによって包含される機能を実施するハードウェア論理回路として実施することができる。最後に、モジュールは、専用命令（ＳＩＭＤ命令）、フィールドプログラマブル論理アレイ、又は所望のレベルの性能及びコストを提供するこれらのいずれかの混合を用いて実施可能である。
【００６１】
本明細書に開示するように、本開示に適合する特徴は、コンピュータハードウェア、ソフトウェア、及び／又はファームウェアを介して実施することができる。例えば、本明細書に開示するシステム及び方法は、例えば、データベース、デジタル電子回路、ファームウェア、ソフトウェア、又はこれらの組合せも含むコンピュータ等のデータプロセッサを含む様々な形式で具現化することができる。更に、開示する実施の一部では、特定のハードウェア構成要素について説明しているが、本明細書のイノベーションに適合するシステム及び方法は、ハードウェア、ソフトウェア、及び／又はファームウェアのいずれかの組合せで実施することができる。更に、本明細書のイノベーションの上述の特徴及び他の態様及び原理は、様々な環境で実施することができる。このような環境及び関連するアプリケーションは、本発明による種々のルーチン、処理、及び／又は動作を実行するように特別に構築することができ、或いは、必要な機能を提供するためのコードによって選択的にアクティブにされ又は再構成される汎用コンピュータ又はコンピューティングプラットフォームを含むことができる。本明細書に開示する処理は、いずれかの特定のコンピュータ、ネットワーク、アーキテクチャ、環境、又は他の装置に内在的に関連するわけではなく、ハードウェア、ソフトウェア、及び／又はファームウェアの適切な組合せによって実施することができる。例えば、様々な汎用マシンを、本発明の教示に従って記述されたプログラムで使用することができ、或いは、所望の方法及び技術を実行するために専用装置又はシステムを構築するほうが、利便性が高い場合がある。
【００６２】
本明細書で説明する方法及びシステムの態様、例えば論理はまた、フィールド・プログラマブル・ゲート・アレイ（「ＦＰＧＡ」）、プログラマブルアレイ論理（「ＰＡＬ」）デバイス、電気的にプログラム可能な論理及びメモリデバイス、及び標準的なセルベースのデバイス等のプログラマブル論理デバイス（「ＰＬＤ」）、並びに特定用途向け集積回路を含む様々な回路のいずれかにプログラムされた機能として実施することもできる。態様を実施するためのいくつかの他の可能性は、メモリデバイス、メモリ（ＥＥＰＲＯＭ等）を有するマイクロコントローラ、埋込み型マイクロプロセッサ、ファームウェア、ソフトウェア等を含む。更に、態様は、ソフトウェアベースの回路エミュレーション、個別論理（シーケンシャル及び組み合わせの）、カスタムデバイス、ファジー（ニューラル）論理、量子デバイス、及び上述のデバイスタイプのいずれかの混成を有するマイクロプロセッサ内で具現化することができる。基本となるデバイス技術は、種々の構成要素タイプ、例えば相補型金属酸化物半導体（「ＣＭＯＳ」）のような金属酸化物半導体電界効果トランジスタ（「ＭＯＳＦＥＴ」）技術、エミッタ結合論理（「ＥＣＬ」）のようなバイポーラ技術、ポリマー技術（例えば、シリコン共役ポリマー及び金属共役ポリマー金属の構造）、アナログ及びデジタル混合、等において提供することができる。
【００６３】
本明細書に開示する種々の論理及び／又は機能は、ハードウェア、ファームウェアのあらゆる数の組合せを用いて、及び／又は様々なマシン可読又はコンピュータ可読媒体で具現化されるデータ及び／又は命令として、これらの挙動、レジスタ転送、論理構成要素、及び／又は他の特性に関して可能にすることができる点にも留意されたい。このようなフォーマットされたデータ及び／又は命令を具現化することができるコンピュータ可読媒体は、限定ではないが、様々な形式（例えば、光学式、磁気、又は半導体ストレージ媒体）の不揮発性ストレージ媒体を含むが、ここでも一時的媒体は含まない。説明にわたって、「備える(ｃｏｍｐｒｉｓｅ)」、「備えている(ｃｏｍｐｒｉｓｉｎｇ)」等の単語は、文脈が明らかに別のものを必要としていない限り、排他的又は網羅的な意味とは対照的な包括的な意味、即ち、「限定ではないが、含んでいる(ｉｎｃｌｕｄｉｎｇ，  ｂｕｔ  ｎｏｔ  ｌｉｍｉｔｅｄ  ｔｏ)」の意味で解釈されるべきである。単数又は複数を使用する単語はまた、複数又は単数をそれぞれ含む。付加的に、「ここに」、「以下に」、「上記の」、「以下の」という語及び同様の意味の単語は、本出願のいずれか特定の部分ではなくこの出願を全体として参照している。「又は（ｏｒ）」という単語が、２又は３以上の項目のリストに関連して用いられている場合、当該単語は、当該単語の以下の解釈、すなわち、リスト内の項目のいずれか、リスト内の項目の全て、及びリスト内の項目のいずれかの組み合わせの全てを網羅する。
【００６４】
本発明の特定の現在好ましい実施について、本明細書では特に説明してきたが、本発明が関連する当業者には、本発明の精神及び範囲から逸脱することなく、ここに示して説明した種々の実施の変形及び修正を加えることができる点は明らかになるであろう。従って、本発明は、法の適用規則によって要求される範囲のみに限定されることが意図される。
【００６５】
上記は、本開示の特定の実施形態を参照してきたが、本開示の原理及び精神から逸脱することなく実施形態に変更を加えることができ、本開示の範囲は添付の特許請求の範囲によって定義されることは、当業者であれば理解されるであろう。
【符号の説明】
【００６６】
１００  分散型医療のためのシステム
１０２  アプリケーション
１０４  バックエンドシステム
１０６  通信経路
１０４Ａ  ヘルスブロックチェーンネットワーク１
１０４Ｂ  ヘルスブロックチェーンネットワーク２
１０４Ｎ  ヘルスブロックチェーンネットワーク（Ｎ番目）
１０８  ヘルスデータソース
【図１】
2018533103.tif 000012
【図１Ｂ】
2018533103.tif 000013
【図２】
2018533103.tif 000014
【図３】
2018533103.tif 000015
【図４】
2018533103.tif 000016
【図５】
2018533103.tif 000017
【図６】
2018533103.tif 000018
【図７】
2018533103.tif 000019
【国際調査報告】
2018533103.tif 000020