JP2015173693A - 医用画像処理装置及び医用画像処理方法 - Google Patents

Abstract

【課題】医用画像の見落としを抑制できる医用画像処理装置及び医用画像処理方法を提供する。【解決手段】実施形態によれば、基データ保管部と画像生成部と画像データ保管部と画像生成要求管理部と制御部とを備えた医用画像処理装置が提供される。基データ保管部は、複数の基データを保管する。画像生成部は、各基データから複数の医用画像を生成する。画像データ保管部は、各医用画像を保管する。画像生成要求管理部は、画像生成部に各医用画像の生成を要求するための要求情報を管理する。制御部は、ネットワークを介して接続されたクライアント端末からの要求に応じて、対応した検査の情報を検査リスト情報として端末に配信する。制御部は、画像生成中であることを示す情報を検査リスト情報に含める。【選択図】図２

Description

本発明の実施形態は、医用画像処理装置及び医用画像処理方法に関する。

検査で取得された複数の基データから複数の医用画像を生成し、生成した各医用画像を保管する医用画像処理装置がある。また、医用画像処理装置は、クライアントからの要求に応じて、各医用画像をクライアント側の端末に配信する。複数の医用画像の生成には、時間がかかる。このため、クライアントから配信が要求されたタイミングにおいて、各医用画像の生成が完了していない場合がある。例えば、各医用画像の生成の途中でクライアントから配信が要求された場合、一検査分の各医用画像の一部が、見落とされてしまう恐れがある。例えば、読影作業において、医用画像の見落としは、病変部の見落としにつながってしまう。このため、医用画像処理装置では、医用画像の見落としを抑制することが望まれる。

特開２０１３−９７２６号公報

本発明の実施形態は、医用画像の見落としを抑制できる医用画像処理装置及び医用画像処理方法を提供する。

本発明の実施形態によれば、基データ保管部と、画像生成部と、画像データ保管部と、画像生成要求管理部と、制御部と、を備えた医用画像処理装置が提供される。前記基データ保管部は、検査で取得された複数の基データを保管する。前記画像生成部は、前記複数の基データから複数の医用画像を生成する。前記画像データ保管部は、前記複数の医用画像を前記検査毎に保管する。前記画像生成要求管理部は、前記画像生成部に前記複数の医用画像の生成を要求するための要求情報を管理する。前記制御部は、ネットワークを介して接続されたクライアント端末からの要求に応じて、前記要求に対応した前記検査の情報を検査リスト情報として要求基の前記クライアント端末に配信する。前記制御部は、前記画像生成要求管理部に記憶された前記要求情報を参照し、該当する検査が画像生成中であることを示す情報を含む前記検査リスト情報を前記クライアント端末に配信する。

第１の実施形態に係る医用画像処理システムを模式的に表すブロック図である。 第１の実施形態に係る医用画像処理装置を模式的に表すブロック図である。 端末情報の一例を表す模式図である。 検査リストの一例を表す模式図である。 医用画像処理装置の動作の一例を模式的に表すフローチャートである。 第１の実施形態に係る医用画像処理装置の変形例を模式的に表すブロック図である。 画像生成情報の一例を表す模式図である。 検査リストの変形例を表す模式図である。 第２の実施形態に係る医用画像処理装置を模式的に表すブロック図である。 検査時間情報の一例を表す模式図である。 第２の実施形態の検査リストの一例を表す模式図である。 第３の実施形態に係る医用画像処理装置の動作の一例を模式的に表すフローチャートである。 第４の実施形態に係る医用画像処理システムを模式的に表すブロック図である。

以下に、各実施の形態について図面を参照しつつ説明する。
なお、図面は模式的または概念的なものであり、各部分の厚みと幅との関係、部分間の大きさの比率などは、必ずしも現実のものと同一とは限らない。また、同じ部分を表す場合であっても、図面により互いの寸法や比率が異なって表される場合もある。
なお、本願明細書と各図において、既出の図に関して前述したものと同様の要素には同一の符号を付して詳細な説明は適宜省略する。

（第１の実施形態）
図１は、第１の実施形態に係る医用画像処理システムを模式的に表すブロック図である。
図１に表したように、医用画像処理システム１０は、医用画像処理装置１２と、クライアント端末１４と、を備える。クライアント端末１４は、ネットワーク１６を介して医用画像処理装置１２と接続されている。ネットワーク１６は、例えば、ＬＡＮ（Local Area Network）などの特定のエリアのネットワークでもよいし、インターネットなどの公共ネットワークでもよい。

医用画像処理装置１２は、医用画像の生成、及び、生成した医用画像の保管を行う。また、医用画像処理装置１２は、クライアント端末１４からの要求に応じて、保管した医用画像をクライアント端末１４に配信する。

このように、医用画像処理システム１０は、クライアント端末１４から医用画像処理装置１２にアクセスすることにより、医用画像処理装置１２で生成された医用画像をクライアント端末１４で参照できるようにしたシステムである。

医用画像処理システム１０は、例えば、医用画像の読影に用いられる。医用画像処理システム１０は、例えば、医用画像を参照しながら医師が患者に説明を行う場合や、医用画像を参照しながら医師が手術計画を立案する場合などに用いてもよい。

医用画像処理装置１２は、例えば、ＣＴ（Computed Tomography）、ＭＲＩ（magnetic resonance imaging）またはＰＥＴ（positron emission tomography）などのモダリティ装置である。換言すれば、この例において、医用画像処理装置１２は、医用画像収集装置である。医用画像処理装置１２は、一検査に対して複数の医用画像を生成する。医用画像処理装置１２の生成する医用画像は、例えば、断層画像である。

また、医用画像処理装置１２は、例えば、医用デジタル画像と通信に関する標準規格であるＤＩＣＯＭ（Digital Imaging and COMmunications）規格に準拠している。医用画像処理装置１２は、例えば、ＤＩＣＯＭ規格のファイル形式で医用画像を生成する。

医用画像処理装置１２は、例えば、被検者を支持する寝台２０と、被検者の撮影を行う撮影部２１と、寝台２０及び撮影部２１の動作を制御する制御装置２２と、を含む。

撮影部２１は、例えば、ガントリと呼ばれる。医用画像処理装置１２がＣＴである場合、撮影部２１は、放射線を照射する管球と、管球から照射された放射線を受ける検出器と、を含む。撮影部２１は、被検者を撮影し、医用画像の基となる基データを取得する。

基データは、例えば、画像データになる前の生データである。例えば、ＣＴの場合、生データは、検出器で検出された放射線の投影データである。ＭＲＩの場合、生データは、ＲＦコイルで受信された磁気共鳴信号である。撮影部２１は、一検査において、複数の基データを取得する。医用画像処理装置１２は、複数の基データから複数の医用画像を生成する。医用画像処理装置１２は、例えば、複数の基データを基に、異なる位置の複数の断層画像を生成する。

基データは、例えば、生データから生成された高解像度の画像データなどでもよい。医用画像処理装置１２は、例えば、画像データに画像処理を施して別の医用画像を生成してもよい。医用画像処理装置１２の生成する医用画像は、例えば、エッジ抽出を行った画像や３次元画像などでもよい。

このように、医用画像処理装置１２の行う医用画像の生成処理は、生データから医用画像を生成する再構成処理でもよいし、画像データから別の医用画像を生成する画像処理でもよい。

制御装置２２は、例えば、コンソールと呼ばれる。制御装置２２は、例えば、種々の制御を行う本体部２２ａと、本体部２２ａの制御に応じて種々の操作画面などを表示する表示部２２ｂと、本体部２２ａに種々の操作指示を入力する入力部２２ｃと、を含む。入力部２２ｃは、例えば、キーボードやマウスなどである。

クライアント端末１４は、例えば、ワークステーションやパーソナルコンピュータなどである。クライアント端末１４は、タブレット端末などの携帯型の端末でもよい。クライアント端末１４は、ネットワーク１６に有線で接続してもよいし、ネットワーク１６に無線で接続してもよい。クライアント端末１４は、医師や技師などに操作され、医用画像の参照に用いられる任意の端末でよい。

この例では、複数台のクライアント端末１４が、ネットワーク１６に接続されている。ネットワーク１６に接続されるクライアント端末１４は、１台でもよい。また、この例では、１台の医用画像処理装置１２が、ネットワーク１６に接続されている。例えば、複数台の医用画像処理装置１２をネットワーク１６に接続してもよい。

図２は、第１の実施形態に係る医用画像処理装置を模式的に表すブロック図である。
図２に表したように、医用画像処理装置１２は、制御部３０と、基データ保管部３１と、基データ管理部３２と、画像生成部３３と、画像データ保管部３４と、画像データ管理部３５と、画像生成要求管理部３６と、を含む。これらの各部は、例えば、医用画像処理装置１２において、制御装置２２に設けられる。より詳しくは、制御装置２２の本体部２２ａに設けられる。

制御部３０は、医用画像処理装置１２の各部を統括的に制御する。制御部３０は、例えば、プロセッサとシステムメモリとを含み、システムメモリに記憶されたプログラムを逐次処理することによって、医用画像処理装置１２の各部を制御する。また、制御部３０は、ネットワーク１６を介してクライアント端末１４と接続されている。制御部３０は、クライアント端末１４と各種の情報を通信する。制御部３０は、例えば、ＤＩＣＯＭサーバの機能を医用画像処理装置１２に提供する。

基データ保管部３１は、検査で取得された基データ４０を保管する。基データ保管部３１は、例えば、撮影部２１で取得された基データ４０を保管する。基データ４０は、１回の検査で複数取得される。基データ保管部３１は、複数の検査のそれぞれにおいて取得された複数の基データ４０を保管する。

基データ管理部３２は、基データ保管部３１に保管された各基データ４０を管理する。基データ管理部３２は、例えば、各基データ４０のそれぞれにタグ情報として付与された検査ＩＤなどに基づいて、各基データ４０を検査毎に管理する。前述のように、１回の検査において、複数の基データ４０が取得される。一検査分の各基データ４０は、例えば、検査ＩＤによって互いに関連付けられる。各基データ４０は、例えば、検査ＩＤの他に、ＤＩＣＯＭ規格で予め用意された患者ＩＤなどの各種のタグ情報を含む。基データ管理部３２は、タグ情報に限ることなく、例えば、基データ４０の識別情報と検査の識別情報とを関連付けたテーブルデータなどに基づいて、各基データ４０を管理してもよい。

画像生成部３３は、基データ保管部３１に保管された各基データ４０から医用画像４２を生成する。画像生成部３３は、例えば、基データ管理部３２から一検査分の各基データ４０を受信し、受信した各基データ４０を基に、一検査分の複数の医用画像４２を生成する。画像生成部３３は、例えば、生データの各基データ４０を再構成することにより、医用画像４２を生成する。画像生成部３３は、例えば、画像データの各基データ４０に画像処理を施すことにより、医用画像４２を生成してもよい。

画像データ保管部３４は、画像生成部３３が生成した各医用画像４２を保管する。基データ保管部３１及び画像データ保管部３４は、例えば、ＨＤＤ（Hard disk drive）などのストレージユニットである。

画像データ管理部３５は、画像データ保管部３４に保管された各医用画像４２を管理する。画像データ管理部３５は、基データ管理部３２と同様に、タグ情報やテーブルデータなどを基に、各医用画像４２を検査毎に管理する。

画像生成要求管理部３６は、画像生成部３３に医用画像４２の生成を要求するための要求情報４４を管理する。医用画像４２の再構成を行う場合、要求情報４４は、例えば、医用画像処理装置１２（撮影部２１）で検査が行われる毎に、画像生成要求管理部３６に記憶される。また、画像処理で医用画像４２を生成する場合、要求情報４４は、例えば、基データ保管部３１に一検査分の各基データ４０が保管された際に、画像生成要求管理部３６に記憶される。要求情報４４は、例えば、検査ＩＤ、生成する医用画像４２の枚数の情報、及び、医用画像４２の生成に必要な画像生成条件の情報などを含む。画像生成条件とは、例えば、再構成関数などの医用画像４２の生成に必要な各種のパラメータなどである。

要求情報４４は、例えば、検査情報などに基づいて制御部３０で生成され、画像生成要求管理部３６に記憶される。例えば、基データ４０を医用画像処理装置１２の外部から入力する場合には、要求情報４４も外部から入力してもよい。画像生成部３３は、画像生成要求管理部３６から要求情報４４を読み出す。そして、画像生成部３３は、その要求情報４４に対応する検査の基データ４０を基データ保管部３１から読み出し、要求情報４４に基づいて医用画像４２を生成する。画像生成部３３は、生成した医用画像４２を画像データ保管部３４に保管する。

画像生成要求管理部３６は、複数の要求情報４４を記憶することができる。画像生成部３３は、画像生成要求管理部３６に複数の要求情報４４が記憶されている場合、古い要求情報４４から順に読みだして医用画像４２の生成を行う。画像生成要求管理部３６に記憶された要求情報４４は、例えば、画像生成部３３が一検査分の複数の医用画像４２を生成し終えた後に、画像生成要求管理部３６から消去される。要求情報４４は、例えば、再構成キューである。

制御部３０は、クライアント端末１４からの要求に応じて、画像データ保管部３４に医用画像４２が保管されている各検査の検査リスト情報を作成する。そして、制御部３０は、作成した検査リスト情報を要求基のクライアント端末１４に配信する。検査リスト情報は、例えば、検査毎のコメント欄の項目を含む。

制御部３０には、端末情報４６が記憶されている。制御部３０は、クライアント端末１４から検査リストの取得要求を受信すると、端末情報４６を基に、検査リスト情報の作成を行う。

図３は、端末情報の一例を表す模式図である。
図３に表したように、端末情報４６は、クライアント端末１４の識別情報と、画像生成中の検査の提示の可否を示す提示可否情報と、医用画像４２を生成中であることのコメントの提示の要否を示すコメント要否情報と、を関連付けて記憶している。

クライアント端末１４の識別情報には、例えば、ＩＰアドレス、マックアドレスまたはＤＩＣＯＭ ＡＥ Ｔｉｔｌｅなどが用いられる。識別情報は、クライアント端末１４を識別可能な任意の情報でよい。

端末情報４６に関連付けて記憶される情報は、上記に限定されるものではない。端末情報４６は、クライアント端末１４毎に合わせた処理を実行するための他の情報をさらに含んでもよい。また、例えば、全てのクライアント端末１４において画像生成中の検査を提示する場合には、端末情報４６に提示可否情報を含めなくてもよい。例えば、画像生成中の検査を提示する全てのクライアント端末１４において、画像生成中のコメントを提示する場合には、端末情報４６にコメント要否情報を含めなくてもよい。すなわち、端末情報４６には、提示可否情報とコメント要否情報との少なくとも一方が、クライアント端末１４の識別情報と関連付けられていればよい。

制御部３０は、クライアント端末１４から検査リスト取得要求を受信すると、当該取得要求に含まれる検索条件を基に、対応する検査の情報を画像データ管理部３５から取得する。制御部３０は、例えば、検索条件の情報を画像データ管理部３５に入力する。検索条件には、例えば、患者ＩＤ、患者名、検査日時などが用いられる。画像データ管理部３５は、例えば、各医用画像４２のタグ情報と検索条件の情報とを照合することにより、画像データ保管部３４に医用画像４２が保管された各検査の中から、入力された検索条件に適合する検査を抽出し、抽出結果を制御部３０に出力する。例えば、検索条件が検査日時である場合、その検査日時に実施された検査を抽出し、その検査の情報を制御部３０に出力する。画像データ管理部３５は、例えば、抽出した検査の検査ＩＤを制御部３０に出力する。

また、制御部３０は、クライアント端末１４から検査リスト取得要求を受信すると、端末情報４６を参照し、要求基のクライアント端末１４の提示可否情報及びコメント要否情報を確認する。端末情報４６の参照は、画像データ管理部３５から検査の情報を取得した後でもよいし、検査の情報を取得する前でもよい。

例えば、図中の「ＡＡＡ」のクライアント端末１４のように、提示可否情報が「可」で、コメント要否情報が「否」である場合、制御部３０は、画像データ管理部３５の抽出した各検査の情報をそのまま検査リスト情報として要求基のクライアント端末１４に配信する。

「ＢＢＢ」のクライアント端末１４のように、提示可否情報が「可」で、コメント要否情報が「要」である場合、制御部３０は、画像生成要求管理部３６に記憶された要求情報４４を参照する。制御部３０は、画像データ管理部３５の抽出した各検査の情報に、要求情報４４の示す検査が含まれているか否かを判定する。すなわち、制御部３０は、画像データ管理部３５の抽出した各検査の情報に、医用画像４２の生成途中の検査が、含まれているか否かを判定する。

制御部３０は、含まれていないと判定した場合、画像データ管理部３５の抽出した各検査の情報をそのまま検査リスト情報として要求基のクライアント端末１４に配信する。一方、制御部３０は、含まれていると判定した場合、その検査の検査コメント欄に、画像生成中であることを示すコメントを追記する。この後、制御部３０は、コメントを追記した分を含む各検査の情報を検査リスト情報として要求基のクライアント端末１４に配信する。

このように、制御部３０は、検査の情報を取得した後、画像生成要求管理部３６に記憶された要求情報４４を参照し、要求情報４４の示す検査が検査の情報に含まれているか否かを判定し、含まれている場合に、該当する検査が画像生成中であることを示す指示情報を検査リスト情報に含め、指示情報を含む検査リスト情報を要求基のクライアント端末１４に配信する。

この例では、コメントを指示情報として検査リスト情報に追加している。指示情報は、これに限ることなく、例えば、画像生成中を示す特定のアイコン（図柄）などでもよい。指示情報は、該当する検査が画像生成中であることを示すことが可能な任意の情報でよい。

「ＣＣＣ」のクライアント端末１４のように、提示可否情報が「不可」である場合、制御部３０は、画像生成要求管理部３６に記憶された要求情報４４を参照し、画像データ管理部３５の抽出した各検査の情報に、要求情報４４の示す検査が含まれているか否かを判定する。

制御部３０は、含まれていないと判定した場合、画像データ管理部３５の抽出した各検査の情報をそのまま検査リスト情報として要求基のクライアント端末１４に配信する。一方、制御部３０は、含まれていると判定した場合、画像データ管理部３５の抽出した各検査から画像生成要求管理部３６に要求情報４４が記憶されている検査を除外し、除外後の各検査の情報を検査リスト情報として要求基のクライアント端末１４に配信する。すなわち、制御部３０は、提示可否情報が「不可」である場合に、画像生成要求管理部３６に要求情報４４が記憶されている検査の情報を検査リスト情報から除外する。

図４は、検査リストの一例を表す模式図である。
図４に表しように、クライアント端末１４は、医用画像処理装置１２の制御部３０から検査リスト情報を取得すると、その検査リスト情報に基づく検査リストＥＬを表示部に表示する。検査リストＥＬには、例えば、患者ＩＤ、患者名、検査日、及び、検査コメントなどが含まれる。検査リストＥＬに含まれる情報は、これらに限ることなく、クライアント端末１４のユーザ（医師や技師など）が所望の検査を抽出可能な任意の情報でよい。

クライアント端末１４のユーザは、例えば、検査リストＥＬが表示された後、その検査リストＥＬから所望の検査を選択する。クライアント端末１４は、ユーザの選択した検査の情報を医用画像処理装置１２に送信する。

医用画像処理装置１２の制御部３０は、クライアント端末１４から検査の情報を受信すると、その検査に対応する各医用画像４２を画像データ保管部３４から読み出す。そして、制御部３０は、読み出した各医用画像４２を要求基のクライアント端末１４に配信する。これにより、クライアント端末１４において、所望の検査の各医用画像４２を参照することができる。例えば、各医用画像４２の読影を行うことができる。

次に、医用画像処理装置１２の作用について説明する。
図５は、医用画像処理装置の動作の一例を模式的に表すフローチャートである。
図５に表したように、医用画像処理装置１２の制御部３０は、クライアント端末１４から検査リスト取得要求を受信する（ステップＳ１）。制御部３０は、検査リスト取得要求を受信すると、その取得要求に含まれる検索条件を画像データ管理部３５に入力し、対応する検査の情報の取得を画像データ管理部３５に要求する。

画像データ管理部３５は、検索条件を受信すると、その検索条件に適合する検査を抽出し、抽出した検査の情報を制御部３０に出力する。これにより、制御部３０は、検査リスト取得要求に対応した検査の情報を画像データ管理部３５から取得する（ステップＳ２）。

制御部３０は、検査リスト取得要求を受信した後、端末情報４６を参照する（ステップＳ３）。制御部３０は、例えば、検査リスト取得要求に含まれる要求基のクライアント端末１４の識別情報を基に、端末情報４６を参照する。これにより、制御部３０は、要求基のクライアント端末１４の提示可否情報を確認する。

制御部３０は、要求基のクライアント端末１４の提示可否情報を確認し、提示可否情報が「可」であるか否かを判定する（ステップＳ４）。制御部３０は、「可」であると判定した場合、要求基のクライアント端末１４のコメント要否情報を確認する。そして、制御部３０は、コメント要否情報が「要」であるか否かを判定する（ステップＳ５）。

制御部３０は、「要」であると判定した場合、画像生成要求管理部３６に記憶された要求情報４４を参照する（ステップＳ６）。そして、制御部３０は、画像データ管理部３５の抽出した検査の情報に、要求情報４４の示す検査が含まれているか否かを判定する（ステップＳ７）。

制御部３０は、含まれていると判定した場合、その検査の検査コメント欄に、画像生成中であることを示すコメントを追記する（ステップＳ８）。制御部３０は、コメントの追記の後、検査リスト取得要求に対応した検査の情報を、検査リスト情報として要求基のクライアント端末１４に配信する（ステップＳ９）。

制御部３０は、ステップＳ７において、含まれていないと判定した場合、コメントの追記を行うことなくステップＳ９に進み、検査リスト取得要求に対応した検査の情報を、検査リスト情報として要求基のクライアント端末１４に配信する。

制御部３０は、ステップＳ５において、コメント要否情報が「否」である判定した場合、ステップＳ９に進み、検査リスト取得要求に対応した検査の情報を、検査リスト情報として要求基のクライアント端末１４に配信する。

制御部３０は、ステップＳ４において、提示可否情報が「不可」であると判定した場合、画像生成要求管理部３６に記憶された要求情報４４を参照する（ステップＳ１０）。そして、制御部３０は、画像データ管理部３５の抽出した検査の情報に、要求情報４４の示す検査が含まれているか否かを判定する（ステップＳ１１）。

制御部３０は、含まれていると判定した場合、画像データ管理部３５の抽出した各検査から画像生成要求管理部３６に要求情報４４が記憶されている検査を除外する（ステップＳ１２）。制御部３０は、画像生成中の検査を除外した後、ステップＳ９に進み、検査リスト取得要求に対応した検査の情報を、検査リスト情報として要求基のクライアント端末１４に配信する。

また、制御部３０は、ステップＳ１１において、含まれていないと判定した場合、画像生成中の検査の除外を行うことなくステップＳ９に進み、検査リスト取得要求に対応した検査の情報を、検査リスト情報として要求基のクライアント端末１４に配信する。

クライアント端末１４は、検査リスト情報を取得した後、その検査リスト情報に基づく検査リストＥＬを表示部に表示する。クライアント端末１４が、提示可否情報が「可」で、コメント要否情報が「要」であり、かつ医用画像４２の生成途中の検査が含まれている場合、画像生成中であることを示すコメントが、検査コメント欄に表示される。

これにより、当該検査において、まだ生成されていない医用画像４２があることを、クライアント端末１４のユーザに即座に認識させることができる。これにより、医用画像４２の見落としを抑制することができる。また、クライアント端末１４は、例えば、ＤＩＣＯＭ規格に準拠して検査リストＥＬの表示を行う。検査コメント欄は、ＤＩＣＯＭ規格などにおいて、予め用意された項目である。従って、クライアント端末１４の変更を要することなく、医用画像処理装置１２側の変更のみで、医用画像４２の見落としを適切に抑制することができる。

このように、本実施形態に係る医用画像処理装置１２の医用画像処理方法は、検査の情報を取得した後、画像生成要求管理部３６に記憶された要求情報４４を参照し、要求情報４４の示す検査が検査の情報に含まれているか否かを判定する工程を含む（ステップＳ６、Ｓ７）。医用画像処理方法は、含まれている場合に、該当する検査が画像生成中であることを示す指示情報を検査リスト情報に含める工程をさらに含む（ステップＳ８）。医用画像処理方法は、指示情報を含む検査リスト情報をクライアント端末１４に配信する工程をさらに含む（ステップＳ９）。

例えば、クライアント端末１４で読影作業を実施する場合、一検査分の全画像が揃っている必要がある。医用画像処理装置１２では、常に新しい医用画像４２が発生している。このため、クライアント端末１４から指定された検索条件に対応する検査を単純に提示すると、全画像が揃っていない状態で、読影が開始されてしまう可能性がある。すなわち、読影作業において、一検査分の複数の医用画像４２の一部が、見落とされてしまう恐れがある。医用画像４２の見落としは、例えば、病変部の見落としにつながる。

これに対して、本実施形態に係る医用画像処理装置１２では、画像生成中の検査が検査リスト情報に含まれる場合に、画像生成中であることを示すコメントを検査コメント欄に追記する。これにより、上記のように、医用画像４２の見落としを抑制することができる。例えば、一検査の全画像が揃っていない状態で読影作業が開始されてしまうことを抑制することができる。

医用画像の見落としを抑制する技術として、例えば、医用画像処理装置とは別に、医用画像を保管する医用画像サーバをシステムに設けることが考えられる。例えば、医用画像サーバ内に検査種毎の画像数に関するテーブルを予め用意しておく。そして、このテーブルに記憶された画像数と実際に生成されている画像数とを比較し、検査下の全画像が揃っている検査のみをクライアント端末に提示する。

しかしながら、医用画像サーバは高価であり、診療所や小規模な病院などの医療機関では、医用画像サーバを設置できない場合がある。また、近年では、読影医の不足も問題になっており、特に救急時の読影などにおいて、クライアント端末（読影用端末）からモダリティ装置などに直接アクセスして医用画像を参照するケースも増加している。

例えば、ＲＩＳ（Radiology Information System）サーバに対する検査情報取得要求や検査終了通知要求などを利用して、医用画像の見落としを抑制することも考えられる。しかしながら、検査終了通知は、必ずしも画像生成が完了してから通知されるとは限らない。また、ＲＩＳサーバは高価であり、医療機関によっては、ＲＩＳサーバを設置することができない。さらに、ＲＩＳサーバとの通信機能をクライアント端末に持たせることも、新たなコストを生む。

本実施形態に係る医用画像処理装置１２では、医用画像サーバやＲＩＳサーバなどを別途設ける必要がない。従って、医用画像サーバやＲＩＳサーバを設ける場合と比べて、簡易な構成で医用画像４２の見落としを抑制することができる。例えば、比較的低コストで、医用画像４２の見落としを抑制することができる。医用画像処理装置１２をモダリティ装置とすることで、救急時対応の要望にも応えることができる。さらには、クライアント端末１４側に変更を加えることなく、医用画像４２の見落としを抑制することができる。

また、本実施形態に係る医用画像処理装置１２では、画像生成中の検査を提示するか否か、及び、途中であることを提示するか否かを、クライアント端末１４毎に選択することができる。これにより、例えば、クライアント端末１４のユーザの好みなどに応じた検査リストＥＬの表示を行うことができる。例えば、医用画像処理システム１０の利便性をより高めることができる。

図６は、第１の実施形態に係る医用画像処理装置の変形例を模式的に表すブロック図である。
図６に表したように、医用画像処理装置５０の制御部３０は、画像生成情報５２をさらに記憶している。

図７は、画像生成情報の一例を表す模式図である。
図７に表したように、画像生成情報５２は、画像生成条件の情報と、画像ｎ枚当たりの生成時間の情報と、を関連付けて記憶している。画像生成条件の情報とは、例えば、再構成関数など、医用画像４２の生成に必要な情報である。

この例において、制御部３０は、画像生成中であることを示すコメントを検査コメント欄に追記する場合に、要求情報４４に含まれる画像生成条件の情報を基に、画像生成情報５２を参照する。制御部３０は、要求情報４４に含まれる枚数の情報と、画像生成情報５２に含まれる生成時間の情報と、を基に、一検査分の複数の医用画像４２の生成に要する時間を算出する。制御部３０は、算出した時間を基に、画像生成の完了予定時刻を算出する。そして、制御部３０は、算出した完了予定時刻を、画像生成中であることを示すコメントとして検査コメント欄に追記する。このように、制御部３０は、該当する検査の画像生成の完了予定時刻を算出し、完了予定時刻をコメントとして検査リスト情報に含める。例えば、画像生成要求管理部３６に複数の要求情報４４が記憶されている場合には、該当する検査の前までの各要求情報４４のそれぞれの画像生成の時間を算出し、各検査の時間の総和から完了予定時刻を算出する。

図８は、検査リストの変形例を表す模式図である。
図８に表しように、この例においては、クライアント端末１４が検査リストＥＬを表示部に表示する際に、画像生成の完了予定時刻が、検査コメント欄に表示される。これにより、当該検査において、生成途中の医用画像４２があることを、クライアント端末１４のユーザに認識させることができるとともに、その医用画像４２の生成の完了予定時刻を報知することができる。例えば、医用画像処理システム１０の利便性をより高めることができる。

例えば、完了予定時刻の提示が必要か否かを示す情報を端末情報４６に含める。これにより、完了予定時刻を提示するか否かをクライアント端末１４毎に選択できるようにしてもよい。すなわち、完了予定時刻を検査リストＥＬに表示するか、「画像生成中」のコメントのみを検査リストＥＬに表示するかを、クライアント端末１４毎に選択できるようにしてもよい。

（第２の実施形態）
図９は、第２の実施形態に係る医用画像処理装置を模式的に表すブロック図である。
図９に表したように、医用画像処理装置６０は、予約情報保管部６１と、検査予約管理部６２と、をさらに含む。また、医用画像処理装置６０では、制御部３０が、検査時間情報６６をさらに記憶している。なお、機能・構成上、上記第１の実施形態と実質的に同じものについては、同符号を付し、詳細な説明を省略する。

予約情報保管部６１は、検査予約情報６４を保管する。検査予約情報６４は、例えば、医用画像処理装置６０で実施される検査の予約状況を表す。例えば、別のモダリティ装置で検査を行い、医用画像処理装置６０で医用画像４２の生成のみを行う場合には、別のモダリティ装置で実施される検査を検査予約情報６４に含めてもよい。検査予約情報６４は、例えば、検査ＩＤ、患者ＩＤ、患者名、検査日時、検査種、撮影枚数、及び、画像生成条件など、検査の実施に必要な各種の情報を含む。

検査予約管理部６２は、予約情報保管部６１に保管された検査予約情報６４を管理する。検査予約管理部６２は、例えば、検査予約情報６４に含まれる検査ＩＤや患者ＩＤなどに基づいて、検査予約情報６４を管理する。

検査予約情報６４は、例えば、ＲＩＳサーバなどから取得され、予約情報保管部６１に保管される。検査予約情報６４は、例えば、医師や技師などの手入力により、予約情報保管部６１に保管してもよい。また、例えば、予約情報保管部６１を設けることなく、必要に応じてＲＩＳサーバなどから検査予約情報６４を随時取得してもよい。

図１０は、検査時間情報の一例を表す模式図である。
図１０に表したように、検査時間情報６６は、検査種の情報と、その検査の所要時間の情報と、を関連付けて記憶している。これにより、検査時間情報６６を参照することで、検査の所要時間を取得することができる。

検査の所要時間の情報は、例えば、撮影部２１で複数の基データ４０（生データ）を取得するまでの時間と、複数の基データ４０から複数の医用画像４２を生成するまでの時間と、を含む。例えば、撮影枚数などの検査条件によって所要時間が変化する場合には、同じ検査種において、検査条件の異なる複数のデータを用意してもよい。この場合には、例えば、検査時間情報６６に検査条件の項目を追加し、検査種と検査条件とから所要時間を取得すればよい。

制御部３０は、クライアント端末１４から検査リスト取得要求を受信すると、その取得要求に含まれる検索条件を検査予約管理部６２に入力し、対応する未実施の検査の情報の取得を検査予約管理部６２に要求する。

検査予約管理部６２は、検索条件を受信すると、その検索条件に適合する検査を抽出し、抽出した検査の情報を制御部３０に出力する。これにより、制御部３０は、検査リスト取得要求に対応した未実施の検査の情報を検査予約管理部６２から取得する。なお、未実施の検査の情報の取得は、画像データ管理部３５から実施済みの検査の情報を取得した後でもよいし、実施済みの検査の情報の取得前でもよい。

制御部３０は、未実施の検査の情報を取得した後、検査予約情報６４に含まれる検査種を基に検査時間情報６６を参照し、その検査の所要時間を取得する。そして、制御部３０は、取得した所要時間と、検査予約情報６４に含まれる検査日時と、を基に、未実施の検査の画像生成の完了予定時刻を算出する。

制御部３０は、未実施の検査の画像生成の完了予定時刻を算出した後、画像データ管理部３５の抽出した実施済みの検査の情報に、検査予約管理部６２の抽出した未実施の検査の情報を加える。この際、制御部３０は、検査の開始予定時刻及び算出した完了予定時刻を、未実施の検査の検査コメント欄に追記する。

制御部３０は、抽出した実施済みの検査の情報及び未実施の検査の情報を検査リスト情報として要求基のクライアント端末１４に配信する。このように、制御部３０は、検査予約情報６４を基に、未実施の検査の画像生成の完了予定時刻を算出し、未実施の検査の完了予定時刻を検査リスト情報にさらに加える。

図１１は、第２の実施形態の検査リストの一例を表す模式図である。
図１１に表しように、この例においては、クライアント端末１４が検査リストＥＬを表示部に表示する際に、未実施の検査の情報も検査リストＥＬに表示される。さらに、検査の開始予定時刻と、その検査の各医用画像４２の生成の完了予定時刻と、が、未実施の検査の検査コメント欄に表示される。これにより、未実施の検査もクライアント端末１４のユーザに報知することができる。例えば、医用画像処理システム１０の利便性をより高めることができる。

例えば、未実施の検査の提示が必要か否かを示す情報を端末情報４６に含める。これにより、未実施の検査を提示するか否かをクライアント端末１４毎に選択できるようにしてもよい。

（第３の実施形態）
図１２は、第３の実施形態に係る医用画像処理装置の動作の一例を模式的に表すフローチャートである。
図１２に表したように、この例では、画像データ管理部３５の抽出した検査の情報に、要求情報４４の示す検査が含まれているとステップＳ７またはステップＳ１１において判定された場合に、画像生成要求管理部３６が、当該検査の画像生成の順序の優先度を高くする（ステップＳ２１、ステップＳ２２）。

例えば、制御部３０は、含まれていると判定した後、その検査について、クライアント端末１４から検索されたことを示す情報を画像生成要求管理部３６に送る。画像生成要求管理部３６は、制御部３０からの情報の受信に応答して、当該検査の優先度を高くする。すなわち、画像生成要求管理部３６は、クライアント端末１４から検査リスト情報の参照を要求された場合に、当該検査の画像生成の順序の優先度を高くする。

クライアント端末１４から検索された検査は、例えば、早く読影などを開始したい検査であると考えられる。従って、上記のように、クライアント端末１４側から検索された検査の要求情報４４が画像生成要求管理部３６に記憶されている場合には、その検査の生成順序の優先度を高くする。換言すれば、検索された検査の画像生成のジョブが待機中である場合には、そのジョブの優先度を高くし、そのジョブを検索されていないジョブよりも先に実行する。これにより、クライアント端末１４のユーザの所望する医用画像４２をなるべく早く参照させることができる。例えば、医用画像処理システムの利便性をより高めることができる。

図１２では、コメントを追記する処理の後に、優先度を高くする処理を行っている。同様に、画像データ管理部３５の抽出した各検査から画像生成要求管理部３６に要求情報４４が記憶されている検査を除外する処理の後に、優先度を高くする処理を行っている。

優先度を高くする処理は、コメントを追記する処理の前や、検査を除外する処理の前に行ってもよい。優先度を高くする処理は、検査リスト情報を配信する処理の後に行ってもよい。すなわち、優先度を高くする処理を行うタイミングは、画像データ管理部３５の抽出した検査の情報に、要求情報４４の示す検査が含まれていると制御部３０が判定した後の任意のタイミングでよい。

画像生成の順序の優先度は、検索が行われる毎に高くしてもよい。例えば、検索されていない検査の優先度は「１」に設定し、１回検索された検査の優先度は「２」に設定し、２回検索された検査の優先度は、「３」に設定する。このように、検索が行われる毎に優先度を高くし、優先度の高い検査から順に画像生成を行う。これにより、例えば、医用画像処理システムの利便性をより高めることができる。

なお、図８や図１１に示したように、画像生成の完了予定時刻をコメントとして追記する場合には、優先度を変更した後の各要求情報４４の並び順に従って完了予定時刻を算出する。これにより、優先度を変更した場合でも、完了予定時刻を適切に算出することができる。この場合には、優先度を高くする処理を行った後に、コメントの追記を行うことが好ましい。

（第４の実施形態）
図１３は、第４の実施形態に係る医用画像処理システムを模式的に表すブロック図である。
図１３に表したように、医用画像処理システム８０では、医用画像処理装置８２が、ネットワーク１６を介してクライアント端末１４及びモダリティ装置８４と接続されている。医用画像処理装置８２は、モダリティ装置８４から基データ４０を受け取り、モダリティ装置８４からの基データ４０に基づいて医用画像４２の生成を行う。医用画像処理装置８２は、例えば、医用画像４２の生成のみを行うアプリケーションサーバである。

このように、医用画像処理装置８２は、必ずしも撮影部２１を含まなくてもよい。モダリティ装置８４から送られる基データ４０は、生データでもよいし、再構成後の画像データでもよい。医用画像処理装置８２は、生データを再構成して医用画像４２を生成してもよいし、画像データに画像処理を施して医用画像４２を生成してもよい。

実施形態によれば、医用画像の見落としを抑制できる医用画像処理装置及び医用画像処理方法が提供される。

以上、具体例を参照しつつ、本発明の実施の形態について説明した。しかし、本発明の実施形態は、これらの具体例に限定されるものではない。例えば、医用画像処理装置に含まれる、基データ保管部、画像生成部、画像データ保管部、画像生成要求管理部、及び、制御部などの各要素の具体的な構成に関しては、当業者が公知の範囲から適宜選択することにより本発明を同様に実施し、同様の効果を得ることができる限り、本発明の範囲に包含される。
また、各具体例のいずれか２つ以上の要素を技術的に可能な範囲で組み合わせたものも、本発明の要旨を包含する限り本発明の範囲に含まれる。

その他、本発明の実施の形態として上述した医用画像処理装置及び医用画像処理方法を基にして、当業者が適宜設計変更して実施し得る全ての医用画像処理装置及び医用画像処理方法も、本発明の要旨を包含する限り、本発明の範囲に属する。

その他、本発明の思想の範疇において、当業者であれば、各種の変更例及び修正例に想到し得るものであり、それら変更例及び修正例についても本発明の範囲に属するものと了解される。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０、８０…医用画像処理システム、 １２、５０、６０、８２…医用画像処理装置、 １４…クライアント端末、 １６…ネットワーク、 ２０…寝台、 ２１…撮影部、 ２２…制御装置、 ３０…制御部、 ３１…基データ保管部、 ３２…基データ管理部、 ３３…画像生成部、 ３４…画像データ保管部、 ３５…画像データ管理部、 ３６…画像生成要求管理部、 ４０…基データ、 ４２…医用画像、 ４４…要求情報、 ４６…端末情報、 ５２…画像生成情報、 ６１…予約情報保管部、 ６２…検査予約管理部、 ６４…検査予約情報、 ６６…検査時間情報、 ８４…モダリティ装置、 ＥＬ…検査リスト

Claims (10)

1. 検査で取得された複数の基データを保管する基データ保管部と、
   前記複数の基データから複数の医用画像を生成する画像生成部と、
   前記複数の医用画像を前記検査毎に保管する画像データ保管部と、
   前記画像生成部に前記複数の医用画像の生成を要求するための要求情報を管理する画像生成要求管理部と、
   ネットワークを介して接続されたクライアント端末からの要求に応じて、前記要求に対応した前記検査の情報を検査リスト情報として要求基の前記クライアント端末に配信する制御部と、
   を備え、
   前記制御部は、前記画像生成要求管理部に記憶された前記要求情報を参照し、該当する検査が画像生成中であることを示す情報を含む前記検査リスト情報を前記クライアント端末に配信する医用画像処理装置。
2. 前記制御部は、前記クライアント端末の識別情報と、画像生成中の検査の提示の可否を示す提示可否情報と、を関連付けた端末情報を含み、前記端末情報を基に、要求基の前記クライアント端末の提示可否情報が可であるか否かを判定し、不可である場合に、前記画像生成要求管理部に前記要求情報が記憶されている前記検査の情報を前記検査リスト情報から除外する請求項１記載の医用画像処理装置。
3. 前記画像生成要求管理部は、前記クライアント端末から前記検査リスト情報の参照を要求された場合に、当該検査の画像生成の順序の優先度を高くする請求項１または２に記載の医用画像処理装置。
4. 前記検査リスト情報は、検査毎のコメント欄の項目含み、
   前記画像生成中であることを示す前記情報は、前記コメント欄に表示されるコメントである請求項１〜３のいずれか１つに記載の医用画像処理装置。
5. 前記制御部は、前記該当する検査の画像生成の完了予定時刻を算出し、前記完了予定時刻を前記コメントとして前記検査リスト情報に含める請求項４記載の医用画像処理装置。
6. 前記制御部は、検査予約情報を基に、未実施の検査の画像生成の完了予定時刻を算出し、前記未実施の検査の完了予定時刻を前記検査リスト情報にさらに加える請求項１〜５のいずれか１つに記載の医用画像処理装置。
7. 前記制御部は、前記検査予約情報を基に、前記未実施の検査の開始予定時刻を前記検査リスト情報にさらに加える請求項６記載の医用画像処理装置。
8. 前記検査予約情報を保管する予約情報保管部をさらに備え、
   前記制御部は、前記クライアント端末からの前記要求に対応した前記未実施の検査の情報を前記予約情報保管部から取得する請求項６または７に記載の医用画像処理装置。
9. 前記端末情報は、前記画像生成中であることを示す前記情報の提示の要否を示す要否情報をさらに関連付けて記憶しており、
   前記制御部は、前記要否情報が要であるか否かを判定し、否である場合、前記画像生成中であることを示す前記情報を含めることなく、取得した前記検査の情報をそのまま前記検査リスト情報として要求基の前記クライアント端末に配信する請求項８記載の医用画像処理装置。
10. 検査で取得された複数の基データを保管する基データ保管部と、前記複数の基データから複数の医用画像を生成する画像生成部と、前記複数の医用画像を前記検査毎に保管する画像データ保管部と、前記画像生成部に前記複数の医用画像の生成を要求するための要求情報を管理する画像生成要求管理部と、ネットワークを介して接続されたクライアント端末からの要求に応じて前記要求に対応した前記検査の情報を検査リスト情報として要求基の前記クライアント端末に配信する制御部と、を備えた医用画像処理装置の医用画像処理方法であって、
    前記画像生成要求管理部に記憶された前記要求情報を参照し、該当する検査が画像生成中であることを示す情報を前記検査リスト情報に含める工程と、
    前記画像生成中であることを示す前記情報を含む前記検査リスト情報を前記クライアント端末に配信する工程と、
    を含む医用画像処理方法。

Images