以下、本発明の実施の形態について図面を参照して詳細に説明する。
(第1の実施の形態)
[医療情報システムの全体構成]
図1は、実施の形態における医療情報システムSの全体構成を示すブロック図である。医療情報システムSは、ユーザが使用するクライアント端末1と、システム運営者が設置し、通信ネットワークNを介してクライアント端末1から送信されるユーザからの要求に基づいて必要な医療情報を収集し、表示レイアウトに沿ってクライアント端末1に表示させるテナント型医療情報システム2と、テナント型医療情報システム2と通信ネットワークNを介して接続され、テナント型医療情報システム2の要求に応じて、ユーザが必要としている医療情報の生成をアプリ提供者によって提供されるアプリケーションを用いて行うアプリサーバ3とを備える。
さらにこの実施の形態における医療情報システムSには、通信ネットワークNを介して、医療画像診断装置4と、管理サーバ5とが併せて接続されている。
クライアント端末1は、ユーザである、医師、或いは、技師によって使用される情報端末である。このクライアント端末1としては、例えば、PC(パーソナルコンピュータ)や、WS(診療ワークステーション)等が考えられる。また、クライアント端末1が携帯可能であることを否定するものではない。さらに、クライアント端末1は、少なくともユーザの操作を受け付ける入力部と、各種処理を行うCPUを備える処理部と、処理内容やユーザの要求に基づいてテナント型医療情報システム2によって収集された医療情報等を表示する表示部を備えている。
テナント型医療情報システム2は、ユーザが患者の診断、検査等において必要とする医療情報を、ユーザの要求に応じて収集しクライアント端末1の表示部に表示させる機能を果たす。ここで「医療情報」とは、カルテ等の文字情報、血液検査等の数値データや波形データ、X線CT装置のような医療画像診断装置が取得(撮影)する医療画像に関する情報、或いは検査レポート等の文字・画像混在情報等、を含む概念である。
テナント型医療情報システム2は、システム運営者が設けるもので、ユーザは当該システムを利用することで、各種アプリケーションを効率よく利用することができる。すなわち、テナント型医療情報システム2には利用することが可能な単数、または複数のアプリケーションと接続されており、ユーザはテナント型医療情報システム2を介してこれらのアプリケーションを利用し、必要な医療情報を取得することができる。この点、ユーザが医療情報の取得に当たって、個別にアプリケーションを探し出して利用するといった手間を省くことができる。
また、ユーザ自ら医療情報の収集を行う場合には、多くの場合、どうしても自らの思考(嗜好)に合った特定のアプリケーションを利用しがちであるが、この実施の形態におけるテナント型医療情報システム2を利用することで、特定のアプリケーションにその利用が集中することなく、適宜適切なアプリケーションが選択され、当該選択されたアプリケーションによる処理がなされた医療情報を取得することができる。
換言すれば、システム運営者が設けるテナント型医療情報システム2は、このシステム運営者が「大家」という位置付けにあり、一方、選択して利用されるアプリケーションを提供するアプリ提供者は、いわば「店子」の位置付けとなる。従って、大家(システム運営者)が設けるテナント型医療情報システム2内には店子(アプリ提供者)がアプリケーションを提供しており、この点を示して「テナント」と表わしている。ユーザは自分が要求する医療情報を取得するに当たって、テナントであるアプリ提供者が提供する各種アプリケーションを利用する。
なお、テナント型医療情報システム2の詳細な内部構成については、図2を利用して後述する。また、図1に示す医療情報システムSにおいては、テナント型医療情報システム2の設置場所については特に示されていない。従って、テナント型医療情報システム2は、医療機関内に設けられていても良く、或いは、クラウド・コンピューティング技術を用いて医療機関外に設けられていても良い。さらに、各医療機関ごとに設けられていても、或いは、複数の医療機関で共有していても良い。
アプリサーバ3は、アプリ提供者が提供するアプリケーションを記憶するとともに、ユーザの要求に従って、必要とされる医療情報を生成する。より詳細には、ユーザがクライアント端末1を介して要求をテナント型医療情報システム2に送信すると、テナント型医療情報システム2内において当該要求に最適なアプリケーションが選択され、当該アプリケーションを備えるアプリサーバ3に対して、医療情報の生成が依頼される。アプリサーバ3では要求に応じて医療情報を生成し、改めてテナント型医療情報システム2に送信する。
アプリサーバ3から生成された医療情報を受信したテナント型医療情報システム2では、この医療情報を当該要求を出したユーザのクライアント端末1にまとめて(統合して)表示させる。
なお、アプリサーバ3の内部構成については、図面を利用して後述する。また、アプリサーバ3は、格納するアプリケーションごとに設けられていても良く、或いは、アプリ提供者ごとに設けられていても良い。後者の場合、1つのアプリサーバ3内に当該アプリ提供者が提供するアプリケーションが単数、或いは、複数含まれて(記憶されて)いる。
医療画像診断装置4は、被検体を撮影してその内部情報を取得する医療画像取得(撮影)装置である。医療画像診断装置4としては、例えば、上述したようにX線CT装置や磁気共鳴診断装置等が該当する。医療画像診断装置4において取得された各撮影データは、テナント型医療情報システム2に送信されて、後述する画像管理部に格納(記憶)される。また、図1には示していないが、例えば、通信ネットワークNに接続されている画像サーバ等に記憶されていても良い。
管理サーバ5は、例えば、医療機関内に構築されている、上述した病院情報管理システム(HIS)、放射線部門情報管理システム(RIS)、医療画像管理システム(PACS)等が該当する。なお、管理サーバ5に入力された各種情報は、併せてテナント型医療情報システム2にも送られ、ユーザからの要求に対処する際に用いられる。
なお、図1に示す医療情報システムSでは、通信ネットワークNに2つのクライアント端末1Aと1B(以下、適宜これら複数のクライアント端末をまとめて「クライアント端末1」と表わす。)、アプリサーバ3A及び3B(以下、適宜これらのアプリサーバをまとめて「アプリサーバ3」と表わす。)が接続されているが、通信ネットワークNに接続されるクライアント端末1、或いは、アプリサーバ3の数は単数、或いは複数のいずれでも良く、その数は任意である。 また、医療画像診断装置4は、図1では1つのみ通信ネットワークNに接続されているが、この医療画像診断装置4の数についても任意である。
通信ネットワークNは、クライアント端末1、テナント型医療情報システム2、アプリサーバ3、医療画像診断装置4、及び管理サーバ5をそれぞれつなぎ、互いの間で、例えば医療情報のやりとりを可能とする。
通信ネットワークNの例としては、LAN(Local Area Network)やインターネット等の通信ネットワークを挙げることができる。また、この通信ネットワークNで使用される通信規格は、DICOM(Digital Imaging and Communication in Medicine)等、いずれの規格であっても良い。
[テナント型医療情報システムの構成]
図2は、実施の形態におけるテナント型医療情報システム2の内部構成を示すブロック図である。テナント型医療情報システム2は、本体部2Aと画像管理部2Bの大きく2つの部分に分かれている。本体部2Aは、ユーザからの要求を受け付けてユーザに必要な医療情報を生成して戻す機能を備えている。一方、画像管理部2Bは、医療画像診断装置4が取得した医療画像を保管、管理する。
本体部2Aは、統合ビューア21と、ワークフローマネージャ22と、設定データベース23と、シンクライアントマネージャ24と、アプリケーション25(アプリケーションA)と、課金エンジン26と、課金データベース27とから構成されている。また、画像管理部2Bは、画像情報マネージャ28と、画像レポートデータベース29とから構成されている。
各部の機能を情報の流れに沿って説明すると、まず統合ビューア21は、まずユーザが使用するクライアント端末1から要求を受信する。受信された要求は、テナント型医療情報システム2に送信される、例えば、管理サーバ5からの情報と突き合わせて、まとめられてワークフローマネージャ22に送信される。
ワークフローマネージャ22は、ユーザからの要求に応じて(統合ビューア21から送信された情報に基づいて)、ユーザが必要としている医療情報の生成を行う上で適切なアプリケーションを選択する。ワークフローマネージャ22には設定データベース23が接続されている。設定データベース23内には、テナント型医療情報システム2に接続されているアプリサーバ3にて提供されているアプリケーションに関する情報が記憶されている。そこで、ワークフローマネージャ22が適切なアプリケーションを選択する際には、設定データベース23を検索して該当するアプリケーションに関する情報を取得する。
シンクライアントマネージャ24は、図1に示すアプリサーバ3に通信ネットワークNを介して接続されており、ワークフローマネージャ22によって選択されたアプリケーションを提供するアプリサーバ3を制御して、ユーザからの要求に応じた医療情報の生成を行わせる。また、アプリサーバ3において生成された医療情報は、シンクライアントマネージャ24を介して統合ビューア21に送信される。
統合ビューア21は、シンクライアントマネージャ24から送信された医療情報を受信し、それぞれの医療情報を予め定められた表示レイアウトに沿って統合する。統合ビューア21によって統合された医療情報は、ユーザが使用するクライアント端末1の表示部に表示される。
アプリケーション25(アプリケーションA)は、システム運営者が提供するアプリケーションの1つである。つまり、アプリ提供者がアプリケーションを提供するのと同じように、テナント型医療情報システム2を運営するシステム運営者が自ら提供するアプリケーションである。システム運営者が提供するアプリケーションであることから、アプリケーション25(アプリケーションA)は、例えば、クライアント端末1に表示される基本的な画面設定に関するアプリケーション、或いは、画像管理部2Bに記憶、管理されている医療画像の処理を行うアプリケーションである。
なお、図2では、1つのアプリケーション25(アプリケーションA)が統合ビューア21に接続されているが、このようなアプリケーションがどのくらい統合ビューア21に接続されている(テナント型医療情報システム2内に設けられている)かは自由である。
また、統合ビューア21には、課金エンジン26が接続されている。この課金エンジン26は、ユーザがアプリケーションを利用した場合に、その利用量に応じて課金し、ユーザに請求する利用料金を算出する。利用料金は、利用量ごとはもちろん、例えば、アプリケーションごと、アプリ提供者ごとにもそれぞれ設定されている。これらアプリケーションの利用料金に関する情報は、課金データベース27に予め記憶されている。そこで、課金エンジン26は、統合ビューア21からアプリケーションの利用の開始、終了等に関する情報を得て、課金データベース27からアプリケーションの利用料金に関する情報を基にユーザのアプリケーション利用料金を算出する。
画像管理部2Bは、画像情報マネージャ28と、画像レポートデータベース29とから構成されている。画像情報マネージャ28は、医療画像診断装置4によって取得される医療画像に関する情報を管理する。一方、画像レポートデータベース29は、画像情報マネージャ28を介して医療画像診断装置4から送られてきた医療画像を記憶する。
なお、上述したこれら各部の内部構成、機能や働きについては、後述する医療情報の提供処理に関する流れを説明する際に併せて説明する。
[ユーザの要求に基づく医療情報の提供の流れ]
図3及び図4は、実施の形態における医療情報システムSによる医療情報の提供の流れを示すフローチャートである。すなわち、これらのフローチャートには、ユーザが自身の診察や検査において必要とする患者の医療情報について、テナント型医療情報システム2に当該医療情報の表示を要求し、この要求に従った医療情報がユーザの使用するクライアント端末1に表示されるまでの流れが示されている。
まず、統合ビューア21において、ユーザによってテナント型医療情報システム2(統合ビューア21)に対して必要とされる医療情報の表示が要求されたか否かが確認される(ST1)。これは具体的には、ユーザがクライアント端末1を使用して統合ビューア21を起動したか否かを、要求を受け付けた統合ビューア21が確認することで行われる。
ここで、ユーザが使用するクライアント端末1から統合ビューア21に対して送られる情報としては、例えば、患者情報、当該患者に関して必要とされる医療情報やユーザ自身に関する情報が挙げられる。その他、例えば、取得される医療情報をクライアント端末1の表示部にどのように表示させるかといった表示レイアウトに関する情報や取得した医療情報をどのような場面(シーン)で利用するかという情報が含まれていても良い。
患者情報としては、例えば、患者氏名、患者ID、或いは、患者の疾患部位等を挙げることができる。また、例えば、造影検査であるのか否か、といった検査の方法に関する情報や検査に利用された医療画像診断装置4の種別といった情報も含まれる。当該患者に関して必要とされる医療情報は、例えば、疾患部位に関する医療画像、心電図、或いは、検査結果を示す数値といった情報である。医療情報の生成に当たっては、テナント型医療情報システム2(医療情報システム1)に提供されているアプリケーションのうち、それぞれ要求される医療情報を生成するに最適なアプリケーションが利用される。
従って、例えば、患者のX線CT画像を用いて所望の医療情報の取得を要求する場合であって、当該医療情報を生成することができるアプリケーションが複数提供されている場合には、ワークフローマネージャ22が適宜後述する各種情報を基に適切なアプリケーションを選択する。そして、アプリケーションに関する情報を抽出し、当該情報に基づくアプリケーションによって医療情報が生成される。また、アプリケーションを選択するにあたっては、ユーザが自らアプリケーションの選択を行い、当該アプリケーションを利用して医療情報の生成を要求することも可能である。
ユーザ自身に関する情報については、例えば、ユーザの氏名、ID番号、或いは、ユーザが使用するクライアント端末1に関する情報を挙げることができる。これらの情報を統合ビューア21に送信する情報に含めることによって、例えばユーザが良く利用するアプリケーション等、医療情報を生成するアプリケーションを選択するに当たって有益な情報となり得る。
表示レイアウトに関する情報は、必要とする医療情報が複数にわたる場合に、それらの医療情報をクライアント端末1の表示部に表示させる際、どのような配置で表示させるか、という情報である。表示する医療情報が1種類の場合は特に表示部上のレイアウトに拘泥しなくても足りるが、複数の医療情報が表示される場合には、見易さ、という観点が重要となる。また、医療情報の見易さについては、個々のユーザによっても異なることが考えられるため、その場合には特にこの表示レイアウトについての情報が必要となる。
医療情報が利用される場面(シーン)に関する情報とは、例えば、ユーザが統合ビューア21に要求する医療情報を通常の診察等で用いるのか、それとも診断決定木を利用する際に用いられるのか、という情報である。なお、後者の診断決定木を利用する場面については、後述する。
医療情報が通常の診察等で用いられる、といっても、その利用される場面(シーン)は多様である。従って、このシーンに関する情報をアプリケーションに関する情報を抽出、判定する際に適宜参照することで、当該シーンにて要求される(当該シーンに合った)医療情報の生成に適したアプリケーションに関する情報を抽出、判定することができる。
ここで「場面(シーン)」と表わしているのは、例えば、診察、検査に関する場面を想定しており、例えば、「スクリーニング」、「精査」、「フォローアップ」の3つに大別することができる。
「スクリーニング」とは、健診等をやって多くの人を検査してその中から異常が見られる人をピックアップすること、或いは、ある患者において、症状が出ている部分を検査するとともに、その他の部分(例えば全身)についてもチェックしてみることを表わしている。「精査」は、異常が発見された人を精密に検査すること、すなわち、主原因について、進んでいるのか、良性か悪性か等、現状を詳しく確認することを指している。精査の結果をもって確定診断ができる。そして、「フォローアップ」とは、治療後にその患者がどのような状態にあるかを診ること、或いは、適切な治療方針だったのか、といった診断、判断等のチェックである。
これら医療情報が利用される場面(シーン)によって、クライアント端末1の表示部に表示されるアプリケーションの種類、表示レイアウト等は大きく異なる可能性がある。従って、医療情報が利用される場面(シーン)を把握して医療情報を生成するに適したアプリケーションを決定することは重要である。
なお、場面(シーン)の特定に当たっては、例えば、上述した「ユーザ自身に関する情報」を利用することができる。このユーザ自身に関する情報として、例えば、クライアント端末1の設置されている場所が挙げられる。例えば診察室なのか、検査室なのかによってクライアント端末1の表示部に表示させる医療情報は異なる。例えば診察室からの要求であれば、「フォローアップ」、検査室からであれば「スクリーニング」、或いは、「精査」の場面であると推測することが可能である。
また、統合ビューア21においては、管理サーバ5から様々な情報を受信するが、これらの情報を利用することで場面(シーン)の特定を行うことができる。例えば、管理サーバ5から送信される該当する患者に関する検査のオーダ等を用いる。具体的には、例えば、X線撮影検査が実施済みであり、検査オーダとして心臓についてのCT検査に関する検査オーダが発行されたが、未実施であるとの情報が管理サーバ5から統合ビューア21へ送信された場合、現在ユーザが医療情報を利用しようとしている場面(シーン)は、心臓CT検査の場面(シーン)であると判断できる。
図5は、実施の形態における統合ビューア21の内部構成を示すブロック図である。統合ビューア21は、受信部21aと、情報解析部21bと、情報収集部21cと、情報統合部21dと、送信部21eとから構成される。
なお、統合ビューアは自体は医療情報を統合的にユーザに提示するアプリケーションである。しかし、以下の説明に係る実施の形態においては、テナント型医療情報システム2に当該アプリケーションが読み込まれることによって統合ビューア21が実装されることを前提とする。統合ビューアは、Webアプリケーション、ファットクライアントアプリケーション、或いは、シンクライアントアプリケーション等、いずれの実装形態を採用しても良い。一方、統合ビューアは医療情報を統合的にユーザに提示する回路としてテナント型医療情報システム2に設けられていても良い。
ユーザが使用するクライアント端末1から送信される要求は、受信部21aで受信される。上述した当該要求に含まれる情報にどのような情報が含まれているのかの確認は、情報解析部21bにて行われ、把握される(上述したステップST1参照)。
次に情報収集部21cは、統合ビューア21にて受信する各種情報を確認する(ST2)。統合ビューア21には、例えば、管理サーバ5から患者の予約情報や治療に関する情報等、医療機関内で管理されている各種情報が送信されてくる。テナント型医療情報システム2内には、図2において図示していないが、例えば記憶部が設けられており、通信ネットワークNを介して送られてくる情報を記憶している。
情報収集部21cは、ユーザからの要求に含まれる、例えば患者情報を基に、テナント型医療情報システム2で受信する各種情報の中から当該患者に関連する情報を選択し、抽出する(ST3)。
さらに、情報収集部21cが当該患者に関する情報を収集した後、統合ビューア21は、ユーザからの要求に関する情報(以下、このような情報を「要求情報」と表わす)、及び、通信ネットワークNを介して管理サーバ5等から送信された情報の中から抽出された当該患者に関する情報(以下、このような情報を「患者関連情報」と表わす)を合わせてワークフローマネージャ22へと送信する(ST4)。これらの情報は、ワークフローマネージャ22が医療情報を得るのに最適なアプリケーションを選択する上で重要な情報となる。
図6は、実施の形態におけるワークフローマネージャ22の内部構成を示すブロック図である。ワークフローマネージャ22は、送受信部22aと、推奨アプリ判定部22bと、アプリ推奨部22cとから構成される。また、ワークフローマネージャ22は、設定データベース23と接続されている。
設定データベース23内には、アプリ情報記憶部23aと、アプリ利用歴記憶部23bとが設けられている。なお、設定データベース23内に設けられている記憶部(テーブル)は、ここに挙げたものに限られるものではない。ここでは、実施の形態を説明する都合上必要な記憶部(テーブル)のみを挙げているのであって、図示しない他の記憶部が設けられていても良い。
なお、ワークフローマネージャも医療情報を生成するアプリケーションに関する情報を抽出等するアプリケーションである。しかし、以下の説明に係る実施の形態においては、テナント型医療情報システム2に当該アプリケーションが読み込まれることによってワークフローマネージャ22が実装されることを前提とする。一方で、ワークフローマネージャは医療情報を生成するアプリケーションに関する情報を抽出等する回路としてテナント型医療情報システム2に設けられていても良い。
また、以下の説明、或いは、各図面において、適宜「アプリ」と表わされる場合があるが、この「アプリ」とは「アプリケーション」の略である。
統合ビューア21から送信された要求情報及び患者関連情報を基に、ワークフローマネージャ22(推奨アプリ判定部22b)は、ユーザが必要とする医療情報が生成可能なアプリケーションに関する情報を設定データベース23(アプリ情報記憶部23a)から抽出し判定する(ST5)。
アプリ情報記憶部23a内には、テナント型医療情報システム2に通信ネットワークNを介して接続されている、アプリ提供者の提供によるアプリケーションに関する情報が記憶されている。記憶されている内容は、例えば、アプリケーション識別情報、アプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性、アプリケーション提供者識別情報、アプリケーション起動方法等である。以上は、アプリケーションに関する情報そのものであるが、その他に、統合ビューア21においてアプリケーションをどのように配置するかに関する情報(表示レイアウト情報)も記憶されている。
なお、記憶される方法としては、例えば、XMLファイルのようなテキスト情報であっても良く、或いは、RDBMSのようなデータベースに保管するようにしても良い。
推奨アプリ判定部22bでは、要求情報や患者関連情報を基に、アプリ情報記憶部23aに記憶されている上記アプリケーションに関する情報を検索し、抽出する。例えば、要求情報等の中に患者の疾患部位に関する情報が含まれている場合には、当該疾患部位をクライアント端末1の表示部に医師や患者にとって理解しやすく、見やすく表示させるに適切なアプリケーションに関する情報を選択する。
また、抽出対象となるアプリケーションが複数アプリ情報記憶部23aに記憶されている場合には、例えば、ユーザが通常利用しているアプリケーションを抽出したり、或いは、シーンに応じて当該ユーザがこれまで利用していたアプリケーションとは異なるアプリケーションを抽出することも可能である。または、これまで利用されていたアプリケーションに類似するアプリケーションであって、より安価なアプリケーションに関する情報が登録されていた場合には、これまで利用されていたアプリケーションに替えて当該安価なアプリケーションを抽出しても良い。
さらに、実際にアプリケーションを利用して生成される医療情報をどのような配置で統合するかについての表示レイアウト情報についても抽出する。
なお、アプリ情報記憶部23a内に記憶されている情報は、上述した各情報に限定されることはない。また、アプリ情報記憶部23aからどの情報を抽出するかについても任意に設定することができる。
また、ここで「アプリ推奨部22c」は、ユーザが使用するクライアント端末1の表示部にテナント型医療情報システム2として推奨するアプリケーションの一覧を表示させる機能を有している。予め表示部にこのような推奨のアプリケーションを表示させることによって、ユーザに直接利用したいアプリケーションを要求させることができる。また、複数推奨するアプリケーションがある場合には、その旨のアイコンを表示させることも可能である。
設定データベース23における「アプリ利用歴記憶部23b」は、ユーザによるアプリケーションの利用履歴を記憶する。利用歴を記憶するタイミングとしては、例えば、ユーザからの要求に基づいてワークフローマネージャ22が選択したアプリケーションが利用されて医療情報が生成された場合に、当該生成された医療情報をシンクライアントマネージャ24から受信した際に、統合ビューア21から利用歴に関する情報を設定データベース23へ送信することが考えられる。
ここで記憶される情報としては、アプリケーションに関する情報や利用者に関する情報を挙げることができる。両者は互いに紐づけられて記憶されている。「アプリケーションに関する情報」としては、例えば、アプリケーション識別情報、アプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性、アプリケーション提供者識別情報等を含むアプリケーションの属性情報が考えられる。また、「利用者に関する情報」として、利用者識別情報、利用者所属情報、利用者契約情報や、利用に関する情報である、アプリ利用開始時間、アプリ利用終了時間、アプリ利用時間、アプリ処理時間、アプリ処理データ量、アプリ使用CPU時間等が挙げられる。
なお、このアプリ利用歴記憶部23bに記憶されている情報は、後述する課金に際して利用される情報であることから、例えば、セキュリティ強度が高められたRDBMSのようなデータベースに保管されることが望ましい。または、暗号化されたXMLファイルのようなテキスト情報として管理しても良い。
ワークフローマネージャ22は、設定データベース23から抽出した医療情報を生成するに適したアプリケーションに関する情報および表示レイアウトに関する情報を統合ビューア21へ送信する(ST6)。
ワークフローマネージャ22から情報を受信した統合ビューア21は、まず受信した情報を「アプリケーションに関する情報」と「表示レイアウトに関する情報」とに分ける。その上でアプリケーションに関する情報が示すアプリケーションを利用してユーザが必要とする医療情報を生成するための基となる画像情報を、アプリケーションA(アプリケーション25)を介して画像レポートデータベース29から抽出する(ST7)。
統合ビューア21は、アプリケーションに関する情報及び、画像レポートデータベース29から抽出された医療画像に関する情報をシンクライアントマネージャ24へ送信する(ST8)。但し、統合ビューア21は、アプリケーションに関する情報については、自身にも保持しておく。これは、アプリサーバ3での医療情報の生成が終了し、シンクライアントマネージャ24から生成された医療情報を受領する際に、シンクライアントマネージャ24を介して医療情報を生成させたアプリサーバ3の全てから医療情報が送られてきたか否かを判断する際に用いるためである。
シンクライアントマネージャ24は、受信したアプリケーションに関する情報の内容から、該当するアプリケーションを備えるアプリサーバ3を確認し、対応する適切な店子(アプリ提供者)のアプリサーバ3へと送信する(ST9)。
図7は、実施の形態におけるアプリサーバ3の内部構成を示すブロック図である。アプリサーバ3は、シンクライアントエンジン31と、アプリケーション32と、画像データベース33とから構成される。
シンクライアントエンジン31は、シンクライアントマネージャ24から送信されたアプリケーションに関する情報を受信する。その上でアプリケーション32の制御を行う。また、シンクライアントマネージャ24から送信された医療画像に関する情報は、画像データベース33に格納される。アプリケーション32は、シンクライアントエンジン31の制御の下、画像データベース33に格納された医療画像に関する情報を基に医療情報を生成する(ST10)。
アプリサーバ3は、アプリケーション32の種類ごとに設けられていても、或いは、アプリ提供者が自らが提供するアプリケーション32についてはまとめて1つのアプリサーバ3に格納することとしても良い。
アプリケーション32によって生成された医療情報は、シンクライアントエンジン31を介してシンクライアントマネージャ24へ送信される(ST11)。シンクライアントマネージャ24では、各アプリサーバ3から送信されてきた医療情報を受信する(図4のST12)。そこでシンクライアントマネージャ24は、ユーザからの要求に基づいて生成される医療情報の全てを受信したか否かを確認する(ST13)。全てのアプリサーバ3からユーザの要求に対応する医療情報の全てを受信していないと判断された場合には(ST13のNO)、全ての医療情報が送信されてくるまで待機する。
一方、全ての医療情報がアプリサーバ3から送信されシンクライアントマネージャ24が受信したことが確認された場合(ST13のYES)、シンクライアントマネージャ24は、全ての医療情報を統合ビューア21に対して送信する(ST14)。
なお、ここでは、全ての医療情報がアプリサーバ3からシンクライアントマネージャ24へと送信されたことをもって統合ビューア21へと当該医療情報を送信することとしているが、シンクライアントマネージャ24はアプリサーバ3から医療情報を受信したら、その都度統合ビューア21へ送信することとしても良い。
以上で必要とされる医療情報は生成されたが、表示レイアウトに関する情報については、シンクライアントマネージャ24を介してアプリサーバ3に送られることはなく、統合ビューア21内にて保持される(ST15)。この表示レイアウトに関する情報は、統合ビューア21が生成された医療情報をクライアント端末1にて表示する際に利用する情報だからである。
統合ビューア21では、アプリケーション32を利用して生成された医療情報を受信するとともに、ユーザがクライアント端末1において表示することを必要としている医療情報が全て揃ったか否かを確認する(ST16)。全てが揃っていない場合にはそのまま待機し、ユーザが要求した医療情報の全てが揃ったことが確認された場合には(ST17のYES)、これら集められた医療情報を表示レイアウトに関する情報に基づいて統合ビューア21の情報統合部21dにて統合される(ST18)。
そして、統合ビューア21にて統合された情報は、ユーザが使用しているクライアント端末1に表示される(ST19)。
さらに、統合ビューア21では、シンクライアントマネージャ24から送信された、医療情報の生成の際に利用したアプリケーション32の利用歴についての情報を受信し、ワークフローマネージャ22や課金エンジン26へ送信する(ST20)。
以上、ユーザが必要とする医療情報の要求を行ってから、適切なアプリケーションが選択され、当該選択されたアプリケーションによって生成された医療情報を統合した上でクライアント端末1に表示される流れを説明した。
図8ないし図11は、実施の形態における統合ビューア21によって統合されクライアント端末1の表示部に表示される画面例である。なお、以下に図面を示しながらクライアント端末1の表示部に表示される画面例について説明するが、各図において示される画面例のレイアウトは、あくまでも例示に過ぎず、そのレイアウトは自由に設定することが可能である。また、このレイアウトはワークフローマネージャ22から統合ビューア21に対して送られた表示レイアウトに関する情報に含まれ、当該表示レイアウトに関する情報に基づいてその配置が設定される。
図8に示す画面例1Aは、上部に「患者氏名」、「患者ID」、及び当該画像のシリーズに関する情報が表示されている。但し、この欄にどのような情報を表示させるかについては、任意に設定することが可能である。
一方、画面例1Aの下部には、左側に1つの画像、右側に上下に分けて2つの画像が表示されている。左側に示されている医療画像1Aaは、例えば、医療画像診断装置4によって取得され、画像レポートデータベース29に記憶されていた画像である。
また、右側上部に示されている医療画像1Abは、例えば、アプリケーションA−1によって生成された医療画像であり、右側下部に示されている医療画像1Acは、例えば、アプリケーションB−1によって生成された医療画像である。従って、当該画面例1Aにおいては、アプリケーションによって生成された医療画像とともに、これら医療情報としての医療画像生成の基となった医療画像が同じ表示部に示されていることになる。
ここで、例えば「アプリケーションA−1」とあるのは、システム運営者がテナント型医療情報システム2内に提供している複数のアプリケーションのうち、「A−1」という種類のアプリケーションを示している。また、同様に、「アプリケーションB−1」とあるのは、アプリ提供者が自社のアプリサーバ3内に提供している複数のアプリケーションのうち、或いは、アプリ提供者が自社が提供しているアプリケーションのうち、「B−1」という種類のアプリケーションを示している。
これによって、例えば、ユーザである医師は医療画像診断装置4によって取得された医療画像を基に、医師が指定した方法に基づいて生成された医療画像を利用して患者に対してより適切な診察、説明を行うことができる。
図9ないし図11は、一連の医療画像を3つのタブで示される画面によって、その内容を表示部に示すことを示した画面例1Bである。画面例1Bには、タブXが3つ設けられており、それぞれに医療画像等の情報が表示されている。
図9に示すタブX1において表示される画面例1Bには、左側にアプリケーションA−2を利用して生成された医療画像1Baが1枚、右側上部に同じくアプリケーションA−2を利用して生成されてはいるものの、別の態様で表示されている2枚の医療画像1Bb、1Bc、右側下部に、例えば、HISといった管理サーバ5から送信された情報1Bdが表示されている。
図10は、タブX2を開いた状態を示す画面例1Bである。左側上部に今回の検査で取得された医療画像1Beが1枚、左側下部に前回の検査で取得された医療画像1Bfが1枚、右側にアプリケーションB−2を利用して生成された医療画像1Bgが1枚表示されている。
図11は、タブX3を開いた状態を示す画面例1Bである。左側に初回のX線検査で取得された医療画像1Bhが1枚、右側上部に検体検査の結果1Bi、右側下部にアプリケーションCを利用して生成された医療画像1Bjが1枚表示されている。
以上、図9ないし図11に示されている画面例1Bの各タブXに示される医療情報については、上述したように、ユーザの要求に基づいてワークフローマネージャ22が設定データベース23内から抽出された表示レイアウトに関する情報に基づいて、統合ビューア21が各医療情報を統合してクライアント端末1の表示部に表示させるものである。各タブXに表示させる医療情報やその配置、大きさ、タブXの数等については、任意に設定することができ、その情報が表示レイアウトに関する情報としてまとめられている。
[アプリケーションの利用に基づく課金の流れ]
図12は、実施の形態における課金エンジン26の内部構成を示すブロック図である。また、図13は、実施の形態におけるアプリケーション利用に基づく課金の流れを示すフローチャートである。以下においては、いずれかのアプリケーションが利用され、ユーザが要求する医療情報が生成された場合の、当該アプリケーション利用についてのユーザへの課金の流れについて説明する。
図12に示すように、課金エンジン26は、情報を受信する受信部26aと、利用されたアプリケーションを確認する利用アプリ確認部26bと、当該アプリケーションを利用するに当たって必要とされる基本の料金を検索する料金検索部26cと、検索された基本料金を基に実際に掛かった料金を算出する料金算出部26dと、算出された料金に関する情報をユーザのクライアント端末1に向けて送信する送信部26eとから構成される。これら各部の詳しい働きについては、以下の課金の流れを説明する際に併せて説明する。
図13のフローチャートに示されているように、まず統合ビューア21は、ユーザからの要求を受信し、ワークフローマネージャ22による適切なアプリケーションの選択を経て、当該アプリケーションに関する情報に基づいて、シンクライアントマネージャ24を介して各アプリサーバ3へと医療情報の生成を依頼する(ST31)。ここまでの流れは、図3に示すステップST1ないしステップST9までに示す流れと同じである。
但し、統合ビューア21は、シンクライアントマネージャ24を介して各アプリサーバ3へと医療情報の生成を依頼するとともに、アプリケーションの利用開始通知を課金エンジン26へと送信する(ST32)。これは、ユーザの要求に基づいて必要とされる医療画像を取得するために、いずれのアプリケーションが利用されるのか、その利用開始の状態を明確にするためである。この利用開始通知をもって課金エンジン26は各アプリケーションが利用されることを理解する。
なお、当該利用開始通知には、例えば、アプリケーションに関する情報である、アプリケーション識別情報、アプリケーション名、アプリケーション提供者識別情報等が含まれている。なお、当該利用開始通知に含まれる情報はこれらに限られることなく、いずれの情報を含めても良い。
統合ビューア21からの利用開始通知を利用して、課金エンジン26は、画像情報マネージャ28にアクセスし、医療情報として生成される基となる医療画像のデータサイズを取得する(ST33)。画像情報マネージャ28は、医療画像診断装置4によって取得された医療画像を受信した際に、例えば、当該医療画像を識別するための識別子と画像サイズ(例えば、データ量(KB))を関連付けて画像レポートデータベース29に記憶させておく。
画像情報マネージャ28は、課金エンジン26からのアクセスによって、医療情報として生成される基となる医療画像の識別子を手がかりに、当該医療画像の画像サイズを画像レポートデータベース29から取得する。
なお、医療画像の識別子と関連付けられて記憶される情報としては、上述した画像サイズに限られず、例えば、部位、空間分解能、時間分解能、イメージング機能種別等、いずれの情報であっても良い。課金エンジン26は、画像レポートデータベース29内に記憶されている情報の種類に合わせて必要とされる情報を入手する。
課金エンジン26の料金検索部26cは、統合ビューア21から取得した情報を基に、課金データベース27から利用されるアプリケーションに関する利用料金の単価を取得する(ST34)。課金データベース27内には、予めテナント型医療情報システム2に提供される各アプリケーションに関する利用料金に関する情報(単価)が記憶されている。そこで料金検索部26cは、利用開始通知を受信した後、当該単価を検索、取得して待機する。
図14は、課金データベース27内に記憶されている料金テーブルの一例を示す表である。この表では、最も左側の欄にアプリ提供者から提供されている各アプリケーションが示されている。この欄から右に向けて、利用料金に関する情報として、3つの項目が並んでおり、それぞれ「メモリ使用量(MB)」、「CPU占有率(%)」、「価格(円)/時間」とされる。例えば、アプリケーションBが利用される場合、メモリの使用量は「20MB」であり、CPU占有率は「1%」、時間当たりの価格は「1500円」である。料金検索部26cは、これら単価(アプリケーションの利用料金)を対象となるアプリケーションに関する情報を基に検索する。
課金エンジン26が利用開始通知の受信をトリガーとしてアプリケーションの利用単価を検索している間、アプリサーバ3では要求された医療情報の生成をしている。そして上述した通り、医療情報が生成されるとシンクライアントマネージャ24に対して生成された医療情報を送信する。さらにシンクライアントマネージャ24は、取得した医療情報を統合ビューア21へと送信する(ST35)。ここで、統合ビューア21は、表示が要求される医療情報の全てが揃ったか否かを確認し(ST36、図4に示すST16に該当)、全ての医療情報が揃うまで待機する(ST37、図4に示すST17に該当)。全ての医療情報が揃ったか否かの判断は、統合ビューア21がシンクライアントマネージャ24を介して各アプリサーバ3へ医療情報の生成を依頼する際に保持する、各アプリケーションに関する情報を用いて行う。
全ての医療情報が揃った場合には(ST37のYES)、統合ビューア21は全ての医療情報を表示レイアウトに従って統合するとともに、医療情報生成のためのアプリケーションの利用が終了した旨、利用終了通知を課金エンジン26へと送信する(ST38)。
なお、ここでは全てのアプリケーションの利用が終了したことをもって、統合ビューア21から課金エンジン26に利用終了通知を送信しているが、例えば、利用されるアプリケーションによっては、課金操作となる、例えば、レポートの作成といった医療情報が生成されるたびに利用終了通知を送信することとしても良い。
課金エンジン26では、利用終了通知に含まれる利用されたアプリケーションに関する情報を基に、利用アプリ確認部26bが再度利用されたアプリケーションを確認し、その上で、料金算出部26dにおいて、検索した利用単価を基にそれぞれ利用されたアプリケーションに関する利用料金を算出する(ST39)。
料金算出部26dでは、例えば、アプリケーションの利用時間、生成された医療情報の枚数、医療情報生成の基となる医療画像のデータサイズ等のアプリケーションの利用状況とそれぞれ定められている単価を基に利用料金が算出される。また、アプリケーションの利用料金については、この他に、アプリケーションが利用されている最中に、当該アプリケーションを提供するアプリサーバ3から随時CPUの利用率やメモリの占有率等の各種情報を収集し、これらの情報を基に利用料金を算出することも可能である。
算出された利用料金については、料金算出部26d、或いは、統合ビューア21等に保持されて、ユーザの要求や他の操作をトリガーとして課金に関する情報をクライアント端末1の表示部に表示させる(ST40)。
以上、ユーザが医療情報を取得するべくアプリケーションを利用した場合に、当該利用に関する課金の流れについて説明した。一方で、ユーザが利用するアプリケーションは、アプリ提供者が医療情報システムSに提供している。従って、システム運営者との契約が締結された上でアプリ提供者はそれぞれ自社のアプリケーションを提供することになる。このアプリ提供者とシステム運営者との間の契約において、システム運営者は、例えば、アプリ提供者が提供したアプリケーションがユーザに使用された場合に、その利用態様によってアプリ提供者に対して課金することができる。また、課金の基準が利用態様ではなく、例えば、期間等の指標に対して一定額、といった課金の方法も考えられる。
また、ユーザからのアプリケーションの利用料金について、システム運営者はアプリケーションの利用態様によって、アプリ提供者に対して当該利用料金の支払い(分配)を行うことも可能である。
ところで、上述した課金の流れは、ユーザが要求した医療情報をアプリケーションを利用して生成した場合を例に挙げて説明した。但し、ユーザによっては、アプリケーションを利用して完全な形の医療情報を生成することまでは求めず、例えば、簡単に当該アプリケーションを利用するとどのような医療情報が提供されることになるのか、確認のみしたい場合もある。また、例えば、医療情報が複数の項目について数値のみで表わされる場合に、全ての項目を医療情報として提供されることは不要であり、予め選択されるいくつかの項目についてのみ医療情報として提供されることを求める場合も考えられる。このように様々な利用実態が存在する場合に、それぞれの利用実態に合わせて課金を行うことも可能である。
以上、ユーザが必要とする医療情報について、その要求から取得、また、アプリケーションの利用に伴う課金の流れまで説明した通り、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとすることで、ユーザの利便性の向上を図ることが可能な医療情報システム及び医療情報提供方法を提供することができる。
なお、上述した統合ビューア21から送信された要求情報及び患者関連情報を基に、ワークフローマネージャ22は、ユーザが必要とする医療情報が生成可能なアプリケーションに関する情報を設定データベース23から抽出し判定する、というワークフローマネージャの働きについては、別の抽出、判定処理も考えられる。
この考え方は、統合ビューア21から要求情報及び患者関連情報を受信したワークフローマネージャ22は、設定データベース23のアプリ情報記憶部23aからユーザからの要求に適したアプリケーションに関する情報を抽出する際に、経済的な視点を加味してアプリケーションの情報を抽出する考え方である。
すなわち、事前にアプリケーションに関する情報としてアプリ情報記憶部23aに、「アプリケーション利用料金契約情報」を記憶させておく。この「アプリケーション利用料金契約情報」は、例えば、「1回当たり」、「一定期間当たり」、「CPU使用量当たり」、或いは、「データ処理量当たり」のアプリケーションの利用料金がそれぞれ規定されており、その料金に関する情報である。その上で、推奨アプリ判定部22bは、アプリ情報記憶部23aからアプリケーションに関する情報を抽出するに当たって、要求情報及び患者関連情報のうち、例えば、特にアプリケーション識別情報、アプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性を基に複数の類似するアプリケーションに関する情報を抽出する。
これら抽出された複数の類似するアプリケーションに関する情報、及び、アプリケーション利用料金契約情報を基に、それぞれのアプリケーションを利用した際にかかる料金を試算する(算出する)。この試算された料金も含めて統合ビューア21にアプリケーションに関する情報を送り、ここで一旦クライアント端末1の表示部に推奨するアプリケーションとしてこれら複数の類似するアプリケーションに関する情報を表示させる。
ユーザは、必要とされる医療情報の生成を行うために利用するアプリケーションについて、利用料金の試算とともに表示されることになるため、利用するアプリケーションを選択する上で有効な情報を得ることになる。
このように、上述したワークフローマネージャ22の抽出、判定処理に比べ、ユーザに推奨するアプリケーションを提示し選択させる分、全体の処理に時間が掛かることになるが、経済的な視点を加味することによって、ユーザに医療情報の取得に当たって、より一層の満足感を与えることになる。一方でアプリ提供者にとっても、ワークフローマネージャ22によるアプリケーションに関する情報の抽出、判定処理において、抽出対象となるアプリケーションが固定されがちとなることを防止して、新たなアプリケーションが抽出される機会を付与されることになる点において、よりユーザの利便性向上に寄与するアプリケーションの開発、提供を行うことのモチベーションにつながる。
さらに、システム運営者にとっては、インフラ上に自由競争の場を提供し、複数の類似するアプリ提供者から魅力的なアプリケーションの提供を受けて競わせることによって、医療情報システムS(テナント型医療情報システム2)へのユーザ、アプリ提供者の参加が増え、システムの利用を促すことになる。
(第2の実施の形態)
次に本発明における第2の実施の形態について説明する。なお、第2の実施の形態において、上述の第1の実施の形態において説明した構成要素と同一の構成要素には同一の符号を付し、同一の構成要素の説明は重複するので省略する。
第2の実施の形態においては、ワークフローマネージャ22において、ユーザからの要求に応じて適切なアプリケーションに関する情報を抽出、判定する処理に関して、アプリケーションを提供するアプリ提供者から出されているそれぞれのアプリケーションに対する推奨希望の度合いを基に抽出、判定処理を行う点に特徴がある。
図15は、第2の実施の形態におけるワークフローマネージャ22、及び、設定データベース23Aの内部構成を示すブロック図である。第1の実施の形態において説明した設定データベース23内に、「推奨希望度合い記憶部23c」が新たに設けられている。なお、ワークフローマネージャ22については、その構成に違いはない。
この「推奨希望度合い記憶部23c」は、アプリサーバ3にアプリケーションを提供するアプリ提供者が、提供するアプリケーションに関して、どの程度ユーザに対して推奨するか、その度合いを記憶する。すなわち、アプリ提供者からの推奨度合いに応じてシステム運営者はユーザに当該アプリケーションの推奨を行うことになることから、換言すれば、店子であるアプリ提供者による大家であるシステム運営者へのアプリケーションのお薦め度合いとも言える。
システム運用者は、ワークフローマネージャ22によって設定データベース23から要求情報及び患者関連情報を基にユーザが必要とする医療情報の生成に適したアプリケーションに関する情報を抽出、判定する。推奨アプリ判定部22bは、推奨希望度合い記憶部23cに記憶されているアプリ提供者による当該アプリケーションの推奨度合いを参考に、適切なアプリケーションに関する情報を抽出、判定処理を行う。または、推奨度合いによってユーザへの推奨順位を決定しても良い。
さらには、複数推奨するアプリケーションをクライアント端末1に表示させ、ユーザにその中の1つのアプリケーションを試用してもらうようにしても良い。試用のアプリケーションをユーザが利用を考えているアプリケーションに類似するアプリケーションとすることで、利用を考えているアプリケーションの利用実態をシミュレーションすることができる。
なお、推奨度合いの参照については、アプリ提供者によって推奨希望度合い記憶部23cに推奨度合いが記憶されている場合には、推奨アプリ判定部22bは常に該当するアプリケーションに関する情報の抽出、判定処理において推奨度合いを参照する、という方法を採用することができる。一方で、例えば、特定のアプリケーション分類に対するユーザからの要求のうち、24時間等、所定の時間当たりの推奨アプリ判定部22bによる当該アプリケーションの抽出割合が指定の値となるまで推奨する、といった方法も採用することができる。さらに、ユーザが要求した特定のアプリケーション分類の中で該当するアプリケーションに関する情報が抽出される割合が予め定められている値よりも小さい場合に、推奨アプリ判定部22bは推奨度合いを参考にしてアプリケーションに関する情報を抽出するとしても良い。
アプリ提供者によるアプリケーションの推奨度合いに応じてワークフローマネージャ22がアプリケーションに関する情報をユーザに推奨した後、当該推奨に従ってユーザが推奨の対象であるアプリケーションの利用を選択した場合には、推奨のアプリケーションとその推奨に基づき選択されたアプリケーションが合致することになる。従って、この場合は、例えばアプリ推奨の成否は「成」と判断されることになり、この判断によって、例えば、アプリ提供者からシステム運営者へ報酬等の支払いを行う等の取り決めが両者の間でなされていても良い。
一方で、アプリ提供者によるアプリケーションの推奨度合いに応じてワークフローマネージャ22がアプリケーションに関する情報をユーザに推奨したにも拘わらずユーザが別のアプリケーションを選択した場合には、アプリ推奨の成否は「否」と判断される。この場合についてもアプリ提供者とシステム運営者との間で何らかの契約を締結して、アプリ提供者の提供するアプリケーションがより利用されるような対策を講じることもできる。
また、システム運営者がアプリ提供者の推奨したアプリケーションを抽出、選択する、ということは、このアプリ提供者がシステム運営者に対して推奨するアプリケーションをユーザに対して推奨するように依頼していることになり、アプリ提供者にとっては、システム運営者にそのアプリケーションに関する営業を依頼していることになる。
従って、アプリ提供者にとっては、自身が注力しているアプリケーションを効率的にユーザに宣伝、提供することができることになるため、システム運営者が運営するテナント型医療情報システム2に参加する動機付けともなり得る。
ここでアプリ提供者が推奨度合いの決定をする際には、上述したように自身が注力しているアプリケーションである、という観点の他にも、例えば、自身の予算に応じて適切なアプリケーションの推奨をシステム運営者に対して依頼するという観点も考えられる。従って、アプリ提供者がどのように考えて当該アプリケーションを推奨するか、については問わない。
このことは、システム運営者にとっても質の良いアプリケーションがテナント型医療情報システム2に参加することにつながり、ユーザにとっても使い勝手に優れるアプリケーションを利用できるという利便性の向上につながる。
従って、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとすることで、ユーザの利便性の向上を図ることが可能な医療情報システム及び医療情報提供方法を提供することができる。
(第3の実施の形態)
次に本発明における第3の実施の形態について説明する。なお、第3の実施の形態において、上述の第1または第2の実施の形態において説明した構成要素と同一の構成要素には同一の符号を付し、同一の構成要素の説明は重複するので省略する。
図16は、第3の実施の形態におけるワークフローマネージャ22A、及び、設定データベース23Bの内部構成を示すブロック図である。第3の実施の形態においては、ワークフローマネージャ22Aにおいて、ユーザからの要求に応じて適切なアプリケーションに関する情報を抽出、判定する処理に関して、ユーザの条件を基に抽出、判定処理を行う点に特徴がある。
ここで「ユーザの条件」とは、例えば、医療情報を要求する医師等の専門性、アプリケーションの利用頻度等の情報である。これらの情報を「条件」として統合ビューア21から要求情報等とともにワークフローマネージャ22Aに対して送信される利用者識別情報に紐づけて予めユーザ条件記憶部23dに記憶させておく。これにより、ユーザにより適したアプリケーションに関する情報を抽出、判断することができる。
なお、医師等の専門性については、例えば、診療科を示す識別情報や認定済み専門医識別情報等を挙げることができる。また、アプリケーションの利用頻度に関する情報については、例えば、アプリケーション識別情報、アプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性、アプリケーション提供者識別情報の他、当該アプリケーションを利用した頻度を回数、利用時間、CPU使用量、或いは、データ使用量等の情報が挙げられる。但し、これら全ての情報を漏れなく記憶することはなく、これらの情報の中から当該テナント型医療情報システム2が利用される環境等を考慮して記憶させることができる。
このようなユーザ自身の条件を記憶させておくことで、ユーザが利用を希望するアプリケーションを選択する際に、その選択の幅が広がることになる。例えば、類似する機能を備えるアプリケーションであっても、初心者用、或いは、ベテラン用というように、ユーザの実力によって使い勝手の異なるアプリケーションが提供されていることが考えられる。推奨アプリ判定部22bが設定データベース23からアプリケーションに関する情報を抽出する際に、このようなユーザの条件を参照することで、医療情報を要求するユーザの実力をも見極めた上で適切なアプリケーションに関する情報を抽出し当該アプリケーションに基づいて医療情報を生成することが可能となる。
さらには、ユーザが持つ予算についても条件の1つとしてユーザ条件記憶部23dに記憶させておいても良い。ここで「予算」とは、例えば、ユーザ個人、或いは、ユーザが属する診療科等のグループにおいて使うことのできる予算の意味である。予算の多寡、及びアプリケーションの利用料金によっては、利用したいアプリケーションを予算の都合上利用することができない場合も考えられる。従って、ユーザの条件としてユーザの持つ「予算」の額を記憶させておくことで、推奨アプリ判定部22bは、例えば、利用を希望するアプリケーションに類似する、より利用料金が安いアプリケーションをユーザに推奨することも可能となる。
ユーザ条件記憶部23dにユーザに関する条件が記憶されていることによって、アプリ提供者は、それぞれの条件に合った複数のアプリケーションを提供することができる。すなわち、例えば、同じ機能を備えるアプリケーションであっても様々なレベルのアプリケーションを提供し、それぞれに適した料金を設定することによって、多様なアプリケーションの提供を行うことができる。このことは、アプリ提供者にすればより多くのユーザに対して自らの提供するアプリケーションの利用する機会を与えることにある。そしてユーザにしてみればアプリケーション選択の幅を広げることになるため、利用機会が拡大し、利便性が向上することになる。
一方、ワークフローマネージャ22Aには、新たに「条件監視部22d」が設けられている。この条件監視部22dは、実際に利用されたアプリケーションに関する情報を統合ビューア21から取得し、ユーザ条件記憶部23dに記憶させる。このようにユーザの利用状況を常に把握することによって、次回当該ユーザが医療情報の要求をしてきた場合により適切なアプリケーションに関する情報を抽出することができる。
システム運営者にすれば、ワークフローマネージャ22に条件監視部22dが設けられ、設定データベース23にユーザ条件記憶部23dが設けられることで、テナント型医療情報システム2を利用するユーザの特質や嗜好等を把握することができる。このことは、ユーザからの各種要求に対してよりきめ細かな対応をすることができることにつながるため、ユーザ自身の利便性の向上をはかることができる。併せて、多くのアプリ提供者のテナント型医療情報システム2への参加、及びアプリ提供者からの良質なアプリケーションの提供を期待することができる。
以上説明した通り、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとするとともに、ユーザの条件を把握し、利用することによって、ユーザの利便性の向上を図ることが可能な医療情報システム及び医療情報提供方法を提供することができる。
(第4の実施の形態)
次に本発明における第4の実施の形態について説明する。なお、第4の実施の形態において、上述の第1ないし第3の実施の形態において説明した構成要素と同一の構成要素には同一の符号を付し、同一の構成要素の説明は重複するので省略する。
これまで説明してきた各実施の形態においては、ユーザが統合ビューア21を介して要求する医療情報を通常の診察等で用いる場合を例に挙げて説明してきた。そのため通常の診察において医療情報を利用する場合には、ユーザが必要と判断した医療情報を、当該医療情報が利用される場面(シーン)に合わせて当該医療情報の生成に適したアプリケーションを選択し、生成させ、表示することで、ユーザの利便性を確保していた。
一方で、上述した場合ではなく、診断決定木を利用する際に医療情報が用いられる場合もある。ここで「診断決定木」とは、患者の病状に基づいて治療を行う際に次に取り得る措置を判断、決定していく際に用いられるグラフである。そのため、診断決定木を用いる場合、ユーザには、次に取り得る措置を決定するのに必要とされる医療情報を示す必要がある。従って、上述の各実施の形態における場合と異なり、いずれの場面において医療情報が利用されるかによってワークフローマネージャ22にて選択、判定されるアプリケーションに相違が生ずる。
図17は、第4の実施の形態におけるワークフローマネージャ22の判断の流れを示す診断決定木を示す模式図である。図17に示す診断決定木Tでは、スタートである所見(例えば、胸痛による受診)に基づいて、まずX線撮影検査が行われる(WF:A−1)。X線撮影検査が行われると、次に予想できる処置としては、「血液検査(WF:A−1−A)」、「超音波検査(WF:A−1−B)」、或いは、「CT検査(WF:A−1−C)」のいずれかが考えられる。そして「超音波検査」が行われた場合には、次に「CT検査(WF:A−1−B−A)」、が行われる可能性が高い。このように、ある処置が行われると、次に行われる処置をある程度予想することが可能である。
そこで、例えば診察室や検査室等からのユーザの要求、すなわち、ユーザが医療情報を要求する際に、診断決定木に基づいて診断をしていることが伺える場合には、ワークフローマネージャ22は、予め設定データベース23内に記憶されている診断決定木に基づいて、次の処置に必要な医療情報の生成を行うことができるアプリケーションに関する情報を抽出、判定する。この際、ワークフローマネージャ22としては、例えば、似たような画像構成を行うアプリケーションが複数提供されている場合に、より次の段階の処置を決定するに適した医療情報を生成することができるアプリケーションを抽出するようにすることも可能である。
統合ビューア21は、ワークフローマネージャ22から送られてきたアプリケーションに関する情報に基づいてシンクライアントマネージャ24を介してアプリサーバ3に医療情報の生成を依頼し、必要な医療情報をクライアント端末1の表示部に表示させる。この際、例えば、現状の処置が適切か否かを判断するため、現状を表わす医療情報のみならず、1つ前の段階における医療情報も併せて表示させる。また診断決定木を利用することによって、次の処置として複数の処置が考えられる場合も多くそれだけ参照しなければならない情報が増える。従って、クライアント端末1の表示部において表示される医療情報の表示レイアウトも適宜変更される。
このように、診断決定木を用いて、ユーザが行う処置に必要な医療情報のみならず、次に行われる処置に必要とされる医療情報までも生成してクライアント端末1に表示させることによって、ユーザによる患者への処置がタイミング良く、迅速に行われることに資することができる。
以上説明した通り、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとするとともに、診断決定木を用いて一歩先の医療情報を提供することによって、ユーザの利便性の向上を図ることが可能な医療情報システム及び医療情報提供方法を提供することができる。
なお、推奨アプリ判定部22bによるアプリケーションに関する情報の抽出に当たっては、これまで様々な場合を例に挙げて説明をしてきた。その他、例えば、アプリケーションに関する情報の抽出の際、当該アプリケーションを利用してのユーザの意見、感想等を反映させる方法も考えられる。例えば、同じ専門を持つ他のユーザの利用経験をフィードバックし、その評価を点数化して重み付けとして利用することもできる。
さらに、これまで説明した推奨アプリ判定部22bによるアプリケーションに関する情報の抽出に関する方法は、互いにそれら単独で用いても、或いは、適宜組み合わせて用いても良い。例えば、ユーザからの要求に従って医療情報を生成する際に、複数のアプリケーションを利用することも考えられる。この場合、例えば、1つ目のアプリケーションで要求される医療情報の基礎となる情報を生成し、2つ目のアプリケーションを利用して、1つ目のアプリケーションを利用して生成された情報を要求される医療情報として生成する等である。このように複数のアプリケーションが連携して1つの医療情報を生成することによって、ユーザは1つのアプリケーションの利用だけでは得ることのできなかった医療情報を取得することができるようになる。
また、この場合、例えば、レポートが作成されるに当たっては、生成された要求される医療情報を利用することも、或いは、アプリケーションを利用するごとに生成される情報を利用することも可能である。
さらに、このようにして複数のアプリケーションが連携して利用される場合には、これらのアプリケーションで使用されるパラメータを校正する必要が出てくる。これらパラメータの校正については、例えば、基準となる情報を基に各アプリケーションを起動させ、それぞれの結果を評価してパラメータを校正することで、アプリケーション間でのバラツキをなくすことができる。
さらに、以上の各実施の形態における説明は、1つの医療情報システムを基に説明をした。但し、この医療情報システムが例えば、ある地域の複数の医療機関に設けられている場合には、それぞれの医療情報システムを連携させて利用することも可能である。
本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することを意図していない。この実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。