JP6081446B2 - 集学的医療感知システムおよび方法 - Google Patents

Description

本開示の実施形態は一般に医療装置の分野に関し、より具体的には、集学的医療感知システムおよび関連する使用法に関する。

本出願は、その全体が参照により本明細書に組み込まれる、「集学的医療感知システムおよび方法」という名称の２０１１年４月８日出願の米国仮特許出願第６１／４７３，５７０号の利益を主張する。

疾病治療の成功度を診断し、検証することにおける技術革新は、外部撮像処理から内部診断処理に移行してきた。具体的には、診断装置および処理は、脈管の閉塞およびその他の脈管の疾病を診断するために開発され、カテーテルまたはカテーテル処置に用いるガイドワイヤなどの可撓性の細長い部材の先端上に配置された超小型センサによって行われてきた。たとえば、既知の医療感知技法には、血管造影、血管内超音波検査（ＩＶＵＳ）、フォワードルッキングＩＶＵＳ（ＦＬ−ＩＶＵＳ）、冠血流予備量値（ＦＦＲ）判定、冠血流予備能（ＣＦＲ）判定、光干渉断層撮影（ＯＣＴ）、経食道心エコー、および画像誘導治療が含まれる。これらの技法は、それぞれ異なる診断状況において、より適していることもある。治療が成功する可能性を高めるために、医療施設は、カテーテル検査室での処置中に、利用可能な複数の撮像および感知手法を有してもよい。ただし、カテーテル検査室の各撮像手法は伝統的に、独自の専用の診断機器を必要とする。たとえば、撮像手法は、カテーテル、患者隔離モジュール（ＰＩＭ）、ユーザ制御インタフェース、ディスプレイ、専用電源、およびカスタマイズされたパーソナルコンピュータなどの処理装置を必要とすることもある。伝統的に、この機器のすべては、処置中にカテーテル室自体に位置し、接続性および信頼できる電源を得るために大量の配線基盤に依存する。物理的空間は一般に、カテーテル検査室では非常に貴重であり、カテーテル検査室で使用する追加の撮像手法それぞれによって処置前の設定が複雑になり、処置中の医療専門家の移動を制限する。さらに、各撮像手法装置は、特定の装置の独自の制御法を操作するように訓練を受けた臨床医療者によって独立して設定され、管理されなければならない。患者の安全性、処置時間、十分に訓練を受けた人材の配置および利用可能性の限度を考慮すると、これは好都合ではないこともある。さらに、複数の撮像手法を組み合わせる現在の統合ソフトウェアソリューションは、アップグレードすることが困難であり、困難でなかったとしても問題が多い。

既存の装置および方法はその意図する目的に対して一般に適切であったが、すべての面で完全に満足いくものではなかった。本開示の医療感知システムおよび関連する方法は、１または複数の従来技術の欠点を克服する。

米国仮特許出願第６１／４７３，５７０号

１つの代表的な態様では、本開示は医療感知システムを対象とする。医療感知システムは、第１の医療感知装置に通信可能に接続する計算システム（ｃｏｍｐｕｔｉｎｇ ｓｙｓｔｅｍ）を含む。計算システムは第１のデータ取得モジュールを含む。第１のデータ取得モジュールは第１の医療感知手法に関連し、第１の医療感知手法に関連する第１の患者データを第１の医療感知装置から受信するように操作可能である。第１のデータ取得モジュールは第１の患者データをパケット化するように操作可能であり、複数のデータ取得モジュールのうちの１つである。本システムはまた、第１の医療感知手法に関連する第１の処理モジュールを含み、パケット化された第１の患者データ処理するように操作可能であり、第１の処理モジュールは複数の処理モジュールのうちの１つである。さらに、本システムは第１のユーザインタフェースモジュールを含む。第１のユーザインタフェースモジュールは、第１の医療感知手法に関連し、処理済みのパケット化された第１の患者データを第１のグラフィカルユーザインタフェース内で提示するように操作可能であり、第１のユーザインタフェースモジュールは複数のユーザインタフェースモジュールのうちの１つである。また、本システムは第１のデータ取得モジュールと、第１の処理モジュールと、第１のユーザインタフェースモジュールと通信するメッセージキューモジュールとを含む。メッセージキューモジュールはパケット化された第１の患者データをモジュールから受信し、パケット化された第１の患者データを一時的に記憶し、パケット化された第１の患者データをモジュールによって検索可能とするように操作可能である。

ある事例では、計算システムは第２のデータ取得モジュールをさらに含む。第２のデータ取得モジュールは第２の医療感知手法に関連し、第２の医療感知手法に関連する第２の患者データを第２の医療感知装置から受信するように操作可能である。第２のデータ取得モジュールは第２の患者データをパケット化するように操作可能であり、複数のデータ取得モジュールのうちの１つである。さらに、ある事例では、本システムは第２の処理モジュールを含む。第２の処理モジュールは、第２の医療感知手法に関連し、パケット化された第２の患者データを処理するように操作可能である。第２の処理モジュールは複数の処理モジュールのうちの１つである。また、ある事例では、本システムは第２のユーザインタフェースモジュールを含む。第２のユーザインタフェースモジュールは第２の医療感知手法に関連し、処理済みのパケット化された第２の患者データを第２のグラフィカルユーザインタフェース内で提示するように操作可能であり、第２のユーザインタフェースモジュールは複数のユーザインタフェースモジュールのうちの１つである。

別の代表的な態様では、本開示は医療感知システムを対象とする。医療感知システムは、第１の医療感知装置に通信可能に接続する計算システムを含む。計算システムは第１のデータ取得モジュールを含む。第１のデータ取得モジュールは第１の医療感知手法に関連し、第１の医療感知手法に関連する第１の患者データを第１の医療感知装置から受信するように操作可能である。第１の取得モジュールはさらに、第１の患者データを含有する第１の複数のメッセージを作成するように操作可能である。本システムはまた、メッセージキューモジュールを含む。メッセージキューモジュールは、第１のデータ取得モジュールから第１の複数のメッセージを受信し、一時的に記録するように操作可能である。さらに、本システムは第１の処理モジュールを含む。第１の処理モジュールは第１の医療感知手法に関連し、第１の複数のメッセージをメッセージキューモジュールから取り出し、第１の複数のメッセージ内の第１の患者データを処理し、処理された第１の患者データを含有する第２の複数のメッセージをメッセージキューモジュールに送信するように操作可能である。また、本システムは第１のユーザインタフェースモジュールを含む。第１のユーザインタフェースモジュールは第１の医療感知手法に関連し、第２の複数のメッセージをメッセージキューモジュールから取り出し、処理された第１の患者データを第１のグラフィカルユーザインタフェース内で提示するように操作可能である。

ある事例では、医療感知システムの第１のデータ取得モジュールは複数の取得モジュールのうちの１つであり、第１の処理モジュールは複数の処理モジュールのうちの１つであり、第１のユーザインタフェースモジュールは複数のユーザインタフェースモジュールのうちの１つである。

別の代表的な態様では、本開示は医療感知データの処理方法を対象とする。医療感知データの処理方法は、第１の患者データを第１の医療感知装置から受信することを含む。第１の患者データは第１の医療感知手法に関連する。前記処理方法は、第１の複数のメッセージを作成する。第１の複数のメッセージの各メッセージは第１の患者データの一部を含有する。本方法はまた、第１の複数のメッセージをメッセージキューのキューに入れ、第１の複数のメッセージをメッセージキューから取り出し、第１の複数のメッセージに含有される第１の患者データを処理することを含む。さらに、本方法は第２の複数のメッセージを作成することを含む。第２の複数のメッセージの各メッセージは処理された第１の患者データの一部を含有する。本方法は第２の複数のメッセージをメッセージキューに入れることを含む。また、本方法は第２の複数のメッセージをメッセージキューから取り出し、第２の複数のメッセージに含有される処理された第１の患者データを、第１のグラフィカルユーザインタフェース内でレンダリングすることを含む。

本開示の一実施形態による集学的処理システムを含む医療感知システムの概略図である。 医療感知システムの集学的処理システムの実施形態で実行するソフトウェアフレームワークの機能ブロック図である。 本開示の一実施形態において集学的処理システムが使用するメッセージフォーマットの説明図である。 集学的処理システムの医療感知データの処理方法を例示するハイレベルフローチャートである。 本開示の別の実施形態による集学的処理システムを含む医療感知システムを示す概略図である。 図５の医療感知システムの態様、つまり、集学的処理システムの斜視線図である。

本開示の原理をより理解しやすくするために、図に例示する実施形態をここで参照し、特定の用語を用いて説明する。しかしながら、本開示の範囲を限定することを意図するものではないことは理解されよう。記載する装置、機器、方法の任意の変更およびさらなる修正、ならびに本明細書に記載する開示の原理の任意の別の適用は、本開示に関係する分野の当業者には通常想案されるであろう。具体的には、一実施形態に関して記載される特徴、構成部品、および／またはステップは、本開示の別の実施形態に関して記載される特徴、構成部品、および／またはステップと組み合わせてもよいことは十分に考えられる。

図１は、本開示の一実施形態による集学的処理システム１０１を含む医療感知システム１００を示す概略図である。一般に、医療感知システム１００は、人間の生物学的生理情報および形態学的情報を取得して、解釈するために用いる様々な方法に影響を受けるように設計される、複数の形態の取得要素および処理要素の整理統合した物（ｃｏｈｅｒｅｎｔ ｉｎｔｅｇｒａｔｉｏｎ ａｎｄ ｃｏｎｓｏｌｉｄａｔｉｏｎ）を提供する。より具体的には、システム１００において、集学的処理システム１０１は、集学的医療感知データを取得し、制御し、解釈し、表示するための統合装置である。一実施形態では、処理システム１０１はハードウェアおよびソフトウェアを搭載したコンピュータワークステーションであり、集学的医療感知データを取得し、処理し、表示する。しかし、別の実施形態では、処理システム１０１は、医療感知データを処理するように操作可能な任意の別の種類の計算システムであってもよい。処理システム１０１がコンピュータワークステーションである実施形態において、本システムは、マイクロコントローラまたは専用中央演算処理装置（ＣＰＵ）などのプロセッサと、ハードドライブ、ランダムアクセスメモリ（ＲＡＭ）、および／またはコンパクトディスク読み出し専用記憶媒体（ＣＤ−ＲＯＭ）などの非一時的コンピュータ可読記録媒体と、グラフィックスプロセッシングユニット（ＧＰＵ）などの映像コントローラと、イーサネット（登録商標）コントローラなどのネットワーク通信装置とを少なくとも含む。

例示実施形態では、医療感知システム１００は、制御室１０４を有するカテーテル検査室１０２に配備され、処理システム１０１は制御室に位置する。別の実施形態では、図５および図６に関連して記載するように、処理システム１０１はカテーテル検査室１０２自体などの他の場所に位置してもよい。カテーテル検査室１０２は滅菌野を含むが、その関連する制御室１０４は、処置および／または医療施設の要件によって、滅菌であっても、滅菌でなくてもよい。カテーテル検査室および制御室を使用して、血管造影、血管内超音波（ＩＶＵＳ）、仮想組織診断（ＶＨ）、フォワードルッキングＩＶＵＳ（ＦＬ−ＩＶＵＳ）、血管内光音響（ＩＶＰＡ）撮像、冠血流予備量値（ＦＦＲ）判定、冠血流予備能（ＣＦＲ）判定、光干渉断層撮影（ＯＣＴ）、コンピュータ断層撮影、心腔内心エコー（ＩＣＥ）、フォワードルッキングＩＣＥ（ＦＬＩＣＥ）、血管内パルポグラフィ、経食道超音波、または従来技術で既知の任意の別の医療感知手法などの任意の数の医療感知処置を患者に実施してもよい。たとえば、カテーテル検査室１０２において、患者１０６は単一の処置として、または１もしくは複数の感知処置を組み合わせて集学的処置を受けてもよい。この処置中、ＩＶＵＳデータはＩＶＵＳカテーテル１０８を用いて収集され、ＯＣＴデータはＯＣＴカテーテル１１０を用いて収集される。ＩＶＵＳカテーテル１０８は、フェーズドアレイ変換器などの１または複数のセンサを含んでいてもよい。一部の実施形態では、ＩＶＵＳカテーテル１０８はＩＶＵＳおよびＩＶＰＡ感知などの集学的感知が可能であってもよい。ＯＣＴカテーテル１１０は１または複数の光学センサを含んでいてもよい。

図１に例示する実施形態では、医療感知システム１００は、カテーテル検査室１０２および制御室１０４に、この集学的ワークフロー処置を促進するために、複数の相互接続する医療感知に関するツールを含む。このツールには、ＩＶＵＳ患者隔離モジュール（ＰＩＭ）１１２、ＯＣＴ ＰＩＭ１１４、心電図（ＥＣＧ）装置１１６、血管造影システム１１７、ベッドサイド制御面１１８、制御室制御面１２０、およびブームディスプレイ１２２が含まれる。カテーテル検査室１０２内のベッドサイドユーティリティボックス（ＢＵＢ）１２４はＰＩＭ１１２および１１４、ＥＣＧ装置１１６、およびベッドサイド制御面（ｃｏｎｔｒｏｌ ｓｕｒｆａｃｅ）１１８に対するハブとして機能し、これらを処理システム１０１に通信可能に接続する。例示実施形態では、血管造影システム１１７、制御室制御面１２０、およびブームディスプレイ１２２は処理システム１０１に通信可能に直接的に接続する。ただし、代替的な実施形態では、これらのツールはＢＵＢ１２４を介して処理システム１０１に接続されてもよい。一実施形態では、ＢＵＢ１２４は受動的なケーブル通過装置であり、配線を整理して、床下のケーブル配線溝まで送る。また、代替的に、別の実施形態では、ＢＵＢ１２４はロジックおよび通信回路を含有して、医療感知ツールと処理システム１０１との間の通信を積極的に調整してもよい。「医療感知通信システムおよび方法」という名称の２０１１年４月８日出願の米国仮特許出願第６１／４７３，６２５号は、医療感知に関するツールを統合して接続するベッドサイドユーティリティボックスを開示しており、その全体が参照により本明細書に組み込まれる。さらに、集学的処理システム１０１はデータネットワーク１２５に通信可能に接続する。例示実施形態では、データネットワーク１２５はＴＣＰ／ＩＰベースのローカルエリアネットワーク（ＬＡＮ）であるが、別の実施形態では、同期型光ネットワーク（ＳＯＮＥＴ）などの異なるプロトコルを利用してもよく、またはワイドエリアネットワーク（ＷＡＮ）であってもよい。処理システム１０１は、ネットワーク１２５を介して様々なリソースに接続してもよい。たとえば、処理システム１０１は、ネットワーク１２５を通じて、医用デジタル撮像および通信（ＤＩＣＯＭ）システム１２６、画像保存通信システム（ＰＡＣＳ）１２７、および病院情報システム１２８と通信してもよい。

また、例示実施形態では、システム１００の医療感知ツールは、規格銅線リンクまたは光ファイバリンクなどの有線接続を介して、処理システム１０１に通信可能に接続するが、代替の実施形態では、ツールは、米国電気電子学会（ＩＥＥＥ）８０２．１１ワイファイ（Ｗｉ−Ｆｉ、登録商標）規格、超広帯域無線（ＵＷＢ）規格、無線ファイヤワイヤ（ＦｉｒｅＷｉｒｅ、登録商標）、無線ＵＳＢ、または別の高速無線ネットワーク規格を用いる無線接続を介して、処理システム１０１に接続されてもよい。

医療感知システム１００では、ＩＶＵＳ ＰＩＭ１１２およびＯＣＴ ＰＩＭ１１４は、それぞれ患者１０６からＩＶＵＳカテーテル１０８およびＯＣＴカテーテル１１０によって収集した医療感知データを受信するように操作可能であり、受信したデータを制御室１０４の処理システム１０１に送信するように操作可能である。一実施形態では、ＩＶＵＳ ＰＩＭ１１２およびＯＣＴ ＰＩＭ１１４は医療感知データを周辺機器相互接続エクスプレス（ＰＣＩｅ）データバス接続で送信するが、別の実施形態では、データをＵＳＢ接続、サンダーボルト（登録商標）接続、ファイヤワイヤ接続、または別の高速データバス接続で送信してもよい。一実施形態では、ＰＩＭ１１２および１１４はアナログ／デジタル（Ａ／Ｄ）変換器を含み、デジタルデータを処理システム１０１に送信する。ただし、別の実施形態では、ＰＩＭはアナログデータを処理システムに送信する。また、ＥＣＧ装置１１６は、患者１０６からの心電図信号または別の血行動態データを処理システム１０１に送信するように操作可能である。一部の実施形態では、処理システム１０１は、ＥＣＧ１１６からのＥＧＧ信号を用いてカテーテル１０８および１１０から収集したデータを同期するように操作可能であってもよい。さらに、血管造影システム１１７は患者１０６のＸ線、コンピュータ断層撮影（ＣＴ）、または磁気共鳴画像（ＭＲＩ）を収集し、処理システム１０１に送信するように操作可能である。一実施形態では、血管造影システム１１７は、処理システム１０１にネットワーク１２５を通じて通信可能に接続してもよいが、別の実施形態では、血管造影システムは、より直接的に、たとえばアダプタ装置を通じて処理システム１０１と接続してもよい。このようなアダプタ装置は第三者（サードパーティ）独自仕様のフォーマットからのデータを、処理システム１０１が使用可能なフォーマットに変換してもよい。一部の実施形態では、処理システム１０１は、血管造影システム１１７（たとえばＸ線データ、ＭＲＩデータ、ＣＴデータなど）からの画像データをＩＶＵＳカテーテル１０８およびＯＣＴカテーテル１１０からの感知データと相互に位置合わせしてもよい。この１つの態様として、相互の位置合わせ（ｃｏ−ｒｅｇｉｓｔｒａｔｉｏｎ）を実施して、感知データを有する三次元画像を生成してもよい。

ベッドサイド制御面１１８はまた、処理システム１０１にＢＵＢ１２４を介して通信可能に接続し、患者１０６を診察するために用いる特定の（１または複数の）医療感知手法のユーザ制御を提供する。該実施形態では、ベッドサイド制御面１１８はタッチ画面であり、ユーザ制御および診断画像を単一の表面（ｓｕｒｆａｃｅ）上に提供する。ただし、代替的な実施形態では、ベッドサイド制御面１１８は、非双方向型ディスプレイと、物理的ボタンおよび／またはジョイスティックなどの個別の制御の両方を含んでいてもよい。統合医療感知システム１００では、ベッドサイド制御面１１８は、ワークフロー制御オプションおよび患者画像データをグラフィカルユーザインタフェース（ＧＵＩ）内で提示するように操作可能である。ベッドサイド制御面１１８は複数の手法に対するＧＵＩを表示することが可能であるため、臨床医療者は感知手法を切り替えるときに、物理的にユーザインタフェース装置間を移動する必要はない。

制御室１０４内の制御室制御面１２０はまた、処理システム１０１に通信可能に接続し、図１に示すように、カテーテル検査室１０２に隣接する。該実施形態では、制御室制御面１２０は、タッチ画面を含み、異なる医療感知手法に対応する複数のＧＵＩベースのワークフローを表示するように操作可能であるという点で、ベッドサイド制御面１１８に類似する。一部の実施形態では、制御室制御面１２０を用いて、ベッドサイド制御面１１８とは異なる態様の処置のワークフローを同時に実行してもよい。代替的な実施形態では、制御室制御面１２０は、非双方向型ディスプレイと、マウスおよびキーボードなどのスタンドアローン制御とを含んでいてもよい。

本システム１００は、処理システム１０１に通信可能に接続するブームディスプレイ１２２をさらに含む。ブームディスプレイ１２２は複数のモニタを配列した物を含んでいてもよい。各モニタは医療感知処置に関連する異なる情報を表示可能である。たとえば、ＩＶＵＳ処置中に、ブームディスプレイ１２２の１つのモニタは断層画像を表示してもよく、別のモニタは矢状面を表示してもよい。

図２を参照すると、医療感知システム１００の集学的処理システム１０１の実施形態で実行するソフトウェアフレームワークの機能ブロック図が例示されている。一般に、処理システム１０１のソフトウェアフレームワークはモジュール式かつ拡張可能である。つまり、ソフトウェアフレームワークは、それぞれ特定の医療感知手法に関連する独立したソフトウェアモジュールによって駆動される。このモジュール式設計によって、フレームワークは、既存の機能性に影響を与えずに追加の医療感知手法に対応するように拡張可能となる。さらに、内部メッセージシステムによって、フレームワークのソフトウェアモジュール間の独立したデータ通信が促進される。

さらに詳細には、図２に示す実施形態において、処理システム１０１は複数の医療感知装置から医療感知データを受信するように通信可能に接続し、操作可能である。たとえば、ＩＶＵＳ ＰＩＭ１１２、ＯＣＴ ＰＩＭ１１４、ＥＣＧシステム１１６、および冠血流予備量値（ＦＦＲ）ＰＩＭ１３０は、ＰＣＩｅ接続を介して本システム１０１に通信可能に接続する。また、ＦＬＩＶＵＳ ＰＩＭ１３２はＵＳＢ接続を介して本システム１０１に通信可能に接続し、およびＩＣＥ ＰＩＭ１３４はファイヤワイヤ接続を介して本システム１０１に通信可能に接続する。別の実施形態では、追加のおよび／または異なる医療感知装置は、従来技術で既知の追加のおよび／または異なるデータ通信接続を介して処理システム１０１に接続されてもよい。前述したように、一部のＰＩＭはアナログ医療感知データを処理システム１０１に送信してもよい。このような事例では、たとえば、本システム１０１に搭載するＰＣＩｅハードウェアによって、医療感知データを届き次第デジタル化してもよい。

処理システム１０１とそこに接続する医療感知装置との間の通信を促進するために、ソフトウェアフレームワークは、それぞれの手法（つまり医療感知装置）に関連する複数のデータ取得モジュールを含む。たとえば、ＩＶＵＳ取得モジュール１３６はＩＶＵＳデータをＩＶＵＳ ＰＩＭ１１２からＰＣＩｅバスを介して受信するように操作可能である。同様に、ＦＦＲ取得モジュール１３８はＦＦＲデータをＦＦＲ ＰＩＭ１３０からＰＣＩｅバスを介して受信するように操作可能であり、ＦＬＩＶＵＳ取得モジュール１４０はＦＬＩＶＵＳデータをＦＬＩＶＵＳ ＰＩＭ１３２からＵＳＢバスを介して受信するように操作可能であり、ＩＣＥ取得モジュール１４２はＩＣＥデータをＩＣＥ ＰＩＭ１３４からファイヤワイヤバスを介して受信するように操作可能であり、ＯＣＴ取得モジュール１４４はＯＣＴデータをＯＣＴ ＰＩＭ１１４からＰＣＩｅバスを介して受信するように操作可能である。取得モジュール１３６、１３８、１４０、１４２、および１４４がデータを接続した医療感知装置から受信すると、モジュールはデータをパケット化して、システム間通信を促進する。具体的には、モジュールは、着信したデジタルデータストリームから複数のメッセージを作成するように操作可能であり、各メッセージはデジタル化された医療感知データの一部およびヘッダを含有する。メッセージヘッダは、メッセージ内に含有される医療感知データに関連する情報を含有する。これらのメッセージのフォーマットを図３に関連して詳細に記載する。さらに、一部の実施形態では、取得モジュール１３６、１３８、１４０、１４２、および１４４は、データをパケット化する前に、何らかの方法でデジタル化された医療感知データを操作するように操作可能であってもよい。たとえば、取得モジュールは感知データを圧縮して、システム間通信をより効率的にしてもよく、またはデータを正規化、基準化またはその他の方法でフィルタリングして、後のデータ処理を補助してもよい。一部の実施形態では、この操作は手法に固有のものであってもよい。たとえば、ＯＣＴ取得モジュール１４４は、データをパケット化する前に、重複するＯＣＴデータを識別して廃棄し、後の処理時間を短くしてもよい。取得モジュール１３６、１３８、１４０、１４２、および１４４は、データ取得に関する複数のタスクを更に実行してもよい。複数のタスクには、データバス（たとえばＰＣＩｅ、ＵＳＢ）が生成する割り込みに応答すること、どの医療感知装置が処理システム１０１に接続しているかを検出すること、接続した医療感知装置に関する情報を取り出すこと、感知装置特有のデータを記憶すること、リソースをデータバスに割り当てることが含まれる。ソフトウェアフレームワークのモジュール式構造（アーキテクチャ）にしたがって、データ取得モジュールはお互いに独立し、別のモジュールによるデータ取得を妨害せずにインストールまたは削除されてもよい。また、取得モジュールは、下位のデータバスソフトウェア層とは（たとえばアプリケーションプログラミングインタフェース（ＡＰＩ）の使用によって）独立しており、そのため、第三者医療感知装置からのデータを取得するために第三者によって書き込まれてもよい。

ソフトウェアフレームワークはメッセージキュー１４６をさらに含み、処理システム１０１内の異なる構成部品間のシステム間通信を促進する。メッセージキュー１４６はメッセージをシステム１０１のフレームワーク内のソフトウェアモジュールから受信し、一時的にメッセージを記憶し、メッセージをフレームワーク内のソフトウェアモジュールによって検索可能とするように操作可能である。たとえば、取得モジュール１３６、１３８、１４０、１４２、および１４４が、着信した医療感知データをメッセージにパケット化した後に、メッセージをメッセージキュー１４６に送り、メッセージはメッセージキュー１４６で次の処理を待つ。一実施形態では、メッセージキュー１４６は、各感知手法に関連するメッセージに対する手法特有のキューを含む。たとえば、このような事例では、メッセージキュー１４６の一部には、ＩＶＵＳデータ取得モジュール１３６から受信したＩＶＵＳデータを含有するメッセージを割り当ててもよい。さらに、一部の実施形態では、メッセージキュー１４６は、受信したメッセージを先入れ先出し（ＦＩＦＯ）の様式で利用可能とするように操作可能であり、最初にバスに到着するメッセージは、最初にバスから削除される。代替的な実施形態では、メッセージキュー１４６は、メッセージを異なる様式で、たとえばメッセージヘッダに記憶される優先順位の値によって、利用可能としてもよい。一実施形態では、メッセージキュー１４６は処理システム１０１のランダムアクセスメモリ（ＲＡＭ）内に実装されるが、別の実施形態では、メッセージキューは、不揮発性ＲＡＭ（ＮＶＲＡＭ）、二次記憶装置（たとえば磁気ハードドライブ、フラッシュメモリなど）、またはネットワークベースの記憶装置に実装されてもよい。さらに、一実施形態では、メッセージキュー１４６に記憶されるメッセージに、処理システム１０１内のソフトウェアおよびハードウェアモジュールが、ダイレクトメモリアクセス（ＤＭＡ）を用いてアクセスしてもよい。

処理システム１０１のソフトウェアフレームワークは、処理プラグイン（またはモジュール）の層１５０をサポートする処理ソフトウェアスタック１４８をさらに含む。一般に、層１５０の各処理プラグインは医療感知手法に対応し、その特定の感知手法に関連するデータを処理する。たとえば、層１５０のＩＶＵＳ処理プラグインはＩＶＵＳ ＰＩＭ１１２から受信したＩＶＵＳデータを解釈して、そのデータを表示可能なＩＶＵＳ画像に変換してもよい。一実施形態では、ソフトウェアスタック１４８は、一式のアプリケーションプログラミングインタフェース（ＡＰＩ）を露出してもよい。このＡＰＩを用いて、層１５０のプラグインは、メッセージキュー１４６、計算リソース、および通信リソースなどのシステムリソースにアクセスするためにコールしてもよい。さらに、一部の実施形態では、プラグイン層１５０は、相互の位置合わせプラグインを含んでいてもよい。この相互の位置合わせプラグインでは、複数の医療感知装置からの医療感知データが解釈され、相互に位置を合わせられる。このような相互の位置合わせアプリケーションをサポートするために、一実施形態では、ソフトウェアスタック１４８は、プラグインが使用するための時刻同期ＡＰＩを露出してもよい。また、ソフトウェアスタック１４８が露出するＡＰＩは、それを通じて、専用の相互の位置合わせモジュール、相互の位置合わせデータを含有するデータベース、または血管造影システム１１７またはＭＲＩシステムなどの、相互の位置合わせに用いるためのリアルタイムなデータを作成する感知システムに、処理モジュールがアクセスしてもよいＡＰＩであってもよい。

層１５０の処理プラグインは、未処理の医療感知データを含有する、メッセージキュー１４６上のメッセージを取り出すように操作可能である。たとえば、１または複数のＡＰＩを用いて、感知手法に関連するプラグインはメッセージキュー１４６にクエリーを実行して、感知手法に対応するメッセージがバス上で処理を待っているかを判断してもよい。感知手法に対応するメッセージがバス上で処理を待っている場合は、プラグインは（ＦＩＦＯを用いる実施形態では）１または複数の最も古いメッセージを取り出して、メッセージ内の未加工データを処理してもよい。データを処理した後に、プラグインはデータを再パケット化して、処理されたデータを含有するメッセージをメッセージキュー１４６に戻してもよい。一部の実施形態では、メッセージをバスに送信する前に、プラグインは、処理されたデータをメッセージが含有することを示すフラグをヘッダに挿入してもよい。ただし、別の実施形態では、フラグを挿入するのではなく、プラグインはその代わりに、処理されたデータを含有するメッセージ用に割り当てられるメッセージキュー１４６のキューに、メッセージを配置してもよい。または、プラグインはメッセージ内の医療感知データが処理済みであることを示す何らかの別の操作を実行してもよい。また、一部の実施形態では、医療感知データを処理した後に、プラグインは処理されたデータを、ローカルに取り付けられた大容量記憶装置またはネットワークベースのＰＡＣＳサーバ１２７などのアーカイブシステムに送信してもよい。

ソフトウェアフレームワークのモジュール式構造によると、層１５０の処理プラグインはお互いに独立し、かつソフトウェアスタック１４８とも独立している。層１５０の処理プラグインは、別のプラグインを妨害せずにインストールまたは削除されてもよく、第三者によって書き込まれてもよい。さらに、複数の医療感知装置からの信号および撮像データを同時に処理するように操作可能である。この点から、一部の実施形態では、処理ソフトウェアスタック１４８は、同時に実施する処理プラグインに共通な包括的な計算（コンピューティング）タスクを特定することによって、集中的に計算リソースを利用してもよい。たとえば、処理ソフトウェアスタック１４８は、（異なる手法に関連する）２つの処理プラグインそれぞれが、着信した感知データのフィルタリング、画像処理、および走査変換処理を実行する必要があることを判断してもよい。これらの共通タスクが特定されると、ソフトウェアスタック１４８は、並列アルゴリズムのライブラリを使用して、これらのタスクを同時に処理してもよい。

処理システム１０１のソフトウェアフレームワークは、ユーザインタフェースソフトウェアスタック１５２をさらに含む。ユーザインタフェースソフトウェアスタック１５２は、グラフィカルユーザインタフェース（ＧＵＩ）プラグイン（またはモジュール）の層１５４をサポートする。一般に、層１５４の各ＧＵＩプラグインは医療感知手法に対応する。そして、該プラグインは、関連する取得ワークフローを制御するため、及び処理された感知データを表示するためのユーザインタフェースをレンダリングするように操作可能である。一実施形態では、ユーザインタフェースソフトウェアスタック１５２は、ＡＰＩを露出してもよい。このＡＰＩを通じて、プラグイン層１５４のプラグインは、メッセージキュー１４６、ルックアンドフィールツールボックス、およびエラー処理リソースなどのシステムリソースにアクセスするためにコールしてもよい。ルックアンドフィールツールボックスＡＰＩによって、ＧＵＩプラグインは共通ボタンを備える規格ユーザインタフェース、並行ワークフローフォーマット、データプレゼンテーションスキームを提示可能となる。このようにして、臨床医療者は、追加のユーザインタフェースの訓練を受けることなく、複数の取得手法間での移行を更に容易にすることができる。さらに、層１５４の相互の位置合わせＧＵＩプラグインは、複数の手法からの処理された画像または信号データを提示および／または組み合わせてもよい。たとえば、ＧＵＩプラグインは、心電図（ＥＣＧ）波形をＩＶＵＳ撮像データに隣接して表示してもよく、またはＯＣＴ画像上に前もって書かれていた輪郭上に重ねてＩＶＵＳ画像を表示してもよい。さらに、一部の実施形態では、ＵＩソフトウェアスタック１５２はマルチタスクフレームワークを含み、複数のＧＵＩプラグインを同時に実行するための調整を行ってもよい。たとえば、処理システム１０１が同時に２つ以上の手法に関連するデータを取得する場合には、ＵＩソフトウェアスタックは所望のＧＵＩを選択することができる手法選択画面をユーザに提示してもよい。

層１５４のＧＵＩプラグインは、処理された医療感知データを含有するメッセージをメッセージキュー１４６から取り出すように操作可能である。たとえば、１または複数のＡＰＩを用いて、感知手法に関連するプラグインはメッセージキュー１４６にクエリーを行い、感知手法に関連するメッセージがバス上で待ち状態にあるかを判断してもよい。感知手法に関連するメッセージがバス上で処理を待っている場合は、プラグインは（ＦＩＦＯを用いる実施形態では）１または複数の最も古いメッセージを取り出して、ルックアンドフィールツールボックスＡＰＩを用いてその中の処理されたデータをレンダリングしてもよい。レンダリングされたＧＵＩを次に、ベッドサイド制御面１１８、制御室制御面１２０、およびブームディスプレイ１２２などの１または複数の制御／ディスプレイ装置上に表示してもよい。さらに、一部の実施形態では、追加の制御装置１５５（たとえばボタンコンソール、マウス、キーボード、タッチパッド）を処理システム１０１に通信可能に接続し、ＧＵＩとのユーザインタラクションを促進してもよい。一部の実施形態では、処理システム１０１は、遠隔ネットワークに接続する装置が、レンダリングされたＧＵＩに、データネットワーク１２５を介してアクセスできるようにしてもよい。このようにして、カテーテル検査室１０２の外側にいる臨床医療者は、データ取得ワークフローを制御してもよく、または受動的に医療感知画像を監視してもよい。さらに、一部の実施形態では、処理システム１０１は、独立したＧＵＩを異なる制御装置に出力するように操作可能であってもよく、それによって臨床医療者は、同一の感知データを同時に用いて、複数のワークフローを実行してもよい。また、ソフトウェアフレームワークのモジュール式構造によれば、層１５４のＧＵＩプラグインはお互いに独立し、かつソフトウェアスタック１５２とも独立している。層１５４のＧＵＩプラグインは、別のプラグインを妨害せずにインストールまたは削除されてもよく、第三者によって書き込まれてもよい。

ソフトウェアフレームワークは追加のソフトウェアモジュールをさらに含み、集学的データの取得および処理を促進する。たとえば、処理システムはワークフローモジュール１５６を含む。一般に、ワークフローモジュール１５６は、処理システム１０１のデータ取得ワークフローを設定および調整するように操作可能である。一部の実施形態では、ワークフローモジュール１５６は、ネットワーク１２５を介してＤＩＣＯＭサーバ１２６またはＨＩＳ１２８と通信するように操作可能であってもよく、それによって、スケジューリング情報などの患者処置情報を取り出す。また、ワークフローモジュール１５６は、処理システム１０１の感知能力をＤＩＣＯＭサーバ１２６またはＨＩＳ１２８に報告してもよく、それによって適切なワークフローが処理システム１０１に割り当てられる。さらに、一部の実施形態では、ワークフローモジュール１５６は、患者情報および処置をメッセージキュー１４６に記憶されるメッセージに関連づけるように操作可能であってもよい。たとえば、モジュール１５６は、患者情報をＤＩＣＯＭサーバ１２６から取り出して、メッセージをアーカイブ化する前に、患者から取得したデータを含有するメッセージのヘッダに情報を挿入してもよい。

さらに、処理システム１０１上のソフトウェアフレームワークは相互の位置合わせモジュール１５８を含む。一般に、相互の位置合わせモジュール１５８は、異なる感知手法に関連する医療感知データの相互の位置合わせを促進する。たとえば、モジュール１５８は、血管造影システム１１７からの取得データとＩＶＵＳ ＰＩＭ１１２からの取得データとを調整してもよい。一部の実施形態では、血管造影システム１１７はＸ線撮像データを含有するメッセージをメッセージキュー１４６に送信してもよく、相互の位置合わせモジュール１５８はこれらのメッセージを取り出し、データを抽出し、データをデータ取得モジュール１３６、１３８、１４０、１４２、および１４４のうちの１つによってメッセージキューに配置されたメッセージから抽出したデータと相互に位置合わせする。さらに別の実施形態では、相互の位置合わせモジュール１５８は、カテーテルで収集したデータを、従前に収集した２Ｄ画像または３Ｄモデルを用いて二次元または三次元空間で空間的に相互に位置を合わせるように操作可能であってもよい。たとえば、カテーテルベースの感知ツールは、基準点を含んでいてもよく、該基準点を追跡して、感知処置中の位置データを生成してもよい。また、相互の位置合わせモジュール１５８はこの位置データを従前に取得したＭＲＩデータに対して位置合わせしてもよい。

また、別の実施形態では、相互の位置合わせモジュール１５８は、相互の位置合わせを目的として処理システム１０１に接続する医療感知装置間で時刻同期を促進するように操作可能であってもよい。たとえば、一実施形態では、相互の位置合わせモジュール１５８は、高精度タイムプロトコル（ＰＴＰ）またはネットワークタイムプロトコル（ＮＴＰ）などのネットワークベースの時刻同期プロトコルを用いて、ＰＩＭ１１２、１３０、１３２、１３４、および１１４のマスタタイムサーバとして機能するように操作可能であってもよい。別の実施形態では、相互の位置合わせモジュール１５８は、複数の医療感知装置からメッセージキュー１４６に到着したデータに共通タイムスタンプを割り当てるように操作可能であってもよい。さらに別の実施形態では、処理システム１０１は、接続した医療感知装置によるサンプリングを同期する専用のリアルタイムクロックを含んでいてもよい。このような実施形態では、相互の位置合わせモジュール１５８は、リアルタイムクロックを利用して、接続した感知装置に同期信号を配布してもよい。一部の実施形態では、リアルタイムクロックは相互の位置合わせモジュール１５８に内蔵されてもよい。「分散医療感知システムおよび方法」という名称の２０１１年４月８日出願の米国仮特許出願第６１／４７３，５９１号は、一時的な同期医療感知データ収集をより詳細に開示し、その全体は参照により本明細書に組み込まれる。

処理システム１０１上のソフトウェアフレームワークはまた、第三者コントローラ１６２との通信を促進するための外部コントローラモジュール１６０を含む。一実施形態では、コントローラモジュール１６０は、処理システム１０１の制御機能性を第三者コントローラ１６２にエクスポートするように操作可能である。それによって、コントローラ１６２はそのユーザインタフェースの制御機能を提示してもよい。さらに、処理システム１０１のＤＩＣＯＭクライアントモジュール１６４はＤＩＣＯＭサーバ１２６との通信を促進してもよい。

ここで図３を参照すると、本開示の一実施形態における集学的処理システム１０１が利用するメッセージフォーマットが例示される。前述したように、データ取得モジュール１３６、１３８、１４０、１４２、および１４４は、着信した医療感知データを、デジタル化された感知データおよび関連する識別情報を含有する複数のメッセージに変換してもよい。図３は例としてメッセージ１８０を例示する。メッセージ１８０はヘッダ１８２と、ペイロード１８４とを含む。ペイロード１８４は、処理システム１０１に接続する医療感知装置で収集したデジタル化された医療感知データを含む。ヘッダ１８２は、ペイロード１８４の感知データに関連する情報を含む。例示実施形態では、ヘッダ１８２は、データに関連する手法情報およびタイムスタンプをそれぞれ含有するブロック１８６および１８８を含む。ブロック１８６の手法情報はペイロード１８４のデータの手法（たとえばＩＶＵＳ、ＯＣＴなど）を含んでいてもよい。一部の実施形態では、ブロック１８６の手法情報はまた、データを取得する際に用いた特定の医療感知装置（たとえばカテーテル、ＰＩＭなど）に関する情報を含んでいてもよい。さらに、ブロック１８８のタイムスタンプは、ペイロード１８４内のデータが収集された時点に対応してもよい。一部の実施形態では、タイムスタンプ値は起点となるＰＩＭによって提示されてもよいが、別の実施形態では、タイムスタンプは相互の位置合わせモジュール１５８、またはメッセージの作成を担当するデータ取得モジュールによって提示されてもよい。ブロック１８８のタイムスタンプ（または連続番号）を用いて、ペイロード１８４の感知データと異なる手法のデータとを時間的に相互に位置合わせすることを促進してもよい。別の実施形態では、ヘッダ１８２は、ペイロード１８４のデータに関連する追加の情報を含んでいてもよい。追加の情報とは、処置日および時間、処置の場所（たとえば医療施設、カテーテル検査室など）、患者識別情報（たとえば氏名、社会保障番号、出生日など）、および医師識別情報（たとえば氏名、登録番号など）、アナログ／デジタル変換情報、圧縮情報、データの処理状態を示すフラグ、およびワークフロー識別情報などである。

図４は集学的処理システム１０１の医療感知データを処理する方法２００を例示するハイレベルフローチャートである。より具体的には、方法２００はデータメッセージが処理システム１０１のモジュール式構造内を移動する様式を記載する。明確にするために、以下の例ではＩＶＵＳデータの取得に焦点を当てるが、処理システム１０１がサポートする別の感知手法にも同様に適用してもよい。方法２００はブロック２０２で開始する。ブロック２０２では、ＩＶＵＳ ＰＩＭ１１２からの未処理のＩＶＵＳデータのストリームがＩＶＵＳデータ取得モジュール１３６によって受信される。本例では、ＩＶＵＳデータはＩＶＵＳ ＰＩＭ１１２によってデジタル化されているため、デジタル方式で到着する。方法２００はブロック２０４に進む。ブロック２０４では、ＩＶＵＳデータ取得モジュール１３６はデータストリームをパケット化する。具体的には、データ取得モジュール１３６は、データの一部、データの手法を識別する情報、およびタイムスタンプを含有する複数のメッセージを作成する。次に、方法２００はブロック２０６に続く。ブロック２０６では、ＩＶＵＳデータ取得モジュール１３６はＩＶＵＳメッセージをメッセージキュー１４６に配置する。次に、ブロック２０８において、ソフトウェア層１５０のＩＶＵＳ処理プラグインはＩＶＵＳメッセージがバス上に配置された順番にしたがって（つまりＦＩＦＯ）、ＩＶＵＳメッセージをメッセージキュー１５０から取り出す。方法２００は次に、ブロック２１０に進む。ブロック２１０では、ＩＶＵＳ処理プラグインはＩＶＵＳデータをメッセージから抽出し、データを解釈し、処理ソフトウェアスタック１４８によって露出されるＡＰＩを用いてＩＶＵＳ画像をレンダリングする。次に、ブロック２１２において、ＩＶＵＳ処理プラグインは処理されたＩＶＵＳデータを再パケット化し、メッセージキュー１４６上に再び配置する。一部の実施形態では、ＩＶＵＳプラグインはまた、ＰＡＣＳサーバ１２７などの記憶装置でアーカイブ化されるように、処理されたＩＶＵＳ画像を送信する。方法２００は次に、ブロック２１４に進む。ブロック２１４では、ソフトウェア層１５４のＩＶＵＳ ＧＵＩプラグインは、処理されたＩＶＵＳデータを含有するメッセージを、ＩＶＵＳ処理プラグインによってＩＶＵＳメッセージがバス上に配置された順番にしたがって、メッセージキュー１４６から取り出す。最後に、方法２００はブロック２１６に進む。ブロック２１６では、ＩＶＵＳ ＧＵＩプラグインはＩＶＵＳ画像データを抽出し、ＩＶＵＳワークフローＧＵＩの一部として、ベッドサイド制御面１１８または別のコントローラ上に表示する。繰り返すが、前述のＩＶＵＳメッセージフローは例に過ぎない。しかし、該フローは、処理システム１０１の別の感知手法に関連するデータのメッセージフローの代表するものと言える。

ここで図５および図６を参照すると、図５は、本開示の別の実施形態による集学的処理システム２５２を含む医療感知システム２５０を示す概略図である。図６は、図５の集学的処理システム２５２の斜視図である。

システム１００の処理システム１０１と同様に、医療感知システム２５０の集学的処理システム２５２は、集学的医療感知データを取得し、制御し、解釈し、表示するための統合装置である。この点から、処理システム２５０は、（図２に示す）処理システム１０１と同様のソフトウェアフレームワークを含有する。ただし、処理システム２５２は移動式であり、カテーテル検査室間を移動してもよい。例示実施形態では、処理システム２５０は図示の時点でカテーテル検査室１０２に位置し、ＩＶＵＳおよびＯＣＴワークフローを患者１０６に実施している。医療感知システム２５０では、ＩＶＵＳ ＰＩＭ１１２、ＯＣＴ ＰＩＭ１１４、ＥＣＧシステム１１６、血管造影システム１１７、ブームディスプレイ１２２、およびデータネットワーク１２５は、処理システム２５０に通信可能に接続する。システム２５０の医療感知ツールはお互いに、かつ処理システム２５２に有線接続（たとえば規格銅線リンク、光ファイバリンク）を介して通信可能に接続するように図示されるものの、別の実施形態では、ツールは処理システム２５２に無線接続（たとえばＩＥＥＥ８０２．１１ワイファイ、ＵＷＢ、無線ファイヤワイヤ、無線ＵＳＢ）を介して接続されてもよい。

さらに、図６に示すように、処理システム２５２は車輪付カート２５４上に載っており、本システムの移動性を高める。一部の実施形態では、カート２５４は、配線管理システムを含んでいてもよく、本システム２５２に取り付けられる様々な配線を制御する。また、コントローラ２５６はカート２５４上に載っており、処理システム２５２に通信可能に接続する。コントローラ２５６はワークフローを実施する臨床医療者にＧＵＩを提示するように操作可能である。例示実施形態では、コントローラ２５６はタッチ画面であり、単一の表面上でユーザ制御および診断画像を提供する。ただし、代替的な実施形態では、コントローラ２５６は、非双方向型ディスプレイと、物理的ボタンおよび／またはジョイスティックなどの個別の制御との両方を含んでいてもよい。

例示実施形態を図示し、説明してきたが、広範な修正、変更および代替を前述の開示において企図している。ある事例では、本開示の一部の特徴を、該特徴に対応する別の特徴を使用することなく、使用してもよい。たとえば、一部の実施形態では、集学的処理システム１０１および２５２を用いて、頭部動脈または抹消動脈からのデータなどの心臓血管ではない診断データ、ならびに脈管ではない身体部分からのデータを処理してもよい。さらに、システム１０１および２５２を用いて、ＭＲＩデータを収集および処理してもよく、または、コンピュータ支援手術（ＣＡＳ）での応用に用いてもよい。さらに、集学的処理システムに関して前述したモジュールは、ハードウェア、ソフトウェア、またはその両方の組み合わせにおいて実装されてもよい。処理システムは、任意の特定の構造上で機能するように設計されてもよい。たとえば、本システムは、単一のコンピュータ、ローカルエリアネットワーク、クライアントサーバネットワーク、ワイドエリアネットワーク、インターネット、携帯および別のポータブルおよび無線装置およびネットワーク上で実施されてもよい。このような変形は、本開示の範囲から逸脱することなく、前述のように行うことができることを理解されたい。したがって、添付の請求項が広範に、かつ本開示の範囲と一致する様式で解釈されることが適切である。
一側面において本発明は以下の発明を包含する。
（発明１）
第１の医療感知装置に通信可能に接続する計算システムを備える医療感知システムであって、前記計算システムは、
第１の医療感知手法に関連し、前記第１の医療感知手法に関連する第１の患者データを前記第１の医療感知装置から受信するように操作可能である第１のデータ取得モジュールであって、前記第１のデータ取得モジュールは、前記第１の患者データをパケット化するように操作可能であり、複数のデータ取得モジュールのうちの１つである第１のデータ取得モジュールと、
前記第１の医療感知手法に関連し、前記パケット化された第１の患者データを処理するように操作可能である第１の処理モジュールであって、前記第１の処理モジュールは複数の処理モジュールのうちの１つである第１の処理モジュールと、
前記第１の医療感知手法に関連し、前記処理済みのパケット化された第１の患者データを第１のグラフィカルユーザインタフェース内で提示するように操作可能である第１のユーザインタフェースモジュールであって、前記第１のユーザインタフェースモジュールは複数のユーザインタフェースモジュールのうちの１つである第１のユーザインタフェースモジュールと、
前記第１のデータ取得モジュール、第１の処理モジュール、および第１のユーザインタフェースモジュールと通信するメッセージキューモジュールであって、前記メッセージキューモジュールは、前記パケット化された第１の患者データを前記モジュールから受信し、前記パケット化された第１の患者データを一時的に記憶し、前記パケット化された第１の患者データを前記モジュールによって検索可能とするように操作可能である、メッセージキューモジュールと、
を含む、医療感知システム。
（発明２）
発明１に記載の医療感知システムであって、前記計算システムはさらに、
第２の医療感知手法に関連し、前記第２の医療感知手法に関連する第２の患者データを第２の医療感知装置から受信するように操作可能である第２のデータ取得モジュールであって、前記第２のデータ取得モジュールは、前記第２の患者データをパケット化するように操作可能であり、前記複数のデータ取得モジュールのうちの１つである第２のデータ取得モジュールと、
前記第２の医療感知手法に関連し、前記パケット化された第２の患者データを処理するように操作可能である第２の処理モジュールであって、前記第２の処理モジュールは前記複数の処理モジュールのうちの１つである第２の処理モジュールと、
前記第２の医療感知手法に関連し、前記処理済みのパケット化された第２の患者データを第２のグラフィカルユーザインタフェースで提示するように操作可能である第２のユーザインタフェースモジュールであって、前記第２のユーザインタフェースモジュールは前記複数のユーザインタフェースモジュールのうちの１つである第２のユーザインタフェースモジュールと、
を含み、
前記第２の医療感知手法は前記第１の医療感知手法とは異なる、医療感知システム。
（発明３）
前記第１および第２の処理モジュールは、それぞれ前記第１および第２の患者データを同時に処理するように操作可能である、発明２に記載の医療感知システム。
（発明４）
前記第１のデータ取得モジュール、第１の処理モジュール、および第１のユーザインタフェースモジュールはそれぞれ、アプリケーションプログラミングインタフェースを介してメッセージキューモジュールと通信する、発明１に記載の医療感知システム。
（発明５）
前記第１の医療感知手法は、血管内超音波（ＩＶＵＳ）撮像、血管内光音響（ＩＶＰＡ）撮像、光干渉断層撮影（ＯＣＴ）、フォワードルッキングＩＶＵＳ（ＦＬ−ＩＶＵＳ）、冠血流予備量値（ＦＦＲ）、冠血流予備能（ＣＦＲ）、および血管造影のうちの１つである、発明１に記載の医療感知システム。
（発明６）
前記第１のデータ取得モジュールは識別情報を前記パケット化された第１の患者データに関連づけるように操作可能である、発明１に記載の医療感知システム。
（発明７）
前記識別情報は、前記第１の医療感知手法を識別する情報を含む、発明６に記載の医療感知システム。
（発明８）
処理スタックを含む前記計算システムは、アプリケーションプログラミングインタフェースを前記複数の処理モジュールに露出するように操作可能である、発明１に記載の医療
感知システム。
（発明９）
前記複数の処理モジュールの既存の処理モジュールを変えずに、追加の処理モジュールが前記複数の処理モジュールに追加されてもよいという点で、前記複数の処理モジュールはお互いに独立している、発明１に記載の医療感知システム。
（発明１０）
ユーザインタフェーススタックを含む前記計算システムは、アプリケーションプログラミングインタフェースを前記複数のユーザインタフェースモジュールに露出するように操作可能である、発明１に記載の医療感知システム。
（発明１１）
前記複数のユーザインタフェースモジュールの既存のユーザインタフェースモジュールを変えずに、追加のユーザインタフェースモジュールが前記複数のユーザインタフェースモジュールに追加されてもよいという点で、前記複数のユーザインタフェースモジュールはお互いに独立している、発明１に記載の医療感知システム。
（発明１２）
第１の医療感知装置に通信可能に接続する計算システムを備える医療感知システムであって、
前記計算システムは、
第１の医療感知手法に関連し、前記第１の医療感知手法に関連する第１の患者データを前記第１の医療感知装置から受信するように操作可能である第１のデータ取得モジュールであって、前記第１の取得モジュールは、前記第１の患者データを含有する第１の複数のメッセージを作成するようにさらに操作可能である第１のデータ取得モジュールと、
前記第１の複数のメッセージを前記第１のデータ取得モジュールから受信し、一時的に記憶するように操作可能であるメッセージキューモジュールと、
前記第１の医療感知手法に関連し、前記第１の複数のメッセージを前記メッセージキューモジュールから取り出し、前記第１の複数のメッセージ内の前記第１の患者データを処理し、前記処理された第１の患者データを含有する第２の複数のメッセージを前記メッセージキューモジュールに送信するように操作可能である第１の処理モジュールと、
前記第１の医療感知手法に関連し、前記第２の複数のメッセージを前記メッセージキューモジュールから取り出し、前記処理された第１の患者データを第１のグラフィカルユーザインタフェース内で提示するように操作可能である第１のユーザインタフェースモジュールと、
を含む、医療感知システム。
（発明１３）
発明１２に記載の医療感知システムであって、
前記第１のデータ取得モジュールは複数の取得モジュールのうちの１つであり、
前記第１の処理モジュールは複数の処理モジュールのうちの１つであり、
前記第１のユーザインタフェースモジュールは複数のユーザインタフェースモジュールのうちの１つである、医療感知システム。
（発明１４）
前記計算システムは、アプリケーションプログラミングインタフェースを前記複数の処理モジュールに露出するように操作可能である処理スタックを含む、発明１３に記載の医療感知システム。
（発明１５）
前記処理スタックは、前記複数の処理モジュールまたは前記処理スタックの既存の処理モジュールを変えずに、追加の処理モジュールが前記複数の処理モジュールに追加されてもよいという点で、前記複数の処理モジュールがお互いに独立するように構成される、発明１４に記載の医療感知システム。
（発明１６）
前記複数のユーザインタフェースモジュールまたは前記処理スタックの既存のユーザインタフェースモジュールを変えずに、追加のユーザインタフェースモジュールが前記複数のユーザインタフェースモジュールに追加されてもよいという点で、前記複数のユーザインタフェースモジュールはお互いに独立している、発明１３に記載の医療感知システム。
（発明１７）
前記第１の複数のメッセージのそれぞれは、前記第１の患者データの一部と、前記第１の患者データの前記一部に関連する情報とを含有する、発明１２に記載の医療感知システム。
（発明１８）
前記情報は前記第１の医療感知手法を識別する情報を含む、発明１７に記載の医療感知システム。
（発明１９）
発明１２に記載の医療感知システムであって、前記計算システムはさらに、
第２の医療感知手法に関連し、前記第２の医療感知手法に関連する第２の患者データを第２の医療感知装置から受信するように操作可能である第２のデータ取得モジュールであって、前記第２の取得モジュールはさらに、前記第２の患者データを含有する第３の複数のメッセージを作成するように操作可能である第２のデータ取得モジュールと、
前記第２の医療感知手法に関連し、前記第３の複数のメッセージを前記メッセージキューモジュールから取り出し、前記第３の複数のメッセージ内の前記第２の患者データを処理し、前記処理された第２の患者データを含有する第４の複数のメッセージを前記メッセージキューモジュールに送信するように操作可能である第２の処理モジュールと、
前記第２の医療感知手法に関連し、前記第４の複数のメッセージを前記メッセージキューモジュールから取り出し、前記処理された第２の患者データを第２のグラフィカルユーザインタフェース内で提示するように操作可能である第２のユーザインタフェースモジュールと、
を含み、
前記第２の医療感知手法は前記第１の医療感知手法とは異なる、医療感知システム。
（発明２０）
前記第１および第２の処理モジュールは、それぞれ前記第１および第２の患者データを同時に処理するように操作可能である、発明１９に記載の医療感知システム。
（発明２１）
医療感知データの処理方法であって、
第１の患者データを第１の医療感知装置から受信することとであって、前記第１の患者データは第１の医療感知手法に関連することと、
第１の複数のメッセージを作成することであって、前記第１の複数のメッセージの各メッセージは前記第１の患者データの一部を含有することと、
前記第１の複数のメッセージをメッセージキューのキューに入れることと、
前記第１の複数のメッセージを前記メッセージキューから取り出すことと、
前記第１の複数のメッセージに含有される前記第１の患者データを処理することと、
第２の複数のメッセージを作成することであって、前記第２の複数のメッセージの各メッセージは前記処理された第１の患者データの一部を含有することと、
前記第２の複数のメッセージを前記メッセージキューのキューに入れることと、
前記第２の複数のメッセージを前記メッセージキューから取り出すことと、
前記第２の複数のメッセージに含有される前記処理された第１の患者データを第１のグラフィカルユーザインタフェース内でレンダリングすることと、
を備える、方法。
（発明２２）
発明２１に記載の医療感知データを処理する方法であって、第２の医療感知手法に関連する第２の患者データの処理と、前記第１の患者データの処理とを同時に行うことを含み、前記第２の医療感知手法は前記第１の医療感知手法とは異なる、方法。
（発明２３）
発明２１に記載の医療感知データを処理する方法であって、
前記受信すること、第１の複数のメッセージを作成すること、および前記第１の複数のメッセージをキューに入れることを、前記第１の医療感知手法に関する第１のデータ取得モジュールによって実行し、
前記第１の複数のメッセージを取り出し、処理し、前記第２の複数のメッセージを作成し、前記第２の複数のメッセージをキューに入れることを、前記第１の医療感知手法に関連する第１の処理モジュールによって実行し、
前記第２の複数のメッセージを取り出し、レンダリングすることを、前記第１の医療感知手法に関連する第１のユーザインタフェースモジュールによって実行する、方法。
（発明２４）
発明２３に記載の医療感知データを処理する方法であって、
前記第１のデータ取得モジュールは複数の取得モジュールのうちの１つであり、
前記第１の処理モジュールは複数の処理モジュールのうちの１つであり、
前記第１のユーザインタフェースモジュールは複数のユーザインタフェースモジュールのうちの１つである、方法。
（発明２５）
前記第１の複数のメッセージを作成することは、識別情報を前記第１の複数のメッセージそれぞれの前記第１の患者データの前記一部に関連づけることを含む、発明２１に記載の医療感知データを処理する方法。
（発明２６）
前記識別情報は前記第１の医療感知手法を識別する情報を含む、発明２５に記載の医療感知データを処理する方法。
（発明２７）
前記第１の患者データは、血管内超音波（ＩＶＵＳ）撮像データ、光干渉断層撮影（ＯＣＴ）データ、および冠血流予備量値（ＦＦＲ）データのうちの１つを含む、発明２１に記載の医療感知データを処理する方法。
（発明２８）
発明２１に記載の医療感知データを処理する方法であって、さらに、
第２の患者データを第２の医療感知装置から受信することであって、前記第２の患者データは、前記第１の医療感知手法とは異なる第２の医療感知手法に関連することと、
第３の複数のメッセージを作成することであって、前記第３の複数のメッセージの各メッセージは、前記第２の患者データの一部を含有することと、
前記第２の複数のメッセージを前記メッセージキューに入れることと、
前記第２の複数のメッセージを前記メッセージキューから取り出すことと、
前記第３の複数のメッセージに含有される前記第２の患者データを処理することと、
第４の複数のメッセージを作成することであって、前記第４の複数のメッセージの各メッセージは、前記処理された第２の患者データの一部を含有することと、
前記第４の複数のメッセージを前記メッセージキューのキューに入れることと、
前記第４の複数のメッセージを前記メッセージキューから取り出すことと、
前記第４の複数のメッセージに含有される前記処理された第２の患者データを、第２のグラフィカルユーザインタフェース内でレンダリングすることと、
を含む、方法。
（発明２９）
前記第１の複数のメッセージに含有される前記第１の患者データを処理することと、前記第３の複数のメッセージに含有される前記第２の患者データを処理することを同時に実行する、発明２８に記載の医療感知データを処理する方法。

Claims (16)

1. 第１の医療感知装置に通信可能に接続する計算システムを備える医療感知システムであって、
   前記計算システムは、
   第１の医療感知手法に関連し、前記第１の医療感知手法に関連する第１の患者データを前記第１の医療感知装置から受信するように操作可能である第１のデータ取得モジュールであって、前記第１の取得モジュールは、前記第１の患者データを含有する第１の複数のメッセージを作成するようにさらに操作可能である第１のデータ取得モジュールと、
   前記第１の複数のメッセージを前記第１のデータ取得モジュールから受信し、一時的に記憶するように操作可能であるメッセージキューモジュールと、
   前記第１の医療感知手法に関連し、前記第１の複数のメッセージを前記メッセージキューモジュールから取り出し、前記第１の複数のメッセージ内の前記第１の患者データを処理して相互に位置合わせし、前記処理され相互に位置合わせされた第１の患者データを含有する第２の複数のメッセージを前記メッセージキューモジュールに送信するように操作可能である第１の処理モジュールと、
   前記第１の医療感知手法に関連し、前記第２の複数のメッセージを前記メッセージキューモジュールから取り出し、前記処理された第１の患者データを第１のグラフィカルユーザインタフェース内で提示するように操作可能である第１のユーザインタフェースモジュールと、
   を含む、医療感知システム。
2. 請求項１に記載の医療感知システムであって、
   前記第１のデータ取得モジュールは複数の取得モジュールのうちの１つであり、
   前記第１の処理モジュールは複数の処理モジュールのうちの１つであり、
   前記第１のユーザインタフェースモジュールは複数のユーザインタフェースモジュールのうちの１つである、医療感知システム。
3. 前記計算システムは、アプリケーションプログラミングインタフェースを前記複数の処理モジュールに露出するように操作可能である処理スタックを含む、請求項２に記載の医療感知システム。
4. 前記処理スタックは、前記複数の処理モジュールまたは前記処理スタックの既存の処理モジュールを変えずに、追加の処理モジュールが前記複数の処理モジュールに追加されてもよいという点で、前記複数の処理モジュールがお互いに独立するように構成される、請求項３に記載の医療感知システム。
5. 前記複数のユーザインタフェースモジュールまたは処理スタックの既存のユーザインタフェースモジュールを変えずに、追加のユーザインタフェースモジュールが前記複数のユーザインタフェースモジュールに追加されてもよいという点で、前記複数のユーザインタフェースモジュールはお互いに独立している、請求項２に記載の医療感知システム。
6. 前記第１の複数のメッセージのそれぞれは、前記第１の患者データの一部と、前記第１の患者データの前記一部に関連する情報とを含有する、請求項１に記載の医療感知システム。
7. 前記情報は前記第１の医療感知手法を識別する情報を含む、請求項６に記載の医療感知システム。
8. 請求項１に記載の医療感知システムであって、前記計算システムはさらに、
   第２の医療感知手法に関連し、前記第２の医療感知手法に関連する第２の患者データを第２の医療感知装置から受信するように操作可能である第２のデータ取得モジュールであって、前記第２の取得モジュールはさらに、前記第２の患者データを含有する第３の複数のメッセージを作成するように操作可能である第２のデータ取得モジュールと、
   前記第２の医療感知手法に関連し、前記第３の複数のメッセージを前記メッセージキューモジュールから取り出し、前記第３の複数のメッセージ内の前記第２の患者データを処理し、前記処理された第２の患者データを含有する第４の複数のメッセージを前記メッセージキューモジュールに送信するように操作可能である第２の処理モジュールと、
   前記第２の医療感知手法に関連し、前記第４の複数のメッセージを前記メッセージキューモジュールから取り出し、前記処理された第２の患者データを第２のグラフィカルユーザインタフェース内で提示するように操作可能である第２のユーザインタフェースモジュールと、
   を含み、
   前記第２の医療感知手法は前記第１の医療感知手法とは異なる、医療感知システム。
9. 前記第１および第２の処理モジュールは、それぞれ前記第１および第２の患者データを同時に処理するように操作可能である、請求項８に記載の医療感知システム。
10. 請求項１に記載の医療感知システムであって、前記第１の患者データを含む第１の複数のメッセージが、パケット化された第１の患者データを含む、該システム。
11. 請求項１に記載の医療感知システムであって、前記第１のデータ取得モジュール、第１の処理モジュール、及び第１のユーザインタフェースモジュールは、アプリケーションプログラミングインタフェースを介して、前記メッセージキューモジュールとそれぞれ通信する、該システム。
12. 請求項１に記載の医療感知システムであって、前記第１の医療感知手法が、以下のうちの１つである、該システム：血管内超音波（ＩＶＵＳ）撮像、血管内光音響（ＩＶＰＡ）撮像、光干渉断層撮影（ＯＣＴ）、フォワードルッキングＩＶＵＳ（ＦＬ−ＩＶＵＳ）、冠血流予備量値（ＦＦＲ）、冠血流予備能（ＣＦＲ）、および血管造影。
13. 請求項６に記載の医療感知システムであって、第１のデータ取得モジュールは、前記第１の患者データの一部に前記情報を関連づけるように操作可能である、該システム。
14. 請求項２に記載の医療感知システムであって、前記計算システムは、ユーザインタフェーススタックを含み、該スタックは、アプリケーションプログラミングインタフェースを前記複数のユーザインタフェースモジュールに露出するように操作可能である、該システム。
15. 請求項１に記載の医療感知システムであって、前記メッセージキューモジュールは、前記第１の医療感知手法に関連する患者データに割り当てられた部分を含む、該システム。
16. 請求項６に記載の医療感知システムであって、前記メッセージキューモジュールは、少なくとも以下のうちの１つに基づいて、前記第１の複数のメッセージを利用可能にするように構成される、該システム：
    先入れ先出し（ＦＩＦＯ）法；及び
    前記第１の患者データの一部に関連する情報に含まれる優先順位の値。
    

Images