JP6275876B2 - 医療データ処理のための進化型文脈的臨床データエンジン - Google Patents

Description

〔関連出願との相互参照〕
本出願は、２０１４年５月１４日に出願された米国仮特許出願第６１／９９３，００５号の利益を主張するものであり、この仮特許出願はその全体が引用により本明細書に組み入れられる。

本発明の実施形態は、一般に医療情報処理システムに関する。具体的には、本発明の実施形態は、進化型文脈的臨床データ（ＥＣＣＤ）エンジンを用いた医療データ処理に関する。

電子健康記録（ＥＨＲ）及び／又は電子医療記録（ＥＭＲ）は、急速に医療情報の取り込み、記憶及び表示のための標準になりつつある。しかしながら、複数の全く異なるソースからの医療情報を分析して使用するというニーズも存在する。例えば、医療情報は、ＥＭＲにおけるテキスト又は構造化データとして存在することも、或いは口述システムにおける音声記録などの非構造化データとして存在することもできる。データは、ＥＫＧなどのグラフ又はチャートとして存在することも、Ｘ線又は写真などの画像として存在することも、或いはコンピュータ断層撮影（ＣＴ）又はその他のスキャンなどの一連の画像として存在することもできる。画像系列データは、組織分析などの関連情報を有することもできる。臨床検査及び病理検査は、様々なフォーマットのレポートと同様の他のタイプの医療データである。

米国特許出願公開第１２／１９６，０９９号明細書（米国特許第８，３７０，２９３号明細書）

現在のところ、ＥＭＲは、テキスト及び臨床検査などのこれらのタイプのデータの一部を収集し、記憶して表示することはできるが、他の多くのタイプのデータを収集し、記憶して表示する能力は有していない。さらに重要なことに、ＥＭＲは、記憶しているデータを分析して最終的に使用する能力を有していない。例えば、胸痛を訴える患者がやって来た場合、ＥＭＲシステムは、その原因が何であるかを見極めることができない。原因を特定するために講じるべき対策を提案することもできない。ＥＭＲは、特定の臨床検査又は報告症状などの胸痛に関連し得るデータを容易に表示することができない。胸部Ｘ線又は胸部ＣＴスキャンなどの画像は、ＥＭＲシステムの一部でさえないこともあり、従ってＥＭＲシステムを介してこのような重要なデータにアクセスし、又は使用することもできない。

画像表示能力を有するＥＭＲシステムであっても、異常性などについて画像を分析することはできない。現在の医療データ記憶システム又は分析システムは、異なるフォーマットのデータ及び／又は異なるソースからのデータ（画像、テキスト、レポート、音声など）を分析することができない。また、いずれの現行システムも、ユーザの懸案事項に関連する異なるフォーマットのデータ及び／又は異なるソースからのデータを表示することはできない。例えば、胸痛を訴える患者がやって来た場合、症状、画像、臨床検査、現在の投薬、潜在的薬物相互作用などの、胸痛に関するユーザ医療情報を収集して表示できる現行システムは存在しない。また、異なるフォーマットのデータ及び／又は異なるソースからのデータを分析して、考えられる次の措置又は考えられる診断／治療を創造できる現行の医療データ記憶システム又は分析システムも存在しない。

同様の要素を同じ参照数字によって示す添付図面の図に、本発明の実施形態を限定ではなく一例として示す。

本発明の１つの実施形態による、進化型文脈的臨床データ技術を用いた医療情報システムを示すブロック図である。 本発明の１つの実施形態による、医療情報システムを示すブロック図である。 本発明の１つの実施形態による、医療情報を処理する進化型文脈的臨床データエンジンを示すブロック図である。 本発明の１つの実施形態による、医療情報サーバのデータコレクタの例を示すブロック図である。 本発明の１つの実施形態による、進化型文脈的臨床データ技術を用いて医療データを処理する過程を示すフロー図である。 本発明の１つの実施形態による、進化型文脈的臨床データ技術を用いて医療データを処理する過程を示すフロー図である。 本発明のいくつかの実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明のいくつかの実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明のいくつかの実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明のいくつかの実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明のいくつかの実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明のいくつかの実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の別の実施形態による、進化型文脈的臨床データ技術を用いて医療データを処理する過程を示すフロー図である。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の別の実施形態による、進化型文脈的臨床データ技術を用いて医療データを処理する過程を示すフロー図である。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。 本発明のいくつかの実施形態による、クラウドベースの画像処理システムを示すブロック図である。 本発明のいくつかの実施形態による、クラウドベースの画像処理システムを示すブロック図である。 本発明の１つの実施形態と共に使用できるデータ処理システムのブロック図である。

後述する詳細を参照しながら本発明の様々な実施形態及び態様について説明し、添付図面に様々な実施形態を示す。以下の説明及び図面は本発明を例示するものであり、本発明を限定するものとして解釈すべきではない。本発明の様々な実施形態を完全に理解できるように数多くの特定の詳細を示す。しかしながら、本発明の実施形態を簡潔に説明するために、いくつかの例では周知の又は従来の詳細については示していない。

本明細書における「１つの実施形態」又は「ある実施形態」についての言及は、その実施形態に関連して説明する特定の特徴、構造又は特性を本発明の少なくとも１つの実施形態に含めることができることを意味する。本明細書の様々な箇所で見られる「１つの実施形態では」という表現は、必ずしも全てが同じ実施形態を参照しているわけではない。

いくつかの実施形態によれば、本発明の実施形態は、ＤＩＣＯＭ（医用におけるデジタル画像及び通信）画像、（ＰＮＧ（ポータブルネットワークグラフィクス）、ＪＰＥＧ（ジョイントフォトグラフエキスパートグループ）、ＧＩＦ（グラフィクスインターチェンジフォーマット）、ＢＭＰ（ビットマップ）などの）非ＤＩＣＯＭ画像、テキスト、レポート、ＰＤＦ（ポータブルドキュメントフォーマット）文書、ファイル、音声ファイル、ビデオファイル、オフィス文書、及びその他のデータオブジェクトなどを含む進化型文脈的臨床データ（ＥＣＣＤ）技術を用いた医療データと、関連データの表示との統合をエンドユーザに有用な形で、又は「文脈的に」提供する。「文脈的に」とは、表示されるデータが、ユーザが検索又は閲覧している全てのものに関連することを意味する。例えば、「文脈的に」とは、患者ＩＤ、アクセス番号、研究ＩＤ、ログイン認証情報、日付、時間枠、発現、予約、身体部分又は部位、ユーザ、研究、保険コード、臨床試験など、又はこれらのパラメータのあらゆる組み合わせに関連するデータを表示することを意味する。

例えば、ユーザは、胸痛を訴える特定の患者を診ている場合、「胸痛」という用語をクリック又は入力すると、ＥＣＣＤシステムが痛み及び／又は心臓病に関するデータを表示することができる。例えば、システムは、最近行われたＥＫＧ、又はＥＫＧデータの経時的なあらゆる変化に関する情報を表示することができる。ＥＣＣＤシステムは、心臓病に関する臨床結果、又は臨床結果の経時的な変化を表示することができる。システムは、痛み及び／又は心臓病に関連する過去のレポート、訪問、口述などにおけるあらゆる関連症状を表示することができる。ＥＣＣＤシステムは、この情報をテキスト、画像、グラフ、チャート、スプレッドシートなどを含むあらゆる適切なフォーマットで表示することができる。

いくつかの実施形態では、ＥＣＣＤシステムが表示した特定のタイプのデータをユーザが操作することができる。例えば、ユーザ（例えば、内科医、医師、教授又は研究者、医学生、検査技師、又は特定のアクセス権を有する他のいずれかのスタッフ）は、トピックの範囲を狭め又は広げることにより、表示されるデータを絞り込むことができる。例えば、ユーザは、全身痛に関するデータを見ずに心臓病に関するデータのみを見たいと望む場合、表示されるデータの範囲を狭めることができる。ユーザは、データ自体を操作したいと望むこともできる。例えば、ＥＣＣＤシステムが、過去のＣＴ又はその他の画像スキャンに基づいて患者に６５％の狭窄があることを示す情報を表示した場合、ユーザは、この情報のソースを掘り下げて、（ユーザのアクセス認証情報に応じて）必要と見なすあらゆる変更を行うことができる。この例では、ユーザは、実際のＣＴ画像と、ＥＣＣＤシステムが行った画像分析とを掘り下げて画像が正しく見えるかどうかを判断し、あらゆる補正を行うことができる。例えば、ユーザは、画像上の狭窄の輪郭が全面的に正しいわけではないと感じた場合、輪郭を動かして分析を改善することができる。この場合、システムは、新たな狭窄の輪郭に基づいてユーザに情報を提供し、場合によっては狭窄数が増減する。

１つの実施形態では、ＥＣＣＤシステムが、医療データを文脈的に表示する以上のことを行うことができる。ＥＣＣＤシステムは、データを分析して情報及び診断を提供し、次の措置／治療を推奨することもできる。分析は、一切のユーザ介入又はユーザ関与を伴わずに、又は最低限のユーザ関与しか伴わずに、医療データに照らして一連のルール又は公開済みの疾患管理指針に基づいて自動的に行うことができる。ＥＣＣＤシステムは、画像スキャン系列を分析してこれらを解釈する役に立つだけでなく、異なるソースからの他の医療データを組み合わせ、これらのデータをまとめて分析することもできる。組み合わされた医療データは、同じ患者の他の医療データ（例えば、病歴）、状況が似ている他の患者の医療データ、及び／又はこの特定の医療データ項目又はトピックに関連するいくつかの所定のベンチマークを含むことができる。ＥＣＣＤシステムは、確率による鑑別診断の提供及び表示を行うことができる。ＥＣＣＤシステムは、この確率を絞るために、特定の検査を行うことを提案することができる。この種の提案は、経時的に及び／又は患者全体から収集されたデータ、及び／又は公開済みの疾患管理指針に基づくことができる。

例えば、ある患者に行ったＣＴスキャンが、１本の心臓動脈にわずかな狭窄があることを示す場合がある。この１つのデータでは、狭窄を治療すべきか否かについて医師の判断を促す情報として十分でないこともある。しかしながら、この１つのデータを、例えば臨床データ、症状データ、病歴、家族歴、結果が分かっている同様の状況の他の患者からの医療データなどの他の医療データと組み合わせると、決定を行うためのさらに多くの文脈が医師に与えられるようになる。

図１は、本発明の１つの実施形態による、進化型文脈的臨床データ技術を用いた医療情報システムを示すブロック図である。図１を参照すると、医療情報サーバ１０１は、ネットワークを介してクライアント１０２などの様々なクライアントに医療情報を提供するように構成される。１つの実施形態では、医療情報サーバ１０１が、とりわけＥＣＣＤエンジン１０３及びデータソースインターフェイス１０４を含む。ＥＣＣＤエンジン１０３は、プロセッサ及びメモリと、他のハードウェアコンポーネントとを有する専用コンピュータマシンに実装することができる。１つの実施形態では、ＥＣＣＤエンジン１０３を、人工知能（ＡＩ）技術を用いて実装することができる。ＥＣＣＤエンジン１０３は、高度医療データ処理エンジン及びインターフェイス、又は略して「Ｅｎｇ−Ｉｎｔ」と呼ぶこともできる。

再び図１を参照すると、１つの実施形態では、ＥＣＣＤエンジン１０３が、ユーザの入力に基づいてビューア又はユーザから情報を受け取る機能と、データコレクタ１０４を呼び出して、クライアント１０２から受け取った情報に関する情報を複数のデータソース１０５に問い合わせる機能と、複数のデータソース１０５から受け取ったデータを統合し、クライアント１０２に送信して、ビューアに、場合によっては異なるディスプレイ領域又はビューア領域に表示されるようにする機能とを含む複数の機能を実行する。この処理は、ユーザが自身の検索範囲を狭め又は広げて結果を見ることができるように反復的に繰り返される。この処理は反復問い合わせと呼ばれ、提示情報とのユーザインタラクションに応答してＥＣＣＤエンジン１０３によって行われる。

ＥＣＣＤエンジン１０３は、以前のユーザインタラクション又は特定の１又は複数のユーザの行動に基づいてモデル化できる一連のＥＣＣＤルール又はモデル（図示せず）に基づいて、クライアント１０２のユーザがどのようなタイプの医療データを受け取りたいと思っている可能性が高いかを判断することができる。換言すれば、ＥＣＣＤは自己学習することができる。ＥＣＣＤエンジン１０３は、例えばデータソース１０５と互換性のある様々なネットワーク通信プロトコルを用いて、１又は複数のデータソースインターフェイス１０４を介してデータソース１０５と通信し、ＥＣＣＤエンジン１０３からの推奨に基づく医療データ（例えば、特定の１又は複数の患者の医療データ）を検索する。ＥＣＣＤエンジン１０３は、複数の異なるデータソース１０５からのデータオブジェクトを分析又は調査し、患者ＩＤ、アクセス番号、日付、時間枠、身体部分、身体領域、病状、接触、処置、症状などの共通メタデータに基づいてデータオブジェクトを互いに統合する。

ＥＣＣＤエンジン１０３は、特定のデータソースインターフェイス１０４を用いて様々なデータソース１０５に接続する。医療データは、複数のデータソース１０５からプルされ、統合され、ウェブブラウザなどのシンクライアントとすることができるクライアント１０２に送信されて表示される。図１に示す例では、データソース１０５が、臨床検査情報システム（ＬＩＳ）、放射線医学情報システム（ＲＩＳ）、エンタープライズコンテンツ管理システム（ＥＣＭ）、電子医療記録（ＥＭＲ）、病院情報システム（ＨＩＳ）、画像保管通信システム（ＰＡＣＳ）、ＶＮＡ（ベンダ中立アーカイブ）、ＥＭＲデータ、様々なディレクトリ、及びその他のデータソースＨＩＥ（健康情報交換）サーバを含む。しかしながら、需要がある特定の構成及び／又は医療データに応じて、これよりも多くの又は少ないデータソースを適用することもできる。データソース１０５は、サーバ１０１を運用する組織とは異なる組織又は情報プロバイダによって管理及び／又は運用することができる。

１つの実施形態では、データソース１０５によって提供される医療データが、ＤＩＣＯＭフォーマットの医用画像データ、非ＤＩＣＯＭフォーマットの医用画像データ、スケジューリングデータ、登録データ、人口統計データ、処方箋データ、課金データ、保険データ、口述データ、レポートデータ、ワークフローデータ、ＥＫＧデータ、最良実施参考資料、参考資料、トレーニング資料などを含むことができる。これらのデータは、ＨＩＳ、ＲＩＳ、ＰＡＣＳ、ＬＩＳ、ＥＣＭ、ＥＭＲ又はその他のシステムを含む複数の場所又はシステムに存在することができる。非ＤＩＣＯＭデータは、Ａ／Ｖ、ＭＰＥＧ、ＷＡＶ、ＪＰＧ、ＰＤＦ、ＭｉｃｒｏｓｏｆｔＯｆｆｉｃｅ（商標）フォーマット及びその他のフォーマットを含む複数のフォーマットとすることができる。

一般に、ＰＡＣＳのデータはＤＩＣＯＭデータを含み、ＨＩＳ、ＲＩＳ及びＬＩＳ、ＥＣＭ、ＥＭＲのデータは、画像データと非画像データの両方を含む非ＤＩＣＯＭデータを含む。ＨＩＥデータは、健康情報交換システムを介して利用できるデータを含む。一般に、これらのデータは、地域システム、コミュニティシステム又は病院システム内の異なる組織にわたって利用できるデータを含み、ＤＩＣＯＭデータ又は非ＤＩＣＯＭデータとすることができる。他のデータは、コンピュータ上のディレクトリ内のデータ、モバイル装置からのデータなどを含む、他のいずれかの関連データを含むことができる。

様々なシステム（例えば、ＬＩＳ、ＲＩＳ、ＥＣＭ、ＥＭＲ、ＨＩＳ、ＰＡＣＳなど）は、ＤＩＣＯＭ、ＨＬ７（ヘルスレベルセブン）、ＸＤＳ、ＨＩＥ、ＯＲＵなどの異なる通信規格、フォーマット又はプロトコルを使用することができるので、ＥＣＣＤエンジン１０３は、特定のコネクタ又はデータソースインターフェイス１０４を用いて様々なシステム１０５のデータにアクセスする。一般に、これらのコネクタは、ビューアレベルでエンドユーザから隠されるので、ユーザがこれらの複雑性について心配する必要はない。しかしながら、適切なアクセス認証情報を有する特定のユーザは、ビューアインターフェイスを介して、ＥＣＣＤエンジン１０３を用いて直接、又は他の何らかのインターフェイスを介してコネクタを構成することができる。データコネクタのタイプとしては、以下に限定されるわけではないが、モバイル、ＥＭＲプラグインＡＰＩ（アプリケーションプログラミングインターフェイス）、ウェブサービス、ウェブブラウザアップロード／ダウンロード、ＨＬ７、ディレクトリスキャナ、ＤＬＬ（ダイナミックリンクライブラリ）ＡＰＩ、ＸＤＳ（クロスエンタープライズドキュメントシェアリング）、ＶＮＡ（ベンダ中立アーカイブ）、インデクシングサーバなどが挙げられる。

この実施形態のビューア又はクライアント１０２は、コンピュータ上のウェブブラウザ、モバイル装置上のモバイル装置アプリケーションなどのシンクライアントとすることができる。ビューアは、いずれかのソフトウェア又はプラグインのダウンロード／インストールを必要とするものであっても、又は必要としないものであってもよい。ビューアは、様々なデータソースから収集されたデータと、統合されてサーバ１０１から受け取られたデータとを表示するための１又は２以上のビューア領域／表示領域を有することができる。表示領域は、ウェブブラウザ内のフレーム及び／又はタブ内に存在することができる。表示領域は、互いに重なり合うことも、又は一体化することもできる。表示領域は、互いの中に存在することもできる。ビューアは、１つよりも多くの表示領域を有することが好ましい。

ビューアには、ＥＣＤエンジン１０３の問い合わせによって得られたデータを表示することができる。しかしながら、データは、データベース、レポートに組み込まれるようにＥＣＣＤエンジン１０３がエクスポートして別のシステムなどに統合することもできる。反復問い合わせの結果は、ＥＣＣＤエンジン１０３に記憶することも、又はエクスポートして別のシステムに記憶することも、或いはこの両方に記憶することもできる。ＥＣＣＤエンジン１０３は、別のソフトウェアシステムの起動、プリンタによる印刷の開始などの別の処理を開始することもできる。

１つの実施形態では、ＥＣＣＤエンジン１０３が、医療データを文脈的に表示する以上のことを行うことができる。ＥＣＣＤエンジン１０３は、データを分析して情報及び診断を提供し、次の措置／治療を推奨することもできる。分析は、一切のユーザ介入又はユーザ関与を伴わずに、医療データに照らして一連のルール又は確立された疾患管理指針に基づいて自動的に行うことができる。ＥＣＣＤエンジン１０３は、画像スキャン系列を分析してこれらを解釈する役に立つだけでなく、異なるソースからの他の医療データを組み合わせ、これらのデータをまとめて分析することもできる。組み合わされた医療データは、同じ患者の他の医療データ（例えば病歴、臨床データなど）、状況が似ている他の患者の医療データ、及び／又はこの特定の医療データ項目又はトピックに関連するいくつかの所定のベンチマークを含むことができる。

別の実施形態によれば、ＥＣＣＤエンジン１０３が、組み合わせたデータの分析に基づいて推奨を提供することができる。例えば、この患者は長年にわたってこの特定の狭窄を患っており、全ての血液検査／臨床検査は正常であり、患者は何の症状も示していないかもしれない。この情報の組み合わせは、患者に胸痛がある場合とは全く異なる治療、心臓病を示した血液検査の変化、又は他のさらに重大なデータを医師に示す可能性がある。この背景がなければ、医師は、最良の立場で決定を下すことができず、或いは検査／スキャンなどを繰り返す必要があると考えられる。

１つの実施形態によれば、ＥＣＣＤエンジン１０３は、この特定の患者の関連データを含むことに加えて、他の患者からのデータを検討することもできる。例えば、６５％又はそれを上回る狭窄があり、胸痛及び一定範囲の臨床検査値を有するほとんどの患者が１年などの一定期間内に心臓発作を起こすようになる可能性がこれまでに高い場合、ＥＣＣＤエンジン１０３は、この情報を医師に表示し、この特定の所見に関連する治療を推奨することもできる。他の患者／ユーザからの集約データは、「グラウンドトゥルース」と呼ばれることもある。データは、あらゆる数の状況について調査して分析することができる。ＥＣＣＤエンジン１０３は、異なるプロファイルに一致する患者に対して行われた治療を分析し、このデータを結果と共に分析することができる。その後、ＥＣＣＤエンジン１０３は、このデータを用いて他のユーザに治療を推奨することができる。

さらに、１つの実施形態によれば、ＥＣＣＤエンジン１０３は、患者の医療データの分析に照らして、一連のルールに基づいて行動又は動作を自動的に実行することもできる。例えば、特定の医療データ、事項又はトピックのデータが所定の閾値を上回った場合又は下回った場合には、患者及び／又は掛かり付け医などの所定の受信者に自動的に通知を送信することができる。

図２は、本発明の１つの実施形態による医療情報システムを示すブロック図である。例えば、システム２００は、図１に示すようなシステムを表すことができ、ＥＣＣＤエンジン１０３及びＥＣＣＤルール／モデル２０２などのサーバ１０１のコンポーネントの少なくとも一部をＥＣＣＤエンジン１０３の一部として実装することができる。図２を参照すると、システム２００は、以下に限定されるわけではないが、ネットワーク２０６を介して医療情報サーバ１０１に通信可能に結合された１又は２以上のクライアント１０２Ａ〜１０２Ｂを含む。ネットワーク２０６は、ローカルエリアネットワーク（ＬＡＮ）、都市圏ネットワーク（ＭＡＮ）、インターネット又はイントラネットなどのワイドエリアネットワーク（ＷＡＮ）、プライベートクラウドネットワーク、パブリッククラウドネットワーク、又はこれらの組み合わせとすることができる。

１つの実施形態では、医療情報サーバ１０１が、とりわけＥＣＣＤエンジン１０３、ＥＣＣＤモデル／ルール２０２、（単複の）ユーザデータベース２０３、（単複の）患者データベース２０４、医療データ統合器２０５、及び医用画像処理システム２１０を収容する。ＥＣＣＤエンジン１０３は、ユーザデータベース２０３に記憶されている特定のユーザのユーザインタラクション、行動及び／又はユーザ選択に基づいて、ＥＣＣＤルール又はＥＣＣＤモデル２０２をモデル化して生成するために利用できる様々な技術を用いて実装することができる。ユーザインタラクションは、クライアント１０２Ａ〜１０２Ｂにおけるクライアントソフトウェアアプリケーション２０７〜５０８のユーザインタラクションをモニタするユーザデータコレクタ（図示せず）によってモニタして取り込むことができる。この取り込んだユーザインタラクションをユーザデータベース２０３に記憶し、ＥＣＣＤエンジン１０３によって分析して、ＥＣＣＤルール又はＥＣＣＤモデル２０２を生成することができる。

１つの実施形態によれば、この例ではクライアント１０２Ａのユーザであるクライアントのユーザが、クライアントソフトウェア２０７Ａ（例えば、クライアントアプリケーション、ウェブブラウザ）において提示されたコンテンツ（例えば、患者又は医療データ２１１Ａ、医用画像２１２Ａ）と相互作用すると、このユーザインタラクションを表す信号又はメッセージ（例えば、クリック、キーストローク、音声コマンド）がクライアントアプリケーション２０７Ａによって医療情報サーバ１０１に送信される。このメッセージは、ユーザが相互作用した特定のコンテンツ及びその他のメタデータ（例えば、患者ＩＤ、身体領域又は身体部分ＩＤ、医療処置ＩＤ、医療予約、病状、ユーザＩＤ、相互作用の日付及び時間など）を含むことができる。データ統合器２０５は、クライアント１０２Ａから受け取ったメッセージに基づいて、ＥＣＣＤエンジン１０３及び／又はＥＣＣＤルール／モデル２０２を呼び出して一連の医療データを決定する。ＥＣＣＤルール／モデル２０２は、クライアントソフトウェア２０７及び／又はメタデータ（例えば、患者ＩＤ、身体部分ＩＤなど）を操作するユーザのユーザＩＤに基づいて識別することができる。データ統合器２０５は、決定されたデータセットに基づいて、このようなデータを提供できるデータソース１０５Ａ〜１０５Ｃのいくつかを識別する。データ統合器２０５は、様々なネットワーク通信プロトコルを用いて、識別されたデータソース１０５Ａ〜１０５Ｃと通信し、ＥＣＣＤエンジン１０３及び／又はＥＣＣＤルール／モデル２０２によって決定又は推奨された医療データを検索する。或いは、データ統合器２０５は、クライアント１０２Ａから受け取ったメッセージに基づいて一部又は全部の利用可能なデータソース１０５Ａ〜１０５Ｃを検索し、関連する一連の医療データの識別及び収集を行うこともできる。

データ統合器２０５は、検索された医療データを１又は２以上の医療情報ビューに統合する。１つの実施形態では、データ統合器２０５が、例えばユーザに関連するＥＣＣＤルール／モデル２０２に基づいて、最もユーザに適した及び／又は最もユーザが好む形で医療データを統合する。その後、１又は２以上の医療情報ビューが医療情報サーバ１０１からネットワーク２０６を介してクライアント１０２Ａに送信され、クライアントソフトウェアアプリケーション２０７Ａによって医療データ２１１Ａ及び／又は医用画像２１２Ａの一部としてユーザに提示される。

なお、提示される医療情報は、以前にクライアントに提示されたコンテンツとのユーザインタラクション時にユーザが要求した医療情報を含むことができる。また、医療情報は、ユーザが具体的には要求していないが、ＥＣＣＤルール／モデル２０２に基づいてＥＣＣＤエンジン１０３によって決定又は推奨された情報をさらに含むこともできる。例えば、あるユーザがＣＴスキャンに関する情報を要求した場合、ＥＣＣＤエンジンは、このユーザに関連するＥＣＣＤルール又はモデルに基づくとともに、例えばＣＴスキャンのメタデータに関連する別の一連のＥＣＣＤルールに基づいて、ＣＴスキャンに関連する１又は２以上の臨床検査又はＥＫＧもユーザに提示できる旨を推奨することができる。ＥＣＣＤルールは、人口動態、家族歴、臨床記録など、及び／又は関連情報の組み合わせを用いて決定することができる。一方で、ユーザが具体的に臨床検査又はＥＫＧを要求しなかったとしても、ＥＣＣＤが、ＥＣＣＤルール又はモデルに基づいて、ＣＴスキャン情報又はＥＫＧ又は臨床検査を見ることが大いに関連性があって診断上重要であると判断した時には、ユーザが臨床検査又はＥＫＧを受け取りたいと思っている可能性が高いこともある。

医用画像２１２Ａ〜２１２Ｂは、医療情報サーバ１０１内に統合できる、又は別個のサーバ又はサーバクラスタに収容される画像処理システム２２０の一部としてネットワークを介して遠隔的に統合できる画像処理システム２１０によってレンダリング又は生成することができる。様々なデータソース１０５Ａ〜１０５Ｃは、同じ又は異なる組織又は情報プロバイダが運用できる１又は２以上のサーバに収容することができる。１つの実施形態では、データソース１０５Ａ〜１０５Ｃが、ＬＩＳ、ＲＩＳ、ＥＣＭ、ＥＭＲ、ＨＩＳ、ＰＡＣＳ、ＶＮＡ及びＨＩＥサーバのうちの少なくとも１つを含む。データ統合器２０５は、例えばＤＩＣＯＭ、ＨＬ７、ＸＤＳ、ＨＩＥ及びＯＲＵなどの様々な通信方法又は通信プロトコルを用いてデータソース１０５Ａ〜１０５Ｃと通信して医療データを検索する。

１つの実施形態では、データソース１０５Ａ〜１０５Ｃから取得された１又は複数の患者の医療データを患者データベース２０４にキャッシュ又は記憶することができる。或いは、データベースが外部に存在することも、及び／又は複数のデータベースが存在することもできる。また、ＥＣＣＤエンジン１０３は、データベース２０４に記憶されている収集された対象患者の患者医療データを分析することもできる。例えば、ＥＣＣＤエンジン１０３は、クライアント装置のユーザが関心を寄せている現在の医療データに基づいて、患者に関連する医療データ、医療問題又は医療トピックに関連する異常な病状又は疾患が患者に発生する可能性を特定することができる。このような病状の可能性の特定は、患者の過去の医療履歴又は医療記録、或いは関連する特定のベンチマーク又は閾値、及び／又は他の患者のデータに照らした分析結果に基づいて行うことができる。

１つの実施形態では、ＥＣＣＤエンジン１０３が、医用画像処理システムを呼び出し、患者の身体部分の画像に画像処理動作を行って、特定の導出された画像定量データ又は測定データを作成することができる。画像は、データソース１０５Ａ〜１０５Ｃから取得された医療データの一部としてクライアント装置のユーザが選択することができる。この画像定量データを用いて、医用画像の特定の身体部分のサイズ及び／又は形状を特定又は測定することができる。この画像定量データを画像のタイプに関連する対応するベンチマークと比較して、近い将来又は指定時間枠内に特定の病状、医療問題又は疾患が発生する可能性があるかどうかを判定することができる。このような発生の可能性は、患者の病歴の一部及び／又は他の患者のデータと同じタイプの患者医療データの傾向に基づいてさらに予測又は決定することができる。

１つの実施形態では、ＥＣＣＤエンジン１０３が、分析に照らして取るべき行動又は行動指針をさらに推奨することができる。さらに、ＥＣＣＤエンジン１０３は、分析に基づいて所定の行動（例えば、予め設定した受信者に通知を送ること）を自動的に行うこともできる。これらの分析結果及び推奨される行動指針は、分析結果及び推奨２１３Ａ〜２１３Ｂの一部としてクライアント装置１０２Ａ〜１０２Ｂにそれぞれ送信することができる。分析結果は、所定の行動が行われた旨を示す情報、及び／又は推奨をさらに含むことができる。これらの全ての動作は、分析に照らして一連のルールに基づいてユーザ介入を伴わずに自動的に行うことができる。

図３は、本発明の１つの実施形態による、医療情報を処理する進化型文脈的臨床データエンジンを示すブロック図である。図３を参照すると、システム３００は、図１の医療情報サーバ１０１の一部として実装することができる。１つの実施形態では、ＥＣＣＤエンジン１０３が、以下に限定されるわけではないが、ユーザ行動分析器３０１と、ルールエンジン３０２と、ＥＣＣＤエンジン３０２によって生成された、メモリ３５１にロードして１又は２以上のプロセッサ（図示せず）によって実行できるＥＣＣＤルール又はモデル３０３とを含む。１つの実施形態では、ユーザ行動分析器３０１が、ユーザのユーザインタラクションデータを分析して、異なる医療情報への患者アクセスに関するユーザ行動パターンを特定する。例えば、ユーザ行動分析器３０１は、異なるユーザのユーザデータベース２０３にアクセスし、対応するユーザのユーザインタラクション履歴３２１を分析してそれぞれの行動パターンを特定することができる。ユーザインタラクション履歴３２１は、図２のユーザデータコレクタ２０４によって収集して、ハードドライブなどの永続記憶装置３５２の１又は２以上のデータベース内に実装できるユーザデータベース２０３に記憶することができる。上述したように、ユーザ行動パターンは、様々なアルゴリズム又は技術３０４を用いて特定又はモデル化することができる。ユーザ行動パターンは、個々のユーザのために使用することも、又は複数のユーザにわたって集約することもできる。

ＥＣＣＤルールエンジン３０２は、ユーザ行動分析器３０１によって特定されたユーザ行動パターンに基づき、それぞれの行動及び個人的選択３１１に基づいて各ユーザの一連のＥＣＣＤルール又はモデル３０３を取りまとめて生成する。その後、これらのＥＣＣＤルール及び／又はモデルは、対応するユーザデータベースにＥＣＣＤルール／モデル３３１の一部として記憶され、或いはＥＣＣＤエンジン１０３がＥＣＣＤルール／モデル３０３の一部として中央で維持することもできる。その後、データ統合器２０５は、特定の医療データにアクセスする新たなユーザ行動３３５を受け取るとＥＣＣＤエンジン１０３を呼び出し、ユーザに対応するＥＣＣＤルール／モデル３０３及び／又はＥＣＣＤルール／モデル３３１にアクセスして、ユーザが受け取りたいと思っている可能性の高い追加の医療データを決定する。次に、データ統合器２０５は、関連するデータソース１０５と通信して、要求された医療データ（例えば、第１の医療データ）と、追加の医療データ（例えば、第２の医療データ）とを検索する。次に、データ統合器２０５は、検索した医療データを統合して１又は２以上の医療情報ビュー３３６を生成する。その後、この１又は２以上の医療情報ビュー３３６がユーザのクライアント装置に送信されて提示される。

さらに、ユーザ行動３３５を取り込み、ユーザインタラクション履歴３２１の一部として永続装置３５２に記憶することもできる。ＥＣＣＤエンジン１０３は、更新されたユーザインタラクション履歴を使用又は「学習」して、対応するＥＣＣＤルール又はモデルを、将来的に使用できるようにトレーニング又は調整することができる。例えば、ユーザが、脳のスキャンを見ている時にＥＫＧデータをめったに又は全く要求しない場合、ＥＣＣＤエンジン１０３は、対応するＥＣＣＤルール又はモデルを構成することにより、ユーザが脳のスキャンを見ている時にはＥＫＧデータを提示しないことを学習する。ユーザは、この状況でＥＫＧ情報を見たいと望む場合、ＥＫＧ情報を見るための特定のクエリを行う必要があり、このようなユーザ行動によってそのＥＣＣＤルール又はモデルのさらなる修正をもたらすことができる。

別の例では、心臓内科医などのユーザが、過去のユーザ行動に基づいて、胸部のＣＴスキャンを見ている時に患者のＥＫＧを表す画像を常に見たいと望むこともできる。ユーザが１回又は２回以上この要求を行うと、ＥＣＣＤエンジン１０３は、この特定のユーザがこれらの画像を同時に見たいと望む頻度が高いことを学習し、その後にユーザが胸部のＣＴスキャンを見ることを要求した時にＥＫＧデータを提示するようにＥＣＣＤルール／モデルを修正することができる。他の多くのユーザも胸部ＣＴスキャンを見ている間にＥＫＧデータを要求する頻度が高い場合、ＥＣＣＤエンジン１０３はこのデータを解釈し、全てのユーザ又は例えば心臓内科医などの全てのユーザの一部に対して胸部ＣＴスキャンデータの要求時にＥＫＧデータを提示する尤度を高めることができる。このように、ＥＣＣＤエンジン１０３は、異なるユーザ又は異なるユーザタイプ又は全てのユーザについて「文脈的な」意味が何であるかを「学習」することができる。

ＥＣＣＤエンジン１０３がユーザから学習できる別の方法は、（例えば、図５のユーザデータコレクタ２０４によってモニタした）クリック率及び閲覧時間を追跡し、この情報をＥＣＣＤエンジン１０３内でユーザ、研究タイプ、個々の研究、情報タイプ、表示されている他の情報などに結び付けることによるものである。低いクリック率及び／又は短い閲覧時間は、関連性の低い情報を示すことができ、高いクリック率及び／又は長い閲覧時間は、関連性の高い情報を示すことができる。ＥＣＣＤエンジン１０３は、この経時的に収集された情報を用いて、提示するコンテンツを精密化することにより、使用されるにつれてますます知的になる。例えば、１又は複数のユーザが３ヶ月よりも古い臨床データをほんの数秒しか見ず、新しい臨床データを長時間にわたって見て、古い情報がそれほど有用でないことを示すことがある。ＥＣＣＤエンジン１０３は、この情報を用いて、この例では３ヶ月よりも前の臨床データを１又は複数のユーザに提示しないようにすることができる。

ＥＣＣＤエンジン１０３がそのユーザからどのように学習できるかについての別の例は、総解釈時間の追跡によるものである。総解釈時間とは、複数の関連する画像又は情報オブジェクトを見る時間、及び／又は特定の高度画像処理ステップを実行する時間、及び／又は１人の患者に関する情報を精査する総時間とすることができる。ＥＣＣＤエンジン１０３は、この情報を分析して読み取り時間の傾向を判断することができる。最終的に、この情報を用いて総読み取り時間を低減することができる。例えば、ＥＣＣＤエンジン１０３が、ＣＴスキャンを単独で見ることが精査過程の一部に含まれる時には内科医が特定の患者の精査に３０分を費やし、前回のＣＴスキャンの隣りにＣＴスキャンが提示された時には患者の精査に１０分しか費やさないと判断した場合、システムは、ユーザが見たいＣＴスキャンを選択した時に古い又は新しいＣＴスキャンを表示する尤度を高めることができる。

ＥＣＣＤエンジン１０３がそのユーザからどのように学習できるかについての別の例は、直接ユーザフィードバックを要求することによるものである。例えば、ＥＣＣＤエンジン１０３は、特定のデータオブジェクトの表示が有用であったか、それとも有用でなかったかを尋ねることができる。ＥＣＣＤエンジン１０３は、この情報を収集して分析することにより、どのデータオブジェクトの関連性が高いか又は低いかをさらに素早く学習することができる。ＥＣＣＤエンジン１０３は、いずれかの時点に表示しているデータオブジェクトの組み合わせも認識しており、この認識を分析に組み込むことができる。例えば、ユーザが、ＥＫＧを単独で又は大腸内視鏡と組み合わせて表示した時には有用でない旨を示したが、ＥＫＧを心臓のＣＴスキャンと横並びに表示した時には非常に有用である旨を示した場合、ＥＣＣＤエンジン１０３は、心臓のＣＴスキャンが見られている時にはＥＫＧを表示する頻度を高め、そうでなければ頻度を下げることを学習する。上記の例は、ＥＣＣＤルール／モデル３０３及び３３１によって表現できる考えられる状況のほんのいくつかである。他の可能性を適用することもできる。

１つの実施形態によれば、データソース１０５から特定の１又は複数の患者の患者医療データを取得して、記憶装置３５２内に維持されている患者データベース２０４にキャッシュして記憶することができる。患者データベース２０４に記憶される情報としては、以下に限定されるわけではないが、患者医用画像３１２、患者病歴又は記録３２２、及び情報処理方法を定める任意の一連のＥＣＣＤルール３３２を挙げることができる。患者データベースは、他の患者の医療データ及び特定の医療データベンチマーク（図示せず）をさらに記憶することができる。或いは、患者医療データを記憶／キャッシュせずに、データソース１０５からのデータにリアルタイムでアクセスすることもできる。

１つの実施形態によれば、ＥＣＣＤエンジン１０３が、分析モジュール３０４及び行動推奨モジュール３０５をさらに含む。分析モジュール３０４は、患者データベース２０４に記憶されている医療情報がメモリ３５１にロードされるようにして、特定の患者の医療情報の分析を行うことができる。例えば、分析モジュール３０４は、画像処理システム２１０を呼び出して医用画像３１２を処理し、画像に関する定量データ（例えば、画像からの身体部分のサイズ及び／又は形状に関する測定結果）を提供することができる。次に、分析モジュール３０４は、この画像定量データを分析して、近い将来又は特定の時間枠内に患者に特定の医療状態が生じる可能性があるかどうかを判定する。この判定は、患者の病歴３２２及び／又は他の患者の同様の医療データに照らして行うことができる。この判定は、医療データ及び／又は関連する患者のタイプに基づいて構成できる一連のＥＣＣＤルール３２２に基づいて自動的に行うことができる。或いは、患者医療データを記憶／キャッシュせずに、データソース１０５からのデータにリアルタイムでアクセスすることもできる。

別の実施形態によれば、推奨モジュール３５０は、医療データ及びその対応する分析に基づいて、取るべき行動指針についての１又は２以上の推奨を決定するように構成される。この推奨は、医療データ及び／又はその分析に照らしてＥＣＣＤルール３０３に基づいて決定することができる。データ統合器２０５は、これらの分析結果及び推奨を医療情報３３６の（単複の）ビューに組み込み、ネットワークを介してユーザのクライアント装置に送信して表示することができる。

なお、これまでに図示し説明したコンポーネントの一部又は全部（例えば、ＥＣＣＤエンジン１０３、画像処理システム２１０）は、ソフトウェア、ハードウェア、又はこれらの組み合わせで実装することができる。例えば、このようなコンポーネントは、永続記憶装置にインストールされ記憶されたソフトウェアとして実装し、メモリにロードし、プロセッサ（図示せず）によって実行して、本出願を通じて説明する処理又は動作を実行することができる。或いは、このようなコンポーネントは、対応するドライバ及び／又はオペレーティングシステムを介してアプリケーションからアクセスできる、集積回路（特定用途向けＩＣ又はＡＳＩＣ）、ＧＰＵ（図形処理ユニット）、デジタルシグナルプロセッサ（ＤＳＰ）又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの専用ハードウェアにプログラムされた又は組み込まれた実行可能コードとして実装することもできる。さらに、このようなコンポーネントは、１又は２以上の特定の命令を介してソフトウェアコンポーネントがアクセスできる命令セットの一部としての、プロセッサ又はプロセッサコア内の特定のハードウェアロジックとして実装することもできる。

図４は、本発明の１つの実施形態による、医療情報サーバのデータコレクタの例を示すブロック図である。図４を参照すると、データ統合器２０５は、以下に限定されるわけではないが、データ検索モジュール４０１と、ビュー生成器４０２と、ユーザ行動分析モジュール４０３と、医療データインターフェイス（Ｉ／Ｆ）モジュール４０４Ａ〜４０４Ｃとを含む。１つの実施形態によれば、ユーザが、クライアント装置１０２によって提示された医療コンテンツと相互作用すると、クライアント装置１０２からネットワークを介して医療情報サーバ１０１に信号又はメッセージが送信され、このような信号又はメッセージがユーザ行動分析モジュール４０３によって受け取られる。受け取られるメッセージは、ユーザがどのようなコンテンツ項目と相互作用したかを示すいくつかのメタデータと、その他の識別情報（例えば、ユーザＩＤ、患者ＩＤ、医療処置ＩＤ、身体領域又は身体部分ＩＤ、相互作用の日付及び／又は時間、病状ＩＤ、医療予約ＩＤなど）とを含むことができる。ユーザ行動分析モジュール４０３は、メッセージから情報を抽出し、抽出した情報を分析する。

１つの実施形態では、ユーザ行動分析モジュール４０３が、この分析に基づいて、分析結果についての情報及び／又はメッセージから抽出されたメタデータを提供することによってＥＣＣＤエンジン１０３を呼び出す。これに応答して、ＥＣＣＤエンジン１０３は、例えばユーザのユーザＩＤに基づいて、クライアント装置１０２のユーザに関連するＥＣＣＤルール／モデル３０３からの一連のＥＣＣＤルール又はモデルを識別する。次に、ＥＣＣＤエンジン１０３は、ユーザ行動分析モジュール４０３がユーザに関連する対応するＥＣＣＤルール又はモデルを用いて提供した入力に基づいて、一連の１又は２以上の動作又は推奨を導出する。これらの推奨は、ユーザによって要求された医療データに関連する特定の追加医療データを収集又は表示することを含むことができ、ＥＣＣＤエンジン１０３は、要求された医療データ、及び／又はクライアント装置１０２から受け取られたメッセージから抽出されたユーザ行動に照らして、ユーザが受け取りたいと思っている可能性の高い追加医療データを想定又は予測することができる。

データ検索モジュール４０１は、ユーザが最初に要求した第１の医療データと、ＥＣＣＤエンジン１０３がさらに推奨した第２の医療データとに基づいて、このような医療データを提供するデータソース１０５Ａ〜１０５Ｃのうちの１つ又は２つ以上を識別する。例えば、データ検索モジュール４０１は、ユーザによって要求された異なる医療データ及びＥＣＣＤエンジン１０３によって推奨された異なる医療データの識別子を決定することができる。データ検索モジュール４０１は、この医療データ識別子を対応するデータソースにマッピングするデータベース又はデータ構造を維持し、及び／又はこれにアクセスすることができる。データ検索モジュール４０１は、識別されたデータソースに基づいて、対応する医療データインターフェイスモジュール４０４Ａ〜４０４Ｃを呼び出し、これらの医療データインターフェイスモジュール４０４Ａ〜４０４Ｃがデータソース１０５Ａ〜１０５Ｃにそれぞれアクセスする。

医療データインターフェイスモジュール４０４Ａ〜４０４Ｃは、データソース１０５Ａ〜１０５Ｃのうちの特定のデータソースとの通信を処理するように特別に設計されたインターフェイスロジックを（ソフトウェア、ハードウェア、又はこれらの組み合わせのいずれかで）含む。データインターフェイスモジュール４０４Ａ〜４０４Ｃの各々は、対応するデータソースと互換性のある、又は対応するデータソースによって認識される特定の通信プロトコル（例えば、ＴＣＰ／ＩＰ、ＤＩＣＯＭ、ＨＬ７、ＸＤＳ、ＨＩＥ、ＯＲＵなど）又はアプリケーションプログラミングインターフェイス（ＡＰＩ）を用いて、データソース１０５Ａ〜１０５Ｃのうちの対応する１又は２以上のデータソースと通信するように特別に構成された機能を含む。この機能は、正しいプロトコルシグナリング又は呼び出し規約、ハンドシェーキング、データ交換、及び関連する認証クレデンシャルを用いた異なるユーザの認証を含む。

１つの実施形態によれば、データインターフェイスモジュール４０４Ａ〜４０４Ｃは、データソース１０５Ａ〜１０５Ｃから受け取った医療データ（例えば、未加工データ）をデータ検索モジュール４０１と共通のフォーマット、又はデータ検索モジュール４０１によって予想されるフォーマットに再フォーマットすることができ、或いはデータ検索モジュール４０１が再フォーマット動作を行うこともできる。１つの実施形態では、データインターフェイスモジュール４０４Ａ〜４０４Ｃの各々が、対応するデータソースのためのプラグインインターフェイスモジュールを含む。データインターフェイスモジュール４０４Ａ〜４０４Ｃは、例えば、ＤＩＣＯＭ画像、非ＤＩＣＯＭ画像、テキスト、レポート、ＰＤＦ文書、ＪＰＥＧファイル、音声ファイル、ビデオファイル、オフィス文書及びその他のデータオブジェクトなどの異なるタイプのデータを処理することができる。データソース１０５Ａ〜１０５Ｃは、ＬＩＳ、ＲＩＳ、ＥＣＭ、ＥＭＲ、ＨＩＳ、ＰＡＣＳ、及び／又はＨＩＥサーバを含む様々なサーバ又はサーバクラスタに収容することができる。

データ検索モジュール４０１によってデータソース１０５Ａ〜１０５Ｃから医療データが検索されると、ビュー生成器４０２が、これらの医療データを統合して１又は２以上の医療情報ビューを生成する。１又は２以上の医療情報ビューは、ユーザ選択に基づいてユーザの好みのレイアウトに従って配置することができる。或いは、医療情報ビューは、ＥＣＣＤルール又はモデル３０３に基づいて、及び／又はユーザ選択に照らして、ＥＣＣＤエンジン１０３が推奨する形で構築することもできる。例えば、使用頻度の低い画像処理ツールはユーザに提示せず、或いは他の使用頻度の高い画像処理ツールに対して低い優先度で提示することができる。その後、この１又は２以上の医療情報ビューはクライアント装置１０２に送信され提示される。ユーザが医療情報とさらに相互作用した場合、このユーザインタラクションが再び取り込まれ、データ統合器２０５に送信されて、上記の過程が繰り返し行われる。

１つの実施形態によれば、ＥＣＣＤエンジン１０３は、データ検索モジュール４０１に通信可能に結合されて、永続記憶装置のデータベース（データベース２０４など）に記憶することも、或いはデータソース１０５から直接アクセスすることもできる検索データにアクセスする。ＥＣＣＤエンジン１０３は、記憶している医療データを分析し、異常な病状又は疾患の確率を求め、１又は２以上の推奨を生成し、上述したようなＥＣＣＤルール３０３に基づく所定の動作を任意に実行する。ビュー生成器４０２は、ＥＣＣＤエンジン１０３によって生成された分析結果及び推奨４１０を医療情報のビューに統合してクライアント装置１０２に送信することができる。

図５は、本発明の１つの実施形態による進化型文脈的臨床データ技術を用いて医療データを処理する過程を示すフロー図である。プロセス５００は、ソフトウェア、ハードウェア又はこれらの組み合わせを含むことができる処理ロジックによって実行することができる。例えば、プロセス５００は、医療情報サーバ１０１によって実行することができる。図５を参照すると、ブロック５０１において、処理ロジックは、ユーザのクライアント装置において表示された医療情報（例えば、第１の医療情報）に対するユーザインタラクションを示す信号又はメッセージを受け取る。ブロック５０２において、処理ロジックは、要求された医療データのタイプを特定し、１又は２以上のデータソース（例えば、ＰＡＣＳ、ＥＭＲ、ＨＩＳ）と通信して、ユーザインタラクションに基づいて患者の医療データ（例えば、医用画像、患者情報又は医療記録）を検索する。ブロック５０３において、処理ロジックは、例えば患者の病歴及び／又は他の患者の医療データに照らして、検索された患者の医療データの分析を自動的に行う。処理ロジックは、任意に分析に基づいて行動指針の推奨を生成する。ブロック５０４において、処理ロジックは、受け取った医療データと分析結果とを統合して１又は２以上の医療情報ビューを生成する。その後、ブロック５０５において、クライアント装置に医療情報ビューが送信されて表示される。

図６は、本発明の１つの実施形態による、進化型文脈的臨床データ技術を用いて医療データを処理する過程を示すフロー図である。プロセス６００は、ソフトウェア、ハードウェア又はこれらの組み合わせを含むことができる処理ロジックによって実行することができる。例えば、プロセス６００は、医療情報サーバ１０１によって実行することができる。図６を参照すると、ブロック６０１において、処理ロジックは、ユーザのクライアント装置において表示された医療情報（例えば第１の医療情報）に対するユーザインタラクションを示す信号又はメッセージを受け取る。ブロック６０２において、処理ロジックは、要求された医療データのタイプを特定し、１又は２以上のデータソース（例えば、ＰＡＣＳ、ＥＭＲ、ＨＩＳ）と通信して、ユーザインタラクションに基づいて患者の医療データ（例えば、医用画像、患者情報又は医療記録）を検索する。ブロック６０３において、処理ロジックは、医用画像に自動的に画像処理動作（例えば、測定及び／又は計算）を行って医用画像定量データを生成する。ブロック６０４において、処理ロジックは、医用画像定量データを対応するベンチマークと比較して、任意に患者の病歴に照らしてあらゆる異常な病状又は問題を検出する。ブロック６０５において、検索された医療情報及び画像定量データの比較結果がクライアント装置に送信されて表示される。

図７Ａ及び図７Ｂは、本発明のいくつかの実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。例えば、図７Ａ〜図７Ｂに示すグラフィカルユーザインターフェイス（ＧＵＩ）ページは、医療情報サーバ１０１によって生成し、医療情報サーバ１０１からネットワーク２０６を介してクライアント装置１０２Ａ〜１０２Ｂに送信し、図２に示すようなクライアント装置１０２Ａ〜１０２Ｂのクライアントアプリケーション２０７Ａ〜２０７Ｂによって提示することができる。このＧＵＩページとのユーザインタラクションが取り込まれ、クライアント装置から医療情報サーバ１０１に送信される。次に、医療情報サーバ１０１は、このユーザインタラクションを解釈又は分析し、ユーザインタラクションに応答して、画像処理動作、情報検索動作、並びにデータ処理及び／又は統合動作、分析、推奨などの正しい動作を実行し、クライアントに処理結果を戻す。処理結果は、クライアントのディスプレイ装置において既存の情報と共に提示及び／又は統合される。

図７Ａを参照すると、この実施形態では、図示のＧＵＩが、電子医療記録（ＥＭＲ）又は電子健康記録（ＥＨＲ）ビューアインターフェイスを表すことができ、これをＧＵＩのタイトル領域に示すことができる。１つの実施形態では、ＧＵＩページが、患者識別情報を表示する第１の表示領域７０１と、患者に関する詳細情報を表示する第２の表示領域７０２と、１又は２以上の処理段階の処理タイムライン（例えば、１又は２以上のワークフロー段階を含むワークフロー）を表示する第３の表示領域７０３とを含む。ＧＵＩは、特定の患者に関連する医療データにアクセスするための１つの方法を示す。この例では、ユーザが、人体の図形表示の頭部、肺、心臓などの身体領域を介して医療データにアクセスすることができる。

この例では、ビューア／クライアントをウェブブラウザとして示している。表示領域７０３のブラウザウィンドウの上部全体は、データ閲覧／処理過程のタイムライン又はプロセスライン又はワークフローである。このワークフロー図は、ユーザがプロセス内のどこにいるかをユーザに示す。このＧＵＩは、ユーザがプロセスの「身体領域選択」段階７１１にいることを示している。このサンプル画面では、このことが、暗い輪郭又は強調アイコン７１１と、その下の矢印インジケータとによって伝えられる。ページタイトル７１５は、ユーザがワークフロープロセス内のどこにいるかを示し、この例では「身体領域選択」段階にいることをユーザに示している。身体７２０を通じて、人体の表現が示される。身体７２０に対してカーソル又はポインタを用いて、心臓、肺、胸部、頭部、腹部、腸などの様々な身体領域を示すことができる。この図では、心臓領域上でホバリングしてヒントとしてのポップアップテキストが見えるようにしているカーソルが示されている。このようにして、ユーザは、身体のあちこちにカーソルを動かして、どの身体領域をクリックしたいと望むかを決定することができる。

表示領域７０１は、患者名、患者ＩＤ及び性別などの患者情報を表示する。表示領域７０１は、例えば、患者の医療レポート、患者の病歴などの、選択した患者に関連するＨＥＲの異なる領域にアクセスし、医師との医療予約を作成又は閲覧し、患者の特定の病状を見るための１又は２以上のナビゲーションボタン又は制御をさらに含む。ユーザのアクセス権（例えば、医師、検査技師、医学生、教授など）に応じて、情報の一部をアクセス可能又はアクセス不可能とすることができ、アクセス可能な場合には、一部の機密情報を編集済み又は不可視とすることができる。

図７Ｂに、図７Ａの代替表現を示す。図７Ａでは、ユーザに身体図が提示され、身体部分に基づいてレポートを選択する。図７Ｂでは、ＥＣＣＤシステムが患者の（及び場合によっては他の患者の）データの分析に基づいて提示した複数の考えられる病気／疾病／状態がユーザに提示される。この例では、表示領域７０１に識別される患者Ｘが、心臓病の可能性、肺癌の可能性及び予定日を過ぎた大腸内視術という３つの関心分野を有する。これらは、リスト７５０に表示される。ユーザは、これらのリンクのいずれかを作動させると、選択したリンクに関連する情報を含む画面に誘導される。

図８Ａ〜図８Ｄは、本発明のいくつかの実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。例えば、図８Ａ〜図８Ｄは、図７Ａ〜図７Ｂとのユーザインタラクションに応答して生成され表示されるものとすることができる。図８Ａを参照すると、この例のＧＵＩページは、図７Ａの人体表現から心臓を選択したユーザインタラクションに応答して生成され表示されたものである。ユーザがクライアント装置のクライアントアプリケーション（例えば、ウェブブラウザ）から心臓を選択したことに応答して、このクライアントアプリケーションは、対応する患者の心臓に関連する医療情報を求める要求を医療情報サーバ１０１に送信する。この要求は、患者を識別する患者ＩＤ、心臓を識別する身体部分ＩＤ、及びその他の必要な情報（例えば、ユーザを識別してアクセス権を判断するユーザＩＤ）を含むことができる。

サーバ１０１は、この要求に応答して、この例では心臓に関する医療データである、患者のいずれかの関連する医療データと、上述したようなユーザが受け取りたいと思っている可能性の高い他のデータとを決定するように構成される。次に、サーバ１０１は、異なる情報プロバイダの１又は２以上の医療データサーバと通信して患者の関連する医療データを取得する。また、自動的に分析を行い、分析に基づいて行動指針の推奨を生成することもできる。さらに、上述したような医療データ、ユーザ及び／又は患者のタイプに関連する一連のルールに基づいて、所定の動作（例えば通知を所定の受信者に送信する）を自動的に行うこともできる。その後、サーバ１０１は、医療データと分析結果とを統合して１又は２以上の医療情報ビューを生成し、この医療情報ビューをクライアント装置に戻して、図８Ａ〜図８Ｄに示すようなＧＵＩページの一部として表示することができる。

図８Ａを参照すると、ＧＵＩページは、この患者の心臓に関するデータを表示している。この例では、図７Ａから心臓を起動又は選択したことに応答して、テーブル８０２に患者の心臓に関連するデータが表示されるとともに、画像８０４が表示されている。表示領域７０３の処理段階タイムラインも、アイコン７１２を通じて、現在の処理段階がレポート表示段階であることを示している。この例では、医療情報サーバ１０１から受け取られた医療データが、様々なタイプの医療データを有するテーブル８０２と医用画像８０４とを含む。テーブル８０２のデータ及び画像８０４は、ＥＣＣＤシステムによって生成され、ユーザのクライアント装置に送信される。この例では、ウェブブラウザのフレーム、タブ、又は領域内にデータが表示されているが、別のウィンドウ又はポップアップウィンドウにデータを表示することもできる。表示されるデータは、ＲＩＳ、ＰＡＣＳ、ＬＩＳなどの様々な異なるデータソースに記憶されているデータとすることができる。この例では、提示される医療データが、駆出率、ＬＡＤ、壁厚、Ｃ反応性タンパク質及び症状を含む様々なタイプのデータ項目を含む。

上述したように、ＥＣＣＤシステムは、さらなるデータ分析を行うこともできる。例えば、テーブル８０２には駆出率データ８０６が４５％として示されている。この数字は、ＥＣＣＤシステムが、例えばＣＴスキャン画像系列データなどの画像系列データを分析することによって求めることができる。また、結果を正常範囲と比較することも、分析及び表示の一部とすることができる。このサンプルテーブルに含まれるデータは、画像、画像分析、臨床レポート及び症状から得られるデータを含む。これらのデータは、一般に全く異なるサーバシステム及びデータベース内に存在する。ＥＣＣＤシステムは、これらの関連データをこの患者及びこの身体部分である心臓に関連付け、あらゆる関連分析を行い、関連データをビューア内でユーザに文脈的に提示することができる。ビューアは、スタンドアロン型とすることも、或いはＥＨＲソフトウェアシステム又は臨床試験ソフトウェアシステムなどの別のソフトウェアシステムと統合することもできる。

この例では、各データ項目が、患者の病歴に基づいて及び／又は他の患者の同様のデータに照らして特定できるデータの傾向（例えば、増加、減少、潜在的な新しい症状、可能性のある異常な病状又は疾患など）などの、自動生成されたコメントを有するコメント欄を含む。各データ項目は、分析結果又は計算結果及び正常なデータ項目範囲を表示する結果欄と、データ項目のさらなる詳細情報にアクセスするためのリンク（例えば、「Ｄｘ／文脈」）とをさらに含む。

ＥＣＣＤシステムは、複数のデータ処理／分析ツールを組み込むことができ、以下ではその一部についてさらに説明する。他のタイプのデータ処理／分析は、データを正常範囲、病気範囲と比較すること、データを患者データベース内の他人のデータと比較すること、分析及び／又は比較で使用できるようにデータを組み合わせること、データを「グラウンドトゥルース」又はその他の基準と比較すること、データを経時的に分析すること、データの変化を分析すること、データを分析して最良の治療経路を決定すること、データを分析して、どのデータが失われていてどのデータを収集すべきかを判断すること、データを分析して病気リスクを特定すること、データを分析して考えられる治療副作用を特定すること、データを分析して治療効果を特定すること、及び複数のソースからの複数のフォーマットのデータを分析することのうちの１つ又は２つ以上を含む。

分析されるデータのタイプは、画像データ、（例えば、本文書の最後に列挙するツールによって実行されるような）処理済み画像データ、臨床検査データ、病理学データ、症状データ、医師／技術者のコメント／観察／口述、薬物療法データ、治療データ、結果データ、レポートデータ、患者の人口統計データ、患者の病歴データ、遺伝データ、ゲノムデータ、傾向データ、集約的患者データ、（データ駆動型又は専門家駆動型の）グラウンドトゥルースデータ、標準データ、調査データ及び臨床試験データのうちの１つ又は２つ以上を含むことができる。

ＥＣＣＤシステムは、様々なソースから様々なフォーマット及び／又は通信プロトコルで医療データを収集できるので、あらゆる数の方法でデータの分析を行うことができる。ＥＣＣＤシステムは、データ及び／又は分析を文脈的に生成することもでき、この文脈が、患者の文脈であるか、身体部分の文脈であるか、病気の文脈であるか、治療の文脈であるか、臨床又は調査研究の文脈であるか、それとも他のいずれかの文脈であるかは関係ない。このように、ＥＣＣＤシステムは、ユーザ介入を全く又はわずかしか伴わない本格的な知的システムである。

例えば、ＥＣＣＤシステムは、患者Ｘに関連する画像及びその他のデータにアクセスして分析することができる。ユーザは、患者ＸのＥＭＲの精査中に心臓に関連する情報を精査したいと望み、従って例えば図７Ａに示すように心臓をクリックすることができる。なお、ＥＣＣＤシステムは、心臓を選択又は有効化することによって文脈データをリアルタイムで収集及び／又は分析できるようになるが、データ収集及び／又は分析の一部又は全部を自動的に背景で実行することもできる。どのデータ収集及び／又は分析をリアルタイムで行い、どのデータ収集及び／又は分析を事前に行うかは、データの収集／処理／分析に必要なリソース、並びにデータの変更及び／又は更新頻度に依存する。

この例では、ＥＣＣＤシステムがＣＴスキャンデータを分析して、患者Ｘの心臓のＬＡＤ（左前下行枝）動脈の６５％に狭窄があると判断する。次に、ＥＣＣＤシステムは、このデータをビューア内に取りまとめる。ＥＣＣＤシステムは、心臓に関する臨床データ、並びに心臓に関連する症状データ及び医師のレポート／口述／注釈データにアクセスし、これらを提示することもできる。例えば、ＥＣＣＤシステムは、Ｃ反応性タンパク質レベルがわずかに増加したと判断することができる。ＥＣＣＤシステムは、以前の注釈／症状／レポートではなく最近の医師の注釈内の「左腕の痛み」という症状を検出し、「左腕の痛み」が新たな症状である旨を表示することができる。ＥＣＣＤシステムは、心臓画像データを分析して心臓の壁厚が増加していると判断するとともに、駆出率結果を標準と比較することによって心臓の駆出率が正常未満であると判断することもできる。患者Ｘは、２年前の腕の骨折に関するデータ（例えば、画像、症状、治療などのデータ）を有している場合もある。ＥＣＣＤシステムは、これらの全てのデータにアクセスすることができるが、これらの腕の骨折に関するデータは心臓との関連性が低いと判断することにより、ユーザが患者Ｘの心臓に関するデータを見ている時にこれらのデータは表示されない。

図８Ａには、ＥＣＣＤシステムが生成した情報をどのように表示できるかについての例を示している。複数のデータオブジェクトに下線が引かれており、従って「クリック可能」であり又はさらなる情報にリンクされている点に注意されたい。ユーザは、基礎データを詳しく見たいと望む場合も望まない場合もあるが、ユーザがデータの閲覧、精細化又は変更を望む場合には、このリンクによって行うことができる。この例では、コメント、結果、及びＤｘ（診断）／文脈のデータオブジェクトにリンクが与えられている。画像にリンクを与えることもできる。ユーザは、コメントの１つをクリックした場合、文脈的なリンク付きの単語を含む全てのコメントを表示する画面に導かれる。或いは、コメントがデータ分析の結果である場合には、ユーザがリンクをクリックした時にデータ及び／又はアルゴリズムを表示することができる。ユーザが結果リンクのうちの１つをクリックした場合、ＥＣＣＤシステムは、どのように結果が求められたかを示す画面を表示する。

例えば、ユーザがリンク付きの駆出率データ８０６をクリックした場合、ＥＣＣＤシステムは、図８Ｂに示すＧＵＩページと同様の対応する詳細な情報を表示する別のＧＵＩページを編纂してクライアント装置に表示させることができる。詳細ビュー／変更段階７１３における図８Ｂを参照すると、ブラウザ又はクライアントの右下領域の表示エリア／タブ／フレームに、いくつかの高度画像処理ビュー及びツールが示されている。この例では、ＥＣＣＤシステムが、心臓スキャン画像から心臓の駆出率を計算するために使用した方法及びデータを生成してクライアント装置に表示させる。表示領域７０２の右側は、画像処理ツールを含む。表示領域７０２の左側は、区分線及びチャートと共にスキャン画像を表示する。区分線とは、ＥＣＣＤシステムが分析した心臓組織の周囲及び心臓組織内の境界を表す線のことである。駆出率の例では、ＥＣＣＤシステムが、心室の体積を求めて心室の内面の輪郭を描く。心臓が拍動すると、この輪郭も経時的に追跡される。計算された駆出率は、ＥＣＣＤシステムによって計算され表示されたものである。この図では、左側の４つの画像領域のうちの３つに１つの画像しか示していないが、これらの画像は画像系列を表すことができ、従ってユーザは、１回又は２回以上のスキャンの数百枚、数千枚又はそれよりも多くの画像をスクロールすることができる。

ＥＣＣＤシステムは、図８Ｂに示すような詳細な画像データ及び分析情報を表示するだけでなく、（ログイン認証情報に応じて）ユーザによるデータの変更も可能にする。例えば、ユーザは、ＥＣＣＤシステムが表示した心臓周囲の輪郭を別様に描くべきであると考える場合、マウス又はその他のポインタを用いて輪郭を動かして、心臓の生体構造をより良く反映させることができる。このユーザインタラクションは、クライアント装置からＥＣＣＤサーバに送信される。ＥＣＣＤシステムは、ユーザインタラクションに基づいて、変更されたデータに基づいて駆出率（又は他のパラメータ）を再計算することができる。その後、この新たな分析を全体的な患者分析に使用することができる。

ユーザは、変更を行った場合、「保存」ボタンをクリックしてデータを保存して全体的な分析に組み込み、これを更新のためにＥＣＣＤサーバに返送することができる。或いは、ユーザは、「戻る」ボタンをクリックして、前の画面に戻って変更を無視することもできる。

図８Ｃには、図８Ａに示すものと同様のＧＵＩページを示しているが、この計算に使用したパラメータをユーザが変更した結果、駆出率が変更されている。この変更は、ユーザが図８Ｂに示す心室の輪郭を変更したことによって行われたものであり、この時点で段階７１２に戻っている。

ＥＣＣＤシステムは、データを分析して、考えられる患者の診断経路又は治療経路を提案することもできる。及び／又は、ＥＣＣＤシステムは、現在の患者に関するデータを他の患者の文脈又は時間の文脈で表示することもできる。図８Ｃには、「Ｄｘ／文脈」と表記された列が右側に示されている。ユーザがこれらのリンクのうちの１つをクリックした場合、ＥＣＣＤシステムは、例えば図８Ｄに示すような、表示されているデータのさらなる文脈情報を表示する。

この例では、ユーザが、ＬＡＤ動脈の６５％狭窄に関連する「Ｄｘ」リンク８１５をクリックした。図８Ｄに、リンク８１５とのユーザインタラクションに応答して生成される、ＥＣＣＤシステムによって表示される画面例を示す。この例では、ユーザがリンク８１５をクリック又は有効化すると、選択されたデータ項目ＬＡＤに関する詳細情報を求める要求がＥＣＣＤサーバに送信される。この要求は、選択されたデータ項目ＬＡＤを識別するデータ項目識別子を含むことができる。これに応答して、ＥＣＣＤサーバは、選択されたデータ項目ＬＡＤに関連するあらゆる情報を検索して関連情報の分析を行うことができる。１つの実施形態では、ＥＣＣＤサーバが、分析に基づいて、関連する患者の異常な病状又は疾患が起こり得る可能性を特定する。この特定は、他の患者の医療データに照らして行うことができる。また、他の患者の医療データに照らして、患者の医療データを示すグラフを生成することもできる。

この例では、図８Ｄの段階７１４に示すように、グラフ８２０が、何らかのレベルの狭窄がある他の患者からのデータの文脈でこの患者に関するデータを表示する。この例では、１つのタイプのインジケータ８２５（例えば、円）を用いてこの患者のデータ点が示されており、インジケータ８３０（例えば、中実ドット）などの他のタイプのインジケータによって示される他の患者からのデータに基づいて、６５％のＬＡＤ狭窄に基づくこの患者の心臓病リスクの増加率が３３％であることを示している。このグラフでは、左側の軸に狭窄率を示しているが、狭窄の位置、狭窄の経過年数、狭窄の成長速度などを含む他の因子を組み込むこともできる。症状、患者の年齢、体重、病歴などを含む他のデータを検討することもできる。図示のように、ほとんど全てのデータを他のいずれかのデータと共に分析して、考えられる診断及び／又は治療を決定することができる。ＥＣＣＤシステムは、様々なデータベースから同様の事例を検索し、ユーザが見ているものと同様の事例をユーザに表示することもできる。ユーザ及び／又はＥＣＣＤシステムは、類似性及び差異を分析することができる。ＥＣＣＤシステムが差異及び類似性を分析した場合、これらをビューア内で何らかの方法で識別又は強調表示することができる。

図９は、本発明の別の実施形態による、進化型文脈的臨床データ技術を用いて医療データを処理する過程を示すフロー図である。プロセス９００は、ソフトウェア、ハードウェア又はこれらの組み合わせを含むことができる処理ロジックによって実行することができる。例えば、プロセス９００は、医療情報サーバ１０１によって実行することができる。図９を参照すると、ブロック９０１において、処理ロジックは、要求に応答して異なるデータソースから取得された患者の医療データの分析を行う。ブロック９０２において、分析結果がネットワークを介してユーザのクライアント装置に送信され表示される。分析結果は、１又は２以上のコンテンツ又はデータ項目を含む。ブロック９０３において、処理ロジックは、第１のデータ項目を選択したユーザインタラクションに応答して、分析に基づいて患者に起こり得る異常な病状又は疾患の尤度又は可能性を特定する。ブロック９０４において、処理ロジックは、他の患者の医療データに基づいて他の患者の異常な病状又は疾患の尤度又は可能性を特定する。ブロック９０５において、処理ロジックは、他の患者の異常な病状又は疾患の尤度に照らして患者の尤度のグラフィック表現を生成し、ユーザのクライアント装置に送信する。

図１０Ａ及び図１０Ｂは、本発明のいくつかの実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。例えば、図１０Ａ及び１０Ｂは、図７Ａ〜図７Ｂとのユーザインタラクションに応答して生成され表示されるものとすることができる。図１０Ａを参照すると、この図には、ＥＣＣＤシステムによって表示される別の考えられるレポート画面を示している。この画面には、図８Ａ及び図８Ｃと同様のデータを示しているが、行動指針の推奨としての考えられる診断、治療及び次のステップに関するデータも表示される。ボックス１００２は、ＥＣＣＤシステムが、基礎データ及び分析に基づいてこの患者の心臓病リスクが３０％高まっていると判断した旨の診断をユーザに示す。この診断は、一連のルールとして構成できるいくつかのベンチマーク及び／又は患者の病歴及び／又は他の患者のデータに照らした患者のデータの分析に基づいて自動的に行うことができる。

ボックス１００４は、考えられる次のステップ、この例では、ＥＣＣＤシステムが経過観察の予約を立てるように既に患者に電子メールを送った旨を表示する。ＥＣＣＤシステムは、動作を自動的に実行することができ、この例では、患者の医療データの分析又は診断に基づいて、一連のルールに従って患者に通知を送信する。他の次のステップとしては、臨床検査の取得、専門家との相談などを挙げることができる。ボックス１００６は、推奨される治療、この例では血管形成術を表示する。ここでは「血管形成術」という単語にリンクが付いており、これをクリックすると、ユーザはデータの詳細及びこの推奨の基本となる分析を示す別の画面に導かれる。

この実施形態では、ＥＣＣＤシステムが、ボックス１００２に示される分析に基づいて異常な病状又は疾患の尤度を特定することを含め、患者の医療データの分析を行う。また、ＥＣＣＤシステムは、予め構成できる一連のルールに従って自動的に動作を実行することもできる。例えば、ユーザは、特定の医療データが閾値を上回った場合又は下回った場合、この例では患者である予め設定された受信者に自動的に通知が送られるように構成することができる。さらに、ＥＣＣＤシステムは、患者の医療データの分析に基づいて自動的に推奨も決定する。全てのこれらの情報を取りまとめ、１又は２以上の医療情報ビューに統合し、ＥＣＣＤシステムからクライアント装置に送信して図１０Ａに示すように表示することができる。

図１０Ａには、ユーザが患者に直ぐに連絡できるボタン１００８も示している。このボタンは、診断及び／又は治療が本質的に時間に左右される場合に有用となり得る。この例では、ＥＣＣＤシステムが、複数タイプのデータを組み込むことによって心臓病のリスクが３０％高まるという診断を下している。例えば、この３０％とは、ここに表示されているデータの一部又は全部、駆出率、狭窄の割合及び位置、壁厚、関連する臨床検査結果、症状などを組み込むことによって特定できたものである。診断は、非常に複雑なアルゴリズムを用いて下すことができる。ユーザがここに示されている診断をクリックした場合、ＥＣＣＤシステムは、データに関するさらなる詳細及び／又は診断の背後にあるアルゴリズムを表示する。図１０Ｂに、例えば図１０Ａのリンク１０１０とのユーザインタラクションに応答して、心臓病のリスクが３０％高まるという診断をＥＣＣＤシステムがどのようにして決定できたかに関する詳細を示す。この例ではグラフが用いられている。アルゴリズムリンク１０１２をクリックすると、アルゴリズムの背後にある詳細がユーザに表示される。

図１１は、本発明の別の実施形態による、進化型文脈的臨床データ技術を用いて医療データを処理する過程を示すフロー図である。プロセス１１００は、ソフトウェア、ハードウェア又はこれらの組み合わせを含むことができる処理ロジックによって実行することができる。例えば、プロセス１１００は、医療情報サーバ１０１によって実行することができる。図１１を参照すると、ブロック１１０１において、処理ロジックは、異なる情報プロバイダ又はサーバによって提供される異なるデータソースから取得できる患者の医療データの分析を行う。この分析は、臨床レポート、病歴などの患者の他のデータ、及び他の患者の医療データに基づいて行われる。この分析に基づき、ブロック１１０２において、処理ロジックは、一連のルールに基づいて所定の動作（例えば、予め設定した受信者に通知を送信すること）を自動的に実行する。例えば、特定の医療データ項目又はデータタイプについては、ユーザが、この特定のデータ項目が所定の閾値又は周知のベンチマークを上回った場合又は下回った場合に所定の行動を取るべきである旨の一連のルールを構成することができる。ブロック１１０３において、処理ロジックは、分析に基づいて異常な病状又は疾患が患者に起こり得る尤度を特定する。この場合も、このような特定は、患者の他の医療データ及び／又は病歴、並びに他の患者の同様の医療データに基づくことができる。ブロック１１０４において、処理ロジックは、分析に基づいて、行うべき第２の行動を推奨として決定する。ブロック１１０５において、クライアント装置に分析結果が送信されて表示される。この分析結果は、第１の行動が既に行われた旨を示す情報、異常な病状又は疾患の尤度、及び推奨を含む。

図１２Ａ〜図１２Ｄは、本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。例えば図１２Ａ〜図１２Ｄは、図７Ａ〜図７Ｂとのユーザインタラクションに応答して生成され表示されるものとすることができる。図１２Ａでは、図７Ａから肺を選択したユーザインタラクションに応答してＧＵＩページを生成及び表示することができる。この例では、ユーザが、図７Ａに示すＧＵＩページから例えば肺を選択すると、クライアントアプリケーション（例えば、ウェブブラウザ）が、クライアント装置からネットワークを介してＥＣＣＤサーバに要求を送信する。この要求は、肺を識別する身体部分ＩＤと、対象の患者を識別する患者ＩＤとを含むことができる。この要求は、要求を開始したユーザを識別するユーザＩＤをさらに含むことができる。ＥＣＣＤサーバは、このような情報により、（例えば、ユーザのアクセス制御リスト又はＡＣＬに基づいて）ユーザがこの特定の患者の患者情報にアクセスできるかどうかを判定し、できる場合には、ユーザが患者のどのような種類の医療データにアクセスできるかを特定することができる。

ＥＣＣＤサーバは、患者に関連する肺のユーザ選択に応答して、患者ＩＤによって識別された患者の肺を識別する身体部分ＩＤによって識別された患者の肺に関連するあらゆる医療データを検索する。この例では、ウェブブラウザのフレーム、タブ、又は領域内にデータが表示されているが、別のウィンドウ又はポップアップウィンドウにデータを表示することもできる。表示されるデータは、ＲＩＳ、ＰＡＣＳ、ＬＩＳなどの様々な異なるデータソースに記憶されているデータとすることができ、ＥＣＣＤシステムは、データのさらなる分析を行うこともできる。例えば、テーブルには肺小結節の直径が１０ｍｍとして表示されている。この数字は、ＥＣＣＤシステムが、例えばＣＴスキャン画像系列データなどの画像系列データを分析することによって求めることができる。また、結果を正常範囲と比較することも、分析及び表示の一部とすることができる。

ＥＣＣＤシステムがこのサンプルテーブル内に表示するデータは、画像、画像分析、臨床レポート及び症状から得られるデータを含む。これらのデータは、一般に全く異なるサーバシステム及びデータベース内に存在する。ＥＣＣＤシステムは、これらの関連データをこの患者及びこの身体部分である肺に関連付け、あらゆる関連分析を行い、関連データをビューア内でユーザに文脈的に提示することができる。ビューアは、スタンドアロン型とすることも、或いはＥＨＲソフトウェアシステム又は臨床試験ソフトウェアシステムなどの別のソフトウェアシステムと統合することもできる。

この例では、ＥＣＣＤシステムがＣＴスキャンデータを分析して、患者Ｘが直径１０ｍｍの新たな肺小結節を有していると判断する。ＥＣＣＤシステムは、ＣＴスキャンデータを経時的に分析することによって小結節が新たなものであると知ることができる。システムは、癌に関する臨床データ、並びに肺及び／又は癌に関する症状データ及び医師レポート／口述／注釈データにアクセスすることもできる。例えば、ＥＣＣＤシステムは、癌に関するＣＡ−１２５バイオマーカが陽性であると判断することができる。ＥＣＣＤシステムは、以前の注釈／症状／レポートではなく最近の医師の注釈内の「咳」という症状を検出し、「咳」が新たな症状である旨を表示することもできる。ＥＣＣＤシステムは、患者履歴／人口統計データを経時的に分析して、最近この患者の体重が減少していると判断することもできる。

ユーザがリンク付きの小結節直径データ１２０１、１０ｍｍをクリックした場合、ＥＣＣＤシステムは図１２Ｂと同様のページを表示することができる。図１２Ｂには、心臓の例である図８Ｂと同様に、肺の高度画像処理結果及びツールを示している。ここでは、ユーザが、１０ｍｍという結果がどのように決定されたかをチェックし、以前のＣＴスキャンを見てどのように比較したかを調べることができる。ユーザは、適切なアクセスレベルを有している場合、分析に変更を加えることもできる。図１２Ｃは、図１２Ｄに示す肺小結節のＤｘ／文脈を精査するためにユーザがクリックできる場所を示している点を除き、図１２Ａと全く同じ図である。

図１２Ｄは、ＥＣＣＤシステムがこの患者の肺小結節データの文脈を表示している点で図８Ｄと同様の図である。ここでは、肺小結節を有している他の複数の患者の文脈で患者Ｘのデータ点が表示されている。ＥＣＣＤシステムは、このデータプールに基づいて、１０ｍｍの肺小結節によって肺癌のリスクが１０％増すと判断している。この分析は、小結節の直径しか考慮していないが、小結節の密度、小結節の形、小結節の位置、小結節の体積、小結節の成長速度、症状、臨床検査などを含む他の因子を考慮することもできる。ＥＣＣＤシステムは、データに基づいて、５年、１０年などの特定の時間枠にわたる患者の生存可能性を特定することもできる。

図１３Ａ〜図１３Ｂは、本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。例えば、図１３Ａ〜図１３Ｂは、図７Ａ〜図７Ｂとのユーザインタラクションに応答して生成され表示されるものとすることができる。図１３Ａを参照すると、この図には、診断、次のステップ及び推奨される治療を含む、ＥＣＣＤシステムの分析結果を示している。図１３Ｂには、アルゴリズムが複数のデータ点を組み込むことによって決定された診断に関するデータを示している。例えば、バイオマーカテスト結果、症状、小結節の成長速度及びサイズなどである。

図１４Ａ〜図１４Ｃは、本発明の他のいくつか実施形態による、医療情報を提供するグラフィカルユーザインターフェイスを示すスクリーンショットである。図１４Ａを参照すると、この図には、異なるタイプの医療ソフトウェアと組み合わせたＥＣＣＤシステムの例を示している。この例では、ＥＣＣＤシステムが、ＥＨＲソフトウェアシステムではなく、表示領域７０３に表示される処理段階１４１１〜１４１４を含む臨床試験ソフトウェアシステムに統合されている。

臨床試験ラベル１４０１は、ユーザがどの臨床試験を見ているかを示し、この例では「臨床試験Ｘ」である。表示領域７０３のワークフロー又はステップタイムラインは、ユーザがプロセス内のどこにいるかを示し、この例では「レポート表示」ステップ１４１２である。ユーザは、複数のレポートを利用することができる。この例では、ユーザが「結果」レポートをクリックして、段階１４１２から図１４Ｂに示すような段階１４１３に移行する。図１４Ｂには、結果を表示する画面例を示す。グラフ１４２１及び１４２２は、プラセボプロトコルと試験薬治療プロトコルの両方を用いた経時的な肺小結節サイズのグラフを示すものであり、ＥＣＣＤシステムは、画像データを含むデータの分析に基づいてこれらの両方を表示する。ボックス１４２３は、現在の薬の結果とプラセボの結果とを対比した高水準表示である。ＥＣＣＤシステムは、この要約を２つのグラフのデータの分析に基づいて表示している。ＥＣＣＤシステムは、副作用、他の薬物療法が結果に与える影響、年齢、性別などによる結果の分析、投薬量、及び／又は他のいずれかの関連データを含む他のタイプのデータを表示することもできる。ビュー領域は、ウェブブラウザ内のフレーム及び／又はタブに存在することも、或いは別個のウィンドウ又は別個のモニタ内に存在することもできる。ビュー領域は、互いに重なり合うことも、或いは統合することもできる。ビュー領域は、別の１つのデータ内に存在して、データに関するさらに詳細な情報にリンクすることもできる。例えば、データ点１４３１をクリックすると、図１４Ｃに示すようなデータ点１４３１の背後にある詳細な情報及び分析を見ることができる。図１４Ｃには、ユーザが図１４Ｂのデータ点１４３１をクリックした場合にＥＣＣＤシステムが表示する考えられる画面を示す。図１４Ｃには、詳細な画像スキャンデータ及び分析を示している。ここではデータを変更することもできるが、通常、臨床試験の例では、データを変更するためのアクセスレベルが、ＥＨＲの文脈で表示されるデータの例よりも制限される。

ＥＣＣＤシステムは、学習することもできる。この学習は、ユーザ及び／又はデータ全体にわたって行うことも、或いは特定のサブセット又はデータ内、又は１人のユーザ又は１つのユーザタイプ内で行うこともできる。例えば、ＥＣＣＤシステムは、ユーザが膣鏡診の例を見ている時には一般に臨床データをクリックしないというユーザデータを収集し、ユーザが将来的に大腸内視鏡検診の例を見る時には、臨床データに低表示優先度を設定することができる。別の例では、ＥＣＣＤシステムが、特定のユーザが画像データよりも長い期間にわたってＥＫＧデータを見るというデータを収集し、このユーザについてＥＫＧデータに高表示優先度を設定することができる。

再び図２を参照すると、１つの実施形態では、医用画像処理システム２１０が、クライアントにネットワークを介して医用画像処理サービスを提供する画像処理エンジンを含む。画像処理エンジンは、グラフィクス処理ユニット（ＧＰＵ）などの専用グラフィクス又は画像処理ハードウェアを用いて実装することができる。医用画像処理システム２１０は、ＪＰＥＧ、ＴＩＦＦ、ビデオ、ＥＫＧ、実験画像、レポート、テキスト、ＰＤＦ、音声及びその他のファイルを含む、医用におけるデジタル画像及び通信（ＤＩＣＯＭ）と互換性のあるデータ又は他の画像データなどの医療データを記憶する画像ストア（図示せず）も含み、又はこのような画像ストアに関連する。画像ストアは、暗号化機能を組み込んで、暗号化形式による医療データの記憶及び送信を行うこともできる。画像ストアは、複数のデータベースを含むことができ、例えばＯｒａｃｌｅ（商標）データベース又はＭｉｃｒｏｓｏｆｔ（登録商標）ＳＱＬサーバなどのリレーショナルデータベース管理システム（ＲＤＢＭＳ）を用いて実装することができる。

１つの実施形態では、医療情報サーバ１０１が、クライアント装置１０２によるリソース（例えば、画像処理ツール）及び／又は画像ストアに記憶されている医療データへのアクセスを制御するアクセス制御システム（図示せず）を含む。クライアント１０２は、そのアクセス権に依存して、リソース及び／又は画像ストアに記憶されている医療データの特定の部分又はタイプにアクセスできることも、又はできないこともある。これらのアクセス権は、一連の役割ベースのルール又はポリシーに基づいて決定又は構成することができる。例えば、クライアント１０２は、医療情報サーバ１０１によって提供されるツールの一部へのアクセスしか許可しない特定の役割を有するように構成することができる。他の例では、クライアントを、何らかの患者情報へのアクセスを制限する特定の役割を有するように構成することができる。例えば、クライアント１０２の特定のユーザ（例えば、医師、医学生）は、画像ストア１０８に記憶されている異なる医療情報、又は医療情報サーバ１０１によって提供される異なる画像レンダリングリソースにアクセスするための異なるアクセス権を有することができる。

クライアント装置１０２は、統合医療ソフトウェアを含むことができるクライアントとすることができる。１つの実施形態では、この統合ソフトウェアが、（単複の）画像及び／又は画像処理機能を、本明細書ではまとめて医療記録及び／又は臨床ソフトウェア（ＭＲＣＳ）と呼ぶ医療記録ソフトウェア（ＭＲＳ）及び／又は臨床試験ソフトウェア（ＣＴＳ）と統合する。医療記録ソフトウェア（ＭＲＳ）は、個々の患者の医療記録に焦点を絞る患者中心ソフトウェアである。ここで言う患者中心とは、ソフトウェアの主な目的が個々の患者に関するデータの記録及び閲覧であることを意味する。この種のソフトウェアは、電子医療記録（ＥＭＲ）ソフトウェア、電子健康記録（ＥＨＲ）ソフトウェア、個人健康記録（ＰＨＲ）ソフトウェアという名前及びその他の名前で呼ぶことができる。通常、ＭＲＳによって維持される情報としては、患者ＩＤ、人口動態、年齢、体重、身長、血圧（ＢＰ）などの情報、臨床順及び結果、検査順及び結果、病歴、予約履歴、スケジュール中の予約、検査履歴、処方／投薬、症状／診断、及び保険／返済情報が挙げられる。

臨床試験ソフトウェア（ＣＴＳ）は、遡及的臨床研究及び予想的臨床研究の両方のためのソフトウェアを含む。この種のソフトウェアは、臨床試験管理システムと呼ぶことができる。ＣＴＳは、研究のためのソフトウェアを含むこともできる。ＣＴＳは試験中心であり、これは、ソフトウェアの主な目的が複数の患者又は参加者の集約データの収集及び閲覧であることを意味する。データは、個々の患者／参加者レベルで収集されるが、通常、このデータは「盲目的に」閲覧される。このことは、一般にデータの閲覧者及び／又は分析者が個々の患者／参加者のアイデンティティを知らないことを意味する。しかしながら、必要であれば、個々の患者／参加者レベルでデータを閲覧することもできる。このことは、画像を伴う場合に特に重要である。通常、ＣＴＳは、患者ＩＤ、併用薬、有害事象、ランダム化情報、データ収集、納得診療、集約データ、及び研究状況を含む。

１つの実施形態では、クライアント１０２Ａ内で実行される統合医療ソフトウェアとして動作するクライアントアプリケーション２０７が、例えば患者の医療記録及び／又は試験記録の一部とすることができる患者の医学的治療履歴を含む患者の医療情報を表示する。このような記録は、ユーザ要求、及び／又はＥＣＣＤエンジン１０３による推奨に応答して、医療情報サーバ１０１からダウンロードすることができる。統合医療ソフトウェアがＭＲＳを組み込む場合、一般に患者の完全なアイデンティティが医療情報の一部として表示される。一方で、統合ＣＴＳの場合には、通常、患者は上述したように匿名であり、通常、患者のアイデンティティは、表示される医療情報の一部として公開されない。

１つの実施形態では、（単複の）画像及び／又は画像処理機能をＭＲＣＳと統合することができる。統合は、ＭＲＣＳと同じウィンドウ内に現れる（単複の）画像及び／又は画像処理ツールの形を取ることができる。統合は、ＭＲＣＳウィンドウとは別のウィンドウ内で開かれる（単複の）画像及び／又は画像処理ツールを含むウィンドウの形を取ることもできる。しかしながら、いずれの形の統合であっても、患者の医療情報及び（単複の）画像は、統合ソフトウェアのユーザに別のソフトウェアプログラムを介して別個に画像を取得するように要求することなく統合医療ソフトウェア内に表示される。

１つの実施形態では、医用画像処理システム２１０が、高度画像処理システム及び自動画像処理システム（例えば、画像処理ウィザード）を含む。高度画像処理システムを利用する場合、ユーザが特定の画像を処理するために１つ又は２つ以上の画像処理ツールを指定できるように、一連の画像処理ツールを表す一連のグラフィック表現を高度画像処理グラフィカルユーザインターフェイス内に提示することができる。自動画像処理システムを利用する場合、自動画像処理システムの基本処理ロジックは、例えばどの画像処理ツールを利用すべきかについてのユーザ介入又はユーザ知識を伴わずに、画像を処理するための１又は２以上の画像処理ツールを自動的に決定して選択するように構成される。クライアント上で実行される統合医療ソフトウェアのユーザには、遠隔画像処理サーバによって提供される画像処理ツールのためのグラフィック表現（例えば、アイコン）が表示される。このような実施形態では、ユーザによる起動時に遠隔画像処理システム２１０が画像を操作できるようにするアイコンの組又は他の何らかのグラフィック表現として、統合医療ソフトウェア内に利用可能な画像処理ツールが表示される。１つの実施形態では、画像処理ソフトウェアがＭＲＣＳプログラムと統合されて、やはり「文脈的に」開く。「文脈的に」とは、画像処理ソフトウェアが開いて現在のユーザ及び／又は患者及び／又は苦痛に適した画像及び／又はツールを表示することを意味する。特定のユーザに対する画像ツールの利用可能性は、その特定のユーザのアクセス権（例えば、医師と医学生）に依存する。或いは、画像ツールの利用可能性は、ＤＩＣＯＭタグなどの特定のタグによって識別できる患者の特定の身体部分に基づいて決定することもできる。

例えば、ある医師は、自分の患者の心臓血管画像については、血管中心線ツールを利用できる状態で３Ｄビューで開く一方で、自分の患者の腹部画像については、フライスルーツール又は仮想大腸内視鏡ツールを利用できる状態で冠状ビューで開くことを好む場合がある。この医師は、他のビュー及びツールが視界から隠れることを好む場合もある。別の例では、別の医師が、自身がこの患者に使用した最新のビュー及びツールを表示して自分の患者の画像が開くことを好む場合もある。別の例では、心臓血管事例のデフォルトビューを特定のビュー及びツールが表示されるように設定することもできるが、デフォルトビュー及びツールよりも自身の基本設定が優先するようにユーザがデフォルトを変更することもできる。

上記の全ての例では、その時に評価する患者に関する画像のみが見えることが理想的である。また、ユーザ／医師は、患者に関する画像を探して発見する必要がなく、画像は、例えば対応する患者ＩＤに基づいて自動的に正しい患者に関連付けられる。これを行うには、患者のアイデンティティを患者の画像に関連付ける必要がある。この関連付けは、ＩＤ番号などの共通識別子などのタグ、画像の１つ又は２つ以上に関連するメタデータ、マイニング患者データ、身体部分分析、又はその他の方法を用いて行うことができる。また、適切なツールを表示して不適切なツールを隠す必要もある。タグについては以下でさらに詳細に説明する。

例えば、画像又は画像系列を分析し、生体構造に基づいて、その画像が頭部であるか、腹部であるか、それとも他の身体部分であるかを判断することができる。頭蓋骨は特徴的形状を有し、他の生体構造部分も同様である。参照画像の一覧を用いて、特定の身体部分の識別に役立てることもできる。この分析に基づいて、適切なビュー及び／又はツールをユーザに見えるようにし、不適切なビュー及び／又はツールを隠すことができる。例えば、画像系列が頭部／頭蓋骨のものである場合には、画像系列を軸方向ビューなどの特定のビューで表示し、脳に関連するツールを現れるようにすることができる。また、ＭＲＣＳ記録に「腫瘍」又は「発作」などの特定のキーワードが見つかった場合、腫瘍の検出又は脳潅流の評価を行うツールなどの特定のツールを表示することもできる。形状、疾患、タグなどに基づいて画像内の生体構造から患者ＩＤを特定することもできる。例えば、口腔領域の画像を歯科記録と照合して、医用画像から患者を識別することができる。或いは、ＣＴスキャナのテーブル上又はその付近、或いは患者自身に設定された患者ＩＤ番号を含むタグなどの識別タグを医用画像に含めることもできる。別の実施形態では、ソフトウェアのユーザが、画像処理ソフトウェアが文脈的にどのように提示されるようにするかをカスタマイズすることができる。例えば、心臓内科医である医師Ｙは、３Ｄモデルビューで画像を開き、心臓ツールＡ及び心臓ツールＢが見えるようにすることを好む場合がある。この例では、他のビュー（例えば、軸方向ビュー、矢状ビュー及び冠状ビュー）を隠すことができ、他のツール（例えば、大腸又は脳に関するツール）も隠される。

１つの実施形態によれば、高度画像処理システムでは、ネットワークを介して処理リソース（例えば、画像処理エンジン）を利用する、画像処理のためのツールアイコンによって表される画像ツールに異なるタイプのユーザがアクセスすることができる。自動画像処理システムでは、異なるタイプのユーザが、画像ツールを直接取り扱う必要なくツールの機能にアクセスすることができる。自動画像処理システムは、医用画像処理リソース（例えば、画像処理エンジン）の使用を単純化又は自動化するように、既存の又は新規の高度医用画像処理ソフトウェアシステム（例えば、高度画像処理システム）上に階層化又は統合し、ソフトウェア、ハードウェア又はこれらの組み合わせで実装することができる。

１つの実施形態によれば、高度画像処理システム及び自動画像処理システムは、いずれも一連のアプリケーションプログラミングインターフェイス（ＡＰＩ）又は通信プロトコルを介して基本となる画像処理エンジンの画像処理機能（例えば、ライブラリ、ルーチン、ツールなど）にアクセスすることができる。高度画像処理システムを利用する場合、１つの実施形態によれば、ユーザが選択した特定の画像を処理するための詳細な画像処理パラメータをユーザが指定できるようにする高度グラフィカルユーザインターフェイスを提示することができる。高度画像処理システムの基本処理ロジックは、高度グラフィカルユーザインターフェイスから受け取られたユーザ入力を処理し、このユーザ入力に基づいて生成された一連の画像処理パラメータを用いて１又は２以上の画像処理コマンドを作成する。次に、高度画像処理システムの処理ロジックは、例えばＡＰＩを介してバックエンド画像処理エンジンにコマンドを送信して画像を処理する。

自動画像処理システムを利用する場合、１つの実施形態によれば、ユーザのクライアント装置に簡易グラフィカルユーザインターフェイス（例えば、ウィザード）を提示して、ユーザに詳細な動作画像処理パラメータを指定するように要求することなく、一連の単純なステップ又は対話式の質問を通じて進むようにユーザを誘導する。基本処理ロジックは、簡易グラフィカルユーザインターフェイスとのユーザインタラクションに基づいて詳細な画像処理パラメータを自動的に決定するように構成される。一連の画像処理コマンドが生成され、画像処理のためのバックエンド画像処理エンジンに送信される。或いは、自動画像処理システムの基本処理ロジックがパラメータを決定し、高度画像処理システムがその対応するグラフィカルユーザインターフェイスを介してユーザから受け取るのと同様に、これらのパラメータを高度画像処理システムに渡す。高度画像処理システムは、自動画像処理システムの代わりに基本画像処理エンジンとさらに通信する。

自動画像処理システムは、画像処理ウィザードの形で実装することができる。このウィザードは、高度画像処理プロセスを通じてユーザを誘導する。このウィザードは、ユーザが高度画像処理ツールの操作方法の詳細を知らなくても済むように、例えば設定、前提及び一連のルールを用いてできるだけ多くのステップを自動化して画像データを処理する。このウィザードは、ユーザに、自動的に又は別様に生じた結果を確認又は変更する機会も与える。このウィザードは、直感的ユーザインターフェイスと、画像処理過程を通じてユーザを導く支援となる答えやすい質問とを提示することで構成することができる。

１つの実施形態によれば、自動画像処理システムは、ユーザフレンドリーな対話型グラフィカルユーザインターフェイスを提供する。ユーザは、この自動画像処理システムにより、画像を処理するための特定のステップ及び／又は画像処理パラメータ又はツールを完全に理解する必要なく、理解可能な一連の処理段階に基づいて基本処理リソースにアクセスし、画像に対していくつかの主な又は共通の又は一般的な画像処理動作を実行することができる。自動画像処理システムは、ユーザフレンドリーなグラフィカルユーザインターフェイス（ＧＵＩ）を介して一連の質問を通じてユーザと相互作用し、ユーザからの回答の一部としてのユーザ入力を受け取ってユーザの意図を判別することができる。自動画像処理システムとのユーザインタラクションに基づいて１又は２以上の画像処理動作を決定し、自動画像処理システムを介してユーザに推奨することができる。ユーザは、画像処理のための推奨される画像処理動作のうちの１つ又は２つ以上を選択することができ、或いは自動画像処理システムによって画像処理動作を自動的に実行することもできる。ユーザがこれらの画像処理指標のうちの１つ又は２つ以上を選択したことに基づいて、選択された画像処理動作に関連する１又は２以上の画像処理パラメータが、ユーザ介入を伴わずに、ユーザに同じパラメータを提供させることなく自動的に決定される。

１つの実施形態によれば、自動画像処理システムが受け取った画像処理パラメータに基づいて１又は２以上の画像処理コマンドが生成され、画像処理のために自動画像処理システムから画像処理エンジンに送信される。画像処理エンジンは、これらの画像処理コマンドに応答して、画像処理パラメータに基づいて画像を処理し、新たな又は更新された画像を生成する。この新たな画像は、元々の画像に関連する同じ医療データの異なるビューを表すことができる。その後、この新たな画像が画像処理エンジンから再び自動画像処理システムに送信され、自動画像処理システムがこの新たな画像をさらにクライアント装置に送信してユーザに提示されるようになる。自動画像処理システムは、ユーザが新たな画像に満足したかどうかについてクライアントがユーザに促すようにもする。ユーザが新たな画像に満足していない場合、自動画像処理システムは、新たな画像に関するさらなるユーザ入力を求めてユーザと相互作用し、画像処理パラメータをさらに調整して画像処理動作を繰り返し実行することができる。この結果、ユーザは、高度画像処理システムの利用方法を完全に理解する必要はないが、高度ユーザには高度画像処理システムを利用可能にすることもできる。

１つの実施形態によれば、医療データセンタ、画像取り込み装置（図示せず）、或いはＣＤ又はコンピュータデスクトップなどの別の画像ソースから画像データが受け取られたことに応答して、画像前処理システム２１０を、画像データの特定の前処理を自動的に実行して前処理済みの画像データを医療データストア（図示せず）に記憶するように構成することができる。例えば、画像前処理システム２０４は、ＰＡＣＳから又は医用画像取り込み装置から直接画像データを受け取ると、骨の除去、中心線の抽出、球面の発見、位置合わせ、パラメータマップの計算、再フォーマット、時間−密度分析、構造のセグメント化及び自動３Ｄ動作、並びにその他の動作などの、一部を後程列挙するいくつかの動作を自動的に実行することができる。

画像前処理システム２１０は、ワークフロー管理システムをさらに含む。ワークフロー管理システムは、別個のサーバとすることも、或いは画像処理システム２１０に統合することもできる。ワークフロー管理システムは、本発明のいくつかの実施形態による複数の機能を実行する。例えば、ワークフロー管理システムは、医用画像取り込み装置から受け取った医用画像データを取得して記憶する際にデータサーバ機能を実行する。ワークフロー管理システムは、医用画像データを処理して２Ｄ又は３Ｄ医用画像ビューを生成する際にグラフィックエンジンの役割を果たし、又は画像処理システム２１０を呼び出すこともできる。１つの実施形態では、ワークフロー管理システムが、グラフィックスエンジンを有する画像処理システム２１０を呼び出して２Ｄ及び３Ｄ画像の生成を実行する。クライアントが特定の医用画像ビューを要求すると、ワークフロー管理システムは、医療データストアに記憶されている医用画像データを検索し、この医用画像データから２Ｄ又は３Ｄ医用画像ビューをレンダリングする。クライアントには、医用画像ビューの最終結果が送信される。

１つの実施形態では、ワークフロー管理システムが、ワークフローテンプレートの作成、更新及び削除を管理する。ワークフロー管理システムは、医用画像データにワークフローテンプレートを適用するためのユーザ要求を受け取った場合、ワークフローシーンの作成も実行する。ワークフローは、診断用の医用画像ビューを生成する過程における反復的活動パターンを取り込むように定められる。ワークフローは、これらの活動を、各活動の実行順に従ってプロセスフローに編成する。ワークフローにおける各活動は、その機能の明確な定義、活動を行う上で必要なリソース、並びに受け取った入力及び活動によって生成された出力を有する。ワークフローにおける各活動は、ワークフロー段階又はワークフロー要素と呼ばれる。ワークフローのワークフロー段階は、要件及び責任が明確に定められた状態で、ワークフローに定められた目標を達成する過程において１つの特定のタスクを実行するように設計される。多くの医用画像研究では、通常、診断用の医用画像ビューを生成する活動パターンが反復的であって明確に定められている。従って、ワークフローを利用して実際の医用画像処理実務のモデル化及び文書化を行い、定められたワークフローの手続きルールの下で画像処理が正しく行われるのを確実にすることが有利である。ワークフロー段階の結果は、後で再検討又は使用できるように保存することができる。

１つの実施形態では、特定の医用画像研究のワークフローが、ワークフローテンプレートによってモデル化される。ワークフローテンプレートは、論理的ワークフローを形成する予め定められた一連のワークフロー段階を含むテンプレートである。活動の処理順は、予め定められた一連のワークフロー段階に設定される順序によってモデル化される。１つの実施形態では、ワークフローテンプレート内のワークフロー段階が、高次段階の前に低次段階が行われるように順番に並べられる。別の実施形態では、ワークフロー段階間で従属関係が維持される。このような構成下では、あるワークフロー段階の従属先のワークフロー段階が最初に実行されるまでそのワークフロー段階を実行することはできない。さらなる実施形態では、高度ワークフロー管理により、複数のワークフロー段階に従属する１つのワークフロー段階、又は１つのワークフロー段階に従属する複数のワークフロー段階などが可能になる。

画像処理動作は、医用画像装置によって収集された医用画像データを入力として受け取り、この医用画像データを処理し、メタデータを出力として生成する。メタデータ要素としても知られているメタデータは、医用画像データの記述、処理及び／又は管理のためのパラメータ及び／又は命令を広く意味する。例えば、ワークフロー段階の画像処理動作によって生成されるメタデータは、診断用の医用画像ビューを生成するために医用画像データに適用できる画像処理パラメータを含む。さらに、医用画像ビューの様々な自動及び手動操作をメタデータとして取り込むこともできる。従って、メタデータは、メタデータを保存した時の状態にシステムを戻すことができる。

ワークフロー管理システムは、ワークフローテンプレートに予め定められたワークフロー段階の処理から生じた結果をユーザが検証した後に、新たなシーンを作成してワークフローシーンに記憶する。ワークフロー管理システムでは、シーンから生成された医用画像ビューをユーザが調整している最中にシーンの更新及びセーブを行うことができる。ワークフロー管理システムに関するさらに詳細な情報は、２００８年８月２１日に出願された「医用画像データ処理のためのワークフローテンプレート管理（Ｗｏｒｋｆｌｏｗ Ｔｅｍｐｌａｔｅ Ｍａｎａｇｅｍｅｎｔ ｆｏｒ Ｍｅｄｉｃａｌ Ｉｍａｇｅ Ｄａｔａ Ｐｒｏｃｅｓｓｉｎｇ）」という名称の同時係属中の米国特許出願第１２／１９６，０９９号、現在の米国特許第８，３７０，２９３号に見出すことができ、この特許出願はその全体が引用により本明細書に組み入れられる。

上述したように、ユーザは、画像処理システムを用いて様々な画像処理ツールにアクセスすることができる。以下は、上述した画像処理システムの一部として含めることができる医用画像処理ツールの例である。これらの例は、例示目的で示すものであり、本発明を限定するものではない。

血管分析（Ｖｅｓｓｅｌ Ａｎａｌｙｓｉｓ）ツールは、広範囲の血管分析タスク、冠状動脈から大動脈までのエンドグラフトプラニング、並びに頸動脈及び腎動脈を含むさらに一般的な血管レビューが可能なＣＴ及びＭＲ血管造影のための包括的血管分析パッケージを含むことができる。自動中心線抽出、直線ビュー、直径及び長さ測定、ＣＰＲ及び軸レンダリング、及び自動薄スラブＭＩＰのための血管トラック（Ｖｅｓｓｅｌ Ｔｒａｃｋ）モードを含めることもできる。

カルシウムスコアリングツールは、Ａｇａｔｓｔｏｎを用いた冠状動脈カルシウムの半自動（Ｓｅｍｉ−ａｕｔｏｍａｔｅｄ）識別、容積及びミネラル質量アルゴリズムを含むことができる。カスタマイズオプション付きの統合レポートパッケージを含めることもできる。

時間依存型分析（ＴＤＡ）ツールは、ＣＴ又はＭＲを用いて取得される時間分解平面又は容積４Ｄ脳潅流検査を含むことができる。ＴＤＡツールは、入力関数及び基線の半自動選択を用いた平均強化時間及び強化積分などの様々なパラメータの色又はマッピングをサポートして分析速度を高めることができる。ＴＤＡツールは、動的４Ｄエリア検出器ＣＴ検査の迅速な自動処理をサポートして、取得後数分以内の解釈を確実にすることができる。

ＣＴ／ＣＴＡ（コンピュータ血管造影法）サブトラクションツールは、ＣＴ血管造影検査から非強化構造（例えば骨）を除去する際に使用され、ＣＴ／ＣＴＡオプションは、ＣＴＡスキャンからノイズを増やすことなく（骨及び外科クリップのような）高強度構造を除去する高密度ボクセルマスキングアルゴリズムが後続する事前及び事後コントラスト画像の自動登録を含み、造営血管構造の分離を支援する。

小葉分解ツールは、関心容積内のツリー状構造、例えば血管床を含む走査領域、又は肝臓などの臓器を識別する。ＬＤツールは、ツリーの所与の分枝又はその副分枝の１つとの近接性に基づいて関心副容積を識別することができる。研究用途としては、臓器の小葉構造の分析が挙げられる。

低被爆一般強化＆ノイズ処理（Ｇｅｎｅｒａｌ Ｅｎｈａｎｃｅｍｅｎｔ ＆ Ｎｏｉｓｅ Ｔｒｅａｔｍｅｎｔ ｗｉｔｈ Ｌｏｗ Ｅｘｐｏｓｕｒｅ）ツールは、ソース画像の品質が最適でない場合でも３Ｄの有効性、中心線、輪郭削り及びセグメント化アルゴリズムを改善するノイズ管理技術を適用する高度容積フィルタアーキテクチャを含むことができる。

Ｓｐｈｅｒｅｆｉｎｄｅｒツールは、容積検査の自動分析を行って、高球面指数（多くの結節及びポリープによって示される特徴）を有する構造の位置を識別する。Ｓｐｈｅｒｅｆｉｎｄｅｒは、潜在的関心領域を識別するために肺又は大腸ＣＴスキャンと共に使用されることが多い。

セグメント化、分析＆追跡ツールは、孤立性肺結節又はその他の潜在的病変などの塊及び構造の分析及び特徴付けを支援する。ツールは、関心領域を識別してセグメント化し、その後にＲＥＣＩＳＴ及びＷＨＯなどの測定基準を適用して、発見物の集計報告及び追跡比較をもたらす。Ｓｐｈｅｒｅｆｉｎｄｅｒを含む任意の検出エンジンからの候補マーカの表示及び管理を支援することもできる。

時間容積分析ツールは、心室などのリズミカルな動きの房から駆出率を自動計算することができる。ユーザが対象の壁境界（例えば、心外膜及び心内膜）を識別し、ユーザが確認したこれらの関心領域に基づいて、多面的ＣＴデータから駆出率、壁容積（質量）及び壁肥厚を報告することを可能にする高速かつ効率的なワークフローを含めることもできる。集計レポート出力が含まれる。

顎顔面（Ｍａｘｉｌｌｏ−ｆａｃｉａｌ）ツールは、顎顔面領域のＣＴ検査の分析及び視覚化をサポートし、これらのツールは、ＣＰＲツールを適用して、様々な平面の、及び様々な厚みの「パノラマ」投影、及び規定の曲面に沿った設定増分の断面ＭＰＲ像を生成する。

大腸、肺、又は血管などの膣内ＣＴ又はＭＲ検査に適用できるＦｌｙｔｈｒｏｕｇｈツールは、比較レビュー、以前に見た領域の塗り潰し、カバー率追跡、並びに早送り、巻き戻し、魚眼及びフラット容積表示ビューを含む複数画面レイアウトをサポートする。ンコントラストサブトラクションのためのツールである「Ｃｕｂｅ Ｖｉｅｗ」及び統合文脈レポートをサポートすることもできる。ｉＮｔｕｉｔｉｏｎ社のＳｐｈｅｒｅｆｉｎｄｅｒを含む任意の検出エンジンからの候補マーカの表示及び管理をサポートすることもできる。

容量ヒストグラム（Ｖｏｌｕｍｅｔｒｉｃ Ｈｉｓｔｏｇｒａｍ）ツールは、関心容積のセグメント化及び組成のための分析を可能にする。研究用途としては、肺の低減衰領域の分析、閾値に基づく腫瘍のボクセル集団への分割、血栓血管又は動脈瘤の検査、又はその他の病変が挙げられる。

発見物ワークフローツールは、連続検査にわたって発見物を追跡するためのフレームワークを提供する。データベースは、測定結果及びキー画像を保持し、連続比較を提示するＲＥＣＩＳＴ１．１法などの発見物の構造的比較及び経時的な集計レポートをサポートする。音声認識システム又は臨床データベースとの自動統合のための注釈及び画像マークアップ（ＡＩＭ）ＸＭＬスキーマをサポートすることもでき、ワードベースの（Ｗｏｒｄ−ｂａｓｅｄ）レポートをデータベースから取得することもできる。

これらのツールを用いて、いずれか２つのＣＴ、ＰＥＴ、ＭＲ又はＳＰＥＣＴ系列、又はこれらのいずれかの２系列の組み合わせを、一方に半透明カラーコーディングを割り当て、他方を解剖学的参照のためのグレースケール及び容積レンダリングで示して重ね合わせることができる。自動位置合わせが提供され、一時的系列又は保存された第３系列へのサブトラクションが可能である。ＰＥＴ／ＭＲ視覚化のサポートが含まれる。

特定のＭＲ検査（例えば、胸部ＭＲ）では、一定期間にわたって一連の画像が取得され、特定の構造が他の構造に対して経時的に強調されるようになる。これらのツールは、全ての強調後の画像から強調前の画像を減法して強化構造（例えば、血管構造及びその他の強化組織）の視覚化を強調する能力を特徴とする。時間依存性関心領域ツールを提供して、所与の領域の時間−強度グラフをプロットすることもできる。

パラメータマッピングツールは、多相ＭＲツールへの拡張機能であり、パラメータマッピングオプションは、画像内の各画素が画素強度の時間依存的挙動に応じて色分けされたオーバーレイマップを事前計算する。一例として、このツールを胸部ＭＲで使用して、強化領域の識別及び検査の速度を高めることができる。

ＭｕｌｔｉＫｖツールは、複数のベンダからのデュアルエネルギー及びスペクトル画像（Ｄｕａｌ Ｅｎｅｒｇｙ ａｎｄ Ｓｐｅｃｔｒａｌ Ｉｍａｇｉｎｇ）の取得をサポートし、セグメント化又はコントラスト抑制などの標準的な画像処理アルゴリズム、並びに新技術の正確な分析及び開発のための汎用ツールキットを提供する。

上述の実施形態は、様々な医学領域に適用することができる。例えば、上述の技術は、（ステントグラフト内挿術（ＥＶＡＲ）及び電気生理学（ＥＰ）プラニングを含む）血管分析に適用することができる。このような血管分析は、大動脈エンドグラフト及び電気生理学プラニングに加えて、冠状動脈、並びに頸動脈及び腎動脈などの一般血管の両方の分析を解釈するために行われる。クラウドサービスとして提供されるツールは、自動中心線抽出、直線ビュー、直径及び長さ測定、曲面再形成（Ｃｕｒｖｅｄ Ｐｌａｎａｒ Ｒｅｆｏｒｍａｔｉｏｎ：ＣＰＲ）及び軸レンダリング、並びに血管直径対距離及び断面図の図表化を含む。血管追跡ツールは、ナビゲーションの容易さと深い取り調べのために血管中心線に沿って移動してその周囲で回転する２つの直交する平面における最大値投影法（ＭＩＰ）ビューを提供する。プラーク分析ツールは、ソフトプラーク、石灰化プラーク及び壁内病変などの非管腔構造の詳細な描画を提供する。

また、上述した技術は、ステントグラフト内挿術の分野で利用することもできる。いくつかの実施形態によれば、クラウドサービスとして提供される血管分析ツールは、エンドグラフトのサイズ決定のための測定結果を取り込むレポートテンプレートの定義をサポートする。複数の中心線を抽出して、複数のアクセスポイントを用いたＥＶＡＲ処置のプラニングを可能にすることができる。２つの大動脈腸骨経路に沿った距離と共に、血管に垂直な直径を測定することができる。カスタムワークフローテンプレートを用いて、ステントのサイズ決定に必要とされる主大動脈エンドグラフト製造の測定仕様を作成することができる。有窓の分岐装置をプラニングするための血管枝の配向及び位置の文書化を支援する「クロックフェース」オーバレイによる心嚢のセグメント化及び容積決定を使用することもできる。必要な測定結果及びデータを含むレポートを生成することができる。

上述した技術は、クラウドサービスとして提供される主静脈及び副静脈直径評価のためのシングルクリック距離ペアツールを用いて各肺静脈口の半自動左心房セグメンテーションがサポートされる左心房分析モードにおいて適用することもできる。測定結果は、自動的に検出されて統合レポートシステムに取り込まれる。これらの機能を他の血管分析ツールと組み合わせて、切除及びリードアプローチプラニングのための包括的なカスタマイズされたＥＰプラニングワークフローを提供することができる。

上述した技術は、カルシウムスコアリングに利用することもできる。冠動脈カルシウムの半自動識別は、Ａｇａｔｓｔｏｎを用いてサポートされ、容積及びミネラル質量アルゴリズムがスクリーン上で合計されてレポートされる。結果は、患者及びその心臓血管病歴及びリスク因子に関する他の様々なデータと共に、オープンフォーマットデータベースに記憶することができる。クラウドサービスの一部として、これらのデータに基づいてカスタマイズレポートを自動的に生成することもできる。また、心臓血管コンピュータ断層撮影学会（ＳＣＣＴ）ガイドラインによって定められるレポート作成も含む。

上述の技術は、左心室容積、駆出率、心筋容積（質量）及び多相データからの壁肥厚の完全自動計算を含むことができる時間−容積分析（ＴＶＡ）において利用することもできる。クラウドサービスの一部として提供される高速かつ効率的なワークフローは、レベル及び輪郭の容易な検証又は調整を可能にする。結果は、統合レポート機能内で提示される。

上述した技術は、肺ＣＴ検査を含む様々なスキャンにおける質量及び構造の分析及び特徴付けの支援を含むセグメンテーション分析及び追跡（ＳＡＴ）の分野で利用することもできる。特徴としては、シングルクリックによる質量のセグメント化、セグメント化の問題を解消する手動編集ツール、次元及び容積の自動レポート、選択領域のグラフィカル３Ｄ表示、統合自動レポートツール、パーセント容積の変化及び倍化時間を含むフォローアップ比較のサポート、及び球面フィルタ結果の再検討のサポートが挙げられる。

上述した技術は、必要時に大腸の中心線を再定義するために利用可能な編集ツールを用いた大腸の自動セグメンテーション及び中心線抽出の特徴を含むことができるフライスルーの分野で利用することもできる。２Ｄレビューは、代表的な同期膣内ビューを用いた軸状、冠状又は矢状ビューのいずれかの形の横並びの同期背臥及び腹臥データセットを含む。３Ｄレビューは、大型の膣内ビュー及び大腸全体を表示する展開ビューを用いた軸状、冠状及び矢状ＭＰＲ又はＭＩＰ画像表示を含む。見えない部分の段階的レビュー、１クリックによるポリープ識別、ブックマーク及びマージ発見、並びに関心容積及び統合文脈レポートツールを分離するための立方体ビューによる１００％カバレージを確実にするためにカバレージトラッキングがサポートされる。球面フィルタの結果を使用するためのサポートが提供される。

上述の技術は、脳潅流研究などにおいて適当なコンピュータ断層撮影血管造影法（ＣＴＡ）及び／又はＭＲＩ検査の時間的依存挙動を分析する評価ツールを提供する時間依存分析（ＴＤＡ）の分野において利用することもできる。特徴としては、複数の時間依存シリーズを同時にロードするためのサポート、並びに入力及び出力関数及び関心領域を選択するための手順ワークフローが挙げられる。血流、血液量及び通過時間マップをＤＩＣＯＭにエクスポートするための能力と共に統合レポートツールが提供される。このツールは、時間依存性ＭＲ取得と共に使用して、様々な時間依存パラメータを計算することもできる。

上述した技術は、造影前及び造影後画像の自動登録の後に、ノイズの増加を伴わずに造影血管構造を無傷にしたままでＣＴＡスキャンから（骨及び外科クリップのような）高強度構造を除去するサブトラクション又はデンス−ボクセルマスキング技術を含むＣＴＡ−ＣＴサブトラクションの分野において利用することもできる。

上述の技術は、歯科分析において利用して、様々な平面における様々な厚みの「パノラマ」投影を生成する能力と、規定の曲面に沿った設定増分での断面ＭＰＲビューとをもたらす、歯科ＣＴスキャンのレビューに適用できるＣＰＲツールを提供することもできる。

上述の技術は、多層ＭＲの分野（基本、例えば胸部、前立腺ＭＲ）において利用することもできる。特定のＭＲ検査（例えば、胸部、前立腺ＭＲ）は、一定期間にわたって撮影された一連の画像収集を伴い、特定の構造が他の構造に対して時間と共に強化される。このモジュールは、全ての強調後の画像から強調前の画像を減法して強化構造（例えば、血管構造及びその他の強化組織）の視覚化を強調する能力を特徴とする。時間依存性関心領域ツールを提供して、所与の領域の時間−強度グラフをプロットする。

上述の技術は、画像内の各画素が画素強度の時間依存的挙動に応じて色分けされたオーバレイマップをパラメータマッピングモジュールが事前計算する（例えば多層胸部ＭＲのための）パラメータマッピングにおいて利用することもできる。上述の技術は、ＳｐｈｅｒｅＦｉｎｄｅｒ（例えば、肺及び大腸のための球面フィルタ）の分野において利用することもできる。ＳｐｈｅｒｅＦｉｎｄｅｒは、データセットを受け取ると直ぐに前処理し、フィルタを適用して球状構造を検出する。ＳｐｈｅｒｅＦｉｎｄｅｒは、潜在的関心領域を識別するために肺又は大腸ＣＴスキャンと共に使用されることが多い。説明した技術は、ＣＴ／ＭＲ／ＰＥＴ／ＳＰＥＣＴの融合において利用することもできる。いずれか２つのＣＴ、ＰＥＴ、ＭＲ又はＳＰＥＣＴシリーズ、又はいずれかの２シリーズの組み合わせを、一方に半透明カラーコーディングを割り当て、他方を解剖学的参照のためのグレースケール及び容積レンダリングで示してオーバーレイすることができる。自動登録が提供され、一時的系列又は保存された第３系列へのサブトラクションが可能である。

上述の技術は、小葉分解（Ｌｏｂｕｌａｒ Ｄｅｃｏｍｐｏｓｉｔｉｏｎ）の分野において利用することもできる。小葉分解は、人体構造を念頭において設計された分析及びセグメント化ツールである。小葉分解ツールは、（動脈及び／又は静脈ツリーなどの）ツリー状構造が絡み合ったあらゆる構造又は臓器領域に対し、ユーザが関心容積、及びそれに関連するツリーを選択して、容積をツリー又はそのいずれかの特定の副分枝に最も近い小葉又はテリトリーに区分できるようにする。この汎用かつ柔軟なツールには、肝臓、肺、心臓、並びに他の様々な臓器及び病理学的構造の分析に潜在的な研究用途がある。

上述の技術は、容積ヒストグラム（Ｖｏｌｕｍｅｔｒｉｃ Ｈｉｓｔｏｇｒａｍ）の分野において利用することもできる。容積ヒストグラムは、成分ボクセルを異なる強度又は密度範囲の集団に区分化することに基づく所与の関心容積の分析をサポートする。容積ヒストグラムを用いて、例えば癌（活動腫瘍、壊死組織及び浮腫間のバランスを理解する試みにおいて腫瘍の組成を分析することが望ましい場合）、又は気腫（肺ＣＴ検査における低減衰ボクセルの集団が早期疾患の重要なインジケータになり得る場合）などの疾病過程の研究をサポートすることができる。

上述の技術は、動作分析（Ｍｏｔｉｏｎ Ａｎａｌｙｔｉｃｓ）の分野において利用することもできる。動作分析は、対話型３Ｄ又は４Ｄディスプレイが利用できない時に発見物をより効率的に伝える、４Ｄプロセスの強力な２Ｄ表現を提供する。鼓動する心臓などのあらゆる動的容積取得を動作分析して、動的シーケンス全体を通じて重要な境界の輪郭の色分けされた「トレール」を生成し、単一の２Ｄフレームが、文献内で容易にレポートできる形で動作を取り込んで例示できるようにすることができる。カラーパターンの均一性又は均一性の欠如は、動作が調和する程度を反映し、単一の画像から中間視覚フィードバックを提供する。

図１５Ａ及び図１５Ｂは、本発明のいくつかの実施形態による、クラウドベースの画像処理システムを示すブロック図である。例えば、クラウドサーバ１５０９は、上述したような医療情報サーバ１０１を表すことができる。図１５Ａを参照すると、１つの実施形態によれば、システム１５００は、ネットワークを介してクラウド１５０３に通信可能に結合された１又は２以上のエンティティ又は機関１５０１〜１５０２を含む。エンティティ１５０１〜１５０２は、世界中に存在する様々な施設を有する医療機関などの様々な組織を表すことができる。例えば、エンティティ１５０１は、１又は複数の画像取り込み装置１５０４、画像記憶システム（例えば、ＰＡＣＳ）１５０５、ルータ１５０６、及び／又はデータゲートウェイマネージャ１５０７を含み、又はこれらに関連することができる。画像記憶システム１５０５は、エンティティ１５０１に関連するアドミニストレータ又はユーザなどのワークステーション１５０８がアクセスできる、エンティティ１５０１にアーカイブサービスを提供するサードパーティエンティティによって維持することができる。なお、本出願では、組織エンティティの例として医療機関を利用している。しかしながら、本出願はこのように限定されるわけではなく、他の組織又はエンティティを適用することもできる。

１つの実施形態では、クラウド１５０３が、ネットワークを介して地理的に分散する、サービスプロバイダに関連する一連のサーバ又はサーバクラスタを表すことができる。例えば、クラウド１５０３は、カリフォルニア州フォスターシティのＴｅｒａＲｅｃｏｎ社などの医用画像処理サービスプロバイダに関連することができる。ネットワークは、ローカルエリアネットワーク（ＬＡＮ）、都市圏ネットワーク（ＭＡＮ）、インターネット又はイントラネットなどのワイドエリアネットワーク（ＷＡＮ）、又はこれらの組み合わせとすることができる。クラウド１５０３は、クライアント１５１３〜１５１６などの様々なクライアントにネットワークを介してアプリケーションサービスを提供できる様々なサーバ及び装置で構成することができる。１つの実施形態では、クラウド１５０３が、画像処理サービスを提供する１又は２以上のクラウドサーバ１５０９と、画像及びその他の医療データを記憶する１又は２以上のデータベース１５１０と、エンティティ１５０１〜１５０２などの他のエンティティとの間でデータを転送する１又は２以上のルータ１５１２とを含む。クラウドサーバがサーバクラスタ又は複数のサーバで構成される場合、クラスタ内のサーバ間におけるデータの転送を制御するルールが存在することができる。例えば、１つの国のサーバのデータを別の国のサーバに配置すべきでない理由が存在することができる。

サーバ１５０９は、ネットワークを介してクライアント１５１３〜１５１６に医用画像処理サービスを提供する画像処理サーバとすることができる。例えば、サーバ１５０９は、ＴｅｒａＲｅｃｏｎＡｑｕａｒｉｕｓＮＥＴ（商標）サーバ及び／又はＴｅｒａＲｅｃｏｎＡｑｕａｒｉｕｓＡＰＳサーバの一部として実装することができる。データゲートウェイマネージャ１５０７及び／又はルータ１５０６は、ＴｅｒａＲｅｃｏｎＡｑｕａｒｉｕｓＧＡＴＥ装置の一部として実装することができる。医用画像装置１５０４は、Ｘ線ＣＴ装置、ＭＲＩスキャニング装置、核医学装置、超音波装置又は他のいずれかの医用画像装置などの画像診断装置とすることができる。医用画像装置１５０４は、試料の複数の断面図から情報を収集し、これらを再構成して、複数の断面図のための医用画像データを生成する。医用画像装置１５０４は、モダリティとも呼ばれる。

データベース１５１０は、医用におけるデジタル画像及び通信（ＤＩＣＯＭ）と互換性のあるデータ又はその他の画像データなどの医療データを記憶するデータストアとすることができる。データベース１５１０は、暗号化機能を組み込むこともできる。データベース１５１０は、複数のデータベースを含むことができ、及び／又はストレージプロバイダなどのサードパーティベンダによって維持することができる。データストア１５１０は、例えばＯｒａｃｌｅ（商標）データベース又はＭｉｃｒｏｓｏｆｔ（登録商標）ＳＱＬサーバなどのリレーショナルデータベース管理システム（ＲＤＢＭＳ）を用いて実装することができる。クライアント１５１３〜１５１６は、デスクトップ、ラップトップ、タブレット、携帯電話機、携帯情報端末（ＰＤＡ）などの様々なクライアント装置を表すことができる。クライアント１５１３〜１５１６の一部は、サーバ１５０９に収容される医用画像処理ツール又はアプリケーションなどのリソースにネットワークを介してアクセスできるようにクライアントアプリケーション（例えば、シンクライアントアプリケーション）を含むことができる。シンクライアントの例としては、ウェブブラウザ、電話アプリケーション及びその他が挙げられる。

１つの実施形態によれば、サーバ１５０９は、医療機関からの医師、インストラクタ、学生、保険会社からの代理人、患者、医学研究者などを表すことができるクライアント１５１３〜１５１６に高度画像処理サービスを提供するように構成される。クラウドサーバ１５０９は、画像処理サーバとも呼ばれ、１又は２以上の医用画像及び医用画像に関連するデータを収容して、クライアント１５１３〜１５１６などの複数の参加者が共同的に又は会議環境において画像についてのディスカッション／処理フォーラムに参加できるようにすることができる。異なる参加者が、画像の議論セッション又はワークフロープロセスの異なる段階及び／又はレベルに参加することができる。

いくつかの実施形態によれば、データゲートウェイマネージャ１５０７が、医療機関などのデータプロバイダ（例えば、ＰＡＣＳシステム）との間で医療データを自動又は手動で転送するように構成される。このようなデータゲートウェイ管理は、アドミニストレータ又は許可スタッフによって構成できる一連のルール又はポリシーに基づいて実行することができる。１つの実施形態では、データゲートウェイマネージャが、クラウドで行われる画像討論会又は画像処理動作中における医用画像データの更新に応答して、更新された画像データ、又は更新された画像データと元々の画像データとの違いを、元々の医用画像データを提供したＰＡＣＳ１５０５などのデータプロバイダにネットワーク（例えば、インターネット）を介して送信するように構成される。同様に、データゲートウェイマネージャ１５０７は、エンティティ１５０１に関連する画像取り込み装置１５０４などの画像取り込み装置によって取り込むことができたいずれかの新たな画像及び／又は画像データをデータプロバイダから送信するように構成することができる。また、データゲートウェイマネージャ１５０７は、同じエンティティに関連する複数のデータプロバイダ（例えば、医療機関の複数の施設）間でデータをさらに転送することもできる。さらに、クラウド１５０３は、クラウドシステムによって提供された特定の高度画像処理リソースを用いて、受け取った画像の特定の前処理動作を自動的に行うことができる高度前処理システム（図示せず）を含むこともできる。１つの実施形態では、ゲートウェイマネージャ１５０７が、ポート８０又は４４３などの特定のインターネットポートを介してクラウド１５０３と通信するように構成される。転送中のデータは、様々な暗号化法及び圧縮法を用いて暗号化及び／又は圧縮することができる。この文脈における「インターネットポート」という用語は、イントラネットポート、又はイントラネット上のポート８０又は４４３などのプライベートポートとすることもできる。

図１６は、本発明の１つの実施形態と共に使用できるデータ処理システムのブロック図である。例えば、システム１６００は、上述したようなサーバ又はクライアントの一部として使用することができる。例えば、システム１６００は、ネットワークインターフェイス１６１０を介して遠隔クライアント装置又は別のサーバに通信可能に結合される、上述した医療情報サーバ１０１を表すことができる。上述したように、少なくともＥＣＣＤエンジン１０３、医用画像処理システム２１０及び医療データ統合器２０５は、システム１６００に収容することができる。

なお、図１６には、コンピュータシステムの様々なコンポーネントを示しているが、コンポーネント同士を相互接続するいずれかの特定のアーキテクチャ又は方式を表す意図はなく、従ってこのような詳細は本発明とは無関係である。これよりも少ないコンポーネント、又は場合によっては多くのコンポーネントを有するネットワークコンピュータ、ハンドヘルドコンピュータ、携帯電話機及びその他のデータ処理システムを本発明と共に使用することもできると理解されるであろう。

図１６に示すように、データ処理システムの一形態であるコンピュータシステム１６００は、１又は２以上のマイクロプロセッサ１６０３及びＲＯＭ１６０７、揮発性ＲＡＭ１６０５、並びに不揮発性メモリ１６０６に結合されたバス又は相互接続部１６０２を含む。マイクロプロセッサ１６０３は、キャッシュメモリ１６０４に結合される。バス１６０２は、これらの様々なコンポーネントを互いに相互接続するともに、これらのコンポーネント１６０３、１６０７、１６０５及び１６０６を、ディスプレイコントローラ及びディスプレイ装置１６０８、並びにマウス、キーボード、モデム、ネットワークインターフェイス、プリンタ及び当業で周知の他の装置とすることができる入力／出力（Ｉ／Ｏ）装置１６１０にも相互接続する。

通常、入力／出力装置１６１０は、入力／出力コントローラ１６０９を介してシステムに結合される。通常、揮発性ＲＡＭ１６０５は、メモリ内のデータをリフレッシュ又は維持するために絶えず電力を必要とするダイナミックＲＡＭ（ＤＲＡＭ）として実装される。通常、不揮発性メモリ１６０６は、磁気ハードドライブ、磁気光学ドライブ、光学ドライブ、ＤＶＤ ＲＡＭ、又はシステムから電力が除去された後にもデータを維持する他のタイプのメモリシステムである。通常、不揮発性メモリもランダムアクセスメモリであるが、これは必須ではない。

図１６には、不揮発性メモリが、データ処理システムの残りのコンポーネントに直接結合されたローカル装置であるように示しているが、本発明は、モデム又はイーサネット（登録商標）インターフェイスなどのネットワークインターフェイスを介してデータ処理システムに結合されたネットワーク記憶装置などの、システムから離れて存在する不揮発性メモリを利用することもできる。バス１６０２は、当業で周知のように、様々なブリッジ、コントローラ及び／又はアダプタを介して互いに接続された１又は２以上のバスを含むことができる。１つの実施形態では、Ｉ／Ｏコントローラ１６０９が、ＵＳＢ周辺装置を制御するＵＳＢ（ユニバーサルシリアルバス）アダプタを含む。或いは、Ｉ／Ｏコントローラ１６０９は、ファイヤワイヤ装置を制御する、ファイヤワイヤアダプタとしても知られているＩＥＥＥ−１３９４アダプタを含むこともできる。

上述した詳細な説明の一部は、コンピュータメモリ内のデータビットにおける演算のアルゴリズム及び記号表現の観点から示したものである。これらのアルゴリズムによる記述及び表現は、データ処理における当業者が自らの研究内容を他の当業者に最も効果的に伝えるために使用する方法である。ここでは、一般に、アルゴリズムとは、望ましい結果をもたらす首尾一貫した一連の演算であると考えられる。これらの演算は、物理量の物理的操作を必要とするものである。

しかしながら、これらの及び同様の用語は、全て適当な物理量に関連付けられるべきものであり、またこれらの量に与えられた便利な表記に過ぎないことに留意されたい。上述の説明から明らかなように、特に別途述べていない限り、本発明全体を通じ、以下の特許請求の範囲に記載するような用語を利用した説明は、コンピュータシステムのレジスタ及びメモリ内の物理（電子）量として表されるデータを操作し、コンピュータシステムのメモリ、レジスタ、又はその他のこのような情報記憶装置、送信又は表示装置内の物理量として同様に表される他のデータに変換するコンピュータシステム又は同様の電子コンピュータ装置の動作及び処理を意味するものである。

図示の技術は、１又は２以上の電子装置上に記憶され実行されるコード及びデータを用いて実装することができる。このような電子装置は、（磁気ディスク、光ディスク、ランダムアクセスメモリ、リードオンリメモリ、フラッシュメモリデバイス、相変化メモリなどの）非一時的コンピュータ可読記憶媒体及び（電気信号、光信号、音響信号、又は搬送波、赤外線信号、デジタル信号などのその他の形の伝搬信号などの）一時的コンピュータ可読伝送媒体などのコンピュータ可読媒体を使用してコード及びデータを記憶し（内部的に及び／又はネットワークを介して他の電子装置と）通信する。

上述した図に示すプロセス又は方法は、（回路、専用ロジックなどの）ハードウェア、ファームウェア、（非一時的コンピュータ可読媒体上で具体化されるような）ソフトウェア、又はこれらの組み合わせを含むロジックを処理することによって実施することができる。上記では、これらのプロセス又は方法をいくつかの順次処理の観点から説明したが、説明した動作の一部を異なる順序で実行することもできると理解されたい。さらに、動作によっては、順次的にではなく同時に実行できるものもある。

上述の明細書では、本発明の実施形態をその特定の例示的な実施形態を参照しながら説明した。特許請求の範囲に示す本発明の幅広い思想及び範囲から逸脱することなく本発明に様々な修正を行えることが明白であろう。従って、明細書及び図面は、限定的な意味ではなく例示的な意味で捉えるべきである。

１０１ 医療情報サーバ
１０２Ａ クライアント装置
１０２Ｂ クライアント装置
１０３ ＥＣＣＤエンジン
１０５Ａ 医療データソース（ＰＡＣＳサーバなど）
１０５Ｂ 医療データソース（ＥＭＲサーバなど）
１０５Ｃ 医療データソース（ＨＩＳサーバなど）
２００ 医療情報システム
２０２ ＥＣＣＤモデル／ルール
２０３ ユーザデータベース
２０４ 患者データベース
２０５ 医療データ統合器
２０６ ネットワーク（インターネットなど）
２０７Ａ クライアントアプリケーション
２０７Ｂ クライアントアプリケーション
２１０ 医用画像処理システム
２１１Ａ 患者／医療データ
２１１Ｂ 患者／医療データ
２１２Ａ 医用画像
２１２Ｂ 医用画像
２１３Ａ 分析結果／推奨
２１３Ｂ 分析結果／推奨
２２０ 医用画像処理システム

Claims (15)

1. 医療データを処理するためのコンピュータ実装方法であって、
   医療情報サーバにおいて、クライアント装置において表示された第１の医療データに対するユーザの第１のユーザインタラクションを表す信号を前記ユーザの前記クライアント装置からネットワークを介して受け取り、前記第１の医療データは、患者の第１の病状に関連し、前記第１の医療データは、前記第１の病状に関連する前記患者の医用画像の画像データを含み、前記第１の医療データは、第１の医療データサーバから前記ネットワークを介して受け取られたものであり、
   前記信号に応答して、プロセッサによって実行されるデータ検索モジュールが第２の医療データサーバにアクセスして、前記第１の医療データに関連する前記患者の第２の医療データを検索し、前記第２の医療データは、前記第１の病状に関連する前記患者の医療臨床データ及び医学的症状の少なくとも一方を含み、前記第１の医療データサーバと前記第２の医療データサーバとは異なるサーバであり、
   進化型文脈的臨床データ（ＥＣＣＤ）エンジンのデータ分析モジュールが、
   前記第１の医療データの前記画像データに第１の分析を実行して画像定量結果を生成することと、
   前記患者の医療臨床データ及び医学的症状の少なくとも一方に照らして前記画像定量結果に第２の分析を実行することと、
   を自動的に行い、
   前記分析モジュールが、前記分析に基づいて前記患者の第２の病状が発生する可能性を特定し、
   データ統合器が、前記第２の医療データを前記分析の分析結果と統合して、前記患者の前記第２の病状が発生する可能性を示す情報を含む１又は２以上の医療情報ビューを生成し、
   前記１又は２以上の第２の医療情報ビューを前記クライアント装置に送信して、該クライアント装置のディスプレイに表示されるようにする、
   ことを特徴とする方法。
2. 一定範囲の特定の医療データに基づいて推奨すべき行動リストを指定する一連のＥＣＣＤルールに照らして、前記分析結果に基づいて取るべき行動指針の推奨を自動的に決定し、
   前記推奨を前記１又は２以上の医療情報ビューの一部として前記クライアント装置に送信して、該クライアント装置に表示されるようにする、
   ことをさらに行う、
   請求項１に記載の方法。
3. 前記第１の病状に関連する他の患者の第３の医療データを検索し、
   前記第１の病状に関連する他の患者の前記第３の医療データに基づいて、前記第２の病状が発生する可能性を特定する、
   ことをさらに行う、
   請求項１に記載の方法。
4. 前記患者の前記第２の医療データと、他の患者の前記第３の医療データとに基づいて、前記患者の前記第２の医療データを表す第１のインジケータと、前記他の患者の前記第３の医療データを表す複数の第２のインジケータを含むグラフィック表現を生成し、
   前記グラフィック表現を前記クライアント装置に送信して、前記１又は２以上の医療情報ビューの一部として表示されるようにする、
   ことをさらに行う、
   請求項３に記載の方法。
5. 前記患者の前記第２の医療データの分析に照らして、一連のＥＣＣＤルールに基づいて第１の行動を自動的に実行し、前記１又は２以上の医療情報ビューは、前記第１の行動が実行されたことをさらに示す、
   ことをさらに行う、
   請求項１に記載の方法。
6. 前記第１の行動は、前記第２の医療データに関するメッセージを前記患者に送信することを含む、
   請求項５に記載の方法。
7. 前記医療データサーバは、ピクチャアーカイブ及び情報システム（ＰＡＣＳ）と、電子医療記録（ＥＭＲ）サーバと、臨床検査情報サーバと、及び病院情報システムとを含む、
   請求項１に記載の方法。
8. 命令を記憶した非一時的機械可読媒体であって、前記命令は、プロセッサによる実行時に、該プロセッサに請求項１から７のいずれかに記載の方法を実行させる、
   ことを特徴とする非一時的機械可読媒体。
9. 医療情報サーバとして動作するデータ処理システムであって、
   プロセッサと、
   前記プロセッサに結合された、命令を記憶するメモリと、
   を備え、前記命令は、前記プロセッサによる実行時に、該プロセッサに請求項１から７のいずれかに記載の方法を実行させる、
   ことを特徴とするシステム。
10. 医療データを処理するための装置であって、
    医療情報サーバにおいて、クライアント装置において表示された第１の医療データに対するユーザの第１のユーザインタラクションを表す信号を前記ユーザの前記クライアント装置からネットワークを介して受け取る手段を備え、前記第１の医療データは、患者の第１の病状に関連し、前記第１の医療データは、前記第１の病状に関連する前記患者の医用画像の画像データを含み、前記第１の医療データは、第１の医療データサーバから前記ネットワークを介して受け取られたものであり、
    前記信号に応答して、第２の医療データサーバにアクセスして、前記第１の医療データに関連する前記患者の第２の医療データを検索する手段をさらに備え、前記第２の医療データは、前記第１の病状に関連する前記患者の医療臨床データ及び医学的症状の少なくとも一方を含み、前記第１の医療データサーバと前記第２の医療データサーバとは異なるサーバであり、
    前記第１の医療データの前記画像データに第１の分析を実行して画像定量結果を生成することと、前記患者の医療臨床データ及び医学的症状の少なくとも一方に照らして前記画像定量結果に第２の分析を実行することとを自動的に行う手段と、
    前記分析に基づいて前記患者の第２の病状が発生する可能性を特定する手段と、
    前記第２の医療データを前記分析の分析結果と統合して、前記患者の前記第２の病状が発生する可能性を示す情報を含む１又は２以上の医療情報ビューを生成する手段と、
    前記１又は２以上の第２の医療情報ビューを前記クライアント装置に送信して、該クライアント装置のディスプレイに表示されるようにする手段と、
    がさらに設けられることを特徴とする装置。
11. 一定範囲の特定の医療データに基づいて推奨すべき行動リストを指定する一連のＥＣＣＤルールに照らして、前記分析結果に基づいて取るべき行動指針の推奨を自動的に決定する手段と、
    前記推奨を前記１又は２以上の医療情報ビューの一部として前記クライアント装置に送信して、該クライアント装置に表示されるようにする手段と、
    をさらに備える、
    請求項１０に記載の装置。
12. 前記第１の病状に関連する他の患者の第３の医療データを検索する手段と、
    前記第１の病状に関連する他の患者の前記第３の医療データに基づいて、前記第２の病状が発生する可能性を特定する手段と、
    をさらに備える、
    請求項１０に記載の装置。
13. 前記患者の前記第２の医療データと、他の患者の前記第３の医療データとに基づいて、前記患者の前記第２の医療データを表す第１のインジケータと、前記他の患者の前記第３の医療データを表す複数の第２のインジケータを含むグラフィック表現を生成する手段と、
    前記グラフィック表現を前記クライアント装置に送信して、前記１又は２以上の医療情報ビューの一部として表示されるようにする手段と、
    をさらに備える、
    請求項１２に記載の装置。
14. 前記患者の前記第２の医療データの分析に照らして、一連のＥＣＣＤルールに基づいて第１の行動を自動的に実行する手段をさらに備え、前記１又は２以上の医療情報ビューは、前記第１の行動が実行されたことをさらに示す、
    請求項１０に記載の装置。
15. 前記第１の行動は、前記第２の医療データに関するメッセージを前記患者に送信することを含む、
    請求項１４に記載の装置。

Images