JP6563170B2 - 医療情報システム及び医療情報提供方法 - Google Patents

Description

本発明の実施の形態は、医療情報システム及び医療情報提供方法に関する。

近年、技術の進展に伴って、医療機関内にも各種電子機器を利用した医療画像診断装置やシステムが導入されている。医療画像診断装置は、被検体内部の情報を収集し、この収集された情報に基づいて被検体内部を画像化して医療画像を生成する装置であり、例えば、Ｘ線ＣＴ装置（computed tomography：コンピュータ断層撮影装置）や、磁気共鳴診断装置（ＭＲＩ：magnetic resonance imaging）等が該当する。

また、医療機関内に構築されるシステムとしては、例えば、病院情報管理システム（ＨＩＳ：Hospital Information System）、放射線部門情報管理システム（ＲＩＳ：Radiological Information System）、医療画像管理システム（ＰＡＣＳ：Picture Archiving Communication System）や検査システムといったシステムが挙げられる（特許文献１参照）。

これら医療機関に構築されるシステムに関しては、中規模以上の医療機関に導入されるシステムは、多くのシステムが複数社のシステムによって運用されることが多い。これはシステムを開発する会社それぞれに得意な分野があり、また、医療情報を生成するアプリケーションにしても、Ｘ線画像の解析に強いアプリケーションやＸ線ＣＴ装置で得られたボリュームデータから３Ｄ画像を生成するに適したアプリケーション等々、様々なアプリケーションが存在し、導入されるからである。

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

しかしながら、上記特許文献１において開示されている発明では、次の点について配慮がなされていない。

すなわち、上述したように１つの医療機関内に、例えば、複数のシステム、複数のアプリケーションが導入された場合、それぞれのシステム、アプリケーションが区々となってしまうことから、ユーザである医師、或いは、技師の使い勝手は決して良くないと考えられる。また、アプリケーションについては、当該アプリケーションを利用する者の好み、嗜好等もあり、また、アプリケーションの内容等が高度でありユーザの実力によって使いこなせない、といった場合もあり得る。

さらには、複数のシステム、複数のアプリケーションが乱立、導入されることによって、その世代（バージョン）がまちまちになることも考えられる。このような場合、例えば、バージョンの違いによって一方で取得した医療情報が他方では保存できない、或いは、閲覧できない、といった現象が発生し得る。これは患者の治療、救命に当たる医療機関にあってはならない重篤な障害となりかねない。

本発明は上記課題を解決するためになされたものであり、本発明の目的は、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとすることで、ユーザの利便性の向上を図ることが可能な医療情報システム及び医療情報提供方法を提供することにある。

請求項１に記載の発明の特徴は、医療情報システムにおいて、ユーザが使用するクライアント端末と、システム運営者が設置し、通信ネットワークを介して前記クライアント端末から送信されるユーザからの要求に応じて、ユーザが必要としている医療情報の生成を行う上で適切なアプリケーションをユーザの条件を基に選択するワークフローマネージャと、アプリケーションによって生成される医療情報を収集し、ワークフローマネージャから示される表示レイアウトに沿って医療情報の統合を行い、クライアント端末に表示させる統合ビューアと、を備えるテナント型医療情報システムと、テナント型医療情報システムと通信ネットワークを介して接続され、テナント型医療情報システムの要求に応じて、ユーザが必要としている医療情報の生成をアプリ提供者によって提供されるアプリケーションを用いて行うアプリケーションサーバとを備える。

請求項９に記載の発明の特徴は、医療情報システムにおいて、ユーザが使用するクライアント端末と、システム運営者が設置し、通信ネットワークを介してクライアント端末から送信されるユーザからの要求に基づいて必要な医療情報を収集し、表示レイアウトに沿ってクライアント端末に表示させるテナント型医療情報システムと、テナント型医療情報システムと通信ネットワークを介して接続され、テナント型医療情報システムの要求に応じて、ユーザが必要としている医療情報の生成をアプリ提供者によって提供されるアプリケーションを用いて行うアプリケーションサーバと、を備え、テナント型医療情報システムが備える、ユーザが必要としている医療情報の生成を行う上で適切なアプリケーションを選択するワークフローマネージャに対してユーザからの要求を伝えるとともに、アプリケーションサーバによって生成される医療情報を収集し、ワークフローマネージャから示される表示レイアウトに沿って医療情報の統合を行い、クライアント端末に表示させる統合ビューアには、アプリケーションの利用に応じて掛かる料金を算出する課金エンジンが接続されており、課金エンジンは、料金の算出の基となる利用料金に関する情報を記憶する課金データベースからの情報を基に料金の算出を行う。

請求項１３に記載の発明の特徴は、医療情報提供方法において、テナント型医療情報システム内の統合ビューアがユーザが使用するクライアント端末を介してユーザからの要求を受信するステップと、要求を確認するとともに、統合ビューアが受信する情報の中から確認された要求に対応する情報を選択するステップと、要求及び要求に対応する情報を統合ビューアからワークフローマネージャへ送信するステップと、ワークフローマネージャは、受信した情報を基に設定データベースから要求を充足する医療情報の生成に必要なアプリケーションに関する情報及びクライアント端末における表示レイアウトに関する情報を設定データベースから抽出するステップと、ワークフローマネージャは、抽出されたアプリケーションに関する情報及び表示レイアウトに関する情報を統合ビューアに送信するステップと、統合ビューアは、アプリケーションに関する情報をシンクライアントマネージャを介してアプリケーションを備えるアプリケーションサーバに送信するステップと、アプリケーションサーバにてユーザが要求する医療情報を生成するステップと、アプリケーションサーバが生成した医療情報をシンクライアントマネージャへ送信するステップと、シンクライアントマネージャがアプリケーションサーバから送信された医療情報を統合ビューアへと送信するステップと、統合ビューアは、受信した医療情報を表示レイアウトに関する情報を基に統合するステップと、統合された医療情報をユーザが使用するクライアント端末へ表示させるステップとを備える。

請求項１４に記載の発明の特徴は、医療情報提供方法において、テナント型医療情報システム内の統合ビューアがユーザが使用するクライアント端末を介してユーザからの要求を受信するステップと、要求を確認するとともに、統合ビューアが受信する情報の中から確認された要求に対応する情報を選択するステップと、要求及び要求に対応する情報を統合ビューアからワークフローマネージャへ送信するステップと、ワークフローマネージャは、受信した情報を基に設定データベースから要求を充足する医療情報の生成に必要なアプリケーションに関する情報及びクライアント端末における表示レイアウトに関する情報を設定データベースから抽出するステップと、ワークフローマネージャは、抽出されたアプリケーションに関する情報及び表示レイアウトに関する情報を統合ビューアに送信するステップと、統合ビューアは、アプリケーションに関する情報をシンクライアントマネージャを介してアプリケーションを備えるアプリケーションサーバに送信するステップと、アプリケーションサーバにてユーザが要求する医療情報を生成するステップと、統合ビューアが、アプリケーションサーバにて利用されるアプリケーションの利用開始通知を課金エンジンへ送付するステップと、課金エンジンが、課金データベースから利用されるアプリケーションの利用料金に関する情報を取得するステップと、統合ビューアは、アプリケーションサーバから受信した医療情報を表示レイアウトに関する情報を基に統合するステップと、統合ビューアが、アプリケーションの利用終了通知を課金エンジンへと送付するステップと、利用終了通知を受信した課金エンジンは、利用料金に関する情報からアプリケーションの利用料金を算出するステップと、統合された医療情報、算出された利用料金をユーザが使用するクライアント端末へ表示させるステップとを備える。

実施の形態における医療情報システムの全体構成を示すブロック図である。 実施の形態におけるテナント型医療情報システムの内部構成を示すブロック図である。 実施の形態における医療情報システムによる医療情報の提供の流れを示すフローチャートである。 実施の形態における医療情報システムによる医療情報の提供の流れを示すフローチャートである。 実施の形態における統合ビューアの内部構成を示すブロック図である。 実施の形態におけるワークフローマネージャの内部構成を示すブロック図である。 実施の形態におけるアプリサーバの内部構成を示すブロック図である。 実施の形態における統合ビューアによって統合されクライアント端末に表示される画面例である。 実施の形態における統合ビューアによって統合されクライアント端末に表示される画面例である。 実施の形態における統合ビューアによって統合されクライアント端末に表示される画面例である。 実施の形態における統合ビューアによって統合されクライアント端末に表示される画面例である。 実施の形態における課金エンジンの内部構成を示すブロック図である。 実施の形態におけるアプリケーション利用に基づく課金の流れを示すフローチャートである。 実施の形態における課金データベース内に記憶されている料金テーブルの一例を示す表である。 第２の実施の形態におけるワークフローマネージャ、及び、設定データベースの内部構成を示すブロック図である。 第３の実施の形態におけるワークフローマネージャ、及び、設定データベースの内部構成を示すブロック図である。 第４の実施の形態におけるワークフローマネージャの判断の流れを示す決定木を示す模式図である。

以下、本発明の実施の形態について図面を参照して詳細に説明する。

（第１の実施の形態）
［医療情報システムの全体構成］
図１は、実施の形態における医療情報システムＳの全体構成を示すブロック図である。医療情報システムＳは、ユーザが使用するクライアント端末１と、システム運営者が設置し、通信ネットワークＮを介してクライアント端末１から送信されるユーザからの要求に基づいて必要な医療情報を収集し、表示レイアウトに沿ってクライアント端末１に表示させるテナント型医療情報システム２と、テナント型医療情報システム２と通信ネットワークＮを介して接続され、テナント型医療情報システム２の要求に応じて、ユーザが必要としている医療情報の生成をアプリ提供者によって提供されるアプリケーションを用いて行うアプリサーバ３とを備える。

さらにこの実施の形態における医療情報システムＳには、通信ネットワークＮを介して、医療画像診断装置４と、管理サーバ５とが併せて接続されている。

クライアント端末１は、ユーザである、医師、或いは、技師によって使用される情報端末である。このクライアント端末１としては、例えば、ＰＣ（パーソナルコンピュータ）や、ＷＳ（診療ワークステーション）等が考えられる。また、クライアント端末１が携帯可能であることを否定するものではない。さらに、クライアント端末１は、少なくともユーザの操作を受け付ける入力部と、各種処理を行うＣＰＵを備える処理部と、処理内容やユーザの要求に基づいてテナント型医療情報システム２によって収集された医療情報等を表示する表示部を備えている。

テナント型医療情報システム２は、ユーザが患者の診断、検査等において必要とする医療情報を、ユーザの要求に応じて収集しクライアント端末１の表示部に表示させる機能を果たす。ここで「医療情報」とは、カルテ等の文字情報、血液検査等の数値データや波形データ、Ｘ線ＣＴ装置のような医療画像診断装置が取得（撮影）する医療画像に関する情報、或いは検査レポート等の文字・画像混在情報等、を含む概念である。

テナント型医療情報システム２は、システム運営者が設けるもので、ユーザは当該システムを利用することで、各種アプリケーションを効率よく利用することができる。すなわち、テナント型医療情報システム２には利用することが可能な単数、または複数のアプリケーションと接続されており、ユーザはテナント型医療情報システム２を介してこれらのアプリケーションを利用し、必要な医療情報を取得することができる。この点、ユーザが医療情報の取得に当たって、個別にアプリケーションを探し出して利用するといった手間を省くことができる。

また、ユーザ自ら医療情報の収集を行う場合には、多くの場合、どうしても自らの思考（嗜好）に合った特定のアプリケーションを利用しがちであるが、この実施の形態におけるテナント型医療情報システム２を利用することで、特定のアプリケーションにその利用が集中することなく、適宜適切なアプリケーションが選択され、当該選択されたアプリケーションによる処理がなされた医療情報を取得することができる。

換言すれば、システム運営者が設けるテナント型医療情報システム２は、このシステム運営者が「大家」という位置付けにあり、一方、選択して利用されるアプリケーションを提供するアプリ提供者は、いわば「店子」の位置付けとなる。従って、大家（システム運営者）が設けるテナント型医療情報システム２内には店子（アプリ提供者）がアプリケーションを提供しており、この点を示して「テナント」と表わしている。ユーザは自分が要求する医療情報を取得するに当たって、テナントであるアプリ提供者が提供する各種アプリケーションを利用する。

なお、テナント型医療情報システム２の詳細な内部構成については、図２を利用して後述する。また、図１に示す医療情報システムＳにおいては、テナント型医療情報システム２の設置場所については特に示されていない。従って、テナント型医療情報システム２は、医療機関内に設けられていても良く、或いは、クラウド・コンピューティング技術を用いて医療機関外に設けられていても良い。さらに、各医療機関ごとに設けられていても、或いは、複数の医療機関で共有していても良い。

アプリサーバ３は、アプリ提供者が提供するアプリケーションを記憶するとともに、ユーザの要求に従って、必要とされる医療情報を生成する。より詳細には、ユーザがクライアント端末１を介して要求をテナント型医療情報システム２に送信すると、テナント型医療情報システム２内において当該要求に最適なアプリケーションが選択され、当該アプリケーションを備えるアプリサーバ３に対して、医療情報の生成が依頼される。アプリサーバ３では要求に応じて医療情報を生成し、改めてテナント型医療情報システム２に送信する。

アプリサーバ３から生成された医療情報を受信したテナント型医療情報システム２では、この医療情報を当該要求を出したユーザのクライアント端末１にまとめて（統合して）表示させる。

なお、アプリサーバ３の内部構成については、図面を利用して後述する。また、アプリサーバ３は、格納するアプリケーションごとに設けられていても良く、或いは、アプリ提供者ごとに設けられていても良い。後者の場合、１つのアプリサーバ３内に当該アプリ提供者が提供するアプリケーションが単数、或いは、複数含まれて（記憶されて）いる。

医療画像診断装置４は、被検体を撮影してその内部情報を取得する医療画像取得（撮影）装置である。医療画像診断装置４としては、例えば、上述したようにＸ線ＣＴ装置や磁気共鳴診断装置等が該当する。医療画像診断装置４において取得された各撮影データは、テナント型医療情報システム２に送信されて、後述する画像管理部に格納（記憶）される。また、図１には示していないが、例えば、通信ネットワークＮに接続されている画像サーバ等に記憶されていても良い。

管理サーバ５は、例えば、医療機関内に構築されている、上述した病院情報管理システム（ＨＩＳ）、放射線部門情報管理システム（ＲＩＳ）、医療画像管理システム（ＰＡＣＳ）等が該当する。なお、管理サーバ５に入力された各種情報は、併せてテナント型医療情報システム２にも送られ、ユーザからの要求に対処する際に用いられる。

なお、図１に示す医療情報システムＳでは、通信ネットワークＮに２つのクライアント端末１Ａと１Ｂ（以下、適宜これら複数のクライアント端末をまとめて「クライアント端末１」と表わす。）、アプリサーバ３Ａ及び３Ｂ（以下、適宜これらのアプリサーバをまとめて「アプリサーバ３」と表わす。）が接続されているが、通信ネットワークＮに接続されるクライアント端末１、或いは、アプリサーバ３の数は単数、或いは複数のいずれでも良く、その数は任意である。 また、医療画像診断装置４は、図１では１つのみ通信ネットワークＮに接続されているが、この医療画像診断装置４の数についても任意である。

通信ネットワークＮは、クライアント端末１、テナント型医療情報システム２、アプリサーバ３、医療画像診断装置４、及び管理サーバ５をそれぞれつなぎ、互いの間で、例えば医療情報のやりとりを可能とする。

通信ネットワークＮの例としては、ＬＡＮ（Local Area Network）やインターネット等の通信ネットワークを挙げることができる。また、この通信ネットワークＮで使用される通信規格は、ＤＩＣＯＭ（Digital Imaging and Communication in Medicine）等、いずれの規格であっても良い。

［テナント型医療情報システムの構成］
図２は、実施の形態におけるテナント型医療情報システム２の内部構成を示すブロック図である。テナント型医療情報システム２は、本体部２Ａと画像管理部２Ｂの大きく２つの部分に分かれている。本体部２Ａは、ユーザからの要求を受け付けてユーザに必要な医療情報を生成して戻す機能を備えている。一方、画像管理部２Ｂは、医療画像診断装置４が取得した医療画像を保管、管理する。

本体部２Ａは、統合ビューア２１と、ワークフローマネージャ２２と、設定データベース２３と、シンクライアントマネージャ２４と、アプリケーション２５（アプリケーションＡ）と、課金エンジン２６と、課金データベース２７とから構成されている。また、画像管理部２Ｂは、画像情報マネージャ２８と、画像レポートデータベース２９とから構成されている。

各部の機能を情報の流れに沿って説明すると、まず統合ビューア２１は、まずユーザが使用するクライアント端末１から要求を受信する。受信された要求は、テナント型医療情報システム２に送信される、例えば、管理サーバ５からの情報と突き合わせて、まとめられてワークフローマネージャ２２に送信される。

ワークフローマネージャ２２は、ユーザからの要求に応じて（統合ビューア２１から送信された情報に基づいて）、ユーザが必要としている医療情報の生成を行う上で適切なアプリケーションを選択する。ワークフローマネージャ２２には設定データベース２３が接続されている。設定データベース２３内には、テナント型医療情報システム２に接続されているアプリサーバ３にて提供されているアプリケーションに関する情報が記憶されている。そこで、ワークフローマネージャ２２が適切なアプリケーションを選択する際には、設定データベース２３を検索して該当するアプリケーションに関する情報を取得する。

シンクライアントマネージャ２４は、図１に示すアプリサーバ３に通信ネットワークＮを介して接続されており、ワークフローマネージャ２２によって選択されたアプリケーションを提供するアプリサーバ３を制御して、ユーザからの要求に応じた医療情報の生成を行わせる。また、アプリサーバ３において生成された医療情報は、シンクライアントマネージャ２４を介して統合ビューア２１に送信される。

統合ビューア２１は、シンクライアントマネージャ２４から送信された医療情報を受信し、それぞれの医療情報を予め定められた表示レイアウトに沿って統合する。統合ビューア２１によって統合された医療情報は、ユーザが使用するクライアント端末１の表示部に表示される。

アプリケーション２５（アプリケーションＡ）は、システム運営者が提供するアプリケーションの１つである。つまり、アプリ提供者がアプリケーションを提供するのと同じように、テナント型医療情報システム２を運営するシステム運営者が自ら提供するアプリケーションである。システム運営者が提供するアプリケーションであることから、アプリケーション２５（アプリケーションＡ）は、例えば、クライアント端末１に表示される基本的な画面設定に関するアプリケーション、或いは、画像管理部２Ｂに記憶、管理されている医療画像の処理を行うアプリケーションである。

なお、図２では、１つのアプリケーション２５（アプリケーションＡ）が統合ビューア２１に接続されているが、このようなアプリケーションがどのくらい統合ビューア２１に接続されている（テナント型医療情報システム２内に設けられている）かは自由である。

また、統合ビューア２１には、課金エンジン２６が接続されている。この課金エンジン２６は、ユーザがアプリケーションを利用した場合に、その利用量に応じて課金し、ユーザに請求する利用料金を算出する。利用料金は、利用量ごとはもちろん、例えば、アプリケーションごと、アプリ提供者ごとにもそれぞれ設定されている。これらアプリケーションの利用料金に関する情報は、課金データベース２７に予め記憶されている。そこで、課金エンジン２６は、統合ビューア２１からアプリケーションの利用の開始、終了等に関する情報を得て、課金データベース２７からアプリケーションの利用料金に関する情報を基にユーザのアプリケーション利用料金を算出する。

画像管理部２Ｂは、画像情報マネージャ２８と、画像レポートデータベース２９とから構成されている。画像情報マネージャ２８は、医療画像診断装置４によって取得される医療画像に関する情報を管理する。一方、画像レポートデータベース２９は、画像情報マネージャ２８を介して医療画像診断装置４から送られてきた医療画像を記憶する。

なお、上述したこれら各部の内部構成、機能や働きについては、後述する医療情報の提供処理に関する流れを説明する際に併せて説明する。

［ユーザの要求に基づく医療情報の提供の流れ］
図３及び図４は、実施の形態における医療情報システムＳによる医療情報の提供の流れを示すフローチャートである。すなわち、これらのフローチャートには、ユーザが自身の診察や検査において必要とする患者の医療情報について、テナント型医療情報システム２に当該医療情報の表示を要求し、この要求に従った医療情報がユーザの使用するクライアント端末１に表示されるまでの流れが示されている。

まず、統合ビューア２１において、ユーザによってテナント型医療情報システム２（統合ビューア２１）に対して必要とされる医療情報の表示が要求されたか否かが確認される（ＳＴ１）。これは具体的には、ユーザがクライアント端末１を使用して統合ビューア２１を起動したか否かを、要求を受け付けた統合ビューア２１が確認することで行われる。

ここで、ユーザが使用するクライアント端末１から統合ビューア２１に対して送られる情報としては、例えば、患者情報、当該患者に関して必要とされる医療情報やユーザ自身に関する情報が挙げられる。その他、例えば、取得される医療情報をクライアント端末１の表示部にどのように表示させるかといった表示レイアウトに関する情報や取得した医療情報をどのような場面（シーン）で利用するかという情報が含まれていても良い。

患者情報としては、例えば、患者氏名、患者ＩＤ、或いは、患者の疾患部位等を挙げることができる。また、例えば、造影検査であるのか否か、といった検査の方法に関する情報や検査に利用された医療画像診断装置４の種別といった情報も含まれる。当該患者に関して必要とされる医療情報は、例えば、疾患部位に関する医療画像、心電図、或いは、検査結果を示す数値といった情報である。医療情報の生成に当たっては、テナント型医療情報システム２（医療情報システム１）に提供されているアプリケーションのうち、それぞれ要求される医療情報を生成するに最適なアプリケーションが利用される。

従って、例えば、患者のＸ線ＣＴ画像を用いて所望の医療情報の取得を要求する場合であって、当該医療情報を生成することができるアプリケーションが複数提供されている場合には、ワークフローマネージャ２２が適宜後述する各種情報を基に適切なアプリケーションを選択する。そして、アプリケーションに関する情報を抽出し、当該情報に基づくアプリケーションによって医療情報が生成される。また、アプリケーションを選択するにあたっては、ユーザが自らアプリケーションの選択を行い、当該アプリケーションを利用して医療情報の生成を要求することも可能である。

ユーザ自身に関する情報については、例えば、ユーザの氏名、ＩＤ番号、或いは、ユーザが使用するクライアント端末１に関する情報を挙げることができる。これらの情報を統合ビューア２１に送信する情報に含めることによって、例えばユーザが良く利用するアプリケーション等、医療情報を生成するアプリケーションを選択するに当たって有益な情報となり得る。

表示レイアウトに関する情報は、必要とする医療情報が複数にわたる場合に、それらの医療情報をクライアント端末１の表示部に表示させる際、どのような配置で表示させるか、という情報である。表示する医療情報が１種類の場合は特に表示部上のレイアウトに拘泥しなくても足りるが、複数の医療情報が表示される場合には、見易さ、という観点が重要となる。また、医療情報の見易さについては、個々のユーザによっても異なることが考えられるため、その場合には特にこの表示レイアウトについての情報が必要となる。

医療情報が利用される場面（シーン）に関する情報とは、例えば、ユーザが統合ビューア２１に要求する医療情報を通常の診察等で用いるのか、それとも診断決定木を利用する際に用いられるのか、という情報である。なお、後者の診断決定木を利用する場面については、後述する。

医療情報が通常の診察等で用いられる、といっても、その利用される場面（シーン）は多様である。従って、このシーンに関する情報をアプリケーションに関する情報を抽出、判定する際に適宜参照することで、当該シーンにて要求される（当該シーンに合った）医療情報の生成に適したアプリケーションに関する情報を抽出、判定することができる。

ここで「場面（シーン）」と表わしているのは、例えば、診察、検査に関する場面を想定しており、例えば、「スクリーニング」、「精査」、「フォローアップ」の３つに大別することができる。

「スクリーニング」とは、健診等をやって多くの人を検査してその中から異常が見られる人をピックアップすること、或いは、ある患者において、症状が出ている部分を検査するとともに、その他の部分（例えば全身）についてもチェックしてみることを表わしている。「精査」は、異常が発見された人を精密に検査すること、すなわち、主原因について、進んでいるのか、良性か悪性か等、現状を詳しく確認することを指している。精査の結果をもって確定診断ができる。そして、「フォローアップ」とは、治療後にその患者がどのような状態にあるかを診ること、或いは、適切な治療方針だったのか、といった診断、判断等のチェックである。

これら医療情報が利用される場面（シーン）によって、クライアント端末１の表示部に表示されるアプリケーションの種類、表示レイアウト等は大きく異なる可能性がある。従って、医療情報が利用される場面（シーン）を把握して医療情報を生成するに適したアプリケーションを決定することは重要である。

なお、場面（シーン）の特定に当たっては、例えば、上述した「ユーザ自身に関する情報」を利用することができる。このユーザ自身に関する情報として、例えば、クライアント端末１の設置されている場所が挙げられる。例えば診察室なのか、検査室なのかによってクライアント端末１の表示部に表示させる医療情報は異なる。例えば診察室からの要求であれば、「フォローアップ」、検査室からであれば「スクリーニング」、或いは、「精査」の場面であると推測することが可能である。

また、統合ビューア２１においては、管理サーバ５から様々な情報を受信するが、これらの情報を利用することで場面（シーン）の特定を行うことができる。例えば、管理サーバ５から送信される該当する患者に関する検査のオーダ等を用いる。具体的には、例えば、Ｘ線撮影検査が実施済みであり、検査オーダとして心臓についてのＣＴ検査に関する検査オーダが発行されたが、未実施であるとの情報が管理サーバ５から統合ビューア２１へ送信された場合、現在ユーザが医療情報を利用しようとしている場面（シーン）は、心臓ＣＴ検査の場面（シーン）であると判断できる。

図５は、実施の形態における統合ビューア２１の内部構成を示すブロック図である。統合ビューア２１は、受信部２１ａと、情報解析部２１ｂと、情報収集部２１ｃと、情報統合部２１ｄと、送信部２１ｅとから構成される。

なお、統合ビューアは自体は医療情報を統合的にユーザに提示するアプリケーションである。しかし、以下の説明に係る実施の形態においては、テナント型医療情報システム２に当該アプリケーションが読み込まれることによって統合ビューア２１が実装されることを前提とする。統合ビューアは、Ｗｅｂアプリケーション、ファットクライアントアプリケーション、或いは、シンクライアントアプリケーション等、いずれの実装形態を採用しても良い。一方、統合ビューアは医療情報を統合的にユーザに提示する回路としてテナント型医療情報システム２に設けられていても良い。

ユーザが使用するクライアント端末１から送信される要求は、受信部２１ａで受信される。上述した当該要求に含まれる情報にどのような情報が含まれているのかの確認は、情報解析部２１ｂにて行われ、把握される（上述したステップＳＴ１参照）。

次に情報収集部２１ｃは、統合ビューア２１にて受信する各種情報を確認する（ＳＴ２）。統合ビューア２１には、例えば、管理サーバ５から患者の予約情報や治療に関する情報等、医療機関内で管理されている各種情報が送信されてくる。テナント型医療情報システム２内には、図２において図示していないが、例えば記憶部が設けられており、通信ネットワークＮを介して送られてくる情報を記憶している。

情報収集部２１ｃは、ユーザからの要求に含まれる、例えば患者情報を基に、テナント型医療情報システム２で受信する各種情報の中から当該患者に関連する情報を選択し、抽出する（ＳＴ３）。

さらに、情報収集部２１ｃが当該患者に関する情報を収集した後、統合ビューア２１は、ユーザからの要求に関する情報（以下、このような情報を「要求情報」と表わす）、及び、通信ネットワークＮを介して管理サーバ５等から送信された情報の中から抽出された当該患者に関する情報（以下、このような情報を「患者関連情報」と表わす）を合わせてワークフローマネージャ２２へと送信する（ＳＴ４）。これらの情報は、ワークフローマネージャ２２が医療情報を得るのに最適なアプリケーションを選択する上で重要な情報となる。

図６は、実施の形態におけるワークフローマネージャ２２の内部構成を示すブロック図である。ワークフローマネージャ２２は、送受信部２２ａと、推奨アプリ判定部２２ｂと、アプリ推奨部２２ｃとから構成される。また、ワークフローマネージャ２２は、設定データベース２３と接続されている。

設定データベース２３内には、アプリ情報記憶部２３ａと、アプリ利用歴記憶部２３ｂとが設けられている。なお、設定データベース２３内に設けられている記憶部（テーブル）は、ここに挙げたものに限られるものではない。ここでは、実施の形態を説明する都合上必要な記憶部（テーブル）のみを挙げているのであって、図示しない他の記憶部が設けられていても良い。

なお、ワークフローマネージャも医療情報を生成するアプリケーションに関する情報を抽出等するアプリケーションである。しかし、以下の説明に係る実施の形態においては、テナント型医療情報システム２に当該アプリケーションが読み込まれることによってワークフローマネージャ２２が実装されることを前提とする。一方で、ワークフローマネージャは医療情報を生成するアプリケーションに関する情報を抽出等する回路としてテナント型医療情報システム２に設けられていても良い。

また、以下の説明、或いは、各図面において、適宜「アプリ」と表わされる場合があるが、この「アプリ」とは「アプリケーション」の略である。

統合ビューア２１から送信された要求情報及び患者関連情報を基に、ワークフローマネージャ２２（推奨アプリ判定部２２ｂ）は、ユーザが必要とする医療情報が生成可能なアプリケーションに関する情報を設定データベース２３（アプリ情報記憶部２３ａ）から抽出し判定する（ＳＴ５）。

アプリ情報記憶部２３ａ内には、テナント型医療情報システム２に通信ネットワークＮを介して接続されている、アプリ提供者の提供によるアプリケーションに関する情報が記憶されている。記憶されている内容は、例えば、アプリケーション識別情報、アプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性、アプリケーション提供者識別情報、アプリケーション起動方法等である。以上は、アプリケーションに関する情報そのものであるが、その他に、統合ビューア２１においてアプリケーションをどのように配置するかに関する情報（表示レイアウト情報）も記憶されている。

なお、記憶される方法としては、例えば、ＸＭＬファイルのようなテキスト情報であっても良く、或いは、ＲＤＢＭＳのようなデータベースに保管するようにしても良い。

推奨アプリ判定部２２ｂでは、要求情報や患者関連情報を基に、アプリ情報記憶部２３ａに記憶されている上記アプリケーションに関する情報を検索し、抽出する。例えば、要求情報等の中に患者の疾患部位に関する情報が含まれている場合には、当該疾患部位をクライアント端末１の表示部に医師や患者にとって理解しやすく、見やすく表示させるに適切なアプリケーションに関する情報を選択する。

また、抽出対象となるアプリケーションが複数アプリ情報記憶部２３ａに記憶されている場合には、例えば、ユーザが通常利用しているアプリケーションを抽出したり、或いは、シーンに応じて当該ユーザがこれまで利用していたアプリケーションとは異なるアプリケーションを抽出することも可能である。または、これまで利用されていたアプリケーションに類似するアプリケーションであって、より安価なアプリケーションに関する情報が登録されていた場合には、これまで利用されていたアプリケーションに替えて当該安価なアプリケーションを抽出しても良い。

さらに、実際にアプリケーションを利用して生成される医療情報をどのような配置で統合するかについての表示レイアウト情報についても抽出する。

なお、アプリ情報記憶部２３ａ内に記憶されている情報は、上述した各情報に限定されることはない。また、アプリ情報記憶部２３ａからどの情報を抽出するかについても任意に設定することができる。

また、ここで「アプリ推奨部２２ｃ」は、ユーザが使用するクライアント端末１の表示部にテナント型医療情報システム２として推奨するアプリケーションの一覧を表示させる機能を有している。予め表示部にこのような推奨のアプリケーションを表示させることによって、ユーザに直接利用したいアプリケーションを要求させることができる。また、複数推奨するアプリケーションがある場合には、その旨のアイコンを表示させることも可能である。

設定データベース２３における「アプリ利用歴記憶部２３ｂ」は、ユーザによるアプリケーションの利用履歴を記憶する。利用歴を記憶するタイミングとしては、例えば、ユーザからの要求に基づいてワークフローマネージャ２２が選択したアプリケーションが利用されて医療情報が生成された場合に、当該生成された医療情報をシンクライアントマネージャ２４から受信した際に、統合ビューア２１から利用歴に関する情報を設定データベース２３へ送信することが考えられる。

ここで記憶される情報としては、アプリケーションに関する情報や利用者に関する情報を挙げることができる。両者は互いに紐づけられて記憶されている。「アプリケーションに関する情報」としては、例えば、アプリケーション識別情報、アプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性、アプリケーション提供者識別情報等を含むアプリケーションの属性情報が考えられる。また、「利用者に関する情報」として、利用者識別情報、利用者所属情報、利用者契約情報や、利用に関する情報である、アプリ利用開始時間、アプリ利用終了時間、アプリ利用時間、アプリ処理時間、アプリ処理データ量、アプリ使用ＣＰＵ時間等が挙げられる。

なお、このアプリ利用歴記憶部２３ｂに記憶されている情報は、後述する課金に際して利用される情報であることから、例えば、セキュリティ強度が高められたＲＤＢＭＳのようなデータベースに保管されることが望ましい。または、暗号化されたＸＭＬファイルのようなテキスト情報として管理しても良い。

ワークフローマネージャ２２は、設定データベース２３から抽出した医療情報を生成するに適したアプリケーションに関する情報および表示レイアウトに関する情報を統合ビューア２１へ送信する（ＳＴ６）。

ワークフローマネージャ２２から情報を受信した統合ビューア２１は、まず受信した情報を「アプリケーションに関する情報」と「表示レイアウトに関する情報」とに分ける。その上でアプリケーションに関する情報が示すアプリケーションを利用してユーザが必要とする医療情報を生成するための基となる画像情報を、アプリケーションＡ（アプリケーション２５）を介して画像レポートデータベース２９から抽出する（ＳＴ７）。

統合ビューア２１は、アプリケーションに関する情報及び、画像レポートデータベース２９から抽出された医療画像に関する情報をシンクライアントマネージャ２４へ送信する（ＳＴ８）。但し、統合ビューア２１は、アプリケーションに関する情報については、自身にも保持しておく。これは、アプリサーバ３での医療情報の生成が終了し、シンクライアントマネージャ２４から生成された医療情報を受領する際に、シンクライアントマネージャ２４を介して医療情報を生成させたアプリサーバ３の全てから医療情報が送られてきたか否かを判断する際に用いるためである。

シンクライアントマネージャ２４は、受信したアプリケーションに関する情報の内容から、該当するアプリケーションを備えるアプリサーバ３を確認し、対応する適切な店子（アプリ提供者）のアプリサーバ３へと送信する（ＳＴ９）。

図７は、実施の形態におけるアプリサーバ３の内部構成を示すブロック図である。アプリサーバ３は、シンクライアントエンジン３１と、アプリケーション３２と、画像データベース３３とから構成される。

シンクライアントエンジン３１は、シンクライアントマネージャ２４から送信されたアプリケーションに関する情報を受信する。その上でアプリケーション３２の制御を行う。また、シンクライアントマネージャ２４から送信された医療画像に関する情報は、画像データベース３３に格納される。アプリケーション３２は、シンクライアントエンジン３１の制御の下、画像データベース３３に格納された医療画像に関する情報を基に医療情報を生成する（ＳＴ１０）。

アプリサーバ３は、アプリケーション３２の種類ごとに設けられていても、或いは、アプリ提供者が自らが提供するアプリケーション３２についてはまとめて１つのアプリサーバ３に格納することとしても良い。

アプリケーション３２によって生成された医療情報は、シンクライアントエンジン３１を介してシンクライアントマネージャ２４へ送信される（ＳＴ１１）。シンクライアントマネージャ２４では、各アプリサーバ３から送信されてきた医療情報を受信する（図４のＳＴ１２）。そこでシンクライアントマネージャ２４は、ユーザからの要求に基づいて生成される医療情報の全てを受信したか否かを確認する（ＳＴ１３）。全てのアプリサーバ３からユーザの要求に対応する医療情報の全てを受信していないと判断された場合には（ＳＴ１３のＮＯ）、全ての医療情報が送信されてくるまで待機する。

一方、全ての医療情報がアプリサーバ３から送信されシンクライアントマネージャ２４が受信したことが確認された場合（ＳＴ１３のＹＥＳ）、シンクライアントマネージャ２４は、全ての医療情報を統合ビューア２１に対して送信する（ＳＴ１４）。

なお、ここでは、全ての医療情報がアプリサーバ３からシンクライアントマネージャ２４へと送信されたことをもって統合ビューア２１へと当該医療情報を送信することとしているが、シンクライアントマネージャ２４はアプリサーバ３から医療情報を受信したら、その都度統合ビューア２１へ送信することとしても良い。

以上で必要とされる医療情報は生成されたが、表示レイアウトに関する情報については、シンクライアントマネージャ２４を介してアプリサーバ３に送られることはなく、統合ビューア２１内にて保持される（ＳＴ１５）。この表示レイアウトに関する情報は、統合ビューア２１が生成された医療情報をクライアント端末１にて表示する際に利用する情報だからである。

統合ビューア２１では、アプリケーション３２を利用して生成された医療情報を受信するとともに、ユーザがクライアント端末１において表示することを必要としている医療情報が全て揃ったか否かを確認する（ＳＴ１６）。全てが揃っていない場合にはそのまま待機し、ユーザが要求した医療情報の全てが揃ったことが確認された場合には（ＳＴ１７のＹＥＳ）、これら集められた医療情報を表示レイアウトに関する情報に基づいて統合ビューア２１の情報統合部２１ｄにて統合される（ＳＴ１８）。

そして、統合ビューア２１にて統合された情報は、ユーザが使用しているクライアント端末１に表示される（ＳＴ１９）。

さらに、統合ビューア２１では、シンクライアントマネージャ２４から送信された、医療情報の生成の際に利用したアプリケーション３２の利用歴についての情報を受信し、ワークフローマネージャ２２や課金エンジン２６へ送信する（ＳＴ２０）。

以上、ユーザが必要とする医療情報の要求を行ってから、適切なアプリケーションが選択され、当該選択されたアプリケーションによって生成された医療情報を統合した上でクライアント端末１に表示される流れを説明した。

図８ないし図１１は、実施の形態における統合ビューア２１によって統合されクライアント端末１の表示部に表示される画面例である。なお、以下に図面を示しながらクライアント端末１の表示部に表示される画面例について説明するが、各図において示される画面例のレイアウトは、あくまでも例示に過ぎず、そのレイアウトは自由に設定することが可能である。また、このレイアウトはワークフローマネージャ２２から統合ビューア２１に対して送られた表示レイアウトに関する情報に含まれ、当該表示レイアウトに関する情報に基づいてその配置が設定される。

図８に示す画面例１Ａは、上部に「患者氏名」、「患者ＩＤ」、及び当該画像のシリーズに関する情報が表示されている。但し、この欄にどのような情報を表示させるかについては、任意に設定することが可能である。

一方、画面例１Ａの下部には、左側に１つの画像、右側に上下に分けて２つの画像が表示されている。左側に示されている医療画像１Ａａは、例えば、医療画像診断装置４によって取得され、画像レポートデータベース２９に記憶されていた画像である。

また、右側上部に示されている医療画像１Ａｂは、例えば、アプリケーションＡ−１によって生成された医療画像であり、右側下部に示されている医療画像１Ａｃは、例えば、アプリケーションＢ−１によって生成された医療画像である。従って、当該画面例１Ａにおいては、アプリケーションによって生成された医療画像とともに、これら医療情報としての医療画像生成の基となった医療画像が同じ表示部に示されていることになる。

ここで、例えば「アプリケーションＡ−１」とあるのは、システム運営者がテナント型医療情報システム２内に提供している複数のアプリケーションのうち、「Ａ−１」という種類のアプリケーションを示している。また、同様に、「アプリケーションＢ−１」とあるのは、アプリ提供者が自社のアプリサーバ３内に提供している複数のアプリケーションのうち、或いは、アプリ提供者が自社が提供しているアプリケーションのうち、「Ｂ−１」という種類のアプリケーションを示している。

これによって、例えば、ユーザである医師は医療画像診断装置４によって取得された医療画像を基に、医師が指定した方法に基づいて生成された医療画像を利用して患者に対してより適切な診察、説明を行うことができる。

図９ないし図１１は、一連の医療画像を３つのタブで示される画面によって、その内容を表示部に示すことを示した画面例１Ｂである。画面例１Ｂには、タブＸが３つ設けられており、それぞれに医療画像等の情報が表示されている。

図９に示すタブＸ１において表示される画面例１Ｂには、左側にアプリケーションＡ−２を利用して生成された医療画像１Ｂａが１枚、右側上部に同じくアプリケーションＡ−２を利用して生成されてはいるものの、別の態様で表示されている２枚の医療画像１Ｂｂ、１Ｂｃ、右側下部に、例えば、ＨＩＳといった管理サーバ５から送信された情報１Ｂｄが表示されている。

図１０は、タブＸ２を開いた状態を示す画面例１Ｂである。左側上部に今回の検査で取得された医療画像１Ｂｅが１枚、左側下部に前回の検査で取得された医療画像１Ｂｆが１枚、右側にアプリケーションＢ−２を利用して生成された医療画像１Ｂｇが１枚表示されている。

図１１は、タブＸ３を開いた状態を示す画面例１Ｂである。左側に初回のＸ線検査で取得された医療画像１Ｂｈが１枚、右側上部に検体検査の結果１Ｂｉ、右側下部にアプリケーションＣを利用して生成された医療画像１Ｂｊが１枚表示されている。

以上、図９ないし図１１に示されている画面例１Ｂの各タブＸに示される医療情報については、上述したように、ユーザの要求に基づいてワークフローマネージャ２２が設定データベース２３内から抽出された表示レイアウトに関する情報に基づいて、統合ビューア２１が各医療情報を統合してクライアント端末１の表示部に表示させるものである。各タブＸに表示させる医療情報やその配置、大きさ、タブＸの数等については、任意に設定することができ、その情報が表示レイアウトに関する情報としてまとめられている。

［アプリケーションの利用に基づく課金の流れ］
図１２は、実施の形態における課金エンジン２６の内部構成を示すブロック図である。また、図１３は、実施の形態におけるアプリケーション利用に基づく課金の流れを示すフローチャートである。以下においては、いずれかのアプリケーションが利用され、ユーザが要求する医療情報が生成された場合の、当該アプリケーション利用についてのユーザへの課金の流れについて説明する。

図１２に示すように、課金エンジン２６は、情報を受信する受信部２６ａと、利用されたアプリケーションを確認する利用アプリ確認部２６ｂと、当該アプリケーションを利用するに当たって必要とされる基本の料金を検索する料金検索部２６ｃと、検索された基本料金を基に実際に掛かった料金を算出する料金算出部２６ｄと、算出された料金に関する情報をユーザのクライアント端末１に向けて送信する送信部２６ｅとから構成される。これら各部の詳しい働きについては、以下の課金の流れを説明する際に併せて説明する。

図１３のフローチャートに示されているように、まず統合ビューア２１は、ユーザからの要求を受信し、ワークフローマネージャ２２による適切なアプリケーションの選択を経て、当該アプリケーションに関する情報に基づいて、シンクライアントマネージャ２４を介して各アプリサーバ３へと医療情報の生成を依頼する（ＳＴ３１）。ここまでの流れは、図３に示すステップＳＴ１ないしステップＳＴ９までに示す流れと同じである。

但し、統合ビューア２１は、シンクライアントマネージャ２４を介して各アプリサーバ３へと医療情報の生成を依頼するとともに、アプリケーションの利用開始通知を課金エンジン２６へと送信する（ＳＴ３２）。これは、ユーザの要求に基づいて必要とされる医療画像を取得するために、いずれのアプリケーションが利用されるのか、その利用開始の状態を明確にするためである。この利用開始通知をもって課金エンジン２６は各アプリケーションが利用されることを理解する。

なお、当該利用開始通知には、例えば、アプリケーションに関する情報である、アプリケーション識別情報、アプリケーション名、アプリケーション提供者識別情報等が含まれている。なお、当該利用開始通知に含まれる情報はこれらに限られることなく、いずれの情報を含めても良い。

統合ビューア２１からの利用開始通知を利用して、課金エンジン２６は、画像情報マネージャ２８にアクセスし、医療情報として生成される基となる医療画像のデータサイズを取得する（ＳＴ３３）。画像情報マネージャ２８は、医療画像診断装置４によって取得された医療画像を受信した際に、例えば、当該医療画像を識別するための識別子と画像サイズ（例えば、データ量（ＫＢ））を関連付けて画像レポートデータベース２９に記憶させておく。

画像情報マネージャ２８は、課金エンジン２６からのアクセスによって、医療情報として生成される基となる医療画像の識別子を手がかりに、当該医療画像の画像サイズを画像レポートデータベース２９から取得する。

なお、医療画像の識別子と関連付けられて記憶される情報としては、上述した画像サイズに限られず、例えば、部位、空間分解能、時間分解能、イメージング機能種別等、いずれの情報であっても良い。課金エンジン２６は、画像レポートデータベース２９内に記憶されている情報の種類に合わせて必要とされる情報を入手する。

課金エンジン２６の料金検索部２６ｃは、統合ビューア２１から取得した情報を基に、課金データベース２７から利用されるアプリケーションに関する利用料金の単価を取得する（ＳＴ３４）。課金データベース２７内には、予めテナント型医療情報システム２に提供される各アプリケーションに関する利用料金に関する情報（単価）が記憶されている。そこで料金検索部２６ｃは、利用開始通知を受信した後、当該単価を検索、取得して待機する。

図１４は、課金データベース２７内に記憶されている料金テーブルの一例を示す表である。この表では、最も左側の欄にアプリ提供者から提供されている各アプリケーションが示されている。この欄から右に向けて、利用料金に関する情報として、３つの項目が並んでおり、それぞれ「メモリ使用量（ＭＢ）」、「ＣＰＵ占有率（％）」、「価格（円）／時間」とされる。例えば、アプリケーションＢが利用される場合、メモリの使用量は「２０ＭＢ」であり、ＣＰＵ占有率は「１％」、時間当たりの価格は「１５００円」である。料金検索部２６ｃは、これら単価（アプリケーションの利用料金）を対象となるアプリケーションに関する情報を基に検索する。

課金エンジン２６が利用開始通知の受信をトリガーとしてアプリケーションの利用単価を検索している間、アプリサーバ３では要求された医療情報の生成をしている。そして上述した通り、医療情報が生成されるとシンクライアントマネージャ２４に対して生成された医療情報を送信する。さらにシンクライアントマネージャ２４は、取得した医療情報を統合ビューア２１へと送信する（ＳＴ３５）。ここで、統合ビューア２１は、表示が要求される医療情報の全てが揃ったか否かを確認し（ＳＴ３６、図４に示すＳＴ１６に該当）、全ての医療情報が揃うまで待機する（ＳＴ３７、図４に示すＳＴ１７に該当）。全ての医療情報が揃ったか否かの判断は、統合ビューア２１がシンクライアントマネージャ２４を介して各アプリサーバ３へ医療情報の生成を依頼する際に保持する、各アプリケーションに関する情報を用いて行う。

全ての医療情報が揃った場合には（ＳＴ３７のＹＥＳ）、統合ビューア２１は全ての医療情報を表示レイアウトに従って統合するとともに、医療情報生成のためのアプリケーションの利用が終了した旨、利用終了通知を課金エンジン２６へと送信する（ＳＴ３８）。

なお、ここでは全てのアプリケーションの利用が終了したことをもって、統合ビューア２１から課金エンジン２６に利用終了通知を送信しているが、例えば、利用されるアプリケーションによっては、課金操作となる、例えば、レポートの作成といった医療情報が生成されるたびに利用終了通知を送信することとしても良い。

課金エンジン２６では、利用終了通知に含まれる利用されたアプリケーションに関する情報を基に、利用アプリ確認部２６ｂが再度利用されたアプリケーションを確認し、その上で、料金算出部２６ｄにおいて、検索した利用単価を基にそれぞれ利用されたアプリケーションに関する利用料金を算出する（ＳＴ３９）。

料金算出部２６ｄでは、例えば、アプリケーションの利用時間、生成された医療情報の枚数、医療情報生成の基となる医療画像のデータサイズ等のアプリケーションの利用状況とそれぞれ定められている単価を基に利用料金が算出される。また、アプリケーションの利用料金については、この他に、アプリケーションが利用されている最中に、当該アプリケーションを提供するアプリサーバ３から随時ＣＰＵの利用率やメモリの占有率等の各種情報を収集し、これらの情報を基に利用料金を算出することも可能である。

算出された利用料金については、料金算出部２６ｄ、或いは、統合ビューア２１等に保持されて、ユーザの要求や他の操作をトリガーとして課金に関する情報をクライアント端末１の表示部に表示させる（ＳＴ４０）。

以上、ユーザが医療情報を取得するべくアプリケーションを利用した場合に、当該利用に関する課金の流れについて説明した。一方で、ユーザが利用するアプリケーションは、アプリ提供者が医療情報システムＳに提供している。従って、システム運営者との契約が締結された上でアプリ提供者はそれぞれ自社のアプリケーションを提供することになる。このアプリ提供者とシステム運営者との間の契約において、システム運営者は、例えば、アプリ提供者が提供したアプリケーションがユーザに使用された場合に、その利用態様によってアプリ提供者に対して課金することができる。また、課金の基準が利用態様ではなく、例えば、期間等の指標に対して一定額、といった課金の方法も考えられる。

また、ユーザからのアプリケーションの利用料金について、システム運営者はアプリケーションの利用態様によって、アプリ提供者に対して当該利用料金の支払い（分配）を行うことも可能である。

ところで、上述した課金の流れは、ユーザが要求した医療情報をアプリケーションを利用して生成した場合を例に挙げて説明した。但し、ユーザによっては、アプリケーションを利用して完全な形の医療情報を生成することまでは求めず、例えば、簡単に当該アプリケーションを利用するとどのような医療情報が提供されることになるのか、確認のみしたい場合もある。また、例えば、医療情報が複数の項目について数値のみで表わされる場合に、全ての項目を医療情報として提供されることは不要であり、予め選択されるいくつかの項目についてのみ医療情報として提供されることを求める場合も考えられる。このように様々な利用実態が存在する場合に、それぞれの利用実態に合わせて課金を行うことも可能である。

以上、ユーザが必要とする医療情報について、その要求から取得、また、アプリケーションの利用に伴う課金の流れまで説明した通り、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとすることで、ユーザの利便性の向上を図ることが可能な医療情報システム及び医療情報提供方法を提供することができる。

なお、上述した統合ビューア２１から送信された要求情報及び患者関連情報を基に、ワークフローマネージャ２２は、ユーザが必要とする医療情報が生成可能なアプリケーションに関する情報を設定データベース２３から抽出し判定する、というワークフローマネージャの働きについては、別の抽出、判定処理も考えられる。

この考え方は、統合ビューア２１から要求情報及び患者関連情報を受信したワークフローマネージャ２２は、設定データベース２３のアプリ情報記憶部２３ａからユーザからの要求に適したアプリケーションに関する情報を抽出する際に、経済的な視点を加味してアプリケーションの情報を抽出する考え方である。

すなわち、事前にアプリケーションに関する情報としてアプリ情報記憶部２３ａに、「アプリケーション利用料金契約情報」を記憶させておく。この「アプリケーション利用料金契約情報」は、例えば、「１回当たり」、「一定期間当たり」、「ＣＰＵ使用量当たり」、或いは、「データ処理量当たり」のアプリケーションの利用料金がそれぞれ規定されており、その料金に関する情報である。その上で、推奨アプリ判定部２２ｂは、アプリ情報記憶部２３ａからアプリケーションに関する情報を抽出するに当たって、要求情報及び患者関連情報のうち、例えば、特にアプリケーション識別情報、アプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性を基に複数の類似するアプリケーションに関する情報を抽出する。

これら抽出された複数の類似するアプリケーションに関する情報、及び、アプリケーション利用料金契約情報を基に、それぞれのアプリケーションを利用した際にかかる料金を試算する（算出する）。この試算された料金も含めて統合ビューア２１にアプリケーションに関する情報を送り、ここで一旦クライアント端末１の表示部に推奨するアプリケーションとしてこれら複数の類似するアプリケーションに関する情報を表示させる。

ユーザは、必要とされる医療情報の生成を行うために利用するアプリケーションについて、利用料金の試算とともに表示されることになるため、利用するアプリケーションを選択する上で有効な情報を得ることになる。

このように、上述したワークフローマネージャ２２の抽出、判定処理に比べ、ユーザに推奨するアプリケーションを提示し選択させる分、全体の処理に時間が掛かることになるが、経済的な視点を加味することによって、ユーザに医療情報の取得に当たって、より一層の満足感を与えることになる。一方でアプリ提供者にとっても、ワークフローマネージャ２２によるアプリケーションに関する情報の抽出、判定処理において、抽出対象となるアプリケーションが固定されがちとなることを防止して、新たなアプリケーションが抽出される機会を付与されることになる点において、よりユーザの利便性向上に寄与するアプリケーションの開発、提供を行うことのモチベーションにつながる。

さらに、システム運営者にとっては、インフラ上に自由競争の場を提供し、複数の類似するアプリ提供者から魅力的なアプリケーションの提供を受けて競わせることによって、医療情報システムＳ（テナント型医療情報システム２）へのユーザ、アプリ提供者の参加が増え、システムの利用を促すことになる。

（第２の実施の形態）
次に本発明における第２の実施の形態について説明する。なお、第２の実施の形態において、上述の第１の実施の形態において説明した構成要素と同一の構成要素には同一の符号を付し、同一の構成要素の説明は重複するので省略する。

第２の実施の形態においては、ワークフローマネージャ２２において、ユーザからの要求に応じて適切なアプリケーションに関する情報を抽出、判定する処理に関して、アプリケーションを提供するアプリ提供者から出されているそれぞれのアプリケーションに対する推奨希望の度合いを基に抽出、判定処理を行う点に特徴がある。

図１５は、第２の実施の形態におけるワークフローマネージャ２２、及び、設定データベース２３Ａの内部構成を示すブロック図である。第１の実施の形態において説明した設定データベース２３内に、「推奨希望度合い記憶部２３ｃ」が新たに設けられている。なお、ワークフローマネージャ２２については、その構成に違いはない。

この「推奨希望度合い記憶部２３ｃ」は、アプリサーバ３にアプリケーションを提供するアプリ提供者が、提供するアプリケーションに関して、どの程度ユーザに対して推奨するか、その度合いを記憶する。すなわち、アプリ提供者からの推奨度合いに応じてシステム運営者はユーザに当該アプリケーションの推奨を行うことになることから、換言すれば、店子であるアプリ提供者による大家であるシステム運営者へのアプリケーションのお薦め度合いとも言える。

システム運用者は、ワークフローマネージャ２２によって設定データベース２３から要求情報及び患者関連情報を基にユーザが必要とする医療情報の生成に適したアプリケーションに関する情報を抽出、判定する。推奨アプリ判定部２２ｂは、推奨希望度合い記憶部２３ｃに記憶されているアプリ提供者による当該アプリケーションの推奨度合いを参考に、適切なアプリケーションに関する情報を抽出、判定処理を行う。または、推奨度合いによってユーザへの推奨順位を決定しても良い。

さらには、複数推奨するアプリケーションをクライアント端末１に表示させ、ユーザにその中の１つのアプリケーションを試用してもらうようにしても良い。試用のアプリケーションをユーザが利用を考えているアプリケーションに類似するアプリケーションとすることで、利用を考えているアプリケーションの利用実態をシミュレーションすることができる。

なお、推奨度合いの参照については、アプリ提供者によって推奨希望度合い記憶部２３ｃに推奨度合いが記憶されている場合には、推奨アプリ判定部２２ｂは常に該当するアプリケーションに関する情報の抽出、判定処理において推奨度合いを参照する、という方法を採用することができる。一方で、例えば、特定のアプリケーション分類に対するユーザからの要求のうち、２４時間等、所定の時間当たりの推奨アプリ判定部２２ｂによる当該アプリケーションの抽出割合が指定の値となるまで推奨する、といった方法も採用することができる。さらに、ユーザが要求した特定のアプリケーション分類の中で該当するアプリケーションに関する情報が抽出される割合が予め定められている値よりも小さい場合に、推奨アプリ判定部２２ｂは推奨度合いを参考にしてアプリケーションに関する情報を抽出するとしても良い。

アプリ提供者によるアプリケーションの推奨度合いに応じてワークフローマネージャ２２がアプリケーションに関する情報をユーザに推奨した後、当該推奨に従ってユーザが推奨の対象であるアプリケーションの利用を選択した場合には、推奨のアプリケーションとその推奨に基づき選択されたアプリケーションが合致することになる。従って、この場合は、例えばアプリ推奨の成否は「成」と判断されることになり、この判断によって、例えば、アプリ提供者からシステム運営者へ報酬等の支払いを行う等の取り決めが両者の間でなされていても良い。

一方で、アプリ提供者によるアプリケーションの推奨度合いに応じてワークフローマネージャ２２がアプリケーションに関する情報をユーザに推奨したにも拘わらずユーザが別のアプリケーションを選択した場合には、アプリ推奨の成否は「否」と判断される。この場合についてもアプリ提供者とシステム運営者との間で何らかの契約を締結して、アプリ提供者の提供するアプリケーションがより利用されるような対策を講じることもできる。

また、システム運営者がアプリ提供者の推奨したアプリケーションを抽出、選択する、ということは、このアプリ提供者がシステム運営者に対して推奨するアプリケーションをユーザに対して推奨するように依頼していることになり、アプリ提供者にとっては、システム運営者にそのアプリケーションに関する営業を依頼していることになる。

従って、アプリ提供者にとっては、自身が注力しているアプリケーションを効率的にユーザに宣伝、提供することができることになるため、システム運営者が運営するテナント型医療情報システム２に参加する動機付けともなり得る。

ここでアプリ提供者が推奨度合いの決定をする際には、上述したように自身が注力しているアプリケーションである、という観点の他にも、例えば、自身の予算に応じて適切なアプリケーションの推奨をシステム運営者に対して依頼するという観点も考えられる。従って、アプリ提供者がどのように考えて当該アプリケーションを推奨するか、については問わない。

このことは、システム運営者にとっても質の良いアプリケーションがテナント型医療情報システム２に参加することにつながり、ユーザにとっても使い勝手に優れるアプリケーションを利用できるという利便性の向上につながる。

従って、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとすることで、ユーザの利便性の向上を図ることが可能な医療情報システム及び医療情報提供方法を提供することができる。

（第３の実施の形態）
次に本発明における第３の実施の形態について説明する。なお、第３の実施の形態において、上述の第１または第２の実施の形態において説明した構成要素と同一の構成要素には同一の符号を付し、同一の構成要素の説明は重複するので省略する。

図１６は、第３の実施の形態におけるワークフローマネージャ２２Ａ、及び、設定データベース２３Ｂの内部構成を示すブロック図である。第３の実施の形態においては、ワークフローマネージャ２２Ａにおいて、ユーザからの要求に応じて適切なアプリケーションに関する情報を抽出、判定する処理に関して、ユーザの条件を基に抽出、判定処理を行う点に特徴がある。

ここで「ユーザの条件」とは、例えば、医療情報を要求する医師等の専門性、アプリケーションの利用頻度等の情報である。これらの情報を「条件」として統合ビューア２１から要求情報等とともにワークフローマネージャ２２Ａに対して送信される利用者識別情報に紐づけて予めユーザ条件記憶部２３ｄに記憶させておく。これにより、ユーザにより適したアプリケーションに関する情報を抽出、判断することができる。

なお、医師等の専門性については、例えば、診療科を示す識別情報や認定済み専門医識別情報等を挙げることができる。また、アプリケーションの利用頻度に関する情報については、例えば、アプリケーション識別情報、アプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性、アプリケーション提供者識別情報の他、当該アプリケーションを利用した頻度を回数、利用時間、ＣＰＵ使用量、或いは、データ使用量等の情報が挙げられる。但し、これら全ての情報を漏れなく記憶することはなく、これらの情報の中から当該テナント型医療情報システム２が利用される環境等を考慮して記憶させることができる。

このようなユーザ自身の条件を記憶させておくことで、ユーザが利用を希望するアプリケーションを選択する際に、その選択の幅が広がることになる。例えば、類似する機能を備えるアプリケーションであっても、初心者用、或いは、ベテラン用というように、ユーザの実力によって使い勝手の異なるアプリケーションが提供されていることが考えられる。推奨アプリ判定部２２ｂが設定データベース２３からアプリケーションに関する情報を抽出する際に、このようなユーザの条件を参照することで、医療情報を要求するユーザの実力をも見極めた上で適切なアプリケーションに関する情報を抽出し当該アプリケーションに基づいて医療情報を生成することが可能となる。

さらには、ユーザが持つ予算についても条件の１つとしてユーザ条件記憶部２３ｄに記憶させておいても良い。ここで「予算」とは、例えば、ユーザ個人、或いは、ユーザが属する診療科等のグループにおいて使うことのできる予算の意味である。予算の多寡、及びアプリケーションの利用料金によっては、利用したいアプリケーションを予算の都合上利用することができない場合も考えられる。従って、ユーザの条件としてユーザの持つ「予算」の額を記憶させておくことで、推奨アプリ判定部２２ｂは、例えば、利用を希望するアプリケーションに類似する、より利用料金が安いアプリケーションをユーザに推奨することも可能となる。

ユーザ条件記憶部２３ｄにユーザに関する条件が記憶されていることによって、アプリ提供者は、それぞれの条件に合った複数のアプリケーションを提供することができる。すなわち、例えば、同じ機能を備えるアプリケーションであっても様々なレベルのアプリケーションを提供し、それぞれに適した料金を設定することによって、多様なアプリケーションの提供を行うことができる。このことは、アプリ提供者にすればより多くのユーザに対して自らの提供するアプリケーションの利用する機会を与えることにある。そしてユーザにしてみればアプリケーション選択の幅を広げることになるため、利用機会が拡大し、利便性が向上することになる。

一方、ワークフローマネージャ２２Ａには、新たに「条件監視部２２ｄ」が設けられている。この条件監視部２２ｄは、実際に利用されたアプリケーションに関する情報を統合ビューア２１から取得し、ユーザ条件記憶部２３ｄに記憶させる。このようにユーザの利用状況を常に把握することによって、次回当該ユーザが医療情報の要求をしてきた場合により適切なアプリケーションに関する情報を抽出することができる。

システム運営者にすれば、ワークフローマネージャ２２に条件監視部２２ｄが設けられ、設定データベース２３にユーザ条件記憶部２３ｄが設けられることで、テナント型医療情報システム２を利用するユーザの特質や嗜好等を把握することができる。このことは、ユーザからの各種要求に対してよりきめ細かな対応をすることができることにつながるため、ユーザ自身の利便性の向上をはかることができる。併せて、多くのアプリ提供者のテナント型医療情報システム２への参加、及びアプリ提供者からの良質なアプリケーションの提供を期待することができる。

以上説明した通り、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとするとともに、ユーザの条件を把握し、利用することによって、ユーザの利便性の向上を図ることが可能な医療情報システム及び医療情報提供方法を提供することができる。

（第４の実施の形態）
次に本発明における第４の実施の形態について説明する。なお、第４の実施の形態において、上述の第１ないし第３の実施の形態において説明した構成要素と同一の構成要素には同一の符号を付し、同一の構成要素の説明は重複するので省略する。

これまで説明してきた各実施の形態においては、ユーザが統合ビューア２１を介して要求する医療情報を通常の診察等で用いる場合を例に挙げて説明してきた。そのため通常の診察において医療情報を利用する場合には、ユーザが必要と判断した医療情報を、当該医療情報が利用される場面（シーン）に合わせて当該医療情報の生成に適したアプリケーションを選択し、生成させ、表示することで、ユーザの利便性を確保していた。

一方で、上述した場合ではなく、診断決定木を利用する際に医療情報が用いられる場合もある。ここで「診断決定木」とは、患者の病状に基づいて治療を行う際に次に取り得る措置を判断、決定していく際に用いられるグラフである。そのため、診断決定木を用いる場合、ユーザには、次に取り得る措置を決定するのに必要とされる医療情報を示す必要がある。従って、上述の各実施の形態における場合と異なり、いずれの場面において医療情報が利用されるかによってワークフローマネージャ２２にて選択、判定されるアプリケーションに相違が生ずる。

図１７は、第４の実施の形態におけるワークフローマネージャ２２の判断の流れを示す診断決定木を示す模式図である。図１７に示す診断決定木Ｔでは、スタートである所見（例えば、胸痛による受診）に基づいて、まずＸ線撮影検査が行われる（ＷＦ：Ａ−１）。Ｘ線撮影検査が行われると、次に予想できる処置としては、「血液検査（ＷＦ：Ａ−１−Ａ）」、「超音波検査（ＷＦ：Ａ−１−Ｂ）」、或いは、「ＣＴ検査（ＷＦ：Ａ−１−Ｃ）」のいずれかが考えられる。そして「超音波検査」が行われた場合には、次に「ＣＴ検査（ＷＦ：Ａ−１−Ｂ−Ａ）」、が行われる可能性が高い。このように、ある処置が行われると、次に行われる処置をある程度予想することが可能である。

そこで、例えば診察室や検査室等からのユーザの要求、すなわち、ユーザが医療情報を要求する際に、診断決定木に基づいて診断をしていることが伺える場合には、ワークフローマネージャ２２は、予め設定データベース２３内に記憶されている診断決定木に基づいて、次の処置に必要な医療情報の生成を行うことができるアプリケーションに関する情報を抽出、判定する。この際、ワークフローマネージャ２２としては、例えば、似たような画像構成を行うアプリケーションが複数提供されている場合に、より次の段階の処置を決定するに適した医療情報を生成することができるアプリケーションを抽出するようにすることも可能である。

統合ビューア２１は、ワークフローマネージャ２２から送られてきたアプリケーションに関する情報に基づいてシンクライアントマネージャ２４を介してアプリサーバ３に医療情報の生成を依頼し、必要な医療情報をクライアント端末１の表示部に表示させる。この際、例えば、現状の処置が適切か否かを判断するため、現状を表わす医療情報のみならず、１つ前の段階における医療情報も併せて表示させる。また診断決定木を利用することによって、次の処置として複数の処置が考えられる場合も多くそれだけ参照しなければならない情報が増える。従って、クライアント端末１の表示部において表示される医療情報の表示レイアウトも適宜変更される。

このように、診断決定木を用いて、ユーザが行う処置に必要な医療情報のみならず、次に行われる処置に必要とされる医療情報までも生成してクライアント端末１に表示させることによって、ユーザによる患者への処置がタイミング良く、迅速に行われることに資することができる。

以上説明した通り、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとするとともに、診断決定木を用いて一歩先の医療情報を提供することによって、ユーザの利便性の向上を図ることが可能な医療情報システム及び医療情報提供方法を提供することができる。

なお、推奨アプリ判定部２２ｂによるアプリケーションに関する情報の抽出に当たっては、これまで様々な場合を例に挙げて説明をしてきた。その他、例えば、アプリケーションに関する情報の抽出の際、当該アプリケーションを利用してのユーザの意見、感想等を反映させる方法も考えられる。例えば、同じ専門を持つ他のユーザの利用経験をフィードバックし、その評価を点数化して重み付けとして利用することもできる。

さらに、これまで説明した推奨アプリ判定部２２ｂによるアプリケーションに関する情報の抽出に関する方法は、互いにそれら単独で用いても、或いは、適宜組み合わせて用いても良い。例えば、ユーザからの要求に従って医療情報を生成する際に、複数のアプリケーションを利用することも考えられる。この場合、例えば、１つ目のアプリケーションで要求される医療情報の基礎となる情報を生成し、２つ目のアプリケーションを利用して、１つ目のアプリケーションを利用して生成された情報を要求される医療情報として生成する等である。このように複数のアプリケーションが連携して１つの医療情報を生成することによって、ユーザは１つのアプリケーションの利用だけでは得ることのできなかった医療情報を取得することができるようになる。

また、この場合、例えば、レポートが作成されるに当たっては、生成された要求される医療情報を利用することも、或いは、アプリケーションを利用するごとに生成される情報を利用することも可能である。

さらに、このようにして複数のアプリケーションが連携して利用される場合には、これらのアプリケーションで使用されるパラメータを校正する必要が出てくる。これらパラメータの校正については、例えば、基準となる情報を基に各アプリケーションを起動させ、それぞれの結果を評価してパラメータを校正することで、アプリケーション間でのバラツキをなくすことができる。

さらに、以上の各実施の形態における説明は、１つの医療情報システムを基に説明をした。但し、この医療情報システムが例えば、ある地域の複数の医療機関に設けられている場合には、それぞれの医療情報システムを連携させて利用することも可能である。

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

１ クライアント端末
２ テナント型医療情報システム
３ アプリサーバ
４ 医療画像診断装置
５ 管理サーバ
２１ 統合ビューア
２２ ワークフローマネージャ
２３ 設定データベース
２４ シンクライアントマネージャ
２５ アプリケーションＡ
２６ 課金エンジン
２７ 課金データベース
２８ 画像情報マネージャ
２９ 画像レポートデータベース
Ｓ 医療情報システム

Claims (14)

1. ユーザが使用するクライアント端末と、
   システム運営者が設置し、通信ネットワークを介して前記クライアント端末から送信される前記ユーザからの要求に応じて、前記ユーザが必要としている医療情報の生成を行う上で適切なアプリケーションを前記ユーザの条件を基に選択するワークフローマネージャと、前記アプリケーションによって生成される前記医療情報を収集し、前記ワークフローマネージャから示される表示レイアウトに沿って前記医療情報の統合を行い、前記クライアント端末に表示させる統合ビューアと、を備えるテナント型医療情報システムと、
   前記テナント型医療情報システムと前記通信ネットワークを介して接続され、前記テナント型医療情報システムの要求に応じて、前記ユーザが必要としている前記医療情報の生成をアプリ提供者によって提供される前記アプリケーションを用いて行うアプリケーションサーバと、
   を備えることを特徴とする医療情報システム。
2. 前記テナント型医療情報システムは、
   医療画像診断装置によって取得される医療画像に関する情報を管理する画像情報マネージャと、
   前記医療画像を記憶する画像レポートデータベースと、
   前記ワークフローマネージャによって選択された前記アプリケーションを提供する前記アプリケーションサーバを制御して前記医療情報の生成を行わせるシンクライアントマネージャと、
   を備えることを特徴とする請求項１に記載の医療情報システム。
3. 前記ワークフローマネージャが選択する前記アプリケーションに関する情報は、前記ワークフローマネージャに接続される設定データベースに記憶されていることを特徴とする請求項２に記載の医療情報システム。
4. 前記ワークフローマネージャは、
   前記統合ビューアから送信される情報を基に前記設定データベース内から前記ユーザが必要としている前記医療情報の生成を行う上で適切な前記アプリケーションを推奨する推奨アプリ判定部と、
   前記設定データベース内に記憶されている前記アプリケーションに関する情報を基に、前記ユーザに対して推奨の前記アプリケーションを提示するアプリ推奨部と、
   を備えることを特徴とする請求項３に記載の医療情報システム。
5. 前記ワークフローマネージャによる前記設定データベースに記憶されている前記アプリケーションの選択は、前記統合ビューアから送信される、前記ユーザからの要求に含まれる情報や前記通信ネットワークに接続される管理サーバからの情報を基に行われることを特徴とする請求項３または請求項４に記載の医療情報システム。
6. 前記統合ビューアは、
   前記統合ビューアにて受信する情報を解析する情報解析部と、
   前記情報解析部にて把握された前記ユーザが必要としている前記医療情報に関係する情報を収集する情報収集部と、
   前記シンクライアントマネージャから送信された前記ユーザが必要としている前記医療情報を受信し、前記ワークフローマネージャから送信された表示レイアウトに従って前記クライアント端末に表示させる前記医療情報を統合する情報統合部と、
   を備えることを特徴とする請求項２に記載の医療情報システム。
7. 前記統合ビューアには、前記画像情報マネージャと、前記画像レポートデータベースから構成される画像管理部が接続され、前記ワークフローマネージャによって選択される前記アプリケーションを備える前記アプリケーションサーバに対して、前記シンクライアントマネージャを介して前記画像管理部から取得される医療画像に関する情報を送信することを特徴とする請求項２または請求項６に記載の医療情報システム。
8. 前記統合ビューアには、前記システム運営者の提供するアプリケーションが接続されており、前記アプリケーションは、前記統合ビューアによって制御されることを特徴とする請求項２または請求項６に記載の医療情報システム。
9. ユーザが使用するクライアント端末と、
   システム運営者が設置し、通信ネットワークを介して前記クライアント端末から送信される前記ユーザからの要求に基づいて必要な医療情報を収集し、表示レイアウトに沿って前記クライアント端末に表示させるテナント型医療情報システムと、
   前記テナント型医療情報システムと前記通信ネットワークを介して接続され、前記テナント型医療情報システムの要求に応じて、前記ユーザが必要としている医療情報の生成をアプリ提供者によって提供されるアプリケーションを用いて行うアプリケーションサーバと、を備え、
   前記テナント型医療情報システムが備える、前記ユーザが必要としている前記医療情報の生成を行う上で適切な前記アプリケーションを前記ユーザの条件を基に選択するワークフローマネージャに対して前記ユーザからの要求を伝えるとともに、前記アプリケーションサーバによって生成される前記医療情報を収集し、前記ワークフローマネージャから示される表示レイアウトに沿って前記医療情報の統合を行い、前記クライアント端末に表示させる統合ビューアには、前記アプリケーションの利用に応じて掛かる料金を算出する課金エンジンが接続されており、前記課金エンジンは、前記料金の算出の基となる利用料金に関する情報を記憶する課金データベースからの情報を基に前記料金の算出を行うことを特徴とする医療情報システム。
10. 前記課金エンジンは、
    前記統合ビューアから送信される情報に基づいて、利用されたアプリケーションを確認するとともに前記アプリケーションの利用量を把握する利用アプリ確認部と、
    利用が確認された前記アプリケーションの利用料金に関する情報を前記課金データベースから検索する料金検索部と、
    前記料金検索部によって検索された前記利用料金に関する情報及び前記利用アプリ確認部にて確認された前記アプリケーションの利用量を基に前記アプリケーションの利用料金を算出する料金算出部と、
    を備えることを特徴とする請求項９に記載の医療情報システム。
11. 前記課金データベースは、 複数の前記アプリケーションそれぞれに対応して異なる条件の下設定される前記利用料金に関する情報を備えていることを特徴とする請求項９または請求項１０に記載の医療情報システム。
12. 前記アプリケーションサーバは、
    前記テナント型医療情報システムからの依頼を受信するとともに生成された医療情報を送信するシンクライアントエンジンと、
    前記シンクライアントエンジンによって制御され、前記医療情報を生成するアプリケーションと、
    生成される前記医療情報の基となる医療画像を記憶する画像データベースと、
    を備えることを特徴とする請求項２または請求項９に記載の医療情報システム。
13. テナント型医療情報システム内の統合ビューアがユーザが使用するクライアント端末を介して前記ユーザからの要求を受信するステップと、
    前記要求を確認するとともに、前記統合ビューアが受信する情報の中から確認された前記要求に対応する情報を選択するステップと、
    前記要求及び前記要求に対応する情報を前記統合ビューアからワークフローマネージャへ送信するステップと、
    前記ワークフローマネージャは、受信した情報及び前記ユーザの条件を基に設定データベースから前記要求を充足する医療情報の生成に必要なアプリケーションに関する情報及び前記クライアント端末における表示レイアウトに関する情報を設定データベースから抽出するステップと、
    前記ワークフローマネージャは、抽出された前記アプリケーションに関する情報及び前記表示レイアウトに関する情報を前記統合ビューアに送信するステップと、
    前記統合ビューアは、前記アプリケーションに関する情報をシンクライアントマネージャを介して前記アプリケーションを備えるアプリケーションサーバに送信するステップと、
    前記アプリケーションサーバにて前記ユーザが要求する医療情報を生成するステップと、
    前記アプリケーションサーバが生成した前記医療情報を前記シンクライアントマネージャへ送信するステップと、
    前記シンクライアントマネージャが前記アプリケーションサーバから送信された前記医療情報を前記統合ビューアへと送信するステップと、
    前記統合ビューアは、受信した前記医療情報を前記表示レイアウトに関する情報を基に統合するステップと、
    統合された前記医療情報を前記ユーザが使用するクライアント端末へ表示させるステップと、
    を備えることを特徴とする医療情報提供方法。
14. テナント型医療情報システム内の統合ビューアがユーザが使用するクライアント端末を介して前記ユーザからの要求を受信するステップと、
    前記要求を確認するとともに、前記統合ビューアが受信する情報の中から確認された前記要求に対応する情報を選択するステップと、
    前記要求及び前記要求に対応する情報を前記統合ビューアからワークフローマネージャへ送信するステップと、
    前記ワークフローマネージャは、受信した情報及び前記ユーザの条件を基に設定データベースから前記要求を充足する医療情報の生成に必要なアプリケーションに関する情報及び前記クライアント端末における表示レイアウトに関する情報を設定データベースから抽出するステップと、
    前記ワークフローマネージャは、抽出された前記アプリケーションに関する情報及び前記表示レイアウトに関する情報を前記統合ビューアに送信するステップと、
    前記統合ビューアは、前記アプリケーションに関する情報をシンクライアントマネージャを介して前記アプリケーションを備えるアプリケーションサーバに送信するステップと、
    前記アプリケーションサーバにて前記ユーザが要求する医療情報を生成するステップと、
    前記統合ビューアが、前記アプリケーションサーバにて利用される前記アプリケーションの利用開始通知を課金エンジンへ送付するステップと、
    前記課金エンジンが、課金データベースから利用される前記アプリケーションの利用料金に関する情報を取得するステップと、
    前記統合ビューアは、前記アプリケーションサーバから受信した前記医療情報を前記表示レイアウトに関する情報を基に統合するステップと、
    前記統合ビューアが、前記アプリケーションの利用終了通知を前記課金エンジンへと送付するステップと、
    前記利用終了通知を受信した前記課金エンジンは、前記利用料金に関する情報から前記アプリケーションの利用料金を算出するステップと、
    統合された前記医療情報、算出された前記利用料金を前記ユーザが使用するクライアント端末へ表示させるステップと、
    を備えることを特徴とする医療情報提供方法。

Images