以下、本発明の実施の形態について図面を参照して詳細に説明する。
[医療情報システムの全体構成]
図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が適宜後述する各種情報を基に適切なアプリケーションを選択する。そして、アプリケーションに関する情報を抽出し、当該情報に基づくアプリケーションによって医療情報が生成される。
また、アプリケーションを選択するにあたっては、ユーザが自らアプリケーションの選択を行い、当該アプリケーションを利用して医療情報の生成を要求することも可能である。この点については後述するが、例えば、ユーザが使用するクライアント端末1の表示部にテナント型医療情報システム2として推奨するアプリケーションの一覧を表示させることも可能である。ユーザは当該表示された一覧を参考にアプリケーションの選択を行うことができる。
ユーザ自身に関する情報については、例えば、ユーザの氏名、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時間等が挙げられる。
また、上述したような利用に関する情報(利用歴)については、表、グラフ、或いは、ランキングといった形式によってクライアント端末1に表示させてユーザに当該情報を提供することができる。なお、提供される利用歴に関しては、例えば、個々のユーザごとの利用歴を表示しても良く、或いは、テナント型医療情報システム2全体における利用歴であっても良い。
なお、このアプリ利用歴記憶部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に表示される流れを説明した。
次に、設定データベース23に記憶されているアプリケーションに関する情報をユーザに提供する(紹介する)流れについて説明する。
大家であるシステム運営者が設置するテナント型医療情報システム2には、複数のアプリケーションが提供されており、ユーザは目的、用途に応じて適切なアプリケーションを選択して利用する。
この際、ユーザは自らが利用する予定であるアプリケーションを事前に選択することができていれば、最初から所望のアプリケーションを指定して画像処理等の処理を行い、クライアント端末1に表示させることができる。
一方で、利用するアプリケーションを決めかねていたり、普段利用するアプリケーションとは異なったアプリケーションの利用を考えているユーザにとっては、テナント型医療情報システム2内に提供されているアプリケーションの中からユーザが自身で選択して利用するのは、提供されているアプリケーションの数が多ければ多いほど困難である。従って、このような場合にはテナント型医療情報システム2がユーザに対してユーザの条件に合致するアプリケーションを紹介することが有効である。
ユーザへのアプリケーションの紹介は、ユーザにおけるアプリケーション選択の一助になるためユーザに対するメリットが大きい。またアプリケーションの提供者にとってもアプリケーションの紹介は、いわば宣伝になるため、新たに自身が提供するアプリケーションを利用してもらう機会が設定されることになり、例えば新規に開発したアプリケーションの提供のチャンスとなり得る。
さらには、システム運営者である大家にとってもユーザにアプリケーションを紹介し、その中から利用するアプリケーションを選択してもらうことは、ユーザにおいて利用されるアプリケーションの固定化を防ぐことになる。そして、ユーザが都度いろいろなアプリケーションを利用するという状態になれば、新たにテナント型医療情報システム2に提供されるアプリケーションを増やすことにもつながる。
アプリケーションの利用に当たっては、ユーザの使い勝手や慣れ等によって、ユーザがある特定の処理を行う際に利用するアプリケーションはいつも同じアプリケーションということが少なからずある。このようにユーザが利用するアプリケーションが半ば固定してしまうと、同じ処理を行うに当たって使い慣れているアプリケーションを利用せず別の類似するアプリケーションを利用するということは少なくなる。このようになると、ユーザとアプリケーションとが固定されてしまい、アプリケーションが通常利用するユーザ以外に訴求せず、新たなユーザの利用を獲得することが困難となる。
すなわち、テナント型医療情報システム2内に常に魅力的な、どのユーザも利用したいと思わせるアプリケーションが揃っていることで、新たなユーザの獲得、ユーザに利用されることによるアプリケーションの改良、開発が行われるようになる。従って、如何にユーザにアプリケーションを利用してもらうかがテナント型医療情報システム2内の活性化のためにも必要なこととなる。
以下の実施の形態の説明においては、ユーザにアプリケーションの紹介を行う場面を分けて説明する。
まずは、ユーザが自身の診察や検査において患者の医療情報を必要としており、テナント型医療情報システム2に当該医療情報の表示を要求する場面である。なお、この場面においては、利用するアプリケーションが既に決まっているユーザにとっては何ら問題になるところではなく、利用するアプリケーションを指定することで統合ビューア21へと要求を出す。
図8は、実施の形態におけるアプリケーション紹介の流れの一例を示すフローチャートである。利用するアプリケーションを決めかねている、或いは、新たなアプリケーションの利用を検討しているユーザは、医療情報システムSを起動した後、クライアント端末1上でアプリケーションの表示を要求するための画面を表示させる(ST31)。この画面は、自身がアプリケーションを選択する際に、その候補となる複数のアプリケーションを表示させるための条件を設定するものである。
図9は、実施の形態におけるアプリケーション紹介に当たってユーザに示される画面例M1である。図9では「アプリ表示要求」とある画面例M1が示されており、その下部に、「ユーザID」、「部位」、「処理方法」、「費用」、「利用レベル」といった条件の項目が示されている。
なお、以下、各説明に当たって種々の画面例が示されるが、その表示項目、レイアウト等については、あくまでも例示に過ぎず、当該表示項目、レイアウト等は任意に設定することができる。従って、図面上示されている表示項目、レイアウト等に限定されるものではない。
「ユーザID」とは、アプリケーションの利用を予定している、医師や技師等のユーザに付与されているIDである。当該IDが入力されることで、ユーザ自身の情報を把握することができる。その他、ユーザ自身に関する情報として、例えば、ユーザの氏名やユーザが使用するクライアント端末1に関する情報も挙げることができ、これらの情報が入力されることとしても良い。また、クライアント端末1に関する情報に関しては、例えば、表示要求として統合ビューア21へと要求する情報の中に予め組み込まれていても良い。
ユーザ自身に関する情報が入力されることで、例えば、ユーザの所属科や専門等に関する情報が把握でき、紹介するアプリケーションを選択する際の有力な情報となり得る。
「部位」は、診察及びそのための処理を行う対象となる部位(疾患部位)である。アプリ提供者によって提供されるアプリケーションは、その部位特有の表示形態等もあることから、部位ごとに独立して提供されていることも多い。従って、この情報が条件として設定されることによって、ユーザがどの部位に対して用いられるアプリケーションを求めているかが把握でき、より適切な絞り込み、表示を行うことができる。なお、図9に示す画面例M1では、プルダウンメニューの形式を採用していることから、当該プルダウンメニューをクリックすることで部位を選択することができる。
「処理方法」は、例えば、疾患部位をどのようにアプリケーションを利用して表示させるか示している。この項目についてもプルダウンメニューが設けられていることから、ユーザが望む処理方法を選択し、アプリケーションを表示させる条件とすることができる。
「費用」は、表示させるアプリケーションの利用料金としてどの範囲のものを望むか、を設定する項目である。ここでは、下限と上限を設定することができるようにされている。この「費用」の項目を入力しなかった場合には費用条件がないことになるため、利用料金が低価格のアプリケーションから高価格のアプリケーションまでその利用料金の多寡を問わずクライアント端末1に表示されることになる。
次の「利用レベル」は、ユーザがアプリケーションを利用する上でのユーザのレベル(アプリケーションのレベル)を設定するものである。アプリケーションによっては、同じ処理を行うものであっても、例えば、ビギナーのユーザが利用することのできるアプリケーション、ベテランでなければ利用することができないアプリケーションというように、アプリケーションを利用する上でユーザに相応のレベルが求められる場合も考えられる。そこで、ユーザがこの利用レベルを自ら設定することによって、自らのレベルに合ったアプリケーションの表示を行わせることができる。図9に示す画面例M1では、「高」、「中」、「低」の3段階に分かれ、ユーザが該当するレベルのラジオボタンをクリックすることで設定することが可能とされている。
ユーザは表示させるアプリケーションに関する条件を設定した後、例えば、図9の画面例M1に示されているような「決定」ボタンを押すことで、表示要求の条件が決定される(ST32)。決定された表示要求の条件は、クライアント端末1から統合ビューア21へと送信される(ST33)。
表示要求を受信した統合ビューア21は、ワークフローマネージャ22へと配信し、ワークフローマネージャ22では、表示要求に関する条件を確認する(ST34)。この表示要求は、ワークフローマネージャ22にとっては、すなわち表示させるアプリケーションの選択要求となる。そのため、図8のフローチャートでは「表示(選択)条件」と表わしている。
その上で、ワークフローマネージャ22は、設定データベース23から表示(選択)条件に合致するアプリケーションに関する情報を抽出する(ST35)。ワークフローマネージャ22は、抽出したアプリケーションとその情報を統合ビューア21へと戻し(ST36)、統合ビューア21ではこれらの情報を整理して表示に適した状態に統合する(ST37)。その上で、ユーザが使用するクライアント端末1の表示部に統合した画面を表示させる(ST38)。
図10は、実施の形態におけるアプリケーションの紹介画面の例であり、図11は、別の画面例である。
図10に示す画面例M2では、5つの項目が設けられており、順に「名称」、「提供者」、「特徴」、「料金」、「備考」である。「名称」は、表示されるアプリケーションの名称である。また、「提供者」は、当該アプリケーションを提供するアプリ提供者(店子)のことである。一方、「特徴」はアプリケーションの特徴であり、「料金」は、当該アプリケーションを利用する場合に掛かる料金のことである。なお、この料金の設定は任意に行うことができるが、図10に示す料金の項目では「1検査」単位、或いは、「1月」単位とされている。
「備考」の欄には、当該アプリケーションに関する情報が書き込まれている。ここの欄には、図10で示されているように、「料金」に関する情報であっても、或いは、別途アプリ提供者の宣伝等、自由に表示させることができるようにされていても良い。
例えば、「3D−Pro」というアプリケーションは、「A」というアプリ提供者が提供するものであり、「上級者向け」のアプリケーションであることが示されている。また、「今月いっぱいのお試し価格」として、1検査当たり「□□円」で利用することが可能である旨、表示されている。
また、アプリケーションの名称の横にはチェックを付けることができる欄が設けられており、この欄にチェックを入れると、当該アプリケーションの詳細を表示させることができる。
図11に示す画面例M3は、図10に示す画面例M2とはまた別の態様で示される。図10に示す画面例M2と異なるのは、項目の1つに「総合評価」という項目が設けられており、既に当該アプリケーションを利用したことのあるユーザによる評価が示されている点である。上述した「3D−Pro」というアプリケーションに関しては、「総合評価」の欄に4つの星印が表示されている。一方、他のアプリケーションに対しては星が2つ、或いは、1つしか表示されていない例も見受けられることから、表示されたアプリケーションの中では良い評価を得ているものと考えられる。
また併せて「コメント」欄も設けられており、このコメント欄には、当該アプリケーションを利用したユーザのコメントが記載されている。アプリケーションの表示を受けたユーザは「総合評価」や「コメント」の欄も勘案して自身が利用するアプリケーションの選択を行うことができる。
上述したアプリ提供者から提供されるアプリケーションに関する情報に関しては、個々のユーザの状況が反映されていても良い。例えば、図10においては「料金」の項目が示されているが、特定のアプリケーションを頻繁に利用するユーザに対しては、他のユーザよりも引き下げられた単価を表示させることとしても良い。また、アプリ提供者は、適宜紹介画面に表示させるアプリケーションに関する情報を設定、変更することができる。
さらに、図12は、実施の形態において紹介されたアプリケーションのうち、チェックが付けられたアプリケーションに関する概要を示す画面例M4である。図12に示す画面例M4は、例えば、図10、或いは図11に示されている「ボリュームイメージ」というアプリケーションに関してユーザがより詳細な内容を知りたいとして、「名称」の脇に設けられている「□欄」にチェックをいれることによって表示されるものである。
画面例M4においては、左上部にアプリケーションの名称が示されており、以下、下に向けて順に「特徴」、「料金」、「提供者」、及び「利用者のコメント」が表示されている。また、さらにその下には、当該「ボリュームイメージ」の特徴(評価)がレーダーチャートで表示されている。
画面例M4の右側には、当該「ボリュームイメージ」を利用した場合の表示例がいくつか示されている。ユーザはこの表示例を見ることで自身がこのアプリケーションを利用して行おうとしている処理の結果を思い描くことができる。さらに表示例の下部には、当該アプリケーションの前後でチェックが付されたアプリケーションの詳細情報画面へと遷移するための「戻る」、「次へ」ボタンが設けられているとともに、図10や図11の紹介(表示)画面へ遷移するための「紹介画面へ」というボタンも設けられている。
なお、図12に示す画面例M4では示されていないが、当該画面例M4に表示させたアプリケーションの利用に当たって、この画面例M4から直接利用対象として選択し、統合ビューア21へと表示要求をおこなうことができるようにされていても良い。或いは、選択する対象として、例えばクライアント端末1内に当該アプリケーションの情報を保存しておくこと、或いは、購入できるようにされていても良い。
次に、ユーザがアプリケーションを利用した結果が統合ビューア21によってクライアント端末1上に表示されてアプリケーションの利用が終了した後に、アプリケーションの紹介(表示)がなされる場合である。この場合は、上述した場合と異なり、より宣伝的な意味合いが強い表示となる。
図13は、実施の形態におけるアプリケーション紹介の別の流れの一例を示すフローチャートである。以下に説明する流れは、図4に示す医療情報システムによる医療情報の提供の流れの最後(ステップST20)につながる流れである。すなわち、ユーザがアプリケーションを利用して処理を行い、統合ビューア21によって処理結果が表示された後、統合ビューア21によってワークフローマネージャ21に対して当該アプリケーションの利用歴が送信された後の流れである。この場合、ユーザには処理結果がクライアント端末1に表示された後、アプリケーションの表示(紹介)が行われることになる。
ワークフローマネージャ22は、統合ビューア21から利用歴を受信する(ST41)。ワークフローマネージャ22では、受信した利用歴に係るアプリケーションに関する情報を確認し、設定データベース23から当該アプリケーションに類似するアプリケーションに関する情報を抽出する(ST42、ST43)。
ここで、利用歴に係るアプリケーションに類似するアプリケーションを抽出するに当たっては、両者が類似するアプリケーションであるか否かを判断する必要がある。例えば、ワークフローマネージャ22の推奨アプリ判定部22bがその判断を行う。推奨アプリ判定部22bは、例えば、利用歴に係るアプリケーションが処理の対象とする疾患部位と同じ部位の処理に用いられる他のアプリケーションを類似するアプリケーションとして抽出する。
なお、ここで抽出されるアプリケーションが利用歴に係るアプリケーションと類似すると判断する基準については、上述したようにワークフローマネージャ22が設定データベース23からアプリケーションを抽出する条件と基準とする等、事前に設定しておくことができる。
ワークフローマネージャ22は、抽出したアプリケーションとその情報を統合ビューア21へと送信し(ST44)、統合ビューア21ではこれらの情報を整理して表示に適した状態に統合する(ST45)。その上で、ユーザが使用するクライアント端末1の表示部に統合した画面を表示させる(ST46)。
以上説明した通り、何らかの機会にユーザに対してテナント型医療情報システム2が保持するアプリケーションに関する情報を提供することによって、ユーザはアプリケーションの選択の幅が広がる。特に医療の分野においては情報の処理を行う際に用いられるアプリケーションは特殊なものが多く、或いは、例えば部位ごと、疾患ごとというように、アプリケーションの専門性が高い場合が多い。このような場合にユーザが利用を望むアプリケーションを複数表示(紹介)することでユーザは簡易、確実に所望の処理を行うことができるアプリケーションを選択することができる。
一方、アプリ提供者にとっては自身の提供するアプリケーションをユーザに直接宣伝する機会を得ることになる。さらには、表示されたアプリケーションの中からユーザが新たなアプリケーションを選択し利用してくれることにより、当該アプリケーションの利用回数が増え、それに伴って得ることのできる利用料金も増加する。アプリ提供者が、例えば当該利用料金を基にアプリケーションの開発を行えばユーザにとってもメリットがある。
また、大家であるシステム運営者にとっても店子であるアプリ提供者が新規なアプリケーションを開発しユーザに提供することによって、新たなユーザ、新たなアプリ提供者がシステムに参加することになってテナント型医療情報システム2の利用者が増え、システム自体が活況を呈することにもつながる。
上述したようにテナント型医療情報システム2では、ユーザのアプリケーションの利用歴も収集していることから、当該利用歴を用いてアプリ提供者、或いは、システム運営者がそれぞれマーケティング活動を行い、よりユーザのニーズに合ったアプリケーションの提供を行うことが可能となる。
従って、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとすることで、ユーザの利便性の向上を図るとともにシステム運営者やアプリケーション提供者による十分なマーケティング活動を行うことが可能な医療情報システムを提供することができる。
なお、上述したアプリケーションの表示は、ユーザを対象とすることを前提に説明をしてきたが、例えば、当該アプリケーションの表示をアプリ提供者に対して開示できるようにしても良い。このような対応を取ることによって、ユーザの感想、コメント等をアプリ提供者も取得することができ、今後の開発等に生かすことができる。
また、上述した説明では、アプリケーションのユーザへの表示について、アプリケーション選択時、或いは、アプリケーションの利用後というように、その時を設定して説明した。但し、このユーザへの表示時期を、例えば、定期的に、或いは、新たなアプリケーションがアプリ提供者から提供された場合に随時、とすることも当然可能である。
さらに、ユーザに表示するアプリケーションは、これまでの説明では、ワークフローマネージャが設定データベースから該当するアプリケーションを抽出して統合ビューアを介して表示させていた。但し、例えば、ワークフローマネージャが設定データベースから抽出するのではなく、ユーザからの表示要求がある都度、表示対象となりうるアプリケーションの提供者にシステム運営者が連絡をし、アプリ提供者自身がユーザに直接対象となるアプリケーションの特徴を宣伝する方法を採用しても良い。
また、アプリケーションの表示を行うだけではなく、例えば、ユーザの属性等に合わせて診療のワークフローに沿った各場面で必要となると思われるアプリケーションを順に表示、紹介するようにしても良い。このように診療ワークフローに沿って表示させることによって、ユーザの使い勝手は各段に向上するとともに、アプリ提供者にとっても一度に表示されるアプリケーションの数が増加することになるため、有効な宣伝、マーケティング活動を行うことができる。
本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することを意図していない。この実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。