JP2010245862A - 医用画像処理装置 - Google Patents

Abstract

【課題】シンクライアントシステム環境下において、サーバの負荷を低減する。
【解決手段】ダウンロード制御部１ｄは、記憶部１ｂに記憶されている検査スケジュールを読み込み、読み込んだ検査スケジュールと、画像処理負荷、サーバにおける画像処理可能負荷、クライアント端末の処理能力などに基づいて、画像処理不可能な検査情報があるか否かを判断する。ダウンロード制御部１ｄは、画像処理不可能な検査情報があると判断した場合、サーバに代わって画像処理することが可能な送信先を決定し、決定した送信先を検査スケジュールの一覧に追加する。ダウンロード制御部１ｄは、送信先が追加された検査スケジュールに基づいて、送信可能になった検査情報に対応する画像データおよび画像診断／表示アプリケーションを読み出し、アプリケーション処理用画像送信部１ｅを介して所定のクライアント端末にダウンロードする。
【選択図】図３

Description

本発明は、医用画像処理装置に関し、特に、シンクライアントシステム環境下において、サーバの負荷を低減することができるようにした医用画像処理装置に関する。

医療分野において、MRI（Magnetic Resonance Imaging）装置やＸ線CT（Computed Tomography）装置などで撮影された画像は、ネットワークを介して接続されたPACS（Picture Archiving Communication System）に送信され、そこで集中管理される。

医用画像診断装置は、画像の読影を行うためのビューアと呼ばれる機能を用いて、PACSからネットワークを介して画像を取得し、その画像を表示することができる。

特許文献１には、効率的に画像データの検索および読影を行うことができるようにするために、画像データを画像表示条件毎に区分けする技術が提案されている。

特開２００６−２８０５９８号公報

近年、シンクライアントシステムと呼ばれる技術が提案されており、この技術によれば、クライアントサーバに、全てのデータおよびクライアント端末からの要求に従ってデータ処理するためのアプリケーションが記憶され、クライアント端末に、クライアントサーバで処理された結果を表示させるためのブラウザソフトウェアが記憶される。

このようなシンクライアントシステムを医療分野に適用した場合、複数の医用画像診断装置で同時に診断を行うといった状況下では、サーバ側となるPACSは、複数のアプリケーションを同時に実行させる必要があり、処理の負荷が高くなるという課題があった。

上述した特許文献１の技術では、シンクライアントシステム環境下ではないため、当然、サーバの負荷も考慮されていない。

本発明はこのような状況に鑑みてなされたものであり、その目的は、シンクライアントシステム環境下において、サーバの負荷を低減することができるようにした医用画像処理装置を提供することである。

請求項１記載の発明の特徴は、クライアント端末とネットワークを介して接続される医用画像処理装置において、医用画像および医用画像で必要なアプリケーションを記憶する記憶手段と、検査スケジュールに基づいて処理負荷を予測し、その予測結果に基づいて、医用画像に対する画像処理をクライアント端末で行うか否かを判断する制御手段とを備える。

請求項４記載の本発明の特徴は、クライアント端末とネットワークを介して接続される医用画像処理装置において、医用画像および医用画像で必要なアプリケーションを記憶する記憶手段と、検査スケジュールに基づいて処理負荷を予測し、その予測結果に基づいて、記憶手段から、医用画像および医用画像で必要なアプリケーションのうちの少なくとも一方を読み出し、クライアント端末にダウンロードするダウンロード制御手段とを備える。

本発明によれば、シンクライアントシステム環境下において、サーバの負荷を低減することができるようにした医用画像処理装置を提供することができる。

シンクライアントシステムの構成例を示す図である。 検査スケジュールに登録される情報例を示す図である。 医用画像アプリケーションサーバの機能構成例を示すブロック図である。 記憶部に記憶される情報例を示す図である。 画像処理負荷のテーブルの情報例を示す図である。 画像処理可能負荷のテーブルの情報例を示す図である。 装置性能情報のテーブルの情報例を示す図である。 サーバ負荷低減処理を説明するフローチャートである。 検査スケジュールに追加される情報例を示す図である。 サーバ負荷低減処理後の結果例を示す図である。 ダウンロード処理を説明するフローチャートである。

以下、本発明の実施の形態について図面を参照して詳細に説明する。

図１は、本発明に係るシンクライアントシステムの構成例を示す図である。

シンクライアントシステムとは、クライアントサーバとクライアント端末から構成されるシステムのことである。クライアントサーバには、全てのデータと、このデータをクライアント端末からの要求に従って処理するためのアプリケーションとが記憶され、クライアント端末には、クライアントサーバにアプリケーションを実行させるとともに、その実行結果を閲覧するためのブラウザソフトウェアが記憶される。

図１に示すシンクライアントシステムでは、クライアントサーバである医用画像アプリケーションサーバ１、クライアント端末である医用画像診断装置２−１乃至２−３の他、検査スケジュール管理装置３、および画像撮影装置４がネットワーク５を介して接続されている。

医用画像アプリケーションサーバ１は、CPU（Central Processing Unit）、ROM（Read Only Memory）、RAM（Random Access Memory）、およびHDD（Hard Disc Drive）などを実装したコンピュータシステムで構成される。医用画像アプリケーションサーバ１は、画像撮影装置４からネットワーク５を介して取得した医用画像データを記憶するとともに、その医用画像データで必要なアプリケーションを記憶する。以下、医用画像データを、画像データと略記する。

医用画像アプリケーションサーバ１は、検査スケジュール管理装置３に対して検査スケジュールの送信を要求し、その要求に基づいてネットワーク５を介して送信されてきた検査スケジュールを受信する。医用画像アプリケーションサーバ１は、受信した検査スケジュールからサーバの負荷を予測し、サーバにおいて画像処理可能な検査情報と画像処理不可能な検査情報を判断する。

サーバにおいて画像処理不可能な検査情報があると判断した場合、医用画像アプリケーションサーバ１は、予め取得した医用画像診断装置２−１乃至２−３の装置性能情報（処理能力）に基づいて、サーバに代わって医用画像に対する画像処理を行うことが可能なクライアント端末を決定する。医用画像アプリケーションサーバ１は、画像処理不可能な検査情報が送信可能になった場合（例えば、撮影が終了して画像データとして蓄積された場合）、検査情報に対応する画像データおよびその画像データで必要な画像診断／表示アプリケーションを読み出し、送信先の医用画像診断装置２−１乃至２−３にダウンロード（転送）する。

一方、サーバにおいて全て画像処理可能であると判断した場合、医用画像アプリケーションサーバ１は、画像診断／表示アプリケーションを実行して画像データを画像処理する。

また医用画像アプリケーションサーバ１は、医用画像診断装置２−１乃至２−３からの要求に基づいて、画像処理結果および画像診断／表示のためのGUI（Graphical User Interface）データを、ネットワーク５を介して医用画像診断装置２−１乃至２−３に送信する。

医用画像診断装置２−１乃至２−３は、Ｘ線CT（Computed Tomography）装置、超音波画像診断装置、またはMRI（Magnetic Resonance Imaging）装置などで構成される。医用画像診断装置２−１乃至２−３は、操作者による図示せぬ入力部からの指示に応じて、医用画像アプリケーションサーバ１で管理されている画像診断／表示アプリケーションを実行するように要求する。医用画像診断装置２−１乃至２−３は、医用画像アプリケーションサーバ１から送信された、画像処理結果および画像診断／表示のためのGUIデータを取得し、図示せぬ表示部に表示させる。

また医用画像診断装置２−１乃至２−３は、医用画像アプリケーションサーバ１からネットワーク５を介してダウンロードされた、画像データおよび対応する画像診断／表示アプリケーションを受信したとき、受信した画像診断／表示アプリケーションを実行して画像データを画像処理し、その処理結果を表示する。

検査スケジュール管理装置３は、操作者によって図示せぬ入力部が操作され、各種検査の情報が登録されることにより、例えば、図２に示すような検査スケジュールを作成し、管理する。

図２の例では、受付時間、撮影開始時間、診断開始時間、および診断方法の項目からなる検査スケジュールの一覧が示されている。受付時間の項目には、受診者が検査の受付を行う予約時間が登録され、撮影開始時間の項目には、受診者が撮影を開始する予定時刻が登録され、診断開始時間の項目には、受診者が診断を開始する予定時刻が登録され、診断方法の項目には、撮影した画像に基づいて医師が行う診断方法が登録されている。

なお、検査スケジュールに登録される項目は、受付時間、撮影開始時間、診断開始時間、および診断方法に限られるものではなく、検査に関連するさまざまな項目（例えば、撮影場所、診断場所、画像データの蓄積先）が登録される。

検査スケジュール管理装置３は、医用画像アプリケーションサーバ１からの送信要求に基づいて、ネットワーク５を介して医用画像アプリケーションサーバ１に対して検査スケジュールを送信する。

なお、検査スケジュールは、検査スケジュール管理装置３で管理するだけでなく、医用画像アプリケーションサーバ１で管理するようにしてもよい。

画像撮影装置４は、Ｘ線画像、超音波画像、血管造影画像などの撮影を行う装置である。画像撮影装置４は、撮影した画像データを、ネットワーク５を介して医用画像アプリケーションサーバ１に送信する。

ネットワーク５は、公衆回線網、ローカルエリアネットワーク、またはインターネットなどのネットワーク、デジタル衛星放送といった、有線または無線のいずれのものでもよい。

以下において、医用画像診断装置２−１乃至２−３を個々に区別する必要が無い場合、単に医用画像診断装置２と称する。また、医用画像診断装置２の数は任意であり、図１に示されるように３つに限られるものではない。

図３は、医用画像アプリケーションサーバ１の機能構成例を示すブロック図である。

検査スケジュール受信部１ａは、検査スケジュール管理装置３からネットワーク５を介して送信されてきた、図２に示したような検査スケジュールを受信し、それを記憶部１ｂに記憶させる。

記憶部１ｂは、大容量のHDDで構成され、例えば、図４に示すように、検査スケジュール一覧の他、画像登録処理部１ｃによって登録される画像群、画像処理で必要な画像診断／表示アプリケーションなどを記憶する。なお、ネットワーク５を介して接続されている医用画像診断装置２の処理状況（実行中のアプリケーション、CPU使用率、およびメモリ使用量など）を受信して、記憶部１ｂに記憶させるようにしてもよい。この記憶部１ｂが、検査情報に対応する画像データおよび画像データで必要なアプリケーションを記憶する記憶手段として機能する。

画像登録処理部１ｃは、画像撮影装置４からネットワーク５を介して送信されてきた画像データを受信し、それを記憶部１ｂに記憶させる。

ダウンロード制御部１ｄは、例えば、図５に示すように、診断方法に応じて実行される画像診断／表示アプリケーションの画像処理にかかる負荷をテーブルとして保持している。図５のテーブルの例の場合、大腸解析アプリケーションの画像処理負荷が１（単位は、例えば％）、脳解析アプリケーションの画像処理負荷が３、冠動脈解析アプリケーションの画像処理負荷が７に設定されている。

またダウンロード制御部１ｄは、例えば、図６に示すように、サーバにおいて画像処理可能な負荷と、画像処理不可能な検査情報を送信先で処理できない場合の対処方法をテーブルとして保持している。図６のテーブルの例の場合、サーバにおける画像処理可能負荷が７、送信先で処理できない場合の対処方法が「サーバで処理」に設定されている。

さらにダウンロード制御部１ｄは、例えば、図７に示すように、医用画像診断装置２−１乃至２−３の装置性能情報（処理能力）をテーブルとして保持している。図７のテーブルの例の場合、装置番号１の医用画像診断装置２−１は、全ての画像診断／表示アプリケーションの実行が可能に設定され、装置番号２の医用画像診断装置２−２および装置番号３の医用画像診断装置２−３は、大腸解析アプリケーションと脳解析アプリケーションの実行が可能に設定されている。

ダウンロード制御部１ｄは、記憶部１ｂに記憶されている検査スケジュール（図２）を読み込み、読み込んだ検査スケジュールと、図５乃至図７に示したテーブルに基づいて、画像処理不可能な検査情報があるか否かを判断する。ダウンロード制御部１ｄは、画像処理不可能な検査情報があると判断した場合、その検査情報を、サーバに代わって画像処理することが可能な送信先クライアントを決定し、決定した送信先の装置番号を検査スケジュールの一覧に追加する。このダウンロード制御部１ｄは、検査スケジュールに基づいて処理負荷を予測し、その予測結果に基づいて、医用画像に対する画像処理をクライアント端末で行うか否かを判断する制御手段として機能する。

ダウンロード制御部１ｄは、送信先装置番号を追加した検査スケジュールに基づいて、記憶部１ｂから、送信可能になった検査情報に対応する画像データおよび画像診断／表示アプリケーションのうちの少なくとも一方を読み出し、アプリケーション処理用画像送信部１ｅに供給する。このダウンロード制御部１ｄは、検査スケジュールに基づいて処理負荷を予測し、その予測結果に基づいて、画像データおよび画像データで必要なアプリケーションのうちの少なくとも一方を読み出し、クライアント端末にダウンロードするダウンロード制御手段としても機能する。

アプリケーション処理用画像送信部１ｅは、ダウンロード制御部１ｄから供給された、画像データおよび画像診断／表示アプリケーションを、ネットワーク５を介して医用画像診断装置２にダウンロードする。

クライアント入力情報受信部１ｆは、医用画像診断装置２からネットワーク５を介して送信されてきたクライアント入力情報を受信し、それを画像診断／表示処理部１ｇに供給する。クライアント入力情報とは、医用画像診断装置２において、操作者によって図示せぬ入力部が操作された各種操作内容（例えば、アプリケーションの実行）を表す情報である。

画像診断／表示処理部１ｇは、クライアント入力情報受信部１ｆから供給されたクライアント入力情報に基づいて、記憶部１ｂに記憶されている画像診断／表示アプリケーションを実行して画像データを画像処理し、画像処理結果および画像診断／表示のためのGUIデータをクライアント表示データ送信部１ｈに供給する。

クライアント表示データ送信部１ｈは、画像診断／表示処理部１ｇから供給された画像処理結果および画像診断／表示のためのGUIデータを、ネットワーク５を介して医用画像診断装置２に送信する。

次に、図８のフローチャートを参照して、ダウンロード制御部１ｄが実行する、サーバ負荷低減処理について説明する。

ステップＳ１において、ダウンロード制御部１ｄは、記憶部１ｂに記憶されている検査スケジュール（図２）を読み込む。ステップＳ２において、ダウンロード制御部１ｄは、ステップＳ１の処理で読み込んだ検査スケジュールと、保持している画像処理負荷のテーブル（図５）から、診断開始時間毎のサーバの予測負荷を算出する。

図２に示す検査スケジュール一覧において、１番目乃至５番目に登録されている、大腸解析、脳解析、冠動脈解析、脳解析、脳解析の診断が13:00に開始される。図５に示す画像処理負荷のテーブルから、13:00におけるサーバの予測負荷は、１７（＝１（大腸解析）＋３（脳解析）＋７（冠動脈解析）＋３（脳解析）＋３（脳解析））と算出される。

図２に示す検査スケジュール一覧において、６番目乃至１１番目に登録されている、大腸解析、脳解析、冠動脈解析、脳解析、大腸解析、大腸解析の診断が14:30に開始される。図５に示す画像処理負荷のテーブルから、14:30におけるサーバの予測負荷は、１６（＝１（大腸解析）＋３（脳解析）＋７（冠動脈解析）＋３（脳解析）＋１（大腸解析）＋１（大腸解析））と算出される。

図２に示す検査スケジュール一覧において、１２番目乃至１５番目に登録されている、脳解析、脳解析、冠動脈解析、冠動脈解析の診断が16:00に開始される。図５に示す画像処理負荷のテーブルから、16:00におけるサーバの予測負荷は、２０（＝３（脳解析）＋３（脳解析）＋７（冠動脈解析）＋７（冠動脈解析））と算出される。

ステップＳ３において、ダウンロード制御部１ｄは、サーバにおける画像処理可能負荷のテーブル（図６）を読み出す。ステップＳ４において、ダウンロード制御部１ｄは、ステップＳ２の処理で算出した診断開始時間毎のサーバの予測負荷と、ステップＳ３の処理で読み出した画像処理可能負荷のテーブルを比較する。

13:00に開始される診断方法のうち、図２に示す検査スケジュール一覧の１番目に登録されている大腸解析（画像処理負荷が１）、２番目に登録されている脳解析（画像処理負荷が３）、および４番目に登録されている脳解析（画像処理負荷が３）がサーバにおける画像処理可能な検査と判断され、３番目に登録されている冠動脈解析（画像処理負荷が７）、および５番目に登録されている脳解析（画像処理負荷が３）がサーバにおいて画像処理不可能な検査と判断される。

14:30に開始される診断方法のうち、図２に示す検査スケジュール一覧の６番目に登録されている大腸解析、７番目に登録されている脳解析、および９番目に登録されている脳解析がサーバにおける画像処理可能な検査と判断され、８番目に登録されている冠動脈解析、１０番目に登録されている大腸解析、および１１番目に登録されている大腸解析がサーバにおける画像処理不可能な検査と判断される。

16:00に開始される診断方法のうち、図２に示す検査スケジュール一覧の１２番目に登録されている脳解析、および１３番目に登録されている脳解析がサーバにおける画像処理可能な検査と判断され、１４番目に登録されている冠動脈解析、および１５番目に登録されている冠動脈解析がサーバにおける画像処理不可能な検査と判断される。

ステップＳ５において、ダウンロード制御部１ｄは、ステップＳ４の処理の比較の結果、サーバで処理できない検査情報があるか否かを判定し、サーバで処理できない検査情報があると判定した場合、ステップＳ６に進む。ステップＳ６において、ダウンロード制御部１ｄは、サーバ処理が不可能な検査情報を送信予定検査情報として抽出する。

13:00に開始される診断方法のうち、図２に示す検査スケジュール一覧の３番目に登録されている冠動脈解析、および５番目に登録されている脳解析が送信予定検査情報として抽出される。

14:30に開始される診断方法のうち、図２に示す検査スケジュール一覧の８番目に登録されている冠動脈解析、１０番目に登録されている大腸解析、および１１番目に登録されている大腸解析が送信予定検査情報として抽出される。

16:00に開始される診断方法のうち、図２に示す検査スケジュール一覧の１４番目に登録されている冠動脈解析、および１５番目に登録されている冠動脈解析が送信予定検査情報として抽出される。

ステップＳ７において、ダウンロード制御部１ｄは、保持している装置性能情報（図７）に基づいて、ステップＳ６の処理で抽出された送信予定検査情報の送信先を決定する。

13:00に開始される診断方法のうち、送信予定検査情報として抽出された、検査スケジュール一覧の３番目に登録されている冠動脈解析の検査情報の送信先が、装置番号１の医用画像診断装置２−１に決定され、５番目に登録されている脳解析の検査情報の送信先が、装置番号２の医用画像診断装置２−１に決定される。

14:30に開始される診断方法のうち、送信予定検査情報として抽出された、検査スケジュール一覧の８番目に登録されている冠動脈解析の検査情報の送信先が、装置番号１の医用画像診断装置２−１に決定され、１０番目に登録されている大腸解析の検査情報の送信先が、装置番号２の医用画像診断装置２−２に決定され、１１番目に登録されている大腸解析の検査情報の送信先が、装置番号３の医用画像診断装置２−３に決定される。

16:00に開始される診断方法のうち、送信予定検査情報として抽出された、検査スケジュール一覧の１４番目に登録されている冠動脈解析の検査情報の送信先が、装置番号１の医用画像診断装置２−１に決定される。なお、１５番目に登録されている冠動脈解析の検査情報は、図７に示す装置性能情報のテーブルから、送信先で処理できないと判断されるため、その対処方法として、図６に示す画像処理可能負荷のテーブルから、「サーバで処理」に決定される。

ステップＳ８において、ダウンロード制御部１ｄは、図９に示すように、検査スケジュール一覧に送信先装置番号を追加する。またダウンロード制御部１ｄは、それぞれの検査の状態を表す情報（図９の例の場合、送信済、送信中、撮影済、未撮影など）も追加する。

ステップＳ５において、サーバで処理できない検査情報がないと判定された場合には、処理は直ちに終了される。

以上の処理によって、サーバで処理できない検査情報を、サーバに代わって処理することが可能な医用画像診断装置２に送信するようにスケジューリングすることができる。これにより、図１０に示すように、13:00におけるサーバの予測負荷を１７から７に低減させることができ、14:30におけるサーバの予測負荷を１６から７に低減させることができ、16:00におけるサーバの予測負荷を２０から１３に低減させることができる。

次に、図１１のフローチャートを参照して、ダウンロード制御部１ｄが実行する、スケジューリングされた検査情報のダウンロード処理について説明する。

ステップＳ１１において、ダウンロード制御部１ｄは、記憶部１ｂに記憶されている検査スケジュール（図９）を読み込む。ステップＳ１２において、ダウンロード制御部１ｄは、ステップＳ１１の処理で読み込んだ検査スケジュールに基づいて、送信可能になった検査情報に対応する画像データおよび画像診断／表示アプリケーションを読み出す。

例えば、図９に示す検査スケジュール一覧のうち、１０番目に登録されている大腸解析の検査情報が送信可能になった場合、ダウンロード制御部１ｄは、記憶部１ｂから、検査スケジュール一覧の１０番目に登録されている検査情報に対応する画像データを読み出すとともに、その画像データで必要な大腸解析アプリケーションを読み出す。

ステップＳ１３において、ダウンロード制御部１ｄは、ステップＳ１２の処理で読み出した画像データおよび大腸解析アプリケーションを、アプリケーション処理用画像送信部１ｅに供給し、ネットワーク５を介して医用画像診断装置２にダウンロードさせる。

以上の処理によってダウンロードされた画像データおよび大腸解析アプリケーションを受信した装置番号２の医用画像診断装置２−２は、大腸解析アプリケーションを実行して画像データを画像処理し、その処理結果を表示することができる。

なお、以上においては、画像データおよび大腸解析アプリケーションの両方を読み出すようにしたが、ダウンロード先である医用画像診断装置２に、この画像データで必要な大腸解析アプリケーションが既に保持されている場合には、画像データのみを読み出すようにしてもよい。

以上のように、シンクライアントシステムにおいて、クライアントサーバである医用画像アプリケーションサーバ１は、検査スケジュールに基づいてサーバの予測負荷を算出し、サーバで処理することができない検査情報をクライアント端末である医用画像診断装置２に行わせることで、サーバの負荷を低減させることができる。これにより、画像診断のスループットを低下させることなく、スムーズな診断を行うことが可能となる。また、医用画像診断装置２の処理性能に基づいて、実行させるアプリケーションを判断することで、クライアント側にも高負荷な処理を実行させることなく、スムーズな診断を行うことが可能となる。

なおこの発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化したり、上記実施の形態に開示されている複数の構成要素を適宜組み合わせたりすることにより種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態に亘る構成要素を適宜組み合わせても良い。

１ 医用画像アプリケーションサーバ
１ｂ 記憶部
１ｄ ダウンロード制御部
２−１乃至２−３ 医用画像診断装置
３ 検査スケジュール管理装置

Claims (6)

1. クライアント端末とネットワークを介して接続される医用画像処理装置において、
   医用画像および前記医用画像で必要なアプリケーションを記憶する記憶手段と、
   検査スケジュールに基づいて処理負荷を予測し、その予測結果に基づいて、前記医用画像に対する画像処理をクライアント端末で行うか否かを判断する制御手段と
   を備えることを特徴とする医用画像処理装置。
2. 前記制御手段は、前記検査スケジュールに基づいて、診断開始時間毎の処理負荷を算出し、予め保持している自身の処理可能負荷と比較することで、前記クライアント端末で行うか否かを判断する
   ことを特徴とする請求項１に記載の医用画像処理装置。
3. 前記制御手段は、前記医用画像に対する画像処理を前記クライアント端末で行うと判断した場合、前記クライアント端末を、前記医用画像処理装置に代わって画像処理することが可能な送信先クライアントとして決定し、前記検査スケジュールに追加する
   ことを特徴とする請求項１または２に記載の医用画像処理装置。
4. クライアント端末とネットワークを介して接続される医用画像処理装置において、
   医用画像および前記医用画像で必要なアプリケーションを記憶する記憶手段と、
   検査スケジュールに基づいて処理負荷を予測し、その予測結果に基づいて、前記記憶手段から、前記医用画像および前記医用画像で必要なアプリケーションのうちの少なくとも一方を読み出し、前記クライアント端末にダウンロードするダウンロード制御手段と
   を備えることを特徴とする医用画像処理装置。
5. 前記ダウンロード制御手段は、前記検査スケジュールに基づいて、診断開始時間毎の処理負荷を算出し、予め保持している自身の処理可能負荷と比較することで、前記処理負荷を予測する
   ことを特徴とする請求項４に記載の医用画像処理装置。
6. 前記ダウンロード制御手段は、前記クライアント端末を送信先クライアントとして前記検査スケジュールに追加する
   ことを特徴とする請求項４または５に記載の医用画像処理装置。

Images