JP2020042864A - オンデマンドリアルタイム患者固有データ解析計算プラットフォームを提供するシステムおよび方法 - Google Patents

Abstract

【課題】オンデマンドリアルタイム患者固有データ解析発注を受信し、処理するように構成される計算プラットフォームが提供される。【解決手段】計算プラットフォームは発注を受信し、発注の実行可能性を判定し、次に、発注内で提供されるパラメータに基づき所望の解析を実行する。解析の一環として、計算プラットフォームは１以上のデータソースを調査して、発注された診断に関連するデータを収集することができる。いったんデータが収集されれば、計算プラットフォームは、１以上の予めプログラミングされたアルゴリズムに従ってデータを解析することができる。データセットに適用するアルゴリズムの選択は、発注されたオンデマンドリアルタイム患者固有データ解析の種類によって決定することができる。いくつかの例では、オンデマンドリアルタイム患者固有データ解析は、外部発注ユーザインタフェースを用いて発注することができる。【選択図】図４

Description

本開示は概して、電子発注入力プラットフォームおよび電子医療記録システム内の各種セットの利用可能な医療および医療関連データを、インタフェースを通じてオンデマンド解析し、解析結果を同じインタフェースを通じてリアルタイムで提供することができる計算プラットフォームに関する。

医療に伴うコストに目を光らせつつ高品質の医療サービスを提供することは、従来から医療提供者および関連事業の目的であった。患者が広範な地理的領域にわたって、相互にコミュニケーションを取れる、あるいは取れない複数の医師や医療提供者を訪れる医療環境においては、医学的診断またはその他の検査を実行して患者の関連情報を確認することは、そうした検査や医学的診断が患者の訪れる様々な医療提供者の間で重複し、他の医療提供者には既知である情報を入手するという恩恵を受けずに実行される場合があるため、非効率となり得る。

さらに、医療シーンはますます複雑化しつつあり、低コストで高品質な医療という目的との間でせめぎ合っている。臨床医にとって既知な病状の数は、科学的発見によってこれまで理解があまりされていなかった症状の病因、遺伝学、下位分割に関する詳細な理解が深まるにつれ、さらに増え続けている。ＩＣＤ−９（約１４０００診断コードを含む）基準からＩＣＤ−１０（約６８０００診断コードを含む）基準への移行に例示されるように、このような症状を医療記録文書内に反映させるコードもきめ細やかさを増している。臨床医が利用可能な診断の数と種類は、治療方法と同様に増加の一途をたどっている。

中核の医療行為における上記のきめ細やかさと複雑さの進歩に加えて、医療周縁の事業プロセス、経営、法的監視も同様に複雑化しつつある。医療産業が量ベースの治療から質ベースの治療に移行するにつれ、品質結果の測定もその重要性を劇的に増大させた。患者が過去に受けた治療の質を評価する能力は、最適な医療の決定だけでなく、医療費削減を推し進める上で極めて重要になり得る。しかしながら、こうした評価を実行するのに必要なデータは、相互にコミュニケーションを取れない種々雑多な場所や実体に保管されることが多い。さらに、このような評価に必要な情報は大量であるために、医療提供者が「リアルタイム」で（直に治療に当たっている期間中）、患者が受けた治療の質や、治療が法的基準を遵守しているか否かを判定できない可能性がある。

複数のソースからのデータを集計、調査、解析し、患者の病歴の様々な面を広範かつ綿密に「オンデマンド」で（必要と要請に応じて）総合的に検討する計算プラットフォームは、不要なまたは重複する医学的検査やラボ診断に伴う非効率的な出費を最小限に抑えつつ、医療の質を最大限に向上させるのに役立てることができる。しかしながら、上記の集計、調査、解析は、多くの異なるソースに点在する大量のデータに基づくことが多いため、医療提供者はこのような解析を実行することができない。

本開示は、様々な第三者の内部データベースから集計および調査される医学的データを用いて解析を実行するコンピュータ化プラットフォームに関する。

プラットフォームは、患者の医学的データをリアルタイムで解析して、実際の治療中に、患者と医療提供者に最も関係性が高い解析検査をオンデマンドで発注してその解答を受け取ることで、臨床医による高品質かつ費用効果の高い治療の提供をサポートすることができる。

本開示の例によるオンデマンドリアルタイム患者固有データ解析（「データ診断」と称することもある）を実行する例示の方法を示す図。 本開示の例によるオンデマンドリアルタイム患者固有データ解析を実行する別の例示の方法を示す図。 本開示の例によるオンデマンドリアルタイム患者固有データ解析を実行する例示の方法を示す図。 本開示の例によるオンデマンドリアルタイム患者固有データ解析を実行する例示の計算プラットフォームを示す図。 本開示の例による例示のメッセージハブを示す図。 本開示の例による例示の発注処理アーキテクチャを示す図。 本開示の例による例示の臨床解析エンジンを示す図。 本開示の例による例示のフローチャート設計プロセスを示す図。 本開示の例による例示のｐｄｆジェネレータアーキテクチャを示す図。 本開示の例による例示のデータ統合サービスを示す図。

オンデマンドリアルタイム患者固有データ解析は、１例では、治療時に、臨床医が個別に発注することのできる１そろいの様々な患者固有データ解析とすることができる。いくつかの例では、リアルタイム患者固有データ解析の発注は、複数のデータベースを調査して、特定の患者の関連情報を検索することと、患者の関連情報を収集することと、医師または医療提供者がより高品質でコスト効果の高い患者の体験を提供するのを助けることができる具体的な特徴またはパターンを求めて、収集した情報を解析することとを含むプロセスを開始させることができる。

あるシナリオ例が、リアルタイム患者固有データ解析を実行する概念を例示するのに役立つ。このシナリオ例では、患者は救急処置室に運ばれて、急性の苦痛、外傷、または意識不明状態により情報を提供できない。通常、患者は病歴に関連する質問に確実に回答できないため、治療を提供する臨床医は、医学的問題を診断するだけでなく、臨床医の処方する治療過程に影響を及ぼすおそれのあるその他の悪化要因が存在しないように確保するために、広範な一連の医学的検査を行わなければならない。さらに、医師は、発見される異常が急性なのか慢性なのか、あるいは、過去の治療がアレルギー反応などの悪影響を招いたことがあるか否かを判定することができないため、進行中の問題とそれに関連する適切な治療を判定することが難しい。しかしながら、臨床医が患者のためにオンデマンドリアルタイム患者固有データ解析を発注できれば、計算プラットフォームは複数のデータソース（すなわち、他の臨床医のデータベース、過去の診断データ、薬剤記録、ラボ記録、電子医療記録データなど）を調査して、患者の過去の病歴と治療に関する情報を収集し、収集された情報を解析し、救急処置室で適切または確実に反応できない、不十分にしか反応できない、あるいは意識不明である患者を治療する際に医療提供者の助けとなる要因またはその他の関連情報を判定することができる。１例では、オンデマンドリアルタイム患者固有データ解析は、患者が過去に受けた、あるいは現在受けている投薬治療に関する情報、患者に関して実行された過去の全ラボ作業、過去の診断、過去の入院歴を検索することができる。オンデマンドリアルタイム患者固有データ解析によって検索された情報は、単独のデータベースにすべて置くことができる、あるいは、いくつかの例では、第三者の医療提供者によって維持される種々雑多なデータベースに置くことができる。計算プラットフォームは、これらのデータベースをそれぞれ調査して、オンデマンドリアルタイム患者固有データ解析を発注する患者の関連情報が、特定のデータベースに記憶されているかどうかを確認することができる。

臨床医がラボ検査を発注して、患者にとって最適な治療過程を判定するのとほぼ同じように、臨床医はリアルタイム患者固有データ解析を発注して、具体的な患者に関するデータを調査および解析して治療過程を教示するプロセスを開始させることもできる。

図１は、本開示の例によるオンデマンドリアルタイム患者固有データ解析を実行する例示の方法を示す。図１に示すように、臨床医１０２は、ラボ診断発注入力インタフェースまたはその他の発注入力インタフェース１１４を用いてオンデマンドリアルタイム患者固有データ解析プロセスを開始することができる。発注入力インタフェース１１４は、いくつかの例では、ラボサービスプロバイダが検査機関での試験を発注する、あるいは臨床医が特定の薬局に直接処方薬を発注するために利用する既存のコンピュータインタフェースとすることができる。既存の発注入力インタフェースを利用することによって、医療提供者は既存のワークフロー内で治療中の特定の患者に関して、共通のインタフェースにラボ診断とオンデマンドリアルタイム患者固有データ解析の両方を発注させることができる。いくつかの例では、オンデマンドリアルタイム患者固有データ解析は、（後で詳述する）オンデマンドリアルタイム患者固有データ解析計算プラットフォームとのインタフェース専用の別個のインタフェースを用いて発注することができる。

いったん臨床医１０２がオンデマンドリアルタイム患者固有データ解析を開始すれば、プロセスは、患者記録の位置を特定するステップ１０４に進むことができる。ステップ１０４で、発注入力システムは、名前、誕生日、年齢、およびその他、臨床医または医療提供者が意図する対象者に関して確実に検査（すなわち、オンデマンドリアルタイム患者固有データ解析またはラボ診断）を発注することができる識別情報を含む患者の記録の検索を試みることができる。

いったん患者がステップ１０４で識別されれば、プロセスは検査の発注を開始できるステップ１０６に進むことができる。オンデマンドリアルタイム患者固有データ解析の例では、ステップ１０８で、医療提供者は利用可能な検査リストからオンデマンドリアルタイム患者固有データ解析検査を選択することができる。

オンデマンドリアルタイム患者固有データ解析の種類
以下のオンデマンドリアルタイム患者固有データ解析に関する説明は、例示を目的としており、オンデマンドリアルタイム患者固有データ解析計算プラットフォームの範囲の包括的リストまたはその限定と解釈すべきではない。

１例では、臨床医は、患者が受けた治療の質を確認したいと思うかもしれない。さらに、医療提供者は、臨床医が患者の治療の質を評価し、患者の現状を把握し、患者の治療の質を向上させることができるように、ＮＣＱＡ／ＨＥＤＩＳ（登録商標）、メディケアアドバンテージ５星格付け評価、ＵＲＡＣ評価、州固有の基準（たとえば、ＮＹ ＱＡＲＲ評価）、民間のＡＣＡ ＱＲＳ評価、ＰＱＲＩ評価、またはその他の適用可能な評価などの国の治療基準に基づいて治療の質を査定したいと思うかもしれない。このような例では、医療提供者は、質関連のオンデマンドリアルタイム患者固有データ解析を発注して、患者の過去の病歴に関連するデータを調査および解析して、患者が受けた治療の質と、患者を適用可能な治療標準内に導くために講じるべき治療ステップとを評価することができる。

別の例では、新患、複数の病気を抱える患者、または病歴に関する詳細を提供できない患者らの広範な病歴を認識できないことが支障となっている臨床医は、患者の病歴に関する情報をさらに必要とする、あるいは求めるかもしれない。上記シナリオでは、開業医は、患者の過去の臨床診断、処方薬、ラボ結果、外科的処置などに関連する情報を求めて各種医療団体の電子医療記録を調査する履歴データ関連オンデマンドリアルタイム患者固有データ解析を発注したいと考えるであろう。

別の例では、医師は患者の病歴と進行度を確認したいと思うが、患者の病気や同時罹患の認識や、リスクスコアのコード化の精度要件における専門知識が制限されることが多い。上記シナリオでは、医療提供者は、データを調査および解析して、関連リスクスコアモデル内で具体的な患者の過去、現在、未来の疾病の負担およびリスクスコアを判定するリスクスコア関連のデータ診断を発注することができる。

別の例では、医療提供者は、検査の重複を回避しようとするが、実行された類似の検査の結果、または処方遵守、適切な診断撮像ガイドライン、専門医治療などの治療考慮事項に関する患者コスト担当機関が命じるパラメータが、どのくらいの頻度で、どのくらい最近に、あるいはどのように得られたかを認識できないことが多い。上記シナリオでは、医療提供者は、無駄回避関連のオンデマンドリアルタイム患者固有データ解析を発注することができる。無駄回避関連のオンデマンドリアルタイム患者固有データ解析は患者関連データを調査および解析して、患者治療の保険保護対象範囲ガイドラインに関連する潜在的に不要な利用およびコストを特定する関連情報を検索し、よりコストのかからない代替策を発見することができる。

オンデマンドリアルタイム患者固有データ解析の種類の別の例では、医師は、患者が利用資格を有する様々な治療管理リソースを判定したいと考えるかもしれない。しかしながら、このようなタスクは、大抵の場合、臨床医は患者が利用資格を有する国、州、医療団体固有のプログラムを知ることができないために困難な場合がある。上記シナリオでは、臨床医は、それらのプログラムおよび患者のプログラムに対する適格性に関連するデータを集計、調査、解析する的確性関連のオンデマンドリアルタイム患者固有データ解析を発注することができる。

図１の例に戻ると、いったん臨床医が患者のために発注したいオンデマンドリアルタイム患者固有データ解析の種類を選択すれば、プロセスはステップ１１０に進んで、診断を外部計算プラットフォームに発注することができ、外部計算プラットフォームは発注されたデータ診断の関連情報を求めて各種データソースを集計および調査して、集計および調査されたデータの解析を実行し、その結果のレポートを構築し、結果を医療提供者に送信する。ステップ１１２で、医療提供者は解析を受け取った計算プラットフォームの結果をリアルタイムで視ることができる。

ステップ１１０で発注され、ステップ１１２で結果が見られるプロセスは、要請された解析を実行する計算プラットフォームに対して発注することを含むことができる。図２は、本開示の例によるオンデマンドリアルタイム患者固有データ解析を実行する別の例示の方法を示す。図１に示す方法と同様に、臨床医２０２は、ステップ２０４で、オンデマンドリアルタイム患者固有データ解析を発注することができる。ステップ２０６で、発注はラボ情報システムまたはその他の発注入力プラットフォームで受信することができる。情報システムまたは発注入力プラットフォームは、出された発注を見て、発注が従来のラボ診断、処方薬、またはその他の従来の発注に関するものか、あるいは発注がオンデマンドリアルタイム患者固有データ解析に関するものかを判定することができる。発注がオンデマンドリアルタイム患者固有データ解析に関するものであると判定された場合、プロセスはステップ２０８に進み、発注は（以下詳述する）オンデマンドリアルタイム患者固有データ解析サービスプロバイダに送られる。ステップ２１０で、オンデマンドリアルタイム患者固有データ解析サービスプロバイダはウェブサービスを利用して、要請をパースし、所望のデータを集計、調査、解析し、オンデマンドリアルタイム患者固有データ解析の結果／レポートを生成することができる。ステップ２１２で、その結果が受信され、要請元のサービスプロバイダに返信される。

図３は、本開示の例によるオンデマンドリアルタイム患者固有データ解析ウェブサービスの例示の機能を示す。臨床医３０２は図１および図２を参照して上述したように、ステップ３０４でオンデマンドリアルタイム患者固有データ解析発注を出すことができる。オンデマンドリアルタイム患者固有データ解析発注は、発注入力プラットフォーム３０６で受信することができる。上述したように、オンデマンドリアルタイム患者固有データ解析は、ラボサービスプロバイダが使用するものと同じ計算プラットフォーム、薬局、あるいはその他の電子または発注入力プラットフォームを採用して発注することができる。１例として、商業ラボサービスプロバイダを利用する医療提供者は、ラボサービスの発注に使われる電子ユーザインタフェースを採用して、オンデマンドリアルタイム患者固有データ解析も発注することができる。別の例では、発注入力をサポートする電子医療記録システムを利用する医療提供者は、電子ユーザインタフェースを採用してデータ診断も発注することができる。

オンデマンドリアルタイム患者固有データ解析の発注プロセスの一環として、医療提供者は発注の一部に包含基準を含むことができる。包含基準は、リアルタイム患者固有データ解析に含めたいと考える解析の種類またはデータセットを含むことができる。１例として、医師が質関連のオンデマンドリアルタイム患者固有データ解析を発注したいと思う場合、開業医は様々な理由から、メディケアアドバンテージ５星格付け評価などの特定の治療基準を含めたいと考えるかもしれない。この場合、開業医は、メディケア標準をオンデマンドリアルタイム患者固有データ解析に含めるべきであると明示するユーザインタフェースを採用することができる。

また、オンデマンドリアルタイム患者固有データ解析の発注プロセスの一環として、医療提供者は発注の一部として排除基準を含めることができる。排除基準は、オンデマンドリアルタイム患者固有データ解析から排除したいと考える解析の種類またはデータセットを含めることができる。医療提供者はすべての利用可能な質評価の一般的な解析を発注することができ、プロバイダは評価のサブセットを含む具体的なプログラム（ＮＣＱＡまたはＨＥＤＩＳなど）を選択する排除基準を提供することができる、あるいは、プロバイダは個々の評価を選択することができる。

具体的なオンデマンドリアルタイム患者固有データ解析を発注する際、開業医は階層的選択メニューを提示され、階層の各層は、開業医がその前の層に関して行った選択に依存する。１例では、開業医がメディケード解析のみを実行したいと決定する場合、プログラムの種類（すなわち、成人プログラム、子供プログラム）を指定し、ニューヨーク、フロリダ、カリフォルニアなどの州も指定することができる。このように、階層メニューは、オンデマンドリアルタイム患者固有データ解析ウェブサービスに送信され、ウェブサービスによって使用されて所望の解析を実行する１セットの包含および排除基準を生成することができる。

いくつかの例では、包含および排除基準は計算プラットフォーム／ウェブサービスによって生成することができる。たとえば、臨床医は質関連の診断を発注することができる。特定の患者に関連する情報に基づき、計算プラットフォームは包含および排除基準を生成することができる。たとえば、計算プラットフォームが、特定の患者をニューヨーク州のメディケア患者およびメディケード患者としても認識する場合、プラットフォームは臨床医に決定を下させる代わりに、明らかに二重の有資格患者に対して評価されるべき質基準を特定することができる。別の例では、臨床医は患者に適用可能な異なる臨床品質基準について自覚していない。このように、臨床医が高レベルな階層性オンデマンドリアルタイム患者固有データ解析を発注する場合、計算プラットフォームは、各患者の関連品質基準への適用可能性を認識し、該当する解析を適用する。

他の例では、オンデマンドリアルタイム患者固有データ解析は、オンデマンドリアルタイム患者固有データ解析計算プラットフォーム／ウェブサービスに直接リンクされるスタンドアローンユーザインタフェースを用いて発注することができる。ラボサービスプロバイダのユーザインタフェースが採用される図３の例では、発注入力プラットフォーム３０６がステップ３０８でオンデマンドリアルタイム患者固有データ解析発注を受信することができる。ステップ３１０で、オンデマンドリアルタイム患者固有データ解析発注は、処理の前にオンデマンドリアルタイム患者固有データ解析計算プラットフォーム／ウェブサービスに送ることができる。

オンデマンドリアルタイム患者固有データ解析計算プラットフォーム３１６はステップ３２４で発注を受信することができる。医療提供者によって生成される発注は、医療提供者がオンデマンドリアルタイム患者固有データ解析を発注した患者に関して計算プラットフォームが確実に解析を実行できるように、名前とその他の識別情報（誕生日、社会保障番号、保険情報など）など治療下の患者に関する情報を含むことができる。ステップ３２６で、予備チェックが実行されて、患者の保険会社や、会計責任のある医療機関、病院、またはリスク共有機関などのその他の関連団体が、医療提供者によって発注されたオンデマンドリアルタイム患者固有データ解析を認可し、そのコストをカバーするように確保する。保険会社またはその他の関連団体がオンデマンドリアルタイム患者固有データ解析を認可しないと判定された場合、プロセスはステップ３２２に進み、そこで「未検査」というメッセージを生成することができる。ステップ３２０で、「未検査」メッセージは発注システム発注メッセージフォーマット（後で詳述する）に同調させて、ステップ３１２で発注システムに送信することができる。最後に、ステップ３１４で、保険会社またはその他の関連団体が認可しないことによりオンデマンドリアルタイム患者固有データ解析が実行されなかったことを示す回答を医療提供者に返信することができる。

しかしながら、保険会社またはその他の関連団体がオンデマンドリアルタイム患者固有データ解析を認可する場合、プロセスはステップ３２８に進んで、計算プラットフォームは、患者がオンデマンドリアルタイム患者固有データ解析ウェブサービスシステム内に存在するか否か、および解析を実行するのに十分なデータ履歴が存在するか否かを確認することができる。このような解析は適格化アルゴリズムによって実行することができる。適格化アルゴリズムは、システムが患者のＩＤを十分に自信を持って確定しているか否か、および解析を実行するのに十分なデータがあることを確信しているか否かを判定することができる。

適格化アルゴリズムが、患者がシステム内に存在し、オンデマンドリアルタイム患者固有データ解析を実行するのに十分なデータ履歴を有することが確信されると判定する場合、プロセスはステップ３３０、３３２、３３８に進むことができる。ステップ３３０で、内部データベース（またはその他のデータ記憶媒体）を調査して、発注されたオンデマンドリアルタイム患者固有データ解析に関連する情報を抽出することができる。

内部データベースは、計算プラットフォーム内に局地的に記憶されるデータベースとすることができる。データベースは、各種所属団体によって提供され、識別されずに長期にわたって合致される情報で構成することができる。１例として、ブルークロスブルーシールド（ＢＣＢＳ）（登録商標）などの保険会社が患者へのオンデマンドリアルタイム患者固有データ解析サービスに所属する場合、ＢＣＢＳは患者に関して有するすべてのデータを計算プラットフォームに提供することができる。そのデータは、計算プラットフォーム自体によって維持されるデータベース内に吸収し保管することができる。上記データセットは、バッチまたはトランザクショナルデータ供給プロセスを通じて設定および維持することができる。

よって、医師がオンデマンドリアルタイム患者固有データ解析を発注すると、発注が患者の治療の代わりにおよび患者の治療のために解釈され、内部データベースが調査および解析されて、特定の患者の関連情報を特定および抽出することができる。そうする際、内部データベース内に記憶される非識別データは、オンデマンドリアルタイム患者固有データ解析を発注する患者に属するデータとして抽出および再識別することができる。

内部データベースは複数のデータセットを含むことができ、各データセットは特定の所属団体から提供されるデータに対応する。１例では、１つのデータセットはＢＣＢＳ患者に属し、別のデータセットはラボサービスプロバイダに属することができる。よって、患者の臨床医がオンデマンドリアルタイム患者固有データ解析を要請すると、患者のＩＤおよびその他の包含および排除基準に応じて、計算プラットフォームは内部データベースに記憶される関連データセットからデータを抽出し、再特定し、必要に応じて、患者のＩＤに基づきそのデータを長期にわたって合致させ、解析されるようにデータを１つの位置にまとめることができる。いったんデータが解析されれば、データが識別されないようにまとめられたデータは削除することができる（最初のデータセットは元のままである）。

ステップ３３２および３３８で、計算プラットフォームは、第三者が提供する各種外部データベースからのデータも調査することができる。１例として、内部データベースに記憶されるデータを医療提供者または医療団体から計算プラットフォームに提供させるのではなく、データは第三者のデータベースに保持および記憶させることができる。計算プラットフォームはそれらのデータベースにアクセスして、オンデマンドリアルタイム患者固有データ解析を要求する患者の関連データだけでなくオンデマンドリアルタイム患者固有データ解析自体も調査することができる。

いったんデータが各種データベースから調査されると、ステップ３３４で、計算プラットフォームは採用される適切な解析プロセスを判定して、臨床医３０２の所望する結果を生成することができる。どの解析測定値を採用すべきかだけでなく、それらの解析をどのように実行すべきかを決定するアルゴリズムの作成を以下にさらに詳述する。ステップ３３６で、計算プラットフォーム３１６は、ステップ３３４で決定された解析測定値を用いて各種データソースから調査されるデータのリアルタイム解析を実行することができる。

いったん解析がステップ３３６で実行されれば、回答パッケージをステップ３１８で作成することができる。回答パッケージの形成についてさらに詳細に後述する。ステップ３２０で、回答パッケージは、ステップ３２０で発注入力プラットフォーム３０６に送り返すことができる。発注入力プラットフォーム３０６はステップ３１２で回答を受信し、ステップ３１４で回答パッケージを医療提供者に発送することができる。

図４は、本開示の例によるオンデマンドリアルタイム患者固有データ解析を実行する例示の計算システムを示す。図４の計算システムは、外部インタフェース部４０２と、オンデマンドリアルタイム患者固有データ解析計算プラットフォーム部４０４の２つの主なコンポーネントを含むことができる。計算システム４００の外部インタフェース部４０２は、上述したようにウェブサービスの外部に計算システムのコンポーネントを含むことができる。たとえば、計算システム４００の外部インタフェース部４０２は臨床医４０６を含むことができる。図４は、本開示の例によるリアルタイム患者固有データ解析計算プラットフォームの例示の概要を示すことができる。

上述したように、オンデマンドリアルタイム患者固有データ解析の要請者（すなわち、ユーザ）は、治療中の患者のオンデマンドリアルタイム患者固有データ解析を発注したいと望む医療提供者を含むことができる。臨床医４０６はいろいろな種類のインタフェースを利用して、このような診断を発注することができる。図４の例では、２つのインタフェース例を示す。オンデマンドリアルタイム患者固有データ解析の要請者は、上述したようなラボ発注システムまたは処方薬発注システム用のユーザインタフェースとすることができる発注インタフェース４０８を利用することができる。発注インタフェース４０８を利用して血液作業などのラボサービスを発注することができ、同じ発注インタフェース４０８を利用して（上述したように）オンデマンドリアルタイム患者固有データ解析サービスを発注、送信、配信することもできる。

また、臨床医４０６は、電子医療記録インタフェースまたはその他の発注入力プラットフォーム４１０を利用して、オンデマンドリアルタイム患者固有データ解析を発注することもできる。電子医療記録（ＥＨＲ）は、医療提供者によって維持される患者の病歴の電子版である。いくつかの例では、医療提供者は、ＥＨＲを用いて患者の病歴を調査し、同じインタフェース内で、患者に関して実行されるラボ作業を発注することができる。このインタフェース４１０を用いて、臨床医４０６は、ラボ診断または処方薬とほぼ同じようにオンデマンドリアルタイム患者固有データ解析を要請することができる。同様に、その他の発注入力プラットフォームもデータ診断の発注に適用することができる。たとえば、投薬発注プラットフォーム、放射線検査発注入力、その他の発注入力システム、またはデータ診断発注専用のプラットフォームなどである。

いったん臨床医４０６がインタフェース４０８または４１０を用いてオンデマンドリアルタイム患者固有データ解析を要請すれば、発注は発注システム４１２に送信することができる。上述したように、発注システム４１２は、４０８および４１０で例示されるような外部ユーザインタフェースからの発注を満たすための内部処理および通信システムである。発注システムは独自の内部プロセスを用いて発注を処理し、処理のために、オンデマンドリアルタイム患者固有データ解析要求を計算プラットフォーム４０４に送ることができる。このようにして、発注システムはオンデマンドリアルタイム患者固有データ解析サービスの配給元として利用できる一方、オンデマンドリアルタイム患者固有データ解析計算プラットフォーム４０４は患者に配給される実際のオンデマンドリアルタイム患者固有データ解析サービスを提供することができる。

計算プラットフォーム４０４はメッセージハブ４１４を含むことができる。メッセージハブ４１４は、計算プラットフォーム４０４と発注システム４１２などの外部との間のインタフェースとして機能することができる。メッセージハブ４１４は計算プラットフォーム４０４に通信機能を付与して、発注を承諾して、オンデマンドリアルタイム患者固有データ解析の結果を有するレポートを関係者に提供することができる。

図５は、本開示の例による例示のメッセージハブを示す。例示のため、メッセージハブ５０４とラボデータエクスチェンジ４０２との間のインタフェースも示す。図４を参照して上述したように、発注システム４１２は、オンデマンドリアルタイム患者固有データ解析を発注する臨床医４０６と計算プラットフォーム４０４との間のインタフェースとして機能することができる。図５の例に戻ると、発注システム４１２はプラットフォームデータエクスチェンジ５１２を含むことができる。プラットフォームデータエクスチェンジ５１２は、発注システム４１２と計算プラットフォーム４０４との間のウェブ／ネットワークインタフェースを提供することができる。

プラットフォームデータエクスチェンジ５１２はウェブサービス５１４を含むことができる。ウェブサービス５１４はメッセージハブ内に位置するウェブサービス５０４を介して、プラットフォームデータエクスチェンジ５１２とオンデマンドリアルタイム患者固有データ解析計算プラットフォームとの間で通信を開始し実行することができる。１例では、ウェブサービス５１４は、プラットフォームデータエクスチェンジから、メッセージハブセンター内に位置するウェブサービス５０４とセキュアソケットレイヤ（ＳＳＬ）認証５１６をやり取りすることができる。

プラットフォームデータエクスチェンジへのオンデマンドリアルタイム患者固有データ解析プラットフォームのＩＤを確定するため、ＳＳＬ認証をオンデマンドリアルタイム患者固有データ解析計算プラットフォームのメッセージハブからプラットフォームデータエクスチェンジに渡すことができる。ＳＳＬ認証５１６は、プラットフォームデータエクスチェンジとメッセージハブセンターとの間で安全な通信ソケットを開放し確立するためにも使用することができる。

いったんオンデマンドリアルタイム患者固有データ解析の発注がメッセージハブセンターによって受信されれば、入力プロセッサ５０６に送信することができる。入力プロセッサ５０６は発注を受信し、発注をオンデマンドリアルタイム患者固有データ解析の実際の処理を実行するコンポーネントによって読取可能なフォーマットに変換することができる。１例では、計算プラットフォームは、当業者にとって既知なヘルスレベル７（ＨＬ７）プロトコルを採用することができる。入力プロセッサ５０６は、オンデマンドリアルタイム患者固有データ解析の発注を入力し、オンデマンドリアルタイム患者固有データ解析計算プラットフォームによって使用されるようにＨＬ７フォーマットに変換することができる。

受信した発注がいったん適切なフォーマットに変換されれば、後で詳述する発注処理ステップ５０８に送信することができる。また、発注メッセージは、システムで受信した発注を保管することのできるログファイルデータベース５１０に送信することができる。ログファイルデータベース５１０は演算インテリジェンスソフトウェア５２０によってアクセスすることができる。演算インテリジェンスソフトウェア５２０はログファイルデータベース５１０上で様々なクエリを実行して、計算プラットフォームが受信した発注に関する様々な解析を行うことができる。解析の種類は、たとえば、受信した発注の種類に関する解析、オンデマンドリアルタイム患者固有データ解析を発注している団体または個人に関する解析、オンデマンドリアルタイム患者固有データ解析計算プラットフォームが受信した発注を検討するときに収集することのできるその他の情報を含むことができる。

ステップ５２４で、処理された発注は、メッセージハブ５００に返信することができる。いくつかの例では、処理済みの発注は生（未編集）フォーマットで返信することができる、あるいは、いくつかの例では、結果のレポートを有するｐｄｆファイルとして同時に送信することができる。発注は、生結果データをＨＬ７観察結果メッセージ（ＯＲＵ）またはｐｄｆファイルに変換することのできる出力プロセッサ５２２によって受信することができ、別の例では、単に発注処理ステップ５２４から受信されるｐｄｆと一緒に送信することができる。

いくつかの例では、出力プロセッサは複数ファイルフォーマットで結果を送信することができるため、オンデマンドリアルタイム患者固有データ解析の消費者、および／またはユーザが採用するユーザインタフェースは所望する出力フォーマットを選択できる。出力ファイルフォーマットは、メッセージのウェブサービス５０４を介してユーザに返信することができ、結果パッケージをプラットフォームデータエクスチェンジ５１２のウェブサービス５１４に中継することができる。

図４に戻ると、いったん発注が受け付けられて、上述したようにメッセージハブによって処理されれば、発注をオンデマンドリアルタイム患者固有データ解析発注処理システム４１６に送信することができる。オンデマンドリアルタイム患者固有データ解析発注処理システム４１６の役割は、オンデマンドリアルタイム患者固有データ解析発注を推敲するのに必要な技術を調整することである。

図６は、本開示の例による例示の発注処理アーキテクチャを示す。上述したように、メッセージハブ５００は、発注パラメータを発注処理コンポーネント６００に送信することができる。パラメータの送信は、発注処理コンポーネント６００内に位置するウェブサービス６０２によって簡易化することができる。ウェブサービス６０２は、図５のメッセージハブに関連して説明したウェブサービスと略同じように発注処理コンポーネント６００との間の通信を簡易化することができる。

ステップ６０４で、発注処理コンポーネントは、図３のステップ３２８に関して上述したように患者の検索を開始することができる。患者検索の一部として、患者のパラメータ（すなわち、名前、誕生日、またはその他の識別情報）をデータレイク６０６に問い合わせることができる。データレイク６０６は、図１〜図３を参照して上述したように患者の関連情報を含む１以上のデータベースを表すことができる。ステップ６０４で、データレイク６０６は患者のパラメータで問い合わせることができ、データレイクは患者に関連するデータの位置と識別子を返すことができる。

発注処理コンポーネントが患者のパラメータに基づきデータレイクからデータの位置と識別子を抽出できる場合、患者がシステム内に存在することを確定できる。しかしながら、システムがデータレイク６０６からデータの位置または識別子を抽出できない場合、システムは図３を参照して説明したステップ３２２に従ってエラーメッセージを返すことができる。

発注処理の一環として、システムは、オンデマンドリアルタイム患者固有データ解析を実行するのに十分なデータがあるか否かをチェックすることができる。ステップ６１２で、発注処理コンポーネントは、患者のパラメータを用いてデータレイク６０６の検索を開始し、患者にとって十分なデータが存在するか否かを判定してオンデマンドリアルタイム患者固有データ解析に伝える。このプロセスは、図３のステップ３２８に関して上述されている。不十分なデータしか存在しないと判定された場合、システムは図３を参照して上述されたステップ３２２に従ってエラーメッセージを返すことができる。データレイクは、十分なデータが存在するか否かを示す（１または０に設定される）ブールフラグを返すことができる。データレイクは、このような場合、データが不十分な様子を示す詳細フラグ（多くのインジケータのうちの１つに設定される）も返すことができる。

ステップ６０８で、所属団体のチェックは、図３のステップ３２６を参照して説明したように開始させることができる。患者の健康保険パラメータを送信して、所属団体マップ６１０に問い合わせることができる。所属団体マップ６１０は、オンデマンドリアルタイム患者固有データ解析を認可する団体のリストとすることができる。患者の医療団体が所属しており、オンデマンドリアルタイム患者固有データ解析を認可する場合、診断が認可されることを示すブールフラグを返すことができる。このような場合、認可または未認可を示す（多くのインジケータのうちの１つに設定される）詳細フラグも返すことができる。診断が認可されない場合、図３のステップ３２２に記載されるようにエラーメッセージを送信することができる。

ステップ６１４で、ステップ６０４、６０８、６１２で開始されたチェックがすべて肯定結果を示す場合、プロセスは（さらに後述する）臨床解析エンジン６１６からの解析結果を要求できるプロセス解析ステップに進むことができる。ステップ６１４で、発注パラメータが臨床解析エンジン６１６に送信されて、要求された解析を実行し、結果を返すことができる。臨床解析エンジンについて、さらに後述する。

ステップ６１８で、いったん臨床解析エンジン６１６が結果を作製すれば、その結果はレポートジェネレータ６２０に送られて、ユーザが使用する所望のフォーマットに変換することができる。レポートジェネレータについて、さらに後述する。

よって、上述したように、発注処理コンポーネント６００は、オンデマンドリアルタイム患者固有データ解析発注を処理し、その結果をユーザに戻すために、データレイク６０６、所属団体マップ６１０、臨床解析エンジン６１６、レポートジェネレータ６２０などの個々のコンポーネントを調整することができる。

図４に戻ると、上述したように、オンデマンドリアルタイム患者固有データ解析発注処理部４１６は、臨床解析エンジン４１８に接続することができる。臨床解析エンジン４１８は、データレイク４２２に記憶されるデータベースなどの計算プラットフォームからアクセス可能なデータ記憶アセットに対して、予めプログラミングされた解析アルゴリズムまたはデータ解析スキームを実行する解析計算ランタイム環境を提供することができる。

図７は、本開示の例による例示の臨床解析エンジンを示す。臨床解析エンジンは構成管理モジュール７０４、解析サービス７０６、計算クラスタ７０８を含むことができる。構成管理モジュール７０４は、（後で詳述する）フローチャートデザイナ７０２によって生成されるアルゴリズムとデータ解析スキームとの一貫性を確立および維持する役割を果たすことができる。

解析サービス７０６は、発注処理モジュール７１０から受信した発注を処理することによってオンデマンドリアルタイム患者固有データ解析を実行することができる。解析サービス７０６は、オンデマンドリアルタイム患者固有データ解析をユーザの仕様に応じて確実に実行するため、発注処理モジュール７１０から受け取った要求を解析し、データレイク７１２からの適切なデータが適切なアルゴリズムまたはアルゴリズムセットを用いて解析されるように確保することによってこのタスクを実行することができる。

上述したように、オンデマンドリアルタイム患者固有データ解析発注は、１セットのデータに関して実行される１以上のデータ解析スキームまたはアルゴリズムを開始することができる。アルゴリズムまたはデータ解析スキームは、フローチャートデザイナ７０２によって作成することができる。フローチャートデザイナ７０２はプラットフォームとすることができ、該プラットフォームによって、プログラマは１以上のアルゴリズムを予めプログラムし、アルゴリズムが特定のオンデマンドリアルタイム患者固有データ解析に関連するデータをどのように解析するかを明示する。１例では、フローチャートデザイナ７０２は、論理的考慮事項をデータに適用されるアルゴリズムプロセスに翻訳する共通トランスレータとしての役割を果たすことができる。上述したように、各データ解析スキームまたはアルゴリズムは一連の包含および排除基準を含むことができる。排除および包含基準は、ユーザによって規定し、ユーザが発注するオンデマンドリアルタイム患者固有データ解析の種類によって指定することができる。

フローチャートデザイナを用いて、プログラマは、利用しやすい構文を用いて検索の包含および排除基準を入力することができ、その後、１セットのデータに対して適用されてオンデマンドリアルタイム患者固有データ解析を実行することができるアルゴリズムプロセスに翻訳／コンパイルすることができる。解析サービス７０６は発注を受けると、どのアルゴリズムまたはアルゴリズムのセットが１セットのデータに適用されるかを判定することができる。

解析サービス７０６は、データレイク７１２から患者データを検索および抽出することもできる。上述したように、発注は、オンデマンドリアルタイム患者固有データ解析を発注した患者に関する識別情報を含む。このような情報とアルゴリズムが提供する包含および排除基準とを用いて、解析サービス７０６はデータレイク７１２から患者データを抽出することができる。データレイク７１２は、上述したように内部および外部データベース、またはその他のデータサービスを含むことができる。

解析サービスは、データレイク７１２から所望のデータを抽出し、その後、オンデマンドリアルタイム患者固有データ解析要求の遂行に関係すると判定されたアルゴリズムまたはアルゴリズムを実行することができる。大きなデータセット上で大量のアルゴリズムを効率よく実行するのに必要な処理パワーと速度を提供するため、解析サービス７０６は計算クラスタ７０８を利用することができる。計算クラスタ７０８は、１以上のアルゴリズムを実行するのに必要な処理能力を提供する１以上のサーバを含むことができる。このように、解析サービス７０６は、具体的なデータ解析に必要な処理ニーズと解析されるユーザ情報とに基づきデータを処理するために使用されるサーバの数をカスタマイズすることができる。

図４に戻ると、臨床解析エンジン４１８は、オンデマンドリアルタイム患者固有データ解析発注処理モジュール４１６から発注を受信することができる。受信した発注は、データ４２２から調査され抽出されるデータと、抽出されたデータを解析するために使用されるフローチャートデザイナ４２４によって設計されるアルゴリズムとを決定することができる。フローチャートデザイナ４２４は、データ解析スキームを作成したいと思うプログラマと、具体的なオンデマンドリアルタイム患者固有データ解析発注の受信時に開始されるアルゴリズムとの間のインタフェースとしての役割を果たすことができる。

図８は、本開示の例による例示のフローチャート設計プロセスを示す。図８に示す設計プロセスは、データ解析計算プラットフォームのプログラマが、具体的なオンデマンドリアルタイム患者固有データ解析が上述したように発注されたときに実行可能な予めプログラミングされたアルゴリズムまたはデータ解析スキームを作成する方法を示す。

ユーザ８０２は、フローチャートデザイナユーザインタフェース８０４を介してフローチャートデザイナツールセットにアクセスすることができる。フローチャートデザイナツールセットは、上述した例のように、各種オンデマンドリアルタイム患者固有データ解析に適した広範な医療データ解析アルゴリズムセットの設計、開発、配備のために、１セットの利用しやすいツールを提供することができる。ユーザインタフェース８０４は、ツールセットのユーザが、高度なプログラミングの経験や訓練なしに優れた解析機能を達成できるように構成することができる。言い換えると、ユーザインタフェース８０４は、利用しやすい構文でユーザが解析機能を提供し、この構文をその後、処理のために計算プラットフォームによって使用されるアルゴリズムの難解な記述に変換できるようなプラットフォームを提供することができる。

ユーザインタフェース８０４は、フローチャート構成リポジトリ８０６へのアクセス機能をユーザに提供することができる。フローチャート構成リポジトリ８０６はいくつかの予めプログラミングされたアルゴリズムモジュールを含むことができる。ユーザ８０２は、包含および排除基準をさらに規定するだけでなく、オンデマンドリアルタイム患者固有データ解析計算プラットフォームのユーザによって規定可能な排除および包含基準を規定することによって、リポジトリ８０６に記憶されたプログラミング済みのアルゴリズムモジュールをカスタマイズすることができる。

いったんユーザ／プログラマ８０２がアルゴリズムまたはデータ解析スキームを作成すれば、プロセスは構成管理システム８０８に進み、そこで、公開されたアルゴリズムがアルゴリズムの各種構成を記憶し、オンデマンドリアルタイム患者固有データ解析計算プラットフォーム内での使用および配備を管理することができる。

図４に戻ると、いったん臨床解析エンジンがオンデマンドリアルタイム患者固有データ解析を実行すれば、オンデマンドリアルタイム患者固有データ解析の結果をオンデマンドリアルタイム患者固有データ解析発注処理モジュール４１６に送信することができる。オンデマンドリアルタイム患者固有データ解析発注処理モジュール４１６は、受信した結果を受け取り、オンデマンドリアルタイム患者固有データ解析計算プラットフォーム４０４のユーザが最終的に利用可能なレポートを生成することができる。１例では、オンデマンドリアルタイム患者固有データ解析発注処理モジュール４１６は、具体的な種類のオンデマンドリアルタイム患者固有データ解析に対して予め定義することのできる確定テンプレートに応じて受信した結果をフォーマット可能なレポート生成モジュール４２６にアクセスすることができる。

図９は、本開示の例による例示のレポートジェネレータアーキテクチャを示す。図４を参照して上述したように、処理されたオンデマンドリアルタイム患者固有データ解析の結果がいったん発注処理モジュール９０２によって受信されれば、発注処理モジュールは結果をレポートジェネレータモジュール９００に送信することができる。レポートジェネレータモジュール９００は発注結果を受信し、モジュール９０４で、発注結果をｐｄｆ設計テンプレートまたはその他の出力フォーマットに適用することができる。モジュール９０４で、結果を解析して、どのような種類のオンデマンドリアルタイム患者固有データ解析が結果に関連するかを判定することができる。判定された種類に基づき、レポートジェネレータ９００はテンプレートリポジトリ９０６にアクセスして、様々なフォーマットで最終レポートを生成することができる。

テンプレートリポジトリ９０６は、１例では、複数のレポートテンプレートを記憶することができ、リポジトリ内の各レポートテンプレートは、オンデマンドリアルタイム患者固有データ解析計算プラットフォームによって実行することができる１以上のオンデマンドリアルタイム患者固有データ解析に関連する。計算プラットフォームによって実行され、結果内で反映されるオンデマンドリアルタイム患者固有データ解析の種類が判定されると、発注処理モジュール９０４はテンプレートリポジトリにアクセスし、適切なレポートテンプレートを抽出し、受信した結果を用いてレポートを生成することができる。

いったんレポートジェネレータ９００がレポートを生成すれば、それを発注処理モジュール９０２に返信して、最終的にオンデマンドリアルタイム患者固有データ解析計算プラットフォームのユーザに送信することができる。１例では、レポートジェネレータコンポーネント９００は生成されたレポートを演算インテリジェンスモジュール９０８にも送信することができる。演算インテリジェンスモジュールは生成された各種レポートをすべて記憶し、図５を参照して説明したモジュール５２０で説明したように、データの様々な傾向を認識するようにレポートに基づく解析を実行することができる。

図４に戻ると、いくつかの例では、計算プラットフォーム４０４はデータ統合サービスモジュール４２８も含むことができる。データ統合サービスモジュール４２８は、所属する医療提供者などの外部団体から受け取るデータを処理、変更、検証することによってデータレイク４２２内のデータをポピュレートする役割を果たすことができる。

図１０は、本開示の例による例示のデータ統合サービスを示す。データ統合サービス１０００の第１の役割は、外部団体からのデータを計算プラットフォームに取り込むことである。いったんデータが取り込まれたら、データ統合サービス１０００は、上述したようなリアルタイム患者固有データ解析を実行する計算プラットフォームによってデータが使用されるように、データを検証、変更、整理することができる。

１例として、決して限定するように解釈すべきではないが、所属団体１００２とラボサービス１００４は、計算プラットフォーム、より具体的にはデータ統合サービス１０００にデータを供給することのできる外部団体の例としての役割を果たす。ラボサービス１００４と所属団体１００２は両方とも、患者の過去の治療に関する情報や患者に関係するその他の健康関連情報を含むが、それらに限定されない患者の医療関連データを含むことができる。

１例では、図１０に示すように、データ統合サービス１０００は、３つの異なる入力経路を介して ラボサービス１００４と所属団体１００２からのデータを取り入れることができる。データをデータ統合サービス１０００に取り入れる第１の経路では、ユーザがユーザインタフェース（ＵＩ）１００６を用いてデータをウェブサービスに手動でアップロードすることができる。ユーザは、ＵＩ１００６を介して計算プラットフォームに送信したいと考えるファイルを選択することによって、ファイルをデータ統合サービス１０００に手動でアップロードすることができる。

上述の例の代わりに、または上述の例に加えて、データ統合サービス１０００は、メッセージハブ１００８を利用するリアルタイムウェブベースのメッセージサービスを用いてメッセージを受信し、外部団体からデータを受信することができる。メッセージハブ１００８は、所属団体１００２などのデータプロバイダとデータ統合サービス１０００との間のリアルタイム接続を提供することができる。よって、所属団体１００２がリアルタイム患者固有データ解析計算プラットフォームに送信したいと思う新たなデータを有するとき、このデータと計算プラットフォームに送られる他のデータとをまとめるのを待って１バッチとしてアップロードする代わりに、データプロバイダは各データ項目をリアルタイムで個別に送信することができる。

別の例では、データプロバイダおよびラボサービス１００４はファイル転送プロトコル（ＦＴＰ）接続を利用して、データをデータ統合サービス１０００にアップロードすることができる。着陸ゾーン１０１０は、ＦＴＰ接続を通じてデータを受信するファイル記憶媒体としての役割を果たすことができる。ファイルウォッチャ１０１２は着陸ゾーン１０１０を監視して、着陸ゾーンからデータ管理ワークフロー１０１４にデータをアップロードし、受信時にデータを取り込む（後述）のに必要なワークフローを開始することができる。

データ管理ワークフローモジュール１０１４は、データプロバイダ１００２やラボサービス１００４などの外部団体から受信したデータの吸収に関連する各種組織的タスクを実行することができる。１例として、データ管理ワークフローは、管理される内在化データと関連する患者ＩＤの管理、情報の効率的呼出しを簡易化することができる標準化フォーマットにデータを整理するデータの整理および標準化、データ品質チェックを含むことができる。

データ管理ワークフロー１０１４は、外部機関から受信したデータを、データ統合サービス１０００内に含まれる各種データ記憶媒体に最終的に整理することができる。生データ、すなわち、受信されたときの形状のデータは生データ記憶装置１０１６に記憶することができる。上述したように、受信したデータは標準化することができ、いったん標準化されれば、データは標準化データ記憶ファイルシステム１０１８に記憶することができる。標準化とは、内在化データが計算プラットフォームの認識する形状で表されるように確保することを指す。標準化プロセスの１例として、計算プラットフォームが性別を男性、女性、その他として表すことを要求するが、外部団体が性別をＭ、Ｆ、Ｏと表す場合、標準化プロセスはＭ、Ｆ、Ｏを男性、女性、その他に翻訳することを含む。

データ管理ワークフローモジュール１０１４は、データを「マスタ化」するようにデータ上で１以上のアルゴリズムを実行するマスタデータ管理モジュール１０２０を開始することもできる。データのマスタ化とは、様々な形で特定の個人に属するデータをその個人の属性とすることができるプロセスを指す。１例として、データのマスタ化は、Ｅｄｗａｒｄ ＳｍｉｔｈとＥｄ Ｓｍｉｔｈに帰するデータが同じ個人に属すると認識することを含むことができる。マスタ化プロセスが存在しない場合、システムがＥｄｗａｒｄ ＳｍｉｔｈとＥｄ Ｓｍｉｔｈを２人の別々の個人とみなすことによって、リアルタイム患者固有データ解析中のデータの誤識別につながる可能性がある。

マスタ化プロセスの一環として、マスタデータ管理プロセス１０２０は、一連のマスタ化ＩＤと、個人をこの特定の個人のＩＤに照らして識別するための複数の方法をマッピングするマップとをデータ記憶装置１０２２に記憶することができる。リアルタイム患者固有データ解析中、マスタ化ＩＤおよびマップ記憶装置１０２２にアクセスして、特定の個人に関するリアルタイム患者固有データ解析を実行する際、データがアクセスするロードマップをアルゴリズムに提供することができる。

いったんデータがマスタ化されれば、データは、データを元にデータ解析を実行する計算プラットフォームの能力を最適化する形で各種ファイル記憶装置に保管することができる。１例として、患者プロフィールデータ記憶装置１０２４は、システムの一部として各患者のプロフィールを記憶することができる。計算プラットフォームは患者プロフィールデータ記憶装置１０２４を利用して、特定の患者がシステム内に存在するか否かを確認し、いくつかの例では、リアルタイム患者固有データ解析を実行するのに十分な特定患者に関するデータが存在するか否かも確認することができる。

データベース１０２６は、患者の全データを記憶する主データベースを表すことができる。データベース１０２６をポピュレートするデータは、計算プラットフォームによって実行される各種データ解析を最適化するフォーマットに一致させることができる。セキュリティ目的で、データベース１０２６内のデータは（上述したように）非識別化することができ、計算プラットフォームのユーザが様々なセキュリティおよび認証手順に合格したときだけ再識別される。

また、別の例では、データ統合サービスはラボサービス結果データ記憶装置１０２８も維持することができる。ラボサービス結果データ記憶装置は、各種ラボサービスプロバイダから受信したデータを含むことができ、このデータはフォーマット化されて、計算プラットフォームが動作してリアルタイム患者固有データ解析を実行するフォーマットに合致される。

本開示と実施例を添付図面を参照して説明したが、様々な変更および変形は当業者にとって自明であることに留意すべきである。このような変更および変形は、請求項によって定義されるような本開示および実施例の範囲に含まれると理解すべきである。

Claims (20)

1. コンピュータにより実行される方法であって、
   データ解析システムのメッセージハブによって、特定のユーザのリアルタイムユーザ固有データの解析の要求を受信することであって、データ解析システムは、（i）メッセージハブ、（ii）発注処理コンポーネント、（iii）異なるユーザのユーザプロフィール、（iv）データレイク、（iv）解析エンジン、（v）結果生成部を含むことと、
   データ解析システムの発注処理コンポーネントによって、特定のユーザに関連する特定のユーザプロフィールが、データレイクに記憶されたリアルタイムユーザ固有データが要求された解析を実行するのに十分であることを示すと判定することと、
   特定のユーザに関連する特定のユーザプロフィールが、データレイクに記憶されたリアルタイムユーザ固有データが要求された解析を実行するのに十分であることを示すと判定したことを受けて、データ解析システムの発注処理コンポーネントによって、リアルタイムを用いたデータレイクに記憶されたリアルタイムユーザ固有データ、バッチ処理以外でかつリアルタイムでそれぞれデータ条項を得るトランザクショナルデータ検索技術を取得することと、
   データベース内に記憶された非識別データを、リアルタイムユーザ固有データの解析を要求した特定のユーザに属するデータとして再識別すると共に再識別されたデータを特定のユーザのＩＤに基づいて照合することと、
   データ解析システムの解析エンジンによって、得られた特定のユーザのリアルタイムユーザ固有データに基づき要求された解析を実施することと、
   データ解析システムの結果生成部によって、得られた特定のユーザのリアルタイムユーザ固有データに基づき要求された解析を実施した結果を生成することと、
   データ解析システムのメッセージハブによって、出力として、要求された解析を実施した結果を提供することと
   を備える方法。
2. データレイクに記憶されたユーザ固有データの取得は、特定のユーザに関連するデータ条項を回収するように複数の個々のデータベースを検索することを含む、請求項１に記載の方法。
3. 要求された解析は、ユーザが提供者により受けた治療の質にアクセスする治療の質解析を含む、請求項１に記載の方法。
4. 要求された解析は、可能性のある現在又は未来の存在、又は予想され押し付けられる推測、条件にアクセスする解析を含む、請求項１に記載の方法。
5. 要求された解析は、潜在的に不要な検査の利用にアクセスする無駄評価回避システムを含む、請求項１に記載の方法。
6. 要求された解析は、種々のプログラムのユーザ適格性にアクセする適格性解析を含む、請求項１に記載の方法。
7. 要求された解析は、治療モデル又は支払いモデルに対する治療又はコスト負担のカテゴリにアクセスするリスク解析を含む、請求項１に記載の方法。
8. 要求は、サービス供給者に関連する過去発注エントリユーザインタフェースによる入力である、請求項１に記載の方法。
9. 要求は、解析に含まれるべきデータレイクに記憶された固有のデータセットを特定する包含基準を含む、請求項１に記載の方法。
10. 要求は、解析から排除されるべきデータレイクに記憶された固有のデータセットを特定する排除基準を含む、請求項１に記載の方法。
11. データレイクに記憶されたユーザ固有データの取得は、要求を受けた場合、データ解析システムの最初のデータベースである１以上のデータ条項の取得を含む、請求項１に記載の方法。
12. データレイクに記憶されたユーザ固有データの取得は、要求を受けた場合、外部データソースに記憶された１以上のデータ条項の取得を含む、請求項１に記載の方法。
13. データ解析システムは、ウェブサービスに示されている、請求項１に記載の方法。
14. 要求を受けた後、メッセージハブから発注処理コンポーネントへのセキュアソケットレイヤ（ＳＳＬ）認証を送信する、請求項１に記載の方法。
15. 特定のユーザに関連する特定のユーザプロフィールが、データレイクに記憶されたリアルタイムユーザ固有データが要求された解析を実行するのに十分である旨を示すと判定する前に、所属団体マップを用いて、要求された解析を認証する所属団体にユーザが関連していることを判定する、請求項１に記載の方法。
16. 特定のユーザに関連する特定のユーザプロフィールが、データレイクに記憶されたリアルタイムユーザ固有データが要求された解析を実行するのに十分である旨を示すと判定することは、十分にデータが存在することを示すブールフラグを含むデータを受信することを含む、請求項１に記載の方法。
17. 非識別データを再識別することは、解析されるように再識別されたデータを１つの位置にまとめることを備え、
    前記再識別化されたデータは、解析後に再識別されたデータが識別されないように、削除される、請求項１に記載の方法。
18. データ解析システムであって、
    １以上のコンピュータによる実行される場合、１以上のコンピュータに以下を実行させるように動作可能な１以上のコンピュータ及び１以上の記憶装置を含み、
    データ解析システムのメッセージハブによって、特定のユーザのリアルタイムユーザ固有データの解析の要求を受信することと、
    データ解析システムの発注処理コンポーネントによって、特定のユーザに関連する特定のユーザプロフィールが、データレイクに記憶されたリアルタイムユーザ固有データが要求された解析を実行するのに十分であることを示すと判定することと、
    特定のユーザに関連する特定のユーザプロフィールが、データレイクに記憶されたリアルタイムユーザ固有データが要求された解析を実行するのに十分であることを示すと判定したことを受けて、データ解析システムの発注処理コンポーネントによって、リアルタイムを用いたデータレイクに記憶されたリアルタイムユーザ固有データ、バッチ処理以外でかつリアルタイムでそれぞれデータ条項を得るトランザクショナルデータ検索技術を取得することと、
    データベース内に記憶された非識別データを、リアルタイムユーザ固有データの解析を要求した特定のユーザに属するデータとして再識別すると共に再識別されたデータを特定のユーザのＩＤに基づいて照合することと、
    データ解析システムの解析エンジンによって、得られた特定のユーザのリアルタイムユーザ固有データに基づき要求された解析を実施することと、
    データ解析システムの結果生成部によって、得られた特定のユーザのリアルタイムユーザ固有データに基づき要求された解析を実施した結果を生成することと、
    データ解析システムのメッセージハブによって、出力として、要求された解析を実施した結果を提供することと
    を備える方法。
19. データレイクに記憶されたユーザ固有データの取得は、特定のユーザに関連するデータ条項を回収するように複数の個々のデータベースを検索することを含む、請求項１８に記載のシステム。
20. １以上のコンピュータにより実行される指示を含み、１以上のコンピュータに以下を実行させる非一時的コンピュータ可読記憶媒体であって、
    データ解析システムのメッセージハブによって、特定のユーザのリアルタイムユーザ固有データの解析の要求を受信することであって、データ解析システムは、（i）メッセージハブ、（ii）発注処理コンポーネント、（iii）異なるユーザのユーザプロフィール、（iv）データレイク、（iv）解析エンジン、（v）結果生成部を含むことと、
    データ解析システムの発注処理コンポーネントによって、特定のユーザに関連する特定のユーザプロフィールが、データレイクに記憶されたリアルタイムユーザ固有データが要求された解析を実行するのに十分であることを示すと判定することと、
    特定のユーザに関連する特定のユーザプロフィールが、データレイクに記憶されたリアルタイムユーザ固有データが要求された解析を実行するのに十分であることを示すと判定したことを受けて、データ解析システムの発注処理コンポーネントによって、リアルタイムを用いたデータレイクに記憶されたリアルタイムユーザ固有データ、バッチ処理以外でかつリアルタイムでそれぞれデータ条項を得るトランザクショナルデータ検索技術を取得することと、
    データベース内に記憶された非識別データを、リアルタイムユーザ固有データの解析を要求した特定のユーザに属するデータとして再識別すると共に再識別されたデータを特定のユーザのＩＤに基づいて照合することと、
    データ解析システムの解析エンジンによって、得られた特定のユーザのリアルタイムユーザ固有データに基づき要求された解析を実施することと、
    データ解析システムの結果生成部によって、得られた特定のユーザのリアルタイムユーザ固有データに基づき要求された解析を実施した結果を生成することと、
    データ解析システムのメッセージハブによって、出力として、要求された解析を実施した結果を提供することと
    を備える、方法。