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

Abstract

【課題】医療情報システムにおいてアプリケーション利用におけるユーザの利便性を向上させる。
【解決手段】実施形態に係る医療情報システムＳは、クライアント端末１Ａ又は１Ｂと、そのクライアント端末１Ａ又は１Ｂから送信されるユーザからの要求に基づいて必要な医療情報を収集し、その収集した医療情報を表示レイアウトに沿って要求元のクライアント端末１Ａ又は１Ｂに表示させるテナント型医療情報システム２と、そのテナント型医療情報システム２から送信される要求に応じて、医療情報としての解析結果をそれぞれ生成する複数のアプリケーション（アプリサーバ３Ａ又は３Ｂ）とを備える。テナント型医療情報システム２は、各アプリケーションによりそれぞれ得られた解析結果を表示レイアウトに沿って統合することにより統合レポートを生成し、その統合レポートを要求元のクライアント端末１Ａ又は１Ｂに表示させる。
【選択図】図１

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 (7)

1. ユーザが使用するクライアント端末と、
   システム運営者が提供し、前記クライアント端末から送信される前記ユーザからの要求に基づいて必要な医療情報を収集し、その収集した医療情報を表示レイアウトに沿って前記クライアント端末に表示させるテナント型医療情報システムと、
   アプリケーション提供者が提供し、前記テナント型医療情報システムから送信される要求に応じて、前記医療情報としての解析結果をそれぞれ生成する複数のアプリケーションと、
   を備え、
   前記テナント型医療情報システムは、前記複数のアプリケーションによりそれぞれ生成された解析結果を前記表示レイアウトに沿って統合することにより統合レポートを生成し、その生成した統合レポートを前記クライアント端末に表示させることを特徴とする医療情報システム。
2. 前記複数のアプリケーションは、それぞれ解析結果に係る独自の解析レポートを生成し、
   前記テナント型医療情報システムは、前記複数のアプリケーションによりそれぞれ生成された前記独自の解析レポートと前記統合レポートとを関連付けて保存することを特徴とする請求項１記載の医療情報システム。
3. 前記テナント型医療情報システムは、前記複数のアプリケーションによりそれぞれ生成された前記独自の解析レポートとその独自の解析レポートに含まれる解析結果に対応する医療画像とを関連付けて保存することを特徴とする請求項２記載の医療情報システム。
4. 前記テナント型医療情報システムは、前記複数のアプリケーションのうちの第１のアプリケーションにより生成された解析結果を第２のアプリケーションに提供し、アプリケーション間の連携を実行することを特徴とする請求項１ないし３のいずれか一に記載の医療情報システム。
5. ユーザが使用するクライアント端末から送信されるユーザからの要求に基づいて、システム運営者が提供するテナント型医療情報システムにより、アプリケーション提供者が提供する複数のアプリケーションに要求を送信するステップと、
   前記テナント型医療情報システムから送信される要求に応じて、前記複数のアプリケーションにより解析結果をそれぞれ生成するステップと、
   前記複数のアプリケーションによりそれぞれ生成された解析結果を前記表示レイアウトに沿って統合することにより統合レポートを生成し、その生成した統合レポートを前記クライアント端末に表示させるステップと、
   を有することを特徴とする医療情報提供方法。
6. ユーザが使用するクライアント端末と、
   システム運営者が提供し、前記クライアント端末から送信される前記ユーザからの要求に基づいて必要な医療情報を収集し、その収集した医療情報を表示レイアウトに沿って前記クライアント端末に表示させるテナント型医療情報システムと、
   アプリケーション提供者が提供し、前記テナント型医療情報システムから送信される要求に応じて、前記医療情報としての解析結果をそれぞれ生成する複数のアプリケーションと、
   を備え、
   前記複数のアプリケーションは、基準データセットに対して同じ解析結果を得る解析処理を行う等価なアプリケーションであり、
   前記テナント型医療情報システムは、前記基準データセットに対する前記複数のアプリケーションのそれぞれの解析処理により生成された解析結果を比較し、それらの解析結果を同じにするための校正パラメータを前記アプリケーションごとに生成することを特徴とする医療情報システム。
7. 前記テナント型医療情報システムは、前記アプリケーションごとの校正パラメータから、前記ユーザからの要求に応じたアプリケーションに対応する校正パラメータを選択して用いることを特徴とする請求項６記載の医療情報システム。

Images