JP2009189541A - 読影支援装置及び方法、並びに医用ネットワークシステム - Google Patents

Abstract

【課題】比較的処理能力が低く安価な携帯端末を用いて、支障なく医用画像の読影が行えるようにする。
【解決手段】データセンタのアプリケーションサーバは、依頼元から受信した読影対象の画像３６を読影医の携帯端末２２に配信して、携帯端末２２を用いた読影を支援する。アプリケーションサーバは、画像３６の撮影範囲全体を配信する場合には、画像処理部４１ｂが画像３６のデータに対してデータ量削減処理を施して全体画像５３を生成する。また、撮影範囲の一部３６ａを配信する場合には、一部３６ａに対応するデータをオリジナルデータから切り出して部分画像５４を生成する。部分画像５４は、データ量削減処理がされていないので、全体画像５３と比較して解像度が高い。
【選択図】図５

Description

本発明は、携帯端末へ医用画像を配信して読影を支援する読影支援装置及び方法、並びに医用ネットワークシステムに関するものである。

医療施設間で行われる医療検査の予約を支援する検査予約支援サービス、医用画像の画像診断（読影）を支援する読影支援サービスといった、コンピュータシステムを利用したアプリケーションサービスを、オンラインで提供する医用ネットワークシステムが知られている（例えば、特許文献１参照）。医用ネットワークシステムは、複数の医療施設に設置される複数のコンピュータシステムと、サービス提供元のデータセンタに設置されるコンピュータシステムとを、広域ＩＰ（Internet Protocol）ネットワーク、公衆電話網、専用線といった広域通信網（ＷＡＮ）で接続することによって構成される。

読影支援サービスでは、依頼元の医療施設から発行される読影の依頼情報をデータセンタが受信して、読影の専門医が在籍する読影センタに依頼情報を送る。読影センタでは、依頼情報に応じて読影を行い、その結果をまとめた医用レポートを依頼元へ送る。

医療現場においては緊急の読影が必要な場合も多く、読影センタには、緊急の読影依頼に応えられる体制が求められている。しかしながら、休日や深夜など読影医が不足している場合や、依頼元が指定した読影医（過去に依頼経験がある読影医など）が読影センタに不在の場合などがあり、緊急の読影依頼に迅速に対応できないこともあった。

上記問題点の解決策として、特許文献２が提案されている。特許文献２には、読影医の携帯端末（携帯電話など）へ読影対象となる医用画像を配信するコンピュータシステムが記載されている。これによれば、読影医が携帯端末で医用画像を受け取れる環境にあれば、携帯端末のディスプレイで医用画像の読影が可能となるので、そうしたコンピュータシステムに対する医療現場からの期待は大きい。
特開２００５−３０１４３４号公報 特開２００６−０２４０４８号公報

しかしながら、携帯電話などの市販の携帯端末は、ＣＰＵの処理能力やメモリの容量といったハードウエアの性能が、卓上用のパーソナルコンピュータやワークステーションに比べて劣るため、医用画像のようにデータサイズの大きい画像をディスプレイへ表示する処理能力の不足が懸念される。処理能力が不足すると、医用画像が表示されるまでの表示待ち時間、複数枚の医用画像間の表示切り替え時間、医用画像の一部を拡大するための拡大処理時間といった表示処理の長時間化を招く。

読影に際しては、複数枚の医用画像を比較参照するための表示の切り替えや、１枚の画像内の関心領域の拡大といった画面操作が多用されるので、処理能力が不足すると、読影に支障が生じる。この問題の解決策として、高性能な読影用の専用携帯端末を開発して読影医に携帯させるといった対応も考えられるが、コスト的な問題を考慮すると現実的ではない。

また、もう１つの解決策として、携帯端末へ配信する医用画像のデータ量を減らすために、圧縮処理などによって解像度を一律に下げることが考えられる。しかし、読影に際しては、細部を拡大して微妙な陰影の確認が必要なケースも多いため、単に配信する医用画像に対して一律に解像度を下げたのでは細部の確認ができず、やはり、読影に支障が生じる。

本発明は、こうした背景に鑑みてなされたもので、その目的は、比較的処理能力が低く安価な携帯端末を用いて、支障なく医用画像の読影が行えるようにすることにある。

上記目的を達成するために、本発明の読影支援装置は、ネットワークを介して携帯端末へ医用画像を配信して前記医用画像の読影を支援する読影支援装置において、前記医用画像のデータを取得する画像取得手段と、前記データのデータ量を削減して、第１画像を生成するデータ量削減手段と、前記第１画像の撮影範囲の一部を前記データから切り出して、前記第1画像よりも高解像度の第２画像を生成する画像切り出し手段と、前記第１画像と前記第２画像を前記携帯端末へ配信する配信手段とを備えたことを特徴とする。

前記第１画像の撮影範囲は、１枚の前記医用画像の全体であることが好ましい。

前記配信手段は、前記画像取得手段で取得した複数枚の前記医用画像のリストを前記携帯端末に配信して、前記携帯端末において前記リストから選択された前記医用画像に対応する前記第１画像を配信することが好ましい。

前記リストには、読影を依頼する依頼元が優先して読影してほしい前記医用画像を、他の前記医用画像と識別するための識別情報が付されることが好ましい。

前記配信手段は、前記第１画像、前記第２画像、及び前記リストのうち少なくとも１つを、前記携帯端末のディスプレイに表示させるための表示画面データを前記携帯端末に配信することが好ましい。

前記表示画面データには、前記携帯端末で実行され、前記携帯端末への操作指示入力と非同期で前記第２画像の配信要求を発行するための非同期通信プログラムが含まれることが好ましい。

前記非同期通信プログラムは、前記携帯端末のディスプレイで表示されている前記第２画像の周辺の画像の配信要求を発行することが好ましい。

前記配信手段は、前記携帯端末のディスプレイに医用レポートの編集画面を表示させるための編集画面データを前記携帯端末に配信することが好ましい。

前記編集画面で入力された前記医用レポートのデータを前記携帯端末から受信して、前記医用レポートのデータを所定のレポートフォーマットに変換するフォーマット変換手段を備えることが好ましい。

前記編集画面は、テキストを入力する編集領域と、前記第１画像又は第２画像とを並べて表示可能であることが好ましい。

前記編集画面には、前記編集領域を、前記第１画像又は第２画像と並べて表示する並列表示モードと、前記編集領域を単独で表示させる単独表示モードとを切り替えるユーザインタフェースが設けられていることが好ましい。

本発明の読影支援方法は、ネットワークを介して携帯端末へ医用画像を配信して前記医用画像の読影を支援する読影支援方法において、前記医用画像のデータを取得する画像取得ステップと、前記データのデータ量を削減して、第１画像を生成するデータ量削減ステップと、前記第１画像の撮影範囲の一部を前記データから切り出して、前記第1画像よりも高解像度の第２画像を生成する画像切り出しステップと、前記第１画像と前記第２画像を前記携帯端末へ配信する配信ステップとを備えたことを特徴とする。

本発明の医用ネットワークシステムは、医用画像の読影を依頼する依頼元の第１コンピュータシステムと、前記第１コンピュータシステムとネットワークを介して通信可能に接続され、前記第１コンピュータシステムから受信した前記医用画像を携帯端末に配信する第２コンピュータシステムとからなる医用ネットワークシステムにおいて、前記第２コンピュータシステムは、前記医用画像のデータを前記第１コンピュータシステムから取得する画像取得手段と、前記データのデータ量を削減して、第１画像を生成するデータ量削減手段と、前記第１画像の撮影範囲の一部を前記データから切り出して、前記第1画像よりも高解像度の第２画像を生成する画像切り出し手段と、前記第１画像と前記第２画像を前記携帯端末へ配信する配信手段とを備えたことを特徴とする。

前記第２コンピュータシステムは、前記第１コンピュータシステムから受信した前記読影の依頼情報を前記携帯端末へ通知する通知手段を備えることが好ましい。

前記通知手段は、前記携帯端末へ前記依頼情報を通知する前に、前記携帯端末とは異なる依頼先へ前記依頼情報を通知し、前記依頼先からの応答結果に基づいて前記携帯端末へ前記依頼情報を通知することが好ましい。

本発明によれば、医用画像のデータ量を削減した第１画像と、前記第１画像の撮影範囲の一部を切り出し前記第１画像よりも高解像度な第２画像を携帯端末に配信するから、比較的処理能力が低い安価な携帯端末を用いて、支障なく医用画像の読影を行うことができる。

図１に示す医用ネットワークシステム１０は、データセンタ１１のコンピュータシステムと、このコンピュータシステムと通信ネットワークによって接続された、病院１２、診療所１３、及び読影センタ１４の各医療施設のコンピュータシステムとからなる。

病院１２は、例えば、地域における医療施設の中で比較的大規模な医療施設であり、ＣＴ（Computed Tomography）装置やＭＲＩ（Magnetic Resonance Imaging）装置など高度な医療検査設備（モダリティ）を保有し、外部の医療施設からの検査依頼などの診療依頼を受託する医療施設である。診療所１３は、そうしたモダリティを持たず、病院１２に対して診療を委託する比較的小規模な医療施設の例である。病院１２は、診療所１３からの依頼をデータセンタ１１経由で受け付けて、診療を受託する。読影センタ１４は、病院１２や診療所１３からの依頼に応じて、医用画像（以下、単に画像という）の読影を受託する読影機関である。読影センタ１４には、読影を専門とする読影医２１が在籍している。

データセンタ１１のコンピュータシステムは、病院１２及び診療所１３のそれぞれのコンピュータシステムを構成する各クライアント端末１６、１７とＷＡＮ（Wide Area Network）１８を介して通信可能に接続されている。また、データセンタ１１のコンピュータシステムは、読影センタ１４のコンピュータシステムを構成する受付サーバ１９やクライアント端末（図示せず）とも接続されている。

データセンタ１１は、クライアント端末１６、１７からの要求に応じて、検査予約支援サービス及び読影支援サービスといったアプリケーションサービスを提供する。各クライアント端末１６、１７には、例えば、ＨＴＴＰ(Hypertext Transfer Protocol)に対応したブラウザソフトがインストールされており、ブラウザソフトを通じてデータセンタ１１のコンピュータシステムと通信を行ってアプリケーションサービスを受ける。

検査予約支援サービスは、データセンタ１１にアクセスした診療所１３のクライアント端末１７に対して、病院１２の予約受け付け枠に対応したスケジュールデータを配信し、診療所１３から医療検査の予約申し込み情報を受け付けて、受信した予約申し込み情報を病院１２へ配信するサービスである。診療所１３に配信されるスケジュールデータは、クライアント端末１７において、例えば、カレンダ形式で表示される。診療所１３は、表示されたスケジュールから空き状況を確認して、依頼先の病院１２宛の予約申し込み情報を、クライアント端末１７からデータセンタ１１に送信する。

読影支援サービスは、病院１２が読影センタ１４に対して依頼する画像の読影の申し込みや、読影医２１が携帯端末２２を利用して行う読影行為を支援するサービスである。データセンタ１１は、依頼元の病院１２からの読影の依頼情報と読影対象の画像を受信して、受信した依頼情報と画像を依頼先に送信する。

また、データセンタ１１は、例えば、依頼元から緊急の読影依頼が発行され、依頼元が指定した読影医２１が読影センタ１４に不在であったり、読影センタ１４内の読影医２１の手が足りなかったりする場合に、読影医２１の携帯端末２２に緊急依頼通知を転送する。読影医２１は、携帯端末２２で緊急依頼通知を受信すると、データセンタ１１にアクセスして読影対象の画像をダウンロードする。読影医２１は、携帯端末２２のディスプレイで画像を見ながら医用レポート（以下、単にレポートという）を作成し、作成したレポートをデータセンタ１１へアップロードする。データセンタ１１は、アップロードされたレポートを依頼元へ配信する。

ＷＡＮ１８は、広域ＩＰ（Internet Protocol）ネットワーク、公衆電話網、専用線といった広域通信網である。データセンタ１１と、病院１２や診療所１３のそれぞれとを結ぶＷＡＮ１８としては、例えば、情報セキュリティと通信コストのバランスを考慮して、通信事業者が提供するＩＰネットワークやインターネットなどの共有ネットワーク上に専用回線を仮想的に構築するＶＰＮ（Virtual Private Network）が使用される。読影医２１の
携帯端末２２とデータセンタ１１の通信には、例えば、インターネットが使用される。

病院１２のコンピュータシステムは、各クライアント端末１６と、病院ＤＢ（Data Base）サーバ２３とからなり、ルータ２４を介してＷＡＮ１８と接続されている。各クライアント端末１６は、外科や内科といった各診療部門に配置された診療科端末、放射線科や内視鏡科といった各検査部門に配置された管理端末、データセンタ１１にアクセスして、読影センタ１４への依頼情報や画像のデータをアップロードする外部接続用端末といった各種の端末として利用される。

各クライアント端末１６は、病院１２内のＬＡＮ(Local Area Network)２６を介して通信可能に接続されており、各端末１６相互間でメール連絡といった通信を行う。また、クライアント端末１６は、ＬＡＮ２６を介して病院ＤＢサーバ２３と通信を行って、病院ＤＢサーバ２３内のデータにアクセスできるようになっている。また、ＬＡＮ２６には、複数のモダリティ２７が接続されており、各モダリティ２７で撮影された画像は、ＬＡＮ２６を通じて病院ＤＢサーバ２３に送信されて格納される。

病院ＤＢサーバ２３は、例えば、ワークステーションをベースにＤＢＭＳ（Data Base Management System）をインストールして構成される。病院ＤＢサーバ２３は、患者のカルテデータを格納したカルテＤＢ、検査データを格納した検査データＤＢといった各種のＤＢを管理する。検査データには、モダリティ２７で撮影された画像の他、生理検査や検体検査で得られた数値データや心電図などが含まれる。病院ＤＢサーバ２３は、各クライアント端末１６からの要求に応じて、各ＤＢ内へのデータ格納処理、各ＤＢ内のデータ検索処理を実行する。

ルータ２４は、病院１２内のＬＡＮ２６とＷＡＮ１８といった異なるネットワーク間でデータの受け渡しを行う転送機器であり、ＬＡＮ２６と接続するＬＡＮポートと、ＷＡＮ１８と接続するＷＡＮポートを備えている。

データセンタ１１のコンピュータシステムは、アプリケーションサーバ２８、センタＤＢサーバ２９、ルータ３０からなり、これらは、ＬＡＮ３１を介して通信可能に接続されている。ルータ３０は、ルータ２４と同様であり、ＬＡＮ３１とＷＡＮ１８の間でデータ転送を行う。検査予約支援サービスや読影支援サービスは、アプリケーションサーバ２８によって提供される。

センタＤＢサーバ２９は、例えば、病院ＤＢサーバ２３と同様に、ワークステーションにＤＢＭＳをインストールして構成される。センタＤＢサーバ２９は、病院１２や診療所から受信した予約申し込み情報や読影の依頼情報を格納する依頼情報ＤＢ３２、病院１２から受信した読影対象の画像のデータを格納する画像ＤＢ３３、読影センタ１４や携帯端末２２から受信したレポートのデータを格納するレポートＤＢ３４を管理する。センタＤＢサーバ２９は、アプリケーションサーバ２８からの要求に応じて、各ＤＢ内へのデータ格納処理、各ＤＢ内のデータ検索処理を実行する。

図２に示すように、依頼情報ＤＢ３２に格納される読影の依頼情報は、１件の依頼毎に受付ＩＤが与えられて依頼単位で管理される。依頼情報には、依頼元の名称やＩＤ、依頼元が指定した依頼先の名称やＩＤ、依頼文、患者基本情報（患者名、患者ＩＤ、生年月日、年齢、性別）、依頼目的、依頼元が希望する読影医がある場合には、その読影医の名称やＩＤといった複数の項目が含まれる。依頼目的には、例えば、診断に際して注目して読影してもらいたい画像（優先して読影してもらいたい画像）のＩＤや、その画像内の関心領域（部位や病変）に関する項目が含まれる。さらに、緊急の依頼の場合には、その旨を表す緊急指定が依頼情報に含まれる。

画像ＤＢ３３には、読影対象の画像３６のデータが受付ＩＤと対応付けて格納されている。ＣＴ画像やＭＲＩ画像のように複数枚の画像（断層画像）が１組になったボリュームデータが１件の依頼の読影対象となっている場合には、各画像を受付ＩＤに対応する１つのフォルダに格納したり、１組の画像のそれぞれのＩＤと１つの受付ＩＤを対応付けるテーブルデータを作成するといった対応付け処理が行われる。また、各画像のデータには、ＤＩＣＯＭ（Digital Imaging and Communications in Medicine）タグなどの付帯情報が含まれている。依頼情報には、撮影条件などの検査パラメータや、患者名、患者ＩＤ、性別といった患者基本情報が記録されるフィールドが設けられている。

レポートＤＢ３４には、標準レポート３７、簡易レポート３８のデータが格納される。標準レポート３７は、標準的な書式やデータ構造を定めた標準フォーマットで作成されたレポートである。標準フォーマットは、データセンタ１１と、読影センタ１４や病院１２との間で送受信されるレポートのデータに適用される。簡易レポート３８は、簡易的な書式やデータ構造を定めた簡易フォーマットで作成されたレポートである。簡易フォーマットは、携帯端末２２とデータセンタ１１との間で送受信されるレポートのデータに適用される。

簡易フォーマットが適用された簡易レポート３８は、標準フォーマットが適用された標準レポート３７に比べて装飾性等の点で劣るが、データ量は少ない。後述するように、データセンタ１１は、携帯端末２２から送られた簡易レポート３８に対してレポートフォーマット変換をして標準レポート３７を生成し、生成した標準レポート３７を依頼元へ配信する。レポートＤＢ３４には、１件の依頼について作成された、標準レポート３７と簡易レポート３８が受付ＩＤに対応付けて格納される。

図３に示すように、アプリケーションサーバ２８は、ワークステーションやパーソナルコンピュータなどのコンピュータをベースに、オペレーティングシステムや、検査予約支援プログラム（図示せず）、読影支援プログラム４８といったサーバアプリケーションソフトウエアをインストールすることによって構成される。

アプリケーションサーバ２８は、ＣＰＵ４１、メモリ４２、ＨＤＤ（Hard Disk Drive）４３、ＬＡＮポート４４及びコンソール４６を備えており、これらはデータバス４７を介して接続されている。コンソール４６は、ディスプレイと、キーボードやマウスなどの入力デバイスとからなり、アプリケーションサーバ２８の管理や設定を行うために用いられる。

ＨＤＤ４３には、ＣＰＵ４１が実行するオペレーティングシステムや読影支援プログラム４８などの各種のプログラムが格納される。読影支援プログラム４８は、メインプログラムと、後述するアプレットから構成される。

メモリ４２は、ＣＰＵ４１が処理を実行するためのワークメモリである。ＣＰＵ４１は、ＨＤＤ４３に格納されたプログラムをメモリ４２へロードして、プログラムに従った処理を実行することにより、アプリケーションサーバ２８の各部を統括的に制御する。ＬＡＮポート４４は、ＬＡＮ３１との間で伝送制御を行うネットワークインタフェースである。

ＣＰＵ４１は、読影支援プログラム４８を実行することにより、要求処理部４１ａ、画像処理部４１ｂ、レポートフォーマット変換部４１ｃとして機能する。ここで、要求処理部４１ａは、本発明の画像取得手段、配信手段、通知手段に相当する。

図４に示すように、要求処理部４１ａは、読影の依頼元となる病院１２のクライアント端末１６、依頼先となる読影センタ１４の受付サーバ１９及び携帯端末２２からのアクセスを受け付けて、それぞれから発行される要求を処理する。要求処理部４１ａは、クライアント端末１６からの依頼情報と画像３６を取得すると、センタＤＢサーバ２９にアクセスして、それぞれのデータを依頼情報ＤＢ３２、画像ＤＢ３３に格納する。

要求処理部４１ａは、画像ＤＢ３３内の画像３６を配信するための配信サイトのＵＲＬ（Uniform Resource Locator）を、受信した依頼情報に付加して、例えば、メール形式の依頼通知を作成し、依頼先の読影センタ１４の受付サーバ１９に送信する。読影センタ１４のスタッフは、受付サーバ１９に接続された端末を通じて、受付サーバ１９が受信した依頼通知を確認する。スタッフは、依頼通知を確認すると、端末から受付サーバ１９を通じてデータセンタ１１の配信サイトのＵＲＬにアクセスし、要求処理部４１ａに対して読影対象の画像３６の配信要求を発行する。要求処理部４１ａは、受付サーバ１９からの配信要求を受け付けると、画像ＤＢ３３から画像３６を読み出して、要求元である受付サーバ１９に配信する。

緊急の読影依頼の場合には、クライアント端末１６によって依頼情報に緊急指定が付される。読影センタ１４のスタッフは、緊急指定が付された依頼通知（緊急依頼通知）を受けた場合には、読影センタ１４内の読影医のスケジュールを確認して、読影センタ１４内の読影医で対応が可能か否かを判断する。対応が可能な場合には、端末から受付サーバ１９を通じて配信サイトのＵＲＬにアクセスして画像３６をダウンロードする。読影センタ１４のスタッフは、休暇、出張等の理由で依頼元が指定した読影医２１が読影センタ１４に不在であるなど、読影センタ１４内での対応が不可能な場合には、読影センタ１４に不在の読影医２１の携帯端末２２のメールアドレスを付した転送指示を、受付サーバ１９を通じてデータセンタ１１に送信する。

要求処理部４１ａは、受付サーバ１９からの転送指示を受信した場合には、転送指示に含まれるメールアドレス宛に緊急依頼通知を送信する。携帯端末２２宛ての緊急依頼通知に含まれる配信サイトのＵＲＬは、携帯端末向けの配信サイトのＵＲＬに変更される。携帯端末２２に緊急依頼通知が着信すると、読影医２１は、携帯端末２２によって、緊急依頼通知内の携帯端末向けの配信サイトのＵＲＬにアクセスして画像３６をダウンロードする。画像３６を受信すると携帯端末２２を用いた読影が行われる。さらに、携帯端末２２を用いて読影の結果がレポートにまとめられると、簡易フォーマットが適用された簡易レポート３８のデータがデータセンタ１１にアップロードされる。要求処理部４１ａは、携帯端末２２からの簡易レポート３８を受信して、依頼情報の受付ＩＤと対応付けてレポートＤＢ３４に格納する。

また、要求処理部４１ａは、簡易レポート３８を格納した後、レポートフォーマット変換部４１ｃに変換処理を指令する。レポートフォーマット変換部４１ｃは、簡易フォーマットで作成された簡易レポート３８を、標準フォーマットに変換して標準レポート３７を生成し、この標準レポート３７と簡易レポート３８を対応付けてレポートＤＢ３４に格納する。要求処理部４１ａは、簡易レポート３８が格納された後、依頼元の病院１２のクライアント端末１６に対してレポート完了通知を送信する。レポート完了通知には、標準レポート３７の格納先アドレス（ＵＲＬ）が含まれており、クライアント端末１６は、そのＵＲＬにアクセスして、配信要求を発行する。要求処理部４１ａは、クライアント端末１６からの配信要求に応答して簡易レポート３８をクライアント端末１６に配信する。

図５及び図６に示すように、要求処理部４１ａは、ＨＴＴＰに対応した手順で携帯端末２２と通信を行って、携帯端末２２のディスプレイ２２ａで画像３６を表示するための表示画面５６（図７参照）、管理レポート３８を編集するための編集画面６１（図９参照）といった画面を生成するための画面データ５１を配信する。画面データ５１は、ＸＭＬ（Extensible Markup Language）などのＷＷＷ（World Wide Web）に対応したハイパーテキストマークアップ言語でソースコードが記述されたＷｅｂ用のページデータである。

図６に示すように、携帯端末２２には、そのＣＰＵ２２ｂによって実行されるブラウザ２２ｃがインストールされており、ブラウザ２２ｃが、受信した画面データ５１のソースコードを解析して実行することにより、携帯端末２２のディスプレイ２２ａに表示される表示画面５６や編集画面６１を生成する。ブラウザ２２ｃは、例えば、市販の携帯電話などにインストールされる標準的なブラウザである。

ソースコードには、タグやスクリプトといった、ブラウザ２２ｃに対する命令や処理手順を表すコマンド群が含まれている。タグやスクリプトは、各画面５６，６１内の画像表示領域、編集領域、操作ボタンなどのＧＵＩ（graphical user interface）、及びそれらの色、サイズ、レイアウトといった画面構成情報を定義する。

また、ソースコードには、画像３６や依頼情報といった画面データ５１のコンテンツとなるデータへのリンク情報や、アプレットへのリンク情報が記述される。要求処理部４１ａは、依頼元から受信した画像３６の画像ＤＢ３３内の格納先アドレスを、画面データ５１のリンク情報として記述する。ブラウザ２２ｃは、リンク情報に基づいてリンク先のコンテンツの配信要求を要求処理部４１ａに対して発行し、配信されたコンテンツを表示画面５６にレイアウトしてディスプレイ２２ａに表示する。アプレットは、ブラウザ２２ｃによって実行される小型のアプリケーションプログラムであり、必要に応じて要求処理部４１ａから配信される。要求処理部４１ａは、画像３６の表示処理を高速化するための非同期通信プログラムをアプレットの形態で提供する。このアプレットは、例えば、読影支援プログラム４８のメインプログラムとともに、ＨＤＤ４３に格納されている（図３参照）。

図５に示すように、要求処理部４１ａは、携帯端末２２から画像３６の配信要求を受信すると、センタＤＢサーバ２９の画像ＤＢ３３から選択された１枚の画像３６のオリジナルデータを読み出し、画像処理部４１ｂに画像処理を指令する。ここで、オリジナルデータとは、要求処理部４１ａが取得する画像３６の取得元に格納されたデータをいい、本例においては、依頼元から受信して画像ＤＢ３３内に格納された画像３６のデータをいう。

画像処理部４１ｂは、要求処理部４１ａからの指令に応じて、オリジナルデータのデータ量を削減するデータ量削減処理と、オリジナルデータから一部を切り出す切り出し処理を行う。データ量削減処理では、１枚の画像３６の撮影範囲全体（画面全体）のオリジナルデータに対して、データ圧縮処理や画素間引き処理を行ってデータ量を削減して、全体画像５３を生成する。切り出し処理では、画像３６の撮影範囲の一部３６ａをオリジナルデータから切り出して、全体画像５３よりも高解像度の部分画像５４を生成する。１個の部分画像５４は、例えば、切り出しサイズが予め決められており、後述する領域指定がなされたときに、そのサイズで切り出される。

画像処理部４１ｂは、１個の部分画像５４が配信された後、その部分画像５４の周辺の領域の配信要求があった場合には、直前に切り出した部分画像５４と新たに切り出す部分画像５４の境界がオーバラップするように切り出しを行う。これにより、部分画像５４の周辺領域の視認性が向上する。全体画像５３や部分画像５４は、要求処理部４１ａによって携帯端末２２に配信される。

携帯端末２２のディスプレイ２２ａで１枚の画像３６の撮影範囲全体を表示する場合には、全体画像５３が用いられ、画像３６の撮影範囲の一部３６ａを拡大表示する場合には、部分画像５４が用いられる。これにより、撮影範囲全体のオリジナルデータをすべて携帯端末２２にダウンロードして表示処理を行うのに比べて、携帯端末２２が処理するデータ量が減り、携帯端末２２の処理長時が短縮される。

要求処理部４１ａは、全体画像５３や部分画像５４を配信する際に、各画像５３、５４の画面内の位置を特定するための座標データを生成し、これを各画像５３、５４のデータとともに配信する。座標データは、例えば、携帯端末２２のディスプレイ２２ａにおいて部分画像５４を表示していて、次に、その周辺の部分画像５４を表示したり、全体画像５３を表示していて、その一部を部分画像５４として拡大して表示する場合に、周辺領域や拡大領域の位置を特定するためのデータである。ブラウザ２２ｃは、携帯端末２２へ入力される操作指示に従って、読影医２１が望む表示領域を特定する。ブラウザ２２ｃは、特定した領域に対応する座標データを要求処理部４１ａに送信して、特定した領域に対応するデータをダウンロードする。

図７に示す表示画面５６は、要求処理部４１ａが配信する画面データ５１に基づいてブラウザ２２ｃが生成して、ディスプレイ２２ａに表示される。表示画面５６は、患者基本情報や依頼目的を表示する患者情報表示画面５６ａ、読影対象となる複数枚の画像３６のリストを表示する画像リスト画面５６ｂ、全体画像５３を表示する全体表示画面５６ｃ、部分画像５４を表示する詳細表示画面５６ｄの４つの画面からなる。各画面５６ａ〜５６ｄの下部には、操作指示入力用のＧＵＩが表示される。ＧＵＩの選択操作機能は、例えば、携帯端末２２の本体に設けられた操作パネル２２ｄ（図６参照）内のマルチファンクションキー（十字キーなど）や「０」〜「９」のダイヤルボタンに割り当てられる。表示画面５６のＧＵＩには、ディスプレイ２２ａに表示中の１つの画面から他の４つの画面（編集画面６１を含む）のいずれかへ移行する画面切り替えを行うための画面切り替えボタン５７が設けられている。

画面切り替えボタン５７は、患者情報表示画面５６ａへ移行するための患者情報ボタン、画像リスト画面５６ｂへ移行するための画像リストボタン、全体表示画面５６ｃ、詳細表示画面５６ｄのそれぞれへ移行するための全体表示ボタン、詳細表示ボタンの４つのボタンと、表示画面５６から編集画面６１へ移行するための編集ボタンからなる。画面切り替えボタン５７が選択されると、ブラウザ２２ｃは、要求処理部４１ａに対して、選択されたボタンに対応する各画面の画面データ５１の要求を発行し、ダウンロードした画面データ５１によって表示画面５６を生成する。

画面切り替えボタン５７は、それぞれのボタンに対応する画面がディスプレイ２２ａに表示中のときは、その表示中の画面に対応するボタンが非表示となり、他の画面へ移行するための残りの４つのボタンが表示される。例えば、患者情報表示画面５６ａがディスプレイ２２ａに表示されている場合には、患者情報ボタンは表示されず、画面リストボタン、全体表示ボタン、詳細表示ボタン、編集ボタンの４つのボタンが表示される。

このようなＧＵＩを採用することにより、例えば、１つの画面切り替えボタンでサイクリックに複数の画面を切り替える場合と比べて、図において矢印で示すように、どの画面５６ａ〜５６ｄを表示している場合でも、他の画面への移行を簡単かつ迅速に行うことができる。

患者情報表示画面５６ａに表示される情報は、依頼情報ＤＢ３２に格納された依頼情報から取得される。画像リスト画面５６ｂは、画像ＤＢ３３に格納された１件の依頼に対応する複数の画像３６のリストを表示する画面であり、各画像３６に対応する複数の選択ボタン５８が並べて表示される。各選択ボタン５８上には、各画像３６のＩＤやその画像３６の撮影部位（頭部、胸部、腹部など）が表示される。画像３６のＩＤや撮影部位の情報は、各画像３６の付帯情報から読み出される。

また、星印５９は、各画像３６の中で、依頼元が依頼先の読影医２１に対して特に注目して読影してもらいたい画像３６を識別するための識別情報である。この星印５９は。依頼情報内の依頼目的のフィールドに、依頼元が指定した画像ＩＤが記録されている場合に表示される。なお、星印５９は、識別情報の一例であり、マークの形状、選択ボタンの色や明るさなど、識別が可能であれば他の形態でもよい。

画像リスト画面５６ｂから、１つの選択ボタン５８が操作されると、選択された画像３６の配信要求が要求処理部４１ａに送信される。要求処理部４１ａは、配信要求のあった画像３６の全体画像５３を送る。選択された画像３６に対応する全体画像５３がダウンロードされると、ディスプレイ２２ａの表示が全体表示画面５６ｃに自動的に切り替わり、全体画像５３が表示される。

全体表示画面５６ｃにおいて、全体画像５３内の関心領域の拡大表示をするなど、全体画像５３内の一部の領域を指定する領域指定機能は、操作パネル２２ｄのダイヤルボタンに割り当てられている。例えば、「１」〜「９」のダイヤルボタンが「５」を中心として縦横３列のマトリックスで配列されている場合、「５」のダイヤルボタンに、画面の中心を指定する領域指定機能が割り当てられ、その上下左右、斜め方向を指定する領域指定機能が、「５」の周辺の他のダイヤルボタンに割り当てられる。例えば、「５」を押下すると、全体画像５３の画面内の中央領域が指定され、「５」の真上のボタンが「２」である場合には、「２」を押下すると、中央領域の上方部分が指定される。同様に、「５」の周辺のダイヤルボタンを押下することで、上下左右、斜め方向が指定される。

ダイヤルボタンによって全体画像５３内の領域指定がなされると、ブラウザ２２ｃは、その領域に対応する部分画像５４の配信要求を要求処理部４１ａに対して発行する。この配信要求には、指定された領域の座標データが含まれているので、要求処理部４１ａは、その座標データに基づいて指定された領域を特定して、画像処理部４２ｂにオリジナルデータから対応する領域を切り出させて部分画像５４を生成させて配信する。部分画像５４が配信されると、ディスプレイ２２ａの表示が、全体表示画面５６ｃから詳細表示画面５６ｄへ自動的に切り替わり、部分画像５４が表示される。

詳細表示画面５６ｄにおいては、ダイヤルボタンには、表示中の部分画像５４の上下左右、斜め方向の周辺の領域を指定するための周辺指定機能が割り当てられる。ダイヤルボタン押下により周辺指定がされると、ブラウザ２２ｃは、指定された方向の周辺の画像の配信要求（座標データを含む）を発行し、要求処理部４１ａは、それに応答して対応する部分画像５４を配信する。

図８に示すように、部分画像５４は、例えば、ディスプレイ２２ａの画面サイズよりも大きなサイズで切り出される。ブラウザ２２ｃは、受信した部分画像５４の全領域を表示用メモリに描画しておき、描画部分の中からディスプレイ２２ａの画面サイズに見合うサイズの領域を表示させるという、いわゆる仮想画面技術を用いて部分画像５４を表示する。これによれば、ダイヤルボタンによって周辺指定がなされた場合に、すでに表示用メモリに描画済みの部分については、要求処理部４１ａへの配信要求を発行することなく、描画済み部分のスクロール処理で対応できるので、部分画像５４の迅速な表示が可能である。

また、ブラウザ２２ｃは、ダイヤルボタンを通じて周辺指定が入力された場合、その指定方向の周辺画像を予測して、要求処理部４１ａに対して配信要求を発行する。この処理は、ブラウザ２２ｃが画面データ５１に記述されたアプレット（非同期通信プログラム）を実行することにより行われる。非同期通信プログラムとしては、例えば、Ａｊａｘ（Asynchronous JavaScript（登録商標） + XML）が使用される。

非同期通信プログラムの処理は、以下の通りである。例えば、図８のように、画像３６の中央部分の部分画像５４が表示されている場合に、ダイヤルボタンによって斜め左下方向の周辺指定が入力されたとする。このとき、ブラウザ２２ｃは、まず、表示用メモリに描画済み部分のスクロール処理によって、ディスプレイ２２ａに表示される部分画像５４の領域を斜め左下方向に移動させる。

ここで、さらに、ダイヤルボタンによって斜め左下方向の周辺指定がなされた場合には、ブラウザ２２ｃは、その操作指示入力を受け付けて、周辺画像６０に対応する部分画像５４の配信要求を要求処理部４１ａに対して発行する。一方、さらなる周辺指定が無い場合でも、ブラウザ２２ｃは、非同期通信プログラムによって、その操作指示入力を予測して、周辺画像６０の部分画像５４の配信要求を発行する。このように、操作指示入力と非同期で要求処理部４１ａと通信して、ディスプレイ２２ａの表示が予測される部分画像５４を先読みしてダウンロードすることで、部分画像５４のさらに迅速な表示が可能となる。

また、全体表示画面５６ｃ、詳細表示画面５６ｄのいずれにおいても、表示されている画像の電子ズーム処理が可能である。電子ズーム処理の操作機能は、操作パネル２２ｄ内の十字キーなどに割り当てられる。

図９に示す編集画面６１も、表示画面５６と同様に画面データ５１によって生成される。編集画面６１は、簡易レポート３８を作成するためのものであり、編集画面６１には、テキストを入力するための編集領域６１ａが設けられる。編集領域６１ａの下方には、切り替えボタン６１ｂと終了ボタン６１ｃからなるＧＵＩが設けられている。

切り替えボタン６１ｂは、編集領域６１ａを編集画面６１内に単独で表示する単独表示モード（図９下段参照）と、編集画面６１内に編集領域６１ａと画像表示領域６１ｄとを並べて表示する並列表示モードとからなる２つの表示モードを切り替える操作ボタンである。画像表示領域６１ｄには、全体画像５３や部分画像５４が表示される。単独表示モードと並列表示モードを切り替えられるようにしたことで、画像を確認しながら文章を入力したい場合には並列表示モードを使用し、文章の推敲をする場合には単独表示モードを使用するというような使い分けが可能となり、レポート編集作業を効率化できる。

画像表示領域６１ｄには、例えば、編集画面６１に移行する直前に全体表示画面５６ｃ又は詳細表示画面５６ｄにおいて表示した全体画像５３又は部分画像５４が表示される。もちろん、編集画面６１のＧＵＩに、全体画像５３と部分画像５４を切り替える画像切り替えボタンを設け、画像表示領域６１ｄで表示する画像を切り替えられるようにしてもよい。終了ボタン６１ｃは、レポートの編集を終了する際に選択されるボタンであり、この終了ボタン６１ｃが選択されると、編集画面６１が表示される直前の表示画面５６に復帰する。

以下、上記構成による作用について、図１０に示すフローチャートに基づいて説明する。病院１２のクライアント端末１６から緊急の読影依頼が発行されると、アプリケーションサーバ２８は、依頼情報とアップロードされた画像３６のデータを受信して、依頼情報ＤＢ３２、画像ＤＢ３３にそれぞれ格納する。アプリケーションサーバ２８は、図４に示すように、緊急依頼通知を読影センタ１４に送信する。読影センタ１４で対応できない場合には、読影センタ１４からアプリケーションサーバ２８へ転送指示が送られる。アプリケーションサーバ２８では、読影センタ１４から転送指示を受信すると、携帯端末２２へ緊急依頼通知を転送する。

読影医２１は、携帯端末２２で緊急依頼通知を受信すると、その通知に含まれるＵＲＬに基づいて、アプリケーションサーバ２８の配信サイトにアクセスする。アプリケーションサーバ２８は、携帯端末２２からの配信要求に応答して、画面データ５１、全体画像５３、及び部分画像５４を配信する。携帯端末２２は、ブラウザ２２ｃによって画面データ５１を解析して、表示画面５６や編集画面６１を生成し、ディスプレイ２２ａに表示する。

患者情報表示画面５６ａには、患者基本情報や依頼目的が表示され、画像リスト画面５６ｂには、読影対象の画像リストが表示される。画像リスト画面５６ｂには、依頼元が依頼先の読影医２１に対して優先して読影してもらいたい画像３６を識別するための星印５９が表示されるので、依頼情報を詳細に確認することなく、読影医２１が依頼元の意向を簡単明瞭に把握することができる。画像リスト画面５６ｂから１つの画像３６が選択されると、携帯端末２２からアプリケーションサーバ２８に対して選択された画像３６の配信要求が発行される。

アプリケーションサーバ２８は、図５に示すように、携帯端末２２によって選択された画像３６のオリジナルデータを画像ＤＢ３３から読み出して、画像処理部４１ｂによってデータ量削減処理を施して全体画像５３を生成し、要求処理部４１ａが全体画像５３を携帯端末２２に配信する。携帯端末２２は、全体画像５３を受信すると全体表示画面５６ｃに全体画像５３をレイアウトしてディスプレイ２２ａに表示する。全体画像５３は、オリジナルデータに比べてデータ量が削減されているから、通信時間が短く、携帯端末２２が実行する表示処理に掛かる時間も短い。また、処理の負荷が少なく、省電力化にも寄与する。

携帯端末２２において、全体表示画面５６ｃを表示中に、操作パネル２２ｄから領域指定がなされると、ブラウザ２２ｃによって指定された領域に対応する部分画像５４の配信要求が発行される。アプリケーションサーバ２８は、要求処理部４１ａが配信要求に含まれる座標データによって領域を特定し、画像処理部４１ｂがその部分に対応するデータをオリジナルデータから切り出して部分画像５４を生成する。要求処理部４１ａによって部分画像５４が携帯端末２２へ配信される。

携帯端末２２は、受信した部分画像５４を詳細表示画面５６ｄにレイアウトしてディスプレイ２２ａに表示する。部分画像５４は、画像３６のオリジナルデータの一部であるので、画像３６の１枚分のオリジナルデータに比べてデータ量は少ない。そのため、通信時間が短く、携帯端末２２における表示処理の時間も短い。しかも、部分画像５４は、オリジナルデータから切り出されたものであるから、データ量を削減した全体画像５３よりも解像度が高い。そのため、細部を詳細に読影することができ、病変の陰影などを明瞭に確認できる。

携帯端末２２は、詳細表示画面５６ｄをディスプレイ２２ａで表示中に、操作パネル２２ｄから周辺指定がなされると、その指定方向に従って部分画像５４のスクロール処理を行う。周辺指定がなされた場合、携帯端末２２は、非同期通信プログラムによって、指定方向に応じて、次に表示されると予測される周辺画像６０をアプリケーションサーバ２８から取得する。このため、部分画像５４の表示処理時間が短縮される。

読影作業においては、このような全体表示画面５６ｃや詳細表示画面５６ｄの画面切り替えや拡大表示を行いながら、画像３６の全体や部分が確認される。画像３６が複数枚ある場合には、各画像３６について同様の作業が行われる。アプリケーションサーバ２８は、全体画像５３のデータ量を削減し、部分画像５４については、オリジナルデータから部分的にデータを切り出して、配信する。このため、携帯端末２２における表示処理に掛かる負荷が軽減されるので、比較的処理能力が低い安価な端末を用いて、支障なく読影を行うことができる。また、部分画像５４は全体画像５３よりも解像度が高いため、細部の確認にも支障が生じることはない。

読影の結果は、編集画面６１においてテキストを入力して簡易レポート３８にまとめられる。編集画面６１では、画像確認や文書推敲のそれぞれの場面に応じて単独表示モードと並列表示モードを使い分けることができるので、レポート編集の作業効率がよい。簡易レポートの編集が完了すると、簡易フォーマットで簡易レポート３８のデータが作成される。携帯端末２２は、アプリケーションサーバ２８に簡易レポート３８をアップロードする。

アプリケーションサーバ２８は、レポートフォーマット変換部４１ｃによって、受信した簡易レポート３８を標準フォーマットの標準レポート３７にフォーマット変換する。簡易レポート３８と標準レポート３７は対応付けられてレポートＤＢ３４に格納される。アプリケーションサーバ２８は、標準レポート３７、３８を格納すると、病院１２のクライアント端末１６にレポート完了通知を送信する。

クライアント端末１６は、レポート完了通知を受信すると、その通知に含まれるＵＲＬに基づいてアプリケーションサーバ２８にアクセスして、標準レポート３７をダウンロードする。フォーマット変換により、クライアント端末１６は、標準フォーマットの標準レポート３７を受信できるので、他のレポートのデータと同様の取り扱いが可能となる。そのため、例えば、読影の依頼元において、携帯端末２２で作成された管理レポート３８を表示するための専用のアプリケーションが必要になるなど、業務の煩雑化や新たなコスト負担の要因が生じることもない。

上記実施形態では、本発明の第１画像を、読影対象の画像の撮影範囲全体を表示する全体画像とし、それに対してデータ量削減処理を施して配信し、本発明の第２画像を、撮影範囲の一部を表示する部分画像とし、それに対してはデータ量削減処理を施さずに、オリジナルデータから切り出したデータをそのまま配信する例で説明したが、第１画像及び第２画像は、本例に限定されない。例えば、第１画像は、全体画像でなくてもよく、第２画像よりも相対的に広い撮影範囲であればよい。また、第２画像は、オリジナルデータをそのまま使用するのではなく、第１画像よりも高い解像度を確保できる範囲で、データ量削減処理を施してもよい。

また、図１１のフローチャートに示すように、アプリケーションサーバが、携帯端末が発行する機種情報に基づいて、データ量削減処理において行う全体画像のデータの削減率、切り出し処理が行う部分画像の切り出しサイズといった画像処理条件を決定してもよい。携帯端末によってディスプレイの画面サイズが異なるとともに、表示処理の能力も異なることが考えられる。表示性能が比較的高く、ディスプレイの画面サイズが比較的大きい携帯端末に対しては、削減率を小さくした全体画像、切り出しサイズを大きくした部分画像を配信し、反対に、表示性能が比較的低く、ディスプレイの画面サイズが比較的小さい携帯端末に対しては、削減率を大きくした全体画像、切り出しサイズを大きくした部分画像を配信するというように、携帯端末の機種に応じて適切な削減率や切り出しサイズを決定すれば、それぞれの携帯端末の性能を十分に使い切ることができる。

上記実施形態の表示画面や編集画面は１例であり、ＧＵＩの内容、操作パネルへの機能の割り当て方等、適宜変更可能である。例えば、領域指定や周辺指定の機能を操作パネルに割り当てているが、ＧＵＩに領域指定や周辺指定を行うための方向指定ボタンを設けてもよい。

上記実施形態では、携帯端末を携帯電話の例で説明したが、ＰＤＡ（Personal Digital Assistant）などの携帯端末でもよい。

上記実施形態では、読影センタにおいて、緊急依頼通知の携帯端末への転送指示を発行するか否かの判断を読影センタのスタッフがマニュアルで行うようにしているが、その判断を受付サーバが行ってもよい。その場合には、例えば、受付サーバに、読影医のスケジュールデータを格納しておき、受付サーバが、緊急依頼通知を受信したときに、スケジュールデータを参照して、転送指示が必要か否かを判定し、必要な場合には、読影医の携帯端末のメールアドレスを付した転送指示をデータセンタに対して送信する。

また、緊急依頼通知に緊急指定が付されていない場合でも、例えば、依頼元が指定した読影医が読影センタに不在の場合に、指定された読影医の携帯端末へ転送指示を発行してもよい。さらに、データセンタのアプリケーションサーバで読影医のスケジュールデータを管理して、アプリケーションサーバが携帯端末へ転送するか否かを判定してもよい。また、この場合、アプリケーションサーバでスケジュールデータを管理しなくてもよく、例えば、読影センタの受付サーバにスケジュールデータを格納しておき、アプリケーションサーバがＷＡＮ経由でオンラインアクセスしてスケジュールデータを取得してもよい。

上記実施形態では、携帯端末へ画像を配信するアプリケーションサーバをデータセンタに設置した例で説明したが、読影センタにアプリケーションサーバを設置して、病院や診療所からの読影依頼を直接受け付けるようにしてもよい。

また、上記実施形態では、本発明の医用ネットワークシステムを、読影の依頼元となる複数の医療施設のコンピュータシステムと、依頼元から依頼先へ依頼情報や読影対象の画像を配信するデータセンタのコンピュータシステムとからなる形態で説明したが、他の形態にも適用可能である。例えば、１つの病院に複数の拠点があり、それぞれの拠点が、依頼元、依頼先、データセンタとしての役割を担い、各拠点の複数のコンピュータシステムをネットワークで接続した医用ネットワークシステムとしてもよい。また、複数の病院のそれぞれのコンピュータシステムをネットワークで接続した医用ネットワークシステムでもよい。この場合、いずれかの病院がデータセンタとなりホスト的な役割を担う。上記いずれの場合でも、各コンピュータシステム間を接続するネットワークはＷＡＮでもＬＡＮでもよい。

本発明の読影支援装置は、アプリケーションサーバのように１台のサーバからなるコンピュータシステムで構成してもよいし、複数台のサーバに処理を分散させるコンピュータシステムとして構成してもよい。

なお、上記実施形態で示したとおり、本発明は、プログラムの形態、さらにはプログラムを記憶する記憶媒体にも及ぶことはもちろんである。

医用ネットワークシステムの概略を示す構成図である。 センタＤＢサーバ内の各ＤＢに格納されるデータの説明図である。 アプリケーションサーバの概略構成図である。 要求処理部の処理の流れを示す説明図である。 要求処理部及び画像処理部の処理の流れを示す説明図である。 画面データの説明図である。 画面データによって生成される表示画面の説明図である。 部分画像表示処理の説明図である。 画面データによって生成される編集画面の説明図である。 読影の依頼及びレポート作成手順を示すフローチャートである。 機種情報に基づいて画像処理条件を決定する場合のフローチャートである。

符号の説明

１０ 医用ネットワークシステム
１１ データセンタ
１２ 病院
１３ 診療所
１４ 読影センタ
１６ クライアント端末（病院）
１７ クライアント端末（診療所）
１８ ＷＡＮ
１９ 受付サーバ
２２ 携帯端末
２８ アプリケーションサーバ
２９ センタＤＢサーバ
３６ 画像
３７ 標準レポート
３８ 簡易レポート
４１ ＣＰＵ
４１ａ 要求処理部
４１ｂ 画像処理部
４１ｃ レポートフォーマット変換部
４８ 読影支援プログラム
５１ 画面データ
５３ 全体画像
５４ 部分画像
５６ 表示画面
５６ａ 患者情報表示画面
５６ｂ 画像リスト表示画面
５６ｃ 全体表示画面
５６ｄ 詳細表示画面
５９ 星印
６１ 編集画面
６１ａ 編集領域
６１ｄ 画像表示領域

Claims (15)

1. ネットワークを介して携帯端末へ医用画像を配信して前記医用画像の読影を支援する読影支援装置において、
   前記医用画像のデータを取得する画像取得手段と、
   前記データのデータ量を削減して、第１画像を生成するデータ量削減手段と、
   前記第１画像の撮影範囲の一部を前記データから切り出して、前記第1画像よりも高解像度の第２画像を生成する画像切り出し手段と、
   前記第１画像と前記第２画像を前記携帯端末へ配信する配信手段とを備えたことを特徴とする読影支援装置。
2. 前記第１画像の撮影範囲は、１枚の前記医用画像の全体であることを特徴とする請求項１記載の読影支援装置。
3. 前記配信手段は、前記画像取得手段で取得した複数枚の前記医用画像のリストを前記携帯端末に配信して、前記携帯端末において前記リストから選択された前記医用画像に対応する前記第１画像を配信することを特徴とする請求項１又は２記載の読影支援装置。
4. 前記リストには、読影を依頼する依頼元が優先して読影してほしい前記医用画像を、他の前記医用画像と識別するための識別情報が付されることを特徴とする請求項３記載の読影支援装置。
5. 前記配信手段は、前記第１画像、前記第２画像、及び前記リストのうち少なくとも１つを、前記携帯端末のディスプレイに表示させるための表示画面データを前記携帯端末に配信することを特徴とする請求項３又は４記載の読影支援装置。
6. 前記表示画面データには、前記携帯端末で実行され、前記携帯端末への操作指示入力と非同期で前記第２画像の配信要求を発行するための非同期通信プログラムが含まれることを特徴とする請求項５記載の読影支援装置。
7. 前記非同期通信プログラムは、前記携帯端末のディスプレイで表示されている前記第２画像の周辺の画像の配信要求を発行することを特徴とする請求項６記載の読影支援装置。
8. 前記配信手段は、前記携帯端末のディスプレイに医用レポートの編集画面を表示させるための編集画面データを前記携帯端末に配信することを特徴とする請求項１〜７いずれか記載の読影支援装置。
9. 前記編集画面で入力された前記医用レポートのデータを前記携帯端末から受信して、前記医用レポートのデータを所定のレポートフォーマットに変換するフォーマット変換手段を備えたことを特徴とする請求項８記載の読影支援装置。
10. 前記編集画面は、テキストを入力する編集領域と、前記第１画像又は第２画像とを並べて表示可能であることを特徴とする請求項８又は９記載の読影支援装置。
11. 前記編集画面には、前記編集領域を、前記第１画像又は第２画像と並べて表示する並列表示モードと、前記編集領域を単独で表示させる単独表示モードとを切り替えるユーザインタフェースが設けられていることを特徴とする請求項１０記載の読影支援装置。
12. ネットワークを介して携帯端末へ医用画像を配信して前記医用画像の読影を支援する読影支援方法において、
    前記医用画像のデータを取得する画像取得ステップと、
    前記データのデータ量を削減して、第１画像を生成するデータ量削減ステップと、
    前記第１画像の撮影範囲の一部を前記データから切り出して、前記第1画像よりも高解像度の第２画像を生成する画像切り出しステップと、
    前記第１画像と前記第２画像を前記携帯端末へ配信する配信ステップとを備えたことを特徴とする読影支援方法。
13. 医用画像の読影を依頼する依頼元の第１コンピュータシステムと、前記第１コンピュータシステムとネットワークを介して通信可能に接続され、前記第１コンピュータシステムから受信した前記医用画像を携帯端末に配信する第２コンピュータシステムとからなる医用ネットワークシステムにおいて、
    前記第２コンピュータシステムは、前記医用画像のデータを前記第１コンピュータシステムから取得する画像取得手段と、
    前記データのデータ量を削減して、第１画像を生成するデータ量削減手段と、
    前記第１画像の撮影範囲の一部を前記データから切り出して、前記第1画像よりも高解像度の第２画像を生成する画像切り出し手段と、
    前記第１画像と前記第２画像を前記携帯端末へ配信する配信手段と、
    を備えたことを特徴とする医用ネットワークシステム。
14. 前記第２コンピュータシステムは、前記第１コンピュータシステムから受信した前記読影の依頼情報を前記携帯端末へ通知する通知手段を備えたことを特徴とする請求項１３記載の医用ネットワークシステム。
15. 前記通知手段は、前記携帯端末へ前記依頼情報を通知する前に、前記携帯端末とは異なる依頼先へ前記依頼情報を通知し、前記依頼先からの応答結果に基づいて前記携帯端末へ前記依頼情報を通知することを特徴とする請求項１４記載の医用ネットワークシステム。

Images