(第1の実施の形態)
第1の実施形態について図1ないし図11を参照して説明する。
[医療情報システムの全体構成]
図1に示すように、第1の実施形態に係る医療情報システムSは、ユーザ(例えば、医師や技師など)が使用する複数のクライアント端末1A及び1Bと、システム運営者が提供するテナント型医療情報システム2と、アプリ(アプリケーションの略)提供者により提供されるアプリケーションを管理する複数のアプリサーバ3A及び3Bと、医療画像を取得する医療画像診断装置4と、医療機関内の各種管理システム構築用の管理サーバ5とを備えている。これらの各部は、有線又は無線等の通信ネットワークNを介して接続されており、互いに通信が可能に形成されている。
クライアント端末1A及び1Bは、ユーザである医師や技師によって使用される情報端末である。これらのクライアント端末1A及び1Bとしては、例えば、PC(パーソナルコンピュータ)やWS(診療ワークステーション)等が挙げられ、さらに、携帯型の端末(携帯端末)が用いられても良い。このようなクライアント端末1A及び1Bは、少なくともユーザの操作を受け付ける入力部と、各種処理を行うCPUを有する処理部と、処理内容やユーザの要求に基づいてテナント型医療情報システム2によって収集された医療情報等を表示する表示部(いずれも図示せず)をそれぞれ備えている。
テナント型医療情報システム2は、通信ネットワークNを介してクライアント端末1A又は1Bから送信されるユーザからの要求に基づいて必要な医療情報を収集し、表示レイアウトに沿って要求元のクライアント端末1A又は1Bに表示させる。すなわち、テナント型医療情報システム2は、ユーザが患者の診断や検査等において必要とする医療情報をユーザの要求に応じて収集し、要求元のクライアント端末1A又は1Bの表示部に表示させる機能を果たす。ここで、医療情報としては、例えば、カルテ等の文字情報や血液検査等の数値データ及び波形データ、さらに、X線CT装置のような医療画像診断装置4が取得(撮影)する医療画像に関する情報、あるいは、検査レポート等の文字と画像の混在情報等が挙げられる。
このテナント型医療情報システム2は、システム運営者が設けるものであり、ユーザはそのシステムを利用することで、各種アプリケーションを効率よく利用することができる。すなわち、テナント型医療情報システム2には、利用することが可能な単数又は複数のアプリケーションが接続されており、ユーザはテナント型医療情報システム2を介してこれらのアプリケーションを利用し、必要な医療情報を取得することができる。これにより、ユーザが医療情報の取得に当たって、個別に各種のアプリケーションを探し出して利用するといった手間を省くことができる。また、ユーザ自ら医療情報の収集を行う場合には、多くの場合、どうしても自らの思考(嗜好)に合った特定のアプリケーションを利用しがちであるが、テナント型医療情報システム2を利用することで、特定のアプリケーションにその利用が集中することなく、適宜適切なアプリケーションが選択され、当該選択されたアプリケーションによる処理がなされた医療情報を取得することができる。
このようなテナント型医療情報システム2では、システム運営者が「大家」という位置付けにあり、一方、選択して利用されるアプリケーションを提供するアプリ提供者は、いわば「店子」の位置付けとなる。従って、大家(システム運営者)が設けるテナント型医療情報システム2内には店子(アプリ提供者)がアプリケーションを提供しており、この点を示して「テナント」と表わしている。ユーザは自分が要求する医療情報を取得するに当たって、テナントであるアプリ提供者が提供する各種アプリケーションを利用する。
なお、前述のテナント型医療情報システム2は、医療機関内に設けられていても良く、あるいは、クラウド・コンピューティング技術を用いて医療機関外に設けられていても良い。さらに、医療機関ごとに設けられていても、あるいは、複数の医療機関で共有されていても良い。
アプリサーバ3A及び3Bは、テナント型医療情報システム2と通信ネットワークNを介して接続され、テナント型医療情報システム2の要求に応じて、ユーザが必要としている医療情報の生成をアプリ提供者によって提供されるアプリケーションを用いて行う。すなわち、アプリサーバ3A及び3Bは、アプリ提供者が提供するアプリケーションを記憶するとともに、ユーザの要求に従って、必要とされる医療情報をそれぞれ生成する。より詳細には、ユーザがクライアント端末1A又は1Bを介して要求をテナント型医療情報システム2に送信すると、テナント型医療情報システム2内において当該要求に最適なアプリケーションが選択され、そのアプリケーションを備えるアプリサーバ3A又は3Bに対して、医療情報の生成が依頼される。依頼されたアプリサーバ3A又は3Bでは、要求に応じて医療情報を生成し、改めてテナント型医療情報システム2に送信する。アプリサーバ3から生成された医療情報を受信したテナント型医療情報システム2では、この医療情報を要求元のユーザのクライアント端末1A又は1Bにまとめて(統合して)表示させる。
なお、アプリサーバ3A及び3Bは、格納するアプリケーションごとやその種類ごとに設けられていても良く、あるいは、アプリ提供者ごとに設けられていても良い。後者の場合には、アプリ提供者が提供するアプリケーションがまとめて1つのアプリサーバ3A又は3B内に単数あるいは複数記憶されている。
医療画像診断装置4は、被検体を撮影してその内部情報を取得する医療画像取得(撮影)装置である。この医療画像診断装置4としては、例えば、上述したようにX線CT装置や磁気共鳴診断装置等が用いられる。医療画像診断装置4において取得された各撮影データは、テナント型医療情報システム2に送信されて格納(記憶)される。また、図1には示していないが、例えば、通信ネットワークNに接続されている画像サーバ等に記憶されていても良い。
管理サーバ5は、例えば、医療機関内において病院情報管理システム(HIS)や放射線部門情報管理システム(RIS)、医療画像管理システム(PACS)等を構築するサーバである。この管理サーバ5に入力された各種情報は、併せてテナント型医療情報システム2にも送られ、ユーザからの要求に対処する際に用いられる。
通信ネットワークNは、クライアント端末1A及び1B、テナント型医療情報システム2、アプリサーバ3A及び3B、医療画像診断装置4及び管理サーバ5をそれぞれつなぎ、互いの間で、例えば医療情報のやりとり(通信)を可能とする。この通信ネットワークNの例としては、LAN(Local Area Network)やインターネット等の通信ネットワークが挙げられる。また、この通信ネットワークNで使用される通信規格は、DICOM(Digital Imaging and Communication in Medicine)等、いずれの規格であっても良い。
このような医療情報システムSでは、図1に示すように、通信ネットワークNに二つのクライアント端末1A及び1Bが接続されており、また、二つのアプリサーバ3A及び3Bが接続されているが、それらの数は限定されるものではなく、単数あるいは複数のいずれでも良く、その数は任意である。また、医療画像診断装置4は1つのみ通信ネットワークNに接続されているが、この数も限定されるものではなく任意である。
[テナント型医療情報システムの構成]
次に、前述のテナント型医療情報システム2の内部構成について図2を参照して説明する。
図2に示すように、テナント型医療情報システム2は、医療情報管理部2Aと、医療情報提供部2Bとの大きく2つの部分に分かれている。医療情報管理部2Aは、医療画像診断装置4が取得した医療画像やレポート等の医療情報を保管及び管理する。一方、医療情報提供部2Bは、ユーザからの要求を受け付けてユーザに必要な医療情報を生成して提供する機能を備えている。
医療情報管理部2Aは、医療情報マネージャ21と、医療情報データベース22とから構成されている。医療情報マネージャ21は、医療画像診断装置4によって取得された医療画像やレポート等の医療情報を管理する。一方、医療情報データベース22は、医療情報マネージャ21を介して医療画像診断装置4から送られてきた医療情報を記憶する。
医療情報提供部2Bは、統合ビューア23と、ワークフローマネージャ24と、設定データベース25と、シンクライアントマネージャ26と、アプリケーション27と、課金エンジン28と、課金データベース29とから構成されている。これらの各部の機能を情報の流れに沿って以下に説明する。
統合ビューア23は、まずユーザが使用するクライアント端末1A又は1Bからの要求を受信する。受信された要求は、ワークフローマネージャ24に送信される。このとき、例えば、要求は、管理サーバ5からの情報と突き合わせてまとめられ、ワークフローマネージャ24に送信される。
ワークフローマネージャ24は、ユーザからの要求に応じて、統合ビューア23から送信された情報に基づき、ユーザが必要としている医療情報の生成を行う上で適切なアプリケーションを選択する。このワークフローマネージャ24には、設定データベース25が接続されている。
設定データベース25は、テナント型医療情報システム2に接続されているアプリサーバ3A及び3Bにより提供されるアプリケーションに関する情報を記憶している。そこで、ワークフローマネージャ24が適切なアプリケーションを選択する際には、設定データベース25を検索して該当するアプリケーションに関する情報を取得する。
シンクライアントマネージャ26は、アプリサーバ3A及び3Bに通信ネットワークNを介して接続されており、ワークフローマネージャ24によって選択されたアプリケーションを提供するアプリサーバ3A又は3Bを制御して、ユーザからの要求に応じた医療情報の生成をアプリケーションに実行させる。その後、アプリサーバ3A又は3Bにおいて生成された医療情報は、シンクライアントマネージャ26を介して統合ビューア23に送信される。
統合ビューア23は、シンクライアントマネージャ26から送信された医療情報を受信し、それぞれの医療情報を予め定められた表示レイアウトに沿って統合する。この統合ビューア23によって統合された医療情報は、要求元のユーザが使用するクライアント端末1A又は1Bの表示部に表示される。
ここで、アプリケーション27(アプリケーションA)は、システム運営者が提供するアプリケーションの1つである。つまり、アプリケーション27は、アプリ提供者がアプリケーションを提供するのと同じように、テナント型医療情報システム2を運営するシステム運営者が自ら提供するアプリケーションである。このアプリケーション27は、システム運営者が提供するアプリケーションであることから、例えば、クライアント端末1A又は1Bに表示される基本的な画面設定に関するアプリケーション、あるいは、医療情報管理部2Aに記憶されている医療情報の処理を行うアプリケーションである。
なお、図2では、1つのアプリケーション27(アプリケーションA)が統合ビューア23に接続されているが、これに限るものではなく、システム提供者が提供するアプリケーションは統合ビューア23に複数接続されても良く(テナント型医療情報システム2内に設けられている)、その数は限定されない。
課金エンジン28は、ユーザがアプリケーションを利用した場合に、その利用量に応じて課金し、ユーザに請求する利用料金を算出する。利用料金は、利用量ごとはもちろん、例えば、アプリケーションごと、アプリ提供者ごとにもそれぞれ設定されている。これらアプリケーションの利用料金に関する情報は、課金データベース29に予め記憶されている。そこで、課金エンジン28は、統合ビューア23からアプリケーションの利用の開始や終了等に関する情報を得て、課金データベース29からアプリケーションの利用料金に関する情報を基にユーザのアプリケーション利用料金を算出する。
次に、前述の統合ビューア23の内部構成について図3を参照して説明する。
図3に示すように、統合ビューア23は、受信部23a、情報解析部23b、情報収集部23c、情報統合部23d及び送信部23eを備えている。受信部23aは、ユーザが使用するクライアント端末1A又は1Bから送信される要求を受信する。情報解析部23bは、その要求に含まれる情報にどのような情報が含まれているのかの確認を行う。情報収集部23cは、ユーザからの要求に含まれる、例えば患者情報を基に、テナント型医療情報システム2で受信する各種情報の中から当該患者に関連する情報を選択して抽出する。その後、送信部23eは、情報収集部23cにより抽出された患者に関する患者関連情報、さらに、ユーザからの要求に関する要求情報を合わせてワークフローマネージャ24に送信する。また、情報統合部23dは、ユーザの要求に応じてアプリケーションにより生成された各医療情報を表示レイアウトに沿って統合する。その後、送信部23eは、統合された情報(統合画像)を要求元のクライアント端末1A又は1Bに送信する。
この統合ビューア23は医療情報を統合的にユーザに提示するアプリケーションである。ただし、本実施形態においては、テナント型医療情報システム2に当該アプリケーションが読み込まれることによって統合ビューア23が実装されることを前提とする。なお、統合ビューア23としては、Webアプリケーション、ファットクライアントアプリケーション、あるいは、シンクライアントアプリケーション等、いずれの実装形態(ソフトウエア)を採用しても良い。また、統合ビューア23は医療情報を統合的にユーザに提示する回路(ハードウエア)としてテナント型医療情報システム2に設けられていても良い。
次いで、前述のワークフローマネージャ24及び設定データベース25の内部構成について図4を参照して説明する。
図4に示すように、ワークフローマネージャ24は、送受信部24aと、推奨アプリ判定部24bと、アプリ推奨部24cとから構成される。このワークフローマネージャ24は、設定データベース25と接続されている。
ワークフローマネージャ24は、医療情報を生成するアプリケーションに関する情報を抽出等するアプリケーションである。ただし、本実施形態においては、テナント型医療情報システム2に当該アプリケーションが読み込まれることによってワークフローマネージャ24が実装されることを前提とする(ソフトウエア)。一方で、ワークフローマネージャ24は医療情報を生成するアプリケーションに関する情報を抽出等する回路(ハードウエア)としてテナント型医療情報システム2に設けられていても良い。
推奨アプリ判定部24bは、要求情報や患者関連情報を基に、設定データベース25に記憶されているアプリケーションに関する情報を検索して抽出する。例えば、要求情報等の中に患者の疾患部位に関する情報が含まれている場合には、その疾患部位をクライアント端末1A又は1Bの表示部に医師や患者にとって理解しやすく、見やすく表示させるに適切なアプリケーションに関する情報を選択する。また、抽出対象となるアプリケーションが設定データベース25に複数記憶されている場合には、例えば、ユーザが通常利用しているアプリケーションを抽出したり、あるいは、シーンに応じてそのユーザがこれまで利用したりしていたアプリケーションとは異なるアプリケーションを抽出することも可能である。また、これまで利用されていたアプリケーションに類似するアプリケーションであって、より安価なアプリケーションに関する情報が登録されていた場合には、これまで利用されていたアプリケーションに替えてその安価なアプリケーションを抽出しても良い。
また、推奨アプリ判定部24bは、実際にアプリケーションを利用して生成される医療情報をどのような配置で統合するかについての表示レイアウト情報についても抽出する。なお、設定データベース25内に記憶されている情報は、上述した各情報に限定されることはない。また、設定データベース25からどの情報を抽出するかについても任意に設定することができる。
アプリ推奨部24cは、ユーザが使用するクライアント端末1A又は1Bの表示部にテナント型医療情報システム2として推奨するアプリケーションの一覧を表示させる機能を有している。予め表示部にこのような推奨のアプリケーションを表示させることによって、ユーザに直接利用したいアプリケーションを要求させることができる。また、複数推奨するアプリケーションがある場合には、その旨のアイコンを表示させることも可能である。
前述の設定データベース25は、アプリ情報記憶部25aと、アプリ利用歴記憶部25bとを有している。この設定データベース25内に設けられている記憶部(テーブル)としては、他の記憶部(テーブル)が設けられても良い。ここでは、実施形態を説明する都合上必要な記憶部のみを挙げているのであって、図示しない他の記憶部が設けられていても良い。
アプリ情報記憶部25aは、アプリ提供者が提供するアプリケーションに関する情報を記憶している。このアプリ提供者が提供するアプリケーションとは、テナント型医療情報システム2に通信ネットワークNを介して接続されているアプリサーバ3Aや3B内のアプリケーションのことである。また、記憶されている内容としては、例えば、アプリケーション識別情報やアプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性、アプリケーション提供者識別情報、アプリケーション起動方法等が挙げられる。このような情報は、アプリケーションに関する情報そのものであるが、その他に、統合ビューア23においてアプリケーションをどのように配置するかに関する情報(表示レイアウト情報)も記憶されている。表示レイアウト情報としては、アプリの統合方法、例えば、画面レイアウトが保持されている。この画面レイアウトには、そのレイアウト内に医療情報を提供したアプリケーションのサーバ識別子やアプリ種別、事前状態などが関連付けられている。なお、記憶方法としては、例えば、情報をXMLファイルのようなテキスト情報としても良く、あるいは、RDBMSのようなデータベースに保管するようにしても良い。
アプリ利用歴記憶部25bは、ユーザによるアプリケーションの利用歴を記憶する。この利用歴に関する情報は、例えば、ユーザからの要求に基づきワークフローマネージャ24により選択されたアプリケーションによって医療情報が生成された場合に、その医療情報がシンクライアントマネージャ26を介して統合ビューア23によって受信されると、その統合ビューア23から送信される。
ここで、利用歴に関する情報としては、アプリケーションに関する情報や利用者に関する情報が挙げられる。それらの両者は互いに関連付けられて記憶されている。アプリケーションに関する情報としては、例えば、アプリケーション識別情報やアプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性、アプリケーション提供者識別情報等を含むアプリケーションの属性情報が挙げられる。また、利用者に関する情報としては、例えば、利用者識別情報や利用者所属情報、利用者契約情報、アプリ利用開始時間、アプリ利用終了時間、アプリ利用時間、アプリ処理時間、アプリ処理データ量、アプリ使用CPU時間等が挙げられる。
なお、前述のアプリ利用歴記憶部25bに記憶されている情報は、課金に際して利用される情報であることから、例えば、セキュリティ強度が高められたRDBMSのようなデータベースに保管されることが望ましい。または、暗号化されたXMLファイルのようなテキスト情報として管理されても良い。
ここで、前述のアプリサーバ3の内部構成について図5を参照して説明すると、図5に示すように、アプリサーバ3A及び3Bは、シンクライアントエンジン31と、アプリケーション32と、画像データベース33とをそれぞれ備えている。シンクライアントエンジン31は、シンクライアントマネージャ26から送信されたアプリケーションに関する情報を受信し、その上でアプリケーション32の制御を行う。また、シンクライアントマネージャ26から送信された医療画像に関する情報は、画像データベース33に格納される。
[ユーザの要求に基づく医療情報の提供の流れ]
次に、前述の医療情報システムSによる医療情報の提供の流れについて図6及び図7を参照して説明する。この医療情報の提供の流れでは、ユーザが自身の診察や検査において必要とする患者の医療情報について、テナント型医療情報システム2に当該医療情報の表示を要求し、この要求に従った医療情報が要求元のユーザの使用するクライアント端末1A又は1Bに表示されるまでの流れが示されている。
図6に示すように、まず、ユーザによってテナント型医療情報システム2(統合ビューア23)に対して必要とされる医療情報の表示が要求されたか否かが確認される(ステップST1)。この確認は、例えば、ユーザがクライアント端末1A又は1Bを使用して統合ビューア23を起動したか否かが、要求を受け付けた統合ビューア23により判断されることによって行われる。
ここで、ユーザが使用するクライアント端末1A又は1Bから統合ビューア23に対して送られる情報としては、例えば、患者情報、当該患者に関して必要とされる医療情報やユーザ自身に関する情報が挙げられる。その他、例えば、取得される医療情報をクライアント端末1A又は1Bの表示部にどのように表示させるかといった表示レイアウトに関する情報や取得した医療情報をどのような場面(シーン)で利用するかという情報が含まれていても良い。
また、患者情報としては、例えば、患者氏名や患者ID、患者の疾患部位等が挙げられる。この患者情報には、例えば、造影検査であるのか否かといった検査の方法に関する情報や検査に利用された医療画像診断装置4の種別といった情報も含まれる。対象の患者に関して必要とされる医療情報は、例えば、疾患部位に関する医療画像や心電図、あるいは、検査結果を示す数値といった情報である。医療情報の生成に当たっては、テナント型医療情報システム2(医療情報システムS)に提供されているアプリケーションのうち、それぞれ要求される医療情報を生成するのに最適なアプリケーションが利用される。
したがって、例えば、患者のX線CT画像を用いて所望の医療情報の取得を要求する場合であって、その医療情報を生成することができるアプリケーションが複数提供されている場合には、ワークフローマネージャ24が各種情報を基に適切なアプリケーションを選択する。その後、アプリケーションに関する情報が抽出され、その情報に基づくアプリケーションによって医療情報が生成される。なお、アプリケーションを選択するにあたっては、ユーザが自らアプリケーションの選択を行い、そのアプリケーションを利用して医療情報の生成を要求することも可能である。
また、ユーザ自身に関する情報としては、例えば、ユーザの氏名やID番号、ユーザが使用するクライアント端末1A又は1Bに関する情報が挙げられる。これらの情報を統合ビューア23に送信する情報に含めることによって、その情報は、例えばユーザが良く利用するアプリケーション等、医療情報を生成するアプリケーションを選択するに当たって有益な情報となり得る。
また、表示レイアウトに関する情報は、必要とする医療情報が複数にわたる場合に、それらの医療情報をクライアント端末1A又は1Bの表示部に表示させる際、どのような配置で表示させるかという情報である。表示する医療情報が1種類の場合には、特に表示部上のレイアウトを気にしなくても良いが、複数の医療情報が表示される場合には、見易さという観点が重要となる。また、医療情報の見易さについては、個々のユーザによっても異なることがあるため、その場合には特に表示レイアウトについての情報が必要となる。
また、医療情報が利用される場面(シーン)に関する情報としては、例えば、ユーザが統合ビューア23に要求する医療情報を通常の診察等で用いるのか、それとも他の診察等で用いるのかという情報が挙げられる。ただし、医療情報が通常の診察等で用いるといっても、その利用される場面は多様である。したがって、アプリケーションに関する情報を抽出及び判定する際に、シーンに関する情報を適宜参照することによって、そのシーンにより要求される(シーンに合った)医療情報の生成に適したアプリケーションに関する情報を抽出及び判定することができる。
ここで、「場面(シーン)」は、一例として、診察や検査に関する場面を想定しており、例えば、「スクリーニング」、「精査」及び「フォローアップ」の3つに大別される。「スクリーニング」は、健診等をやって多くの人を検査してその中から異常が見られる人をピックアップすること、あるいは、ある患者において、症状が出ている部分を検査するとともに、その他の部分(例えば全身)についてもチェックしてみることを表わしている。「精査」は、異常が発見された人を精密に検査すること、すなわち、主原因について進んでいるのか、良性か悪性か等、現状を詳しく確認することを表している。この精査の結果をもって確定診断を行うことができる。「フォローアップ」は、治療後にその患者がどのような状態にあるかを診ること、あるいは、適切な治療方針だったのかといった診断や判断等のチェックである。
これら医療情報が利用される場面(シーン)によって、クライアント端末1A又は1Bの表示部に表示されるアプリケーションの種類や表示レイアウト等は大きく異なる可能性がある。したがって、医療情報が利用される場面を把握して医療情報を生成するに適したアプリケーションを決定することは重要である。
なお、場面(シーン)の特定に当たっては、例えば、上述した「ユーザ自身に関する情報」を利用することができる。このユーザ自身に関する情報としては、例えば、クライアント端末1A又は1Bの設置されている場所が挙げられる。例えば、診察室なのか、検査室なのかによってクライアント端末1A又は1Bの表示部に表示させる医療情報は異なる。診察室からの要求であれば、「フォローアップ」の場面、検査室からであれば「スクリーニング」又は「精査」の場面であると推測することが可能である。
すなわち、統合ビューア23は、管理サーバ5から様々な情報を受信するが、これらの情報を利用することで前述の場面(シーン)の特定を行うことができる。例えば、管理サーバ5から送信される該当する患者に関する検査のオーダ等が用いられる。具体的には、例えば、X線撮影検査が実施済みであり、検査オーダとして心臓についてのCT検査に関する検査オーダが発行されたが、未実施であるという情報が管理サーバ5から統合ビューア23へ送信された場合、現在ユーザが医療情報を利用しようとしている場面(シーン)は心臓CT検査の場面であると判断することができる。
前述のステップST1の処理後、統合ビューア23は、統合ビューア23へ送信される各種情報、すなわち受信する各種情報を確認する(ステップST2)。統合ビューア23には、例えば、管理サーバ5から患者の予約情報や治療に関する情報等、医療機関内で管理されている各種情報が送信されてくる。テナント型医療情報システム2内には、例えば記憶部(図示せず)が設けられており、通信ネットワークNを介して送られてくる情報が記憶されている。
その後、統合ビューア23は、ユーザからの要求に含まれる、例えば患者情報を基に、テナント型医療情報システム2で受信する各種情報の中から当該患者に関連する情報を選択して抽出する(ステップST3)。さらに、統合ビューア23は、当該患者に関する情報を収集した後、ユーザからの要求に関する要求情報、及び、通信ネットワークNを介して管理サーバ5等から送信された情報の中から抽出された当該患者に関する患者関連情報を合わせて、ワークフローマネージャ24へと送信する(ステップST4)。これらの情報は、ワークフローマネージャ24が医療情報を得るために最適なアプリケーションを選択する上で重要な情報となる。
次に、ワークフローマネージャ24は、統合ビューア23から送信された要求情報及び患者関連情報を基に、ユーザが必要とする医療情報が生成可能なアプリケーションに関する情報を設定データベース25のアプリ情報記憶部25aから抽出する(ステップST5)。次いで、ワークフローマネージャ24は、設定データベース25から抽出した医療情報を生成するに適したアプリケーションに関する情報および表示レイアウトに関する情報を統合ビューア23へ送信する(ステップST6)。
その後、統合ビューア23は、ワークフローマネージャ24から情報を受信し、その受信した情報を「アプリケーションに関する情報」と「表示レイアウトに関する情報」とに分ける。その上でアプリケーションに関する情報が示すアプリケーションを利用してユーザが必要とする医療情報を生成するための基となる画像情報を、アプリケーション27(アプリケーションA)により医療情報データベース22から抽出する(ステップST7)。
次いで、統合ビューア23は、アプリケーションに関する情報及び医療情報データベース22から抽出された医療画像に関する情報をシンクライアントマネージャ26へ送信する(ステップST8)。ただし、統合ビューア23は、アプリケーションに関する情報については、自身にも保持しておく。これは、アプリサーバ3A又は3Bでの医療情報の生成が終了し、シンクライアントマネージャ26から生成された医療情報を受領する際に、シンクライアントマネージャ26を介して対象のアプリサーバ3A及び3Bの全てから医療情報が送られてきたか否かを判断する際に用いるためである。
次に、シンクライアントマネージャ26は、受信したアプリケーションに関する情報の内容から、該当するアプリケーションを備えるアプリサーバ3A又は3Bを確認し、対応する適切な店子(アプリ提供者)のアプリサーバ3A又は3Bへと送信する(ステップST9)。
次いで、対象のアプリサーバ3A又は3B内のアプリケーション32は、シンクライアントエンジン31の制御の下、画像データベース33に格納された医療画像に関する情報を基に医療情報を生成する(ステップST10)。そのアプリケーション32によって生成された医療情報は、アプリサーバ3A又は3Bによりシンクライアントエンジン31を介してシンクライアントマネージャ26へ送信される(ステップST11)。
その後、図7に示すように、シンクライアントマネージャ26は、アプリサーバ3A又は3Bから送信されてきた医療情報を受信する(ステップST12)。その後、シンクライアントマネージャ26は、ユーザからの要求に基づいて生成される医療情報の全てを受信したか否かを確認する(ステップST13)。
前述のステップST13において、全てのアプリサーバ3A及び3Bからユーザの要求に対応する医療情報の全てを受信していないと判断された場合には(ステップST13のNO)、全ての医療情報が送信されてくるまで処理が待機する。一方、ステップST13において、全ての医療情報がアプリサーバ3から送信されシンクライアントマネージャ26が受信したことが確認された場合(ステップST13のYES)、シンクライアントマネージャ26は、全ての医療情報を統合ビューア23に対して送信する(ステップST14)。
このステップST14では、全ての医療情報がアプリサーバ3A又は3Bからシンクライアントマネージャ26へと送信されたことをもって統合ビューア23へと当該医療情報を送信することとしているが、シンクライアントマネージャ26はアプリサーバ3A又は3Bから医療情報を受信したら、その都度統合ビューア23へ送信することとしても良い。
なお、図6に戻り、ステップST6において、受信した情報のうち、表示レイアウトに関する情報については、シンクライアントマネージャ26を介してアプリサーバ3A又は3Bに送られることはなく、統合ビューア23内にて保持される(ステップST15)。この表示レイアウトに関する情報は、統合ビューア23が生成された医療情報をクライアント端末1A又は2Bにて表示する際に利用する情報である。
図7に戻り、ステップST14の処理後、統合ビューア23は、アプリケーション32を利用して生成された医療情報を受信するとともに、ユーザがクライアント端末1A又は1Bにおいて表示することを必要としている医療情報が全て揃ったか否かを確認する(ステップST16)。
その後、全てが揃っていない場合にはそのまま処理が待機し(ステップST17のNO)、ユーザが要求した医療情報の全てが揃ったことが確認された場合には(ステップST17のYES)、これら集められた医療情報が表示レイアウトに関する情報に基づいて統合ビューア23により統合される(ステップST18)。
前述の統合ビューア23にて統合された情報(統合画像)は、ユーザが使用している要求元のクライアント端末1A又は1Bに表示される(ステップST19)。さらに、統合ビューア23は、シンクライアントマネージャ26から送信された、医療情報の生成の際に利用したアプリケーション32の利用歴についての情報を受信し、ワークフローマネージャ24や課金エンジン28へ送信する(ステップST20)。
以上のような処理によれば、ユーザが必要とする医療情報の要求を行ってから、適切なアプリケーションが選択され、その選択されたアプリケーションによって生成された医療情報が統合され、その上で要求元のクライアント端末1A又は1Bに表示される。
ここで、前述のように医療情報が統合され、クライアント端末1A又は1Bの表示部に表示される統合画像の画面例について図8を参照して説明する。なお、画面例のレイアウトは、あくまでも例示に過ぎず、そのレイアウトは自由に設定することが可能である。また、このレイアウトはワークフローマネージャ24から統合ビューア23に対して送られた表示レイアウトに関する情報に含まれ、その表示レイアウトに関する情報に基づいてその配置が設定される。
図8に示すように、画面例1Aaは、上部に「患者氏名」、「患者ID」及び画像のシリーズに関する情報が表示されている。ただし、この欄にどのような情報を表示させるかについては、任意に設定することが可能である。また、画面例1Aaの下部には、左側に1つの医療画像a1、右側に上下に分けて2つの医療画像a2及びa3が表示されている。
医療画像a1は、例えば、医療画像診断装置4によって取得され、医療情報データベース22に記憶されていた画像である。また、右側上部の医療画像a2は、例えば、アプリケーションA−1によって生成された医療画像であり、右側下部の医療画像a3は、例えば、アプリケーションB−1によって生成された医療画像である。したがって、このような画面例1Aaにおいては、各アプリケーションによって生成された医療画像とともに、これら医療情報としての医療画像生成の基となった医療画像が同じ表示部に示されていることになる。
なお、前述の「アプリケーションA−1」は、例えば、システム運営者がテナント型医療情報システム2内に提供している複数のアプリケーションのうち、「A−1」という種類のアプリケーションを示している。また、「アプリケーションB−1」は、例えば、アプリ提供者が自社のアプリサーバ3A又は3B内に提供している複数のアプリケーションのうち(アプリ提供者が提供しているアプリケーションのうち)、「B−1」という種類のアプリケーションを示している。
このような画面例1Aaの表示によって、例えば、ユーザである医師は医療画像診断装置4によって取得された医療画像a1を基に、医師が指定したアプリケーションにより生成された医療画像a2及びa3を利用して患者に対してより適切な診察及び説明を行うことができる。
[アプリケーションの利用に基づく課金の流れ]
次に、前述の課金エンジン28の内部構成について図9を参照して説明する。
図9に示すように、課金エンジン28は、情報を受信する受信部28aと、利用されたアプリケーションを確認する利用アプリ確認部28bと、そのアプリケーションを利用するに当たって必要とされる基本の料金を検索する料金検索部28cと、検索された基本料金を基に実際に掛かった料金を算出する料金算出部28dと、算出された料金に関する情報をユーザのクライアント端末1A又は1Bに向けて送信する送信部28eとを備えている。
これら各部の詳しい働きについては、以下のアプリケーション利用に基づく課金の流れを説明する際に併せて説明する。なお、以下においては、いずれかのアプリケーションが利用され、ユーザが要求する医療情報が生成された場合に、当該アプリケーション利用に関するユーザへの課金の流れについて図10を参照して説明する。
図10に示すように、統合ビューア23は、まずユーザからの要求を受信し、ワークフローマネージャ24による適切なアプリケーションの選択を経て、当該アプリケーションに関する情報に基づいて、シンクライアントマネージャ26を介してアプリサーバ3A又は3Bに医療情報の生成を依頼する(ステップST31)。ここまでの流れは、図6に示すステップST1ないしステップST9までに示す流れと同じである。
このとき、統合ビューア23は、シンクライアントマネージャ26を介してアプリサーバ3A又は3Bへと医療情報の生成を依頼するとともに、アプリケーションの利用開始通知を課金エンジン28へと送信する(ステップST32)。これは、ユーザの要求に基づいて必要とされる医療画像を取得するために、いずれのアプリケーションが利用されるのか、その利用開始の状態を明確にするためである。この利用開始通知をもって課金エンジン28は各アプリケーションが利用されることを理解する。
なお、利用開始通知には、例えば、アプリケーションに関する情報である、アプリケーション識別情報やアプリケーション名、アプリケーション提供者識別情報等が含まれている。なお、利用開始通知に含まれる情報は、それらに限られるものではなく、その情報にはいずれの情報が含められていても良い。
前述のステップST32の処理後、課金エンジン28は、統合ビューア23からの利用開始通知を利用して、医療情報マネージャ21にアクセスし、医療情報として生成される基となる医療画像のデータサイズを取得する(ステップST33)。
ここで、医療情報マネージャ21は、医療画像診断装置4によって取得された医療画像を受信した際に、例えば、当該医療画像を識別するための識別子と画像サイズ(例えば、データ量(KB))を関連付けて医療情報データベース22に記憶させておく。また、医療情報マネージャ21は、課金エンジン28からのアクセスによって、医療情報として生成される基となる医療画像の識別子を手がかりに、対象の医療画像の画像サイズを医療情報データベース22から取得する。
なお、医療画像の識別子と関連付けられて記憶される情報としては、上述した画像サイズに限られるものではなく、例えば、部位や空間分解能、時間分解能、イメージング機能種別等、いずれの情報であっても良い。課金エンジン28は、医療情報データベース22内に記憶されている情報の種類に合わせて必要とされる情報を入手する。
前述のステップST33の処理後、課金エンジン28の料金検索部28cは、統合ビューア23から取得した情報を基に、課金データベース29から利用されるアプリケーションに関する利用料金の単価を取得する(ステップST34)。
なお、課金データベース29内には、予めテナント型医療情報システム2に提供される各アプリケーションに関する利用料金の単価が記憶されている。そこで、料金検索部28cは、利用開始通知を受信した後、当該単価を検索及び取得して待機する。
ここで、課金データベース29内に記憶されている料金テーブルの一例を示す表について図11を参照して説明する。図11に示すように、表には、最も左側の欄にアプリ提供者から提供されている各アプリケーションが示されている。この欄から右に向けて3つの項目が並んでおり、それぞれ「メモリ使用量(MB)」、「CPU占有率(%)」、「価格(円)/時間」とされる。例えば、アプリケーションBが利用される場合、メモリの使用量は「20MB」であり、CPU占有率は「1%」、時間当たりの価格は「1500円」である。料金検索部28cは、これら単価を対象となるアプリケーションに関する情報を基に検索する。
なお、課金エンジン28が利用開始通知の受信をトリガーとしてアプリケーションの利用単価を検索している間、アプリサーバ3A又は3Bでは、要求された医療情報の生成を行っている。そして上述した通り、医療情報が生成されるとシンクライアントマネージャ26に対して生成された医療情報を送信する。
前述のステップST34の処理後、シンクライアントマネージャ26は、取得した医療情報を統合ビューア23へと送信する(ステップST35)。統合ビューア23は、表示が要求される医療情報の全てが揃ったか否かを確認し(ステップST36、図7に示すステップST16に該当)、全ての医療情報が揃うまで待機する(ステップST37、図7に示すステップST17に該当)。全ての医療情報が揃ったか否かの判断は、統合ビューア23がシンクライアントマネージャ26を介して各アプリサーバ3A又は3Bへ医療情報の生成を依頼する際に保持する、各アプリケーションに関する情報を用いて行われる。
前述のステップST37において、全ての医療情報が揃った場合には(ステップST37のYES)、統合ビューア23は全ての医療情報を表示レイアウトに従って統合するとともに、医療情報生成のためのアプリケーションの利用が終了した旨、利用終了通知を課金エンジン28へと送信する(ステップST38)。
このステップST38では、全てのアプリケーションの利用が終了したことをもって、統合ビューア23から課金エンジン28に利用終了通知を送信しているが、例えば、利用されるアプリケーションによっては、課金操作となる、例えば、レポートの作成といった医療情報が生成されるたびに利用終了通知を送信することとしても良い。
その後、課金エンジン28は、利用終了通知に含まれる、利用されたアプリケーションに関する情報を基に、利用アプリ確認部28bが再度利用されたアプリケーションを確認し、その上で料金算出部28dにおいて、検索した利用単価を基にそれぞれ利用されたアプリケーションに関する利用料金を算出する(ステップST39)。
このステップST39では、料金算出部28dは、例えば、アプリケーションの利用時間、生成された医療情報の枚数、医療情報生成の基となる医療画像のデータサイズ等のアプリケーションの利用状況とそれぞれ定められている単価を基に利用料金を算出する。また、その他、アプリケーションの利用料金については、アプリケーションが利用されている最中に、そのアプリケーションを提供するアプリサーバ3A又は3Bから随時CPUの利用率やメモリの占有率等の各種情報を収集し、これらの情報を基に利用料金を算出することも可能である。
その後、前述のように算出された利用料金は、料金算出部28d、あるいは、統合ビューア23等に保持されて、ユーザの要求や他の操作をトリガーとして課金に関する情報がクライアント端末1A又は1Bの表示部に表示される(ステップST40)。
以上のような処理によれば、ユーザが医療情報を取得するべくアプリケーションを利用した場合に、当該利用に関する課金が行われる。このユーザが利用するアプリケーションはアプリ提供者により医療情報システムSに提供されている。したがって、システム運営者との契約が締結された上でアプリ提供者はそれぞれ自社のアプリケーションを提供することになる。このアプリ提供者とシステム運営者との間の契約において、システム運営者は、例えば、アプリ提供者が提供したアプリケーションがユーザに使用された場合に、その利用態様によってアプリ提供者に対して課金することができる。また、課金の基準が利用態様ではなく、例えば、期間等の指標に対して一定額、といった課金の方法も用いることが可能である。
また、ユーザからのアプリケーションの利用料金について、システム運営者はアプリケーションの利用態様によって、アプリ提供者に対してその利用料金の支払い(分配)を行うことも可能である。
ところで、上述した課金の流れは、ユーザが要求した医療情報をアプリケーションの利用により生成した場合が例に挙げられて説明されている。ただし、ユーザによっては、アプリケーションを利用して完全な形の医療情報を生成することまでは求めず、例えば、簡単に当該アプリケーションを利用するとどのような医療情報が提供されることになるのか、確認のみしたい場合もある。また、例えば、医療情報が複数の項目について数値のみで表わされる場合には、全ての項目を医療情報として提供されることは不要であり、予め選択されるいくつかの項目についてのみ医療情報として提供されることを求める場合もある。このように様々な利用実態が存在する場合には、それぞれの利用実態に合わせて課金を行うことも可能である。
以上説明したように、第1の実施形態によれば、ユーザが必要とする医療情報について、その要求から取得、加えて、アプリケーションの利用に伴う課金の流れまで説明した通り、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとすることで、アプリケーション利用におけるユーザの利便性を向上させることができる。
なお、上述した統合ビューア23から送信された要求情報及び患者関連情報を基に、ユーザが必要とする医療情報が生成可能なアプリケーションに関する情報を設定データベース25から抽出し判定する、というワークフローマネージャ24の働きについては、別の抽出及び判定処理を行うことも可能である。例えば、統合ビューア23から要求情報及び患者関連情報を受信したワークフローマネージャ24は、設定データベース25のアプリ情報記憶部25aからユーザからの要求に適したアプリケーションに関する情報を抽出する際に、経済的な視点を加味してアプリケーションの情報を抽出することが可能である。
(第2の実施形態)
第2の実施形態について図12ないし図15を参照して説明する。
第2の実施形態は基本的に第1の実施形態と同様である。第2の実施形態では、第1の実施形態との相違点について説明し、第1の実施形態で説明した部分と同一部分は同一符号で示し、その説明も省略する。
図12に示すように、第2の実施形態に係るテナント型医療情報システム2は、第1の実施形態に係る各部に加え、レポート作成アプリケーション41及びそのレポート作成アプリケーション41が用いるレポートテンプレートを保管するレポートテンプレートデータベース42を備えている。レポート作成アプリケーション41は統合ビューア23に接続されており、レポートテンプレートデータベース42はそのレポート作成アプリケーション41に接続されている。
ここで、例えば、アプリサーバ3A(アプリサーバB)はアプリケーション32としてアプリケーションBを記憶しており、また、アプリサーバ3B(アプリサーバC)はアプリケーション32としてアプリケーションCを記憶している。これらのアプリケーションB及びアプリケーションCは、どちらも医療画像の解析を行う解析アプリケーションであり、医療画像を解析し、キー画像や解析結果(例えば、各種の数値)などの解析情報を生成する。さらに、アプリケーションB及びアプリケーションCは、それぞれアプリ独自の解析結果を示す解析レポート(独自の解析レポート)を作成して医療情報データベース22に保存する。
レポート作成アプリケーション41は、アプリケーションB及びアプリケーションCによりそれぞれ生成された解析情報をレポートテンプレートの所定項目に入れて統合レポートを作成し、医療情報データベース22に保存する。このとき、レポートテンプレートは、目的に応じてレポートテンプレートデータベース42から選択されて用いられる。
レポートテンプレートデータベース42には、各種のレポートテンプレートが目的(例えば、場面)に関連付けて保管されている。ここで、「場面(シーン)」としては、第1の実施形態と同様に、例えば、「スクリーニング」、「精査」及び「フォローアップ」の3つが挙げられる。なお、目的はシーンに限られるものではなく、例えば、より細かい検査の目的(例えば、検査種類や検査部位など)であっても良く、特に限定されるものではない。
次に、前述のテナント型医療情報システム2を有する医療情報システムSによる医療情報(統合レポート)の提供の流れについて図13を参照して説明する。
図13に示すように、クライアント端末1A又は1Bからの起動要求に応じて、統合ビューア23が起動され、シンクライアントマネージャ26を介してアプリケーションB及びアプリケーションCが起動される(ステップST51)。ここで、前述のように、アプリケーションBはアプリサーバ3A(アプリサーバB)に格納されているアプリケーションであり、アプリケーションCはアプリサーバ3B(アプリサーバC)に格納されているアプリケーションである。なお、統合ビューア23が起動されると、第1の実施形態と同様に医療画像が取得される(図6のステップST1〜ステップST7参照)。
前述のステップST51の処理後、アプリケーションBは、シンクライアントマネージャ26からの要求に応じ、前述の統合ビューア23により取得された医療画像を解析することでキー画像や解析結果(例えば、各種の数値)などの解析情報を生成し、その生成した解析情報をシンクライアントマネージャ26に返す(ステップST52)。なお、キー画像は統合画面の作成に用いられ、解析結果はレポート作成アプリケーション41により用いられる。
加えて、アプリケーションBは、アプリ独自の解析レポートを作成して医療情報データベース22に保存する(ステップST53)。なお、このアプリ独自の解析レポートの作成機能は、必ずしも必要なわけではなく、オプションの機能として存在している。したがって、この機能の有無はシステム提供者やアプリ提供者により必要に応じて変更される。
その後、シンクライアントマネージャ26は、アプリケーションBから送られた解析情報(解析結果)のうちアプリケーションCが必要とするデータをアプリケーションCに送信する(ステップST54)。このとき、送信するデータとしては、例えば、アプリケーションBで扱う数値単位とアプリケーションCで扱う数値単位を一致させるようなマッチング情報(例えば、解析結果の単位情報など)が挙げられる。
次に、アプリケーションCは、シンクライアントマネージャ26から送られたデータ(例えば、マッチング情報)を用い、前述の統合ビューア23により取得された医療画像を解析することでキー画像や解析結果(例えば、各種の数値)などの解析情報を生成し、その生成した解析情報をシンクライアントマネージャ26に返す(ステップST55)。なお、前述と同様に、キー画像は統合画面の作成に用いられ、解析結果はレポート作成アプリケーション41により用いられる。
ステップST55の処理後、アプリケーションCは、アプリ独自の解析レポートを作成して医療情報データベース22に保存する(ステップST56)。なお、前述と同様に、このアプリ独自の解析レポートの作成機能は、必ずしも必要なわけではなく、オプションの機能として存在している。したがって、この機能の有無はシステム提供者又はアプリ提供者により必要に応じて変更される。
その後、シンクライアントマネージャ26は、アプリケーションB及びアプリケーションCからそれぞれ送られた解析情報のうち解析結果をレポート作成アプリケーション41に統合ビューア23を介して送信する(ステップST57)。なお、このとき、シンクライアントマネージャ26は、解析情報のうちキー画像を統合画像作成用として統合ビューア23に送信するが、これに限るものではなく、例えば、レポート作成アプリケーション41がレポート作成のためにキー画像を必要とする場合には、解析結果と共にキー画像を送るようにしても良い。
ステップST57の処理後、レポート作成アプリケーション41は、目的に応じたレポートテンプレートをレポートテンプレートデータベース42から読み出し、読み出したレポートテンプレートの所定項目に、シンクライアントマネージャ26から送信された各解析結果を入れて統合レポートを作成し、その作成した統合レポートを要求元のクライアント端末1A又は1Bに表示させる(ステップST58)。
このステップST58では、統合レポートとして、図14に示すように、画面例1Abが表示される。この画面例1Abは、上部に、「患者氏名」、「患者ID」及びレポートのシリーズに関する情報が表示されている。ただし、この欄にどのような情報を表示させるかについては、任意に設定することが可能である。また、画面例1Abの下部には、左側に編集領域b1、右側に上下に分けて解析結果領域b2及びb3が存在している。
編集領域b1は、例えば、要求元のクライアント端末1A又は1Bによる編集が可能な領域である。この編集領域b1には、各種情報(例えば、コメントや数値など)がクライアント端末1A又は1Bに対するユーザの入力操作によって入力される。また、右側上部の解析結果領域b2には、例えば、アプリケーションBによって得られた解析結果(例えば、各種の数値)が表示され、また、右側下部の解析結果領域b3には、例えば、アプリケーションCによって得られた解析結果(例えば、各種の数値)が表示される。したがって、このような画面例1Abにおいては、アプリケーションB及びアプリケーションCによって得られた解析結果とともに、その解析結果などを見てユーザがコメントなどを入力する編集領域b1が同じ表示部に示されていることになる。
図13に戻り、前述のステップST58の処理後、レポート作成アプリケーション41は、統合レポートが表示されているクライアント端末1A又は1Bに対するユーザの入力操作に応じて統合レポートを編集し、その編集の完了(入力操作に応じて送信された完了信号の受信)に応じて、完成した統合レポートを医療情報データベース22に保存する(ステップST59)。
その後、統合ビューア23は、レポート作成アプリケーション41、さらに、アプリケーションB及びアプリケーションCの利用歴についての情報を取得し、ワークフローマネージャ24や課金エンジン28へ送信する(ステップST60)。その後の課金の流れなどは第1の実施形態と同様である。なお、課金では、アプリ連携に応じて、アプリケーションの組合せや順序、解析結果(内容)、アプリケーション間のデータ送受信内容等を関連付けて保存しておき、その情報を課金に用いるようにしても良い。
ここで、前述のステップST59では、図15に示すように、レポート作成アプリケーション41により作成された統合レポートR1は、患者名や患者IDなどの患者情報に関連付けられると共に、アプリケーションB及びアプリケーションCによりそれぞれ作成されたアプリ独自の解析レポートR2及びR3に関連付けられて保存される。さらに、アプリケーションB独自の解析レポートR2は、アプリケーションBにより生成されたキー画像G1に関連付けられており、同様に、アプリケーションC独自の解析レポートR3も、アプリケーションCにより生成されたキー画像G2に関連付けられている。
これにより、例えば、前述の統合レポートR1の画面例1Abがクライアント端末1A又は1Bに表示された状態で、ユーザがアプリケーションBの解析結果に関する詳細なレポートが見たい場合には、そのアプリケーションBの解析結果が表示されている解析結果領域b2が選択されると(例えば、クリックされると)、アプリケーションBによるアプリ独自の解析レポートR2が表示される。また、アプリケーションCの解析結果に関する詳細なレポートが見たい場合には、そのアプリケーションCの解析結果が表示されている解析結果領域b3が選択されると(例えば、クリックされると)、アプリケーションCによるアプリ独自の解析レポートR3が表示される。
さらに、前述のアプリ独自の解析レポートR2又はR3の表示中に、ユーザが表示中の解析レポートR2又はR3に関連するキー画像G1又はG2が見たい場合には、表示中の解析レポートR2又はR3が選択されると(例えば、クリックされると)、表示中の解析レポートR2又はR3に関連するキー画像G1又はG2が表示される。なお、キー画像G1又はG2の表示は、これ限るものではなく、例えば、解析レポートR2又はR3を表示するときに一緒に表示対象の解析レポートR2又はR3に関連するキー画像G1又はG2を表示するようにしても良い。
ここで、前述のステップST52及びステップST55において取得されたキー画像は、例えば、図8に示すような統合画面として表示される。この統合画像の表示までの流れは第1の実施形態と同様である(図6及び図7参照)。なお、第2の実施形態では、図8に示す右側上部の医療画像a2が、アプリケーションBにより生成されたキー画像(医療画像)であり、右側下部の医療画像a3が、アプリサーバ3BのアプリケーションCにより生成されたキー画像(医療画像)である。
以上説明したように、第2の実施形態によれば、第1の実施形態と同様の効果を得ることができる。さらに、テナント型医療情報システム2により、アプリケーションB及びアプリケーションCによりそれぞれ得られた解析結果をレポートテンプレート(表示レイアウト)に沿って統合することによって統合レポートを生成し、その生成した統合レポートを要求元のクライアント端末1A又は1Bに表示させる。このように、複数のアプリケーション(アプリケーションB及びアプリケーションC)のそれぞれの解析結果が一つにまとめられて統合レポートとして要求元のクライアント端末1A又は1Bに表示されるので、アプリケーションごと解析結果を見るためにそれらのデータを個別に検索する必要もなく、アプリケーション利用におけるユーザの利便性を向上させることができる。
また、アプリケーションB及びアプリケーションCにより解析結果に係る独自の解析レポートR2又はR3を生成し、テナント型医療情報システム2において、アプリケーションB及びアプリケーションCによりそれぞれ生成された独自の解析レポートR2及びR3と、統合レポートR1とを関連付けて保存することから、統合レポートR1に関連する解析レポートR2及びR3を検索することなく容易に表示させることが可能となるので、アプリケーション利用におけるユーザの利便性をより向上させることができる。
また、テナント型医療情報システム2においてアプリケーションB及びアプリケーションCによりそれぞれ生成された独自の解析レポートR2又はR3と、その解析レポートR2又はR3に含まれる解析結果に対応するキー画像G1又はG2とを関連付けて保存することから、解析レポートR2又はR3に関するキー画像G1又はG2を検索することなく容易に表示させることが可能となるので、アプリケーション利用におけるユーザの利便性をより向上させることができる。
また、テナント型医療情報システム2は複数のアプリケーションのうちの第1のアプリケーションBにより生成された解析情報を第2のアプリケーションCに提供し、アプリケーション間の連携を実行することから、複数のアプリケーションを組み合わせた解析を自動的に行うことが可能となるので、アプリケーション利用におけるユーザの利便性をより向上させることができる。例えば、アプリケーション間の連携により各アプリケーションでの単位を統一することを実現することが可能となり、複数のアプリケーションを組み合わせた解析を自動的に行うことができる。
(第3の実施形態)
第3の実施形態について図16ないし図18を参照して説明する。
第3の実施形態は基本的に第2の実施形態と同様である。第3の実施形態では、第2の実施形態との相違点について説明し、第2の実施形態で説明した部分と同一部分は同一符号で示し、その説明も省略する。
図16に示すように、第3の実施形態に係るテナント型医療情報システム2は、第2の実施形態に係る各部に加え、校正に用いる校正パラメータを生成する評価マネージャ51と、その評価マネージャ51により得られた校正パラメータを管理する校正パラメータデータベース52とを備えている。これらの評価マネージャ51及び校正パラメータデータベース52はシンクライアントマネージャ26に接続されている。
ここで、アプリケーションB及びアプリケーションCは、等価な解析アプリケーションであり、どちらも同じ医療画像、すなわち基準データセットを解析し、キー画像や解析結果(例えば、各種の数値)などの解析情報をそれぞれ生成する。
なお、前述の等価な解析アプリケーションとは、基準データセットに対して同じ解析結果を得る解析処理を行うアプリケーションであるが、等価な解析アプリケーションであっても、アプリケーション(アプリ提供者)ごとの設定値(例えば、各種の閾値や解析アルゴリズムなど)の差異により微妙に解析結果が異なってしまう。特に、読影(経過観測)などでは、解析結果の比較を行うことができなくなってしまう。
そこで、評価マネージャ51は、アプリケーションBにより得られた解析結果と、アプリケーションCにより得られた解析結果(どちらもの解析結果も基準データセットに対する解析結果である)とを比較し、それらの解析結果を同じにする校正パラメータをアプリケーションB及びアプリケーションCごとに生成する。
その後、校正パラメータデータベース52は、評価マネージャ51により生成された各校正パラメータをアプリケーションB及びアプリケーションCごとに関連付けて保管する。これにより、校正パラメータデータベース52には、アプリケーションに対応する校正パラメータがアプリケーションごとに格納されることになる。
次に、前述のテナント型医療情報システム2を有する医療情報システムSによるアプリケーション間の解析結果校正の流れについて図17を参照して説明する。
図17に示すように、評価マネージャ51に対する評価機能実行の指示に応じて、シンクライアントマネージャ26を介してアプリケーションB及びアプリケーションCが起動される(ステップST71)。これらのアプリケーションB及びアプリケーションCは、前述の等価な解析アプリケーションである。
ここで、前述の評価機能実行の指示は、例えば、アプリ提供者が新しく提供するアプリケーションをアプリサーバ3A又は3Bに保存すると、その新たなアプリケーションと既存の全アプリケーションとが比較され、その中に新たなアプリケーションと等価なアプリケーションがある場合に出される指示である。
前述のステップST71の処理後、アプリケーションB及びアプリケーションCは、それぞれシンクライアントマネージャ26からの要求に応じ、校正パラメータ生成用の基準データセットを解析してキー画像や解析結果(例えば、各種の数値)などの解析情報を生成し、その生成した解析情報をシンクライアントマネージャ26に返す(ステップST72)。
評価マネージャ51は、シンクライアントマネージャ26を介して各解析結果を取得し、そのアプリケーションBにより得られた解析結果とアプリケーションCにより得られた解析結果とを比較し、それらの解析結果を同じにするための校正パラメータをアプリケーションB及びアプリケーションCごとに生成する(ステップST73)。
なお、ここでは、必要に応じて、校正パラメータを用いて前述のステップST72を行い、再度ステップST73を行って校正パラメータを補正するようにしても良く、さらに、その補正を繰り返すようにしても良い。このような場合には、校正パラメータが適宜補正されるため、アプリケーションB及びアプリケーションC間の解析結果の一致精度を向上させることができる。
前述のステップST73の処理後、校正パラメータデータベース52は、評価マネージャ51により生成された各校正パラメータをアプリケーションB及びアプリケーションCごとに関連付けて保管する(ステップST74)。
このような評価機能実行によって、アプリケーションBとアプリケーションCとの解析結果を同じにする校正パラメータがアプリケーションB及びアプリケーションCごとに得られ、さらに、それらの校正パラメータがアプリケーションB及びアプリケーションCごとに校正パラメータデータベース52に保管されることになる。
その後、図18に示すように、クライアント端末1A又は1Bからの起動要求に応じて、統合ビューア23が起動され、その要求元のクライアント端末1A又は1BからアプリケーションBの利用要求が受信される(ステップST81)。なお、統合ビューア23により第1の実施形態と同様に医療画像が取得される(図6のステップST1〜ステップST7参照)。
前述のステップST81の処理後、シンクライアントマネージャ26は、校正パラメータデータベース52から、アプリケーションBに関連付けられた校正パラメータを選択して読み込み、医療画像と共にその校正パラメータを付与してアプリケーションBを起動する(ステップST82)。
次に、アプリケーションBは、シンクライアントマネージャ26からの要求に応じ、前述の校正パラメータに従った解析パラメータにより医療画像を解析してキー画像や解析結果(例えば、各種の数値)などの解析情報を生成し、その生成した解析情報をシンクライアントマネージャ26に返す(ステップST83)。その後の処理は第2の実施形態、すなわち図13に示すST57以降の処理と同様である。なお、アプリケーションCの利用要求があった場合にも、前述と同じような処理が行われる。
以上説明したように、第3の実施形態によれば、第2の実施形態と同様の効果を得ることができる。さらに、アプリケーションB及びアプリケーションCごとの校正パラメータを用いて解析を行うことによって、等価なアプリケーションB及びアプリケーションCの解析結果が等しくなるので、同じ目的で使用するアプリケーションごとの解析結果の違いを意識することなく、希望のアプリケーションを用いることが可能となる。その結果、アプリケーション利用におけるユーザの利便性をより向上させることができる。
以上、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。