診断用画像の管理及び分配のためのシステム及び方法
画像スタディを、選択された画像リーダに分配する方法に関する。本発明方法は、サードパーティ通信モジュール（２０４）で、画像プロデューサから画像スタディを受信するステップと、メッセージング層（２１４）に受信通知メッセージを送るステップと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジン（１１４）に送るステップと、抽出画像スタディ情報から画像スタディ・ルールを特定するステップと、画像スタディ・ルールに基づいて、画像スタディに画像スタディ複雑度を適用するステップ（４２２）と、上記画像プロデューサからの画像スタディを受け取ることに応募した複数の画像リーダについて、画像リーダ複雑度を計算するために、それらの画像リーダ複雑度の各々を、画像スタディ複雑度及び複数の認可画像リーダの各々に割り当てられた画像リーダ・プロファイルを用いて計算するステップ（４３２）と、画像リーダ複雑度に基づいて、上記複数の画像リーダから選択画像リーダを選択するステップと、画像スタディを選択画像リーダに割り当てるステップ（４４０）と、ユーザインタフェース上で選択画像リーダに対して画像スタディを表示するステップと、を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、広くは診断用画像の管理に関し、特に、診断用画像と診断的解釈サービスを連携調整するシステム及び方法に関するものである。
【０００２】
関連米国出願：
本出願は、本出願の譲受人であるＲｅａｌ Ｔｉｍｅ Ｒａｄｉｏｌｏｇｙに譲渡された特許文献１の利益を主張するものであり、その内容は参照により組み込まれる。
【背景技術】
【０００３】
医療診断用画像と診断的解釈サービスを連携調整するソフトウェア・プロダクトが知られている。そのような連携調整ソフトウェア・プロダクトによって、病院、診療所、研究所といった医療画像プロデューサ、及び医療撮像法またはモダリティを利用できる他の医療画像プロデューサから医療診断用画像を収集して、それらを解釈及び診断を目的として放射線科医及び他の医療専門家といった医療診断用画像リーダに分配することが可能である。これらのプロダクトによると、利用できる資源の事前設定されたスケジュールに、作業が処理されるべき順序でアクセスすることができる。画像プロデューサは、このようなソフトウェア・プロダクトを利用して、画像スタディを医療画像予測専門医に割り振ることで、必要な医療画像の解釈が確実に行われるようにする。
【０００４】
上述のスケジューリング・ソフトウェアは有用となり得るが、言うまでもなく、改良が望まれる。例えば、そのようなツールは、医療画像リーダが対処可能な作業に応募するにあたって、医療画像リーダによる対処への早期コミットメントのような望ましい行動に報いつつ、利益の大きい作業のみ選択されることを防いで、“申し込み順に作業が割り当てられる”方式をとるようにすることができない。また、このようなスケジューリング・システムは、要望が何であるのかについての予備知識を持つことなく医師にサービスを提供させることができない。
【０００５】
既存のスケジューリング／連携調整プロダクトは、医療専門家と、それらの専門家が支援する医療機関との間の実世界インタラクションを反映するものではない。現在利用可能な医療画像用連携調整プロダクトは、ある特定の患者の画像について以前にレポートを作成した医療専門家が、その同じ患者からのその後の画像スタディを閲覧することを可能にする機構を備えていない。また、このようなプロダクトは、リアルタイムで対処可能な医師による優先的な分析を可能にするものではない。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国仮特許出願第６１／２６４３２７号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
そこで、本発明は、上記欠点を解消し、画像診断サービスと画像診断作業注文との連携調整を支援するシステムを提供することを課題とする。
【課題を解決するための手段】
【０００８】
本発明の一態様によれば、画像スタディを、選択された画像リーダに分配する方法を提供し、これは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信することと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送ることと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送ることと、抽出画像スタディ情報から画像スタディ・ルールを特定することと、画像スタディ・ルールに基づいて画像スタディに画像スタディ複雑度を適用することと、上記画像プロデューサからの画像スタディを受け取ることに応募した複数の画像リーダについて画像リーダ複雑度を計算することであって、それらの画像リーダ複雑度の各々を、画像スタディ複雑度と、複数の認可画像リーダの各々に割り当てられた画像リーダ・プロファイルとを用いて計算することと、画像リーダ複雑度に基づいて複数の画像リーダから選択画像リーダを選択することと、画像スタディを選択画像リーダに割り当てることと、ユーザインタフェース上で選択画像リーダに対して画像スタディを表示することと、を含む。
【０００９】
別の態様によれば、画像スタディを、対処可能な画像リーダに分配する方法を提供し、これは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信することと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送ることと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送ることと、抽出画像スタディ情報から画像スタディ・ルールを特定することと、少なくとも１つの画像スタディ・ルールが、その画像スタディが緊急優先度を有することを示している場合に、その画像スタディを、対処可能な画像リーダに割り当てることと、を含む。
【００１０】
別の態様によれば、画像スタディを、予約された画像リーダに分配する方法を提供し、これは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信することと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送ることと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送ることと、抽出画像スタディ情報から画像スタディ・ルールを特定することと、少なくとも１つの画像スタディ・ルールが、その画像スタディが予約画像リーダに予約されたものであることを示している場合に、その画像スタディを、予約画像リーダに割り当てることと、を含む。
【００１１】
別の態様によれば、画像プロデューサにより生成される画像スタディの、画像リーダへの分配をスケジューリングする方法を提供し、これは、少なくとも１つの対処時間帯中に、画像スタディ作業への対処についての要求を画像プロデューサから受け取ることと、複数の画像リーダから、それら複数の画像リーダが画像スタディ作業に対処することが可能な時間帯があることを示す画像リーダ対処可能通知を受け取ることと、上記少なくとも１つの対処時間帯を、対応する対処可能時間帯を持つ画像リーダと照合することと、上記少なくとも１つの対処時間帯中に受け取る画像スタディを、対応する対処可能時間帯を持つ画像リーダに割り当てることと、を含む。
【００１２】
さらに別の態様によれば、画像分配システムを提供し、これは、関連付けられた画像リーダ・プロファイルをそれぞれ有する複数の画像リーダから選択される画像リーダによる解釈を得ることを目的とする画像スタディを、画像プロデューサから受信するためのサードパーティ通信モジュールであって、受信通知メッセージを生成するサードパーティ通信モジュールと、サードパーティ通信モジュールとやり取りするためのメッセージング層であって、受信通知メッセージを受け取って、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを生成するメッセージング層と、メッセージング層と通信可能に接続された作業分配エンジンであって、スタディ通知メッセージを受け取って、抽出画像スタディ情報から画像スタディ・ルールを特定し、スタディ・ルールに基づいてスタディ複雑度を画像スタディに適用し、複数の画像リーダについての画像リーダ複雑度を、スタディ複雑度及び関連する画像リーダ・プロファイルをそれぞれ用いて計算し、計算された画像リーダ複雑度に基づいて画像リーダを選択し、この選択画像リーダに画像スタディをルーティングする、作業分配エンジンと、スタディ・ルーティング・モジュールから送られる画像スタディを受け取って、画像スタディを選択画像リーダに対して表示するためのユーザインタフェースと、を備える。
【００１３】
さらに別の態様によれば、画像スタディを選択された画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体を提供し、該コンピュータプログラムコードは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信するためのプログラムコードと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、画像スタディ・ルールに基づいて画像スタディに画像スタディ複雑度を適用するためのプログラムコードと、上記画像プロデューサからの画像スタディを受け取ることに応募した複数の画像リーダについて画像リーダ複雑度を計算するためのプログラムコードであって、それらの画像リーダ複雑度の各々を、画像スタディ複雑度及び複数の認可画像リーダの各々に割り当てられた画像リーダ・プロファイルを用いて計算するためのプログラムコードと、画像リーダ複雑度に基づいて複数の画像リーダから選択画像リーダを選択するためのプログラムコードと、画像スタディを選択画像リーダに割り当てるためのプログラムコードと、ユーザインタフェース上で選択画像リーダに対して画像スタディを表示するためのプログラムコードと、を含む。
【００１４】
さらなる態様によれば、画像スタディを対処可能なリーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体を提供し、該コンピュータプログラムコードは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信するためのプログラムコードと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、少なくとも１つの画像スタディ・ルールが、その画像スタディが緊急優先度を有することを示している場合に、その画像スタディを、対処可能な画像リーダに割り当てるためのプログラムコードと、を含む。
【００１５】
さらなる態様によれば、画像スタディを予約された画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体を提供し、該コンピュータプログラムコードは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信するためのプログラムコードと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、少なくとも１つの画像スタディ・ルールが、その画像スタディが予約画像リーダに予約されたものであることを示している場合に、その画像スタディを、予約画像リーダに割り当てるためのプログラムコードと、を含む。
【００１６】
さらに別の態様によれば、画像プロデューサにより生成される画像スタディを画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体を提供し、該コンピュータプログラムコードは、少なくとも１つの対処時間帯中に、画像スタディ作業への対処についての要求を画像プロデューサから受け取るためのプログラムコードと、複数の画像リーダから、それら複数の画像リーダが画像スタディ作業に対処することが可能な時間帯があることを示す画像リーダ対処可能通知を受け取るためのプログラムコードと、上記少なくとも１つの対処時間帯を、対応する対処可能時間帯を持つ画像リーダと照合するためのプログラムコードと、上記少なくとも１つの対処時間帯中に受け取る画像スタディを、対応する対処可能時間帯を持つ画像リーダに割り当てるためのプログラムコードと、を含む。
【図面の簡単な説明】
【００１７】
【図１Ａ】サービス提供者へのサービス要求を連携調整及び分配するシステムの典型例のブロック図
【図１Ｂ】図１Ａの構成要素の一実施形態のエンティティ関係を示す説明図
【図２】図１Ａのシステムの一実施形態のブロック図
【図３】図１Ａ及び１Ｂの需給計画モジュールの構成要素の一実施形態の模式図
【図４】図２の構成要素により用いられる方法の典型例のフローチャート
【図５】図２のシステムで用いる画像プロデューサと画像リーダの間の典型的なワークフローを示すシーケンス図
【発明を実施するための形態】
【００１８】
以下に、添付の図面を参照して、実施形態についてより詳細に説明する。
【００１９】
図１Ａは、画像プロデューサから医療画像診断専門医または画像読取サービス提供者への医療画像サービス要求を連携調整及び分配するためのシステムを示していて、その全体を参照番号１００で識別している。
本実施形態におけるシステムでは、データベース１０５にアクセスするプロデューサ・プロファイル・エンジン１０２を示している。データベース１０５は、画像プロデューサ・プロファイル１０６、画像リーダ・プロファイル１０８、スタディデータ１１０、スケジュール１１２を格納している。また、作業分配エンジン１１４も、同様にデータベース１０５にアクセスし、さらにレポートツール１１６にアクセスする。ウェブベースのユーザインタフェース１１８も、やはりデータベース１０５にアクセスする。
【００２０】
図１Ａに示すシステム１００の実施形態では、画像プロデューサは、ウェブＵＩ １１８を介してプロデューサ・プロファイル１０６にアクセスすることができる。画像プロデューサは、病院、診療所、研究所、及び、画像読取サービス提供者による解釈を得るための医療診断用画像を生成することができる他の医療機関を含んでもよいが、これらに限定されるものではない。画像読取サービス提供者は、通常は放射線科医であるが、医療画像を解釈する訓練を積んだ医療専門家を含めることもできる。そして、画像読取サービス提供者すなわち画像リーダは、ウェブ・ユーザインタフェース（ＵＩ）１１８を介して画像リーダ・プロファイル１０８にアクセスする。
【００２１】
プロデューサ・プロファイル・エンジン１０２によって、画像プロデューサは、特定のスタディについて、そのスタディデータ１０をデータベース１０５に保存することができる。スタディとは、画像プロデューサにより生成された医療診断用画像であって、医療専門家または画像読取サービス提供者により読み取り及び解釈されるべきものである。スタディデータ１１０は、スタディ履歴とスタディレポートを含んでもよい。スタディ履歴は、特定のスタディが作成された日時、アクセスされた日時、作業が行われた日時、及び、そのスタディがどの医療専門家によるものであるかを、画像プロデューサに対して示すものである。スタディレポートは、画像読取サービス提供者によるスタディ解釈結果の文書である。
【００２２】
画像プロデューサは、自身の施設、自身が解釈を求めるモダリティまたは撮像技術、認可した画像リーダのリスト、及び、通知を受ける希望の方法について、プロデューサ・プロファイル１０６の情報をウェブＵＩ
１１８によって提供することが可能である。認可画像リーダとは、画像プロデューサが、その画像プロデューサのスタディに対して許可された画像リーダとして選択した画像リーダである。画像プロデューサ・プロファイル１０６は、限定するものではないが、識別番号、所在地または実際の住所、画像プロデューサが送付すると予想されるスタディのボリュームといった情報をさらに含むものであってもよい。
【００２３】
ウェブＵＩ １１８によって、画像プロデューサは、自身が画像リーダによる対処を必要とする時間帯、及び、その時間帯中に自身が生成すると予想されるスタディのボリュームを指定することが可能であり、また、これらの要件をスケジュール１１２に保存することが可能である。
【００２４】
画像リーダ・プロファイル・ウェブＵＩ １１８によって、画像リーダは、自身の作業のスケジュールを立てることができる。画像リーダ・プロファイル・ウェブＵＩ
１１８によって、画像リーダは、さらに、予想される自身の作業容量、自身が専門とするモダリティ及び専門分科、サービスを提供することに自身が同意できない画像プロデューサ、通知を受ける希望の方法について、自身の画像リーダ・プロファイル１０８の情報を提供することが可能である。画像リーダのデフォルトの予想作業容量は、それぞれの特定の検査モダリティについて、時間当たりの単位数で指定される。例えば、特定の検査モダリティについて値がゼロであれば、その画像リーダが、そのモダリティの解釈を提供することはできないことを示している。
【００２５】
ウェブＵＩ １１８によって、画像リーダは、自身が対処することができる時間帯、自身が解釈することが可能なスタディのボリューム、自身が対処するつもりのある特定の画像プロデューサを指定することができ、また、これらの情報をスケジューリング・モジュール１１２に保存することができる。
【００２６】
作業分配エンジン１１４は、データベースからのスタディデータ１１０にアクセスし、容量と資格認定のルールを用いて、画像リーダの対処可能性を画像プロデューサのスケジュール１１２と照合し、これにより、画像プロデューサの対処要件と画像読取サービス提供者の対処可能性をマッチさせる。
【００２７】
ウェブＵＩ １１８は、システム上に受け取ったスタディのリストを表示する。そのようなリストには、受け取られたが解釈はされていないスタディ、特定の画像リーダに割り当てられているスタディ、解釈されたスタディ、キャンセルされたスタディが含まれる。ウェブＵＩはまた、特定のスタディについてレポートツール１１６を起動する機能、スタディをキャンセルする機能、スタディを予約する機能、またはスタディを特定の画像リーダに手動で割り当てる機能を提供する。さらに、ウェブＵＩ
１１８は、レポートツール１１６で作成されたスタディ解釈結果を表示する機能を提供する。
【００２８】
図１Ｂは、図１Ａのシステムの構成要素間の関係を示すエンティティ関係図である。
画像リーダ１５０は、固有の画像リーダＩＤを有している。画像リーダ１５０には、画像リーダ・プロファイル１０８が関連付けられていて、これは、画像リーダのフルネーム、詳しい連絡先、スキル、及びボリューム情報といった情報を含んでいる。画像リーダ１５０は、対処可能性のコミットメントをスケジュール１１２の中に作成する。画像リーダ１５０は、スタディ１５６の解釈を担当する。スタディ１５６は、固有のスタディ識別子などの属性、画像プロデューサＩＤ、患者情報、モダリティ、検査時間及び検査説明などのスタディデータ、解釈されるべきことの指示（作業アイテム）、ステータス、優先度などのワークフロー・データを有している。作業アイテムであるスタディ１５６について、レポート１５８が作成される。レポート１５８は、画像リーダの署名、バージョン、具体的な解釈内容などの情報を含むことができる。画像プロデューサ１６０は、固有の画像プロデューサＩＤを有している。画像プロデューサ１６０には、画像プロデューサ・プロファイル１０６が関連付けられていて、これは、詳しい連絡先、予想されるボリューム、このプロデューサＩＤからのスタディの受信時にプロデューサ・プロファイル・エンジン１０２により適用されるべきルールといった情報を含んでいる。画像プロデューサ１６０は、スケジュール１１２の中に対処要求を生成することができる。画像プロデューサ１６０は、システムに送信されるスタディ１５６を作成する。
【００２９】
資格認定は、特定の画像プロデューサに対し、画像リーダが対処して、スタディ情報を閲覧し、解釈レポートを作成することが可能であることを明示するプロセスである。システム管理者により、システム管理ＵＩ
２４４でアソシエーションが定義され、データベース１０５の認可テーブル１６４に記憶される。
【００３０】
図２は、画像プロデューサからの医療画像読取サービス要求を画像読取サービス提供者に分配するシステムの一実施形態の典型的な模式図を示していて、その全体を参照番号２００によって識別している。
図２では、サードパーティ業界標準画像アーカイブ／通信システム（ＰＡＣＳ：Ｐｉｃｔｕｒｅ Ａｒｃｈｉｖｅ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ
Ｓｙｓｔｅｍ）アプリケーション２０２が、様々な種類の画像スタディを受け付けて判別することができるサードパーティ通信モジュール２０４とやり取りする。サードパーティ通信モジュール２０４はまた、ＨＬ７など他の種類の通信プロトコルを用いて他のサードパーティ・スタディを受け付けることもできる。本例では、サードパーティ通信モジュール２０４は、ＤＩＣＯＭスタディを受信して保存し、スタディが受信されたことの通知を生成し、ＤＩＣＯＭスタディ移動コマンドを発行し、ＤＩＣＯＭスタディのクエリを発する。本例では、サードパーティ通信モジュール２０４は、ＤＩＣＯＭ統合モジュール２０６を含み、これは、限定するものではないが、スタディ通知モジュール２０８、スタディ・ルーティング・モジュール２１０、プリフェッチ・モジュール２１２などのモジュールを含んでもよい。スタディ通知モジュール２０８は、スタディの受信時にメッセージを作成し、これらのメッセージをメッセージング層２１４に伝送する。スタディ・ルーティング・モジュール２１０は、スタディ・ルーティング命令メッセージをメッセージング層２１４から受け取り、指示された宛先にスタディを移動させるようにサードパーティ通信モジュール２０４に対して命令する。プリフェッチ・モジュール２１２は、スタディの受信時にメッセージング層２１４からメッセージを受け取り、これにより、他の関連スタディの利用可能性について業界標準サードパーティ・アプリケーション（ＰＡＣＳ）２０４に問い合わせして、受信スタディに関連するスタディを取り出す。
【００３１】
別の実施形態では、サードパーティ通信モジュール２０４は、ＤＩＣＯＭ統合モジュール２０６をバイパスし、メッセージング層２１４と直接通信する。メッセージング層２１４は、スタディに関する情報をサードパーティ通信モジュール２０４から受け取り、割当待ちのスタディがあるという通知メッセージを作業分配エンジン１１４に送る。
【００３２】
通知メッセージは、一般的には、スタディのＤＩＣＯＭヘッダから取り出された情報を含み、それはＤＩＣＯＭ統合モジュール２０６内からのものである。通知メッセージのこの情報は、限定するものではないが、患者ＩＤ、患者名、画像プロデューサＩＤ、画像プロデューサのスタディ識別子、スタディ作成日付、発注部科、スタディ内の画像数を含むことができる。
【００３３】
そして、メッセージング層２１４は、作業分配エンジン１１４とやり取りする。本例では、作業分配エンジン１１４は、スタディ・プロファイリング・ルールエンジン２１６、スタディ・ルーティング・モジュール２１８、需給計画モジュール２２０、スタディ分配モジュール２２２、結果管理モジュール２２４、及びメッセージ送信処理モジュール２２６を有している。スタディ・プロファイリング・ルールエンジン２１６は、メッセージング層２１４から受け取ったスタディ通知に対して動作を実行する。それらの動作を実行することで、スタディ・プロファイリング・ルールエンジン２１６は、特定のスタディをルーティングしてもよいかどうか、そのスタディはどのような優先度であるべきか、そのスタディを解釈されるべきスタディ（すなわち作業アイテム）とみなすべきか参照用スタディとみなすべきかについて、判断することができる。
【００３４】
スタディ・ルーティング・モジュール２１８は、スタディの一部として受け取った、プロデューサＩＤや、特定の実施形態ではスタディ分配モジュール２２２により決定された割当済みの画像リーダなどの情報を用いて、メッセージング層２１４を介して伝送される命令メッセージを生成し、これにより、サードパーティ通信モジュール２０４は、スタディを特定のサードパーティ・アプリケーション（ＰＡＣＳ）２０２に移動させて、表示させる。
【００３５】
需給計画モジュール２２０は、スケジュール１１２からの画像プロデューサ対処要求情報、スケジュール１１２からの画像リーダ対処可能性情報、プロデューサ・プロファイル及びリーダ・プロファイルからの画像リーダ資格認定情報を消化して、プロデューサの要求を画像リーダの対処可能性と照合し、プロデューサとリーダの各接点についてのサービス契約を保存する。画像リーダにより表明された対処可能な容量が、プロデューサにより表明された要求に対して解釈を提供するのに不十分である場合には、需給計画モジュール２２０は、スケジューリング・モジュールＵＩ
２４０を介して警告を発する。
【００３６】
需給計画モジュール２２０は、指定された間隔で、近々予定される対処コミットメントについて画像リーダに通知する。一実施形態において、指定した間隔でのこれらの通知は、メッセージ送信処理モジュール２２６を用いて送信されるインターネットカレンダー形式のメッセージを介して、画像リーダのプロファイル１０８に記憶されている画像リーダの電子メールアドレスを用いた電子メールにより実現することができる。別の実施形態では、近々予定される対処コミットメントの通知は、データベース１０５に保存されている画像リーダのプロファイル１０８に記憶されている定期的通知の値に従って、近々予定される対処コミットメントを提示する定期的な電子メール・メッセージで、メッセージ送信処理モジュール２２６により送信される。
【００３７】
画像プロデューサからの注文が発生すると、その注文は、スタディ分配モジュール２２２に伝えられる。スタディ分配モジュール２２２は、複数のスタディ画像プロデューサから複数のスタディ・コンシューマ（リーダ）へのスタディの分配を行う。この分配は、一連のルールと、各画像リーダの未処理の作業量、スタディの優先度、サービスオペレータにより規定される調整値といった重み付け判断とに基づくものである。
【００３８】
作業分配エンジン１１４は、画像プロデューサ、画像リーダ、及びシステム管理者がアクセスできるウェブ・ユーザインタフェース２３８とやり取りする。ウェブ・ユーザインタフェース２３８は、スケジューリング・モジュール・ユーザインタフェース（ＵＩ）２４０、画像プロデューサ・プロファイル・ユーザインタフェース（ＵＩ）２４１、画像リーダ・プロファイル・ユーザインタフェース（ＵＩ）２４３、及びレポートモジュール・ユーザインタフェース（ＵＩ）２４２を含むことができる。
【００３９】
スケジューリング・モジュールＵＩ ２４０は、特定の時間帯または複数の繰り返し時間帯について画像プロデューサが自身の対処要求を表明するための、カレンダー型表示を提供する。画像プロデューサは、特定の対処要求の各々について、自身の画像プロデューサ・プロファイル１０６に記憶されている予想スタディ・ボリューム情報を変更することができる。特定の時間帯または複数の繰り返し時間帯について画像リーダが自身の対処可能性を表明するために、同様のカレンダー型表示を利用することができる。画像リーダにより提供可能な容量の合計が、画像プロデューサにより表明された要求の合計以上であると需給計画モジュール２２０により判断される場合には、ユーザインタフェースは、その時間帯の色を、十分な対処を示すように変更する。
【００４０】
画像プロデューサ・プロファイルＵＩ ２４１及び画像リーダ・プロファイルＵＩ ２４３は、プロデューサ及びリーダが、デフォルトのボリューム、連絡先情報など、自身のプロデューサ・プロファイル３２６及び画像リーダ・プロファイル３２４の情報を管理するための画面を提供し、さらに、リーダ・プロファイルの場合には、専門分科の領域と除外プロデューサの領域を提供する。ユーザインタフェースに入力された情報は、プロデューサ・プロファイル１０６と画像リーダ・プロファイル１０８にそれぞれ保存される。
【００４１】
スタディリストＵＩ ２４５は、システム上でレポート用に割り当て可能なスタディ、スタディのステータス、スタディの割り当て履歴、スタディがどのリーダに割り当てられているのかを表示するためのリスト及び機能を提供し、さらに、ユーザの権限によっては、解釈の結果を表示する機能、または既に解釈のために指定されているスタディをキャンセルする機能を提供する。スタディリスト・モジュールの中のスタディは、スタディデータ１１０から取り出される。
【００４２】
システム管理ＵＩ ２４４は、画像プロデューサと画像リーダとの間にリンクを形成するための入力手段、例えばアクレディテーション１６４を提供し、さらに、プロデューサ・プロファイル・エンジン１０２のルールとパラメータを定義するための入力手段、スタディ分配モジュール２２２のルールとパラメータを定義するための入力手段、画像プロデューサＩＤ及び画像リーダＩＤを生成するための入力手段を提供する。
【００４３】
レポートモジュールＵＩ ２４２は、スタディリストＵＩ ２４５から起動されて、スタディ解釈結果を文書化するための入力手段を提供し、さらに、スタディと関連付けられた画像データを表示するための適当な診断画像ビューアを起動する。入力フォームは、検査説明、モダリティ、プロデューサＩＤなど、スタディ割当待ちメッセージで受け取るデータに応じて異なることがある。
【００４４】
一実施形態では、画像リーダによるスタディについての注文を生成する前に、情報が取得、転送、または変更される。スタディ・プロファイリング・ルールエンジン２１６は、各画像プロデューサＩＤについて、データベース１０５に保存されているスタディ・プロファイリング情報を参照することで、画像プロデューサから受け取ったスタディ割当待ち通知に対して適用されるルールと動作を決定する。ルールと動作は、単独で、または組み合わせて用いることができる。別の実施形態では、スタディ・プロファイリング・ルールエンジン２１６は、メッセージング層２１４からの送信により受け取ったスタディ通知メッセージから、画像プロデューサＩＤ情報を取り出して、ＤＩＣＯＭ統合モジュール２０６へのスタディ転送メッセージを生成し、これによって、サードパーティ通信モジュール２０４は、受信したスタディを、プロデューサ・プロファイルで規定されているターゲット解釈ＰＡＣＳシステムに転送する。
【００４５】
スタディ分配モジュール２２２は、画像リーダの対処可能性を、画像プロデューサのスケジュールと照合して、資格認定、及び作業負荷ルールにより、スタディを画像リーダに割り当てる。スタディ着信通知が受け取られて、スタディが作業分配エンジン１１４に入力されると、スタディ分配モジュール２２２は、スタディに複雑度を割り当てて、その複雑度を合計し、また、各画像リーダに割り当てられた作業量を比較する。複雑度は、スタディの料金収入とスタディの処理にかかる予測時間の組み合わせから導出される。個々のスタディの複雑度は、受信したスタディから導出した情報、検査説明、検査モダリティ、検査で撮像された身体部位に基づくものであってもよい。
【００４６】
別の実施形態では、ＤＩＣＯＭ統合モジュール２０６は、サードパーティ・アプリケーション（ＰＡＣＳ）２０２に保存されている関連スタディの利用可能性を特定するためのクエリを発する。関連スタディがある場合は、プリフェッチ・モジュール２１２が、受信したスタディ通知メッセージから、患者ＩＤ、検査説明、検査モダリティ、及び送信ＰＡＣＳシステム情報を取り出し、さらに、画像プロデューサ・プロファイル１０６に保存されているターゲットＰＡＣＳシステム情報を取り出す。スタディ・ルーティング・モジュール２１６は、ＤＩＣＯＭ統合モジュール２０６のプリフェッチ・モジュール２１２にコマンドメッセージを送り、これによって、サードパーティ通信２０４がターゲットＰＡＣＳシステムに対して制約付きＤＩＣＯＭクエリメッセージを発する。受け取った情報はプリフェッチ・モジュール２１２により用いられ、これにより、サードパーティ通信２０４が、プロデューサＰＡＣＳに対してＤＩＣＯＭ移動コマンドを発する。そして、プロデューサＰＡＣＳは、同定したスタディを、システムにより規定される関連スタディＤＩＣＯＭアプリケーション・エンティティ・タイトルに送る。関連スタディの各々を順次受け取るごとに、ＤＩＣＯＭ統合モジュール２０６は、“スタディ利用可能イベント”を生成し、この情報を、関連スタディ論理アドレス情報（例えば、ＤＩＣＯＭアプリケーション・エンティティ・タイトル）を含めて、スタディ・プロファイリング・ルールエンジン２１６に対してメッセージング層２１４を利用して送る。スタディ・プロファイリング・ルールエンジン２１６は、取り出されたスタディが単なる参照用であって、解釈のための注文を発生させるものではないことを、関連スタディ論理アドレス情報を用いて判断する。スタディ・プロファイリング・ルールエンジン２１６は、メッセージング層２１４を介してスタディ・ルーティング・モジュール２１０に対し“スタディ転送”メッセージを送り、これによって、サードパーティ通信２０４は、スタディを、画像プロデューサ・プロファイル１０６に保存されたデータで規定されているターゲット解釈ＰＡＣＳシステムに転送する。
【００４７】
さらに別の実施形態では、画像プロデューサからの関連スタディの送信をＤＩＣＯＭ統合モジュール２０６が請求するのではなく、画像プロデューサが、解釈用のスタディと、送信請求されてない関連情報とを一緒に送信してもよい。この場合、スタディ・プロファイリング・ルールエンジン２１６は、通知メッセージからスタディが作成された日時を参照することで、送信されたどのスタディが解釈されるべきものであり、どれが関連情報であるか判断する。関連情報は、一般的には、読み取り及び解釈されるべきスタディよりも先に、既に解釈されたスタディである。スタディ・プロファイリング・ルールエンジン２１６は、関連情報については、スタディ情報１５６に記憶されるスタディ・ステータスを“キャンセル”値に設定する。スタディ・プロファイリング・ルールによるスタディのプロファイル設定が誤りである場合には、これを、システム管理者がシステム管理ＵＩ
２４４を介して手動で有効なスタディに変換することができる。同様に、有効なスタディであるとみなされたスタディを、システム管理者は、画像プロデューサによりそのように指示された場合は手動で取り消すことができる。
【００４８】
さらに別の実施形態では、スタディ・プロファイリング・ルールエンジン２１６は、画像プロデューサ・プロファイル１０６内の画像プロデューサＩＤ、スタディがシステムに受信された時刻、スタディの優先度、スタディを発注した画像プロデューサの部科を用いて、スタディ優先度ルールを適用することで、そのスタディの優先度を上げたり下げたりすることができる。これについては、図４で詳細に説明する。
【００４９】
図３は、需給計画及び対処コミットメントの文書化のための、画像プロデューサと画像リーダの関係を示す模式図である。
図３において、画像プロデューサ３０１は対処要求３０２を出し、これはスケジュール・データベース１１２の対処要求部３０４に送られる。一方、画像リーダ３０９は、対処可能性３１０を、スケジューリング・モジュールＵＩ
２４０を介して表示する。対処可能性通知３１２が、スケジュール・データベース１１２の時間部３１２に送られる。需給計画モジュール２２０によって、画像プロデューサの対処要求と画像リーダの対処可能性通知についての照合３０８が、資格認定基準及び画像リーダ・プロファイル１０８と画像プロデューサ・プロファイル１０６に見られるスケジュール・コミットメントを用いて、行われる。
【００５０】
図４は、作業分配エンジン１１４のスタディ分配モジュール２２２がスタディを分配する方法についての詳細なフローチャートである。
ステップ４０２で、作業分配エンジン１１４がスタディを受け取る。ステップ４０４において、作業分配エンジン１１４は、スタディ情報１５６に保存されているスタディ優先度を、プロデューサ・プロファイル・エンジン１０２内のルールを適用した後に、チェックする。優先スタディとは、直ちに処理されなければならないスタディである。優先スタディは、そのスタディの結果が必要とされる緊急性によって、他のスタディよりも優先される。プロデューサ・プロファイル・エンジン１０２では、スタディ優先度は、スタディの着信時刻によって決定されることがある。例えば、画像プロデューサは、その画像プロデューサの施設によってスタディが深夜に送信される場合には、そのスタディが優先度の高いものとみなされることを要請することができる。また、優先度は、どの部科がそのスタディを必要としているのか、またはどの医師がそのスタディを必要としているのかによって、決定することもできる。例えば、受信したスタディが、画像プロデューサの救急科からのものである場合、それは優先度の高いものとみなされることがある。優先度を決定する別の方法は、そのスタディが関係しているモダリティ及び身体部位に基づくものとすることができる。例えば、画像プロデューサは、脳の磁気共鳴画像法（ＭＲＩ）スキャンはすべて優先スタディとみなされることを、要請することができる。
【００５１】
スタディの優先度が高い場合には、ステップ４０６において、作業分配エンジン１１４は、そのスタディの分析及び解釈のために“ホットシート”画像リーダが対処可能であるかどうか判断する。ホットシート画像リーダとは、特定の画像プロデューサに関する需給計画モジュール２２０において、対処に最も早期に応募した画像リーダであって、優先スタディが受信された時点でこのサービスにログインしている者である。例えば、第１の画像リーダが、第１の画像プロデューサからのスタディについての作業に特定の日付及び時間帯に応募していて、さらに同じ日付及び時間帯に、第２の画像リーダが第１と第２の画像プロデューサに応募したとする。第１と第２の画像リーダの両方がログインしている場合、第１の画像リーダは、第１の画像プロデューサにとってホットシート画像リーダであり、第２の画像リーダは、第２の画像プロデューサにとってホットシート画像リーダである。第１のリーダは、ホットシート・リーダであることに対して、自身の複雑度閾値に適用されるスタディ複雑度調整を受ける。第１のリーダは、その特定の時刻にログインしていることに対して、スタディ分配モジュールによる追加調整を受ける。第１の画像リーダがログオンしていない場合には、第２の画像リーダは、両方の画像プロデューサにとってホットシート画像リーダであり、第１のリーダは、自身の複雑度閾値に対する調整を与えられないことになる。
【００５２】
ホットシート画像リーダが対処可能であり、かつスタディの優先度が高い場合には、作業分配エンジン１１４は、ステップ４０８において、リーダの未処理の複雑度及び複雑度閾値に関係なく、そのスタディを割り当てる。ホットシート画像リーダが対処可能ではない場合、作業分配エンジン１１４は、ステップ４１０において、システムにログオンしたアクティブな認可画像リーダが存在するかどうか判断する。システムにログオンしたアクティブな画像リーダが存在する場合、スタディ分配モジュール２２２は、ステップ４０８で、そのアクティブな画像リーダにスタディを割り当てる。アクティブな画像リーダがいずれも優先スタディの読み取りに対処可能ではない場合には、アクティブな画像リーダが対処可能になるまで、そのスタディは“フリー”状態に保持される。
【００５３】
ステップ４０４において、スタディが優先スタディではない場合は、ステップ４１４で、スタディ分配モジュール２２２は、そのスタディが特定の画像リーダに予約されているかどうか判断する。スタディが特定の画像リーダに予約されている場合には、作業分配エンジン１１４は、ステップ４０８で、その特定の画像リーダにスタディを割り当てる。
【００５４】
スタディは、いくつかの方法の１つで、特定の画像リーダに予約される。スタディを特定の画像リーダに予約することができる１つの方法では、ある患者からの医療画像を特定の画像リーダが既に閲覧したことがある場合に、その後、規定の時間内のその患者の画像スタディはいずれも、画像リーダの閾値に適合しているかどうかにかかわりなく、その画像リーダに送られるように、スタディ分配モジュール２２２によって自動的に予約することができる。新しいスタディが着信し、それが過去の患者のものであることがスタディ割当待ちメッセージに示されている場合には、スタディ分配モジュール２２２は、その患者ＩＤを過去のスタディと照合し、過去のスタディに記載されている画像リーダに新しいスタディをルーティングする。別の例では、画像プロデューサは、画像診断を行う前の画像リーダと情報交換することができる。この場合、画像プロデューサは、ウェブＵＩ
１１８のスタディリストＵＩ ２４５を介して、ホットシート・リーダとその連絡先情報を特定する。画像プロデューサは、ホットシート・リーダに連絡を取り、撮像される患者の患者ＩＤをホットシート放射線科医に伝える。ホットシート・リーダは、ウェブ
ＵＩ １１８を介して、その患者ＩＤを画像リーダ・プロファイルＵＩ ２４３に入力することができる。スタディ分配モジュールは、その患者の予約トークンを生成し、その患者トークンを、後にそのスタディが着信するときにスタディ通知メッセージで受け取った患者情報と照合する。
【００５５】
スタディが特定の画像リーダに予約されていない場合には、ステップ４１６で、作業分配エンジン１１４は、そのスタディを作成した画像プロデューサの認可画像リーダのリストをロードする。ステップ４１８で、作業分配エンジン１１４は、リストの１番目の画像リーダを選択し、そしてステップ４２０で、その画像リーダによるスタディの読み取りが可能であるかどうか判断する。画像リーダが、そのスタディのモダリティの経験があることを、その画像リーダのプロファイル１０８が示している場合、画像リーダは、そのスタディの読み取りが可能である。画像リーダによるスタディの読み取りが可能であるかどうかは、その画像リーダの専門分科による影響を受けることもある。例えば、画像リーダの専門分科が小児画像である場合、このことは、その画像リーダによる高齢患者のスタディの読み取りが可能であるかどうかに影響する。その画像リーダによるスタディの読み取りが可能である場合には、ステップ４２２で、スタディ分配モジュール２２２は、そのスタディにモダリティ複雑度調整を適用し、これにより、スタディの複雑度を定義する。複雑度調整は、モダリティ、診断される身体部位、スタディ割当待ちメッセージに含まれるスタディの詳細情報の組み合わせに関連付けられた複雑度重みを適用することによって、決められる。ステップ４２０において、その画像リーダによるスタディの読み取りが可能ではない場合は、ステップ４２４で、その画像リーダは画像リーダのリストから削除される。
【００５６】
ステップ４２６において、スタディ分配モジュール２２２は、その画像リーダにアクティブなスケジュールがあるかどうか判断する。画像リーダが、そのスタディが受信された割り当てタイムスロットに、その画像プロデューサの対処要求に応募している場合に、その画像リーダにアクティブなスケジュールがあるとする。画像リーダにアクティブなスケジュールがある場合には、ステップ４２８で、スタディ分配モジュール２２２は、画像リーダの未処理の作業負荷の作業複雑度にスケジュール調整を適用する。その画像リーダが、他のリーダよりも長くログインしている場合には、そのリーダの未処理の作業負荷の複雑度に追加調整が適用される。画像リーダが、その画像プロデューサの対処要求に最初に応募した者であった場合には、第３の調整が適用されることがある。ステップ４３０において、スタディ分配モジュール２２２は、リストの次の画像リーダに移り、次の画像リーダについてステップ４２０〜４２８を実行する。
【００５７】
ステップ４３０において、作業分配エンジン１１４が認可画像リーダリストの終わりに到達するまで、ステップ４２０〜４２８が繰り返される。ステップ４３２で、作業分配エンジン１１４は、認可画像リーダのリストを、未処理の作業負荷の複雑度の降順で並べ替える。ステップ４３４において、スタディ分配モジュール２２２は、スタディに何らかの事前設定されたルールがあるかどうか判断する。これらのルールとして、限定するものではないが、画像プロデューサ・プロファイル１０６での設定、画像リーダ・プロファイル１０８での設定、時間帯、及びスタディデータによるものを含んでもよい。画像プロデューサ・プロファイル１０６は、例えば、ある時間帯における特定のモダリティのすべてのスタディは、オンライン・ステータスにかかわりなく、特定の画像リーダに割り当てられるべきであるというルールセットを持ってもよい。画像リーダ・プロファイル１０８は、画像リーダの専門分科、または画像リーダがどの身体部位の画像を引き受けるかなどについて表明しているルールセットを持ってもよい。時間帯ルールとして、限定するものではないが、ある時間帯のスタディは、ある特定の画像リーダ・グループによって読み取られるべきであるというようなルールを含んでもよい。スタディデータ・ルールは、限定するものではないが、ある特定のモダリティのスタディは特定のリーダにのみ割り当ててもよいというようなルールを含んでもよい。
【００５８】
ルールが存在する場合には、ステップ４３６で、スタディ分配モジュール２２２は、ルールを適用する。ステップ４３８において、スタディ分配モジュール２２２は、ルールに当てはまらない候補リーダを除いて、リストを残りの候補者で、未処理複雑度による降順または昇順で並べ直す。ステップ４４０で、作業分配エンジン１１４は、リストの最上位の画像リーダ、または調整後の未処理複雑度が未処理複雑度閾値内にあって最も低い複雑度である画像リーダにスタディを割り当てる。ステップ４３４においてルールが存在しない場合には、ステップ４４０で、作業分配エンジン１１４は、リストの最上位の画像リーダ、または調整後の未処理複雑度が未処理複雑度閾値内にあって最も低い複雑度である画像リーダにスタディを割り当てる。調整後の未処理複雑度が、スタディ分配モジュール内で設定されている未処理複雑度閾値未満であるリーダがいない場合には、そのスタディは割り当てられることなく、分配サービス２２２は、再びステップ４１６から開始する。
【００５９】
図５は、図２のシステムを使用した、画像プロデューサ３０１のサードパーティ・アプリケーション２０２と画像リーダのレポートモジュールＵＩ
２４２との間のメッセージフローを示すシーケンス図である。
画像プロデューサ３０１のサードパーティ・アプリケーション２０２は、矢印６０２で示すように、スタディをサードパーティ通信モジュール２０４に送る。サードパーティ通信モジュール２０４は、矢印６０４で示すように、スタディ着信通知を作業分配エンジン１１４に送る。サードパーティ通信モジュール２０４は、矢印６０６で示すように、スタディ割当待ち通知を作業分配エンジンに送る。スタディ割当待ち通知は、そのスタディがどの画像リーダに割り当てられるべきか判断する作業分配エンジン１１４の解釈のための情報を含んでいる。この情報は、限定するものではないが、患者名、患者ＩＤ、検査日付、検査説明、診断する身体部位、画像プロデューサ名、画像プロデューサＩＤ、委託医師を含んでもよい。矢印６１０で、サードパーティ通信モジュール２０４からサードパーティ・アプリケーション２０２に、スタディ転送通知が送られる。スタディ転送通知は、特定の宛先ＤＩＣＯＭアプリケーション・エンティティ・タイトルにスタディを転送するように、画像プロデューサ・インタフェースに対して指示するものである。矢印６１２で、サードパーティ通信モジュール２０４は、過去の関連スタディについてのクエリをサードパーティ・アプリケーション２０２に送り、そしてサードパーティ・アプリケーション２０２に対して、結果のスタディを特定のＤＩＣＯＭアプリケーション・エンティティ・タイトルに送るように指示する。サードパーティ通信モジュール２０４は、矢印６１４で示すように、前例スタディ利用可能イベントを作業分配エンジン１１４に送る。このイベントは、そのスタディが作業アイテムであるか参照用であるかについての情報を伝える。作業アイテムは、画像リーダによる解釈レポートを必要とするスタディである。参照アイテムは、同じ患者の同様の身体部位についての、同一または関連するモダリティの他の画像スタディである。参照アイテムは、解釈される画像スタディで確認されるアイテムが現在のスタディよりも前に存在したかどうか、また、確認されるアイテムが参照スタディの取得から当該スタディまでの期間に変化したどうか判断するために、画像リーダによって使用される。参照アイテムは、一般的に、前例スタディまたは前例と呼ばれている。作業分配エンジン１１４は、必要に応じて、矢印６１６で示すようにスタディリストＵＩ
２４５に対して、または矢印６１６で示すようにサードパーティ・アプリケーション２０２に対して、スタディ優先度設定コマンドを送る。このコマンドで、スタディ優先度が設定されるように、作業分配エンジン１１４内でスタディ・プロファイリング・エンジン２１６により指示が送られる。これは、スタディ・ステータスが最初にスタディと一緒に送信されない場合に生じる。レポートモジュールＵＩ
２４２は、矢印６１８で示すように、画像リーダ・ログイン・イベントを作業分配エンジン１１４に送る。ログイン・イベントは、システムにログインした画像リーダのログイン情報を伝えるものであり、これによって、作業分配エンジン１１４は、その画像リーダが割り当てを受けることが可能であることを知ることができる。矢印６２０で示すように、スタディ割当コマンドが、作業分配エンジン１１４から、レポートがシステムの外部で行われる場合はサードパーティ・アプリケーション２０２に対して、またはレポートがシステムの内部で行われる場合はスタディリストＵＩ
２４５に対して、送られる。このコマンドは、そのスタディが、特定の画像リーダのスタディリスト２４５またはサードパーティ・アプリケーション２０２の同等の要素において利用可能でなければならないことを示している。スタディ取得イベントが、矢印６２４で示すように、レポートモジュールＵＩ
２４２から作業分配エンジン１１４に送られる。このイベントは、そのスタディが、読み取りと解釈のために画像リーダによって取り出されたことを示している。矢印６２６は、スタディ・スキップ・イベントを示している。このイベントは、スタディが閉じられたが、解釈されていないことを示している。作業分配エンジン１１４は、このスタディを再割り当て可能であるとみなすことになる。矢印６２８で示すように、保留イベントが、レポートモジュールＵＩ
２４２から作業分配エンジンに送られる。このイベントは、そのスタディが画像リーダによる最終的な解釈を得ていないが、しかし、このスタディを再割り当てすることもできないことを、作業分配エンジン１１４に知らせるものである。矢印６３０で示すように、スタディ読取イベントが、レポートモジュールＵＩ
２４２から作業分配エンジン１１４に送られる。これは、そのスタディの解釈が完了したことを、作業分配エンジン１１４に知らせるものである。矢印６３２は、作業分配エンジン１１４からサードパーティ通信２０４へのレポート送信を示している。レポートは、矢印６３４で示すように、さらに画像プロデューサ３０１のサードパーティ・アプリケーション２０２に送られる。矢印６３６で示すように、対処可能性通知が、レポートモジュールＵＩ
２４２から作業分配エンジン１１４に送られる。この通知は、その画像リーダが引き続き、更なるスタディの解釈に対処可能であることを作業分配エンジン１１４に知らせるものでる。矢印６３８は、レポートモジュールＵＩ
２４２から作業分配エンジン１１４に伝えられるログアウト・イベントを示している。画像リーダがシステムからログアウトしたという通知を作業分配エンジン１１４が受け取ると、作業分配エンジン１１４は、スタディの割り当てを解除し、その画像リーダに新たなスタディを割り当てることをやめて、それらのスタディを他のログインしている画像リーダに割り当て可能にする。
【００６０】
本明細書に記載の実施形態は、医療画像と医療画像解釈の分配及び管理に適用することができるが、これらの技術は、例えば、電気生理学、皮膚科学、心臓病学、または病理学など、他の医療診断管理システムに適用可能である。
【００６１】
以上、実施形態について説明を行ったが、添付の請求項により規定される趣旨及び範囲から逸脱することなく、変形及び変更の実施が可能である。
【技術分野】
【０００１】
本発明は、広くは診断用画像の管理に関し、特に、診断用画像と診断的解釈サービスを連携調整するシステム及び方法に関するものである。
【０００２】
関連米国出願：
本出願は、本出願の譲受人であるＲｅａｌ Ｔｉｍｅ Ｒａｄｉｏｌｏｇｙに譲渡された特許文献１の利益を主張するものであり、その内容は参照により組み込まれる。
【背景技術】
【０００３】
医療診断用画像と診断的解釈サービスを連携調整するソフトウェア・プロダクトが知られている。そのような連携調整ソフトウェア・プロダクトによって、病院、診療所、研究所といった医療画像プロデューサ、及び医療撮像法またはモダリティを利用できる他の医療画像プロデューサから医療診断用画像を収集して、それらを解釈及び診断を目的として放射線科医及び他の医療専門家といった医療診断用画像リーダに分配することが可能である。これらのプロダクトによると、利用できる資源の事前設定されたスケジュールに、作業が処理されるべき順序でアクセスすることができる。画像プロデューサは、このようなソフトウェア・プロダクトを利用して、画像スタディを医療画像予測専門医に割り振ることで、必要な医療画像の解釈が確実に行われるようにする。
【０００４】
上述のスケジューリング・ソフトウェアは有用となり得るが、言うまでもなく、改良が望まれる。例えば、そのようなツールは、医療画像リーダが対処可能な作業に応募するにあたって、医療画像リーダによる対処への早期コミットメントのような望ましい行動に報いつつ、利益の大きい作業のみ選択されることを防いで、“申し込み順に作業が割り当てられる”方式をとるようにすることができない。また、このようなスケジューリング・システムは、要望が何であるのかについての予備知識を持つことなく医師にサービスを提供させることができない。
【０００５】
既存のスケジューリング／連携調整プロダクトは、医療専門家と、それらの専門家が支援する医療機関との間の実世界インタラクションを反映するものではない。現在利用可能な医療画像用連携調整プロダクトは、ある特定の患者の画像について以前にレポートを作成した医療専門家が、その同じ患者からのその後の画像スタディを閲覧することを可能にする機構を備えていない。また、このようなプロダクトは、リアルタイムで対処可能な医師による優先的な分析を可能にするものではない。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国仮特許出願第６１／２６４３２７号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
そこで、本発明は、上記欠点を解消し、画像診断サービスと画像診断作業注文との連携調整を支援するシステムを提供することを課題とする。
【課題を解決するための手段】
【０００８】
本発明の一態様によれば、画像スタディを、選択された画像リーダに分配する方法を提供し、これは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信することと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送ることと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送ることと、抽出画像スタディ情報から画像スタディ・ルールを特定することと、画像スタディ・ルールに基づいて画像スタディに画像スタディ複雑度を適用することと、上記画像プロデューサからの画像スタディを受け取ることに応募した複数の画像リーダについて画像リーダ複雑度を計算することであって、それらの画像リーダ複雑度の各々を、画像スタディ複雑度と、複数の認可画像リーダの各々に割り当てられた画像リーダ・プロファイルとを用いて計算することと、画像リーダ複雑度に基づいて複数の画像リーダから選択画像リーダを選択することと、画像スタディを選択画像リーダに割り当てることと、ユーザインタフェース上で選択画像リーダに対して画像スタディを表示することと、を含む。
【０００９】
別の態様によれば、画像スタディを、対処可能な画像リーダに分配する方法を提供し、これは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信することと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送ることと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送ることと、抽出画像スタディ情報から画像スタディ・ルールを特定することと、少なくとも１つの画像スタディ・ルールが、その画像スタディが緊急優先度を有することを示している場合に、その画像スタディを、対処可能な画像リーダに割り当てることと、を含む。
【００１０】
別の態様によれば、画像スタディを、予約された画像リーダに分配する方法を提供し、これは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信することと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送ることと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送ることと、抽出画像スタディ情報から画像スタディ・ルールを特定することと、少なくとも１つの画像スタディ・ルールが、その画像スタディが予約画像リーダに予約されたものであることを示している場合に、その画像スタディを、予約画像リーダに割り当てることと、を含む。
【００１１】
別の態様によれば、画像プロデューサにより生成される画像スタディの、画像リーダへの分配をスケジューリングする方法を提供し、これは、少なくとも１つの対処時間帯中に、画像スタディ作業への対処についての要求を画像プロデューサから受け取ることと、複数の画像リーダから、それら複数の画像リーダが画像スタディ作業に対処することが可能な時間帯があることを示す画像リーダ対処可能通知を受け取ることと、上記少なくとも１つの対処時間帯を、対応する対処可能時間帯を持つ画像リーダと照合することと、上記少なくとも１つの対処時間帯中に受け取る画像スタディを、対応する対処可能時間帯を持つ画像リーダに割り当てることと、を含む。
【００１２】
さらに別の態様によれば、画像分配システムを提供し、これは、関連付けられた画像リーダ・プロファイルをそれぞれ有する複数の画像リーダから選択される画像リーダによる解釈を得ることを目的とする画像スタディを、画像プロデューサから受信するためのサードパーティ通信モジュールであって、受信通知メッセージを生成するサードパーティ通信モジュールと、サードパーティ通信モジュールとやり取りするためのメッセージング層であって、受信通知メッセージを受け取って、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを生成するメッセージング層と、メッセージング層と通信可能に接続された作業分配エンジンであって、スタディ通知メッセージを受け取って、抽出画像スタディ情報から画像スタディ・ルールを特定し、スタディ・ルールに基づいてスタディ複雑度を画像スタディに適用し、複数の画像リーダについての画像リーダ複雑度を、スタディ複雑度及び関連する画像リーダ・プロファイルをそれぞれ用いて計算し、計算された画像リーダ複雑度に基づいて画像リーダを選択し、この選択画像リーダに画像スタディをルーティングする、作業分配エンジンと、スタディ・ルーティング・モジュールから送られる画像スタディを受け取って、画像スタディを選択画像リーダに対して表示するためのユーザインタフェースと、を備える。
【００１３】
さらに別の態様によれば、画像スタディを選択された画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体を提供し、該コンピュータプログラムコードは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信するためのプログラムコードと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、画像スタディ・ルールに基づいて画像スタディに画像スタディ複雑度を適用するためのプログラムコードと、上記画像プロデューサからの画像スタディを受け取ることに応募した複数の画像リーダについて画像リーダ複雑度を計算するためのプログラムコードであって、それらの画像リーダ複雑度の各々を、画像スタディ複雑度及び複数の認可画像リーダの各々に割り当てられた画像リーダ・プロファイルを用いて計算するためのプログラムコードと、画像リーダ複雑度に基づいて複数の画像リーダから選択画像リーダを選択するためのプログラムコードと、画像スタディを選択画像リーダに割り当てるためのプログラムコードと、ユーザインタフェース上で選択画像リーダに対して画像スタディを表示するためのプログラムコードと、を含む。
【００１４】
さらなる態様によれば、画像スタディを対処可能なリーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体を提供し、該コンピュータプログラムコードは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信するためのプログラムコードと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、少なくとも１つの画像スタディ・ルールが、その画像スタディが緊急優先度を有することを示している場合に、その画像スタディを、対処可能な画像リーダに割り当てるためのプログラムコードと、を含む。
【００１５】
さらなる態様によれば、画像スタディを予約された画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体を提供し、該コンピュータプログラムコードは、サードパーティ通信モジュールで画像プロデューサから画像スタディを受信するためのプログラムコードと、サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、少なくとも１つの画像スタディ・ルールが、その画像スタディが予約画像リーダに予約されたものであることを示している場合に、その画像スタディを、予約画像リーダに割り当てるためのプログラムコードと、を含む。
【００１６】
さらに別の態様によれば、画像プロデューサにより生成される画像スタディを画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体を提供し、該コンピュータプログラムコードは、少なくとも１つの対処時間帯中に、画像スタディ作業への対処についての要求を画像プロデューサから受け取るためのプログラムコードと、複数の画像リーダから、それら複数の画像リーダが画像スタディ作業に対処することが可能な時間帯があることを示す画像リーダ対処可能通知を受け取るためのプログラムコードと、上記少なくとも１つの対処時間帯を、対応する対処可能時間帯を持つ画像リーダと照合するためのプログラムコードと、上記少なくとも１つの対処時間帯中に受け取る画像スタディを、対応する対処可能時間帯を持つ画像リーダに割り当てるためのプログラムコードと、を含む。
【図面の簡単な説明】
【００１７】
【図１Ａ】サービス提供者へのサービス要求を連携調整及び分配するシステムの典型例のブロック図
【図１Ｂ】図１Ａの構成要素の一実施形態のエンティティ関係を示す説明図
【図２】図１Ａのシステムの一実施形態のブロック図
【図３】図１Ａ及び１Ｂの需給計画モジュールの構成要素の一実施形態の模式図
【図４】図２の構成要素により用いられる方法の典型例のフローチャート
【図５】図２のシステムで用いる画像プロデューサと画像リーダの間の典型的なワークフローを示すシーケンス図
【発明を実施するための形態】
【００１８】
以下に、添付の図面を参照して、実施形態についてより詳細に説明する。
【００１９】
図１Ａは、画像プロデューサから医療画像診断専門医または画像読取サービス提供者への医療画像サービス要求を連携調整及び分配するためのシステムを示していて、その全体を参照番号１００で識別している。
本実施形態におけるシステムでは、データベース１０５にアクセスするプロデューサ・プロファイル・エンジン１０２を示している。データベース１０５は、画像プロデューサ・プロファイル１０６、画像リーダ・プロファイル１０８、スタディデータ１１０、スケジュール１１２を格納している。また、作業分配エンジン１１４も、同様にデータベース１０５にアクセスし、さらにレポートツール１１６にアクセスする。ウェブベースのユーザインタフェース１１８も、やはりデータベース１０５にアクセスする。
【００２０】
図１Ａに示すシステム１００の実施形態では、画像プロデューサは、ウェブＵＩ １１８を介してプロデューサ・プロファイル１０６にアクセスすることができる。画像プロデューサは、病院、診療所、研究所、及び、画像読取サービス提供者による解釈を得るための医療診断用画像を生成することができる他の医療機関を含んでもよいが、これらに限定されるものではない。画像読取サービス提供者は、通常は放射線科医であるが、医療画像を解釈する訓練を積んだ医療専門家を含めることもできる。そして、画像読取サービス提供者すなわち画像リーダは、ウェブ・ユーザインタフェース（ＵＩ）１１８を介して画像リーダ・プロファイル１０８にアクセスする。
【００２１】
プロデューサ・プロファイル・エンジン１０２によって、画像プロデューサは、特定のスタディについて、そのスタディデータ１０をデータベース１０５に保存することができる。スタディとは、画像プロデューサにより生成された医療診断用画像であって、医療専門家または画像読取サービス提供者により読み取り及び解釈されるべきものである。スタディデータ１１０は、スタディ履歴とスタディレポートを含んでもよい。スタディ履歴は、特定のスタディが作成された日時、アクセスされた日時、作業が行われた日時、及び、そのスタディがどの医療専門家によるものであるかを、画像プロデューサに対して示すものである。スタディレポートは、画像読取サービス提供者によるスタディ解釈結果の文書である。
【００２２】
画像プロデューサは、自身の施設、自身が解釈を求めるモダリティまたは撮像技術、認可した画像リーダのリスト、及び、通知を受ける希望の方法について、プロデューサ・プロファイル１０６の情報をウェブＵＩ
１１８によって提供することが可能である。認可画像リーダとは、画像プロデューサが、その画像プロデューサのスタディに対して許可された画像リーダとして選択した画像リーダである。画像プロデューサ・プロファイル１０６は、限定するものではないが、識別番号、所在地または実際の住所、画像プロデューサが送付すると予想されるスタディのボリュームといった情報をさらに含むものであってもよい。
【００２３】
ウェブＵＩ １１８によって、画像プロデューサは、自身が画像リーダによる対処を必要とする時間帯、及び、その時間帯中に自身が生成すると予想されるスタディのボリュームを指定することが可能であり、また、これらの要件をスケジュール１１２に保存することが可能である。
【００２４】
画像リーダ・プロファイル・ウェブＵＩ １１８によって、画像リーダは、自身の作業のスケジュールを立てることができる。画像リーダ・プロファイル・ウェブＵＩ
１１８によって、画像リーダは、さらに、予想される自身の作業容量、自身が専門とするモダリティ及び専門分科、サービスを提供することに自身が同意できない画像プロデューサ、通知を受ける希望の方法について、自身の画像リーダ・プロファイル１０８の情報を提供することが可能である。画像リーダのデフォルトの予想作業容量は、それぞれの特定の検査モダリティについて、時間当たりの単位数で指定される。例えば、特定の検査モダリティについて値がゼロであれば、その画像リーダが、そのモダリティの解釈を提供することはできないことを示している。
【００２５】
ウェブＵＩ １１８によって、画像リーダは、自身が対処することができる時間帯、自身が解釈することが可能なスタディのボリューム、自身が対処するつもりのある特定の画像プロデューサを指定することができ、また、これらの情報をスケジューリング・モジュール１１２に保存することができる。
【００２６】
作業分配エンジン１１４は、データベースからのスタディデータ１１０にアクセスし、容量と資格認定のルールを用いて、画像リーダの対処可能性を画像プロデューサのスケジュール１１２と照合し、これにより、画像プロデューサの対処要件と画像読取サービス提供者の対処可能性をマッチさせる。
【００２７】
ウェブＵＩ １１８は、システム上に受け取ったスタディのリストを表示する。そのようなリストには、受け取られたが解釈はされていないスタディ、特定の画像リーダに割り当てられているスタディ、解釈されたスタディ、キャンセルされたスタディが含まれる。ウェブＵＩはまた、特定のスタディについてレポートツール１１６を起動する機能、スタディをキャンセルする機能、スタディを予約する機能、またはスタディを特定の画像リーダに手動で割り当てる機能を提供する。さらに、ウェブＵＩ
１１８は、レポートツール１１６で作成されたスタディ解釈結果を表示する機能を提供する。
【００２８】
図１Ｂは、図１Ａのシステムの構成要素間の関係を示すエンティティ関係図である。
画像リーダ１５０は、固有の画像リーダＩＤを有している。画像リーダ１５０には、画像リーダ・プロファイル１０８が関連付けられていて、これは、画像リーダのフルネーム、詳しい連絡先、スキル、及びボリューム情報といった情報を含んでいる。画像リーダ１５０は、対処可能性のコミットメントをスケジュール１１２の中に作成する。画像リーダ１５０は、スタディ１５６の解釈を担当する。スタディ１５６は、固有のスタディ識別子などの属性、画像プロデューサＩＤ、患者情報、モダリティ、検査時間及び検査説明などのスタディデータ、解釈されるべきことの指示（作業アイテム）、ステータス、優先度などのワークフロー・データを有している。作業アイテムであるスタディ１５６について、レポート１５８が作成される。レポート１５８は、画像リーダの署名、バージョン、具体的な解釈内容などの情報を含むことができる。画像プロデューサ１６０は、固有の画像プロデューサＩＤを有している。画像プロデューサ１６０には、画像プロデューサ・プロファイル１０６が関連付けられていて、これは、詳しい連絡先、予想されるボリューム、このプロデューサＩＤからのスタディの受信時にプロデューサ・プロファイル・エンジン１０２により適用されるべきルールといった情報を含んでいる。画像プロデューサ１６０は、スケジュール１１２の中に対処要求を生成することができる。画像プロデューサ１６０は、システムに送信されるスタディ１５６を作成する。
【００２９】
資格認定は、特定の画像プロデューサに対し、画像リーダが対処して、スタディ情報を閲覧し、解釈レポートを作成することが可能であることを明示するプロセスである。システム管理者により、システム管理ＵＩ
２４４でアソシエーションが定義され、データベース１０５の認可テーブル１６４に記憶される。
【００３０】
図２は、画像プロデューサからの医療画像読取サービス要求を画像読取サービス提供者に分配するシステムの一実施形態の典型的な模式図を示していて、その全体を参照番号２００によって識別している。
図２では、サードパーティ業界標準画像アーカイブ／通信システム（ＰＡＣＳ：Ｐｉｃｔｕｒｅ Ａｒｃｈｉｖｅ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ
Ｓｙｓｔｅｍ）アプリケーション２０２が、様々な種類の画像スタディを受け付けて判別することができるサードパーティ通信モジュール２０４とやり取りする。サードパーティ通信モジュール２０４はまた、ＨＬ７など他の種類の通信プロトコルを用いて他のサードパーティ・スタディを受け付けることもできる。本例では、サードパーティ通信モジュール２０４は、ＤＩＣＯＭスタディを受信して保存し、スタディが受信されたことの通知を生成し、ＤＩＣＯＭスタディ移動コマンドを発行し、ＤＩＣＯＭスタディのクエリを発する。本例では、サードパーティ通信モジュール２０４は、ＤＩＣＯＭ統合モジュール２０６を含み、これは、限定するものではないが、スタディ通知モジュール２０８、スタディ・ルーティング・モジュール２１０、プリフェッチ・モジュール２１２などのモジュールを含んでもよい。スタディ通知モジュール２０８は、スタディの受信時にメッセージを作成し、これらのメッセージをメッセージング層２１４に伝送する。スタディ・ルーティング・モジュール２１０は、スタディ・ルーティング命令メッセージをメッセージング層２１４から受け取り、指示された宛先にスタディを移動させるようにサードパーティ通信モジュール２０４に対して命令する。プリフェッチ・モジュール２１２は、スタディの受信時にメッセージング層２１４からメッセージを受け取り、これにより、他の関連スタディの利用可能性について業界標準サードパーティ・アプリケーション（ＰＡＣＳ）２０４に問い合わせして、受信スタディに関連するスタディを取り出す。
【００３１】
別の実施形態では、サードパーティ通信モジュール２０４は、ＤＩＣＯＭ統合モジュール２０６をバイパスし、メッセージング層２１４と直接通信する。メッセージング層２１４は、スタディに関する情報をサードパーティ通信モジュール２０４から受け取り、割当待ちのスタディがあるという通知メッセージを作業分配エンジン１１４に送る。
【００３２】
通知メッセージは、一般的には、スタディのＤＩＣＯＭヘッダから取り出された情報を含み、それはＤＩＣＯＭ統合モジュール２０６内からのものである。通知メッセージのこの情報は、限定するものではないが、患者ＩＤ、患者名、画像プロデューサＩＤ、画像プロデューサのスタディ識別子、スタディ作成日付、発注部科、スタディ内の画像数を含むことができる。
【００３３】
そして、メッセージング層２１４は、作業分配エンジン１１４とやり取りする。本例では、作業分配エンジン１１４は、スタディ・プロファイリング・ルールエンジン２１６、スタディ・ルーティング・モジュール２１８、需給計画モジュール２２０、スタディ分配モジュール２２２、結果管理モジュール２２４、及びメッセージ送信処理モジュール２２６を有している。スタディ・プロファイリング・ルールエンジン２１６は、メッセージング層２１４から受け取ったスタディ通知に対して動作を実行する。それらの動作を実行することで、スタディ・プロファイリング・ルールエンジン２１６は、特定のスタディをルーティングしてもよいかどうか、そのスタディはどのような優先度であるべきか、そのスタディを解釈されるべきスタディ（すなわち作業アイテム）とみなすべきか参照用スタディとみなすべきかについて、判断することができる。
【００３４】
スタディ・ルーティング・モジュール２１８は、スタディの一部として受け取った、プロデューサＩＤや、特定の実施形態ではスタディ分配モジュール２２２により決定された割当済みの画像リーダなどの情報を用いて、メッセージング層２１４を介して伝送される命令メッセージを生成し、これにより、サードパーティ通信モジュール２０４は、スタディを特定のサードパーティ・アプリケーション（ＰＡＣＳ）２０２に移動させて、表示させる。
【００３５】
需給計画モジュール２２０は、スケジュール１１２からの画像プロデューサ対処要求情報、スケジュール１１２からの画像リーダ対処可能性情報、プロデューサ・プロファイル及びリーダ・プロファイルからの画像リーダ資格認定情報を消化して、プロデューサの要求を画像リーダの対処可能性と照合し、プロデューサとリーダの各接点についてのサービス契約を保存する。画像リーダにより表明された対処可能な容量が、プロデューサにより表明された要求に対して解釈を提供するのに不十分である場合には、需給計画モジュール２２０は、スケジューリング・モジュールＵＩ
２４０を介して警告を発する。
【００３６】
需給計画モジュール２２０は、指定された間隔で、近々予定される対処コミットメントについて画像リーダに通知する。一実施形態において、指定した間隔でのこれらの通知は、メッセージ送信処理モジュール２２６を用いて送信されるインターネットカレンダー形式のメッセージを介して、画像リーダのプロファイル１０８に記憶されている画像リーダの電子メールアドレスを用いた電子メールにより実現することができる。別の実施形態では、近々予定される対処コミットメントの通知は、データベース１０５に保存されている画像リーダのプロファイル１０８に記憶されている定期的通知の値に従って、近々予定される対処コミットメントを提示する定期的な電子メール・メッセージで、メッセージ送信処理モジュール２２６により送信される。
【００３７】
画像プロデューサからの注文が発生すると、その注文は、スタディ分配モジュール２２２に伝えられる。スタディ分配モジュール２２２は、複数のスタディ画像プロデューサから複数のスタディ・コンシューマ（リーダ）へのスタディの分配を行う。この分配は、一連のルールと、各画像リーダの未処理の作業量、スタディの優先度、サービスオペレータにより規定される調整値といった重み付け判断とに基づくものである。
【００３８】
作業分配エンジン１１４は、画像プロデューサ、画像リーダ、及びシステム管理者がアクセスできるウェブ・ユーザインタフェース２３８とやり取りする。ウェブ・ユーザインタフェース２３８は、スケジューリング・モジュール・ユーザインタフェース（ＵＩ）２４０、画像プロデューサ・プロファイル・ユーザインタフェース（ＵＩ）２４１、画像リーダ・プロファイル・ユーザインタフェース（ＵＩ）２４３、及びレポートモジュール・ユーザインタフェース（ＵＩ）２４２を含むことができる。
【００３９】
スケジューリング・モジュールＵＩ ２４０は、特定の時間帯または複数の繰り返し時間帯について画像プロデューサが自身の対処要求を表明するための、カレンダー型表示を提供する。画像プロデューサは、特定の対処要求の各々について、自身の画像プロデューサ・プロファイル１０６に記憶されている予想スタディ・ボリューム情報を変更することができる。特定の時間帯または複数の繰り返し時間帯について画像リーダが自身の対処可能性を表明するために、同様のカレンダー型表示を利用することができる。画像リーダにより提供可能な容量の合計が、画像プロデューサにより表明された要求の合計以上であると需給計画モジュール２２０により判断される場合には、ユーザインタフェースは、その時間帯の色を、十分な対処を示すように変更する。
【００４０】
画像プロデューサ・プロファイルＵＩ ２４１及び画像リーダ・プロファイルＵＩ ２４３は、プロデューサ及びリーダが、デフォルトのボリューム、連絡先情報など、自身のプロデューサ・プロファイル３２６及び画像リーダ・プロファイル３２４の情報を管理するための画面を提供し、さらに、リーダ・プロファイルの場合には、専門分科の領域と除外プロデューサの領域を提供する。ユーザインタフェースに入力された情報は、プロデューサ・プロファイル１０６と画像リーダ・プロファイル１０８にそれぞれ保存される。
【００４１】
スタディリストＵＩ ２４５は、システム上でレポート用に割り当て可能なスタディ、スタディのステータス、スタディの割り当て履歴、スタディがどのリーダに割り当てられているのかを表示するためのリスト及び機能を提供し、さらに、ユーザの権限によっては、解釈の結果を表示する機能、または既に解釈のために指定されているスタディをキャンセルする機能を提供する。スタディリスト・モジュールの中のスタディは、スタディデータ１１０から取り出される。
【００４２】
システム管理ＵＩ ２４４は、画像プロデューサと画像リーダとの間にリンクを形成するための入力手段、例えばアクレディテーション１６４を提供し、さらに、プロデューサ・プロファイル・エンジン１０２のルールとパラメータを定義するための入力手段、スタディ分配モジュール２２２のルールとパラメータを定義するための入力手段、画像プロデューサＩＤ及び画像リーダＩＤを生成するための入力手段を提供する。
【００４３】
レポートモジュールＵＩ ２４２は、スタディリストＵＩ ２４５から起動されて、スタディ解釈結果を文書化するための入力手段を提供し、さらに、スタディと関連付けられた画像データを表示するための適当な診断画像ビューアを起動する。入力フォームは、検査説明、モダリティ、プロデューサＩＤなど、スタディ割当待ちメッセージで受け取るデータに応じて異なることがある。
【００４４】
一実施形態では、画像リーダによるスタディについての注文を生成する前に、情報が取得、転送、または変更される。スタディ・プロファイリング・ルールエンジン２１６は、各画像プロデューサＩＤについて、データベース１０５に保存されているスタディ・プロファイリング情報を参照することで、画像プロデューサから受け取ったスタディ割当待ち通知に対して適用されるルールと動作を決定する。ルールと動作は、単独で、または組み合わせて用いることができる。別の実施形態では、スタディ・プロファイリング・ルールエンジン２１６は、メッセージング層２１４からの送信により受け取ったスタディ通知メッセージから、画像プロデューサＩＤ情報を取り出して、ＤＩＣＯＭ統合モジュール２０６へのスタディ転送メッセージを生成し、これによって、サードパーティ通信モジュール２０４は、受信したスタディを、プロデューサ・プロファイルで規定されているターゲット解釈ＰＡＣＳシステムに転送する。
【００４５】
スタディ分配モジュール２２２は、画像リーダの対処可能性を、画像プロデューサのスケジュールと照合して、資格認定、及び作業負荷ルールにより、スタディを画像リーダに割り当てる。スタディ着信通知が受け取られて、スタディが作業分配エンジン１１４に入力されると、スタディ分配モジュール２２２は、スタディに複雑度を割り当てて、その複雑度を合計し、また、各画像リーダに割り当てられた作業量を比較する。複雑度は、スタディの料金収入とスタディの処理にかかる予測時間の組み合わせから導出される。個々のスタディの複雑度は、受信したスタディから導出した情報、検査説明、検査モダリティ、検査で撮像された身体部位に基づくものであってもよい。
【００４６】
別の実施形態では、ＤＩＣＯＭ統合モジュール２０６は、サードパーティ・アプリケーション（ＰＡＣＳ）２０２に保存されている関連スタディの利用可能性を特定するためのクエリを発する。関連スタディがある場合は、プリフェッチ・モジュール２１２が、受信したスタディ通知メッセージから、患者ＩＤ、検査説明、検査モダリティ、及び送信ＰＡＣＳシステム情報を取り出し、さらに、画像プロデューサ・プロファイル１０６に保存されているターゲットＰＡＣＳシステム情報を取り出す。スタディ・ルーティング・モジュール２１６は、ＤＩＣＯＭ統合モジュール２０６のプリフェッチ・モジュール２１２にコマンドメッセージを送り、これによって、サードパーティ通信２０４がターゲットＰＡＣＳシステムに対して制約付きＤＩＣＯＭクエリメッセージを発する。受け取った情報はプリフェッチ・モジュール２１２により用いられ、これにより、サードパーティ通信２０４が、プロデューサＰＡＣＳに対してＤＩＣＯＭ移動コマンドを発する。そして、プロデューサＰＡＣＳは、同定したスタディを、システムにより規定される関連スタディＤＩＣＯＭアプリケーション・エンティティ・タイトルに送る。関連スタディの各々を順次受け取るごとに、ＤＩＣＯＭ統合モジュール２０６は、“スタディ利用可能イベント”を生成し、この情報を、関連スタディ論理アドレス情報（例えば、ＤＩＣＯＭアプリケーション・エンティティ・タイトル）を含めて、スタディ・プロファイリング・ルールエンジン２１６に対してメッセージング層２１４を利用して送る。スタディ・プロファイリング・ルールエンジン２１６は、取り出されたスタディが単なる参照用であって、解釈のための注文を発生させるものではないことを、関連スタディ論理アドレス情報を用いて判断する。スタディ・プロファイリング・ルールエンジン２１６は、メッセージング層２１４を介してスタディ・ルーティング・モジュール２１０に対し“スタディ転送”メッセージを送り、これによって、サードパーティ通信２０４は、スタディを、画像プロデューサ・プロファイル１０６に保存されたデータで規定されているターゲット解釈ＰＡＣＳシステムに転送する。
【００４７】
さらに別の実施形態では、画像プロデューサからの関連スタディの送信をＤＩＣＯＭ統合モジュール２０６が請求するのではなく、画像プロデューサが、解釈用のスタディと、送信請求されてない関連情報とを一緒に送信してもよい。この場合、スタディ・プロファイリング・ルールエンジン２１６は、通知メッセージからスタディが作成された日時を参照することで、送信されたどのスタディが解釈されるべきものであり、どれが関連情報であるか判断する。関連情報は、一般的には、読み取り及び解釈されるべきスタディよりも先に、既に解釈されたスタディである。スタディ・プロファイリング・ルールエンジン２１６は、関連情報については、スタディ情報１５６に記憶されるスタディ・ステータスを“キャンセル”値に設定する。スタディ・プロファイリング・ルールによるスタディのプロファイル設定が誤りである場合には、これを、システム管理者がシステム管理ＵＩ
２４４を介して手動で有効なスタディに変換することができる。同様に、有効なスタディであるとみなされたスタディを、システム管理者は、画像プロデューサによりそのように指示された場合は手動で取り消すことができる。
【００４８】
さらに別の実施形態では、スタディ・プロファイリング・ルールエンジン２１６は、画像プロデューサ・プロファイル１０６内の画像プロデューサＩＤ、スタディがシステムに受信された時刻、スタディの優先度、スタディを発注した画像プロデューサの部科を用いて、スタディ優先度ルールを適用することで、そのスタディの優先度を上げたり下げたりすることができる。これについては、図４で詳細に説明する。
【００４９】
図３は、需給計画及び対処コミットメントの文書化のための、画像プロデューサと画像リーダの関係を示す模式図である。
図３において、画像プロデューサ３０１は対処要求３０２を出し、これはスケジュール・データベース１１２の対処要求部３０４に送られる。一方、画像リーダ３０９は、対処可能性３１０を、スケジューリング・モジュールＵＩ
２４０を介して表示する。対処可能性通知３１２が、スケジュール・データベース１１２の時間部３１２に送られる。需給計画モジュール２２０によって、画像プロデューサの対処要求と画像リーダの対処可能性通知についての照合３０８が、資格認定基準及び画像リーダ・プロファイル１０８と画像プロデューサ・プロファイル１０６に見られるスケジュール・コミットメントを用いて、行われる。
【００５０】
図４は、作業分配エンジン１１４のスタディ分配モジュール２２２がスタディを分配する方法についての詳細なフローチャートである。
ステップ４０２で、作業分配エンジン１１４がスタディを受け取る。ステップ４０４において、作業分配エンジン１１４は、スタディ情報１５６に保存されているスタディ優先度を、プロデューサ・プロファイル・エンジン１０２内のルールを適用した後に、チェックする。優先スタディとは、直ちに処理されなければならないスタディである。優先スタディは、そのスタディの結果が必要とされる緊急性によって、他のスタディよりも優先される。プロデューサ・プロファイル・エンジン１０２では、スタディ優先度は、スタディの着信時刻によって決定されることがある。例えば、画像プロデューサは、その画像プロデューサの施設によってスタディが深夜に送信される場合には、そのスタディが優先度の高いものとみなされることを要請することができる。また、優先度は、どの部科がそのスタディを必要としているのか、またはどの医師がそのスタディを必要としているのかによって、決定することもできる。例えば、受信したスタディが、画像プロデューサの救急科からのものである場合、それは優先度の高いものとみなされることがある。優先度を決定する別の方法は、そのスタディが関係しているモダリティ及び身体部位に基づくものとすることができる。例えば、画像プロデューサは、脳の磁気共鳴画像法（ＭＲＩ）スキャンはすべて優先スタディとみなされることを、要請することができる。
【００５１】
スタディの優先度が高い場合には、ステップ４０６において、作業分配エンジン１１４は、そのスタディの分析及び解釈のために“ホットシート”画像リーダが対処可能であるかどうか判断する。ホットシート画像リーダとは、特定の画像プロデューサに関する需給計画モジュール２２０において、対処に最も早期に応募した画像リーダであって、優先スタディが受信された時点でこのサービスにログインしている者である。例えば、第１の画像リーダが、第１の画像プロデューサからのスタディについての作業に特定の日付及び時間帯に応募していて、さらに同じ日付及び時間帯に、第２の画像リーダが第１と第２の画像プロデューサに応募したとする。第１と第２の画像リーダの両方がログインしている場合、第１の画像リーダは、第１の画像プロデューサにとってホットシート画像リーダであり、第２の画像リーダは、第２の画像プロデューサにとってホットシート画像リーダである。第１のリーダは、ホットシート・リーダであることに対して、自身の複雑度閾値に適用されるスタディ複雑度調整を受ける。第１のリーダは、その特定の時刻にログインしていることに対して、スタディ分配モジュールによる追加調整を受ける。第１の画像リーダがログオンしていない場合には、第２の画像リーダは、両方の画像プロデューサにとってホットシート画像リーダであり、第１のリーダは、自身の複雑度閾値に対する調整を与えられないことになる。
【００５２】
ホットシート画像リーダが対処可能であり、かつスタディの優先度が高い場合には、作業分配エンジン１１４は、ステップ４０８において、リーダの未処理の複雑度及び複雑度閾値に関係なく、そのスタディを割り当てる。ホットシート画像リーダが対処可能ではない場合、作業分配エンジン１１４は、ステップ４１０において、システムにログオンしたアクティブな認可画像リーダが存在するかどうか判断する。システムにログオンしたアクティブな画像リーダが存在する場合、スタディ分配モジュール２２２は、ステップ４０８で、そのアクティブな画像リーダにスタディを割り当てる。アクティブな画像リーダがいずれも優先スタディの読み取りに対処可能ではない場合には、アクティブな画像リーダが対処可能になるまで、そのスタディは“フリー”状態に保持される。
【００５３】
ステップ４０４において、スタディが優先スタディではない場合は、ステップ４１４で、スタディ分配モジュール２２２は、そのスタディが特定の画像リーダに予約されているかどうか判断する。スタディが特定の画像リーダに予約されている場合には、作業分配エンジン１１４は、ステップ４０８で、その特定の画像リーダにスタディを割り当てる。
【００５４】
スタディは、いくつかの方法の１つで、特定の画像リーダに予約される。スタディを特定の画像リーダに予約することができる１つの方法では、ある患者からの医療画像を特定の画像リーダが既に閲覧したことがある場合に、その後、規定の時間内のその患者の画像スタディはいずれも、画像リーダの閾値に適合しているかどうかにかかわりなく、その画像リーダに送られるように、スタディ分配モジュール２２２によって自動的に予約することができる。新しいスタディが着信し、それが過去の患者のものであることがスタディ割当待ちメッセージに示されている場合には、スタディ分配モジュール２２２は、その患者ＩＤを過去のスタディと照合し、過去のスタディに記載されている画像リーダに新しいスタディをルーティングする。別の例では、画像プロデューサは、画像診断を行う前の画像リーダと情報交換することができる。この場合、画像プロデューサは、ウェブＵＩ
１１８のスタディリストＵＩ ２４５を介して、ホットシート・リーダとその連絡先情報を特定する。画像プロデューサは、ホットシート・リーダに連絡を取り、撮像される患者の患者ＩＤをホットシート放射線科医に伝える。ホットシート・リーダは、ウェブ
ＵＩ １１８を介して、その患者ＩＤを画像リーダ・プロファイルＵＩ ２４３に入力することができる。スタディ分配モジュールは、その患者の予約トークンを生成し、その患者トークンを、後にそのスタディが着信するときにスタディ通知メッセージで受け取った患者情報と照合する。
【００５５】
スタディが特定の画像リーダに予約されていない場合には、ステップ４１６で、作業分配エンジン１１４は、そのスタディを作成した画像プロデューサの認可画像リーダのリストをロードする。ステップ４１８で、作業分配エンジン１１４は、リストの１番目の画像リーダを選択し、そしてステップ４２０で、その画像リーダによるスタディの読み取りが可能であるかどうか判断する。画像リーダが、そのスタディのモダリティの経験があることを、その画像リーダのプロファイル１０８が示している場合、画像リーダは、そのスタディの読み取りが可能である。画像リーダによるスタディの読み取りが可能であるかどうかは、その画像リーダの専門分科による影響を受けることもある。例えば、画像リーダの専門分科が小児画像である場合、このことは、その画像リーダによる高齢患者のスタディの読み取りが可能であるかどうかに影響する。その画像リーダによるスタディの読み取りが可能である場合には、ステップ４２２で、スタディ分配モジュール２２２は、そのスタディにモダリティ複雑度調整を適用し、これにより、スタディの複雑度を定義する。複雑度調整は、モダリティ、診断される身体部位、スタディ割当待ちメッセージに含まれるスタディの詳細情報の組み合わせに関連付けられた複雑度重みを適用することによって、決められる。ステップ４２０において、その画像リーダによるスタディの読み取りが可能ではない場合は、ステップ４２４で、その画像リーダは画像リーダのリストから削除される。
【００５６】
ステップ４２６において、スタディ分配モジュール２２２は、その画像リーダにアクティブなスケジュールがあるかどうか判断する。画像リーダが、そのスタディが受信された割り当てタイムスロットに、その画像プロデューサの対処要求に応募している場合に、その画像リーダにアクティブなスケジュールがあるとする。画像リーダにアクティブなスケジュールがある場合には、ステップ４２８で、スタディ分配モジュール２２２は、画像リーダの未処理の作業負荷の作業複雑度にスケジュール調整を適用する。その画像リーダが、他のリーダよりも長くログインしている場合には、そのリーダの未処理の作業負荷の複雑度に追加調整が適用される。画像リーダが、その画像プロデューサの対処要求に最初に応募した者であった場合には、第３の調整が適用されることがある。ステップ４３０において、スタディ分配モジュール２２２は、リストの次の画像リーダに移り、次の画像リーダについてステップ４２０〜４２８を実行する。
【００５７】
ステップ４３０において、作業分配エンジン１１４が認可画像リーダリストの終わりに到達するまで、ステップ４２０〜４２８が繰り返される。ステップ４３２で、作業分配エンジン１１４は、認可画像リーダのリストを、未処理の作業負荷の複雑度の降順で並べ替える。ステップ４３４において、スタディ分配モジュール２２２は、スタディに何らかの事前設定されたルールがあるかどうか判断する。これらのルールとして、限定するものではないが、画像プロデューサ・プロファイル１０６での設定、画像リーダ・プロファイル１０８での設定、時間帯、及びスタディデータによるものを含んでもよい。画像プロデューサ・プロファイル１０６は、例えば、ある時間帯における特定のモダリティのすべてのスタディは、オンライン・ステータスにかかわりなく、特定の画像リーダに割り当てられるべきであるというルールセットを持ってもよい。画像リーダ・プロファイル１０８は、画像リーダの専門分科、または画像リーダがどの身体部位の画像を引き受けるかなどについて表明しているルールセットを持ってもよい。時間帯ルールとして、限定するものではないが、ある時間帯のスタディは、ある特定の画像リーダ・グループによって読み取られるべきであるというようなルールを含んでもよい。スタディデータ・ルールは、限定するものではないが、ある特定のモダリティのスタディは特定のリーダにのみ割り当ててもよいというようなルールを含んでもよい。
【００５８】
ルールが存在する場合には、ステップ４３６で、スタディ分配モジュール２２２は、ルールを適用する。ステップ４３８において、スタディ分配モジュール２２２は、ルールに当てはまらない候補リーダを除いて、リストを残りの候補者で、未処理複雑度による降順または昇順で並べ直す。ステップ４４０で、作業分配エンジン１１４は、リストの最上位の画像リーダ、または調整後の未処理複雑度が未処理複雑度閾値内にあって最も低い複雑度である画像リーダにスタディを割り当てる。ステップ４３４においてルールが存在しない場合には、ステップ４４０で、作業分配エンジン１１４は、リストの最上位の画像リーダ、または調整後の未処理複雑度が未処理複雑度閾値内にあって最も低い複雑度である画像リーダにスタディを割り当てる。調整後の未処理複雑度が、スタディ分配モジュール内で設定されている未処理複雑度閾値未満であるリーダがいない場合には、そのスタディは割り当てられることなく、分配サービス２２２は、再びステップ４１６から開始する。
【００５９】
図５は、図２のシステムを使用した、画像プロデューサ３０１のサードパーティ・アプリケーション２０２と画像リーダのレポートモジュールＵＩ
２４２との間のメッセージフローを示すシーケンス図である。
画像プロデューサ３０１のサードパーティ・アプリケーション２０２は、矢印６０２で示すように、スタディをサードパーティ通信モジュール２０４に送る。サードパーティ通信モジュール２０４は、矢印６０４で示すように、スタディ着信通知を作業分配エンジン１１４に送る。サードパーティ通信モジュール２０４は、矢印６０６で示すように、スタディ割当待ち通知を作業分配エンジンに送る。スタディ割当待ち通知は、そのスタディがどの画像リーダに割り当てられるべきか判断する作業分配エンジン１１４の解釈のための情報を含んでいる。この情報は、限定するものではないが、患者名、患者ＩＤ、検査日付、検査説明、診断する身体部位、画像プロデューサ名、画像プロデューサＩＤ、委託医師を含んでもよい。矢印６１０で、サードパーティ通信モジュール２０４からサードパーティ・アプリケーション２０２に、スタディ転送通知が送られる。スタディ転送通知は、特定の宛先ＤＩＣＯＭアプリケーション・エンティティ・タイトルにスタディを転送するように、画像プロデューサ・インタフェースに対して指示するものである。矢印６１２で、サードパーティ通信モジュール２０４は、過去の関連スタディについてのクエリをサードパーティ・アプリケーション２０２に送り、そしてサードパーティ・アプリケーション２０２に対して、結果のスタディを特定のＤＩＣＯＭアプリケーション・エンティティ・タイトルに送るように指示する。サードパーティ通信モジュール２０４は、矢印６１４で示すように、前例スタディ利用可能イベントを作業分配エンジン１１４に送る。このイベントは、そのスタディが作業アイテムであるか参照用であるかについての情報を伝える。作業アイテムは、画像リーダによる解釈レポートを必要とするスタディである。参照アイテムは、同じ患者の同様の身体部位についての、同一または関連するモダリティの他の画像スタディである。参照アイテムは、解釈される画像スタディで確認されるアイテムが現在のスタディよりも前に存在したかどうか、また、確認されるアイテムが参照スタディの取得から当該スタディまでの期間に変化したどうか判断するために、画像リーダによって使用される。参照アイテムは、一般的に、前例スタディまたは前例と呼ばれている。作業分配エンジン１１４は、必要に応じて、矢印６１６で示すようにスタディリストＵＩ
２４５に対して、または矢印６１６で示すようにサードパーティ・アプリケーション２０２に対して、スタディ優先度設定コマンドを送る。このコマンドで、スタディ優先度が設定されるように、作業分配エンジン１１４内でスタディ・プロファイリング・エンジン２１６により指示が送られる。これは、スタディ・ステータスが最初にスタディと一緒に送信されない場合に生じる。レポートモジュールＵＩ
２４２は、矢印６１８で示すように、画像リーダ・ログイン・イベントを作業分配エンジン１１４に送る。ログイン・イベントは、システムにログインした画像リーダのログイン情報を伝えるものであり、これによって、作業分配エンジン１１４は、その画像リーダが割り当てを受けることが可能であることを知ることができる。矢印６２０で示すように、スタディ割当コマンドが、作業分配エンジン１１４から、レポートがシステムの外部で行われる場合はサードパーティ・アプリケーション２０２に対して、またはレポートがシステムの内部で行われる場合はスタディリストＵＩ
２４５に対して、送られる。このコマンドは、そのスタディが、特定の画像リーダのスタディリスト２４５またはサードパーティ・アプリケーション２０２の同等の要素において利用可能でなければならないことを示している。スタディ取得イベントが、矢印６２４で示すように、レポートモジュールＵＩ
２４２から作業分配エンジン１１４に送られる。このイベントは、そのスタディが、読み取りと解釈のために画像リーダによって取り出されたことを示している。矢印６２６は、スタディ・スキップ・イベントを示している。このイベントは、スタディが閉じられたが、解釈されていないことを示している。作業分配エンジン１１４は、このスタディを再割り当て可能であるとみなすことになる。矢印６２８で示すように、保留イベントが、レポートモジュールＵＩ
２４２から作業分配エンジンに送られる。このイベントは、そのスタディが画像リーダによる最終的な解釈を得ていないが、しかし、このスタディを再割り当てすることもできないことを、作業分配エンジン１１４に知らせるものである。矢印６３０で示すように、スタディ読取イベントが、レポートモジュールＵＩ
２４２から作業分配エンジン１１４に送られる。これは、そのスタディの解釈が完了したことを、作業分配エンジン１１４に知らせるものである。矢印６３２は、作業分配エンジン１１４からサードパーティ通信２０４へのレポート送信を示している。レポートは、矢印６３４で示すように、さらに画像プロデューサ３０１のサードパーティ・アプリケーション２０２に送られる。矢印６３６で示すように、対処可能性通知が、レポートモジュールＵＩ
２４２から作業分配エンジン１１４に送られる。この通知は、その画像リーダが引き続き、更なるスタディの解釈に対処可能であることを作業分配エンジン１１４に知らせるものでる。矢印６３８は、レポートモジュールＵＩ
２４２から作業分配エンジン１１４に伝えられるログアウト・イベントを示している。画像リーダがシステムからログアウトしたという通知を作業分配エンジン１１４が受け取ると、作業分配エンジン１１４は、スタディの割り当てを解除し、その画像リーダに新たなスタディを割り当てることをやめて、それらのスタディを他のログインしている画像リーダに割り当て可能にする。
【００６０】
本明細書に記載の実施形態は、医療画像と医療画像解釈の分配及び管理に適用することができるが、これらの技術は、例えば、電気生理学、皮膚科学、心臓病学、または病理学など、他の医療診断管理システムに適用可能である。
【００６１】
以上、実施形態について説明を行ったが、添付の請求項により規定される趣旨及び範囲から逸脱することなく、変形及び変更の実施が可能である。
【特許請求の範囲】
【請求項１】
画像スタディを選択画像リーダに分配する方法であって、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するステップと、
そのサードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るステップと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るステップと、
抽出画像スタディ情報から画像スタディ・ルールを特定するステップと、
画像スタディ・ルールに基づいて、画像スタディに画像スタディ複雑度を適用するステップと、
画像プロデューサからの画像スタディを受け取ることに応募した複数の画像リーダについて、画像リーダ複雑度を計算するに当たり、それらの画像リーダ複雑度の各々を、画像スタディ複雑度と、複数の認可画像リーダの各々に割り当てられた画像リーダ・プロファイルとを用いて計算するステップと、
画像リーダ複雑度に基づいて、複数の画像リーダから選択画像リーダを選択するステップと、
画像スタディを選択画像リーダに割り当てるステップと、
ユーザインタフェース上で、選択画像リーダに対して画像スタディを表示するステップと、を有する
ことを特徴とする方法。
【請求項２】
選択するステップが、
画像リーダ複雑度に従って、複数の画像リーダを、最低複雑度から最高複雑度にソートするステップと、
ソートされた複数の画像リーダから、最低複雑度の画像リーダを、選択画像リーダとして選択するステップと、を有する
請求項１に記載の方法。
【請求項３】
計算するステップが、
画像リーダ・プロファイルからパラメータを抽出することであって、リーダのモダリティ、リーダの未処理作業量、リーダのセッション長さ、リーダのスケジュール情報、リーダの応募情報からなるグループから選択されるパラメータを抽出するステップと、
パラメータに複雑度値を割り当てるステップと、を有する
請求項１に記載の方法。
【請求項４】
画像スタディを対処可能な画像リーダに分配する方法であって、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するステップと、
サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るステップと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るステップと、
抽出画像スタディ情報から画像スタディ・ルールを特定するステップと、
少なくとも１つの画像スタディ・ルールが、画像スタディが緊急優先度を有することを示している場合に、画像スタディを、対処可能な画像リーダに割り当てるステップと、を有する
ことを特徴とする方法。
【請求項５】
割り当てるステップが、画像スタディがルーティングされたら、画像スタディを受信及び解釈することに対処可能である複数の画像リーダから、対処可能な画像リーダを特定するステップを有する
請求項４に記載の方法。
【請求項６】
画像スタディを予約画像リーダに分配する方法であって、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するステップと、
サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るステップと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るステップと、
抽出画像スタディ情報から画像スタディ・ルールを特定するステップと、
少なくとも１つの画像スタディ・ルールが、画像スタディが予約画像リーダに予約されたものであることを示している場合に、画像スタディを、予約画像リーダに割り当てるステップと、を有する
ことを特徴とする方法。
【請求項７】
画像プロデューサにより生成される画像スタディの画像リーダへの分配をスケジューリングする方法であって、
少なくとも１つの対処時間帯中に、画像スタディ作業への対処についての要求を、画像プロデューサから受け取るステップと、
複数の画像リーダから、それら複数の画像リーダが画像スタディ作業に対処することが可能な時間帯があることを示す画像リーダ対処可能通知を受け取るステップと、
少なくとも１つの対処時間帯を、対応する対処可能時間帯を持つ画像リーダと照合するステップと、
少なくとも１つの対処時間帯中に受け取る画像スタディを、対応する対処可能時間帯を持つ画像リーダに割り当てるステップと、を有する
ことを特徴とする方法。
【請求項８】
対処時間帯におけるすべての要求が満たされるか否かを判断するため、すべての対処時間帯とすべての対処可能時間帯の総括に基づいて重みを計算するステップを有する
請求項７に記載の方法。
【請求項９】
すべての対処時間帯が満たされるのではない場合には、システム管理者に通知される
請求項８に記載の方法。
【請求項１０】
画像分配システムであって、
関連付けられた画像リーダ・プロファイルをそれぞれ有する複数の画像リーダから選択される画像リーダによる解釈を得ることを目的とする画像スタディを、画像プロデューサから受信するため、受信通知メッセージを生成するサードパーティ通信モジュールと、
サードパーティ通信モジュールとやり取りするため、受信通知メッセージを受け取って、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを生成するメッセージング層と、
メッセージング層と通信可能に接続され、スタディ通知メッセージを受け取って、抽出画像スタディ情報から画像スタディ・ルールを特定し、スタディ・ルールに基づいてスタディ複雑度を画像スタディに適用し、複数の画像リーダについての画像リーダ複雑度を、スタディ複雑度及び関連する画像リーダ・プロファイルをそれぞれ用いて計算し、計算された画像リーダ複雑度に基づいて画像リーダを選択し、この選択画像リーダに画像スタディをルーティングする作業分配エンジンと、
スタディ・ルーティング・モジュールから送られる画像スタディを受け取って、画像スタディを選択画像リーダに表示するためのユーザインタフェースと、を備える
ことを特徴とするシステム。
【請求項１１】
ユーザインタフェースが、選択画像リーダによる画像スタディの解釈結果を入力するためのレポートモジュールを備える
請求項１０に記載のシステム。
【請求項１２】
少なくとも１つの画像スタディ・ルールが、画像スタディが緊急優先度を有することを示している場合に、作業分配エンジンが、画像スタディを、対処可能な画像スタディ・リーダに割り当てる
請求項１０に記載のシステム。
【請求項１３】
作業分配エンジンが、画像スタディがルーティングされたら、画像スタディを受信及び解釈することに対処可能である複数の画像リーダから、対処可能な画像リーダを特定する
請求項１０に記載のシステム。
【請求項１４】
少なくとも１つの画像スタディ・ルールが、画像スタディが予約画像リーダに予約されたものであることを示している場合に、作業分配エンジンが、画像スタディを、予約画像リーダに割り当てる
請求項１０に記載のシステム。
【請求項１５】
作業分配エンジンが、画像リーダ複雑度に従って、複数の画像リーダを、最低複雑度から最高複雑度にソートし、ソートされた複数の画像リーダから、最低複雑度の画像リーダを、選択画像リーダとして選択するためのスタディ分配モジュールを備える
請求項１０に記載のシステム。
【請求項１６】
作業分配エンジンが、リーダのモダリティ、リーダの未処理作業量、リーダのセッション長さ、リーダのスケジュール情報、リーダの応募情報からなるグループから選択されたパラメータを画像リーダ・プロファイルから抽出して、パラメータに複雑度値を割り当てる
請求項１０に記載のシステム。
【請求項１７】
対処時間帯中の画像プロデューサからのスタディ作業対処要求を、複数の画像リーダが画像スタディ作業に対処することが可能な時間帯があることを示すそれら複数の画像リーダからの画像リーダ対処可能通知と、照合するための需給モジュールと、
少なくとも１つの対処時間帯中に受け取る画像スタディを、対応する対処可能時間帯を持つ画像リーダに割り当てるスケジューリング・モジュールと、を備える
請求項１０ないし１６のいずれかに記載のシステム。
【請求項１８】
画像スタディを選択画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体であって、
そのコンピュータプログラムコードが、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するためのプログラムコードと、
サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、
抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、
画像スタディ・ルールに基づいて、画像スタディに画像スタディ複雑度を適用するためのプログラムコードと、
画像プロデューサからの画像スタディを受け取ることに応募した複数の画像リーダについて、画像リーダ複雑度を計算するため、それらの画像リーダ複雑度の各々を、画像スタディ複雑度及び複数の認可画像リーダの各々に割り当てられた画像リーダ・プロファイルを用いて計算するためのプログラムコードと、
画像リーダ複雑度に基づいて、複数の画像リーダから選択画像リーダを選択するためのプログラムコードと、
画像スタディを選択画像リーダに割り当てるためのプログラムコードと、
ユーザインタフェース上で、選択画像リーダに対して画像スタディを表示するためのプログラムコードと、を有する
ことを特徴とするコンピュータ読み取り可能な媒体。
【請求項１９】
画像スタディを対処可能なリーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体であって、
そのコンピュータプログラムコードが、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するためのプログラムコードと、
サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、
抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、
少なくとも１つの画像スタディ・ルールが、画像スタディが緊急優先度を有することを示している場合に、画像スタディを、対処可能な画像リーダに割り当てるためのプログラムコードと、を有する
ことを特徴とするコンピュータ読み取り可能な媒体。
【請求項２０】
画像スタディを予約画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体であって、
そのコンピュータプログラムコードが、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するためのプログラムコードと、
サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、
抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、
少なくとも１つの画像スタディ・ルールが、画像スタディが予約画像リーダに予約されたものであることを示している場合に、画像スタディを、予約画像リーダに割り当てるためのプログラムコードと、を有する
ことを特徴とするコンピュータ読み取り可能な媒体。
【請求項２１】
画像プロデューサにより生成される画像スタディを画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体であって、
そのコンピュータプログラムコードが、
少なくとも１つの対処時間帯中に、画像スタディ作業への対処についての要求を、画像プロデューサから受け取るためのプログラムコードと、
複数の画像リーダから、それら複数の画像リーダが画像スタディ作業に対処することが可能な時間帯があることを示す画像リーダ対処可能通知を受け取るためのプログラムコードと、
少なくとも１つの対処時間帯を、対応する対処可能時間帯を持つ画像リーダと照合するためのプログラムコードと、
少なくとも１つの対処時間帯中に受け取る画像スタディを、対応する対処可能時間帯を持つ画像リーダに割り当てるためのプログラムコードと、を有する
ことを特徴とするコンピュータ読み取り可能な媒体。
【請求項１】
画像スタディを選択画像リーダに分配する方法であって、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するステップと、
そのサードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るステップと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るステップと、
抽出画像スタディ情報から画像スタディ・ルールを特定するステップと、
画像スタディ・ルールに基づいて、画像スタディに画像スタディ複雑度を適用するステップと、
画像プロデューサからの画像スタディを受け取ることに応募した複数の画像リーダについて、画像リーダ複雑度を計算するに当たり、それらの画像リーダ複雑度の各々を、画像スタディ複雑度と、複数の認可画像リーダの各々に割り当てられた画像リーダ・プロファイルとを用いて計算するステップと、
画像リーダ複雑度に基づいて、複数の画像リーダから選択画像リーダを選択するステップと、
画像スタディを選択画像リーダに割り当てるステップと、
ユーザインタフェース上で、選択画像リーダに対して画像スタディを表示するステップと、を有する
ことを特徴とする方法。
【請求項２】
選択するステップが、
画像リーダ複雑度に従って、複数の画像リーダを、最低複雑度から最高複雑度にソートするステップと、
ソートされた複数の画像リーダから、最低複雑度の画像リーダを、選択画像リーダとして選択するステップと、を有する
請求項１に記載の方法。
【請求項３】
計算するステップが、
画像リーダ・プロファイルからパラメータを抽出することであって、リーダのモダリティ、リーダの未処理作業量、リーダのセッション長さ、リーダのスケジュール情報、リーダの応募情報からなるグループから選択されるパラメータを抽出するステップと、
パラメータに複雑度値を割り当てるステップと、を有する
請求項１に記載の方法。
【請求項４】
画像スタディを対処可能な画像リーダに分配する方法であって、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するステップと、
サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るステップと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るステップと、
抽出画像スタディ情報から画像スタディ・ルールを特定するステップと、
少なくとも１つの画像スタディ・ルールが、画像スタディが緊急優先度を有することを示している場合に、画像スタディを、対処可能な画像リーダに割り当てるステップと、を有する
ことを特徴とする方法。
【請求項５】
割り当てるステップが、画像スタディがルーティングされたら、画像スタディを受信及び解釈することに対処可能である複数の画像リーダから、対処可能な画像リーダを特定するステップを有する
請求項４に記載の方法。
【請求項６】
画像スタディを予約画像リーダに分配する方法であって、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するステップと、
サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るステップと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るステップと、
抽出画像スタディ情報から画像スタディ・ルールを特定するステップと、
少なくとも１つの画像スタディ・ルールが、画像スタディが予約画像リーダに予約されたものであることを示している場合に、画像スタディを、予約画像リーダに割り当てるステップと、を有する
ことを特徴とする方法。
【請求項７】
画像プロデューサにより生成される画像スタディの画像リーダへの分配をスケジューリングする方法であって、
少なくとも１つの対処時間帯中に、画像スタディ作業への対処についての要求を、画像プロデューサから受け取るステップと、
複数の画像リーダから、それら複数の画像リーダが画像スタディ作業に対処することが可能な時間帯があることを示す画像リーダ対処可能通知を受け取るステップと、
少なくとも１つの対処時間帯を、対応する対処可能時間帯を持つ画像リーダと照合するステップと、
少なくとも１つの対処時間帯中に受け取る画像スタディを、対応する対処可能時間帯を持つ画像リーダに割り当てるステップと、を有する
ことを特徴とする方法。
【請求項８】
対処時間帯におけるすべての要求が満たされるか否かを判断するため、すべての対処時間帯とすべての対処可能時間帯の総括に基づいて重みを計算するステップを有する
請求項７に記載の方法。
【請求項９】
すべての対処時間帯が満たされるのではない場合には、システム管理者に通知される
請求項８に記載の方法。
【請求項１０】
画像分配システムであって、
関連付けられた画像リーダ・プロファイルをそれぞれ有する複数の画像リーダから選択される画像リーダによる解釈を得ることを目的とする画像スタディを、画像プロデューサから受信するため、受信通知メッセージを生成するサードパーティ通信モジュールと、
サードパーティ通信モジュールとやり取りするため、受信通知メッセージを受け取って、画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを生成するメッセージング層と、
メッセージング層と通信可能に接続され、スタディ通知メッセージを受け取って、抽出画像スタディ情報から画像スタディ・ルールを特定し、スタディ・ルールに基づいてスタディ複雑度を画像スタディに適用し、複数の画像リーダについての画像リーダ複雑度を、スタディ複雑度及び関連する画像リーダ・プロファイルをそれぞれ用いて計算し、計算された画像リーダ複雑度に基づいて画像リーダを選択し、この選択画像リーダに画像スタディをルーティングする作業分配エンジンと、
スタディ・ルーティング・モジュールから送られる画像スタディを受け取って、画像スタディを選択画像リーダに表示するためのユーザインタフェースと、を備える
ことを特徴とするシステム。
【請求項１１】
ユーザインタフェースが、選択画像リーダによる画像スタディの解釈結果を入力するためのレポートモジュールを備える
請求項１０に記載のシステム。
【請求項１２】
少なくとも１つの画像スタディ・ルールが、画像スタディが緊急優先度を有することを示している場合に、作業分配エンジンが、画像スタディを、対処可能な画像スタディ・リーダに割り当てる
請求項１０に記載のシステム。
【請求項１３】
作業分配エンジンが、画像スタディがルーティングされたら、画像スタディを受信及び解釈することに対処可能である複数の画像リーダから、対処可能な画像リーダを特定する
請求項１０に記載のシステム。
【請求項１４】
少なくとも１つの画像スタディ・ルールが、画像スタディが予約画像リーダに予約されたものであることを示している場合に、作業分配エンジンが、画像スタディを、予約画像リーダに割り当てる
請求項１０に記載のシステム。
【請求項１５】
作業分配エンジンが、画像リーダ複雑度に従って、複数の画像リーダを、最低複雑度から最高複雑度にソートし、ソートされた複数の画像リーダから、最低複雑度の画像リーダを、選択画像リーダとして選択するためのスタディ分配モジュールを備える
請求項１０に記載のシステム。
【請求項１６】
作業分配エンジンが、リーダのモダリティ、リーダの未処理作業量、リーダのセッション長さ、リーダのスケジュール情報、リーダの応募情報からなるグループから選択されたパラメータを画像リーダ・プロファイルから抽出して、パラメータに複雑度値を割り当てる
請求項１０に記載のシステム。
【請求項１７】
対処時間帯中の画像プロデューサからのスタディ作業対処要求を、複数の画像リーダが画像スタディ作業に対処することが可能な時間帯があることを示すそれら複数の画像リーダからの画像リーダ対処可能通知と、照合するための需給モジュールと、
少なくとも１つの対処時間帯中に受け取る画像スタディを、対応する対処可能時間帯を持つ画像リーダに割り当てるスケジューリング・モジュールと、を備える
請求項１０ないし１６のいずれかに記載のシステム。
【請求項１８】
画像スタディを選択画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体であって、
そのコンピュータプログラムコードが、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するためのプログラムコードと、
サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、
抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、
画像スタディ・ルールに基づいて、画像スタディに画像スタディ複雑度を適用するためのプログラムコードと、
画像プロデューサからの画像スタディを受け取ることに応募した複数の画像リーダについて、画像リーダ複雑度を計算するため、それらの画像リーダ複雑度の各々を、画像スタディ複雑度及び複数の認可画像リーダの各々に割り当てられた画像リーダ・プロファイルを用いて計算するためのプログラムコードと、
画像リーダ複雑度に基づいて、複数の画像リーダから選択画像リーダを選択するためのプログラムコードと、
画像スタディを選択画像リーダに割り当てるためのプログラムコードと、
ユーザインタフェース上で、選択画像リーダに対して画像スタディを表示するためのプログラムコードと、を有する
ことを特徴とするコンピュータ読み取り可能な媒体。
【請求項１９】
画像スタディを対処可能なリーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体であって、
そのコンピュータプログラムコードが、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するためのプログラムコードと、
サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、
抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、
少なくとも１つの画像スタディ・ルールが、画像スタディが緊急優先度を有することを示している場合に、画像スタディを、対処可能な画像リーダに割り当てるためのプログラムコードと、を有する
ことを特徴とするコンピュータ読み取り可能な媒体。
【請求項２０】
画像スタディを予約画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体であって、
そのコンピュータプログラムコードが、
サードパーティ通信モジュールで、画像プロデューサから画像スタディを受信するためのプログラムコードと、
サードパーティ通信モジュールからメッセージング層に受信通知メッセージを送るためのプログラムコードと、
画像スタディのスタディ・ヘッダから取り出された抽出画像スタディ情報を含むスタディ割当待ち通知メッセージを、メッセージング層から作業分配エンジンに送るためのプログラムコードと、
抽出画像スタディ情報から画像スタディ・ルールを特定するためのプログラムコードと、
少なくとも１つの画像スタディ・ルールが、画像スタディが予約画像リーダに予約されたものであることを示している場合に、画像スタディを、予約画像リーダに割り当てるためのプログラムコードと、を有する
ことを特徴とするコンピュータ読み取り可能な媒体。
【請求項２１】
画像プロデューサにより生成される画像スタディを画像リーダに分配するためのコンピュータプログラムを具現化するコンピュータ読み取り可能な媒体であって、
そのコンピュータプログラムコードが、
少なくとも１つの対処時間帯中に、画像スタディ作業への対処についての要求を、画像プロデューサから受け取るためのプログラムコードと、
複数の画像リーダから、それら複数の画像リーダが画像スタディ作業に対処することが可能な時間帯があることを示す画像リーダ対処可能通知を受け取るためのプログラムコードと、
少なくとも１つの対処時間帯を、対応する対処可能時間帯を持つ画像リーダと照合するためのプログラムコードと、
少なくとも１つの対処時間帯中に受け取る画像スタディを、対応する対処可能時間帯を持つ画像リーダに割り当てるためのプログラムコードと、を有する
ことを特徴とするコンピュータ読み取り可能な媒体。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１３−５１２４８３（Ｐ２０１３−５１２４８３Ａ）
【公表日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願番号】特願２０１２−５４０２４２（Ｐ２０１２−５４０２４２）
【出願日】平成２２年１１月２５日（２０１０．１１．２５）
【国際出願番号】ＰＣＴ／ＣＡ２０１０／００１８９８
【国際公開番号】ＷＯ２０１１／０６３５３０
【国際公開日】平成２３年６月３日（２０１１．６．３）
【出願人】（５１２１３５８０５）リアルタイム ラジオロジー インコーポレイテッド (1)
【氏名又は名称原語表記】ＲＥＡＬＴＩＭＥ ＲＡＤＩＯＬＯＧＹ ＩＮＣ．
【住所又は居所原語表記】２２０ Ｓｕｐｅｒｉｏｒ Ｂｏｕｌｅｖａｒｄ，Ｍｉｓｓｉｓｓａｕｇａ，Ｏｎｔａｒｉｏ Ｌ５Ｔ ２Ｌ２ ＣＡＮＡＤＡ
【Ｆターム（参考）】
【公表日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願日】平成２２年１１月２５日（２０１０．１１．２５）
【国際出願番号】ＰＣＴ／ＣＡ２０１０／００１８９８
【国際公開番号】ＷＯ２０１１／０６３５３０
【国際公開日】平成２３年６月３日（２０１１．６．３）
【出願人】（５１２１３５８０５）リアルタイム ラジオロジー インコーポレイテッド (1)
【氏名又は名称原語表記】ＲＥＡＬＴＩＭＥ ＲＡＤＩＯＬＯＧＹ ＩＮＣ．
【住所又は居所原語表記】２２０ Ｓｕｐｅｒｉｏｒ Ｂｏｕｌｅｖａｒｄ，Ｍｉｓｓｉｓｓａｕｇａ，Ｏｎｔａｒｉｏ Ｌ５Ｔ ２Ｌ２ ＣＡＮＡＤＡ
【Ｆターム（参考）】
[ Back to top ]