JP6417719B2 - 情報処理装置、情報処理システム、情報処理方法、およびプログラム - Google Patents

Description

本発明は、情報処理装置、情報処理システム、情報処理方法、およびプログラムに関する。

近年、インターネットを利用したパブリックなストレージサービスが提供されるようになり、大量のデータを安価に保管できるようになった。しかしながら大量のデータのやり取りには回線の速度などの問題により時間がかかってしまう場合がある。

これに対して回線の速度や品質を保証するようなストレージサービスも存在しているが、利用料金がパブリックなストレージサービスよりも高価な場合が多いという問題があった。

特許文献１では、利用者にとってよく利用される情報であるキャッシュ記憶手段と実体を記憶するデータ記憶手段を有していて、アクセス要求を受け付けると当該要求と関連する情報をキャッシュ記憶手段に記憶する技術が提案されている。

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

患者の主治医から出された依頼（患者の主訴や病歴・家族歴など）をもとに、適正な検査（ＣＴ、ＭＲＩ、血管造影など）を判断し、その検査画像から画像診断を行い、今後さらに必要になると思われる検査や治療方針の助言を行う読影システムにおいては、大量の検査画像を扱うので、システムで取り扱う検査画像は、パブリックなストレージサービスに保管することが多い。そして、最近読影を依頼された検査画像は、速度の速いストレージサービスを利用することが行われている。

読影システムでは、読影医が検査画像を見ながら診断を行うのであるが、同じ症例や似た部位の検査画像を見ることがある。この場合、見たい画像が速度の遅いパブリックなストレージサービスに保管されているとファイルの読み出しに時間がかかってしまうので、事前に速度の速いストレージシステムに保存（転送）しておきたいという要望がある。

しかしながら特許文献１の発明では、関連する情報をルールとして定義されたものを使って検索している。しかしながら、読影システムの場合、患者の症例によって関連する情報を一意に決定することは難しい。例えば、同じ患者の過去の画像があれば、過去の画像を見たい場合もあるし、患者と同年代の患者の画像を見たい場合もあるので、あらかじめ決まったルールに基づいてルールを設定することは難しい。

また、特許文献１においては、検索された時に関連する情報を検索するようにしているが、検索した時に関連する画像を検索するのは遅い場合があり、検査画像が読影システムに保管された時に、読影医によって要求されるであろう関連画像をキャッシュしておくことが望ましい。

そこで本発明は、読影依頼を受け付けた際に、読影対象の医用画像と関連のある関連画像を特定可能なしくみを提供することを目的とする。

本発明は、第１のストレージに保存された医用画像を第２のストレージに保存する情報処理装置であって、前記第1のストレージに保存されている医用画像を所定の条件に従って削除する削除手段と、読影を行う医用画像と当該医用画像の読影に関連する先に保存されている医用画像を特定するための関連情報とを含む読影依頼情報を受信する受信手段と、前記受信手段で受信した前記読影依頼情報に含まれる関連情報に基づいて、先に保存されている医用画像を特定する医用画像特定手段と、前記医用画像特定手段により特定される先に保存されている医用画像であって、前記第１のストレージから削除された医用画像を前記第２のストレージから取得する取得手段と、前記取得手段で取得した医用画像を前記第１のストレージに保存する医用画像保存手段と、を有することを特徴とする。

本発明によれば、読影依頼を受け付けた際に、読影対象の医用画像と関連のある関連画像を特定可能なしくみを提供することが可能となる。

本発明の実施形態に係わる読影システムのシステム構成図の一例を示す図である。 本発明の実施形態に係わるアプリケーションサーバである情報処理装置のハードウェア構成の一例を示すブロック図である。 本発明の実施形態に係わる読影システムのクライアント端末の読影依頼画面の一例を示す図である。 本発明の実施形態に係わる読影システムのクライアント端末の読影画面の一例を示す図である。 本発明の実施形態に係わる読影システムの画像ファイル登録時の処理の一例を示すフローチャートである。 本発明の実施形態に係わる読影システムの画像ファイル取得時の処理の一例を示すフローチャートである。 本発明の実施形態に係わる情報処理装置のキャッシュアウト処理の一例を示すフローチャートである。 本発明の実施形態に係わる読影システムのファイルマスＤＢの一例を示す図である。 本発明の実施形態に係わる読影システムの各種ユーザマスタテーブルの一例を示す図ある。

以下、図面を参照して、本発明の実施形態を詳細に説明する。

図１は、本発明の実施形態に係わる読影システムのシステム構成図の一例を示す図である。

本発明に係る読影システム（情報処理システム）は、クライアント端末１００、アプリケーションサーバ１０１、および外部サーバ１０２が通信ネットワーク５００を介して通信可能に接続されている。

読影システムとは、患者の主治医から出された依頼（患者の主訴や病歴・家族歴など）をもとに、読影医が検査や治療方針の助言を行うものであり、クライアント端末１００は、読影の依頼元である患者の主治医や、読影を行う読影医により利用される。利用者ＩＤにより利用できるメニューが異なる。

例えば、依頼元のクライアント端末１００からは、アプリケーションサーバ１０１に対して、医療画像や患者情報などを付与して読影の依頼を行う。読影医のクライアント端末は、アプリケーションサーバ１０１から、依頼された読影に関するデータを読み出したり、参考情報として他の患者の画像データ（電子ファイル）を要求したりする。アプリケーションサーバ１０１ではＷＥＢアプリケーションとして稼働しており、ブラウザを利用して読影システムにアクセス可能になっている。

アプリケーションサーバ１０１は、読影システムが稼働しているサーバであってローカルキャッシュ１１１、ＤＢＭＳ１１２、ｃｒｏｎ１１３、ローカルキャッシュ管理部１１４、データ検索部１１５、および外部サーバ通信部１１６を有する。

外部サーバ１０２は、例えばクラウドを利用したストレージサービスなどを指す。外部サーバは複数利用することが可能となっている。本実施例の読影システムでは、依頼元のクライアント端末１００から依頼されたデータが一旦アプリケーションサーバ１０１のローカルキャッシュ１１１と、外部サーバ１０２に保管される。ローカルキャッシュ１１１は、アプリケーションサーバのローカルディスクであったり、別途契約する信頼性が高かったり、通信速度が速かったりするストレージを指す。また、ローカルキャッシュ１１１のデータはｃｒｏｎ１１３を利用し、定期的に古いデータが削除されるものである（これをキャッシュアウトと呼ぶ）。

本実施例では、外部サーバ１０２のように全てのデータは永続的に保管し、必要な時にデータを読み出すストレージサービスを外部ストレージと呼び、アプリケーションサーバ１０１が通常使うストレージサービスをローカルキャッシュと呼ぶ。

またローカルキャッシュには、依頼元１００から読影の依頼データから関連キーを取得し、関連キーに合致するデータをデータ検索部１１５が検索し、外部サーバ１０２にだけ保管されている場合（ローカルキャッシュ１１１からは削除済み）は、外部サーバ通信部１１６によって、該当する外部サーバ１０２からローカルキャッシュ１１１に関連画像を読み込んでおく（これをキャッシュインと呼ぶ）。

ＤＢＭＳ１１２には、ファイルマスタＤＢ（図８）、依頼元マスタ、読影医マスタ、および患者マスタ（図９）が記憶されており、アプリケーションサーバは、これらテーブルを利用して必要な情報を画面に表示したり、依頼や回答などの電文に付与したりするのに利用する。

図２は、本発明の実施形態に係わるアプリケーションサーバである情報処理装置のハードウェア構成の一例を示すブロック図である。

図２に示すように、情報処理装置１０１では、システムバス２００を介してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３、記憶装置２０４、入力コントローラ２０５、音声入力コントローラ２０６、ビデオコントローラ２０７、メモリコントローラ２０８、よび通信Ｉ／Ｆコントローラ２０９が接続される。

ＣＰＵ２０１は、システムバス２００に接続される各デバイスやコントローラを統括的に制御する。

ＲＯＭ２０２あるいは記憶装置２０４は、ＣＰＵ２０１が実行する制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や、本情報処理方法を実現するためのコンピュータ読み取り実行可能なプログラムおよび必要な各種データ（データテーブルを含む）を保持している。

ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは記憶装置２０４からＲＡＭ２０３にロードし、ロードしたプログラムを実行することで各種動作を実現する。

入力コントローラ２０５は、キーボード／タッチパネル２１０などの入力装置からの入力を制御する。入力装置はこれに限ったものでなく、マウスやマルチタッチスクリーンなどの、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。

ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下（指等でタッチ）することにより、各種の指示を行うことができる。

この入力装置を用いて各種通信装置で利用可能な通信宛先に対する宛先を入力するようになっている。

音声入力コントローラ２０６は、マイク２１１からの入力を制御する。マイク２１１から入力された音声を音声認識することが可能となっている。

ビデオコントローラ２０７は、ディスプレイ２１２などの外部出力装置への表示を制御する。ディスプレイは本体と一体になったノート型パソコンのディスプレイも含まれるものとする。なお、外部出力装置はディスプレイに限ったものははく、例えばプロジェクタであってもよい。また、前述のタッチ操作により受け付け可能な装置については、キーボード／タッチパネル２１０からの入力を受け付けることも可能となる。

なおビデオコントローラ２０７は、表示制御を行うためのビデオメモリ（ＶＲＡＭ）を制御することが可能で、ビデオメモリ領域としてＲＡＭ２０３の一部を利用することもできるし、別途専用のビデオメモリを設けることも可能である。

本発明では、ユーザが情報処理装置を通常する場合の表示に用いられる第１のビデオメモリ領域と、所定の画面が表示される場合に、第１のビデオメモリ領域の表示内容に重ねての表示に用いられる第２のビデオメモリ領域を有している。ビデオメモリ領域は２つに限ったものではなく、情報処理装置の資源が許す限り複数有することが可能なものとする。

メモリコントローラ２０８は、外部メモリ２１３へのアクセスを制御する。外部メモリとしては、ブートプログラム、各種アプリケーション、フォントデータ、ユーザファイル、編集ファイル、および各種データ等を記憶する外部記憶装置（ハードディスク）、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等を利用可能である。

通信Ｉ／Ｆコントローラ２０９、ネットワーク２１４を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信やＩＳＤＮなどの電話回線、および携帯電話の３Ｇ回線を用いた通信が可能である。

なお、記憶装置２０４は情報を永続的に記憶するための媒体であって、その形態をハードディスク等の記憶装置に限定するものではない。例えば、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの媒体であってもよい。

また本実施形態における通信端末で行われる各種処理時の一時的なメモリエリアとしても利用可能である。

図３は、本発明の実施形態に係わる読影システムのクライアント端末の読影依頼画面の一例を示す図である。

読影依頼画面３０１は、クライアント端末１００から不図示の読影依頼メニューを起動することで表示される。通常は依頼元の主治医または入力担当者によって利用される画面である。依頼元３０９に表示されているように依頼次郎さんが依頼元としての読影依頼の入力を行っている。

依頼先情報３０２は、依頼先および依頼番号からなっており、依頼先は入力領域をマウスでクリックすることにより表示される、システムに登録されている依頼先から選べるようになっている。また、依頼番号はシステムが一意になるよう自動採番される。

患者情報３０３は、読影される患者に関する情報が記入される。例えば診察カードのようなものを利用し、患者を識別可能な番号をキーに患者マスタから読み込まれたものである。登録されているマスタにより表示される内容は異なる。患者マスタについては図９を利用して後述する。

画像情報３０４は、当該依頼の患者の画像に関する情報である。撮影した画像と対応づいたものが記入される。「画像枚数」は、依頼画像の枚数である。「検査種」がＣＴとなっているので、ＣＴスキャンされた画像の枚数が５０枚あるということであり、「ファイルＩＤ」である０１０は、５０枚の画像から構成されることがわかる。「検査部位」は実際に検査された部位であり、検査機器から取得するようにしてもよいし、依頼元のユーザが書き込むようにしてもよい。「検査日時」は、検査が行われた日時、すなわち画像の撮影が行われた日である。

依頼情報３０５は、本依頼に関するサマリとなっており、「依頼医」「優先度」「部位」「検査項目」「検査種」「依頼内容」「関連キー」および「依頼元」が記入される。

「依頼医」には読影を行ってもらう読影医が記入される。読影医は読影医マスタ（図９にて後述）から選択できるようになっている。

「優先度」は依頼元ユーザが入力するもので、読影医もしくは、読影システムが優先度を考慮して読影の順番を決めることができる。

「部位」「検査項目」「検査種」は、それぞれ、検査が行われた部位や検査の種類に関する情報が記入される。

「依頼内容」は、依頼元である依頼次郎さんが、依頼である読影太郎さんに向けてのコメントとして利用される。

「関連キー」には、「本人画像」「部位」「モダリティ」「年齢」および「参考画像優先」の項目があり、これを依頼元がチェックすることで読影システムは本依頼の関連キーとして登録される。登録された関連キーが関連情報としてアプリケーションサーバに取得される。

通常読影医は、患者の検査画像に対して診断を行うときに、本人の過去の画像データや同様の症状を持つ他人の検査画像を参考画像として利用することがある。この時に、読み読み出しに時間のかかる外部ストレージから読み出すのではなく、事前にローカルキャッシュにキャッシュインしておくことで素早く参考画像にアクセスすることができる。

関連キーは、依頼時に依頼元のユーザが入力することができる。例えば、「本人画像」にチェックがついている場合は、患者本人の過去の画像を関連ファイルとする。「部位」にチェックがされた場合は、患者の部位と同じ部位の画像を関連ファイルとする。例えば検査部位が胸部の場合は、胸部の検査画像が関連ファイルとなる。「検査種」にチェックが入った場合は、患者の画像を診断した種類と同じ種類の診断画像を関連ファイルとする。例えば検査種がＣＴの場合は、ＣＴ画像が関連ファイルとなる。「年齢」にチェックが入っている場合、患者の年齢と同じ年齢（単位を１０才単位や２０才単位として区切ることも可能）層を関連ファイルとする。

「参考画像優先」にチェックが入っている場合、前述した条件で関連ファイルとして選定されたファイルに優先度をつけることが可能となる。例えば、関連ファイルが多く選定されるとキャッシュインされるファイル数が多くなるので、上限を設定したい場合に有効である。

後述する読影画面で、読影医が参考になった（有効であった）画像に対して「参考になった」とチェック入力することで、画像ファイルのファイルマスタＤＢにその旨が記録され、参考になったとされたファイルを優先的に関連ファイルとしてキャッシュインさせることができる。これにより、参考になったものを優先的にキャッシュインするので効率よく診断ができるようになる。

なお、関連キーの各項目は、複数指定することが可能であり、例えば全部にチェックがついている場合、本人の画像で、部位と検査種が同じで、参考画像が優先的に関連画像として選定される。この場合、本人の画像であっても古すぎると年齢が異なるためヒットしない場合があるので、本人画像が選択された場合は、年齢を選択できないようにしてもよい。

また、本実施形態では、依頼元のユーザが指定するようにしたが、あらかじめシステムに設定しておくようにしてもよい。

依頼画面では複数の読影依頼を入力することが可能で、一覧へ戻る３０６が押下されると、読影依頼を一覧画面（不図示）で見ることができる。また、矢印キーを押下することで、前の依頼や次の依頼を表示することができる。

保存３０７が押下されると入力した内容が保存され、依頼送信３０８が押下されるとアプリケーションサーバへ依頼データが送信される。

図４は、本発明の実施形態に係わる読影システムのクライアント端末の読影画面の一例を示す図である。

読影画面４０１は、クライアント端末１００から不図示の読影メニューを起動することで表示される。通常は読影医によって利用される画面である。利用者４１０に表示されているように、読影太郎さんが読影を行うための画面である。

ワークリスト４０２は、読影太郎さん宛ての読影依頼が表示されている。「依頼番号」には、図３の依頼画面で入力された内容が依頼番号をキーに表示される。「ステータス」には、読影済みや読影中、読影待ちなどのステータスがシステムによって表示される。本画面においては、「ｉｒａｉ−ａ０１」を読影中であるものとして説明する。

患者情報４０３についても同様に図３で入力された患者情報が表示される。

画像情報４０４には、読影する画像（依頼されたもの）を表示する「今回の読影画像」４０５を表示するエリアと、読影医が参考にしたい（見たい）画像を検索する検索エリア４０７と、当該検索により検索した画像４０９が表示されるエリアが表示される。

今回の読影画像４０５には、依頼されたファイルＩＤ「０１０」に対応する画像が表示される。本画像は画像枚数が５０枚あるので、スクロールバー４０６を利用することで全ての画像を表示することが可能である。また、「０１０−１」「０１０−・・」のようにファイルＩＤの後ろに連番が付与されるようになっている。

検索エリア４０７では、検索項目を入力して検索ボタン４０８を押下することでファイルマスタを検索し、ローカルキャッシュにあれば、そのまま表示し、ローカルキャッシュになければ（外部ストレージにある）、外部ストレージからローカルキャッシュに一度キャッシュインしてからクライアント端末１００に表示される。ここで、読影医により検索される可能性の高い画像が、関連キーとして読影依頼時に付与されて、事前にキャッシュインされるようになっている。

検索された画像４０９に表示された画像が読影医にとって有用な情報であるなどして参考になった場合、「参考になった」にチェックを入れるようになっている。このチェックはファイルマスタＤＢに記憶され、次回以降の関連画像の候補を選定するときの優先順位が高くなるようにすることができる。

所見入力４０９が押下されると、不図示の所見入力画面が起動し、読影医は所見を入力しアプリケーションサーバに送信する。送信が受理されると、ワークリスト４０２に表示されるステータスが「読影済み」に変更される。

図９は、本発明の実施形態に係わる読影システムの各種ユーザマスタテーブルの一例を示す図ある。

図３および図４で表示される依頼元情報、読影医情報、および患者情報を表示するためのマスタデータである。いずれのマスタテーブルもＤＢＭＳ１１２に記憶されるものである。

依頼元マスタ９００は、主に図３に示す読影依頼画面を利用するユーザに関するマスタテーブルである。依頼元ＩＤに対応して氏名および依頼元施設が記録されている。ユーザは依頼元ＩＤでシステムにログインし、読影依頼画面にアクセスすると、依頼元として氏名（図３の３０９）と依頼元施設（図４のワークリスト）がデータに付与され表示に使用される。

読影医マスタ９１０は、主に図４に示す読影画面を利用するユーザに関するマスタテーブルである。読影医ＩＤに対応して氏名および所属が記録されている。ユーザは読影医ＩＤでシステムにログインし、読影画面にアクセスすると、利用者として氏名（図４の４１０）がデータに付与され表示に使用される

患者マスタ９２０は、読影を受ける患者のマスタテーブルで、患者ＩＤに対応して、氏名、性別、および生年月日が記憶されている。ここに示した患者情報は一例であり、より多くの患者情報を記憶しておくこともできる。患者ＩＤをキーにして各種読影画面上に患者情報が表示される。

図５は、本発明の実施形態に係わる読影システムの画像ファイル登録時の処理の一例を示すフローチャートである。

ステップＳ５０１からステップＳ５０４はクライアント端末１００の処理、ステップＳ５１１からステップＳ５２１はアプリケーションサーバ１０１（情報処理装置）の処理、ステップＳ５３１からステップＳ５３２は外部サーバ１０３の処理である。

ステップＳ５０１でクライアントは、図３に示す読影依頼画面の画像情報３０４で指定された画像データを受信し、ステップＳ５０２では、依頼情報３０５に含まれる関連キーを受付ける。

ステップＳ５０３では、受け付けた画像データおよび関連キーをアプリケーションサーバ１０１に送付する。なお、関連キーについては、アプリケーションサーバにあらかじめ登録されている場合もあるので、その場合は、関連キー以外の情報が送信される。

ステップＳ５１１でアプリケーションサーバは、画像データと関連キーを受信し、ステップＳ５１２で、ローカルキャッシュ１１１に画像ファイルを保存する。

次にステップＳ５１３に進み、関連キーと保管先をファイルマスタＤＢに保管する。ファイルマスタＤＢについて説明する。

図８は、本発明の実施形態に係わる読影システムのファイルマスタＤＢの一例を示す図である。

ファイルマスタＤＢ８０１は、ＤＢＭＳ１１２に記憶されており、「ファイルＩＤ」「外部格納パス」「ローカル格納パス」「患者名」「検査種／部位」「年齢」「最終参照日時」および「有効画像」の各項目を記憶しており、画像ファイルの保管状態を管理可能となっている。

ファイルＩＤは読影依頼に含まれるファイルＩＤであって、ファイルマスタＤＢのキーとなる項目である。

外部格納パスは、外部ストレージである外部サーバ１０２への格納パスであり、ファイルＩＤをキーにどのファイルがどの外部サーバのどこに格納されているかが分かる。また、外部サーバに記憶されたファイルは契約が解除されたりしない限り永続的に保存されるものなので、必ずパスは記入されるものである。なお、外部サーバが変更された際には、変更後のパスに書き換わるものである。

ローカル格納パスは、ローカルキャッシュ１１１への格納パスであり、所定期間経過後に削除されるものであるので、削除されると格納パスは「ｎｕｌｌ」に変更される。

「患者名」「検査種／部位」「年齢」の各項目は、患者に関する情報であって患者マスタから取得して表示するか、読影依頼データの患者情報３０３から取得して表示する。

最終参照日時は、読影医に参照された最終日時であって、図４で検索されて表示された場合は、その日時が最終参照日時として記録される。なお、その場合は、一度消された（キャッシュアウト）画像であってもローカルキャッシュに保存され、ローカル格納パスにもパスが記録される。なお、最終日時情報は日付情報だけでなく、時間／分／秒まで記録しておくことが望ましい。これにより大量の画像データを対象とすることができる。

有効画像１、有効画像２については、図４の読影画面で読影医が「参考になった」とチェックした画像に対して付与される。図の例では、ファイルＩＤ「００１」の画像が、「ｉｒａｉ−Ｂ０１」と「ｉｒａｉ−Ａ０１」で検索されて参考になったことを意味する。ファイルＩＤ「００１」は、例えば所定期間経過したのでキャッシュアウトされていたとしても、「２０１２／１２／２５」の依頼である「ｉｒａｉ−Ａ０１」で検索されてローカルキャッシュに保存されているので、最終参照日時に「２０１２／１２／２５」と記録されている。

また、ローカル格納パスには、「ｃｈａｃｈｅ／０１１」と新しいパスが記録される。（本実施例においてローカル格納パスの／より後ろの部分は日付の昇順に付与されるものとする。）

このように有効画像のチェックを設けることによって、画像がどれだけ他の読影の参考になったのかを記録しておくことが可能となる。例えば、本実施例では、「００１」が２件、「００４」「００５」「００９」でそれぞれ１件ずつ参考になったことが分かる。また依頼番号を付加しているので、依頼の詳細も簡単に参照することができる。
図５のフローチャートの説明に戻る。

次にステップＳ５１４で登録結果をクライアント端末に返却し、ステップＳ５０４で登録結果を受信して、クライアント端末の処理は終了する。

ステップＳ５１５では、外部サーバにファイルを保管し、ステップＳ５３１で外部サーバは対象の画像ファイルを保管する。

ステップＳ５１６では、外部サーバへの保管先情報を、ファイルマスタＤＢの外部格納パスに記憶する。

次にステップＳ５１７では関連キーを使ってファイルマスタＤＢを検索する。関連キーはステップＳ５１１で取得したものを使用する。ここで関連キーとして参考画像優先にチェックがされていた場合、ファイルマスタＤＢの「有効画像」を持つ画像ファイルを対象としてもよいし、例えば所定ファイル数（例えば５０枚）を超える場合は、「有効画像」を持つ画像ファイルを優先して関連ファイルとすることができる。

関連キーで検索した結果、関連ファイルとして選定された全てのファイルに対して、ステップＳ５１８からステップＳ５２１でループ処理され、全ての関連ファイルへの処理が終了すると処理が終了する。

ステップＳ５１９では対象の関連ファイルがローカルキャッシュに保管されているか（保管状態判定）、すなわち、ファイルマスタＤＢのローカル格納パスが「ｎｕｌｌ」でないかどうかの判定を行う。

「ｎｕｌｌ」でない場合、パスが記録されておりローカルキャッシュに記憶されているということになるので、何もせずステップＳ５１８に戻り次の関連ファイルの処理に移る。一方、「ｎｕｌｌ」の場合、ローカルキャッシュからは削除（キャッシュアウト）されたファイルであるので、ステップＳ５２０に進み、外部サーバから関連する画像ファイルを取得（複製が作成される）し、ステップＳ５２１でファイルマスタＤＢのローカル格納パスに保存先のパス情報を登録し、ステップＳ５１８に戻り、次の関連ファイルの処理に移る。

図６は、本発明の実施形態に係わる読影システムの画像ファイル取得時の処理の一例を示すフローチャートである。

図４に示す読影画面に画像情報４０４を表示するためにクライアント端末からアプリケーションサーバに画像データの要求が行われるものである。

ステップＳ６０１からステップＳ６０２はクライアント端末１００の処理、ステップＳ６１１からステップＳ６１７はアプリケーションサーバ１０１（情報処理装置）の処理、ステップＳ６３１は外部サーバ１０３の処理である。

ステップＳ６０１で、クライアント端末から画像データリクエストがアプリケーションサーバ１００（情報処理装置）に対して送信される。ここでのリクエストには、画像ファイルが１つずつ要求されるものとして説明する。また、一度に複数の画像ファイルの要求を受け付ける場合には、ステップＳ６１１からステップＳ６１７のアプリケーションサーバの処理が画像ファイルの数だけループされるものとする。

ステップＳ６１１でリクエストされた画像のファイルＩＤを取得し、ファイルマスタＤＢのインデックス情報を検索する。ステップＳ６１３では対象の関連ファイルがローカルキャッシュに保管されているか、すなわち、ファイルマスタＤＢのローカル格納パスが「ｎｕｌｌ」でないかどうかの判定を行う。

「ｎｕｌｌ」でない場合、パスが記録されておりローカルキャッシュに記憶されているということになるので、何もせずステップＳ６１６に進む。一方、「ｎｕｌｌ」の場合、ローカルキャッシュからは削除（キャッシュアウト）されたファイルであるので、ステップＳ６１４に進み、外部サーバのステップＳ６３１の処理により関連する画像ファイルを取得（キャッシュイン）し、ステップＳ６１５で、ローカル格納パスに保存先のパス情報を登録し、ステップＳ６１６に進む。

ステップＳ６１６では、クライアント端末からリクエストされた画像データを、ローカルキャッシュから送信し、ステップＳ６０２では、クライアント端末がリクエストした画像を受信し、クライアントは処理を終了する。

ステップＳ６１７では、送信した画像データに対して、ファイルマスタＤＢの最終参照日時を更新して処理を終了する。ここで最終参照日時を更新しておくことで、次回キャッシュアウトされる時の基準を変更することが可能となる。

図７は、本発明の実施形態に係わる情報処理装置のキャッシュアウト処理の一例を示すフローチャートである。

アプリケーションサーバ１０１（情報処理装置）でｃｒｏｎ１１３の設定によって定期的（所定のタイミングで）に行われるキャッシュアウトの処理である。

ｃｒｏｎによって指定された時間に処理が開始される。ステップＳ７０１で、ローカルキャッシュの空き容量を取得する。ここで空き容量の閾値を１０００テラバイトとすると、ステップＳ７０２では、１０００テラバイト未満になると空き容量不足となり、１０００テラバイト以上空き容量があれば空き容量不足とならない。

ステップＳ７０２で空き容量不足でない場合は、何もせず処理を終了し、空き容量が不足と判定された場合は、ステップＳ７０３に進み、キャッシュアウト候補を決定する。ここでキャッシュアウト候補とは、例えば、最終参照されてから古い順に決まった件数（例えば１万件）をキャッシュアウト候補とする。

また、キャッシュアウト候補となったファイルであっても、ファイルマスタＤＢで「有効画像」として登録さているファイルについてはキャッシュアウトの候補から外すことができる。これにより、参考になった回数の多い画像ファイルについては、再度読まれる可能性があるので、無駄なキャッシュアウト・キャッシュインを防ぐことができる。これは、外部サーバとして、ファイルの送受信に際して課金が発生するような外部ストレージを利用している場合などには特に有効である。

ステップＳ７０４では、候補となったファイルのキャッシュアウトを行う。キャッシュアウトとは、ローカルキャッシュから該当するファイルを削除することである。削除されると、ステップＳ７０５に進み、ファイルマスタのキャッシュ情報を更新してステップＳ７０２に戻り、再度空き容量が不足していないかの判定を行う。これは、キャッシュアウトの処理の際中に画像ファイルが新規に登録されたり、キャッシュインされたりした場合に空き容量が不足してしまう場合があるからである。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるプログラムは、本発明に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体はコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは各装置の処理方法ごとのプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１００ クライアント端末
１０１ アプリケーションサーバ
１０２ 外部サーバ
５００ 通信ネットワーク

Claims (10)

1. 第１のストレージに保存された医用画像を第２のストレージに保存する情報処理装置であって、
   前記第1のストレージに保存されている医用画像を所定の条件に従って削除する削除手段と、
   読影を行う医用画像と当該医用画像の読影に関連する先に保存されている医用画像を特定するための関連情報とを含む読影依頼情報を受信する受信手段と、
   前記受信手段で受信した前記読影依頼情報に含まれる関連情報に基づいて、先に保存されている医用画像を特定する医用画像特定手段と、
   前記医用画像特定手段により特定される先に保存されている医用画像であって、前記第１のストレージから削除された医用画像を前記第２のストレージから取得する取得手段と、
   前記先に保存されている医用画像を前記第１のストレージに保存する医用画像保存手段と、
   を有することを特徴とする情報処理装置。
2. 前記情報処理装置は、保存された医用画像が所定の条件で削除される第１のストレージと保存された医用画像が削除されない第２のストレージとの双方に前記受信手段で受信した前記読影依頼情報に含まれる医用画像を保存することを特徴とする請求項１に記載の情報処理装置。
3. 前記関連情報は、受信した医用画像に対応する患者と同一の患者の医用画像と、受信した医用画像と同一の部位の医用画像と、受信した医用画像を取得した検査種別と同一の検査種別の医用画像とを前記受信手段で受信した医用画像と関連する医用画像として先に保存されている医用画像から特定可能な項目であって、複数の前記項目のうち少なくともいずれか一つを含む情報であることを特徴とする請求項１または２に記載の情報処理装置。
4. 前記取得手段は、前記読影依頼情報を受信したことに応じて、前記第２のストレージに先に保存されている医用画像を前記第１のストレージに保存することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記情報処理装置は、読影で参考となった医用画像を示す参考画像の設定を受け付ける参考画像受付手段を更に有し、
   前記医用画像保存手段は、前記医用画像特定手段で特定された医用画像のうち、前記参考画像受付手段で前記設定を受け付けた前記参考画像を優先的に第１のストレージに保存することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記削除手段は、前記参考画像受付手段で参考画像の設定を受付けた医用画像が前記削除手段による削除対象の医用画像であったとしても削除対象外とすることを特徴とする請求項５に記載の情報処理装置。
7. 前記情報処理装置は、前記医用画像の保管状態を管理する保管状態管理手段を更に有し、
   前記保管状態管理手段は、前記削除手段により前記第１のストレージから医用画像を削除した場合には、当該医用画像を削除したことを示す情報を記憶することを特徴とする請求項６に記載の情報処理装置。
8. 第１のストレージに保存された医用画像を第２のストレージに保存する情報処理装置を含む情報処理システムであって、
   前記第1のストレージに保存されている医用画像を所定の条件に従って削除する削除手段と、
   読影を行う医用画像と当該医用画像の読影に関連する先に保存されている医用画像を特定するための関連情報とを含む読影依頼情報を受信する受信手段と、
   前記受信手段で受信した前記読影依頼情報に含まれる関連情報に基づいて、先に保存されている医用画像を特定する医用画像特定手段と、
   前記医用画像特定手段により特定される先に保存されている医用画像であって、前記第１のストレージから削除された医用画像を前記第２のストレージから取得する取得手段と、
   前記取得手段で取得した医用画像を前記第１のストレージに保存する医用画像保存手段と、
   を有することを特徴とする情報処理システム。
9. 第１のストレージに保存された医用画像を第２のストレージに保存する情報処理装置の制御方法であって、
   前記情報処理装置の削除手段が、前記第1のストレージに保存されている医用画像を所定の条件に従って削除する削除ステップと、
   前記情報処理装置の受信手段が、読影を行う医用画像と当該医用画像の読影に関連する先に保存されている医用画像を特定するための関連情報とを含む読影依頼情報を受信する受信ステップと、
   前記情報処理装置の医用画像特定手段が、前記受信ステップで受信した前記読影依頼情報に含まれる関連情報に基づいて、先に保存されている医用画像を特定する医用画像特定ステップと、
   前記情報処理装置の取得手段が、前記医用画像特定手段により特定される先に保存されている医用画像であって、前記第１のストレージから削除された医用画像を前記第２のストレージから取得する取得ステップと、
   前記情報処理装置の医用画像保存手段が、前記取得ステップで取得した医用画像を前記第１のストレージに保存する医用画像保存ステップと、
   を含むことを特徴とする情報処理装置の制御方法。
10. コンピュータを、請求項１乃至８のいずれか１項に記載された情報処理装置として機能させるためのプログラム。
    

Images