医療用インテリジェント・サーバ・アーキテクチャ
【課題】ますます増加する患者に対して拡張することができ、様々なモダリティに基づいて、サービス検出の変更および追加を容易に行えるコンピュータ支援検出のための医療用インテリジェント・サーバ・アーキテクチャを提供すること。
【解決手段】アーキテクチャは、１組の医療画像が提供されたとき、疾患を検出するためのサービスを提供できる専用サーバ・コンフィギュレーションである。アーキテクチャは、既存の医療情報システム中に統合させることができる。コンピュータ支援検出のためのアーキテクチャは、コンピュータ支援検出サービスが必要とする変化に適合可能であり、新規のまたは変更された検出サービスを含むように容易に拡張可能であり、ますます増加する患者および様々なタイプの患者画像に適合するように拡張可能である。
【解決手段】アーキテクチャは、１組の医療画像が提供されたとき、疾患を検出するためのサービスを提供できる専用サーバ・コンフィギュレーションである。アーキテクチャは、既存の医療情報システム中に統合させることができる。コンピュータ支援検出のためのアーキテクチャは、コンピュータ支援検出サービスが必要とする変化に適合可能であり、新規のまたは変更された検出サービスを含むように容易に拡張可能であり、ますます増加する患者および様々なタイプの患者画像に適合するように拡張可能である。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、医療用コンピュータ支援検出の技術に関し、より詳細には、１組の医療画像に基づくコンピュータ支援検出に関する。
【背景技術】
【０００２】
（関連出願の相互参照）
ＪａｅＪｕｎｇ Ｃｈａｎｇによる、整理番号３３５２−０１４５ＰＵＳ１の、「Ｊｏｂ Ｄｉｓｐａｔｃｈｅｒ ｆｏｒ Ｍｅｄｉｃａｌ Ｉｎｔｅｌｌｉｇｅｎｔ Ｓｅｒｖｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ（医療用インテリジェント・サーバ・アーキテクチャのためのジョブ・ディスパッチャ）」と題する関連出願が本明細書と同時に出願されており、それを参照により本明細書に組み込む。
【０００３】
病院情報システムおよび医療用検査（ｍｅｄｉｃａｌ ｌａｂｏｒａｔｏｒｙ）システムは、ますます増加する量およびタイプの医療画像を生成している。病院は、徐々に従来の臨床カルテを電子臨床カルテに置き換えてきた。病院は、病歴および処方箋歴のデータベースを追加してきている。診断を支援するための情報を提供する放射線情報システムも追加されている。最近では、ＰＡＣＳ（画像保管通信システム）が、医療画像データの記憶、検索、分配、およびプレゼンテーションに専用のコンピュータ・システムとして開発されている。ＰＡＣＳは、フィルム保管など、医療画像を管理するハード・コピーベースの手段の代替となるものである。Ｆｕｌｌ ＰＡＣＳは、超音波検査法、磁気共鳴イメージング、ＰＥＴ（陽電子放射断層撮影）、コンピュータ断層撮影、内視鏡検査法、マンモグラフィ、およびＸ線撮影法（単純Ｘ線）など、様々なモダリティからの画像を処理する。
【０００４】
現在、コンピュータ支援検出（ＣＡＤ：ｃｏｍｐｕｔｅｒ ａｉｄｅｄ ｄｅｔｅｃｔｉｏｎ）は、医師を支援する有効な手段であることが示されている。例えば、ＣＡＤは、末期の病気を持つ患者を有する医師を支援するのに有用であった。ＣＡＤ用のアルゴリズムは、ますます増加する疾患や病気のために開発され、改良されている。
【０００５】
典型的なＰＡＣＳネットワークは、画像を含むデータベースを保管する中央サーバで構成することができる。中央サーバは、ＬＡＮまたはＷＡＮ、ならびにインターネットを介してクライアントに接続することができる。クライアント・ワークステーションは、画像フィルムを走査してシステムに送るローカルの周辺装置（例えば、フィルム・デジタイザ）と、そのシステムから画像フィルムを印刷するローカルの周辺装置と、デジタル画像の対話型ディスプレイとを含むことができる。ＰＡＣＳワークステーションは、画像を操作する（切取り、回転、ズーム、輝度、コントラストなど）手段を提供する。
【０００６】
撮像装置、すなわち、モダリティの多くのタイプは、デジタル形式で患者の画像を直接、ＰＡＣＳに供給できるようになりつつある。ＮＥＭＡ規格である、ＤＩＣＯＭ（医用画像通信規格）として知られる医療画像を記憶し送信するための１組の規格が開発されてきた。ＤＩＣＯＭは、複数の製造業者からのスキャナ、サーバ、ワークステーション、プリンタ、およびネットワーク・ハードウェアの統合を可能にするように開発された。したがって、ＤＩＣＯＭは、多数のモダリティに対する共通のプラットフォームを提供する。ＤＩＣＯＭは、ファイル・フォーマット定義と、画像送信のためのネットワーク通信プロトコルの両方を含んでいる。
【０００７】
ＤＩＣＯＭのファイル・フォーマットは、ヘッダと画像データの両方を含んでいる。ヘッダは、規格化されたフィールドと、自由形式のフィールドを含むことができる。ＤＩＣＯＭファイルは、画像タイプに依存した（すなわち、モダリティに対応した）必要な要素を含んでいる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
患者の来院、または他の医療行為により、１つまたは複数の画像ファイルを提供可能なモダリティに関して取得されたデータを含むスタディ（ｓｔｕｄｙ）を得ることができる。患者が何回か来院すれば、いくつかのスタディが得られるはずである。ＰＡＣＳシステムは、通常、多くの患者に対する画像ファイルを記憶し、管理することができる。医療画像を用いて検出を実施できるＣＡＤアルゴリズムは、絶えず開発されている。しかし、診断を実施するために、患者の多数の医療画像をＣＡＤアルゴリズムに提供できるシステムが求められている。特に、進化しつつある様々なＣＡＤソフトウェアを用いて、多くの異なる潜在的な疾患に対して、数百人の患者に対する検出サービスを提供できるシステムが望ましい。長い目で見れば、このような役割を果たすシステムは、多様な数およびタイプの画像、ならびに検出サービスに対して多様な要求に適合させ、新規のまたは変更されたＣＡＤソフトウェアに対して容易に拡張され、かつますます増加する患者のスタディを処理するために拡大可能であることが必要である。
【課題を解決するための手段】
【０００９】
本発明の一態様は、ますます増加する患者に対して拡張できるコンピュータ支援検出のためのアーキテクチャであり、また様々のモダリティに基づくＣＡＤサービスの変更および追加を容易にすることである。本発明は、１組の医療画像が提供されたとき診断を決定するためのサービスを提供できるサーバ・コンフィギュレーションである。本発明は、既存の医療情報システム中に統合され得る。
【００１０】
本発明の一態様は、医療用コンピュータ支援検出システムであって、１組の医療画像ファイルをそれぞれが含む１つまたは複数のケースを受け取り、そのファイルを分配するためのディスパッチャと、プラグインＣＡＤコンポーネントを用いて、１組の医療画像ファイルに基づき医療用コンピュータ支援検出を実施する画像処理サーバとを有し、その画像処理サーバが、プラグインＣＡＤコンポーネントをディスパッチャに登録し、そのディスパッチャが、画像処理サーバおよび登録されたプラグインＣＡＤコンポーネントの作業負荷に基づき医療画像ファイルを分配する、医療用コンピュータ支援検出システムである。
【００１１】
本発明のシステムは、新規のまたは変更されたプラグインＣＡＤコンポーネントを含むように拡張することができる。本発明のシステムでは、画像処理サーバがプラグインＣＡＤコンポーネントをディスパッチャに登録する。ディスパッチャは、検出サービスを実施するために、プラグインＣＡＤコンポーネントの可用性に基づいて画像ファイルを配布する。現在利用可能なＣＡＤコンポーネントの情報に基づいて画像ファイルを配布することにより、本発明のシステムは、新規のまたは変更されたプラグインＣＡＤコンポーネントに適合するように、容易に拡張することができる。
【００１２】
本医療用コンピュータ支援検出システムの画像処理サーバの一態様は、医療画像ファイルに基づいてコンピュータ支援検出を実施するために、プラグインＣＡＤコンポーネントによる処理を呼び出すスクリプト・ファイルを実行することである。スクリプト・ファイルからＣＡＤコンポーネントを呼び出すことにより、エンド・ユーザは、その基礎となるＣＡＤコンポーネントの細部の知識なしに、またシステムの他の部分を再コンパイルする必要なしに、新規のまたは変更されたコンポーネントを容易にシステムに追加することができる。
【００１３】
本発明のシステムの一態様は、医療用コンピュータ支援検出システムの各医療画像ファイルが、患者データおよび画像データを含むヘッダを含むことである。本発明のシステムにより処理される医療画像ファイルは、別のヘッダ・ファイルを管理する必要がなく、また別のソースから、医療画像データおよび関連する患者に関する情報を取得する必要なく、検出のために使用することができる。
【００１４】
医療用コンピュータ支援検出システムの画像処理サーバの一態様は、画像処理サーバがさらに、スクリプト・ファイルが事前にコンパイルされているか、あるいは変更されているかどうかを判定し、スクリプトが変更されている場合、画像処理サーバが、スクリプトのコンパイルされたバージョンがあるかどうかを判定し、それがない場合、スクリプトをコンパイルし、コンパイルされたスクリプトを実行することである。したがって、本発明のシステムは、スクリプト・ファイルのコンパイルおよび実行を処理することができる。こうするとさらに、新規のまたは変更されたＣＡＤコンポーネントに適合するように、システムを簡単に拡張できるようになる。
【００１５】
医療用コンピュータ支援検出システムの画像処理サーバの一態様は、画像処理サーバが、画像サービス・アドミニストレータおよびスクリプト・ランナを含むことである。画像サービス・アドミニストレータは、プラグインＣＡＤコンポーネントをディスパッチャに登録し、ＣＡＤコンポーネントが登録された場合、スクリプト・ファイルの実行を管理するために別の検出サービス・プロセスを作成し、ディスパッチャから画像ファイルを受け取る。スクリプト・ファイルの実行を管理するために、別の検出サービス・プロセスを作成することにより、本発明のシステムは、検出サービスが必要とする変更に適合することができる。別のサービス・プロセスでスクリプト・ファイルの実行を管理することにより、いくつかのサービス・プロセスが、他のサービス・プロセスに影響を与えることなく、いくつかの論理プロセッサ上で同時に実行することができる。さらに、あるサービス・プロセスに障害が起きた場合、実行中の他のサービス・プロセスの実行を継続することができる。したがって、本発明は、必要に応じた変更に適合可能であり、またロバストである。
【００１６】
医療用コンピュータ支援検出システムの医療画像ファイルに含まれる医療画像データは、モダリティおよび体の部分に基づいており、またそのモダリティのタイプに基づいてコンピュータ支援検出処理を行うように、スクリプト・ファイルが選択される。したがって、モダリティのタイプおよび体の部分に対して適切な検出サービスを提供するために、スクリプト・ファイルは、モダリティに基づいて記述され得る。さらに、医療画像ファイルに基づいて検出を実施するためのＣＡＤコンポーネントの選択は、その医療画像データのモダリティに基づいて行うことができる。
【００１７】
医療用コンピュータ支援検出システムの一態様は、多数の患者および患者の画像ファイルに対して拡張できることである。特に、本発明のシステムは、複数の画像処理サーバを含むことができ、複数の画像処理サーバのうちの少なくとも１つの画像処理サーバが、始動時にそのプラグインＣＡＤコンポーネントを登録し、またディスパッチャが、ケースの画像ファイルを、現在の作業負荷に基づいて選択された画像処理サーバと、ディスパッチャに登録されたＣＡＤコンポーネントに分配する。追加される画像処理サーバにその利用可能なＣＡＤサービスを登録させることにより、本発明のシステムは、画像処理サーバを容易に追加することができる。
【００１８】
医療用コンピュータ支援検出システムの画像サービス・アドミニストレータの一態様は、それがさらに、実行される検出サービス・プロセスの待ち行列を維持し、待ち行列から取得された検出サービス・プロセスの実行を依頼（ｓｕｂｍｉｔ）した後、待ち行列中に現在ある検出プロセスの数、および実行されている検出プロセスの数に基づき、画像処理サーバの作業負荷状況の変化をディスパッチャに知らせるサービス・アソシエートを含むことができることである。画像処理サーバの作業負荷状況をディスパッチャに知らせることにより、ディスパッチャは、画像処理サーバの作業負荷状況に基づいて、医療画像ファイルを配布することができる。
【００１９】
コンピュータ支援検出のための医療用インテリジェント・サーバのさらなる態様は、プラグインＣＡＤコンポーネントがアップグレードされるか、または画像処理サーバ中に新しく追加された場合、画像処理サーバが再始動され、新しい組のＣＡＤコンポーネントをディスパッチャに登録することである。ＣＡＤコンポーネントが追加または変更されたとき、新しい１組のＣＡＤコンポーネントを登録することによって、画像処理サーバへの画像ファイルの配布が、画像処理サーバの最新の能力により保証されることになる。さらに、本発明の医療用インテリジェント・サーバは、現在利用可能なＣＡＤコンポーネントに対して容易に拡張される。
【発明を実施するための最良の形態】
【００２０】
添付の図面を参照して、本発明をさらに詳細に述べる。
【００２１】
本発明は、医師および放射線専門医が、医療診断を実施するのに利用可能な進んだアルゴリズムを使用できるようにするために使用され得る。本発明は、ガンなどの疾患を正確に検出する高度なアルゴリズムによって進んだＣＡＤを提供し、またその後に、有益な検出情報を提供する。本発明は、ＤＩＣＯＭ規格通信プロトコルを使用するので、既存の医療情報システムおよび作業フロー、ならびに新しい病院システムに適合するように設計されている。検出サービスは、大幅に遅れることなく実施される。組込みのウェブ・サーバは、いつでもシステム・アクセスおよびレポート生成を可能にする。
【００２２】
特に、本発明は、ますます増加する患者および患者の画像に対して、様々なＣＡＤアルゴリズムを適用することを容易にし、新規のまた変更されたＣＡＤサービスに適合するように容易に拡張することができる。患者ケースを同時に接続する数、およびその患者ケースの接続に対して要求されるサービスを処理するために追加されるサーバの数に対する拡張可能なアーキテクチャにより、大容量の処理を容易に行うことができる。新規のまた変更されたＣＡＤサービスへの拡張は、スクリプトおよびプラグインのサービス・コンポーネントにより容易に行うことが可能となる。本発明は、検出サービスに対する要求の多様化に対して動的に適合可能である。
用語および頭字語の定義
以下の定義は、本実施の形態を通して使用される用語に対して提供される。
【００２３】
関連（ａｓｓｏｃｉａｔｉｏｎ）（ＤＩＣＯＭプロトコル）：ＤＩＣＯＭ情報がそれにより交換される２つのＤＩＣＯＭアプリケーション相互間で確立される通信接続。関連に先行して接続が開始される。関連は、関連の折衝（ｎｅｇｏｔｉａｔｉｏｎ）と呼ばれるプロセスにより確立される。
【００２４】
グラフィカル・ユーザ・インターフェース（ＧＵＩ）：コンピュータのグラフィックス機能を利用して、プログラムを使いやすくするプログラム・インターフェース。ＧＵＩの代替と考えられるコンピュータ・プログラムへのユーザ・インターフェースは、コマンド駆動型インターフェースである。現在のＧＵＩは、ポインタおよび関連するポインティング・デバイスを有し、ユーザに、ディスプレイ画面上のグラフィカル・オブジェクトを選択できるようにする。ＧＵＩは、アイコン、メニュー、スクロール・バーなどの機能コンポーネントを表示することができ、コマンドを活動化させ、または表示を操作するなどの機能を有効にする。
【００２５】
メッセージ：動作しているプログラム、デバイス中を、またはオペレーティング環境内を通る情報の単位。情報の単位は、１つまたは複数のテキスト・ブロック、制御キャラクタ、ヘッダ、ならびに誤り検査もしくは同期化情報を含むことができる。
【００２６】
モジュール：関連するアプリケーション・プログラムおよびサービス・アプリケーションの集合体。
【００２７】
サーバ：資源を管理し、ネットワーク中の他のコンピュータにより使用され得るサービス・アプリケーションを送達する、ネットワーク上のコンピュータまたはデバイス。
【００２８】
スタディ（Ｓｔｕｄｙ）（ＤＩＣＯＭ、ケース（ｃａｓｅ）も同様）：病院、診療所での受診中、または他の医療行為中に生成された画像モダリティの１組の画像に対するＤＩＣＯＭ用語。
【００２９】
タスク（プロセスも同様）：実行されるプログラムと、オペレーティング・システムにより使用されるブックキーピング（ｂｏｏｋｋｅｅｐｉｎｇ）情報との組合せ。プログラムがコンピュータにより実行されるとき、オペレーティング・システムは、そのために新しいタスクを作成する。そのタスクはプログラムのためのラッパーを構成し、タスク番号でプログラムを識別し、他のブックキーピング情報をそれに添付する。
【００３０】
トランスファ・シンタックス（Ｔｒａｎｓｆｅｒ Ｓｙｎｔａｘ）（ＤＩＣＯＭ ＰＳ．３．５ ２００４より）：アプリケーション・エンティティが、サポート可能な符号化技法（例えば、データ・エレメント構造、バイト順、圧縮）と曖昧さのない折衝を可能にする１組の符号化規則であり、それにより、これらのアプリケーション・エンティティが通信できるようになる。
【００３１】
Ｗｉｎｄｏｗｓサービス（Ｍｉｃｒｏｓｏｆｔ）：それ自体のＷｉｎｄｏｗｓセッション中に長期間動作するように設計された高度に特殊化されたタイプのアプリケーション。Ｗｉｎｄｏｗｓサービスは、ローカルに、またはネットワーク中で、普通はユーザ・インターフェースなしにバックグラウンド・プロセスとして通常動作する。例えば、大部分のサーバ・ベースのアプリケーションはサービスである。Ｗｉｎｄｏｗｓサービスは、Ｍｉｃｒｏｓｏｆｔ管理コンソールから開始することができる。
【００３２】
モダリティ：Ｃ−ＳＴＯＲＥ要求（他のシステムにデジタル画像を記憶させるための要求）を送る、ＣＴ、ＭＲ、ＣＲ、超音波、および核医学システム、または撮像デバイスおよび装置。モダリティは関連する画像モダリティを有する。
【００３３】
モダリティの例
ＡＳ＝血管内視鏡
ＢＩ＝生体磁気イメージング
ＣＤ＝カラードップラ法
ＣＰ＝コルポスコピー
ＣＲ＝コンピュータＸ線撮影
ＣＳ＝膀胱鏡検査
ＣＴ＝コンピュータ断層撮影
ＤＤ＝デュプレックス・ドップラ
ＤＧ＝透光法
ＤＭ＝デジタル顕微鏡検査
ＤＳ＝減算血管撮影
ＤＸ＝デジタル・ラジオグラフィ
ＥＣ＝心臓超音波検査法
ＥＳ＝内視鏡検査法
ＦＡ＝蛍光血管造影法
ＦＳ＝眼底検査
ＨＣ＝ハード・コピー
ＬＰ＝腹腔鏡検査法
ＬＳ＝レーザ表面走査
ＭＡ＝磁気共鳴血管造影法
ＭＲ＝磁気共鳴
ＭＳ＝磁気共鳴分光検査法
ＮＭ＝核医学
ＰＴ＝ＰＥＴ（陽電子放出断層撮影法）
ＲＦ＝放射線蛍光透視法
ＲＧ＝Ｘ線写真イメージング（従来のフィルム画面）
ＲＴＤＯＳＥ＝治療用放射線量
ＲＴＩＭＡＧＥ＝放射線療法画像
ＲＴＰＬＡＮ＝放射線療法計画
ＲＴＳＴＲＵＣＴ＝放射線療法構造セット
ＳＴ＝単一光子放出型コンピュータ断層撮影法
ＴＧ＝温度記録法
ＵＳ＝超音波
ＸＡ＝Ｘ線血管造影法
ＸＣ＝外部カメラ
ＥＣＧ＝心電図
ＣＡＤ（コンピュータ支援検出）：疾患または病気を示す可能性のある、医療画像中の部位を検出するように設計された、例えば、パターン認識アルゴリズムなどのアルゴリズム。
【００３４】
ＤＩＣＯＭ：（医用画像通信規格）。医療撮像における情報を処理し、記憶し、印刷し、送信するための包括的な１組の規格である。それは、ファイル・フォーマット定義およびネットワーク通信プロトコルを含む。上記プロトコルは、システム間で通信を行うためにＴＣＰ／ＩＰを使用する。ＤＩＣＯＭファイルは、ＤＩＣＯＭフォーマットで、情報、すなわち、画像と患者データを受け取る機能を有する２つのエンティティ間で交換することができる。ｄｉｃｏｍ．ｎｅｍａ．ｏｒｇを参照のこと。
【００３５】
ＰＡＣＳ：（画像保管通信システム）。市販のＰＡＣＳは、入力モダリティ、ＤＩＣＯＭサーバ、ＰＡＣＳサーバ、アーカイブ・サーバ、ウェブ・サーバ、ＲＩＳ（放射線情報サーバ）、および放射線クライアントを含むアーキテクチャを提供する。
【００３６】
ＳＯＡＰ：（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）。
【００３７】
本発明の医療用画像インテリジェント・サーバ（ＭＩＩＳ）の概念図が図１に示されている。図１に示すように、ＭＩＩＳは、ジョブ・ディスパッチャ２０、コンソール４０、および１つまたは複数の画像処理サーバ３０（簡単のために１つだけを示す）から構成される。ジョブ・ディスパッチャは、１つまたは複数のＤＩＣＯＭデバイス１０との接続を確立することができる。ＤＩＣＯＭデバイスは、スキャナ、ワークステーション、プリンタ、およびネットワーク・ハードウェアなど、任意のＤＩＣＯＭ準拠デバイスを含む。
【００３８】
大規模な病院システムに対するスループット要件は、単一のサーバが提供できる能力をはるかに超える。ＭＩＩＳは、画像処理サーバをさらに追加できる能力を提供し、適切な性能を達成するように、その作業負荷を調整する。ＭＩＩＳは、画像処理サーバの情報を登録し、登録された情報に基づいて画像を配布するジョブ・ディスパッチャを介して拡張容易性（ｓｃａｌａｂｉｌｉｔｙ）を達成し、また新規のまたは変更されたＣＡＤサービスに対して動的にスクリプトを適合させる画像処理サーバを介して拡張性を達成する。ジョブ・ディスパッチャは、ＤＩＣＯＭデバイスからの要求を検出し、スタディ用の画像を受け取り、適切な画像処理サーバに画像を配布する。ジョブ・ディスパッチャは、ますます増加する新しいサービス、ならびに既存のサービスの変更を有する環境中で負荷バランスをとるために登録サービスを使用する。
【００３９】
本発明は、ＭＩＩＳのバックエンドとしての画像処理サーバの諸態様を開示する。ジョブ・ディスパッチャの詳細は、関連出願（整理番号３３５２−０１４５ＰＵＳ１）に開示されており、上記で述べたように、それを参照により本明細書に組み込む。
【００４０】
図２は、画像処理サーバの作業フロー図を示す。ジョブ・ディスパッチャは、多数の画像処理サーバ中で作業負荷を平衡させることができる。図２で分かるように、ジョブ・ディスパッチャは、スタディ・ハンドラ２２および登録サービス２３を含む。画像処理サーバは、登録サービス２３に登録（「Ｒｅｇｉｓｔｅｒ」）することができる。登録サービス２３は、画像処理サーバ３０のステータス情報を記憶し、管理する。ステータス情報は、画像処理サーバが提供できるＣＡＤサービスのリスト、画像処理サーバによるサービス要求に必要なプロセスおよびプロトコル、ならびに画像処理サーバの位置（例えば、ローカル・マシン、またはＩＰアドレス）を含んでいる。
【００４１】
画像処理サーバは、サービス・グループのメンバーであり得る前に、登録サービスに登録される必要がある。ジョブ・ディスパッチャは、ＣＡＤサービスを実施するために、画像処理サーバに画像を配布（「ＣａｒｒｙＯｕｔＳｅｒｖｉｃｅ」）できるように登録情報を検索することになる。登録情報は、システム・コンフィギュレーションが変わる場合、例えば、画像処理サーバを追加／除去し、あるいはＣＡＤサービスを追加／アップグレードする場合、更新される必要がある。
【００４２】
画像処理サーバ３０は、ＭＩＩＳのＣＡＤサービスを提供する。図２に示すように、画像処理サーバ３０は、画像サービス・アドミニストレータ３１、スクリプト・ランナ３２および１つまたは複数のプラグインＣＡＤコンポーネント５４を含んでいる。スクリプト・ソフトウェア・プログラムは、１つまたは複数のＣＡＤ画像処理コンポーネントを一緒に組み合わせて、ＤＩＣＯＭ画像に基づく診断を行う。ＣＡＤ画像処理コンポーネントは、スクリプト・エディタにより呼び出すことのできるメソッドを公開（ｅｘｐｏｓｅ）するＣＡＤプラグイン・コンポーネント中にラップされる。スクリプトは、プロジェクト単位で実行される。プロジェクトは、参照アセンブリおよびそのプロジェクト中のスクリプト・ファイルのリストを記述するファイルである。結果を分析し、レポートの様々なフォーマットを生成できるプラグイン・コンポーネントが存在する。フォーマットの中で、プラグイン・コンポーネントは、ＤＩＣＯＭをサポートし、かつＤＩＣＯＭ画像を結果と共に指定された位置に送ることができる。例示的なスクリプトは、［プログラムコード］のAPPENDIX 1に含まれる。
【００４３】
画像サービス・アドミニストレータ３１は、画像サービス・オブジェクト５１、サービス・アソシエート５２、およびサービス・ドゥーア（Ｄｏｅｒ）５３を含む。画像サービス・オブジェクト５１は、スタディ・ハンドラ２２から配布された画像を受け取るためのメソッドを提供する。画像サービス・オブジェクト５１のインスタンスは、画像サービス・アドミニストレータ３１により、要求に応じてインスタンス生成される（ｉｎｓｔａｎｔｉａｔｅｄ）。スタディ・ハンドラ２２から受け取られた画像は、サービス・アソシエート５２によって管理される待ち行列中に配置される。
【００４４】
サービス・アソシエート５２は、優先順位および画像が受け取られた時間により（先着順）整列されるサービス・ドゥーア待ち行列を維持する。サービス・アソシエート５２は、新しいケースの到来、ＣＡＤサービスの完了、およびサーバのシャット・ダウンなどのイベントをトリガする手続きを処理する。サービス・ドゥーア５３は、画像データを取得し、ＣＡＤ画像処理を実施するために子プロセスを開始する。
【００４５】
図３は、画像サービス・アドミニストレータ３１に対するクラス図を示す。画像サービス・アドミニストレータ３１は、画像サーバ・アドミニストレータ・クラス、画像サービス・オブジェクト・クラス、サービス・アソシエート・クラス、およびサービス・ドゥーア・クラスを含む。各クラスは、インスタンスが生成された各オブジェクトが実施できる例示的なメソッドと共に示されている。例示的な実施形態では、画像サービス・アドミニストレータ３１は、連続的に動作するＷｉｎｄｏｗｓサービスである。画像サービス・アドミニストレータ・クラスは、「ＯｎＳｔａｒｔ」メソッドを含み、それは、呼び出されたとき、コンフィギュレーション設定を読み取り、それに従って、サービス・アソシエートを構成し、画像サービス・オブジェクト５１をロードし、「ＲｅｇｉｓｔｅｒＳｅｒｖｉｃｅ」メソッドをコールして画像処理サーバおよびそれが処理できるサービスを登録し、またサービスが開始したことをサービス・アソシエートに通知する。「ＲｅｇｉｓｔｅｒＳｅｒｖｉｃｅ」メソッドは、すべての画像処理コンポーネントを検索し、画像処理サーバが提供できる、または現在実行中のサービスの要約表を生成し、遠隔の登録サービス２３にサービスの表を転送するための機能を呼び出す。サービスの表にある各サービスは、ストリング「Ｍｏｄａｌｉｔｙ／Ｂｏｄｙｐａｒｔ」により表されることが好ましい。サービスは、例えば、ＣＲ／ＢＲＥＡＳＴ、ＭＧ／ＢＲＥＡＳＴ、ＣＲ／ＣＨＥＳＴなどとして表すこともできる。サービスの表中で表されるサービスは、ハッシュ・テーブルに記憶されることが好ましい（図４を参照）。画像サービス・アドミニストレータ３１はまた、メソッド「ＯｎＳｔｏｐ」および「ＵｎＲｅｇｉｓｔｅｒＳｅｒｖｉｃｅ」を実施することもできる。「ＯｎＳｔｏｐ」は、画像処理サーバ３１のサービスが停止したとき、登録サービスから登録を抹消するための「ＵｎＲｅｇｉｓｔｅｒＳｅｒｖｉｃｅ」機能を含む機能を実施する。「Ｒｅｇｉｓｔｒａｔｉｏｎ Ｓｅｒｖｉｃｅ」メソッドはまた、プラグイン・コンポーネントが追加されたとき、または変更されたときに実施される。画像処理サーバの再登録は、画像処理サーバを一時停止するか停止させることにより、コンフィギュレーションをアップグレードすることにより、画像処理サーバを始動することにより、またプラグイン・コンポーネントの新しい組を登録することにより行われ得る。
【００４６】
画像サービス・オブジェクト・クラスは、画像を送るためにスタディ・ハンドラにより呼び出され得るメソッド「ＣａｒｒｙＯｕｔＳｅｒｖｉｃｅ」を含む。パラメータは、「Ｓｅｒｖｉｃｅ Ｎａｍｅ（サービス名）」と、ＤＩＣＯＭヘッダ、および要求が優先順であるかどうかを示すフラグを含む画像データとを含む。「ＣａｒｒｙＯｕｔＳｅｒｖｉｃｅ」は、受け取られたデータをサービス・ドゥーア・オブジェクトのインスタンス中に入れることを担当し、サービス・ドゥーア・オブジェクトをサービス・アソシエート中の待ち行列中に挿入し、イベントを生成するために「Ｃａｌｌ Ｓｅｒｖｉｃｅ Ａｓｓｏｃｉａｔｅ」メソッドを呼び出し、新しい要求が到来したことをサービス・アソシエートに通知する。
【００４７】
サービス・アソシエート５２は、要求を保持する待ち行列を維持する。それは、要求の待ち行列を作り、イベントを生成するために呼び出すことのできるメソッドを含む。それはまた、生成されたイベントを処理するためのメソッドも提供する。特に、サービス・アソシエートは、待ち行列イベントの処理を委譲する「ＨａｎｄｌｅＱｕｅｕｅＥｖｅｎｔ」メソッドを含む。メソッド「ＱｕｅｕｅＵｐＲｅｑ」は、パラメータとして、サービス・ドゥーアのインスタンスおよびその優先順位を取り、サービス・ドゥーア・オブジェクトを待ち行列中に挿入する。メソッドは、先着順ベースで呼び出される。しかし、あるオブジェクトが優先に設定された場合、待ち行列の先頭部分に挿入されることになる。メソッド「Ｒａｉｓｅ」が、待ち行列イベントを生成するのに呼び出され得る。上記で述べた「ＨａｎｄｌｅＱｕｅｕｅＥｖｅｎｔ」は、入力として２つのパラメータをとる。すなわち、イベントを送るオブジェクトであるＳｅｎｄｅｒ（送信側）と、生成されたイベントのタイプＱｕｅｕｅＥｖｅｎｔＡｒｇである。
【００４８】
待ち行列イベント処理は、生成されたイベントのタイプに基づく。例示のイベント・タイプは、新しい要求が到来したこと、スタディ用の画像処理が完了したこと、タスクの実行に失敗したこと、画像サービス・アドミニストレータが始動、またはシャット・ダウンしたことを含んでいる。サービス・アソシエートは、同時に画像処理を開始することを特定の数の子プロセスに許可する。この特定の数の値は、画像サービス・アドミニストレータのコンフィギュレーション・ファイルで指示される。それは、マシン中で利用可能な論理プロセッサの数に自動的に設定することができる。タスクまたは新しい要求の到来に関係するイベントおいて、サービス・アソシエートは、現在動作している子プロセスの数を調べる。現在動作している子プロセスの数が、事前設定の閾値よりも低い場合、待ち行列中の次のサービス・ドゥーア・オブジェクトが実行のために取り出され、その他の場合、そのイベントは無視される。サービス・ドゥーア・オブジェクトが、タスクを実行するために取り出され場合、性能を高めるために、サービス・アソシエートは、別の子プロセスを開始し、「ＤｏＳｅｒｖｉｃｅ」をその子プロセスで動作させる。画像サービス・アドミニストレータがシャット・ダウンされたとき、シャット・ダウン・イベントが開始され、サービス・アソシエートが、子プロセスの動作を停止させて、未終了のタスクをすべてハード・ドライブに書き込む。画像サービス・アドミニストレータが始動されたとき、始動イベントが開始され、ハード・ドライブに書き込まれたすべてのタスクが再度ロードされ、実行されることになる。
【００４９】
呼び出すことのできるサービス・アソシエートの他のメソッドは、「ＳｃｒｉｐｔＲｕｎｎｅｒＥｘｉｔ」、「ＩｎｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、「ＤｅｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、「ＧｅｔＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、および「ＵｐｄａｔｅＳｅｒｖｅｒＳｔａｔｅ」を含んでいる。「ＳｃｒｉｐｔＲｕｎｎｅｒＥｘｉｔ」メソッドが、受け取られたイベントにより呼び出された場合、サービス・アソシエートは、ｔａｓｋ ｄｏｎｅイベントを生成し、待ち行列イベント・ハンドラにそのイベントの処理を引き継ぐようにさせる。「ＩｎｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、「ＤｅｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、および「ＧｅｔＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」は、現在動作している子プロセスの数のカウントを維持する。「ＵｐｄａｔｅＳｅｒｖｅｒＳｔａｔｅ」は、画像処理サーバのステータスの変化情報を登録サービスに提供するためのメソッドである。ステータス情報は、開始された子プロセスの数、および待ち行列中のタスクの数を含むことができる。メソッドは、新しい要求処理イベントが生じたときにコールされ、または関数「ＩｎｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、または「ＤｅｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」の内部からコールされ得る。
【００５０】
上記で述べたように、サービス・ドゥーア・オブジェクトは、受け取られたデータおよび画像のホルダであり、待ち行列上の単位として記憶される。サービス・ドゥーア・オブジェクトは、メソッド「ＤｏＳｅｒｖｉｃｅ」を含んでいる。「ＤｏＳｅｒｖｉｃｅ」メソッドを呼び出すことにより、ＣＡＤ画像処理を実行する別の子プロセスが作成される。本発明の発明者は、最大数の画像ファイルに対して同時に適合できるアーキテクチャを用いたとき、より高いスループットが達成できると判断した。したがって、「ＤｏＳｅｒｖｉｃｅ」メソッドは、より多くの画像ファイルが処理できるように、別のプロセスで動作する。さらに、別のプロセスとして動作させることによって、プロセスの障害は、他の子プロセス、ならびに親の画像処理サーバに影響を与えないことになる。
【００５１】
サービス・ドゥーアはまた、サービス・ドゥーア・オブジェクト中に記憶されたスタディの特性をリストする表を返す（ｒｅｔｕｒｎ）ためのメソッドを提供する。特に、メソッド「ＧｅｔＪｏｂＰｒｏｐｓ」は、待ち行列中のまたはプロセス中のケースに関する情報を検索するためにコンソールにより呼び出すことができる。検索され得る特性の好ましいリストは、次のものを含む。
【００５２】
患者ＩＤ
患者名
患者の性別
受入れ番号（Ａｃｃｅｓｓｉｏｎ Ｎｕｍｂｅｒ）
スタディのモダリティ
スタディの記述
スタディの日付
スタディの時間
委託医師の名前
スクリプト・ランナ３２は、メソッド「ＤｏＳｅｒｖｉｃｅ」でサービス・ドゥーアにより呼び出されるアプリケーションである。スクリプト・ランナ３２は、コンパイルし、アセンブリをセーブし、指定されたスクリプト・ファイルの実行を担当する。スクリプト・ファイルは、ＣＡＤコンポーネントおよび他のプラグイン・コンポーネントにコールすることができる。
【００５３】
図５は、サービス・ドゥーア・オブジェクトのフローチャートを示す。サービス・ドゥーア・オブジェクトの子プロセスは、要求された検出サービスを実施するためのスクリプトを取得するために作成され呼び出される。子プロセスは、画像サービス・アドミニストレータのコンフィギュレーションから、スクリプトまたは対応する実行可能ファイルを検索する（ステップＳ−５１）。所望のスクリプトまたは実行可能ファイルが見つからない場合（ステップＳ−５２の「Ｎｏ」）、結果を得ることなくプロセスは終了したというメッセージが、サービス・アソシエートに送られる。所望のスクリプトが見出された場合（ステップＳ−５２の「Ｙｅｓ」）、２つのアクションのうちの一方が、モジュール・タイプに基づいて行われることになる（ステップＳ−５３）。モジュールが、実行可能ファイルである場合、その実行可能ファイルは、子プロセスで実行される（ステップＳ−５７）。モジュールがスクリプトである場合、そのスクリプトが変更されているかどうかについて検査が行われる（ステップＳ−５４）。スクリプトが変更されていない場合（Ｓ−５４の「Ｎｏ」）、前に記憶された可能性のある対応する実行可能ファイルを突き止めるための検査が行われる（ステップＳ−５８）。発見された場合、その実行可能ファイルは子プロセス中で実行される。スクリプトが変更されている場合、スクリプト・ランナが開始されてスクリプトをコンパイルする（ステップＳ−５５）。コンパイルされたスクリプトは、続いて実行される。プロセスが完了したとき、他のスクリプトの処理を可能にするために、メッセージがサービス・アソシエートに送られる。
【００５４】
プラグインＣＡＤコンポーネントは、どのオブジェクトを、またどのメソッドを呼び出すかを指示することにより、スクリプトによって使用される。したがって、プラグイン・コンポーネントは、サーバ・オブジェクトの挙動を変更するために、サーバ・モジュール全体を再コンパイルすることなく変更することができる。さらに、スクリプト・ファイルは、プラグイン・コンポーネントの実装形態の細部の知識なしに、また時間が経過してプラグイン・コンポーネントが改訂されたとき、大規模なメンテナンスをすることなく、エンド・ユーザが容易に準備することができる。スクリプトの使用により、ＭＩＩＳは、大幅な拡張性を実現する。
【００５５】
図６は、画像処理サーバにおける典型的なセッション中に行われ得る諸ステップを示す。画像処理システムは、まず、ジョブ・ディスパッチャの登録サービスに登録する必要がある。画像サービス・アドミニストレータ３１が始動され、そのコンフィギュレーション・ファイルをロードする。画像サービス・アドミニストレータ３１は、画像処理サーバが提供できる利用可能な画像処理コンポーネントをすべて検討し、そのコンポーネントをサービス表に要約する。
【００５６】
コンポーネントのリストが、登録プロセスを実行する登録サービスに送られる（Ｒｅｇｉｓｔｅｒ、ステップＳ−６１）。
【００５７】
スタディ・ハンドラが画像を受け取ると、画像サービス・オブジェクト５１のインスタンスを呼び出し、「ＣａｒｒｙＯｕｔＳｅｒｖｉｃｅ」メソッドをコールしてその画像を送る（ＣａｒｒｙＯｕｔＳｅｒｖｉｃｅ、ステップＳ−６２）。
【００５８】
画像サービス・オブジェクト５１は、サービス・ドゥーア・オブジェクト５３を作成し、サービス・アソシエート５２のメソッド「ＱｕｅｕｅＵｐＲｅｑ」をコールする（ＱｕｅｕｅＵｐＲｅｑ、ステップＳ−６３）。サービス・ドゥーア・オブジェクトは、サービス・アソシエートによって維持される待ち行列中に配置される。
【００５９】
画像サービス・オブジェクト５１は、イベントを生成して、新しい要求が到来したことをサービス・アソシエート５２に通知する（Ｒａｉｓｅ Ｅｖｅｎｔ、ステップＳ−６４）。サービス・アソシエートは、待ち行列からサービス・ドゥーアを取り出し、ＤｏＳｅｒｖｉｃｅメソッドをコールして、別のプロセスとしてサービスを実施する（ＤｏＳｅｒｖｉｃｅ、Ｓ−６５）。
【００６０】
サービス・ドゥーア５３は、子プロセスを開始してサービスを実施する。サービス・ドゥーアは、サービスを２つの方法の一方で実施する。スクリプト・ファイルが変更されているか、または実行可能ファイルが利用可能ではない場合（Ｓｔａｒｔ、ステップＳ−６６）、スクリプト・ランナ３２がスクリプトをコンパイルし（Ｃｏｍｐｉｌｅ、ステップＳ−６７）動作させる。コンパイルされたスクリプトは、同じスクリプトを将来使用するために実行可能ファイルにセーブされる。実行可能ファイルが存在する場合、子プロセスが開始されてその実行可能ファイルを動作させる（Ｅｘｅｃｕｔｅ、ステップＳ−６８）。実行可能ファイルは、プラグイン・コンポーネント中のメソッドをコールすることにより動作する（Ｆｕｎｃ、ステップＳ−６９）。サービスが完了すると、子プロセスはイベントを生成して、サービス・アソシエートに、待ち行列中に記憶された次の要求を処理するように通知する（ステップＳ−７０）。
【００６１】
【表１】
【図面の簡単な説明】
【００６２】
【図１】医療用画像インテリジェント・サーバ（ＭＩＩＳ）およびインターフェースのブロック図である。
【図２】画像処理サーバの作業フローの図である。
【図３】画像サービス・アドミニストレータのためのクラス図である。
【図４】画像処理サーバで提供されるサービスの表のフォーマットを示す図である。
【図５】サービス・ドゥーアのフローチャートである。
【図６】画像処理サーバの例示的なオペレーションのためのフローチャートである。
【技術分野】
【０００１】
本発明は、医療用コンピュータ支援検出の技術に関し、より詳細には、１組の医療画像に基づくコンピュータ支援検出に関する。
【背景技術】
【０００２】
（関連出願の相互参照）
ＪａｅＪｕｎｇ Ｃｈａｎｇによる、整理番号３３５２−０１４５ＰＵＳ１の、「Ｊｏｂ Ｄｉｓｐａｔｃｈｅｒ ｆｏｒ Ｍｅｄｉｃａｌ Ｉｎｔｅｌｌｉｇｅｎｔ Ｓｅｒｖｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ（医療用インテリジェント・サーバ・アーキテクチャのためのジョブ・ディスパッチャ）」と題する関連出願が本明細書と同時に出願されており、それを参照により本明細書に組み込む。
【０００３】
病院情報システムおよび医療用検査（ｍｅｄｉｃａｌ ｌａｂｏｒａｔｏｒｙ）システムは、ますます増加する量およびタイプの医療画像を生成している。病院は、徐々に従来の臨床カルテを電子臨床カルテに置き換えてきた。病院は、病歴および処方箋歴のデータベースを追加してきている。診断を支援するための情報を提供する放射線情報システムも追加されている。最近では、ＰＡＣＳ（画像保管通信システム）が、医療画像データの記憶、検索、分配、およびプレゼンテーションに専用のコンピュータ・システムとして開発されている。ＰＡＣＳは、フィルム保管など、医療画像を管理するハード・コピーベースの手段の代替となるものである。Ｆｕｌｌ ＰＡＣＳは、超音波検査法、磁気共鳴イメージング、ＰＥＴ（陽電子放射断層撮影）、コンピュータ断層撮影、内視鏡検査法、マンモグラフィ、およびＸ線撮影法（単純Ｘ線）など、様々なモダリティからの画像を処理する。
【０００４】
現在、コンピュータ支援検出（ＣＡＤ：ｃｏｍｐｕｔｅｒ ａｉｄｅｄ ｄｅｔｅｃｔｉｏｎ）は、医師を支援する有効な手段であることが示されている。例えば、ＣＡＤは、末期の病気を持つ患者を有する医師を支援するのに有用であった。ＣＡＤ用のアルゴリズムは、ますます増加する疾患や病気のために開発され、改良されている。
【０００５】
典型的なＰＡＣＳネットワークは、画像を含むデータベースを保管する中央サーバで構成することができる。中央サーバは、ＬＡＮまたはＷＡＮ、ならびにインターネットを介してクライアントに接続することができる。クライアント・ワークステーションは、画像フィルムを走査してシステムに送るローカルの周辺装置（例えば、フィルム・デジタイザ）と、そのシステムから画像フィルムを印刷するローカルの周辺装置と、デジタル画像の対話型ディスプレイとを含むことができる。ＰＡＣＳワークステーションは、画像を操作する（切取り、回転、ズーム、輝度、コントラストなど）手段を提供する。
【０００６】
撮像装置、すなわち、モダリティの多くのタイプは、デジタル形式で患者の画像を直接、ＰＡＣＳに供給できるようになりつつある。ＮＥＭＡ規格である、ＤＩＣＯＭ（医用画像通信規格）として知られる医療画像を記憶し送信するための１組の規格が開発されてきた。ＤＩＣＯＭは、複数の製造業者からのスキャナ、サーバ、ワークステーション、プリンタ、およびネットワーク・ハードウェアの統合を可能にするように開発された。したがって、ＤＩＣＯＭは、多数のモダリティに対する共通のプラットフォームを提供する。ＤＩＣＯＭは、ファイル・フォーマット定義と、画像送信のためのネットワーク通信プロトコルの両方を含んでいる。
【０００７】
ＤＩＣＯＭのファイル・フォーマットは、ヘッダと画像データの両方を含んでいる。ヘッダは、規格化されたフィールドと、自由形式のフィールドを含むことができる。ＤＩＣＯＭファイルは、画像タイプに依存した（すなわち、モダリティに対応した）必要な要素を含んでいる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
患者の来院、または他の医療行為により、１つまたは複数の画像ファイルを提供可能なモダリティに関して取得されたデータを含むスタディ（ｓｔｕｄｙ）を得ることができる。患者が何回か来院すれば、いくつかのスタディが得られるはずである。ＰＡＣＳシステムは、通常、多くの患者に対する画像ファイルを記憶し、管理することができる。医療画像を用いて検出を実施できるＣＡＤアルゴリズムは、絶えず開発されている。しかし、診断を実施するために、患者の多数の医療画像をＣＡＤアルゴリズムに提供できるシステムが求められている。特に、進化しつつある様々なＣＡＤソフトウェアを用いて、多くの異なる潜在的な疾患に対して、数百人の患者に対する検出サービスを提供できるシステムが望ましい。長い目で見れば、このような役割を果たすシステムは、多様な数およびタイプの画像、ならびに検出サービスに対して多様な要求に適合させ、新規のまたは変更されたＣＡＤソフトウェアに対して容易に拡張され、かつますます増加する患者のスタディを処理するために拡大可能であることが必要である。
【課題を解決するための手段】
【０００９】
本発明の一態様は、ますます増加する患者に対して拡張できるコンピュータ支援検出のためのアーキテクチャであり、また様々のモダリティに基づくＣＡＤサービスの変更および追加を容易にすることである。本発明は、１組の医療画像が提供されたとき診断を決定するためのサービスを提供できるサーバ・コンフィギュレーションである。本発明は、既存の医療情報システム中に統合され得る。
【００１０】
本発明の一態様は、医療用コンピュータ支援検出システムであって、１組の医療画像ファイルをそれぞれが含む１つまたは複数のケースを受け取り、そのファイルを分配するためのディスパッチャと、プラグインＣＡＤコンポーネントを用いて、１組の医療画像ファイルに基づき医療用コンピュータ支援検出を実施する画像処理サーバとを有し、その画像処理サーバが、プラグインＣＡＤコンポーネントをディスパッチャに登録し、そのディスパッチャが、画像処理サーバおよび登録されたプラグインＣＡＤコンポーネントの作業負荷に基づき医療画像ファイルを分配する、医療用コンピュータ支援検出システムである。
【００１１】
本発明のシステムは、新規のまたは変更されたプラグインＣＡＤコンポーネントを含むように拡張することができる。本発明のシステムでは、画像処理サーバがプラグインＣＡＤコンポーネントをディスパッチャに登録する。ディスパッチャは、検出サービスを実施するために、プラグインＣＡＤコンポーネントの可用性に基づいて画像ファイルを配布する。現在利用可能なＣＡＤコンポーネントの情報に基づいて画像ファイルを配布することにより、本発明のシステムは、新規のまたは変更されたプラグインＣＡＤコンポーネントに適合するように、容易に拡張することができる。
【００１２】
本医療用コンピュータ支援検出システムの画像処理サーバの一態様は、医療画像ファイルに基づいてコンピュータ支援検出を実施するために、プラグインＣＡＤコンポーネントによる処理を呼び出すスクリプト・ファイルを実行することである。スクリプト・ファイルからＣＡＤコンポーネントを呼び出すことにより、エンド・ユーザは、その基礎となるＣＡＤコンポーネントの細部の知識なしに、またシステムの他の部分を再コンパイルする必要なしに、新規のまたは変更されたコンポーネントを容易にシステムに追加することができる。
【００１３】
本発明のシステムの一態様は、医療用コンピュータ支援検出システムの各医療画像ファイルが、患者データおよび画像データを含むヘッダを含むことである。本発明のシステムにより処理される医療画像ファイルは、別のヘッダ・ファイルを管理する必要がなく、また別のソースから、医療画像データおよび関連する患者に関する情報を取得する必要なく、検出のために使用することができる。
【００１４】
医療用コンピュータ支援検出システムの画像処理サーバの一態様は、画像処理サーバがさらに、スクリプト・ファイルが事前にコンパイルされているか、あるいは変更されているかどうかを判定し、スクリプトが変更されている場合、画像処理サーバが、スクリプトのコンパイルされたバージョンがあるかどうかを判定し、それがない場合、スクリプトをコンパイルし、コンパイルされたスクリプトを実行することである。したがって、本発明のシステムは、スクリプト・ファイルのコンパイルおよび実行を処理することができる。こうするとさらに、新規のまたは変更されたＣＡＤコンポーネントに適合するように、システムを簡単に拡張できるようになる。
【００１５】
医療用コンピュータ支援検出システムの画像処理サーバの一態様は、画像処理サーバが、画像サービス・アドミニストレータおよびスクリプト・ランナを含むことである。画像サービス・アドミニストレータは、プラグインＣＡＤコンポーネントをディスパッチャに登録し、ＣＡＤコンポーネントが登録された場合、スクリプト・ファイルの実行を管理するために別の検出サービス・プロセスを作成し、ディスパッチャから画像ファイルを受け取る。スクリプト・ファイルの実行を管理するために、別の検出サービス・プロセスを作成することにより、本発明のシステムは、検出サービスが必要とする変更に適合することができる。別のサービス・プロセスでスクリプト・ファイルの実行を管理することにより、いくつかのサービス・プロセスが、他のサービス・プロセスに影響を与えることなく、いくつかの論理プロセッサ上で同時に実行することができる。さらに、あるサービス・プロセスに障害が起きた場合、実行中の他のサービス・プロセスの実行を継続することができる。したがって、本発明は、必要に応じた変更に適合可能であり、またロバストである。
【００１６】
医療用コンピュータ支援検出システムの医療画像ファイルに含まれる医療画像データは、モダリティおよび体の部分に基づいており、またそのモダリティのタイプに基づいてコンピュータ支援検出処理を行うように、スクリプト・ファイルが選択される。したがって、モダリティのタイプおよび体の部分に対して適切な検出サービスを提供するために、スクリプト・ファイルは、モダリティに基づいて記述され得る。さらに、医療画像ファイルに基づいて検出を実施するためのＣＡＤコンポーネントの選択は、その医療画像データのモダリティに基づいて行うことができる。
【００１７】
医療用コンピュータ支援検出システムの一態様は、多数の患者および患者の画像ファイルに対して拡張できることである。特に、本発明のシステムは、複数の画像処理サーバを含むことができ、複数の画像処理サーバのうちの少なくとも１つの画像処理サーバが、始動時にそのプラグインＣＡＤコンポーネントを登録し、またディスパッチャが、ケースの画像ファイルを、現在の作業負荷に基づいて選択された画像処理サーバと、ディスパッチャに登録されたＣＡＤコンポーネントに分配する。追加される画像処理サーバにその利用可能なＣＡＤサービスを登録させることにより、本発明のシステムは、画像処理サーバを容易に追加することができる。
【００１８】
医療用コンピュータ支援検出システムの画像サービス・アドミニストレータの一態様は、それがさらに、実行される検出サービス・プロセスの待ち行列を維持し、待ち行列から取得された検出サービス・プロセスの実行を依頼（ｓｕｂｍｉｔ）した後、待ち行列中に現在ある検出プロセスの数、および実行されている検出プロセスの数に基づき、画像処理サーバの作業負荷状況の変化をディスパッチャに知らせるサービス・アソシエートを含むことができることである。画像処理サーバの作業負荷状況をディスパッチャに知らせることにより、ディスパッチャは、画像処理サーバの作業負荷状況に基づいて、医療画像ファイルを配布することができる。
【００１９】
コンピュータ支援検出のための医療用インテリジェント・サーバのさらなる態様は、プラグインＣＡＤコンポーネントがアップグレードされるか、または画像処理サーバ中に新しく追加された場合、画像処理サーバが再始動され、新しい組のＣＡＤコンポーネントをディスパッチャに登録することである。ＣＡＤコンポーネントが追加または変更されたとき、新しい１組のＣＡＤコンポーネントを登録することによって、画像処理サーバへの画像ファイルの配布が、画像処理サーバの最新の能力により保証されることになる。さらに、本発明の医療用インテリジェント・サーバは、現在利用可能なＣＡＤコンポーネントに対して容易に拡張される。
【発明を実施するための最良の形態】
【００２０】
添付の図面を参照して、本発明をさらに詳細に述べる。
【００２１】
本発明は、医師および放射線専門医が、医療診断を実施するのに利用可能な進んだアルゴリズムを使用できるようにするために使用され得る。本発明は、ガンなどの疾患を正確に検出する高度なアルゴリズムによって進んだＣＡＤを提供し、またその後に、有益な検出情報を提供する。本発明は、ＤＩＣＯＭ規格通信プロトコルを使用するので、既存の医療情報システムおよび作業フロー、ならびに新しい病院システムに適合するように設計されている。検出サービスは、大幅に遅れることなく実施される。組込みのウェブ・サーバは、いつでもシステム・アクセスおよびレポート生成を可能にする。
【００２２】
特に、本発明は、ますます増加する患者および患者の画像に対して、様々なＣＡＤアルゴリズムを適用することを容易にし、新規のまた変更されたＣＡＤサービスに適合するように容易に拡張することができる。患者ケースを同時に接続する数、およびその患者ケースの接続に対して要求されるサービスを処理するために追加されるサーバの数に対する拡張可能なアーキテクチャにより、大容量の処理を容易に行うことができる。新規のまた変更されたＣＡＤサービスへの拡張は、スクリプトおよびプラグインのサービス・コンポーネントにより容易に行うことが可能となる。本発明は、検出サービスに対する要求の多様化に対して動的に適合可能である。
用語および頭字語の定義
以下の定義は、本実施の形態を通して使用される用語に対して提供される。
【００２３】
関連（ａｓｓｏｃｉａｔｉｏｎ）（ＤＩＣＯＭプロトコル）：ＤＩＣＯＭ情報がそれにより交換される２つのＤＩＣＯＭアプリケーション相互間で確立される通信接続。関連に先行して接続が開始される。関連は、関連の折衝（ｎｅｇｏｔｉａｔｉｏｎ）と呼ばれるプロセスにより確立される。
【００２４】
グラフィカル・ユーザ・インターフェース（ＧＵＩ）：コンピュータのグラフィックス機能を利用して、プログラムを使いやすくするプログラム・インターフェース。ＧＵＩの代替と考えられるコンピュータ・プログラムへのユーザ・インターフェースは、コマンド駆動型インターフェースである。現在のＧＵＩは、ポインタおよび関連するポインティング・デバイスを有し、ユーザに、ディスプレイ画面上のグラフィカル・オブジェクトを選択できるようにする。ＧＵＩは、アイコン、メニュー、スクロール・バーなどの機能コンポーネントを表示することができ、コマンドを活動化させ、または表示を操作するなどの機能を有効にする。
【００２５】
メッセージ：動作しているプログラム、デバイス中を、またはオペレーティング環境内を通る情報の単位。情報の単位は、１つまたは複数のテキスト・ブロック、制御キャラクタ、ヘッダ、ならびに誤り検査もしくは同期化情報を含むことができる。
【００２６】
モジュール：関連するアプリケーション・プログラムおよびサービス・アプリケーションの集合体。
【００２７】
サーバ：資源を管理し、ネットワーク中の他のコンピュータにより使用され得るサービス・アプリケーションを送達する、ネットワーク上のコンピュータまたはデバイス。
【００２８】
スタディ（Ｓｔｕｄｙ）（ＤＩＣＯＭ、ケース（ｃａｓｅ）も同様）：病院、診療所での受診中、または他の医療行為中に生成された画像モダリティの１組の画像に対するＤＩＣＯＭ用語。
【００２９】
タスク（プロセスも同様）：実行されるプログラムと、オペレーティング・システムにより使用されるブックキーピング（ｂｏｏｋｋｅｅｐｉｎｇ）情報との組合せ。プログラムがコンピュータにより実行されるとき、オペレーティング・システムは、そのために新しいタスクを作成する。そのタスクはプログラムのためのラッパーを構成し、タスク番号でプログラムを識別し、他のブックキーピング情報をそれに添付する。
【００３０】
トランスファ・シンタックス（Ｔｒａｎｓｆｅｒ Ｓｙｎｔａｘ）（ＤＩＣＯＭ ＰＳ．３．５ ２００４より）：アプリケーション・エンティティが、サポート可能な符号化技法（例えば、データ・エレメント構造、バイト順、圧縮）と曖昧さのない折衝を可能にする１組の符号化規則であり、それにより、これらのアプリケーション・エンティティが通信できるようになる。
【００３１】
Ｗｉｎｄｏｗｓサービス（Ｍｉｃｒｏｓｏｆｔ）：それ自体のＷｉｎｄｏｗｓセッション中に長期間動作するように設計された高度に特殊化されたタイプのアプリケーション。Ｗｉｎｄｏｗｓサービスは、ローカルに、またはネットワーク中で、普通はユーザ・インターフェースなしにバックグラウンド・プロセスとして通常動作する。例えば、大部分のサーバ・ベースのアプリケーションはサービスである。Ｗｉｎｄｏｗｓサービスは、Ｍｉｃｒｏｓｏｆｔ管理コンソールから開始することができる。
【００３２】
モダリティ：Ｃ−ＳＴＯＲＥ要求（他のシステムにデジタル画像を記憶させるための要求）を送る、ＣＴ、ＭＲ、ＣＲ、超音波、および核医学システム、または撮像デバイスおよび装置。モダリティは関連する画像モダリティを有する。
【００３３】
モダリティの例
ＡＳ＝血管内視鏡
ＢＩ＝生体磁気イメージング
ＣＤ＝カラードップラ法
ＣＰ＝コルポスコピー
ＣＲ＝コンピュータＸ線撮影
ＣＳ＝膀胱鏡検査
ＣＴ＝コンピュータ断層撮影
ＤＤ＝デュプレックス・ドップラ
ＤＧ＝透光法
ＤＭ＝デジタル顕微鏡検査
ＤＳ＝減算血管撮影
ＤＸ＝デジタル・ラジオグラフィ
ＥＣ＝心臓超音波検査法
ＥＳ＝内視鏡検査法
ＦＡ＝蛍光血管造影法
ＦＳ＝眼底検査
ＨＣ＝ハード・コピー
ＬＰ＝腹腔鏡検査法
ＬＳ＝レーザ表面走査
ＭＡ＝磁気共鳴血管造影法
ＭＲ＝磁気共鳴
ＭＳ＝磁気共鳴分光検査法
ＮＭ＝核医学
ＰＴ＝ＰＥＴ（陽電子放出断層撮影法）
ＲＦ＝放射線蛍光透視法
ＲＧ＝Ｘ線写真イメージング（従来のフィルム画面）
ＲＴＤＯＳＥ＝治療用放射線量
ＲＴＩＭＡＧＥ＝放射線療法画像
ＲＴＰＬＡＮ＝放射線療法計画
ＲＴＳＴＲＵＣＴ＝放射線療法構造セット
ＳＴ＝単一光子放出型コンピュータ断層撮影法
ＴＧ＝温度記録法
ＵＳ＝超音波
ＸＡ＝Ｘ線血管造影法
ＸＣ＝外部カメラ
ＥＣＧ＝心電図
ＣＡＤ（コンピュータ支援検出）：疾患または病気を示す可能性のある、医療画像中の部位を検出するように設計された、例えば、パターン認識アルゴリズムなどのアルゴリズム。
【００３４】
ＤＩＣＯＭ：（医用画像通信規格）。医療撮像における情報を処理し、記憶し、印刷し、送信するための包括的な１組の規格である。それは、ファイル・フォーマット定義およびネットワーク通信プロトコルを含む。上記プロトコルは、システム間で通信を行うためにＴＣＰ／ＩＰを使用する。ＤＩＣＯＭファイルは、ＤＩＣＯＭフォーマットで、情報、すなわち、画像と患者データを受け取る機能を有する２つのエンティティ間で交換することができる。ｄｉｃｏｍ．ｎｅｍａ．ｏｒｇを参照のこと。
【００３５】
ＰＡＣＳ：（画像保管通信システム）。市販のＰＡＣＳは、入力モダリティ、ＤＩＣＯＭサーバ、ＰＡＣＳサーバ、アーカイブ・サーバ、ウェブ・サーバ、ＲＩＳ（放射線情報サーバ）、および放射線クライアントを含むアーキテクチャを提供する。
【００３６】
ＳＯＡＰ：（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）。
【００３７】
本発明の医療用画像インテリジェント・サーバ（ＭＩＩＳ）の概念図が図１に示されている。図１に示すように、ＭＩＩＳは、ジョブ・ディスパッチャ２０、コンソール４０、および１つまたは複数の画像処理サーバ３０（簡単のために１つだけを示す）から構成される。ジョブ・ディスパッチャは、１つまたは複数のＤＩＣＯＭデバイス１０との接続を確立することができる。ＤＩＣＯＭデバイスは、スキャナ、ワークステーション、プリンタ、およびネットワーク・ハードウェアなど、任意のＤＩＣＯＭ準拠デバイスを含む。
【００３８】
大規模な病院システムに対するスループット要件は、単一のサーバが提供できる能力をはるかに超える。ＭＩＩＳは、画像処理サーバをさらに追加できる能力を提供し、適切な性能を達成するように、その作業負荷を調整する。ＭＩＩＳは、画像処理サーバの情報を登録し、登録された情報に基づいて画像を配布するジョブ・ディスパッチャを介して拡張容易性（ｓｃａｌａｂｉｌｉｔｙ）を達成し、また新規のまたは変更されたＣＡＤサービスに対して動的にスクリプトを適合させる画像処理サーバを介して拡張性を達成する。ジョブ・ディスパッチャは、ＤＩＣＯＭデバイスからの要求を検出し、スタディ用の画像を受け取り、適切な画像処理サーバに画像を配布する。ジョブ・ディスパッチャは、ますます増加する新しいサービス、ならびに既存のサービスの変更を有する環境中で負荷バランスをとるために登録サービスを使用する。
【００３９】
本発明は、ＭＩＩＳのバックエンドとしての画像処理サーバの諸態様を開示する。ジョブ・ディスパッチャの詳細は、関連出願（整理番号３３５２−０１４５ＰＵＳ１）に開示されており、上記で述べたように、それを参照により本明細書に組み込む。
【００４０】
図２は、画像処理サーバの作業フロー図を示す。ジョブ・ディスパッチャは、多数の画像処理サーバ中で作業負荷を平衡させることができる。図２で分かるように、ジョブ・ディスパッチャは、スタディ・ハンドラ２２および登録サービス２３を含む。画像処理サーバは、登録サービス２３に登録（「Ｒｅｇｉｓｔｅｒ」）することができる。登録サービス２３は、画像処理サーバ３０のステータス情報を記憶し、管理する。ステータス情報は、画像処理サーバが提供できるＣＡＤサービスのリスト、画像処理サーバによるサービス要求に必要なプロセスおよびプロトコル、ならびに画像処理サーバの位置（例えば、ローカル・マシン、またはＩＰアドレス）を含んでいる。
【００４１】
画像処理サーバは、サービス・グループのメンバーであり得る前に、登録サービスに登録される必要がある。ジョブ・ディスパッチャは、ＣＡＤサービスを実施するために、画像処理サーバに画像を配布（「ＣａｒｒｙＯｕｔＳｅｒｖｉｃｅ」）できるように登録情報を検索することになる。登録情報は、システム・コンフィギュレーションが変わる場合、例えば、画像処理サーバを追加／除去し、あるいはＣＡＤサービスを追加／アップグレードする場合、更新される必要がある。
【００４２】
画像処理サーバ３０は、ＭＩＩＳのＣＡＤサービスを提供する。図２に示すように、画像処理サーバ３０は、画像サービス・アドミニストレータ３１、スクリプト・ランナ３２および１つまたは複数のプラグインＣＡＤコンポーネント５４を含んでいる。スクリプト・ソフトウェア・プログラムは、１つまたは複数のＣＡＤ画像処理コンポーネントを一緒に組み合わせて、ＤＩＣＯＭ画像に基づく診断を行う。ＣＡＤ画像処理コンポーネントは、スクリプト・エディタにより呼び出すことのできるメソッドを公開（ｅｘｐｏｓｅ）するＣＡＤプラグイン・コンポーネント中にラップされる。スクリプトは、プロジェクト単位で実行される。プロジェクトは、参照アセンブリおよびそのプロジェクト中のスクリプト・ファイルのリストを記述するファイルである。結果を分析し、レポートの様々なフォーマットを生成できるプラグイン・コンポーネントが存在する。フォーマットの中で、プラグイン・コンポーネントは、ＤＩＣＯＭをサポートし、かつＤＩＣＯＭ画像を結果と共に指定された位置に送ることができる。例示的なスクリプトは、［プログラムコード］のAPPENDIX 1に含まれる。
【００４３】
画像サービス・アドミニストレータ３１は、画像サービス・オブジェクト５１、サービス・アソシエート５２、およびサービス・ドゥーア（Ｄｏｅｒ）５３を含む。画像サービス・オブジェクト５１は、スタディ・ハンドラ２２から配布された画像を受け取るためのメソッドを提供する。画像サービス・オブジェクト５１のインスタンスは、画像サービス・アドミニストレータ３１により、要求に応じてインスタンス生成される（ｉｎｓｔａｎｔｉａｔｅｄ）。スタディ・ハンドラ２２から受け取られた画像は、サービス・アソシエート５２によって管理される待ち行列中に配置される。
【００４４】
サービス・アソシエート５２は、優先順位および画像が受け取られた時間により（先着順）整列されるサービス・ドゥーア待ち行列を維持する。サービス・アソシエート５２は、新しいケースの到来、ＣＡＤサービスの完了、およびサーバのシャット・ダウンなどのイベントをトリガする手続きを処理する。サービス・ドゥーア５３は、画像データを取得し、ＣＡＤ画像処理を実施するために子プロセスを開始する。
【００４５】
図３は、画像サービス・アドミニストレータ３１に対するクラス図を示す。画像サービス・アドミニストレータ３１は、画像サーバ・アドミニストレータ・クラス、画像サービス・オブジェクト・クラス、サービス・アソシエート・クラス、およびサービス・ドゥーア・クラスを含む。各クラスは、インスタンスが生成された各オブジェクトが実施できる例示的なメソッドと共に示されている。例示的な実施形態では、画像サービス・アドミニストレータ３１は、連続的に動作するＷｉｎｄｏｗｓサービスである。画像サービス・アドミニストレータ・クラスは、「ＯｎＳｔａｒｔ」メソッドを含み、それは、呼び出されたとき、コンフィギュレーション設定を読み取り、それに従って、サービス・アソシエートを構成し、画像サービス・オブジェクト５１をロードし、「ＲｅｇｉｓｔｅｒＳｅｒｖｉｃｅ」メソッドをコールして画像処理サーバおよびそれが処理できるサービスを登録し、またサービスが開始したことをサービス・アソシエートに通知する。「ＲｅｇｉｓｔｅｒＳｅｒｖｉｃｅ」メソッドは、すべての画像処理コンポーネントを検索し、画像処理サーバが提供できる、または現在実行中のサービスの要約表を生成し、遠隔の登録サービス２３にサービスの表を転送するための機能を呼び出す。サービスの表にある各サービスは、ストリング「Ｍｏｄａｌｉｔｙ／Ｂｏｄｙｐａｒｔ」により表されることが好ましい。サービスは、例えば、ＣＲ／ＢＲＥＡＳＴ、ＭＧ／ＢＲＥＡＳＴ、ＣＲ／ＣＨＥＳＴなどとして表すこともできる。サービスの表中で表されるサービスは、ハッシュ・テーブルに記憶されることが好ましい（図４を参照）。画像サービス・アドミニストレータ３１はまた、メソッド「ＯｎＳｔｏｐ」および「ＵｎＲｅｇｉｓｔｅｒＳｅｒｖｉｃｅ」を実施することもできる。「ＯｎＳｔｏｐ」は、画像処理サーバ３１のサービスが停止したとき、登録サービスから登録を抹消するための「ＵｎＲｅｇｉｓｔｅｒＳｅｒｖｉｃｅ」機能を含む機能を実施する。「Ｒｅｇｉｓｔｒａｔｉｏｎ Ｓｅｒｖｉｃｅ」メソッドはまた、プラグイン・コンポーネントが追加されたとき、または変更されたときに実施される。画像処理サーバの再登録は、画像処理サーバを一時停止するか停止させることにより、コンフィギュレーションをアップグレードすることにより、画像処理サーバを始動することにより、またプラグイン・コンポーネントの新しい組を登録することにより行われ得る。
【００４６】
画像サービス・オブジェクト・クラスは、画像を送るためにスタディ・ハンドラにより呼び出され得るメソッド「ＣａｒｒｙＯｕｔＳｅｒｖｉｃｅ」を含む。パラメータは、「Ｓｅｒｖｉｃｅ Ｎａｍｅ（サービス名）」と、ＤＩＣＯＭヘッダ、および要求が優先順であるかどうかを示すフラグを含む画像データとを含む。「ＣａｒｒｙＯｕｔＳｅｒｖｉｃｅ」は、受け取られたデータをサービス・ドゥーア・オブジェクトのインスタンス中に入れることを担当し、サービス・ドゥーア・オブジェクトをサービス・アソシエート中の待ち行列中に挿入し、イベントを生成するために「Ｃａｌｌ Ｓｅｒｖｉｃｅ Ａｓｓｏｃｉａｔｅ」メソッドを呼び出し、新しい要求が到来したことをサービス・アソシエートに通知する。
【００４７】
サービス・アソシエート５２は、要求を保持する待ち行列を維持する。それは、要求の待ち行列を作り、イベントを生成するために呼び出すことのできるメソッドを含む。それはまた、生成されたイベントを処理するためのメソッドも提供する。特に、サービス・アソシエートは、待ち行列イベントの処理を委譲する「ＨａｎｄｌｅＱｕｅｕｅＥｖｅｎｔ」メソッドを含む。メソッド「ＱｕｅｕｅＵｐＲｅｑ」は、パラメータとして、サービス・ドゥーアのインスタンスおよびその優先順位を取り、サービス・ドゥーア・オブジェクトを待ち行列中に挿入する。メソッドは、先着順ベースで呼び出される。しかし、あるオブジェクトが優先に設定された場合、待ち行列の先頭部分に挿入されることになる。メソッド「Ｒａｉｓｅ」が、待ち行列イベントを生成するのに呼び出され得る。上記で述べた「ＨａｎｄｌｅＱｕｅｕｅＥｖｅｎｔ」は、入力として２つのパラメータをとる。すなわち、イベントを送るオブジェクトであるＳｅｎｄｅｒ（送信側）と、生成されたイベントのタイプＱｕｅｕｅＥｖｅｎｔＡｒｇである。
【００４８】
待ち行列イベント処理は、生成されたイベントのタイプに基づく。例示のイベント・タイプは、新しい要求が到来したこと、スタディ用の画像処理が完了したこと、タスクの実行に失敗したこと、画像サービス・アドミニストレータが始動、またはシャット・ダウンしたことを含んでいる。サービス・アソシエートは、同時に画像処理を開始することを特定の数の子プロセスに許可する。この特定の数の値は、画像サービス・アドミニストレータのコンフィギュレーション・ファイルで指示される。それは、マシン中で利用可能な論理プロセッサの数に自動的に設定することができる。タスクまたは新しい要求の到来に関係するイベントおいて、サービス・アソシエートは、現在動作している子プロセスの数を調べる。現在動作している子プロセスの数が、事前設定の閾値よりも低い場合、待ち行列中の次のサービス・ドゥーア・オブジェクトが実行のために取り出され、その他の場合、そのイベントは無視される。サービス・ドゥーア・オブジェクトが、タスクを実行するために取り出され場合、性能を高めるために、サービス・アソシエートは、別の子プロセスを開始し、「ＤｏＳｅｒｖｉｃｅ」をその子プロセスで動作させる。画像サービス・アドミニストレータがシャット・ダウンされたとき、シャット・ダウン・イベントが開始され、サービス・アソシエートが、子プロセスの動作を停止させて、未終了のタスクをすべてハード・ドライブに書き込む。画像サービス・アドミニストレータが始動されたとき、始動イベントが開始され、ハード・ドライブに書き込まれたすべてのタスクが再度ロードされ、実行されることになる。
【００４９】
呼び出すことのできるサービス・アソシエートの他のメソッドは、「ＳｃｒｉｐｔＲｕｎｎｅｒＥｘｉｔ」、「ＩｎｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、「ＤｅｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、「ＧｅｔＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、および「ＵｐｄａｔｅＳｅｒｖｅｒＳｔａｔｅ」を含んでいる。「ＳｃｒｉｐｔＲｕｎｎｅｒＥｘｉｔ」メソッドが、受け取られたイベントにより呼び出された場合、サービス・アソシエートは、ｔａｓｋ ｄｏｎｅイベントを生成し、待ち行列イベント・ハンドラにそのイベントの処理を引き継ぐようにさせる。「ＩｎｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、「ＤｅｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、および「ＧｅｔＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」は、現在動作している子プロセスの数のカウントを維持する。「ＵｐｄａｔｅＳｅｒｖｅｒＳｔａｔｅ」は、画像処理サーバのステータスの変化情報を登録サービスに提供するためのメソッドである。ステータス情報は、開始された子プロセスの数、および待ち行列中のタスクの数を含むことができる。メソッドは、新しい要求処理イベントが生じたときにコールされ、または関数「ＩｎｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」、または「ＤｅｃＷｏｒｋｉｎｇＴｈｄＣｏｕｎｔ」の内部からコールされ得る。
【００５０】
上記で述べたように、サービス・ドゥーア・オブジェクトは、受け取られたデータおよび画像のホルダであり、待ち行列上の単位として記憶される。サービス・ドゥーア・オブジェクトは、メソッド「ＤｏＳｅｒｖｉｃｅ」を含んでいる。「ＤｏＳｅｒｖｉｃｅ」メソッドを呼び出すことにより、ＣＡＤ画像処理を実行する別の子プロセスが作成される。本発明の発明者は、最大数の画像ファイルに対して同時に適合できるアーキテクチャを用いたとき、より高いスループットが達成できると判断した。したがって、「ＤｏＳｅｒｖｉｃｅ」メソッドは、より多くの画像ファイルが処理できるように、別のプロセスで動作する。さらに、別のプロセスとして動作させることによって、プロセスの障害は、他の子プロセス、ならびに親の画像処理サーバに影響を与えないことになる。
【００５１】
サービス・ドゥーアはまた、サービス・ドゥーア・オブジェクト中に記憶されたスタディの特性をリストする表を返す（ｒｅｔｕｒｎ）ためのメソッドを提供する。特に、メソッド「ＧｅｔＪｏｂＰｒｏｐｓ」は、待ち行列中のまたはプロセス中のケースに関する情報を検索するためにコンソールにより呼び出すことができる。検索され得る特性の好ましいリストは、次のものを含む。
【００５２】
患者ＩＤ
患者名
患者の性別
受入れ番号（Ａｃｃｅｓｓｉｏｎ Ｎｕｍｂｅｒ）
スタディのモダリティ
スタディの記述
スタディの日付
スタディの時間
委託医師の名前
スクリプト・ランナ３２は、メソッド「ＤｏＳｅｒｖｉｃｅ」でサービス・ドゥーアにより呼び出されるアプリケーションである。スクリプト・ランナ３２は、コンパイルし、アセンブリをセーブし、指定されたスクリプト・ファイルの実行を担当する。スクリプト・ファイルは、ＣＡＤコンポーネントおよび他のプラグイン・コンポーネントにコールすることができる。
【００５３】
図５は、サービス・ドゥーア・オブジェクトのフローチャートを示す。サービス・ドゥーア・オブジェクトの子プロセスは、要求された検出サービスを実施するためのスクリプトを取得するために作成され呼び出される。子プロセスは、画像サービス・アドミニストレータのコンフィギュレーションから、スクリプトまたは対応する実行可能ファイルを検索する（ステップＳ−５１）。所望のスクリプトまたは実行可能ファイルが見つからない場合（ステップＳ−５２の「Ｎｏ」）、結果を得ることなくプロセスは終了したというメッセージが、サービス・アソシエートに送られる。所望のスクリプトが見出された場合（ステップＳ−５２の「Ｙｅｓ」）、２つのアクションのうちの一方が、モジュール・タイプに基づいて行われることになる（ステップＳ−５３）。モジュールが、実行可能ファイルである場合、その実行可能ファイルは、子プロセスで実行される（ステップＳ−５７）。モジュールがスクリプトである場合、そのスクリプトが変更されているかどうかについて検査が行われる（ステップＳ−５４）。スクリプトが変更されていない場合（Ｓ−５４の「Ｎｏ」）、前に記憶された可能性のある対応する実行可能ファイルを突き止めるための検査が行われる（ステップＳ−５８）。発見された場合、その実行可能ファイルは子プロセス中で実行される。スクリプトが変更されている場合、スクリプト・ランナが開始されてスクリプトをコンパイルする（ステップＳ−５５）。コンパイルされたスクリプトは、続いて実行される。プロセスが完了したとき、他のスクリプトの処理を可能にするために、メッセージがサービス・アソシエートに送られる。
【００５４】
プラグインＣＡＤコンポーネントは、どのオブジェクトを、またどのメソッドを呼び出すかを指示することにより、スクリプトによって使用される。したがって、プラグイン・コンポーネントは、サーバ・オブジェクトの挙動を変更するために、サーバ・モジュール全体を再コンパイルすることなく変更することができる。さらに、スクリプト・ファイルは、プラグイン・コンポーネントの実装形態の細部の知識なしに、また時間が経過してプラグイン・コンポーネントが改訂されたとき、大規模なメンテナンスをすることなく、エンド・ユーザが容易に準備することができる。スクリプトの使用により、ＭＩＩＳは、大幅な拡張性を実現する。
【００５５】
図６は、画像処理サーバにおける典型的なセッション中に行われ得る諸ステップを示す。画像処理システムは、まず、ジョブ・ディスパッチャの登録サービスに登録する必要がある。画像サービス・アドミニストレータ３１が始動され、そのコンフィギュレーション・ファイルをロードする。画像サービス・アドミニストレータ３１は、画像処理サーバが提供できる利用可能な画像処理コンポーネントをすべて検討し、そのコンポーネントをサービス表に要約する。
【００５６】
コンポーネントのリストが、登録プロセスを実行する登録サービスに送られる（Ｒｅｇｉｓｔｅｒ、ステップＳ−６１）。
【００５７】
スタディ・ハンドラが画像を受け取ると、画像サービス・オブジェクト５１のインスタンスを呼び出し、「ＣａｒｒｙＯｕｔＳｅｒｖｉｃｅ」メソッドをコールしてその画像を送る（ＣａｒｒｙＯｕｔＳｅｒｖｉｃｅ、ステップＳ−６２）。
【００５８】
画像サービス・オブジェクト５１は、サービス・ドゥーア・オブジェクト５３を作成し、サービス・アソシエート５２のメソッド「ＱｕｅｕｅＵｐＲｅｑ」をコールする（ＱｕｅｕｅＵｐＲｅｑ、ステップＳ−６３）。サービス・ドゥーア・オブジェクトは、サービス・アソシエートによって維持される待ち行列中に配置される。
【００５９】
画像サービス・オブジェクト５１は、イベントを生成して、新しい要求が到来したことをサービス・アソシエート５２に通知する（Ｒａｉｓｅ Ｅｖｅｎｔ、ステップＳ−６４）。サービス・アソシエートは、待ち行列からサービス・ドゥーアを取り出し、ＤｏＳｅｒｖｉｃｅメソッドをコールして、別のプロセスとしてサービスを実施する（ＤｏＳｅｒｖｉｃｅ、Ｓ−６５）。
【００６０】
サービス・ドゥーア５３は、子プロセスを開始してサービスを実施する。サービス・ドゥーアは、サービスを２つの方法の一方で実施する。スクリプト・ファイルが変更されているか、または実行可能ファイルが利用可能ではない場合（Ｓｔａｒｔ、ステップＳ−６６）、スクリプト・ランナ３２がスクリプトをコンパイルし（Ｃｏｍｐｉｌｅ、ステップＳ−６７）動作させる。コンパイルされたスクリプトは、同じスクリプトを将来使用するために実行可能ファイルにセーブされる。実行可能ファイルが存在する場合、子プロセスが開始されてその実行可能ファイルを動作させる（Ｅｘｅｃｕｔｅ、ステップＳ−６８）。実行可能ファイルは、プラグイン・コンポーネント中のメソッドをコールすることにより動作する（Ｆｕｎｃ、ステップＳ−６９）。サービスが完了すると、子プロセスはイベントを生成して、サービス・アソシエートに、待ち行列中に記憶された次の要求を処理するように通知する（ステップＳ−７０）。
【００６１】
【表１】
【図面の簡単な説明】
【００６２】
【図１】医療用画像インテリジェント・サーバ（ＭＩＩＳ）およびインターフェースのブロック図である。
【図２】画像処理サーバの作業フローの図である。
【図３】画像サービス・アドミニストレータのためのクラス図である。
【図４】画像処理サーバで提供されるサービスの表のフォーマットを示す図である。
【図５】サービス・ドゥーアのフローチャートである。
【図６】画像処理サーバの例示的なオペレーションのためのフローチャートである。
【特許請求の範囲】
【請求項１】
コンピュータ支援検出（ＣＡＤ）のための医療用インテリジェント・サーバであって、
１組の医療画像ファイルをそれぞれが含む１つまたは複数のケースを受け取り、前記ファイルを分配するためのディスパッチャと、
プラグインＣＡＤコンポーネントを用いて、前記１組の医療画像ファイルに基づき医療用コンピュータ支援検出を実施する画像処理サーバとを備え、前記画像処理サーバが、前記プラグインＣＡＤコンポーネントを前記ディスパッチャに登録し、前記ディスパッチャが、前記画像処理サーバおよび前記登録されたプラグインＣＡＤコンポーネントの作業負荷に基づき前記医療画像ファイルを分配する、コンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項２】
前記画像処理サーバが、前記医療画像ファイルに基づいてコンピュータ支援検出を実施するために、プラグインＣＡＤコンポーネントによる処理を呼び出すスクリプト・ファイルを実行する、請求項１に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項３】
前記医療画像ファイルのそれぞれが、患者データおよび画像データを含むヘッダを含む、請求項１に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項４】
前記画像処理サーバが、スクリプト・ファイルが事前にコンパイルされているか、あるいは変更されているかどうかを判定し、前記スクリプト・ファイルが変更されている場合、前記画像処理サーバが、前記スクリプトのコンパイルされたバージョンがあるかどうかを判定し、それがない場合、前記スクリプト・ファイルをコンパイルし、前記コンパイルされたスクリプトを実行する、請求項２に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項５】
前記画像処理サーバが、画像サービス・アドミニストレータ、およびスクリプト・ランナを備え、前記画像サービス・アドミニストレータが、プラグインＣＡＤコンポーネントを前記ディスパッチャに登録し、前記ＣＡＤコンポーネントが登録された場合、前記ＣＡＤコンポーネントに基づき、スクリプト・ファイルの実行を管理するための別の検出サービス・プロセスを作成し、前記ディスパッチャから画像ファイルを受け取る、請求項１に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項６】
前記医療画像ファイルが、モダリティおよび体の部分に基づいており、スクリプト・ファイルが、モダリティの前記タイプに基づくコンピュータ支援検出処理を行うために選択される、請求項５に記載のコンピュータ支援診断のための医療用インテリジェント・サーバ。
【請求項７】
複数の画像処理サーバをさらに備え、前記複数の画像処理サーバのうちの少なくとも１つの画像処理サーバが、始動時にそのプラグインＣＡＤコンポーネントを登録し、前記ディスパッチャが、ケースの画像ファイルを、現在の作業負荷に基づいて選択された画像処理サーバと、前記ディスパッチャに登録されたＣＡＤコンポーネントに分配する、請求項１に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項８】
前記画像サービス・アドミニストレータが、実行される検出サービス・プロセスの待ち行列を維持し、また前記待ち行列から取得された検出サービス・プロセスの実行を依頼した後、前記待ち行列中に現在ある検出プロセスの数、および実行されている検出プロセスの数に基づき、前記画像処理サーバの作業負荷状況の変化を前記ディスパッチャに知らせるサービス・アソシエートを備える、請求項５に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項９】
プラグインＣＡＤコンポーネントがアップグレードされるか、または画像処理サーバ中に新しく追加された場合、前記画像処理サーバが再始動され、前記新しい組のＣＡＤコンポーネントを前記ディスパッチャに登録する、請求項１に記載のコンピュータ支援診断のための医療用インテリジェント・サーバ。
【請求項１】
コンピュータ支援検出（ＣＡＤ）のための医療用インテリジェント・サーバであって、
１組の医療画像ファイルをそれぞれが含む１つまたは複数のケースを受け取り、前記ファイルを分配するためのディスパッチャと、
プラグインＣＡＤコンポーネントを用いて、前記１組の医療画像ファイルに基づき医療用コンピュータ支援検出を実施する画像処理サーバとを備え、前記画像処理サーバが、前記プラグインＣＡＤコンポーネントを前記ディスパッチャに登録し、前記ディスパッチャが、前記画像処理サーバおよび前記登録されたプラグインＣＡＤコンポーネントの作業負荷に基づき前記医療画像ファイルを分配する、コンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項２】
前記画像処理サーバが、前記医療画像ファイルに基づいてコンピュータ支援検出を実施するために、プラグインＣＡＤコンポーネントによる処理を呼び出すスクリプト・ファイルを実行する、請求項１に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項３】
前記医療画像ファイルのそれぞれが、患者データおよび画像データを含むヘッダを含む、請求項１に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項４】
前記画像処理サーバが、スクリプト・ファイルが事前にコンパイルされているか、あるいは変更されているかどうかを判定し、前記スクリプト・ファイルが変更されている場合、前記画像処理サーバが、前記スクリプトのコンパイルされたバージョンがあるかどうかを判定し、それがない場合、前記スクリプト・ファイルをコンパイルし、前記コンパイルされたスクリプトを実行する、請求項２に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項５】
前記画像処理サーバが、画像サービス・アドミニストレータ、およびスクリプト・ランナを備え、前記画像サービス・アドミニストレータが、プラグインＣＡＤコンポーネントを前記ディスパッチャに登録し、前記ＣＡＤコンポーネントが登録された場合、前記ＣＡＤコンポーネントに基づき、スクリプト・ファイルの実行を管理するための別の検出サービス・プロセスを作成し、前記ディスパッチャから画像ファイルを受け取る、請求項１に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項６】
前記医療画像ファイルが、モダリティおよび体の部分に基づいており、スクリプト・ファイルが、モダリティの前記タイプに基づくコンピュータ支援検出処理を行うために選択される、請求項５に記載のコンピュータ支援診断のための医療用インテリジェント・サーバ。
【請求項７】
複数の画像処理サーバをさらに備え、前記複数の画像処理サーバのうちの少なくとも１つの画像処理サーバが、始動時にそのプラグインＣＡＤコンポーネントを登録し、前記ディスパッチャが、ケースの画像ファイルを、現在の作業負荷に基づいて選択された画像処理サーバと、前記ディスパッチャに登録されたＣＡＤコンポーネントに分配する、請求項１に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項８】
前記画像サービス・アドミニストレータが、実行される検出サービス・プロセスの待ち行列を維持し、また前記待ち行列から取得された検出サービス・プロセスの実行を依頼した後、前記待ち行列中に現在ある検出プロセスの数、および実行されている検出プロセスの数に基づき、前記画像処理サーバの作業負荷状況の変化を前記ディスパッチャに知らせるサービス・アソシエートを備える、請求項５に記載のコンピュータ支援検出のための医療用インテリジェント・サーバ。
【請求項９】
プラグインＣＡＤコンポーネントがアップグレードされるか、または画像処理サーバ中に新しく追加された場合、前記画像処理サーバが再始動され、前記新しい組のＣＡＤコンポーネントを前記ディスパッチャに登録する、請求項１に記載のコンピュータ支援診断のための医療用インテリジェント・サーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００８−１７３４５８（Ｐ２００８−１７３４５８Ａ）
【公開日】平成２０年７月３１日（２００８．７．３１）
【国際特許分類】
【外国語出願】
【出願番号】特願２００７−３０４３４８（Ｐ２００７−３０４３４８）
【出願日】平成１９年１１月２６日（２００７．１１．２６）
【出願人】（３０６０３７３１１）富士フイルム株式会社 (25,513)
【Ｆターム（参考）】
【公開日】平成２０年７月３１日（２００８．７．３１）
【国際特許分類】
【出願番号】特願２００７−３０４３４８（Ｐ２００７−３０４３４８）
【出願日】平成１９年１１月２６日（２００７．１１．２６）
【出願人】（３０６０３７３１１）富士フイルム株式会社 (25,513)
【Ｆターム（参考）】
[ Back to top ]