JP6381901B2 - 医療情報システム及び医療情報提供方法 - 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）等、いずれの規格であっても良い。

このような医療情報システムＳでは、図１に示すように、通信ネットワークＮに二つのクライアント端末１Ａ及び１Ｂが接続されており、また、二つのアプリサーバ３Ａ及び３Ｂが接続されているが、それらの数は限定されるものではなく、単数あるいは複数のいずれでも良く、その数は任意である。また、医療画像診断装置４は１つのみ通信ネットワークＮに接続されているが、この数も限定されるものではなく任意である。

［テナント型医療情報システムの構成］
次に、前述のテナント型医療情報システム２の内部構成について図２を参照して説明する。

図２に示すように、テナント型医療情報システム２は、医療情報管理部２Ａと、医療情報提供部２Ｂとの大きく２つの部分に分かれている。医療情報管理部２Ａは、医療画像診断装置４が取得した医療画像やレポート等の医療情報を保管及び管理する。一方、医療情報提供部２Ｂは、ユーザからの要求を受け付けてユーザに必要な医療情報を生成して提供する機能を備えている。

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

医療情報提供部２Ｂは、統合ビューア２３と、ワークフローマネージャ２４と、設定データベース２５と、シンクライアントマネージャ２６と、アプリケーション２７と、課金エンジン２８と、課金データベース２９とから構成されている。これらの各部の機能を情報の流れに沿って以下に説明する。

統合ビューア２３は、まずユーザが使用するクライアント端末１Ａ又は１Ｂからの要求を受信する。受信された要求は、ワークフローマネージャ２４に送信される。このとき、例えば、要求は、管理サーバ５からの情報と突き合わせてまとめられ、ワークフローマネージャ２４に送信される。

ワークフローマネージャ２４は、ユーザからの要求に応じて、統合ビューア２３から送信された情報に基づき、ユーザが必要としている医療情報の生成を行う上で適切なアプリケーションを選択する。このワークフローマネージャ２４には、設定データベース２５が接続されている。

設定データベース２５は、テナント型医療情報システム２に接続されているアプリサーバ３Ａ及び３Ｂにより提供されるアプリケーションに関する情報を記憶している。そこで、ワークフローマネージャ２４が適切なアプリケーションを選択する際には、設定データベース２５を検索して該当するアプリケーションに関する情報を取得する。

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

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

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

なお、図２では、１つのアプリケーション２７（アプリケーションＡ）が統合ビューア２３に接続されているが、これに限るものではなく、システム提供者が提供するアプリケーションは統合ビューア２３に複数接続されても良く（テナント型医療情報システム２内に設けられている）、その数は限定されない。

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

次に、前述の統合ビューア２３の内部構成について図３を参照して説明する。

図３に示すように、統合ビューア２３は、受信部２３ａ、情報解析部２３ｂ、情報収集部２３ｃ、情報統合部２３ｄ及び送信部２３ｅを備えている。受信部２３ａは、ユーザが使用するクライアント端末１Ａ又は１Ｂから送信される要求を受信する。情報解析部２３ｂは、その要求に含まれる情報にどのような情報が含まれているのかの確認を行う。情報収集部２３ｃは、ユーザからの要求に含まれる、例えば患者情報を基に、テナント型医療情報システム２で受信する各種情報の中から当該患者に関連する情報を選択して抽出する。その後、送信部２３ｅは、情報収集部２３ｃにより抽出された患者に関する患者関連情報、さらに、ユーザからの要求に関する要求情報を合わせてワークフローマネージャ２４に送信する。また、情報統合部２３ｄは、ユーザの要求に応じてアプリケーションにより生成された各医療情報を表示レイアウトに沿って統合する。その後、送信部２３ｅは、統合された情報（統合画像）を要求元のクライアント端末１Ａ又は１Ｂに送信する。

この統合ビューア２３は医療情報を統合的にユーザに提示するアプリケーションである。ただし、本実施形態においては、テナント型医療情報システム２に当該アプリケーションが読み込まれることによって統合ビューア２３が実装されることを前提とする。なお、統合ビューア２３としては、Ｗｅｂアプリケーション、ファットクライアントアプリケーション、あるいは、シンクライアントアプリケーション等、いずれの実装形態（ソフトウエア）を採用しても良い。また、統合ビューア２３は医療情報を統合的にユーザに提示する回路（ハードウエア）としてテナント型医療情報システム２に設けられていても良い。

次いで、前述のワークフローマネージャ２４及び設定データベース２５の内部構成について図４を参照して説明する。

図４に示すように、ワークフローマネージャ２４は、送受信部２４ａと、推奨アプリ判定部２４ｂと、アプリ推奨部２４ｃとから構成される。このワークフローマネージャ２４は、設定データベース２５と接続されている。

ワークフローマネージャ２４は、医療情報を生成するアプリケーションに関する情報を抽出等するアプリケーションである。ただし、本実施形態においては、テナント型医療情報システム２に当該アプリケーションが読み込まれることによってワークフローマネージャ２４が実装されることを前提とする（ソフトウエア）。一方で、ワークフローマネージャ２４は医療情報を生成するアプリケーションに関する情報を抽出等する回路（ハードウエア）としてテナント型医療情報システム２に設けられていても良い。

推奨アプリ判定部２４ｂは、要求情報や患者関連情報を基に、設定データベース２５に記憶されているアプリケーションに関する情報を検索して抽出する。例えば、要求情報等の中に患者の疾患部位に関する情報が含まれている場合には、その疾患部位をクライアント端末１Ａ又は１Ｂの表示部に医師や患者にとって理解しやすく、見やすく表示させるに適切なアプリケーションに関する情報を選択する。また、抽出対象となるアプリケーションが設定データベース２５に複数記憶されている場合には、例えば、ユーザが通常利用しているアプリケーションを抽出したり、あるいは、シーンに応じてそのユーザがこれまで利用したりしていたアプリケーションとは異なるアプリケーションを抽出することも可能である。また、これまで利用されていたアプリケーションに類似するアプリケーションであって、より安価なアプリケーションに関する情報が登録されていた場合には、これまで利用されていたアプリケーションに替えてその安価なアプリケーションを抽出しても良い。

また、推奨アプリ判定部２４ｂは、実際にアプリケーションを利用して生成される医療情報をどのような配置で統合するかについての表示レイアウト情報についても抽出する。なお、設定データベース２５内に記憶されている情報は、上述した各情報に限定されることはない。また、設定データベース２５からどの情報を抽出するかについても任意に設定することができる。

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

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

アプリ情報記憶部２５ａは、アプリ提供者が提供するアプリケーションに関する情報を記憶している。このアプリ提供者が提供するアプリケーションとは、テナント型医療情報システム２に通信ネットワークＮを介して接続されているアプリサーバ３Ａや３Ｂ内のアプリケーションのことである。また、記憶されている内容としては、例えば、アプリケーション識別情報やアプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性、アプリケーション提供者識別情報、アプリケーション起動方法等が挙げられる。このような情報は、アプリケーションに関する情報そのものであるが、その他に、統合ビューア２３においてアプリケーションをどのように配置するかに関する情報（表示レイアウト情報）も記憶されている。表示レイアウト情報としては、アプリの統合方法、例えば、画面レイアウトが保持されている。この画面レイアウトには、そのレイアウト内に医療情報を提供したアプリケーションのサーバ識別子やアプリ種別、事前状態などが関連付けられている。なお、記憶方法としては、例えば、情報をＸＭＬファイルのようなテキスト情報としても良く、あるいは、ＲＤＢＭＳのようなデータベースに保管するようにしても良い。

アプリ利用歴記憶部２５ｂは、ユーザによるアプリケーションの利用歴を記憶する。この利用歴に関する情報は、例えば、ユーザからの要求に基づきワークフローマネージャ２４により選択されたアプリケーションによって医療情報が生成された場合に、その医療情報がシンクライアントマネージャ２６を介して統合ビューア２３によって受信されると、その統合ビューア２３から送信される。

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

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

ここで、前述のアプリサーバ３の内部構成について図５を参照して説明すると、図５に示すように、アプリサーバ３Ａ及び３Ｂは、シンクライアントエンジン３１と、アプリケーション３２と、画像データベース３３とをそれぞれ備えている。シンクライアントエンジン３１は、シンクライアントマネージャ２６から送信されたアプリケーションに関する情報を受信し、その上でアプリケーション３２の制御を行う。また、シンクライアントマネージャ２６から送信された医療画像に関する情報は、画像データベース３３に格納される。

［ユーザの要求に基づく医療情報の提供の流れ］
次に、前述の医療情報システムＳによる医療情報の提供の流れについて図６及び図７を参照して説明する。この医療情報の提供の流れでは、ユーザが自身の診察や検査において必要とする患者の医療情報について、テナント型医療情報システム２に当該医療情報の表示を要求し、この要求に従った医療情報が要求元のユーザの使用するクライアント端末１Ａ又は１Ｂに表示されるまでの流れが示されている。

図６に示すように、まず、ユーザによってテナント型医療情報システム２（統合ビューア２３）に対して必要とされる医療情報の表示が要求されたか否かが確認される（ステップＳＴ１）。この確認は、例えば、ユーザがクライアント端末１Ａ又は１Ｂを使用して統合ビューア２３を起動したか否かが、要求を受け付けた統合ビューア２３により判断されることによって行われる。

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

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

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

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

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

また、医療情報が利用される場面（シーン）に関する情報としては、例えば、ユーザが統合ビューア２３に要求する医療情報を通常の診察等で用いるのか、それとも他の診察等で用いるのかという情報が挙げられる。ただし、医療情報が通常の診察等で用いるといっても、その利用される場面は多様である。したがって、アプリケーションに関する情報を抽出及び判定する際に、シーンに関する情報を適宜参照することによって、そのシーンにより要求される（シーンに合った）医療情報の生成に適したアプリケーションに関する情報を抽出及び判定することができる。

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

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

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

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

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

その後、統合ビューア２３は、ユーザからの要求に含まれる、例えば患者情報を基に、テナント型医療情報システム２で受信する各種情報の中から当該患者に関連する情報を選択して抽出する（ステップＳＴ３）。さらに、統合ビューア２３は、当該患者に関する情報を収集した後、ユーザからの要求に関する要求情報、及び、通信ネットワークＮを介して管理サーバ５等から送信された情報の中から抽出された当該患者に関する患者関連情報を合わせて、ワークフローマネージャ２４へと送信する（ステップＳＴ４）。これらの情報は、ワークフローマネージャ２４が医療情報を得るために最適なアプリケーションを選択する上で重要な情報となる。

次に、ワークフローマネージャ２４は、統合ビューア２３から送信された要求情報及び患者関連情報を基に、ユーザが必要とする医療情報が生成可能なアプリケーションに関する情報を設定データベース２５のアプリ情報記憶部２５ａから抽出する（ステップＳＴ５）。次いで、ワークフローマネージャ２４は、設定データベース２５から抽出した医療情報を生成するに適したアプリケーションに関する情報および表示レイアウトに関する情報を統合ビューア２３へ送信する（ステップＳＴ６）。

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

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

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

次いで、対象のアプリサーバ３Ａ又は３Ｂ内のアプリケーション３２は、シンクライアントエンジン３１の制御の下、画像データベース３３に格納された医療画像に関する情報を基に医療情報を生成する（ステップＳＴ１０）。そのアプリケーション３２によって生成された医療情報は、アプリサーバ３Ａ又は３Ｂによりシンクライアントエンジン３１を介してシンクライアントマネージャ２６へ送信される（ステップＳＴ１１）。

その後、図７に示すように、シンクライアントマネージャ２６は、アプリサーバ３Ａ又は３Ｂから送信されてきた医療情報を受信する（ステップＳＴ１２）。その後、シンクライアントマネージャ２６は、ユーザからの要求に基づいて生成される医療情報の全てを受信したか否かを確認する（ステップＳＴ１３）。

前述のステップＳＴ１３において、全てのアプリサーバ３Ａ及び３Ｂからユーザの要求に対応する医療情報の全てを受信していないと判断された場合には（ステップＳＴ１３のＮＯ）、全ての医療情報が送信されてくるまで処理が待機する。一方、ステップＳＴ１３において、全ての医療情報がアプリサーバ３から送信されシンクライアントマネージャ２６が受信したことが確認された場合（ステップＳＴ１３のＹＥＳ）、シンクライアントマネージャ２６は、全ての医療情報を統合ビューア２３に対して送信する（ステップＳＴ１４）。

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

なお、図６に戻り、ステップＳＴ６において、受信した情報のうち、表示レイアウトに関する情報については、シンクライアントマネージャ２６を介してアプリサーバ３Ａ又は３Ｂに送られることはなく、統合ビューア２３内にて保持される（ステップＳＴ１５）。この表示レイアウトに関する情報は、統合ビューア２３が生成された医療情報をクライアント端末１Ａ又は２Ｂにて表示する際に利用する情報である。

図７に戻り、ステップＳＴ１４の処理後、統合ビューア２３は、アプリケーション３２を利用して生成された医療情報を受信するとともに、ユーザがクライアント端末１Ａ又は１Ｂにおいて表示することを必要としている医療情報が全て揃ったか否かを確認する（ステップＳＴ１６）。

その後、全てが揃っていない場合にはそのまま処理が待機し（ステップＳＴ１７のＮＯ）、ユーザが要求した医療情報の全てが揃ったことが確認された場合には（ステップＳＴ１７のＹＥＳ）、これら集められた医療情報が表示レイアウトに関する情報に基づいて統合ビューア２３により統合される（ステップＳＴ１８）。

前述の統合ビューア２３にて統合された情報（統合画像）は、ユーザが使用している要求元のクライアント端末１Ａ又は１Ｂに表示される（ステップＳＴ１９）。さらに、統合ビューア２３は、シンクライアントマネージャ２６から送信された、医療情報の生成の際に利用したアプリケーション３２の利用歴についての情報を受信し、ワークフローマネージャ２４や課金エンジン２８へ送信する（ステップＳＴ２０）。

以上のような処理によれば、ユーザが必要とする医療情報の要求を行ってから、適切なアプリケーションが選択され、その選択されたアプリケーションによって生成された医療情報が統合され、その上で要求元のクライアント端末１Ａ又は１Ｂに表示される。

ここで、前述のように医療情報が統合され、クライアント端末１Ａ又は１Ｂの表示部に表示される統合画像の画面例について図８を参照して説明する。なお、画面例のレイアウトは、あくまでも例示に過ぎず、そのレイアウトは自由に設定することが可能である。また、このレイアウトはワークフローマネージャ２４から統合ビューア２３に対して送られた表示レイアウトに関する情報に含まれ、その表示レイアウトに関する情報に基づいてその配置が設定される。

図８に示すように、画面例１Ａａは、上部に「患者氏名」、「患者ＩＤ」及び画像のシリーズに関する情報が表示されている。ただし、この欄にどのような情報を表示させるかについては、任意に設定することが可能である。また、画面例１Ａａの下部には、左側に１つの医療画像ａ１、右側に上下に分けて２つの医療画像ａ２及びａ３が表示されている。

医療画像ａ１は、例えば、医療画像診断装置４によって取得され、医療情報データベース２２に記憶されていた画像である。また、右側上部の医療画像ａ２は、例えば、アプリケーションＡ−１によって生成された医療画像であり、右側下部の医療画像ａ３は、例えば、アプリケーションＢ−１によって生成された医療画像である。したがって、このような画面例１Ａａにおいては、各アプリケーションによって生成された医療画像とともに、これら医療情報としての医療画像生成の基となった医療画像が同じ表示部に示されていることになる。

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

このような画面例１Ａａの表示によって、例えば、ユーザである医師は医療画像診断装置４によって取得された医療画像ａ１を基に、医師が指定したアプリケーションにより生成された医療画像ａ２及びａ３を利用して患者に対してより適切な診察及び説明を行うことができる。

［アプリケーションの利用に基づく課金の流れ］
次に、前述の課金エンジン２８の内部構成について図９を参照して説明する。

図９に示すように、課金エンジン２８は、情報を受信する受信部２８ａと、利用されたアプリケーションを確認する利用アプリ確認部２８ｂと、そのアプリケーションを利用するに当たって必要とされる基本の料金を検索する料金検索部２８ｃと、検索された基本料金を基に実際に掛かった料金を算出する料金算出部２８ｄと、算出された料金に関する情報をユーザのクライアント端末１Ａ又は１Ｂに向けて送信する送信部２８ｅとを備えている。

これら各部の詳しい働きについては、以下のアプリケーション利用に基づく課金の流れを説明する際に併せて説明する。なお、以下においては、いずれかのアプリケーションが利用され、ユーザが要求する医療情報が生成された場合に、当該アプリケーション利用に関するユーザへの課金の流れについて図１０を参照して説明する。

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

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

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

前述のステップＳＴ３２の処理後、課金エンジン２８は、統合ビューア２３からの利用開始通知を利用して、医療情報マネージャ２１にアクセスし、医療情報として生成される基となる医療画像のデータサイズを取得する（ステップＳＴ３３）。

ここで、医療情報マネージャ２１は、医療画像診断装置４によって取得された医療画像を受信した際に、例えば、当該医療画像を識別するための識別子と画像サイズ（例えば、データ量（ＫＢ））を関連付けて医療情報データベース２２に記憶させておく。また、医療情報マネージャ２１は、課金エンジン２８からのアクセスによって、医療情報として生成される基となる医療画像の識別子を手がかりに、対象の医療画像の画像サイズを医療情報データベース２２から取得する。

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

前述のステップＳＴ３３の処理後、課金エンジン２８の料金検索部２８ｃは、統合ビューア２３から取得した情報を基に、課金データベース２９から利用されるアプリケーションに関する利用料金の単価を取得する（ステップＳＴ３４）。

なお、課金データベース２９内には、予めテナント型医療情報システム２に提供される各アプリケーションに関する利用料金の単価が記憶されている。そこで、料金検索部２８ｃは、利用開始通知を受信した後、当該単価を検索及び取得して待機する。

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

なお、課金エンジン２８が利用開始通知の受信をトリガーとしてアプリケーションの利用単価を検索している間、アプリサーバ３Ａ又は３Ｂでは、要求された医療情報の生成を行っている。そして上述した通り、医療情報が生成されるとシンクライアントマネージャ２６に対して生成された医療情報を送信する。

前述のステップＳＴ３４の処理後、シンクライアントマネージャ２６は、取得した医療情報を統合ビューア２３へと送信する（ステップＳＴ３５）。統合ビューア２３は、表示が要求される医療情報の全てが揃ったか否かを確認し（ステップＳＴ３６、図７に示すステップＳＴ１６に該当）、全ての医療情報が揃うまで待機する（ステップＳＴ３７、図７に示すステップＳＴ１７に該当）。全ての医療情報が揃ったか否かの判断は、統合ビューア２３がシンクライアントマネージャ２６を介して各アプリサーバ３Ａ又は３Ｂへ医療情報の生成を依頼する際に保持する、各アプリケーションに関する情報を用いて行われる。

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

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

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

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

その後、前述のように算出された利用料金は、料金算出部２８ｄ、あるいは、統合ビューア２３等に保持されて、ユーザの要求や他の操作をトリガーとして課金に関する情報がクライアント端末１Ａ又は１Ｂの表示部に表示される（ステップＳＴ４０）。

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

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

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

以上説明したように、第１の実施形態によれば、ユーザが必要とする医療情報について、その要求から取得、加えて、アプリケーションの利用に伴う課金の流れまで説明した通り、医療機関内に構築されるシステムを、単独のシステム運営者の下で単数または複数のアプリケーションを利用できるシステムとすることで、アプリケーション利用におけるユーザの利便性を向上させることができる。

なお、上述した統合ビューア２３から送信された要求情報及び患者関連情報を基に、ユーザが必要とする医療情報が生成可能なアプリケーションに関する情報を設定データベース２５から抽出し判定する、というワークフローマネージャ２４の働きについては、別の抽出及び判定処理を行うことも可能である。例えば、統合ビューア２３から要求情報及び患者関連情報を受信したワークフローマネージャ２４は、設定データベース２５のアプリ情報記憶部２５ａからユーザからの要求に適したアプリケーションに関する情報を抽出する際に、経済的な視点を加味してアプリケーションの情報を抽出することが可能である。

（第２の実施形態）
第２の実施形態について図１２ないし図１５を参照して説明する。なお、第２の実施形態では、第１の実施形態との相違点について説明し、第１の実施形態で説明した部分と同一部分は同一符号で示し、その説明も省略する。

図１２に示すように、第２の実施形態に係る医療情報システムＳは、システム提供者が第１の医療機関に対して提供する第１の医療情報システムＳａと、システム提供者が第２の医療機関に対して提供する第２の医療情報システムＳｂと、それらの医療情報システムＳａ及びＳｂを連携する地域連携マネージャ４１と、各種のアプリケーションを管理するデータセンタ４２及び４３とを備えている。

なお、第１の医療情報システムＳａ及び第２の医療情報システムＳｂの構成は、どちらも第１の実施形態に係る医療情報システムＳ（図１参照）と同じである。ただし、第２の医療情報システムＳｂは、第１の実施形態に係るアプリサーバ３Ａ及び３Ｂに替えて、アプリサーバ３Ｃ（アプリサーバＫ）及びアプリサーバ３Ｄ（アプリサーバＨ）を備えている。これらのアプリサーバ３Ｃ及び３Ｄの構成はどちらも第１の実施形態に係るアプリサーバ３Ａ及び３Ｂと同じである（図５参照）。

地域連携マネージャ４１は、第１の医療情報システムＳａが有するテナント型医療情報システム２及び第２の医療情報システムＳｂが有するテナント型医療情報システム２の両方に接続されている。また、第１の医療情報システムＳａのテナント型医療情報システム２、第２の医療情報システムＳｂのテナント型医療情報システム２、さらに、データセンタ４２及び４３は、有線又は無線等の通信ネットワークＮａを介して接続されており、互いに通信が可能に形成されている。

データセンタ４２はアプリサーバ３Ｅを備えており、データセンタ４３はアプリサーバ３Ｆを備えている。これらのアプリサーバ３Ｅ及び３Ｆの構成はどちらも第１の実施形態に係るアプリサーバ３Ａ及び３Ｂと同じである（図５参照）。なお、データセンタ４２及び４３が備えるアプリサーバの数は単数に限定されるものではなく、複数であっても良い。また、第１の実施形態と同様に、アプリサーバ３Ｅ及び３Ｆは、格納するアプリケーションごとやその種類ごとに設けられていても良く、あるいは、アプリ提供者ごとに設けられていても良い。後者の場合には、アプリ提供者が提供するアプリケーションがまとめて１つのアプリサーバ３Ｅ又は３Ｆ内に単数あるいは複数記憶されている。

通信ネットワークＮａは、第１の医療情報システムＳａのテナント型医療情報システム２と、第２の医療情報システムＳｂのテナント型医療情報システム２と、データセンタ４２及び４３とを各々つなぎ、互いの間で、例えば医療情報のやりとり（通信）を可能とする。この通信ネットワークＮａの例としては、ＬＡＮ（Local Area Network）やインターネット等の通信ネットワークが挙げられる。また、この通信ネットワークＮａで使用される通信規格は、ＤＩＣＯＭ（Digital Imaging and Communication in Medicine）等、いずれの規格であっても良い。

このような医療情報システムＳでは、図１２に示すように、第１の医療情報システムＳａ及び第２の医療情報システムＳｂが構築されているが、それらのシステム数は二つ以上であれば良く、また、二つのデータセンタ４２及び４３が接続されているが、それらの数は限定されてものではなく、単数あるいは複数のいずれでも良く、その数は任意である。

図１３に示すように、第１の医療情報システムＳａのテナント型医療情報システム２及び第２の医療情報システムＳｂのテナント型医療情報システム２は、それぞれ第１の実施形態と同様に各部、特に、統合ビューア２３、ワークフローマネージャ２４、設定データベース２５、シンクライアントマネージャ２６及びアプリケーション２７を備えている。なお、図１３では、第１の医療情報システムＳａ、第２の医療情報システムＳｂ、データセンタ４２及び４３の各部の主要部分のみが示されている。ここで、第１の医療情報システムＳａのテナント型医療情報システム２が第１のテナント型医療情報システムとして機能し、第２の医療情報システムＳｂのテナント型医療情報システム２が第２のテナント型医療情報システムとして機能する。

第１の医療情報システムＳａのシンクライアントマネージャ２６は、アプリサーバ３Ａ及び３Ｂに通信ネットワークＮを介して接続されており、さらに、アプリサーバ３Ｅ及び３Ｆに通信ネットワークＮａを介して接続されている。この第１の医療情報システムＳａのシンクライアントマネージャ２６は、第１の医療情報システムＳａのワークフローマネージャ２４によって選択されたアプリケーションを提供するアプリサーバ３Ａ、３Ｂ、３Ｅ又は３Ｆを制御し、ユーザからの要求に応じた医療情報の生成をアプリケーションに実行させる。

第２の医療情報システムＳｂのシンクライアントマネージャ２６は、アプリサーバ３Ｃ及び３Ｄに通信ネットワークＮを介して接続されており、さらに、アプリサーバ３Ｅ及び３Ｆに通信ネットワークＮａを介して接続されている。この第２の医療情報システムＳｂのシンクライアントマネージャ２６は、第２の医療情報システムＳｂのワークフローマネージャ２４によって選択されたアプリケーションを提供するアプリサーバ３Ｃ、３Ｄ、３Ｅ又は３Ｆを制御し、ユーザからの要求に応じた医療情報の生成をアプリケーションに実行させる。

地域連携マネージャ４１は、ユーザ（例えば、医師や技師など）ごとにワークフロープロファイル（ワークフロー情報）を管理するマネージャであって、例えば、第１の医療機関及び第２の医療機関の両方で業務を行うユーザに関するワークフロープロファイルを管理する。この地域連携マネージャ４１は、各ユーザのワークフロープロファイルが地域連携マネージャ４１内に存在する旨を第１の医療情報システムＳａや第２の医療情報システムＳｂに通知する。

例えば、あるユーザのワークフロープロファイルが第１の医療情報システムＳａのワークフローマネージャ２４により地域連携マネージャ４１に統合ビューア２３を介して登録される。すると、その登録に応じて、地域連携マネージャ４１は、対象ユーザが業務を行う可能性がある第２の医療情報システムＳｂのワークフローマネージャ２４に統合ビューア２３を介して、対象ユーザに関するワークフロープロファイルが存在する旨を通知する。これにより、第２の医療情報システムＳｂのワークフローマネージャ２４は、対象ユーザに関するワークフロープロファイルが地域連携マネージャ４１に登録されていることを把握することが可能となり、必要に応じてその情報を用いることができる。

ここで、ワークフロープロファイルは、地域連携マネージャ４１によりユーザごとに関連付けられて管理されている。このワークフロープロファイルには、ユーザが自施設で用いた表示レイアウト情報が含まれており、この表示レイアウト情報としては、アプリの統合方法、例えば、画面レイアウトが保持されている。この画面レイアウトには、そのレイアウト内に医療情報を提供したアプリケーションのサーバ識別子やアプリ種別、事前状態などが関連付けられている。

なお、本実施形態においては、医療情報システムＳにアプリケーションが読み込まれることによって地域連携マネージャ４１が実装されるが（ソフトウエア）、これに限るものではなく、例えば、地域連携マネージャ４１は各ユーザのワークフロープロファイルを管理する回路（ハードウエア）として医療情報システムＳに設けられていても良い。

次に、前述の医療情報システムＳによる医療情報の提供の流れについて図１４を参照して説明する。なお、ユーザは第１の医療機関である自施設及び第２の医療機関である他施設の両方で業務を行うものとして説明を行う。

図１４に示すように、第１の医療情報システムＳａのワークフローマネージャ２４は、適宜、業務を行うユーザのワークフロープロファイルを地域連携マネージャ４１に統合ビューア２３を介して登録する（ステップＳＴ５１）。

このステップＳＴ５１では、例えば、ワークフロープロファイルは、ユーザの自施設（第１の医療機関）において業務（クライアント端末１Ａ又は１Ｂを利用した各種業務）が完了したタイミングで、地域連携マネージャ４１に登録される。この登録のタイミングは特に限定されるものではなく、他のタイミングでも良く、また、登録自体も他のオフライン媒体による伝達方法により行われても良い。なお、第１の医療情報システムＳａのクライアント端末１Ａ又は１Ｂが第１のクライアント端末として機能する。

ここで、ワークフロープロファイルは、ユーザ識別情報（例えば、ユーザＩＤやユーザ名など）に関連付けられて地域連携マネージャ４１に登録される。これにより、地域連携マネージャ４１はワークフロープロファイルをユーザごとに管理することが可能になる。このワークフロープロファイルは、前述のように、ユーザが自施設で用いた表示レイアウト情報を含んでおり、表示レイアウト情報としては、アプリの統合方法、例えば、画面レイアウトが保持されている。この画面レイアウトには、そのレイアウト内に医療情報を提供したアプリケーションのサーバ識別子やアプリ種別などが関連付けられている。

例えば、図８に示す画面例１Ａａ（画面レイアウト）において、医療画像ａ１は、例えば、第１の医療情報システムＳａの医療画像診断装置４によって取得され、第１の医療情報システムＳａのテナント型医療情報システム２に記憶されていた画像である。また、右側上部の医療画像ａ２は、例えば、第１の医療情報システムＳａのアプリケーション２７（アプリケーションＡ）によって生成された医療画像であり、右側下部の医療画像ａ３は、例えば、アプリサーバ３Ａ（アプリサーバＢ）のアプリケーションＢによって生成された医療画像である。

このような画面レイアウトと、アプリケーションＡ及びアプリケーションＢは関連付けられ、ユーザが使用した画面レイアウトに関するワークフロープロファイルが生成される。さらに、このワークフロープロファイルには、アプリケーションＢの代替のアプリケーションとして、例えば、データセンタ４２のアプリサーバ３Ｅ内のアプリケーションＢａが関連付けられて設定されている。このとき、代替のアプリケーションは、ユーザにより予め設定されても良く、あるいは、通信ネットワークＮａを介して接続されている全アプリケーションから同じ機能を有するアプリケーションが自動的に選択されることによって設定されても良い。

図１４に戻り、前述のステップＳＴ５１の処理後、地域連携マネージャ４１は、前述の登録に応じて、ユーザが業務を行う可能性がある他施設（第２の医療機関）、すなわち第２の医療情報システムＳｂのワークフローマネージャ２４に統合ビューア２３を介して、そのユーザに対応するワークフロープロファイルが存在する旨を通知する（ステップＳＴ５２）。

その後、ユーザが他施設（第２の医療機関）で業務を行うと、第２の医療情報システムＳｂは、クライアント端末１Ａ又は１Ｂに対するユーザの入力操作に応じて、第２の医療情報システムＳｂの統合ビューア２３を起動する（ステップＳＴ５３）。なお、第２の医療情報システムＳｂのクライアント端末１Ａ又は１Ｂが第２のクライアント端末として機能する。

ステップＳＴ５３の処理後、第２の医療情報システムＳｂのワークフローマネージャ２４は、地域連携マネージャ４１から対象ユーザのワークフロープロファイルを読み込み、第２の医療情報システムＳｂの統合ビューア２３にセットする（ステップＳＴ５４）。

このステップＳＴ５４では、例えば、ユーザの識別情報（例えば、ユーザＩＤやユーザ名など）がクライアント端末１Ａ又は１Ｂに対するユーザの入力操作によって入力されると、そのユーザの識別情報に基づいて対象ユーザのワークフロープロファイルが地域連携マネージャ４１から検索されて読み込まれる。

次に、第２の医療情報システムＳｂの統合ビューア２３は、ワークフロープロファイルの表示レイアウト情報、例えば、前述の画面レイアウトに従って各種のアプリケーション、まずアプリケーションＡを起動する（ステップＳＴ５５）。

次いで、第２の医療情報システムＳｂの統合ビューア２３は、前述の画面レイアウトに従ってアプリケーションＢを起動しようとするが、そのアプリケーションＢが第２の医療情報システムＳｂに存在しないため、ワークフロープロファイルに設定されているアプリケーションＢの代替のアプリケーション、すなわちデータセンタ４２が有するアプリサーバ３Ｅ内のアプリケーションＢａを検索して起動する（ステップＳＴ５６）。

その後、第２の医療情報システムＳｂの統合ビューア２３は、アプリケーションＡ及びアプリケーションＢによりそれぞれ生成された医療情報に加え、表示に必要な全ての医療情報をワークフロープロファイルの表示レイアウト情報、すなわち前述の画面レイアウトに従って統合し、第２の医療情報システムＳｂにおける要求元のクライアント端末１Ａ又は１Ｂに表示させる（ステップＳＴ５７）。なお、この統合表示の詳細は第１の実施形態と基本的に同様である（図６及び図７参照）。

これにより、図１５に示すように、画面例１Ａｂの画面レイアウトは、地域連携マネージャ４１から読み込まれたワークフロープロファイルの表示レイアウト情報である画面レイアウト（図８参照）と同じとなる。この画面例１Ａｂ（画面レイアウト）において、医療画像ａ１は、例えば、第２の医療情報システムＳｂの医療画像診断装置４によって取得され、第２の医療情報システムＳｂのテナント型医療情報システム２に記憶されていた画像である。また、右側上部の医療画像ａ２は、例えば、第２の医療情報システムＳｂのアプリケーション２７（アプリケーションＡ）によって生成された医療画像である。また、右側下部の医療画像ａ３Ａは、例えば、アプリサーバ３Ａ（アプリサーバＢ）のアプリケーションＢの替わりとなる代替のアプリケーション、すなわち、データセンタ４２が有するアプリサーバ３Ｅ内のアプリケーションＢａによって生成された医療画像である。なお、第２の医療情報システムＳｂのアプリケーション２７（アプリケーションＡ）は、第１の医療情報システムＳａのアプリケーション２７（アプリケーションＡ）と同じものである。

このような医療情報の提供によれば、ユーザが自施設で使用するアプリケーションＢが他施設に無くても、ユーザは意識することなく、データセンタ４２のアプリサーバ３Ｅ内のアプリケーションＢａを利用し、自施設と同様のワークフローで業務を行うことが可能となる。すなわち、ユーザが自施設（第１の医療機関）から他施設（第２の医療機関）に行き、その他施設の第２の医療情報システムＳｂを使用する場合でも、ユーザは自施設の第１の医療情報システムＳａと同じ機能を有するアプリケーションを用いることが可能となる。これにより、ユーザは自身のいつものワークフローで検査や診断、読影などの各種業務を行うことができ、その結果、ユーザの使い勝手は良くなり、アプリケーション利用におけるユーザの利便性が向上することになる。

なお、前述のようなアプリケーションの利用に対する課金に関して、データセンタ４２のアプリサーバ３Ｅ内のアプリケーションＢａを利用した場合には、その利用歴がデータセンタ４２から第２の医療情報システムＳｂを介して地域連携マネージャ４１に送信される。地域連携マネージャ４１はその利用歴を第１の医療情報システムＳａに送信し、第１の医療情報システムＳａの課金エンジン２８（図２参照）がその利用歴を用いることになる。なお、利用歴の送信は、これに限るものではなく、例えば、データセンタ４２又は４３から直接第１の医療情報システムＳｂに利用歴が送信されても良い。ただし、この場合には、データセンタ４２又は４３に対してユーザ情報（例えば、どの医療機関に所属しているかなどの秘匿情報も含まれる場合がある）を送信する必要が生じるため、ユーザ情報の保護の観点から地域連携マネージャ４１を介する送信の方が好ましい。

また、ユーザの自施設において、例えば、第１の医療情報システムＳａのアプリサーバ３Ａ内のアプリケーションＢが故障した場合には、その代替のアプリケーション、すなわち、第２の医療情報システムＳｂにおけるデータセンタ４２のアプリサーバ３Ｅ内のアプリケーションＢａを利用するようにしても良い。この場合にも、第１の医療情報システムＳａは、対象ユーザに対応するワークフロープロファイルを読み込み、そのワークフロープロファイル内の表示レイアウト情報を用いて、代替のアプリケーションを決定する。なお、ワークフロープロファイルとしては、例えば、予め自施設にワークフロープロファイルを記憶しておき、そのワークフロープロファイルを読み込んで用いても良く、あるいは、地域連携マネージャ４１からワークフロープロファイルを読み込んで用いても良い。

以上説明したように、第２の実施形態によれば、第１の実施形態と同様の効果を得ることができる。さらに、要求元のユーザに対応するワークフロープロファイル（ワークフロー情報）を地域連携マネージャ４１から読み込み、そのワークフロープロファイル内の第１の医療情報システムＳａにおける表示レイアウトを用いる場合には、その表示レイアウトに関連するアプリケーションに替えて代替のアプリケーションを起動し、その代替のアプリケーションにより第２の医療情報システムＳｂにおける医療情報を生成する。これにより、他施設にユーザが使用するアプリケーションが無くても、ユーザは意識することなく、そのアプリケーションの替わりとなる代替のアプリケーションを利用し、自施設と同様のワークフローで業務を行うことが可能となる。これにより、ユーザの使い勝手は良くなるため、アプリケーション利用におけるユーザの利便性を向上させることができる。

また、地域連携マネージャ４１は、第１の医療情報システムＳａにおける表示レイアウト及びその表示レイアウト内の医療情報を生成するアプリケーションに加え、そのアプリケーションの替わりとなる代替のアプリケーションが関連付けられているワークフロープロファイルをユーザに関連付けて管理する。さらに、第２の医療情報システムＳｂは、読み込んだワークフロープロファイルに示されている代替のアプリケーションを検索して起動し、その代替のアプリケーションにより第２の医療情報システムＳｂにおける医療情報を生成する。これにより、表示レイアウトに基づくアプリケーションが第２の医療情報システムＳｂに存在しない場合でも、ワークフロープロファイルにより代替のアプリケーションが指定されており、その代替のアプリケーションを確実に起動することが可能となるので、アプリケーション利用におけるユーザの利便性を確実に向上させることができる。

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

１Ａ クライアント端末
１Ｂ クライアント端末
２ テナント型医療情報システム
３Ａ アプリサーバ
３Ｂ アプリサーバ
３Ｃ アプリサーバ
３Ｄ アプリサーバ
３Ｅ アプリサーバ
３Ｆ アプリサーバ
Ｓ 医療情報システム
Ｓａ 第１の医療情報システム
Ｓｂ 第２の医療情報システム

Claims (7)

1. ユーザが第１の医療機関で使用する第１のクライアント端末と、
   システム運営者が前記第１の医療機関に提供し、前記第１のクライアント端末から送信される前記ユーザからの要求に基づいて必要な医療情報を収集し、その収集した医療情報を表示レイアウトに沿って前記第１のクライアント端末に表示させる第１のテナント型医療情報システムと、
   アプリケーション提供者が前記第１の医療機関に提供し、前記第１のテナント型医療情報システムから送信される要求に応じて、前記第１のテナント型医療情報システムにおける医療情報をそれぞれ生成する複数のアプリケーションと、
   前記ユーザが第２の医療機関で使用する第２のクライアント端末と、
   システム運営者が前記第２の医療機関に提供し、前記第２のクライアント端末から送信される前記ユーザからの要求に基づいて必要な医療情報を収集し、その収集した医療情報を表示レイアウトに沿って前記第２のクライアント端末に表示させる第２のテナント型医療情報システムと、
   アプリケーション提供者が前記第２の医療機関に提供し、前記第２のテナント型医療情報システムから送信される要求に応じて、前記第２のテナント型医療情報システムにおける医療情報をそれぞれ生成する複数のアプリケーションと、
   前記第１のテナント型医療情報システムにおける表示レイアウト及びその表示レイアウト内の医療情報を生成するアプリケーションが関連付けられているワークフロー情報を前記ユーザに関連付けて管理する地域連携マネージャと、
   アプリケーション提供者が前記第２の医療機関に提供し、前記第１のテナント型医療情報システムにおける表示レイアウトに関連するアプリケーションに替わり、前記第２のテナント型医療情報システムにおける医療情報を生成する代替のアプリケーションと、
   を備え、
   前記第１のテナント型医療情報システムは、前記第１のテナント型医療情報システムにおける医療情報をそれぞれ生成する複数のアプリケーションに関するアプリケーション情報を事前に記憶し、前記第１のクライアント端末から送信される前記ユーザからの要求を受けた場合に、要求中に含まれる患者情報と、要求される医療情報に関する要求情報と、前記アプリケーション情報とを比較して、要求に対応するアプリケーションの候補を選択し、
   前記第２のテナント型医療情報システムは、前記第２のクライアント端末から送信される前記ユーザからの要求に応じて、その要求元のユーザに対応する前記ワークフロー情報を前記地域連携マネージャから読み込み、そのワークフロー情報内の前記第１のテナント型医療情報システムにおける表示レイアウトを用いるとき、その表示レイアウトに関連するアプリケーションに替えて前記代替のアプリケーションに前記第２のテナント型医療情報システムにおける医療情報を生成させることを特徴とする医療情報システム。
2. 前記ワークフロー情報は、前記第１のテナント型医療情報システムにおける表示レイアウト及びその表示レイアウト内の医療情報を生成するアプリケーションに加え、そのアプリケーションの替わりとなる代替のアプリケーションが関連付けられており、
   前記第２のテナント型医療情報システムは、読み込んだ前記ワークフロー情報内の代替のアプリケーションを検索して起動し、その代替のアプリケーションに前記第２のテナント型医療情報システムにおける医療情報を生成させることを特徴とする請求項１記載の医療情報システム。
3. ユーザが第１の医療機関で使用する第１のクライアント端末から送信されるユーザからの要求に基づいて、システム運営者が前記第１の医療機関に提供する第１のテナント型医療情報システムにより、アプリケーション提供者が前記第１の医療機関に提供する複数のアプリケーションに要求を送信するステップと、
   前記第１のテナント型医療情報システムから送信される要求に応じて、前記第１の医療機関における複数のアプリケーションにより、前記第１のテナント型医療情報システムにおける医療情報をそれぞれ生成するステップと、
   前記第１のテナント型医療情報システムにより、前記第１のテナント型医療情報システムにおける複数の医療情報を表示レイアウトに沿って前記第１のクライアント端末に表示させるステップと、
   前記第１のテナント型医療情報システムにより、前記第１のテナント型医療情報システムにおける表示レイアウト及びその表示レイアウト内の医療情報を生成するアプリケーションが関連付けられているワークフロー情報を前記ユーザに関連付けて地域連携マネージャに登録するステップと、
   ユーザが第２の医療機関で使用する第２のクライアント端末から送信されるユーザからの要求に基づいて、システム運営者が前記第２の医療機関に提供する第２のテナント型医療情報システムにより、アプリケーション提供者が前記第２の医療機関に提供する複数のアプリケーションに要求を送信するステップと、
   前記第２のテナント型医療情報システムから送信される要求に応じて、前記第２の医療機関における複数のアプリケーションにより、前記第２のテナント型医療情報システムにおける医療情報をそれぞれ生成するステップと、
   前記第２のテナント型医療情報システムにより、前記第２のテナント型医療情報システムにおける複数の医療情報を表示レイアウトに沿って前記第２のクライアント端末に表示させるステップと、
   を有し、
   前記第１の医療機関における医療情報を生成するステップでは、前記第１のテナント型医療情報システムにおける複数のアプリケーションに関するアプリケーション情報を事前に記憶し、前記第１のクライアント端末から送信される前記ユーザからの要求を受けた場合に、要求中に含まれる患者情報と、要求される医療情報に関する要求情報と、前記アプリケーション情報とを比較して、要求に対応するアプリケーションの候補を選択し、
   前記第２の医療機関における医療情報を生成するステップでは、前記第２のクライアント端末から送信される前記ユーザからの要求に応じて、その要求元のユーザに対応する前記ワークフロー情報を読み込み、そのワークフロー情報内の前記第１のテナント型医療情報システムにおける表示レイアウトを用いるとき、その表示レイアウトに関連するアプリケーションに替えて代替のアプリケーションにより前記第２のテナント型医療情報システムにおける医療情報を生成することを特徴とする医療情報提供方法。
4. ユーザが使用するクライアント端末と、
   システム運営者が提供し、前記クライアント端末から送信される前記ユーザからの要求に基づいて必要な医療情報を収集し、その収集した医療情報を表示レイアウトに沿って前記クライアント端末に表示させるテナント型医療情報システムと、
   前記テナント型医療情報システムの要求に応じて、前記ユーザが必要としている医療情報の生成をアプリ提供者によって提供されるアプリケーションを用いて行うアプリケーションサーバと、
   を備え、
   前記テナント型医療情報システムは、複数のアプリケーションに関するアプリケーション情報を事前に記憶し、前記クライアント端末から送信される前記ユーザからの要求を受けた場合に、要求中に含まれる患者情報と、要求される医療情報に関する要求情報と、前記アプリケーション情報とを比較して、要求に対応するアプリケーションの候補を選択することを特徴とする医療情報システム。
5. 前記アプリケーション情報には、医療情報を使用するシーンに関する情報が記録されており、
   前記第１のテナント型医療情報システムは、要求に含まれる情報に基づいて前記シーンを特定し、特定された前記シーンに対応する前記アプリケーション情報に係る前記アプリケーションの候補を選択することを特徴とする請求項１記載の医療情報システム。
6. 前記患者情報には、検査済みの検査と未実施の検査を示す検査オーダに関する情報が含まれており、
   前記第１のテナント型医療情報システムは、前記検査オーダに基づいて前記シーンを特定することを特徴とする請求項５記載の医療情報システム。
7. 前記アプリケーション情報には、疾患部位に関する情報が記録されており、
   前記第１のテナント型医療情報システムは、前記要求情報に患者の疾患部位に関する情報が含まれている場合、対応する疾患部位に関する情報を用いて前記アプリケーションの候補を選択することを特徴とする請求項１記載の医療情報システム。

Images