(57)【要約】【課題】医用画像診断装置で取得した複数の二次元医用画像のシリーズ数に応じて、当該二次元医用画像から生成される三次元医用画像の読影依頼を適切に行なうことの可能な画面を表示することのできる仕組みを提供すること。【解決手段】医用画像診断装置で取得した複数の二次元医用画像から生成される三次元医用画像の読影依頼を行うことの可能な読影依頼システムであって、記憶手段に記憶された複数の二次元医用画像のシリーズ数を特定する。そして、記憶手段に記憶された複数の二次元医用画像から生成される三次元医用画像の読影依頼を受け付ける画面を表示するよう制御する。この画面では、特定されたシリーズ数が１である場合には、読影依頼に関する警告を行う。または、読影依頼を受け付けないように制御する。【選択図】図１３
2017120636.tif 000002
【特許請求の範囲】
【請求項１】
医用画像診断装置で取得した複数の二次元医用画像から生成される三次元医用画像の読影依頼を行うことの可能な読影依頼システムであって、
１または複数のシリーズで構成される複数の前記二次元医用画像を記憶する記憶手段と、
前記記憶手段に記憶された複数の前記二次元医用画像のシリーズ数を特定する第１の特定手段と、
前記記憶手段に記憶された複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を受け付ける画面を表示するよう制御する表示制御手段と
を備え、
前記表示制御手段は、前記第１の特定手段で特定されたシリーズ数が１である場合には、前記読影依頼に関する警告を行う前記画面を表示するよう制御することを特徴とする読影依頼システム。
【請求項２】
前記記憶手段は、前記二次元医用画像に含まれる被検体の体位の種類を示す体位情報を更に記憶し、
前記読影依頼システムは、
前記記憶手段に記憶された体位情報に基づいて、前記記憶手段に記憶された複数の前記二次元医用画像に含まれる前記体位の種類の数を特定する第２の特定手段
を更に備え、
前記表示制御手段は、更に、前記第２の特定手段で特定された前記体位の種類の数が１である場合には、前記読影依頼に関する警告を行う前記画面を表示するよう制御することを特徴とする請求項１に記載の読影依頼システム。
【請求項３】
前記体位情報は、前記医用画像診断装置で前記二次元医用画像に付与された付帯情報であることを特徴とする請求項２に記載の読影依頼システム。
【請求項４】
前記表示制御手段は、前記読影依頼の指示に応じて、前記読影依頼に関する警告を行う前記画面を表示するよう制御することを特徴とする請求項１乃至３のいずれか１項に記載の読影依頼システム。
【請求項５】
医用画像診断装置で取得した複数の二次元医用画像から生成される三次元医用画像の読影依頼を行うことの可能な読影依頼システムであって、
１または複数のシリーズで構成される複数の前記二次元医用画像を記憶する記憶手段と、
前記記憶手段に記憶された複数の前記二次元医用画像のシリーズ数を特定する第１の特定手段と、
前記記憶手段に記憶された複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を受け付ける画面を表示するよう制御する表示制御手段と
を備え、
前記表示制御手段は、前記第１の特定手段で特定されたシリーズ数が１である場合には、前記読影依頼を受け付けない前記画面を表示するよう制御することを特徴とする読影依頼システム。
【請求項６】
前記記憶手段は、前記二次元医用画像に含まれる被検体の体位の種類を示す体位情報を更に記憶し、
前記読影依頼システムは、
前記記憶手段に記憶された体位情報に基づいて、前記記憶手段に記憶された複数の前記二次元医用画像に含まれる前記体位の種類の数を特定する第２の特定手段
を更に備え、
前記表示制御手段は、更に、前記第２の特定手段で特定された前記体位の種類の数が１である場合には、前記読影依頼を受け付けない前記画面を表示するよう制御することを特徴とする請求項５に記載の読影依頼システム。
【請求項７】
前記体位情報は、前記医用画像診断装置で前記二次元医用画像に付与された付帯情報であることを特徴とする請求項６に記載の読影依頼システム。
【請求項８】
１または複数のシリーズで構成される、医用画像診断装置で取得した複数の二次元医用画像を記憶する記憶手段を備え、複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を行うことの可能な読影依頼システムの制御方法であって、
前記読影依頼システムの第１の特定手段が、前記記憶手段に記憶された複数の前記二次元医用画像のシリーズ数を特定する第１の特定ステップと、
前記読影依頼システムの表示制御手段が、前記記憶手段に記憶された複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を受け付ける画面を表示するよう制御する表示制御ステップと
を備え、
前記表示制御ステップは、前記第１の特定ステップで特定されたシリーズ数が１である場合には、前記読影依頼に関する警告を行う前記画面を表示するよう制御することを特徴とする読影依頼システムの制御方法。
【請求項９】
１または複数のシリーズで構成される、医用画像診断装置で取得した複数の二次元医用画像を記憶する記憶手段を備え、複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を行うことの可能な読影依頼システムの制御方法を実行可能なプログラムであって、
前記読影依頼システムを、
前記記憶手段に記憶された複数の前記二次元医用画像のシリーズ数を特定する第１の特定手段と、
前記記憶手段に記憶された複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を受け付ける画面を表示するよう制御する表示制御手段
として機能させ、
前記表示制御手段は、前記第１の特定手段で特定されたシリーズ数が１である場合には、前記読影依頼に関する警告を行う前記画面を表示するよう制御することを特徴とするプログラム。
【請求項１０】
１または複数のシリーズで構成される、医用画像診断装置で取得した複数の二次元医用画像を記憶する記憶手段を備え、複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を行うことの可能な読影依頼システムの制御方法であって、
前記読影依頼システムの第１の特定手段が、前記記憶手段に記憶された複数の前記二次元医用画像のシリーズ数を特定する第１の特定ステップと、
前記読影依頼システムの表示制御手段が、前記記憶手段に記憶された複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を受け付ける画面を表示するよう制御する表示制御ステップと
を備え、
前記表示制御ステップは、前記第１の特定ステップで特定されたシリーズ数が１である場合には、前記読影依頼を受け付けない前記画面を表示するよう制御することを特徴とする読影依頼システムの制御方法。
【請求項１１】
１または複数のシリーズで構成される、医用画像診断装置で取得した複数の二次元医用画像を記憶する記憶手段を備え、複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を行うことの可能な読影依頼システムの制御方法であって、
前記読影依頼システムを、
前記記憶手段に記憶された複数の前記二次元医用画像のシリーズ数を特定する第１の特定手段と、
前記記憶手段に記憶された複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を受け付ける画面を表示するよう制御する表示制御手段
として機能させ、
前記表示制御手段は、前記第１の特定手段で特定されたシリーズ数が１である場合には、前記読影依頼を受け付けない前記画面を表示するよう制御することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、読影依頼システム、その制御方法、及びプログラムに関する。
【背景技術】
【０００２】
従来、ＣＴ（Ｃｏｍｐｕｔｅｄ  Ｔｏｍｏｇｒａｐｈｙ）装置やＭＲＩ（Ｍａｇｎｅｔｉｃ  Ｒｅｓｏｎａｎｃｅ  Ｉｍａｇｉｎｇ）装置といった医用画像診断装置で患者の撮像を行い、撮像により得られた医用画像を読影し、診断を行っている。
【０００３】
ところが、こうした読影を行うことの可能な医師（以下、読影医という。）は限られているため、読影を行うことのできない病院が存在する。そこで、インターネット経由で読影医に対して医用画像の読影を依頼する仕組みが存在する。
【０００４】
特許文献１には、読影してもらいたい医用画像で読影医に着目して欲しい箇所を指定することで、これを当該医師に通知することの可能な仕組みが開示されている。これにより、読影医に対して正確に依頼内容を知らせることができ、読影の手戻りを抑止することが可能となる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−２７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
近年は、大腸をＣＴ装置で撮像することにより二次元医用画像を取得し、この二次元医用画像から生成される三次元医用画像を読影する、大腸ＣＴ検査（ＣＴコロノグラフィ、略称ＣＴＣ）が行われている。大腸ＣＴ検査は、従来の内視鏡による検査よりも患者の負担が軽いことが特徴である。
【０００７】
大腸ＣＴ検査の主な流れは、次の通りである。まず、患者の大腸に専用のガス等を注入して、読影しやすいように大腸を膨張させる。そして、患者の大腸を撮像して、二次元医用画像を取得する。ここで、複数の体位（仰臥位・伏臥位等）で患者を撮像することが望ましい。こうして得られた二次元医用画像から三次元医用画像を生成し、この三次元医用画像を読影医が読影する。
【０００８】
複数の体位で患者を撮像するのは、患者の大腸にある残渣等を移動させるためである。残渣等が二次元医用画像に写りこんでしまうと、読影の精度が低下してしまう。これを抑止するために、従来、患者を複数の体位で撮像し、複数シリーズの二次元医用画像を生成し、シリーズごとに三次元医用画像を生成している。つまり、こうして生成された複数の三次元医用画像を比較しながら読影すれば、残渣等によって誤った読影が行われることを抑止できる。
【０００９】
読影依頼を行う場合にも、こうした点を考慮する必要がある。すなわち、大腸ＣＴ検査を行うために、１シリーズしか存在しない二次元医用画像が読影依頼の対象として選択されたとしても、読影医が適切に読影することができない可能性がある。また、依頼側の病院においても、読影医からの要望があれば、再度患者の大腸を撮像しなければならないし、患者にとっても二度手間になってしまい、効率的でない。
【００１０】
本発明は、医用画像診断装置で取得した複数の二次元医用画像のシリーズ数に応じて、当該二次元医用画像から生成される三次元医用画像の読影依頼を適切に行なうことの可能な画面を表示することのできる仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記の目的を達成するために本発明の読影依頼システムは、医用画像診断装置で取得した複数の二次元医用画像から生成される三次元医用画像の読影依頼を行うことの可能な読影依頼システムであって、１または複数のシリーズで構成される複数の前記二次元医用画像を記憶する記憶手段と、前記記憶手段に記憶された複数の前記二次元医用画像のシリーズ数を特定する第１の特定手段と、前記記憶手段に記憶された複数の前記二次元医用画像から生成される三次元医用画像の読影依頼を受け付ける画面を表示するよう制御する表示制御手段とを備え、前記表示制御手段は、前記第１の特定手段で特定されたシリーズ数が１である場合には、前記読影依頼に関する警告を行う前記画面を表示するよう制御することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、医用画像診断装置で取得した複数の二次元医用画像のシリーズ数に応じて、当該二次元医用画像から生成される三次元医用画像の読影依頼を適切に行なうことの可能な画面を表示することができるようになる。
【図面の簡単な説明】
【００１３】
【図１】第１の実施形態における読影依頼システムのシステム構成を示す図である。
【図２】依頼端末、読影依頼サーバのハードウェア構成を示す図である。
【図３】依頼端末、読影依頼サーバの機能構成を示す図である。
【図４】申請待ち画面を表示するための一連の処理の流れを示すフローチャートである。
【図５】申請待ち画面の画面構成の一例を示す図である。
【図６】検査管理テーブル、シリーズ管理テーブルのテーブル構成を示す図である。
【図７】ＤＩＣＯＭ画像のデータ構成を示す図である。
【図８】ＤＩＣＯＭ画像を一覧表示する画面の画面構成を示す図である。
【図９】申請詳細画面１０００を表示するための一連の処理の流れを示すフローチャートである。
【図１０】申請詳細画面１０００の画面構成を示す図である。
【図１１】図９のステップＳ９０６で生成される申請詳細画面における一連の処理の流れを示すフローチャートである。
【図１２】図９のステップＳ９０７で生成される申請詳細画面における一連の処理の流れを示すフローチャートである。
【図１３】警告ダイアログの画面構成を示す図である。
【図１４】第２の実施形態における、図９のステップＳ９０７で生成される申請詳細画面における一連の処理の流れを示すフローチャートである。
【図１５】第２の実施形態における、警告メッセージの一例を示す図である。
【図１６】第３の実施形態における、申請詳細画面を表示するための一連の処理の流れを示すフローチャートである。
【図１７】第３の実施形態における、申請詳細画面の画面構成を示す図である。
【図１８】第４の実施形態における、申請詳細画面１９００を表示するための一連の処理の流れを示すフローチャートである。
【図１９】申請詳細画面１９００の画面構成を示す図である。
【図２０】第４の実施形態における、図１８のステップＳ１８０７で生成される申請詳細画面における一連の処理の流れを示すフローチャートである。
【図２１】第４の実施形態における、警告メッセージの一例を示す図である。
【図２２】第４の実施形態における、画像一覧画面２２００の一例を示す図である。
【図２３】不足画像の種類に応じて警告メッセージの一例を示す図である。
【発明を実施するための形態】
【００１４】
以下、図面を参照して、本発明の実施形態を詳細に説明する。まず、第１の実施形態について説明する。
【００１５】
図１は、本発明の読影依頼システムのシステム構成の一例を示す図である。読影依頼システムでは、依頼施設（病院）とデータセンターと読影センターとがインターネット１０３を介して通信可能に接続されている。依頼施設には、ＣＴ装置やＭＲＩ装置といった医用画像診断装置１０１と、医用画像診断装置１０１で生成されたＤＩＣＯＭ画像の読影依頼を行うための依頼端末１０２とがＬＡＮ等のネットワークを介して通信可能に接続されている。
【００１６】
データセンターには、依頼施設からの読影の依頼申請と、読影センターで読影された結果とを管理する遠隔読影サーバ１０４と、依頼施設から送信されたＤＩＣＯＭ画像を蓄積するストレージサーバ１０５とがネットワークを介して通信可能に接続されている。すなわち、データセンターは、依頼施設と読影センターとの仲介役である。また、読影センターには、読影医がＤＩＣＯＭ画像から多断面再構成像画像や仮想内視鏡画像（三次元医用画像）を生成し、読影を行うための読影端末１０６が備えられている。
【００１７】
図１のネットワーク上に接続される各種端末あるいはサーバの構成は一例であり、用途や目的に応じて様々な構成例があるため、これに限定されない。
【００１８】
読影の依頼申請から読影結果を返信する一連の流れについて説明する。まず、医用画像診断装置で患者（被検体）を撮像する。大腸ＣＴ検査であれば、医用画像診断装置としてＣＴ装置を用い、患者の断面を示すＤＩＣＯＭ画像を複数得る。１回のスキャン（撮像）で得られる複数のＤＩＣＯＭ画像を１シリーズとして管理するので、複数回撮像した場合には複数シリーズとして管理される。そして、撮像時の情報や患者の情報をＤＩＣＯＭ画像の付帯情報（ＤＩＣＯＭタグ）に格納し、依頼施設からデータセンターに送信する。データセンターはＤＩＣＯＭ画像を受信すると、遠隔読影サーバ１０４が受信したＤＩＣＯＭ画像に関する情報を検査ごとに管理し、更にＤＩＣＯＭ画像をストレージサーバ１０５に格納する。ここでいう検査とは、大腸ＣＴ検査等の１回分の検査を指し、１回の検査中であれば、複数シリーズ分撮像したとしてもその結果のＤＩＣＯＭ画像は、１つの検査に紐づく。
【００１９】
読影の依頼申請を行う場合には、依頼端末１０２から遠隔読影サーバ１０４にアクセスし、検査を選択した上で、当該検査に紐づくＤＩＣＯＭ画像の読影依頼を行う。このとき、遠隔読影サーバ１０４は、依頼申請を行うための画面を生成し、これを依頼端末１０２に提供する。依頼端末１０２はこの画面を表示して依頼施設のユーザから依頼内容の入力を受け付ける。
【００２０】
ここで、大腸ＣＴ検査の場合には、複数の体位で撮像された複数シリーズ分のＤＩＣＯＭ画像がなければ読影の精度が低下してしまう可能性がある。そのため、依頼申請する検査に紐づくＤＩＣＯＭ画像が複数シリーズから構成されるＤＩＣＯＭ画像でない、すなわち１シリーズ分しかないＤＩＣＯＭ画像である場合には、大腸ＣＴ検査の読影依頼に関する警告を出す。このようにすることで、読影医の読影精度を低下することを抑止できる。第１の実施形態・第２の実施形態についてはこの仕組みについて説明する。第３の実施形態については、こうした検査が選択された場合には、読影の依頼申請を受け付けない仕組みについて説明する。
【００２１】
このように申請された読影の依頼は、遠隔読影サーバ１０４で管理される。読影センターでは、依頼された読影を適切な読影医に対して振り分けて、読影医が読影端末１０６を操作し読影を行う。大腸ＣＴ検査であれば、選択された検査に紐づく１または複数シリーズの複数のＤＩＣＯＭ画像から１または複数の多断面再構成像画像や仮想内視鏡画像を生成する。これを読影して、読影結果をレポートにまとめ、遠隔読影サーバ１０４に登録する。そして、依頼施設はこの読影結果を遠隔読影サーバ１０４から取得して確認する。以上のような流れで読影が行われる。前述した通り、本実施形態では特に、読影の依頼申請を行う際の一連の処理について説明を行う。
【００２２】
図２は、依頼端末１０２と遠隔読影サーバ１０４のハードウェア構成の一例を示す図である。尚、図２に示すハードウェア構成はあくまで一例であり、用途や目的に応じて様々な構成例があるため、これに限定されない。
【００２３】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２４】
また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  ／  ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳという。）が記憶されている。また外部メモリ２１１には、各種装置が実行する機能を実現するために必要な各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。
【００２５】
ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。
【００２６】
また、入力コントローラ２０５は、キーボードやマウス等のポインティングデバイスといった入力デバイス２０９からの入力を制御する。
【００２７】
ビデオコントローラ２０６は、ディスプレイ２１０等の表示器への表示を制御する。表示器はＣＲＴや液晶ディスプレイでも構わない。
【００２８】
メモリコントローラ２０７は、ハードディスクやフレキシブルディスク或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の外部メモリ２１１へのアクセスを制御する。外部メモリ２１１（記憶手段）は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する。
【００２９】
通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。
【００３０】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３１】
本発明の各種装置が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルは外部メモリ２１１に格納されている。
【００３２】
図３は、依頼端末１０２と遠隔読影サーバ１０４の機能構成の一例を示す図である。尚、図３に示す機能構成はあくまで一例であり、用途や目的に応じて様々な構成例があるため、これに限定されない。
【００３３】
依頼端末１０２は機能部として、通信制御部３０１と、表示制御部３０２と、入力受付制御部３０３とを備える。通信制御部３０１は、遠隔読影サーバ１０４やその他各種装置と情報の送受信を行うための機能部である。表示制御部３０２は、通信制御部３０１で受信したＷｅｂページの画面をディスプレイ２１０に表示するための機能部である。画面のレンダリングについても表示制御部３０２が行う。入力受付制御部３０３は、表示制御部３０２で表示された画面に対する入力を受け付けるための機能部である。依頼端末１０２の入力デバイスを操作するユーザからの入力を受け付ける。そして、通信制御部３０１は、入力受付制御部３０３が入力を受け付けた内容を遠隔読影サーバ１０４に送信する。
【００３４】
遠隔読影サーバ１０４は機能部として、通信制御部３１１と、画面生成部３１２と、ＤＩＣＯＭ画像管理部３１３と、依頼申請管理部３１４とを備える。通信制御部３１１は、依頼端末１０２やその他各種装置と情報の送受信を行うための機能部である。画面生成部３１２は、依頼端末１０２で表示する画面を生成するための機能部である。画面生成部３１２が生成する画面はＷｅｂブラウザで表示可能なＷｅｂページである。画面生成部３１２は、静的なＷｅｂページに限らず、動的なＷｅｂページも生成することが可能である。動的なＷｅｂページとしては、ＪａｖａＳｃｒｉｐｔ（登録商標）等のスクリプト言語をＷｅｂページに埋め込むことにより、動的なＷｅｂページを生成する。
【００３５】
ＤＩＣＯＭ画像管理部３１３は、依頼端末１０２から送信されたＤＩＣＯＭ画像を管理するための機能部である。ＤＩＣＯＭ画像を依頼端末１０２から受信すると、ＤＩＣＯＭ画像に含まれる付帯情報から、患者に関する情報やＤＩＣＯＭ画像に関する情報、検査に関する情報等を取得し、これをデータベースに登録する。また、ＤＩＣＯＭ画像をストレージサーバ１０５に送信し、その保存先を同じくデータベースに登録する。
【００３６】
依頼申請管理部３１４は、依頼端末１０２から送信された読影の依頼申請を管理するための機能部である。依頼申請についてもその依頼申請の内容や依頼の対象となっている検査に関する情報をデータベースに登録する。
【００３７】
図４は、申請待ち画面を生成するための一連の処理の流れを示すフローチャートである。以下説明するＳ４０１、Ｓ４０５、Ｓ４０６の各ステップは、依頼端末１０２のＣＰＵ２０１が各機能部を動作することにより実行される処理である。また、Ｓ４０２乃至Ｓ４０４の各ステップは、遠隔読影サーバ１０４のＣＰＵ２０１が各機能部を動作することにより実行される処理である。
【００３８】
ステップＳ４０１では、依頼端末１０２の通信制御部３０１は、遠隔読影サーバ１０４に対して申請待ち画面の取得要求を送信する。ステップＳ４０２では、遠隔読影サーバ１０４の通信制御部３１１は、依頼端末１０２から送信された申請待ち画面の取得要求を受信し、ステップＳ４０３では、申請待ち画面を生成する。
【００３９】
図５に申請待ち画面５００の画面構成の一例を示す。申請待ち画面５００は、依頼施設から送信された検査に関する情報が一覧表示される画面である。この画面では、読影の依頼申請がなされていない申請待ちの検査だけが表示されている。申請待ちリスト５０１には、申請の状態を始め、患者に関する情報や検査に関する情報、またＤＩＣＯＭ画像に関する情報が一覧表示される。また、申請待ちリスト５０１は、依頼ボタン５０２を検査ごと（レコードごと）に備えており、依頼ボタン５０２に対する押下を受け付けることにより、依頼申請の内容を入力するための申請詳細画面を表示することができる。
【００４０】
申請待ち画面５００は、遠隔読影サーバ１０４が管理する検査管理テーブル６００とＤＩＣＯＭ画像に含まれる付帯情報から各種情報を取得して生成される。検査管理テーブル６００のテーブル構成の一例を図６に示す。
【００４１】
検査管理テーブル６００は、遠隔読影サーバ１０４の外部メモリ２１１に記憶されるデータテーブルである。検査管理テーブル６００は、検査ＩＤ６０１、患者情報６０２、シリーズ数６０３、画像枚数６０４、シリーズＩＤ６０５を備える。検査ＩＤ６０１は、検査を一意に識別するための情報である。患者情報６０２は、患者に関する情報（患者番号、患者名、年齢、性別等）である。シリーズ数６０３は、検査で撮像された回数を示す情報である。画像枚数６０４は、検査で得られたＤＩＣＯＭ画像の総枚数である。シリーズＩＤ６０５は、検査に対応するシリーズのＩＤである。シリーズＩＤ６０５については、複数のシリーズが検査に対応づいているのであれば、その対応づくシリーズの数だけシリーズＩＤ６０５の項目を有する。検査管理テーブル６００の各項目には、依頼施設から送信されたＤＩＣＯＭ画像の付帯情報に基づく情報が格納されている。
【００４２】
申請待ちリスト５０１は、更に画像ボタン５０３を検査ごとに備えており、検査に紐づくＤＩＣＯＭ画像の一覧を閲覧可能な画面を表示することができる。検査に紐づくＤＩＣＯＭ画像は、検査管理テーブル６００のシリーズＩＤ６０５をキーとして、図６に示すシリーズ管理テーブル６１０を検索し、ヒットしたレコードの保存パス６１３からＤＩＣＯＭ画像を取得してサムネイル画像を生成する。そして生成したサムネイル画像の一覧を画面に表示する。
【００４３】
シリーズ管理テーブル６１０は、遠隔読影サーバ１０４の外部メモリ２１１に記憶されたデータテーブルである。シリーズ管理テーブル６１０は、シリーズＩＤ６１１、画像ＩＤ６１２、保存パス６１３を備える。シリーズＩＤ６１１は、シリーズＩＤ６０５に対応する項目である。画像ＩＤ６１２は、画像を一意に識別するためのＩＤである。保存パス６１３は、ＤＩＣＯＭ画像の保存場所を示す。このシリーズ管理テーブル６１０は、依頼施設からＤＩＣＯＭ画像が送信されて来ると、遠隔読影サーバ１０４が送信されてきたＤＩＣＯＭ画像の付帯情報に基づいて生成する。
【００４４】
ここで、ＤＩＣＯＭ画像（二次元医用画像）のデータ構造について説明する。図７は、ＤＩＣＯＭ画像のデータ構造である。ＤＩＣＯＭ画像は、付帯情報７１０と画像データ７２０とを有している。付帯情報は、患者に関する情報や検査に関する情報、ＤＩＣＯＭ画像に関する情報など、タグとして付与されている情報である。本実施形態では特に、患者体位７１１（体位情報）とシリーズ数７１２を用いる。これらの情報は依頼施設の医用画像診断装置で付与される。
【００４５】
画像データ７２０は、医用画像診断装置で撮像された画像データである。本実施形態では便宜的に画像データと表記するが、その実態はＣＴ装置であればＣＴ値を示す情報である。そのため、ＤＩＣＯＭ画像を表示するビューワにおいて、ＣＴ値に応じた色を与えることで可視化される。
【００４６】
こうしたＤＩＣＯＭ画像が１回の撮像（スキャン）で複数取得できる。すなわち、１回の撮像動作で患者の体の断面を示す複数のＤＩＣＯＭ画像が生成される。この１回分の撮像動作で取得した複数のＤＩＣＯＭ画像を１シリーズとして管理する。例えば、大腸ＣＴ検査の場合、仰臥位で撮像して１シリーズ、伏臥位で撮像してもう１シリーズとなり、１回の検査で合計２シリーズのＤＩＣＯＭ画像が生成されることになる。
【００４７】
このＤＩＣＯＭ画像のサムネイル画像を一覧表示した画面が、図８である。図８は、画像ボタン５０３が押下された場合にディスプレイ２１０に表示される画面である。画像ボタン５０３によって選択された検査に対応するシリーズＩＤ６０５と、シリーズ管理テーブル６１０とを用いて、検査で得られたＤＩＣＯＭ画像を特定し、このサムネイル画像をシリーズごとに一覧表示する。サムネイル画像はあらかじめ生成しておくのが望ましい。生成するタイミングは特に問わない。こうした画面を表示して、読影の依頼申請を行う検査に間違いがないかどうかをユーザが確認する。
【００４８】
次に、依頼ボタン５０２が押下された場合の一連の処理について、図９に示すフローチャートを用いて説明する。以下説明するＳ９０１、Ｓ９０２、Ｓ９０９、Ｓ９１０の各ステップは、依頼端末１０２のＣＰＵ２０１が各機能部を動作することにより実行される処理である。また、Ｓ９０３乃至Ｓ９０８の各ステップは、遠隔読影サーバ１０４のＣＰＵ２０１が各機能部を動作することにより実行される処理である。
【００４９】
ステップＳ９０１では、依頼端末１０２の入力受付制御部３０３は、依頼ボタン５０２が押下されたか否かを判定する。依頼ボタン５０２が押下されたと判定した場合には、ステップＳ９０２に処理を進める。そうでない場合には、そのまま待機する。
【００５０】
ステップＳ９０２では、依頼端末１０２の通信制御部３０１は、依頼ボタン５０２が押下された検査の読影依頼を行うために、当該検査に関する申請詳細画面の取得要求を遠隔読影サーバ１０４に対して送信する。
【００５１】
ステップＳ９０３では、遠隔読影サーバ１０４の通信制御部３１１は、依頼端末１０２から送信された申請詳細画面の取得要求を受信する。ステップＳ９０４では、遠隔読影サーバ１０４のＤＩＣＯＭ画像管理部３１３は、依頼ボタン５０２が押下された検査が複数シリーズから構成される複数のＤＩＣＯＭ画像と対応づいているか否かを判定する。より具体的には、依頼ボタン５０２によって選択された検査のシリーズ数を当該検査のシリーズ数６０３から特定すればよい（第１の特定手段）。シリーズ数６０３は、当該検査で得られたＤＩＣＯＭ画像の付帯情報（シリーズ数７１２）から取得された情報であるので、ＤＩＣＯＭ画像のシリーズ数７１２を直接参照して、シリーズ数を特定してもよい。ステップＳ９０４では、こうして特定したシリーズ数が複数であるか否かを判定する。シリーズ数が複数であると判定した場合には、ステップＳ９０６に処理を進める。シリーズ数が複数でない、つまりシリーズ数が１であると判定した場合には、ステップＳ９０７に処理を進める。
【００５２】
ステップＳ９０５では、遠隔読影サーバ１０４のＤＩＣＯＭ画像管理部３１３は、ステップＳ９０４で特定した複数シリーズから構成される複数のＤＩＣＯＭ画像が、複数種類の体位で撮像されたものか否かを判定する。より具体的には、依頼ボタン５０２が押下された検査に対応するシリーズごとに、どのような体位で撮像されたのかを特定する（第２の特定手段）。撮像された際の患者の体位は、付帯情報（患者体位７１１）に含まれている。患者体位７１１は、ＤＩＣＯＭタグでいうところの“Ｐａｔｉｅｎｔ  Ｐｏｓｉｔｉｏｎ”である。患者体位としては、仰臥位、伏臥位、側臥位といった体位が存在する。この患者体位７１１が示す情報をシリーズごとに特定し、特定した情報同士を比較する。比較した結果、１つでも異なる患者体位が存在するのであれば、複数種類の体位で撮像されたものであると判定する。例えば、仰臥位で撮像されたシリーズと伏臥位で撮像されたシリーズの場合には、複数種類の体位で撮像されたものであると判定する。比較した結果、患者体位がすべて同一であれば、複数種類の体位で撮像されたものではない、つまり１種類の体位で撮像されたものであると判定する。例えば、すべて仰臥位で撮像されたシリーズである場合には、複数種類の体位で撮像されたものではないと判定する。複数種類の体位で撮像されたものであると判定した場合には、ステップＳ９０６に処理を進める。複数種類の体位で撮像されたものではないと判定した場合には、ステップＳ９０７に処理を進める。
【００５３】
ステップＳ９０６では、遠隔読影サーバ１０４の画面生成部３１２は、依頼ボタン５０２が押下された検査に関して、大腸ＣＴ検査の読影を依頼申請することの可能な申請詳細画面を生成する（表示制御手段）。図１０は申請詳細画面１０００の画面構成の一例を示す図である。申請詳細画面１０００は、読影の依頼申請に際して、その依頼内容を入力するための画面である。この画面には、依頼ボタン５０２が押下された検査に関する情報や、患者に関する情報、ＤＩＣＯＭ画像に関する情報も表示される。申請詳細画面１０００においても、画像ボタン５０３と同様のボタンを設け、検査に紐づくＤＩＣＯＭ画像を確認できるようにしてもよい。
【００５４】
一方、ステップＳ９０７では、遠隔読影サーバ１０４の画面生成部３１２は、依頼ボタン５０２が押下された検査に関して、大腸ＣＴ検査の読影を依頼申請することの可能な、ステップＳ９０６で生成される画面とは異なる動作を実行する申請詳細画面を生成する。依頼ボタン５０２が押下された検査に対応するシリーズが１つであるか、複数シリーズあるけれども複数種類の体位で撮像されていない検査である。つまり、大腸ＣＴ検査の読影を行う場合に、残渣等によって読影の精度が低下してしまう可能性がある。そのため、大腸ＣＴ検査の読影を依頼申請しようとした場合に、依頼施設のユーザに対して警告を行う申請詳細画面をステップＳ９０７で生成する（表示制御手段）。
【００５５】
ステップＳ９０８では、遠隔読影サーバ１０４の通信制御部３１１は、ステップＳ９０６またはステップＳ９０７で生成された申請詳細画面１０００を依頼端末１０２に対して送信する。
【００５６】
ステップＳ９０９では、依頼端末１０２の通信制御部３０１は、遠隔読影サーバ１０４から送信された申請詳細画面１０００を受信する。そして、ステップＳ９１０では、依頼端末１０２の表示制御部３０２は、受信した申請詳細画面１０００をディスプレイ２１０に表示する（表示制御手段）。
【００５７】
次に、ステップＳ９０６で生成された申請詳細画面１０００で依頼申請を受け付ける一連の処理の流れについて、図１１に示すフローチャートを用いて説明する。以下説明する、Ｓ１１０１、Ｓ１１０２の各ステップは、依頼端末１０２のＣＰＵ２０１が各機能部を動作することにより実行される処理である。また、Ｓ１１０３、Ｓ１１０４の各ステップは、遠隔読影サーバ１０４のＣＰＵ２０１が各機能部を動作することにより実行される処理である。
【００５８】
ステップＳ１１０１では、依頼端末１０２の入力受付制御部３０３は、ステップＳ９０６で生成された申請詳細画面１０００の各入力欄に対して必要事項の入力を受け付けた上で、依頼申請ボタン１００２が押下されたか否かを判定する。図１０に示すように、申請詳細画面１０００には、部位のチェックボックス１００１を備えており、大腸ＣＴ検査の読影を依頼する場合には、“ＣＴＣ”にチェックを入れた上で、依頼申請ボタン１００２を押下する。依頼申請ボタン１００２が押下されたと判定した場合には、ステップＳ１１０２に処理を進める。そうでない場合には、そのまま待機する。
【００５９】
ステップＳ１１０２では、依頼端末１０２の通信制御部３０１は、ステップＳ９０６で生成された申請詳細画面１０００で入力を受け付けた各種情報を含む依頼申請情報を、遠隔読影サーバ１０４に送信する。
【００６０】
ステップＳ１１０３では、遠隔読影サーバ１０４の通信制御部３１１は、依頼端末１０２から送信された依頼申請情報を受信する。そして、ステップＳ１１０４では、遠隔読影サーバ１０４の依頼申請管理部３１４は、受信した依頼申請情報を遠隔読影サーバ１０４が備えるデータベースに登録し、読影依頼を読影医に振り分けられるように管理する。このように、ステップＳ９０６で生成された申請詳細画面１０００では、従来通り、大腸ＣＴ検査の依頼申請を行うことができる。
【００６１】
次に、ステップＳ９０７で生成された申請詳細画面１０００で依頼申請を受け付ける一連の処理の流れについて、図１２に示すフローチャートを用いて説明する。以下説明する、Ｓ１２０１乃至Ｓ１２０５の各ステップは、依頼端末１０２のＣＰＵ２０１が各機能部を動作することにより実行される処理である。また、Ｓ１２０６、Ｓ１２０７の各ステップは、遠隔読影サーバ１０４のＣＰＵ２０１が各機能部を動作することにより実行される処理である。
【００６２】
ステップＳ１２０１では、依頼端末１０２の入力受付制御部３０３は、ステップＳ９０７で生成された申請詳細画面１０００の各入力欄に対して必要事項の入力を受け付けた上で、依頼申請ボタン１００２が押下されたか否かを判定する。チェックボックス１００１の動作については、ステップＳ１１０１と同様である。依頼申請ボタン１００２が押下されたと判定した場合には、ステップＳ１２０２に処理を進める。そうでない場合には、そのまま待機する。
【００６３】
ステップＳ１２０２では、依頼端末１０２の入力受付制御部３０３は、ステップＳ９０７で生成された申請詳細画面１０００のチェックボックス１００１のうち、大腸ＣＴ検査を示す“ＣＴＣ”にチェックされているか否かを判定する。“ＣＴＣ”にチェックされていると判定した場合には、ステップＳ１２０３に処理を進める。“ＣＴＣ”にチェックされていないと判定した場合には、ステップＳ１２０４に処理を進める。
【００６４】
ステップＳ１２０３では、依頼端末１０２の表示制御部３０２は、選択された検査のＤＩＣＯＭ画像だけでは、読影の精度が低下する可能性がある旨をユーザに警告する。この警告の一例を図１３に示す。図１３に示すようにダイアログを表示して警告してもよいし、音声を再生することで警告してもよい。また、警告する内容は図１３に示す内容に限らない。大腸ＣＴ検査に関して手戻りが発生する可能性を通知してもよいし、正確な読影ができなくとも読影依頼に対する料金が変わらない旨を通知してもよい。
【００６５】
ステップＳ１２０４では、依頼端末１０２の入力受付制御部３０３は、ステップＳ１２０３で行われた警告と共に表示されたＹＥＳボタン１３０１またはＮＯボタンのいずれが押下されたのかを判定する。大腸ＣＴ検査の読影精度が低下する可能性があったとしても、読影の依頼申請を行いたい場合には、ユーザはＹＥＳボタン１３０１を押下する。そうでない場合には、ＮＯボタン１３０２を押下して申請を取り止める。ＹＥＳボタン１３０１が押下されたと判定した場合には、ステップＳ１２０５に処理を進める。ＮＯボタン１３０２が押下されたと判定した場合には、警告を終了し、申請詳細画面１０００に対する入力を再度受け付けるようにする。
【００６６】
ステップＳ１２０５では、依頼端末１０２の通信制御部３０１は、ステップＳ９０７で生成された申請詳細画面１０００で入力を受け付けた各種情報を含む依頼申請情報を、遠隔読影サーバ１０４に送信する。
【００６７】
ステップＳ１２０６では、遠隔読影サーバ１０４の通信制御部３１１は、依頼端末１０２から送信された依頼申請情報を受信する。そして、ステップＳ１２０７では、遠隔読影サーバ１０４の依頼申請管理部３１４は、受信した依頼申請情報を遠隔読影サーバ１０４が備えるデータベースに登録し、読影依頼を読影医に振り分けられるように管理する。このように、ステップＳ９０７で生成された申請詳細画面１０００では、大腸ＣＴ検査の読影の精度が低下してしまう可能性がある旨をユーザに通知することで、読影精度の低下と大腸ＣＴ検査の手戻りとを抑止することができる。
【００６８】
以上、第１の実施形態で説明した通り、この仕組みを用いることにより大腸ＣＴ検査に関する読影を適切に行うことが可能となる。
【００６９】
次に、第２の実施形態について説明する。第２の実施形態は、図１２の変形例である。そのため、第２の実施形態で説明する点以外については、第１の実施形態と同様であるので、説明は省略する。
【００７０】
第１の実施形態では、依頼申請ボタン１００２が押下された後に、ユーザに対して警告を行った。第２の実施形態は、チェックボックス１００１のうち、“ＣＴＣ”にチェックがされた際に、ユーザに対して警告を行う仕組みである。この仕組みについて、図１４及び図１５を用いて説明する。
【００７１】
図１４は、ステップＳ９０７で生成された申請詳細画面１０００で依頼申請を受け付ける一連の処理の流れを示すフローチャートである。以下説明する、Ｓ１４０１乃至Ｓ１４０４の各ステップは、依頼端末１０２のＣＰＵ２０１が各機能部を動作することにより実行される処理である。また、Ｓ１４０５、Ｓ１４０６の各ステップは、遠隔読影サーバ１０４のＣＰＵ２０１が各機能部を動作することにより実行される処理である。
【００７２】
ステップＳ１４０１では、依頼端末１０２の入力受付制御部３０３は、ステップＳ９０７で生成された申請詳細画面１０００が備えるチェックボックス１００１のうち、“ＣＴＣ”のチェックがＯＮに切り替えられたか否かを判定する。“ＣＴＣ”のチェックがＯＮに切り替えられたと判定した場合には、ステップＳ１４０２に処理を進める。そうでない場合には、ステップＳ１４０３に処理を進める。
【００７３】
ステップＳ１４０２では、依頼端末１０２の表示制御部３０２は、選択された検査のＤＩＣＯＭ画像だけでは、読影の精度が低下する可能性がある旨をユーザに警告する。この警告の一例を図１５に示す。“ＣＴＣ”のチェックボックスの近傍に吹き出し１５０１を表示し、この吹き出し内にユーザに対する警告を表示する。このような警告を行う申請詳細画面１０００をステップＳ９０７で生成することで、依頼申請を行う前にユーザに対して警告を行うことが可能となる。
【００７４】
ステップＳ１４０３では、依頼端末１０２の入力受付制御部３０３は、ステップＳ９０７で生成された申請詳細画面１０００の各入力欄に対して必要事項の入力を受け付けた上で、依頼申請ボタン１００２が押下されたか否かを判定する。依頼申請ボタン１００２が押下されたと判定した場合には、ステップＳ１４０４に処理を進める。そうでない場合には、ステップＳ１４０１に処理を戻す。
【００７５】
ステップＳ１４０４では、依頼端末１０２の通信制御部３０１は、ステップＳ９０７で生成された申請詳細画面１０００で入力を受け付けた各種情報を含む依頼申請情報を、遠隔読影サーバ１０４に送信する。
【００７６】
ステップＳ１４０５では、遠隔読影サーバ１０４の通信制御部３１１は、依頼端末１０２から送信された依頼申請情報を受信する。そして、ステップＳ１４０６では、遠隔読影サーバ１０４の依頼申請管理部３１４は、受信した依頼申請情報を遠隔読影サーバ１０４が備えるデータベースに登録し、読影依頼を読影医に振り分けられるように管理する。
【００７７】
以上、第２の実施形態で説明した通り、依頼申請ボタン１００２の押下を受け付ける前に、“ＣＴＣ”のチェックボックス１００１がＯＮになったタイミングでユーザに警告を行うことが可能となる。
【００７８】
次に第３の実施形態について説明する。第３の実施形態は、図９の変形例である。そのため、第３の実施形態で説明する点以外については、第１の実施形態と同様であるので、説明は省略する。
【００７９】
第１の実施形態と第２の実施形態では、ユーザに対して警告を行った。第３の実施形態は、依頼ボタン５０２が押下された検査に対応するシリーズが１つであるか、複数シリーズあるけれども複数種類の体位で撮像されていない検査に関しては、大腸ＣＴ検査の読影依頼を受け付けないように制御する仕組みである。この仕組みについて、図１６及び図１７を用いて説明する。
【００８０】
図１６は、依頼ボタン５０２が押下された場合の一連の処理を示すフローチャートである。Ｓ９０１、Ｓ９０２、Ｓ９０９、Ｓ９１０の各ステップは、依頼端末１０２のＣＰＵ２０１が各機能部を動作することにより実行される処理である。また、Ｓ９０３乃至Ｓ９０８、Ｓ１６０１の各ステップは、遠隔読影サーバ１０４のＣＰＵ２０１が各機能部を動作することにより実行される処理である。
【００８１】
更に、ステップＳ９０１乃至ステップＳ９１０の各ステップは、図９と同様であるのでこれらの説明は省略する。
【００８２】
ステップＳ１６０１では、遠隔読影サーバ１０４の画面生成部３１２は、依頼ボタン５０２が押下された検査に関して、大腸ＣＴ検査の読影を依頼申請できないように制御する（依頼申請を受け付けない）申請詳細画面１０００を生成する。図１７（ａ）と図１７（ｂ）はステップＳ１６０１で生成される申請詳細画面１０００の一例である。まず、図１７（ａ）は、１７０１に示すように、“ＣＴＣ”のチェックボックスがチェックできないようにグレーアウトさせた画面である。このように、ステップＳ９０４及びステップＳ９０５の条件を満たさない検査については、大腸ＣＴ検査の読影依頼を受け付けない。図１７（ｂ）は、“ＣＴＣ”のチェックボックスにはチェックが可能だが、チェックされると１７０２に示すように依頼申請ボタンがグレーアウトし、依頼申請ボタンに対する押下を受け付けなくさせる。このようにして、大腸ＣＴ検査の読影依頼を受け付けないようにしてもよい。また、更に別の形態としては、“ＣＴＣ”のチェックボックスにはチェックが可能で、依頼申請ボタンも押下可能だが、依頼申請ボタンを押下した後にエラー通知を出して、依頼申請を受け付けないようにしてもよい。また、遠隔読影サーバ１０４に依頼申請が送信されるが、遠隔読影サーバ１０４が依頼申請を受け付けないように制御してもよい。
【００８３】
以上、第３の実施形態で説明した通り、“ＣＴＣ”のチェックボックスまたは依頼申請ボタンの押下を受け付けないように制御することが可能となる。
【００８４】
次に、第４の実施形態について説明する。第１から第３までの実施形態は、医用画像診断装置で取得した複数のシリーズ数に応じて、当該二次元医用画像から生成される三次元医用画像の読影依頼を適切に行なうことの可能な画面を表示する仕組みについて説明した。第４の実施形態は、医用画像診断装置で取得した医用画像であって、三次元医用画像を生成しない場合の二次元医用画像を用いた読影依頼を適切に行う仕組みについて説明する。
【００８５】
第１から第３までの実施形態は、主に大腸ＣＴ検査を前提に説明したため、三次元医用画像を生成することが前提であった。第４の実施形態では、三次元医用画像を生成しない、二次元医用画像の読影を行う場合に、複数の医用画像もしくは異なる方面から撮像された医用画像が必要な場合について説明する。例えば、健康診断（以下、健診）で撮像された医用画像を読影する場合がこれに該当する。健診の読影依頼時には、例えば、撮像された胸部レントゲン（胸部Ｘ線）の読影を依頼する場合に、正面と側面等複数の方面からレントゲンで撮像された二次元画像を用いて読影を行う。これは、肺付近にある臓器もしくは骨が重なり合うことで死角が出来てしまい、正面からの画像のみでは異常部の判断が難しいためである。例えば、側面から撮像した二次元医用画像と共に読影することで正面の二次元医用画像の読影を補完し、異常部の検出精度をあげることが可能となる。こうした場合の依頼申請を行う一連の処理について以下説明行う。以下説明する、図１８のＳ１８０１、Ｓ１８０２、Ｓ１８０９、Ｓ１８１０の各ステップは、依頼端末１０２のＣＰＵ２０１が各機能部を動作することにより実行される処理である。また、Ｓ１８０３乃至Ｓ１８０８の各ステップは、遠隔読影サーバ１０４のＣＰＵ２０１が各機能部を動作することにより実行される処理である。尚、ステップＳ１８０１からステップＳ１８０３の処理は図９のステップＳ９０３の処理と同様であるため説明を省略する。
【００８６】
図１８のステップＳ１８０４では、遠隔読影サーバ１０４のＤＩＣＯＭ画像管理部３１３は、依頼ボタン５０２が押下された検査が、複数のＤＩＣＯＭ画像と対応づいているか否かを判定する。より具体的には、依頼ボタン５０２によって選択された検査の画像枚数を、画像枚数６０４から特定するとよい。特定した画像枚数が複数であると判定した場合はステップＳ１８０５に処理を進める。画像枚数が複数でない、つまり画像枚数が１であると判定した場合はステップＳ１８０７に処理を進める。
【００８７】
ステップＳ１８０５では、遠隔読影サーバ１０４のＤＩＣＯＭ画像管理部３１３は、ステップＳ１８０４で特定した複数のＤＩＣＯＭ画像が、複数種類の方面（体位）から撮像されたものか否かを判定する。撮像の方面としては、正面、側面等が含まれる。この撮像方面を画像ごとに特定し、特定した情報を比較する。比較した結果１つでも異なる撮像方面が存在するのであれば、複数種類の方面から撮像されたものであると判定する。比較した結果、患者体位がすべて同一であれば、複数種類の方面から撮像されたものではないと判定する。複数種類の方面から撮像されたものであると判定した場合はステップＳ１８０６へ処理を進める。複数種類の方面から撮像されたものでないと判定した場合は、ステップＳ１８０７処理を進める。
【００８８】
ステップＳ１８０６では、遠隔読影サーバ１０４の画面生成部３１２は、依頼ボタン５０２が押下された検査に関して、健診に関する読影を依頼することの可能な申請詳細画面を生成する。
【００８９】
図１９は申請詳細画面１９００の一例を示す図である。この画面には、依頼ボタン５０２が押下された検査に関する情報や、患者に関する情報の他に健診会場の情報等も表示される。
【００９０】
一方ステップＳ１８０７では、遠隔読影サーバ１０４の画面生成部３１２は、依頼ボタン５０２が押下された検査に関して、健診に関する読影を依頼することの可能な、ステップＳ１８０６で生成される画面とは異なる動作を実行する申請詳細画面を生成する。この画面は依頼ボタン５０２が押下された検査に対応する画像枚数が１枚であるか、複数枚あるけれども複数種類の方面で撮像されていない検査である場合に表示される。つまり、臓器や骨の重なりからなる死角付近の読影が難しい場合の胸部等の検査の場合である。そのため、異なる方面から撮像した二次元医用画像がない場合には、ユーザに対して警告しつつも追加登録できるような申請詳細画面をステップＳ１８０７で生成する。
【００９１】
ステップＳ１８０８からステップＳ１８０９は、図９のステップＳ９０８からステップＳ９１０と同様の処理であるため説明を省略する。
【００９２】
次に、ステップＳ１８０６で生成された申請詳細画面１９００で依頼申請を受け付ける一連の処理の流れについて、図２０に示すフローチャートを用いて説明する。以下説明する、Ｓ２００１乃至Ｓ２００６の各ステップは、依頼端末１０２のＣＰＵ２０１が各機能部を動作することにより実行される処理である。また、Ｓ２００７、Ｓ２００８の各ステップは、遠隔読影サーバ１０４のＣＰＵ２０１が各機能部を動作することにより実行される処理である。
【００９３】
ステップＳ２００１では、依頼端末１０２の入力受付制御部３０３は、ステップＳ１８０６で生成された申請詳細画面１９００の各入力欄に対して必要事項の入力を受け付けた上で、依頼申請ボタン１９０２が押下されたか否かを判定する。図１９に示すように、申請詳細画面１９００には、部位のチェックボックス１９０１を備えており、健診の読影を依頼する場合には、該当する部位にチェックを入れた上で、依頼申請ボタン１９０２を押下する。依頼申請ボタン１９０２が押下されたと判定した場合には、ステップＳ２００２に処理を進める。そうでない場合には、そのまま待機する。
【００９４】
ステップＳ２００２では、依頼端末１０２の入力受付制御部３０３は、申請詳細画面１９００のチェックボックス１９０１のうち、胸部のレントゲン検査を示す“胸部”にチェックされているか否かを判定する。“胸部”にチェックされていると判定された場合にはステップＳ２００３に処理を進める。それ以外の場合にはステップＳ２００５に処理を進める。
【００９５】
ステップＳ２００３では、依頼端末１０２の表示制御部３０２は、選択された検査のＤＩＣＯＭ画像だけでは、読影の制度が落ちる、もしくは読影を受け付けない旨をユーザに警告し、追加で画像の登録を行うことが可能な画面を表示させる。その画面の例を図２１に示す。図２１に示すようにダイアログ表示して警告してもよいし、音声を再生するなどして警告してもよい。また、図２１のように不足している画像を登録するか否かの選択を受け付けてもよい。ＹＥＳボタン２１０１の押下を受け付けた、つまり画像の追加登録を受け付けたと判定した場合はステップＳ２００４に処理を進める。図２１のＮＯボタン２１０２の押下を受け付けた、つまり画像の追加登録を受け付けなかったと判定した場合はステップＳ２００５に処理を進める。ここで画像の追加登録を受け付けず、読影の精度が落ちるような場合には、読影の割り振りを読影医一人に割り振るシングル読影ではなく、二人の読影医に割り振るダブル読影に切り替えてもよい。
【００９６】
ステップＳ２００４では、依頼端末１０２の入力受付制御部３０３は、ステップＳ２００３で画像の追加登録を受け付けた場合に、画像候補一覧から画像の選択を受け付ける。
【００９７】
図２２は、画像一覧画面２２００の一例を示す図である。画像一覧画面２２００では、画像の情報、患者情報、検査日時等の情報が表示され、それぞれの検索条件を用いて画像の検索を実行可能である。画像一覧画面２２００で画像の選択を受け付け、依頼追加ボタン２２０１の押下を検知すると、選択を受け付けた画像が依頼情報に追加で登録される。これにより、読影において不足していた、異なる方面から撮像した画像を追加で登録可能となる。
【００９８】
ステップＳ２００５では、依頼端末１０２の入力受付制御部３０３は、依頼申請ボタン１９０２が押下されたか否かを判定する。より具体的には、ステップＳ２００４で画像を追加するか否かの選択を受け付けて画像を追加した後、もしくは画像を追加せずそのまま依頼を行う場合に、再度依頼申請ボタン１９０２が押下されたか否かを判定する。依頼申請ボタン１９０２が押下されたと判定した場合はステップＳ２００６に処理を進める。依頼申請ボタン１９０２が押下されたと判定しなかった場合は申請を取り止めて一連の処理を終了する。
【００９９】
ステップＳ２００６からステップＳ２００８の処理はステップＳ１２０５からステップＳ１２０７の処理と同様であるため説明を終了する。これらの処理により、同一検査に対応する複数の二次元医用画像を用いた健診に関する読影を依頼する場合に対しても、画像の添付し忘れや読影の精度の低下、健診の検査の手戻り等を抑止することが可能となる。
【０１００】
以上、第４の実施形態で説明した通り、この仕組みを用いることにより健診の検査に関する読影を適切に行うことが可能となる。
【０１０１】
また、図２３の申請詳細画面２３００について説明する。図２３はＰＥＴ／ＣＴの検査の読影依頼時に表示されるダイアログ画面の一例を示す。ＰＥＴ／ＣＴの検査では、ＰＥＴ（ｐｏｓｉｔｒｏｎ  ｅｍｉｓｓｉｏｎ  ｔｏｍｏｇｒａｐｈｙ）検査で取得した画像とＣＴ検査で取得した画像を組み合わせて、一度の検査で両方の画像を重ねて表示させることが可能となる。これにより診断の精度を向上させることが出来る。ＰＥＴ／ＣＴ検査の読影を依頼する際に、ＰＥＴのシリーズ画像のみ、もしくはＣＴのシリーズ画像のみであった場合は、二次元医用画像のシリーズ数を参照して、シリーズ数の過不足を警告する。その際に図２３に示すように、どちらの種類のシリーズが不足しているのかをダイアログとして表示させてもよい。また、第４の実施形態で説明したように、警告画面で画像の追加登録を受け付けてもよい。
【０１０２】
以上、ＰＥＴ／ＣＴの検査のような場合には、二次元医用画像のシリーズ数が１であった場合に警告してＰＥＴ／ＣＴ検査に関する読影を適切に行うことが可能となる。
【０１０３】
以上説明したように、本実施形態によれば、医用画像診断装置で取得した複数の二次元医用画像のシリーズ数に応じて、当該二次元医用画像から生成される三次元医用画像の読影依頼を適切に行なうことの可能な画面を表示することが表示可能となる。
【０１０４】
本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。
【０１０５】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
【０１０６】
したがって、本発明の機能処理をコンピュータで実現（実行可能と）するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１０７】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【０１０８】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【０１０９】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【０１１０】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１１１】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１１２】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１１３】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【０１１４】
なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【０１１５】
１０１  医用画像診断装置
１０２  依頼端末
１０３  インターネット
１０４  遠隔読影サーバ
１０５  ストレージサーバ
２０１  ＣＰＵ
２０２  ＲＯＭ
２０３  ＲＡＭ
２０４  システムバス
２０５  入力コントローラ
２０６  ビデオコントローラ
２０７  メモリコントローラ
２０８  通信Ｉ／Ｆコントローラ
２０９  入力デバイス
２１０  ディスプレイ
２１１  外部メモリ
【図１】
2017120636.tif 000003
【図２】
2017120636.tif 000004
【図３】
2017120636.tif 000005
【図４】
2017120636.tif 000006
【図５】
2017120636.tif 000007
【図６】
2017120636.tif 000008
【図７】
2017120636.tif 000009
【図８】
2017120636.tif 000010
【図９】
2017120636.tif 000011
【図１０】
2017120636.tif 000012
【図１１】
2017120636.tif 000013
【図１２】
2017120636.tif 000014
【図１３】
2017120636.tif 000015
【図１４】
2017120636.tif 000016
【図１５】
2017120636.tif 000017
【図１６】
2017120636.tif 000018
【図１７】
2017120636.tif 000019
【図１８】
2017120636.tif 000020
【図１９】
2017120636.tif 000021
【図２０】
2017120636.tif 000022
【図２１】
2017120636.tif 000023
【図２２】
2017120636.tif 000024
【図２３】
2017120636.tif 000025