(57)【要約】      （修正有）【課題】画像ファイルが保存された時に、当該画像とともに後から利用される可能性の高い画像ファイルを特定する。【解決手段】クライアント端末から受信した電子ファイルを第１のストレージおよび第２のストレージの双方に保管する情報処理装置であって、受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得手段と、取得した関連情報により特定される電子ファイルに関連する電子ファイルを特定する関連ファイル特定手段と、特定された電子ファイルが第１のストレージに保管されているかを保管状態管理手段で記憶された保管状態に基づいて判定する保管状態判定手段と、保管状態判定手段により特定された電子ファイルが第１のストレージに保管されていない場合、第２のストレージから第１のストレージに当該特定された電子ファイルを複製する複製手段と、を有する。【選択図】図１
2019049988.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末から受信した電子ファイルを第１のストレージおよび第２のストレージの双方に保管する情報処理装置であって、
前記電子ファイルの保管状態を管理する保管状態管理手段と、
前記第１のストレージに保管された前記電子ファイルを定期的に削除する削除手段と、
前記受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得手段と、
前記電子ファイルを受信した場合に前記取得した関連情報により特定される前記電子ファイルに関連する電子ファイルを特定する関連ファイル特定手段と、
前記関連ファイル特定手段により特定された電子ファイルが前記第１のストレージに保管されているかを前記保管状態管理手段で記憶された保管状態に基づいて判定する保管状態判定手段と、を有し、
前記保管状態判定手段により前記特定された電子ファイルが前記第１のストレージに保管されていない場合、前記第２のストレージから前記第１のストレージに当該特定された電子ファイルを複製する複製手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記電子ファイルは読影を行うための医療画像であって、
前記関連キーは、前記読影の対象となる患者の過去の医療画像を関連する電子ファイルとして特定可能な項目であることを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記関連キーは、前記読影の対象となる医療画像と同一の部位の医療画像を関連する電子ファイルとして特定可能な項目であることを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記関連キーは、前記読影の対象となる医療画像を取得した検査種別と同一の検査種別の医療画像を関連する電子ファイルとして特定可能な項目であることを特徴とする請求項２または３のいずれか１項に記載の情報処理装置。
【請求項５】
読影診断を行うのに参考になった電子ファイルを受付ける参考画像受付手段を更に有し、
前記削除手段は、当該参考画像として受付けた電子ファイルが前記削除手段による削除対象の電子ファイルであったとしても削除対象外とすることを特徴とする請求項１乃至４のいずれか1項に記載の情報処理装置。
【請求項６】
前記保管状態管理手段は、前記削除手段により削除された電子ファイルの前記第１のストレージに対する保管状態をｎｕｌｌとすることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項７】
クライアント端末と当該クライアント端末から受信した電子ファイルを第１のストレージおよび第２のストレージの双方に保管する情報処理装置とからなる情報処理システムであって、
前記電子ファイルの保管状態を管理する保管状態管理手段と、
前記第１のストレージに保管された前記電子ファイルを所定のタイミングで削除する削除手段と、
前記受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得手段と、
前記電子ファイルを受信した場合前記取得した関連情報により特定される前記電子ファイルに関連する電子ファイルを特定する関連ファイル特定手段と、
前記関連ファイル特定手段により特定された電子ファイルが前記第１のストレージに保管されているかを前記保管状態管理手段に記憶された保管状態に基づいて判定する保管状態判定手段と、を有し、
前記保管状態判定手段により前記特定された電子ファイルが前記第１のストレージに保管されていない場合、前記第２のストレージから前記第１のストレージに当該特定された電子ファイルを複製する複製手段と、
を有することを特徴とする情報処理システム。
【請求項８】
クライアント端末から受信した電子ファイルを第１のストレージおよび第２のストレージの双方に保管する情報処理装置の制御方法であって、
前記電子ファイルの保管状態を管理する保管状態管理ステップと、
前記第１のストレージに保管された前記電子ファイルを所定のタイミングで削除する削除ステップと、
前記受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得ステップと、
前記電子ファイルを受信した場合前記取得した関連情報により特定される前記電子ファイルに関連する電子ファイルを特定する関連ファイル特定ステップと、
前記関連ファイル特定ステップにより特定された電子ファイルが前記第１のストレージに保管されているかを前記保管状態管理ステップで記憶された保管状態に基づいて判定する保管状態判定ステップと、を有し、
前記保管状態判定ステップにより前記特定された電子ファイルが前記第１のストレージに保管されていない場合、前記第２のストレージから前記第１のストレージに当該特定された電子ファイルを複製する複製ステップと、
を有することを特徴とする情報処理装置の制御方法。
【請求項９】
クライアント端末から受信した電子ファイルを第１のストレージおよび第２のストレージの双方に保管する情報処理装置で読み取り可能なプログラムであって、
前記情報処理装置を、
前記電子ファイルの保管状態を管理する保管状態管理手段と、
前記第１のストレージに保管された前記電子ファイルを所定のタイミングで削除する削除手段と、
前記受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得手段と、
前記電子ファイルを受信した場合前記取得した関連情報により特定される前記電子ファイルに関連する電子ファイルを特定する関連ファイル特定手段と、
前記関連ファイル特定手段により特定された電子ファイルが前記第１のストレージに保管されているかを前記保管状態管理手段で記憶された保管状態に基づいて判定する保管状態判定手段と、を有し、
前記保管状態判定手段により前記特定された電子ファイルが前記第１のストレージに保管されていない場合、前記第２のストレージから前記第１のストレージに当該特定された電子ファイルを複製する複製手段と、
を有することを特徴とする情報処理装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理システム、情報処理方法、およびプログラムに関する。
【背景技術】
【０００２】
近年、インターネットを利用したパブリックなストレージサービスが提供されるようになり、大量のデータを安価に保管できるようになった。しかしながら大量のデータのやり取りには回線の速度などの問題により時間がかかってしまう場合がある。
【０００３】
これに対して回線の速度や品質を保証するようなストレージサービスも存在しているが、利用料金がパブリックなストレージサービスよりも高価な場合が多いという問題があった。
【０００４】
特許文献１では、利用者にとってよく利用される情報であるキャッシュ記憶手段と実体を記憶するデータ記憶手段を有していて、アクセス要求を受け付けると当該要求と関連する情報をキャッシュ記憶手段に記憶する技術が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１８７３９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
患者の主治医から出された依頼（患者の主訴や病歴・家族歴など）をもとに、適正な検査（ＣＴ、ＭＲＩ、血管造影など）を判断し、その検査画像から画像診断を行い、今後さらに必要になると思われる検査や治療方針の助言を行う読影システムにおいては、大量の検査画像を扱うので、システムで取り扱う検査画像は、パブリックなストレージサービスに保管することが多い。そして、最近読影を依頼された検査画像は、速度の速いストレージサービスを利用することが行われている。
【０００７】
読影システムでは、読影医が検査画像を見ながら診断を行うのであるが、同じ症例や似た部位の検査画像を見ることがある。この場合、見たい画像が速度の遅いパブリックなストレージサービスに保管されているとファイルの読み出しに時間がかかってしまうので、事前に速度の速いストレージシステムに保存（転送）しておきたいという要望がある。
【０００８】
しかしながら特許文献１の発明では、関連する情報をルールとして定義されたものを使って検索している。しかしながら、読影システムの場合、患者の症例によって関連する情報を一意に決定することは難しい。例えば、同じ患者の過去の画像があれば、過去の画像を見たい場合もあるし、患者と同年代の患者の画像を見たい場合もあるので、あらかじめ決まったルールに基づいてルールを設定することは難しい。
【０００９】
また、特許文献１においては、検索された時に関連する情報を検索するようにしているが、検索した時に関連する画像を検索するのは遅い場合があり、検査画像が読影システムに保管された時に、読影医によって要求されるであろう関連画像をキャッシュしておくことが望ましい。
【００１０】
そこで本発明は、画像ファイルが保存された時に、当該画像とともに後から利用される可能性の高い画像ファイルを特定可能な情報処理装置を提供することを課題とする。
【課題を解決するための手段】
【００１１】
クライアント端末から受信した電子ファイルを第１のストレージおよび第２のストレージの双方に保管する情報処理装置であって、前記電子ファイルの保管状態を管理する保管状態管理手段と、前記第１のストレージに保管された前記電子ファイルを定期的に削除する削除手段と、前記受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得手段と、前記電子ファイルを受信した場合に前記取得した関連情報により特定される前記電子ファイルに関連する電子ファイルを特定する関連ファイル特定手段と、前記関連ファイル特定手段により特定された電子ファイルが前記第１のストレージに保管されているかを前記保管状態管理手段で記憶された保管状態に基づいて判定する保管状態判定手段と、を有し、前記保管状態判定手段により前記特定された電子ファイルが前記第１のストレージに保管されていない場合、前記第２のストレージから前記第１のストレージに当該特定された電子ファイルを複製する複製手段と、を有する。
【発明の効果】
【００１２】
本発明によれば、画像ファイルが保存された時に、当該画像とともに後から利用される可能性の高い画像ファイルを特定可能な情報処理装置を提供することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態に係わる読影システムのシステム構成図の一例を示す図である。
【図２】本発明の実施形態に係わるアプリケーションサーバである情報処理装置のハードウェア構成の一例を示すブロック図である。
【図３】本発明の実施形態に係わる読影システムのクライアント端末の読影依頼画面の一例を示す図である。
【図４】本発明の実施形態に係わる読影システムのクライアント端末の読影画面の一例を示す図である。
【図５】本発明の実施形態に係わる読影システムの画像ファイル登録時の処理の一例を示すフローチャートである。
【図６】本発明の実施形態に係わる読影システムの画像ファイル取得時の処理の一例を示すフローチャートである。
【図７】本発明の実施形態に係わる情報処理装置のキャッシュアウト処理の一例を示すフローチャートである。
【図８】本発明の実施形態に係わる読影システムのファイルマスＤＢの一例を示す図である。
【図９】本発明の実施形態に係わる読影システムの各種ユーザマスタテーブルの一例を示す図ある。
【発明を実施するための形態】
【００１４】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１５】
図１は、本発明の実施形態に係わる読影システムのシステム構成図の一例を示す図である。
【００１６】
本発明に係る読影システム（情報処理システム）は、クライアント端末１００、アプリケーションサーバ１０１、および外部サーバ１０２が通信ネットワーク５００を介して通信可能に接続されている。
【００１７】
読影システムとは、患者の主治医から出された依頼（患者の主訴や病歴・家族歴など）をもとに、読影医が検査や治療方針の助言を行うものであり、クライアント端末１００は、読影の依頼元である患者の主治医や、読影を行う読影医により利用される。利用者ＩＤにより利用できるメニューが異なる。
【００１８】
例えば、依頼元のクライアント端末１００からは、アプリケーションサーバ１０１に対して、医療画像や患者情報などを付与して読影の依頼を行う。読影医のクライアント端末は、アプリケーションサーバ１０１から、依頼された読影に関するデータを読み出したり、参考情報として他の患者の画像データ（電子ファイル）を要求したりする。アプリケーションサーバ１０１ではＷＥＢアプリケーションとして稼働しており、ブラウザを利用して読影システムにアクセス可能になっている。
【００１９】
アプリケーションサーバ１０１は、読影システムが稼働しているサーバであってローカルキャッシュ１１１、ＤＢＭＳ１１２、ｃｒｏｎ１１３、ローカルキャッシュ管理部１１４、データ検索部１１５、および外部サーバ通信部１１６を有する。
【００２０】
外部サーバ１０２は、例えばクラウドを利用したストレージサービスなどを指す。外部サーバは複数利用することが可能となっている。本実施例の読影システムでは、依頼元のクライアント端末１００から依頼されたデータが一旦アプリケーションサーバ１０１のローカルキャッシュ１１１と、外部サーバ１０２に保管される。ローカルキャッシュ１１１は、アプリケーションサーバのローカルディスクであったり、別途契約する信頼性が高かったり、通信速度が速かったりするストレージを指す。また、ローカルキャッシュ１１１のデータはｃｒｏｎ１１３を利用し、定期的に古いデータが削除されるものである（これをキャッシュアウトと呼ぶ）。
【００２１】
本実施例では、外部サーバ１０２のように全てのデータは永続的に保管し、必要な時にデータを読み出すストレージサービスを外部ストレージと呼び、アプリケーションサーバ１０１が通常使うストレージサービスをローカルキャッシュと呼ぶ。
【００２２】
またローカルキャッシュには、依頼元１００から読影の依頼データから関連キーを取得し、関連キーに合致するデータをデータ検索部１１５が検索し、外部サーバ１０２にだけ保管されている場合（ローカルキャッシュ１１１からは削除済み）は、外部サーバ通信部１１６によって、該当する外部サーバ１０２からローカルキャッシュ１１１に関連画像を読み込んでおく（これをキャッシュインと呼ぶ）。
【００２３】
ＤＢＭＳ１１２には、ファイルマスタＤＢ（図８）、依頼元マスタ、読影医マスタ、および患者マスタ（図９）が記憶されており、アプリケーションサーバは、これらテーブルを利用して必要な情報を画面に表示したり、依頼や回答などの電文に付与したりするのに利用する。
【００２４】
図２は、本発明の実施形態に係わるアプリケーションサーバである情報処理装置のハードウェア構成の一例を示すブロック図である。
【００２５】
図２に示すように、情報処理装置１０１では、システムバス２００を介してＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０２、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０３、記憶装置２０４、入力コントローラ２０５、音声入力コントローラ２０６、ビデオコントローラ２０７、メモリコントローラ２０８、よび通信Ｉ／Ｆコントローラ２０９が接続される。
【００２６】
ＣＰＵ２０１は、システムバス２００に接続される各デバイスやコントローラを統括的に制御する。
【００２７】
ＲＯＭ２０２あるいは記憶装置２０４は、ＣＰＵ２０１が実行する制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や、本情報処理方法を実現するためのコンピュータ読み取り実行可能なプログラムおよび必要な各種データ（データテーブルを含む）を保持している。
【００２８】
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは記憶装置２０４からＲＡＭ２０３にロードし、ロードしたプログラムを実行することで各種動作を実現する。
【００２９】
入力コントローラ２０５は、キーボード／タッチパネル２１０などの入力装置からの入力を制御する。入力装置はこれに限ったものでなく、マウスやマルチタッチスクリーンなどの、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。
【００３０】
ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下（指等でタッチ）することにより、各種の指示を行うことができる。
【００３１】
この入力装置を用いて各種通信装置で利用可能な通信宛先に対する宛先を入力するようになっている。
【００３２】
音声入力コントローラ２０６は、マイク２１１からの入力を制御する。マイク２１１から入力された音声を音声認識することが可能となっている。
【００３３】
ビデオコントローラ２０７は、ディスプレイ２１２などの外部出力装置への表示を制御する。ディスプレイは本体と一体になったノート型パソコンのディスプレイも含まれるものとする。なお、外部出力装置はディスプレイに限ったものははく、例えばプロジェクタであってもよい。また、前述のタッチ操作により受け付け可能な装置については、キーボード／タッチパネル２１０からの入力を受け付けることも可能となる。
【００３４】
なおビデオコントローラ２０７は、表示制御を行うためのビデオメモリ（ＶＲＡＭ）を制御することが可能で、ビデオメモリ領域としてＲＡＭ２０３の一部を利用することもできるし、別途専用のビデオメモリを設けることも可能である。
【００３５】
本発明では、ユーザが情報処理装置を通常する場合の表示に用いられる第１のビデオメモリ領域と、所定の画面が表示される場合に、第１のビデオメモリ領域の表示内容に重ねての表示に用いられる第２のビデオメモリ領域を有している。ビデオメモリ領域は２つに限ったものではなく、情報処理装置の資源が許す限り複数有することが可能なものとする。
【００３６】
メモリコントローラ２０８は、外部メモリ２１３へのアクセスを制御する。外部メモリとしては、ブートプログラム、各種アプリケーション、フォントデータ、ユーザファイル、編集ファイル、および各種データ等を記憶する外部記憶装置（ハードディスク）、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等を利用可能である。
【００３７】
通信Ｉ／Ｆコントローラ２０９、ネットワーク２１４を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信やＩＳＤＮなどの電話回線、および携帯電話の３Ｇ回線を用いた通信が可能である。
【００３８】
なお、記憶装置２０４は情報を永続的に記憶するための媒体であって、その形態をハードディスク等の記憶装置に限定するものではない。例えば、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）などの媒体であってもよい。
【００３９】
また本実施形態における通信端末で行われる各種処理時の一時的なメモリエリアとしても利用可能である。
【００４０】
図３は、本発明の実施形態に係わる読影システムのクライアント端末の読影依頼画面の一例を示す図である。
【００４１】
読影依頼画面３０１は、クライアント端末１００から不図示の読影依頼メニューを起動することで表示される。通常は依頼元の主治医または入力担当者によって利用される画面である。依頼元３０９に表示されているように依頼次郎さんが依頼元としての読影依頼の入力を行っている。
【００４２】
依頼先情報３０２は、依頼先および依頼番号からなっており、依頼先は入力領域をマウスでクリックすることにより表示される、システムに登録されている依頼先から選べるようになっている。また、依頼番号はシステムが一意になるよう自動採番される。
【００４３】
患者情報３０３は、読影される患者に関する情報が記入される。例えば診察カードのようなものを利用し、患者を識別可能な番号をキーに患者マスタから読み込まれたものである。登録されているマスタにより表示される内容は異なる。患者マスタについては図９を利用して後述する。
【００４４】
画像情報３０４は、当該依頼の患者の画像に関する情報である。撮影した画像と対応づいたものが記入される。「画像枚数」は、依頼画像の枚数である。「検査種」がＣＴとなっているので、ＣＴスキャンされた画像の枚数が５０枚あるということであり、「ファイルＩＤ」である０１０は、５０枚の画像から構成されることがわかる。「検査部位」は実際に検査された部位であり、検査機器から取得するようにしてもよいし、依頼元のユーザが書き込むようにしてもよい。「検査日時」は、検査が行われた日時、すなわち画像の撮影が行われた日である。
【００４５】
依頼情報３０５は、本依頼に関するサマリとなっており、「依頼医」「優先度」「部位」「検査項目」「検査種」「依頼内容」「関連キー」および「依頼元」が記入される。
【００４６】
「依頼医」には読影を行ってもらう読影医が記入される。読影医は読影医マスタ（図９にて後述）から選択できるようになっている。
【００４７】
「優先度」は依頼元ユーザが入力するもので、読影医もしくは、読影システムが優先度を考慮して読影の順番を決めることができる。
【００４８】
「部位」「検査項目」「検査種」は、それぞれ、検査が行われた部位や検査の種類に関する情報が記入される。
【００４９】
「依頼内容」は、依頼元である依頼次郎さんが、依頼である読影太郎さんに向けてのコメントとして利用される。
【００５０】
「関連キー」には、「本人画像」「部位」「モダリティ」「年齢」および「参考画像優先」の項目があり、これを依頼元がチェックすることで読影システムは本依頼の関連キーとして登録される。登録された関連キーが関連情報としてアプリケーションサーバに取得される。
【００５１】
通常読影医は、患者の検査画像に対して診断を行うときに、本人の過去の画像データや同様の症状を持つ他人の検査画像を参考画像として利用することがある。この時に、読み読み出しに時間のかかる外部ストレージから読み出すのではなく、事前にローカルキャッシュにキャッシュインしておくことで素早く参考画像にアクセスすることができる。
【００５２】
関連キーは、依頼時に依頼元のユーザが入力することができる。例えば、「本人画像」にチェックがついている場合は、患者本人の過去の画像を関連ファイルとする。「部位」にチェックがされた場合は、患者の部位と同じ部位の画像を関連ファイルとする。例えば検査部位が胸部の場合は、胸部の検査画像が関連ファイルとなる。「検査種」にチェックが入った場合は、患者の画像を診断した種類と同じ種類の診断画像を関連ファイルとする。例えば検査種がＣＴの場合は、ＣＴ画像が関連ファイルとなる。「年齢」にチェックが入っている場合、患者の年齢と同じ年齢（単位を１０才単位や２０才単位として区切ることも可能）層を関連ファイルとする。
【００５３】
「参考画像優先」にチェックが入っている場合、前述した条件で関連ファイルとして選定されたファイルに優先度をつけることが可能となる。例えば、関連ファイルが多く選定されるとキャッシュインされるファイル数が多くなるので、上限を設定したい場合に有効である。
【００５４】
後述する読影画面で、読影医が参考になった（有効であった）画像に対して「参考になった」とチェック入力することで、画像ファイルのファイルマスタＤＢにその旨が記録され、参考になったとされたファイルを優先的に関連ファイルとしてキャッシュインさせることができる。これにより、参考になったものを優先的にキャッシュインするので効率よく診断ができるようになる。
【００５５】
なお、関連キーの各項目は、複数指定することが可能であり、例えば全部にチェックがついている場合、本人の画像で、部位と検査種が同じで、参考画像が優先的に関連画像として選定される。この場合、本人の画像であっても古すぎると年齢が異なるためヒットしない場合があるので、本人画像が選択された場合は、年齢を選択できないようにしてもよい。
【００５６】
また、本実施形態では、依頼元のユーザが指定するようにしたが、あらかじめシステムに設定しておくようにしてもよい。
【００５７】
依頼画面では複数の読影依頼を入力することが可能で、一覧へ戻る３０６が押下されると、読影依頼を一覧画面（不図示）で見ることができる。また、矢印キーを押下することで、前の依頼や次の依頼を表示することができる。
【００５８】
保存３０７が押下されると入力した内容が保存され、依頼送信３０８が押下されるとアプリケーションサーバへ依頼データが送信される。
【００５９】
図４は、本発明の実施形態に係わる読影システムのクライアント端末の読影画面の一例を示す図である。
【００６０】
読影画面４０１は、クライアント端末１００から不図示の読影メニューを起動することで表示される。通常は読影医によって利用される画面である。利用者４１０に表示されているように、読影太郎さんが読影を行うための画面である。
【００６１】
ワークリスト４０２は、読影太郎さん宛ての読影依頼が表示されている。「依頼番号」には、図３の依頼画面で入力された内容が依頼番号をキーに表示される。「ステータス」には、読影済みや読影中、読影待ちなどのステータスがシステムによって表示される。本画面においては、「ｉｒａｉ−ａ０１」を読影中であるものとして説明する。
【００６２】
患者情報４０３についても同様に図３で入力された患者情報が表示される。
【００６３】
画像情報４０４には、読影する画像（依頼されたもの）を表示する「今回の読影画像」４０５を表示するエリアと、読影医が参考にしたい（見たい）画像を検索する検索エリア４０７と、当該検索により検索した画像４０９が表示されるエリアが表示される。
【００６４】
今回の読影画像４０５には、依頼されたファイルＩＤ「０１０」に対応する画像が表示される。本画像は画像枚数が５０枚あるので、スクロールバー４０６を利用することで全ての画像を表示することが可能である。また、「０１０−１」「０１０−・・」のようにファイルＩＤの後ろに連番が付与されるようになっている。
【００６５】
検索エリア４０７では、検索項目を入力して検索ボタン４０８を押下することでファイルマスタを検索し、ローカルキャッシュにあれば、そのまま表示し、ローカルキャッシュになければ（外部ストレージにある）、外部ストレージからローカルキャッシュに一度キャッシュインしてからクライアント端末１００に表示される。ここで、読影医により検索される可能性の高い画像が、関連キーとして読影依頼時に付与されて、事前にキャッシュインされるようになっている。
【００６６】
検索された画像４０９に表示された画像が読影医にとって有用な情報であるなどして参考になった場合、「参考になった」にチェックを入れるようになっている。このチェックはファイルマスタＤＢに記憶され、次回以降の関連画像の候補を選定するときの優先順位が高くなるようにすることができる。
【００６７】
所見入力４０９が押下されると、不図示の所見入力画面が起動し、読影医は所見を入力しアプリケーションサーバに送信する。送信が受理されると、ワークリスト４０２に表示されるステータスが「読影済み」に変更される。
【００６８】
図９は、本発明の実施形態に係わる読影システムの各種ユーザマスタテーブルの一例を示す図ある。
【００６９】
図３および図４で表示される依頼元情報、読影医情報、および患者情報を表示するためのマスタデータである。いずれのマスタテーブルもＤＢＭＳ１１２に記憶されるものである。
【００７０】
依頼元マスタ９００は、主に図３に示す読影依頼画面を利用するユーザに関するマスタテーブルである。依頼元ＩＤに対応して氏名および依頼元施設が記録されている。ユーザは依頼元ＩＤでシステムにログインし、読影依頼画面にアクセスすると、依頼元として氏名（図３の３０９）と依頼元施設（図４のワークリスト）がデータに付与され表示に使用される。
【００７１】
読影医マスタ９１０は、主に図４に示す読影画面を利用するユーザに関するマスタテーブルである。読影医ＩＤに対応して氏名および所属が記録されている。ユーザは読影医ＩＤでシステムにログインし、読影画面にアクセスすると、利用者として氏名（図４の４１０）がデータに付与され表示に使用される
【００７２】
患者マスタ９２０は、読影を受ける患者のマスタテーブルで、患者ＩＤに対応して、氏名、性別、および生年月日が記憶されている。ここに示した患者情報は一例であり、より多くの患者情報を記憶しておくこともできる。患者ＩＤをキーにして各種読影画面上に患者情報が表示される。
【００７３】
図５は、本発明の実施形態に係わる読影システムの画像ファイル登録時の処理の一例を示すフローチャートである。
【００７４】
ステップＳ５０１からステップＳ５０４はクライアント端末１００の処理、ステップＳ５１１からステップＳ５２１はアプリケーションサーバ１０１（情報処理装置）の処理、ステップＳ５３１からステップＳ５３２は外部サーバ１０３の処理である。
【００７５】
ステップＳ５０１でクライアントは、図３に示す読影依頼画面の画像情報３０４で指定された画像データを受信し、ステップＳ５０２では、依頼情報３０５に含まれる関連キーを受付ける。
【００７６】
ステップＳ５０３では、受け付けた画像データおよび関連キーをアプリケーションサーバ１０１に送付する。なお、関連キーについては、アプリケーションサーバにあらかじめ登録されている場合もあるので、その場合は、関連キー以外の情報が送信される。
【００７７】
ステップＳ５１１でアプリケーションサーバは、画像データと関連キーを受信し、ステップＳ５１２で、ローカルキャッシュ１１１に画像ファイルを保存する。
【００７８】
次にステップＳ５１３に進み、関連キーと保管先をファイルマスタＤＢに保管する。ファイルマスタＤＢについて説明する。
【００７９】
図８は、本発明の実施形態に係わる読影システムのファイルマスタＤＢの一例を示す図である。
【００８０】
ファイルマスタＤＢ８０１は、ＤＢＭＳ１１２に記憶されており、「ファイルＩＤ」「外部格納パス」「ローカル格納パス」「患者名」「検査種／部位」「年齢」「最終参照日時」および「有効画像」の各項目を記憶しており、画像ファイルの保管状態を管理可能となっている。
【００８１】
ファイルＩＤは読影依頼に含まれるファイルＩＤであって、ファイルマスタＤＢのキーとなる項目である。
【００８２】
外部格納パスは、外部ストレージである外部サーバ１０２への格納パスであり、ファイルＩＤをキーにどのファイルがどの外部サーバのどこに格納されているかが分かる。また、外部サーバに記憶されたファイルは契約が解除されたりしない限り永続的に保存されるものなので、必ずパスは記入されるものである。なお、外部サーバが変更された際には、変更後のパスに書き換わるものである。
【００８３】
ローカル格納パスは、ローカルキャッシュ１１１への格納パスであり、所定期間経過後に削除されるものであるので、削除されると格納パスは「ｎｕｌｌ」に変更される。
【００８４】
「患者名」「検査種／部位」「年齢」の各項目は、患者に関する情報であって患者マスタから取得して表示するか、読影依頼データの患者情報３０３から取得して表示する。
【００８５】
最終参照日時は、読影医に参照された最終日時であって、図４で検索されて表示された場合は、その日時が最終参照日時として記録される。なお、その場合は、一度消された（キャッシュアウト）画像であってもローカルキャッシュに保存され、ローカル格納パスにもパスが記録される。なお、最終日時情報は日付情報だけでなく、時間／分／秒まで記録しておくことが望ましい。これにより大量の画像データを対象とすることができる。
【００８６】
有効画像１、有効画像２については、図４の読影画面で読影医が「参考になった」とチェックした画像に対して付与される。図の例では、ファイルＩＤ「００１」の画像が、「ｉｒａｉ−Ｂ０１」と「ｉｒａｉ−Ａ０１」で検索されて参考になったことを意味する。ファイルＩＤ「００１」は、例えば所定期間経過したのでキャッシュアウトされていたとしても、「２０１２／１２／２５」の依頼である「ｉｒａｉ−Ａ０１」で検索されてローカルキャッシュに保存されているので、最終参照日時に「２０１２／１２／２５」と記録されている。
【００８７】
また、ローカル格納パスには、「ｃｈａｃｈｅ／０１１」と新しいパスが記録される。（本実施例においてローカル格納パスの／より後ろの部分は日付の昇順に付与されるものとする。）
【００８８】
このように有効画像のチェックを設けることによって、画像がどれだけ他の読影の参考になったのかを記録しておくことが可能となる。例えば、本実施例では、「００１」が２件、「００４」「００５」「００９」でそれぞれ１件ずつ参考になったことが分かる。また依頼番号を付加しているので、依頼の詳細も簡単に参照することができる。
図５のフローチャートの説明に戻る。
【００８９】
次にステップＳ５１４で登録結果をクライアント端末に返却し、ステップＳ５０４で登録結果を受信して、クライアント端末の処理は終了する。
【００９０】
ステップＳ５１５では、外部サーバにファイルを保管し、ステップＳ５３１で外部サーバは対象の画像ファイルを保管する。
【００９１】
ステップＳ５１６では、外部サーバへの保管先情報を、ファイルマスタＤＢの外部格納パスに記憶する。
【００９２】
次にステップＳ５１７では関連キーを使ってファイルマスタＤＢを検索する。関連キーはステップＳ５１１で取得したものを使用する。ここで関連キーとして参考画像優先にチェックがされていた場合、ファイルマスタＤＢの「有効画像」を持つ画像ファイルを対象としてもよいし、例えば所定ファイル数（例えば５０枚）を超える場合は、「有効画像」を持つ画像ファイルを優先して関連ファイルとすることができる。
【００９３】
関連キーで検索した結果、関連ファイルとして選定された全てのファイルに対して、ステップＳ５１８からステップＳ５２１でループ処理され、全ての関連ファイルへの処理が終了すると処理が終了する。
【００９４】
ステップＳ５１９では対象の関連ファイルがローカルキャッシュに保管されているか（保管状態判定）、すなわち、ファイルマスタＤＢのローカル格納パスが「ｎｕｌｌ」でないかどうかの判定を行う。
【００９５】
「ｎｕｌｌ」でない場合、パスが記録されておりローカルキャッシュに記憶されているということになるので、何もせずステップＳ５１８に戻り次の関連ファイルの処理に移る。一方、「ｎｕｌｌ」の場合、ローカルキャッシュからは削除（キャッシュアウト）されたファイルであるので、ステップＳ５２０に進み、外部サーバから関連する画像ファイルを取得（複製が作成される）し、ステップＳ５２１でファイルマスタＤＢのローカル格納パスに保存先のパス情報を登録し、ステップＳ５１８に戻り、次の関連ファイルの処理に移る。
【００９６】
図６は、本発明の実施形態に係わる読影システムの画像ファイル取得時の処理の一例を示すフローチャートである。
【００９７】
図４に示す読影画面に画像情報４０４を表示するためにクライアント端末からアプリケーションサーバに画像データの要求が行われるものである。
【００９８】
ステップＳ６０１からステップＳ６０２はクライアント端末１００の処理、ステップＳ６１１からステップＳ６１７はアプリケーションサーバ１０１（情報処理装置）の処理、ステップＳ６３１は外部サーバ１０３の処理である。
【００９９】
ステップＳ６０１で、クライアント端末から画像データリクエストがアプリケーションサーバ１００（情報処理装置）に対して送信される。ここでのリクエストには、画像ファイルが１つずつ要求されるものとして説明する。また、一度に複数の画像ファイルの要求を受け付ける場合には、ステップＳ６１１からステップＳ６１７のアプリケーションサーバの処理が画像ファイルの数だけループされるものとする。
【０１００】
ステップＳ６１１でリクエストされた画像のファイルＩＤを取得し、ファイルマスタＤＢのインデックス情報を検索する。ステップＳ６１３では対象の関連ファイルがローカルキャッシュに保管されているか、すなわち、ファイルマスタＤＢのローカル格納パスが「ｎｕｌｌ」でないかどうかの判定を行う。
【０１０１】
「ｎｕｌｌ」でない場合、パスが記録されておりローカルキャッシュに記憶されているということになるので、何もせずステップＳ６１６に進む。一方、「ｎｕｌｌ」の場合、ローカルキャッシュからは削除（キャッシュアウト）されたファイルであるので、ステップＳ６１４に進み、外部サーバのステップＳ６３１の処理により関連する画像ファイルを取得（キャッシュイン）し、ステップＳ６１５で、ローカル格納パスに保存先のパス情報を登録し、ステップＳ６１６に進む。
【０１０２】
ステップＳ６１６では、クライアント端末からリクエストされた画像データを、ローカルキャッシュから送信し、ステップＳ６０２では、クライアント端末がリクエストした画像を受信し、クライアントは処理を終了する。
【０１０３】
ステップＳ６１７では、送信した画像データに対して、ファイルマスタＤＢの最終参照日時を更新して処理を終了する。ここで最終参照日時を更新しておくことで、次回キャッシュアウトされる時の基準を変更することが可能となる。
【０１０４】
図７は、本発明の実施形態に係わる情報処理装置のキャッシュアウト処理の一例を示すフローチャートである。
【０１０５】
アプリケーションサーバ１０１（情報処理装置）でｃｒｏｎ１１３の設定によって定期的（所定のタイミングで）に行われるキャッシュアウトの処理である。
【０１０６】
ｃｒｏｎによって指定された時間に処理が開始される。ステップＳ７０１で、ローカルキャッシュの空き容量を取得する。ここで空き容量の閾値を１０００テラバイトとすると、ステップＳ７０２では、１０００テラバイト未満になると空き容量不足となり、１０００テラバイト以上空き容量があれば空き容量不足とならない。
【０１０７】
ステップＳ７０２で空き容量不足でない場合は、何もせず処理を終了し、空き容量が不足と判定された場合は、ステップＳ７０３に進み、キャッシュアウト候補を決定する。ここでキャッシュアウト候補とは、例えば、最終参照されてから古い順に決まった件数（例えば１万件）をキャッシュアウト候補とする。
【０１０８】
また、キャッシュアウト候補となったファイルであっても、ファイルマスタＤＢで「有効画像」として登録さているファイルについてはキャッシュアウトの候補から外すことができる。これにより、参考になった回数の多い画像ファイルについては、再度読まれる可能性があるので、無駄なキャッシュアウト・キャッシュインを防ぐことができる。これは、外部サーバとして、ファイルの送受信に際して課金が発生するような外部ストレージを利用している場合などには特に有効である。
【０１０９】
ステップＳ７０４では、候補となったファイルのキャッシュアウトを行う。キャッシュアウトとは、ローカルキャッシュから該当するファイルを削除することである。削除されると、ステップＳ７０５に進み、ファイルマスタのキャッシュ情報を更新してステップＳ７０２に戻り、再度空き容量が不足していないかの判定を行う。これは、キャッシュアウトの処理の際中に画像ファイルが新規に登録されたり、キャッシュインされたりした場合に空き容量が不足してしまう場合があるからである。
【０１１０】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１１１】
また、本発明におけるプログラムは、本発明に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体はコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは各装置の処理方法ごとのプログラムであってもよい。
【０１１２】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１１３】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
【０１１４】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。
【０１１５】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１６】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１７】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１１８】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１１９】
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１２０】
１００  クライアント端末
１０１  アプリケーションサーバ
１０２  外部サーバ
５００  通信ネットワーク
【図１】
2019049988.tif 000003
【図２】
2019049988.tif 000004
【図３】
2019049988.tif 000005
【図４】
2019049988.tif 000006
【図５】
2019049988.tif 000007
【図６】
2019049988.tif 000008
【図７】
2019049988.tif 000009
【図８】
2019049988.tif 000010
【図９】
2019049988.tif 000011