JP6266310B2 - 医用情報処理装置 - Google Patents

Description

本発明の実施形態は、医用情報処理装置に関する。

読影用ワークステーションは、医用画像撮影装置により撮影された医用画像を処理して表示することで、ユーザ（読影者）に医用画像を提供するものである。なお、医用画像撮影装置は、被検体内部の情報を収集し、この収集した情報に基づいて被検体内部を画像化して医用画像を得る装置である。この医用画像撮影装置としては、例えば、コンピュータ断層撮影装置（ＣＴ）や磁気共鳴診断装置（ＭＲ）、超音波診断装置（ＵＬ）などが挙げられる。

前述のような読影用ワークステーションにおいて、読影用ワークステーション自身のアプリケーション（自アプリ）以外に、不足しているアプリケーションの補完やユーザの志向を考慮し、異なるデータベース上で動作するアプリケーション（他アプリ）を搭載するケースがある（以後、適宜、アプリケーションをアプリと略す）。自アプリは、読影用ワークステーションのデータベース内のデータをそのまま用いることが可能なアプリケーションであるが、他アプリは前述のデータベース内のデータを自身のデータ形式に変換して用いるアプリケーションである。

他アプリとしては、読影用ワークステーションのデータベースからデータを自身のデータ形式に変換しながら読み込んで処理を行うアプリケーションや、読影用ワークステーションのデータベースからデータを読み込んで自身のデータ形式に変換し、一端、自身のデータベース（キャッシュデータベース）に保存し、その保存したデータを読み込んで処理を行うアプリケーションがある。さらに、読影用ワークステーションのデータベースから全データ（例えば、ひと月分のデータなど）を読み込んで自身のデータ形式に変換し、予め自身のデータベース（キャッシュデータベース）に保存しておくアプリケーションも存在している。

しかしながら、リアルタイムなデータ変換を行う場合には、他アプリ自体にその機能を持たせるため、他アプリを修正する必要が生じることから、アプリ提供者の利便性が低下してしまう。また、データを変換してキャッシュデータベースに保存する場合には、データ変換待ち時間が生じるため、ユーザがデータを選択してから処理が開始するまでに要する時間が長くなってしまう。また、予め全データを変換してキャッシュデータベースに保存する場合には、その分キャッシュデータベースのサイズが大きくなってしまう。

また、他アプリとして、自アプリと似たようなアプリケーションが搭載されるケースもある。自アプリに似たような他アプリが搭載されると、読影者などのユーザがアプリケーションを判別し難くなるため、ユーザの利便性が低下してしまう。さらに、読影用ワークステーションの提供者側にとっても、同様なアプリケーションをメンテナンスしていく必要が出てくるため、提供者の利便性も低下してしまう。

特開２０１０−２４５８６２号公報

本発明が解決しようとする課題は、利便性の向上、処理開始に要する時間の短縮及びデータ記憶容量の低減を実現することができる医用情報処理装置を提供することである。

実施形態に係る医用情報処理装置は、データベースと、データベース内のデータをそのまま用いるアプリケーションである自アプリと、データベース内のデータを変換して用いる他のアプリケーションである他アプリとを含む複数のアプリケーションの中から、使用対象のアプリケーションを判定するアプリ判定部と、アプリ判定部により使用対象のアプリケーションとして他アプリが判定された場合、他アプリが処理する処理対象のデータを読み込み、その読み込んだデータを他アプリのデータ形式に変換するデータ変換部と、データ変換部により変換されたデータを記憶する記憶部とを備え、アプリ判定部は、他アプリよりも自アプリを優先し、使用対象のアプリケーションとして判定する。

第１の実施形態に係る医用情報処理システムの概略構成を示すブロック図である。 第１の実施形態に係る医用情報処理装置の概略構成を示すブロック図である。 第１の実施形態に係るデータ受信時の処理を説明するための説明図である。 第１の実施形態に係るアプリ判定テーブルを示す図である。 第１の実施形態に係るアプリ起動時の処理を説明するための説明図である。 第２の実施形態に係るデータ受信時の処理を説明するための説明図である。 第２の実施形態に係るアプリ判定テーブルを示す図である。 第３の実施形態に係るデータ受信時の処理を説明するための説明図である。 第３の実施形態に係るアプリ判定テーブルを示す図である。 第４の実施形態に係るデータ受信時の処理を説明するための説明図である。 第４の実施形態に係るアプリ利用頻度テーブルを示す図である。 第４の実施形態に係るアプリ判定テーブルを示す図である。 第５の実施形態に係るアプリ判定テーブルの更新を説明するための説明図である。 第５の実施形態に係るアプリボタンの強調を説明するための説明図である。 第６の実施形態に係るデータ受信時の処理を説明するための説明図である。

（第１の実施形態）
第１の実施形態について図１ないし図５を参照して説明する。

図１に示すように、第１の実施形態に係る医用情報処理システム１は、医用画像を撮影する複数（図１では、一例として三台）の医用画像撮影装置２と、検査予約情報を管理する検査予約装置３と、医用情報を処理する医用情報処理装置４とを備えている。これらの各部はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワーク５を介して有線又は無線により通信可能に接続されている。

医用画像撮影装置２は、被検体内部の情報を収集し、この収集した情報に基づいて被検体内部を画像化して医用画像を生成する装置（モダリティ）である。この医用画像撮影装置２としては、例えば、コンピュータ断層撮影装置（ＣＴ）や磁気共鳴診断装置（ＭＲ）、超音波診断装置（ＵＬ）などが挙げられる。なお、生成した医用画像はネットワーク５を介して他の装置（例えば、医用情報処理装置４や画像保管装置など）に送信されて保存される。

検査予約装置３は、検査を受診する患者（受診者）の検査予約に関する検査予約情報を管理する装置である。患者の検査予約情報は予約担当の作業者が検査予約装置３の入力部（例えば、マウスやキーボードなどの入力デバイス）を入力操作することによって検査予約装置３のデータベースに登録される。この検査予約情報は検査予約装置３のデータベースから必要に応じて読み出されて使用される。

ここで、検査予約情報には、例えば、患者に関する患者情報や検査内容に関する検査内容情報などが患者ごとに含まれている。患者情報としては、例えば、患者ＩＤ（識別符号）や氏名、性別、生年月日などがある。また、検査内容情報としては、例えば、検査日や検査部位、使用したモダリティ、検査の依頼科などがある。

医用情報処理装置４は、図２に示すように、データ受信部４ａと、アプリ判定部４ｂと、リスト表示部４ｃと、アプリ起動部４ｄと、複数の自アプリ４ｅと、複数の他アプリ４ｆと、他アプリ４ｆごとのデータ変換部４ｇと、他アプリ４ｆごとのキャッシュ記憶部（キャッシュデータベース）４ｈと、自身のデータベース４ｉとを備えている。

ここで、自アプリ４ｅはデータベース４ｉ内のデータをそのまま用いることが可能なアプリケーションであり、他アプリ４ｆはデータベース４ｉ内のデータを自身のデータ形式に変換して用いるアプリケーションである。第１の実施形態では、例えば、自アプリ４ｅとして、自アプリ１及び自アプリ２が搭載されており、他アプリ４ｆとして、アプリＡ−１、アプリＡ−２、アプリＢ−１、アプリＢ−２、アプリＣ−１及びアプリＣ−２が搭載されている。

これらの自アプリ４ｅや他アプリ４ｆとしては、様々なアプリケーションを用いることが可能であり、例えば、Ｘ線画像の解析に有用なアプリケーションや断層画像から三次元画像を生成するアプリケーション、特定の部位や疾患の解析に有用なアプリケーションなどを用いることが可能である。また、アプリケーションを利用するユーザの好みや能力などに合わせて、同じような機能を有する複数のアプリケーションが存在する場合もある。なお、アプリケーションを開発する会社（アプリ提供者）にはそれぞれ得意な分野があるため、数社のアプリケーションが同じシステム上に存在することが一般的である。

次に、前述の医用情報処理装置４の各部について処理（データ受信時の処理及びアプリ起動時の処理）の流れに沿って図３ないし図５を参照して説明する。

＜データ受信時の処理＞
図３に示すように、データ受信部４ａは、ＣＴやＭＲ、ＵＬなどの医用画像撮影装置２からネットワーク５を介して医用情報の一つである医用画像データ（以下、適宜、医用画像データをデータと略す）を受信し（ステップＳ１）、受信したデータをデータベース４ｉに保存し（ステップＳ２）、さらに、受信したデータの付帯情報をアプリ判定部４ｂに渡す（ステップＳ３）。

ここで、データの付帯情報には、例えば、検査内容に関する検査内容情報や患者に関する患者情報などが含まれている。検査内容情報としては、例えば、検査日や検査部位、使用したモダリティ、検査の依頼科などがある。また、患者情報としては、例えば、患者ＩＤ（識別符号）や氏名、性別、生年月日などがある。この付帯情報によりデータを特定することが可能となり、データは必要に応じてデータベース４ｉから読み込まれて用いられる。

アプリ判定部４ｂは、データ受信部４ａから送信された付帯情報と、アプリ判定情報の一例であるアプリ判定テーブルＴ１（図４参照）との内容を比較し、その比較結果に応じて、適合するアプリケーションが他アプリ４ｆである場合、その適合する他アプリ４ｆに対応するデータ変換部４ｇにキャッシュ保存要求を出す（ステップＳ４）。

例えば、図４に示すように、アプリ判定テーブルＴ１では、医用画像撮影装置２及び部位ごとにアプリケーションが関連付けられている。医用画像撮影装置２がＣＴであって部位が胸部である場合にはアプリＡ−１が設定されており、医用画像撮影装置２がＣＴであって部位が頭部である場合にはアプリＡ−２が設定されている。また、医用画像撮影装置２がＭＲであって部位が胸部である場合にはアプリＢ−１が設定されており、医用画像撮影装置２がＭＲであって部位が頭部である場合にはアプリＢ−２が設定されている。また、医用画像撮影装置２がＣＴ及びＭＲ以外である場合には自アプリ１が設定されている。

このアプリ判定テーブルＴ１が用いられ、例えば、付帯情報に含まれる医用画像撮影装置２がＣＴであって部位が胸部である場合には、適合するアプリケーションとしてアプリＡ−１が特定される。また、付帯情報に含まれる医用画像撮影装置２がＭＲであって部位が頭部である場合には、適合するアプリケーションとしてアプリＢ−２が特定される。また、付帯情報に含まれる医用画像撮影装置２がＣＴ及びＭＲ以外である場合には、適合するアプリケーションとして自アプリ１が特定される。このようにして特定されたアプリケーションが他アプリ４ｆであると、その他アプリ４ｆに対応するデータ変換部４ｇにキャッシュ保存要求が出される。なお、特定されたアプリケーションが自アプリ４ｅである場合には、キャッシュ保存要求は出されない。

前述のキャッシュ保存要求を受けたデータ変換部４ｇは、データベース４ｉから対象のデータ（例えば、ステップＳ２で保存したデータ）を読み込み（ステップＳ５）、その読み込んだデータを対象の他アプリ４ｆ自身のデータ形式に変換してキャッシュ記憶部４ｈに保存する（ステップＳ６）。

＜アプリ起動時の処理＞
図５に示すように、リスト表示部４ｃは、データベース４ｉからリスト情報を取得してモニタに表示する（ステップＳ１１）。リスト情報としては、検査内容情報（又はシリーズ情報）や患者情報などの情報がリスト化されて表示される。

読影者などのユーザは、モニタに表示されたリスト情報を見ながら、マウスやキーボードなどの入力部（例えば、入力デバイスやグラフィカルユーザインターフェイスなど）を入力操作して、リスト情報から任意の検査（検査内容）を選択し、さらに、使用対象（起動対象）のアプリケーションを選択する。

この入力操作に応じて、リスト表示部４ｃは、選択された検査及び使用対象のアプリケーションの情報をアプリケーションランチャ、すなわちアプリ起動部４ｄに渡す（ステップＳ１２）。

アプリ起動部４ｄは、リスト表示部４ｃから送信された情報に基づいて、使用対象のアプリケーションが他アプリ４ｆである場合、その情報内のアプリケーションに対応するデータ変換部４ｇにアプリ起動要求を出す（ステップＳ１３）。このアプリ起動要求には、選択されたアプリケーション（例えば、アプリＩＤ又はアプリ名など）及び検査の情報が含まれている。なお、使用対象のアプリケーションが自アプリ４ｅである場合には、アプリ起動部４ｄは、その自アプリ４ｅに直接アプリ起動要求を出して起動させる。

アプリ起動要求を受けたデータ変換部４ｇは、選択された検査に対応するデータが自身のキャッシュ記憶部４ｈに存在するか否かを判断し、選択された検査に対応するデータが自身のキャッシュ記憶部４ｈに存在すると判断した場合、選択されたアプリケーションを起動させる（ステップＳ１４）。このとき、データ変換部４ｇは、選択された検査に対応するデータをキャッシュ記憶部４ｈから読み込み、起動対象の他アプリ４ｆに渡す（ステップＳ１５）。起動したアプリケーションは、データ変換部４ｇから渡されたデータを受け取って処理を行う。

一方、選択された検査に対応するデータが自身のキャッシュ記憶部４ｈに存在しないと判断した場合には、データベース４ｉから、選択された検査に対応する全データを読み込み（ステップＳ１６）、読み込んだ全データを自身のデータ形式に変換し、対応するキャッシュ記憶部４ｈに保存する（ステップＳ１７）。

その後、データ変換部４ｇは、前述と同様に、選択されたアプリケーションを起動させる（ステップＳ１４）。このとき、データ変換部４ｇは、選択された検査に対応するデータをキャッシュ記憶部４ｈから読み込み、起動対象の他アプリ４ｆに渡す（ステップＳ１５）。起動したアプリケーションは、前述と同様に、データ変換部４ｇから渡されたデータを受け取って処理する。

前述のデータ受信時の処理によれば、データ受信部３ａから渡された付帯情報とアプリ判定テーブルＴ１がアプリ判定部４ｂにより比較され、適合するアプリケーションが特定される。特定されたアプリケーションが他アプリ４ｆであると、その他アプリ４ｆのデータ変換部４ｇにキャッシュ保存要求が出される。キャッシュ保存要求を受けたデータ変換部４ｇにより、データベース４ｉから対象のデータが読み込まれ、自身のデータ形式に変換されてからキャッシュ記憶部４ｈに保存される。このように医用画像撮影装置２から送られたデータが、付帯情報により特定された他アプリ４ｆのデータ形式に変換され、その他アプリ４ｆの起動前に予めキャッシュ記憶部４ｈに記憶されることになる。

また、前述のアプリ起動時の処理によれば、選択された検査に対応するデータが自身のキャッシュ記憶部４ｈに存在するか否かが判断され、選択された検査に対応するデータが自身のキャッシュ記憶部４ｈに存在すると判断された場合には、選択された他アプリ４ｆが起動する。このとき、選択された検査に対応するデータはキャッシュ記憶部４ｈから読み込まれて他アプリ４ｆに渡される。前述のように他アプリ４ｆの起動前に予めデータ変換が終了しているため、このアプリ起動時には、キャッシュ記憶部４ｈからデータを読み込めば良く、データ変換のための待ち時間が無くなる。このため、処理開始に要する時間を短縮することができる。

一方、選択された検査に対応するデータが自身のキャッシュ記憶部４ｈに存在しないと判断された場合には、選択された検査に対応するデータがデータベース４ｉから読み込まれて自身のデータ形式に変換され、対応するキャッシュ記憶部４ｈに保存される。その後、選択された他アプリ４ｆが起動する。このとき、前述と同様に、選択された検査に対応するデータはキャッシュ記憶部４ｈから読み込まれて他アプリ４ｆに渡される。このため、選択された検査に対応するデータが自身のキャッシュ記憶部４ｈに存在しない場合にも、必要なデータ変換を行って処理を行うことが可能となるため、選択された検査に対応するデータが自身のキャッシュ記憶部４ｈに存在しないことに起因して中断などが生じることはなく、処理を継続することができる。

以上説明したように、第１の実施形態によれば、複数のアプリケーションの中から使用対象のアプリケーションを判定し、その判定したアプリケーションが処理する処理対象のデータを読み込み、その読み込んだデータを使用対象のアプリケーションのデータ形式に変換して記憶する。これにより、他のアプリケーション自体にデータ変換を行う機能を持たせる修正を行わなくても、アプリケーションのデータ形式に応じてデータ変換を行うことが可能となるため、アプリ提供者の利便性を向上させることができる。また、処理対象のデータは処理開始前にそのアプリケーション自身のデータ形式に予め変換されており、処理開始時にデータ変換のための待ち時間が無くなるので、処理開始に要する時間の短縮を実現することができる。さらに、処理対象のデータだけが変換されて記憶されるため、データ記憶容量を低減することができる。

（第２の実施形態）
第２の実施形態について図６及び図７を参照して説明する。

第２の実施形態は基本的に第１の実施形態と同様である。このため、第２の実施形態では、第１の実施形態との相違点（特に、アプリ判定時の処理）について説明し、第１の実施形態で説明した部分は同一符号で示し、その説明も省略する。

第２の実施形態に係る医用情報処理装置４は、図６に示すように、第１の実施形態に係る各部に加え、予約に関する予約情報を取得する予約情報取得部１１を備えている。

予約情報取得部１１は、検査予約装置３からネットワーク５を介して検査予約情報を取得し、その取得した検査予約情報をアプリ判定部４ｂに渡す（ステップＳ２１）。この予約情報取得部１１は、例えば、アプリ判定部４ｂが付帯情報から検査の依頼科を取得することができない場合などに、付帯情報内の検査内容情報や患者情報などをキーとして検査予約装置３に問い合わせ、検査予約装置３から必要とする検査予約情報（検査の依頼科を含む）を取得してアプリ判定部４ｂに渡す。

アプリ判定部４ｂは、予約情報取得部１１から渡された検査予約情報と、アプリ判定情報の一例であるアプリ判定テーブルＴ２（図７参照）との内容を比較し、その比較結果に応じて、適合するアプリケーションが他アプリ４ｆである場合、その適合する他アプリ４ｆに対応するデータ変換部４ｇにキャッシュ保存要求を出す（ステップＳ４）。

例えば、図７に示すように、アプリ判定テーブルＴ２では、依頼科ごとにアプリケーションが関連付けられている。依頼科が脳神経外科である場合にはアプリＡ−１が設定されており、依頼科が心臓外科である場合にはアプリＢ−１が設定されており、依頼科が呼吸器科である場合にはアプリＢ−２が設定されている。

このアプリ判定テーブルＴ２が用いられ、例えば、検査予約情報に含まれる依頼科が脳神経外科である場合には、適合するアプリケーションとしてアプリＡ−１が特定され、また、検査予約情報に含まれる依頼科が心臓外科である場合には、適合するアプリケーションとしてアプリＢ−１が特定される。検査予約情報に含まれる依頼科が呼吸器科である場合には、適合するアプリケーションとしてアプリＢ−２が特定される。このようにして特定されたアプリケーション（他アプリ４ｆ）に対応するデータ変換部４ｇにキャッシュ保存要求が出される。

なお、第２の実施形態においては、検査の依頼科に応じて適合するアプリケーションのキャッシュ記憶部４ｈにデータを保存しているが、これに限るものではなく、例えば、依頼科が救急科である場合、すなわち患者が急患（救急）である場合には、どのような処理が必要になるか不明であり、迅速に読影を行う必要があるため、全てのキャッシュ記憶部４ｈに急患のデータを保存するようにしても良い。

以上説明したように、第２の実施形態によれば、前述の第１の実施形態と同様の効果を得ることができる。さらに、付帯情報から必要とする情報を取得することができない場合などでも、検査予約情報を用いて適合するアプリケーションを判定することが可能となるので、利便性の向上、処理開始に要する時間の短縮及びデータ記憶容量の低減を実現することができる。

（第３の実施形態）
第３の実施形態について図８及び図９を参照して説明する。

第３の実施形態は基本的に第１の実施形態と同様である。このため、第３の実施形態では、第１の実施形態との相違点（特に、アプリ判定時の処理）について説明し、第１の実施形態で説明した部分は同一符号で示し、その説明も省略する。

第３の実施形態に係る医用情報処理装置４は、図８に示すように、第１の実施形態に係る各部に加え、ユーザに関するユーザ情報を取得するユーザ情報取得部１２を備えている。

ユーザ情報取得部１２は、現在の利用中のユーザ情報を取得し、その取得したユーザ情報をアプリ判定部４ｂに渡す（ステップＳ３１）。ユーザ情報としては、例えば、現在のユーザを識別可能なユーザＩＤや氏名などが挙げられる。読影者などのユーザは、医用情報処理装置４に対するログイン時（認証行為時）、マウスやキーボードなどの入力部を入力操作し、ユーザ情報を入力する。このユーザ情報がユーザ情報取得部１２により読み込まれてアプリ判定部４ｂに渡される。

アプリ判定部４ｂは、ユーザ情報取得部１２から渡されたユーザ情報と、アプリ判定情報の一例であるアプリ判定テーブルＴ３（図９参照）との内容を比較し、その比較結果に応じて、適合するアプリケーションが他アプリ４ｆである場合、その適合する他アプリ４ｆに対応するデータ変換部４ｇにキャッシュ保存要求を出す（ステップＳ４）。

例えば、図９に示すように、アプリ判定テーブルＴ３では、医用画像撮影装置２ごとにアプリケーションが関連付けられており、さらに、その医用画像撮影装置２ごとのアプリケーション内においてユーザごとにアプリケーションが関連付けられている。医用画像撮影装置２がＣＴであって、ユーザがユーザＡ又はユーザＢである場合には、アプリＡ−１及びアプリＣ−１のうち、アプリＡ−１が設定されており、ユーザがユーザＣである場合には、アプリＣ−１が設定されている。また、医用画像撮影装置２がＭＲであって、ユーザがユーザＡである場合には、アプリＢ−１及びアプリＣ−２のうち、アプリＢ−１が設定されており、ユーザがユーザＢ又はユーザＣである場合には、アプリＣ−２が設定されている。また、医用画像撮影装置２がＣＴ及びＭＲ以外であって、ユーザがユーザＡ又はユーザＣである場合には、自アプリ１及びアプリＢ−２のうち、アプリＢ−２が設定されており、ユーザがユーザＢである場合には、自アプリ１が設定されている。

このアプリ判定テーブルＴ３が用いられ、例えば、付帯情報に含まれる医用画像撮影装置２がＣＴであって、ユーザ情報に含まれるユーザがユーザＡである場合には、適合するアプリケーションとしてアプリＡ−１が特定される。また、付帯情報に含まれる医用画像撮影装置２がＭＲであって、ユーザ情報に含まれるユーザがユーザＢである場合には、適合するアプリケーションとしてアプリＣ−２が特定される。さらに、付帯情報に含まれる医用画像撮影装置２がＣＴ及びＭＲ以外であって、ユーザ情報に含まれるユーザがユーザＣである場合には、適合するアプリケーションとしてアプリＢ−２が特定される。このようにして特定されたアプリケーション（他アプリ４ｆ）に対応するデータ変換部４ｇにキャッシュ保存要求が出される。

以上説明したように、第３の実施形態によれば、前述の第１の実施形態と同様の効果を得ることができる。さらに、ユーザごとに使用アプリをプリセットし、ユーザの好みや能力などに応じて使用アプリを決定することが可能となるので、ユーザに適したアプリケーションを提供することができ、結果として、ユーザの利便性を向上させることができる。

（第４の実施形態）
第４の実施形態について図１０ないし図１２を参照して説明する。

第４の実施形態は基本的に第１の実施形態と同様である。このため、第４の実施形態では、第１の実施形態との相違点（特に、アプリ判定時の処理）について説明し、第１の実施形態で説明した部分は同一符号で示し、その説明も省略する。

第４の実施形態に係る医用情報処理装置４は、図１０に示すように、第１の実施形態に係る各部に加え、利用頻度に関する利用頻度情報を記憶する利用頻度記憶部１３を備えている。

なお、第４の実施形態においては、アプリ起動部４ｄは、アプリケーションを起動させる度に、その起動させたアプリケーションを識別するアプリ識別情報を利用頻度記憶部１３に渡す（ステップＳ４１）。アプリ識別情報としては、例えば、アプリケーションを識別可能なアプリＩＤやアプリ名などが挙げられる。

利用頻度記憶部１３は、アプリ起動部４ｄから渡されたアプリ識別情報に基づき、アプリケーションの利用頻度に関する利用頻度情報の一例、すなわち利用頻度テーブルＴ４を更新して記憶し、その記憶した利用頻度テーブルＴ４を必要に応じてアプリ判定部４ｂに渡す（ステップＳ４２）。

例えば、図１１に示すように、利用頻度テーブルＴ４では、アプリごとに利用回数（起動回数）が記憶されている。図１１では、自アプリ１及びアプリＢ−１の利用回数はそれぞれ４０であり、自アプリ２及びアプリＣ−１の利用回数はそれぞれ２０であり、アプリＡ−１及びアプリＡ−２の利用回数はそれぞれ１０であり、アプリＢ−２及びアプリＣ−２の利用回数はそれぞれ３０である。例えば、アプリ起動部４ｄから送信されたアプリケーションのアプリ識別情報がアプリＡ−１を示していると、アプリＡ−１の利用回数は１０から１１に更新されて記憶される（他のアプリケーションの利用回数の更新も同様である）。

アプリ判定部４ｂは、データ受信部３ａから渡された付帯情報と、アプリ判定テーブルＴ５（図１２参照）との内容を比較し、さらに、利用頻度記憶部１３から利用頻度テーブルＴ４を読み出し、その読み出した利用頻度テーブルＴ４を用いて、適合するアプリケーションが他アプリ４ｆである場合、その適合する他アプリ４ｆに対応するデータ変換部４ｇにキャッシュ保存要求を出す（ステップＳ４）。

例えば、図１２に示すように、アプリ判定テーブルＴ５では、医用画像撮影装置２ごとにアプリケーションが関連付けられている。医用画像撮影装置がＣＴである場合にはアプリＡ−１及びアプリＣ−１が設定されており、医用画像撮影装置がＭＲである場合にはアプリＢ−１及びアプリＣ−２が設定されている。また、医用画像撮影装置がＣＴ及びＭＲ以外である場合には自アプリ１及びアプリＢ−２が設定されている。

このアプリ判定テーブルＴ５が用いられ、例えば、付帯情報に含まれる医用画像撮影装置がＣＴである場合には、アプリＡ−１及びアプリＣ−１が選択され、それらの利用回数が利用頻度テーブルＴ４に基づいて比較され（１０＜２０）、適合するアプリケーションとして利用回数が多いアプリＣ−１が特定される。また、付帯情報に含まれる医用画像撮影装置の種類がＭＲである場合には、アプリＢ−１及びアプリＣ−２が選択され、それらの利用回数が利用頻度テーブルＴ４に基づいて比較され（４０＜３０）、適合するアプリケーションとして利用回数が多いアプリＢ−１が特定される。このようにして特定されたアプリケーション（他アプリ４ｆ）に対応するデータ変換部４ｇにキャッシュ保存要求が出される。

以上説明したように、第４の実施形態によれば、前述の第１の実施形態と同様の効果を得ることができる。さらに、ユーザの利用頻度に応じて使用アプリを決定することが可能となるので、ユーザに適したアプリケーションを提供することができ、結果として、ユーザの利便性を向上させることができる。

（第５の実施形態）
第５の実施形態について図１３及び図１４を参照して説明する。

第５の実施形態は基本的に第１の実施形態と同様である。このため、第５の実施形態では、第１の実施形態との相違点（特に、アプリ判定テーブルの更新及びリスト表示）について説明し、第１の実施形態で説明した部分は同一符号で示し、その説明も省略する。

第５の実施形態では、アプリ判定部４ｂはアプリ判定情報更新部（テーブル更新部）としても機能し、図１３に示すように、アプリ判定情報の一例であるアプリ判定テーブルＴ１を更新する。アプリ判定情報更新部はソフトウェアバージョンアップの検出やサービスマンなどの手動入力の検出に応じてアプリ判定テーブルＴ１を更新する。具体的には、ソフトウェアバージョンアップを検出した場合、そのバージョンアップしたソフトウェアに基づいてアプリ判定テーブルＴ１を自動的に更新したり、また、サービスマンなどによる手動、すなわち入力部に対する入力操作に応じてアプリ判定テーブルＴ１を更新したりする。

例えば、図１３では、自アプリのバージョンアップなどに応じて、ＭＲの頭部を扱うアプリとしてアプリＢ−２に加え自アプリ３を設定し、アプリ判定テーブルＴ１を更新する。このとき、自アプリ３はアプリＢ−２より左側に位置付けられて欄に設定される。なお、左側に位置するアプリの方が優先度の高いアプリとされている。このように、アプリ判定テーブルＴ１は特定のアプリケーション（図１３では、自アプリ３）を優先するように更新される。この更新後のアプリ判定テーブルＴ１が用いられ、例えば、医用画像撮影装置２がＭＲであって部位が頭部である場合には、適合するアプリとして自アプリ３がアプリＢ−２より優先され特定される。したがって、アプリ判定時、アプリ判定部４ｂは優先度が高い自アプリ３を選択することになる。

このようなアプリ判定テーブルＴ１の更新によって自アプリ３を推奨し、アプリＢ−２に対応するキャッシュ記憶部４ｈにデータを保存しないようにする。これにより、アプリＢ−２を残しつつ（移行期間）、自アプリ３を使ってもらうようにする（自アプリなのでキャッシュを行わない）。なお、アプリＢ−２を起動させると、データがキャッシュ記憶部４ｈにないため、必ずデータ変換を行うことになるので、処理開始に要する時間が長くなる。このため、ユーザは、処理開始に要する時間がより短い自アプリ３を使用することが多くなるので、自アプリ３の利用頻度を上げることができる。

また、リスト表示部４ｃは、アプリ判定テーブルＴ１におけるアプリの優先度をチェックし、図１４に示すように、優先度が高い自アプリ３（アプリ３）のボタンＢ１をアプリＢ−２のボタンＢ２よりも強調して表示する。図１４では、一例として、ボタンＢ１が立体的に表示され、アプリＢ−２のボタンＢ２は通常と同じあるいは通常より薄く表示される。このとき、ユーザは自アプリ３に加えアプリＢ−２も選択可能であるが、自アプリ３のボタンＢ１が強調されているため、システムが自アプリ３を推奨していることを認識することができる。

なお、第５の実施形態においては、ボタンＢ１を立体的な表示により強調しているが、これに限るものではなく、例えば、ボタンＢ１を目立つ色により強調しても、あるいは、点滅により強調しても良く、強調手段は特に限定されるものではない。

以上説明したように、第５の実施形態によれば、前述の第１の実施形態と同様の効果を得ることができる。さらに、アプリ判定テーブルＴ１の更新、あるいは、自アプリ４ｅのボタン（例えば、自アプリ３のボタンＢ１）の強調によって、システムの自アプリ４ｅをユーザに推奨することが容易となるので、提供者の利便性を向上させることができる。

例えば、自アプリ４ｅに似たような他アプリ４ｆが搭載されても、自アプリ４ｅが自動的にユーザに対して推奨されるため、ユーザによるアプリケーションの選択が容易となり、ユーザの利便性を向上させることができる。さらに、システムの提供者も特定のアプリケーションのメンテナンスを行っていけば良くなるため、提供者の利便性を向上させることができる。

（第６の実施形態）
第６の実施形態について図１５を参照して説明する。

第６の実施形態は基本的に第１の実施形態と同様である。このため、第６の実施形態では、第１の実施形態との相違点（特に、アプリ判定時の処理）について説明し、第１の実施形態で説明した部分は同一符号で示し、その説明も省略する。

第６の実施形態に係る医用情報処理装置４は、図１５に示すように、第１の実施形態に係る各部に加え、モードを設定するモード設定部１４を備えている。

モード設定部１４は、モードをスピード優先モード又はディスク容量優先モードに設定し、そのモードに関するモード情報をアプリ判定部４ｂに渡す（ステップＳ５１）。なお、モード設定部１４は、読影者などのユーザがマウスやキーボードなどの入力部を入力操作することに応じてモードを切り替える。

ここで、スピード優先モードは、使用可能な全アプリケーション（全ての他アプリ４ｆ）に関して、キャッシュ記憶部４ｈにデータを予め保存しておくモードである。また、ディスク容量優先モードは、キャッシュ記憶部４ｈの容量に応じてデータ保存を制御するモードである。例えば、キャッシュ記憶部４ｈの容量が残り数％（例えば、３％や１０％）になったら、キャッシュ記憶部４ｈへの保存が禁止される。その後、保存が禁止されたキャッシュ記憶部４ｈの残り容量が基準値以上となるまでキャッシュは一切行われない。

アプリ判定部４ｂは、モード設定部１４から送信されたモード情報に基づいて現在のモードを判断し、そのモードがスピード優先モードである場合、全ての他アプリ４ｆのデータ変換部４ｇにキャッシュ保存要求を出す（ステップＳ４）。一方、現在のモードがディスク容量優先モードである場合には、データ受信部３ａから送信された付帯情報と、アプリ判定情報の一例であるアプリ判定テーブルＴ１との内容を比較し、その比較結果に応じて、適合するアプリケーションが他アプリ４ｆである場合、その適合する他アプリ４ｆに対応するデータ変換部４ｇにキャッシュ保存要求を出す（ステップＳ４）。

キャッシュ保存要求を受けたデータ変換部４ｇは、キャッシュ記憶部４ｈの残り容量が基準値以上であるか否かを判断し、キャッシュ記憶部４ｈの残り容量が基準値以上であると判断した場合、データベース４ｉから対象のデータを読み込み（ステップＳ５）、その読み込んだデータを自身のデータ形式に変換してキャッシュ記憶部４ｈに保存する（ステップＳ６）。一方、キャッシュ記憶部４ｈの残り容量が基準値より小さいと判断した場合には、データベース４ｉから対象のデータを読み込んで変換せず、すなわちデータ読み込み及び変換を制限し、キャッシュ記憶部４ｈへの保存を禁止する。

なお、前述のアプリ判定時の処理に第４の実施形態に係る処理を用いた場合には、ディスク容量優先モードにおいて、利用頻度が低いアプリケーションに対応するキャッシュ記憶部４ｈから、キャッシュ記憶部４ｈへのデータ保存が禁止される。ただし、患者が急患（救急）である場合には、キャッシュ記憶部４ｈの残り容量が基準値より小さくても、キャッシュ記憶部４ｈへのデータ保存は許可される。

以上説明したように、第６の実施形態によれば、前述の第１の実施形態と同様の効果を得ることができる。さらに、ユーザが動作モードを切り替えることが可能となるので、スピード優先モード又はディスク容量優先モードを切り替えて希望の優先モードを選択することが可能となるので、ユーザの利便性を向上させることができる。

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

４ 医用情報処理装置
４ｂ アプリ判定部
４ｇ データ変換部
４ｈ キャッシュ記憶部

Claims (10)

1. データベースと、
   前記データベース内のデータをそのまま用いるアプリケーションである自アプリと、前記データベース内のデータを変換して用いる他のアプリケーションである他アプリとを含む複数のアプリケーションの中から、使用対象のアプリケーションを判定するアプリ判定部と、
   前記アプリ判定部により前記使用対象のアプリケーションとして前記他アプリが判定された場合、前記他アプリが処理する処理対象のデータを読み込み、その読み込んだデータを前記他アプリのデータ形式に変換するデータ変換部と、
   前記データ変換部により変換されたデータを記憶する記憶部と、
   を備え、
   前記アプリ判定部は、前記他アプリよりも前記自アプリを優先し、前記使用対象のアプリケーションとして判定することを特徴とする医用情報処理装置。
2. 前記データ変換部は、前記他アプリのデータ形式のデータが前記記憶部にあるか否かを判断し、前記他アプリのデータ形式のデータが前記記憶部にあると判断した場合、前記記憶部から前記他アプリのデータ形式のデータを読み込んで前記他アプリに渡し、前記他アプリのデータ形式のデータが前記記憶部にないと判断した場合、前記他アプリが処理する処理対象のデータを読み込み、その読み込んだデータを前記他アプリのデータ形式に変換することを特徴とする請求項１に記載の医用情報処理装置。
3. 前記アプリ判定部は、医用画像に付帯する付帯情報を用いて、前記複数のアプリケーションの中から前記使用対象のアプリケーションを判定することを特徴とする請求項１に記載の医用情報処理装置。
4. 前記アプリ判定部は、検査予約に関する検査予約情報を用いて、前記複数のアプリケーションの中から前記使用対象のアプリケーションを判定することを特徴とする請求項１に記載の医用情報処理装置。
5. 前記アプリ判定部は、ユーザに関するユーザ情報を用いて、前記複数のアプリケーションの中から前記使用対象のアプリケーションを判定することを特徴とする請求項１に記載の医用情報処理装置。
6. 前記アプリ判定部は、前記複数のアプリケーションの利用頻度に関する利用頻度情報を用いて、前記複数のアプリケーションの中から前記使用対象のアプリケーションを判定することを特徴とする請求項１に記載の医用情報処理装置。
7. 前記アプリ判定部は、前記複数のアプリケーションの中から前記使用対象のアプリケーションを判定するためのアプリ判定情報を有しており、そのアプリ判定情報を特定のアプリケーションを優先して更新することを特徴とする請求項１に記載の医用情報処理装置。
8. 前記アプリ判定部は、モードがスピードを優先するスピード優先モードである場合、前記複数のアプリケーションの全てを前記使用対象のアプリケーションとして判定することを特徴とする請求項１ないし請求項７のいずれか一に記載の医用情報処理装置。
9. 前記データ変換部は、モードが前記記憶部の容量を優先するディスク容量優先モードであり、前記記憶部の容量が基準値より小さい場合、前記他アプリが処理する処理対象のデータを読み込んで前記他アプリのデータ形式に変換することを制限することを特徴とする請求項１ないし請求項７のいずれか一に記載の医用情報処理装置。
10. 前記アプリ判定部は、患者が急患である場合、前記複数のアプリケーションの全てを前記使用対象のアプリケーションとして判定することを特徴とする請求項１ないし請求項７のいずれか一に記載の医用情報処理装置。

Images