JP2015114692A - 医療情報システム - 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 (12)

1. ユーザが使用するクライアント端末と、
   システム運営者が設置し、通信ネットワークを介して前記クライアント端末から送信される前記ユーザからの要求に基づいて必要な医療情報を収集し、表示レイアウトに沿って前記クライアント端末に表示させるテナント型医療情報システムと、
   前記テナント型医療情報システムと前記通信ネットワークを介して接続され、前記テナント型医療情報システムの要求に応じて、前記ユーザが必要としている医療情報の生成をアプリ提供者によって提供されるアプリケーションを用いて行うアプリケーションサーバと、を備え、
   前記テナント型医療情報システムは、
   前記ユーザからの要求に応じて、前記ユーザが必要としている医療情報の生成を行う上で適切な前記アプリケーションを選択するワークフローマネージャと、
   前記ワークフローマネージャによって選択された前記アプリケーションを提供する前記アプリケーションサーバを制御して前記医療情報の生成を行わせるシンクライアントマネージャと、
   前記ワークフローマネージャに対して前記ユーザからの要求を伝えるとともに、前記アプリケーションサーバによって生成される前記医療情報を収集し、前記ワークフローマネージャから示される表示レイアウトに沿って前記医療情報の統合を行い、前記クライアント端末に表示させる統合ビューアと、
   を備えることを特徴とする医療情報システム。
2. 前記ワークフローマネージャが選択する前記アプリケーションに関する情報は、前記ワークフローマネージャに接続される設定データベースに記憶されていることを特徴とする請求項１に記載の医療情報システム。
3. 前記ワークフローマネージャは、
   前記統合ビューアから送信される情報を基に前記設定データベース内から前記ユーザが必要としている医療情報の生成を行う上で適切な前記アプリケーションを推奨する推奨アプリ判定部と、
   前記設定データベース内に記憶されている前記アプリケーションに関する情報を基に、前記ユーザに対して推奨の前記アプリケーションを提示するアプリ推奨部と、
   を備えることを特徴とする請求項１または請求項２に記載の医療情報システム。
4. 前記ワークフローマネージャによる前記設定データベースに記憶されている前記アプリケーションの選択は、前記統合ビューアから送信される、前記ユーザからの要求に含まれる情報や前記通信ネットワークに接続される管理サーバからの情報を基に行われることを特徴とする請求項２または請求項３に記載の医療情報システム。
5. 前記ワークフローマネージャは、前記設定データベースに記憶されている単数または複数の前記アプリケーションに関する情報を前記ユーザへ提供することを特徴とする請求項２または請求項３に記載の医療情報システム。
6. 前記ワークフローマネージャが前記アプリケーションに関する情報を前記ユーザへ提供する際は、前記アプリケーションに関する情報を一覧にして前記クライアント端末に表示させることを特徴とする請求項１または請求項５に記載の医療情報システム。
7. 前記ワークフローマネージャによって前記ユーザへ情報提供される前記アプリケーションは、前記ユーザに関する情報を基に前記ワークフローマネージャが選択することを特徴とする請求項５または請求項６に記載の医療情報システム。
8. 前記ワークフローマネージャによって前記ユーザへ情報提供される前記アプリケーションは、前記アプリケーションを利用した経験のあるユーザの評価を基に前記ワークフローマネージャが選択することを特徴とする請求項５ないし請求項７のいずれかに記載の医療情報システム。
9. 前記ワークフローマネージャによって前記ユーザへ情報提供される前記アプリケーションは、前記アプリケーションを提供する前記アプリ提供者からの要求に基づいて前記ワークフローマネージャが選択することを特徴とする請求項５ないし請求項８のいずれかに記載の医療情報システム。
10. 前記アプリ提供者は、前記アプリケーションに関して設定されている前記アプリケーションに関する情報を前記アプリケーションを利用する前記ユーザごとに設定、変更することが可能であることを特徴とする請求項１または請求項５ないし請求項９のいずれかに記載の医療情報システム。
11. 前記設定データベースは、
    ワークフローマネージャが選択する前記アプリケーションに関する情報を記憶するアプリ情報記憶部と、
    前記ユーザにおける前記アプリケーションの利用歴を記憶するアプリ利用歴記憶部と、
    を備えていることを特徴とする請求項２に記載の医療情報システム。
12. 前記アプリ利用歴記憶部に記憶されている前記ユーザにおける前記アプリケーションの利用歴は、前記クライアント端末に表示させることが可能とされていることを特徴とする
    請求項１１に記載の医療情報システム。
    
    
    

Images