JP2022520987A - 分散型コンピューティングプラットフォームを使用して、優先順位別に地理的領域を横断して健康データを分析するためのシステムアーキテクチャおよび方法 - Google Patents

Abstract

システムおよび方法が、分散型クラウドコンピューティングプラットフォームを経由して健康データを分析するために開示される。分散型クラウドコンピューティングプラットフォームを経由して健康データを分析するための１つの方法は、分析のために、１つ以上の匿名ＤＩＣＯＭオブジェクトを含有する一意の症例ファイルを受信するステップと、１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる優先順位に基づいて、一意の症例ファイルに関して優先レベルを設定するステップと、１つ以上の匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つを解凍し、正当性を立証するステップと、解凍され、正当性を立証された匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つの分析であって、一意の症例ファイルの優先レベルに従って完了した分析を伝送するステップとを含む。

Description

（関連出願）
本願は、その開示全体が参照することによってその全体として本明細書に組み込まれる、２０１９年２月２２日に出願された、米国仮出願第６２／８０９，１３９号の優先権を主張する。

（導入）
病院は、患者に関する有意量の健康データ記録を発生させ、記憶する。従来的に、健康データ（例えば、医療記録、Ｘ線、ＣＴスキャン、ＭＲＩ等）の分析は、病院において医療専門家によって実施される。しかしながら、病院は、最先端技術を伴う予測健康データ分析を実施するように装備されていない場合がある。これらの状況では、健康データは、第三者ベンダまたはサービスによって分析される必要があり得る。

ますます、健康データ分析の種々の側面が、病院外で実施されている。健康データが、病院外の１つ以上の第三者処理システムを使用して分析されるとき、病院の外に健康データを転送し、分析するために考慮するべき種々の要因、例えば、ファイルサイズ、タイプ、ルーティング、ファイル妥当性（例えば、画質）、転送するファイルの選択を促進するために使用されるべきアプリケーションユーザインターフェース（ＡＰＩ）、およびプライバシーが存在し得る。

加えて、第三者処理システムは、異なる領域（または国）からの多くの異なる病院からのデータを効率的に分析および編成するために、ロバストなプラットフォームアーキテクチャを要求し得る。例えば、健康データ分析、記憶、および管理能力の特定のセットが、病院領域と異なる、ある領域内のみに存在し得る。その選択された領域外の病院は、患者プライバシー規制が、患者健康データが選択された領域に転送されることができないことを決定付け得るため、分析サービスへのアクセスを有していない場合がある。

したがって、終端間自動取り込み、国境を越えた健康データの分析および処理、および分析の報告のためのセキュア、拡張可能、ロバスト、かつ融通性のあるインフラストラクチャを作成する、分散型健康データプラットフォームの所望が、存在する。さらに、データ分析および病院への報告を向上させるために、分散型健康データプラットフォームが誘導分析者ワークフローを提供するための所望が、存在する。前述の一般的説明および以下の詳細な説明は、例示的かつ解説的にすぎず、本開示の制限ではない。本開示の種々の実施形態は、一実施形態による、異なる地理的地域内で発生される健康データを効率的に分析、管理、および記憶しながら、患者プライバシーを守るシステムおよび方法に関する。

本開示のある側面によると、システムおよび方法が、分散型クラウドコンピューティングプラットフォームを経由して国境を越えた健康データを管理するために開示される。

分散型クラウドコンピューティングプラットフォームを経由して健康データを分析する方法であって、本方法は、分析のために、１つ以上の匿名ＤＩＣＯＭオブジェクトを含有する一意の症例ファイルを受信するステップと、１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる優先順位に基づいて、一意の症例ファイルに関して優先レベルを設定するステップと、１つ以上の匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つを解凍し、正当性を立証するステップと、解凍され、正当性を立証された匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つの分析であって、一意の症例ファイルの優先レベルに従って完了した分析を伝送するステップとを含む。

別の実施形態によると、分散型クラウドコンピューティングプラットフォームを経由して健康データを分析するためのシステムは、分散型クラウドコンピューティングプラットフォームを経由して健康データを分析するための命令を記憶する、データ記憶デバイスと、分析のために、１つ以上の匿名ＤＩＣＯＭオブジェクトを含有する一意の症例ファイルを受信し、１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる優先順位に基づいて、一意の症例ファイルに関して優先レベルを設定し、１つ以上の匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つを解凍し、正当性を立証し、解凍され、正当性を立証された匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つの分析であって、一意の症例ファイルの優先レベルに従って完了した分析を伝送するように構成される、プロセッサとを備える。

別の実施形態によると、分散型クラウドコンピューティングプラットフォームを経由して健康データを分析する方法を実施するためのコンピュータ実行可能プログラミング命令を含有する、コンピュータシステム上で使用するための非一過性のコンピュータ可読媒体であって、本方法は、分析のために、１つ以上の匿名ＤＩＣＯＭオブジェクトを含有する一意の症例ファイルを受信するステップと、１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる優先順位に基づいて、一意の症例ファイルに関して優先レベルを設定するステップと、１つ以上の匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つを解凍し、正当性を立証するステップと、解凍され、正当性を立証された匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つの分析であって、一意の症例ファイルの優先レベルに従って完了した分析を伝送するステップとを含む。

開示される実施形態の付加的目的および利点は、以下に続く説明に部分的に記載され、説明から部分的に明白となるであろう、または開示される実施形態の実践によって習得され得る。開示される実施形態の目的および利点は、特に、添付の請求項で指摘される、要素および組み合わせを用いて、実現および達成されるであろう。

前述の一般的説明および以下の詳細な説明は両方とも、例示的かつ解説的にすぎず、請求されるような開示される実施形態の制限ではないことを理解されたい。

図１Ａは、本開示の例示的実施形態による、分散型健康データ管理システムの例示的ブロック図を描写する。

図１Ｂは、本開示の例示的実施形態による、図１Ａの健康データＩＯシステムの例示的概略図を描写する。

図１Ｃは、本開示の例示的実施形態による、図１Ａの健康データ分析システムの例示的概略図を描写する。

図２は、本開示の例示的実施形態による、図１Ｃの健康データ分析システムの詳細なブロック図を図示する。

図３は、本開示の例示的実施形態による、図１Ａの健康データＩＯシステム１０１においてネットワーク負荷の平衡を保つ例示的方法のブロック図である。

図４は、本開示の例示的実施形態による、健康データを受信、分析、および報告する方法のシーケンス図である。

図５は、本開示の例示的実施形態による、症例処理の順序を管理する例示的方法のフロー図である。

図６は、本開示の例示的実施形態による、分散型クラウドコンピューティングプラットフォームを使用して、国境を越えた健康データを分析する方法のフロー図である。

図７は、本開示の例示的実施形態による、健康データ分析システムからの結果ファイルを後処理および報告する例示的方法のフロー図である。

ここで、その実施例が付随する図面に図示される、本開示の例示的実施形態が詳細に参照されるであろう。可能な限り、同一の参照番号が、同一または同様の部分を指すために、図面の全体を通して使用されるであろう。

本明細書で使用されるように、用語「例示的」は、「理想的」ではなく、「実施例」の意味で使用される。さらに、用語「ａ」および「ａｎ」は、本明細書では、数量の限定を表さず、むしろ、参照される項目のうちの１つ以上のものの存在を表す。本開示の目的のために、「患者」は、診断または治療分析（例えば、データ分析）が実施されている任意の個人または人物、または１人以上の個人の診断または治療分析と関連付けられる任意の個人または人物を指し得る。

用語「健康データ」は、１回の実践で患者に関して収集される医療データ（例えば、医用デジタル画像および通信（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ；ＤＩＣＯＭ）オブジェクト）、および任意の医療提供者、研究所、専門家、臨床医等によって患者に関して収集される健康データを含んでもよい。健康データは、特定の患者と関連付けられ得、患者は、患者プライバシー情報を介して識別可能である。患者プライバシー情報は、健康データを特定の個人にリンクする任意の情報であってもよい。患者プライバシー情報は、客観的に（個人をその健康データに結び付ける情報として）、および／または法律および規制によって定義され得る。種々の領域は、患者プライバシー情報を構成する情報の種類の異なる定義を含んでもよい。

「領域」は、患者プライバシーを保護する規制によって定義される国境を伴う任意の環境を指し得る。一実施形態では、「領域」は、患者プライバシー／個人データを保護する規制のセットによって統制される、既知の地理的領域を指し得る。例えば、「領域」は、患者プライバシー法の単一のセットの下で運営される、州（例えば、カリフォルニア）、国（例えば、米国、日本、カナダ等）、または国の群（例えば、ヨーロッパ）を指し得る。米国に関して、患者プライバシー情報は、保護健康情報（ＰＨＩ）を含んでもよい。米国および種々の他の領域に関して、患者プライバシー情報は、個人健康情報、患者識別情報等（例えば、ＣＴ、ＭＲＩ、超音波等）を含んでもよい。健康データを伝送しながら患者健康情報を保護するための種々のシステムおよび方法が、例えば、２０１７年６月２７日に出願され、「Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｍｏｄｉｆｙｉｎｇ ａｎｄ Ｒｅａｃｔｉｎｇ Ｈｅａｌｔｈ Ｄａｔａ Ａｃｒｏｓｓ Ｇｅｏｇｒａｐｈｉｃ Ｒｅｇｉｏｎｓ」と題された、米国非仮出願第１５／６３５，１２７号（参照することによってその全体として本明細書に組み込まれる）に開示される。

代替として、または加えて、「領域」は、所与の物理的設備、所与のエンティティのコンピューティングシステム、または所与のクラウドプラットフォームを指し得る。そのような場合において、その間で健康データが編集される種々の領域がなお、単一の国、州、または地方内に存在し得る。例えば、領域は、データ分析のために健康データを別の領域（例えば、クラウドプラットフォーム）に転送することに先立って、収集された健康データから患者プライバシー情報を除去し得る、病院を含んでもよい。病院およびクラウドプラットフォームは、同一の地理的に定義された領域、例えば、米国内に存在し得る。

本開示は、分散型クラウドコンピューティングプラットフォームを経由して健康データを管理するためのシステムおよび方法を含む。一実施形態では、健康データは、１つ以上のクラウドベースのウェブサービスを使用して報告するために、前処理、分析、および後処理されてもよい。健康データ管理システムは、１つ以上の病院から健康データを受信し、自動健康データ取り込みを実施し、分析のための健康データを準備し、分析に備えて健康データを分析／変換し、分析のために転送するファイルを選択または識別し、分析のために健康データファイルの転送の時間を決め、健康データファイルが関連するかどうかを決定し、健康データ分析の進捗またはステータスを監視し、健康データの完了した分析を決定し、別様に病院またはＤＩＣＯＭモダリティと種々のクラウドベースのデータ分析ウェブサービスとの間の相互作用を促進してもよい。一実施形態では、健康データは、ＤＩＣＯＭオブジェクトの形態であってもよい。

一実施形態では、健康データ管理システムは、顧客地点（例えば、病院、診療所等）からクラウドコンピューティングウェブサービスに健康データ（例えば、ＤＩＣＯＭオブジェクト）を転送してもよい。例えば、本システムは、ＤＩＣＯＭプロトコルを使用して、ＣＴスキャナ、ＣＴワークステーション、または画像保管通信システム（ＰＡＣＳ）から直接、健康データを受信し、受信された健康データをクラウドサービスにセキュアに転送してもよい。クラウドコンピューティングサービスは、受信された健康データに基づいて、１つ以上の診断メトリックまたは患者推奨を導出し得る、データ分析サービスを含んでもよい。本システムはさらに、転送された健康データの完了した分析を読み出す、１つ以上のクラウドサービスからの分析結果を集約する、報告を発生させる、および／または報告を病院システムにプッシュしてもよい。

一実施形態では、健康データは、患者特有の画像データを含んでもよい。１つのシナリオでは、画像データは、患者の心臓の幾何学形状、例えば、患者の大動脈の少なくとも一部、大動脈に接続される主冠動脈（およびそこから延在する分岐）の近位部分、および心筋に関するデータを含んでもよい。一実施形態では、患者特有の画像データは、ＤＩＣＯＭファイルの形態であってもよい。患者特有の解剖学的データは、例えば、非侵襲性撮像方法を使用して、非侵襲的に取得されてもよい。例えば、ＣＣＴＡは、ユーザが、コンピュータ断層撮影（ＣＴ）スキャナを動作させ、構造、例えば、心筋、大動脈、主冠動脈、およびそこに接続された他の血管を視認し、その画像を作成し得る、撮像方法である。ＣＣＴＡデータは、例えば、心周期にわたって血管形状の変化を示すように、時間的に変動し得る。ＣＣＴＡは、患者の心臓の画像を生成するために使用されてもよい。

代替として、磁気共鳴映像法（ＭＲＩ）または超音波（ＵＳ）を含む、他の非侵襲性撮像方法、またはデジタル減算血管造影（ＤＳＡ）等の侵襲性撮像方法が、患者の生体構造の構造の画像を生成するために使用されてもよい。撮像方法は、造影剤を静脈内で患者に注入し、生体構造の構造の識別を可能にすることを伴い得る。画像（例えば、ＣＣＴＡ、ＭＲＩ等によって提供される）を伴う健康データは、放射線学研究所または心臓専門医等の第三者ベンダによって、患者の医師によって等、提供されてもよい。

他の患者特有の解剖学的データもまた、非侵襲性的に患者から決定されてもよい。例えば、患者の血圧、基準心拍数、身長、体重、ヘマトクリット、１回拍出量等の生理学的データが、測定されてもよい。血圧は、最大（収縮期）および最小（拡張期）圧力等の患者の上腕動脈（例えば、圧力カフを使用する）内の血圧であってもよい。例示的健康データは、したがって、画像診断法、ウェアラブル機器、血圧カフ、温度計、フィットネストラッカ、血糖測定器、心拍数モニタ等から収集されるデータを含んでもよい。

一実施形態では、分析のためにファイルを準備し、分析されたデータを読み出すことは、患者プライバシーを守ることを伴ってもよい。例えば、ファイル準備は、ファイルから患者プライバシー情報を除去するステップを含んでもよい。１つのそのような場合において、健康データファイルは、ファイルが発生されるときに、患者プライバシー情報を自動的に含んでもよい。例示的患者プライバシー情報は、保護健康情報（ＰＨＩ）またはＰＨＩと同等の患者プライバシーデータを含んでもよい。１つのシナリオでは、ファイル準備は、健康データが分析のために病院から健康データ分析システムに転送される前に、健康データファイルから患者プライバシー情報を取り除くステップを含んでもよい。一実施形態では、患者プライバシー情報が欠けた、分析された健康データを備える結果報告が、発生されてもよい。報告は、病院／病院インターフェースにプッシュされてもよく、報告は、対応する患者プライバシー情報に結合されてもよい。このように、データ分析が、患者プライバシー情報を遠隔領域に伝送することなく、遠隔領域内で実施されてもよい。

図１Ａは、本開示の例示的実施形態による、クラウドプラットフォームを経由して健康データを管理および分析するための分散型健康データ管理システム１００のブロック図である。健康データインフラストラクチャは、１つ以上の健康データ入出力（ＩＯ）システム１０１（１０１ａ－１０１ｎ）と、健康データ分析システム１０５とを備えてもよく、健康データ入出力システムはそれぞれ、健康データ分析システム１０５の顧客であってもよい。例えば、健康データ分析システム１０５は、健康データから分析されたデータ（例えば、診断メトリック、治療シミュレーション、治療最適化または推奨等）を発生させるステップを含む、サービスを提供してもよい。健康データ入出力システム１０１は、次いで、健康データを健康データ分析システム１０５に送信し、提供された健康データにサービスを実施させてもよい。

一実施形態では、１つ以上の健康データＩＯシステム１０１はそれぞれ、健康データ分析システム１０５の場所と異なる領域内に位置してもよい。１つ以上の健康データシステム１０１は、無線ネットワーク１０３を経由して、健康データを入力として健康データ分析システム１０５に伝達してもよい。代替として、健康データは、有線接続を経由して健康データ分析システム１０５に伝達されてもよい。健康データＩＯシステム１０１はまた、無線ネットワーク１０３を経由して健康データ分析システム１０５から出力される、分析された健康データの報告を受信してもよい。

一実施形態では、健康データＩＯシステム１０１はそれぞれ、患者プライバシー情報が１つの領域から別の領域に自由に転送され得ない、異なる事前決定された領域を表し得る。一実施形態では、領域の境界は、患者プライバシー情報が領域の境界内で自由に通過し得、患者プライバシー情報が領域の境界をいったん越えると自由に転送され得ないように、定義され得る。例えば、領域の境界は、患者プライバシー情報の転送を取り巻く政府規制に基づき得る。そのような場合において、領域は、各領域の政府が患者プライバシー情報の転送について異なるルールを決定付け得る、物理的な地理的領域（例えば、ヨーロッパ、日本、および米国）を指し得る。代替として、または加えて、健康データＩＯシステム１０１は、境界が、保健条例、保険証券、病院の方針、および／または地元／州／地方規制によって決定付けられる、領域を表し得る。例えば、健康データＩＯシステム１０１は、種々の設備（例えば、明確に異なる病院、病院ネットワーク、研究設備、患者群等）を表し得る。健康データＩＯシステム１０１と健康データ分析システム１０５との間の例示的区別は、健康データが健康データＩＯシステム１０１において発生され、分析のための健康データ分析システム１０５への健康データの転送に対する技術的および法的障壁が存在し得る、実施形態を含んでもよい。

一実施形態では、各健康データＩＯシステム１０１は、事前設定された優先レベルと関連付けられてもよい。優先レベルは、健康データが（例えば、図２に説明されるように）精査のために提出され、（例えば、健康データ分析システム１０５による）分析のために伝送される順序、および分析されたデータの報告が統合または（例えば、健康データ分析システム１０５から健康データＩＯシステム１０１に）配信され得る順序を決定付けてもよい。１つの例示的シナリオは、「高優先順位」優先レベルと関連付けられている健康データＩＯシステム１０１ａと、「低優先順位」優先レベルと関連付けられている健康データＩＯシステム１０１ｂとを含んでもよい。そのような場合において、健康データの第２のセットが健康データＩＯシステム１０１ｂによって発生されることと同時に、健康データの第１のセットが健康データＩＯシステム１０１ａによって発生される場合でさえも、データの第１のセットは、健康データ分析システム１０５に転送されてもよく、健康データ分析システム１０５は、健康データＩＯシステム１０１ｂからの健康データの第２のセットが健康データ分析システム１０５に転送される、またはそれによって分析される前に、健康データＩＯシステム１０１ａに戻るように、分析されたデータの報告を伝達してもよい。

代替として、または加えて、各健康データＩＯシステム１０１は、複数の優先レベルと関連付けられてもよい。例えば、健康データＩＯシステム１０１ａは、例えば、タスク項目（例えば、「アクション」）、優先順位ステータス（例えば、「低優先順位」、「高優先順位」、「緊急ステータス」）、または標準プロセス（例えば、「更新をチェックする」、「更新を監視する」等）によって編成される、複数の優先順位設定を含んでもよい。優先順位設定は、健康データＩＯシステム１０１ａと健康データ分析システム１０５との間のデータ伝送チャネルの構成に応じて、事前設定されてもよい。優先順位は、データ伝送のための優先順位ステータスだけではなく、データ処理が実施されることになる順序も指し得る。代替として、または加えて、優先順位設定は、健康データを発生させるデバイスと関連付けられる、健康データの発生に応じて臨床医／医療提供者によって決定付けられる、要求される分析によって決定付けられる等であってもよい。換言すると、ＤＩＣＯＭオブジェクトの症例ファイルの優先順位は、（１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる）１つ以上のＤＩＣＯＭオブジェクトを発生させるエンティティ、および／または症例ファイルの１つ以上の匿名ＤＩＣＯＭオブジェクトを分析するエンティティに基づいてもよい。

健康データは、（例えば、健康データＩＯシステム１０１によって生成される健康データの他のセットに対する）各健康データＩＯシステム１０１内の健康データセットの優先レベルに従った、かつ（例えば、他の健康データＩＯシステムに対する）健康データＩＯシステムの優先レベルに従った順序で、健康データ分析システム１０５によって分析されてもよい。一実施形態では、健康データのタイプはまた、優先順位ステータスに影響を及ぼし得る。例えば、健康データの特定のセットが、健康データの記憶または前もって作成されたセットと関連付けられることが見出される場合、健康データの特定のセットは、健康データの記憶または前もって作成されたセットの優先レベルにかかわらず、自動的に「優先される」または「高優先順位」と見なされ得る。換言すると、優先順位設定は、種々の要因から成り、それによる影響を受け得、健康データ管理システム１００には、優先順位のいくつかの層が存在し得る。

一実施形態では、ユーザは、優先順位設定を決定付け、健康データ管理システム１００を初期化することに応じて、または健康データＩＯシステム１０１と健康データ分析システム１０５との間の通信を初期化することに応じて、種々の要因が優先順位に影響を及ぼす、またはそれを変化させる方法を定義し得る。代替として、または加えて、健康データ分析システム１０５は、いくつかの優先順位設定が一貫している、または健康データ分析システム１０５の全ての健康データＩＯシステム１０１顧客を横断してデフォルトで使用されるように、少なくとも１つ以上の優先順位設定を事前定義してもよい。

優先順位に加えて、他の性質が、各健康データＩＯシステム１０１から健康データ分析システム１０５への健康データのアップロードの間に健康データと関連付けられてもよい。健康データと関連付けられる性質は、例えば、画像診断法、委託医師、実験的検査コード、研究所コード、請求コード、患者健康保険、保険制度等を含んでもよい。一実施形態では、健康データのアップロードの間に決定される性質は、データを分析する際に直接、または（例えば、データの報告を準備する際に、またはデータが受信または報告されるタイミングで）補助的方法のいずれかで、１つ以上の具体的アルゴリズムが健康データ分析システム１０５によって起動されるようにプロンプトしてもよい。

健康データＩＯシステム１０１および健康データ分析システム１０５は、任意のタイプまたは組み合わせのコンピューティングシステム、例えば、ハンドヘルドデバイス、パーソナルコンピュータ、サーバ、クラスタ化されたコンピューティングマシン、および／またはクラウドコンピューティングシステムを含み得ることを理解されたい。一実施形態では、健康データＩＯシステム１０１および健康データ分析システム１０５は、メモリ、中心処理ユニット（「ＣＰＵ」）、および／またはユーザインターフェースを含む、ハードウェアのアセンブリを備えてもよい。メモリは、フロッピー（登録商標）ディスク、ハードディスク、または磁気テープを含む、磁気記憶装置、ソリッドステートディスク（ＳＳＤ）またはフラッシュメモリ等の半導体記憶装置、光ディスク記憶装置、または磁気光学ディスク記憶装置等の物理的記憶媒体で具現化される、任意のタイプのＲＡＭまたはＲＯＭを含んでもよい。ＣＰＵは、メモリ内に記憶された命令に従ってデータを処理するための１つ以上のプロセッサを含んでもよい。

図１Ｂは、本開示の例示的実施形態による、図１Ａの例示的健康データＩＯシステム１０１の詳細な概略ブロック図である。健康データＩＯシステム１０１は、１つ以上の病院コンピューティングデバイス１０６と、データトランスポートシステム（「接続システム」）１０７と、モバイルユーザインターフェース１０９とを含む、病院インターフェースから成ってもよい。健康データＩＯシステム１０１の一実施形態はまた、ウェブサービス１１２と、報告データベース１１３と、患者健康情報データベース（例えば、ＰＨＩデータベース１１４）とを含んでもよい。顧客サポートユーザインターフェース１１１は、ウェブサービス１１２と通信してもよい。ウェブサービス１１２は、クラウドサービスから成ってもよい。健康データＩＯシステム１０１はさらに、メタデータデータベースを含んでもよい。健康データＩＯシステム１０１のこれらのコンポーネントは、１つ以上の病院と同一の領域または国内に位置してもよい。

病院コンピューティングデバイス１０６は、ウェブサイト、モデル、医療データ、健康記録、マルチメディアコンテンツ等を含む、データを収集、送信、および／または受信するように構成される、任意のタイプの電子デバイスを含んでもよい。例示的病院コンピューティングデバイスは、医療デバイス、例えば、医療撮像デバイス、医療モニタ等を含んでもよい。病院コンピューティングデバイス１０６はまた、１つ以上のモバイルデバイス、スマートフォン、携帯情報端末（「ＰＤＡ」）、タブレットコンピュータ、または任意の他の種類のタッチスクリーン対応デバイス、パーソナルコンピュータ、ラップトップ、および／またはサーバを含んでもよい。一実施形態では、病院コンピューティングデバイス１０６はそれぞれ、健康データＩＯシステム１０１と連携しているウェブサーバのうちの１つ以上のものから受信される、電子コンテンツを受信および表示するためにインストールされる、ウェブブラウザおよび／またはモバイルブラウザを有してもよい。病院コンピューティングデバイス１０６はまた、ウェブまたはモバイルブラウザ、および任意のタイプのアプリケーション、例えば、モバイルアプリケーションを実行するように構成される、オペレーティングシステムを有し得る、クライアントデバイスを含んでもよい。一実施形態では、種々の病院コンピューティングデバイス１０６は、データまたは分析された報告を通信するようにネットワークアダプタを伴って構成されてもよい。代替として、または加えて、種々の病院コンピューティングデバイス１０６は、ローカルネットワーク接続を経由して、データを伝送する、または分析されたデータを受信するように構成されてもよい。

例示的実施形態では、病院デバイスは、病院内にインストールされたコンピュータ断層撮影（ＣＴ）スキャンワークステーション、ＣＴスキャナ、または画像保管通信システム（ＰＡＣＳ）システムであってもよい。一実施形態では、病院コンピューティングデバイス１０６は、無線ネットワークを経由して健康データを接続システム１０７にアップロードしてもよい。接続システム１０７は、（例えば、病院コンピューティングデバイス１０６によって発生されるＤＩＣＯＭオブジェクトを遠隔健康データ分析システム１０５にプッシュすることによって）健康データＩＯシステム１０１／病院コンピューティングデバイス１０６と健康データ分析システム１０５との間の接続としての役割を果たしてもよい。

一実施形態では、健康データは、病院コンピューティングデバイス１０６から接続システム１０７にアップロードされてもよい。例えば、ＤＩＣＯＭ研究（ＣＴスキャンを含む）が、ＤＩＣＯＭモダリティ病院コンピューティングデバイス１０６から接続システム１０７にプッシュされてもよい。接続システム１０７は、ＤＩＣＯＭ研究に対応する新しい症例ファイルを作成してもよい。加えて、接続システム１０７は、健康データ分析システム１０５において新しい症例アカウントまたはファイルの作成をプロンプトしてもよい。代替実施形態では、接続システム１０７は、病院コンピューティングデバイス（ＣＴワークステーション、ＣＴスキャナ、およびＰＡＣＳ等）にクエリを行い、そのようなコンピューティングデバイスから健康データ（例えば、ＤＩＣＯＭオブジェクト）をプルしてもよい。一実施形態では、病院コンピューティングデバイスは、ＤＩＣＯＭオブジェクトを保存するウェブサーバと通信してもよい。接続システム１０７は、本ウェブサーバからＤＩＣＯＭオブジェクトをプッシュまたはプルしてもよい。

一実施形態では、接続システム１０７は、規則的時間間隔においてウェブサーバと通信し、サーバを介して利用可能な任意のＤＩＣＯＭオブジェクトをプルしてもよい。代替として、または加えて、ＤＩＣＯＭオブジェクトを発生させることと関連付けられるプロセッサは、接続システム１０７とローカル通信してもよく、接続システム１０７は、ＤＩＣＯＭオブジェクトが発生または記憶されるときにＤＩＣＯＭオブジェクトをプルするようにプロンプトされてもよい。

代替として、または加えて、プル機構がさらに、例えば、ＤＩＣＯＭオブジェクトの分析のために、任意のタスクに対する要求によって開始されてもよい。一実施形態では、ＤＩＣＯＭオブジェクトは、種々のデータ、例えば、分析の優先順位、行われるべき症例研究のタイプ、患者スキャン／画像、患者プライバシー情報等と関連付けられてもよい。本データは、ＤＩＣＯＭオブジェクトファイル内に含まれるメタデータまたはタグであってもよい。ＤＩＣＯＭオブジェクトのそのようなコンポーネントは、ファイルが分析のために送信される順序に影響を及ぼし得る。一事例では、ＤＩＣＯＭオブジェクトは、データ分析が要求されるまで記憶されてもよい。症例を健康データ分析システム１０５に転送するために使用されるプル機構が、各ＤＩＣＯＭオブジェクトと関連付けられる症例優先レベルまたは症例タイプによって統制されてもよい。例えば、健康データは、データタイプまたは優先順位設定によって決定付けられるレートまたは順序に基づいて、分析のためにデータをプルし得る、「タイプ」で標識されてもよい。例示的タイプは、以下、すなわち、緊急、優先、遡及的、至急、低優先順位、試験、研究、商業、標準、デモ、研修、監視、将来的、臨床研究を含んでもよい。タイプは、スタックされてもよく、例えば、「至急」症例はさらに、「緊急」または「優先」にソートされてもよく、「緊急」は、危機的な状態にある患者の健康状態に起因する、高優先順位を示し得、「優先」は、患者の直近の健康状態以外の理由により、迅速分析の必要性を示し得る。症例タイプの設定は、病院コンピューティングデバイス１０６、モバイルユーザインターフェース１０９において、および／または接続システム１０７によって設定されてもよい。プル機構は、重複するデータプル、または健康データＩＯシステム１０１、接続システム１０７、および健康データ分析システム１０５の過負荷を最小限にするように構成されてもよい。

代替として、または加えて、病院ユーザまたは臨床医が、モバイルユーザインターフェース１０９を使用して、健康データを接続システム１０７にアップロードしてもよい。モバイルユーザインターフェース１０９は、（例えば、病院ユーザへの）顧客に面したウェブインターフェースであってもよい。モバイルユーザインターフェース１０９は、ログインインターフェースを１人以上のユーザに提示し、パスワード管理を実施し、症例リストを表示し、検索し、症例の詳細を表示し、ユーザプロファイルを表示してもよい。モバイルユーザインターフェース１０９はまた、患者と関連付けられる分析されたデータを含有する、報告にアクセスするために使用されてもよい。モバイルユーザインターフェース１０９は、モバイルアプリケーションを備えてもよい。

一実施形態では、病院コンピューティングデバイス１０６によって発生されるデータは、患者プライバシー情報と関連付けられてもよく、ＤＩＣＯＭオブジェクトの患者プライバシー情報は、ウェブサービス１１２に利用可能であり得るが、健康データＩＯシステム１０１外のエンティティからは利用可能またはアクセス可能ではない。例えば、接続システム１０７は、ＤＩＣＯＭオブジェクトから患者プライバシー情報（例えば、ＰＨＩデータ）を抽出し、健康データＩＯシステム１０１内のウェブサービス１１２（例えば、ＰＨＩデータベース１１４）に利用可能であるように、患者プライバシー情報を記憶してもよい。例えば、接続システム１０７は、ＤＩＣＯＭ画像からの患者プライバシー情報を含有する、ＤＩＣＯＭタグを分割してもよい。患者プライバシー情報を含有するＤＩＣＯＭタグは、所定の文字列と置換されてもよい。代替実施形態として、ウェブサービス１１２は、接続システム１０７からＤＩＣＯＭオブジェクトを受信し、ＤＩＣＯＭオブジェクトから患者プライバシー情報を抽出してもよい。ウェブサービス１１２はさらに、データベース（例えば、ＰＨＩデータベース１１４）内に患者プライバシー情報を記憶してもよい。例示的実施形態では、領域特有の顧客サービスプロバイダが、顧客サポートユーザインターフェース１１１を使用して、患者プライバシー情報（ＰＨＩ）および患者結果報告へのアクセスを有してもよい。

一実施形態では、接続システム１０７は、健康データＩＯシステム１０１（例えば、病院と関連付けられる領域）内に展開されるアプリケーションプログラミングインターフェース（ＡＰＩ）を使用して、データ分析のための症例ファイルを作成してもよい。症例のＤＩＣＯＭファイルから取り除かれた患者プライバシー情報は、提出された患者プライバシー情報を患者プライバシー情報データベース（例えば、ＰＨＩデータベース１１４）に記憶し得る、ＡＰＩに提出されてもよい。いったん症例が処理される（例えば、ＤＩＣＯＭファイルのデータが健康データ分析システム１０５によって分析される）と、症例／分析完了が、健康データＩＯシステム１０１内に展開される報告プロセスをトリガしてもよく、報告が、分析されたデータおよび患者プライバシー情報データベース（例えば、ＰＨＩデータベース１１４）内に記憶された患者プライバシー情報を使用して発生され得ることを意味する。一実施形態では、患者プライバシー情報は、ＡＰＩを使用して読み出されてもよい。

患者プライバシー情報は、常に、症例（例えば、ＤＩＣＯＭオブジェクト）に関する健康データが発生された領域、または健康データがプッシュされた領域内に留まってもよい。患者プライバシー情報は、領域のそれぞれ（例えば、図１Ａの健康データＩＯシステム１０１）の中の記憶サービスバケットおよび／または患者プライバシー情報データベース内に記憶されてもよい。

一実施形態では、患者プライバシー情報の全てが、送信中および保管時に暗号化されてもよい。一実施形態では、患者プライバシー情報のための記憶サービスバケットは、新しいオブジェクトが記憶される度に暗号化が生じ得るように、サーバ側暗号化を可能にさせてもよい。患者プライバシー情報データベース（例えば、ＰＨＩデータベース１１４）はまた、記憶に応じて、かつ患者プライバシー情報がアクセスされる度に、患者プライバシー情報が暗号化され得る、暗号化サービスを提供してもよい。

一実施形態では、患者プライバシー情報は、それが記憶される領域外でアクセスされ得ない。例えば、日本で症例を提出したユーザは、別の領域（例えば、ヨーロッパ）にいる間に種々のウェブサービスにアクセスすることが可能であり得るが、ユーザは、他の領域にいる間に健康データ管理システム１００の患者プライバシー情報にアクセスすることが可能であり得ない。

例示的実施形態では、ウェブサービス１１２は、健康データ分析システム１０５から分析されたデータの報告を受信してもよい。例えば、ウェブサービス１１２は、完了した報告が報告データベース１１３内で利用可能であることを決定してもよい。一実施形態では、完了した報告は、一意の症例識別子と関連付けられてもよい。一実施形態では、ウェブサービス１１２は、一意の症例識別子を使用して、読み出された症例結果と関連付けられるＰＨＩデータベース１１４から患者プライバシー情報を読み出してもよい。ウェブサービス１１２はさらに、ＰＨＩデータを結果報告と統合する、および／または報告データベース１１３内に報告を記憶してもよい。ウェブサービス１１２はさらに、患者プライバシー情報とともに、または一意の症例識別子とともにのいずれかで、報告データベース１１３内に報告を記憶してもよい。一実施形態では、健康データＩＯシステム１０１はさらに、メタデータデータベースを含んでもよい。メタデータデータベースは、健康データの各報告またはセットと関連付けられるメタデータを含んでもよい。メタデータは、データの作成時に把握される健康データと関連付けられるデータ、例えば、データが作成または撮像された時間、保険計画、請求情報等を含んでもよい。メタデータはまた、（例えば、健康データ分析システム１０５による）健康データの分析のプロセスにおいて作成されるデータ、例えば、医師または精査者からの注記またはマーキング、健康データ前処理からのピン（例えば、解剖学的モデルが健康データから構築される場合）等を含んでもよい。

一実施形態では、ウェブサービス１１２は、報告が（例えば、臨床医、医療従事者、患者等による）使用のためにアクセスされる、または利用可能にされる、順序または優先順位を適用し得る、報告待ち行列モニタを含んでもよい。優先順位は、ユーザまたはウェブサービス（例えば、ウェブサービス１１２）によって設定されてもよい。一実施形態では、報告待ち行列は、（症例「タイプ」によって決定付けられるような）症例優先順位の順序で症例を管理してもよい。健康データＩＯシステム１０１はさらに、顧客サポートユーザインターフェース１１１を含んでもよい。顧客サポートユーザインターフェース１１１は、顧客サポートプロバイダ（例えば、顧客サポート人員）にアクセス可能であり得る。一実施形態では、患者プライバシー情報および／または患者報告は、顧客サポートプロバイダによるその使用のために構成される、仮想プライベートネットワーク（ＶＰＮ）を介してアクセスされてもよい。例えば、顧客サポート人員は、ＶＰＮサービスを活用することによって、個別に各領域にログインする能力を有してもよい。ＶＰＮサービスは、顧客サポートプロバイダが、健康データが発生された具体的領域から患者プライバシー情報にアクセスしていないときでさえも、具体的領域の患者プライバシー情報へのアクセスを顧客サポートプロバイダに拡張してもよい。

図１Ｃは、本開示の例示的実施形態による、健康データ分析システム１０５の概略ブロック図である。健康データ分析システム１０５は、症例プロセッサ１２１、１つ以上の分析ウェブサービス１２３、匿名一時記憶装置１２４ａ、匿名恒久記憶装置１２４ｂ、同期プロセッサ１２５、およびモデリングワークステーション１２７から成ってもよい。健康データ分析システム１０５はさらに、１つ以上の分析ウェブサービス１２３からのデータを精査する、および／またはそれにアクセスするために、ユーザインターフェースを分析者または顧客サポート人員に提供してもよい。一実施形態では、ユーザインターフェースは、生成ユーザインターフェース１２９および／または顧客サポートユーザインターフェース１３１を含んでもよい。

健康データ分析システム１０５は、少なくとも１つの国境を越えた領域からの（例えば、接続システム１０７を介した）匿名健康データを分析するための１つ以上のクラウドプラットフォームとしての役割を果たしてもよい。より具体的には、分析ウェブサービス１２３は、結果を算出し、報告（例えば、３Ｄモデル、ＰＤＦ等）を発生させ、分析および結果を患者、臨床医、またはユーザに提示してもよい。例えば、１つ以上の分析ウェブサービス１２３は、心臓ＣＴスキャンからの受信された画像データを使用して、冠動脈内の血流を算出してもよい。画像再構築および解剖学的モデルを使用する診断分析の種々の実施形態が、例えば、２０１２年１１月２０日に発行され、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｐａｔｉｅｎｔ－Ｓｐｅｃｉｆｉｃ Ｍｏｄｅｌｉｎｇ ｏｆ Ｂｌｏｏｄ Ｆｌｏｗ」と題された、米国特許第８，３１５，８１２号（参照することによってその全体として組み込まれる）に開示される。１つ以上の分析ウェブサービス１２３は、分析ウェブサービス１２３によって実施される分析の結果の報告を提供してもよい。上記に説明される分析に関して、報告は、算出された血流予備量比（ＦＦＲ）値を示す冠動脈の双方向３Ｄモデルおよび／またはＰＤＦ報告を含んでもよい。例示的報告は、表面モデル、グラフ、チャート、色分け、インジケータ、双方向ディスプレイ、アラート、信号、または任意の公知のグラフィックオブジェクトを含んでもよい。グラフィック表現および表示の種々の実施形態が、例えば、２０１４年４月２２日に発行され、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ ｆｒｏｍ ａ Ｐａｔｉｅｎｔ－Ｓｐｅｃｉｆｉｃ Ｍｏｄｅｌ ｏｆ Ｂｌｏｏｄ Ｆｌｏｗ」と題された、米国特許第８，７０６，４５７号（参照することによってその全体として組み込まれる）に開示される。

例示的実施形態では、症例プロセッサ１２１と関連付けられる１つ以上のプロセッサが、受信されたＤＩＣＯＭオブジェクトから１つ以上の中間結果を発生させてもよい。例示的実施形態では、同期プロセッサ１２５は、１つ以上のプロセッサからの中間結果を同期化してもよく、中間結果は、モデリングワークステーション１２７を介して精査のためにアクセスされてもよい。例示的実施形態では、同期プロセッサ１２５は、症例を処理する人々（例えば、技術者または分析者）によってアクセス可能なユーザインターフェースから立ち上げられるアプリケーションであってもよい。一実施形態では、同期プロセッサ１２５はさらに、具体的症例毎にモデリングワークステーション１２７を立ち上げてもよい。同期プロセッサ１２５は、１つ以上の分析ウェブサービス１２３とモデリングワークステーション１２７との間の適切な通信を確実にしてもよい。例示的実施形態では、分析者が、症例処理からの中間結果を閲覧する、症例プロセッサ１２１によって発生される結果を更新する、または症例プロセッサ１２１を介して症例を再分析する要求を提出してもよい。

例示的実施形態では、健康データ分析システム１０５は、生成ユーザインターフェース１２９と、顧客サポートユーザインターフェース１３１とを含む、複数のフロントエンドを含んでもよい。例示的実施形態では、生成ユーザインターフェース１２９は、症例分析者および分析ウェブサービス１２３の品質制御のための内部フロントエンドとしての役割を果たしてもよい。生成ユーザインターフェース１２９はまた、健康データ分析システム１０５のための内部処理アプリケーションへのポータルとしての役割を果たしてもよい。１つのシナリオでは、生成ユーザインターフェース１２９は、症例を処理し、優先順位を管理し、症例が顧客に配信される前にそれらを報告および精査する能力を分析者に提供してもよい。生成ユーザインターフェース１２９はまた、例えば、比較的に低い統計的信頼を有し得る分析結果を識別し、分析結果を精査する（またその精査を優先させる）ように分析者にプロンプトすることによって、分析者が分析結果の正当性を立証することを促進し得る。顧客サポートユーザインターフェース１３１は、地点作成、ユーザ管理、およびダッシュボード化のための内部フロントエンドとしての役割を果たしてもよい。顧客サポートユーザインターフェース１３１は、例えば、接続システム１０７（図１Ｂに示される）によって、地点および施設を監視および管理するために、サポートスタッフによって使用されてもよい。一実施形態では、サポートユーザインターフェース１３１はまた、例えば、製品試験、開発、または他のツール開発機能のために、データ隔離を管理してもよい。例えば、症例は、１つ以上のタグ、例えば、隔離、制限、または一般を有してもよい。これらのタグは、症例が作成されるときに発生されてもよい。タグは、未加工または分析されたデータが将来の開発／分析のために使用され得るかどうかを確認するために、各症例報告が完了した後に使用または更新されてもよい。顧客サポートユーザインターフェース１３１はまた、無料で、契約によって、支払のため、研究のため等に発生される症例の報告を起動するための内部使用または会計のために、所与のまたは選択された期間にわたって処理される症例の報告を発生させてもよい。

図２は、本開示の例示的実施形態による、図１Ｃの健康データ分析システム１０５の詳細なブロック図２００を図示する。例示的実施形態では、接続システム１０７は、症例ファイルが匿名であるように、症例ファイルのＤＩＣＯＭオブジェクトから患者プライバシー情報を抽出してもよい。接続システム１０７は、次いで、ＨＴＴＰまたはＨＴＴＰＳセキュアハイパーテキスト転送プロトコル（ＨＴＴＰＳ）を使用して、匿名症例ファイルを健康データ分析システム１０５に送信してもよい。一実施形態では、接続システム１０７は、匿名症例ファイルが、患者プライバシー情報を使用するのではなく、一意の症例識別子を使用して追跡され得るように、匿名症例ファイルのための一意の症例識別子を作成してもよい。

例示的実施形態では、症例プロセッサ１２１は、事前ロードプロセッサ２０２（モデリングワークステーション１２７）、解析前プロセッサ２０４、解析プロセッサ２０６、解析後プロセッサ２０７、および報告プロセッサ２０８を使用して、各症例のＤＩＣＯＭオブジェクトを処理してもよい。例示的実施形態では、症例は、症例の設定された優先順位に従って、事前ロードプロセッサ２０２、解析前プロセッサ２０４、解析プロセッサ２０６、解析後プロセッサ２０７、および報告プロセッサ２０８を通して処理されてもよい。例示的実施形態では、病院臨床医または管理者が、ウェブインターフェースを使用して、１つ以上のＤＩＣＯＭオブジェクトソースＣＴスキャナ、ＣＴワークステーション、またはＰＡＣＳに関して優先順位設定を入力してもよい。代替実施形態では、優先順位は、病院内の病院デバイスの場所に従って自動的に設定されてもよい。優先順位は、ステートレスプロトコルを使用して、症例プロセッサ１２１に送信されてもよい。各段階または処理では、症例は、優先順位に従って待ち行列に入れられてもよく、高優先順位の症例が、より低優先順位の症例に先立って処理されてもよい。代替として、または加えて、症例優先順位が、プロセスの任意の段階において編集されてもよい。

一実施形態では、事前ロードプロセッサ２０２が、受信されたＤＩＣＯＭファイルを準備する、またはそれに分析の準備ができていることを検証してもよい。例えば、事前ロードプロセッサ２０２は、接続システム１０７から受信されるＤＩＣＯＭファイルを解凍（または圧縮解除）してもよい。一実施形態では、接続システム１０７はまた、ＤＩＣＯＭファイルを解凍する能力を有してもよいが、事前ロードプロセッサ２０２は、接続システム１０７に対してＤＩＣＯＭファイルを解凍するためのよりセキュアな環境を提供してもよい。事前ロードプロセッサ２０２はまた、要求される分析が健康データ分析システム１０５によって実施されるために必要な最小閾値を満たすものとしてのＤＩＣＯＭファイルの品質の検証を実施してもよい。例えば、血流分析は、結果として生じた血流メトリックが臨床的に正確であるために、最小の事前決定された閾値を満たすＣＴ画質を伴い得る。プラーク検出分析は、結果が患者にとって有用であるために、画質のより低い事前決定された閾値を有してもよい。一実施形態では、接続システム１０７は、受信された健康データを自動的に否認してもよい。別の実施形態として、事前ロードプロセッサ２０２もまた、受信された健康データを自動的に否認する能力を有してもよい。例えば、事前ロードプロセッサ２０２は、健康データにＤＩＣＯＭ画像が欠落している、不正確な画像間隔、不正確なｚ位置付け等を有する場合、症例を否認してもよい。ＤＩＣＯＭオブジェクトが事前ロードプロセッサ２０２の品質査定を満たすことができない場合、接続システム１０７は、ＤＩＣＯＭファイルが分析のために否認される、または分析がアップロードされたＤＩＣＯＭオブジェクトを使用して実施されることができないという通知を受信してもよい。一実施形態では、健康データＩＯシステム１０１は、分析のために新しいまたは更新されたＤＩＣＯＭファイルを発生させる、またはアップロードするようにプロンプトされてもよい。例えば、モバイルユーザインターフェース１０９が、症例を「返送」として表示するようにプロンプトされてもよい。別の実施例として、「返送」症例は、健康データが分析のために否認される理由を含む、画質否認報告を含んでもよい。容認される新しい健康データが送信される場合、新しい症例エンティティが、作成されてもよく、任意の関連付けられるデータが、新しい症例／重複症例にコピーされてもよい。

一実施形態では、解凍されたＤＩＣＯＭファイルが、事前決定された閾値正確度または画質レベルを満たす、正確度または画質レベルを有する場合、解凍されたＤＩＣＯＭファイルは、解析前プロセッサ２０４に直接通過してもよい。ファイルが、事前決定された正確度または画質閾値レベルを満たさない場合、ファイルは、例えば、メッシュ（解剖学的モデル）を作成するためのワークステーションを使用して、手動処理のためにモデリングワークステーション１２７に転送されてもよい。いくつかの実施形態では、モデリングワークステーション１２７によって作成されるメッシュモデルは、次いで、事前ロードプロセッサ２０２に転送されてもよい。

一実施形態では、解析前プロセッサ２０４は、予備算出を実施し、画像ファイルを要求される分析に使用されるべき形態に変換してもよい。例えば、健康データ分析システム１０５の血流分析は、患者の血管系の３次元（「３Ｄ」）モデルに基づいてもよい。解析前プロセッサ２０４は、未加工ＤＩＣＯＭ画像ファイルを血流分析のための３Ｄ立体モデルに変換してもよい。一実施形態では、解析前プロセッサ２０４はさらに、４面体要素のメッシュを発生させる、および／または分析のために使用されるべき初期境界条件を確認してもよい。一実施形態では、解析前プロセッサ２０４は、モデリングワークステーション１２７と通信し、健康データ分析システム１０５の分析者による立証のためのモデルをレンダリングしてもよい。要求される分析が、血流シミュレーションを含む場合、解析前プロセッサ２０４は、患者の血管系の３Ｄモデルの種々の場所に沿って初期境界条件を決定してもよい。

一実施形態では、解析プロセッサ２０６は、解析前プロセッサ２０４によってレンダリングされる、準備されたモデルの分析を立ち上げてもよい。例えば、解析プロセッサ２０６は、解析前プロセッサ２０４によって生成される３Ｄモデルを通して血流シミュレーションを生成してもよい。一実施形態では、解析プロセッサ２０６は、分析ウェブサービス１２３とインターフェースをとり、分析を実施してもよい。一実施形態では、解析プロセッサ２０６は、解析プロセッサ２０６によって実施される分析を集約し、報告プロセッサ２０８のために集約された分析をパッケージ化し得る、解析後プロセッサを含んでもよい。例えば、解析後プロセッサは、解析プロセッサ２０６によって実施される現在の分析に関連する前の分析または記憶された分析を識別してもよい。分析は、実施される分析のタイプ（例えば、血流シミュレーションまたは灌流シミュレーション）、患者または患者人口統計学との関連付けによってリンクされる分析等を介して、関連し得る。（データは、匿名化され得る（例えば、患者プライバシー情報から解離される）が、データの種々のセットが、依然として、匿名化されたデータと関連付けられる一意のＩＤを追跡またはハッシュ化することによって、同一の個人と関連付けられるものとして識別され得る。）分析は、ユーザ特有の血流および可能性として考えられる治療転帰の画像およびモデルを含んでもよい。一実施形態では、報告プロセッサ２０８は、解析プロセッサ（および解析後プロセッサ）２０６によって実施される査定の最終報告を構成し得る、ビュー、表示、ピン、ＰＤＦ、および／または双方向インターフェースおよびモデルを発生させてもよい。報告プロセッサ２０８は、精査および改訂が解析プロセッサ２０６によって発生される分析に行われることを可能にしてもよい。

一実施形態では、症例プロセッサの各コンポーネントは、対応する待ち行列モニタ２０１（例えば、事前ロードプロセッサ２０２に対応する事前ロード待ち行列プロセッサ２０３、解析前プロセッサ２０４に対応する解析前待ち行列プロセッサ２０５、解析プロセッサ２０６に対応する解析待ち行列プロセッサ２０７ａおよび解析後待ち行列プロセッサ２０７ｂ、および報告プロセッサ２０８に対応する報告待ち行列プロセッサ２０９）を有してもよい。待ち行列モニタ２０１は、それらの対応するコンポーネントのそれぞれを通して、症例を前進させてもよい。例えば、事前ロード待ち行列プロセッサ２０３は、事前ロードプロセッサ２０２を通して各画像データセットの進捗を決定付けてもよい。一実施形態では、ＡＰＩが、分析の状態を通して前進するにつれて、各症例のステータスを捕捉するために使用されてもよい。

待ち行列モニタはそれぞれ、症例プロセッサのそれらの個別のコンポーネントから利用可能である症例のインジケーションに関して周期的にポーリングし、記憶装置から関連データをダウンロードしてもよい。例えば、事前ロード待ち行列プロセッサ２０３は、新しいＤＩＣＯＭデータセットがアップロードされたことを検出してもよい。事前ロード待ち行列プロセッサ２０３は、次いで、新しいデータセットをダウンロードし、データセットが画質要求を満たすことを検証するように事前ロードプロセッサ２０２にプロンプトしてもよい。事前ロード待ち行列プロセッサ２０３は、事前ロードプロセッサ２０２から、データセットが画質標準を満たすことを検出し、解析前プロセッサ２０４からアクションを開始し、データセットに基づいて幾何学的または立体モデルを発生させてもよい。同様に、解析待ち行列プロセッサ２０７ａは、幾何学的または立体モデルが利用可能であり、分析に適していることを検出し、したがって、幾何学的または立体メトリックモデルを通して血流をシミュレートする分析を開始するように解析プロセッサ２０６（および分析ウェブサービス１２３）にプロンプトしてもよい。一実施形態では、解析後待ち行列プロセッサ２０７ｂは、解析プロセッサ２０６による分析の完了を検出してもよい。解析後待ち行列プロセッサ２０７ｂは、次いで、結果の正当性を立証するように解析後プロセッサ２０７にプロンプトしてもよい。いくつかの実施形態では、本立証は、分析者が分析成果を確認するために結果をモデリングワークステーション１２７に提示するステップを含んでもよい。報告待ち行列プロセッサ２０９は、正当性を立証された結果から報告プロセッサ２０８の報告の作成を開始してもよい。

一実施形態では、待ち行列モニタ２０１はさらに、受信された症例の１つ以上の優先順位セットに従って、１つ以上の受信された症例（例えば、ＤＩＣＯＭオブジェクト）を処理してもよい。例えば、優先順位は、健康データＩＯシステム１０１によって設定されてもよい、および／または優先順位は、健康データに関して要求される分析と関連して設定されてもよい。待ち行列モニタは、各症例に割り当てられる優先順位に応じて、データ分析の各段階を管理してもよい。例えば、解析前プロセッサ段階にある低優先順位の症例が、解析前プロセッサ段階に留まってもよい一方、後続の高優先順位の症例は、低優先順位の症例に先立って、解析プロセッサ段階にルーティングされる。待ち行列モニタはさらに、症例が安定したペースにおいて処理されるように、分析ウェブサービス１２３の帯域幅を監視する。

図２の監視プロセッサ２１０は、症例処理および分析のステータスを監視することに関与し得る。監視プロセッサ２１０は、症例が、事前ロードプロセッサ２０２、解析前プロセッサ２０４、解析プロセッサ２０６、および報告プロセッサ２０８を通して処理されるにつれて、各レベルにおいて症例の状態（例えば、成功、失敗等）を監視してもよい。例示的実施形態では、監視プロセッサ２１０は、遠隔コマンドを使用する１人以上の認定ユーザによって、呼び出される、または無効化されてもよい。監視プロセッサ２１０は、遠隔コマンドを実行する目的だけのための限定された権利を用いて具体的に作成される、ユーザのコンテキストの下でコマンドを実行してもよい。監視プロセッサ２１０は、症例のステータス（例えば、ＤＩＣＯＭオブジェクト分析）についてフロントエンドユーザインターフェースと関連付けられる１つ以上のＡＰＩに通知してもよい。監視プロセッサ２１０は、処理の１つ以上の段階において一意の症例によって発生される、１つ以上のステータスメッセージ（例えば、成功、失敗等を使用して、１つ以上の自動処理事象を発生させてもよい。

図３は、本開示の例示的実施形態による、フロントエンド（臨床ユーザインターフェース（例えば、モバイルユーザインターフェース１０９または顧客サポートユーザインターフェース１１１、ウェブサービス１１２、分析ウェブサービス１２３、または任意のクラウド、ローカル、分析ウェブサービスを含む））、データベース、およびバックエンド（例えば、ウェブサービスまたは症例プロセッサ）の間の通信を橋渡しするための負荷分散の例示的ブロック図３００である。一実施形態では、健康データ管理システム１００は、そのＡＰＩ３０７（例えば、ＡＰＩ３０７ａ－３０７ｃ）を水平にスケーリングしてもよい。例えば、健康データ管理システム１００は、効率的にＡＰＩ３０７を横断してネットワーク負荷を分散し得る負荷分散装置３０５の背後に提供される、薄型の複数のプロキシマシン３０３を使用し得る、融通性のある負荷分散装置３０１を採用してもよい。代替として、または加えて、健康データ管理システム１００は、健康データ管理システム１００によって遭遇される負荷に対処するための先進マシンハードウェアを含んでもよい。

図４は、本開示の例示的実施形態による、健康データを受信、分析、および報告する例示的方法４００のシーケンス図を描写する。例示的実施形態では、ＤＩＣＯＭオブジェクトは、１つ以上の病院コンピューティングデバイス１０６から接続システム１０７にプッシュされてもよい。いったん接続システム１０７がＤＩＣＯＭオブジェクトを受信する（例えば、ステップ４０１）と、接続システム１０７は、ＤＩＣＯＭオブジェクトと関連付けられる新しい症例ファイルを作成してもよい。本症例ファイルは、ＤＩＣＯＭオブジェクトの分析の進捗の全体を通して監視されてもよい。症例ファイルはまた、最終報告が利用可能になるまで、分析を通して監視されてもよい。

一実施形態では、接続システム１０７は、ＤＩＣＯＭオブジェクトから患者プライバシー情報（例えば、ＰＨＩデータ）を抽出してもよい（例えば、ステップ４０３）。そうする際に、ＤＩＣＯＭオブジェクトは、匿名化されてもよい。一実施形態では、患者プライバシー情報は、ステートレス動作を許容し得るサービスを使用して、領域特有のクラウドプラットフォーム（例えば、ウェブサービス１１２）に送信されてもよい。例えば、患者プライバシー情報は、表現状態転送（ＲＥＳＴ）アプリケーションプログラミングインターフェース（ＡＰＩ）を介して、領域特有のクラウドプラットフォームに送信されてもよい。領域特有のクラウドプラットフォームは、ローカル関係データベース（例えば、情報の記憶された項目の間の関係を認識するように構造化されるデータベース）内に患者プライバシー情報を記憶してもよい。ＰＨＩデータベース１１４は、そのようなローカル関係データベースの一実施例である。ＤＩＣＯＭオブジェクトを匿名化するための種々のシステムおよび方法が、２０１７年６月２７日に出願され、「Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｍｏｄｉｆｙｉｎｇ ａｎｄ Ｒｅａｃｔｉｎｇ Ｈｅａｌｔｈ Ｄａｔａ Ａｃｒｏｓｓ Ｇｅｏｇｒａｐｈｉｃ Ｒｅｇｉｏｎｓ」と題された、米国非仮出願第１５／６３５，１２７号（参照することによってその全体として本明細書に組み込まれる）に開示される。

一実施形態では、ステップ４０５は、匿名化されたＤＩＣＯＭオブジェクトを事前ロードプロセッサ（例えば、事前ロードプロセッサ２０２）に伝送するステップを含んでもよい。一実施形態では、接続システム１０７および／または事前ロードプロセッサ２０２のいずれかは、ＤＩＣＯＭオブジェクトを解凍し、事前構成された立証基準に従って、正当性を立証してもよい。立証基準は、ＤＩＣＯＭオブジェクトに実施されるべき分析に依存し得る。

一実施形態では、事前ロードプロセッサ２０２はさらに、受信されたＤＩＣＯＭオブジェクトから体積画像ファイルを準備してもよい（例えば、ステップ４０７）。一実施形態では、事前ロードプロセッサ２０２はさらに、１つ以上の体積画像ファイルに関連し得る、圧縮アーカイブファイルを発生させてもよい。一実施形態では、圧縮アーカイブファイルは、体積画像ファイルに対応する情報を含有してもよい。情報は、体積画像ファイルの分析に関連し得る。例えば、圧縮アーカイブファイルは、ユーザログ、タスク状態、体積画像ファイルを使用して実施され得る処理のタイプ等を含んでもよい。ユーザログは、体積画像ファイルに実施された前の処理、ユーザによってモデルに実施されたアクション等を含む、ファイルの履歴を含んでもよい。タスク状態は、体積画像ファイルを発生させるための各タスクの状態、および各タスクで費やされる時間を含んでもよい。例示的タスクは、以下、すなわち、大動脈を識別すること、血管目印を識別すること、心筋組織を識別すること、正中線を識別すること、血管系を標識すること、管腔幾何学形状を精査すること、モデルを仕上げること等を含んでもよい。体積画像ファイルを使用して実施され得る処理のタイプは、健康データＩＯシステム１０１、健康データＩＯシステム１０１の特定のユーザ、または健康データ分析システム１０５によって決定付けられる、または受信されるデータのタイプによって決定付けられてもよい。例えば、ステップ４０７は、受信されたデータにおいて位置ずれを補正するステップ、または事前設定された動作を有するステップ、例えば、受信されたデータが１つだけのオブジェクト位相を含む場合、さらにファイルを処理するステップを含んでもよい。一実施形態では、正当性を立証されたＤＩＣＯＭオブジェクトまたは体積画像ファイルへの操作は、分析（例えば、健康データ分析システム１０５による、またはモデリングワークステーション１２７によるクリーニング）のために正当性を立証されたＤＩＣＯＭオブジェクトを準備する。一実施形態では、処理された画像が、画質の付加的チェックのために、モデリングワークステーション１２７に送信されてもよい。本付加的チェックは、画像立証の否認につながり得る。一実施形態では、接続システム１０７は、受信された画像の第１のレベルの立証を実施してもよく、事前ロードプロセッサ２０２は、画像関連立証（例えば、任意の解剖学的間隔または厚さが受信されたデータにおいて誤っているかどうかをチェックすること）を実施してもよい。一実施形態では、モデリングワークステーション１２７は、例えば、ヒューという音または画像アーチファクトに関して、さらに画像データを精査してもよい。一実施形態では、圧縮アーカイブファイルと体積画像ファイルとの間の対応または連携が、チェックサムを使用して維持されてもよい。チェックサムは、事前ロードプロセッサ２０２、接続システム１０７、ＡＰＩ、またはシステム１００の任意のコンポーネントによって算出されてもよい。一実施形態では、事前ロードプロセッサ２０２の体積画像ファイルは、例えば、モデリングワークステーション１２７を介して分析者に提示されてもよい。例えば、ステップ４０９は、モデリングワークステーション１２７のユーザインターフェースを使用して、１つ以上の体積画像ファイルを提示するステップを含んでもよい。一実施形態では、モデリングワークステーション１２７は、患者特有の解剖学的モデルを発生させるために使用されてもよい（例えば、ステップ４１１）。モデルは、患者の血管系の３次元（３Ｄ）幾何学形状（例えば、患者の冠動脈樹の３Ｄメッシュモデル）を含んでもよい。一実施形態では、患者特有の３Ｄモデルは、１つ以上の自動画像分析アルゴリズムを使用して、体積画像ファイルから発生されてもよい。

一実施形態では、モデリングワークステーション１２７は、（例えば、生成ユーザインターフェース１２９を介して）精査のために３Ｄモデルを分析者に提示してもよい。モデリングワークステーション１２７は、一連の立証画面内で３Ｄモデルを提示し、モデルの種々の部分を承認または否認するように分析者にプロンプトしてもよい。一実施形態では、モデリングワークステーション１２７は、分析者から入力を受信し、（例えば、ユーザログの一部として）圧縮アーカイブファイル内に分析者の応答を記憶してもよい。入力は、分析者からの症例注記を含んでもよい。例示的実施形態では、モデリングワークステーション１２７は、モデルが承認されない場合、ＤＩＣＯＭオブジェクトの再アップロードをプロンプトしてもよい。例えば、１つ以上の病院コンピューティングデバイス１０６は、付加的ＤＩＣＯＭオブジェクトを発生させるための（例えば、モバイルユーザインターフェース１０９を介した）プロンプトを受信してもよい。代替実施形態では、モデリングワークステーション１２７は、体積画像ファイルを再発生させるように要求を事前ロードプロセッサ２０２に伝達してもよい。例示的実施形態では、モデリングワークステーション１２７は、３Ｄモデルおよび症例注記を、例えば、拡張マークアップ言語（ＸＭＬ）ファイルに変換してもよい。モデリングワークステーション１２７からの出力は、（例えば、血流をシミュレートし、１つ以上の血流メトリックを生成するために）分析で使用されてもよい。

いったん３Ｄモデルが承認されると、解析前プロセッサ（例えば、解析前プロセッサ２０４）が、１つ以上の動作を実施し、健康データ分析システム１０５による分析のためにさらに準備してもよい。一実施形態では、解析前プロセッサは、承認された３Ｄモデルを受信し（例えば、ステップ４１３）、３Ｄモデルを通して血流シミュレーションのための境界条件を発生させてもよい（例えば、ステップ４１５）。一実施形態では、解析前プロセッサは、１つ以上の分析アルゴリズムを使用し、（ＸＭＬファイル内にあり得る）３Ｄモデルから４面体要素のメッシュを発生させてもよい。解析前プロセッサ２０４は、血流シミュレーション算出への入力として使用されるべき初期境界条件のセットを計算してもよい。解析前プロセッサ２０４は、次いで、初期境界条件を解析プロセッサに伝達してもよい（例えば、ステップ４１７）。

一実施形態では、解析プロセッサ（例えば、解析プロセッサ２０６）は、（例えば、分析ウェブサービス１２３を採用しながら）分析を実施してもよい。例えば、解析プロセッサ２０６は、４面体要素の３次元（３Ｄ）メッシュモデルおよび初期境界条件を使用して、血流シミュレーションを実施してもよい（例えば、ステップ４１９）。１つのシナリオでは、解析プロセッサ２０６は、血流シミュレーションに基づいて、１つ以上の血流メトリックを計算してもよい。血流メトリックは、血流予備量比（ＦＦＲ）、血圧、血液流速、灌流、プラーク脆弱性メトリック等を含んでもよい。

一実施形態では、解析プロセッサ２０６の分析結果が、解析後プロセッサ（例えば、解析後プロセッサ２０７）によって受信およびコンパイルされてもよい。例えば、解析プロセッサ２０６は、血流シミュレーション分析からの計算された血流メトリックを結果として解析後プロセッサに送信してもよい（例えば、ステップ４２１）。一実施形態では、解析後プロセッサ（例えば、解析後プロセッサ２０７）が、解析プロセッサ２０６によって発生される１つ以上のファイルを集約してもよい（例えば、ステップ４２３）。解析後プロセッサ２０７はさらに、最終結果に寄与しない場合があるシミュレーションにおける注記またはピンを含む、最終報告において所望されない項目を分析ファイルから除去してもよい。

代替として、または加えて、報告プロセッサ（例えば、報告プロセッサ２０８）が、結果データを集約し、完了した分析のための報告を準備してもよい（例えば、ステップ４２３）。例えば、報告プロセッサ２０８は、着目面積を指し示す自動ピンを伴う初期ビューおよびＰＤＦファイルを含む、完了した分析の報告を発生させてもよい。例えば、報告プロセッサ２０８は、（例えば、血流シミュレーションまたは算出を含む分析に基づいて）モデル化された血管系内の狭窄の面積を特定してもよい。

一実施形態では、ステップ４２７および４２９は、（例えば、生成ユーザインターフェース１２９を介して）精査および編集のために発生された報告およびピンを提示するステップを含んでもよい。注釈が、報告プロセッサ２０８によって自動的に発生されてもよい。一実施形態では、３Ｄモデル報告は、例えば、生成ユーザインターフェース１２９において修正されてもよい。例えば、生成ユーザインターフェース１２９は、報告を精査し、種々のモデルビュー内の関連性がある面積（例えば、主血管）のための１つ以上のピンの位置を調節するように分析者にプロンプトしてもよい。加えて、生成ユーザインターフェース１２９は、より多くのピンまたは注記を報告に追加し、関連性があるビューを作成し、分析の詳細（例えば、血流シミュレーション）を含有するＰＤＦ報告を発生させる能力を提供してもよい。ＰＤＦ報告は、（例えば、図１Ｂの報告データベース１１３における）記憶および（例えば、１つ以上のモバイルユーザインターフェース１０９を介した）アクセスのために、健康データＩＯシステム１０１に提供されてもよい。加えて、分析が、分析者が結果に満足していない場合、プロンプトされてもよい。例示的実施形態では、分析を再トリガすることが、事前ロード、モデル化、解析前、解析、解析後、または報告状態のうちのいずれかに戻るように症例を遷移させてもよい（例えば、ステップ４３１）。一実施形態では、（例えば、モデリングワークステーション１２７を介した）手動介入が、受信された未処理データの症例が事前設定された必要正確度または画質レベルを満たす場合、迂回されてもよい。解析前プロセッサ２０４、解析プロセッサ２０６、および解析後プロセッサ２０７動作を通過した後、報告が、（例えば、報告プロセッサ２０８によって）顧客に配信されてもよい。そのような実施形態は、（例えば、モデリングワークステーション１２７による報告または報告内のピンの）さらなる精査を迂回してもよい。

例示的実施形態では、症例モニタ（例えば、症例プロセッサ１２１）４２９が、報告が完了したことを健康データＩＯシステム１０１のＡＰＩに通知してもよい。一実施形態では、報告は、患者プライバシー情報（例えば、ＰＨＩデータベース１１４のＰＨＩ）に合致されてもよく、患者プライバシー情報は、報告に統合されてもよい。報告は、次いで、患者および／または医療従事者によってアクセスされるべき要求病院ワークステーション、ＰＡＣＳ、またはＨＬ７エンジン／ブローカにプッシュされてもよい。

図５は、本開示の例示的実施形態による、（健康データ分析システム１０５による）症例処理の順序を管理する例示的方法のフロー図である。一実施形態では、ステップ５０１および５０３は、第１の匿名化されたＤＩＣＯＭオブジェクトを受信するステップと、第１の匿名化されたＤＩＣＯＭオブジェクトと関連付けられる優先レベルを識別するステップとを含んでもよい。匿名化されたＤＩＣＯＭオブジェクトは、患者プライバシー情報を欠いている１つ以上の画像ファイルを含んでもよい。一実施形態では、優先レベルは、ＤＩＣＯＭオブジェクトを発生させた健康データＩＯシステム１０１と関連付けられてもよい。例えば、種々の優先レベルは、健康データＩＯシステム１０１と健康データ分析システム１０５との間の通信の確立に応じて、構成されてもよい。優先レベルはさらに、分析または分析を要求する医療提供者によって設定されてもよい。例えば、健康データＩＯシステム１０１は、発生されたＤＩＣＯＭオブジェクトと関連付けられるべき優先レベルを設定するようにユーザにプロンプトしてもよい。

一実施形態では、ステップ５０５および５０７は、第２の匿名化されたＤＩＣＯＭオブジェクトを受信するステップと、第２の匿名化されたＤＩＣＯＭオブジェクトと関連付けられる優先レベルを識別するステップとを含んでもよい。ステップ５０９は、（例えば、健康データ分析システム１０５において）最初に処理するべき症例を決定するステップを含んでもよい。一実施形態では、ステップ５０９は、第２の匿名化されたＤＩＣＯＭオブジェクトと関連付けられる優先レベルに対して、第１の匿名化されたＤＩＣＯＭオブジェクトと関連付けられる優先レベルを比較するステップを含んでもよい。第１の匿名化されたＤＩＣＯＭオブジェクトの優先レベルが、第２の匿名化されたＤＩＣＯＭオブジェクトと関連付けられる優先レベルよりも高い場合、分析が、第２の匿名化されたＤＩＣＯＭオブジェクトの分析に先立って、第１の匿名化されたＤＩＣＯＭオブジェクトに関して開始されてもよい（例えば、ステップ５１１）。例えば、ステップ５１１は、症例プロセッサ１２１のステップの進捗を通して第２の匿名化されたＤＩＣＯＭオブジェクトをプッシュすることに先立って、症例プロセッサ１２１の種々のコンポーネントを通した処理のために、（例えば、図２の）待ち行列モニタ２０１が第１の匿名化されたＤＩＣＯＭオブジェクトを待ち行列に入れるステップを含んでもよい。例えば、第１の匿名化されたＤＩＣＯＭオブジェクトは、第２の匿名化されたＤＩＣＯＭオブジェクトに先立って、事前ロードプロセッサ２０２による立証、解析前プロセッサ２０４による分析のための準備、解析プロセッサ２０６による分析、またはそれらの組み合わせのステップのうちの１つを受けてもよい。第１の匿名化されたＤＩＣＯＭオブジェクトに基づく分析の報告もまた、第２の匿名化されたＤＩＣＯＭオブジェクトに基づいて、最終報告の完了に先立って発生され、健康データＩＯシステム１０１に利用可能にされてもよい。

第１の匿名化されたＤＩＣＯＭオブジェクトの優先レベルが、第２の匿名化されたＤＩＣＯＭオブジェクトと関連付けられる優先レベルよりも低い場合、分析が、第１の匿名化されたＤＩＣＯＭオブジェクトの分析に先立って、第２の匿名化されたＤＩＣＯＭオブジェクトに関して開始されてもよい（例えば、ステップ５１３）。例えば、第２の匿名化されたＤＩＣＯＭオブジェクトは、第１の匿名化されたＤＩＣＯＭオブジェクトに先立って、事前ロードプロセッサ２０２、解析前プロセッサ２０４、解析プロセッサ２０６、報告プロセッサ２０８、またはそれらの組み合わせを通した処理のうちの少なくとも１つを受けてもよい。

図６は、本開示の例示的実施形態による、クラウドコンピューティングプラットフォームを経由して効率的に国境を越えた健康データを分析する例示的方法のフロー図である。一実施形態では、ステップ６０１は、１つ以上のＤＩＣＯＭオブジェクトを含有する一意の症例ファイルとして、健康データを受信するステップを含んでもよい。症例ファイルは、それと関連付けられる１つ以上の優先レベルを含んでもよく、優先レベルは、症例が健康データ分析システム１０５における分析を通過する順序を決定付けてもよい。一実施形態では、一意の症例識別子が、受信された健康データ（例えば、ＤＩＣＯＭオブジェクト）に関して発生されてもよい。

一実施形態では、ステップ６０３は、受信されたデータからＤＩＣＯＭ画像を解凍および抽出するステップを含んでもよい。一実施形態では、ステップ６０３は、一意の症例毎に、抽出されたＤＩＣＯＭ画像から圧縮アーカイブファイルを発生させるステップを含んでもよい。圧縮アーカイブファイルは、ヘッダファイルを含有するカスタマイズされたファイル、一連の選択ファイル、履歴ファイル（例えば、ユーザログ）、タスク状態ファイル、プロセスＩＤファイル、処理された一連の算出を表すフォルダのセット（ｎ＞＝１）等を含んでもよい。圧縮アーカイブファイルはまた、受信される健康データに応じて、１つ以上の体積画像ファイルを含んでもよい。例えば、健康データが、ＣＴスキャナによって発生される場合、圧縮アーカイブファイルは、ＣＴスキャンを備える、１つ以上の体積画像ファイルを含んでもよい。

一実施形態では、ステップ６０３は、受信された一意の症例の１つ以上のＤＩＣＯＭオブジェクトの正当性を立証するステップを含んでもよい。例えば、ＤＩＣＯＭオブジェクトは、ＤＩＣＯＭオブジェクトにＤＩＣＯＭ画像が欠落している場合、ＤＩＣＯＭオブジェクトのＤＩＣＯＭ画像サイズが定義された範囲外である場合、またはＤＩＣＯＭ画像が定義された品質基準を満たさない場合、無効と見なされ得る。一実施形態では、ステップ６０３は、（例えば、分析ウェブサービス１２３を介して）健康データ分析システム１０５から利用可能な各分析と関連付けられる、１つ以上の品質標準を設定するステップを含んでもよい。例えば、健康データ分析システム１０５によって提供される分析が、ＤＩＣＯＭオブジェクトから構築される解剖学的モデルに基づいて、血流シミュレーションを実施するステップを含む場合、ステップ６０３は、臨床的に使用され得るシミュレーション結果をレンダリングするであろう、解剖学的モデルを構築するための最小画質要件を含んでもよい。ステップ６０３はさらに、画質パラメータに基づいて信頼パラメータを発生させるステップを含んでもよい。例えば、ステップ６０３は、受信されたＤＩＣＯＭオブジェクトの画質を査定し、事前決定された画質要件に対して、受信されたＤＩＣＯＭオブジェクの画質スコアを比較するステップを含んでもよい。ステップ６０３はさらに、ＤＩＣＯＭオブジェクトの画質スコアが事前決定された画質要件を満たすことを決定し、ＤＩＣＯＭオブジェクトの画質スコアを決定することに基づいて、血流シミュレーション結果に関する信頼スコアを含む、メタデータタグを発生させるステップを含んでもよい。ステップ６０３はさらに、受信されたＤＩＣＯＭオブジェクトが無効であることを決定するステップを含んでもよい。ステップ６０３は、次いで、ユースケースに関して健康データを再び取り込む、または再提出するためのプロンプトを発生させるステップを含んでもよい。プロンプトは、病院コンピューティングデバイス１０６に直接送信されてもよい、またはプロンプトは、ユーザインターフェースを介してユーザに送信されてもよい。

一実施形態では、ステップ６０５は、ＤＩＣＯＭオブジェクトを前処理するステップを含んでもよい。例えば、ステップ６０５は、受信されたＤＩＣＯＭオブジェクトを使用して実施されるべき分析を決定するステップを含んでもよく、ステップ６０５はさらに、決定された分析に備えてＤＩＣＯＭオブジェクトを前処理するステップを含んでもよい。例えば、分析が血流シミュレーションを含む場合、前処理ステップは、ＤＩＣＯＭオブジェクトに基づいて解剖学的モデルを発生させるステップを含んでもよい。解剖学的モデルは、３Ｄメッシュモデルを含んでもよい。１つのシナリオでは、前処理は、受信されたＤＩＣＯＭオブジェクトからＤＩＣＯＭ画像を抽出し、抽出されたＤＩＣＯＭ画像から３Ｄ立体モデルを発生させるステップを含んでもよい。血流シミュレーション分析は、次いで、発生された３Ｄメッシュモデルを通して血流をシミュレートすることによって実施されてもよい。血流をシミュレートするための種々のシステムおよび方法が、例えば、２０１１年１月２５日に出願され、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｐａｔｉｅｎｔ－Ｓｐｅｃｉｆｉｃ Ｍｏｄｅｌｉｎｇ ｏｆ Ｂｌｏｏｄ Ｆｌｏｗ」と題された、米国特許第８，３１５，８１２号（参照することによってその全体として本明細書に組み込まれる）に開示される。一実施形態では、ステップ６０５は、健康データ分析システム１０５から利用可能な分析毎に所望される前処理を決定するステップを含んでもよい。ステップ６０５はさらに、前処理の結果のための使用を決定するステップを含んでもよい。例えば、発生された３Ｄメッシュモデルは、血流シミュレーション以外の分析のために使用されてもよい。代替として、または加えて、１つのメトリック（例えば、血圧）に関する分析のために使用される３Ｄメッシュモデルが、異なるメトリック（例えば、プラーク脆弱性）に関する分析で使用されてもよい。１つのシナリオでは、ステップ６０５はまた、ある分析に関して所望される前処理の程度を決定するステップを含んでもよい。例えば、ＤＩＣＯＭオブジェクトは、症例の一意の症例ＩＤと関連付けられる３Ｄメッシュモデルを補完するために使用されてもよい一方、ＤＩＣＯＭオブジェクトは、一意の症例識別子がそれと関連付けられるモデルをまだ有していない場合、新しい３Ｄメッシュモデルを発生させるために使用されてもよい。

一実施形態では、３Ｄメッシュモデルは、表現状態転送（ＲＥＳＴ）ＨＴＴＰプロトコルを使用して作成される、３Ｄ体積ファイルの形態であってもよい。例示的実施形態では、体積画像ファイルは、ヘッダ、バイナリデータ、カスタムヘッダ（例えば、分析ウェブサービス１２３によってサポートされる追跡機構または識別子）等を含んでもよい。ヘッダは、一連の一意の識別（ＵＩＤ）を含んでもよい。ＵＩＤは、分析下の症例ファイルと関連付けられるＤＩＣＯＭオブジェクトヘッダから読み出されてもよい。

一実施形態では、画像データの各体積画像ファイルは、体積画像ファイルの画像データに基づいて発生される３Ｄモデルに関する情報を記憶する、圧縮アーカイブファイルに対応し得る。圧縮アーカイブファイルはさらに、人間可読および機械可読の両方であり得る３Ｄモデルの表現（例えば、拡張マークアップ言語（ＸＭＬ）ファイル）を含む、ファイルに変換されてもよい。ファイルは、３Ｄモデルメッシュと、正中線、血管境界、血管直径／半径、組織境界、ピン（例えば、分析者によって作製されるマーキング）、画質スコア、信頼メトリック等を含む、他の情報とを含んでもよい。

一実施形態では、体積画像ファイルはそれぞれ、ファイルチェックサムを含有してもよい。ファイルチェックサムは、一連のＵＩＤをモデルデータ（例えば、管腔分割および／または心筋質量）と相関させ、（例えば、縦断研究またはデータ追跡のために）圧縮アーカイブファイルを１つ以上の体積画像ファイルと関連付け、１つ以上の体積画像ファイルが経時的に破損していないことを確実にするために、使用されてもよい。一実施形態では、チェックサムは、既製のアルゴリズムと体積画像ファイルの未加工データ部分を併用して、算出されてもよい。チェックサムアルゴリズムに関する識別子は、チェックサム自体に含有されてもよい。本配列は、チェックサムアルゴリズムの種々のバージョンまたはアップグレードに対処するために使用されてもよい。一実施形態では、圧縮アーカイブファイルは、圧縮アーカイブファイルと画像データとの間の一貫したリンクを維持するために、体積画像ファイルチェックサムを含んでもよい。一実施形態では、種々のモデルが、例えば、異なる分割アルゴリズムを使用して、画像データの異なる部分に焦点を当てて等、画像データから作成されてもよい。

一実施形態では、ステップ６０７は、前処理の結果の分析をプロンプトするステップを含んでもよい。例えば、ステップ６０５の前処理が、３Ｄモデルを発生させた場合、ステップ６０７は、３Ｄモデルを使用して分析をプロンプトするステップを含んでもよい。一実施形態では、ステップ６０７は、図５の通りに、症例ファイルの設定された優先順位に従って実施されてもよい。一実施形態では、ステップ６０７は、分析のために１つ以上の前処理された匿名ＤＩＣＯＭオブジェクトを分析ウェブサービス１２３に送信するステップを含んでもよい。例示的実施形態では、モデリングワークステーションが、チェックサムが伝送された体積画像ファイル内にまだ含まれていない場合、体積画像ファイルのためのチェックサムを算出してもよい。チェックサムが、体積画像ファイルを圧縮アーカイブファイルに合致させるために使用されてもよい。例えば、体積画像ファイルが、その独自のチェックサムに基づいて名前を付けられてもよく、したがって、圧縮アーカイブファイル内に含有される情報との相関を促進する。例えば、モデリングワークステーションが、所与の圧縮アーカイブファイルと関連付けられる体積画像ファイルのリストを読み出してもよい。

図７は、本開示の例示的実施形態による、健康データ分析システム１０５からの結果ファイルを後処理する例示的方法７００のフロー図である。例示的実施形態では、ステップ７０１は、分析ウェブサービス１２３から仮結果報告を受信するステップを含んでもよい。一実施形態では、最終結果報告を提示するための事前決定された形式が、事前決定されてもよく、最終結果報告の一部ではない仮結果報告内の任意の項目が、除去されてもよい。例えば、分析ウェブサービス１２３は、患者の血管系内の狭窄を治療するためのステント挿入のいくつかのシミュレーションを返してもよい。複数のシミュレーション結果が、仮結果報告が最も保守的なシミュレーション（例えば、最も低侵襲性であり、最高の血液動態影響を生成し得るステント挿入）のみを示すように、除去されてもよい。一実施形態では、ステップ７０１はさらに、仮結果報告に関連する分析ウェブサービス１２３からの前の結果が存在するかどうかを識別し、仮結果報告を前の結果と集約するステップを含んでもよい。

一実施形態では、ステップ７０３は、（双方向ユーザインターフェース、例えば、図１Ｃのモデリングワークステーション１２７または生成ユーザインターフェース１２９を使用して）精査のために仮結果報告／集約された報告を分析者に提示するステップを含んでもよい。一実施形態では、ステップ７０５は、仮結果報告への１つ以上の変更／修正、例えば、仮報告、ピン、シミュレーション等のビューへの編集を受信するステップを含んでもよい。一実施形態では、ステップ７０７は、仮結果報告の分析および発生を再トリガするステップを含んでもよい。

例示的実施形態では、ステップ７０７は、ユーザインターフェースを介して分析者によって提供される、１つ以上の変更／修正を組み込む、最終結果報告を発生させるステップを含んでもよい。例示的実施形態では、最終結果報告は、ＰＤＦ文書および／または分析からのモデルおよびソリューションの関連性がある面積を強調するピンまたはマークを伴う双方向３Ｄモデルを含んでもよい。例えば、最終結果報告は、患者の生体構造の３Ｄモデル、３Ｄモデルに基づいて計算される血流メトリック、（例えば、ステントまたはグラフトの挿入、生理学的状態の変化、薬剤等からの）３Ｄモデルへの種々の幾何学的修正の血液動態影響の比較を含んでもよい。一実施形態では、最終結果報告は、縦断研究および／または分析ウェブサービス１２３の種々の分析のための機械学習目的のために、（例えば、図１Ｃの匿名恒久記憶装置１２４ｂ内に記憶されてもよい。

一実施形態では、ステップ７０９は、（例えば、病院システムの所定のネットワークアドレスまたは健康データＩＯシステム１０１のウェブインターフェースを介して）最終結果報告を健康データＩＯシステム１０１にプッシュするステップを含んでもよい。例示的実施形態では、ステップ７０９は、最終結果報告を発生させるために使用される１つ以上のＤＩＣＯＭオブジェクトから所定のネットワークアドレスを読み出すステップを含んでもよい。例示的実施形態では、ユーザ（例えば、病院技術者）が、ウェブアプリケーション（例えば、オンラインポータル）および一意の症例識別子を使用して、症例に関して結果報告を要求し得る。結果報告は、具体的形式（例えば、ＰＤＦ形式または３Ｄモデル形式）で健康データＩＯシステム１０１にプッシュされてもよい。健康データＩＯシステム１０１は、ＨＴＴＰプロトコルを通してユーザから結果報告に対する要求を受信してもよい。

代替実施形態では、健康データ分析システム１０５は、結果報告の準備ができると、結果報告を病院コンピューティングシステム（例えば、ＰＡＣＳまたはＣＴワークステーション）にプッシュしてもよい。例えば、症例ステータスが、（例えば、待ち行列モニタによって）監視されてもよく、結果が、いったん症例が完了状態に遷移されると、（例えば、健康データＩＯシステム１０１の）病院システムまたは臨床ユーザインターフェースにプッシュされてもよい。例示的実施形態では、健康データ報告を、病院コンピューティングデバイス、病院電子記録サーバ、および事前構成された宛先ネットワークアドレスのうちの少なくとも１つにプッシュするステップは、ＨＬ７標準メッセージを、病院コンピューティングデバイス、病院電子記録サーバ、および事前構成された宛先ネットワークアドレスのうちの少なくとも１つに送信するステップを含んでもよい。一実施形態では、ＨＬ７標準メッセージは、カプセル化されたデータタイプまたはＵＲＬとして健康データ報告を含有してもよい。

本開示は、患者プライバシーデータを守りながら、異なる地理的領域内の患者の健康データを分析、記憶、および管理するためのシステムおよび方法を含む。本開示はさらに、匿名健康データを病院の領域外の分析クラウドプラットフォームに送信し、分析結果報告を伝送するためのシステムおよび方法を含む。故に、データ分析が、１つの領域から別の領域へのプライバシーデータの転送を回避しながら、領域を横断して提供され得る。説明される実施形態のうちのいずれかは、例えば、領域内で保たれ得るデータの変形例を含むように修正されてもよい。開示されるシステムおよび方法は、循環への任意の範囲の変化をモデル化および査定するように修正されてもよい。

１つ以上のクラウドベースのウェブサービスと関連付けられる１つ以上のプロセッサの機能は、単一の専用プロセッサによって、または複数のプロセッサによって提供されてもよい。さらに、プロセッサは、限定ではないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、またはソフトウェアを実行することが可能な任意の他のハードウェアを含んでもよい。技術のプログラム側面は、典型的には、あるタイプの機械可読媒体上で搬送される、またはそれで具現化される実行可能コードおよび／または関連付けられるデータの形態の「製品」または「製造品」と考えられ得る。「記憶」タイプ媒体は、ソフトウェアプログラミングのために任意の時間に非一過性の記憶を提供し得る、種々の半導体メモリ、テープドライブ、ディスクドライブ、および同等物等のコンピュータ、プロセッサ、または同等物、またはその関連付けられるモジュールの有形メモリのうちのいずれかまたは全てを含む。

ソフトウェアの全てまたは一部は、随時、インターネットまたは種々の他の電気通信ネットワークを通して通信されてもよい。そのような通信は、例えば、１つのコンピュータまたはプロセッサから別のものの中へ、例えば、モバイル通信ネットワークの管理サーバまたはホストコンピュータからサーバのコンピュータプラットフォームの中へ、および／またはサーバからモバイルデバイスへのソフトウェアのロードを可能にし得る。したがって、ソフトウェア要素を担い得る別のタイプの媒体は、ローカルデバイスの間の物理的インターフェースを横断して、有線および光学地上通信線ネットワークを通して、および種々のエアリンクを経由して使用されるような、光学、電気、および電磁波を含む。有線または無線リンク、光学リンク、または同等物等のそのような波を搬送する物理的要素はまた、ソフトウェアを担う媒体と見なされ得る。本明細書で使用されるように、非一過性の有形「記憶」媒体に制限されない限り、コンピュータまたは機械「可読媒体」等の用語は、実行のために命令をプロセッサに提供することに関与する、任意の媒体を指す。

本発明の他の実施形態も、本明細書に開示される本発明の明細書および実践の考慮から当業者に明白となるであろう。明細書および実施例は、例示的にすぎないと見なされ、本発明の真の範囲および精神は、以下の請求項によって示されることが意図される。

Claims (20)

1. 分散型クラウドコンピューティングプラットフォームを経由して健康データを分析するコンピュータ実装方法であって、前記方法は、
   分析のために、１つ以上の匿名ＤＩＣＯＭオブジェクトを含有する一意の症例ファイルを受信することと、
   前記１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる優先順位に基づいて、前記一意の症例ファイルに関して優先レベルを設定することと、
   前記１つ以上の匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つを解凍し、正当性を立証することと、
   前記解凍され、正当性を立証された匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つの分析を伝送することであって、前記分析は、前記一意の症例ファイルの優先レベルに従って完了されている、ことと
   を含む、方法。
2. 前記分析は、
   前記一意の症例ファイルの匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つに基づいて、体積画像ファイルを発生させることであって、前記体積画像ファイルは、３次元（３Ｄ）体積を表す、ことと、
   前記体積画像ファイルと関連付けられる分析データを含むアーカイブファイルを発生させることと、
   前記体積画像ファイルおよび前記アーカイブファイルに基づいて、患者特有のモデルを発生させることと
   を含む、請求項１に記載のコンピュータ実装方法。
3. 前記体積画像ファイルは、前記体積画像ファイルを前記アーカイブファイルに相関させるファイルチェックサムを含む、請求項２に記載のコンピュータ実装方法。
4. 前記一意の症例ファイルのステータスを監視することと、
   前記一意の症例ファイルのステータスおよび優先レベルに基づいて、前記一意の症例ファイルの分析を前進させることと
   をさらに含む、請求項１に記載のコンピュータ実装方法。
5. 前記１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる１つ以上のＤＩＣＯＭオブジェクトを発生させるエンティティ、および／または前記１つ以上の匿名ＤＩＣＯＭオブジェクトを分析するエンティティに基づいて、前記一意の症例ファイルに関して前記優先レベルを設定することをさらに含む、請求項１に記載のコンピュータ実装方法。
6. 前記受信された分析に基づいて、仮結果報告を発生させることと、
   前記仮結果報告の双方向ユーザインターフェースを発生させることと
   をさらに含む、請求項１に記載のコンピュータ実装方法。
7. 前記仮結果報告への修正を受信することと、
   前記修正に基づいて、最終結果報告を発生させることと、
   前記最終結果報告、所定の識別されたネットワークアドレス、または要求ウェブインターフェースを記憶することと
   をさらに含む、請求項１に記載のコンピュータ実装方法。
8. 前記最終結果報告は、セキュアなハイパーテキスト転送プロトコル（ＨＴＴＰＳ）を使用して、データベース、所定の識別されたネットワークアドレス、または要求ウェブインターフェースにプッシュされる、請求項６に記載のコンピュータ実装方法。
9. 分散型クラウドコンピューティングプラットフォームを経由して健康データを分析するためのシステムであって、前記システムは、
   分散型クラウドコンピューティングプラットフォームを経由して健康データを分析する命令を記憶する１つ以上のデータ記憶デバイスと、
   １つ以上のプロセッサであって、前記１つ以上のプロセッサは、前記命令を実行し、
   分析のために、１つ以上の匿名ＤＩＣＯＭオブジェクトを含有する一意の症例ファイルを受信することと、
   前記１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる優先順位に基づいて、前記一意の症例ファイルに関して優先レベルを設定することと、
   前記１つ以上の匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つを解凍し、正当性を立証することと、
   前記解凍され、正当性を立証された匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つの分析を伝送することであって、前記分析は、前記一意の症例ファイルの優先レベルに従って完了されている、ことと
   を含む方法を実施するように構成される、１つ以上のプロセッサと
   を備える、システム。
10. 前記分析はさらに、
    前記一意の症例ファイルの匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つに基づいて、体積画像ファイルを発生させることであって、前記体積画像ファイルは、３次元（３Ｄ）体積を表す、ことと、
    前記体積画像ファイルと関連付けられる分析データを含むアーカイブファイルを発生させることと、
    前記体積画像ファイルおよび前記アーカイブファイルに基づいて、患者特有のモデルを発生させることと
    から成る、請求項９に記載のシステム。
11. 前記体積画像ファイルは、前記体積画像ファイルを前記アーカイブファイルに相関させるファイルチェックサムを含む、請求項１０に記載のシステム。
12. 前記システムはさらに、
    前記一意の症例ファイルのステータスを監視することと、
    前記一意の症例ファイルのステータスおよび優先レベルに基づいて、前記一意の症例ファイルの分析を前進させることと
    を行うように構成される、請求項９に記載のシステム。
13. 前記システムはさらに、前記１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる１つ以上のＤＩＣＯＭオブジェクトを発生させるエンティティ、および／または前記１つ以上の匿名ＤＩＣＯＭオブジェクトを分析するエンティティに基づいて、前記一意の症例ファイルに関して前記優先レベルを設定するように構成される、請求項９に記載のシステム。
14. 前記システムはさらに、
    前記受信された分析に基づいて、仮結果報告を発生させることと、
    前記仮結果報告の双方向ユーザインターフェースを発生させることと
    を行うように構成される、請求項９に記載のシステム。
15. 前記システムはさらに、
    前記仮結果報告への修正を受信することと、
    前記修正に基づいて、最終結果報告を発生させることと、
    前記最終結果報告、所定の識別されたネットワークアドレス、または要求ウェブインターフェースを記憶することと
    を行うように構成される、請求項９に記載のシステム。
16. 前記最終結果報告は、セキュアなハイパーテキスト転送プロトコル（ＨＴＴＰＳ）を使用して、データベース、所定の識別されたネットワークアドレス、または要求ウェブインターフェースにプッシュされる、請求項１５に記載のシステム。
17. 分散型クラウドコンピューティングプラットフォームを経由して健康データを分析するためのコンピュータ実行可能プログラミング命令を含有するコンピュータシステム上で使用するための非一過性のコンピュータ可読媒体であって、方法は、
    分析のために、１つ以上の匿名ＤＩＣＯＭオブジェクトを含有する一意の症例ファイルを受信することと、
    前記１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる優先順位に基づいて、前記一意の症例ファイルに関して優先レベルを設定することと、
    前記１つ以上の匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つを解凍し、正当性を立証することと、
    前記解凍され、正当性を立証された匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つの分析を伝送することであって、前記分析は、前記一意の症例ファイルの優先レベルに従って完了されている、ことと
    を含む、非一過性のコンピュータ可読媒体。
18. 前記分析は、
    前記一意の症例ファイルの匿名ＤＩＣＯＭオブジェクトのうちの少なくとも１つに基づいて、体積画像ファイルを発生させることであって、前記体積画像ファイルは、３次元（３Ｄ）体積を表す、ことと、
    前記体積画像ファイルと関連付けられる分析データを含むアーカイブファイルを発生させることと、
    前記体積画像ファイルおよび前記アーカイブファイルに基づいて、患者特有のモデルを発生させることと
    を含む、請求項１７に記載の非一過性のコンピュータ可読媒体。
19. 前記方法はさらに、
    前記一意の症例ファイルのステータスを監視することと、
    前記一意の症例ファイルのステータスおよび優先レベルに基づいて、前記一意の症例ファイルの分析を前進させることと
    を含む、請求項１７に記載の非一過性のコンピュータ可読媒体。
20. 前記方法はさらに、前記１つ以上の匿名ＤＩＣＯＭオブジェクトと関連付けられる１つ以上のＤＩＣＯＭオブジェクトを発生させるエンティティ、および／または前記１つ以上の匿名ＤＩＣＯＭオブジェクトを分析するエンティティに基づいて、前記一意の症例ファイルに関して前記優先レベルを設定することを含む、請求項１７に記載の非一過性のコンピュータ可読媒体。

Images