特許 7171645 マルチモダリティ医療処理システムを用いて、マルチモダリティ医療データを表示する方法、及びマルチモダリティ医療システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-11-07

(45)【発行日】2022-11-15

(54)【発明の名称】マルチモダリティ医療処理システムを用いて、マルチモダリティ医療データを表示する方法、及びマルチモダリティ医療システム

(51)【国際特許分類】

   G16H 10/00 20180101AFI20221108BHJP

【ＦＩ】

G16H10/00

【請求項の数】 24

(21)【出願番号】P 2020072633

(22)【出願日】2020-04-15

(62)【分割の表示】P 2018095015の分割

【原出願日】2013-12-19

(65)【公開番号】P2020115389

(43)【公開日】2020-07-30

【審査請求日】2020-04-23

(31)【優先権主張番号】61/746,806

(32)【優先日】2012-12-28

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】61/746,854

(32)【優先日】2012-12-28

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】61/746,897

(32)【優先日】2012-12-28

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】61/747,000

(32)【優先日】2012-12-28

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】515122402

【氏名又は名称】フィリップス イメージ ガイディッド セラピー コーポレイション

(74)【代理人】

【識別番号】110001690

【氏名又は名称】特許業務法人Ｍ＆Ｓパートナーズ

(72)【発明者】

【氏名】アッシャー・コーエン

(72)【発明者】

【氏名】アポロ・バリグナセイ

(72)【発明者】

【氏名】トム・プロベスコ

(72)【発明者】

【氏名】マイケル・エイ・エチェベリア

(72)【発明者】

【氏名】リチャード・イー・マンスカー

(72)【発明者】

【氏名】ジェイソン・スペンサー

(72)【発明者】

【氏名】ビル・クラーク

(72)【発明者】

【氏名】レックス・カー

【審査官】阿部 潤

(56)【参考文献】

【文献】特開２０１０－１２８８４７（ＪＰ，Ａ）

【文献】国際公開第２００７／１１６８９８（ＷＯ，Ａ１）

【文献】特開２００８－０５２５４４（ＪＰ，Ａ）

【文献】特開２０１２－０４８６０２（ＪＰ，Ａ）

【文献】特開２０１２－０８４００８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ１６Ｈ １０／００ － ８０／００

Ｇ０６Ｑ １０／００ － ９９／００

(57)【特許請求の範囲】

【請求項1】

マルチモダリティ医療処理システムを用いて、患者に関連付けられるマルチモダリティ医療データを収集し、前記マルチモダリティ医療データを表示する方法であって、
前記マルチモダリティ医療処理システムは、第一の医療モダリティコンポーネントと、第二の医療モダリティコンポーネントと、前記第一の医療モダリティコンポーネント及び前記第二の医療モダリティコンポーネントと通信するマルチモダリティ管理コンポーネントとを備え、
第一の医療機器は、前記患者の血管内に挿入される形状及びサイズを有し、前記患者の血管内に配置され、可撓性の細長い部材を含む血管内カテーテル又はガイドワイヤと、第一の医療モダリティに関連づけられている第一の医療データを前記患者の血管内で取得するように構成されているデータ収集コンポーネントとを備え、
この方法は：
前記第一の医療モダリティコンポーネントで、前記第一の医療機器からの前記患者から取得した前記第一の医療データを受信すること；
前記第一の医療データに固有の識別子を関連付けること；
前記第一の医療データをデータリポジトリ内に記憶すること；
前記第二の医療モダリティコンポーネントで、第二の医療機器からの前記患者についての第二の医療データを受信することであって、当該第二の医療データは前記第一の医療モダリティとは異なる第二の医療モダリティに関連づけられる、受信すること；
前記第二の医療データに前記固有の識別子を関連付けること；
前記第二の医療データを前記データリポジトリ内に記憶すること；
前記患者の近くに配置されるベッドサイドコントローラのタッチ画面上のユーザインタフェース出力領域の同じ部分に、第一の選択可能なオプション及び第二の選択可能なオプションを同時に表示することであって、前記第一の選択可能なオプションは、前記第一の医療データの表示を制御し、前記第二の選択可能なオプションは、前記第二の医療データの表示を制御し、前記ベッドサイドコントローラは、前記第一の医療機器、前記第二の医療機器及び前記マルチモダリティ医療処理システムと通信し、前記マルチモダリティ医療処理システムのユーザインタフェースコンポーネントは、前記ベッドサイドコントローラの前記タッチ画面を描画し、前記ユーザインタフェースコンポーネントは、前記第一の医療モダリティコンポーネント及び前記第二の医療モダリティコンポーネントに関連付けられるデータを表示するように、前記マルチモダリティ管理コンポーネントにより利用される、表示すること；
前記第一の医療データを表示するために、前記第一の選択可能なオプションのユーザ選択を受信することであって、前記ユーザ選択は、前記ベッドサイドコントローラの前記タッチ画面上のユーザ入力を含む、受信すること；および
前記ユーザ選択を受信することに応答して、前記ベッドサイドコントローラの前記タッチ画面上の前記ユーザインタフェース出力領域内に前記第一の医療データを表示すること；を含む、方法。

【請求項2】

請求項１記載の方法において：
前記第二の医療データを表示するために、前記第二の選択可能なオプションの更なるユーザ選択を受信すること；および
前記ユーザインタフェースにて、前記第一の医療データおよび第二の医療データを同時に表示すること、をさらに含む方法。

【請求項3】

請求項１記載の方法において、前記第一の選択可能なオプション及び前記第二の選択可能なオプションを表示することは、前記第一の医療データおよび前記第二の医療データに関連づけられるメタデータ値によって決定される順序で、前記第一の選択可能なオプション及び前記第二の選択可能なオプションを表示すること、を含むことを特徴とする方法。

【請求項4】

請求項３記載の方法において、前記メタデータ値は、医療モダリティ、医療データ取得時間、又は医師名の一つである、ことを特徴とする方法。

【請求項5】

請求項１記載の方法において、前記第一の選択可能なオプション及び前記第二の選択可能なオプションを表示することは、前記表現された医療データの前記医療モダリティのタイプによって体系化して、グループ内の前記第一の選択可能なオプション及び前記第二の選択可能なオプションを表示すること、を含むことを特徴とする方法。

【請求項6】

請求項１記載の方法において、前記第一の選択可能なオプションに関連づけられるトグル要素のユーザ操作を受けて、当該第一の医療データについての追加情報を表示すること、をさらに含む方法。

【請求項7】

請求項６記載の方法において、前記追加情報は、前記第一の医療データから得た前記患者の一部分のプレビュー画像を含む、ことを特徴とする方法。

【請求項8】

請求項６記載の方法において、前記追加情報は、前記第一の選択可能なオプションに隣接して表示される、ことを特徴とする方法。

【請求項9】

請求項６記載の方法において、前記追加情報は、前記第一の医療データを生成した取得プロシージャのプルバックレートを含む、ことを特徴とする方法。

【請求項10】

請求項１記載の方法において、
前記第一の選択可能なオプションに関連づけられるトグル要素のユーザ操作を受けて、削除ボタンを表示すること；
前記削除ボタンのユーザ操作を受信すること；および
前記ユーザ操作を受信することに応答して、前記データリポジトリから前記第一の医療データを削除すること、をさらに含む方法。

【請求項11】

請求項１記載の方法において、前記第一の医療データおよび前記第二の医療データは、単一のカテーテルラボセッション中に前記患者から取得されたことを特徴とする方法。

【請求項12】

請求項１記載の方法において、前記第一および前記第二の医療モダリティは、それぞれ、血管内超音波（ＩＶＵＳ）イメージング、血管内光音響（ＩＶＰＡ）イメージング、光コヒーレンストモグラフィ（ＯＣＴ）、前方視ＩＶＵＳ（ＦＬ－ＩＶＵＳ）、血流予備量比（ＦＦＲ）法、冠血流予備量比（ＣＦＲ）、圧力、流量、温度、血流予備量比（ＦＦＲ）、瞬時血流予備量比（ｉＦＲ）、冠血流予備量比（ＣＦＲ）、心臓内超音波検査（ＩＣＥ）、前方視ＩＣＥ（ＦＬＩＣＥ）、血管内パルポグラフィ、経食道超音波、Ｘ線、磁気共鳴画像（ＭＲＩ）又はコンピュータ断層撮影（ＣＴ）の一つである、ことを特徴とする方法。

【請求項13】

マルチモダリティ医療処理システムであって、
データリポジトリと、
第一の医療モダリティコンポーネントと、
第二の医療モダリティコンポーネントと、
前記第一の医療モダリティコンポーネント及び前記第二の医療モダリティコンポーネントと通信するマルチモダリティ管理コンポーネントと、
少なくとも一つのコンピュータプロセッサによる実行のための複数の命令を記憶する、固定のコンピュータで読取り可能なストレージ媒体と、を備え、
第一の医療機器は、前記患者の血管内に挿入される形状及びサイズを有し、前記患者の血管内に配置され、可撓性の細長い部材を含む血管内カテーテル又はガイドワイヤと、第一の医療モダリティに関連づけられている第一の医療データを前記患者の血管内で取得するように構成されているデータ収集コンポーネントとを備え、
前記命令は：
前記第一の医療モダリティコンポーネントで、前記第一の医療機器からの前記患者から取得した前記第一の医療データを受信すること；
前記第一の医療データに固有の識別子を関連付けること；
前記第一の医療データを前記データリポジトリ内に記憶すること；
前記第二の医療モダリティコンポーネントで、第二の医療機器からの前記患者から取得した第二の医療データを受信することであって、当該第二の医療データは前記第一の医療モダリティとは異なる第二の医療モダリティに関連づけられる、受信すること；
前記第二の医療データに前記固有の識別子を関連付けること；
前記第二の医療データを前記データリポジトリ内に記憶すること；
前記患者の近くに配置されるベッドサイドコントローラのタッチ画面上のユーザインタフェース出力領域の同じ部分に、第一の選択可能なオプション及び第二の選択可能なオプションを同時に表示することであって、前記第一の選択可能なオプションは、前記第一の医療データの表示を制御し、前記第二の選択可能なオプションは、前記第二の医療データの表示を制御し、前記ベッドサイドコントローラは、前記第一の医療機器、前記第二の医療機器及び前記マルチモダリティ医療処理システムと通信し、前記マルチモダリティ医療処理システムのユーザインタフェースコンポーネントは、前記ベッドサイドコントローラの前記タッチ画面を描画し、前記ユーザインタフェースコンポーネントは、前記第一の医療モダリティコンポーネント及び前記第二の医療モダリティコンポーネントに関連付けられるデータを表示するように、前記マルチモダリティ管理コンポーネントにより利用される、表示すること；
前記第一の医療データを表示するために、前記第一の選択可能なオプションのユーザ選択を受信することであって、前記ユーザ選択は、前記ベッドサイドコントローラの前記タッチ画面上のユーザ入力を含む、受信すること；および
前記ユーザ選択を受信することに応答して、前記ベッドサイドコントローラの前記タッチ画面上の前記ユーザインタフェース出力領域内に前記第一の医療データを表示すること；に関する、システム。

【請求項14】

請求項１３記載のマルチモダリティ医療処理システムにおいて、前記命令は以下の命令を含むことを特徴とするシステム：
前記第二の医療データを表示するために、前記第二の選択可能なオプションの更なるユーザ選択を受信すること；および
前記ユーザインタフェースにて前記第一の医療データおよび前記第二の医療データを同時に表示すること。

【請求項15】

請求項１３記載のマルチモダリティ医療処理システムにおいて、前記第一の選択可能なオプション及び前記第二の選択可能なオプションを表示することは、前記第一の医療データおよび前記第二の医療データに関連づけられるメタデータ値によって決定された順序で、前記第一の選択可能なオプション及び前記第二の選択可能なオプションを表示することを含む、ことを特徴とするシステム。

【請求項16】

請求項１５記載のマルチモダリティ医療処理システムにおいて、前記メタデータ値は、医療モダリティ、医療データ取得時間、又は医師名の一つである、ことを特徴とするシ
ステム。

【請求項17】

請求項１３記載のマルチモダリティ医療処理システムにおいて、前記第一の選択可能なオプション及び前記第二の選択可能なオプションを表示することは、前記表現された医療データの前記医療モダリティのタイプによって体系化して、グループ内の前記第一の選択可能なオプション及び前記第二の選択可能なオプションを表示すること、を含むことを特徴とするシステム。

【請求項18】

請求項１３記載のマルチモダリティ医療処理システムにおいて、前記命令は、前記第一の選択可能なオプションに関連づけられるトグル要素のユーザ操作を受けて、当該第一の医療データについての追加情報を表示するための命令、をさらに含むことを特徴とするシステム。

【請求項19】

請求項１８記載のマルチモダリティ医療処理システムにおいて、前記追加情報は、前記第一の医療データから得た前記患者の一部分のプレビュー画像を含む、ことを特徴とするシステム。

【請求項20】

請求項１８記載のマルチモダリティ医療処理システムにおいて、前記追加情報は、前記第一の選択可能なオプションに隣接して表示される、ことを特徴とするシステム。

【請求項21】

請求項１８記載のマルチモダリティ医療処理システムにおいて、前記追加情報は、前記第一の医療データを生成した取得プロシージャのプルバックレートを含む、ことを特徴とするシステム。

【請求項22】

請求項１３記載のマルチモダリティ医療処理システムにおいて、前記命令は下記に関する更なる命令を含む、ことを特徴とするシステム：
前記第一の選択可能なオプションに関連づけられるトグル要素のユーザ操作を受けて、削除ボタンを表示すること；
前記削除ボタンのユーザ操作を受信すること；および
前記ユーザ操作を受信することに応答して、前記データリポジトリから前記第一の医療データを削除すること。

【請求項23】

請求項１３記載のマルチモダリティ医療処理システムにおいて、前記第一の医療データおよび前記第二の医療データは、単一のカテーテルラボセッション中に前記患者から取得されたことを特徴とするシステム。

【請求項24】

請求項１３記載のマルチモダリティ医療処理システムにおいて、前記第一および前記第二の医療モダリティは、それぞれ、血管内超音波（ＩＶＵＳ）イメージング、血管内光音響（ＩＶＰＡ）イメージング、光コヒーレンストモグラフィ（ＯＣＴ）、前方視ＩＶＵＳ（ＦＬ－ＩＶＵＳ）、血流予備量比（ＦＦＲ）、冠血流予備量比（ＣＦＲ）、圧力、流量、温度、血流予備量比（ＦＦＲ）、瞬時血流予備量比（ｉＦＲ）、冠血流予備量比（ＣＦＲ）、心臓内超音波検査（ＩＣＥ）、前方視ＩＣＥ（ＦＬＩＣＥ）、血管内パルポグラフィ、経食道超音波、Ｘ線、磁気共鳴画像（ＭＲＩ）又はコンピュータ断層撮影（ＣＴ）の一つである、ことを特徴とするシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示の実施形態は、一般的には医療機器の分野に関し、より具体的には、マルチモダリティ選択アーカイブシステムおよび方法に関する。

【背景技術】

【0002】

疾患の処置の成功レベルを診断し、および検証することにおけるイノベーションは、外部画像形成プロセスから内部診断プロセスへと移行している。具体的には、診断装置および方法は、カテーテル、またはカテーテル処置に使用されるガイドワイヤなどの可撓性の細長い部材の遠位端上に配置された超小型センサにより血管閉塞および他の脈管構造疾患を診断するために開発されてきた。例えば、公知の医療センシング技術は、血管造影、血管内超音波（ＩＶＵＳ）、前方視ＩＶＵＳ（ＦＬ－ＩＶＵＳ）、血流予備量比（ＦＦＲ）測定、冠血流予備量比（ＣＦＲ）測定、光コヒーレンストモグラフィ（ＯＣＴ）、経食道心エコー、および画像誘導療法を含む。これらの技術の各々は、異なる診断の状況により適したものであってもよい。処置の成功の可能性を高めるために、医療施設は、プロシージャの間にイメージング、処置、診断、およびカテーテルラボで手持ちのモダリティを検知することの多数のものがある。伝統的には、患者は、異なるモダリティに関連づけられる複数のプロシージャを経るとき、異なるモダリティの各々のための患者についての識別情報を入力する必要があり得る。言い換えれば、同一の患者情報を複数回入力しなければならないことがある。労力のこのような重複は事務的な誤りおよび無駄なリソースにつながることがある。さらに、患者の診断の不一致は、同じ患者のための個別の患者カルテを維持する各モダリティによって引き起こされることがある。

【0003】

加えて、各医療モダリティに関連づけられるデータは、伝統的に取得され、異なるハードウェアまたはソフトウェアのシステムで管理されている。その結果、医師は、第二の異なる医療モダリティに関連づけられるデータセットとは別のシステム上の第一の医療モダリティに関連づけられるデータセットをレビューすることができる。同じ患者から取得したデータをレビューするためのシステム間での移行は非効率的であり、かつ、不正確な診断につながる可能性がある。さらに、アーカイブ機構およびアーカイブストレージロケーションは、異なるモダリティ取得システム間で異なっていてもよい。例えば、患者のＩＶＵＳデータは、同じ患者のＯＣＴデータとは異なるロケーションで、かつ、異なるフォーマットでアーカイブされてもよく、これがデータの取得を非効率的、かつ、煩わしくしている。

【0004】

さらに、アーカイブされた医療データは、教育および他の非診断目的のために使用される場合、そのデータが取得された患者を識別することができる任意の情報を削除することが典型的である。伝統的には、アーカイブ前の識別情報の削除は、手動で選択したフィールドからの患者データを削除する技術者によって行われる。このように匿名化データは、多くの場合、発生しやすい誤りとなり、かつ、多くの場合、すべての識別情報が削除されることにはならない。

【0005】

したがって、既存の症例管理システムおよび方法は、一般的にそれらの意図する目的のために適切となっている一方で、それらはすべての点で完全に満足のいくものではなかった。

【発明の概要】

【0006】

一般に、本開示は、マルチモダリティ医療処理システムにおいて、選択的に患者データをアーカイブするようにすることを対象としている。ここで記載された方法およびシステムは、患者症例レベルで、モダリティデータセットレベルで、および／または個々の画像レベルで、選択的に医療データをアーカイブし、これにより、医師がアーカイブされた特定のデータに対する、微細なレベルの管理権を有するようになる。さらに、別の医療モダリティのデータセットを同時にアーカイブしてもよく、および異なる患者に対応する患者症例は同時にアーカイブして、アーカイブの効率を高めてもよい。

【0007】

ある例示的な態様において、本開示は、マルチモダリティ医療処理システムを用いて患者に関連づけられる医療データを選択的にアーカイブする方法を対象とする。この方法は、第一の医療機器からの患者から取得した第一の医療データを受信すること、この第一の医療データは第一の医療モダリティに関連づけられる；および第二の医療機器からの患者から取得した第二の医療データを受信すること、この第二の医療データは第一の医療モダリティとは異なる第二の医療モダリティに関連づけられる；を含む。この方法はまた、ユーザインタフェース上に、前記第一の医療データおよび前記第二の医療データの選択可能な表現を表示すること、この一つ以上の選択可能な表現のユーザ選択を受信すること、およびユーザインタフェースを介してアーカイブ要求を受信することを含む。さらに、この方法は、アーカイブ要求を受信することに応答して、アーカイブロケーションに、選択された一つまたは複数の選択可能な表現に対応する医療データをアーカイブすることを含む。

【0008】

別の例示的な態様において、本開示は、マルチモダリティ医療処理システムを対象とする。このシステムは、少なくとも一つのコンピュータプロセッサによる実行のための複数の命令を記憶する、固定の（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ）コンピュータで読取り可能なストレージ媒体を含む。この命令は、第一の医療機器からの患者から取得した第一の医療データを受信すること、当該第一の医療データは第一の医療モダリティに関連づけられる；および第二の医療機器からの患者から取得した第二の医療データを受信すること、当該第二の医療データは前記第一の医療モダリティとは異なる第二の医療モダリティに関連づけられる；に関する。この命令はまた、ユーザインタフェース上に、前記第一の医療データおよび前記第二の医療データの選択可能な表現を表示すること、一つ以上の前記選択可能な表現のユーザ選択を受信すること、および前記ユーザインタフェースを介してアーカイブ要求を受信することに関する。さらに、命令は、アーカイブ要求を受信することに応答して、前記選択された一つ以上の選択可能な表現に対応する医療データを、アーカイブロケーションへアーカイブすることに関する。

【0009】

さらに別の例示的な態様では、本開示は、マルチモダリティ医療処理システムを用いて患者に関連づけられる医療データを選択的にアーカイブする方法を対象とする。この方法は、第一の患者に対応した第一の患者症例を保持すること、この第一の患者症例は前記第一の患者から取得したマルチモダリティ医療データを含む；および第二の患者に対応する第二の患者症例を保持すること、この第二の患者症例は前記第二の患者から取得したマルチモダリティ医療データを含む；を含む。この方法はまた、ユーザインタフェース上に、前記第一の医療データおよび前記第二の医療データの選択可能な表現を表示すること、この一つ以上の選択可能な表現のユーザ選択を受信すること、およびユーザインタフェースを介してアーカイブ要求を受信することを含む。さらに、この方法は、アーカイブ要求を受信することに応答して、アーカイブロケーションへ、選択された一つまたは複数の選択可能な表現に対応する患者症例内のマルチモダリティ医療データをアーカイブすることを含む。

【0010】

別のコンテキストでは、本開示は、マルチモダリティ医療処理システムにおいて患者データを匿名化することに関する。ここで記載された方法およびシステムは、患者のプライバシーを保護するために、医療データから、それが取得された患者を識別することができる情報を自動的に削除する。具体的には、匿名化は、エラーや不完全な情報の削除を制限するために、人間の介入なしに行われる。さらに、別の医療モダリティのデータセットを同時に匿名化してもよく、および異なる患者に対応する複数の患者症例を同時に匿名化して、効率を高めてもよい。

【0011】

ある例示的な態様において、本開示は、マルチモダリティ医療処理システムにおいて、患者から取得した医療データを匿名化する方法を対象とする。この方法は、第一の医療機器からの前記患者から取得した第一医療データを受信すること、当該第一の医療データは第一の医療モダリティに関連づけられる；第二の医療機器からの前記患者から取得した第二の医療データを受信すること、当該第二の医療データは前記第一の医療モダリティとは異なる第二の医療モダリティに関連づけられる；および前記第一および第二の医療データを当該患者に対応する患者症例に追加すること、当該患者症例は前記患者についての識別情報を含む；を含む。この方法は、さらに、ユーザインタフェース上に、前記患者症例の選択可能な表現を表示すること、前記選択可能な表現のユーザ選択を受信すること、および前記ユーザインタフェースを介してユーザからの匿名化要求を受信することを含む。また、この方法は、前記匿名化要求を受信することに応答して、前記患者症例から識別情報を削除すること、当該削除は前記ユーザからの影響を受けないものであり、かつ、この削除の間、少なくともいくつかの前記識別情報が前記ユーザから隠される。

【0012】

別の例示的な態様において、本開示は、マルチモダリティ医療処理システムを対象とする。このシステムは、少なくとも一つのコンピュータプロセッサによる実行のための複数の命令を記憶する、固定のコンピュータで読取り可能なストレージ媒体を含む。この命令は、第一の医療機器からの前記患者から取得した第一の医療データを受信すること、当該第一の医療データは第一の医療モダリティに関連づけられる；および第二の医療機器からの前記患者から取得した第二の医療データを受信こと、当該第二の医療データは前記第一の医療モダリティとは異なる第二の医療モダリティに関連づけられる；に関する。この命令はまた、前記第一および前記第二の医療データを前記患者に対応する患者症例に追加すること、当該患者症例は前記患者についての識別情報を含む；ユーザインタフェース上に、前記患者症例の選択可能な表現を表示すること；および前記選択可能な表現のユーザ選択を受信することに関する。さらに、この命令は、前記ユーザインタフェースを介してユーザからの匿名化要求を受信すること；および前記匿名化要求を受信することに応答して、前記患者症例から識別情報を削除すること、当該削除は前記ユーザからの影響を受けないものであり、かつ、この削除の間、少なくともいくつかの前記識別情報が前記ユーザから隠される；に関する。

【0013】

さらに別の例示的な態様では、本開示は、マルチモダリティ医療処理システムにおいて医療データを匿名化する別の方法を対象とする。この方法は、第一の医療機器からの第一の患者から取得した第一の医療データを受信すること；この第一の医療データをこの第一の患者に対応する第一の患者症例に追加すること、当該第一の患者症例は当該第一の患者についての識別情報を含む；第二の医療機器からの第二の患者から取得した医療データを受信すること、当該第二の患者は前記第一の患者とは異なる；および第二の医療データをこの第二の患者に対応する第二の患者症例に追加すること、当該第二の患者症例は当該第二の患者についての識別情報を含む；を含む。この方法はまた、ユーザインタフェース上に、前記第一および前記第二の患者症例の選択可能な表現を表示すること、この両方の選択可能な表現のユーザ選択を受信すること、およびユーザインタフェースを介して匿名化要求を受信することを含む。この方法はまた、前記匿名化要求を受信することに応答して、第一および第二の患者症例のそれぞれから第一および第二の識別情報を削除することを含み、この削除はユーザからの影響を受けないものであり、かつ、この削除の間、第一または第二の識別情報がユーザから隠される。

【0014】

別のコンテキストでは、本開示は、マルチモダリティ医療処理システムにおいて、患者の医療データを表示することを対象とする。ここで記載された方法およびシステムは、単一のユーザインタフェース画面上の複数の異なるモダリティにおいて、医療データを提示し、ユーザインタフェースを見た医師が、モダリティを気にすることなく、患者に関連づけられる全ての取得データセットを管理することを可能にする。このように、医師が患者の医療データをレビューするのに費やさなければならない時間の量を低減し、より効率的な診断および処置につながる。さらに、異なる患者に対応する複数の患者症例は、単一のユーザインタフェース画面上に提示して、マルチの患者症例の管理を簡素化してもよい。

【0015】

ある例示的な態様において、本開示は、マルチモダリティ医療用処理システムを用いて、マルチモダリティ医療データを表示する方法を対象とする。この方法は、第一の医療機器からの患者から取得した第一の医療データを受信すること、当該第一の医療データは第一の医療モダリティに関連づけられる；前記第一の医療データをデータリポジトリ内に記憶すること；第二の医療機器からの当該患者から取得した第二の医療データを受信すること、当該第二の医療データは前記第一の医療モダリティとは異なる第二の医療モダリティに関連づけられる；および前記第二の医療データを前記データリポジトリ内に記憶すること；を含む。この方法はまた、ユーザインタフェース上で、前記第一の医療データおよび前記第二の医療データのそれぞれの選択可能な表現を表示すること；前記第一の医療データの前記選択可能な表現のユーザ選択を受信すること；および前記ユーザ選択を受信することに応答して、前記ユーザインタフェースにて前記第一の医療データを表示すること；を含む。

【0016】

別の例示的な態様において、本開示は、マルチモダリティ医療処理システムを対象とする。このシステムは、データリポジトリ、および少なくとも一つのコンピュータプロセッサによる実行のための複数の命令を記憶する、固定のコンピュータで読取り可能なストレージ媒体を含む。前記の命令は、第一の医療機器からの患者から取得した第一の医療データを受信すること、当該第一の医療データは第一の医療モダリティに関連づけられる；前記第一の医療データを前記データリポジトリ内に記憶すること；第二の医療機器からの当該患者から取得した第二の医療データを受信すること、当該第二の医療データは前記第一の医療モダリティとは異なる第二の医療モダリティに関連づけられる；および前記第二の医療データを前記データリポジトリ内に記憶すること；に関する。この命令はまた、ユーザインタフェース上で、前記第一の医療データおよび前記第二の医療データのそれぞれの選択可能な表現を表示すること；前記第一の医療データの前記選択可能な表現のユーザ選択を受信すること；および前記ユーザ選択を受信することに応答して、前記ユーザインタフェースにて前記第一の医療データを表示すること；に関する。

【0017】

さらに別の例示的な態様では、本開示は、マルチモダリティ医療用処理システムを用いて、マルチモダリティ医療データを表示する別の方法を対象とする。この方法は、第一の患者に対応した第一の患者症例を保持すること、当該第一の患者症例は第一の医療モダリティに関連づけられた第一のデータセットおよび当該第一の医療モダリティとは異なる第二の医療モダリティに関連づけられた第二のデータセットを含む；および第二の患者に対応する第二の患者症例を保持すること、当該第二の患者症例は前記第二の患者から取得した医療データを含む；を含む。この方法はまた、ユーザインタフェース上で、前記第一の患者症例および前記第二の患者症例のそれぞれの選択可能な表現を表示すること；第一の患者症例の選択可能な表現の第一のユーザ選択を受信すること；およびこの第一のユーザ選択を受信することに応答して、前記ユーザインタフェース上で前記第一のデータセットおよび前記第二のデータセットのそれぞれの選択可能な表現を表示すること；を含む。この方法はまた、前記第一のデータセットの選択可能な表現の第二のユーザ選択を受信すること；および前記第二のユーザ選択を受信することに応答して、前記ユーザインタフェース上で前記第一のデータセットを表示すること；を含む。

【0018】

別のコンテキストでは、本開示は、管理し、マルチモダリティ医療処理システムにおいて、患者データを管理し、および記憶することを対象とする。ここで記載された方法およびシステムは、患者から取得された全ての医療データを、固有の識別子が割り当てられている単一の患者レコードに記憶する。例えば、（ｉ）患者の識別情報、（ｉｉ）第一の診断プロシージャの間に取得されたデータ、および（ｉｉｉ）第二の、別の診断プロシージャの間に取得されたデータは、全て、同じ固有の識別子と関連付けて記憶し、患者症例のレビューおよび検索を簡素化することができる。これの態様として、患者の名前や生年月日などの患者情報を特定することのみが、単一の時間で開示されたシステムに入力される必要があることであり、これにより事務的な誤り可能性を減らすことになる。

【0019】

ある例示的な態様において、本開示は、マルチモダリティ医療処理システムにおけるマルチモダリティ医療症例管理の方法を対象とする。この方法は、患者についての識別情報を受信すること、当該患者に対応する固有の識別子を生成すること、および前記固有の識別子を前記識別情報と関連づけることを含む。この方法はまた、前記マルチモダリティ医療処理システムにて、第一の医療機器からの前記患者から取得された第一の医療データを受信すること、当該第一の医療データは第一の医療モダリティに関連付けられる；および前記第一の医療データをデータリポジトリ内に記憶すること、当該第一の医療データは当該データリポジトリ内の前記固有の識別子に関連付けられる；を含む。さらに、この方法は、前記マルチモダリティ医療処理システムにて、第二の医療機器からの前記患者から取得した第二の医療データを受信すること、当該第二の医療データは前記第一の医療モダリティとは異なる第二の医療モダリティに関連づけられる；および前記第二の医療データを前記データリポジトリ内に記憶すること、当該第二の医療データは前記データリポジトリ内の前記固有の識別子に関連付けられる；を含む。

【0020】

別の例示的な態様において、本開示は、マルチモダリティ医療処理システムを対象とする。このシステムは、データリポジトリ、および少なくとも一つのコンピュータプロセッサによる実行のための複数の命令を記憶する、固定のコンピュータで読取り可能なストレージ媒体を含む。この命令は、患者についての識別情報を受信すること、当該患者に対応する固有の識別子を生成すること、および前記固有の識別子を前記識別情報と関連づけることを含む、ことに関する。この命令はまた、前記マルチモダリティ医療処理システムと通信的に接続された、第一の医療機器からの前記患者から取得された第一の医療データを受信すること、当該第一の医療データは第一の医療モダリティに関連付けられる；および前記第一の医療データを前記データリポジトリ内に記憶すること、当該第一の医療データは前記データリポジトリにて、前記固有の識別子に関連付けられる；に関する。さらに、命令は、前記マルチモダリティ医療処理システムに通信的に接続された、第二の医療機器からの前記患者から取得した第二の医療データを受信すること、当該第二の医療データは前記第一の医療モダリティとは異なる第二の医療モダリティに関連づけられる；および前記第二の医療データを前記データリポジトリ内に記憶すること、当該第二の医療データは前記データリポジトリにて、前記固有の識別子に関連付けられる；に関する。

【0021】

さらに別の例示的な態様では、本開示は、マルチモダリティ医療処理システムを対象とする。このシステムは、第一の医療機器および第二の医療機器に通信的に接続されたコンピューティングシステムを含む。コンピューティングシステムは、患者についての識別情報を受信するように構成されたユーザインタフェースコンポーネント；前記第一の医療機器からの前記患者から取得した第一の医療データを受信するように構成された第一のモダリティワークフローコンポーネント、当該第一の医療データは第一の医療モダリティにある；および前記第二の医療機器からの前記患者から取得した第二の医療データを受信するように構成された第二のモダリティワークフローコンポーネント、当該第二の医療データは前記第一の医療モダリティとは異なる第二の医療モダリティにある；を含む。コンピュータシステムはまた、前記識別情報、前記第一の医療データおよび前記第二の医療データを固有の識別子に関連づけるように構成されたマルチモダリティ症例管理（ＭＭＣＭ）ワークフローコンポーネント；および前記識別情報、前記第一の医療データおよび前記第二の医療データを前記固有の識別子と関連づけて記憶するように構成されたデータリポジトリ；を含む。

【図面の簡単な説明】

【0022】

【図1】図１は、本開示の一実施形態に係るマルチモダリティ処理システムを含む医療システムを示す概略図である。

【図2】図２は、前記マルチモダリティ処理システムの一実施形態で実行される処理フレームワークを含む、医療システムの部分の機能ブロック図である。

【図3A】図３Ａは、図２の処理フレームワークの部分の機能ブロック図であり、前記部分は、マルチモダリティ症例管理に関連付けられている。

【図3B】図３Ｂは、各階層のデータレベルで固有の識別子を有する具体的な患者症例を示す図である。

【図4】図４は、本開示の態様による、図１の前記マルチモダリティ処理システム内の患者症例管理の単純化したフロー図である。

【図5】図５は、図１の前記マルチモダリティ処理システムによってレンダリングされた症例管理ユーザインタフェースのさまざまな画面の具体例である。

【図6】図６は、図１の前記マルチモダリティ処理システムによってレンダリングされた症例管理ユーザインタフェースのさまざまな画面の具体例である。

【図7】図７は、図１の前記マルチモダリティ処理システムによってレンダリングされた症例管理ユーザインタフェースのさまざまな画面の具体例である。

【図8】図８は、図１の前記マルチモダリティ処理システムによってレンダリングされた症例管理ユーザインタフェースのさまざまな画面の具体例である。

【図9】図９は、図１の前記マルチモダリティ処理システムによってレンダリングされた症例管理ユーザインタフェースのさまざまな画面の具体例である。

【図10】図１０は、図１の前記マルチモダリティ処理システムによってレンダリングされた症例管理ユーザインタフェースのさまざまな画面の具体例である。

【図11】図１１は、図１の前記マルチモダリティ処理システムによってレンダリングされた症例管理ユーザインタフェースのさまざまな画面の具体例である。

【図12】図１２は、図１の前記マルチモダリティ処理システムによってレンダリングされた症例管理ユーザインタフェースのさまざまな画面の具体例である。

【図13】図１３は、図１の前記マルチモダリティ処理システムによってレンダリングされた症例管理ユーザインタフェースのさまざまな画面の具体例である。

【図14】図１４は、図１の前記マルチモダリティ処理システム内の患者の医療データをアーカイブすること、および匿名化することを示す単純化したフロー図である。

【図15】図１５は、図１の前記マルチモダリティ処理システムによってレンダリングされた症例管理ユーザインタフェースの具体的なアーカイブ画面である。

【発明を実施するための形態】

【0023】

本開示の原理の理解を促進する目的で、図面に示された実施形態について言及し、および特定の言語が同じものを説明するために使用される。それでもなお、本開示の範囲の限定を意図するものではないことを理解されたい。記載された装置、システム、および方法へのいかなる変更や更なる修正、および本開示の原理のさらなる応用は、本開示が関係する当業者に正常に起こるであろうように、本開示内に完全に意図し、および包含される。
特に、一実施形態に関して説明した特徴、構成要素、および／またはステップが、本開示の他の実施形態に関して説明した特徴、構成要素、および／またはステップと組み合わせてもよいことが完全に意図される。しかしながら、簡潔にするために、これらの組み合わせの多数の繰り返しは個別には説明しない。

【0024】

図１は、本開示の一実施形態に係るマルチモダリティ処理システム１０１を含む医療システム１００を示す概略図である。一般的に、医療システム１００は、人間の生物学的生理学的および形態学的情報を取得し、および解釈し、および種々の症状の処置をまとめるために使用される様々な方法に敏感であるように設計された取得および処理要素の複数の形態の首尾一貫した統合および強化を提供する。より具体的には、システム１００において、マルチモダリティ処理システム１０１は、マルチモダリティ医療検出データの取得、管理、解釈、および表示するための統合デバイスである。ある実施形態では、処理システム１０１は、マルチモダリティ医療データを取得し、処理し、および表示するためのハードウェアおよびソフトウェアを有するコンピュータシステムであるが、他の実施形態では、プロセス処理システム１０１は、医療データを処理するために動作可能なコンピューティングシステムの他のいかなるタイプであってもよい。処理システム１０１がコンピュータワークステーションである実施形態では、システムは、マイクロコントローラまたは専用の中央処理ユニット（ＣＰＵ）、および固定のコンピュータで読取り可能なストレージ媒体例えばハードディスクドライブ、ランダムアクセス・メモリ（ＲＡＭ）および／またはコンパクトディスク読取専用メモリ（ＣＤ－ＲＯＭ）、およびビデオコントローラ例えばグラフィックス処理ユニット（ＧＰＵ）、およびネットワーク通信デバイス例えばイーサネット（登録商標）コントローラや無線通信コントローラなどの少なくともプロセッサを含む。その点で、いくつかの特定の例において、処理システム１０１は、本開示に記載のデータ取得および分析に関連づけられるプロシージャを実行するようにプログラムされている。したがって、データ取得、データ処理、機器制御、および／または本開示の他の処理または管理の態様に関連するプロシージャが、前記処理システムによってアクセス可能な、固定のコンピュータで読取り可能なストレージ媒体上または内に記憶された対応する命令を使用する処理システムによって実現されてもよいことが理解される。いくつかの例では、処理システム１０１は、ポータブル（例えば、ハンドヘルドの、運搬カート上等）である。さらに、いくつかの例において、処理システム１０１は、複数のコンピューティングデバイスを備えていることが理解される。その点で、本開示の異なる処理および／または管理の態様が、複数のコンピューティングデバイスを使用して、別々に、または予め定義されたグループ内で実現されてもよいことが特に理解される。複数のコンピューティングデバイスにわたる、以下で述べる処理および／または管理の態様のいかなる分割および／または組合せは、本開示の範囲内である。

【0025】

図示された実施形態では、医療システム１００は、管理室１０４を有するカテーテルラボ１０２内に、当該管理室に配置された処理システム１０１と配備される。他の実施形態では、処理システム１０１は、他の場所、例えばカテーテルラボ１０２、医療施設内の中央集中エリア、またはオフサイトの場所（すなわち、クラウド内）に位置していてもよい。カテーテルラボ１０２は、一般的に、プロシージャエリアを網羅する無菌領域を含むが、それに関連する管理室１０４は、プロシージャおよび／または医療施設の要求に応じて、無菌状態であっても、なくてもよい。カテーテルラボと管理室は、患者に、様々な医療検出プロシージャ、例えば血管造影、血管内超音波（ＩＶＵＳ）、仮想組織構造（ＶＨ）、前方視ＩＶＵＳ（ＦＬ－ＩＶＵＳ）、血管内光音響（ＩＶＰＡ）イメージング、血流予備量比（ＦＦＲ）測定、瞬時血流予備量比（ｉＦＲ）測定、Ｘ線血管造影（ＸＡ）イメージング、冠血流予備量比（ＣＦＲ）測定、光コヒーレンストモグラフィ（ＯＣＴ）、コンピュータ断層撮影、心臓内超音波検査（ＩＣＥ）、前方視ＩＣＥ（ＦＬＩＣＥ）、血管内パルポグラフィ（ｉｎｔｒａｖａｓｃｕｌａｒ ｐａｌｐｏｇｒａｐｈｙ）、経食道超音波、または当技術分野で公知の他のいかなる医療検知モダリティを行うために用いることができる。さらに、カテーテルラボおよび管理室は、患者に、一つ以上の処置または治療プロシージャ、例えば高周波アブレーション（ＲＦＡ）、凍結療法、アテローム切除術、または当技術分野で公知の他のいかなる医療処置を実行するために使用することができる。例えば、カテーテルラボ１０２で、患者１０６は、単一のプロシージャ、または一つ以上の検出プロシージャと組み合わせて、マルチモダリティプロシージャを受けることができる。いずれの場合も、カテーテルラボ１０２は、患者１０６から様々な異なる医療検知モダリティでの医療検出データを収集することができる医療用検知デバイスを含む複数の医療機器を含む。

【0026】

図１に示す実施形態では、機器１０８および１１０は、患者１０６に関する医療検出データを取得するために、臨床医によって利用することができる医療用検知デバイスである。特定の例において、デバイス１０８は、一つのモダリティでの医療検出データを収集し、デバイス１１０は、異なるモダリティでの医療検出データを収集する。例えば、それら機器は、それぞれ、圧力、流量（流速）、画像（超音波（例えば、ＩＶＵＳ）、ＯＣＴ、熱、および／または他のイメージング技術を用いて得られた画像を含む）、温度、および／またはそれらの組み合わせのうちの一つを収集することができる。それらデバイス１０８および１１０は、装置、機器、または血管内に配置されるように、または前記患者の外部に取り付けられるように、またはある間隔で患者を横切って走査されるような大きさおよび形状にしたプローブのいずれの形態であってもよい。

【0027】

図１に示す実施形態では、機器１０８は、一つ以上のセンサ、例えばＩＶＵＳ検出データを収集するためのフェーズドアレイトランスデューサーを含むようなＩＶＵＳカテーテル１０８である。いくつかの実施形態では、このＩＶＵＳカテーテル１０８は、ＩＶＵＳおよびＩＶＰＡ検出などのマルチモダリティ検出の可能性を持たせてもよい。さらに、図示の実施形態において、機器１１０は、ＯＣＴ検出データを収集するように構成された一つ以上の光センサを含むようなＯＣＴカテーテル１１０である。いくつかの例では、ＩＶＵＳ患者インタフェースモジュール（ＰＩＭ）１１２およびＯＣＴ－ＰＩＭ１１４が、それぞれ、ＩＶＵＳカテーテル１０８およびＯＣＴカテーテル１１０を医療システム１００に接続させる。具体的には、ＩＶＵＳ－ＰＩＭ１１２およびＯＣＴ－ＰＩＭ１１４は、それぞれ、ＩＶＵＳカテーテル１０８およびＯＣＴカテーテル１１０による患者１０６から収集された医療検出データを受信するように操作可能であり、かつ、受信したデータを管理室１０４の処理システム１０１に送信するように操作可能である。ある実施形態では、ＰＩＭ１１２および１１４は、アナログ－デジタル（Ａ／Ｄ）変換器を含み、かつ、デジタルデータを処理システム１０１に送信するが、他の実施形態では、これらのＰＩＭは、アナログデータを前記処理システムに送信する。ある実施形態では、ＩＶＵＳ－ＰＩＭ１１２およびＯＣＴ－ＰＩＭ１１４は、周辺コンポーネント相互接続高速（ＰＣＩｅ）データバス接続を介して医療検出データを送信するが、他の実施形態では、それらは、ＵＳＢ接続、サンダーボルト（Ｔｈｕｎｄｅｒｂｏｌｔ）接続、ファイヤーワイヤー（ＦｉｒｅＷｉｒｅ）接続、またはいくつかの他の高速データバス接続を介してデータを送信してもよい。他の例では、ＰＩＭは、ＩＥＥＥ８０２．１１のＷｉ－Ｆｉ標準規格、超広帯域（ＵＷＢ）規格、無線ファイヤーワイヤー（ＦｉｒｅＷｉｒｅ）、無線ＵＳＢ、または別の高速無線ネットワーク規格を用いた無線接続を介して処理システム１０１に接続してもよい。

【0028】

さらに、医療システム１００では、心電図（ＥＣＧ）デバイス１１６は、処理システム１０１に患者１０６からの心電図信号または他の血行動態データを送信するように操作可能である。いくつかの実施形態では、処理システム１０１は、ＥＣＧ１１６からＥＣＧ信号を使用して、カテーテル１０８および１１０で収集されたデータを同期するように操作可能である。さらに、血管造影システム１１７は、患者１０６の、Ｘ線、コンピュータ断層撮影（ＣＴ）、または磁気共鳴画像（ＭＲＩ）を収集し、処理システム１０１に送信するように操作可能である。ある実施形態では、血管造影システム１１７は、アダプタデバイスを介して処理システム１０１に通信的に接続されてもよい。このようなアダプタデバイスは、独自のサードパーティフォーマットから、処理システム１０１によって使用可能なフォーマットに、データを変換することができる。いくつかの実施形態では、処理システム１０１は、血管造影システム１１７からの画像データ（例えば、Ｘ線データ、ＭＲＩデータ、ＣＴデータ等）を、ＩＶＵＳおよびＯＣＴカテーテル１０８および１１０からの検出データと一緒に、同時登録するように操作可能であってもよい。その一態様として、同時登録は、検出データを用いて三次元画像を生成するために実行してもよい。

【0029】

ベッドサイドコントローラ１１８は、処理システム１０１に通信的に結合され、かつ、患者１０６を診断するために使用される特定の医療モダリティ（またはモダリティ）のユーザ管理権を提供する。現在の実施形態では、ベッドサイドコントローラ１１８は、ユーザ管理権および単一の表面についての診断画像を提供するタッチ画面コントローラである。しかしながら、代替の実施形態では、ベッドサイドコントローラ１１８は、非対話型ディスプレイおよび別個の操作装置、例えば物理的なボタンおよび／またはジョイスティックなどの両方を含んでもよい。統合医療システム１００では、ベッドサイドコントローラ１１８は、グラフィカルユーザインタフェース（ＧＵＩ）において、ワークフロー管理オプションおよび患者の画像データを提示するように動作可能である。図２に関連づけてより詳細に説明するように、ベッドサイドコントローラ１１８は、複数のモダリティに関連付けられたワークフローをそれを介して実行してもよい、ユーザインタフェース（ＵＩ）フレームワークサービスを含む。このように、ベッドサイドコントローラ１１８は、臨床医が単一のインタフェースデバイスを用いてマルチモダリティ医療検出データの取得を管理することを可能にするように、複数のモダリティのためのワークフローおよび診断画像を表示させることができる。

【0030】

制御室１０４内のメインコントローラ１２０は、処理システム１０１に通信的に接続され、および、図１に示すように、カテーテルラボ１０２に隣接している。現在の実施形態では、メインコントローラ１２０は、タッチ画面を含むベッドサイドコントローラ１１８と同様であり、それについて実行するＵＩフレームワークサービスを介して、別の医療検出モダリティに対応する、ＧＵＩベースのワークフローの多くを表示するように動作可能である。いくつかの実施形態では、メインコントローラ１２０は、ベッドサイドコントローラ１１８とは異なる態様のプロシージャのワークフローを同時に実行するために使用することができる。代替の実施形態では、メインコントローラ１２０は、非対話型ディスプレイおよびスタンドアロンの操作装置、例えばマウスやキーボードなどを含んでもよい。

【0031】

医療システム１００は、処理システム１０１に通信的に接続されたブームディスプレイ１２２をさらに含む。ブームディスプレイ１２２は、医療検出プロシージャに関連づけられる異なる情報を表示することがそれぞれに可能な、モニタのアレイを含んでもよい。例えば、ＩＶＵＳプロシージャの間、ブームディスプレイ１２２における一つのモニタには断層ビューを表示させてもよく、およびあるモニタにはサジタルビューを表示させてもよい。

【0032】

さらに、マルチモダリティ処理システム１０１は、データネットワーク１２５に通信的に接続されている。図示した実施形態では、データネットワーク１２５は、ＴＣＰ／ＩＰベースのローカルエリアネットワーク（ＬＡＮ）であるが、他の実施形態では、同期型光ネットワーク（ＳＯＮＥＴ）などの異なるプロトコルであってもよく、またはワイドエリアネットワーク（ＷＡＮ）であってもよい。処理システム１０１は、ネットワーク１２５を介して様々なリソースに接続することができる。例えば、処理システム１０１は、ネットワーク１２５を介して医療のデジタル画像処理と通信（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ：ＤＩＣＯＭ）システム１２６、画像アーカイブおよび通信システム（ＰＡＣＳ）１２７、病院情報システム（ＨＩＳ）１２８と通信することができる。さらに、いくつかの実施形態において、ネットワークコンソール１３０は、ネットワーク１２５を介してマルチモダリティ処理システム１０１と通信して、医師または他の医療専門家が、医療システム１００の態様に遠隔的アクセスすることを可能にしてもよい。例えば、ネットワークコンソール１３０のユーザは、患者の医療データ、例えばマルチモダリティ処理システム１０１によって収集した診断画像にアクセスでき、またはいくつかの実施形態では、ネットワークコンソール１３０のユーザは、カテーテルラボ１０２で行われている一つ以上のプロシージャをリアルタイムで監視しまたは管理することができる。ネットワークコンソール１３０は、ネットワーク接続、例えばＰＣ、ラップトップ、スマートフォン、タブレットコンピュータ、または医療施設の内外に位置する他のそのようなデバイスをしたコンピューティングデバイスのいかなる種類であってもよい。

【0033】

さらに、図示の実施形態では、上述したシステム１００の医療検出ツールが有線接続、例えば標準的銅リンク、光ファイバリンクを介して処理システム１０１に通信的に接続されるように示されるが、代替の実施形態では、当該ツールが無線接続、例えばＩＥＥＥ８０２．１１Ｗｉ－Ｆｉ標準規格、超広帯域（ＵＷＢ）規格、無線ファイヤーワイヤー（ＦｉｒｅＷｉｒｅ）、無線ＵＳＢ、または別の高速無線ネットワーク規格を介して処理システム１０１に接続してもよい。

【0034】

当業者は、上述した医療システム１００は、単に複数の医療モダリティに関連づけられる診断データを収集するように操作可能であるシステムの例示的な実施形態であることを認識するであろう。代替的な実施形態では、異なるおよび／または追加のツールを、医療システム１００に追加および／または異なる機能性に付与するように、処理システム１０１に通信的に接続してもよい。

【0035】

次に、図２は、マルチモダリティ処理システム１０１の一つの実施形態上で実行する処理フレームワーク２００を含む、医療システム１００の一部の機能ブロック図を示す。プロセスフレームワーク２００は、マルチモダリティ医療検出データの取得、処理、および表示を含む処理システム１０１の動作を制御する各種の独立型および依存型の実行可能なコンポーネントを含む。一般に、処理システム１０１の処理フレームワーク２００は、モジュール式であり、および拡張可能である。すなわち、フレームワーク２００は、それぞれ異なる機能および医療検出モダリティに関連づけられる、独立したソフトウェアおよび／またはハードウェアコンポーネント（または拡張）から構成されている。このモジュラー設計は、既存の機能に影響を与えることなく、または、基盤となるアーキテクチャを変更することを要求することなく、追加の医療検出モダリティおよび機能性に適合するために、前記のフレームワークが拡張することを可能にする。さらに、内部のメッセージングシステムは、前記のフレームワーク内のモジュール間の独立したデータ通信を容易にする。ある例では、処理フレームワーク２００は、処理システム１０内の固定のコンピュータで読取り可能なストレージ媒体に記憶された、コンピュータで実行可能な命令として実装してもよい。他の例では、処理フレームワーク２００は、処理システム１０１内で実行する、ハードウェアおよびソフトウェアモジュールとの組合せであってもよい。

【0036】

一般に、図２に示す実施形態において、処理フレームワーク２００は、複数の医療用検出デバイスから医療検出データ；プロセスデータ；またはメインコントローラ１２０、ベッドサイドコントローラ１１８または他のグラフィック表示デバイスを介した診断画像としての出力データ；を受信するように構成される、複数のコンポーネントを含む。フレームワーク２００は、処理システム１０１のコアシステム機能を管理し、および複数のモダリティ固有のコンポーネントをまとめる、いくつかのシステムレベルのコンポーネントを含む。例えば、フレームワーク２００は、患者の診断データの取得および処理に関連するハードウェアおよびソフトウェアモジュールを含む処理フレームワーク２００の実行可能な複数のコンポーネントの起動およびシャットダウンを調整するシステムコントローラ２０２を含む。システムコントローラ２０２はまた、例えば、任意のコンポーネントが予期せずに実行を停止しているかどうかを決定するために、フレームワーク２０２内で実行するコンポーネントの状態を監視するように構成されている。加えて、システムコントローラ２０２は、他のフレームワークのコンポーネントがシステム設定およびステータス情報を取得することができるインタフェースを提供する。ソフトウェアフレームワーク２００はモジュール式であるため、システムコントローラ２０２は、それが管理するフレームワーク内のコンポーネントとは独立しており、これにより、コンポーネントに発生したエラーおよび変更は、システムコントローラの実行または構造に影響を与えないようになる。

【0037】

上記のように、フレームワーク２００は、システムアーキテクチャを変更せずに、様々な拡張を追加し、および削除することができるように構成されている。ある特定の実施形態では、フレームワーク２００内で実行する拡張は、当該拡張の完全な機能を一緒に実装する、複数の実行可能なコンポーネントを含んでもよい。このような実施形態では、拡張は、拡張に関連づけられる様々な実行可能なコンポーネントを起動、終了、および監視するように動作可能である、システムコントローラ２０２に類似する拡張コントローラを含んでもよい。例えば、システムの起動時に、システムコントローラ２０２は、医療モダリティに対応する拡張コントローラを開始することができ、その後、拡張コントローラは、モダリティに関連付けられた実行可能なコンポーネントを順番に開始してもよい。ある実施形態では、拡張コントローラは、設定機構、例えば設定ファイルとして取得したパラメータを介して、システムコントローラ２０２が特定のモダリティまたは他のシステムタスクそれらを関連づけるまで、割り当てていなくてもよい。

【0038】

プロセスフレームワーク２００は、一般に、マルチモダリティ医療検出ワークフローの間、フレームワーク２０２の実行可能なコンポーネントの実行を統制するように構成されたワークフローコントローラコンポーネント２０４を含む。ワークフローコントローラコンポーネント２０４は、様々な異なる方法で処理フレームワーク２００によって実行されるワークフローを統制することができる。

【0039】

処理フレームワーク２００は、処理フレームワークの様々なコンポーネントから受信したメッセージをログにとるように構成されたイベントログコンポーネント２０６が含まれる。例えば、システムの起動中に、システムコントローラ２０２は、開始されたコンポーネントの状態に関するメッセージを、標準化されたフォーマットでログファイルにメッセージを順番に書き込むイベントログコンポーネント２０６に送信することができる。加えて、処理フレームワーク２００は、マルチモダリティ医療検出および／または処置ワークフローの間、フレームワーク２０２の様々な実行可能なコンポーネント間の限られたシステム資源の共有を管理するように構成されている、リソースアービターコンポーネント２０８を含む。例えば、マルチモダリティワークフローの間に、処理フレームワーク２０２内の異なるモダリティに関連づけられる、二つ以上のコンポーネントは、同じシステム資源、例えばメインコントローラ１２０上のグラフィカルディスプレイなどを争ってもよい。リソースアービターコンポーネント２０８は、様々な方法において、例えばロックシステム、キューシステム、または階層的なコリジョン（ｃｏｌｌｉｓｉｏｎ）管理システムを通じて、限られたシステム資源の共有をまとめることができる。

【0040】

ある実施形態では、システムコントローラ２０２、ワークフローコントローラコンポーネント２０４、イベントログコンポーネント２０６、およびリソースアービターコンポーネント２０８は、固定のコンピュータで読取り可能なストレージ媒体に記憶されたプロセッサ実行可能ソフトウェアとして実装してもよいが、代替の実施形態では、これらのコンポーネントが、ハードウェアコンポーネント、例えば特別な目的のマイクロプロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、マイクロコントローラ、グラフィックスプロセッシングユニット（ＧＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）として実装することができる。あるいは、処理フレームワークのコンポーネントは、ハードウェアおよびソフトウェアの組合せとして実装してもよい。実行可能なコンポーネントをＦＰＧＡに実装した、ある特定の実施形態では、システムコントローラ２０２は、動的にＦＰＧＡ内のプログラマブルロジックを変更して、その時点で必要な様々な機能を実装するように構成してもよい。この態様のように、処理システム１０１は、システムの起動中、システムコントローラによって割り当てられることができる一つ以上のアサインされていないＦＰＧＡを含んでもよい。例えば、処理システム１０１の起動時に、システムコントローラがＯＣＴ－ＰＩＭおよびそれに結合したカテーテルを検出した場合、このシステムコントローラまたはＯＣＴの機能に関連づけられる拡張コントローラは、アサインされていないＦＰＧＡの一つの中のプログラマブルロジックを動的に変換することができ、これにより、それがＯＣＴ医療データを受信および／または処理するための機能性を含むようになる。

【0041】

マルチモダリティ処理システム１０１で異なるハードウェアおよびソフトウェアコンポーネントの間でシステム間通信を容易にするために、処理フレームワーク２００は、さらに、メッセージ配信コンポーネント２１０を含む。ある実施形態では、メッセージ配信コンポーネント２１０は、フレームワーク２０２内のコンポーネントからメッセージを受信して、当該メッセージの意図された目標を決定し、タイムリーに当該メッセージを配信するように構成されている（すなわち、メッセージ配信コンポーネントは、メッセージの配信にアクティブな参加者（ｐａｒｔｉｃｉｐａｎｔ）である）。このような実施形態では、メッセージのメタデータはこの送信コンポーネントによって生成されてもよく、これは、宛先情報、ペイロードデータ（例えば、モダリティのタイプ、患者データ等）、優先度情報、タイミング情報、または他のそのような情報を含む。別の実施形態では、メッセージ配信コンポーネント２１０は、フレームワーク２０２内のコンポーネントからのメッセージを受信し、一時的に当該メッセージを記憶し、当該フレームワーク内の他のコンポーネントによる検索のためのメッセージを利用できるように構成されてもよい（すなわち、メッセージ配信コンポーネントは、受動的なキューである）。いずれの場合でも、メッセージ配信コンポーネント２１０は、フレームワーク２００で実行可能なコンポーネント間の通信を容易にする。例えば、システムコントローラ２０２は、メッセージ配信コンポーネント２１０を利用して、システムの起動シーケンス中に起動するコンポーネントの状態を調査し、そしてこの受信状態情報に関して、当該メッセージ配信コンポーネントを利用して、前記状態情報をイベントログコンポーネント２０６に送信して、これによりそれがログファイルに書き込むことができる。同様に、リソースアービターコンポーネント２０８は、メッセージ配信コンポーネント２１０を利用して、限られた資源へのアクセスを要求するコンポーネント間のリソーストークンを渡すことができる。

【0042】

メッセージ配信コンポーネント２１０が受動的なキューである、ある一実施例では、フレームワーク２００のコンポーネントは、メッセージの中に入ってくる医療検出データをパケット化させてもよく、および他のコンポーネント、例えば画像データ処理コンポーネントによって取得することができるメッセージ配信コンポーネントのキューに当該メッセージを送信することができる。さらに、いくつかの実施形態では、メッセージ配信コンポーネント２１０は、前記キューに最初に到着するメッセージがまず当該最初のキューを削除する、先入れ先出し（ファースト・イン・ファースト・アウト：ＦＩＦＯ）方式で、受信したメッセージを利用可能にするように動作可能である。代替の実施形態では、メッセージ配信コンポーネント２１０は、メッセージヘッダに記憶された優先度値によって、例えば異なる方法で使用可能なメッセージを作成することができる。ある実施形態では、メッセージ配信コンポーネント２１０は、処理システム１０１でランダムアクセスメモリ（ＲＡＭ）内に実装されるが、他の実施形態では、それは、不揮発性ＲＡＭ（ＮＶＲＡＭ）、二次ストレージ（例えば、磁気的ハードドライブ、フラッシュメモリなど）、またはネットワークベースのストレージに実装してもよい。さらに、ある実施形態では、メッセージ配信コンポーネント２１０に記憶されているメッセージは、ダイレクトメモリアクセス（ＤＭＡ）を使用して、処理システム１０１でソフトウェアおよびハードウェアモジュールによってアクセスすることができる。

【0043】

プロセスフレームワーク２０２は、さらに、コアシステムの機能性を提供する多くの追加のシステムコンポーネントを含み、この機能性はセキュリティコンポーネント２１２、マルチモダリティケース管理（ＭＭＣＭ）コンポーネント２１４、およびデータベース管理コンポーネント２１６を含む。ある特定の実施形態では、セキュリティコンポーネント２１２は、様々なセキュリティサービスを処理フレームワークの全体、および個々のコンポーネントに提供するように構成されている。例えば、ＩＶＵＳデータ取得ワークフローを実装するコンポーネントは、セキュリティコンポーネント２１２により公開される暗号化アプリケーションプログラミングインタフェース（ＡＰＩ）を利用して、ＩＶＵＳデータがネットワーク接続を介して送信される前に、このＩＶＵＳデータを暗号化してもよい。さらに、セキュリティコンポーネント２１２は、他のセキュリティサービス、例えばシステムレベルの認証および承認サービスを提供して、資格認定したユーザに対して前記処理フレームワークへのアクセスを制限することができ、および拡張可能なフレームワーク内の信頼できないコンポーネントの実行を防止することができる。マルチモダリティ症例管理（ＭＭＣＭ）コンポーネント２１４は、複数の医療モダリティに関連づけられる診断データを、より簡単に管理することができる統一された患者カルテへまとめ、および強化するように構成される。このような統一された患者カルテはより効率的にデータベースに記憶することができ、およびデータのアーカイブおよび検索により適する。その点では、データベース管理コンポーネント２１６は、フレームワーク２００の他のコンポーネントに対して透明なデータベースサービスを提供するように構成され、また、データベース接続および管理の詳細は、前記他のコンポーネントから隠される。例えば、ある特定の実施形態では、データベース管理コンポーネント２１６は、データベースストレージと検索機能を含むＡＰＩをフレームワーク２００のコンポーネントに公開してもよい。言い換えれば、医療検出ワークフローコンポーネントは、データベース接続の詳細を意識することなく、データベースコンポーネントを介して、ローカルおよび／またはリモートデータベース、例えばＤＩＣＯＭまたはＰＡＣＳサーバなどに診断データを送信することができる場合がある。他の実施形態では、データベース管理コンポーネント２１６は、追加のおよび／または別のデータベースサービス、例えばデータベースのアーカイブ用の診断データを準備するデータフォーマットサービスを実行するように動作可能としてもよい。

【0044】

上記のように、マルチモダリティ処理システム１０１の処理フレームワーク２００は、複数のモダリティに関連づけられる医療データを受信し、および処理するように動作可能である。この点において、処理フレームワーク２００は、それぞれ異なる医療検出および診断モダリティに関連づけられる、モジュール取得コンポーネントおよびワークフローコンポーネントを含む。例えば、図２に図示される実施形態に示すように、処理フレームワーク２００は、それぞれ、ＩＶＵＳ－ＰＩＭ１１２からのＩＶＵＳ医療検出データを受信し、および処理するように構成されている、ＩＶＵＳ取得コンポーネント２２０およびＩＶＵＳワークフローコンポーネント２２２を含む。処理フレームワーク２００のモジュールおよび拡張性にしたがって、任意の数の追加の取得およびワークフローのコンポーネントは、モダリティ「Ｎ」ＰＩＭ２２８からのデータを取得し、および処理する、モダリティ「Ｎ」取得コンポーネント２２４およびモダリティ「Ｎ」ワークフローコンポーネント２２６によって示されるように、独立してフレームワークに加えてもよい。例えば、ある特定の実施形態では、処理システム１０１は、ＯＣＴ－ＰＩＭ１１４、ＥＣＧシステム１１６、血流予備量比（ＦＦＲ）－ＰＩＭ、ＦＬＩＶＵＳ－ＰＩＭ、およびＩＣＥ－ＰＩＭに通信的に接続させてもよい。他の実施形態では、追加のおよび／または異なる医療検出、処置、または診断デバイスは、当該技術分野で知られている追加のおよび／または異なるデータ通信接続を介して処理システム１０１に接続されてもよい。このようなシナリオでは、ＩＶＵＳ－取得モジュール２２０に加えて、プロセスフレームワーク２００は、ＦＦＲ－ＰＩＭからＦＦＲデータを受信するためのＦＦＲ取得コンポーネント、ＦＬＩＶＵＳ－ＰＩＭからＦＬＩＶＵＳデータを受信するためのＦＬＩＶＵＳ取得コンポーネント、ＩＣＥ－ＰＩＭからＩＣＥデータを受信するためのＩＣＥ取得コンポーネントを含んでもよく、およびＯＣＴ取得コンポーネントはＯＣＴ－ＰＩＭからＯＣＴデータを受信するように動作可能である。このコンテキストでは、処理フレームワーク２００の実行可能なコンポーネントおよび通信的に接続された医療デバイス（例えば、ＰＩＭ、カテーテルなど）の間で通信された医療データは、センサによって収集されたデータ、制御信号、電力レベル、デバイスフィードバック、および検出、処置または診断プロシージャに関する他の医療データを含んでもよい。さらに、ある特定の実施形態では、患者処置デバイスは、処理システム１０１に通信的に接続されてもよく、例えば、高周波アブレーション（ＲＦＡ）、凍結療法、またはアテローム切除術および任意のＰＩＭまたはそのような処置プロシージャに関連づけられる他の制御装置に関連づけられるデバイスであってもよい。このような実施形態では、モダリティ「Ｎ」取得コンポーネント２２４およびモダリティ「Ｎ」ワークフローコンポーネント２２６は、例えば制御信号の中継により、電力レベルの中継により、デバイスフィードバックの受信により、処置デバイス上に配置されたセンサにより収集されたデータの受信により、前記の処置デバイスと通信し、および管理するように構成することができる。

【0045】

ある実施形態では、一度、取得コンポーネント２２０および２２４が、接続された医療用検出デバイスからデータを受信すると、当該コンポーネントは、システム間の通信を容易にするために、データをメッセージにパケット化する。具体的には、前記コンポーネントは、各メッセージがデジタル化された医療検出データおよびヘッダの一部を含む入力デジタルデータストリームからの複数のメッセージを作成するように動作可能としてもよい。メッセージヘッダは、メッセージ内に含まれる医療検出データに関連づけられる、メタデータを含む。さらに、いくつかの実施形態では、取得コンポーネント２２０および２２４は、デジタル化された医療検出データがフレームワーク２００の他の部分に伝達される前に、何らかの方法で、そのデジタル化された医療検出データを操作するように動作可能であってもよい。例えば、前記取得コンポーネントは、システム間の通信をより効率的にする、またはデータの後処理を支援するために、当該データを正常化、スケール化またはその他フィルタリングするために、前記検出データを圧縮してもよい。いくつかの実施形態では、この操作は、モダリティ固有であってもよい。例えば、ＩＶＵＳ－取得コンポーネント２２０は、冗長ＩＶＵＳ－データがその後の工程で処理時間を節約するために渡される前に、当該冗長ＩＶＵＳ－データを特定し、破棄してもよい。前記取得コンポーネント２２０および２２４は、追加でデータの取得に関連する多くのタスクを実行してもよく、このタスクとしては、データバス（例えば、ＰＣＩｅ、ＵＳＢ）により発生した割り込みに応答すること、どの医療検出デバイスが処理システム１０１と接続しているか検出すること、接続された医療検出デバイスについての情報を取得すること、検知デバイス固有のデータを記憶すること、および前記データベースにリソースを割り当てることが挙げられる。上記のように、前記のデータ取得コンポーネントは、互いに独立しており、および他のコンポーネントによってデータ取得を中断することなく、インストールまたは削除することができる。加えて、取得コンポーネントは、基礎となるデータバスソフトウェア層から独立している（例えば、ＡＰＩの使用を通じて）、および第三者医療検出デバイスからのデータの取得を容易にするために第三者によって作成したものであってもよい。

【0046】

前記処理フレームワークの前記ワークフローコンポーネント、例えばＩＶＵＳワークフローコンポーネント２２２は、メッセージ配信コンポーネント２１０を介して各取得コンポーネントからの未処理の医療検出および／または診断データを受信する。一般に、前記ワークフローコンポーネントは、例えば算出時間にデータ収集を開始および停止し、および取得され、かつ、処理された患者データを表示し、および臨床医によって取得された患者データの分析を容易にすることなどによって、医療検出データの取得を管理するように構成されている。この態様として、前記ワークフローコンポーネントは、患者から収集した未処理の医療データを、診断画像または臨床医が患者の状態を評価することを可能にする、他のデータフォーマットに変換するように動作可能である。例えば、ＩＶＵＳワークフローコンポーネント２２２は、ＩＶＵＳ－ＰＩＭ１１２から受信したＩＶＵＳデータを解釈し、およびこのデータを人間が読み取り可能なＩＶＵＳ画像に変換することができる。ある実施形態では、フレームワーク内のソフトウェアスタックは、ワークフローコンポーネント２２２および当該フレームワークの他の前記ワークフローコンポーネントがシステム資源、例えばコンピュータ資源、メッセージ配信コンポーネント２１０、および通信資源にアクセスするために呼び出すときに使用する、一連のＡＰＩを公開してもよい。取得されたデータを処理した後、当該モダリティ中心のワークフローコンポーネントは、この処理されたデータを含む一つ以上のメッセージを、フレームワーク２００内の他のコンポーネントへ、メッセージ配信コンポーネント２１０を介して、送信してもよい。いくつかの実施形態では、このようなメッセージを送信する前に、コンポーネントは、ヘッダに、当該メッセージが処理されたデータを含むことを示すフラグを挿入してもよい。さらに、いくつかの実施形態では、医療検出データを処理した後、当該コンポーネントは、データベース管理コンポーネント２１６を利用して、当該処理されたデータを、アーカイブシステム、例えばローカルに接続された大容量ストレージデバイスまたはネットワークベースのＰＡＣＳサーバ１２７へ送信することもできる。プロセスフレームワーク２００のモジュール構造によれば、ワークフローコンポーネント２２２および２２６は、互いに独立しており、および他のコンポーネントを中断させることなくインストールまたは削除することができ、およびサードパーティにより書き込まれてもよい。さらに、これらの独立性により、これらコンポーネントは、複数の医療検出デバイスからのシグナリングおよびイメージングデータを、同時に処理するように動作可能となることができる。

【0047】

プロセスフレームワーク２００は、さらに、任意の数のデータ収集ツール２３４からのデータを取得し、および処理するように、およびこの取得したデータを前記フレームワーク内の他の取得コンポーネントの一つにより取得されたデータと同時登録するように、構成された、同時登録インタフェースコンポーネント２３０および同時登録ワークフローコンポーネント２３２を含む。より詳細には、同時登録インタフェースコンポーネント２３０は、いかなる数のモダリティ、例えばＥＣＧデバイス１１６または図１の血管造影システム１１７に関連付けられる、医療データ取得ツールと通信的にインタフェースするように動作可能となることができる。ある特定の実施形態では、インタフェースコンポーネント２３０は、入ってくるモダリティデータを標準化し、および／または変換するように動作可能とすることができ、これにより、そのデータは処理システム１０１により取得された他の検出データと同時登録することができる。医療データは、同時登録インタフェースコンポーネント２３０により取得されるものであるため、同時登録ワークフローコンポーネント２３２は、例えば空間的に、または時間的に医療検出デバイス間でのデータ収集を同期させることにより、および空間的および時間的な登録マーカに基づいて二つ以上の取得されたデータセットを整列させることにより、および同時登録された診断画像または臨床医が患者の状態を評価することを可能にする、人間が読み取り可能な他のデータを生成することにより、異なるモダリティからのデータの同時登録を容易にするように構成される。さらに、他の実施形態では、同時登録ワークフローコンポーネント２３２は、前もって収集した２－Ｄ画像または３次元モデルを用いて、二次元（２－Ｄ）または三次元（３－Ｄ）空間でのカテーテル収集データを、空間的に同時登録するように動作可能としてもよい。例えば、カテーテルベースの検出ツールは、検出プロシージャの間に位置データを生成するために追跡される基準を含んでもよく、および同時登録ワークフローコンポーネント２３２は、前もって取得されたＭＲＩデータに対して、この位置データを登録することができる。さらに、同時登録ワークフローコンポーネント２３２は、フレームワーク２００内のネイティブな取得コンポーネント、例えばＩＶＵＳ取得コンポーネント２２０および当該モダリティ「Ｎ」取得コンポーネント２２４により取得されたマルチモダリティデータの同時登録を容易にすることができる。加えて、いくつかの実施形態では、リアルタイムクロックが、同時登録ワークフローコンポーネント２３２に組み込まれてもよい。
米国仮特許出願第６１／４７３５９１、発明の名称「分散型医療検出システムおよび方法」は、医療検出データ収集の時間的に同期することについてさらに詳細に開示しており、および本開示にその全体が参考として援用される。

【0048】

図１に関連して上述したように、処理システム１０１を利用する臨床医は、ワークフローを管理し、およびメインコントローラ１２０およびベッドサイドコントローラ１１８を通じて診断画像をレビューすることができる。メインコントローラ１２０およびベッドサイドコントローラ１１８は、複数のユーザインタフェース（ＵＩ）拡張（またはコンポーネント）をサポートするユーザインタフェース（ＵＩ）のフレームワークサービス２４０および２４２をそれぞれ含む。一般的には、ＵＩフレームワークサービス２４０および２４２によってサポートされるＵＩの拡張機能は、それぞれ、医療検出モダリティに対応し、および関連づけられる取得ワークフローの管理し、および処理された検出データを表示するためのユーザインタフェースをレンダリングように動作可能である。処理フレームワーク２００と同様に、ＵＩフレームワーク２４０および２４２は、互いに独立するＵＩ拡張機能をそれらがサポートしている点で、拡張可能である。すなわち、そのモジュール設計は、ＵＩフレームワーク２４０及び２４２が、既存のユーザインタフェースに影響を与えることなく、または基礎となるＵＩアーキテクチャを変更することを要求することなく追加の医療検出モダリティユーザインタフェースに適合するために拡張することを可能にする。図示の実施形態では、メインコントローラ１２０は、コアシステムの管理および構成オプションを含むユーザインタフェースをレンダリングするシステムＵＩ拡張２４４を含む。例えば、臨床医は、システムＵＩ拡張２４４によってレンダリングされるユーザインタフェースを使用して、処理システム１０１を起動し、停止し、あるいは他の管理をすることができる。ある実施形態では、メインコントローラ１２０のコンポーネントは、処理フレームワーク２００の一部と考えることができる。ＩＶＵＳ－ＵＩ拡張２４６および２４８は、それぞれ、メインコントローラ１２０およびベッドサイドコントローラ１１８のためのユーザインタフェースをレンダリングする。例えば、ＩＶＵＳ－ＵＩ拡張２４６および２４８は、ＩＶＵＳワークフローを管理するために使用される、タッチ画面ボタンをレンダリングし、および表示してもよく、およびＩＶＵＳワークフローコンポーネント２２２によって作成されたＩＶＵＳ診断画像をレンダリングし、および表示することもできる。同様に、当該モダリティ「Ｎ」のＵＩ拡張機能２５０および２５２は、当該モダリティ「Ｎ」のワークフローに関連付けられる管理および画像をレンダリングする。

【0049】

ある実施形態では、ＵＩフレームワークサービス２４０および２４２は、ＵＩ拡張がシステム資源、例えばルック・アンド・フィールツールボックスおよびエラー処理資源にアクセスするために呼び出すときに使用する、ＡＰＩを公開してもよい。ルック・アンド・フィール・ツールボックスＡＰＩは、前記ＵＩ拡張が、異なる当該モダリティワークフローのための共通のボタン、並列ワークフローフォーマット、およびデータプレゼンテーションスキームで標準化されたユーザインタフェースを提示することを可能にする。このように、臨床医は、追加のユーザインタフェースの訓練なしで、取得モダリティ間で、より容易に移行することができる。さらに、同時登録ＵＩ拡張は、複数のモダリティからの処理された画像またはシグナリングデータを提示し、および／または組み合わせることができる。例えば、ＵＩ拡張は、心電図（ＥＣＧ）はＩＶＵＳ画像データに隣接する波を表示してもよく、および前もってＯＣＴ画像上に描いておいた境界線を重ねたＩＶＵＳ画像を表示してもよい。さらに、いくつかの実施形態では、ＵＩフレームワークサービス２４０および２４２は、ＵＩ拡張を同時に実行するように調整するためのマルチタスクフレームワークを含んでもよい。例えば、処理システム１０１が同時に一つより多くのモダリティに関連づけられるデータを取得する場合、ＵＩフレームワークサービス２４０および２４２は、所望のユーザインタフェースを選択するように、モダリティ選択画面をユーザに提示してもよい。

【0050】

ＵＩフレームワークサービス２４０は、メッセージ配信コンポーネント２１０を介して処理フレームワーク２００のコンポーネントと通信する。図２に示す実施形態に示すように、ベッドサイドコントローラ１１８は、ネットワーク接続２５４を介して処理フレームワーク２００に、通信的に接続されてもよい。このネットワーク接続２５４は、いかなる有線または無線ネットワーク接続、例えばイーサネット（登録商標）接続またはＩＥＥＥ８０２．１１のＷｉ－Ｆｉ接続であってもよい。あるいは、メインおよびベッドサイドコントローラ１２０および１１８の一つまたは両方は、処理フレームワーク２００と、ローカルバス接続、例えば（ＰＣＩｅ）データバス接続、ＵＳＢ接続、サンダーボルト（Ｔｈｕｎｄｅｒｂｏｌｔ）接続、ＦｉｒｅＷｉｒｅ接続、またはいくつかの他の高速データバス接続を介して通信してもよい。さらに、図２に示す実施形態では、前記ベッドサイドコントローラは、ベッドサイドコントローラ１１８内のＵＩ拡張および処理フレームワーク２００内のコンポーネントの間でのメッセージベースの通信を容易にするように構成されている、メッセージ配信コンポーネント２５６を含む。ある特定の実施形態では、メッセージ配信コンポーネント２５６は、ネットワーク通信パケットからの診断画像データを、これらがこのネットワーク接続２５４経由で到着する際に、抽出してもよい。

【0051】

プロセスフレームワーク２００は、臨床医が、マルチモダリティ処理システム１０１で実行されるワークフローを、アクセスし、および／または管理することを可能にする、追加のコンポーネントを含む。例えば、フレームワーク２００は、ネットワークコンソール１３０（図１）を処理フレームワーク２００に通信的に接続する、リモートアクセスコンポーネント２６０を含む。ある実施形態では、リモートアクセスコンポーネント２６０は、ネットワークコンソール１３０に、処理システム１０１の管理機能をエクスポートするように動作可能であり、これにより、当該ネットワークコンソールがそのユーザインタフェース内でワークフロー管理機能を提示することができる。ある特定の実施形態では、リモートアクセスコンポーネント２６０は、ネットワークコンソール１３０からのワークフローコマンドを受信し、リモートアクセスワークフローコンポーネント２６２に転送する。このリモートアクセスワークフローコンポーネント２６２は、コマンドセットおよび診断データを、リモートユーザーがネットワークコンソール１３０を介してアクセスできるところに、指示することができる。さらに、レガシー管理コンポーネント２６４およびレガシー管理ワークフローコンポーネント２６６は、レガシーコンソール２６８（例えば、ボタンコンソール、マウス、キーボード、スタンドアロンモニター）のユーザに、モダリティワークフロー管理およびデータへのアクセスのいくつかのレベルを提供する。

【0052】

ある実施形態では、処理フレームワーク２００のコアシステムコンポーネントおよびこのような当該モダリティに関連するコンポーネントのような追加のコンポーネントは、固定のコンピュータで読取り可能なストレージ媒体に記憶されたプロセッサ実行可能ソフトウェアとして実装してもよいが、代替の実施形態では、これらのコンポーネントが、ハードウェアコンポーネント、例えば特別な目的のマイクロプロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、マイクロコントローラ、グラフィックスプロセッシングユニット（ＧＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）として実装することができる。あるいは、処理フレームワークのコンポーネントは、ハードウェアとソフトウェアの組み合わせとして実装されてもよい。

【0053】

当業者は、図２の処理フレームワーク２００は、単に例示的な実施形態であること、および、代替の実施形態では、前記フレームワークが異なるおよび／または追加コンポーネントを含むことができ、様々な医療検出ワークフローを実行するように構成されること、を認識するであろう。例えば、処理フレームワーク２００は、ヒト血管の狭窄を評価するために構成される実行可能コンポーネント、またはコンピュータ支援の外科手術または遠隔管理された手術の管理を容易にするように構成された実行可能コンポーネントを含んでもよい。

【0054】

次に、図３Ａは、マルチモダリティ症例管理（ＭＭＣＭ）ワークフローコンポーネント２１４に関連づけられる処理フレームワーク２００の一部の機能ブロック図を示す。上述したように、マルチモダリティ症例管理（ＭＭＣＭ）コンポーネント２１４は、複数の医療モダリティに関連づけられる患者医療データを、より簡単に管理することができる統一された患者カルテへまとめ、および強化するように構成される。具体的には、図示の実施形態において、ＭＭＣＭワークフローコンポーネント２１４は、固有の識別子（ＵＩＤ）を、患者症例の全ての態様と関連づけ、この患者症例には、医療機器から取得した医療データおよび患者、取得したデータおよびプロシージャを記述するメタデータ（未取得データ）の両方を含む。ＵＩＤは数字、英数字キー、１６進数の値、または患者を独自に同定するのに用いることができる他のいかなるアイテムであってもよい。ＵＩＤに関連づけられるメタデータは、患者についての識別情報（例えば、患者の名前、性別、生年月日、ソーシャルセキュリティナンバー、血液型など）、および取得された医療データに関連づけられる派生データ（測定、血管内画像上で生成された境界線など）、取得された医療データから生成された画像に関する注釈（血管名、医師ノート、内部構造識別など）、および患者に対してなされたプロシージャについての情報（例えば、プロシージャ時間、プロシージャ位置、医師名、用いた医療機器など）を含む。共通の固有の識別子を、患者のメタデータおよび取得されたデータの両方に割り当てることは、効率的なデータ検索および分析に必要とされる強い関連性を創り出す（すなわち、測定は単一の血管内画像に関連づけられる必要があり；血管名の注釈はマルチフレーム画像の全てのフレームに関連づけられている必要がある）。さらに、図示の実施形態では、共通の固有の識別子は、データの当該モダリティにかかわらず、患者から取得した全てのデータに割り当てられる。例えば、患者は、典型的には、複数の異なる診断プロシージャを経験することになり、これにより、医師がより完全に患者の状態を評価することができるようになる。その点で、患者に対してＩＶＵＳプロシージャの間に取得されたデータは、患者に関するＯＣＴプロシージャの間に取得されたデータと同じＵＩＤを割り当てることができる。いくつかの例では、プロシージャは、単一のカテーテルラボセッションの間で実行されていてもよく、および他の例では、プロシージャは、時間、日、月、または年で区切られた、複数のセッションの間に実行されてもよい。いずれの場合においても、同じ患者から取得された全ての診断および／または処置データは、改善された患者の診断および、最終的には、処置のために同一の固有の識別子を割り当てられる。

【0055】

図３Ａに示すＭＭＣＭワークフローコンポーネント２１４は、患者症例に関連する、全てのメタデータおよび取得したデータに、共通のＵＩＤの割り当てについて整理する。具体的には、当該モダリティ固有のワークフローコンポーネント、例えばＩＶＵＳワークフローコンポーネント２２２およびモダリティＮワークフローコンポーネント２２６は、ＭＭＣＭワークフローコンポーネント２１４を利用して、医療器具、例えばカテーテルベースのトランスデューサを用いて患者から取得された医療データを記憶する。ある実施形態では、ＭＭＣＭワークフローコンポーネント２１４は、ストレージ関連機能のライブラリを、前記モダリティワークフローコンポーネントに公開して、これにより、これらは記憶し、および指定された記憶媒体から患者データを取り出すことができる。このように、取得したデータのストレージは、各モダリティコンポーネントで独自のストレージメカニズム、例えばファイル管理メカニズムおよびデータフォーマットメカニズムなどを実装するというよりむしろ、統一された方法で扱われる。この一態様としては、ＭＭＣＭワークフローコンポーネント２１４が、モダリティ固有のコンポーネントからのストレージ／検索要求を受信するとき、それは単一の患者のメタデータのセットを複数の異なるモダリティにわたって患者から取得した医療データと一緒にまとめることができる。

【0056】

ＭＭＣＭワークフローコンポーネント２１４は、当該モダリティ固有のコンポーネントによって呼び出されるライブラリのストレージおよび検索機能を実装するＭＭＣＭロジックコンポーネント３０２を含む。ある実施形態では、ＭＭＣＭロジックコンポーネント３０２は、階層的なステートマシーンとして実装することができるが、他の実施形態では、それは実行ファイルまたは別の論理コンテナとして実装されてもよい。ＭＭＣＭロジックコンポーネント３０２は、固有の識別子を生成し、それらを患者症例内の新たに取得したデータおよびメタデータに関連づける。ある実施形態では、一つの患者症例が処理フレームワーク２００内のタイムで「オープン」にすることができ、およびＭＭＣＭロジックコンポーネント３０２は、医師により取得され、または入力された全てのデータが、当該症例がオープンな間、同じスタディ（症例）のＵＩＤに関連づけられることを保証する。患者からデータを取得する診断プロシージャの間に、ＭＭＣＭロジックコンポーネント３０２は、取得したデータに当座のＵＩＤを割り当て、データリポジトリ３０４に格納する。
データリポジトリ３０４は、いかなるタイプのロジックデータコンテナ、例えばデータベースを実装してもよく、およびいかなるタイプのストレージ媒体上、例えばマルチモダリティ処理システム１０１上のハードドライブとしてまたはネットワーク上のストレージロケーションにて記憶されてもよい。ある実施形態では、前記リポジトリは共有患者情報管理システム（ＳＰＩＭＳ）を介してアクセスされたＸＭＬデータベースである。図３Ａに示すように、患者のメタデータ（例えば、識別情報、画像注釈など）およびモダリティにわたって取得した診断データの両方は、同一のＵＩＤに関連づけられて、リポジトリ３０４に記憶される。例えば、図３Ａに示すように、ＵＩＤ１は、メタデータ３０６、ＩＶＵＳデータ３０８、ＯＣＴデータ３１０、およびモダリティＮデータ３１２を含む患者症例に関連づけられている。当業者は、リポジトリ３０４内のデータの編成は単なる一具体例であること、および患者症例に関連づけられる全てデータは、多数の異なる方法で、例えばデータベーステーブル、データ構造、ハッシュテーブル、スタック、キュー、リンクリストなどと、ＵＩＤとでまとめることができることを認識するであろう。ある例では、医療モダリティに関連づけられる全てのデータは、論理データパーティション内で一緒に記憶されるが、モダリティデータのグループ内の各データセットが、それが属する患者症例に対応するＵＩＤと関連づけられてもよい。さらに、取得した患者データは、多くの異なるフォーマットで、リポジトリ３０４に記憶されてもよい。例えば、それは取得する医療機器によって生成されたフォーマットから変わらない「生」の形態で記憶されてもよく、または処理されたフォーム、例えば血管内のＩＶＵＳ画像として、記憶されてもよい。上述したように、１つのＵＩＤに関連づけられるデータは、複数の臨床セッションにわたって収集してもよく、または単一のセッションの間に収集されてもよい。

【0057】

さらに、いくつかの実施形態では、患者カルテ内のデータの各階層レベルは、その固有の識別子を有し、これにより、全ての患者データを一緒にリンクする固有の識別子のチェーンが存在する。各データレベルで固有の識別子を有する患者症例の具体例を、図３Ｂに示す。例えば、取得されまたは患者に関連づけられる全てのデータを含む患者症例は、図３Ｂに示すような患者症例ＵＩＤとして、グローバルな固有の識別子を有することができる。患者症例は、一つ以上の患者スタディを含んでいてもよく、各患者スタディは、カテーテルラボセッション中に収集されたすべてのデータを含む。各患者スタディでは、グローバルな患者症例固有の識別子にリンクされている、独自の固有の識別子を含んでもよい。さらに、次に、それぞれの患者スタディは、特定の医療モダリティのデータから構成される一つ以上のデータセット（またはシリーズ）を含むことができる。例えば、患者スタディは、全て単一のカテーテルラボセッション中に取得した、ＩＶＵＳシリーズ、ＯＣＴシリーズ、およびＦＦＲシリーズを含んでもよく、各シリーズは、患者スタディ固有の識別子にリンクされている、独自の固有の識別子を有する。加えて、各データセットまたはシリーズは、一つ以上の診断画像を含んでもよく、各画像は、データセット固有の識別子にリンクされている、独自の固有の識別子を有する。このように、各データレベルでの固有の識別子は、患者症例内の患者メタデータ、患者スタディ、データセット（シリーズ）、および個々の画像を一緒にリンクする、オーナーシップのチェーンを形成する。

【0058】

加えて、患者症例に含まれる全てのデータに固有の識別子の利用は、マルチモダリティ処理システム１０１内のデータ管理を簡素化する。このスキームは、全患者症例、または患者症例内の個々のデータの一部を、特定し、およびアドレス指定されることを許可する。例えば、医師による患者データをレビューする際に、ＭＭＣＭロジックコンポーネント３０２は、当該患者症例に関連づけられるＵＩＤを使用してリポジトリの単一のアクセスで、モダリティを気にすることなく、全ての取得した診断データを取り出すことができる。または、ＭＭＣＭロジックコンポーネント３０２は、画像に関連づけられる固有の識別子を使用して、ただ一つの画像を取り出すことができる。患者データが不要になった場合も、同様に、患者に関連づけられる全ての医療データは、モダリティを気にすることなく、当該患者に関連づけられるＵＩＤを使用して同時に削除することができる。

【0059】

加えて、ＭＭＣＭロジックコンポーネント３０２は、患者データをアーカイブする要求が医師によってなされたとき、データアーカイブコンポーネント３１４と対話することができる。具体的には、図１４－１５に関連してより詳細に説明するように、医師は、ストレージ媒体３１６に患者症例の全部または一部をアーカイブすることを選択することができる。このストレージ媒体３１６は、リムーバブルメディア、例えば書き込み可能なデジタル多用途ディスク（ＤＶＤ）、書き込み可能なブルーレイディスク、ポータブルフラッシュドライブであってもよく、またはストレージ媒体３１６は、固定タイプのストレージ、例えばローカルハードドライブ、ＤＩＣＯＭサーバ、または別のネットワーク接続されたアーカイブリポジトリーであってもよい。ある実施形態では、アーカイブ要求に応じて、ＭＭＣＭロジックコンポーネント３０２は、対応するＵＩＤを介してリポジトリ３０４から患者症例に関連づけられる全てのデータを取得してもよく、その後当該データをＵＩＤに関連づけられてアーカイブされた、データアーカイブコンポーネント３１４に送信してもよい。そのようなシナリオでは、アーカイブされたデータの復元は、ＵＩＤを参照して達成することができる。さらに、データアーカイブコンポーネント３１４は、要求に応じて、それがアーカイブされる前にデータを匿名化するように構成される。実施形態では、患者についての全ての識別情報は、患者症例から削除されてもよいが、ＵＩＤは、効率的なデータ管理を容易にするために、当該症例に関連づけられたままであってもよい。

【0060】

ＭＭＣＭワークフローコンポーネント２１４は、患者症例の管理に関連づけられるユーザインタフェースコンポーネントを駆動するＭＭＣＭグラフィカルユーザインタフェースコンポーネント３２０を含む。具体的には、ＭＭＣＭ ＧＵＩコンポーネント３２０は、新たな患者症例作成、患者についての識別情報の収集、前もって取得したモダリティデータの管理、および患者診断データのアーカイブに関連したＵＩ画面をレンダリングする。
この一態様として、ＭＭＣＭ ＧＵＩコンポーネント３２０は、ユーザインタフェースに関連づけて入力されたユーザコマンドを解釈ように構成されている。患者症例管理に関連する画面をまとめて症例エクスプローラと呼ぶことがある。ＭＭＣＭ ＧＵＩコンポーネント３２０によってレンダリングされるユーザインタフェースは、図４－１３に関連づけて詳細に説明する。

【0061】

当業者は、図３Ａに示すＭＭＣＭワークフローコンポーネント２１４に関連付けられる処理フレームワーク２００の態様は単純化されており、および追加のおよび／または異なるコンポーネントが患者症例データを管理するためのフレームワーク内で実行することができることを認識するであろう。例えば、ＭＭＣＭロジックコンポーネント３０２は、一つ以上のデータベース通信コンポーネントを利用して、リポジトリ３０４へのおよびリポジトリ３０４からのデータの送信をまとめてもよい。さらに、いくつかの実施形態では、各モダリティ固有のワークフローコンポーネントは、独立して、取得した診断データのストレージを扱うことができる。このようなシナリオでは、各モダリティ固有のワークフローコンポーネントは、ＭＭＣＭワークフローコンポーネント２１４に、当座オープン状態の患者症例に対応するＵＩＤを照会し、および取得した診断データを、当該ＵＩＤを用いて専用のストレージコンテナに記憶する。さらに、ＭＭＣＭワークフローコンポーネント２１４は、別のＭＭＣＭストレージコンテナ内の患者のメタデータを、対応するＵＩＤと一緒に記憶することができる。

【0062】

次に、図４は、マルチモダリティ処理システム１０１内の患者症例管理の簡略化したフロー図である。上述したように、ＭＭＣＭワークフローコンポーネント２１４は、マルチモダリティ処理システム１０１内で取得され、および取得されない、患者データの管理を強化する。ＭＭＣＭワークフローコントローラ２１４は、を制御し、フロントエンドユーザインタフェースおよびバックエンドデータストレージの両方を管理する。フロントエンドユーザインタフェースは、患者症例のワークフローを通して開業医を効率よくガイドするための多数の画面を含む。まず、識別情報入力画面４０２は、医師に、最初に、新たな患者についての識別情報をマルチモダリティ処理システム１０１へ入力することを許可する。識別情報入力画面４０２の一具体例を、図５に詳細に示す。表示画面４０２は、ラストネーム、ミドルネーム、ファーストネーム、生年月日、性別、およびＵＩＤを含む、患者のメタデータの入力を許可する。ＵＩＤは、医師によって入力されてもよく、またはＭＭＣＭワークフローコンポーネントによって自動的に生成されてもよい。さらに、識別情報入力画面４０２は、以前に保存された患者情報を編集するために使用することができる。全ての取得した患者データ用の共通の固有の識別子を使用することにより、モダリティを気にすることなく、患者症例が初期化されるときに、医師は一度だけ患者識別情報を入力すれば足りる。このように、データ入力エラーが低減され、患者識別情報が正しく取得された診断データにリンクすることが保証される。代替の実施形態では、患者識別情報は、外部の患者データリポジトリ、例えば病院情報システム（ＨＩＳ）から取り出すことができる。このような場合には、識別情報入力画面４０２は、医師に、前記の外部データリポジトリ用のネットワーク接続情報を指示してもよく、これにより、患者のメタデータが取得できるようになる。

【0063】

図４に戻り、医師が患者のメタデータ４０４を画面４０２に入力した後、患者症例は初期化され、およびメタデータ４０４は、このメタデータがＵＩＤ４０６に関連づけられるところのＭＭＣＭワークフローコンポーネント２１４に送られる。ＵＩＤ４０６は、画面４０２に入力されたＵＩＤであってもよく、またはそれはＭＭＣＭワークフローコンポーネントによって生成されたＵＩＤであってもよい。患者メタデータ４０４がＵＩＤ４０６に関連づけられた後、ＭＭＣＭワークフローコンポーネント２１４は当該メタデータをデータリポジトリ３０４に記憶する。患者についての識別情報を入力することにより患者症例を開いたとき、医師は、患者に対して一つ以上の診断および／または治療プロシージャを実行することができる。モダリティデータ取得画面４０８は、患者の内部または外部の医療機器から受信した診断データの取得を容易にする。モダリティデータ取得画面４０８の一具体例を、図６に詳細に示す。画面例４０８は、ＩＶＵＳ取得ワークフローを示す。
ＩＶＵＳトランスデューサによって捕捉されたデータから生成される、患者の血管の画像は、医師が患者を通して送達カテーテルをガイドすることを可能にするために表示される。図２に関連づけて上述したように、各モダリティは特定のモダリティに関連する診断プロシージャを実行するために必要な画面をレンダリングするユーザインタフェース拡張を有していてもよい。ＭＭＣＭのワークフローコンポーネント２１４によりレンダリングされたデータ管理に関連づけられる画面、および各モダリティの拡張によりレンダリングされたデータ取得に関連づけられる画面は、システムＵＩ拡張２４４（図２）により、シームレスにユーザインタフェースに統合される。図４に戻り、モダリティデータ取得画面４０８を介して捕捉された第一のモダリティに関連づけられる患者の医療データ４１０は、それがオープンな患者症例に対応するＵＩＤ４０６に関連付けられるところのＭＭＣＭワークフローコンポーネント２１４に送信され、その後データリポジトリ３０４に記憶される。このように、患者のメタデータ４０４、および患者の医療データ４０６は、両方ともＵＩＤ４０６に関連づけられてデータリポジトリ３０４に記憶される。ある実施形態では、医療データ４１０は、医療機器から受信した形式でデータリポジトリ３０４に記憶されてもよいが、別の実施形態では、当該医療データは、処理されたデータ、例えばＩＶＵＳまたはＯＣＴ画像として記憶されてもよい。

【0064】

図４の一具体例のワークフローでは、第二のデータ取得プロシージャが患者に対して行われる。第二のデータ取得に関連付けられる医療モダリティは、第一のデータ取得に関連付けられる医療モダリティとは異なる。第二のデータ取得は、第一のデータ取得と同じカテーテルラボプロシージャの間に実行してもよいし、または後プロシージャの間に実行されてもよい。ここで開示された固有の識別子の方法論は、各取得の間に収集されたデータが、いつ取得が発生したか気にすることなく、同じ患者について登録されることを保証する。第二のモダリティデータ取得画面４１２は、医師に第二の取得ワークフローをガイドするために、提示される。モダリティデータ取得画面４１２の一具体例を、図７に詳細に示す。画面例４１２は、ＦＦＲ診断プロシージャを示す。画面４１２は、医師に、血管内に配置されたセンサにより取得される、患者の血管を通る血流を表すデータを提示する。
図４に戻り、第二のデータ取得画面４１２に関連づけられて捕捉された患者の医療データ４１４は、同一のＵＩＤ４０６がデータに関連付けられ、およびこのデータがデータリポジトリ３０４に記憶されているところのＭＭＣＭワークフローコンポーネント２１４に送られる。

【0065】

一つ以上のモダリティに関連づけられる診断データが患者から取得された後、取得データ管理画面４１６は、医師が、取得したデータセットをレビューし、および管理することを可能にする。取得データ管理画面４１６の一具体例を、図８に詳細に示す。画面４１６は、モダリティを気にすることなく、患者に対して実行されるすべての取得プロシージャの選択可能な表現を表示した症例ログを含む。換言すれば、症例ログに表示されるデータセットの各々は、患者症例に対応する同一のＵＩＤの下、データリポジトリ３０４に記憶されている。例えば、画面例４１６は、同じ患者から取得した、ＩＶＵＳデータセットおよびＦＦＲデータセットの両方を含む。画面４１６上に表示される選択可能な表現は、時間、日、週、または年の期間にわたって取得されたデータセットに対応してもよく、またはそれらは同じプロシージャ内で取得された別々のデータセットに対応してもよい。

【0066】

ある実施形態では、画面４１６をレンダリングするために、ＭＭＣＭ ＧＵＩコンポーネント３２０は、データリポジトリ３０４に、オープンな患者症例に対応するＵＩＤに関連づけられている、全ての収集データセットのリストについて照会する。画面例４１６では、全てのデータセットは固有の識別子１２３４５６に関連づけられており、選択可能な表現はモダリティのタイプによって体系化される。さらに、図示の実施形態では、データセットの各選択可能な表現は、データセットのタイトル、および当該データセットが重要な患者特徴を強調する任意のブックマークを含むか否か、および当該データセットが取得された日時を表示する。他の実施形態では、追加情報は、データセットの各選択可能な表現に関連づけて表示してもよい。加えて、いくつかの例では、症例ログにおける選択可能な表現の表示順序は、データセットの様々な特徴、例えば取得時間に基づいて変更してもよい。以下に説明するように、画面４１６上の選択可能な表現を選択ことにより、ユーザインタフェースに、当該選択したデータセットに含まれるデータおよび／または画像を表示させる。しかしながら、いくつかの実施形態では、画面４１６上で選択可能な表現を選択することにより、前記のＵＩに、画面４１６内の当該選択されたデータセットに関する追加情報を、例えばドロップダウンプレビューペインで表示させる。例えば、図９は、医師が「ＵＮＴＩＴＬＥＤ０１」というタイトルのデータセットを選択したシナリオを示す。取得時間、プルバックレートおよびデータセット内のブックマークなどの当該データに関する追加情報は、当該データセットの選択可能な表現の下に表示される。さらに、図示の実施形態に示すように、当該データセット内に含まれる画像データのプレビューを、加えて表示してもよい。ドロップダウンプレビューペイン内では、データセットを削除するためのボタン、データセットをロードするためのボタン、およびデータセットに関する追加情報を表示するためのボタンは、医師によって選択可能である。加えて、いくつかの実施形態では、画面４１６は、医師が、比較目的のために、データセットの複数の選択可能な表現を選択することを可能にする。したがって、取得データ管理画面４１６をレビューする医師は、モダリティを気にすることなく、患者に関連づけられる全ての取得データセットをレビューし、管理することができる。このように、医師が患者の医療データをレビューするのに費やさなければならない時間の量は低減され、より効率的な診断および処置につながる。

【0067】

次に、図１０は、多数の患者取得データ管理画面４１８を示す。データ管理画面４１８は、データ管理画面４１６と同様であるが、それは、複数の患者症例に関連づけられるデータセットの選択可能な表現を表示するように構成されている。患者症例の各選択可能な表現は、患者症例についての情報、例えば患者の名前、固有の識別子（ＵＩＤ）、プロシージャの日、医師、モダリティ／モード、当該データセットがアーカイブされているか否か、当該データセットのサイズ、および症例タイプが含まれる。他の実施形態では、患者症例の各選択可能な表現は、異なるおよび／または追加の情報、例えば患者の生年月日、患者の性別、プロシージャロケーションなどを含んでいてもよい。データ管理画面４１８にリストされた患者症例の表示の順序は、それぞれの患者症例に関連づけられる情報カテゴリの一つ以上により配置してもよい。さらに、いくつかの実施形態において、図１０に示すように、医師が患者症例の選択可能な表現に関連づけられるトグル要素を選択するときに、選択された患者症例を備える個々のデータセットが表示される。患者症例に関連づけられる全ての取得データセットは、医療モダリティを気にすることなく、前記選択可能な表現の下方に表示される。画面４１８の一具体例では、第一の患者症例が選択され、およびＩＶＵＳプロシージャおよびＦＦＲプロシージャに関連づけられるデータセットが表示される。加えて、多数の患者取得データ管理画面４１８は、医師が、表示された一つ以上の選択可能な表現を選択することにより、患者症例を取得、およびオープンにすることを可能にするように構成される。患者症例の選択可能な表現が画面４１８上で選択された場合、ＭＭＣＭ ＧＵＩコンポーネント３２０は、関連付けられたＵＩＤを使用して、データレポジトリ３０４を照会して、患者に関連づけられるデータセットが取得される。いくつかの実施形態では、選択された患者症例はローカルまたはネットワークベースのハードドライブから取得してもよいが、他の実施形態では、選択された患者症例がリムーバブルメディア、例えばＤＶＤ、ブルーレイディスク、またはフラッシュベースのドライブから取得してもよい。したがって、多数の患者取得データ管理画面４１８をレビューする医師は、モダリティを気にすることなく、当該患者症例に含まれる全て取得データセットを含む、全ての患者症例を容易にレビューおよび管理することができる。このように、医師が、効率的に関連する患者症例を特定し、および比較することができ、これにより、効率的な診断および処置を容易にする。

【0068】

参照してすぐに戻って図４に、取得データ管理画面４１６をレビューする医師は、前述したように、より詳細にレビューするために特定のデータセットを選択してもよい。選択された医療データ４２０の指摘は、ＭＭＣＭワークフローコンポーネント２１４に送信され、これにより、当該選択された医療データがデータリポジトリ３０４から取り出すことができる。具体的には、ＭＭＣＭワークフローコンポーネント２１４は、少なくとも選択された医療データのＵＩＤを使用してデータリポジトリ３０４を照会する。図４に示す実施形態に示すように、選択された患者医療データ４２２がデータレポジトリ３０４から取得されると、取得された医療データ表示画面４２４を介して要求元の医師にそれが表示される。その点で、取得した医療データ表示画面４２４の一具体例を、図１１に示す。表示画面４２４の具体例は、ＩＶＵＳプロシージャの間に捕捉された画像データセットを示す。ＩＶＵＳ画像をレビューする際に、医師は、測定を行ってもよく、および前記データセットでのＩＶＵＳ画像に対してラベルや他の注釈を追加してもよい。その点で、強化された測定、操作、ナビゲーション、表示、およびマルチモダリティ医療画像の注釈のための方法およびシステムは、米国仮特許出願第ＸＸ／ＸＸＸ、ＸＸＸ（出願番号４４７５５．１０４１）名称「マルチモダリティ画像診断システムにおけるＤＡＴＡラベリングとインデックシング」、米国仮特許出願第ＸＸ／ＸＸＸ、ＸＸＸ（出願番号４４７５５．１０４２）名称「マルチモダリティ画像診断システムでの測定および強化」、米国仮特許出願第ＸＸ／ＸＸＸ、ＸＸＸ（出願番号４４７５５．１０４３）名称「マルチモダリティ画像診断システムのためのジェスチャーベースのインタフェース」、および米国仮特許出願第ＸＸ／ＸＸＸ、ＸＸＸ（出願番号４４７５５．１０４４）名称「マルチモダリティ画像診断システムにおける測定ナビゲーション」も開示されており、およびこれら全てが本開示にその全体が参考として援用される。

【0069】

上述のように、いくつかの実施形態では、取得データ管理画面４１６は、医師が、比較目的のために、データセットの複数の選択可能な表現を選択することを可能にしてもよい。このようなシナリオでは、ＭＭＣＭワークフローコンポーネント２１４が取得医療データ表示画面４２４に対して同時表示のために要求されたデータセットの各々を取り出すことができる。図１２は、二つのＩＶＵＳ画像をサイドバイサイドで示す、取得医療データ表示画面４２４の他の例を示す図である。二つのＩＶＵＳ画像は、患者に対して行った二つの異なるＩＶＵＳプロシージャの間に取得されたデータセットからのものであってもよい。異なる時刻に取得した患者画像のサイドバイサイド比較により、医師が効率的に時間をかけて患者の症状の変化を決定することができる。加えて、図１３は、サイドバイサイドで表示された異なるモダリティに関連づけられるデータを示す医療データ表示画面４２４の別の例である。具体的には、患者から取得されたＩＶＵＳ画像は、同じ患者から収集されたＦＦＲデータと同時に示される。ＩＶＵＳデータおよびＦＦＲデータは同一のカテーテルラボプロシージャの間または異なるカテーテルラボプロシージャの間に収集されたものであってもよい。ＭＭＣＭワークフローコンポーネント２１４は、画面４２４に表示されたマルチモダリティデータを空間的または時間的に同期する、同期コンポーネントを含んでもよい。当業者は、図１３の画面４２４はほんの一例であり、異なるモダリティのデータが比較目的のために、サイドバイサイドで表示してもよいことを認識するであろう。例えばＯＣＴ画像をＩＣＥ画像に隣接して表示させてもよく、またはいくつかの例では、マルチモダリティ処理システム１０１の外部の（ストリーミングの）取得データ、例えばＸ線血管造影（ＸＡ）データを、当該処理システム自体によって取得されたデータ、例えばＩＶＵＳまたはＯＣＴデータに隣接して表示させてもよい。

【0070】

図４に戻り、任意の測定、注釈、メモ、または画面４２４を経由して取得データのレビュー中に作成されて導出された他のデータ４２６が、ＭＭＣＭワークフローコンポーネント２１４に送信される。ＭＭＣＭワークフローコンポーネント２１４は、このオープンな患者症例に対応するＵＩＤ４０６を前記導出データ４２６と関連づけて、当該導出データ４２６をデータリポジトリ３０４に記憶する。このように、任意の注釈、測定等が、それらに対応する取得データに密接に関連付けられており、効率的な検索およびその後のレビューを容易にする。

【0071】

当業者は、図４－１３に関連づけて説明した患者症例管理のシステムおよび方法が単なる例示的な実施形態であり、代替の実施形態において、追加のおよび／異なるステップを実行してもよいし、および追加のおよび／または異なる画面をユーザインタフェースの一部としてレンダリングしてもよいことを、を認識するであろう。例えば、ある実施形態では、ＭＭＣＭワークフローコンポーネントよりはむしろ各モダリティワークフローコンポーネントが、そのモダリティに関連づけられるデータの書き込みおよび取り出しを処理してもよい。このような実施形態では、独立したモダリティワークフローコンポーネントは、新しい取得データを記憶する前に、ＭＭＣＭワークフローコンポーネントに、当座オープン状態の患者症例に対応するＵＩＤを照会することができる。さらに、画面４０２、４０８、４１２、４１６、および４２４は、単に具体例であり、このような画面は、さらに、マルチモダリティ処理システム１０１内の患者症例管理を容易にするために、異なるおよび／または追加の特徴およびユーザオプションを含めてもよい。

【0072】

次に、図１４は、マルチモダリティ処理システム１０１内の患者症例管理の別の態様を示すフロー図である。具体的には、図１４は、患者医療データをアーカイブし、および匿名化するシステムおよび方法を示す。明確のために、図４の部分に類似する図１４の部分が、同様にラベルされている。

【0073】

一つ以上のモダリティに関連づけられる医療データが患者から取得され、データリポジトリ３０４に記憶された後、図３Ａに関連して上述したように、医師は、アーカイブストレージ媒体に当該データをアーカイブするためのオプションを与えられる。一般的に、取得した医療データをアーカイブすることは、医療データが取得される、医療処理システムの外部のストレージロケーションに医療データを移動させることを含む。ある例では、取得した医療データは、リムーバブルストレージ媒体、例えば書き込み可能な光ディスクまたはポータブルフラッシュベースのコンテナに転送してもよい。別の例では、取得した医療データは、ネットワーク接続を介して、リモートデータリポジトリ、例えばＤＩＣＯＭに転送してもよい。

【0074】

マルチモダリティ患者カルテのアーカイブを容易にするために、前記ＭＭＣＭ ＧＵＩコンポーネントは、取得した医療データアーカイブ画面１４００をレンダリングする。取得した医療データアーカイブ画面１４００の具体例を、図１５に詳細に示す。このアーカイブ画面１４００の具体例は、アーカイブのために利用可能な患者症例の選択可能な表現のリストを表示する。患者症例のそれぞれの選択可能な表現は、当該患者症例についての情報、例えば患者の名前、固有の識別子（ＵＩＤ）、プロシージャの日、医師、モダリティ／モード、データセットがすでにアーカイブされたかどうか、データセットのサイズ、および症例タイプが含まれる。いくつかの例では、それぞれの患者症例に関連づけて表示されたＵＩＤが、患者を処置する臨床病院によって割り当てられた識別子であってもよく、ソーシャルセキュリティナンバーのような一般的に固有でなくてもよい。他の実施形態では、患者症例のそれぞれの選択可能な表現は、異なるおよび／または追加の情報、例えば患者の誕生日、患者の性別、プロシージャの場所などを含んでもよく。アーカイブ画面１４００にリストされた患者症例の表示順序は、それぞれの患者症例に関連づけられる情報のカテゴリの一つ以上を配置してもよい。患者症例の各表現は、例えばチェックボックスを介して、－選択可能である。患者症例の一つに関連づけられるドロップダウントグルを操作することにより、患者症例構成するモダリティデータセット表示する。例えば、画面１４００上に表示される第一の患者症例は、ＩＶＵＳプロシージャ中に生成されたデータセット、およびＦＦＲプロシージャ中に生成されたデータセットを含む。これらのデータセットは、例えばデータセット表現の左にあるチェックボックスを選択することにより－個別に選択可能な表現として表示される。他の実施形態では、データセットを選択する異なる方法を実装することができる。さらなる実施形態では、画面例１４００には示していないが、患者症例内でそれぞれの画像ベースのデータセット（即ち、ＩＶＵＳデータセット）を拡張して、データセットを構成する個々の画像を表示するようしてもよい。このような実施形態では、それぞれの画像を、例えばチェックボックスを介して－個別に選択可能である。

【0075】

医師が画面１４００上のアーカイブ用に利用できる患者症例のリストをレビューした後、当該医師は、アーカイブのための患者症例、データセット、または画像の一つ以上を選択してもよい。図示された実施形態では、医師は、アーカイブするために各項目のそばにチェックマークを入れて、その後、アーカイブボタンを操作する。注目すべきことに、本開示のアーカイブシステムは、患者症例レベルで、データセットレベルで、または画像のレベルで、アーカイブするように構成される。すなわち、医師は、（１）どの患者症例または複数の患者症例をアーカイブするのかを選択的に決定する、（２）患者症例内のどのデータセットまたは複数のデータセットをアーカイブするのかを選択的に決定する、および（３）データセット内のどの画像または複数の画像をアーカイブするのかを選択的に決定する、ことができる。いくつかの例では、患者症例、データセット、または画像の任意の順列でも、一緒にアーカイブすることができる。このように、一つのアーカイブアクションにより、複数の患者に対応する複数の患者症例を同時にアーカイブすることができる。また、アーカイブされた患者症例は、異なる医療モダリティに関連づけられるデータセットを含んでもよく、および一つのカテーテルラボプロシージャの間に取得され、または異なる時間に実行された異なるカテーテルラボプロシージャの間に取得された、マルチモダリティデータセットも含んでいてもよい。

【0076】

図３Ａに関連づけて上述したように、患者症例は、効率的なストレージ管理および検索のためにそれに対応するＵＩＤに関連づけてアーカイブすることができる。いくつかの実施形態では、このＵＩＤの利用は、アーカイブ患者症例を、最初のアーカイブアクションの後に取得した「新規の」患者データで更新することを可能にする。より詳細には、患者症例はアーカイブされた後、画面１４００は、「アーカイブされた」という情報カラムにそれだけを示す。新規のデータセットは、以前にアーカイブされた患者症例に関連付けられて取得された場合、画面１４００は、当該新規のデータセットがアーカイブされていないことを示す。医師は、このアーカイブされていないデータセットを個別に選択し、アーカイブボタンを操作することができる。これに応答して、アーカイブシステム（図３Ａのデータアーカイブコンポーネント３１４により、または前記ＭＭＣＭワークフローコンポーネント２１４により実装される）は、関連づけられたＵＩＤを介して、アーカイブされた患者症例を見つけて、それを開き、当該新規のデータセットを挿入する。他の実施形態では、アーカイブされた患者症例を更新することは、異なる方法、例えばアーカイブされた患者症例のデータを取り出し、当該新規のデータセットを追加し、および当該更新された患者症例で新規のアーカイブを作成することによるなどにて、実行することができる。
さらに、他の実施形態では、前記ＭＭＣＭワークフローコンポーネントは、データを、以前にアーカイブされた症例に追加されることを禁止して、データ改ざんを防止する。

【0077】

さらに、いくつかの実施形態では、図１４および図１５のアーカイブシステムは、固定されたロケーションよりもむしろ、当該医師によって選択されたロケーションに医療データをアーカイブするように構成されている。例えば、画面例１４００では、医師は、リムーバブルメディア、例えば書き込み可能な光学ディスク、あるいはポータブルフラッシュストレージへのアーカイブ、またはネットワーク接続されたリモートストレージ媒体、例えばＤＩＣＯＭサーバへのアーカイブのいずれかを選択することができる。代替的な実施形態では、追加のおよび／または異なるアーカイブロケーションが、ローカルハードドライブ、ストレージエリアネットワーク（ＳＡＮ）、またはクラウドベースのストレージのように、医師によって選択することができる。

【0078】

ある特定の実施形態では、図１４および図１５のアーカイブシステムは、画面例１４００上で医師による選択にしたがって、複数の異なるフォーマットの一つに、医療データをアーカイブするように構成されている。その点で、患者医療データを、フォーマットを変更せずに単に「そのまま」アーカイブしてもよく、またはそのフォーマットを変更してもよく（すなわち、画面例１４００上で選択したフォーマットに変更する）、またはそれは必要とされるストレージ空間量を削減するために圧縮フォーマットでアーカイブしてもよい。ある実施形態では、医療データは、専用または業界標準のアーカイブデータコンテナに挿入することができる。さらに、図示されたアーカイブシステムによってアーカイブされた医療データは、暗号化して、またはそうでなければ難読化して、不正なアクセスを防止するようにしてもよい。いくつかの実施形態では、パスワードを介して、アーカイブ済みアイテムへのアクセスを暗号化および／または制限するためのオプションを、アーカイブ画面１４００上で提示することができる。

【0079】

図１４および１５の実施形態に示される、マルチモダリティ処理システム１０１のアーカイブ要素は、医療データを、それがアーカイブされる前に、選択的に匿名化するようにさらに構成されている。例えば、医師は、医療データから、それがアーカイブされる前に、患者識別情報を削除するかどうかを選択することができる。より詳細には、匿名化せずに患者症例をアーカイブするときには、取得した全てのモダリティデータセットおよび全てのメタデータ－患者識別情報を含む－が、アーカイブコンテナに含まれる。同様に、個々のアーカイブされたモダリティデータセットおよび画像は、匿名化しないでアーカイブされる場合に、患者識別情報を含むことになる。しかしながら、医師がアーカイブする前に匿名化することを選択した場合は、前記アーカイブシステムは、データを取得した人からの患者を識別することができる、アーカイブカルテからのいかなる情報も自動的に削除する。図示された実施形態では、アーカイブシステムは、アーカイブ画面１４００の「匿名化（Ａｎｏｎｙｍｉｚｅ）」ボタンが操作されるときに、医療データを匿名化する。注目すべきことに、当該アーカイブシステムは、アーカイブを行う医師の影響を受けることなく、全ての患者識別情報を削除するように構成されている。すなわち、このシステムは、患者症例内のどのデータフィールドが、患者を識別できる情報を含むのかをまず決定し、その後、特定されたフィールド内のいかなるデータをも削除する。ある実施形態では、この決定は、識別情報を含むことが知られているデータフィールドの予め決定されたセットを含む設定ファイルに基づく。代替の実施形態では、アーカイブシステムは、ケースバイケースで自然言語処理アルゴリズムを用いて、機密データフィールドを決定する。さらに、いくつかの実施形態では、患者識別情報は、匿名化手順の間に、削除されるよりもむしろ、難読化される。このような実施形態では、難読化された患者情報は認可されたシステムまたは医師によって回収することができる。加えて、複数の患者に対応する複数の患者症例がアーカイブのために選択される－そして、匿名化オプションが選択される－場合に、それぞれ異なる患者についての識別情報は、患者症例から削除され、または難読化される。

【0080】

したがって、マルチモダリティ処理システム１０１が医師による介入なしで自動的にアーカイブデータを匿名化するため、削除された除去患者情報の少なくともいくつかは、医師又は他のサードパーティのデータプロセッサから隠されたままであり、これにより、機密の医療情報の機密性を増加させることになる。さらに、自動化された匿名化は、それがユーザインタフェースを介してアクセス可能であるかどうかを気にすることなく、事務的な誤りを減少させ、および全ての識別情報が削除されることを保証する。さらに、ここで記載されたアーカイブのシナリオでは、匿名化アクションは、データがリモートアーカイブストレージロケーションに送信される前に、マルチモダリティ取得／処理システムそれ自体で実行される。例えば、マルチモダリティ処理システムがカテーテルラボに配置されるポータブル処理システムである実施形態では、医師は、患者から医療データを取得し、それを匿名化し、およびそれをリムーバブルストレージ媒体、例えばＤＶＤにアーカイブする、全てをカテーテルラボ内の処理システムで行うことができる。

【0081】

図１４に戻り、医師が患者症例、データセット、および／または画像の一つ以上をアーカイブするために選択した後、アーカイブ要求１４０２がＭＭＣＭワークフローコンポーネント２１４に送信される。このアーカイブ要求は、選択した特定の医療データをアーカイブする指示、およびこの選択された医療データを匿名化する必要があるかどうかの指示である。前記ＭＭＣＭワークフローコンポーネント２１４は、この要求を処理し、データリポジトリ３０４から、前記で選択された医療データ１４０４を取り出す。医師が、医療データ１４０４が匿名されるべきである旨指示した場合は、それがアーカイブストレージ媒体３１６に保存される前に、患者識別情報１４０６が削除または前記ＭＭＣＭワークフローコンポーネント２１４によって難読化される。前記ＭＭＣＭワークフローコンポーネント２１４は、さらに、アーカイブするデータを、例えば圧縮し、暗号化し、そのフォーマットを変更し、および／またはアーカイブデータコンテナの中に収納することなどにより、修正することができる。

【0082】

マルチモダリティ処理システムにおけるマルチモダリティ医療データをアーカイブする、または匿名化するための、上述のシステム及び方法は、単に例示的な実施形態であり、および代替の実施形態において、追加のおよび／または異なるステップが方法に含まれてもよいし、システムは追加のおよび／または異なるユーザインタフェース画面を含むことできることが理解される。さらに、アーカイブ画面１４００は、単なる一具体例であり、およびそれが、マルチモダリティ処理システム１０１内の患者症例管理をさらに容易にするために異なるおよび／または追加の機能およびユーザオプションを含んでもよい。

【0083】

例示的な実施形態を図示し説明してきたが、広い範囲の修正、変更、及び置換が、前述の開示において意図されており、およびいくつかの例では、本開示のいくつかの特徴が、対応する他の特徴の使用なしに採用することができる。また、上述したように、マルチモダリティ処理システムに関連づけて上述したコンポーネントおよび拡張は、ハードウェア、ソフトウェア、または両方の組み合わせで実現することができる。および、前記処理システムは、任意の特定のアーキテクチャ上で動作するように設計してもよい。例えば、当該システムは、単一のコンピュータ、ローカルエリアネットワーク、クライアントサーバネットワーク、広域ネットワーク、インターネット、ハンドヘルドおよび他のポータブルワイヤレスデバイスおよびネットワーク上で実行することができる。このようなバリエーションは、本開示の範囲から逸脱することなく、前述においてなすことができることが理解される。したがって、添付の特許請求の範囲は広く、本開示の範囲と一致する方法で解釈されることが適切である。

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】