JP5908248B2 - 医用画像管理システム - Google Patents

医用画像管理システム Download PDF

Info

Publication number
JP5908248B2
JP5908248B2 JP2011224602A JP2011224602A JP5908248B2 JP 5908248 B2 JP5908248 B2 JP 5908248B2 JP 2011224602 A JP2011224602 A JP 2011224602A JP 2011224602 A JP2011224602 A JP 2011224602A JP 5908248 B2 JP5908248 B2 JP 5908248B2
Authority
JP
Japan
Prior art keywords
image
server
information
unit
transfer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2011224602A
Other languages
English (en)
Other versions
JP2012108887A (ja
Inventor
哲志 奥山
哲志 奥山
伸行 小沼
伸行 小沼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Canon Medical Systems Corp
Original Assignee
Toshiba Corp
Toshiba Medical Systems Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp, Toshiba Medical Systems Corp filed Critical Toshiba Corp
Priority to JP2011224602A priority Critical patent/JP5908248B2/ja
Publication of JP2012108887A publication Critical patent/JP2012108887A/ja
Application granted granted Critical
Publication of JP5908248B2 publication Critical patent/JP5908248B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H30/00ICT specially adapted for the handling or processing of medical images
    • G16H30/20ICT specially adapted for the handling or processing of medical images for handling medical images, e.g. DICOM, HL7 or PACS
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H30/00ICT specially adapted for the handling or processing of medical images
    • G16H30/40ICT specially adapted for the handling or processing of medical images for processing medical images, e.g. editing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Description

本発明の実施形態は、医用画像の作成や加工に関する複数の処理を、複数のサーバーに分散し実行する医用画像管理システムの技術に関する。
アプリケーションサーバー上で動作する医用アプリケーションを、クライアントからネットワークを介して利用することが可能となってきた。またこのようなアプリケーションサーバーを複数台導入した環境を構築することも可能となってきている。このような環境では、複数の医用アプリケーションを複数台のアプリケーションサーバーに分散して処理を行うことが可能となる。また、医用画像撮影装置の中には、アプリケーションサーバーの機能を持つものも導入されてきている。
複数のアプリケーションサーバーが導入されている環境では、各アプリケーションサーバーで実行される機能は様々である。このような環境では、実行する処理の内容に応じて接続先のサーバーを自動的に切り替えるプロバイダが導入されている。操作者は、このプロバイダを介すことで、所望のアプリケーションを実行可能なアプリケーションサーバーにクライアントを接続することが可能となる。
しかしながらこのような環境では、各アプリケーションサーバーは、多種多様な医用画像を複数のクライアントからの要求によって処理する必要がある。そのため、処理を実行するために必要な記憶領域が圧迫され、アプリケーションの実行や画像収集などの処理の実行が阻害される恐れがある。
記憶領域の圧迫を避ける方法として、各処理を実行する際に、記憶領域に記憶された医用画像を、他のアプリケーションサーバーに転送する方法があげられる。しかしながら、医用画像はデータ量が大きく転送には時間がかかる。そのため、各処理の実行時に医用画像の転送を行うと、この転送により処理の実行が阻害され、処理をシームレスに実行することが困難になるという問題がある。
特開2010−146261号公報 特開2004−334403号公報
この発明の実施形態は上記の問題を解決するものであり、各アプリケーションサーバーが処理を実行するために必要な記憶領域の圧迫を防ぐ。また医用画像の転送に起因する、画像処理の実行の阻害を防止することを目的とする。
上記目的を達成するために、この実施形態の第1の形態は、複数の医用画像とそれに付帯された前記医用画像を特定する情報及びデータ量を含む付帯情報とを記憶する記憶部と、クライアントから指示される前記医用画像に対する画像処理を実行する画像処理部と、を有する複数のサーバーを備えた医用画像管理システムであって、前記画像処理の対象となる処理対象画像を特定する情報と前記医用画像に施す画像処理内容とともに、その画像処理の予約を前記クライアントから受け付ける予約管理部と、前記予約により前記画像処理の実行が予定された第1のサーバーの記憶部の空き容量が、所定の空き容量より少ないか否かを判断し、前記第1のサーバーの記憶部の空き容量が少ないと判断された場合に、前記複数の医用画像からそれらの前記付帯情報を基に前記処理対象画像以外の転送対象画像を特定する判断手段と、前記転送対象画像を記憶可能な空き容量を有する前記第1のサーバー以外の第2のサーバーに転送する転送処理手段と、を備え、前記転送後に前記第1のサーバーの画像処理部による前記処理対象画像に対する画像処理が行われることを特徴とする。
また、この実施形態の第2の形態は、データ量を含む付帯情報が付帯された複数の医用画像を記憶する記憶部と、前記医用画像に画像処理を施す画像処理部とをそれぞれに備えた複数のサーバーを含み、クライアントから指示される前記医用画像に対する複数の画像処理を画像処理内容に応じて前記複数のサーバーに分散し実行する医用画像管理システムであって、前記画像処理の対象となる処理対象画像を特定する情報と前記医用画像に施す画像処理内容とともに、その画像処理の予約を前記クライアントから受け付ける予約管理部と、前記予約管理部が予約を受け付けた前記画像処理の実行が予定されたサーバーの前記記憶部に前記実行に必要な容量を特定する条件管理部と、前記予定されたサーバーの前記記憶部の空き容量と前記必要な容量とを比較し、前記空き容量が前記必要な容量に満たない場合、前記予定されたサーバーの前記記憶部に記憶された各医用画像の前記付帯情報を基に、前記空き容量が前記必要な容量を満たすように前記予定されたサーバーの前記記憶部に記憶されている前記複数の医用画像のうち、他のサーバーに転送するための前記処理対象画像以外の転送対象画像を特定する判断手段と、各サーバーの記憶部の空き容量を示す情報を含む管理情報を記憶する管理情報記憶部と、前記転送対象画像の前記付帯情報に含まれる前記転送対象画像のデータ量と前記管理情報に含まれる前記各サーバーの空き容量とを照合することで、前記複数のサーバーから前記転送対象画像を記憶可能な前記他のサーバーを特定する転送先判断部と、前記転送先判断部が特定した前記他のサーバーに前記転送対象画像を転送する転送処理手段とを備えたことを特徴とする。
第1の実施形態に係る医用画像管理システムのブロック図である。 統計情報の一例である。 管理情報の一例である。 第1の実施形態に係る医用画像管理システムの動作を示すシーケンス図である。 第1の実施形態に係る医用画像管理システムの動作を示すフローチャートである。 第1の実施形態に係る医用画像管理システムの動作を示すフローチャートである。 第1の実施形態に係る医用画像管理システムの動作を示すフローチャートである。 第1の実施形態に係る医用画像管理システムの動作を示すフローチャートである。 第2の実施形態に係る医用画像管理システムのブロック図である。 統計情報の一例である。 第3の実施形態に係る医用画像管理システムのブロック図である。 第4の実施形態に係る医用画像管理システムのブロック図である。 第4の実施形態に係る医用画像管理システムの動作を示すシーケンス図である。 第4の実施形態に係る医用画像管理システムの動作を示すフローチャートである。
(第1の実施形態)
第1の実施形態に係る医用画像管理システムの構成について図1を参照しながら説明する。第1の実施形態に係る医用画像管理システムは、複数のサーバーと、プロバイダ2と、クライアント3とで構成される。この医用画像処理システムでは、医用画像の作成や加工に関する複数の処理を、複数のサーバーに分散し実行している。以降では、この医用画像処理システムは、サーバー1A、サーバー1B、及びサーバー1Cを含むものとして説明する。なおサーバー1Cは、図1には図示しない。
各サーバーの構成についてサーバー1Aを例に説明する。サーバー1Aは、画像情報記憶部11と、画像処理部12と、予約管理部13と、条件管理部14と、統計情報記憶部15と、画像特定部16と、転送管理部17とを備える。
画像情報記憶部11は、医用画像を記憶する記憶領域である。この医用画像には付帯情報が付されている。付帯情報には、医用画像の属性を示す情報が含まれている。医用画像の属性を示す情報には、医用画像のデータ量、データの形式、医用画像が作成または更新された日時を示す情報、及び医用画像を作成した機器またはアプリケーションの情報などが含まれる。データの形式とは、例えば拡張子などで区別される、画像をデータとして記録する方法やデータの圧縮方法を示す。医用画像を作成した機器またはアプリケーションの情報には、アプリケーション名、モダリティ、メーカー名、バージョン情報、及びプライベートタグなどを示す情報が含まれる。プライベートタグとは、例えば、DICOM(Digital Imaging and COmmunication in Medicine)プライベートタグのような拡張タグを示している。この拡張タグに、各医用画像を特定するための情報や、その医用画像を処理可能なアプリケーションと対応付けるための情報などを属性として付加してもよい。なお、前述したデータの形式を示す情報、及び医用画像を作成した機器またはアプリケーションの情報が、「データの種別」に相当する。
画像処理部12は、クライアント3からの指示に基づき、読影処理や画像処理に係るアプリケーションを実行し、医用画像の作成及び加工のいずれかまたは双方を行う。以降では、医用画像の作成及び加工のいずれかまたは双方に係る処理を、単に「画像処理」と呼ぶ。以下に画像処理部12の動作について具体的に説明する。画像処理部12は、クライアント3から医用画像に対する画像処理が処理対象の医用画像とあわせて指示される。画像処理部12は、まずクライアント3から指示された医用画像を画像情報記憶部11から読み出す。次に画像処理部12は、クライアント3からの指示に対応するアプリケーションを実行することで、読み出した医用画像に対し画像処理を施す。画像処理部12は、画像処理により新たな医用画像が作成された場合、この医用画像を二次画像として画像情報記憶部11に記憶させる。
なお、画像処理部12が実行できる画像処理の内容はサーバーごとに異なる。具体的には各サーバーに、そのサーバーの画像処理部12で実行可能な画像処理の内容に応じて異なるアプリケーションがインストールされている。各サーバーの画像処理部12が実行可能な処理の内容は、後述するプロバイダ2により管理されている。
予約管理部13は、クライアント3から予約情報を受信する。これにより予約管理部13は、画像処理部12による画像処理の予約を受け付ける。予約情報には、処理対象の医用画像を特定するための情報、画像処理の処理内容を示す情報(以下、「処理情報」と呼ぶ)、及び画像の解像度や枚数(スライス数)等の撮影条件を示す情報が含まれる。処理情報には、例えば、所望の画像処理を実行するためのアプリケーションの種別や、そのアプリケーションが提供する機能(一連の画像処理の一部として実行される部分的な画像処理の種別)を示す情報が含まれる。
統計情報記憶部15は、統計情報をあらかじめ記憶している。統計情報には、画像処理の内容に応じて、各処理を実行するために必要な容量がアプリケーションの種別ごとに記録されている。なお、各処理を実行するために必要な容量とは、その種別に該当するアプリケーションを実行するために一時的に使用する容量や、画像処理の結果として作成される二次画像を保管するために必要な容量を示している。図2は、統計情報の一例である。図2に示すように、例えば、心機能解析のアプリケーションを実行する場合、100MBの容量が必要であることが統計情報として記憶されている。統計情報には、各処理の実行に必要な容量を過去の経験に基づき算出し記憶させておくとよい。また、撮影条件に応じて処理対象のデータ量も異なり、このデータ量に応じて、各処理を実行するために必要な容量も変化する。そのため、撮影条件に応じた統計情報を算出し、これを統計情報記憶部15に記憶させておいてもよい。また、アプリケーションが提供する機能ごと(即ち、部分的な画像処理の種別ごと)に統計情報を算出し、これを統計情報記憶部15に記憶させておいてもよい。また、アプリケーションの種別またはそのアプリケーションが提供する画像処理の種別と、撮影条件とを組み合わせて、この組み合わせごとに統計情報を算出し、これを統計情報記憶部15に記憶させておいてもよい。
予約管理部13が画像処理の予約を受け付けると、条件管理部14は、予約された処理を実行するために必要な容量を特定する。具体的には条件管理部14は、予約管理部13が受信した予約情報に含まれる処理情報及び撮影条件を示す情報と、統計情報記憶部15に記憶された統計情報とを照合する。これにより条件管理部14は、この処理情報が示す処理を実行するために必要な容量を統計情報から特定する。
画像特定部16は、条件管理部14が求めた必要な容量と、画像情報記憶部11の空き容量とを比較する。なお画像特定部16は、一例として、空き容量をOS(Operating System)から取得するとよい。また画像特定部16は、画像情報記憶部11の全容量と、画像情報記憶部11に記憶された医用画像のデータ量とから空き容量を算出してもよい。画像情報記憶部11の空き容量が必要な容量に満たない場合、画像特定部16は、必要な容量を確保するために他のサーバーに転送する医用画像(以下「転送対象画像」と呼ぶ)を画像情報記憶部11から特定する。画像特定部16が転送対象画像を特定する処理の内容について、以下に具体的に説明する。
画像特定部16は、画像情報記憶部11に記憶された各医用画像の付帯情報を参照し、あらかじめ決められたルールに従い転送対象画像を特定する。ルールの一例として、画像特定部16は、自己のサーバーにおける画像処理部12が処理の対象としない医用画像を、転送対象画像として特定する。この場合、画像特定部16は、各医用画像に付帯された、データの形式、及び医用画像を作成した機器またはアプリケーションの情報と、画像処理部12が実行可能な処理とを照合する。この場合、実行可能な処理ごとに、各処理が処理対象とするデータの種別を対応付けて管理・記憶させておくとよい。この照合により画像特定部16は、画像処理部12が処理の対象としない医用画像を特定することが可能となる。また、その他の例として、画像特定部16は、一定期間更新がされていない医用画像を、転送対象画像として特定する。この場合、画像特定部16は、各医用画像に付帯された更新の日時を示す情報を参照し、最後の更新からあらかじめ決められた期間が経過している医用画像を検索する。この検索により、画像特定部16は、一定期間更新がされていない医用画像を特定することが可能となる。
また画像特定部16は、転送管理部17からの指示を受けて、画像情報記憶部11の空き容量を求め、求めた空き容量を示す情報を転送管理部17に通知する。なお、この画像特定部16が「判断手段」に相当する。
転送管理部17は、画像特定部16が特定した転送対象画像の付帯情報をプロバイダ2に送信し、この転送対象画像の転送先となるサーバー(以下、「転送先サーバー」と呼ぶ)をプロバイダ2に問合せる。この問合せの応答として、転送管理部17に、プロバイダ2から転送先サーバーが通知される。この通知を受けて転送管理部17は、通知された転送先サーバーに転送対象画像を転送する。転送対象画像の転送が完了すると、転送管理部17は、プロバイダ2に転送の完了を通知する。このとき転送管理部17は、転送対象画像を特定するための情報と転送先のサーバーを示す情報をプロバイダ2にあわせて送信する。これによりプロバイダ2は、各医用画像がどのサーバーの画像情報記憶部11に記憶されているかを管理することが可能となる。なお、転送対象画像が記憶された(転送元である)サーバー1Aが「第1のサーバー」に相当し、上記した転送先サーバーが「第2のサーバー」に相当する。
また転送管理部17は、転送対象画像の転送の完了後に、転送済の転送対象画像を画像情報記憶部11から削除する。これにより、画像情報記憶部11の空き容量が増加する。その後、転送管理部17は、画像特定部16から画像情報記憶部11の空き容量を示す情報を取得する。転送管理部17は、取得した空き容量を示す情報をプロバイダ2に通知する。これによりプロバイダ2は、サーバー1Aの画像情報記憶部11の空き容量を、管理・記憶することが可能となる。
また転送管理部17は、他のサーバーから転送対象画像を受信した場合、受信した転送対象画像を画像情報記憶部11に記憶させる。画像情報記憶部11への転送対象画像の記憶が完了すると、転送管理部17は、画像特定部16から画像情報記憶部11の空き容量を示す情報を取得する。転送管理部17は、取得した空き容量を示す情報をプロバイダ2に通知し管理情報の更新を要求する。これによりプロバイダ2で管理・記憶されている、サーバー1Aの画像情報記憶部11の空き容量を示す情報が更新される。なお、この転送管理部17が「転送処理手段」に相当する。
次にプロバイダ2の構成について説明する。プロバイダ2は、管理情報記憶部21と、要求管理部22と、転送先判断部23と、情報更新部24と、接続先判断部25とを備える。なおこのプロバイダ2が、「医用画像管理装置」に相当する。
管理情報記憶部21は、各サーバー(例えば、サーバー1A〜1C)の情報を管理するための管理情報を記憶している。管理情報には、各サーバーの画像処理部12が実行可能なアプリケーションの種類や、このアプリケーションの情報、及び各サーバーの画像情報記憶部11の空き容量を示す情報が含まれている。アプリケーションの情報には、例えば、アプリケーション名、モダリティ、メーカー名、バージョン情報、プライベートタグ、及びそのアプリケーションが提供する機能(即ち、部分的な画像処理の種別)などを示す情報が含まれる。図3は管理情報の一例である。図3に示すように、例えば、サーバー1Aは、アプリケーションAppXとAppYとして提供される画像処理を実行可能であることが管理情報として記憶されている。この管理情報によれば、サーバー1AにインストールされているアプリケーションAppXは、モダリティ「CT」で撮影された医用画像、すなわちCT画像を処理対象としている。またアプリケーションAppXは、「T社」のアプリケーションであり、バージョンが「2.0」である。またアプリケーションAppXは、プライベートタグ「xxxxyyyy」に対応付けられている。またアプリケーションAppXは、「MIP/MPR」の機能を有している。また、この管理情報は、サーバー1Aの画像情報記憶部11の空き容量が0.5GBであることを示している。また管理情報には、アプリケーションごとに、このアプリケーションが処理対象とするデータの種別を対応付けて記憶させておくとよい。またこの管理情報には、この医用画像管理システムに含まれるサーバー(例えばサーバー1B及び1C)についても、サーバー1Aと同様に前述した各情報が含まれている。
また管理情報記憶部21は、各医用画像を特定するための情報を、その医用画像の記憶先(どのサーバーの画像情報記憶部11に記憶されているか)を示す情報と対応付けて画像保管先情報として記憶している。この画像保管先情報により、プロバイダ2は、各医用画像が記憶されているサーバーを特定することが可能となる。
要求管理部22は、各サーバー(サーバー1A〜1C)から、転送対象画像を転送する転送先サーバーの問合せ、転送の完了の通知、及び空き容量を示す情報の通知を受け付ける。また要求管理部22は、クライアント3からサーバーへの接続要求を受け付ける。要求管理部22は、受け付けた情報の内容に応じて、転送先判断部23、情報更新部24、及び接続先判断部25のいずれかに処理を依頼する。要求管理部22の動作について、以下に具体的に説明する。なお、転送先判断部23、情報更新部24、及び接続先判断部25については後述する。
要求管理部22は、各サーバー(サーバー1A〜1C)から、転送対象画像を転送する転送先サーバーの問合せと、転送対象画像の付帯情報とを受ける。この場合、要求管理部22は、受信した付帯情報を転送先判断部23に出力し、転送先判断部23に転送先サーバーの特定を指示する。この指示に対する応答として、要求管理部22は、転送先判断部23から転送先サーバーの通知を受ける。要求管理部22は、受信した転送先サーバーの問合せの応答として、この転送先サーバーを要求元であるサーバー(例えばサーバー1A)に通知する。なお、転送対象画像が複数ある場合、要求管理部22は、転送対象画像ごとに転送先判断部23に転送先サーバーを特定させるように動作させてもよい。この場合、要求管理部22は、要求元であるサーバーに、転送対象画像ごとに転送先サーバーを通知する。
あるサーバーに記憶された医用画像が他のサーバーに転送されたとき、要求管理部22は、転送元のサーバーから転送の完了の通知を受ける。この場合、要求管理部22は、あわせて通知される転送対象画像を特定するための情報及び転送先のサーバーを示す情報を情報更新部24に出力し、情報更新部24に画像保管先情報の更新を指示する。この指示を受けて情報更新部24は、画像保管先情報に含まれた、転送対象画像の記憶先を示す情報を更新する。
各サーバーの画像情報記憶部11の空き容量が更新されたとき、要求管理部22は、空き容量が更新されたサーバーから、空き容量を示す情報の通知を受ける。この場合、要求管理部22は、空き容量が更新されたサーバーを示す情報と通知された空き容量を示す情報とを情報更新部24に出力し、情報更新部24に管理情報の更新を指示する。この指示を受けて情報更新部24は、管理情報に含まれた空き容量が更新されたサーバーの空き容量を示す情報を更新する。
要求管理部22は、クライアント3から、サーバーへの接続要求を受ける。この接続要求には、処理対象の画像を特定するための情報や、実行する処理の内容を示す情報が含まれる。この場合、要求管理部22は、この接続要求を接続先判断部25に出力し、接続先判断部25に接続先のサーバーの特定を指示する。この指示に対する応答として、要求管理部22は、接続先判断部25から接続先のサーバーの通知を受ける。要求管理部22は、接続要求の要求元であるクライアント3と通知された接続先のサーバーとの間の接続を確立する。これによりクライアント3は、各サーバーに予約情報を送信したり、各サーバーに画像処理の実行を指示したりすることが可能となる。なお要求管理部22は、予約情報に含まれる処理情報を基に接続先のサーバーを特定してもよい。これにより操作者は、接続先のサーバーを意識することなく、所望の処理を実行可能なサーバーに、処理の予約を行うことが可能となる。
転送先判断部23は、要求管理部22から転送先サーバーの特定の指示とあわせて、転送対象画像の付帯情報を受ける。転送先判断部23は、この転送対象画像の付帯情報と、管理情報に含まれた各サーバーの情報とを照合し転送先サーバーを特定する。転送先判断部23が転送先サーバーを特定する処理について、以下に例をあげて具体的に説明する。
転送先判断部23は、付帯情報に含まれた転送対象画像のデータ量を示す情報と、管理情報に含まれた各サーバーの空き容量を示す情報とを照合し、転送対象画像を記憶可能なサーバーを特定する。また転送先判断部23は、転送対象画像を作成した機器またはアプリケーションの情報に含まれる各情報と、各サーバーが実行可能なアプリケーション(画像処理)の各情報とを照合し、転送対象画像を処理可能なサーバーを特定する。例えば転送先判断部23は、転送対象画像に付帯されたプライベートタグと、各サーバーのアプリケーションに対応付けられたプライベートタグとが一致する場合に、そのサーバーを特定するとよい。また、転送対象画像のデータの形式を基に、この転送対象画像を処理できるアプリケーションがインストールされたサーバーを特定してもよい。転送先判断部23は、上記のような照合のうちいずれかを用いてもよいし、全てを組み合わせて用いてもよい。
転送先判断部23は、上記のような各照合のいずれか複数または全照合を実行し、各照合において情報が適合するごとにポイントを付してもよい。この場合、転送先判断部23は、最も高いポイントが付されたサーバーを転送先サーバーとして特定する。また、照合ごとに付されるポイントに重みを設定してもよい。一例として、データ量を示す情報と空き容量を示す情報との照合で付されるポイントの重みを最も高く設定するとよい。また、転送対象画像を作成した機器またはアプリケーションの情報に含まれる各情報と、管理情報に含まれる各サーバーが実行可能なアプリケーション(画像処理)の各情報との照合においても同様である。一例として、プライベートタグや機能(即ち、部分的な画像処理の種別)の照合時のポイントの重みを高く設定し、バージョンの照合時のポイントの重みを低く設定するとよい。転送先判断部23は、上記照合に基づき特定した転送先サーバーを要求管理部22に通知する。
情報更新部24は、要求管理部22から画像保管先情報の更新の指示とあわせて、転送対象画像を特定するための情報及び転送先のサーバーを示す情報を受ける。情報更新部24は、管理情報記憶部21に記憶された画像保管先情報を検索し、転送対象画像を特定するための情報を特定する。情報更新部24は、特定した転送対象画像を特定するための情報に対応付けられた記憶先を、要求管理部22から受けた転送先のサーバーに更新する。これによりプロバイダ2は、転送対象画像の転送後の記憶先を、この画像保管先情報に基づいて特定することが可能となる。
また情報更新部24は、要求管理部22から管理情報の更新の指示とあわせて、空き容量が更新されたサーバーを示す情報とそのサーバーの空き容量を示す情報とを受ける。情報更新部24は、管理情報記憶部21に記憶された管理情報を検索し、通知されたサーバーに対応する情報を特定する。情報更新部24は、特定したサーバーに対応する情報のうち空き容量を示す情報を、要求管理部22から受けたサーバーの空き容量を示す情報に更新する。これによりプロバイダ2は、空き容量が更新されたサーバーの更新後の空き容量を、この管理情報を基に特定することが可能となる。
接続先判断部25は、接続先のサーバーの特定の指示とあわせて、クライアント3からの接続要求を受ける。接続先判断部25は、接続要求に含まれた処理対象の画像を特定するための情報と画像保管先情報とを照合し、処理対象の画像が記憶されたサーバーを接続先のサーバーとして特定する。また接続先判断部25は、接続要求に含まれた実行する処理の内容を示す情報と管理情報に含まれた各サーバーの情報とを照合し、接続要求で指定された処理を実行可能なサーバーを接続先のサーバーとして特定してもよい。接続先判断部25は、上記照合に基づき特定した接続先のサーバーを要求管理部22に通知する。なお、接続要求で指定された処理を実行可能なサーバーに、処理対象の画像が記憶されていない場合、このサーバーに処理対象の画像が転送されるように、画像が保管されているサーバーを動作させるように構成してもよい。この場合、画像が保管されているサーバーは、画像保管先情報に基づき特定することが可能である。
なお上記では、各画像処理を実行するために一時的に使用する容量や、画像処理の結果として作成される二次画像を保管するために必要な容量を画像情報記憶部11に確保する例について説明した。しかしながら、これらの2つの容量を、異なる記憶領域に確保するように構成してもよい。その場合、統計情報として、各記憶領域に必要な容量を処理ごとに記憶させればよい。また画像特定部16を、各領域からそれぞれ転送対象画像を特定するように動作させるとよい。
(動作)
次に、第1の実施形態に係る医用画像管理システムの一連の動作について、図4〜図8を参照しながら、「予約の受付」、「転送先の特定」、及び「画像の転送」に分けて説明する。図4は、第1の実施形態に係る医用画像管理システムのシーケンス図である。
(予約の受付)
まず予約の受付に係る動作について、サーバー1Aがクライアント3から画像処理の予約を受け付けた場合を例に、図4及び図5を参照しながら説明する。図5は、画像処理の予約を受け付けた場合のサーバー1Aの動作を説明するためのフローチャートである。
まずクライアント3から画像処理の内容を示す処理情報を含む予約情報REQ101が、プロバイダ2の要求管理部22に送信される。要求管理部22は、この予約情報REQ101を接続先判断部25に出力し、予約情報REQ101で指定された画像処理を実行可能なサーバーを接続先判断部25に特定させる。例えば、予約情報REQ101の処理情報に対応するアプリケーションがアプリケーションAppXだとする。この場合、接続先判断部25は、管理情報記憶部21に記憶された管理情報(例えば図3)を基に、接続先のサーバーとしてアプリケーションAppXがインストールされたサーバー1Aを特定する。要求管理部22は、接続先判断部25が特定したサーバー1Aとクライアント3との接続を確立する。これにより図4に示すように、クライアント3からサーバー1Aに、画像処理の予約情報REQ102が送信される。次に図5を参照し、予約情報REQ102を受信したサーバー1Aの動作について説明する。
(ステップS101)
クライアント3から送信された予約情報REQ102は、サーバー1Aの予約管理部13により受信される。これにより予約管理部13は、画像処理の予約を受け付ける。
(ステップS102)
予約管理部13により予約が受け付けられると、条件管理部14は、この予約情報に含まれる処理情報と、統計情報記憶部15に記憶された統計情報とを照合する。この照合により条件管理部14は、この処理情報に対応する処理を実行するために必要な容量を特定する。例えば、この処理情報に対応するアプリケーションAppXが脳血流解析のアプリケーションだとする。この場合、条件管理部14は、統計情報(例えば図2)を基に、必要な容量が200MBであることを特定する。
(ステップS103)
次に画像特定部16は、条件管理部14により求められた必要な容量と、画像情報記憶部11の空き容量とを比較する。
(ステップS104)
この必要な容量が、画像情報記憶部11の空き容量より小さい場合(ステップS104、N)、サーバー1Aは、予約の受付に係る処理を終了する。
(ステップS105)
画像情報記憶部11の空き容量が必要な容量に満たない場合(必要な容量が空き容量より大きい場合)(ステップS104、Y)、画像特定部16は、転送対象画像を画像情報記憶部11から特定する。例えば、予約情報に含まれる処理情報がアプリケーションAppXに対応する場合、画像特定部16は、アプリケーションAppXが処理対象としない医用画像を転送対象画像として特定する。また画像特定部16は、一定期間更新がされていない医用画像を転送対象画像として特定してもよい。
(ステップS106)
転送管理部17は、画像特定部16により特定された転送対象画像の付帯情報を、プロバイダ2に送信し、転送先サーバーをプロバイダ2に問合せる。このプロバイダ2に送信された付帯情報及び問合せが、図4に示す問合せREQ201に相当する。
(転送先の特定)
次に、問合せREQ201を受信したプロバイダ2の動作について、図6を参照しながら説明する。図6は、プロバイダ2が、問合せREQ201を基に転送先サーバーを特定する場合の動作を説明するためのフローチャートである。
(ステップS201)
サーバー1Aから送信された問合せREQ201は、プロバイダ2の要求管理部22により受信される。要求管理部22は、問合せREQ201が転送先サーバーの問合せであることを確認したうえで、あわせて受信された転送対象画像の付帯情報を転送先判断部23に出力して転送先サーバーの特定を指示する。
(ステップS202)
転送先判断部23は、転送対象画像の付帯情報と、管理情報記憶部21に記憶された管理情報に含まれる各サーバーの情報とを照合し転送先サーバーを特定する。例えば、転送対象画像の付帯情報に、プライベートタグが「aaaabbbb」であることが示されているとする。この場合、転送先判断部23は、管理情報(例えば図3)を基に転送対象画像がアプリケーションAppZの処理対象であることを特定する。そのため転送先判断部23は、アプリケーションAppZがインストールされたサーバー1Bを転送先サーバーとして特定する。なお転送先判断部23は、プライベートタグに限らずモダリティを示す情報や機能(即ち、部分的な画像処理の種別)を示す情報などを基に転送先サーバーを特定してもよい。以降では、転送先サーバーとしてサーバー1Bが特定されたものとして説明する。転送先判断部23は、上記照合に基づき特定されたサーバー1Bを要求管理部22に通知する。
(ステップS203)
要求管理部22は、転送先判断部23から通知されたサーバー1Bを、転送先サーバーの要求元であるサーバー1Aに転送先サーバーとして通知する。この転送先サーバーの通知が、図4のRES211に相当する。
(画像の転送)
次に、プロバイダ2から通知RES211を受信したサーバー1Aの動作について図7を参照しながら説明する。図7は、サーバー1Aが転送対象画像を転送先サーバーに転送する場合の動作を説明するためのフローチャートである。
(ステップS111)
要求管理部22からの転送先サーバーの通知RES211は、サーバー1Aの転送管理部17により受信される。
(ステップS112)
転送管理部17は、通知RES211により通知されたサーバー1Bに転送対象画像を転送する。なお、サーバー1Bに転送される転送対象画像が、図4のREQ202に相当する。なお、この転送対象画像REQ202を受信したサーバー1Bの動作については後述する。
(ステップS113)
転送管理部17は、転送対象画像の転送が完了すると、転送済の転送対象画像を画像情報記憶部11から削除する。これにより、画像情報記憶部11の空き容量が増加する。その後、転送管理部17は、画像特定部16から画像情報記憶部11の空き容量を示す情報を取得する。
(ステップS114)
次に転送管理部17は、転送対象画像を特定するための情報と転送先のサーバーを示す情報をプロバイダ2に送信し、プロバイダ2に転送の完了を通知する。また、転送管理部17は、画像特定部16から取得した空き容量を示す情報をプロバイダ2に通知する。この転送の完了の通知及び空き容量を示す情報の通知が、図4のREQ203に相当する。
要求管理部22は、サーバー1Aから転送の完了の通知を受けると、あわせて通知された転送対象画像を特定するための情報及び転送先のサーバーを示す情報を情報更新部24に出力して画像保管先情報の更新を指示する。この指示を受けて情報更新部24は、画像保管先情報に含まれた転送対象画像の記憶先を示す情報を更新する。これにより画像保管先情報に含まれた転送対象画像の記憶先が、サーバー1Aから転送先サーバーであるサーバー1Bに更新される。これにより、転送対象画像を対象とした処理が予約された場合、接続先判断部25は、接続先のサーバーとして転送先サーバーであるサーバー1Bを特定することが可能となる。
また要求管理部22は、サーバー1Aから空き容量を示す情報の通知を受けると、サーバー1Aを示す情報と通知された空き容量を示す情報とを情報更新部24に出力して管理情報の更新を指示する。この指示を受けて情報更新部24は、管理情報に含まれたサーバー1Aの空き容量を示す情報を更新する。
これによりサーバー1Aの画像情報記憶部11に、予約された画像処理を実行するために必要な容量が確保される。以降、サーバー1Aは、予約された画像処理の実行に関する指示(図4のREQ103)をクライアント3から受け、この画像処理を実行する。
次に、サーバー1Aから転送対象画像REQ202を受信したサーバー1Bの動作について図8を参照しながら説明する。図8は、サーバー1Bが転送対象画像を受信した場合の動作を説明するためのフローチャートである。
(ステップS301)
サーバー1Aの転送管理部17から送信された転送対象画像REQ202は、サーバー1Bの転送管理部17で受信される。
(ステップS302)
サーバー1Bの転送管理部17は、受信した転送対象画像を画像情報記憶部11に記憶させる。画像情報記憶部11への転送対象画像の記憶が完了すると、転送管理部17は、画像特定部16から画像情報記憶部11の空き容量を示す情報を取得する。
(ステップS303)
サーバー1Bの転送管理部17は、取得した空き容量を示す情報をプロバイダ2に通知する。この空き容量を示す情報の通知が図4のREQ301に相当する。この通知REQ301を受けて、プロバイダ2の要求管理部22は、サーバー1Bを示す情報と通知された空き容量を示す情報とを情報更新部24に出力して管理情報の更新を指示する。この指示を受けて情報更新部24は、管理情報に含まれた、通知を受けたサーバーの空き容量を示す情報を更新する。
以上、第1の実施形態に係る医用画像管理システムによれば、画像処理の予約情報を基に、予約された処理を実行するために必要な容量を、この処理が実行される前にあらかじめ確保しておくことが可能となる。これにより、各サーバーが処理を実行するために必要な記憶領域の圧迫を防止する。また、必要な記憶領域の確保が事前に行われるため、領域の確保のためのデータの転送に伴う作業時の待ち時間の発生を防止することが可能となる。
(第2の実施形態)
次に第2の実施形態に係る医用画像管理システムの構成について図9を参照しながら説明する。図9は、この実施形態に係る医用画像管理システムのブロック図である。この実施形態に係るサーバー1Aは、医用画像を撮影する撮影部18を備えていることを特徴とする。以下、第1の実施形態に係る医用画像管理システムと異なる構成に着目し説明する。
撮影部18は、医用画像を撮影する構成である。撮影部18の具体的な例としては、CT(Computed Tomography)やMRI(Magnetic Resonance Imaging system)などがあげられる。撮影部18で撮影された医用画像は画像情報記憶部11に記憶される。
第2の実施形態に係る予約管理部13は、クライアント3から予約情報を受信することで、撮影部18による医用画像の撮影の予約を受け付ける。医用画像の撮影に係る予約情報には、処理情報として撮影条件を示す情報が含まれる。
第2の実施形態に係る統計情報記憶部15は、撮影条件に応じて、撮影を実行するために必要な容量を統計情報としてあらかじめ記憶している。図10は、撮影条件に応じた必要な容量を示す統計情報の一例である。図10に示すように、撮影条件に、「腹部ヘリカル」、スライス厚「1mm」、撮影範囲「20cm」、後処理「MPR」を設定し撮影する場合、300MBの容量が必要であることが統計情報として記憶されている。これらの統計情報には、各処理の実行に必要な容量を過去の経験に基づき算出し記憶させておくとよい。
予約管理部13が撮影の予約を受け付けると、条件管理部14が、予約された撮影に必要な容量を特定する。具体的には、条件管理部14は、予約管理部13が受信した予約情報に含まれる処理情報と、統計情報記憶部15に記憶された統計情報とを照合する。これにより条件管理部14は、この処理情報に対応する撮影を実行するために必要な容量を特定する。
以降、画像特定部16及び転送管理部17の動作は、第1の実施形態に係る医用画像管理システムと同様である。つまり、画像特定部16により、条件管理部14が求めた必要な容量と、画像情報記憶部11の空き容量とが比較される。空き容量が必要な容量に満たない場合、画像特定部16は、必要な容量を確保するために他のサーバーに転送する転送対象画像を特定する。転送管理部17は、プロバイダ2に転送先サーバーを問合せ、通知された転送先サーバーに転送対象画像を転送することで、予約された撮影を実行するために必要な容量を確保する。
以上、この実施形態に係る医用画像管理システムによれば、撮影の予約情報を基に、予約された撮影を実行するために必要な容量を、撮影が実行される前にあらかじめ確保しておくことが可能となる。すなわち、医用画像の撮影においても、第1の実施形態と同様の効果を得ることが可能となる。
(第3の実施形態)
医用画像の作成や加工に関する複数の処理を、複数のサーバーに分散し実行する場合、各サーバーの画像処理部が作成した二次画像を、そのサーバーの画像処理部が加工できるとは限らない。このような場合、この二次画像は、そのサーバーで処理の対象とならないにも拘らず、そのサーバーの画像情報記憶部11に記憶されている。そのためこの二次画像は、このサーバーの画像情報記憶部11を圧迫する要因となり得る。第3の実施形態に係る医用画像管理システムでは、画像処理の予約の有無に拘らず、画像処理部が作成した二次画像がそのサーバーで実行される画像処理の処理対象ではない場合、この二次画像を処理可能なサーバーに転送する。以下にこの実施形態に係る医用画像管理システムの構成について図11を参照しながら、第1の実施形態に係る医用画像管理システムと異なる構成に着目し説明する。図11は、この実施形態に係る医用画像管理システムのブロック図である。
画像処理部12Aは、クライアント3からの指示に対応するアプリケーションを実行することで、指示された医用画像に対し画像処理を施す。画像処理部12Aは、画像処理により新たな医用画像が作成された場合、この医用画像を二次画像として画像情報記憶部11に記憶させる。これらの動作は、第1の実施形態に係る画像処理部12と同様である。
二次画像が作成された場合、画像処理部12Aは、この二次画像に付帯されたデータの形式、及びこの二次画像を作成した機器またはアプリケーションの情報と、自身(画像処理部12A)が実行可能な処理とを照合する。画像処理部12Aは、この二次画像が、自身(画像処理部12A)の処理の対象とならない医用画像の場合、この二次画像を転送対象画像として特定する。
転送管理部17は、この転送対象画像の付帯情報をプロバイダ2に送信して転送先サーバーをプロバイダ2に問合せる。以降の動作は、第1の実施形態に係る医用画像管理システムと同様である。
以上、この実施形態に係る医用画像管理システムによれば、画像処理の予約の有無に拘らず、画像処理部12Aが自身による処理の対象とならない二次画像を作成した場合、その二次画像を転送対象画像として特定する。特定された二次画像は、転送管理部17により、これを処理可能なサーバーに転送される。それにより自身による処理の対象とならない医用画像の蓄積に伴う、サーバーの画像情報記憶部11の圧迫を事前に防止することが可能となる。
(第4の実施形態)
第1の実施形態に係る医用画像管理システムでは、画像処理の予約を各サーバーで受け付ける例について説明した。これに対し、第4の実施形態に係る医用画像管理システムでは、各サーバーに対する画像処理の予約をプロバイダが一括管理することを特徴としている。この実施形態に係る医用画像管理システムの構成について図12を参照しながら、第1の実施形態に係る医用画像管理システムと異なる構成に着目し説明する。図12は、この実施形態に係る医用画像管理システムのブロック図である。
第1の実施形態に係る医用画像管理システムでは、予約管理部13、条件管理部14、統計情報記憶部15、及び画像特定部16を、各サーバーが備えていた。この実施形態に係る医用画像管理システムでは、これらに替わり、予約管理部13B、条件管理部14B、統計情報記憶部15B、及び画像特定部16Bを、プロバイダ2が備えている。
要求管理部22は、クライアント3から画像処理の予約情報を受信すると、この予約情報を接続先判断部25に出力し、この予約情報で指定された画像処理を実行可能なサーバーを接続先サーバーとして接続先判断部25に特定させる。接続先判断部25の動作は第1の実施形態と同様である。次に要求管理部22は、接続先サーバーを示す情報と予約情報とを予約管理部13Bに出力する。
予約管理部13Bは、要求管理部22から受けた接続先サーバーを示す情報と予約情報とを対応付ける。これにより予約管理部13Bは、接続先サーバーに対する画像処理の予約を受け付ける。なお、予約管理部13Bに、予約情報及び接続先サーバーを示す情報を記憶する記憶領域を設けてもよい。
予約管理部13Bは、画像処理の予約を受け付けると、接続先サーバーを示す情報と予約情報に含まれる処理情報とを条件管理部14Bに出力する。
統計情報記憶部15Bは、各サーバーで実行される各画像処理の内容に応じて、各処理を実行するために必要な容量を、各サーバーの画像処理ごとに統計情報としてあらかじめ記憶している。
またこの実施形態に係る管理情報記憶部21は、各医用画像を特定するための情報を、その医用画像の記憶先を示す情報及びその医用画像の付帯情報と対応付けて画像保管先情報として記憶している。この付帯情報を基に、画像特定部16Bが、転送対象画像を特定する。なお管理情報記憶部21には、転送対象画像を特定するために必要な付帯情報が記憶されていればよく、全ての付帯情報を記憶する必要は無い。
条件管理部14Bは、予約管理部13Bから受けた接続先サーバーを示す情報及び処理情報と、統計情報記憶部15Bに記憶された統計情報とを照合する。これにより条件管理部14Bは、この処理情報に対応する処理を、接続先サーバーで実行するために必要な容量を特定する。条件管理部14Bは、接続先サーバーを示す情報と求めた必要な容量とを画像特定部16Bに出力する。
画像特定部16Bは、条件管理部14Bから受けた接続先サーバーを示す情報と、管理情報記憶部21に記憶された管理情報とを照合し、接続先サーバーの空き容量を特定する。画像特定部16Bは、条件管理部14Bから受けた必要な容量と接続先サーバーの空き容量とを比較する。接続先サーバーの空き容量が必要な容量に満たない場合、画像特定部16Bは、接続先サーバーから他のサーバーに転送される転送対象画像を特定する。画像特定部16Bが転送対象画像を特定する動作について、以下に具体的に説明する。
画像特定部16Bは、まず管理情報記憶部21に記憶された画像保管先情報を検索し、接続先サーバーに記憶された医用画像の情報を抽出する。また画像特定部16Bは、管理情報記憶部21に記憶された管理情報を検索し、接続先サーバーが実行可能な処理に関する情報を抽出する。画像特定部16Bは、接続先サーバーに記憶された医用画像の情報に含まれた付帯情報と、接続先サーバーが実行可能な処理に関する情報とを照合する。この照合により画像特定部16Bは、接続先サーバーが処理の対象としない医用画像を転送対象画像として特定する。また、その他の例として、画像特定部16Bは、付帯情報を基に、一定期間更新がされていない医用画像を、転送対象画像として特定するように動作させてもよい。画像特定部16Bは、特定した転送対象画像を転送先判断部23に通知する。
転送先判断部23は、画像特定部16Bが特定した転送対象画像に対応付けられた付帯情報と、管理情報に含まれた各サーバーの情報とを照合し転送先サーバーを特定する。この転送先サーバーを特定する処理については、第1の実施形態に係る転送先判断部23と同様である。転送先判断部23は、上記照合に基づき特定した転送先サーバーを転送対象画像とあわせて要求管理部22に通知する。
要求管理部22は、転送先判断部23から転送先サーバー及び転送対象画像の通知を受けると、転送対象画像の転送を接続先サーバーに指示する。
この転送指示は、接続先サーバーの転送管理部17Bにより受信される。転送管理部17Bは、この指示を受けると、通知された転送対象画像を画像情報記憶部11から抽出し、通知された転送先サーバーに転送する。転送管理部17Bは、転送対象画像の転送を完了すると、転送対象画像を特定するための情報と転送先のサーバーを示す情報をプロバイダ2に送信して転送の完了を通知する。なお、この通知を受けたプロバイダ2の動作は、第1の実施形態に係るプロバイダ2と同様である。
また転送管理部17Bは、転送の完了後に、転送済の転送対象画像を画像情報記憶部11から削除する。その後、転送管理部17Bは、画像情報記憶部11の空き容量を算出する。その算出方法は、第1の実施形態に係る画像特定部16の動作と同様である。転送管理部17Bは、算出された空き容量を示す情報をプロバイダ2に通知する。なお、この通知を受けたプロバイダ2の動作は、第1の実施形態に係るプロバイダ2と同様である。
また転送管理部17Bは、他のサーバーから転送対象画像を受信した場合、この転送対象画像を画像情報記憶部11に記憶させる。画像情報記憶部11への転送対象画像の記憶が完了すると、転送管理部17Bは、画像情報記憶部11の空き容量を算出する。転送管理部17は、算出された空き容量を示す情報をプロバイダ2に通知し管理情報の更新を要求する。なお、この要求を受けたプロバイダ2の動作は、第1の実施形態に係るプロバイダ2と同様である。
(動作)
次に、第4の実施形態に係る医用画像管理システムの一連の動作について、サーバー1Aがクライアント3から画像処理の予約を受け付けた場合を例に、図13及び図14を参照しながら説明する。図13は、この実施形態に係る医用画像管理システムのシーケンス図である。また図14は、この実施形態に係る医用画像管理システムのプロバイダ2の動作を説明するためのフローチャートである。
まずクライアント3から画像処理の内容を示す処理情報を含む予約情報(図13のREQ101)が、プロバイダ2の要求管理部22に送信される。
(ステップS211)
要求管理部22は、クライアント3から予約情報REQ101を受信すると、この予約情報を接続先判断部25に出力し、この予約情報で指定された画像処理を実行可能な接続先サーバーを接続先判断部25に特定させる。例えば、予約情報REQ101の処理情報に対応するアプリケーションがアプリケーションAppXだとする。この場合、接続先判断部25は、管理情報記憶部21に記憶された管理情報(例えば図3)を基に、接続先サーバーとしてアプリケーションAppXがインストールされたサーバー1Aを特定する。次に要求管理部22は、特定されたサーバー1Aを示す情報と予約情報REQ101とを予約管理部13Bに出力する。
予約管理部13Bは、要求管理部22から受けたサーバー1Aを示す情報と予約情報REQ101とを対応付けて管理・記憶する。これにより予約管理部13Bは、サーバー1Aに対する画像処理の予約を受け付ける。
(ステップS212)
予約管理部13Bは、画像処理の予約を受け付けると、サーバー1Aを示す情報と予約情報REQ101に含まれる処理情報とを条件管理部14Bに出力する。条件管理部14Bは、予約管理部13Bから受けたサーバー1Aを示す情報及び処理情報と、統計情報記憶部15Bに記憶された統計情報とを照合する。これにより条件管理部14Bは、この処理情報に対応する処理を、サーバー1Aで実行するために必要な容量を特定する。例えば、この処理情報に対応するアプリケーションAppXが脳血流解析のアプリケーションだとすると、条件管理部14Bは、統計情報(例えば図2)を基に、必要な容量として200MBを特定する。
(ステップS213)
条件管理部14Bは、接続先であるサーバー1Aを示す情報と求められた必要な容量とを画像特定部16Bに出力する。画像特定部16Bは、条件管理部14Bから受けたサーバー1Aを示す情報と、管理情報記憶部21に記憶された管理情報とを照合し、サーバー1Aの空き容量を示す情報を特定する。画像特定部16Bは、条件管理部14Bから受けた必要な容量とサーバー1Aの空き容量を示す情報とを比較する。
(ステップS214)
処理情報に対応する処理を実行するために必要な容量が、サーバー1Aの空き容量より小さい場合(ステップS214、N)、サーバー1Aは、予約の受付に係る処理を終了する。
(ステップS215)
サーバー1Aの空き容量が必要な容量に満たない場合(必要な容量が空き容量より大きい場合)(ステップS214、Y)、画像特定部16Bは、サーバー1Aに記憶された医用画像のうちから転送対象画像を特定する。例えば、転送対象画像の付帯情報に、プライベートタグが「aaaabbbb」であることが示されているとする。この場合、転送先判断部23は、管理情報(例えば図3)を基に転送対象画像がアプリケーションAppZの処理対象であることを特定する。そのため転送先判断部23は、アプリケーションAppZがインストールされたサーバー1Bを転送先サーバーとして特定する。なお転送先判断部23は、プライベートタグに限らずモダリティを示す情報や機能(即ち、部分的な画像処理の種別)を示す情報などを基に転送先サーバーを特定してもよい。画像特定部16Bは、特定した転送対象画像を転送先判断部23に通知する。
(ステップS216)
転送先判断部23は、画像特定部16Bにより特定された転送対象画像に対応付けられた付帯情報と、管理情報に含まれた各サーバーの情報とを照合し転送先サーバーを特定する。転送先判断部23は、特定された転送先サーバーを転送対象画像とあわせて要求管理部22に通知する。なお以降は転送先サーバーとしてサーバー1Bが特定されたものとして説明する。
(ステップS217)
要求管理部22は、サーバー1Bへの転送対象画像の転送を、サーバー1Aに指示する(図13のREQ501)。転送対象画像の転送に係る指示REQ501は、サーバー1Aの転送管理部17Bで受信される。転送管理部17Bは、通知された転送対象画像を画像情報記憶部11から抽出し、あわせて通知されたサーバー1Bに転送する(図13のREQ222)。
サーバー1Aの転送管理部17Bは、転送対象画像の転送が完了すると、転送対象画像を特定するための情報と転送先であるサーバー1Bを示す情報をプロバイダ2に送信して転送の完了を通知する。またサーバー1Aの転送管理部17Bは、転送の完了後に、転送済の転送対象画像を画像情報記憶部11から削除する。その後、この転送管理部17Bは、画像情報記憶部11の空き容量を算出する。この転送管理部17Bは、算出された空き容量を示す情報をプロバイダ2に通知する。なお上記したプロバイダ2への転送の完了の通知、及び空き容量を示す情報の通知が、図13のREQ223に相当する。
要求管理部22は、サーバー1Aから転送の完了の通知を受けると、あわせて通知された転送対象画像を特定するための情報及び転送先のサーバーを示す情報を情報更新部24に出力して画像保管先情報の更新を指示する。この指示を受けて情報更新部24は、画像保管先情報に含まれた転送対象画像の記憶先を示す情報を更新する。これにより画像保管先情報に含まれた転送対象画像の記憶先が、サーバー1Aから転送先サーバーであるサーバー1Bに更新される。
また要求管理部22は、サーバー1Aから空き容量を示す情報の通知を受けると、サーバー1Aを示す情報と通知された空き容量を示す情報とを情報更新部24に出力して管理情報の更新を指示する。この指示を受けて情報更新部24は、管理情報に含まれたサーバー1Aの空き容量を示す情報を更新する。
またサーバー1Bの転送管理部17Bは、サーバー1Aから受信した転送対象画像を画像情報記憶部11に記憶させる。画像情報記憶部11への転送対象画像の記憶が完了すると、サーバー1Bの転送管理部17Bは、画像情報記憶部11の空き容量を算出する。この転送管理部17は、算出した空き容量を示す情報をプロバイダ2に通知する(図13のREQ321)。この通知REQ321を受けて、プロバイダ2の要求管理部22は、サーバー1Bを示す情報と通知された空き容量を示す情報とを情報更新部24に出力して管理情報の更新を指示する。この指示を受けて情報更新部24は、管理情報に含まれた、通知を受けたサーバーの空き容量を示す情報を更新する。
以上、この実施形態に係る医用画像管理システムによれば、画像処理の予約や、この予約に伴うサーバー間の画像の転送に係る処理をプロバイダ2で一元管理することが可能となる。また、第1の実施形態に係る医用画像管理システムと同様に、各サーバーが処理を実行するために必要な記憶領域の圧迫を防止し、領域の確保のためのデータの転送に伴う作業時の待ち時間の発生を抑止・軽減することが可能となる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載されたその均等の範囲に含まれる。
1A、1B サーバー
11 画像情報記憶部 12、12A 画像処理部
13、13B 予約管理部 14、14B 条件管理部
15、15B 統計情報記憶部 16、16B 画像特定部
17、17B 転送管理部 18 撮影部
2 プロバイダ
21 管理情報記憶部 22 要求管理部
23 転送先判断部 24 情報更新部
25 接続先判断部
3 クライアント

Claims (7)

  1. 複数の医用画像とそれに付帯された前記医用画像を特定する情報及びデータ量を含む付帯情報とを記憶する記憶部と、クライアントから指示される前記医用画像に対する画像処理を実行する画像処理部と、を有する複数のサーバーを備えた医用画像管理システムであって、
    前記画像処理の対象となる処理対象画像を特定する情報と前記医用画像に施す画像処理内容とともに、その画像処理の予約を前記クライアントから受け付ける予約管理部と、
    前記予約により前記画像処理の実行が予定された第1のサーバーの記憶部の空き容量が、所定の空き容量より少ないか否かを判断し、前記第1のサーバーの記憶部の空き容量が少ないと判断された場合に、前記複数の医用画像からそれらの前記付帯情報を基に前記処理対象画像以外の転送対象画像を特定する判断手段と、
    前記転送対象画像を記憶可能な空き容量を有する前記第1のサーバー以外の第2のサーバーに転送する転送処理手段と、を備え、
    前記転送後に前記第1のサーバーの画像処理部による前記処理対象画像に対する画像処理が行われることを特徴とする医用画像管理システム。
  2. 前記予約管理部が予約を受け付けた前記画像処理内容を実行するために前記記憶部に必要な容量を、予め記憶されている画像処理内容に応じてその画像処理に必要な容量を参照して、前記所定の空き容量として特定する条件管理部と、
    前記転送対象画像の前記付帯情報に含まれる前記データ量と前記複数のサーバーの空き容量とを照合することで、前記複数のサーバーのうちから前記転送対象画像を記憶可能な前記第2のサーバーを特定する転送先判断部と、
    を更に備え、
    前記判断手段は、前記第1のサーバーの前記記憶部に記憶された各医用画像の付帯情報に含まれるデータ量を基に前記転送対象画像を特定し、
    前記転送処理手段は、前記転送対象画像を、前記転送先判断部が特定した前記第2のサーバーへ転送することを特徴とする請求項に記載の医用画像管理システム。
  3. データ量を含む付帯情報が付帯された複数の医用画像を記憶する記憶部と、前記医用画像に画像処理を施す画像処理部とをそれぞれに備えた複数のサーバーを含み、クライアントから指示される前記医用画像に対する複数の画像処理を画像処理内容に応じて前記複数のサーバーに分散し実行する医用画像管理システムであって、
    前記画像処理の対象となる処理対象画像を特定する情報と前記医用画像に施す画像処理内容とともに、その画像処理の予約を前記クライアントから受け付ける予約管理部と、
    前記予約管理部が予約を受け付けた前記画像処理の実行が予定されたサーバーの前記記憶部に前記実行に必要な容量を特定する条件管理部と、
    前記予定されたサーバーの前記記憶部の空き容量と前記必要な容量とを比較し、前記空き容量が前記必要な容量に満たない場合、前記予定されたサーバーの前記記憶部に記憶された各医用画像の前記付帯情報を基に、前記空き容量が前記必要な容量を満たすように前記予定されたサーバーの前記記憶部に記憶されている前記複数の医用画像のうち、他のサーバーに転送するための前記処理対象画像以外の転送対象画像を特定する判断手段と、
    各サーバーの記憶部の空き容量を示す情報を含む管理情報を記憶する管理情報記憶部と、
    前記転送対象画像の前記付帯情報に含まれる前記転送対象画像のデータ量と前記管理情報に含まれる前記各サーバーの空き容量とを照合することで、前記複数のサーバーから前記転送対象画像を記憶可能な前記他のサーバーを特定する転送先判断部と、
    前記転送先判断部が特定した前記他のサーバーに前記転送対象画像を転送する転送処理手段とを備えたことを特徴とする医用画像管理システム。
  4. 前記条件管理部は、前記画像処理を実行するために必要な容量を前記画像処理内容ごとに含む統計情報を記憶し、前記予約された前記画像処理内容と、前記統計情報とを照合することで、前記画像処理を実行するために前記予定された前記記憶部に必要な容量を特定することを特徴とする請求項に記載の医用画像管理システム。
  5. 記判断手段は、前記予定されたサーバーの前記記憶部の空き容量と、前記必要な容量とを比較することを特徴とする請求項3または請求項4に記載の医用画像管理システム。
  6. 前記予約管理部は、前記画像処理内容として撮影条件を含む情報とともに前記画像処理の予約として撮影の予約を受け付け、
    前記予定されたサーバーは、前記画像処理部としての撮影部を有し、撮影が予定されたサーバーであることを特徴とする請求項乃至請求項のいずれかに記載の医用画像管理システム。
  7. 前記付帯情報は、付帯した前記医用画像のデータ種別を含み、
    前記管理情報は、各サーバーが実行可能な前記画像処理内容を含み、
    前記転送先判断部は、前記転送対象画像の付帯情報に含まれる前記データ種別と前記管理情報に含まれる前記画像処理内容とを照合することで、前記複数のサーバーのうちから該付帯情報が付帯された前記転送対象画像を処理可能なサーバーを前記転送先サーバーとして特定することを特徴とする請求項乃至請求項のいずれかに記載の医用画像管理システム。
JP2011224602A 2010-10-25 2011-10-12 医用画像管理システム Active JP5908248B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011224602A JP5908248B2 (ja) 2010-10-25 2011-10-12 医用画像管理システム

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2010238237 2010-10-25
JP2010238237 2010-10-25
JP2011224602A JP5908248B2 (ja) 2010-10-25 2011-10-12 医用画像管理システム

Publications (2)

Publication Number Publication Date
JP2012108887A JP2012108887A (ja) 2012-06-07
JP5908248B2 true JP5908248B2 (ja) 2016-04-26

Family

ID=45993385

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011224602A Active JP5908248B2 (ja) 2010-10-25 2011-10-12 医用画像管理システム

Country Status (4)

Country Link
US (1) US20130204976A1 (ja)
JP (1) JP5908248B2 (ja)
CN (1) CN102598049B (ja)
WO (1) WO2012056637A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6165468B2 (ja) * 2012-03-05 2017-07-19 東芝メディカルシステムズ株式会社 医用画像処理システム
JP2014076137A (ja) * 2012-10-10 2014-05-01 Toshiba Corp 医用画像診断装置及び画像処理管理装置
US9137332B2 (en) * 2012-12-21 2015-09-15 Siemens Aktiengesellschaft Method, computer readable medium and system for generating a user-interface
JP6125300B2 (ja) * 2013-04-08 2017-05-10 東芝メディカルシステムズ株式会社 医用画像表示装置及び医用画像提供システム
JP6466097B2 (ja) * 2013-08-19 2019-02-06 キヤノンメディカルシステムズ株式会社 医用情報処理装置
CN104822047B (zh) * 2015-04-16 2018-10-19 中国科学院上海技术物理研究所 一种基于网络自适应医学图像传输显示方法
DE102016216203A1 (de) * 2016-08-29 2017-09-14 Siemens Healthcare Gmbh Medizinisches bildgebendes System
US11366622B2 (en) 2019-11-20 2022-06-21 Ricoh Company, Ltd. Image forming apparatus, management system, method of managing image forming apparatus
CN111223555B (zh) * 2019-12-26 2021-03-26 北京安德医智科技有限公司 一种面向医学影像人工智能辅助诊断结果表征的dicom扩展方法

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007244887A (ja) * 2001-12-03 2007-09-27 Ziosoft Inc ボリュームレンダリング処理方法、ボリュームレンダリング処理システム、計算機及びプログラム
JP2003242059A (ja) * 2002-02-18 2003-08-29 Sharp Corp 情報配信装置、情報端末装置、情報配信システム、情報配信方法およびプログラムを記録した機械読取り可能な記録媒体
JP2003323321A (ja) * 2002-05-01 2003-11-14 Brother Ind Ltd データファイル転送制御装置、データファイル処理装置、印字出力装置、プログラムおよび記録媒体
JP3999700B2 (ja) * 2003-05-27 2007-10-31 オリンパス株式会社 医療用画像記録装置
US20050008262A1 (en) * 2003-06-03 2005-01-13 Konica Minolta Medical & Graphic, Inc. Medical image system, and medical image processing method
JP2005046534A (ja) * 2003-07-31 2005-02-24 Fuji Photo Film Co Ltd 医用画像処理方法及び装置
KR100662120B1 (ko) * 2003-10-20 2006-12-27 엘지전자 주식회사 홈 네트워킹에 의한 가전기기의 메모리 공용방법
JP2006094047A (ja) * 2004-09-22 2006-04-06 Toshiba Corp 医用画像装置、画像送信装置および画像送信プログラム
JP2006271451A (ja) * 2005-03-28 2006-10-12 Toshiba Corp 医用画像管理サーバ、及び、医用画像管理方法
JP2008234382A (ja) * 2007-03-22 2008-10-02 Fujifilm Corp 医用画像転送制御装置及び方法、並びに医用画像転送システム
JP4343240B2 (ja) * 2007-06-28 2009-10-14 シャープ株式会社 情報処理装置及び情報処理システム
JP4486995B2 (ja) * 2007-08-01 2010-06-23 シャープ株式会社 画像処理システム
JP5279454B2 (ja) * 2008-11-04 2013-09-04 キヤノン株式会社 画像処理装置及びその制御方法、並びにプログラム
JP2010152623A (ja) * 2008-12-25 2010-07-08 Konica Minolta Medical & Graphic Inc 医用画像管理システム
JP5457694B2 (ja) * 2009-02-25 2014-04-02 株式会社東芝 医用画像保管装置及び医用画像保管通信システム
JP2010201002A (ja) * 2009-03-04 2010-09-16 Konica Minolta Medical & Graphic Inc 小規模診断システム及びプログラム
JP5571918B2 (ja) * 2009-07-29 2014-08-13 キヤノン株式会社 画像処理装置、画像管理装置、画像管理方法及び画像管理システム

Also Published As

Publication number Publication date
CN102598049A (zh) 2012-07-18
WO2012056637A1 (ja) 2012-05-03
JP2012108887A (ja) 2012-06-07
US20130204976A1 (en) 2013-08-08
CN102598049B (zh) 2016-08-03

Similar Documents

Publication Publication Date Title
JP5908248B2 (ja) 医用画像管理システム
US8165426B2 (en) Workflow-based management of medical image data
JP6165468B2 (ja) 医用画像処理システム
US9619254B2 (en) Adaptive architecture for a mobile application based on rich application, process, and resource contexts and deployed in resource constrained environments
CA2636705A1 (en) Multiple resource planning system
JP5904782B2 (ja) 医療情報管理システム及び医療情報管理方法
JP2006223465A (ja) 医用画像システム及び医用画像の取得方法
US7383511B2 (en) System, method and recording medium for medical image management
JP2006285740A (ja) 画像管理システム
JP4693452B2 (ja) 画像管理システム及び画像管理装置
JP2006330842A (ja) ライセンス管理方式および方法ならびにキューシステム装置およびそのプログラム
US20120150795A1 (en) Server apparatus and method of aquiring contents
WO2014129076A1 (ja) 医用画像データ管理システム、医用画像データ管理装置、医用画像データ管理プログラム
JP2008234382A (ja) 医用画像転送制御装置及び方法、並びに医用画像転送システム
KR101185729B1 (ko) 의료 영상 조회 시스템
JP6688684B2 (ja) 医用画像処理システム
JP2005149180A (ja) 医用画像管理システム
JP2006260301A (ja) 画像管理サーバ
JP5752302B2 (ja) 情報処理装置及びその制御方法、情報システム、情報処理方法、及び、プログラム
US11921892B2 (en) Data association system and anonymization control system
WO2014097950A1 (ja) 画像データ送信システム、画像表示装置、及び医用画像生成装置
JP5694783B2 (ja) 医用画像検索装置及び医用画像保管検索システム
KR101837844B1 (ko) Vna 시스템에서의 룰 기반 프리페칭 방법
CN113936776B (zh) 分布式的多病种人工智能病理分析系统
JP5039217B2 (ja) 画像管理システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140918

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150617

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150630

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150831

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160223

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160323

R150 Certificate of patent or registration of utility model

Ref document number: 5908248

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313117

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350