特開2015-228140(P2015-228140A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

▶ キヤノンマーケティングジャパン株式会社の特許一覧
特開2015-228140情報処理装置、情報処理システム、情報処理方法、およびプログラム
<>
  • 特開2015228140-情報処理装置、情報処理システム、情報処理方法、およびプログラム 図000003
  • 特開2015228140-情報処理装置、情報処理システム、情報処理方法、およびプログラム 図000004
  • 特開2015228140-情報処理装置、情報処理システム、情報処理方法、およびプログラム 図000005
  • 特開2015228140-情報処理装置、情報処理システム、情報処理方法、およびプログラム 図000006
  • 特開2015228140-情報処理装置、情報処理システム、情報処理方法、およびプログラム 図000007
  • 特開2015228140-情報処理装置、情報処理システム、情報処理方法、およびプログラム 図000008
  • 特開2015228140-情報処理装置、情報処理システム、情報処理方法、およびプログラム 図000009
  • 特開2015228140-情報処理装置、情報処理システム、情報処理方法、およびプログラム 図000010
  • 特開2015228140-情報処理装置、情報処理システム、情報処理方法、およびプログラム 図000011
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2015-228140(P2015-228140A)
(43)【公開日】2015年12月17日
(54)【発明の名称】情報処理装置、情報処理システム、情報処理方法、およびプログラム
(51)【国際特許分類】
   G06F 12/00 20060101AFI20151120BHJP
   G06Q 50/24 20120101ALI20151120BHJP
【FI】
   G06F12/00 514K
   G06F12/00 501B
   G06Q50/24 140
【審査請求】未請求
【請求項の数】9
【出願形態】OL
【全頁数】17
(21)【出願番号】特願2014-113563(P2014-113563)
(22)【出願日】2014年5月30日
(71)【出願人】
【識別番号】390002761
【氏名又は名称】キヤノンマーケティングジャパン株式会社
(74)【代理人】
【識別番号】100188938
【弁理士】
【氏名又は名称】榛葉 加奈子
(72)【発明者】
【氏名】羽部 高志
【テーマコード(参考)】
5L099
【Fターム(参考)】
5L099AA26
(57)【要約】      (修正有)
【課題】画像ファイルが保存された時に、当該画像とともに後から利用される可能性の高い画像ファイルを特定する。
【解決手段】クライアント端末100から受信した電子ファイルを第1のストレージおよび第2のストレージの双方に保管する情報処理装置であって、受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得手段と、取得した関連情報により特定される電子ファイルに関連する電子ファイルを特定する関連ファイル特定手段と、特定された電子ファイルが第1のストレージに保管されているかを判定する保管状態判定手段と、保管状態判定手段により特定された電子ファイルが第1のストレージに保管されていない場合、第2のストレージから第1のストレージに特定された電子ファイルを複製する複製手段と、を有する。
【選択図】図1
【特許請求の範囲】
【請求項1】
クライアント端末から受信した電子ファイルを第1のストレージおよび第2のストレージの双方に保管する情報処理装置であって、
前記電子ファイルの保管状態を管理する保管状態管理手段と、
前記第1のストレージに保管された前記電子ファイルを定期的に削除する削除手段と、
前記受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得手段と、
前記電子ファイルを受信した場合に前記取得した関連情報により特定される前記電子ファイルに関連する電子ファイルを特定する関連ファイル特定手段と、
前記関連ファイル特定手段により特定された電子ファイルが前記第1のストレージに保管されているかを前記保管状態管理手段で記憶された保管状態に基づいて判定する保管状態判定手段と、を有し、
前記保管状態判定手段により前記特定された電子ファイルが前記第1のストレージに保管されていない場合、前記第2のストレージから前記第1のストレージに当該特定された電子ファイルを複製する複製手段と、
を有することを特徴とする情報処理装置。
【請求項2】
前記電子ファイルは読影を行うための医療画像であって、
前記関連キーは、前記読影の対象となる患者の過去の医療画像を関連する電子ファイルとして特定可能な項目であることを特徴とする請求項1記載の情報処理装置。
【請求項3】
前記関連キーは、前記読影の対象となる医療画像と同一の部位の医療画像を関連する電子ファイルとして特定可能な項目であることを特徴とする請求項2に記載の情報処理装置。
【請求項4】
前記関連キーは、前記読影の対象となる医療画像を取得した検査種別と同一の検査種別の医療画像を関連する電子ファイルとして特定可能な項目であることを特徴とする請求項2または3のいずれか1項に記載の情報処理装置。
【請求項5】
読影診断を行うのに参考になった電子ファイルを受付ける参考画像受付手段を更に有し、
前記削除手段は、当該参考画像として受付けた電子ファイルが前記削除手段による削除対象の電子ファイルであったとしても削除対象外とすることを特徴とする請求項1乃至4のいずれか1項に記載の情報処理装置。
【請求項6】
前記保管状態管理手段は、前記削除手段により削除された電子ファイルの前記第1のストレージに対する保管状態をnullとすることを特徴とする請求項1乃至6のいずれか1項に記載の情報処理装置。
【請求項7】
クライアント端末と当該クライアント端末から受信した電子ファイルを第1のストレージおよび第2のストレージの双方に保管する情報処理装置とからなる情報処理システムであって、
前記電子ファイルの保管状態を管理する保管状態管理手段と、
前記第1のストレージに保管された前記電子ファイルを所定のタイミングで削除する削除手段と、
前記受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得手段と、
前記電子ファイルを受信した場合前記取得した関連情報により特定される前記電子ファイルに関連する電子ファイルを特定する関連ファイル特定手段と、
前記関連ファイル特定手段により特定された電子ファイルが前記第1のストレージに保管されているかを前記保管状態管理手段に記憶された保管状態に基づいて判定する保管状態判定手段と、を有し、
前記保管状態判定手段により前記特定された電子ファイルが前記第1のストレージに保管されていない場合、前記第2のストレージから前記第1のストレージに当該特定された電子ファイルを複製する複製手段と、
を有することを特徴とする情報処理システム。
【請求項8】
クライアント端末から受信した電子ファイルを第1のストレージおよび第2のストレージの双方に保管する情報処理装置の制御方法であって、
前記電子ファイルの保管状態を管理する保管状態管理ステップと、
前記第1のストレージに保管された前記電子ファイルを所定のタイミングで削除する削除ステップと、
前記受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得ステップと、
前記電子ファイルを受信した場合前記取得した関連情報により特定される前記電子ファイルに関連する電子ファイルを特定する関連ファイル特定ステップと、
前記関連ファイル特定ステップにより特定された電子ファイルが前記第1のストレージに保管されているかを前記保管状態管理ステップで記憶された保管状態に基づいて判定する保管状態判定ステップと、を有し、
前記保管状態判定ステップにより前記特定された電子ファイルが前記第1のストレージに保管されていない場合、前記第2のストレージから前記第1のストレージに当該特定された電子ファイルを複製する複製ステップと、
を有することを特徴とする情報処理装置の制御方法。
【請求項9】
クライアント端末から受信した電子ファイルを第1のストレージおよび第2のストレージの双方に保管する情報処理装置で読み取り可能なプログラムであって、
前記情報処理装置を、
前記電子ファイルの保管状態を管理する保管状態管理手段と、
前記第1のストレージに保管された前記電子ファイルを所定のタイミングで削除する削除手段と、
前記受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得手段と、
前記電子ファイルを受信した場合前記取得した関連情報により特定される前記電子ファイルに関連する電子ファイルを特定する関連ファイル特定手段と、
前記関連ファイル特定手段により特定された電子ファイルが前記第1のストレージに保管されているかを前記保管状態管理手段で記憶された保管状態に基づいて判定する保管状態判定手段と、を有し、
前記保管状態判定手段により前記特定された電子ファイルが前記第1のストレージに保管されていない場合、前記第2のストレージから前記第1のストレージに当該特定された電子ファイルを複製する複製手段と、
を有することを特徴とする情報処理装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理システム、情報処理方法、およびプログラムに関する。
【背景技術】
【0002】
近年、インターネットを利用したパブリックなストレージサービスが提供されるようになり、大量のデータを安価に保管できるようになった。しかしながら大量のデータのやり取りには回線の速度などの問題により時間がかかってしまう場合がある。
【0003】
これに対して回線の速度や品質を保証するようなストレージサービスも存在しているが、利用料金がパブリックなストレージサービスよりも高価な場合が多いという問題があった。
【0004】
特許文献1では、利用者にとってよく利用される情報であるキャッシュ記憶手段と実体を記憶するデータ記憶手段を有していて、アクセス要求を受け付けると当該要求と関連する情報をキャッシュ記憶手段に記憶する技術が提案されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2009−187394号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
患者の主治医から出された依頼(患者の主訴や病歴・家族歴など)をもとに、適正な検査(CT、MRI、血管造影など)を判断し、その検査画像から画像診断を行い、今後さらに必要になると思われる検査や治療方針の助言を行う読影システムにおいては、大量の検査画像を扱うので、システムで取り扱う検査画像は、パブリックなストレージサービスに保管することが多い。そして、最近読影を依頼された検査画像は、速度の速いストレージサービスを利用することが行われている。
【0007】
読影システムでは、読影医が検査画像を見ながら診断を行うのであるが、同じ症例や似た部位の検査画像を見ることがある。この場合、見たい画像が速度の遅いパブリックなストレージサービスに保管されているとファイルの読み出しに時間がかかってしまうので、事前に速度の速いストレージシステムに保存(転送)しておきたいという要望がある。
【0008】
しかしながら特許文献1の発明では、関連する情報をルールとして定義されたものを使って検索している。しかしながら、読影システムの場合、患者の症例によって関連する情報を一意に決定することは難しい。例えば、同じ患者の過去の画像があれば、過去の画像を見たい場合もあるし、患者と同年代の患者の画像を見たい場合もあるので、あらかじめ決まったルールに基づいてルールを設定することは難しい。
【0009】
また、特許文献1においては、検索された時に関連する情報を検索するようにしているが、検索した時に関連する画像を検索するのは遅い場合があり、検査画像が読影システムに保管された時に、読影医によって要求されるであろう関連画像をキャッシュしておくことが望ましい。
【0010】
そこで本発明は、画像ファイルが保存された時に、当該画像とともに後から利用される可能性の高い画像ファイルを特定可能な情報処理装置を提供することを課題とする。
【課題を解決するための手段】
【0011】
クライアント端末から受信した電子ファイルを第1のストレージおよび第2のストレージの双方に保管する情報処理装置であって、前記電子ファイルの保管状態を管理する保管状態管理手段と、前記第1のストレージに保管された前記電子ファイルを定期的に削除する削除手段と、前記受信した電子ファイルに関連する電子ファイルを特定するための関連情報を取得する関連情報取得手段と、前記電子ファイルを受信した場合に前記取得した関連情報により特定される前記電子ファイルに関連する電子ファイルを特定する関連ファイル特定手段と、前記関連ファイル特定手段により特定された電子ファイルが前記第1のストレージに保管されているかを前記保管状態管理手段で記憶された保管状態に基づいて判定する保管状態判定手段と、を有し、前記保管状態判定手段により前記特定された電子ファイルが前記第1のストレージに保管されていない場合、前記第2のストレージから前記第1のストレージに当該特定された電子ファイルを複製する複製手段と、を有する。
【発明の効果】
【0012】
本発明によれば、画像ファイルが保存された時に、当該画像とともに後から利用される可能性の高い画像ファイルを特定可能な情報処理装置を提供することが可能となる。
【図面の簡単な説明】
【0013】
図1】本発明の実施形態に係わる読影システムのシステム構成図の一例を示す図である。
図2】本発明の実施形態に係わるアプリケーションサーバである情報処理装置のハードウェア構成の一例を示すブロック図である。
図3】本発明の実施形態に係わる読影システムのクライアント端末の読影依頼画面の一例を示す図である。
図4】本発明の実施形態に係わる読影システムのクライアント端末の読影画面の一例を示す図である。
図5】本発明の実施形態に係わる読影システムの画像ファイル登録時の処理の一例を示すフローチャートである。
図6】本発明の実施形態に係わる読影システムの画像ファイル取得時の処理の一例を示すフローチャートである。
図7】本発明の実施形態に係わる情報処理装置のキャッシュアウト処理の一例を示すフローチャートである。
図8】本発明の実施形態に係わる読影システムのファイルマスDBの一例を示す図である。
図9】本発明の実施形態に係わる読影システムの各種ユーザマスタテーブルの一例を示す図ある。
【発明を実施するための形態】
【0014】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【0015】
図1は、本発明の実施形態に係わる読影システムのシステム構成図の一例を示す図である。
【0016】
本発明に係る読影システム(情報処理システム)は、クライアント端末100、アプリケーションサーバ101、および外部サーバ102が通信ネットワーク500を介して通信可能に接続されている。
【0017】
読影システムとは、患者の主治医から出された依頼(患者の主訴や病歴・家族歴など)をもとに、読影医が検査や治療方針の助言を行うものであり、クライアント端末100は、読影の依頼元である患者の主治医や、読影を行う読影医により利用される。利用者IDにより利用できるメニューが異なる。
【0018】
例えば、依頼元のクライアント端末100からは、アプリケーションサーバ101に対して、医療画像や患者情報などを付与して読影の依頼を行う。読影医のクライアント端末は、アプリケーションサーバ101から、依頼された読影に関するデータを読み出したり、参考情報として他の患者の画像データ(電子ファイル)を要求したりする。アプリケーションサーバ101ではWEBアプリケーションとして稼働しており、ブラウザを利用して読影システムにアクセス可能になっている。
【0019】
アプリケーションサーバ101は、読影システムが稼働しているサーバであってローカルキャッシュ111、DBMS112、cron113、ローカルキャッシュ管理部114、データ検索部115、および外部サーバ通信部116を有する。
【0020】
外部サーバ102は、例えばクラウドを利用したストレージサービスなどを指す。外部サーバは複数利用することが可能となっている。本実施例の読影システムでは、依頼元のクライアント端末100から依頼されたデータが一旦アプリケーションサーバ101のローカルキャッシュ111と、外部サーバ102に保管される。ローカルキャッシュ111は、アプリケーションサーバのローカルディスクであったり、別途契約する信頼性が高かったり、通信速度が速かったりするストレージを指す。また、ローカルキャッシュ111のデータはcron113を利用し、定期的に古いデータが削除されるものである(これをキャッシュアウトと呼ぶ)。
【0021】
本実施例では、外部サーバ102のように全てのデータは永続的に保管し、必要な時にデータを読み出すストレージサービスを外部ストレージと呼び、アプリケーションサーバ101が通常使うストレージサービスをローカルキャッシュと呼ぶ。
【0022】
またローカルキャッシュには、依頼元100から読影の依頼データから関連キーを取得し、関連キーに合致するデータをデータ検索部115が検索し、外部サーバ102にだけ保管されている場合(ローカルキャッシュ111からは削除済み)は、外部サーバ通信部116によって、該当する外部サーバ102からローカルキャッシュ111に関連画像を読み込んでおく(これをキャッシュインと呼ぶ)。
【0023】
DBMS112には、ファイルマスタDB(図8)、依頼元マスタ、読影医マスタ、および患者マスタ(図9)が記憶されており、アプリケーションサーバは、これらテーブルを利用して必要な情報を画面に表示したり、依頼や回答などの電文に付与したりするのに利用する。
【0024】
図2は、本発明の実施形態に係わるアプリケーションサーバである情報処理装置のハードウェア構成の一例を示すブロック図である。
【0025】
図2に示すように、情報処理装置101では、システムバス200を介してCPU(Central Processing Unit)201、ROM(Read Only Memory)202、RAM(Random Access Memory)203、記憶装置204、入力コントローラ205、音声入力コントローラ206、ビデオコントローラ207、メモリコントローラ208、よび通信I/Fコントローラ209が接続される。
【0026】
CPU201は、システムバス200に接続される各デバイスやコントローラを統括的に制御する。
【0027】
ROM202あるいは記憶装置204は、CPU201が実行する制御プログラムであるBIOS(Basic Input/Output System)やOS(Operating System)や、本情報処理方法を実現するためのコンピュータ読み取り実行可能なプログラムおよび必要な各種データ(データテーブルを含む)を保持している。
【0028】
RAM203は、CPU201の主メモリ、ワークエリア等として機能する。CPU201は、処理の実行に際して必要なプログラム等をROM202あるいは記憶装置204からRAM203にロードし、ロードしたプログラムを実行することで各種動作を実現する。
【0029】
入力コントローラ205は、キーボード/タッチパネル210などの入力装置からの入力を制御する。入力装置はこれに限ったものでなく、マウスやマルチタッチスクリーンなどの、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。
【0030】
ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下(指等でタッチ)することにより、各種の指示を行うことができる。
【0031】
この入力装置を用いて各種通信装置で利用可能な通信宛先に対する宛先を入力するようになっている。
【0032】
音声入力コントローラ206は、マイク211からの入力を制御する。マイク211から入力された音声を音声認識することが可能となっている。
【0033】
ビデオコントローラ207は、ディスプレイ212などの外部出力装置への表示を制御する。ディスプレイは本体と一体になったノート型パソコンのディスプレイも含まれるものとする。なお、外部出力装置はディスプレイに限ったものははく、例えばプロジェクタであってもよい。また、前述のタッチ操作により受け付け可能な装置については、キーボード/タッチパネル210からの入力を受け付けることも可能となる。
【0034】
なおビデオコントローラ207は、表示制御を行うためのビデオメモリ(VRAM)を制御することが可能で、ビデオメモリ領域としてRAM203の一部を利用することもできるし、別途専用のビデオメモリを設けることも可能である。
【0035】
本発明では、ユーザが情報処理装置を通常する場合の表示に用いられる第1のビデオメモリ領域と、所定の画面が表示される場合に、第1のビデオメモリ領域の表示内容に重ねての表示に用いられる第2のビデオメモリ領域を有している。ビデオメモリ領域は2つに限ったものではなく、情報処理装置の資源が許す限り複数有することが可能なものとする。
【0036】
メモリコントローラ208は、外部メモリ213へのアクセスを制御する。外部メモリとしては、ブートプログラム、各種アプリケーション、フォントデータ、ユーザファイル、編集ファイル、および各種データ等を記憶する外部記憶装置(ハードディスク)、フレキシブルディスク(FD)、或いはPCMCIAカードスロットにアダプタを介して接続されるコンパクトフラッシュ(登録商標)メモリ等を利用可能である。
【0037】
通信I/Fコントローラ209、ネットワーク214を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、TCP/IPを用いた通信やISDNなどの電話回線、および携帯電話の3G回線を用いた通信が可能である。
【0038】
なお、記憶装置204は情報を永続的に記憶するための媒体であって、その形態をハードディスク等の記憶装置に限定するものではない。例えば、SSD(Solid State Drive)などの媒体であってもよい。
【0039】
また本実施形態における通信端末で行われる各種処理時の一時的なメモリエリアとしても利用可能である。
【0040】
図3は、本発明の実施形態に係わる読影システムのクライアント端末の読影依頼画面の一例を示す図である。
【0041】
読影依頼画面301は、クライアント端末100から不図示の読影依頼メニューを起動することで表示される。通常は依頼元の主治医または入力担当者によって利用される画面である。依頼元309に表示されているように依頼次郎さんが依頼元としての読影依頼の入力を行っている。
【0042】
依頼先情報302は、依頼先および依頼番号からなっており、依頼先は入力領域をマウスでクリックすることにより表示される、システムに登録されている依頼先から選べるようになっている。また、依頼番号はシステムが一意になるよう自動採番される。
【0043】
患者情報303は、読影される患者に関する情報が記入される。例えば診察カードのようなものを利用し、患者を識別可能な番号をキーに患者マスタから読み込まれたものである。登録されているマスタにより表示される内容は異なる。患者マスタについては図9を利用して後述する。
【0044】
画像情報304は、当該依頼の患者の画像に関する情報である。撮影した画像と対応づいたものが記入される。「画像枚数」は、依頼画像の枚数である。「検査種」がCTとなっているので、CTスキャンされた画像の枚数が50枚あるということであり、「ファイルID」である010は、50枚の画像から構成されることがわかる。「検査部位」は実際に検査された部位であり、検査機器から取得するようにしてもよいし、依頼元のユーザが書き込むようにしてもよい。「検査日時」は、検査が行われた日時、すなわち画像の撮影が行われた日である。
【0045】
依頼情報305は、本依頼に関するサマリとなっており、「依頼医」「優先度」「部位」「検査項目」「検査種」「依頼内容」「関連キー」および「依頼元」が記入される。
【0046】
「依頼医」には読影を行ってもらう読影医が記入される。読影医は読影医マスタ(図9にて後述)から選択できるようになっている。
【0047】
「優先度」は依頼元ユーザが入力するもので、読影医もしくは、読影システムが優先度を考慮して読影の順番を決めることができる。
【0048】
「部位」「検査項目」「検査種」は、それぞれ、検査が行われた部位や検査の種類に関する情報が記入される。
【0049】
「依頼内容」は、依頼元である依頼次郎さんが、依頼である読影太郎さんに向けてのコメントとして利用される。
【0050】
「関連キー」には、「本人画像」「部位」「モダリティ」「年齢」および「参考画像優先」の項目があり、これを依頼元がチェックすることで読影システムは本依頼の関連キーとして登録される。登録された関連キーが関連情報としてアプリケーションサーバに取得される。
【0051】
通常読影医は、患者の検査画像に対して診断を行うときに、本人の過去の画像データや同様の症状を持つ他人の検査画像を参考画像として利用することがある。この時に、読み読み出しに時間のかかる外部ストレージから読み出すのではなく、事前にローカルキャッシュにキャッシュインしておくことで素早く参考画像にアクセスすることができる。
【0052】
関連キーは、依頼時に依頼元のユーザが入力することができる。例えば、「本人画像」にチェックがついている場合は、患者本人の過去の画像を関連ファイルとする。「部位」にチェックがされた場合は、患者の部位と同じ部位の画像を関連ファイルとする。例えば検査部位が胸部の場合は、胸部の検査画像が関連ファイルとなる。「検査種」にチェックが入った場合は、患者の画像を診断した種類と同じ種類の診断画像を関連ファイルとする。例えば検査種がCTの場合は、CT画像が関連ファイルとなる。「年齢」にチェックが入っている場合、患者の年齢と同じ年齢(単位を10才単位や20才単位として区切ることも可能)層を関連ファイルとする。
【0053】
「参考画像優先」にチェックが入っている場合、前述した条件で関連ファイルとして選定されたファイルに優先度をつけることが可能となる。例えば、関連ファイルが多く選定されるとキャッシュインされるファイル数が多くなるので、上限を設定したい場合に有効である。
【0054】
後述する読影画面で、読影医が参考になった(有効であった)画像に対して「参考になった」とチェック入力することで、画像ファイルのファイルマスタDBにその旨が記録され、参考になったとされたファイルを優先的に関連ファイルとしてキャッシュインさせることができる。これにより、参考になったものを優先的にキャッシュインするので効率よく診断ができるようになる。
【0055】
なお、関連キーの各項目は、複数指定することが可能であり、例えば全部にチェックがついている場合、本人の画像で、部位と検査種が同じで、参考画像が優先的に関連画像として選定される。この場合、本人の画像であっても古すぎると年齢が異なるためヒットしない場合があるので、本人画像が選択された場合は、年齢を選択できないようにしてもよい。
【0056】
また、本実施形態では、依頼元のユーザが指定するようにしたが、あらかじめシステムに設定しておくようにしてもよい。
【0057】
依頼画面では複数の読影依頼を入力することが可能で、一覧へ戻る306が押下されると、読影依頼を一覧画面(不図示)で見ることができる。また、矢印キーを押下することで、前の依頼や次の依頼を表示することができる。
【0058】
保存307が押下されると入力した内容が保存され、依頼送信308が押下されるとアプリケーションサーバへ依頼データが送信される。
【0059】
図4は、本発明の実施形態に係わる読影システムのクライアント端末の読影画面の一例を示す図である。
【0060】
読影画面401は、クライアント端末100から不図示の読影メニューを起動することで表示される。通常は読影医によって利用される画面である。利用者410に表示されているように、読影太郎さんが読影を行うための画面である。
【0061】
ワークリスト402は、読影太郎さん宛ての読影依頼が表示されている。「依頼番号」には、図3の依頼画面で入力された内容が依頼番号をキーに表示される。「ステータス」には、読影済みや読影中、読影待ちなどのステータスがシステムによって表示される。本画面においては、「irai−a01」を読影中であるものとして説明する。
【0062】
患者情報403についても同様に図3で入力された患者情報が表示される。
【0063】
画像情報404には、読影する画像(依頼されたもの)を表示する「今回の読影画像」405を表示するエリアと、読影医が参考にしたい(見たい)画像を検索する検索エリア407と、当該検索により検索した画像409が表示されるエリアが表示される。
【0064】
今回の読影画像405には、依頼されたファイルID「010」に対応する画像が表示される。本画像は画像枚数が50枚あるので、スクロールバー406を利用することで全ての画像を表示することが可能である。また、「010−1」「010−・・」のようにファイルIDの後ろに連番が付与されるようになっている。
【0065】
検索エリア407では、検索項目を入力して検索ボタン408を押下することでファイルマスタを検索し、ローカルキャッシュにあれば、そのまま表示し、ローカルキャッシュになければ(外部ストレージにある)、外部ストレージからローカルキャッシュに一度キャッシュインしてからクライアント端末100に表示される。ここで、読影医により検索される可能性の高い画像が、関連キーとして読影依頼時に付与されて、事前にキャッシュインされるようになっている。
【0066】
検索された画像409に表示された画像が読影医にとって有用な情報であるなどして参考になった場合、「参考になった」にチェックを入れるようになっている。このチェックはファイルマスタDBに記憶され、次回以降の関連画像の候補を選定するときの優先順位が高くなるようにすることができる。
【0067】
所見入力409が押下されると、不図示の所見入力画面が起動し、読影医は所見を入力しアプリケーションサーバに送信する。送信が受理されると、ワークリスト402に表示されるステータスが「読影済み」に変更される。
【0068】
図9は、本発明の実施形態に係わる読影システムの各種ユーザマスタテーブルの一例を示す図ある。
【0069】
図3および図4で表示される依頼元情報、読影医情報、および患者情報を表示するためのマスタデータである。いずれのマスタテーブルもDBMS112に記憶されるものである。
【0070】
依頼元マスタ900は、主に図3に示す読影依頼画面を利用するユーザに関するマスタテーブルである。依頼元IDに対応して氏名および依頼元施設が記録されている。ユーザは依頼元IDでシステムにログインし、読影依頼画面にアクセスすると、依頼元として氏名(図3の309)と依頼元施設(図4のワークリスト)がデータに付与され表示に使用される。
【0071】
読影医マスタ910は、主に図4に示す読影画面を利用するユーザに関するマスタテーブルである。読影医IDに対応して氏名および所属が記録されている。ユーザは読影医IDでシステムにログインし、読影画面にアクセスすると、利用者として氏名(図4の410)がデータに付与され表示に使用される
【0072】
患者マスタ920は、読影を受ける患者のマスタテーブルで、患者IDに対応して、氏名、性別、および生年月日が記憶されている。ここに示した患者情報は一例であり、より多くの患者情報を記憶しておくこともできる。患者IDをキーにして各種読影画面上に患者情報が表示される。
【0073】
図5は、本発明の実施形態に係わる読影システムの画像ファイル登録時の処理の一例を示すフローチャートである。
【0074】
ステップS501からステップS504はクライアント端末100の処理、ステップS511からステップS521はアプリケーションサーバ101(情報処理装置)の処理、ステップS531からステップS532は外部サーバ103の処理である。
【0075】
ステップS501でクライアントは、図3に示す読影依頼画面の画像情報304で指定された画像データを受信し、ステップS502では、依頼情報305に含まれる関連キーを受付ける。
【0076】
ステップS503では、受け付けた画像データおよび関連キーをアプリケーションサーバ101に送付する。なお、関連キーについては、アプリケーションサーバにあらかじめ登録されている場合もあるので、その場合は、関連キー以外の情報が送信される。
【0077】
ステップS511でアプリケーションサーバは、画像データと関連キーを受信し、ステップS512で、ローカルキャッシュ111に画像ファイルを保存する。
【0078】
次にステップS513に進み、関連キーと保管先をファイルマスタDBに保管する。ファイルマスタDBについて説明する。
【0079】
図8は、本発明の実施形態に係わる読影システムのファイルマスタDBの一例を示す図である。
【0080】
ファイルマスタDB801は、DBMS112に記憶されており、「ファイルID」「外部格納パス」「ローカル格納パス」「患者名」「検査種/部位」「年齢」「最終参照日時」および「有効画像」の各項目を記憶しており、画像ファイルの保管状態を管理可能となっている。
【0081】
ファイルIDは読影依頼に含まれるファイルIDであって、ファイルマスタDBのキーとなる項目である。
【0082】
外部格納パスは、外部ストレージである外部サーバ102への格納パスであり、ファイルIDをキーにどのファイルがどの外部サーバのどこに格納されているかが分かる。また、外部サーバに記憶されたファイルは契約が解除されたりしない限り永続的に保存されるものなので、必ずパスは記入されるものである。なお、外部サーバが変更された際には、変更後のパスに書き換わるものである。
【0083】
ローカル格納パスは、ローカルキャッシュ111への格納パスであり、所定期間経過後に削除されるものであるので、削除されると格納パスは「null」に変更される。
【0084】
「患者名」「検査種/部位」「年齢」の各項目は、患者に関する情報であって患者マスタから取得して表示するか、読影依頼データの患者情報303から取得して表示する。
【0085】
最終参照日時は、読影医に参照された最終日時であって、図4で検索されて表示された場合は、その日時が最終参照日時として記録される。なお、その場合は、一度消された(キャッシュアウト)画像であってもローカルキャッシュに保存され、ローカル格納パスにもパスが記録される。なお、最終日時情報は日付情報だけでなく、時間/分/秒まで記録しておくことが望ましい。これにより大量の画像データを対象とすることができる。
【0086】
有効画像1、有効画像2については、図4の読影画面で読影医が「参考になった」とチェックした画像に対して付与される。図の例では、ファイルID「001」の画像が、「irai−B01」と「irai−A01」で検索されて参考になったことを意味する。ファイルID「001」は、例えば所定期間経過したのでキャッシュアウトされていたとしても、「2012/12/25」の依頼である「irai−A01」で検索されてローカルキャッシュに保存されているので、最終参照日時に「2012/12/25」と記録されている。
【0087】
また、ローカル格納パスには、「chache/011」と新しいパスが記録される。(本実施例においてローカル格納パスの/より後ろの部分は日付の昇順に付与されるものとする。)
【0088】
このように有効画像のチェックを設けることによって、画像がどれだけ他の読影の参考になったのかを記録しておくことが可能となる。例えば、本実施例では、「001」が2件、「004」「005」「009」でそれぞれ1件ずつ参考になったことが分かる。また依頼番号を付加しているので、依頼の詳細も簡単に参照することができる。
図5のフローチャートの説明に戻る。
【0089】
次にステップS514で登録結果をクライアント端末に返却し、ステップS504で登録結果を受信して、クライアント端末の処理は終了する。
【0090】
ステップS515では、外部サーバにファイルを保管し、ステップS531で外部サーバは対象の画像ファイルを保管する。
【0091】
ステップS516では、外部サーバへの保管先情報を、ファイルマスタDBの外部格納パスに記憶する。
【0092】
次にステップS517では関連キーを使ってファイルマスタDBを検索する。関連キーはステップS511で取得したものを使用する。ここで関連キーとして参考画像優先にチェックがされていた場合、ファイルマスタDBの「有効画像」を持つ画像ファイルを対象としてもよいし、例えば所定ファイル数(例えば50枚)を超える場合は、「有効画像」を持つ画像ファイルを優先して関連ファイルとすることができる。
【0093】
関連キーで検索した結果、関連ファイルとして選定された全てのファイルに対して、ステップS518からステップS521でループ処理され、全ての関連ファイルへの処理が終了すると処理が終了する。
【0094】
ステップS519では対象の関連ファイルがローカルキャッシュに保管されているか(保管状態判定)、すなわち、ファイルマスタDBのローカル格納パスが「null」でないかどうかの判定を行う。
【0095】
「null」でない場合、パスが記録されておりローカルキャッシュに記憶されているということになるので、何もせずステップS518に戻り次の関連ファイルの処理に移る。一方、「null」の場合、ローカルキャッシュからは削除(キャッシュアウト)されたファイルであるので、ステップS520に進み、外部サーバから関連する画像ファイルを取得(複製が作成される)し、ステップS521でファイルマスタDBのローカル格納パスに保存先のパス情報を登録し、ステップS518に戻り、次の関連ファイルの処理に移る。
【0096】
図6は、本発明の実施形態に係わる読影システムの画像ファイル取得時の処理の一例を示すフローチャートである。
【0097】
図4に示す読影画面に画像情報404を表示するためにクライアント端末からアプリケーションサーバに画像データの要求が行われるものである。
【0098】
ステップS601からステップS602はクライアント端末100の処理、ステップS611からステップS617はアプリケーションサーバ101(情報処理装置)の処理、ステップS631は外部サーバ103の処理である。
【0099】
ステップS601で、クライアント端末から画像データリクエストがアプリケーションサーバ100(情報処理装置)に対して送信される。ここでのリクエストには、画像ファイルが1つずつ要求されるものとして説明する。また、一度に複数の画像ファイルの要求を受け付ける場合には、ステップS611からステップS617のアプリケーションサーバの処理が画像ファイルの数だけループされるものとする。
【0100】
ステップS611でリクエストされた画像のファイルIDを取得し、ファイルマスタDBのインデックス情報を検索する。ステップS613では対象の関連ファイルがローカルキャッシュに保管されているか、すなわち、ファイルマスタDBのローカル格納パスが「null」でないかどうかの判定を行う。
【0101】
「null」でない場合、パスが記録されておりローカルキャッシュに記憶されているということになるので、何もせずステップS616に進む。一方、「null」の場合、ローカルキャッシュからは削除(キャッシュアウト)されたファイルであるので、ステップS614に進み、外部サーバのステップS631の処理により関連する画像ファイルを取得(キャッシュイン)し、ステップS615で、ローカル格納パスに保存先のパス情報を登録し、ステップS616に進む。
【0102】
ステップS616では、クライアント端末からリクエストされた画像データを、ローカルキャッシュから送信し、ステップS602では、クライアント端末がリクエストした画像を受信し、クライアントは処理を終了する。
【0103】
ステップS617では、送信した画像データに対して、ファイルマスタDBの最終参照日時を更新して処理を終了する。ここで最終参照日時を更新しておくことで、次回キャッシュアウトされる時の基準を変更することが可能となる。
【0104】
図7は、本発明の実施形態に係わる情報処理装置のキャッシュアウト処理の一例を示すフローチャートである。
【0105】
アプリケーションサーバ101(情報処理装置)でcron113の設定によって定期的(所定のタイミングで)に行われるキャッシュアウトの処理である。
【0106】
cronによって指定された時間に処理が開始される。ステップS701で、ローカルキャッシュの空き容量を取得する。ここで空き容量の閾値を1000テラバイトとすると、ステップS702では、1000テラバイト未満になると空き容量不足となり、1000テラバイト以上空き容量があれば空き容量不足とならない。
【0107】
ステップS702で空き容量不足でない場合は、何もせず処理を終了し、空き容量が不足と判定された場合は、ステップS703に進み、キャッシュアウト候補を決定する。ここでキャッシュアウト候補とは、例えば、最終参照されてから古い順に決まった件数(例えば1万件)をキャッシュアウト候補とする。
【0108】
また、キャッシュアウト候補となったファイルであっても、ファイルマスタDBで「有効画像」として登録さているファイルについてはキャッシュアウトの候補から外すことができる。これにより、参考になった回数の多い画像ファイルについては、再度読まれる可能性があるので、無駄なキャッシュアウト・キャッシュインを防ぐことができる。これは、外部サーバとして、ファイルの送受信に際して課金が発生するような外部ストレージを利用している場合などには特に有効である。
【0109】
ステップS704では、候補となったファイルのキャッシュアウトを行う。キャッシュアウトとは、ローカルキャッシュから該当するファイルを削除することである。削除されると、ステップS705に進み、ファイルマスタのキャッシュ情報を更新してステップS702に戻り、再度空き容量が不足していないかの判定を行う。これは、キャッシュアウトの処理の際中に画像ファイルが新規に登録されたり、キャッシュインされたりした場合に空き容量が不足してしまう場合があるからである。
【0110】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【0111】
また、本発明におけるプログラムは、本発明に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体はコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは各装置の処理方法ごとのプログラムであってもよい。
【0112】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【0113】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
【0114】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、DVD−ROM、磁気テープ、不揮発性のメモリカード、ROM、EEPROM、シリコンディスク、ソリッドステートドライブ等を用いることができる。
【0115】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【0116】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【0117】
また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【0118】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【0119】
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【0120】
100 クライアント端末
101 アプリケーションサーバ
102 外部サーバ
500 通信ネットワーク
図1
図2
図3
図4
図5
図6
図7
図8
図9