JP2008204432A - 医療用インテリジェント・サーバ・アーキテクチャのためのジョブ・ディスパッチャ - Google Patents

Abstract

【課題】新しい画像モダリティが追加されつつある環境で、膨大な量の医療用データをＣＡＤアルゴリズムに適用するシステムを提供する。
【解決手段】ディスパッチャは、外部装置からケースを動的に受け付け、複数の画像処理サーバへのケースの配布を管理する。ディスパッチャは、１対１の対応で外部装置への接続ごとに子ディスパッチャ・プロセスを作成するジョブ・ディスパッチャ・プロセス、および複数の画像処理サーバの動作状態情報を管理する登録サービスを含む。各子プロセスには、接続のアソシエーションを管理する責任が割り当てられる。各子ディスパッチャ・プロセスには、入ってくる画像ファイルの一時格納用のそれ自身の専用キャッシュ・メモリが割り振られる。したがって、ディスパッチャを実行しているコンピュータ内のメイン・メモリの量によってのみ制限される、高スループットで多数のケースを管理できる。
【選択図】図３

Description

（関連分野の相互参照）
代理人明細書番号３３５２−０１４４ＰＵＳ１のＪａｅＪｕｎｇ Ｃｈａｎｇの「Ｍｅｄｉｃａｌ Ｉｎｔｅｌｌｉｇｅｎｔ Ｓｅｒｖｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ」という名称の関連出願は、本明細書と同時に出願され、参照により本明細書に組み込まれる。

本発明は、医療用コンピュータ支援検出の分野に関し、より詳細には、１組の医療用画像からなるケースに基づくコンピュータ支援検出に関する。本発明は、コンピュータ支援検出を管理する医療用インテリジェント・サーバのためのジョブ・ディスパッチャである。

病院情報システム、薬品試験所システム、および様々なクリニックおよび診療所用のコンピュータ・ネットワークは、増加する医療用データおよび医療用画像を取得し、格納している。コンピュータ支援検出（ＣＡＤ）の分野では、癌などの疾病を正確に検出し、医療用データおよび医療用画像に基づいて貴重な検出情報を提供する高度化されたアルゴリズムが開発されつつある。時間が経つにつれて、病院および他の診療所は、従来の臨床チャートの代わりに電子臨床チャートを使用しており、臨床履歴のデータベースおよび処方箋の履歴が導入されている。診断に使用できる情報を提供するために、放射線情報システムが実装されている。ごく最近、画像保存通信システム（Ｐｉｃｔｕｒｅ Ａｒｃｈｉｖｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ：ＰＡＣＳ）は、フィルム・アーカイブなど、医療用画像を管理するハードコピーベースの手段の代替になった。

ＰＡＣＳは、医療用画像の格納、取り出し、配布、および提示専用のコンピュータ・システムである。Ｆｕｌｌ ＰＡＣＳは、超音波、磁気共鳴映像、ポジション放射断層撮影、コンピュータ断層撮影、内視鏡検査、マンモグラフィ、Ｘ線撮影（通常のＸ線）など、複数の画像タイプおよび関連のモダリティを処理する。

一般のＰＡＣＳネットワークは、画像を含むデータベースを格納する中央サーバで構成され得る。中央サーバは、ＬＡＮまたはＷＡＮで、またインターネットを介してクライアント・ワークステーションに接続されていてもよい。クライアント・ワークステーションは、画像フィルムを走査してシステム内に取り入れる（フィルム・デジタイザなど）、システムからの画像フィルムを印刷する、およびデジタル画像の対話式表示のためのローカル周辺機器を含み得る。ＰＡＣＳワークステーションは、ローカル周辺機器から得られた画像を操作する（トリミング、回転、ズーム、輝度、コントラストなど）手段を提供する。

多くのタイプの撮像機器は、患者の画像を直接ＰＡＣＳにデジタル形式で送ることができる。多くの病院および他の診療所は、現在、医用デジタル画像化および通信（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ：ＤＩＣＯＭ）として知られる、多くのタイプの医療用データを処理する標準、すなわちＮＥＭＡ標準を使用している。ＤＩＣＯＭは、フィルム形式定義およびネットワーク通信プロトコルを含む。ＤＩＣＯＭは、複数のベンダーのスキャナ、サーバ、ワークステーション、プリンタ、およびネットワーク・ハードウェアの統合を可能にするために開発された。

ＤＩＣＯＭ標準は、一般的なＡｎａｌｙｚｅ形式に比べて改良されたものと考えられている。Ａｎａｌｙｚｅ形式は、画像データをあるファイル（＊．ｉｍｇ）に格納し、ヘッダー・データを別のファイル（＊．ｈｄｒ）に格納する。一方、ＤＩＣＯＭは、ヘッダー（患者名、走査のタイプ、画像の寸法など、患者および画像についての情報を格納する）、およびすべての画像データ（３次元画像のための情報を含むことができる）の両方を含む単一のＤＩＣＯＭファイルを必要とする。さらに、ＤＩＣＯＭ標準では、画像の圧縮（カプセル化）で、ファイルにおける画像データの量を低減できるようにする（ＪＰＥＧ、ＪＰＥＧ Ｌｏｓｓｌｅｓｓ、ＪＰＥＧ２０００、ＬＺＷ、およびＲｕｎ−ｌｅｎｇｔｈ符号化を含めて、任意のいくつかの一般的な圧縮標準がサポートされる）。さらに、単一のＤＩＣＯＭオブジェクトは、１つの画像しか含むことができないが、画像は、複数のフレームを有していてもよく、映画や他のマルチ・フレーム・データの格納が可能になる。

ＤＩＣＯＭファイル形式によって提供されたヘッダーは、標準フィールド、および自由形式フィールドを含み得る。ヘッダーのサイズは、ヘッダー情報がどの程度格納されるかに応じて異なる。ＤＩＣＯＭファイルは、必要な要素を含み、必要な要素は、画像タイプ（すなわちモダリティ）に依存する。例えば、画像モダリティＭＲには、ＭＲＩエコー時間を記述するための要素がなければならない。このモダリティにこの情報がないことは、ＤＩＣＯＭ標準の違反となる。

ＤＩＣＯＭヘッダーに含まれる情報の中に、転送構文固有識別（Ｔｒａｎｓｆｅｒ Ｓｙｎｔａｘ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：ＵＩＤ）がある。ＵＩＤは、画像データの構造を定義し、画像データが圧縮されているかどうかを識別し、生データのバイト・オーダーを識別する。

ＰＡＣＳシステムは、多くの患者の多数の医療用画像を管理することができる。ＤＩＣＯＭ標準は、多くのタイプの医療用撮像機器から医療用画像を送信するためのプロトコルおよびデータ形式を定義する。新しい、および変更されたＣＡＤアルゴリズムが開発されつつあり、新しい画像モダリティが追加されつつある環境において、増加する患者および病気の診断を提供するために、膨大な量の医療用データをＣＡＤアルゴリズムに適用するシステムが必要である。長期にわたって、システムは、新しい、または変更されたモダリティおよび関連のＣＡＤアルゴリズムに順応できるとともに、増加する患者および病気に応じて拡大することができなければならない。こうしたシステムが既存のシステムと統合できることが好ましい。

本発明の一態様は、増加する患者および疾病に応じて拡大することができ、モダリティごとに新しいＣＡＤアルゴリズムを変更したり、追加したりしやすくすることができるアーキテクチャである。本発明は、ケースとも呼ばれる患者のスタディについての１組の医療用画像が提出されると、診断を決定する検出サービスを提供する。本発明は、既存の病院システムと統合することができる。本発明は、検出サービスの需要の変化に適応することができる。

本発明の特定の態様は、ＤＩＣＯＭ装置からあるケースのＤＩＣＯＭ画像を受信し、その画像を適切な画像処理サーバにディスパッチするジョブ・ディスパッチャである。親ジョブ・ディスパッチャは、子ジョブ・ディスパッチャを作成し、ケースに関連する画像を受信すること、および画像をディスパッチすることを委譲する。複数の画像処理サーバがあるとき、子ジョブ・ディスパッチャは、所望の検出サービスを実行するための負荷が最も軽い画像処理サーバを選択する。

ジョブ・ディスパッチャの態様は、医療用インテリジェント・サーバ用コンピュータ上で動作しているディスパッチャ・サービスを含み、ディスパッチャは、１または複数の医療用撮像機器から患者のケースを動的に受け付け、１または複数の画像処理サーバへのケースの配布を管理し、ディスパッチャ・サービスは、
医療用撮像装置からの接続要求を検出すると、医療用撮像装置および画像処理サーバとの通信を管理するために、子ディスパッチャ・プロセスを個別のプロセスとして作成するジョブ・ディスパッチャ・プロセスと、
１または複数の画像処理サーバの動作状態情報および検出サービスの存在情報を管理する登録サービスであって、子ディスパッチャ・プロセスが、検出サービスを実行する旨の要求を受け付け、登録サービスで維持されている検出サービスの存在情報および状態情報に基づいて、患者のケースの要求されたサービスを実行する画像処理サーバを選択し、選択された画像処理サーバに患者のケースをディスパッチする登録サービスとを有する。

医療用撮像装置との通信を管理するために、ジョブ・ディスパッチャ・プロセスが子ディスパッチャ・プロセスを個別のプロセスとして作成するディスパッチャ・サービスであれば、医療用撮像装置への並列通信接続の数は、ジョブ・ディスパッチャを実行しているコンピュータ上のメモリ量によってのみ限定される。本発明のジョブ・ディスパッチャは、専用マシン上で稼働しているため、本発明は、患者のケースに基づいて多量のサービスの要求を処理することができる。

状態情報に基づいて画像処理サーバが選択されるように、登録サービスが１または複数の画像処理サーバの動作状態情報を管理するディスパッチャ・サービスであれば、動的なロード・バランシングが可能になる。したがって、入力側の可変数の要求側医療用撮像装置との通信を処理する子プロセスを作成し、登録サービスで維持されている状況に基づいて画像処理サーバに患者のケースをディスパッチすることによって、本発明は、サービスの需要の変化に適応可能である。

ディスパッチャ・サ―ビスの患者のケースは、１または複数の医療用画像ファイルを含み、子ディスパッチャ・プロセスの作成中、ジョブ・ディスパッチャ・プロセスは、要求側医療用撮像装置と通信するために、要求された接続のソケットを子ディスパッチャ・プロセスに割り当て、１または複数の医療用画像ファイルの画像ファイルを一時的に格納するために、専用ローカル・メモリを子ディスパッチャ・プロセスに割り振る。

専用ローカル・メモリの子ディスパッチャ・プロセスへの割り振りであれば、本発明は、ハード・ドライブへのアクセスが低減されて、より大きいスループットを達成することができる。各子ディスパッチャ・プロセスは個別のプロセスであるため、ディスパッチがジョブ・ディスパッチャ・プロセスの一部として実行された場合より、より多くのメモリを割り振ることができる。

ディスパッチャ・サービスにおいて、要求された接続のソケットが割り当てられると、子ディスパッチャ・プロセスは、接続の医療用撮像装置とのアソシエーションを受け付ける、または拒否するためのネゴシエーションを行い、アソシエーションが許可されると、子ディスパッチャ・プロセスは、画像ファイルを受信する。

子ディスパッチャ・プロセスが、医療用撮像装置とのアソシエーションのネゴシエーションを依頼されれば、ジョブ・ディスパッチャ・プロセスが他の通信接続の管理を迅速に進めることができる。したがって、本発明は、医療用撮像装置からの多数の通信接続要求を処理することができる。

ディスパッチャ・サービスの１または複数の医療用画像ファイルは、ジョブ・ディスパッチャ・プロセスとは独立して、医療用撮像装置から子ディスパッチャ・プロセスのメモリに直接送信される。

医療用撮像装置と子ディスパッチャ・プロセスのメモリとの間が直接接続であれば、子ディスパッチャ・プロセスの数に基づいて医療用画像ファイルの同時の受信が可能になる。

登録サービスから取得された状態情報は、画像処理サーバのキューにおけるケースの数、および同じ画像処理サーバによって現在処理中のケースの数に関する状況を含み、子ディスパッチャ・プロセスは、そのそれぞれのキューにおける処理中の最低数のケースを有する画像処理サーバに基づいて画像処理サーバを選択する。

画像処理サーバのキューにおけるケースの数、および現在処理中のケースの数に関する状況を維持する登録サービスであれば、本発明のディスパッチャ・サービスは、画像処理サーバ間で作業負荷のバランスをとる既知の方法で患者のケースをディスパッチすることができる。

子ディスパッチャ・プロセスのローカル・メモリは、専用キャッシュ・メモリであり、画像ファイルの数が所定の閾値を超える場合、子ディスパッチ・プロセスは、閾値量までの画像ファイルの数をキャッシュ・メモリに格納し、ディスパッチャに関連付けられているハード・ドライブに閾値量を超える画像ファイルを格納する。

子ディスパッチャ・プロセスのローカル・メモリが専用キャッシュ・メモリであれば、本発明は、かなりの数のディスク・アクセスなしに、画像ファイルを画像処理サーバに効率的にディスパッチすることができる。ほとんどの患者のケースでは、画像ファイルを取得するためのディスク・アクセスが少なくて済むことを理解されたい。

添付の図面を参照して、本発明をさらに詳しく説明する。本発明の実施形態は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓファミリのオペレーティング・システムおよび関連製品を使用して実施されている。したがって、本発明の以下の好ましい実施形態は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ用語を使用して説明する。いくつかのＵｎｉｘオペレーティング・システムの派生物（Ｓｕｎ ＯＳ、Ｍａｃ ＯＳＸ、Ｌｉｎｕｘなど）のうちの１つを実行するプラットフォーム、他のマルチタスキング・オペレーティング・システム、またはオペレーティング・システムの組合せは、本発明の他の実施形態として提供することができる。

用語および頭字語の定義
本説明を通じて使用される用語について、以下の定義を提供する。

アソシエーション（ＤＩＣＯＭプロトコル）：ＤＩＣＯＭ情報が交換される２つのＤＩＣＯＭアプリケーション間で確立される通信接続である。アソシエーションは、接続の開始より先に行われる。アソシエーションは、アソシエーションネゴシエーションと呼ばれるプロセスによって確立される。

グラフィカル・ユーザ・インターフェース（ＧＵＩ）：プログラムを使いやすくするために、コンピュータのグラフィック機能を利用するプログラム・インターフェースである。ＧＵＩの代替物と考えられるコンピュータ・プログラムへのユーザ・インターフェースは、コマンド駆動型インターフェースである。現在のＧＵＩは、ユーザが表示画面上のグラフィカル・オブジェクトを選択できるようにするポインタおよび関連のポインティング装置を有する。ＧＵＩは、コマンドを起動したり、表示を操作したりするなどの機能を有効にするアイコン、メニュー、スクロール・バーなどの機能要素を表示することができる。

メッセージ：動作中のプログラム間、装置間、および動作環境内に渡される情報の単位である。情報の単位は、１または複数のテキストの塊、制御文字、ヘッダー、およびエラーチェッキングまたは同期情報を含むことができる。

モジュール：関連のアプリケーション・プログラムおよびサービス・アプリケーションの集まりである。

サーバ：リソースを管理し、ネットワークにおける他のコンピュータによって使用できるサービス・アプリケーションを配信するネットワーク上のコンピュータまたは装置である。

スタディ（ＤＩＣＯＭ、またはケース）：病院、クリニック、他の診療所に行っている間に生成される画像モダリティの１組の画像についてのＤＩＣＯＭ用語である。

タスク（またはプロセス）：実行されているプログラムとオペレーティング・システムによって使用されるブックキーピング情報との組合せである。あるプログラムがコンピュータによって実行されるとき、オペレーティング・システムは、そのために新しいタスクを作成する。このタスクは、タスク番号によってプログラムを識別し、それに他のブックキーピング情報を添付するプログラムのラッパーを構成する。

転送構文（ＤＩＣＯＭ ＰＳ３．５ ２００４）：アプリケーション・エンティティが、サポートすることができる符号化技術（データ要素構造、バイト・オーダリング、圧縮など）を曖昧なところなくネゴシエーションでき、それによってこれらのアプリケーション・エンティティが通信することができる１組の符号化ルールである。

Ｗｉｎｄｏｗｓサービス（Ｍｉｃｒｏｓｏｆｔ登録商標）：それ自身のＷｉｎｄｏｗｓセッションにおいて長期間動作するように設計されている極めて専門的なタイプのアプリケーションである。Ｗｉｎｄｏｗｓサービスは、一般に、通常ユーザ・インターフェースなしに、ローカルに、またはネットワークで、背景プロセスとして動作する。例えば、ほとんどのサーバベースのアプリケーションは、サービスである。Ｗｉｎｄｏｗｓサービスは、Ｍｉｃｒｏｓｏｆｔ管理コンソールから開始することができる。

モダリティ：Ｃ−ＳＴＯＲＥ要求（別のシステムにデジタル画像を格納する旨の要求）を送信するＣＴ、ＭＲ、ＣＲ、超音波、および核医学のシステム、または撮像装置および機器である。モダリティは、関連の画像モダリティを有する。

モダリティ例：
ＡＳ＝血管内視鏡検査
ＢＩ＝生体磁気画像
ＣＤ＝カラー・フロー・ドップラー
ＣＰ＝膣鏡検査
ＣＲ＝コンピュータＸ線撮影
ＣＳ＝膀胱鏡検査
ＣＴ＝コンピュータ断層撮影
ＤＤ＝二重ドップラー
ＤＧ＝透光法
ＤＭ＝デジタル顕微鏡検査
ＤＳ＝デジタル・サブトラクション血管造影
ＤＸ＝デジタルＸ線撮影
ＥＣ＝心エコー検査
ＥＳ＝内視鏡検査
ＦＡ＝蛍光眼底血管造影
ＦＳ＝眼底検査
ＨＣ＝ハード・コピー
ＬＰ＝腹腔鏡検査
ＬＳ＝レーザー表面スキャン
ＭＡ＝磁気共鳴血管造影
ＭＲ＝磁気共鳴
ＭＳ＝磁気共鳴分光法
ＮＭ＝核医学
ＰＴ＝陽電子放射断層撮影（ＰＥＴ）
ＲＦ＝無線蛍光透視
ＲＧ＝Ｘ線画像（従来のフィルム画面）
ＲＴＤＯＳＥ＝放射線量
ＲＴＩＭＡＧＥ＝放射線治療画像
ＲＴＰＬＡＮ＝放射線治療計画
ＲＴＳＴＲＵＣＴ＝放射線治療構造体セット
ＳＴ＝単光子放射線コンピュータ断層撮影
ＴＧ＝サーモグラフィ
ＵＳ＝超音波
ＸＡ＝Ｘ線血管造影
ＸＣ＝外部カメラ
ＥＣＧ＝心電図
ＣＡＤ（コンピュータ支援検出）：疾病または病気の兆候徴候の可能性がある、医療用画像における領域を検出するように設計されているパターン認識アルゴリズムなどのアルゴリズムである。

ＤＩＣＯＭ：（医用デジタル画像および通信）。医療用撮像における情報を処理し、格納し、印刷し、送信する包括的な標準の組である。ＤＩＣＯＭは、フィルムフォーマット定義およびネットワーク通信プロトコルを含む。プロトコルは、システム間で通信するのにＴＣＰ／ＩＰを使用する。ＤＩＣＯＭファイルは、情報、すなわち画像および患者データをＤＩＣＯＭ形式で受信する機能を有する２つのエンティティ間で交換することができる。ｄｉｃｏｍ．ｎｅｍａ．ｏｒｇを参照されたい。

ＰＡＣＳ：（画像保存通信システム）。市販のＰＡＣＳは、入力モダリティ、ＤＩＣＯＭサーバ、ＰＡＣＳサーバ、アーカイブ・サーバ、Ｗｅｂサーバ、ＲＩＳ（放射線情報サーバ）、および放射線クライアントを含むアーキテクチャを提供する。

ＳＯＡＰ：（簡易オブジェクト・アクセス・プロトコル）。

医療用画像インテリジェント・サーバ（ＭＩＩＳ）
本発明のジョブ・ディスパッチャは、医療用画像インテリジェント・サーバ（ＭＩＩＳ）の一部である。医療用画像インテリジェント・サーバ（ＭＩＩＳ）は、専用のコンピュータ支援検出（ＣＡＤ）サーバと考えることができる。ＭＩＩＳは、医師および放射線専門医が医療診断を行うのに高度なアルゴリズムを使用するのを助けるためのサービスを提供する。ＭＩＩＳは、増加する患者を処理するために拡大することができ、新しいモダリティおよび身体部分に順応できるアーキテクチャを提供する。増加は、アップグレードしやすい拡張性のあるアーキテクチャによって対応される。

医療用画像インテリジェント・サーバは、癌などの疾病を正確に検出する高度化されたアルゴリズムによる高度なＣＡＤを提供し、次いで貴重な検出情報を提供する。ＭＩＩＳは、既存の病院システムおよびワークフロー、および新しい病院システムに適合するように設計されている。ＭＩＩＳは、柔軟性のあるアーキテクチャに基づいており、ＤＩＣＯＭ標準通信プロトコルを使用する。検出サービスは、大幅な遅延なしに行われる。内蔵されているＷｅｂサーバによって四六時中システム・アクセスおよび報告書の生成が可能になる。

ＣＡＤは、医師の補助に有用なツールであることがわかっている。例えば、ＣＡＤは、医師が後期の病気にかかっている患者を助けるのに役立っていた。ＭＩＩＳにより、容量を大きくしたり、ＣＡＤサービスの数およびタイプを増やしたりすることが容易にできる。

図１に、医療用画像インテリジェント・サーバの概念図が示されている。図１に示されているように、ＭＩＩＳは、ＤＩＣＯＭ互換装置から入力として画像を受信し、ＣＡＤ画像処理を行う。ＭＩＩＳ１００は、ジョブ・ディスパッチャ・モジュール２、少なくとも１つの画像処理サーバ３、およびコンソール４を含む。ＭＩＩＳのジョブ・ディスパッチャ・モジュール２は、ＤＩＣＯＭ Ｃ−Ｓｔｏｒｅサービスを介してＤＩＣＯＭ装置１（簡潔にするために示されているのは１つ）から画像を受信し、その画像を画像処理サーバ３（簡潔にするために示されているのは１つ）に送信することができる。コンソール４は、グラフィカル・ユーザ・インターフェースをＭＩＩＳに提供する。

大規模な病院システムのスループット要件は、単一のサーバが提供できる能力をはるかに超えている。ＭＩＩＳは、画像処理サーバを追加し、適した性能に到達するようにその作業負荷を調整する能力を提供する。ジョブ・ディスパッチャ・モジュール２は、より大きいスループットの要求を満たすために、ＭＩＩＳの拡張性を容易にする。

ジョブ・ディスパッチャ・モジュール
本発明のジョブ・ディスパッチャは、必要な容量の変化を容易にする。ジョブ・ディスパッチャは、増加する検出サービスに対応することができるシステムにおいて、入力側での要求に応じて検出サービスの可変数の要求を並行して管理することができ、出力側の可変数の処理サーバ間で作業負荷のバランスをとるようにジョブをディスパッチすることができる。

図２は、本発明のジョブ・ディスパッチャ・モジュール２の概略図を示している。ジョブ・ディスパッチャ・モジュール２は、サービス・アプリケーション（ジョブ・ディスパッチャ・サービス１１）として提供されたジョブ・ディスパッチャ、および登録サービス１３を含む。ジョブ・ディスパッチャ・サービス１１は、入ってくる各ＤＩＣＯＭアソシエーションを処理するために、１または複数の子プロセス（ＳｔｕｄｙＨａｎｄｌｅｒ１２と呼ぶ）を開始する。ＳｔｕｄｙＨａｎｄｌｅｒ１２は、アソシエーションネゴシエーションを実行し、受信されたＤＩＣＯＭ画像を格納し、登録サービス１３によって維持されている情報に基づいて、受信された画像の選択された画像処理サーバ３へのディスパッチを管理する。

ＭＩＩＳ１００における各画像処理サーバ３は、画像処理サーバ３が処理することができる検出サービス、および検出サービスの場所を提供することによって、登録サービス１３に登録することができる。また、画像処理サーバ３は、登録サービス１３にその現在の作業負荷の状況を知らせる。ＳｔｕｄｙＨａｎｄｌｅｒ１２プロセスは、作業負荷状況、および要求された検出サービスを処理することができる情報処理サーバの情報に基づいて、受信されたＤＩＣＯＭ画像をディスパッチする。

図３は、ＭＩＩＳ１００におけるジョブ・ディスパッチャ・モジュール２の役割を示している。画像処理サーバ３は、登録サービス１３にその動作状況を知らせ、必要に応じてその状況を更新する（「レジスタ／状況更新」）。主要なジョブ・ディスパッチャ・サービス１１は、ＤＩＣＯＭ装置１からの入ってくる接続要求をリッスンし、接続（ＤＩＣＯＭプロトコル）を受け付けると、ＳｔｕｄｙＨａｎｄｌｅｒ１２プロセス（「開始」）を開始し、アソシエーションの管理を渡す。ＳｔｕｄｙＨａｎｄｌｅｒ１２は、アソシエーションのネゴシエーションを行い、アソシエーションを受け付けるかまたは拒否する。アソシエーションを受け付けると、ＳｔｕｄｙＨａｎｄｌｅｒ１２は、ＤＩＣＯＭ画像を受信し、格納する（「画像の送信」）。画像処理サーバの数および作業負荷に応じて、ＳｔｕｄｙＨａｎｄｌｅｒ１２は、画像処理サーバを選択し、検出サービスを行うために、選択された画像処理サーバにケースの画像をディスパッチする（「ディスパッチ」）。

図４は、図３のジョブ・ディスパッチャ・モジュールのワークフロー例を示す。ＤＩＣＯＭ装置は、ＤＩＣＯＭ画像の格納のための接続を要求するために、ＤＩＣＯＭプロトコルを使用して、ジョブ・ディスパッチャ・サービス１１と通信する（「接続」）。ジョブ・ディスパッチャ・サービス１１は、要求を受信し、接続を構築し、ＤＩＣＯＭ装置に接続を知らせる。ＤＩＣＯＭ装置から確認応答が受信され、ジョブ・ディスパッチャ・サービスは、接続を確認するために、最終応答を送信する。次いで、ジョブ・ディスパッチャ・サービス１１は、アソシエーションの管理を委譲するために、ＳｔｕｄｙＨａｎｄｌｅｒ１２プロセスを開始する。一実施形態では、ジョブ・ディスパッチャ・サービス１１は、パラメータ「ソケットＩＤ」がアソシエーションの通信ポートに設定されている状態で、「ＣｒｅａｔｅＰｒｏｃｅｓｓ」などのメソッドを呼び出す。その後、ＳｔｕｄｙＨａｎｄｌｅｒ１２が開始すると、ＳｔｕｄｙＨａｎｄｌｅｒ１２は、アソシエーションの制御を受け継ぎ、アソシエーションを受け付ける、または拒否するためのネゴシエーションを行う（「アソシエーション要求」）。提案された検出サービスを受け付けると、アソシエーションが確立される（「アソシエーションの受け付け」）。ＤＩＣＯＭ装置は、格納されるべき画像をサブミットし（「格納要求」）、ＳｔｕｄｙＨａｎｄｌｅｒ１２は、格納が完了した旨のメッセージで応答する（「応答の送信」）。ＳｔｕｄｙＨａｎｄｌｅｒ１２は、必要な検出サービスを提供することができる画像処理サーバの情報を要求するメッセージを登録サービスに送信する（「サービスＵＲＬの検出」）。画像処理サーバを選択すると、ＳｔｕｄｙＨａｎｄｌｅｒ１２は、検出サービスを行う（「サービスの実行」）ために、画像処理サーバ３へのディスパッチを行う。

ＤＩＣＯＭ装置１との新しい接続が確立されると、新しいＳｔｕｄｙＨａｎｄｌｅｒ１２プロセスを開始し、ＭＩＩＳで並行して実行することができる。ジョブ・ディスパッチャ・サービス１１は、開始されるＳｔｕｄｙＨａｎｄｌｅｒ１２子プロセスの数を監視し、制御の責任を負う。

ＳｔｕｄｙＨａｎｄｌｅｒ
各ＳｔｕｄｙＨａｎｄｌｅｒには、専用のキャッシュ・メモリを含めて、それ自身のリソースが備えられている。新しいアソシエーションごとに子プロセスを作成することによって、多数のＤＩＣＯＭ画像をジョブ・ディスパッチャ・モジュールによって処理することができる。各子プロセスは、キャッシュ・メモリを含めて、それ自身の専用リソースを有しているため、多数のＤＩＣＯＭ画像を、高スループット・レートで、ハード・ドライブ・アクセスからの遅延なく、画像処理サーバに配布することができる。並行して処理することができる画像の数は、主に、ジョブ・ディスパッチ・モジュールを実行しているマシンにおけるメイン・メモリのサイズによって制限される。並行して処理できるアソシエーションの数は、ネットワーク帯域幅、プロセッサ速度、および使用可能な物理メモリの量によって制限される。

ＳｔｕｄｙＨａｎｄｌｅｒ１２は、以下の理由でアソシエーションを拒否することができる（「アソシエーションの拒否」）。１）画像処理サーバが現在登録されていない、２）ライセンス情報が使用不可であるか、ライセンスが無効であるか、またはライセンスが期限切れであるために、使用許可の認証に失敗した、３）接続数がその許容最大数に到達したためにＭＩＩＳがビジーである、または４）内部サーバ・エラーがある。ジョブ・ディスパッチャ・サービスが処理できる並列アソシエーション数は、ＭＩＩＳが動作しているマシンの能力によって決まる。

ＳｔｕｄｙＨａｎｄｌｅｒ１２は、このアソシエーションネゴシエーションを行うとともに、メッセージを受信し、スタディをディスパッチする責任がある（上記で定義したように、スタディは、ケースの代わりのＤＩＣＯＭ用語であり、ケースは、患者が診察室に行っている間に得られる画像の組である）。特に、ＳｔｕｄｙＨａｎｄｌｅｒは、受信されたＤＩＣＯＭオブジェクトを検査して、画像処理サーバが処理する必要な属性値を有することを確認する。図５は、アソシエーションネゴシエーションおよびメッセージの受信のワークフロー例を示す。ステップＳ−１で、ＳｔｕｄｙＨａｎｄｌｅｒは、要求されたサービス（すなわち、モダリティに関連する検出サービス）およびプレゼンテーション・コンテキストが受諾可能な場合、アソシエーションを受け付ける。各ＳｔｕｄｙＨａｎｄｌｅｒは、標準プレゼンテーション・コンテキストに従って提供された情報を信頼してアソシエーションネゴシエーションを処理する。そうでない場合、ステップＳ−７でアソシエーションは中止され、ＳｔｕｄｙＨａｎｄｌｅｒプロセスが停止する。表１は、プレゼンテーション・コンテキストの例を示している。
プレゼンテーション・コンテキスト表

アソシエーションが受け付けられた場合、ステップＳ−２、Ｓ−３、およびＳ−４で、ＳｔｕｄｙＨａｎｄｌｅｒは、メッセージを受信し、確認する。受信プロセスをスピード・アップするために、ステップＳ−５で、ＳｔｕｄｙＨａｎｄｌｅｒは、まず、受信した画像をメモリにキャッシュし、ハード・ドライブ・アクセスを回避しようとする。キャッシュに入れることができる画像数の閾値を超えると、ステップＳ−６で、画像がハード・ドライブに書き込まれる。ステップＳ−８で、ＳｔｕｄｙＨａｎｄｌｅｒは、応答メッセージを送信する。

登録サービス１３は、画像処理サーバの情報を保持し、管理する。情報は、画像処理サーバが提供する検出サービス、画像処理サーバによって各サービスを要求するのに必要なプロセスおよびプロトコル、および画像処理サーバの位置（ローカル・マシン、ＩＰアドレスなど）を含む。

画像処理サーバ３は、サービス・グループのメンバとなる前に、登録サービス１３に登録する必要がある。ジョブ・ディスパッチャ・モジュールのＳｔｕｄｙＨａｎｄｌｅｒ１２は、検出サービスを実行する画像処理サーバ３を選択できるように、登録情報を取り出す。保管された情報は、例えば画像処理サーバの追加／削除や検出サービスの追加／アップグレードなど、システム構成が変わると更新される必要がある。

複数の画像処理サーバ３が要求されたサービスを処理できる場合、ＳｔｕｄｙＨａｎｄｌｅｒ１２は、登録サービス１３において、ロード・バランシングを行い、（複数の画像処理サーバが登録されていると仮定して）負荷が最も軽い画像処理サーバのサービスＵＲＬを取得し、受信されたスタディを選択された画像処理サーバ３にディスパッチする関数を呼び出す。複数のケースが受信された場合、ＳｔｕｄｙＨａｎｄｌｅｒ１２は、プロセスを繰り返し、一度に１つのケースを送信する。優先順位ＩＰリストで画像が受信された場合、ケースは、ディスパッチするときに高い優先順位に設定される。

各ＳｔｕｄｙＨａｎｄｌｅｒ１２は、ＤＩＣＯＭを外部装置と通信するためのその通信プロトコルとして使用する。ＭＩＩＳ内の内部通信の場合、各ＳｔｕｄｙＨａｎｄｌｅｒ１２は、ＭＩＩＳ内部の構成要素と通信するために、ＳＯＡＰを使用する。

一実施形態において、ＭＩＩＳコンソール４は、サーバ構成ページを表示する。図６に示されているように、管理者は、サーバ構成ページによってジョブ・ディスパッチャの設定を変更することができる。例えば、管理者は、ＤＩＣＯＭ準拠装置からの受信ストリームのタイトル、ジョブ・ディスパッチャがリッスンしているポート、および受信されたオブジェクトが保存されるハード・ドライブ上のディレクトリを指定することができる。管理者は、ストレージ・オプション、およびログに記録されるべき情報のレベルを指定することができる。管理者は、ワークステーション、またはジョブをＭＩＩＳにサブミットする他のソースの優先順位を設定することができる。

登録サービス
ジョブ・ディスパッチャ・モジュールの登録サービス１３は、画像処理サーバ３が、画像処理サーバによって提供されたサービスを登録したり、画像処理サーバの状況を報告したりすることができるリッスン・モードで動作する。例えば、画像処理サーバ３は、実行されているサービスの数、および現在キューにあり、実行を待っている診断ジョブの数を報告することができる。登録サービス１３は、登録されている各画像処理サーバの状態情報を維持する。

登録サービスの関数
状態情報を維持するために、登録サービスは、以下を含めて、ＭＩＩＳの管理関数を提供する。

画像処理サーバ：画像処理サーバによって呼び出すことができる関数が利用できる。

ＲＥＧＩＳＴＥＲ（ＵＮ−ＲＥＧＩＳＴＥＲ）：画像処理サーバは、画像処理サーバが、ＳｔｕｄｙＨａｎｄｌｅｒの画像ディスパッチ・サービスへの加入／加入中止を行うことができるようにする関数ＲｅｇｉｓｔｅｒまたはＵｎ−ｒｅｇｉｓｔｅｒ Ｓｅｒｖｅｒを呼び出す。Ｒｅｇｉｓｔｅｒ関数により提供される情報は、サービス名およびサービスＵＲＬをそれぞれ有するサポートされたサービスのリストを含む。

ＵＰＤＡＴＥ ＳＴＡＴＵＳ：画像処理サーバは、画像処理サーバが、処理中のケースの数、およびキューで待機しているケースの数を含めて、状態情報を更新することができる関数Ｕｐｄａｔｅ Ｓｔａｔｕｓを呼び出すことができる。

ＥＶＥＮＴ：画像処理サーバは、イベントを報告する関数を呼び出すことができる。

スタディ・ハンドラ：登録サービスは、ＳｔｕｄｙＨａｎｄｌｅｒの管理関数を提供する。

ＦＩＮＤ ＳＥＲＶＥＲ：関数は、ＳｔｕｄｙＨａｎｄｌｅｒがサービス名によって画像処理サーバを検索するのに利用できる。この関数に応答して、最も軽い負荷が一番上に来るように、現在の負荷によってソートされた画像処理サーバのリストが提供される。サーバの負荷は、仮想プロセッサごとに待機しているケースの平均数として定義される。

負荷＝（Ｑ＋Ｅ）／Ｖ
式中、Ｑは、キューで待機しているケースの数、Ｅは、処理中のケースの数、Ｖは、装備された仮想プロセッサの数である。

ＧＥＴ ＳＥＲＶＩＣＥ ＵＲＬ：関数は、サーバ名およびサービス名が与えられた場合、サービスＵＲＬを取得するのに利用できる。

ＧＥＴ ＳＴＡＴＵＳ：関数は、画像処理サーバの状況を取得するのに利用できる。この関数は、処理中のケースの数、およびキューで待機しているケースの数を戻す。

ＧＥＴ ＳＥＲＶＩＣＥＳ：関数は、登録されている画像処理サーバの使用可能なサービスのリストを取得するのに利用できる。

コンソール：コンソール４は、登録サービスから情報の取り出しを可能にするグラフィカル・ユーザ・インターフェースを提供する。

コンソールは、ある期間にわたって起こったイベントのリストを取り出すＧＥＴ ＥＶＥＮＴ ＬＯＧ、現在のジョブ・ディスパッチャ構成設定を取り出し、送信するＧＥＴ ＪＯＢ ＤＩＳＰＡＴＣＨＥＲ ＣＯＮＦＩＧＵＲＡＴＩＯＮ、ジョブ・ディスパッチャを呼び出し、メモリ内の内部パラメータ値を更新するＣＨＡＮＧＥ ＪＯＢ ＤＩＳＰＡＴＣＨＥＲ ＣＯＮＦＩＧＵＲＡＴＩＯＮ、登録された画像処理サーバの数を取得するＧＥＴ ＮＵＭＢＥＲ ＯＦ ＲＥＧＩＳＴＥＲＥＤ ＳＥＲＶＥＲＳ、現在のライセンス情報を取得するＧＥＴ ＬＩＣＥＮＳＥ ＩＮＦＯを含む関数を提供する。

本発明は、詳細に説明され図示されてきたが、これは例示および図示の手段にすぎず、制限の手段と理解されるのではなく、本発明の精神および範囲は、添付の特許請求の範囲の用語によってのみ制限されることが明白に理解される。

医療用画像インテリジェンス・サーバ（ＭＩＩＳ）を示すブロック図である。 ジョブ・ディスパッチャ・モジュールの一般のアーキテクチャを示す図である。 ＭＩＩＳ内のジョブ・ディスパッチャ・モジュールの情報フローを示す図である。 ジョブ・ディスパッチャ・モジュールのワークフロー図である。 スタディ・ハンドラのフロー図である。 ジョブ・ディスパッチャ・サービスのコンソールのユーザ・インターフェース例を示す図である。

Claims (13)

1. 医療用インテリジェント・サーバ用コンピュータ上で動作しているディスパッチャ・サービスであって、前記ディスパッチャが、１または複数の医療用撮像装置から患者のケースを動的に受け付け、１または複数の画像処理サーバへの前記ケースの配布を管理し、前記ディスパッチャ・サービスが、
   医療用撮像装置からの接続要求を検出すると、医療用撮像装置および画像処理サーバとの通信を管理するために、子ディスパッチャ・プロセスを個別のプロセスとして作成するジョブ・ディスパッチャ・プロセスと、
   前記１または複数の画像処理サーバの動作状態情報および検出サービスの存在情報を管理する登録サービスと、
   を含み、前記子ディスパッチャ・プロセスが、検出サービスを実行する旨の要求を受け付け、前記登録サービスで維持されている前記検出サービスの前記存在および前記状態情報に基づいて、患者のケースの前記要求されたサービスを実行する画像処理サーバを選択し、前記選択された画像処理サーバに前記患者のケースをディスパッチするディスパッチャ・サービス。
2. 患者のケースが、１または複数の医療用画像ファイルを含み、前記子ディスパッチャ・プロセスの作成中、前記ジョブ・ディスパッチャ・プロセスが、要求側医療用撮像装置と通信するために、前記要求された接続のソケットを前記子ディスパッチャ・プロセスに割り当て、前記１または複数の医療用画像ファイルの画像ファイルを一時的に格納するために、専用ローカル・メモリを前記子ディスパッチャ・プロセスに割り振る請求項１に記載のディスパッチャ・サービス。
3. 通信接続が割り当てられると、前記子ディスパッチャ・プロセスは、前記接続の前記医療用撮像装置とのアソシエーションを受け付けるかまたは拒否するためのネゴシエーションを行い、前記アソシエーションが許可されると、前記子ディスパッチャ・プロセスは、前記画像ファイルを受信する請求項２に記載のディスパッチャ・サービス。
4. 前記１または複数の医療用画像ファイルが、前記ジョブ・ディスパッチャ・プロセスから独立して、前記医療用撮像装置から前記子ディスパッチャ・プロセスの前記メモリに直接送信される請求項２に記載のディスパッチャ・サービス。
5. 前記登録サービスから取得された前記状態情報が、画像処理サーバのキューにおけるケースの数、および前記同じ画像処理サーバによって現在処理中のケースの数に関する状況を含み、前記子ディスパッチャ・プロセスが、各キューにおける処理中の最低数のケースを有する前記画像処理サーバに基づいて画像処理サーバを選択する請求項１に記載のディスパッチャ・サービス。
6. 前記子ディスパッチャ・プロセスの前記ローカル・メモリが、専用キャッシュ・メモリであり、画像ファイルの数が所定の閾値を超える場合、前記子ディスパッチ・プロセスが、閾値量までの画像ファイルの数を前記キャッシュ・メモリに格納し、前記ディスパッチャに関連付けられているハード・ドライブに前記閾値量を超える画像ファイルを格納する請求項１に記載のディスパッチャ・サービス。
7. 検出サービスの要求を動的に受け付け、複数の画像タイプのコンピュータ支援検出を実行することができる１または複数の画像処理サーバへの前記要求の配布を管理する、処理システムにおいて実行されるディスパッチャであって、
   コンピュータ支援検出サービスの要求を検出し、要求を受信すると接続を確認応答し、前記要求を確認応答すると、子ジョブ・ディスパッチャ・プロセスを開始するジョブ・ディスパッチャ・プロセスと、
   １または複数のコンピュータ支援検出サービス・アプリケーションの１または複数の画像処理サーバから登録情報を受信し、画像処理サーバにおける実行に割り当てられるコンピュータ支援検出サービス・アプリケーションの数を含む状態情報を受信し、前記状態情報を子ジョブ・ディスパッチャ・プロセスに提供する登録サービスと、
   を含み、前記子ジョブ・ディスパッチャ・プロセスを作成すると、前記子ジョブ・ディスパッチャ・プロセスが、１または複数の画像ファイルを受信し、前記登録サービスから状態情報を取得し、前記画像ファイルに含まれている前記画像タイプのコンピュータ支援検出サービスを実行する能力、および前記登録サービスから取得された状態情報に基づいて、前記画像ファイルを画像処理サーバにディスパッチするディスパッチャ。
8. サーバ・コンピュータで実行されるディスパッチャであって、前記サーバ・コンピュータが、ヘッダー情報および画像データをそれぞれ単一のファイルに含める１または複数の医療用画像ファイルをそれぞれ有する複数の患者のケースを受信し、前記ヘッダー情報に示されているように、前記画像データの前記画像タイプに基づいて、それぞれのコンピュータ支援検出サービスを実行し、前記ディスパッチャが、
   接続の要求を検出すると、子ディスパッチャ・プロセスを作成し、前記接続のアソシエーションを管理する責任を前記子ディスパッチャ・プロセスに委譲し、ローカル専用ストレージを前記子ディスパッチャ・プロセスに割り振るジョブ・ディスパッチャ・プロセスであって、前記子ディスパッチ・プロセスが、前記接続を介して１または複数の患者のケースを受信するジョブ・ディスパッチャ・プロセスと、
   少なくとも１つの画像処理サーバの動作状態情報および検出サービスのタイプを管理する登録サービスと、
   を含み、各子ディスパッチャ・プロセスがそれぞれの患者のケースの画像ファイルを管理するように、前記各子ディスパッチャ・プロセスが、前記動作状態情報、および検出サービスのタイプに基づいて、それぞれの患者のケースの画像ファイルを前記少なくとも１つの画像処理サーバにディスパッチするディスパッチャ。
9. 各子ディスパッチャ・プロセスが、それぞれのアソシエーションを受け付ける、または拒否する責任を負う請求項８に記載のディスパッチャ。
10. 各子ディスパッチャ・プロセスが、現在の処理負荷を示す前記登録サービスから取得された状態情報、および画像処理サーバごとの使用可能な検出サービスに基づいて、複数の画像処理サーバのうちの１つを選択し、前記選択された画像処理サーバが処理負荷が最も軽いものである請求項８に記載のディスパッチャ。
11. 複数の患者のケースの画像ファイルを、前記画像ファイルに基づいてコンピュータ支援検出を行う１または複数の画像処理サーバにディスパッチする方法であって、前記方法が、ジョブ・ディスパッチャ・サービスおよび登録サービスを含むサーバ・コンピュータによって実行され、前記ジョブ・ディスパッチャ・サービスが、前記登録サービスから取得された動作状況の情報および検出サービスのタイプに基づいて、画像ファイルをディスパッチし、前記方法が、
    外部装置との接続を形成する旨の要求を検出することと、
    前記外部装置との接続を形成すると、前記ジョブ・ディスパッチャ・サービスから子ディスパッチャ・プロセスを作成することと、
    前記要求された接続のソケットを前記子ディスパッチャ・プロセスに割り当て、前記接続のアソシエーションを確立することと、
    ヘッダー情報および画像データをそれぞれ有する画像ファイルを受信し、前記画像ファイルを前記子ディスパッチャ・プロセスの専用メモリに格納することと、
    処理負荷に基づいて検出サービスを行うために、前記画像ファイルを画像処理サーバにディスパッチすることと、
    前記検出サービスの結果を表示するために表示装置に送信することと、
    を含む方法。
12. 画像処理サーバの作業負荷の前記動作状態情報を更新し、作業負荷の前記更新された状態情報に基づいて、前記画像ファイルを情報処理サーバにディスパッチすることをさらに含む請求項１１に記載の画像ファイルをディスパッチする方法。
13. 複数の患者のケースの画像ファイルを、前記画像ファイルに基づいてコンピュータ支援検出を行う１または複数の画像処理サーバにディスパッチする方法であって、前記方法が、ジョブ・ディスパッチャ・サービス、および登録サービスを有するサーバ・コンピュータによって実行され、前記ジョブ・ディスパッチャ・サービスが、前記登録サービスから取得された動作状況の情報および検出サービスのタイプに基づいて、画像ファイルをディスパッチし、前記方法が、
    外部装置との接続を形成する旨の複数の要求を検出することと、
    前記ジョブ・ディスパッチャ・サービスから、前記接続ごとに子ディスパッチャ・プロセスを１つずつ、複数の子ディスパッチャ・プロセスを作成することと、
    要求されたそれぞれの接続のソケットを前記それぞれの子ディスパッチャ・プロセスに割り当て、前記接続のアソシエーションを確立することと、
    前記それぞれの接続を介して画像ファイルを受信し、前記画像ファイルを前記対応する子ディスパッチャ・プロセスの専用メモリに格納することと、
    責任を負う子ディスパッチャ・プロセスが、作業負荷に基づいて、１または複数の患者のケースの画像ファイルを処理する画像処理サーバを選択することと、
    それぞれの子ディスパッチャ・プロセスが、検出サービスを行うために、前記画像ファイルを前記対応する選択された画像処理サーバにディスパッチすることと、
    前記検出サービスの結果を表示するために表示装置に送信することと、
    を含む方法。

Images