JP2018506779A - ヘルスケアデータ相互交換システム及び方法 - Google Patents

Abstract

ローカルヘルスケア基盤に統合されて、標的とするコミュニティのスケーラビリティにステージを設定して、コミュニティにおいて患者中心及び価値に基づくケアを提供するケア管理フレームワークを作成することができるスケーラブル技術コアの一部であるヘルスデータシステム。

Description

関連出願の相互参照

本願は、２０１５年１月１６日に出願された米国仮特許出願第６２／１０４，５３２号に対する優先権を主張し、この仮特許出願の開示内容は、あらゆる目的のために全体として参照により本明細書に明示的に援用される。

本発明は、ヘルスケアデータ相互交換システム及び方法に関する。

多くの国々及び米国内の州は、公衆衛生の低下、慢性疾患の患者数の増大、及び救急処置システムで患者をケアする法外に高いコストに起因して、差し迫ったヘルスケアクライシスに直面している。現在の疾患管理プログラムは、主に手作業でのサイロ型介入に依存しており、これは労力集約的且つ非スケーラブルである。

本開示は、ローカルヘルスケア基盤に統合されて、標的とするコミュニティのスケーラビリティにステージを設定して、コミュニティにおいて患者中心及び価値に基づくケアを提供するケア管理フレームワークを作成することができるスケーラブル技術コアの一部であるヘルスデータシステムに関する。

本明細書に開示される第１の態様によれば、患者中心及び価値に基づくケアを提供するヘルスデータシステムであって、
ヘルスデータサーバと、
セキュアネットワークを介してヘルスデータサーバと通信する１つ又は複数のヘルスデータソースであって、それぞれポーリング許可の組を有する、１つ又は複数のヘルスデータソースと、
識別子の組及びポーリング許可の組に基づいて、指定された頻度でデータソースからヘルスデータをポーリングする、ヘルスデータサーバの１つ又は複数のエージェントモジュールと、
ポーリングされたヘルスデータを共通情報モデルに提供する第１のスイッチモジュールであって、共通情報モデルは、少なくとも１つの患者記録により定義され、各患者記録は１つ又は複数の属性を有する、第１のスイッチモジュールと、
アクセス許可の組に基づいて、共通情報モデルへのアクセスを取得する１つ又は複数のインタフェースモジュールと
を備えるヘルスデータシステムが記載される。

開示されるシステムの幾つかの実施形態では、共通情報モデルは分散データベースを含み、１つ又は複数の属性は、任意選択的に、臨床ヘルスデータ、研究データ、遠隔モニタリングデータ、バイオメトリクス、ウェアラブル、ソーシャルメディアデータ、自己報告データ、モバイルアプリケーションデータ、及びデバイス機器のうちの少なくとも１つを定義する。

開示されるシステムの幾つかの実施形態では、第１のスイッチモジュールは、ポーリングされたヘルスデータが１つ又は複数の属性にマッピングされない場合、共通情報モデルを新しい属性で増補する。

開示されるシステムの幾つかの実施形態では、第１のスイッチモジュールは、任意選択的にヘルスデータサーバ及び１つ又は複数のヘルスデータソースのうちの少なくとも一方により提供される記憶許可に基づいて、ポーリングされたヘルスデータを共通情報モデルに提供する前に、ポーリングされたヘルスデータをフィルタリングすること、患者記録を互いと突き合わせて照合すること、及びセキュアネットワークを介するネットワーク接続を制御することの少なくとも１つを行う。

開示されるシステムの幾つかの実施形態では、指定される頻度は、ヘルスデータサーバ及び１つ又は複数のヘルスデータソースのうちの少なくとも一方により設定される。

開示されるシステムの幾つかの実施形態では、本システムは、ポーリングされたヘルスデータを共通情報モデルに提供する第２のスイッチモジュールを含み、前記第１のスイッチモジュールは、前記第２のスイッチモジュールと通信して、ポーリングされたヘルスデータを受信する。

本明細書に開示される別の態様によれば、患者中心及び価値に基づくケアを提供する方法であって、
ヘルスデータサーバの１つ又は複数のエージェントモジュールを介して、ヘルスデータの１つ又は複数のヘルスデータソースをポーリングするステップであって、１つ又は複数のヘルスデータソースのそれぞれはポーリング許可の組を有する、ステップと、
第１のスイッチモジュールを介して共通情報モデルにポーリングされたヘルスデータを投入するステップであって、共通情報モデルは少なくとも１つの患者記録により定義され、各患者記録は１つ又は複数の属性を有する、ステップと、
アクセス許可の組に基づいて、１つ又は複数のインタフェースモジュールを介して共通情報モデルへのアクセスを提供するステップと
を含む方法が記載される。

開示される方法の幾つかの実施形態では、共通情報モデルに投入するステップは、分散データベースに、任意選択的に、臨床ヘルスデータ、研究データ、遠隔モニタリングデータ、バイオメトリクス、ウェアラブル、ソーシャルメディアデータ、自己報告データ、モバイルアプリケーションデータ、及びデバイス機器のうちの少なくとも１つから選択される１つ又は複数の属性を投入するステップを含む。

開示される方法の幾つかの実施形態では、本方法は、ポーリングされたヘルスデータが第１のスイッチモジュールを介して１つ又は複数の属性にマッピングされない場合、共通情報モデルを新しい属性で増補するステップを更に含む。

開示される方法の幾つかの実施形態では、本方法は、前記投入するステップの前に、記憶許可の組に基づいて、ポーリングされたヘルスデータをフィルタリングするステップを更に含む。

開示される方法の幾つかの実施形態では、記憶許可の組は、ヘルスデータサーバ及び１つ又は複数のヘルスデータソースのうちの少なくとも一方により提供される。

開示される方法の幾つかの実施形態では、ポーリングするステップは、ヘルスデータサーバ及び１つ又は複数のヘルスデータソースのうちの少なくとも一方により設定される指定頻度で行われる。

開示される方法の幾つかの実施形態では、本方法は、第１のスイッチモジュールを介して患者記録を照合するステップを更に含む。

開示される方法の幾つかの実施形態では、本方法は、第１のスイッチモジュールを介して、ポーリングされたヘルスデータに関して第２のスイッチモジュールをポーリングするステップを更に含む。

開示される方法の幾つかの実施形態では、ポーリングするステップは、ポーリング許可の組により制限される。

ヘルスデータシステムの実施形態を示す例示的なネットワーク図である。 図１のヘルスデータシステムの代替の実施形態を示す例示的なネットワーク図である。 図１及び図２のヘルスデータシステムによりヘルスケアデータを取得し処理する方法の実施形態を示す例示的なフローチャートである。 図１及び図２のヘルスデータシステムによりヘルスケアデータを取得し処理する方法の実施形態を示す例示的なフローチャートである。 消費者の健康問題を定義し、それを解決するエコシステムを作成し、ケア提供ネットワークをモニタリングして、健康の恩益が実現される場所を識別し、且つ関連付けられたコスト節減を分離して、様々なステークホルダに再分配する例示的な方法である。 ヘルスケアエコシステムの実施形態を示す例示的なネットワーク図である。

図が一定の縮尺で描かれておらず、同様の構造又は機能の要素は、一般に、例示を目的として、図全体を通して同様の参照番号で表されることに留意されたい。図は、好ましい実施形態の説明の促進のみを目的とすることにも留意されたい。図は、記載される実施形態のあらゆる態様を示しているわけではなく、本開示の範囲を限定しない。

新興の技術解決策がヘルスケア提供を変えようとしている。図１及び図２に示されるようなヘルスデータシステム１００は、他のシステムと共に使用されて、効果的な疾患管理及びケアを拡大及び加速させるように設計された、技術により可能となるデータ駆動解決策の一式を実施することができる。例えば、ヘルスデータシステム１００は、ローカルヘルスケア基盤に統合されて、標的とするコミュニティのスケーラビリティにステージを設定して、コミュニティにおいて患者中心及び価値に基づくケアを提供するケア管理フレームワークを作成することができるスケーラブル技術コアの一部であることができる。

様々な実施形態では、可動性及びアクセス、セルフサービス可能であり、データ流動性及び連続性を有するように設計された消費者中心のシステムを構成することが有利であり得る。診断ではなく、個人を治療するように構成された（例えば、状況に当てはまった健康プロファイルを使用し、長期的、生理学的、且つ挙動的な社会的データ及び環境データを利用することにより）個人化システムを有することも有利であり得る。価値が健康結果により駆動される、結果に基づくシステムを有することが更に有利であり得、品質は、安全及びエビデンスに基づくケアにより定義され、効率は、キャパシティ、性能、可用性、及びコストの最適な割り振りを通して達成され、有効性は、社会的要因及び環境的要因による影響を受ける個人の嗜好及び能力に基づいて個人化される。望ましいシステムは、後手となる一時的なケアを超え、集団の区分化及び層化を含み、慢性疾患ケア調整計画を含み、長期健康管理計画を含み、消費者教育計画を含む、先を見越した健康管理を含むこともできる。

ヘルスデータの取得、記憶、キュレート、分析、及び／又はヘルスデータへのアクセス提供を提供するヘルスデータシステム１００は、望ましさを証明し、本明細書に詳述される広範囲の用途へのベースを提供することができる。この結果は、本明細書に開示される一実施形態によれば、図１に示されるようなヘルスデータシステム１００により達成することができる。

図１を参照すると、ヘルスデータシステム１００は、複数のデータソースデバイス１１０、ヘルスデータサーバ１２０、及び複数のユーザデバイス１３０を備えるものとして示される。幾つかの実施形態では、ユーザデバイス１３０は、ヘルスデータシステム１００から利用可能なユーザサービスを表す。データソースデバイス１１０及びユーザデバイス１３０は、任意の組合せの無線リンク及び有線リンクからなることができるセキュアネットワーク１４０により、ヘルスデバイスサーバ１２０に接続される。データソースデバイス１１０は、スマートフォンデータソース１１０Ａ、ラップトップデータソース１１０Ｂ、及びサーバデータソース１１０Ｃを備えるものとして示されるが、更なる実施形態では、デスクトップコンピュータ、タブレットコンピュータ、ゲームデバイス、スマートテレビ、ヘッドセットコンピュータ、スマートウォッチ、ボディモニタデバイス等を含め、任意の適するデバイスがデータソース１１０を構成することができる。更に、様々な実施形態は、任意の適する数の任意のそのようなデータソースデバイス１１０を含むことができる。

同様に、ユーザデバイス１３０は、スマートフォンユーザデバイス１３０Ａ及びラップトップユーザデバイス１３０Ｂから呼び出されるものとして示されるが、更なる実施形態では、ユーザデバイス１３０は、サーバ、デスクトップコンピュータ、タブレットコンピュータ、ゲームデバイス、スマートテレビ、ヘッドセットコンピュータ、スマートウォッチ、ボディモニタデバイス等を含め、任意の適するデバイスを含むことができる。更に、様々な実施形態は、任意の適する複数の任意のそのようなユーザデバイス１３０を含むことができる。

サーバ１２０は１つ又は複数のサーバシステムを含むことができ、サーバシステムは、任意の適する複数のデバイス及び／又はクラウドベースのシステムを含むことができる。更に、サーバ１２０は、複数のモジュール、データベース等を含むことができる。例えば、図２は、１つ又は複数のエージェントモジュール２０５、セキュリティモジュール３０９、市場規則モジュール及び／又はデータベース３１０、スイッチモジュール３１１、共通情報モデルモジュール及び／又はデータベース３１２、ビッグデータストア３１３、及びＡＰＩ３１４を備えるヘルスデータシステム１００の一実施形態を示し、これらの構成要素はクラウドベースのサーバシステム１２０の一部である。図２に示されるクラウドベースのサーバシステム１２０は、単に例示を目的として、プライベートクラウドとして実施される。

様々な実施形態によれば、サーバ１２０は、データソースデバイス１１０から得られたデータを受信、処理、及び記憶するように構成される（例えば、図３参照）。サーバ１２０は、ユーザデバイス１３０が提供し得る様々なクエリ又はデータ要求に応答して、記憶されたデータを処理及び／又は検索し、１つ又は複数のユーザデバイス１３０に提供するように構成することもできる（例えば、図４参照）。

図１及び／又は図２を参照すると、１つ又は複数のデータソースデバイス１１０には、１つ又は複数のデータソース２０１を関連付けることができる。例えば、データソース２０１は、様々な潜在的なステークホルダ及び標的とされるヘルスエコシステム内のヘルスデータシステム１００を介しての共有に関してデータを承認し得る、関連付けられたデータソースを含むことができる。例えば、データソース２０１は、ヘルスケア提供者（例えば、データは電子医療記録、研究データであることができる）、医療保険会社／支払人（例えば、データは請求記録であることができる）、薬剤デバイス及び医療デバイス企業（例えば、データは臨床試験記録、副作用データであることができる）、研究（例えば、データはゲノムプロファイルであることができる）、政府／コミュニティヘルスプログラム（例えば、データは集団健康統計、パートナーシップデータベースであることができる）、及び／又は個人の患者（例えば、データはバイオメトリクス、活動／行動であることができる）を含むことができる。各データソース２０１は、それ自体の組の独自のデータアクセス制御規則を用いて独立して所有することができる。したがって、ヘルスデータシステム１００は、有利には、独立して開発されたヘルスデータサービスにより使用されるために、様々な場所に保持されるデータ（例えば、データソース２０１にわたり）へのアクセスを提供する（例えば、ユーザデバイス１３０を介して）。

各ステークホルダデータソース２０１は、共有を承認する特定のフィールド及び要素又はデータのサブセットを選ぶことができ、システム１００は、本明細書においてより詳細に説明され、図３に示されるように、識別されたデータの承認を管理し（例えば、許諾書／データ使用合意書を通して）、及び／又は識別可能なデータの承認を管理する（例えば、許諾書／仕事関係者同意書を通して）ことができる。所与のデータソースが関連付けられたデータの例が上述されたが、データソースは、限定されずに、任意の適するタイプのデータのソースを提供するか、又は任意の適するタイプのデータのソースであることができる。

図２のエージェントＡ〜Ｃ３０６、３０７、及び３０８は、手動及び／又は自動的に、データソース２０１からデータを取得、受信、及び／又はアクセスするように構成される分散エージェントモジュール２０５のアーキテクチャ例を表す。エージェントモジュール２０５には、１つ又は複数のデータソース２０１及び／又はデータソースデバイス１１０を関連付けることができ、所与のデータソース２０１又はデータソースデバイス１１０に、１つ又は複数のエージェントモジュール２０５を関連付けることができる。これらのエージェントモジュール２０５は、任意の必要とされるメタデータ／サポート要素（例えば、許諾書、アクセス権、ソース情報）が、データソース２０１から取得、受信、及び／又はアクセスされるデータと共に送信されることを保証する。

幾つかの実施形態では、データソース２０１内のウェブ対応ポータルを介して手動対話を行うことができ（例えば、１つ又は複数のデータソースデバイス１１０を介して）、データソース２０１の所有者は、エージェントモジュール２０５によりデータソース２０１からサーバ１２０にいずれのデータが送信されるかの決定を担う。自動対話は、特定の頻度で及び／又は所望のモニタリング基準に基づいてリアルタイムで実行されて、エージェントモジュール２０５により、いずれのデータがデータソース２０１からサーバ１２０に送信されるかを指定するように構成され（例えば、ビジネス規則等を用いて）、次にスケジュールされるスクリプトプログラムを介するものであることができる。エージェントモジュール２０５によりサーバ１２０に送信することができるデータソース２０１内のデータは、識別子により指定される。識別子は、データソース２０１内の患者記録を一意に識別する英数字文字列である。

ビジネス規則は、エージェントモジュール２０５において構成することができ、命名規則、データ系統追跡、識別可能データを共有する能力に基づく許可又は非許可ファイル、共有制限、及びデータ管理時にエージェントが従う他のステークホルダ組織固有の規則を含むことができる。幾つかの実施形態では、図２に示されるように、エージェントモジュール２０５は、データソース２０１の環境及び／又はファイアウォールを出る前に、サーバ１２０に送信されるデータを暗号化することができる。

様々な実施形態では、データソース２０１により定義される共有されるビジネス規則に従わないデータは、データソース２０１の環境内に留まり、エージェントモジュール２０５によりヘルスデータシステム１００内に運ばれない。幾つかの実施形態では、これは、ヘルスデータシステム１００が、データソース２０１がデータソース２０１の環境外で個人のデータを共有する個人からの許可を有さないことを暗示しなければならない（例えば、図３のブロック４０３、４０６、及び４０９）ように、共有への患者の許諾書が得られず、プライバシー慣行の通知が与えられたことを示すフラグを含まない識別可能データを含むことができる。

一実施形態では、選択されたエージェントモジュール２０５の実施は、以下のステップを含む：
１．エージェントモジュール２０５に、データソース２０１により提供されるデータを保持するデータデバイス１１０のＩＰアドレスで指定される；
２．エージェントモジュール２０５に、データソース２０１から入手可能な患者記録の識別子で指定される。識別子は、データソース２０１によりヘルスデータサーバ１２０に提供される；
３．エージェントモジュール２０５に、データソース２０１から患者記録についてのデータを取得する（ステップ２において設定された識別子を使用して）頻度が指定される。頻度は、ヘルスデータサーバ１２０及び／又はヘルスデータソース２０１により設定し得る；
４．セキュアネットワーク１４０は、ヘルスデータシステム１００とデータソース２０１との間に専用接続を確立する；
５．エージェントモジュール２０５は、専用ネットワーク接続（ステップ４において設定される）を使用して、指定された頻度（ステップ３において設定される）に従ってロケーション（ステップ１において設定される）から識別子（ステップ２において設定される）についてのデータをデータソース２０１から収集する；
６．エージェントモジュール２０５により収集されたデータは、ヘルスデータサーバ１２０内のメッセージキューに記憶される。このメッセージキューは、スイッチ３１１により処理される。エージェントモジュール２０５は、（＜属性＞，＜値＞）対のリストとして、データソースから収集されたデータを表す；
７．エージェントモジュール２０５は、ヘルスデータサーバ１２０がデータソース２０１により、データソース２０１からデータをもはや収集しないと通知されるまで実行し続ける；
８．随時、データソース２０１は、サーバ１２０に送信するために、エージェントモジュール２０５によりデータを収集することができる識別子のリストを変更することができる；
９．随時、データソース２０１は、エージェントモジュール２０５がデータソース２０１からデータを収集した（ステップ５において）１つ又は複数（又は全て）の識別子についてヘルスデータサーバ１２０内のデータソース２０１から入手可能なデータを終了するメッセージをヘルスデータサーバ１２０に送信することができる；
１０．随時、データソースは、ヘルスデータサーバ１２０から、いずれのデータがエージェントモジュール２０５によりデータソース２０１から収集されたかについてのリポートを取得することができる。

図２に示されるように、サーバ１２０はセキュリティモジュール３０９を備えることができ、セキュリティモジュール３０９は、サーバ１２０との通信がデータソースステークホルダのニーズ、規制要件、及び業界のベストプラクティスに従って承認／認証及び／又は暗号化されることを保証する（例えば、図３のブロック４０３、４０６、及び４０９参照）ように動作可能な１つ又は複数のセキュリティ構成要素を備えることができる。例えば、セキュリティモジュール３０９及びその構成要素は、任意のエージェント２０５又はヘルスデータサーバ１２０との直接ユーザ対話が妥当なビジネス規則等に準拠していることを保証するように構成することができる。幾つかの実施形態では、セキュリティモジュール３０９は、以下の構成要素等を含むことができる物理的及び／又は仮想的セキュリティ構成要素を備えることができる。
セキュリティインシデント及びイベント管理
・ログの収集、相関付け、及び通知
・外部インターネット攻撃及び脅威のモニタリング
・インターネット攻撃及び脅威のモニタリング
アイデンティティ及びアクセス管理
・ＡＰＩゲートウェイファイアウォール
・アイデンティティアクセス管理（ＩＡＭ）
・高度多要素認証
・細粒エンタイトルメントアクセス制御
・特権アクセス管理
データベースセキュリティ
・管理者からのデータベース情報のマスキング
・アクセスのデータベース監査及び会計
・データベース暗号化
ネットワークセキュリティ
・統合脅威管理（ＵＴＭ）ファイアウォール
・データ漏出阻止
・構成管理及びモニタリング
・脆弱性管理スキャン
・第三者デジタル証明書
・攻撃及び侵入テスト
・負荷分散装置
エンドポイントセキュリティ
・ハイパーバイザＶＭファイアウォールセキュリティ
・暗号化ボールトキー保護
・パッチ管理保護
・マルウェア保護

ヘルスデータサーバ１２０は、システム１００内で生じるデータフローの一部又は全てを制御する（例えば、図３のブロック４１１及び４１４参照）ことができる市場規則モジュール３１０を含むことができる。市場規則モジュール３１０内の規則は、ユーザデバイス１３０によるデータソース２０１からサーバ１２０内の何らかのデータへのアクセスを指定する。

一実施形態では、市場規則モジュール３１０は、以下のステップを特徴とする：
１．市場規則モジュール３１０にデータアクセス規則を構成するために、呼び出された市場規則は、ヘルスデータシステム１００に接続されたデータソース２０１毎に、データソース２０１によりヘルスデータサーバ１２０に提供される規則を含む構成ファイルをセットアップする
２．市場規則は以下の仕様を有する：
ａ．（＜ソースｉｄ＞＜記録ｉｄ＞＜サービスｉｄ＞＜ユーザｉｄ＞）：この規則は、＜サービスｉｄ＞により識別されたユーザデバイス１３０が、＜記録ｉｄ＞により識別され、＜ソースｉｄ＞により識別されるデータソース２０１により提供され、＜ユーザｉｄ＞により識別されるユーザデバイス１３０のユーザによるアクセスに利用可能な記録へのアクセスを有することができることを述べている；
３．ユーザデバイス１３０によるデータ要求を検証するために、市場規則モジュール３１０は、データソース２０１からユーザデバイス１３０により要求された特定の記録が、データソース２０１により指定された市場規則により許容されているか否かをチェックする。市場規則は、共通情報モデル３１２内で、２０５により収集された２０１からのデータを持続させないようにスイッチ３１１に通知するように指定することができる。この市場規則は以下の仕様を有することができる：（＜ソースｉｄ＞＜記録ｉｄ＞＜オンデマンド）：この規則は、＜ソースｉｄ＞により識別されたデータソース２０１からの＜記録ｉｄ＞により識別される記録が、共通情報モデル３１２に記憶されるべきではないことを述べている。この規則により識別されるデータソース２０１からの記録の場合、スイッチモジュール３１１は、この記録のクエリを共通情報モデル３１２に記憶し、ＡＰＩ３１４によりこの記録に対する要求が行われるとき、このクエリを実行する。

様々な実施形態では、ビジネス規則及び／又は市場規則は、データ一貫性チェック及びクリーニング、参照データ標準化、及びマスタ患者インデックス付け等のアルゴリズム及び論理の適用を促進して、データの再使用を促進し、データの複製又は誤表現を回避することができる。様々な実施形態では、これは、ヌル値及び測定単位の非一貫性の識別及び調整、並びに人口統計学的値を使用して、システム１００内の単一のグローバル識別子下の同じ個人の複数のステークホルダ記録を並べること等の動作を含むことができる。したがって、幾つかの実施形態では、ビジネス規則及び／又は市場規則は、複数のサービスにわたるデータを使用して、情報のプライバシーを保護しながらも、新規の洞察を導出できるようにすることができる。

ヘルスデータサーバ１２０は、１つ又は複数のスイッチモジュール３１１を含むこともできる。一実施形態では、スイッチモジュール３１１の実装形態は以下を含む：
１．選択されたスイッチモジュール３１１に、入力メッセージキューがセットアップされる。入力メッセージキューは、メッセージをエージェントモジュール２０５から受信する。各メッセージのフォーマットは、（＜属性＞，＜値＞）対のリストを含むことができる；
２．選択されたスイッチモジュール３１１に、データ品質エンジン（ＤＱＥ）によりデータ品質問題があることが分かった、データソース２０１から取得された記録を識別するメッセージをログするデータ品質キューがセットアップされる。ＤＱＥは、
ａ．各データソース２０１のデータ品質規則がシステム１００に接続し、
ｂ．データ品質規則が以下のフォーマット＜属性＞＜タイプ＞＜可能な値＞を含むことができ、
ｃ．入力メッセージキュー内のメッセージのいかなる属性も、そのデータソース２０１のデータ品質規則内のその属性で可能な値の組内に含まれた値を有さない場合、エージェントモジュール２０５によりスイッチモジュール３１１の入力メッセージキューに配置されたメッセージへのデータソース２０１に対応するデータ品質規則の適用がデータ品質問題をフラグする
ことを含む；
３．ヘルスデータサーバ１２０は、データソース２０１により解決するために、データ品質キューからのデータ品質メッセージをデータソース２０１に送信する；
４．入力メッセージキュー内のメッセージでデータ品質問題が検出されない場合、スイッチモジュール３１１は、メッセージ内のデータを共通情報モデル３１２内の対応するテーブルに積み込む。例えば、メッセージが、病院で所与の患者に投与される薬物についてのメッセージである場合、このメッセージの内容は、エージェントモジュール２０５がその患者のデータを収集した病院に関連付けられたデータソース２０１の識別子と共に、その患者の識別がタグ付けされた共通情報モデル３１２内の薬物テーブルに積み込まれる。データを共通情報モデル３１２に積み込むとき、１つ又は複数の符号化ディクショナリを使用して、メッセージ内の用語を標準用語にマッピングすることができる。例えば、血圧は高血圧にマッピングすることができる；
５．スイッチモジュール３１１は、照合エンジンを定期的に実行する。照合エンジンは、２つの異なるデータソース２０１からのデータが同じ患者に属する場合を検出する；
６．スイッチモジュール３１１に出力メッセージキューがセットアップされる。出力メッセージキューは、メッセージをＡＰＩモジュール３１４から受信する；
７．スイッチモジュール３１１は、その出力メッセージキュー内のメッセージ毎に市場規則モジュール３１０を呼び出す。市場規則モジュール３１０が、３１２からの要求データへのアクセスについてメッセージを検証する場合、スイッチモジュール３１１は、出力メッセージキュー内のメッセージを共通情報モデル３１２のクエリにマッピングする。クエリフォーマットは（＜ソースｉｄ＞，＜記録ｉｄ＞）であり、＜ソースｉｄ＞はデータソース２０１を識別し、＜記録ｉｄ＞はソース２０１からの記録を識別する。次に、このクエリは、スイッチ構成要素３１１により共通情報モデル３１２に対して実行される。スイッチ３１１により共通情報モデル３１２から得られたデータは、ＡＰＩ３１４によりユーザデバイス１３０に返される；
８．スイッチモジュール３１１は、エージェントモジュール２０５により収集されたデータソース２０１からのデータ内の非構造化属性に自然言語処理（ＮＬＰ）エンジンを適用する（非構造化属性は、３１２において、値として任意の長さの文字列を許す属性として識別される）。その結果生成されるデータは、（＜属性＞，＜値＞）リストを含み、これらのリストを使用して、共通情報モデル３１２内の対応するテーブルにデータを追加する。このようにして、スイッチ構成要素３１１は、２０１から共通情報モデル３１２内の構造化データへの非構造化データを低減する。そうすることにより、スイッチ構成要素３１１は、データソース２０１からの構造化データをデータソース２０１からの非構造化データと統合する；
９．スイッチモジュール３１１は、共通情報モデル３１２に記憶されているデータの生成に使用された任意のデータで、共通情報モデル３１２に記憶された各データをタグ付けする。このようにして、完全なデータ追跡可能性が共通情報モデル３１２内で維持される。例えば、３１２内で患者についての２組の薬物記録があり、ユーザデバイス１３０が一貫させた薬物モデルを生成する場合、共通情報モデル３１２に一貫させた薬物リストを記憶する前に、スイッチモジュール３１１は、一貫させた２つの薬物リストの識別子で、一貫させた薬物リストをタグ付けする；
１０．スイッチモジュール３１１は、データ除外サービスを実施して、データソース２０１からのデータを匿名化する。このサービスは、匿名化する必要があるリスト属性を用いて提供される。指定されたデータに対してデータ除外サービスが実行されると、識別された属性の値は、属性の値を保持することが許された記憶装置の各バイトをヌルバイト「０」で置換することによりマスキングされて、これらの属性の元の値の取得を不可能にする。同時に、データは、マスキングされた属性の名称でタグ付けされる。このようにして、入力データは、データ除外サービスにより匿名化される。データ除外サービスの代替の実施形態では、匿名化された属性の値は、一意のタグで置換することができ、属性の元の値と置換タグとの対応性を共通情報モデル３１２内のトークン化テーブルに追加することができる。

スイッチ構成要素３１１は、様々なサービスを実施して、以下を含め、オンボードから終了までのデータの寿命を管理することができる：
・データソース２０１及びデータサービス１３０をオンボード及び登録する登録サービス。システム１００にデータソース２０１を登録するには、データソース２０１がインタフェースをシステム１００に提供することが必要とされる。このインタフェースは、ＩＰアドレス及びそのＩＰアドレスからデータを取得する方法についての命令の組からなる。データソース２０１は、システム１００に参加しているユーザデバイス１３０による、データソース２０１により提供されたデータの使用を支配するデータアクセス規則の組をヘルスデータサーバ１２０に提供する。ヘルスデータサーバ１２０では、これらの規則は、市場規則モジュール３１０に構成される市場規則と呼ばれる。システム１００へのデータサービスによる登録では、システム１００がデータサービス１３０に、ＩＰアドレス及びそのＩＰアドレスからデータを取得する方法についての命令の組を提供する必要がある。登録されたデータサービス１３０によりデータに対する要求に応答する前に、システム１００は、システム１００への要求データに寄与したデータソース１３０により提供される市場規則と突き合わせて要求を検証する。この方法、システム１００内のデータへのアクセスは、常に、システム１００へのデータに寄与するデータソース２０１により確立されるデータアクセス規則により制御される；
・システム１００に入るデータ及びシステム１００から出るデータをログするデータ監査サービス；
・システム１００に入るデータの品質をモニタリングするデータ品質エンジン（ＤＱＥ）であって、データの品質はよりよい分析を駆動し、以下の次元：属性レベルデータ品質（例えば、年齢は特定の範囲内にあるべきであるか、又は姓は空白であるべきではない）、コンテキスト又は集約データ品質（例えば、患者データは、平均で約５０％±特定のマージンが男性、約５０％±特定のマージンが約５０％女性であるべきである）、動作データ品質（例えば、患者の人口統計学的データが存在するが、薬物データが存在せず、それにより、患者記録全体を有用ではないものにする場合、拒絶）を含むことができる、データ品質エンジン（ＤＱＥ）；
・データソース所有者による要求時、データソースからのあらゆるデータをシステム１００から除去するデータ終了サービスは、プラットフォームからの制御で、ソース所有者がソースのデータを除去するのを容易にする；
・規則がデータ内の非一貫性を十分に解決することができない幾つかの実施形態では、それらの要素／フィールドは、全てのステークホルダからの識別可能データを見て、相違を調停する許可を有するデータスチュワードユーザからの手動介入についてフラグされる。これは、患者照合／インデックス付けアルゴリズムが、２つのステークホルダから同じ患者に属するように見えるが、欠落している２つの記録を識別した例を含むことができる；
・複数のデータソース２０１から取り込まれた同じ患者についてのデータを識別し、照合する患者照合サービス。例えば、患者の寿命を通して変わる可能性が低い患者記録要素（例えば、氏名、生年月日、性別、ＳＳＮ − 例えば、電話番号又は住所とは対照的に）を使用して、ヘルスデータサーバ１２０は、異なるソースからの異なるタイプの複数の記録にわたり患者を照合することができる。したがって、幾つかの実施形態では、ヘルスデータサーバ１２０は、重みを各フィールドに割り当て、総合一致スコアを生成するように構成することができ、重みは、照合プロセスでのそのフィールドの重要性を暗示し（例えば、ソーシャルセキュリティナンバー（ＳＳＮ）及び生年月日（ＤＯＢ）は３５％の重みを得ることができ、一方、性別、姓、及び名はそれぞれ１０％の重みを得ることができる）、重みは一致の正確性を改善するように動作可能であり得る。２つ以上のデータソース２０１からのデータが一致すると、スイッチモジュール３１１は、ヘルスデータシステム１００でのその患者の一意のＩＤでデータをタグ付けする。

結果として生成される、クリーニングされ、構造化され、標準化されたデータは、共通情報モデルモジュール３１２により定義される１つ又は複数のデータベースに記憶することができる（例えば、図３のブロック４１３及び４１５参照）。例えば、共通情報モデルモジュール３１２は、国際医療用語集（Ｓｙｓｔｅｍａｔｉｚｅｄ Ｎｏｍｅｎｃｌａｔｕｒｅ ｏｆ Ｍｅｄｉｃｉｎｅ−−Ｃｌｉｎｉｃａｌ Ｔｅｒｍｓ）（ＳＮＯＭＥＤ）標準（例えば、処置コード、投薬方法について）、国際標準化機構（ＩＳＯ）標準（例えば、国コードについて）、高速医療相互運用性リソース（Ｆａｓｔ Ｈｅａｌｔｈｃａｒｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ Ｒｅｓｏｕｒｃｅｓ）（ＦＨＩＲ）標準（例えば、特定のフィールドについて）等の用語的にロバストな標準に従って情報を標準化することができる。例えば、投薬ルート及び投与方法はＳＮＯＭＥＤ値に標準化することができ、国コードは３桁ＩＳＯ−３１６６国コードに標準化することができ、性別及び人種はＦＨＩＲ標準値を使用して標準化することができる等である。

幾つかの実施形態では、データを標準化し統合する場合、システム１００は、患者照合を促進することもできる。例えば、患者の寿命を通して変わる可能性が低い患者記録要素（例えば、氏名、生年月日、性別、ＳＳＮ − 例えば、電話番号又は住所とは対照的に）を使用して、システム１００は、異なるソースからの異なるタイプの複数の記録にわたり患者を照合することができる。したがって、幾つかの実施形態では、システム１００は、重みを各フィールドに割り当て、総合一致スコアを生成するように構成することができ、重みは、照合プロセスでのそのフィールドの重要性を暗示し（例えば、ソーシャルセキュリティナンバー（ＳＳＮ）及び生年月日（ＤＯＢ）は３５％の重みを得ることができ、一方、性別、姓、及び名はそれぞれ１０％の重みを得ることができる）、重みは一致の正確性を改善するように動作可能であり得る。更に、業務／市場規則は、非構造化データを識別し、系統情報を失わずに、構造化データの残りの部分とは別個のクラスタ（例えば、ビッグデータ記憶装置３１３）に記憶するために準備させることもできる（例えば、図３のブロック４１２参照）。

本明細書で考察される様々な実施形態は、ヘルスデータサーバ１２０に記憶するようにデータを処理することに関するが、更なる実施形態では、本明細書に記載されるデータ処理は、活動中のデータに適用することができる。換言すれば、幾つかの実施形態では、データはサーバ１２０に記憶されなくてもよく、仲介としてヘルスデータサーバ１２０を使用するが、データはヘルスデータサーバ１２０に記憶されることなく、データソース２０１とデータ消費者２０７との間で渡すことができる。そのような実施形態では、データは本明細書に記載のように処理することができる。

図１、図２、及び図４を参照すると、システム１００は、１つ又は複数のユーザデバイス１３０を使用して、研究、臨床ケア、商業等の目的で、サーバ１２０からのデータを消費するように構成される複数のデータ消費者２０７を備えることができる。例えば、所与のデータ消費者２０７は、ユーザデバイス１３０を通して、本明細書により詳細に記載され、図４に示されるように、サーバ１２０から様々なタイプのデータを要求及び／又は受信するように構成される１つ又は複数のユーザデバイス１３０を備えることができる。

様々な実施形態では、データ消費者２０７は、データ保護及びデータ使用同意書及び／又は仕事関係者同意書に従ったデータの使用に同意した、ヘルスケア提供者（例えば、ケアの継続性のために、担当医師と電子医療記録を共有する病院からの医師等）、医療保険会社／支払人／リスク負担エンティティ（例えば、結果データを使用して、薬剤の処方状態を調整する）、薬剤デバイス及び／又は医療デバイス企業（例えば、結果データを使用して、市販後調査／ステージＩＶ臨床試験をサポートする）、政府／コミュニティヘルスプログラム（例えば、特に政府要因に関連する場合、提供者データを使用して、家庭でのケアをサポートする）、及び／又は個人の患者（例えば、薬剤コンプライアンスリマインダー）を含むことができる。

図２は、データ消費者２０７とは別個のデータソース２０１を示すが、幾つかの実施形態では、データソース２０１及びデータ消費者２０７は同じであることができる。更に、データソースデバイス１１０は、ユーザデバイス１３０を含むこともでき、逆も同様である。

様々な実施形態では、データ消費者２０７は、手動で（例えば、提供者、患者、調停者等により開始されるモバイルアプリケーション要求を介して）又は自動化された要求を介して（例えば、ヘルスデータサーバ１２０の共通情報モデルデータベース３１２からローカル研究データベース（図示せず）への日毎、週毎、月毎等の自動プル）、データを要求することができる。

様々な実施形態では、アプリケーションプログラミングインタフェース（ＡＰＩ）３１４は、公開されたサービスコールカタログに従って、データ消費者２０７からのデータ要求（例えば、患者の人口統計に対する要求又はデータの様々なサブセットに対するクエリ）を処理するように構成することができる。そのような対話は、セキュリティ構成要素３０９により促進されるように、承認及び認証を必要とすることができる。幾つかの実施形態では、ＡＰＩ３１４からの要求は、市場／ビジネス規則モジュール３１０に従ってスイッチ３１１により管理することができる。適用可能な規則は、各要求に関連付けられたアクセスレベルに基づいて、特定の要求へのアクセスを認可又はブロックすることができる。

例えば、ユーザデバイス１３０による識別可能なデータへの要求は、要求ユーザ（又はユーザの組織／役割タイプ）に、元のデータソース２０１又はそのデータを共有した患者により権利が認められていない場合にブロックすることができる（例えば、データを処理したエージェント２０５に構成されるように）。別の例では、規則は、組織自体のユーザのみが識別可能データを見ることができ、他方、他の全ての人は、組織のデータの識別されたバージョン又はサブセットへのアクセスのみを受け取り得ることを指定することもできる（例えば、図４のブロック５０８参照）。アクセス制限の性質に応じて、ユーザはエラーメッセージを受信し得る（例えば、図４のブロック５１９）。

幾つかの実施形態では、サーバ１２０は、３つのチェックに基づいて各要求を評価することにより、要求が認められるか否かを判断することができる：
・規制コンプライアンス：要求が医療保険の相互運用性と責任に関する法律（ＨＩＰＡＡ）標準及び／又は医療情報トラストアライアンス（Ｈｅａｌｔｈ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｒｕｓｔ Ａｌｌｉａｎｃｅ）（ＨＩＴＲＵＳＴ）規制に従っているか。換言すれば、ヘルスデータサーバ１２０は、適切な規制文書（例えば、ＨＩＰＡＡ仕事関係者同意書（ＢＡＡ））が整っていることをチェックする；
・セキュリティ：ヘルスデータサーバ１２０は承認及び認証を保証する；
・市場規則：ヘルスデータサーバ１２０は、データアクセス規則を支配する組織固有のコントロールを実施する。

例えば、ＡＰＩモジュール３１４によりサービスされるコンプライアント要求／データ出力は、認可ユーザであるデータへのアクセスを要求するユーザ、ヘルスデータサーバ１２０プラットフォームでのデータの終了を要求するデータソース２０１、データが共有されないことを要求する患者、特定の当事者のみがデータを見ることができることを要求する患者、要求者が認可した診療記録番号（ＭＲＮ）についての患者人口統計データの高速医療相互運用性リソース（ＦＨＩＲ）データ出力、複数の患者へのアクセスが認可されたユーザにより見られる、これらの複数の患者の年齢人口統計のＴａｂｌｅａｕ（Ｔａｂｌｅａｕ，Ｉｎｃ．、ワシントン州シアトル）視覚化要求、第三者臨床判断サポート解決策を通しての患者と組織にわたる他の「私のような患者」とを比較する分析に対する要求等を含むことができる。

ＡＰＩモジュール３１４によりサービスされる非準拠要求（データ出力が提供されない要求）の例としては、アクセスしてはいけないことになっているデータへのアクセスを要求する個人又は組織、セキュリティポリシー及び手順を迂回する要求（例えば、ユーザＩＤの共有に対する要求）、非認可個人からの市場規則をディセーブル又は変更する要求、構造化クエリ言語（ＳＱＬ）にヘルスデータサーバ１２０のデータストアをクエリするように指示することが可能な要求、データ使用同意書の範囲外の方法で情報を使用する要求、ＨＩＰＡＡ仕事関係者同意書（ＢＡＡ）を有さない患者についての保護された健康情報へのアクセスを要求するビジネスエンティティ等を挙げることができる。

しかし、許可が認められる場合、適用可能なクエリを共通情報モデル３１２に対して実行することができる（例えば、図４のブロック５０９、５１０、５１１参照）。

例として、共通情報クエリの出力は、関係フォーマットでのデータセットであり得、一方、ビッグデータクエリの出力は、非構造化内容の塊及び内部の特定のキーワードについての頻度及びセンチメント分析であり得る。

１つ又は複数のクエリの結果は、依然として集約されておらず、データの解釈に必要とされる所要メタデータと共に、ユーザによりフィルタリング又は定義されるような、寄与する様々なデータソース２０１のステークホルダの結合データを反映することができる程度まで統合出力に統一することができる（例えば、図４のブロック５１２参照）。例えば、一実施形態では、提供者、支払人、及びコミュニティヘルスプログラムからの結合データを集計して、参照データの組と照合され、共通情報モデル３１２で出力される総合結果データセットにすることができる。このデータセットは更にチェックされて、要求ユーザ及び／又はアプリケーションが十分なアクセス特権を有し（例えば、図４のブロック５１３参照）、必要に応じて、適切な契約／データ使用同意書／仕事関係者同意書を整えていることを保証することができる。

これに続き、データは、ＡＰＩ３１４のサービスコールに従って、暗号化されたフォーマットで（例えば、図４のブロック５１５及び５１６参照）要求ユーザ／サービスに送出することができる（例えば、図４のブロック５１４参照）。ユーザはここで、より広いデータセットを利用して、洞察を明らかにし、判断することができる。（例えば、図４のブロック５１７及び５１８参照）。例えば、提出された請求書に提示されたもの以外の結果関連データへのアクセスを以前は有していなかった支払者ユーザは、ここで、経験（例えば、コミュニティサポートでの）中又は経験後に収集されたデータの組合せに基づいて、患者の臨床経験へのより深い洞察を有し得る。

ヘルスデータシステム１００の使用及び実施の例
新しい健康経済の変化は、患者が標的とする健康結果を達成する必要がある包括的ケアを提供するために、ヘルスケア組織の協働を強制させる。患者集団のニーズに対処する必要があるヘルスエコシステムが提案されると、ヘルスデータシステム１００は、メンバ（例えば、図２に示されるようなデータソース２０１及び／又はデータ消費者２０７）間でのデータ／情報交換を促進する情報インターチェンジとして機能することができる。ヘルスデータシステム１００は、健康組織（例えば、図２に示されるようなデータソース２０１及び／又はデータ消費者２０７）の正しいネットワークを識別し、接続して、標的集団の中での消費者健康を改善するエコシステムイネーブラであることができる。ヘルスデータシステム１００は、第三者（例えば、図２に示されるようなデータソース２０１及び／又はデータ消費者２０７）が取引して、様々な所望のビジネス目的の達成に必要なデータ及び分析を提供及び／又は消費できるようにすることができる。インテリジェント統合エンジンとして機能することにより、ヘルスデータシステム１００は、市場にわたる接続を促進して、データ及びサービスの流動的な交換を可能にすることができる。

例えば、ヘルスデータシステム１００は、プログラム内の個人、組織、及びデータ駆動解決策のエコシステムを識別してイネーブルし、疾患管理を改善することができる。そのような使用及び実施の例では、ヘルスデータシステム１００は、そのようなプレーヤをモバイルプラットフォーム及び認知分析解決策として結び付けて、連続したシームレスな情報を適切なステークホルダ（例えば、図２に示されるようなデータソース２０１及び／又はデータ消費者２０７）に提供することができる。図５は、消費者健康問題を定義し、それを解決するエコシステムを作成し、ケア提供ネットワークをモニタリングして、健康恩益が実現される場所を識別し、関連するコスト節減を分離して、リスク負担エンティティ及び他のエコシステムメンバの両方に再分配する新規の方法５００を示す。特に、方法５００は、標的とする消費者／患者健康問題を定義するステップ５１０、患者のニーズに対処するために必要なエコシステムの参加及び対話を識別するステップ５２０、ヘルスデータシステム／情報交換１００を使用して、エコシステムの接続を促進するステップ５３０、対話を最適化し、ガバナンスを実施するステップ５４０、並びに消費者の健康改善を通して価値を取得し、コスト節減の共有を通してエコシステムを維持するステップ５５０を含む。

ヘルスデータシステム１００は、分散データをインテリジェントに見つけ、洞察を適時に広め、ケア提供ネットワークにわたり広いコミュニティのユーザをサポートする能力を含め、ビジネスサービス及び技術サービスの包括セットを可能にするシステムの一部であるように構成することができ、及び／又は可能にするシステムの一部であることができる。

そのようなヘルスデータシステム１００は、エコシステムの対話を促進し、ステークホルダにわたる情報交換の信頼できる仲介者として機能し、標的とされるデータに安全にアクセスして、教育の改善、健康モニタリング、健康判断の改善、及び疾患回避等の意図される結果を提供することが可能な様々な分析アプリケーションに接続し、データへのアクセスを提供して、患者結果、ケア提供有効性及び効率性、並びに得られる価値及び達成される節減を含む疾患処置及び回避プログラムの結果についての進行中の報告を促進することができる。様々な実施形態では、そのようなシステムは、全て適切な許可及び同意書に基づいて、選択された数のステークホルダの予め定義されるダッシュボード、リポート、スコアカード、及びアドホック分析を通してデータへのアクセスを提供することにより、そのような報告を可能にすることができる。そのような報告は、資金の流れの追跡をサポートすることもできる。更に、そのようなシステムは、多重防護セキュリティモデルを通して患者及びステークホルダ情報のプライバシー及びセキュリティを保証し、市場規則を開発して、エコシステム内のメンバの対話を管理するように構成することができる。

ヘルスデータシステム１００を利用して、ケア管理（及び他の実施形態では、他のヘルスケアプログラム）を改善するために、様々なヘルスステークホルダ（例えば、図２に示されるようなデータソース２０１及び／又はデータ消費者２０７）を接続して、情報を共有することができる。本明細書で考察されるように、ヘルスデータシステム１００は、組織にわたるデータ及び分析へのアクセスを提供して、新規の洞察及びケア変換を駆動するように設計することができる。

更に、ヘルスデータシステム１００は、ケア提供ネットワークエンティティ（例えば、コア提供者、専門家、外来患者、病院、クリニック、応急手当、患者ケアを提供するリテールクリニック）、健康管理ネットワーク（ＨＭＮ）エンティティ（例えば、政府組織、自家保険従業員、及び商業支払者等のリスク負担エンティティ（ＲＢＥ）、並びに従業員（非自家保険）、コミュニティセンター、及びヘルスプロモーター、教育者として機能する患者調停者を含む非ＲＢＥ）を含むが、これらに限定されないエコシステム参加者に関与する。幾つかの実施形態では、そのようなＨＭＮグループは、標的プログラムに資金提供、補助金提供、又は他の方法で奨励して、ケア提供を最適化し、コストを低減することができる。

ヘルスデータシステム１００は、米国経済で費やされる健康の影響を考えて、治療への準拠及びコンプライアンスの駆動に既得権を有するはずの主要ビジネスエンティティを含むが、これらに限定されない商業ビジネスネットワークエンティティに関与するように構成することもできる。そのようなエンティティは、製品又は集団への提供を調整し、コミュニティ健康イニシアティブを金銭的にサポートすることにより、健康管理を駆動するコーディネータとしての役割を果たすこともできる。

更に、ヘルスデータシステム１００は、モバイル患者関与プラットフォーム又は認知分析専門家システムを含め、コミュニティのニーズを満たす目的に適った技術解決策を統合することができる。

現在利用可能なヘルスケアエコシステムには欠陥があるため、ヘルスケアデータの取得、記憶、及び／又は提供を提供するヘルスケアエコシステムは、望ましいと証明することができ、本明細書に詳述されるような広範囲の用途のベースを提供することができる。この結果は、本明細書に開示される一実施形態によれば、図６に示されるヘルスケアエコシステム６００により達成することができる。例えば、図６は、ウェブサービス（ＡＰＩ）を介して送出される複数のソースからの情報の交換を含む、ヘルスケアエコシステム６００の実施形態を示す。図６に示されるように、ヘルスデータシステム１００は、様々なエコシステム参加者が接続し、データを共有できるようにするデータハブとしての役割を果たすことができる。例えば、ヘルスデータシステム１００は、エコシステム６００内のステークホルダが、「移動中」（例えば、システム１００がデータの輸送のみを行っている）又は「静止中」（例えば、システム１００は、本明細書で考察されるように、データをリポジトリに記憶／保持している）のデータへのアクセスを得られるようにすることができる。

様々な実施形態では、ヘルスデータシステム１００は、インターチェンジとして機能することができ、インターチェンジでは、システム管理者は、データを所有せず、又はアクセス権／規則を決定せず、むしろ、データ所有者（患者、クライアント、及び／又はステークホルダ）が、データがいずれのユーザ及びサービスに流れるかを指示できるようにするデータスチュワードとして機能する。ヘルスデータシステム１００は、規制データ及び非規制データの両方の交換を可能にすることができ、エコシステム６００内の各エンティティは、関連する規制及び／又はクライアント定義のアクセス規則により支配される（例えば、図２に示されるような市場規則３１０により支配される）データを提供し、受信することができる。

様々な実施形態では、ヘルスデータシステム１００は、消費者アプリケーション、医療デバイス、電子健康記録（ＥＨＲ）、薬局記録、及び患者レジストリを含め、様々なソースからのデータを共有できるようにすることができる。次に、これらのデータタイプのそれぞれは、ヘルスデータシステム１００によりサポートされる広範囲のアプリケーションに供給することができる。

疾患回避及び治療プログラム等の様々な実施形態の範囲内のデータタイプは、１次臨床データ（例えば、人口統計、在宅服薬、アレルギー、研究所及び病理学リポート、転写された記録等）、提供者２次臨床データ（例えば、自然言語処理データ、観察データ、予後スコア、分析及び統計データ等）、標準化のための参照データ（ＦＨＩＲ標準オントロジー、ＩＳＯ３１６６コード、ＬＯＩＮＣ及びＳＮＯＭＥＤ標準データセット等）、患者自己管理／自己報告データ（例えば、血糖測定器、ウェアラブルデータ等）、コミュニティ推奨関連データ（例えば、自己管理プログラムデータ、教育プログラムデータ等）、金融的／リスク負担エンティティデータ（例えば、メンバープラン、提供者品質評価、請求書等）を含むことができる。

様々な実施形態では、エコシステム６００及び／又はヘルスデータシステム１００は、以下のサービスを提供するように構成することができる。

本明細書で考察するように、ヘルスデータシステム１００のアーキテクチャは、様々なデータソース及びサービスに接続するように、柔軟に開発することができる。例えば、図２に示されるように、そのような構成要素は、以下を含むことができる。

ヘルスデータシステム１００を利用して、ケアを提供し、慢性疾患を管理するコミュニティ志向の手法を可能にすることにより、様々なヘルスケアプロジェクトは、国民健康管理変換努力及び医療費負担適正化法（ＡＣＡ）の共有ミッションを進める将来性を有する。特に、ヘルスデータシステム１００は、ＡＣＡの「３つの目的」のそれぞれに有利な影響を有することができる：ケアの品質を保証しながら、患者がいる場所へのエビデンスベースのケアの民主化を通して、より効率的なケアを提供し、患者の結果を改善する；高度な分析のために患者データへのアクセスを有する統合ケア提供ネットワークにより可能になるトリアージ及び割り振りにより、ケアをより効率的に提供し、ケア提供のコストを低減する；及びモバイル及びソーシャルプラットフォームを使用して、ケア経験を個人化することを通して、より消費者中心のケアを提供し、患者経験を改善する。

説明される実施形態は、様々な変更形態及び代替形態を受けやすく、その特定の例が例として図面に示され、本明細書に詳述される。しかし、説明される実施形態が、開示される特定の形態又は方法に限定されず、逆に、本開示が全ての変更形態、均等物、及び代替形態を包含すべきであることを理解されたい。

追加の用途は以下を含むことができる。

Ａ．ケア提供者、リテールクリニック、及び家庭のネットワークにわたるケアの分配を最適化することによる慢性疾患管理の改善
慢性疾患管理は、ヘルスケア業界が直面する高コスト、低リターンの問題である。この問題は、糖尿病、呼吸疾患、及び心血管疾患等の複数の治療領域に広がっている。平均でヘルスケア総費の２／３は慢性疾患管理によるものである。データ駆動慢性疾患管理は、既にコスト削減及び生活の質の改善で大きい潜在性を示しており、ヘルスデータシステム１００は、革新的な介入及びデータの統合を通してデータ駆動慢性疾患管理を次のレベルに進める
１．システム１００は、慢性疾患管理プログラムの統合部分であり、コアデータ管理、取り込み、及びアプリケーションホストサービスを提供する。システム１００は、介護者／提供者が施設にわたりシームレスにケア提供のために必要なツール及びデータにアクセスし、その間、患者も、治療計画への準拠を改善するために必要なツール及びサービスへの同様のアクセスを有するのに役立つ提供チャネルサービスを提供する。新しいエコシステムビジネスモデルを可能にするシステム１００の幾つかの主要な機能を以下に列挙する：
・データ収集器：システム１００は、ＥＭＲ（電子医療記録）、非構造化トランザクション及び研究データ（自然言語処理を通して）、金融データ、患者報告情報、及び医療デバイス又はフィットネスウェアラブルからのデータストリーム等の複数のソースからデータを捕捉するエージェントモジュール２０５を提供する。データは、複数の組織／ソースから捕捉され、それに従ってタグ付けされる：
○予め定義される間隔で実行されるようにスケジュールされるデータエージェントモジュール２０５、及び／又はオンデマンドで実行することができる；
○各データエージェントモジュール２０５は、データソースシステム２０１に対して実行され、予め定義されるデータ値の組を抽出するクエリの集合を提供する；
○データソース２０１からのデータは、予め定義されるアルゴリズム及び規則セットを使用してスイッチ３１１により変換され、変換されたデータ値は、永続的又は一時的モードのいずれかで共通情報モデル３１２に記憶される；
○フィードバックを目的として、システム１００は、スイッチ３１１により共通情報モデル３１２に対して実行されるクエリの結果に基づいて投入される別の組のテンプレート／属性／リストを提供する；
○システム１００は、ボックスエージェントモジュール２０５の多出力を含む。これらのエージェントモジュール２０５は、ＥＰＩＣ、ＣＥＲＮＥＲ、Ｃｅｎｔｒｉｃｉｔｙ等の第三者当事者ＥＭＲシステム並びにＢＰ及び血糖測定器等のウェアラブルデバイスからデータを抽出するように構築されている。エージェントモジュール２０５は、抽出される臨床属性及び非臨床属性並びに抽出に向けて書かれる最適化されたクエリに関して独自である。更に、エージェントモジュール２０５は、トランザクションシステムの標準インストールがクライアントにより使用されている場合、構成の必要が最小化される独自のプラグアンドプレイ機能を提供する；
○システム１００は、非構造化データを自動タグ付けする自然言語処理（ＮＬＰ）エンジンを含み、それにより、文書タグ付けの労力を２０〜３０％低減する；
○プラットフォームは、ヘルスケア業界に関して一意の構造化データ、非構造化データ、及びソーシャルデータの統合を可能にする；
・データ統合器：システム１００は、独自の一時的及び永続的データモデルを利用して、取り込まれた様々なデータセットにわたる相当量の調和化を実行し、累積分析コアデータセット及びフィードバックループを通して受け取ったデータを記憶する：
○スイッチ３１１は、ある符号化方式（用語）の別の符号化方式への変換を記述する複数のコードブックを保持する；
○これらのコードブックは、インバウンドデータの符号化方式をインストール用に確立された共通符号化方式に変換するのに使用される；
○例えば、符号化ブックの１つは、ＩＣＤ９で符号化された診断のＳＮＯＭＥＤ符号化方式への変換を説明する；
○１対１符号化マップが符号化方式内の特定のエントリに利用できない場合、スイッチモジュール３１１は、ユーザ定義の規則を利用して競合を解決する；
○データ記憶の一時的及び永続的方式は、実行時、記憶されるデータと渡されるデータとを区別するユーザ定義の規則の組を通して制御される；
○例えば、特定のソースシステムから受信する全てのデータは記憶される必要があり、別のソースシステムからの全てのデータは累積状態でプッシュフォワードする必要があることを述べる規則があり得る；
○システム１００は、患者中心であり、バイタル、慢性、一過性、ゲノム、請求書、ソーシャル、行動等の複数のドメインを含む共通情報モデル３１２であるデータモデルを含む。共通情報モデル３１２は、属性及び関係の観点から独自であるのみならず、記憶の観点についてのユーザ定義の規則によっても駆動される；
○システム１００内に展開される独自の「一時的及び永続的」概念により、データ管理者は、編集可能な規則の組を通して、データフロー及びそれに関連する記憶を制御することができる。システム１００は、いずれのデータを永続的に記憶すべきか及びいずれのデータを一時的に流すかのデータ管理者制御を提供する；
・データ提供者：ＡＰＩ３１４は、共通情報モデル３１２で管理されるデータにアクセスする必要がある任意のアプリケーションのアクセス層を確立する。システム１００は、ＡＰＩ３１４、予め定義されるメソッド、及びインタフェースプログラムを含むＳＤＫ（ソフトウェア開発キット）を含む：
○ＡＰＩ３１４は、単純なオーバーロードされたメソッドの集合又は複雑なウェブサービスのいずれかであることができる；
○メソッド又はサービスは通常、以下の構造を保持する；
Ｃｏｌｌｅｃｔｉｏｎ／Ｄａｔａ＿ｓｅｔ ＡＰＩ＿Ｎａｍｅ（ｐａｒａｍｅｔｅｒＬｉｓｔ）
ここで、Ｃｏｌｌｅｃｔｉｏｎ／Ｄａｔａ＿ｓｅｔは、ＡＰＩにより呼び出し側プログラム／システムにより提供される戻り値である
ＡＰＩ＿Ｎａｍｅは、メソッド／サービスを通して送られる機能を呼び出すために呼び出し側プログラムが使用する名前である
ＰａｒａｍｅｅｒＬｉｓｔは、メソッド／サービスからの結果／戻された結果を整形するために、呼び出されたメソッドに値又は参照により渡される幾つかのパラメータである；
○ＡＰＩ定義（シグネチャ）は、予め定義されるメカニズムを通して、又は予め定義されるディレクトリサービス、例えば、ＷＳＤＬを通して露出される；
○ＡＰＩは、システム１００と対話するプログラム及びシステムにより呼ばれる／呼び出される；
○呼び出し側プログラムは、露出されたｐａｒｅａｍｅｔｅｒＬｉｓｔの値を渡し、ＡＰＩは、渡された値に基づいて集合又はデータセットのいずれかの形態で応答を返す；
○システム１００は、呼び出し側プログラム／システムのニーズをサポートする機能を提供する、別個のＡＰＩ３１４下でカテゴリ化された様々なサービス／メソッドを含む。幾つかの例は、所与の患者の統合医療記録を戻すＡＰＩ３１４、患者集団の所定のコホートに対して実行された分析クエリの結果を露出するＡＰＩ３１４、セキュアメッセージをシステム１００の２つのエンドユーザ間で渡すＡＰＩ３１４等を含む；
○全てのＡＰＩ３１４、およびシステム１００により露出される他のアクセスメカニズムを含むＳＤＫ（ソフトウェア開発キット）は、システム１００に独自であり、ＡＰＩ３１４のシグネチャ、オーバーロードされた入力属性、及び出力の集合は、システム１００に向けて特に設計されて開発されている；
・セキュリティ：システム１００内の全てのデータは、静止中であれ、移動中であれ関係なく、セキュリティモジュール３０９内の一連のセキュリティプロトコルを通して保護される。セキュリティモジュール３０９は、役割ベースの動的で多形態の認証及び承認を提供する。データアクセスは、データソースシステム、組織ソース（及び関連規則）、並びに消費ユーザ及びアプリケーションの識別情報に基づいて認証を確立する市場規則３１０に基づいて認可される：
○静止中のデータ：共通情報モジュール３１２に記憶された全てのデータは、最新の暗号化標準を使用して暗号化される。ステージング等の一時的エリアに配置されたデータも暗号化される。暗号鍵は、ダブルブラインドボールト内の別個の場所に保持される。各ユーザには、プラットフォームの管理者により保持される役割の組が割り当てられる。これらの役割は、ユーザに特定の画面、リポート、モジュール、及びコアピースへのアクセスをユーザに提供する。同じアクセス認可を有するユーザであっても、個々のデータ項目と認可ユーザグループとの間の背景リンクにより、同じデータを見ないことがある；
○移動中のデータ：移動中のデータには２つの主なエリアがある：１）ソースシステムから検索中のデータ及び２）ＡＰＩ３１４を通して、データを必要とするプログラム／システムに露出されているデータ。両状況下で、データは、予め確立されたセキュアトンネルを通って流れる。そのセキュアトンネルは、ベースラインＳＳＬプロトコルの上にある複数の規則の組合せである。プラットフォームの各層（ＩＳＯモデルに対応する）は、コアＳＳＬプロトコルを増補するそれ自体の別個の規則セットを有する；
○ソフトウェア開発用のＩＳＯモデルに即した７層セキュリティ及びアクセス制御。１）ＩＳＯ層のそれぞれは独立して、セキュリティモジュール３０９を通して処理され、２）各ＩＳＯ層の処理に使用されるプロセス／アルゴリズムは、システム１００にとってプロプライエタリである；
○暗号鍵を記憶するダブルブラインドボールトは、臨床試験業界から採用された独自の概念である；
・サーバ１２０はＰＨＩ承認される：サーバ１２０は、ＣＳ４０９６等の利用可能な最新で最も厳しいセキュリティプロトコルの使用を通して、ＰＨＩ（保護された健康情報）を管理するように予め構成される。サーバ１２０はＨＩＴＲＵＳＴ承認される：
・サーバ１２０は、ＨＩＴＲＵＳＴ承認されると共に、ＣＳ４０９６暗号化を展開する大学医療センタ（ＡＭＣ）に向けて専ら構築されたＰＨＩのみを運ぶシステムである：
・分析エンジン：システム１００は、ベースライン分析クエリを提供すると共に、ＡＰＩ３１４を使用して、共通情報モデル３１２に含まれる膨大なデータセットからの焦点を絞った分析を可能にする傾向一致コホートを提供するコア分析プラットフォームを提供する：
○データは、データソース２０１から共通情報モデル３１２に流れる；
○データは、スイッチモジュール３１１により調和化される；
○調和化データは、データの分析要件及び／又はトランザクション要件に基づいて、累積及び／又は非正規化される；
○非正規化／累積データは、共通情報モデル３１２に記憶される；
○患者記録は、年齢、性別、民族性、病態、併存疾患、ケアプログラム登録、薬剤タイプ等の複数のファクタに基づいて様々なコホートに分類される；
○ベースライン推論は、これらのコホートにわたり描かれ、全般トレンドとして記憶される；
○全般トレンドは、第三者ベンチマーク／標準と比較され、差異がプラットフォームに記憶される；
○クエリがＡＰＩ３１４を使用して実行される場合、１つ又は複数の患者コホートは、クエリにより渡されるパラメータに応じて、クエリの標的集団として識別される；
○関連するパターン／トレンドは、ＡＰＩ３１４を通して呼び出し側プログラムに露出される；
○トレンドと実生活データとの差異が識別され、予め定義されるスケールに基づいて定量化される；
○加えて、エンドユーザに、生成された推論をオーバーライドする能力が提供される；
○調整ファクタ（元のパターン及び実生活データ差異又はエンドユーザオーバーライドに基づく）は、共通情報モデル３１２にフィードバックされ、ＡＰＩ３１４を使用した同様のクエリ実行の将来の反復でマージン／確率調整ファクタとして機能する；
○認知クエリの場合、トレンドは、特定の事例への医師の典型的な挙動的反応等の将来の無形ファクタに外挿され、ベースラインクエリ応答に重ねられて略現実世界の予測を提供する；
○システム１００は、動的で自己学習的な分析を提供する。すなわち、システム１００により、エンドユーザは、フィードバックの観点から逆データフローを確立することができ、逆データフローは、境界条件、遮断レベル、割合割り振り、確率分布、及び他の数式を調整して、分析クエリの実行の次の反復に影響を及ぼす。収集されたトランザクションフィードバックに基づく分析応答の自己学習的及び自己調整的挙動は、システム１００に独自である；
・患者帰属：システム１００の精密トリアージＡＰＩ３１４は、個人の完全な健康プロファイルを取り、健康ニーズ、提供者の専門性及び能力、保険の補償範囲、アクセス／利便性、及び価値に影響する他のファクタ（品質、コスト、経験）に基づいて、最良適合施設及び健康サービスに一致させる：
○データがデータソース２０１からヘルスサーバ１２０に取り込まれるとき、各記録は、予め定義されるユーザ制御可能な属性の組と比較されて、記録を様々なコホートにリンクする；
○コホート定義は、予め定義され、システムの最終的な機能ニーズに基づく；
○例えば、慢性ケア管理システムの場合、ユーザは、全ての患者を３つのカテゴリ：高リスク、中リスク又はボーダーライン、及び低リスクの患者に分割することを望む場合がある。これらの分類のそれぞれに、管理者は境界条件又は規則の組を定義し得る。例えば、糖尿病管理プログラムでは、規則セットは、ＨＢＡ１Ｃの値：５未満は低リスクに分類され、５〜６はボーダーラインとして分類され、６超は高リスクに分類される、のように簡単であることができる；
○取り込まれた全てのデータは、これらのコホート定義を通り、各記録は複数のコホートに対してタグ付けされ、それにより、患者を様々なカテゴリに帰属させる；
○こうして様々なコホートに帰属した患者は、分析エンジンによりエンドユーザクエリの標的集団として更に使用される；
○システム１００は、患者と様々なケア提供側面との関係を確立する。これらのケア提供側面は、集中プログラム登録、ケア調整、トリアージの事前区分等まで様々であることができる。リンクにより、患者を様々なコホート下に配置することができ、それにより、後のクエリ実行を簡易化すると共に性能を大きく改善する；
・消費者関与：消費者関与ＡＰＩ３１４は、健康的な行動を促進する地理的位置に基づくと共に個人化された動機、消費者に関与して、消費者の健康及びウェルネスを管理するゲームベースのツール、並びにヘルスケア提供者への直接接続を含め、個人の健康プロファイルに基づいてカスタマイズされた内容を有する患者ポータルを実施する：
○患者ポータルは、患者がシステム１００と対話するのに使用される統合ゲートウェイである；
○個々の患者は、指紋スキャン及び／又は虹彩スキャン等のバイオメトリック認証を含むこともできる多形態認証を展開するセキュアメカニズムを通して、ポータルにアクセスする；
○ポータルに入ると、患者には、プロプライエタリヘルススコアを含む患者の累積健康のダッシュボードが提示される；
○ヘルススコアは、患者の人口統計学的データ、バイタル、消費中の併用薬剤、合併症の病態、病歴、家庭環境、及び複数の他のファクタ等の様々なファクタを利用するプロプライエタリアルゴリムの使用を通して、患者の病態に基づいて作成される；
○ポータルはまた、介護者と対話する能力、アポイントメントのスケジューリング、処方の補充、ケアプランの検証及び調整、提供／推奨される教育資材を通しての学習等を含む複数の選択肢を患者に提供する；
○患者ポータルは、統合及び調和の観点から独自である。すなわち、患者ポータルは、患者が全ての認可データを１スポットで見られるようにする単一のゲートウェイである。データは、患者の医療データ、研究結果、放射線画像及びリポート、処方データ、ウェアラブルデバイスデータ、及びＥＫＧ等のデバイスからの波形（ストリーミング）を含む。記録のこれらの全てのデバイス及びシステムは、異なる用語を使用し得る。システム１００は、異なる用語を共通言語及び用語に変換する；
○プラットフォームの別の独自の特徴は、スマートデバイス、ラップトップ、電話等の複数の送出チャネルにわたり同じポータルを通して同じ情報をレンダリングすることである；
・臨床判断サポートシステム：システム１００提供者ケア提供サービスは、カスタマイズされたアプリケーション、患者臨床及び病理学データ、公開リソースからの比較データのような臨床リソースを有する提供者ポータルを含む。これらの機能は、患者データの長期アカウントを提供して、介護者にわたる協働及びケア施設にわたる調整を改善する：
○プラットフォームのＣＤＳＳモジュールは、２つの方法の一方としてレンダリングすることができる：１）スタンドアロンアプリケーションとして、及び２）既存のトランザクションシステムの統合拡張として；
○第２の状況下では、ＣＤＳＳモジュールは通常、介護者のＥＭＲシステム等のエンドユーザにより使用されているコアトランザクションアプリケーション内のボタンのクリックを通して呼び出される；
○調査中の患者の患者ＩＤがＣＤＳＳモジュールに渡される；
○ＣＤＳＳモジュールは、渡された患者ＩＤについて利用可能な病歴全体を検索し、調和化する；
○ＣＤＳＳモジュールは、トランザクションシステムにより実行中の共通用語及び標準に対して患者病歴を調和化し、長期記録を提示する；
○加えて、ＣＤＳＳモジュールは、考慮下の治療経路のケアプランに関連付けられた推奨を提供するように構成することができる。これらの推奨は、患者個人の特徴並びに業界ベンチマーク及びベストプラクティスに基づく；
○ＣＤＳＳの観点から、システム１００は、臨床医により考案され、患者の病態を１つ又は複数の予め定義される治療経路に相関付けて、将来のケアプランを確立するのに使用される背景規則の組により駆動される；
○ＣＤＳＳモジュールは、複数の業界ベンチマーク及びベストプラクティスを利用して、将来のケアプランを微調整する推奨を作成する；
・結果率：病態に関連するコア臨床パラメータにより測定される１０〜２０％の健康結果改善。例えば、糖尿病でのＨＢＡ１Ｃ測定値又は喘息／ＣＯＰＤでのＰＦＴスコアの１０〜２０％の改善：
・コスト削減：病態でのＴＣＭ（総合管理コスト）と突き合わせて測定される１５〜２５％のコスト削減。このコスト削減は、複数の介入コホートにわたり計算された高コスト活動（ＥＲ訪問等）での低減を通して測定される：
・準拠率：患者により記入されたオーダーではなく、患者により消費されたオーダーにより測定される準拠率での２０〜３０％の改善：
・アクセス改善：アポイントメントをスケジュールする時間の短縮、アポイントメントまでの日数の低減、研究結果にアクセスするための日数の低減等の様々なファクタの加重組合せを通して測定される２０〜２５％の改善。

Ｂ．統合がんケア提供ネットワークでのケアのばらつきを低減するためのがん治療標準化
１．米国のヘルスケア支出のうち１兆ドルを超える金額は無駄であると見なされ、ケア提供の非効率性、最適未満のケア、及び不適切なアクセスによりもたらされる。がんケアは、一般的なオンコロジー医による専門知識への不十分なアクセス、治療のばらつきを最小にするためのエビデンスベースのツール及びプラクティスの欠落、及び疾患の効率的な管理に患者が関与できないことに起因して、最も制約されるケアのうちの１つである。現在の補償モデルは、長期ウェルネスへの投資を動機付けず、代わりに治療ボリュームに焦点を当てている。これらのファクタは、治療品質でのギャップを生み出し、コストを増大させる。規模を拡大して結果の改善及びコスト節減を実証する新規のデータ駆動解決策により可能になる永続的な変更を行う新しいヘルスシステムが必要である。ＭＤアンダーソンがんセンター（ＭＤＡＣＣ）ネットワーク民主化プロジェクトは、エビデンスベース及び経験情報に基づいた臨床判断を通して結果を改善することにより、がん患者の臨床ケアの加速化に取り組む１つのそのようなイニシアティブである：
２．ネットワーク民主化イニシアティブは、以下の広いレベルの活動に焦点を当てる：
・提供者（患者を管理する）、リスク負担エンティティ（ケアの料金を支払う）、及び技術パートナー（正しいケアの割り振り、ケア継続性の促進、及びケア品質の改善を可能にする）からなる統合提供者パートナーエコシステムの作成；
・がん患者についてのデータを複数のソース（ＥＭＲシステム等）から安全に取り込む。臨床データを共通フォーマット及び用語に標準化して、キュレートされた疾患サマリを作成すること、専門家知識に基づいて、人口統計的に類似するコホートに対する治療推奨を識別すること、診断及びステージング確認のために専門家の仮想コンサルタントを可能にすること、及び疾患を管理するためのケア経路助言を提供すること；
・教育及びがんスクリーニングサービスを通して、標的とされる介入の手段を作成する；
・予防的スクリーニング及び早期診断のコミュニティ提供者へのシフト（６０％）、専門家助言及び生身の専門家のコンサルタントによりサポートされる個人化ケア（３０％）、及び専門家がローカルネットワークパートナーにいない場合の高速照会の促進（１０％）；
・ウェブ及びモバイル解決策を通して、一貫した統合情報を関わる全てのステークホルダ（医師、サポート人員、患者）に提供する；
・患者のがんの長期ビュー及び病歴データを利用して治療推奨を微調整する；
・介入プログラムのコスト及び結果を国内的及び／又は国際的に確立されたベンチマークと比較して、正しい結果に向けて介入を更に調整する；
３．システム１００は、ネットワーク民主化の統合部分であり、コアデータ管理、データの取り込み／標準化、及び分析ホストを提供する：
・外部データコネクタ及びサービス：エージェントモジュール２０５は、ネットワークプロバイダパートナーに常駐するＥＭＲ（電子医療記録）システム、非構造化臨床データ（患者についての２次情報の取り込みに使用される）、及び患者自己報告情報（病院のオリエンテーションイベント中に完成されるがん調査等）等の複数のソースからデータを捕捉する；
○エージェントモジュール２０５は、予め定義された間隔で実行するようにスケジュールし、及び／又はオンデマンドで実行することができる；
○各エージェントモジュール２０５は、ソース２０１に対して実行されて、予め定義されるデータ値の組を抽出するクエリを含む；
○これらのデータ属性は、システム１００と共にボックスから来るテンプレートを通して制御することができる。これらのテンプレートは、インストール時又は実行中、システム１００の管理者により変更することができる；
○抽出されたデータは、予め定義されるアルゴリズム及び規則セットを使用して変換され、変換されたデータ値は３１２に記憶される；
○システム１００は、プラットフォームにプロプライエタリなボックスエージェントモジュール２０５の多出力を含む。これらのエージェントモジュール２０５は、カスタムシステム及びＥＰＩＣ、ＣＥＲＮＥＲ等の第三者当事者ＥＭＲシステムの両方並びにＢＰ及び血糖測定器等のウェアラブルデバイスからデータを抽出するように構築されている。エージェントモジュール２０５は、抽出中の臨床属性、抽出及び変換に使用されるプロプライエタリ２ステッププロセス、並びに抽出に向けて書かれた最適化されたクエリに関して独自である。更に、エージェントモジュール２０５は、トランザクションシステムの標準インストールがクライアントにより使用されている場合、構成の必要が最小化される独自のプラグアンドプレイ機能を提供する；
○システム１００は、ケア提供に関して独自である構造化データ及び非構造化データを統合することができる；
・データ管理：システム１００は、独自の患者中心共通情報モデルを利用して、様々なデータセットにわたるデータを様々な臨床データ交換標準に標準化し、１次臨床データ及び臨床メモ（例えば、２次臨床診断）から集められる、導出された２次情報（例えば、予後スコア）を保持する；
○システム１００は、ある符号化方式（用語）の別の符号化方式への変換を記述する複数の符号化ディクショナリを保持する；
○これらの符号化ディクショナリは、データソース２０１からのデータ内の用語をシステム１００で使用される標準用語の組に変換するのに使用される；
○例えば、符号化ディクショナリの１つは、ＩＣＤ９で符号化された臨床診断の、ＳＮＯＭＥＤ符号化方式への変換規則を含む。別の例は、研究データをＬＯＩＮＣ符号化方式に変換する；
○１対１符号化マップが符号化方式内の特定のエントリに利用できない場合、システム１００は、ユーザ定義の規則を利用して競合を解決する。システム１００は、そのままの値及び変換された値の両方を保持する；
○データ記憶の一時的及び永続的方式は、１３０によるこのデータへの要求時、３１２に保持すべきデータと、２０１から動的に取得すべきデータとを区別する、３１０内のユーザ定義の規則の組を通して制御される；
○例えば、特定のソースシステムから受信する全てのデータは３１２に保持する必要があり、別のソースシステムからの全てのデータはオンデマンドで２０１から出力とする必要があることを述べる規則があり得る；
○システム１００は、患者中心であり、がんケアに関連する人口統計、在宅服薬、アレルギー、バイタル、観察、研究、及び臨床文書等の複数のドメインを含む共通情報モデル３１２であるデータモデルを含む。３１２は、属性及び関係の観点から独自であるのみならず、記憶の観点についてのユーザ定義の規則によっても駆動される；
○システム１００内の独自の「一時的及び永続的」概念により、データソース所有者及び／又はシステム１００の管理者は、システム１００の管理者により３１２に保持されるデータソース２０１からのデータ量を制御することができる；
・セキュリティ：システム１００は、役割ベースの動的で多形態の認証及び承認プロトコル３１０を使用する。データアクセスは、データソース、消費ユーザ（例えば、地域病院での肺の医師）、及び消費アプリケーション（例えば、オンコロジー専門家アドバイザー分析ツール）に基づいて認可を確立する規則に基づいて認可される。システム１００は、ＣＳ４０９６等の利用可能な最新の最も厳しいセキュリティプロトコルの使用を通して、ＰＨＩ（保護された健康情報）データセットを管理するように予め構成される。加えて、システム１００はＨＩＴＲＵＳＴ承認される；
・アクセス、発見、及び分析：システム１００は、ネットワーク民主化専用の２００を超えるＡＰＩ３１４を含み、分析ツールを消費するための情報提供及びアクセスを確立する；
○ＡＰＩ３１４は、単純なオーバーロードされたメソッドの集合又は複雑なウェブサービスのいずれかであることができる；
○メソッド又はサービスは通常、以下の構造を保持する；
Ｃｏｌｌｅｃｔｉｏｎ／Ｄａｔａ＿ｓｅｔ ＡＰＩ＿Ｎａｍｅ（ｐａｒａｍｅｔｅｒＬｉｓｔ）
ここで、Ｃｏｌｌｅｃｔｉｏｎ／Ｄａｔａ＿ｓｅｔは、ＡＰＩにより呼び出し側プログラム／システムにより提供される戻り値である
ＡＰＩ＿Ｎａｍｅは、メソッド／サービスを通して送られる機能を呼び出すために呼び出し側プログラムが使用する名前である
ＰａｒａｍｅｅｒＬｉｓｔは、メソッド／サービスからの結果／戻された結果を整形するために、呼び出されたメソッドに値又は参照により渡される幾つかのパラメータである；
○ＡＰＩ定義（シグネチャ）は、予め定義されるメカニズムを通して、又は予め定義されるディレクトリサービス、例えば、ＷＳＤＬを通して露出される；
○ＡＰＩ３４１は、システム１００と対話するユーザデバイス／サービス１３０により呼ばれる／呼び出される；
○呼び出し側プログラムは、露出されたｐａｒａｍｅｔｅｒＬｉｓｔの値を渡し、ＡＰＩは、渡された値に基づいた集合又はデータセットのいずれかの形態で応答を返す；
○システム１００は、呼び出し側プログラム／システムのニーズをサポートする機能を提供する、別個のＡＰＩ３１４下でカテゴリ化された様々なサービス／メソッドを含む。幾つかの例は、所与の患者の統合医療記録を戻すＡＰＩ、がん患者の所定のコホートに対して実行された分析クエリの結果を露出するＡＰＩ、システム１００を使用する２つのネットワークパートナー間でセキュアメッセージを渡すＡＰＩ等を含む；
・主要結果：がん治療でのばらつきの低減、診断精度及びステージング精度の改善、及びケア経路へのよりよい準拠性は、不必要なＥＲ／病院来訪の低減並びに教育、スクリーニング、及び準拠ツールを用いて患者を力付けることに繋がる；
・コスト削減：肺がんは、米国で毎年２２０，０００人を超える新規患者を生み出し、推定で毎年８０億ドル〜１００億ドルが非小細胞肺がん（ＮＳＣＬＣ）の治療に使われている（治療は、６５歳を超える患者では５０％高額である）。上に示された結果は、全体の肺がん治療費での１６％の節減機会を表し、これは、ＮＳＣＬＣ（毎年診断される新規肺がん事例の８５％）でのケアコストの１億８０００万ドル〜２億４０００万ドルの削減に置き換えられる；
・乳がんは、米国で毎年２３０，０００人を超える新規患者を生み出し、推定で１６０億ドル〜１７０億ドルが治療に使われている（乳がんのステージ３及びステージ４での治療費は、ステージ１及びステージ２の５倍までになり得る）。上に示された結果は、全体の乳がん治療費での８〜１２％の節減機会を表し、これは、５〜１０％の患者関与率（全体集団のうちの）を仮定して、ケアコストの１億９２００万ドル〜２億４００万ドルの削減に置き換えられる。

Ｃ．治療準拠性を上げて、製薬企業のために慢性疾患結果を改善する
１．服薬非準拠は、製薬業界に対する３０００億ドルの問題を表す − 毎年１２５０００人の死亡に繋がり（主な死因の４位であり、事故死の１位）、病院又は老人ホームの１０〜２０％での受け入れ、及びバイオ医薬品業界の１８８０億ドルの収益損に繋がる。今日の準拠プログラムは、従来のチャネル（郵便、電子メール、電話）を介する限られた患者コミュニケーションを通してこの問題を解決し、投与挙動についてのリアルタイムデータに基づかず、準拠性を症状改善にリンクするヘルスケア専門家（ＨＣＰ）の能力を制限し、患者へのメッセージの有効性を継続して改善することができない。それを受けて、製薬企業は、デジタル及び分析可能な解決策に着手して、介入を個人化し、患者関与の増大を通して結果の改善を実証しつつある：
システム１００は、製薬会社が能動的に患者症状をモニタリングすることにおいて役割を果たし、推奨された治療レジメンに留まり、健康的な行動を強化する（補充を得る、臨床医に会う）のを促進することにおいて独自の役割を果たす。システム１００は、患者のインフォームドコンセントの安全な連続取り込み、処理、及びモニタリングを促進し、投与に関連する機密情報（ＰＨＩ）を医療保険請求書、臨床記録、及び自己報告症状等の他の患者情報と結合して機密情報を結合する。このデータは、分析アルゴリズムにより使用されて、リスク及び推奨介入により患者を層化する傾向スコア、準拠パターン、及び結果尺度等の推測を描き、次に、患者及び提供者ツールは、標的とされる介入及び／又は教育的内容を有する患者又はＨＣＰと通信して、準拠挙動を改善し、結果に影響を及ぼす：
・ヘルスケア専門家（患者を治療するＨＣＰ）、リスク負担エンティティ（医療及び／又は薬剤の請求書処理を促進する保険会社）、患者、及び技術パートナー（準拠データを通知するデバイスパートナー、個人化モバイル通信を可能にするパートナー、個人レベル又はコホートレベルの洞察を生成する分析パートナー）を含む統合パートナーエコシステムを作成する；
・複数のソースからのデータを安全に取り込み、共通フォーマットに調和化して、リスクにある個人を層化し、いずれの介入がいずれのチャネルを介して誰に機能するかを理解し、治療関連関与についてメッセージをカスタマイズする；
・患者及び／又はＨＣＰでの標的介入（メッセージ、インアプリアラート、教育的内容、ダッシュボード）を促進して、専門薬局からの既存のリマインダーを補足する；
・市場後研究を行い、準拠性改善の影響を実証する；
２．システム１００は、準拠解決策の統合部分であり、セキュアデータ収集、標準化、及び分析ホストを提供する：
・分析エンジン：システム１００は、ベースライン分析クエリを提供すると共に、異種データセットからの焦点を絞った分析を可能にする傾向一致コホートを提供する、ＡＰＩ３１４により提供されるサービスとして実施されるコア分析プラットフォームを提供する；
○データは、ソースシステムからシステム１００に流れる；
○データ収集器及びデータ統合器の役割を通して、データは取り込まれ、調和化される；
○調和化データは、データの分析要件及び／又はトランザクション要件に基づいて累積及び／又は非正規化される；
○非正規化／累積データは、標的とされる分析のために特定のデータマートに記憶することができる；
○患者記録は、年齢、性別、民族性、病態、併存疾患、ケアプログラム登録、薬剤タイプ等の複数のファクタに基づいて様々なコホートに分類される；
○ベースライン推論をこれらのコホートにわたり描くことができ、介入のカスタマイズ及び推奨に使用することができる全般トレンドとして記憶される；
○全般トレンドは第三者ベンチマーク／標準と比較され、差異がプラットフォームに記憶される；
○クエリが実行される場合、１つ又は複数の患者コホートは、クエリにより渡されるパラメータに応じてクエリの標的集団として識別される；
○関連するパターン／トレンドは、ＡＰＩ３１４を通して呼び出し側プログラムに露出される；
○トレンドと実生活データとの差異が識別され、予め定義されるスケールに基づいて定量化される；
○加えて、エンドユーザに、生成された推論をオーバーライドする能力が提供される；
○調整ファクタ（元のパターン及び実生活データ差異又はエンドユーザオーバーライドに基づく）は、システム１００のプラットフォームにフィードバックされ、同様のクエリ実行の将来の反復でマージン／確率調整ファクタとして機能する；
○認知クエリの場合、トレンドは、特定の事例への医師の典型的な挙動的反応等の将来の無形ファクタに外挿され、ベースラインクエリ応答に重ねられて予測を提供する；
○システム１００は、動的で自己学習的な分析を提供する。すなわち、システム１００により、エンドユーザは、フィードバックの観点から逆データフローを確立することができ、逆データフローは、境界条件、遮断レベル、割合割り振り、確率分布、及び分析エンジン内の他の数式を調整して、分析クエリの実行の次の反復に影響を及ぼす。収集されたトランザクションフィードバックに基づく分析応答の自己学習的及び自己調整的挙動は、システム１００の独自の前提である；
・情報送出ゲートウェイ：システム１００消費者関与サービスは、健康的な行動を促進する地理的位置に基づくと共に個人化された動機、消費者に関与して、消費者の健康及びウェルネスを管理するゲームベースのツール、並びにヘルスケア専門家（ＨＣＰ）への直接接続を含め、個人の健康プロファイルに基づいてカスタマイズされた内容を有する患者ポータルを含む：
○システム１００の患者ポータルは、統合及び調和化の観点から独自である。すなわち、システム１００の患者ポータルは、患者が全ての認可データを１スポットで見られるようにする単一のゲートウェイである。データは、患者の医療データ、研究結果、放射線画像及びリポート、処方データ、ウェアラブルデバイスデータ、及びＥＫＧ等のデバイスからの波形（ストリーミング）を含む。記録のこれらの全てのデバイス及びシステムは、異なる用語を使用し得る；
○プラットフォームの別の独自の特徴は、スマートデバイス、ラップトップ、電話等の複数の送出チャネルにわたり同じポータルを通して同じ情報をレンダリングすることである；
・エンドツーエンド患者機密データ管理のための施設：システム１００は、役割ベースの動的で多形態の認証及び承認プロトコル３０９を使用する。データアクセスは、データソース、ユーザ（例えば、患者、薬剤師、ＨＣＰユーザ）の識別情報、システム（例えば、患者臨床データを提供するＥＭＲシステム）に基づいて認証を確立する規則に基づいて認可される。システム１００は、ＣＳ４０９６等の利用可能な最新の最も厳しいセキュリティプロトコルの使用を通して、ＰＨＩ（保護された健康情報）データセットを管理するように予め構成される。加えて、システム１００はＨＩＴＲＵＳＴ承認される。

Ｄ．高度分析及びマルチデータ収集を使用した金融性能及び支出性能を改善して、活動に基づく原価計算をもたらす
１．地理的に拡散した複数の施設を有する大規模機関（教育機関及び商用専用）は、通常、多様で複雑なサプライチェーンを管理することが強いられる。「支出」は、通常、広く分散し、中央調整がなく、大きい冗長性及び無駄に繋がる。そのような状況下で直面される重大な問題は、ある施設での在庫の未活用、その一方で、別の施設での同じ在庫の供給薄から、地域のクイックリードサプライの最良ベンダーの識別、経済発注量及び再注文識別等までに及ぶ。これらのサプライチェーンはまた、通常、複数のローカルで運用される発注及び調達システムのネットワークであり、それにより、個々の患者の寿命にわたる「支出」を追跡する可能性がかなり低いことにより妨げられる：
支出分析が向かい、「活動に基づく原価計算」を計算して管理し、一括支払いの最新のヘルスケアパラダイムをサポートするソリッドプラットフォームを確立することである増大するトレンドがある。大規模機関が、ＲＢＥによる提供される処置への一括支払いを論理的に受けいれることができるようにするために、大規模処置（人工股関節置換手術等）下で関わる各活動により分割されたコストの詳細を理解することが、任意の大規模機関にとって重要である；
２．任意の十分に調整された中央化支出分析システムは、以下の広レベルの活動に焦点を当てる：
・供給者（ローカル及び中央化）、患者にサービスする相互リンクされた施設、及び中央化政府機関からなり、全てのステークホルダにわたるデータフローを管理し、調達を支配するグローバル規則を管理する統合エコシステムの作成；
・複数のローカル発注及び調達システムからのデータの取り込み；
・ＥＭＲ、スケジューリングシステム、薬局システム、金融システム、及びキャパシティ管理システム等のローカル臨床及び運用システムからのデータの取り込み；
・国にわたりベンチマーク及びベストプラクティスを提供する第三者ソースからのデータの取り込み；
・「支出」及び臨床データを調和化して、中央化組織に共通のスクリプトを生成する；
・材料／サービスのタイプ、地理的需要及び可用性、臨床の必要性及び緊急性、資本又は非資本ニーズ等の複数のファクタにわたる支出データカテゴリ化；
・支出データを臨床及び／又は治療経路に結び付けて、大きい処置の各サブ活動の活動に基づくコストを生成する。この情報は、サービスに対する支払いではなく、結果に対する支払い等のヘルス業界で出現しつつある新しい支払いモデルにとって重要である；
・様々な提供チャネルを通して、一貫した統合情報を関わる全てのステークホルダ（ローカル施設、供給者、中央化組織等）に提供する；
・調和化された支出データに基づく支出パターン、トレンド、リード時間、補充等の確立；
・支出トレンドを第三者のベンチマークと比較して、差異及び関連する軽減手法を識別する；
・コストと臨床緊急性要件との関係をカバーする規則（ユーザ制御される）を確立する能力；
・ローカルのばらつきを管理しサポートする規則を確立する能力；
・フィードバックを受信し、それを組み込んで、将来のトランザクションを微調整する能力；
・ＰＨＩ承認システム１００：システム１００は、ＣＳ４０９６等の利用可能な最新で最も厳しいセキュリティプロトコルの使用を通して、ＰＨＩ（保護された健康情報）を管理するように予め構成される。更に、システム１００はＨＩＴＲＵＳＴ承認される；
・独自性：システム１００は、ＨＩＴＲＵＳＴ承認されると共に、ＣＳ４０９６暗号化を展開する大学医療センタ（ＡＭＣ）に向けて専ら構築された唯一のＰＨＩキャリープラットフォームである；
・システム１００の患者ポータルは、統合及び調和化の観点から独自である。すなわち、システム１００の患者ポータルは、患者が全ての認可データを１スポットで見られるようにする単一のゲートウェイである。データは、患者の医療データ、研究結果、放射線画像及びリポート、処方データ、ウェアラブルデバイスデータ、及びＥＫＧ等のデバイスからの波形（ストリーミング）を含む。記録のこれらの全てのデバイス及びシステムは、異なる用語を使用し得る。システム１００は、共通言語及び用語に変換する；
○プラットフォームの別の独自の特徴は、スマートデバイス、ラップトップ、電話等の複数の送出チャネルにわたり同じポータルを通して同じ情報をレンダリングすることである；
・活動に基づく原価計算エンジン：システム１００は、金融データを臨床データに結び付けて、大きい治療処置の各サブ活動に対する支出パターンを確立する。例えば、システム１００は、慢性ケアでもなければ、急性ケアでもなく、代わりに、予め定義される時間枠にわたり拡散する典型的な人工股関節置換手術処置の術前、術日、及び術後のケア活動に支出を分割することができる：
○システム１００は、様々な病態での複数の治療経路の活動レベル分割を含む。これらの経路は慢性でもなければ、一過性でもない。代わりに、患者が特定の病態又は異常について治療された時間期間に焦点を当てる；
○例えば、人工股関節置換プロセス及び人工膝関節置換プロセスに関連する術前活動、手術活動、及び術後活動の全ての詳細な分割がある；
○金融データ取り込み後、プラットフォームは、累積して、完全なプロセスを説明するこれらの活動に対してトランザクションデータをタグ付けする；
○金融トランザクションのこのカテゴリ化は、複数の患者及び複数の施設にわたり累積される；
○分析は、これらの累積数に対して実行されて、特定の治療経路の活動毎の平均コスト、コスト及び結果率に基づいて特定の活動を実行するのに最良の施設等のファクタを確立する；
○これらの分析である；
・契約サポートエンジン：システム１００は、活動に基づく原価計算を通して確立されたトレンドを利用して、分析サポートを提供者及びＲＢＥに提供し、価値に基づく支払い及び／又は一括支払い等の新しい支払いモデルの契約期間を確立する：
○活動に基づく原価計算エンジンとして、システム１００は、特定の治療経路をサブ活動に分割する；
○例えば、人工股関節置換手術処置に定義された術前活動、術日活動、及び術後活動の明確なリストがある。これらの活動は、相当量の時間にわたることができるが、慢性状況とは見なされない；
○ヘルスケア業界での新しい支払いモデル下で契約を確立するには、これらのサブ活動のそれぞれに関連するコストを理解することが必須である。サービスに対する料金又は一括支払い契約ではなく、価値に対する料金等のモデル；
○システム１００は、患者混合、地理的及び環境的相関、並びに健康結果等の様々なファクタを考慮して、各サブ活動について活動に基づく原価計算モジュール下で作成されるベースラインベンチマークを利用し、所与の治療経路で、リスク負担エンティティと確立することができる最適な契約期間を理解するうえで金融管理者に役立つ；
・キャパシティ利用：ＥＯＱ及び補充レベルを示唆したシステム１００に基づく中央化処置に基づくキャパシティ利用での１０〜１５％の改善。これは、施設の地理的分布及び中央化処置の程度による影響も受ける：
・契約効率：ＲＢＥによる提供される補償に対する実際の支出の一致に関して、１０〜１２％高い精度。これらの尺度は、そのような一括支払いの額及び治療経路内の明確に識別されるサブ活動による影響も受ける：
・患者混合に基づくキャパシティ調整：施設での患者混合に対して測定されるキャパシティ利用の１５〜２０％の改善。システム１００は、患者混合及びボリュームに基づいて、各施設の最適キャパシティに関して推奨を提供し、無駄及び／又は過剰在庫の上述した低減をもたらす：
・投与コスト効率：１２〜１４％のコスト効率（システム１００のコストに対する全体支出システムコストの低減）は、システム１００を通して達成することができる典型的なＲＯＩである。

Ｅ．包括的がんケアセンタでの翻訳がん研究の加速化
１．がんは、米国での主な死因の２位であり、毎年略６００，０００人の米国人が亡くなり、１７５０億ドルのヘルスケアシステムコストを生じさせる。がん研究での数十年の調査の結果として、毎年がんと診断される１６０万の米国人の多くの余命は着実に延びている。しかし、依然としてがんの真の治療法は比較的少なく、がんの種類によっては、過去数十年にわたり死亡率の改善が殆ど見られなかったものもある。がんは、現在、基本的にゲノムの疾患として認識されている。ＤＮＡの破損は、細胞の無制御の分裂に繋がり、多くの場合、がん性集団が治療に対する耐性を生じさせることを可能にする急速な細胞進化に繋がる。ゲノム科学での最新のブレークスルーをがんケア提供に置き換えて、各個人の特定のがんゲノムに調整された個人化医療手法を作成する後押しがある。これには、通常、１患者当たり多ギガバイトのオーダー及び比較的小さいがんコホートであってもペタバイトのオーダーの大規模ゲノム及び臨床データが関わる：
２．翻訳がん研究は通常、以下を含む：
・時間の経過に伴って進化するにつれて、生殖細胞系列及びがんの両方からのゲノム、エピゲノム、ＲＮＡ配列、及びプロテオミクスデータを含め、各患者についての膨大な量のオミクスデータを取得する；
・この患者レベルのオミクスデータは、他の研究所アッセイ並びに診断、手術、放射線、及び化学療法、治療への反応、及び最終的な結果を含む患者の医療記録からの豊富な臨床データと組み合わせられなければならない；
・これらのデータが各患者について統合されると、がん研究者は、データをクエリして、遺伝子突然変異並びに予後及び治療への反応を予測する他のバイオマーカを探す；
・これらの洞察は、がん生物学、新しい治療モダリティ、及びがん集団の健康についての仮説を生成するため、並びに臨床試験を設計するために有用である；
・幾つかの場合、この統合データは、個人の患者の実際の臨床治療選択肢、すなわち個人化された薬剤を通知することもできる；
３．システム１００は、翻訳がん研究プログラムの統合部分であり、コアデータ管理、取り込み、及びアプリケーションホストサービスを提供する。システム１００は、がん研究者が、研究所で、ベッドサイドで、及び患者集団にわたり研究を駆動するために必要なツール及びデータにアクセスするのに役立つ提供チャネルサービスも提供する。新しいエコシステムビジネスモデルを可能にする幾つかの主要なシステム１００の機能を以下に列挙する。

Ｆ．治療準拠性を増大させて、製薬企業の慢性疾患結果を改善する
情報インターチェンジは、トップの製薬企業がデータ及び分析を使用して、症状をモニタリングし、推奨された治療レジメンに留まり、健康的な行動を強化する（補充を得る、臨床医に会う）のに役立つツールを直接、患者及び患者のヘルスケア提供者チームに提供することにおいて独自の役割を果たすのに役立つ。インターチェンジは、患者のインフォームドコンセントの安全な連続取り込み、処理、及びモニタリングを促進し、ウェアラブル（例えば、Ｆｉｔｂｉｔ、Ａｐｐｌｅ Ｗａｔｃｈ）、薬剤注入器、医療保険請求書、臨床プロファイル、及び患者のモバイルアプリケーションからの自己報告健康及び活動からの投与に関連する機密情報（ＰＨＩ）を結合する：
次に、機密データは、推測（例えば、傾向スコア、準拠パターン、結果尺度）のために分析アルゴリズムにより使用されて、リスクにより患者を層化し、予測される挙動に介入を推奨し、次に、患者及び提供者固有のツールは、患者及び患者の臨床医に標的とされる介入及び情報内容を通知する。

製品品質及び輸入される薬剤の安全性の改善
システム１００は、製薬業界が、食品医薬局安全及びイノベーション法（ＦＤＡＳＩＡ）のタイトルＶＩＩ（Ｐｕｂ．Ｌ．１１２〜１４４号）に記載される連邦政府の期待を満たせるようにする情報インターチェンジとしての役割を果たすことができる。タイトルＶＩＩは、米国内の薬物の安全性、有効性、及び品質の保証に役立つＦＤＡの新しい機関を提供する。例えば、情報インターチェンジは、タイトルＶＩＩの１８のセクションの以下のサブセットで役立つことができる：
１）セクション７０５：リスクに基づく検査頻度。海外薬物製造業者は、データをＦＤＡに定期的に提出して、有限数の検査者がいる状態で海外施設の検査のリスクに基づいてスケジュールを決定する必要がある。したがって、インターチェンジは、製造業者が品質システム分析による評価のために製品データ、施設データ、原材料データ、及びオペレータデータを容易に統合できるようにする。製品品質データを定期的に生成するこの能力は、製造業者がタイトルＶＩＩのこのセクションに準拠できるようにするのみならず、品質システムのレビュー及び検査前に事前対策を講じることができるようにもする；
２）セクション７１０：情報の交換。ＦＤＡは、互恵待遇協定を結び得、企業秘密情報を保護する権限を有し、企業秘密情報を保護する能力を示してきた外国政府に特定の企業秘密情報を提供し得る。ＨＩＴＲＵＳＴ承認情報相互インターチェンジは、企業秘密の取り扱い及び製品品質又は化合物組成データの他のプロプライエタリな側面をサポートする独自のポジションにある；
３）セクション７１１：薬物供給の安全性及び品質の強化。情報インターチェンジは、製造業者が原材料及び完成品を含めて薬剤の製造品質にわたり示す監視及びコントロールを改善することができる。この報告要件をサポートするために、インターチェンジがモニタリングおよび統合し得る品質システムの以下の図を参照されたい。

Claims (15)

1. 患者中心及び価値に基づくケアを提供するヘルスデータシステムにおいて、
   ヘルスデータサーバと、
   セキュアネットワークを介して前記ヘルスデータサーバと通信する１つ又は複数のヘルスデータソースであって、それぞれポーリング許可の組を有する、１つ又は複数のヘルスデータソースと、
   識別子の組及び前記ポーリング許可の組に基づいて、指定された頻度で前記データソースからヘルスデータをポーリングする、前記ヘルスデータサーバの１つ又は複数のエージェントモジュールと、
   前記ポーリングされたヘルスデータを共通情報モデルに提供する第１のスイッチモジュールであって、前記共通情報モデルは、少なくとも１つの患者記録により定義され、各患者記録は１つ又は複数の属性を有する、第１のスイッチモジュールと、
   アクセス許可の組に基づいて、前記共通情報モデルへのアクセスを取得する１つ又は複数のインタフェースモジュールと
   を備えることを特徴とするヘルスデータシステム。
2. 前記共通情報モデルは分散データベースを含み、前記１つ又は複数の属性は、任意選択的に、臨床ヘルスデータ、研究データ、遠隔モニタリングデータ、バイオメトリクス、ウェアラブル、ソーシャルメディアデータ、自己報告データ、モバイルアプリケーションデータ、及びデバイス機器のうちの少なくとも１つを定義することを特徴とする、請求項１に記載のヘルスデータシステム。
3. 前記第１のスイッチモジュールは、前記ポーリングされたヘルスデータが前記１つ又は複数の属性にマッピングされない場合、前記共通情報モデルを新しい属性で増補することを特徴とする、請求項２に記載のヘルスデータシステム。
4. 前記第１のスイッチモジュールは、任意選択的に前記ヘルスデータサーバ及び前記１つ又は複数のヘルスデータソースのうちの少なくとも一方により提供される記憶許可に基づいて、前記ポーリングされたヘルスデータを前記共通情報モデルに提供する前に、前記ポーリングされたヘルスデータをフィルタリングすること、患者記録を互いと突き合わせて照合すること、及び前記セキュアネットワークを介するネットワーク接続を制御することの少なくとも１つを行うことを特徴とする、請求項１〜３のいずれか一項に記載のヘルスデータシステム。
5. 前記指定される頻度は、前記ヘルスデータサーバ及び前記１つ又は複数のヘルスデータソースのうちの少なくとも一方により設定されることを特徴とする、請求項１〜４のいずれか一項に記載のヘルスデータシステム。
6. 前記ポーリングされたヘルスデータを前記共通情報モデルに提供する第２のスイッチモジュールを更に備え、前記第１のスイッチモジュールは、前記第２のスイッチモジュールと通信して、前記ポーリングされたヘルスデータを受信することを特徴とする、請求項１〜５のいずれか一項に記載のヘルスデータシステム。
7. 患者中心及び価値に基づくケアを提供する方法において、
   ヘルスデータサーバの１つ又は複数のエージェントモジュールを介して、ヘルスデータの１つ又は複数のヘルスデータソースをポーリングするステップであって、前記１つ又は複数のヘルスデータソースのそれぞれはポーリング許可の組を有する、ステップと、
   第１のスイッチモジュールを介して共通情報モデルに前記ポーリングされたヘルスデータを投入するステップであって、前記共通情報モデルは少なくとも１つの患者記録により定義され、各患者記録は１つ又は複数の属性を有する、ステップと、
   アクセス許可の組に基づいて、１つ又は複数のインタフェースモジュールを介して前記共通情報モデルへのアクセスを提供するステップと
   を含むことを特徴とする方法。
8. 前記共通情報モデルに投入する前記ステップは、分散データベースに、任意選択的に、臨床ヘルスデータ、研究データ、遠隔モニタリングデータ、バイオメトリクス、ウェアラブル、ソーシャルメディアデータ、自己報告データ、モバイルアプリケーションデータ、及びデバイス機器のうちの少なくとも１つから選択される１つ又は複数の属性を投入するステップを含むことを特徴とする、請求項７に記載の方法。
9. 前記ポーリングされたヘルスデータが前記第１のスイッチモジュールを介して前記１つ又は複数の属性にマッピングされない場合、前記共通情報モデルを新しい属性で増補するステップを更に含むことを特徴とする、請求項７又は８に記載の方法。
10. 前記投入するステップの前に、記憶許可の組に基づいて、前記ポーリングされたヘルスデータをフィルタリングするステップを更に含むことを特徴とする、請求項７〜９のいずれか一項に記載の方法。
11. 前記記憶許可の組は、前記ヘルスデータサーバ及び前記１つ又は複数のヘルスデータソースのうちの少なくとも一方により提供されることを特徴とする、請求項７〜１０のいずれか一項に記載の方法。
12. 前記ポーリングするステップは、前記ヘルスデータサーバ及び前記１つ又は複数のヘルスデータソースのうちの少なくとも一方により設定される指定頻度で行われることを特徴とする、請求項７〜１１のいずれか一項に記載の方法。
13. 前記第１のスイッチモジュールを介して患者記録を照合するステップを更に含むことを特徴とする、請求項７〜１２のいずれか一項に記載の方法。
14. 前記第１のスイッチモジュールを介して、前記ポーリングされたヘルスデータに関して第２のスイッチモジュールをポーリングするステップを更に含むことを特徴とする、請求項７〜１３のいずれか一項に記載の方法。
15. 前記ポーリングするステップは、前記ポーリング許可の組により制限されることを特徴とする、請求項７〜１４のいずれか一項に記載の方法。

Images