(57)【特許請求の範囲】
【請求項１】
マルチモダリティ医療処理システムにおいて実行可能な構成要素間の依存性に基づくスタートアップ方法であって、以下のステップを含む方法：
前記マルチモダリティ医療処理システムのスタートアップ配列の最中に開始すべき複数の実行可能な構成要素についての初期化情報を受け取るステップであって、前記複数の実行可能な構成要素は、実行可能な手法構成要素を含み、該手法構成要素は、医療装置と通信するように構成され、該医療装置は、前記マルチモダリティ医療処理システムに通信可能に接続される、該ステップ；
前記実行可能な手法構成要素についての依存性情報を受け取るステップであって、前記依存性情報は、１以上の前記実行可能な構成要素を特定し、該構成要素に、前記実行可能な手法構成要素が依存する、該ステップ；
前記マルチモダリティ医療処理システムを用いて、前記初期化情報及び前記依存性情報を依存性マップに変換するステップであって、該マップは、前記複数の実行可能な構成要素間での依存性を表す、該ステップ；
前記複数の実行可能な構成要素に関する開始順序を、前記依存性マップに基づいて生成するステップであって、前記実行可能な手法構成要素が依存する前記１以上の実行可能な構成要素が、前記開始順序において、前記実行可能な手法構成要素よりも先行する、該ステップ；及び
前記開始順序に従って、前記マルチモダリティ医療処理システム内の前記複数の実行可能な構成要素を開始させるステップ。
【請求項２】
請求項１に記載の前記依存性に基づくスタートアップ方法であって、前記開始順序を生成するステップが、開始順序情報を、前記依存性マップに基づいて構築することを含み、前記開始順序情報が、前記開始すべき実行可能な構成要素の連続的な順序リストを含む、該方法。
【請求項３】
請求項２に記載の前記依存性に基づくスタートアップ方法であって、前記実行可能な構成要素を開始させるステップが、前記実行可能な構成要素を、前記開始順序情報に従って、連続的に開始させることを含む、該方法。
【請求項４】
請求項１に記載の前記依存性に基づくスタートアップ方法であって、前記変換するステップが、ダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）を構築することを含み、
該グラフは、前記複数の実行可能な構成要素をそれぞれ表す頂点（ノード）と、前記複数の実行可能な構成要素間の依存性を表す頂点（ノード）間のエッジとを有する、該方法。
【請求項５】
請求項４に記載の前記依存性に基づくスタートアップ方法であって、前記開始順序を生成するステップが、深さ優先のソートを、前記ダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）上で行うことを含む、該方法。
【請求項６】
請求項５に記載の前記依存性に基づくスタートアップ方法であって、前記深さ優先のソートを行うことが、前記実行可能な構成要素を、複数のスタートアップレベルのうちの１つにそれぞれ配置することを含む、該方法。
【請求項７】
請求項６に記載の前記依存性に基づくスタートアップ方法であって、前記実行可能な構成要素を開始させるステップが、以下を含む該方法：前記スタートアップレベルのうちの第二のレベル内の前記実行可能な構成要素を開始させる前に、前記スタートアップレベルのうちの第一のレベル内の全ての前記実行可能な構成要素を開始させること。
【請求項８】
請求項７に記載の前記依存性に基づくスタートアップ方法であって、前記実行可能な構成要素を開始させるステップが、前記スタートアップレベルのうちの１つのレベルの中にある前記実行可能な構成要素を、同時に開始させることを含む、該方法。
【請求項９】
請求項１に記載の前記依存性に基づくスタートアップ方法であって、前記依存性マップが循環依存を含むかどうかを判定することを更に含む、該方法。
【請求項１０】
請求項１に記載の前記依存性に基づくスタートアップ方法であって、前記実行可能な手法構成要素が以下のうちの１つに関連する、該方法：血管内超音波検査（ＩＶＵＳ）撮像、
脈管内の光音響の（ＩＶＰＡ）撮像、光干渉断層撮影（ＯＣＴ）、フォワードルッキングＩＶＵＳ（ＦＬ−ＩＶＵＳ）、冠血流予備量比（ＦＦＲ）、冠動脈血流予備能（ＣＦＲ）、血管造影法、ラジオ波アブレーション（ＲＦＡ）、凍結療法、及びアセレクトミ。
【請求項１１】
請求項１に記載の前記依存性に基づくスタートアップ方法であって、更に以下のステップを含む、該方法：
医療データを医療感知装置から受け取るステップ；及び
前記実行可能な手法構成要素を用いて、前記医療データを、臨床医が患者のコンディションを評価することができる画像に変換するステップ。
【請求項１２】
以下を含むマルチモダリティ医療システム：
コンピューティング・システムであって、医療装置に通信可能に接続され、以下を備える該システム：
前記コンピューティング・システムのスタートアップ配列の最中に開始すべき複数の実行可能な構成要素であって、前記複数の実行可能な構成要素は、実行可能な手法構成要素を含み、前記実行可能な手法構成要素は、医療データを前記医療装置から受け取るように構成される、該構成要素；及び
システムコントローラーであって、以下の動作を行うように構成される、該コントローラー：
前記複数の実行可能な構成要素に関する初期化情報及び依存性情報を受け取る動作であって、前記依存性情報は、１以上の前記実行可能な構成要素を特定し、該構成要素に、前記実行可能な手法構成要素が依存する、該受け取る動作；
前記初期化情報及び前記依存性情報に基づいて、依存性マップを構築する動作であって、前記依存性マップは、前記複数の実行可能な構成要素間の依存性を表す、該構築する動作；
前記依存性マップに基づいて、前記複数の実行可能な構成要素に関する開始順序を生成する動作であって、前記実行可能な手法構成要素が依存する前記１以上の実行可能な構成要素が、前記開始順序において、前記実行可能な手法構成要素よりも先行する、該生成する動作；及び
前記コンピューティング・システムの前記複数の実行可能な構成要素を、前記開始順序に従って、開始させる動作。
【請求項１３】
請求項１２に記載の前記マルチモダリティ医療システムであって、
前記コンピューティング・システムに通信可能に接続された表示装置を更に含み；及び
前記システムコントローラーは、以下の動作を行うように構成される、該システム：スタートアップ状態情報を、前記表示装置上に表示し、その間に、前記複数の実行可能な構成要素を開始させる動作。
【請求項１４】
請求項１２に記載の前記マルチモダリティ医療システムであって、前記システムコントローラーは、更に以下の動作を行うように構成される、該システム：開始順序情報を、前記依存性マップに基づいて、構築する動作であって、前記開始順序情報が、前記開始すべき実行可能な構成要素の連続的な順序リストを含む、該動作。
【請求項１５】
請求項１２に記載の前記マルチモダリティ医療システムであって、前記システムコントローラーは、更に以下の動作を行うように構成される：前記初期化情報及び依存性情報に基づいて、ダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）を構築する動作であり、該グラフは、前記複数の実行可能な構成要素をそれぞれ表す頂点（ノード）と、前記複数の実行可能な構成要素間の依存性を表す頂点（ノード）間のエッジとを有する、該動作。
【請求項１６】
請求項１５に記載の前記マルチモダリティ医療システムであって、前記システムコントローラーは、更に以下の動作を行うように構成される、該システム：深さ優先のソートを、前記ダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）上で行うことによって、前記開始順序を生成する動作。
【請求項１７】
請求項１２に記載の前記マルチモダリティ医療システムであって、前記実行可能な手法構成要素が以下のうちの１つに関連する、該システム：血管内超音波検査（ＩＶＵＳ）撮像、脈管内の光音響の（ＩＶＰＡ）撮像、光干渉断層撮影（ＯＣＴ）、フォワードルッキングＩＶＵＳ（ＦＬ−ＩＶＵＳ）、冠血流予備量比（ＦＦＲ）、冠動脈血流予備能（ＣＦＲ）、血管造影法、ラジオ波アブレーション（ＲＦＡ）、凍結療法、及びアセレクトミ。
【請求項１８】
マルチモダリティ医療処理システムを初期化する方法であって、以下を含む方法：
前記マルチモダリティ医療処理システムのスタートアップ配列の最中に開始すべき第一の、第二の、及び第三の実行可能な構成要素に関する初期化情報を受け取るステップであって、ここで、
前記第一の実行可能な構成要素は以下の動作を行うように構成され：前記マルチモダリティ医療処理システムに通信可能に接続された第一の医療装置から、第一の医療手法に関連する医療データを受け取る動作、及び
前記第二の実行可能な構成要素は以下の動作を行うように構成され：前記第一の医療手法とは異なる第二の医療手法に関連する医療データを、第二の医療装置から受け取る動作であって、該医療装置は、前記マルチモダリティ医療処理システムに通信可能に接続される、該動作；
前記第一の、第二の、及び第三の実行可能な構成要素に関する依存性情報を受け取るステップであって、前記依存性情報は、前記第一の及び第二の実行可能な構成要素が前記第三の実行可能な構成要素に依存することを示す、該ステップ；
前記初期化情報及び前記依存性情報を依存性マップに変換するステップであって、該マップは、前記第一の、第二の、及び第三の実行可能な構成要素間での前記依存性を表す、該ステップ；
前記第一の、第二の、及び第三の実行可能な構成要素に関する開始順序を、前記依存性マップに基づいて生成するステップであって、前記開始順序において、前記第三の実行可能な構成要素が前記第一の及び第二の実行可能な構成要素よりも先行する、該ステップ；並びに
前記マルチモダリティ医療処理システムの前記第一の、第二の、及び第三の実行可能な構成要素を、前記開始順序に従って、開始させる、ステップ。
【請求項１９】
請求項１８に記載の方法であって、更に以下のステップを含む、該方法：シャットダウンシグナルを受け取った際に、前記第一の、第二の、及び第三の実行可能な構成要素を、前記開始順序とは逆の順序で停止させるステップ。
【請求項２０】
請求項１８に記載の方法であって、前記第一の実行可能な構成要素が以下のうちの１つに関連する、該方法：血管内超音波検査（ＩＶＵＳ）撮像、脈管内の光音響の（ＩＶＰＡ）撮像、光干渉断層撮影（ＯＣＴ）、フォワードルッキングＩＶＵＳ（ＦＬ−ＩＶＵＳ）、冠血流予備量比（ＦＦＲ）、冠動脈血流予備能（ＣＦＲ）、血管造影法、ラジオ波アブレーション（ＲＦＡ）、凍結療法、及びアセレクトミ。
【請求項２１】
請求項１８に記載の方法であって、前記開始順序を生成するステップが、開始順序情報を、前記依存性マップに基づいて構築することを含み、前記開始順序情報が、前記開始すべき実行可能な構成要素の連続的な順序リストを含む、該方法。
【請求項２２】
請求項１８に記載の方法であって、前記依存性マップを構築するステップが、ダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）を構築することを含み、該グラフは、前記第一の、第二の、及び第三の実行可能な構成要素をそれぞれ表す頂点（ノード）と、及び
前記第一の、第二の、及び第三の実行可能な構成要素間での依存性を表す頂点（ノード）間のエッジとを有する、該方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示の実施形態は、概して医療装置の分野に関する。そして、より具体的には、マルチモダリティ（手法）医療システムにおいての依存性に基づくスタートアップに関する。
【背景技術】
【０００２】
病気の診断及びその治療の成功レベルの検証におけるイノベーションは、外部の撮像プロセスから内部の診断用プロセスへと移行してきた。特に、脈管構造の妨害物及び他の脈管構造の病気を診断するための診断用装置及びプロセスが開発されてきた。これらの手段として、超小型センサが可撓性の細長い部材の遠位端に配置される（例えば、特性分析手順用に使用されるカテーテル、又はガイドワイヤ）。例えば、既知の医療感知技術には以下のものが含まれる：血管造影法、血管内超音波検査（ＩＶＵＳ）、フォワードルッキングＩＶＵＳ（ＦＬ−ＩＶＵＳ）、冠血流予備量比（ＦＦＲ）による決定、冠動脈血流予備能（ＣＦＲ）による決定、光干渉断層撮影（ＯＣＴ）、経食道心エコー、及び画像ガイドによる治療法。これらの各技術は、異なる診断用状況において更に好適となる可能性がある。治療が成功する可能性を高めるため、ヘルスケア施設では、多くの撮像手法、治療手法、診断用手法、及び感知手法を有することができ、これらは、処置中、カテーテル検査室にて、手元で行う。近年設計されてきている処理システムでは、医療データを、複数の異なる撮像ツール、治療ツール、診断用ツール、及び感知ツールから収集し、及びマルチモダリティの医療データを処理する。こうした複数の構成要素のシステムでは、しばしばモジュールを含み、該モジュールは、情報及びシステムサービスに関して、互いに依存する。例えば、２つの異なるモジュールは、共通のエラー・ハンドリング・モジュールに依拠する可能性があり、ログ・ファイル中にエラーのログをとる。しばしば、こうした相互依存の構成要素は、正しく機能するために、特定の順序で開始する必要がある。伝統的には、こうした複数構成要素医療処理システムの設計者は、手動で正しいスタートアップ配列（順序）を生成し、そして、生成した配列を、システムにハード・コーディングしていく。構成要素を追加したり、又は複数構成要素システムから除去したりするたびに、こうした方法を繰り返す必要があるだろう。更にいえば、複数の撮像手法を組み合わせるという、組み込みソフトウェアによる現在の解決策は、アップグレードすることが難しく、また、そうでない場合であっても、問題点がある。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
従って、既存の医療処理装置及び方法は、それらの意図する目的の観点からは、概して十分といえるものであったが、これらは、あらゆる面で完全に満足がいくというわけではなかった。
【課題を解決するための手段】
【０００４】
概要
【０００５】
本開示は、医療処理システムを初期化するための方法及びシステムに関するものであり、該システムは、複数の異なる手法に関連する医療データを取り扱う。医療処理システムの初期化中、異なる医療手法に対応する異なる構成要素は、これら構成要素間の依存性に基づいて特定の順序で開始される。開始順序は依存性マップから生成され、該マップは、構成要素に関連する依存性情報から生成される。
【０００６】
例示的な一態様において、本開示は、マルチモダリティ医療処理システムにおいて依存性に基づくスタートアップ方法に関する。前記方法は、マルチモダリティ医療処理システムのスタートアップ配列の最中に開始すべき複数の実行可能な構成要素についての初期化情報を、受け取ることを含み、複数の実行可能な構成要素は、実行可能な手法構成要素を含み、該手法構成要素は、医療装置と通信するように構成され、該装置は、マルチモダリティ医療処理システムに通信可能に接続される。また、前記方法は、実行可能な手法構成要素に関する依存性情報を受け取ることを含み、依存性情報は、実行可能な手法構成要素が依存する１以上の実行可能な構成要素を特定し、並びに、前記方法は、初期化情報及び依存性情報を依存性マップに変換することを含み、該マップは、複数の実行可能な構成要素間の依存性を表す。更に、前記方法は、依存性マップに基づいて、複数の実行可能な構成要素に関する開始順序を生成することを含み（ここで、実行可能な手法構成要素が依存する１以上の実行可能な構成要素は、開始順序内の実行可能な手法構成要素よりも、先行する）、また、前記方法は、マルチモダリティ医療処理システム内の複数の実行可能な構成要素を、開始順序に従って、開始させることを含む。
【０００７】
別の例示的な態様において、本開示は、マルチモダリティ医療システムに関するものであり、医療装置に通信可能に接続されたコンピューティング・システムを含む。コンピューティング・システムは、コンピューティング・システムのスタートアップ配列中に開始すべき、複数の実行可能な構成要素を含み、複数の実行可能な構成要素は、実行可能な手法構成要素を含み、該構成要素は、医療データを医療装置から受け取るように構成される。また、コンピューティング・システムは、システムコントローラーを含み、該コントローラーは以下の動作を行うように構成される：複数の実行可能な構成要素に関する初期化情報及び依存性情報を受け取ること（ここで、依存性情報は、実行可能な手法構成要素が依存する１以上の実行可能な構成要素を特定する）；並びに、依存性マップを、初期化情報及び依存性情報に基づいて構築すること（ここで、依存性マップは、複数の実行可能な構成要素間の依存性を表す）。また、システムコントローラーは以下の動作を行うように構成される：依存性マップに基づいて、複数の実行可能な構成要素に関する開始順序を生成すること（ここで、実行可能な手法構成要素が依存する１以上の実行可能な構成要素は、開始順序内の実行可能な手法構成要素よりも先行する）；及び、コンピューティング・システムの複数の実行可能な構成要素を、開始順序に従って、開始させること。
【０００８】
更に別の例示的な態様において、本開示は、マルチモダリティ医療処理システムを初期化する方法に関する。前記方法は、マルチモダリティ医療処理システムのスタートアップ配列の最中に開始すべき、第一の、第二の、及び第三の実行可能な構成要素に関する初期化情報を受け取ることを含み、第一の実行可能な構成要素は、第一の医療手法に関連する医療データを第一の医療装置から受け取るように構成され、該装置はマルチモダリティ処理システムに通信可能に接続され、及び第二の実行可能な構成要素は、第二の医療手法に関連する医療データを第二の医療装置から受け取るように構成され、該第二の医療手法は、第一の医療手法と異なり、第二の医療装置は、マルチモダリティ医療処理システムに通信可能に接続される。また、前記方法は、第一の、第二の、及び第三の実行可能な構成要素に関する依存性情報を受け取ることを含み、依存性情報は、第一の及び第二の実行可能な構成要素が第三の実行可能な構成要素に依存することを示し、並びに、前記方法は、初期化情報及び依存性情報を依存性マップに変換することを含み、該マップは、第一の、第二の、及び第三の実行可能な構成要素間での依存性を表す。更に、前記方法は、第一の、第二の、及び第三の実行可能な構成要素に関する開始順序を、依存性マップに基づいて生成することを含み、ここで、第三の実行可能な構成要素は、開始順序において、第一の及び第二の実行可能な構成要素よりも先行し、また、前記方法は、マルチモダリティ医療処理システムの第一の、第二の、及び第三の実行可能な構成要素を、開始順序に従って開始させることを含む。
【図面の簡単な説明】
【０００９】
【図１】概略図であり、本開示の一実施形態に従った医療システムを描写し、該システムは、マルチモダリティ処理システムを含む。
【図２】医療システムの一部の機能ブロック図であり、処理フレームワークを含み、マルチモダリティ処理システムの実施形態を実行する。
【図３】高度なフローチャートであり、本開示の態様に従った、マルチモダリティ処理システムの依存性に基づくスタートアップ配列のための方法を例示する。
【図４】図３の方法の最中に構築された例示的なダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）を例示する。
【図５】図４の例示的なダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）に基づいた例示的な開始順序ベクトルを例示する。
【発明を実施するための形態】
【００１０】
本開示の原理の理解を促す目的で、図面中に例示された実施形態について以下参照し、同一の物について説明するために特定の用語を用いることとする。しかし、本開示の範囲を限定することを意図していない点を理解されたい。装置、システム及び方法に対して、本開示の原理の任意の置き換え、及び更なる変更、並びに任意の更なる応用も意図しており、こうしたものも、当分野に関連する当業者にとって通常生じるものとして、本開示の範囲内に含まれる。特に、１つの実施形態について記載された特徴、構成要素、及び／又はステップは、他の本開示の実施形態について記載された特徴、構成要素、及び／又はステップと組み合わせてもよい点については、完全に企図している。しかし、簡潔にする目的から、こうした組合せについて別途数多く繰り返して説明することはしない。
【００１１】
図１は、概略図であり、本開示の一実施形態に従った医療システム（１００）を描写しており、該システムはマルチモダリティ処理システム（１０１）を含む。一般的に、医療システム（１００）は、以下を提供する：複数の形態で得られたものをコヒーレントな形で統合（ｉｎｔｅｇｒａｔｉｏｎ及びｃｏｎｓｏｌｉｄａｔｉｏｎ）したもの；並びに、処理エレメント、ここで、該エレメントは、種々の方法の影響を受けるように設計されており、該方法は、以下の目的で用いられる：ヒトの生物学的な情報、生理学的な情報、及び形態学的な情報を獲得及び解釈すること；並びに、様々なコンディションの治療を調整すること。より具体的には、システム（１００）において、マルチモダリティ処理システム（１０１）は、以下の目的のために統合化された装置である：マルチモダリティの医療感知データの獲得、コントロール、解釈、及び表示。一実施形態において、処理システム（１０１）は、コンピュータ・システムであり、ハードウェア及びソフトウェアを有し、マルチモダリティの医療データの獲得、処理、及び表示を行う。しかし、他の実施形態では、処理システム（１０１）は、医療データを処理するために動作可能な任意の他の種類のコンピューティング・システムであってもよい。ある実施形態において、処理システム（１０１）はコンピュータ・ワークステーションであるが、該形態では、システムは少なくとも以下を含む：プロセッサ（例えばマイクロコントローラ又は専用の中央演算処理装置（ＣＰＵ））、非一時的コンピュータ可読記憶媒体（例えばハード・ドライブ、ランダム・アクセス・メモリ（ＲＡＭ）、及び／又はコンパクト・ディスクリード・オンリ・メモリ（ＣＤ−ＲＯＭ））、ビデオコントローラー（例えばグラフィックス処理ユニット（ＧＰＵ））、及びネットワーク通信装置（例えばイーサネット（登録商標）コントローラー又は無線通信コントローラー）。こうした点に関して、幾つかの特定の例では、処理システム（１０１）は、プログラム制御され、本明細書に記載のデータ獲得及び分析に関連するステップを実行する。従って、以下の点を理解されたい：即ち、本開示のデータ獲得、データ処理、機器コントロール、及び／又は他の処理若しくはコントロール態様に関連する任意のステップは、この処理システムによって実行することができ、該処理システムは対応指示を用いることができ、該指示は非一時的なコンピュータ読取可能媒体上又はその中に記憶され、該媒体は前記処理システムがアクセス可能である。幾つかの例において、処理システム（１０１）は携帯型である（例えば、手持ち型の物、ローリング・カート上に置かれた物等）。更に、以下の点を理解されたい：即ち、幾つかの例において、処理システム（１０１）は、複数のコンピューティング・デバイスを含む。こうした点に関して、以下の点を特に理解されたい：即ち、本開示の異なる処理及び／又はコントロール態様は、別々に実行されてもよく、又は複数のコンピューティング・デバイスを用いた規定のグルーピング内で実行されてもよい。後述する処理及び／又はコントロール態様を、複数のコンピューティング・デバイスにまたがって、任意で分割すること及び／又は組合せることは、本開示の範囲内である。
【００１２】
例示した実施形態において、医療システム（１００）はカテーテル検査室（１０２）内に配置され、該検査室はコントロール・ルーム（１０４）を有しており、処理システム（１０１）は前記コントロール・ルーム内に位置している。他の実施形態では、処理システム（１０１）は他の場所に位置してもよい（例えば、カテーテル検査室（１０２）内、医療施設内の集中エリア内、又は現場から離れた場所（即ち、クラウド内））。カテーテル検査室（１０２）は滅菌野を含み、滅菌野は、概して処置エリアを含む。しかし、該検査室に関連するコントロール・ルーム（１０４）は、滅菌状態であってもよいし、滅菌状態でなくてもよいし、これは、処置の要求内容及び／又はヘルスケア施設に依存する。カテーテル検査室及びコントロール・ルームは、患者に対して任意の数の医療感知手順を実行するために使用することができる（例えば血管造影法、血管内超音波検査（ＩＶＵＳ）、バーチャルヒストロジー（ＶＨ）、フォワードルッキングＩＶＵＳ（ＦＬ−ＩＶＵＳ）、脈管内の光音響の（ＩＶＰＡ）撮像、冠血流予備量比（ＦＦＲ）による決定、冠動脈血流予備能（ＣＦＲ）による決定、光干渉断層撮影（ＯＣＴ）、コンピュータ断層、心腔内心エコー法（ＩＣＥ）、フォアワード・ルッキングＩＣＥ（ＦＬＩＣＥ）、脈管内のパルポグラフィ（ｐａｌｐｏｇｒａｐｈｙ）、経食道超音波、又は公知且つ任意の他の医療感知手法。更に、カテーテル検査室及びコントロール・ルームは、１以上の治療又は治療法手順を患者に対して実行するために使用することができる（例えばラジオ波アブレーション（ＲＦＡ）、凍結療法、アセレクトミ又は公知且つ任意の他の医療治療手順）。例えば、カテーテル検査室（１０２）において、患者（１０６）は、マルチモダリティ処置を受けることができ、単独の処置又は１以上の感知手順の組合せのいずれかであって良い。いずれの場合にも、カテーテル検査室（１０２）は複数の医療機器を含み、該機器は医療感知装置を含み、該装置は、様々な異なる医療感知手法で患者（１０６）から医療感知データを収集することができる。
【００１３】
図１の例示した実施形態において、機器（１０８）及び（１１０）は、医療感知装置であり、該装置を臨床医が用いて、患者（１０６）に関する医療感知データを得ることができる。特定の例において、装置（１０８）はある手法での医療感知データを収集し、そして、装置（１１０）は別の手法での医療感知データを収集する。例えば、機器はそれぞれ以下のうちの１つを収集することができる：圧力、フロー（速度）、画像（以下を用いて得られた画像を含む：超音波（例えば、ＩＶＵＳ）、ＯＣＴ、熱、及び／又は他の撮像技術）、温度、及び／又はこれらの組み合わせ。装置（１０８）及び（１１０）は、任意の形態の装置、機器、又はプローブであってもよく、脈管内に配置するためのサイズ及び形状を有してもよく、患者の外部に取り付けることができ、又は患者に対してある距離でスキャンを行うことができる。
【００１４】
図１の例示した実施形態において、機器（１０８）はＩＶＵＳカテーテル（１０８）であり、該カテーテルは１以上のセンサ（例えばフェーズド・アレイ・トランスデューサ）を含むことができ、ＩＶＵＳ感知データを収集することができる。幾つかの実施形態において、ＩＶＵＳカテーテル（１０８）は、マルチモダリティ感知（例えばＩＶＵＳ及びＩＶＰＡ感知）が可能であってもよい。更に、例示した実施形態において、機器（１１０）はＯＣＴカテーテル（１１０）であり、該カテーテルは１以上の光学的センサを含むことができ、ＯＣＴ感知データを収集するように構成されてもよい。幾つかの例において、ＩＶＵＳ患者インターフェース・モジュール（ＰＩＭ）（１１２）及びＯＣＴ−ＰＩＭ（１１４）は、それぞれ、ＩＶＵＳカテーテル（１０８）及びＯＣＴカテーテル（１１０）を医療システム（１００）に結合させる。特に、ＩＶＵＳ−ＰＩＭ（１１２）及びＯＣＴ−ＰＩＭ（１１４）は以下の動作が可能である：ＩＶＵＳカテーテル（１０８）及びＯＣＴカテーテル（１１０）が患者（１０６）から収集した医療感知データそれぞれを受け取ること；並びに、前記受け取ったデータをコントロール・ルーム（１０４）内の処理システム（１０１）に伝送すること。一実施形態において、ＰＩＭ（１１２）及び（１１４）はアナログ・デジタル（Ａ／Ｄ）変換器を含む。そして、デジタル・データを処理システム（１０１）に伝送する。しかし、他の実施形態では、ＰＩＭはアナログ・データを処理システムに伝送する。一実施形態において、ＩＶＵＳ−ＰＩＭ（１１２）及びＯＣＴ−ＰＩＭ（１１４）は、医療感知データを、ペリフェラル・コンポーネント・インターコネクト・エクスプレス（ＰＣＩｅ）データバス接続を介して伝送する。しかし、他の実施形態では、これらのＰＩＭは、データを、ＵＳＢ接続、Ｔｈｕｎｄｅｒｂｏｌｔ接続、ＦｉｒｅＷｉｒｅ（登録商標）接続、又は幾つかの他の高速データバス接続を介して伝送することができる。他の例において、ＰＩＭは、処理システム（１０１）に以下を用いた無線接続を介して接続されてもよい：ＩＥＥＥ８０２．１１Ｗｉ−Ｆｉ（登録商標）規格、超広帯域無線（ＵＷＢ）規格、ワイヤレスＦｉｒｅＷｉｒｅ（登録商標）、ワイヤレスＵＳＢ、又は別の高速ワイヤレス・ネットワーク規格。
【００１５】
更に言えば、医療システム（１００）において、心電図（ＥＣＧ）装置（１１６）は、心電図シグナル又は他の血流力学データを、患者（１０６）から処理システム（１０１）に伝送するように操作可能である。幾つかの実施形態において、処理システム（１０１）は、ＥＣＧ（１１６）からのＥＣＧシグナルを用いて、カテーテル（１０８）及び（１１０）により収集されたデータを同期させるために動作可能であって良い。更に、血管撮影図システム（１１７）は以下の点で操作可能である：患者（１０６）のＸ線、コンピュータ断層撮影（ＣＴ）、又は磁気共鳴画像（ＭＲＩ）を収集すること；及びこれらを処理システム（１０１）に伝送すること。一実施形態において、血管撮影図システム（１１７）は、処理システム（１０１）に、アダプタ装置を介して、通信可能に接続されてもよい。こうしたアダプタ装置は、データを、サードパーティの専有形式から、処理システム（１０１）が使用可能な形式へと変換することができる。幾つかの実施形態において、処理システム（１０１）は、以下の動作を行うことができる：血管撮影図システム（１１７）（例えば、Ｘ線データ、ＭＲＩデータ、ＣＴデータ、等）からの画像データを、ＩＶＵＳ並びにＯＣＴカテーテル（１０８）及び（１１０）からの感知データとともに共記録すること。この一態様として、共記録を行い、感知データを用いて３次元画像を生成することができる。
【００１６】
ベッドサイド・コントローラー（１１８）も処理システム（１０１）に通信可能に接続され、そして、特定の医療手法（又は複数の手法）に関するユーザー・コントロールを提供し、これらは、患者（１０６）を診断するために用いられる。当該実施形態において、ベッドサイドコントローラー（１１８）はタッチスクリーン・コントローラーであり、該コントローラーはユーザー・コントロール及び診断用画像を単一表面上に提供する。しかし、別の実施形態では、ベッドサイドコントローラー（１１８）は、相互作用しない表示装置、及び別のコントロール（例えば物理的なボタン及び／又はジョイスティック）の両方を含むことができる。統合された医療システム（１００）において、ベッドサイドコントローラー（１１８）は以下の動作が可能である：ワークフロー・コントロールのオプション及び患者画像データをグラフィカル・ユーザー・インターフェース（ＧＵＩ）内に提示すること。図２に関連して詳述するが、ベッドサイドコントローラー（１１８）はユーザー・インターフェース（ＵＩ）フレームワーク・サービスを含み、複数の手法に関連するワークフローは、該サービスを通じて、実行することができる。従って、ベッドサイドコントローラー（１１８）は、複数の手法に関するワークフロー及び診断用画像を、表示することができる。そして、マルチモダリティ医療感知データの獲得を単一のインターフェース装置を用いて臨床医がコントロールすることを可能にする。
【００１７】
コントロール・ルーム（１０４）内のメイン・コントローラー（１２０）も処理システム（１０１）に通信可能に接続され、そして、図１に示すように、カテーテル検査室（１０２）の隣に位置する。当該実施形態において、メイン・コントローラー（１２０）は、以下の点でベッドサイドコントローラー（１１８）に類似する：即ち、前記コントローラーはタッチスクリーンを含み、そして、多数のＧＵＩベースのワークフローを、該コントローラ上で実行されるＵＩフレームワーク・サービスを介して表示するように動作可能であり、該ワークフローは、異なった医療感知手法に対応する。幾つかの実施形態において、メイン・コントローラー（１２０）を使用して、ベッドサイドコントローラー（１１８）とは異なる処置のワークフローの態様を同時に実行することができる。別の実施形態では、メイン・コントローラー（１２０）は、相互作用しない表示装置及びスタンドアロンコントロール（例えばマウス及びキーボード）を含むことができる。
【００１８】
医療システム（１００）は、更にブーム・ディスプレイ（１２２）を含み、該ディスプレイは処理システム（１０１）に通信可能に接続される。ブーム・ディスプレイ（１２２）は、モニターのアレイを含むことができ、各々は、医療感知手順に関する異なる情報を表示することができる。例えば、ＩＶＵＳ処置の間、ブーム・ディスプレイ（１２２）中の１つのモニターは、断層撮影図を表示することができ、そして、１つのモニターは、サジタル・ビュー（矢状面）を表示することができる。
【００１９】
更に、マルチモダリティ処理システム（１０１）は、データネットワーク（１２５）に通信可能に接続される。例示した実施形態において、データネットワーク（１２５）は、ＴＣＰ／ＩＰベースのローカル・エリア・ネットワーク（ＬＡＮ）であるが、しかし、他の実施形態では、異なるプロトコルを用いてもよく（例えば同期型光ネットワーク（ＳＯＮＥＴ））、又はワイド・エリア・ネットワーク（ＷＡＮ）であってもよい。処理システム（１０１）は、様々なリソースを、ネットワーク（１２５）を介して接続することができる。例えば、処理システム（１０１）は、以下と通信することができる：医療におけるデジタル画像と通信（ＤＩＣＯＭ）システム（１２６）、画像保存通信システム（ＰＡＣＳ）（１２７）、及び病院情報システム（ＨＩＳ）（１２８）（これらはネットワーク（１２５）を介して通信）。更に言えば、幾つかの実施形態において、ネットワークコンソール（１３０）は、ネットワーク（１２５）を介してマルチモダリティ処理システム（１０１）と通信することができ、ドクター又は他の医療専門家が医療システム（１００）の態様に遠隔アクセスすることを可能にする。例えば、ネットワークコンソール（１３０）のユーザーは、患者医療データ（例えば、マルチモダリティ処理システム（１０１）によって収集された診断用画像）にアクセスすることができ、又は、幾つかの実施形態において、カテーテル検査室（１０２）内での１以上の継続中の処置を、リアルタイムでモニター又はコントロールすることができる。ネットワークコンソール（１３０）は、ネットワーク接続された任意の種類のコンピューティング・デバイスであってもよい（例えばＰＣ、ラップトップ、スマートフォン、タブレットコンピュータ、又はヘルスケア施設内外に位置する他のこうした装置）。
【００２０】
更に言えば、例示した実施形態において、上述したシステム（１００）内の医療感知ツールは、有線接続を介して処理システム（１０１）に通信可能に接続されたものとして表示されている（例えば標準銅リンク又は光ファイバリンク）、しかし、別の実施形態では、ツールは、処理システム（１０１）に、以下を使用した無線接続を介して、接続されてもよい：ＩＥＥＥ８０２．１１Ｗｉ−Ｆｉ（登録商標）規格、超広帯域無線（ＵＷＢ）規格、ワイヤレスＦｉｒｅＷｉｒｅ（登録商標）、ワイヤレスＵＳＢ、又は別の高速ワイヤレス・ネットワーク規格。
【００２１】
当業者であれば以下の点を認識するであろう：即ち、上述した医療システム（１００）は単にシステムの例示的な実施形態にすぎず、該システムは、複数の医療手法に関連する診断用データを収集するために動作可能である。別の実施形態では、異なる及び／又は追加のツールは、処理システム（１０１）に通信可能に接続されてもよく、その目的として、追加の及び／又は異なる機能について、医療システム（１００）に対して寄与する。
【００２２】
ここで、図２を参照されたい。該図では、医療システム（１００）の一部の機能ブロック図を表す。そして、マルチモダリティ処理システム（１０１）の実施形態上で実行するための処理フレームワーク（２００）を含む。処理フレームワーク（２００）は、様々な独立した及び依存性の実行可能な構成要素を含み、これらの構成要素は、処理システム（１０１）の動作をコントロールし、該動作として、マルチモダリティ医療感知データを獲得すること、処理すること、及び表示することを含む。一般的に、処理システム（１０１）の処理フレームワーク（２００）は、モジュール化されており、拡張可能である。即ち、フレームワーク（２００）は、独立したソフトウェア及び／又はハードウェア構成要素（又は拡張要素）から構成され、それぞれ異なる機能及び医療感知手法に関連する。こうしたモジュールの設計により、フレームワークを拡張して追加の医療感知手法及び機能を受容することが可能となり、その際に、既存の機能に影響を与えせず、又は内在するアーキテクチャに対する変更を必要としない。更に、内部のメッセージングシステムは、フレームワーク内のモジュール間での独立したデータ通信を促進する。一例において、処理フレームワーク（２００）は、コンピュータ実行可能指示として実装されてもよく、該指示は処理システム（１０１）内の非一時的コンピュータ可読記憶媒体上に保存されてもよい。他の例において、処理フレームワーク（２００）は、ハードウェア及びソフトウェアモジュールの組合せであってもよく、これらは、処理システム（１０１）内で実行される。
【００２３】
概して、図２に示す実施形態において、処理フレームワーク（２００）は、複数の構成要素を含み、これらの要素は以下の動作を行うように構成される：医療感知データを複数の医療感知装置から受け取ること；データを処理すること；及び、データを、診断用画像として、メイン・コントローラー（１２０）、ベッドサイドコントローラー（１１８）、又は他のグラフィカルな表示装置を介して出力すること。フレームワーク（２００）は、複数のシステムレベルの構成要素を含み、これらは、処理システム（１０１）のコアとなるシステムの機能を管理し、また、手法に特化した複数の構成要素の調整を行う。例えば、フレームワーク（２００）は、システムコントローラー（２０２）を含み、該コントローラは、処理フレームワーク（２００）の複数の実行可能な構成要素のスタートアップ及びシャットダウンを調整し、該構成要素は、患者診断用データの獲得及び処理に関連するハードウェア及びソフトウェアモジュールを含む。システムコントローラー（２０２）は、フレームワーク（２００）内で実行する構成要素の状態を監視するように構成され、例えば、任意の構成要素の実行が予期せず停止したかどうかを決定する。更には、システムコントローラー（２０２）は、インターフェースを提供し、該インターフェースを通して、他のフレームワーク構成要素がシステムの構成や状態に関する情報を手に入れることができる。ソフトウェアフレームワーク（２００）はモジュール化されているため、システムコントローラー（２０２）は、該コントローラが管理するフレームワーク内の構成要素から独立しており、従って、構成要素に対して生じたエラー及び変更は、システムコントローラーの実行又は構造に影響しない。システムコントローラー（２０２）がフレームワーク（２００）の実行可能な構成要素を開始及び停止させる態様については、図３〜５で更に詳しく説明する。
【００２４】
上述したように、システムアーキテクチャを変更することなく様々な拡張要素を追加及び削除できるように、フレームワーク（２００）は構成される。ある実施形態において、フレームワーク（２００）内で実行される拡張要素は、複数の実行可能な構成要素を含み、これらは、拡張要素の完全な機能を共に実装する。こうした実施形態において、拡張要素は、システムコントローラー（２０２）と同様の拡張コントローラーを含むことでき、該拡張コントローラーは、拡張要素に関連する様々な実行可能な構成要素をスタートアップ、シャットダウン、及び監視するように動作可能である。例えば、システムのスタートアップ時に、システムコントローラー（２０２）は、医療手法に対応する拡張コントローラーを開始することができ、その後、拡張コントローラーは、順番に、前記手法に関連する実行可能な構成要素を開始することができる。一実施形態において、構成機構（例えば構成ファイル）から取得したパラメーターを介してシステムコントローラー（２０２）が拡張コントローラーを特定の手法又は他のシステムタスクに関連付けるまで、該拡張コントローラーを配置しなくてもよい。
【００２５】
処理フレームワーク（２００）は、更にワークフローコントローラー構成要素（２０４）を含むことができ、該構成要素は概して以下の動作をするように構成される：マルチモダリティ医療感知ワークフローの最中、フレームワーク（２００）の実行可能な構成要素の実行を支配すること。ワークフローコントローラー構成要素（２０４）は、様々な異なる態様で、処理フレームワーク（２００）が実行するワークフローを支配することができる。
【００２６】
処理フレームワーク（２００）は、更にイベントログ構成要素（２０６）を含み、該構成要素は、処理フレームワークの様々な構成要素から受け取ったメッセージのログをとるように構成される。例えば、システムスタートアップの最中、システムコントローラー（２０２）は、開始中の構成要素の状態に関するメッセージを、イベントログ構成要素（２０６）に送ることができ、イベントログ構成要素は、順番にメッセージをログ・ファイルに標準化されたフォーマットで書き込む。更に言えば、処理フレームワーク（２００）は、リソースアーバイター（ａｒｂｉｔｅｒ）構成要素（２０８）を含み、該構成要素は以下の動作を行うように構成される：マルチモダリティ医療感知及び／又は治療ワークフローの最中に、フレームワーク（２００）の様々な実行可能な構成要素の間で、限られたシステムリソースを共有するのを管理すること。例えば、マルチモダリティワークフローの最中、処理フレームワーク（２００）内での異なる手法に関連する２以上の構成要素は、メイン・コントローラー（１２０）上で、同一のシステムリソース（例えば、グラフィカルな表示装置）に関して競合する可能性がある。リソースアーバイター（ａｒｂｉｔｅｒ）構成要素（２０８）は、限られたシステムリソースの共有を様々な方法で調整することができる（例えば、以下を通して：ロックシステム、キューシステム、又は階層衝突管理（ｈｉｅｒａｒｃｈｉｃａｌ  ｃｏｌｌｉｓｉｏｎ  ｍａｎａｇｅｍｅｎｔ）システム）。
【００２７】
一実施形態において、システムコントローラー（２０２）、ワークフローコントローラー構成要素（２０４）、イベントログ構成要素（２０６）、及びリソースアーバイター（ａｒｂｉｔｅｒ）構成要素（２０８）は、非一時的な、コンピュータ可読記憶媒体上に保存されたプロセッサ−実行可能なソフトウェアとして実装されてもよいが、しかし別の実施形態では、これらの構成要素はハードウェア構成要素として実装されてもよい（例えば特定目的マイクロプロセッサ、現場でプログラム可能なゲートアレイ（ＦＰＧＡ）、マイクロコントローラ、グラフィックス処理ユニット（ＧＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）。或いは処理フレームワークの構成要素は、ハードウェア及びソフトウェアの組合せとして実装されてもよい。実行可能な構成要素がＦＰＧＡ内で実装される、ある実施形態において、システムコントローラー（２０２）は、以下の動作を行うように構成されてもよい：ＦＰＧＡ内のプログラム制御可能なロジックを動的に変更して、その時に必要な様々な機能を実装すること。この態様として、処理システム（１０１）は、１以上の割り当てていないＦＰＧＡを含むことができ、該ＦＰＧＡはシステムコントローラーによりシステムスタートアップの最中に割り当てることができる。例えば、もしも、処理システム（１０１）のスタートアップ時に、システムコントローラーが、該システムに接続されたＯＣＴ−ＰＩＭ及びカテーテルを検出した場合、システムコントローラー又はＯＣＴ機能に関連する拡張コントローラーは、１つの割り当てていないＦＰＧＡ内のプログラム制御可能なロジックを動的に変換することができ、その結果ＦＰＧＡはＯＣＴ医療データを受け取る及び／又は処理する機能を含むようになる。
【００２８】
マルチモダリティ処理システム（１０１）において、異なるハードウェア及びソフトウェア構成要素間でのシステム間の通信を促進するため、処理フレームワーク（２００）は、更にメッセージデリバリ構成要素（２１０）を含む。一実施形態において、メッセージデリバリ構成要素（２１０）は以下の動作を行うように構成される：フレームワーク（２００）内の構成要素からメッセージを受け取ること；メッセージの意図するターゲットを決定すること；及び、タイムリーな方法でメッセージをデリバリすること（即ち、メッセージデリバリ構成要素は、メッセージのデリバリという点で、アクティブな関与要素である）。こうした実施形態において、メッセージメタデータを送信構成要素が生成することができ、該データは以下を含む：目的地情報、搭載データ（例えば、手法のタイプ、患者データ等）、優先順位の情報、タイミング情報、又は他のこうした情報。別の実施形態では、メッセージデリバリ構成要素（２１０）は、以下の動作を行うように構成されてもよい：フレームワーク（２００）内の構成要素からメッセージを受け取ること；一時的にメッセージを保存すること、；及び、フレームワーク内の他の構成要素が取得利用可能なメッセージを生成すること（即ち、メッセージデリバリ構成要素はパッシブキューである）。いずれの場合においても、メッセージデリバリ構成要素（２１０）は、フレームワーク（２００）内の実行可能な構成要素の間での通信を促進する。例えば、システムコントローラー（２０２）は、メッセージデリバリ構成要素（２１０）を用いて以下のことを行うことができる：システムスタートアップ配列の最中にスタートアップしている構成要素の状態を調べること；及びその後、状態情報を受け取ったときに、メッセージデリバリ構成要素を用いて、状態情報をイベントログ構成要素（２０６）に送信し、その結果、該情報がログ・ファイルに書き込まれること。同様に、リソースアーバイター（ａｒｂｉｔｅｒ）構成要素（２０８）は、メッセージデリバリ構成要素（２１０）を用いて以下のことを行うことができる：限られたリソースへのアクセスを要求する構成要素間でリソーストークンを渡すこと。
【００２９】
メッセージデリバリ構成要素（２１０）はパッシブキューである実施形態の一例において、フレームワーク（２００）内の構成要素は、受け取った医療感知データをメッセージへとパケット化することができ、そして、その後、メッセージをメッセージデリバリ構成要素上のキューに送ることができ、ここで、これらのメッセージは他の構成要素（例えば画像データ処理構成要素）が取得可能である。更に、幾つかの実施形態において、メッセージデリバリ構成要素（２１０）は、受け取ったメッセージを先入先出（ＦＩＦＯ）の方式で利用可能にするように動作する（該方式では、最初にキューに到着したメッセージが最初にキューから除去される）。別の実施形態では、メッセージデリバリ構成要素（２１０）は、メッセージを異なる方式で利用可能にすることができる（例えば、メッセージヘッダ中に記録された優先順位の値によって）。一実施形態において、メッセージデリバリ構成要素（２１０）は、処理システム（１０１）内のランダム・アクセス・メモリ（ＲＡＭ）内で実装されてもよく、しかし、他の実施形態では、前記構成要素は以下の内部で実装されてもよい：不揮発性のＲＡＭ（ＮＶＲＡＭ）、二次記憶装置（例えば、磁気のハード・ドライブ、フラッシュ・メモリ等）、又はネットワークベースの記憶装置。更に、一実施形態において、メッセージデリバリ構成要素（２１０）上に記憶されたメッセージは、ダイレクトメモリアクセス（ＤＭＡ）を用いて、処理システム（１０１）内のソフトウェア及びハードウェアモジュールがアクセスすることができる。
【００３０】
処理フレームワーク（２０２）は、更に複数の追加システム構成要素を含み、該構成要素は、コアとなるシステム機能を提供し、以下の物が含まれる：セキュリティ構成要素（２１２）、マルチモダリティ・ケース・マネージメント（ＭＭＣＭ）構成要素（２１４）、及びデータベースマネージメント構成要素（２１６）。ある実施形態において、セキュリティ構成要素（２１２）は、様々なセキュリティサービスを、全体の処理フレームワーク及び個々の構成要素に、提供するように構成される。例えば、ＩＶＵＳデータ獲得ワークフローを実施する構成要素は、暗号化アプリケーション・プログラミング・インターフェース（ＡＰＩ）を用いることができ、該ＡＰＩはセキュリティ構成要素（２１２）によって曝され、ネットワーク接続を介してＩＶＵＳデータを送信する前に該データを暗号化することができる。更に、セキュリティ構成要素（２１２）は、他のセキュリティサービス（例えばシステムレベルの認証及び許可サービス）を提供することができ、処理フレームワークへのアクセスを、信任されたユーザーに制限したり、及び拡張可能なフレームワーク内の信頼できない構成要素の実行を防止したりすることもできる。マルチモダリティ・ケース・マネージメント（ＭＭＣＭ）構成要素（２１４）は、以下の動作を行うように構成される：複数の医療手法に関連する診断用データを、更に容易に管理可能な統一された患者記録へと、調整及び統合する。こうした統一された患者記録は、より効率的にデータベースに記録できる可能性があり、そして、データのアーカイブ化及び検索に、より適う可能性がある。こうした点に関して、データベースマネージメント構成要素（２１６）は、以下の動作を行うように構成される：透過性のあるデータベースサービスをフレームワーク（２００）内の他の構成要素に提示し、その結果データベース接続及びマネージメントの詳細を他の構成要素から隠蔽する。例えば、ある実施形態において、データベースマネージメント構成要素（２１６）は、データベース記憶及び検索機能を含むＡＰＩを、フレームワーク（２００）の構成要素に曝すことができる。換言すれば、医療感知ワークフロー構成要素は、診断用データを、ローカルの及び／又はリモートのデータベース（例えばＤＩＣＯＭ又はＰＡＣＳサーバー）に、データベース構成要素経由で伝送することができ、その際にデータベース接続の詳細について知られることがない。他の実施形態では、データベースマネージメント構成要素（２１６）は、追加の及び／又は異なるデータベースサービスを実行するように動作可能であってもよい（例えば、データベースアーカイブ化のための診断用データを準備する、データ・フォーマッティング・サービス）。
【００３１】
上述したように、マルチモダリティ処理システム（１０１）の処理フレームワーク（２００）は、複数の手法に関連する医療データを受け取り及び処理するように動作可能である。こうした点に関して、処理フレームワーク（２００）は、複数のモジュール獲得構成要素及びワークフロー構成要素を含み、これらはそれぞれ異なる医療感知手法及び診断用手法に関連する。例えば、図２の例示した実施形態に示すように、処理フレームワーク（２００）は、ＩＶＵＳ獲得構成要素（２２０）及びＩＶＵＳワークフロー構成要素（２２２）を含み、これらは、それぞれ、ＩＶＵＳ−ＰＩＭ（１１２）からのＩＶＵＳ医療感知データを受け取り及び処理するように構成される。処理フレームワーク（２００）のモジュール特性及び拡張可能な特性に従い、任意の数の追加の獲得構成要素及びワークフロー構成要素を、独立してフレームワークに追加してもよく、これについては、手法「Ｎ」の獲得構成要素（２２４）及び手法「Ｎ」のワークフロー構成要素（２２６）として記され、これらは、手法「Ｎ」のＰＩＭ（２２８）からのデータを獲得及び処理する。例えば、ある実施形態において、処理システム（１０１）は以下の物に通信可能に接続されてもよい：ＯＣＴ−ＰＩＭ（１１４）、ＥＣＧシステム（１１６）、冠血流予備量比（ＦＦＲ）ＰＩＭ、ＦＬＩＶＵＳ−ＰＩＭ、及びＩＣＥ−ＰＩＭ。他の実施形態では、追加の及び／又は異なる医療感知装置、治療装置、又は診断用装置は、追加の及び／又は異なる公知のデータ通信接続を介して、処理システム（１０１）と接続されてもよい。こうしたシナリオにおいて、ＩＶＵＳ獲得モジュール（２２０）のほかに、処理フレームワーク（２００）は以下を含むことができる：ＦＦＲ−ＰＩＭからＦＦＲデータを受け取るためのＦＦＲ獲得構成要素；ＦＬＩＶＵＳデータをＦＬＩＶＵＳ−ＰＩＭから受け取るためのＦＬＩＶＵＳ獲得構成要素；ＩＣＥデータをＩＣＥ−ＰＩＭから受け取るためのＩＣＥ獲得構成要素；及びＯＣＴデータをＯＣＴ−ＰＩＭから受け取るために動作可能なＯＣＴ獲得構成要素。こうした文脈において、処理フレームワーク（２００）の実行可能な構成要素と通信可能に接続される医療装置（例えば、ＰＩＭ、カテーテル等）との間で通信される医療データは、以下を含むことができる：センサによって収集されるデータ、コントロールシグナル、パワーレベル、装置フィードバック、及び感知手順、治療手順、又は診断用手順に関連する他の医療データ。更に、ある実施形態において、患者治療装置は、処理システム（１０１）に通信可能に接続されてもよく、患者治療装置の例として、例えば、以下の装置が挙げられる：ラジオ波アブレーション（ＲＦＡ）、凍結療法、又はアセレクトミに関連した装置、及びこうした治療手順に関連する任意のＰＩＭ又は他のコントロール装置。こうした実施形態において、手法「Ｎ」の獲得構成要素（２２４）及び手法「Ｎ」のワークフロー構成要素（２２６）は、以下の動作を行うように構成されてもよい：治療装置と通信し、及び制御を行うこと（例えば、コントロール・シグナルをリレーすることによって、パワーレベルをリレーすることによって、装置フィードバックを受け取ることによって、及び治療装置上に配置されたセンサが集めたデータを受け取ることによって）。
【００３２】
一実施形態において、一旦、獲得構成要素（２２０）及び（２２４）が、データを、接続された医療感知装置から受け取ると、構成要素は、データをメッセージへとパケット化してシステム間の通信を促進する。具体的には、構成要素は、受け取ったデジタルデータストリームから複数のメッセージを生成するように動作可能であってもよく、ここで、各メッセージは一部のデジタル化した医療感知データ及びヘッダを含む。メッセージヘッダは、メッセージ内に含まれる医療感知データに関連するメタデータを含む。更に、幾つかの実施形態において、獲得構成要素（２２０）及び（２２４）は、以下の操作が可能であってもよい：デジタル化した医療感知データをフレームワーク（２００）の他の部分に送信する前に、該データを何かしらの方法で操作すること。例えば、獲得構成要素は、感知データを圧縮して、システム間の通信をより効率的なものにすることができ、又はデータを正規化したり、スケール調整したり、若しくはそうでない場合にはフィルタリングしたりして、データの後々行う処理を補助することができる。幾つかの実施形態において、こうした操作は、手法に特化したものであってもよい。例えば、ＩＶＵＳ獲得構成要素（２２０）は、ＩＶＵＳデータを渡す前に、冗長なＩＶＵＳデータを特定及び破棄して、続いてのステップでの処理時間を節約することができる。更に言えば、獲得構成要素（２２０）及び（２２４）は、データの獲得に関連する複数のタスクを実行することができ、該タスクとしては以下のものが含まれる：データバス（例えば、ＰＣＩｅ、ＵＳＢ）によって発生した中断に対して応答すること；どの医療感知装置が処理システム（１０１）に接続されているか検出すること；接続された医療感知装置に関する情報を取得すること；感知装置特有のデータを記憶すること；及びリソースをデータバスに割り当てること。上述したように、データ獲得構成要素は互いに独立しており、そして、他の構成要素によるデータ獲得を妨害することなくインストール又は削除されてもよい。更に言えば、獲得構成要素は、潜在的なデータバスソフトウェア層（例えば、ＡＰＩの使用を通して）から独立しており、従って、サードパーティによって生成されて、サードパーティの医療感知装置からのデータの獲得を促進することができる。
【００３３】
処理フレームワークのワークフロー構成要素（例えばＩＶＵＳワークフロー構成要素（２２２））は、処理されていない医療感知及び／又は診断用データを、それぞれの獲得構成要素から、メッセージデリバリ構成要素（２１０）を介して受け取る。一般的に、ワークフロー構成要素は、医療感知データの獲得をコントロールするように構成される（例えば、計算された時間でデータ収集を開始及び停止することによって、獲得及び処理された患者データを表示することによって、及び獲得した患者データを臨床医が分析すること促進することによって）。この態様として、ワークフロー構成要素は、患者から集めた処理されていない医療データを、診断用画像又は他のデータフォーマットに変換するように動作可能であり、これにより、臨床医が患者のコンディションを評価することができる。例えば、ＩＶＵＳワークフロー構成要素（２２２）は、ＩＶＵＳ−ＰＩＭ（１１２）から受け取ったＩＶＵＳデータを解釈し、及びデータをヒトが読み取れるＩＶＵＳ画像に変換することができる。一実施形態において、フレームワーク内のソフトウェアスタックは、１組のＡＰＩを露出することができ、該ＡＰＩを用いて、フレームワーク内のワークフロー構成要素（２２２）及び他のワークフロー構成要素は、コールして、システムリソース（例えば、コンピューターのリソース、メッセージデリバリ構成要素（２１０）、及び通信リソース）にアクセスすることができる。獲得したデータを処理した後、手法を中心としたワークフロー構成要素は、該データ又は処理されたデータを含有するメッセージを、フレームワーク（２００）内の他の構成要素に、メッセージデリバリ構成要素（２１０）を介して送信することができる。幾つかの実施形態において、こうしたメッセージを送信する前に、構成要素は、ヘッダ内にフラグを挿入して、処理されたデータをメッセージが含む旨を示すことができる。更に言えば、幾つかの実施形態において、医療感知データを処理した後、構成要素は、データベースマネージメント構成要素（２１６）を用いて、処理されたデータを、アーカイブのシステムに送信することができる（例えば、ローカルでアタッチされたマス・ストレージ・デバイス又はネットワークベースのＰＡＣＳサーバー（１２７））。処理フレームワーク（２００）のモジュール化アーキテクチャに従い、ワークフロー構成要素（２２２）及び（２２６）は、互いに独立しており、そして、他の構成要素を妨害することなくインストール又は削除することができ、また、サードパーティによって書き込むことができる。更に、これらの独立性が原因となって、これらの構成要素は、複数の医療感知装置からのシグナリング及び撮像データを同時に処理できるように動作可能であってもよい。
【００３４】
処理フレームワーク（２００）は、共記録インターフェース構成要素（２３０）及び共記録ワークフロー構成要素（２３２）を更に含み、これらは以下の動作を行うように構成される：任意の数のデータ収集ツール（２３４）からのデータを獲得及び処理すること；並びに、該獲得したデータを、フレームワーク内の他の獲得構成要素のうちの１つが獲得したデータとともに、共記録すること。更に詳しく述べると、共記録インターフェース構成要素（２３０）は、医療データ獲得ツールとの通信可能なインターフェースとなるよう動作可能であってもよく、該ツールは、任意の数の手法（例えば、図１のＥＣＧ装置（１１６）又は血管造影法システム（１１７））に関連してもよい。ある実施形態において、インターフェース構成要素（２３０）は、受け取った手法データを標準化及び／又は変換するよう動作可能であってもよく、その結果、該データを、処理システム（１０１）が獲得した他の感知データとともに共記録することができる。医療データを共記録インターフェース構成要素（２３０）が獲得しているとき、共記録ワークフロー構成要素（２３２）は、以下の動作を行うように構成される：異なる手法からのデータの共記録を促進すること（例えば医療感知装置間でデータ収集を時間的又は空間的にシンクロさせることによって；空間的又は時間的な記録マーカーに基づいて、２以上の獲得したデータ群を割り当てることによって；及び臨床医が患者のコンディションを評価することができる共記録された診断用画像又は他のヒトが読取可能なデータを生成することによって）。更に、他の実施形態では、共記録ワークフロー構成要素（２３２）は、予め生成した２−Ｄ画像又は３−Ｄモデルを用いた二次元（２−Ｄ）の又は３次元（３−Ｄ）の空間内で、カテーテルで収集したデータを空間的に共記録するように動作可能であってもよい。例えば、カテーテルベースの感知ツールは基準点を含むことができ、これを追跡して、位置データを感知処置中に生成することができ、そして、共記録ワークフロー構成要素（２３２）は、この位置データを、以前獲得したＭＲＩデータに対して記録することができる。更にいうと、共記録ワークフロー構成要素（２３２）は、フレームワーク（２００）内のネイティブな獲得構成要素（例えばＩＶＵＳ獲得構成要素（２２０）及び手法「Ｎ」の獲得構成要素（２２４））が獲得したマルチモダリティデータの共記録を促進することができる。更に言えば、幾つかの実施形態において、リアルタイムクロックを、共記録ワークフロー構成要素（２３２）に組み込むことができる。米国仮特許出願番号６１／４７３，５９１（発明の名称「ＤＩＳＴＲＩＢＵＴＥＤ  ＭＥＤＩＣＡＬ  ＳＥＮＳＩＮＧ  ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ」）は、医療感知データコレクションを時間的にシンクロさせることについて更に詳しく開示しており、そして、参照により全体を本明細書に組み込む。
【００３５】
図１関連して上述したように、処理システム（１０１）を用いる臨床医は、ワークフローをコントロールし、並びに、診断用画像を、メイン・コントローラー（１２０）及びベッドサイドコントローラー（１１８）を通して見ることができる。メイン・コントローラー（１２０）及びベッドサイドコントローラー（１１８）それぞれは、ユーザー・インターフェース（ＵＩ）フレームワークサービス（２４０）及び（２４２）を含み、これらは、複数のユーザー・インターフェース（ＵＩ）拡張要素（又は構成要素）をサポートする。一般的に、ＵＩフレームワーク・サービス（２４０）及び（２４２）がサポートするＵＩ拡張要素は、医療感知手法にそれぞれ対応し、並びに、関連する獲得ワークフロー及び処理された感知データの表示のコントロールのためのユーザー・インターフェースを授けるよう動作可能である。処理フレームワーク（２００）と同様に、ＵＩフレームワーク（２４０）及び（２４２）は、互いに独立したＵＩ拡張要素をサポートするという点で、拡張可能である。即ち、モジュールの設計は、ＵＩフレームワーク（２４０）及び（２４２）を拡張して、追加の医療感知手法ユーザー・インターフェースを収容することを可能にし、その際に、既存のユーザー・インターフェースに影響を与えることがなく、又は潜在するＵＩアーキテクチャに対する変更を要求することがない。例示した実施形態において、メイン・コントローラー（１２０）は、システムＵＩ拡張要素（２４４）を含み、該要素は、ユーザー・インターフェースを授け、該インターフェースは、コアとなるシステムコントロール及び構成オプションを含む。例えば、臨床医は、システムＵＩ拡張要素（２４４）が授けたユーザー・インターフェースを用いて、処理システム（１０１）をスタートアップ、シャットダウン、又はそうでない場合には管理することができる。一実施形態において、メイン・コントローラー（１２０）の構成要素は、処理フレームワーク（２００）の一部と考えることができる。ＩＶＵＳ−ＵＩ拡張要素（２４６）及び（２４８）は、メイン・コントローラー（１２０）及びベッドサイドコントローラー（１１８）のためのユーザー・インターフェースを、それぞれ授ける。例えば、ＩＶＵＳ−ＵＩ拡張要素（２４６）及び（２４８）は、タッチスクリーンボタンを提供及び表示することができ、該ボタンはＩＶＵＳワークフローをコントロールするために用いられ、並びに、ＩＶＵＳワークフロー構成要素（２２２）が生成したＩＶＵＳ診断用画像を提供及び表示することもできる。同様に、手法「Ｎ」のＵＩ拡張要素（２５０）及び（２５２）は、手法「Ｎ」のワークフローに関連するコントロール及び画像を提供する。
【００３６】
一実施形態において、ＵＩフレームワーク・サービス（２４０）及び（２４２）は、ＡＰＩを曝して、これを用いて、ＵＩ拡張要素はコールをし、システムリソースにアクセスする（例えばルック・アンド・フィールなツールボックス及びエラーハンドリングリソース）。ルック・アンド・フィールなツールボックスのＡＰＩは、ＵＩ拡張要素が以下を提示することを可能にする：異なる手法のワークフローのための共通のボタンを有する標準化ユーザー・インターフェース、並行ワークフローのフォーマット、及びデータ提示スキーム。この方法で、臨床医は、追加のユーザー・インターフェース訓練なしでも、更に容易に複数の獲得手法に移行することができる。更に、共記録ＵＩ拡張要素は、複数の手法からの処理された画像又はシグナリングデータを提示する及び／又は組み合わせることができる。例えば、ＵＩ拡張要素は、心電図（ＥＣＧ）の波形をＩＶＵＳ撮像データの隣に表示することができ、又は、ＩＶＵＳ画像を表示することができ、該画像は、ＯＣＴ画像上に予め描写された境界にオーバーレイされてもよい。更に、幾つかの実施形態において、ＵＩフレームワーク・サービス（２４０）及び（２４２）は、マルチタスクなフレームワークを含むことができ、同時に実行するＵＩ拡張要素を調整することができる。例えば、複数の手法に関連するデータを処理システム（１０１）が同時に獲得したときに、ＵＩフレームワーク・サービス（２４０）及び（２４２）は、ユーザーに手法選択スクリーンを提示することができ、該スクリーン上で、所望のユーザー・インターフェースを選択することができる。
【００３７】
ＵＩフレームワーク・サービス（２４０）は、メッセージデリバリ構成要素（２１０）を介して、処理フレームワーク（２００）の構成要素と通信する。図２の例示した実施形態に示すように、ベッドサイドコントローラー（１１８）は、ネットワーク接続（２５４）を介して処理フレームワーク（２００）に通信可能に接続されてもよい。ネットワーク接続（２５４）は、任意のタイプの有線又は無線ネットワーク接続であってもよい（例えばイーサネット（登録商標）接続又はＩＥＥＥ８０２．１１Ｗｉ−Ｆｉ（登録商標）接続）。或いは、メインコントローラー及びベッドサイドコントローラー（（１２０）及び（１１８））のうちの一方又は両方は、ローカルバス接続を介して、処理フレームワーク（２００）と通信してもよい（例えば（ＰＣＩｅ）データバス接続、ＵＳＢ接続、Ｔｈｕｎｄｅｒｂｏｌｔ接続、ＦｉｒｅＷｉｒｅ（登録商標）接続、又は幾つかの他の高速データバス接続）。更に、図２の例示した実施形態において、ベッドサイドコントローラーは、メッセージデリバリ構成要素（２５６）を含み、該構成要素は以下の動作を行うように構成される：ベッドサイドコントローラー（１１８）内のＵＩ拡張要素と処理フレームワーク（２００）内の構成要素との間でのメッセージベースの通信を促進すること。ある実施形態において、ネットワーク通信パケットがネットワーク接続（２５４）を介して到着したときに、メッセージデリバリ構成要素（２５６）は、該パケットから、診断用画像データを抽出することができる。
【００３８】
処理フレームワーク（２００）は、追加の構成要素を含み、これにより、臨床医は、マルチモダリティ処理システム（１０１）中で実行されるワークフローに対してアクセス及び／又はコントロールを行うことができる。例えば、フレームワーク（２００）は、リモートアクセス構成要素（２６０）を含み、該構成要素は、ネットワークコンソール（１３０）（図１）を処理フレームワーク（２００）に通信可能に接続させる。一実施形態において、リモートアクセス構成要素（２６０）は、処理システム（１０１）のコントロール機能をネットワークコンソール（１３０）にエクスポートするように動作可能であり、その結果、ネットワークコンソールは、ワークフローコントロール機能を、該コンソールのユーザー・インターフェース内に提示することができる。ある実施形態において、リモートアクセス構成要素（２６０）は、ワークフローコマンドを、ネットワークコンソール（１３０）から受け取ることができ、そして、該コマンドをリモートアクセスワークフロー構成要素（２６２）に送ることができる。リモートアクセスワークフロー構成要素（２６２）は、コマンド群及び診断用データを受け取ることができ、リモートユーザーは、ネットワークコンソール（１３０）を通じてこれらにアクセスすることができる。更に、レガシーコントロール構成要素（２６４）及びレガシーコントロールワークフロー構成要素（２６６）は、手法ワークフローコントロール及びデータに対するあるレベルのアクセスを、レガシーコンソール（２６８）（例えば、ボタンコンソール、マウス、キーボード、スタンドアロンモニタ）のユーザーに提供する。
【００３９】
一実施形態において、処理フレームワーク（２００）のコアとなるシステム構成要素及び追加の構成要素（例えば手法に関連する構成要素）は、非一時的な、コンピュータ可読記憶媒体上に保存されたプロセッサ−実行可能なソフトウェアとして実装されてもよいが、しかし別の実施形態では、これらの構成要素はハードウェア構成要素として実装されてもよい（例えば特定目的マイクロプロセッサ、現場でプログラム可能なゲートアレイ（ＦＰＧＡ）、マイクロコントローラ、グラフィックス処理ユニット（ＧＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）。或いは処理フレームワークの構成要素は、ハードウェア及びソフトウェアの組合せとして実装されてもよい。
【００４０】
当業者は以下の点を認識するであろう：即ち、図２の処理フレームワーク（２００）は、単に例示的な実施形態であり、そして、別の実施形態では、フレームワークは、異なる及び／又は追加の構成要素を含むことができ、これらは、様々な医療感知ワークフローを実行するように構成される。例えば、処理フレームワーク（２００）は、実行可能な構成要素を更に含むことができ、該構成要素は、以下を行うように構成されてもよい：ヒト血管の狭窄の評価を行うこと；又はコンピュータが補助する外科手術若しくは遠隔制御された外科手術のコントロールを促進すること。
【００４１】
ここで図３を参照されたい。該図では、方法（３００）を示した高度なフローチャートを図示しており、本開示の態様に従ったマルチモダリティ医療処理システムに関する、依存性に基づくスタートアップ配列を目的とする。例示した実施形態において、方法（３００）の少なくとも一部を、図２の処理フレームワーク（２００）のシステムコントローラー（２０２）が実行する。更に、一実施形態において、方法（３００）の一部は、コンピュータ可読指示によって実施されてもよく、該指示は、マス・ストレージ・デバイス又はシステムメモリ上に記憶されてもよく、及び図１のマルチモダリティ処理システム（１０１）のプロセッサによって実行されてもよい。更に、図３中の方法（３００）は、高度な概観であり、そして、前記方法における様々なブロックに関連する詳細内容については、本開示のその後の図と関連して説明する。
【００４２】
方法（３００）は、ブロック（３０２）にて開始され、ここでは、処理システム（１０１）は、パワーオン、再起動、又は、そうでない場合には初期化される。一旦パワーオンになると、１以上のハードウェア構成要素の検証テストを実行することができ、該テストは、基本入力／出力システム（ＢＩＯＳ）又は処理システム（１０１）内の他の低レベルファームウェアインターフェースによって実行され、システムのハードウェア構成要素を初期化する。ハードウェアを初期化した後、処理フレームワーク（２００）のコアとなるシステム構成要素（例えばシステムコントローラー（２０２））を初期化する。システムコントローラー（２０２）は、処理フレームワーク（２００）内のデータ獲得、ワークフロー管理、及び他の医療データ管理に関連する実行可能な構成要素の残り部分を開始させる役割を担う。多くのこうした構成要素は、様々なサービス又は機能に関して互いに依存関係にあり（即ち、構成要素は相互依存している）、従って、構成要素は特定の順序で開始しなければならず、その結果、他の構成要素が依存するサービスは、これらの構成要素が開始されたときに利用可能となる。例えば、処理フレームワーク（２００）のセキュリティ構成要素（２１２）は、ログ取得インターフェースを必要とする可能性があり、該インターフェースは、イベントログ構成要素（２０６）によって利用可能となる。従って、イベントログ構成要素（２０６）は、セキュリティ構成要素（２１２）よりも先に、システムコントローラー（２０２）によって開始されるべきものである。本開示の態様に従って、システムコントローラー（２０２）は、以下の点で動作可能である：構成要素の相互依存性に基づいて開始順序を動的に生成すること、及び連続的に構成要素を開始させること、その結果、各構成要素が開始されたときに、全ての必要なインターフェースへ該構成要素がアクセスし、そして、デッドロック、ブートループ、又は他の初期化エラーを防止する。
【００４３】
こうした点に関して、システムコントローラー（２０２）を初期化した後、方法（３００）はブロック（３０４）まで進み、ここでは、システムコントローラーは、複数の実行可能な構成要素に関する構成要素の初期化及び依存性情報を受け取り、これについては、システムスタートアップの最中の初期化とともにタスク化されている。一実施形態において、実行可能な構成要素に関連する構成要素の初期化情報は、以下を含むことができる：構成要素の名称（即ち、構成要素の識別子）、構成要素の実行可能なファイルの名称及びファイル・システムの場所、実行可能なファイルと共に構成要素を開始させるのに必要なコマンドライン引数、構成要素のタイプ、構成要素の外部のインターフェース、スタートアップのタイムアウト、並びに、リカバリオプション。別の実施形態では、追加の及び／又は異なる情報は、各構成要素の初期化情報に含まれてもよい（例えば優先順位の情報、メモリ割り当て情報、又はもし実行可能な構成要素がハードウェアベースである場合には、ハードウェアのアドレス情報）。実行可能な構成要素に関連する依存性情報は、実行可能な構成要素が依存する他の実行可能な構成要素のリストを含む。こうした文脈において、もしも、第二の構成要素によって曝されるインターフェースによって利用可能になる機能を、第一の構成要素が利用する場合、第一の実行可能な構成要素（即ち、クライアント）は第二の実行可能な構成要素（即ち、サーバー）に依存する。従って、全ての第二の実行可能な構成要素のインターフェースは、第一の実行可能な構成要素をシステムコントローラーが適切に開始させる前に、利用可能にしなければならない。別の実施形態では、追加の及び／又は異なる情報は、各構成要素の依存性情報内に含まれてもよい（例えば、構成要素が依存する特定の外部のインターフェースのアイデンティティ）。
【００４４】
一実施形態において、構成要素初期化及び依存性情報は、システムコントローラー（２０２）がシステムのスタートアップ時に読み込む構成ファイル内に含まれる。少なくとも、こうした構成ファイルは、開始すべき実行可能な構成要素のリスト、及び、該リスト内の各実行可能な構成要素に関して、該構成要素が依存する構成要素のリストを含む。簡単な例として、構成ファイルは、以下の点を示してもよい：イベントログ構成要素（２０６）、ワークフローコントローラー構成要素（２０４）、及びＩＶＵＳワークフロー構成要素（２２２）は、システムコントローラー（２０２）によって開始させる必要があること。また、こうした構成ファイルは以下の点を示すであろう：ＩＶＵＳワークフロー構成要素（２２２）は、イベントログ構成要素（２０６）及びワークフローコントローラー構成要素（２０４）の両方に依存し、及びワークフローコントローラー構成要素（２０４）は、イベントログ構成要素（２０６）に依存する。詳しく後述するが、システムコントローラー（２０２）は、こうした構成ファイルの情報を取得するよう動作可能であり、そして、依存性情報に基づく正しい順序で、イベントログ構成要素（２０６）、ワークフローコントローラー構成要素（２０４）、及びＩＶＵＳワークフロー構成要素（２２２）を開始させるように動作可能である。
【００４５】
ある実施形態において、システムコントローラー（２０２）が読み取った構成ファイルは、既定のスキーマを有する拡張可能マークアップ言語（ＸＭＬ）ドキュメントであってもよい。以下は一部の例示的なＸＭＬ構成ファイルであり、イベントログ構成要素（２０６）、ワークフローコントローラー構成要素（２０４）、及びＩＶＵＳワークフロー構成要素（２２２）のための初期化情報及び依存性情報を含む。
【００４６】
＜ＰｒｏｇｒａｍＯｂｊｅｃｔ  ｖｅｒｓｉｏｎ＝“１”＞
＜Ｎａｍｅ＞ＥｖｅｎｔＬｏｇｇｉｎｇＣｏｍｐｏｎｅｎｔ＜／Ｎａｍｅ＞
＜Ｆｉｌｅｎａｍｅ＞ｃ：￥ｂｉｎ￥ＥｖｅｎｔＬｏｇｇｉｎｇＣｏｍｐｏｎｅｎｔ．ｅｘｅ＜／Ｆｉｌｅｎａｍｅ＞
＜ＣｏｍｍａｎｄＰａｒａｍｅｔｅｒｓ＞＜／ＣｏｍｍａｎｄＰａｒａｍｅｔｅｒｓ＞
＜Ｓｙｎｃｈｒｏｎｉｚｅ  ｔｉｍｅｏｕｔ＝“３００００”＞
＜ＳｙｎｃｈＴｙｐｅ＞ＷａｉｔＦｏｒＲｅｇｉｓｔｒａｔｉｏｎ＜／ＳｙｎｃｈＴｙｐｅ＞
＜／Ｓｙｎｃｈｒｏｎｉｚｅ＞
＜Ｒｅｃｏｖｅｒｙ＞ＳｈｕｔｄｏｗｎＳｙｓｔｅｍ＜／Ｒｅｃｏｖｅｒｙ＞
＜ＰｒｏｇｒａｍＴｙｐｅ＞Ｌｏｇｇｅｒ＜／ＰｒｏｇｒａｍＴｙｐｅ＞
＜Ｉｎｔｅｒｆａｃｅ＞ｉ＿ｅｘｅｃｕｔａｂｌｅ＜／Ｉｎｔｅｒｆａｃｅ＞
＜／ＰｒｏｇｒａｍＯｂｊｅｃｔ＞
＜ＰｒｏｇｒａｍＯｂｊｅｃｔ  ｖｅｒｓｉｏｎ＝“１”＞
＜Ｎａｍｅ＞  ＷｏｒｋｆｌｏｗＣｏｎｔｒｏｌｌｅｒＣｏｍｐｏｎｅｎｔ  ＜／Ｎａｍｅ＞
＜Ｆｉｌｅｎａｍｅ＞ｃ：￥ｂｉｎ￥  ＷｏｒｋｆｌｏｗＣｏｎｔｒｏｌｌｅｒＣｏｍｐｏｎｅｎｔ．ｅｘｅ＜／Ｆｉｌｅｎａｍｅ＞
＜ＣｏｍｍａｎｄＰａｒａｍｅｔｅｒｓ＞ＷＣＣｃｏｎｆｉｇ．ｘｍｌ＜／ＣｏｍｍａｎｄＰａｒａｍｅｔｅｒｓ＞
＜Ｓｙｎｃｈｒｏｎｉｚｅ  ｔｉｍｅｏｕｔ＝“３００００”＞
＜ＳｙｎｃｈＴｙｐｅ＞ＷａｉｔＦｏｒＲｅｇｉｓｔｒａｔｉｏｎ＜／ＳｙｎｃｈＴｙｐｅ＞
＜／Ｓｙｎｃｈｒｏｎｉｚｅ＞
＜Ｒｅｃｏｖｅｒｙ＞ＳｈｕｔｄｏｗｎＳｙｓｔｅｍ＜／Ｒｅｃｏｖｅｒｙ＞
＜ＰｒｏｇｒａｍＴｙｐｅ＞ＣｏｒｅＳｅｒｖｉｃｅ＜／ＰｒｏｇｒａｍＴｙｐｅ＞
＜Ｉｎｔｅｒｆａｃｅ＞ｉ＿ｅｘｅｃｕｔａｂｌｅ＜／Ｉｎｔｅｒｆａｃｅ＞
＜／ＰｒｏｇｒａｍＯｂｊｅｃｔ＞
＜ＰｒｏｇｒａｍＯｂｊｅｃｔ  ｖｅｒｓｉｏｎ＝“１”＞
＜Ｎａｍｅ＞  ＩＶＵＳＷｏｒｋｆｌｏｗＣｏｍｐｏｎｅｎｔ  ＜／Ｎａｍｅ＞
＜Ｆｉｌｅｎａｍｅ＞ｃ：￥  ｂｉｎ￥  ＩＶＵＳＷｏｒｋｆｌｏｗＣｏｍｐｏｎｅｎｔ．ｅｘｅ＜／Ｆｉｌｅｎａｍｅ＞
＜ＣｏｍｍａｎｄＰａｒａｍｅｔｅｒｓ＞ＩＶＵＳｃｏｎｆｉｇ．ｘｍｌ＜／ＣｏｍｍａｎｄＰａｒａｍｅｔｅｒｓ＞
＜Ｓｙｎｃｈｒｏｎｉｚｅ  ｔｉｍｅｏｕｔ＝“３００００”＞
＜ＳｙｎｃｈＴｙｐｅ＞ＷａｉｔＦｏｒＰｉｄ＜／ＳｙｎｃｈＴｙｐｅ＞
＜／Ｓｙｎｃｈｒｏｎｉｚｅ＞
＜Ｒｅｃｏｖｅｒｙ＞ＤｉｓａｂｌｅＭｏｄａｌｉｔｙ＜／Ｒｅｃｏｖｅｒｙ＞
＜ＰｒｏｇｒａｍＴｙｐｅ＞Ｍｏｄａｌｉｔｙ＜／ＰｒｏｇｒａｍＴｙｐｅ＞
＜Ｉｎｔｅｒｆａｃｅ＞＜／Ｉｎｔｅｒｆａｃｅ＞
＜／ＰｒｏｇｒａｍＯｂｊｅｃｔ＞
＜Ｄｅｐｅｎｄｅｎｃｙ＞
＜Ｃｌｉｅｎｔ＞  ＩＶＵＳＷｏｒｋｆｌｏｗＣｏｍｐｏｎｅｎｔ  ＜／Ｃｌｉｅｎｔ＞
＜Ｓｅｒｖｅｒ＞  ＷｏｒｋｆｌｏｗＣｏｎｔｒｏｌｌｅｒＣｏｍｐｏｎｅｎｔ  ＜／Ｓｅｒｖｅｒ＞
＜Ｓｅｒｖｅｒ＞  ＥｖｅｎｔＬｏｇｇｉｎｇＣｏｍｐｏｎｅｎｔ  ＜／Ｓｅｒｖｅｒ＞
＜／Ｄｅｐｅｎｄｅｎｃｙ＞
＜Ｄｅｐｅｎｄｅｎｃｙ＞
＜Ｃｌｉｅｎｔ＞  ＷｏｒｋｆｌｏｗＣｏｎｔｒｏｌｌｅｒＣｏｍｐｏｎｅｎｔ  ＜／Ｃｌｉｅｎｔ＞
＜Ｓｅｒｖｅｒ＞  ＥｖｅｎｔＬｏｇｇｉｎｇＣｏｍｐｏｎｅｎｔ  ＜／Ｓｅｒｖｅｒ＞
＜／Ｄｅｐｅｎｄｅｎｃｙ＞
【００４７】
上記の例示的なＸＭＬ構成ファイル部分に示すように、ＩＶＵＳワークフロー構成要素（２２２）のための初期化情報は以下を含む：識別子（“ＩＶＵＳＷｏｒｋｆｌｏｗＣｏｍｐｏｎｅｎｔ”）、システムコントローラーが開始する実行可能なファイル名（“ｃ：￥ｂｉｎ￥ＩＶＵＳＷｏｒｋｆｌｏｗＣｏｍｐｏｎｅｎｔ．ｅｘｅ”）、コマンドライン実行中に、実行可能な構成要素に渡すコマンドパラメーター（“ＩＶＵＳｃｏｎｆｉｇ．ｘｍｌ”）、タイムアウト及び同期化タイプ、及び実行エラーの場合に行われるリカバリアクション（“Ｄｉｓａｂｌｅ  ｍｏｄａｌｉｔｙ”）。また、ＸＭＬ構成ファイルは、ＩＶＵＳワークフロー構成要素（２２２）に関する依存性情報を含み、該情報は、構成要素の識別子をリスト化しており、該構成要素は、ＩＶＵＳワークフロー構成要素が依存する構成要素である（即ち、ＷｏｒｋｆｌｏｗＣｏｎｔｒｏｌｌｅｒＣｏｍｐｏｎｅｎｔ及びＥｖｅｎｔＬｏｇｇｉｎｇＣｏｍｐｏｎｅｎｔ）。
【００４８】
当業者であれば以下の点を認識するであろう：即ち、上記ＸＭＬ構成ファイルは、単なる例示でありそして、フレームワーク（２０２）に関する構成ファイルは、更に多くの実行可能な構成要素及び関連する依存性を含むことができ、また、任意の数の追加の及び／又は異なる態様でフォーマットされてもよく、並びに追加の及び／又は異なる情報を含むことができる。更に、システムコントローラー（２０２）は、構成用ファイルを読み込む以外の様々な異なる方法で、処理フレームワーク（２００）内の実行可能な構成要素に関する初期化及び依存性情報を受け取ることができる。例えば、一実施形態において、システムコントローラー（２０２）は構成情報を以下から得ることができる：集中ネットワーク構成レポジトリ又は専用のハードウェアメモリ装置（例えば、電気的に消去可能なプログラム制御可能なリード・オンリ・メモリ（ＥＥＰＲＯＭ））。更に、システムコントローラーは、静的な及び動的な構成情報の組合せを得ることができ、例えば、以下によって得ることができる：あらゆるスタートアップ配列の最中に開始されるコアとなるシステム構成要素をリストしている静的な構成ファイルを読み込むことによって；また、どの医療感知装置が処理システム（１０１）と結合したかを動的に検出することによって；及び検出された医療感知装置に関連する実行可能な構成要素のみを開始することによって。
【００４９】
上述したように、処理システム（１０１）は、複数の医療手法に関連するデータを収集及び処理するように動作可能である。とりわけ、特定の手法が特定の医療処置中に必要ない場合、必要ない手法に関連する実行可能な構成要素は、構成情報中の実行可能な構成要素のリストから除外してもよく、従って、システムスタートアップの最中、システムコントローラー（２０２）によって開始されることはないであろう。例えば、一実施形態において、もしも、カテーテル検査室でのセッション中、ＩＶＵＳが患者に対して行われないのであれば、ＩＶＵＳ獲得モジュール、ＩＶＵＳワークフロー構成要素、及びＩＶＵＳ  ＵＩ拡張要素は、システムコントローラーが読み込む構成ファイルから除外することができる。別の実施形態では、特定の手法又は特定の拡張要素は、例外ファイルを用いて、スタートアップから除外することができる。具体的には、システムコントローラー（２０２）が構成ファイルを読み込んだ後、該コントローラーは例外ファイルを読み込むことができ、該ファイルは一時的に不活状態にすべき実行可能な構成要素のリストを含む。また、こうした例外ファイルは、日付を特定した期限情報を含むことができ、該期限後は、実行可能な構成要素は、もはやスタートアップに実行すべきものではなくなる。従って、特定の処置に必要な構成要素のみを開始させることによって、処理システム（１０１）は、より効率的な方法で稼働させることができ、そして、必要のない実行可能な構成要素に関連する不要なエラーを回避することができる。更に言えば、上述したように、処理フレームワーク（２００）は、拡張可能であり、従って、新たな医療手法に対応する実行可能な構成要素を追加することができる。こうしたシナリオにおいて、新たな構成要素をプロセスフレームワークにインストールすることができ、そして、システムスタートアップ時にシステムコントローラーに提供される該構成要素の初期化及び依存性情報にインストールすることができる。従って、新たな手法の構成要素は、任意の既存のシステムスタートアップインフラに再書き込みすることなく、開始することができる。
【００５０】
システムコントローラー（２０２）が、実行可能な構成要素に関する初期化及び依存性情報を、ブロック（３０４）で受け取った後、方法（３００）はブロック（３０６）まで進み、ここでは、システムコントローラー（２０２）が、初期化情報及び依存性情報を依存性マップに変換する。具体的には、システムコントローラーは、データ構造を作成し、該構造は、開始すべき全ての実行可能な構成要素を含み、及び実行可能な構成要素間の全ての依存性を表す。様々な実施形態において、依存性マップは、多くの異なる形態であってもよい（例えばダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）又は数値での依存性マトリックス）。図４は、例示的なダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）（３１０）を表し、方法（３００）のブロック（３０６）で、システムコントローラー（２０２）によって構築される。ダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）（３１０）の頂点（ノード）は、システムコントローラーが開始させる実行可能な構成要素それぞれ表し、及び頂点（ノード）間のエッジは、構成要素間の依存性を表す。例えば、とりわけ、ダイレクトグラフ（３１０）は、上述した例示的なＸＭＬ構成ファイル内で確立された依存性を描写しており、即ち、ＩＶＵＳワークフロー構成要素（２２２）は、イベントログ構成要素（２０６）及びワークフローコントローラー構成要素（２０４）の両方に依存し、並びに、今度は、ワークフローコントローラー構成要素（２０４）がイベントログ構成要素（２０６）に依存する。システムコントローラー（２０２）によって生成される例示的なダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）（３１０）は、同様に、フレームワーク（２００）内の複数の他の構成要素間の相互依存性を表す（例えばリソースアーバイター（ａｒｂｉｔｅｒ）構成要素（２０８）、ＵＩフレームワーク・サービス（２４０）、セキュリティ構成要素（２１２）、様々なＵＩ拡張要素（２４４）（２４６）（２５０）、及び手法ワークフロー構成要素（２２２）及び（２２６））。更に言えば、ダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）（３１０）は、状態表示構成要素（３１１）を描写しており、該構成要素は、システムコントローラー（２０２）と結合している。システムコントローラー（２０２）は、状態表示構成要素（３１１）を用いて、表示装置（例えばメイン・コントローラー（１２０）又はベッドサイドコントローラー（１１８））を介して、処理システム（１０１）のユーザーに、システムのスタートアップ状態を知らせる。一実施形態において、状態表示構成要素（３１１）は、フレームワーク内の他の構成要素から独立した実行可能な構成要素であり、その結果、システムコントローラーは、メインのＵＩフレームワーク・サービスが利用可能になる前に、システムスタートアップの最中、そのインターフェースを開始及び活用することができる。更に、簡潔にする目的から、フレームワーク（２００）の実行可能な構成要素を、全てダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）（３１０）に描写しているわけではない。更に言えば、上述したように、ダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａ���ｈ）（３１０）内で表現される相互依存性は、他のタイプのデータ構造でも表される（例えば構成要素間の相互依存性を表した（例えば、０又は１で）数値マトリックス）。更に、実行可能な構成要素が構成ファイルにリストされ、しかし、例外ファイルにもリストされている場合、実行可能な構成要素は、システムコントローラー（２０２）が構築したダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）内には含まれないであろう。
【００５１】
ブロック（３０６）にてシステムコントローラー（２０２）が依存性マップを構築した後、方法は、決定ブロック（３１２）に進んで、ここでは、依存性マップが任意の循環依存を含むかどうか決定される。具体的には、システムコントローラー（２０２）が依存性マップを検索して、互いに依存している２以上の実行可能な構成要素を探す。こうしたシナリオにおいて、「正しい」スタートアップ順序を決定することが不可能である可能性がある。循環依存が依存性マップ内に存在する場合、システムコントローラー（２０２）は、ブロック（３１４）にてエラーのログをとり、そして、システムをパワーオフする。もしも、循環依存が依存性マップ内に存在しない場合、方法（３００）は続行してブロック（３１６）に進み、ここでは、システムコントローラー（２０２）は、初期化情報によって示される実行可能な構成要素の開始順序を生成する。一実施形態において、システムコントローラー（２０２）は、深い方を先にした、トポロジカルなソートを、依存性マップに対して行うことができ、開始順序を生成し、該順序においては、ある構成要素が依存する別の構成要素よりも前にその構成要素がスタートするようなことはない。図４の例示において、ダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）（３１０）に対して、深い方を先にした、トポロジカルなソートを行った。具体的には、そのソートの結果、実行可能な構成要素は、スタートアップレベル（３２０）（３２２）（３２４）、及び（３２６）に配置され、該配置では、構成要素を、最も依存性の少ないものから最も依存性の高いものまで、グループ分けする。例えば、一番上のスタートアップレベル（３２０）は、リソースアーバイター（ａｒｂｉｔｅｒ）構成要素（２０８）及びイベントログ構成要素（２０６）を含み、その理由として、これらは、システムコントローラー（２０２）のみに依存するからである。一方で、一番下のスタートアップレベル（３２６）は、ＩＶＵＳワークフロー構成要素（２２２）及び手法「Ｎ」のワークフロー構成要素（２２６）を含み、その理由として、これらは、一次的又は二次的な形のいずれかで、他のスタートアップレベルそれぞれにある構成要素に依存するからである。
【００５２】
システムコントローラー（２０２）は、スタートアップレベル（３２０）（３２２）（３２４）、及び（３２６）を利用して、スタートアップ順序を決定する。具体的には、最も上にあるスタートアップレベル（３２０）内の全ての構成要素を、第二のスタートアップレベル（３２２）にある全ての構成要素よりも前に開始させるべきであり、及び第二のスタートアップレベル（３２２）内にある全ての構成要素を、スタートアップレベル（３２４）内の全ての構成要素よりも前に開始すべきであり、以下同様である。幾つかの実施形態において、各レベル内の構成要素のスタートアップ順序は、任意であってもよく、これらは互いに依存しないからである。こうしたシナリオにおいて、システムコントローラー（２０２）は、各レベル内の構成要素に関して、ランダムに開始順序を割り当てることができ、又は、別の実施形態では、システムコントローラーは、スタートレベル内の全ての構成要素を、同時に開始させることができる。しかし、他の実施形態では、システムコントローラー（２０２）は、開始順序ベクトルを構築することができ、該ベクトルは、開始すべき全ての実行可能な構成要素に関して、厳密且つ連続的なスタートアップ順序を表す。例えば、図５は、例示的な開始順序ベクトル（３３０）を表し、該ベクトルは、開始すべき実行可能な構成要素の順序リストを含む。一実施形態において、システムコントローラー（２０２）は、以下を用いて開始順序ベクトル（３３０）を構築する：トポロジカルにソートされたダイレクティドグラフ（ｄｉｒｅｃｔｅｄ  ｇｒａｐｈ）（３１０）；及び追加的因子（例えば構成要素の優先順位）。そして、同じスタートアップレベル内の実行可能な構成要素の開始順序を決定する。当業者であれば以下の点を認識するであろう：即ち、開始順序ベクトル（３３０）は、単なる例示であり、及び、多くの因子に依存した種々の異なる方法で順序付けされてもよく、そして、更には、システムコントローラー（２０２）は他のデータ構造を用いて、開始順序を維持してもよく、該順序は、依存性マップから生成され、該マップは、方法（３００）のブロック（３０６）において構築される。
【００５３】
一旦、開始順序をブロック（３１６）で決定すると、システムコントローラー（２０２）は、ブロック（３３２）内の開始順序に従って、処理フレームワーク（２００）内の実行可能な構成要素を開始させる。各実行可能な構成要素は、該構成要素の初期化情報（例えば、ブロック（３０４）にて、システムコントローラー（２０２）が受け取るコマンドラインパラメーター）に従って開始される。この態様として、一旦、実行可能な構成要素を開始させると、開始順序における次の構成要素を開始させる前に、システムコントローラー（２０２）は、構成要素の全てのインターフェースが利用可能になるまで待つ。一実施形態において、各実行可能な構成要素は、以下の点を必要とする：“Ｐｒｏｃｅｓｓ  Ｒｅａｄｙ”メッセージ（又はデータ転送オブジェクト）をシステムコントローラー（２０２）に配信し、該構成要素が該構成要素の全てのインターフェースを公開したことを示す。
【００５４】
更に、システムコントローラー（２０２）は、以下の動作を行うように構成される：スタートアップ配列の進行に関するログを取得すること（該ログには、開始された各実行可能な構成要素の成功又は失敗が含まれる）。ある実施形態において、スタートアップ配列の初期フェーズの間、イベントログ構成要素（２０６）が開始される前、システムコントローラー（２０２）は、限られた内部のログライブラリを用いて、メッセージのログをとることができる。その後、イベントログ構成要素（２０６）を開始させた後、システムコントローラー（２０２）は、ログ取得が行われるイベントログ構成要素に、状態メッセージを、メッセージデリバリ構成要素（２１０）を介して送ることができる。こうした状態メッセージは、“Ｐｒｏｃｅｓｓ  Ｒｅａｄｙ”メッセージ（又はデータ転送オブジェクト）を含むことができ、これらは実行可能な構成要素によって発行される。
【００５５】
一実施形態において、システムコントローラー（２０２）が、ブロック（３３２）でのシステムスタートアップの最中に、実行可能な構成要素を初期化する際に、該コントローラーは、スタートアップ配列の状態を、ユーザーに対して、表示装置上で表示することができ、該表示装置は、状態表示構成要素（３１１）を介して、処理システム（１０１）と結合している。具体的には、幾つかの例において、システムコントローラー（２０２）は、状態表示構成要素（３１１）をコールして、スプラッシュスクリーンをメイン・コントローラー（１２０）及び／又はベッドサイドコントローラー（１１８）上に表示することができ、その間、システムコントローラーは、実行可能な構成要素を開始させている。幾つかの実施形態において、スプラッシュスクリーンは静的であってもよいが、しかし、他の実施形態では、スプラッシュスクリーンは、各実行可能な構成要素のスタートアップ状態を表示することができ、その際には、システムコントローラー（２０２）が該構成要素を初期化しており、前記スタートアップ状態には、遭遇した任意のエラーが含まれる。例えば、状態表示構成要素（３１１）は、表示装置上に、第一の実行可能な構成要素のスタートアップ状態に関連する第一の情報スクリーンを表示することができ、そして、その後、表示装置をアップデートすることができ、その結果、表示装置は、第二の実行可能な構成要素のスタートアップ状態に関連する第二の情報スクリーンを表示する。
【００５６】
決定ブロック（３３４）において、全ての実行可能な構成要素のうち全てのインターフェースが利用可能であるかどうかが決定される（例えば、Ｐｒｏｃｅｓｓ  Ｒｅａｄｙメッセージを検査することによって）。もし、開始順序ベクトル内の全ての構成要素の開始に成功しなかった場合、方法（３００）はブロック（３３２）に戻り、全てのインターフェースが利用可能になるのを待ち、又は、もし、コアとなるシステム構成要素（例えばワークフローコントローラー構成要素（２０４））が開始できなかった場合には、システムコントローラー（２０２）は、処理システム（１０１）に関するシャットダウン配列を開始することができる。あるいは、もし、開始順序ベクトル内の全ての構成要素の開始に成功した場合には、方法（３００）は続行してブロック（３３６）に進み、ここでは、システムコントローラー（２０２）は、処理システム（１０１）の動作中に構成要素が実行している際に、構成要素の状態を監視する。この一態様として、システムコントローラー（２０２）は、実行可能な構成要素が発行するエラー及び例外を監視することができ、そして、もしもこうしたエラー又は例外がクリティカルな場合には、実行可能な構成要素のシャットダウン（及び随意的には再起動）を開始させることができる。
【００５７】
システムコントローラー（２０２）は、処理フレームワーク（２０２）内の実行可能な構成要素を継続的に監視し、該コントローラーがシステムシャットダウンシグナルを受け取るまでこれを続けるであろう（ブロック（３３８）に示すように）。この時点で、方法（３００）はブロック（３４０）へ移動し、ここでは、システムコントローラー（２０２）は、該コントローラーがブロック（３３２）で開始させた実行可能な構成要素を停止させる。一実施形態において、システムコントローラー（２０２）は、該コントローラーがこれらの構成要素を開始させたのとは逆の順序で構成要素を停止させるが、しかし、別の実施形態では、コントローラーは、追加の及び／又は異なる因子（例えば、各構成要素の現在の処理状態）に基づく順序で構成要素を停止させることができる。更に、ある実施形態において、システムコントローラーは、状態表示構成要素（３１１）を用いて、シャットダウン配列の状態に関する情報を、表示装置上に表示することができ、該表示装置は、処理システム（１０１）と結合している。更に言えば、シャットダウンの最中、システムコントローラーは、以下の動作を行うように構成されてもよい：各実行可能な構成要素のシャットダウン状態のログをとることであって、イベントログ構成要素（２０６）を介してログをとる、又はイベントログ構成要素が既にシャットダウンしている場合には内部のログライブラリを介してログをとること。
【００５８】
システムコントローラー（２０２）が受け持つ全ての実行可能な構成要素を該コントローラーがシャットダウンした後、方法（３００）は決定ブロック（３４２）へと移動し、ここでは、システム再起動が要求されたかどうか決定する。もしそうである場合には、方法は、ブロック（３０４）に戻り、ここでは、システムコントローラー（２０２）は、構成要素初期化及び依存性情報を受け取り、これらの情報は、初期のスタートアップ配列の最中に受け取った情報と異なってもよいし、異なっていなくてもよい。もしも、再起動が要求されていない場合、方法は、ブロック（３４４）にて終了し、ここでは処理システム（１０１）は、パワーオフとなる。
【００５９】
以下の点を理解されたい：即ち、マルチモダリティ処理システムの依存性に基づくスタートアップ配列に関する方法（３００）は、単なる例示的実施形態であり、そして、別の実施形態では、追加の及び／又は異なるステップを、前記方法の中に含めることができる。例えば、一実施形態において、構成要素、及び初期化、及び依存性の情報を、ブロック（３０４）において受け取った後、システムコントローラー（２０２）は以下のことを決定することができる：実行可能な構成要素に関連する医療感知装置が、処理システムに通信可能に接続されるかどうか；及び、こうした装置が稼働できる状態にあるかどうか。医療感知データを獲得するにあたって、実行可能な構成要素に関連する医療感知装置が利用可能な状態にない場合には、システムコントローラー（２０２）は、関連する構成要素を、ブロック（３０６）で生成された依存性マップから除外することができ、及びこうした構成要素の初期化をスキップできる。更に、ある実施形態において、ブロック（３３６）において構成要素を監視するステップは、以下の点を検出するステップを含むことができる：処理システム（１０１）に通信可能に接続された医療感知装置に関連する実行可能な構成要素が、該装置から受け取った医療感知データに応答するかどうか。こうした構成要素が応答しないことが判明した場合には、システムコントローラー（２０２）は、構成要素を停止又は再起動させることができる。更に言えば、方法（３００）は、異なるタイプの処理システムに応用することができる（例えばＭＲＩデータの収集及び処理に関連する診断用システム、又はコンピュータ支援外科（ＣＡＳ）アプリケーションで用いられるシステム）。更に、方法（３００）を応用してネットワークベースの処理フレームワークの依存性に基づくスタートアップを行うことができ、ここで、複数の遠隔配置されたコンピュータシステム間で、実行可能な構成要素を分散させる。更にいうと、図２に関連して上述したが、拡張要素（例えば、特定の手法に関する物）は、拡張コントローラーを含むことができ、該コントローラーは、該拡張要素に関連する実行可能な構成要素をコントロールする。こうした拡張コントローラーは、方法（３００）の一部を実施することができ、これら構成要素の相互依存性に基づく適切な順序で、実行可能な構成要素をスタートアップさせることができる。しかし、システムコントローラー（２０２）と違い、拡張コントローラーは、マルチモダリティ処理システム全体をスタートアップ又はシャットダウンするように動作可能とはなってないであろう。
【００６０】
例示的な実施形態について図示及び説明をしてきたが、広い範囲の改変、変更、及び置換を、上記開示において意図しており、及び幾つかの例において、本開示の幾つかの特徴は、他の特徴の対応する使用を伴うことなく採用することができる。更に、上述したように、マルチモダリティ処理システムに関連して上述した構成要素及び拡張要素は、ハードウェア、ソフトウェア、又は両者の組合せで実装できる。そして、処理システムは、任意の特定のアーキテクチャ上で稼働するように設計してもよい。例えば、システムは以下に述べるものの上で実行することができる：単一のコンピュータ、ローカル・エリア・ネットワーク、クライアント−サーバーネットワーク、ワイド・エリア・ネットワーク、インターネット、手持ちの及び他の携帯の物、並びにワイヤレスの装置及びネットワーク。以下の点を理解されたい：即ち、こうした変更は、上述したように、本開示の範囲から逸脱することなく行うことができる。従って、添付した特許請求の範囲については、幅広く且つ本開示の範囲に合致するように解釈することが適切である。
【図１】
0006310469.tif 000002
【図２】
0006310469.tif 000003
【図３】
0006310469.tif 000004
【図４】
0006310469.tif 000005
【図５】
0006310469.tif 000006