JP2016224676A - 医療情報システム及び当該医療情報システムを利用した課金方法 - Google Patents

Abstract

【課題】アプリケーションの診断等に対する有効度を勘案して料金算出を行う医療情報システム及び医療情報システムを利用した課金方法を提供する。
【解決手段】ユーザが使用するクライアント端末１Ａ、１Ｂと、ユーザが医療画像診断装置４によって取得された患者の内部情報を示す医療画像を基に診断を行う際に利用する医療画像の処理を行うアプリケーションを備えるアプリケーションサーバ３Ａ、３Ｂと、ユーザが診断を行うに当たって、その判断に有効な医療画像の生成、表示を行ったアプリケーションを提供したアプリ提供者に対して、医療画像の有効度、医療画像に対して行った処理の有効度に応じた利用金額を算出するテナント型医療情報システム２とを備える。
【選択図】図１

Description

本発明の実施の形態は、医療情報システム及び当該医療情報システムを利用した課金方法に関する。

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

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

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

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

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

すなわち、通常、提供されているアプリケーションを利用してユーザが医療画像の生成や医療画像の処理を行った場合、例えば、その利用時間等に応じて当該アプリケーションの提供者に対してアプリケーションの利用料金が支払われることになる。つまりここでの利用料金の算出においては、アプリケーションをどのくらいの時間利用したのか、機械的に計測された時間を基にしている。

一方で、当該アプリケーションを利用したことによって生成された医療画像、或いは、当該医療画像を基に行われた処理によって、ユーザが診断を行うに当たってどのくらい役だったのか、という点については考慮されない。換言すれば、数多く提供されているアプリケーションの中で、例えば、実際に診断を行うに役立った医療画像を生成するアプリケーションである、といった判断はなされておらず、それぞれのアプリケーションに関する実態を把握しにくい。つまり、利用時間だけを基に利用料金を算出すると、例えば、使い勝手が悪いために他のアプリケーションよりも操作時間を掛けざるを得ないアプリケーションに対して多くの利用料金が支払われることにもなりかねない。

また、診断に役立つ医療画像を生成するアプリケーションとは、最終的に当該アプリケーションを利用したユーザが属する、例えば、医療機関の収益に貢献するアプリケーションであるとも言える。ユーザからすれば、このようなアプリケーションを提供した提供者（以下、「アプリ提供者」と表わす）に対してより適切な利用料金を支払うことに対しては異論も少なく、今後のより上質で使い勝手の良いアプリケーションの提供を促す点でも好ましいと考えられる。

本発明は上記課題を解決するためになされたものであり、本発明の目的は、ユーザのアプリケーションの利用態様を基に、さらに当該アプリケーションの診断等に対する有効度を勘案して料金算出を行うことで、利用されたアプリケーションに対する公平な課金、アプリ提供者の開発意欲の向上、及びシステム運営者による魅力的なシステム運営を図ることが可能な医療情報システム及び当該医療情報システムを利用した課金方法を提供することにある。

請求項１に記載の発明の特徴は、医療情報システムにおいて、ユーザが使用するクライアント端末と、ユーザが医療画像診断装置によって取得された患者の内部情報を示す医療画像を基に診断を行う際に利用する医療画像の処理を行うアプリケーションを備えるアプリケーションサーバと、ユーザが診断を行うに当たって、その判断に有効な医療画像の生成、表示を行ったアプリケーションを提供したアプリ提供者に対して、医療画像の有効度、医療画像に対して行った処理の有効度に応じた利用金額を算出するテナント型医療情報システムとを備える。

請求項９に記載の発明の特徴は、医療情報システムを利用した課金方法において、ユーザが検査レポートの作成を行うに当たって使用する医療画像をアプリケーションを利用して生成、表示させるステップと、生成、表示された医療画像に対して、ユーザの要求に応じて処理を行うステップと、生成、表示、処理に利用されたアプリケーションに対するユーザによる操作履歴を解析し、生成、表示、処理に対してそれぞれ定められている課金情報をアプリケーションごとに取得するステップと、課金情報を基にアプリケーションごとの診断有効度を判断するステップと、診断有効度を基にアプリケーションを提供するアプリ提供者に対して支払う利用金額を算出するステップとを備える。

本発明の実施の形態における医療情報システムの全体構成を示すブロック図である。 本発明の実施の形態におけるテナント型医療情報システムの内部構成を示すブロック図である。 本発明の実施の形態におけるアプリサーバの内部構成を示すブロック図である。 本発明の実施の形態における統合ビューアの内部構成を示すブロック図である。 本発明の実施の形態における課金エンジンの内部構成を示すブロック図である。 本発明の実施の形態における検査レポートの作成の大まかな流れを示すフローチャートである。 本発明の実施の形態における検査レポートの作成の大まかな流れを示すフローチャートである。 本発明の実施の形態における医療画像の生成に関する課金の流れを示すフローチャートである。 本発明の実施の形態における課金について、設定データベース内に格納される課金情報に関するテーブルの一例を示す説明図である。 本発明の実施の形態における医療画像に対する処理に関する課金の流れを示すフローチャートである。 本発明の実施の形態において医療画像の生成が行われ、検査レポートに貼付された場合に関する課金の流れを示すフローチャートである。 本発明の実施の形態において医療画像の生成が行われ、検査レポートに貼付された場合に関する課金についてのテーブルの一例を示す説明図である。 本発明の実施の形態における医療画像の表示が行われた場合における課金の流れを示すフローチャートである。 本発明の実施の形態において医療画像の表示が行われた場合に関する課金についてのテーブルの一例を示す説明図である。 本発明の実施の形態における医療画像の生成に関する課金に関して、診療報酬等を加味した課金方法を説明するためのテーブルの一例を示す説明図である。 本発明の実施の形態における医療画像に対する処理に関する課金に関して、診療報酬等を加味した課金方法を説明するためのテーブルの一例を示す説明図である。

以下、本発明の実施の形態について図面を参照して詳細に説明する。
［医療情報システムの全体構成］
図１は、本発明の実施の形態における医療情報システムＳの全体構成を示すブロック図である。医療情報システムＳは、ユーザが使用するクライアント端末１と、システム運営者が設置し、通信ネットワークＮを介してクライアント端末１から送信されるユーザからの検査レポートの作成要求に基づいて必要な医療情報を収集、加工し、検査レポートの作成、保存等を行うテナント型医療情報システム２と、テナント型医療情報システム２と通信ネットワークＮを介して接続され、アプリ提供者によって提供されるアプリケーションを備えるアプリケーションサーバ３（以下、明細書における表記及び図面の表記として「アプリサーバ３」と表わす）とを備える。

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

クライアント端末１は、ユーザである、医師、或いは、技師によって使用される情報端末である。このクライアント端末１としては、例えば、ＰＣ（パーソナルコンピュータ）や、ＷＳ（診療ワークステーション）等が考えられる。また、クライアント端末１が携帯可能であることを否定するものではない。

さらに、クライアント端末１は、少なくともユーザの操作を受け付ける入力部と、各種処理を行うＣＰＵを備える処理部と、作成される検査レポート、その他の処理内容やユーザの要求に基づいてテナント型医療情報システム２によって収集された医療情報等を表示する表示部を備えている。

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

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

また、ユーザ自ら医療情報の収集を行う場合には、多くの場合、どうしても自らの思考（嗜好）に合った特定のアプリケーションを利用しがちであり、特に、新規なアプリケーションについては利用されにくいのが現状である。但し、本発明の実施の形態におけるテナント型医療情報システム２を利用することで、新規なアプリケーションを利用して作成され登録されている検査レポートを参照すること等が可能となるため、当該新規なアプリケーションであっても安心して利用することができる。併せて、特定のアプリケーションにその利用が集中することなく、適宜適切なアプリケーションが選択され、当該選択されたアプリケーションによる処理がなされた医療画像を取得することができる。

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

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

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

なお、本体部２Ａの各部の内部構成、機能や働きについては、以下、ユーザが検査レポートを作成する流れに沿って別途説明する。また、テナント型医療情報システム２の統合ビューア２１の詳細な内部構成についても後述する。

画像管理部２Ｂを構成する画像情報マネージャ２８は、医療画像診断装置４によって取得される医療画像に関する情報を管理する。一方、画像レポートデータベース２９は、画像情報マネージャ２８を介して医療画像診断装置４から送られてきた医療画像を記憶する。また、アプリサーバ３に記憶されているアプリケーションを利用して加工、生成される医療画像についても記憶することとしても良い。

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

アプリサーバ３は、アプリ提供者が提供するアプリケーションを記憶している。併せて、必要とされるアプリケーションを販売したり、ユーザによる検査レポートの作成要求に従って必要とされる医療画像を生成する。

より詳細には、ユーザがクライアント端末１を介してレポート作成要求をテナント型医療情報システム２に送信されることで検査レポートの作成が開始される。そしてユーザによって作成される検査レポートに貼付する医療画像の生成、或いは、処理に当たって利用されるアプリケーションが選択され、当該アプリケーションを備えるアプリサーバ３に対して、医療画像の生成、処理が依頼される。アプリサーバ３では要求に応じて医療画像を加工、生成し、改めてテナント型医療情報システム２に送信する。アプリサーバ３から生成された医療画像を受信したテナント型医療情報システム２では、この医療画像と検査レポートとを当該要求を出したユーザのクライアント端末１にまとめて（統合して）表示させる。

或いは、ユーザによって必要なアプリケーションが選択された場合に、当該アプリケーションの入手（購入）が行われる場合もある。この場合には、当該アプリケーションを備えるアプリサーバ３からアプリケーションがダウンロードされ、テナント型医療情報システム２にインストールされる。なお、アプリケーションのインストール先は、テナント型医療情報システム２に限らず、例えば、クライアント端末１、或いは、医療画像診断装置４であっても良い。

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

シンクライアントエンジン３１は、シンクライアントマネージャ２４から送信されたアプリケーションに関する情報を受信する。その上でアプリケーション３２の制御を行う。また、シンクライアントマネージャ２４から送信された医療画像に関する情報は、画像データベース３３に格納される。アプリケーション３２は、シンクライアントエンジン３１の制御の下、画像データベース３３に格納された医療画像に関する情報を基にユーザが検査レポートを作成する際に必要とする医療画像の生成、処理をする。

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

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

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

管理サーバ５は、例えば、医療機関内に構築されている、例えば、病院情報管理システム（ＨＩＳ：Hospital Information System）、放射線部門情報管理システム（ＲＩＳ：Radiological Information System）、医用画像管理システム（ＰＡＣＳ：Picture Archiving Communication System）等が該当する。なお、管理サーバ５に入力された各種情報は、併せてテナント型医療情報システム２にも送られ、ユーザからの要求に対処する際に用いられる。また、テナント型医療情報システム２が、ＨＩＳ、ＲＩＳ、ＰＡＣＳの機能の一部として存在してもよい
なお、図１に示す医療情報システムＳでは、通信ネットワークＮに２つのクライアント端末１Ａと１Ｂ（以下、適宜これら複数のクライアント端末をまとめて「クライアント端末１」と表わす。）、アプリサーバ３Ａ及び３Ｂ（以下、適宜これらのアプリサーバをまとめて「アプリサーバ３」と表わす。）が接続されているが、通信ネットワークＮに接続されるクライアント端末１、或いは、アプリサーバ３の数は単数、或いは複数のいずれでも良く、その数は任意である。 また、医療画像診断装置４は、図１では１つのみ通信ネットワークＮに接続されているが、この医療画像診断装置４の数についても任意である。

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

通信ネットワークＮの例としては、ＬＡＮ（Local Area Network）やインターネット等の通信ネットワークを挙げることができる。また、この通信ネットワークＮで使用される通信規格は、ＤＩＣＯＭ（Digital Imaging and Communication in Medicine）等、いずれの規格であっても良い。
［テナント型医療情報システム（本体部）の構成］
上述したように、テナント型医療情報システム２の本体部２Ａは、統合ビューア２１と、ワークフローマネージャ２２と、設定データベース２３と、シンクライアントマネージャ２４と、アプリケーション２５（アプリケーションＡ）と、課金エンジン２６と、課金データベース２７とから構成されている。

統合ビューア２１は、ユーザからの検査レポート作成の要求があった場合に、過去作成された検査レポートを参照するためにワークフローマネージャ２２を介して設定データベース２２に登録されている検査レポートを検索する。併せて、検査レポートの対象となる医療画像の加工、生成を行うためのアプリケーションを入手、或いは、その利用を図り、作成された検査レポートの文章と医療画像との統合を図る。その上で、ユーザが使用するクライアント端末１に作成された検査レポートを表示させる。

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

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

なお、統合ビューア２１を構成する各部の働き、機能については、別途検査レポートの作成を行う流れを説明する中で併せて説明する。

図２に示すワークフローマネージャ２２は、ユーザからの要求に応じて（統合ビューア２１から送信された情報に基づいて）、ユーザが必要としている医療情報の生成を行う上で適切なアプリケーションを選択する。また、ユーザによって検査レポートが作成される際に起動され、対象となる医療画像等を基に検査レポートの作成を司る。

ワークフローマネージャ２２には、設定データベース２３が接続されている。設定データベース２３内には、テナント型医療情報システム２に接続されているアプリサーバ３にて提供されているアプリケーションに関する情報が記憶されている。そこで、ワークフローマネージャ２２が適切なアプリケーションを選択する際には、設定データベース２３を検索して該当するアプリケーションに関する情報を取得する。また、設定データベース２３には、ユーザによって作成された検査レポートも登録されている。

シンクライアントマネージャ２４は、図１に示すアプリサーバ３に通信ネットワークＮを介して接続されている。ユーザが検査レポート作成に当たって必要とする医療画像の生成、処理を行うためのアプリケーションを入手してユーザが利用することができるようにテナント型医療情報システム２に取り込む。

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

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

図２に示すように、テナント型医療情報システム２には、アプリサーバ３が接続されている。上述したように、いくつのアプリサーバ３がテナント型医療情報システム２に接続されるかは、医療情報システムＳにアプリケーションを提供するアプリ提供者の数、或いは、提供されるアプリケーションの数によって増減する。図２においては、アプリケーションＢを提供するアプリサーバ３ＡとアプリケーションＣを提供するアプリサーバ３Ｂとがテナント型医療情報システム２に接続されている。

課金エンジン２６は、ユーザがテナント型医療情報システム２、或いは、アプリサーバ３に記憶されているアプリケーションを利用した際の利用料金等を算出する。課金エンジン２６に接続されている課金データベース２７は、ユーザの利用料金等の算出を行う際に基礎となる料金に関する情報が記憶されている。

図５は、本発明の実施の形態における課金エンジン２６の内部構成を示すブロック図である。課金エンジン２６は、まず情報を受信する受信部２６ａと、利用アプリ確認部２６ｂと、操作履歴収集部２６ｃと、操作履歴解析部２６ｄと、判断部２６ｅと、料金算出部２６ｆと、算出された料金に関する情報をユーザのクライアント端末１に向けて送信する送信部２６ｇとから構成される。

また、利用アプリの利用金額を算出するに当たって、課金データベース２７に格納されている各種情報を利用する。そのため、料金算出部２６ｆは、必要に応じて課金データベース２７にアクセスして情報を入手する。また、判断部２６ｅは設定データベース２３と接続されており、適宜必要な情報を当該設定データベース２３から取得する。

利用アプリ確認部２６ｂは、課金の前提となるユーザによって利用されたアプリケーションを確認する。操作履歴収集部２６ｃは、確認された該アプリケーションを利用した際のユーザの操作履歴（ログ）を収集し、操作履歴解析部２６ｄは、収集された操作履歴を解析する。また、判断部２６ｅは、操作履歴解析部２６ｄによって解析されたユーザの操作履歴を基に、利用されたアプリケーションにより生成、処理された医療画像、或いは、医療画像に対して行われた処理によって、ユーザが行う診断に対してどれだけ有効であったか、診断有効度を判断する。その上で、料金算出部２６ｆが判断部２６ｅによって判断された診断有効度を基準にアプリ提供者に対して支払う利用金額を算出する。
［ユーザによる検査レポートの作成の流れ］
次に、検査レポートの作成の流れについて、特に課金の工程に重点を置いて説明を行う。すなわち、検査レポートが作成されて表示されるまでには、検査レポートの作成対象となる患者の基本的な情報の収集、検査レポートの作成、検査レポートの作成に当たって利用されたアプリケーションに対する課金、そして、作成された検査レポートの表示、との流れを辿ることになる。このうち以下の説明においては、課金の前提となる検査レポートの作成及び当該検査レポートに生成された医療画像を貼付する場合、或いは、診断のために医療画像を表示させる場合にスポットを当てて説明する。

図６、図７は、本発明の実施の形態における検査レポートの作成の大まかな流れを示すフローチャートである。

まず、ユーザが検査レポートの作成を行うに当たっては、まずユーザによって医療情報システムＳが起動される。そこで、ユーザが使用するクライアント端末１から送信される要求は、統合ビューア２１内の受信部２１ａで受信される（ＳＴ１）。

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

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

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

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

設定データベース２３内には、テナント型医療情報システム２に通信ネットワークＮを介して接続されている、アプリ提供者の提供によるアプリケーションに関する情報が記憶されている。記憶されている内容は、例えば、アプリケーション識別情報、アプリケーション名、アプリケーション分類、アプリケーション機能、アプリケーション特性、アプリケーション提供者識別情報、アプリケーション起動方法等である。

以上は、アプリケーションに関する情報そのものであるが、その他に、統合ビューア２１においてアプリケーションをどのように配置するかに関する情報（表示レイアウト情報）も記憶されている。

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

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

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

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

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

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

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

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

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

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

ワークフローマネージャ２２から情報を受信した統合ビューア２１は、まず受信した情報を「アプリケーションに関する情報」と「表示レイアウトに関する情報」とに分ける。このうち「表示レイアウトに関する情報」は、文章や医療画像等の医療情報等を検査レポートとして構成する際に利用される情報である。従って、当該表示レイアウトに関する情報はより分けて、各種医療情報等が揃うまで保持しておく（ＳＴ７）。

一方、「アプリケーションに関する情報」については、ユーザが必要とする医療情報を生成するために利用を予定するアプリケーションについての情報である。そこで、当該情報を基に、例えば、アプリケーションＡ（アプリケーション２５）を介して画像レポートデータベース２９から基となる医療画像を抽出することになる。

但し、全ての場合に新たに医療画像の生成が行われるわけではない。検査レポートの作成に当たって当該検査レポートに貼付する医療画像を生成する場合の他、例えば、作成する検査レポートには貼付しないものの、患者を診断する上で必要な、或いは、参考にする医療画像もあり、当該医療画像は、表示のみで足りる場合も考えられる。

そこで、統合ビューア２１は、検査レポートの作成に当たって医療画像の生成が行われるか否かを判断し（ＳＴ８）、医療画像の生成を行う場合と（ＳＴ９）、医療画像の生成は行わないが表示を行う場合（ＳＴ１０）とに分ける。
［医療画像の生成、処理に対する課金の流れ］
そこで、次に検査レポートの作成中に医療画像を生成した場合、或いは、医療画像を表示させた場合のそれぞれにおける課金の流れについて説明する。まずは検査レポートの作成中に医療画像を生成した場合についてである。

図８は、本発明の実施の形態における医療画像の生成に関する課金の流れを示すフローチャートである。

まず、統合ビューア２１によって、検査レポートの作成に当たってユーザが医療画像の生成を行うと判断した場合（ＳＴ８のＹＥＳ）、上述したように医療画像の生成が開始される（ＳＴ９）。併せて課金エンジン２６は、受信部２６ａにおいてユーザからの医療画像の生成要求を受信する（図８のＳＴ２１）。

もちろん統合ビューア２１も当該生成要求を受信し、ユーザの要求に基づいてアプリケーションを利用してユーザが求める医療画像を生成する処理を行うことになる。但しここでは、ユーザが検査レポートを作成する上で利用したアプリケーションがユーザによる診断にどれだけ貢献したかを判断し、当該判断を基に課金することで、より適切な利用料金をアプリ提供者に配分するものである。従って、統合ビューア２１が医療画像の生成要求を受信するのに併せて、課金エンジン２６においても当該要求を把握して課金の処理をスタートさせる。

なお、このように統合ビューア２１が医療画像の生成要求を受信すると同時に課金エンジン２６においても課金の処理をスタートさせるように設定しても良いが、例えば、実際に医療画像の生成が終了し、統合ビューア２１が「表示レイアウトに関する情報」に基づいて統合する段階に至って全ての課金の処理をスタートさせる設定としても良い。この場合、医療画像の生成、処理に関するユーザの要求（操作の内容）を全てログとして保存しておき、当該ログを解析することによって、課金を行うことになる。

ユーザは医療画像を生成するために、何らかのアプリケーションを選択し、利用する。利用アプリ確認部２６ｂでは、ユーザが医療画像を生成するべく選択されたアプリケーションがどのようなアプリケーションであるかを把握する（ＳＴ２２）。

次に、課金エンジン２６の操作履歴解析部２６ｄは、選択されたアプリケーションがユーザによって起動されたか否かを確認する（ＳＴ２３）。起動されたか否かの確認は、ユーザによる起動要求がログとして把握されるか否かである。もちろん、統合ビューア２１において選択されたアプリケーションの起動の有無を確認して、その結果を課金エンジン２６に対して送信しても良い。

操作履歴解析部２６ｄにおいて選択されたアプリケーションが起動されたことが確認された場合には（ＳＴ２３のＹＥＳ）、その情報が判断部２６ｅへと送信され、判断部２６ｅは、当該アプリケーションが起動されたことに関する課金情報を把握する（ＳＴ２４）。ここで「課金情報」とは、アプリケーションの利用に応じた課金を行うべく課金金額を算出する際に用いる情報のことである。

図９は、本発明の実施の形態における医療画像の生成に関する課金について、設定データベース２３内に格納される課金情報に関するテーブルの一例を示す説明図である。なお、ここでは課金情報に関する図９に示すようなテーブルは設定データベース２３内に格納されていることを前提とするが、もちろん課金データベース２７内に格納されていても良い。

図９の説明図に示されているテーブルの上欄には、「起動」から始まり、「画像生成」、「画像貼付」、「表示」、「観察時間」、「コマンド発行数」、「診断有効度」、「課金金額」と８つの項目が示されている。

そして、これら８つの項目ごとに課金金額を算出するに利用される数字（点数）が示されている。この数字（点数）の意味するところは各項目ごとに異なるが、例えば、「起動」、「画像生成」、「画像貼付」、「表示」の４つの項目については、事前に付与される点数が示されている。当然各項目ごとに付与される点数は事前に自由に設定することが可能である。

一方、「観察時間」や「コマンド発行数」については、「起動」等の項目のように事前に所定の点数を定めておくことが困難である。これは、「観察時間」はユーザによって、或いは、観察される医療画像によって異なるからであり、「コマンド発行数」についても同様である。そのため基本的に、「観察時間」については時間、「コマンド発行数」については発行されたコマンドの数が計測されることになる。これら計測された値を点数化することで最終的に判断される「診断有効度」を点数で表わすことが可能となる。

なお、図９に示す説明図においては、これら「観察時間」、「コマンド発行数」について、例えば、「観察時間」については「２」、「コマンド発行数」については「５」と計数が設定されている。このように、予め係数を定めておき、それぞれの値に乗ずることで各項目の点数（課金情報）とすることもできる。もちろん、係数を設定することなく単純に「観察時間」、或いは、「発行されたコマンド数」を課金情報として使用しても良い。

「診断有効度」の項目については、「診断有効度」の項目よりも左側に示されている項目ごとに示される点数を合計することで点数が算出されることになるため、図９に示す説明図においては単に「点数」とのみ示されている。なお、「診断有効度」を算出する際に、各項目ごとの点数等を合計するのではなく、例えば、乗算することによって算出することとしても良い。

ここで「診断有効度」とは、当該アプリケーションを使用して生成される医療画像等の医療情報が、ユーザが診断を行う際にどれだけ有効な情報であるかを表わす指標である。つまりユーザによって、例えば、起動や観察等が行われる度に課金情報として累積され、その合計点が当該診断有効度となる。もちろん、図９の説明図に示すような各種課金情報の他、例えば、アプリケーションを利用したユーザからの評価を基に、アプリケーションごとに設定された値を加味しても良い。

以上、図９に示されている説明図に基づけば、例えば、上述したように、ステップＳＴ２４において課金エンジン２６が把握する「起動」に関する課金情報は、「１０点」となる。

さらに操作履歴収集部２６ｃにおいて、当該起動されたアプリケーションを利用してユーザにより医療画像の生成が行われたか否かが確認される（ＳＴ２５）。上述したように、医療画像の生成が行われたか否かの確認は、ユーザによる医療画像の生成要求がログとして把握されるか否かである。

ここで、医療画像の生成の有無が確認されるのは、ユーザによっては、選択したアプリケーションの起動を行ったものの当該アプリケーションを利用して医療画像の生成を行わない場合も考えられるからである。このような判断を行うことによって、医療画像の生成まで行ったアプリケーションと、起動はされたものの医療画像の生成には使用されなかったアプリケーションとを区別することができる。そして当該区別ができれば、アプリケーションの診断への貢献を判断する上でより適切な判断を行うことができる。基本的には起動はされたものの医療画像の生成には使用されなかったアプリケーションよりも医療画像の生成まで行ったアプリケーションの方がユーザの診断における貢献度（有効度）が高いと考えられる。

操作履歴収集部２６ｃにおいて把握されるログを基に、操作履歴解析部２６ｄによってユーザにより医療画像の生成が行われたことが解析された場合は（ＳＴ２５のＹＥＳ）、判断部２６ｅにその情報が送られる。判断部２６ｅでは設定データベース２３にアクセスし、「医療画像の生成」に利用されたアプリケーションに関する課金情報を把握する（ＳＴ２６）。図９に示す課金情報に関するテーブルを参照すると、アプリケーションを利用して医療画像の生成を行うと、「３５点」が付与されることになる。

この状態で、検査レポートを生成する上で必要な医療情報の１つである医療画像が生成されたことになる。そこで判断部２６ｅでは、これまで把握された課金情報を集計し保持しておく（ＳＴ２７）。例えば、医療画像を生成するに当たって利用するアプリケーションが起動され、当該アプリケーションが利用されてユーザによって医療画像が生成された場合には、課金情報として４５点が付与されることになる（図９参照）。

なお、上述したように判断部２６ｅでは、ユーザによって利用されるアプリケーションごとの課金情報を取得、保持する。この課金情報の取得、保持にあたっては、例えば、アプリケーションが起動されたことをトリガーとして判断部２６ｅ内にテーブルが作成されることで保持しても良い。或いは、利用アプリ確認部２６ｂにおいて、ユーザによって利用されるアプリケーションが確認された時に、既に例えば、設定データベース２３内に設けられている当該利用が確認されたアプリケーションに関するテーブルを判断部２６ｅにおいて取得し、課金情報が取得される度に当該テーブルに課金情報を入力して保持することとしても良い。

一方、ユーザによってアプリケーションが起動されたものの（ＳＴ２３のＹＥＳ）、医療画像の生成が行われなかった場合には（ＳＴ２５のＮＯ）、起動に関する課金情報のみ把握され医療画像の生成に関する課金情報は把握されないことから、当該アプリケーションに対しては「１０点」のみ課金情報が付与される。一方、ユーザによって起動すら行われないアプリケーションについては（ＳＴ２３のＮＯ）、課金情報として有効な値を取得することができないため、「０点」となる。

次に、医療画像が生成されず（図６のＳＴ８のＮＯ）医療画像が表示される場合について説明する。図１０は、本発明の実施の形態における医療画像に対する処理に関する課金の流れを示すフローチャートである。

まず、統合ビューア２１が、検査レポートの作成に当たってユーザによって医療画像に関する処理が行われるものの、当該処理が医療画像の生成ではなく医療画像の表示であると判断した場合（ＳＴ８のＮＯ）、医療画像の表示が開始される（ＳＴ１０）。併せて課金エンジン２６は、受信部２６ａにおいてユーザからの医療画像の表示要求を受信する（図１０のＳＴ３１）。

なお、表示のみの場合には、例えば、実際に医療画像の生成が終了し、統合ビューア２１が「表示レイアウトに関する情報」に基づいて統合する段階に至って全ての課金の処理をスタートさせる設定としても良い。

ユーザは医療画像を表示するために、何らかのアプリケーションを選択し、利用する。利用アプリ確認部２６ｂでは、ユーザが医療画像を表示するべく選択されたアプリケーションがどのようなアプリケーションであるかを把握する（ＳＴ３２）。

次に、課金エンジン２６の操作履歴解析部２６ｄは、選択されたアプリケーションがユーザによって起動されたか否かを確認する（ＳＴ３３）。起動されたか否かの確認は、ユーザによる起動要求がログとして把握されるか否かである。もちろん、統合ビューア２１において選択されたアプリケーションの起動の有無を確認して、その結果を課金エンジン２６に対して送信しても良い。

操作履歴解析部２６ｄにおいて選択されたアプリケーションが起動されたことが確認された場合には（ＳＴ３３のＹＥＳ）、その情報が判断部２６ｅへと送信され、判断部２６ｅは、当該アプリケーションが起動されたことに関する課金情報を設定データベース２３から把握する（ＳＴ３４）。

図９に示される本発明の実施の形態における医療画像の生成に関する課金について、設定データベース２３内に格納される課金情報に関するテーブルの一例を示す説明図によれば、課金情報としての「表示」に対しては、例えば「３０点」が付与される。もちろん上述したように、当該「表示」に関する課金情報として付与される点数は任意に設定することができる。

従って、例えば、上述したように、ステップＳＴ３４において課金エンジン２６が把握した「起動」に関する課金情報は、「１０点」となる。

さらに操作履歴収集部２６ｃにおいて、当該起動されたアプリケーションを利用してユーザにより医療画像の表示が行われたか否かが確認される（ＳＴ３５）。表示されたか否かの確認は、ユーザによる表示要求がログとして把握されるか否かである。

ここで、医療画像の表示の有無が確認されるのは、ユーザによっては、選択したアプリケーションの起動を行ったものの当該アプリケーションを利用して医療画像の表示を行わない場合も考えられるからである。このような判断を行うことによって、医療画像の表示まで行ったアプリケーションと、起動はされたものの医療画像の表示には使用されなかったアプリケーションとを区別することができる。そして当該区別ができれば、アプリケーションの診断への貢献を判断する上でより適切な判断を行うことができる。なお、多くの場合、起動はされたものの医療画像の表示には使用されなかったアプリケーションよりも医療画像の表示まで行ったアプリケーションの方がユーザの診断における貢献度（有効度）が高いと考えられる。

操作履歴解析部２６ｄによってユーザにより医療画像の表示が行われたことが解析された場合は（ＳＴ３５のＹＥＳ）、判断部２６ｅにその情報が送られ、「医療画像の表示」に利用されたアプリケーションに関する課金情報を把握する（ＳＴ３６）。

この状態で、検査レポートを生成する上で必要な医療情報の１つである医療画像が表示されたことになる。そこで判断部２６ｅでは、これまで把握された課金情報を集計し保持しておく（ＳＴ３７）。例えば、医療画像を表示するに当たって利用するアプリケーションが起動され、当該アプリケーションが利用されてユーザによって医療画像が表示された場合には、課金情報として４０点が付与されることになる（図９参照）。

なお、ユーザによってアプリケーションが起動されたものの（ＳＴ３３のＹＥＳ）、医療画像の表示が行われなかった場合には（ＳＴ３５のＮＯ）、起動に関する課金情報のみ把握され医療画像の表示に関する課金情報は把握されないことから、当該アプリケーションに対しては、上述したように「１０点」のみ付与される。一方、ユーザによって起動すら行われないアプリケーションについては（ＳＴ３３のＮＯ）、課金情報として有効な値を取得することができないため、「０点」となる。

このようにして統合ビューア２１はユーザの指示に従い検査レポートに貼付する医療画像を生成し、或いは、表示を行う。併せて、統合ビューア２１は、ユーザが表示させた医療画像を見て診断を行い、その結果を入力することで作成した文章を検査レポートに記載する。

その上で統合ビューア２１は、ユーザが検査レポートに表示させるために様々要求した医療情報が全て揃ったかを確認する（図７のＳＴ１１を参照）。すなわち統合ビューア２１は、検査レポートを構成する各パーツが適切に準備されているかを確認し（ＳＴ１２）、何れかの医療情報が欠けて結果として全ての医療情報が揃っていない場合には（ＳＴ１２のＮＯ）、足りない医療情報が生成等されるのを待つ。

一方で検査レポートを作成する上でユーザが必要と考える医療情報が全て揃った場合には（ＳＴ１２のＹＥＳ）、検査レポートとして成立するように保存していた「表示レイアウトに関する情報」を利用して統合する（ＳＴ１３）。その上で、統合されて作成された検査レポートを表示部に表示させる（ＳＴ１４）。統合ビューア２１によるこのような処理が行われることによって、ユーザは検査レポートを完成させることができる。

但し、医療情報システムＳにおいて、ユーザが利用したアプリケーションごとに課金を行う処理はまだこれからである。すなわち、統合ビューア２１によって生成された医療画像や記入された文章が統合されて１つの検査レポートとして作成が終了しても医療画像の生成後に行われた処理等に冠する課金処理が残っている。

そこで、検査レポートとして統合された画面が表示された後に（ＳＴ１４）、課金エンジン２６の操作履歴収集部２６ｃ、操作履歴解析部２６ｄを介して、判断部２６ｅにおいて生成された医療画像が検査レポートに貼付されたか否かが把握される（ＳＴ１５）。

その結果、医療画像の貼付が行われた場合には（ＳＴ１５のＹＥＳ）、医療画像の貼付後の課金処理が課金エンジン２６において行われる（ＳＴ１６）。一方、医療画像の貼付がない場合には（ＳＴ１５のＮＯ）、医療画像が表示された後の課金処理が課金エンジン２６において行われる（ＳＴ１７）。以下、両者の場合に分けて説明する。

図１１は、医療画像の生成が行われ、ユーザによって検査レポートに貼付された場合に関する課金の流れを示すフローチャートである。判断部２６ｅは、検査レポートに生成された医療画像が貼付されたことに関して、課金情報を把握する（ＳＴ４１）。図９に示す設定データベース２３内に格納される課金情報に関するテーブルの一例を示す説明図によれば、課金情報としての「画像貼付」に対しては、例えば「５０点」が付与される。

通常ユーザは、統合ビューア２１によって統合された検査レポートに貼付した医療画像を観察して診断等を行う。そこで課金エンジン２６では、操作履歴収集部２６ｃ及び操作履歴解析部２６ｄにおいて解析されるログを基に、ユーザによる貼付された医療画像の観察時間を把握する（ＳＴ４２）。判断部２６ｅでは把握された観察時間に関する情報を取得し、観察時間に所定の係数を乗ずる（ＳＴ４３）。図９に示す説明図においては、上述したように、「観察時間」に係数２を乗ずることが設定されている。そして係数を乗ずることによって把握される観察時間に関する課金情報を取得、保持する。

ユーザは検査レポートに貼付した医療画像を基に診断を行うに当たって、単に当該医療画像を観察するだけではなく、例えば、当該医療画像を利用して様々な処理を行うことが考えられる。ここで「処理」とは、例えば、医療画像の回転、拡大、縮小、或いは、計測といったユーザの行為を示している。生成された医療画像を用いて様々な処理を行うことによって、ユーザはより適切な診断を行うことができる。

そこで操作履歴収集部２６ｃ及び操作履歴解析部２６ｄはユーザによる処理が行われたか否かを判断し（ＳＴ４４）、何らかの処理が行われた場合には（ＳＴ４４のＹＥＳ）、貼付された医療画像に対する処理の数を把握する（ＳＴ４５）。実際には、ユーザによってなされる回転要求といった、コマンドの数を基に処理の数を把握する。

把握されたコマンド数に関する情報は、判断部２６ｅへと送られる。判断部２６ｅでは取得したコマンド数に関する情報を基に係数を乗じてコマンド発行数に関する課金情報を取得、保持する（ＳＴ４６）。ここで設定されている係数は、図９に示す説明図によれば「５」であり、コマンド数に係数５を乗じてコマンド発行数とする。

一方、貼付された医療画像に対する処理が行われなかった場合には（ＳＴ４４のＮＯ）、コマンド発行数は「０」であり、この課金情報は取得されない。

なお、処理の数を把握するに当たっては、コマンドが発行される都度、操作履歴収集部２６ｃ及び操作履歴解析部２６ｄにおいてログを解析して把握しても良く、或いは、ユーザによるコマンドの発行が終了したことを確認した上で、それまでに発行されたコマンドの数を把握するようにしても良い。

以上でユーザは検査レポートに貼付された医療画像を用いた観察、処理を終了すると考えられる。そこで判断部２６ｅでは、これまで取得、保持してきた課金情報を集計して、「診断有効度」を把握する（ＳＴ４７）。課金情報の集計に当たっては、例えば、「起動」や「画像生成」といった既に判断部２６ｅにおいて保持されている全ての課金情報も併せて集計される。このような処理によって、ユーザに利用されるアプリケーションに関する課金処理が開始された後に把握されるユーザの行為に起因する全ての課金情報を漏れなく集計することができる。

判断部２６ｅにおいて該当するアプリケーションに関する診断有効度が把握されると、当該診断有効度の情報が料金算出部２６ｆへと送られる。料金算出部２６ｆでは、受信した診断有効度に基づいて課金データベース２７に格納されている、例えば金額表を基に、金額を把握する（ＳＴ４８）。この金額が当該アプリケーションの利用に応じた課金の金額として算出されることになる（ＳＴ４９）。

以上説明した、検査レポートに医療画像が貼付された場合の課金の流れについて、実際の課金情報を利用して説明する。

図１２は、本発明の実施の形態において医療画像の生成が行われ、検査レポートに貼付された場合に関する課金についてのテーブルの一例を示す説明図である。なお、図１２の説明図に示されているテーブルについては、判断部２６ｅ内、設定データベース２３内、或いは、課金データベース２７内のいずれの場所に記憶されていても良い。

図１２に示すテーブルの最上段には、アプリケーション名を示す「アプリケーション」という項目と、様々な課金情報の項目、これら課金情報を基に判断部２６ｅにおいて把握される「診断有効度」、及び当該診断有効度を基に料金算出部２６ｆにおいて算出される「課金金額」の項目名がそれぞれ示されている。

図１２のテーブルには、アプリケーションとしてアプリケーションＡないしアプリケーションＤまで４つのアプリケーションが示されている。

このうちアプリケーションＡないしアプリケーションＣは、少なくともユーザにより起動がされ、最終的に料金算出部２６ｆにおいて課金の金額が算出されている。一方、アプリケーションＤは、課金情報としての「起動」の項目について点数が付与されていないことから、アプリケーションＤは医療情報システムＳには登録されているアプリケーションであるものの、今回ユーザは当該アプリケーションＤを利用する意図はなく起動されていないことを示している。このアプリケーションＤのように、起動も行われないアプリケーションについては、アプリケーションの利用がなくユーザが行う診断に対して何らか寄与する医療情報を提供することはないため、診断有効度も「０」であり、従って課金金額も「０」となる。

アプリケーションＡについては、起動され（１０点）、当該アプリケーションＡを利用してユーザによって医療画像の生成が行われている（３５点）。その上、作成された検査レポートに貼付されているので、さらに「画像貼付」に関する課金情報が「５０点」付与されている。

貼付された医療画像は、観察され、コマンドも発行されている。このうち、「観察時間」については、図９に示す課金情報に関するテーブルの一例を示す説明図では、ユーザによる観察時間に係数「２」を乗じて取得された値を点数としている。従って、アプリケーションＡの「観察時間」として「２０点」が付与されている、ということは、ユーザによるアプリケーションＡによって生成され表示された医療画像の観察時間は１０分であることが把握できる。

同じように、「コマンド発行数」については、コマンド数に係数「５」が乗じられることで算出される。従って、ここでは「コマンド発行数」として「２５点」が付与されていることを考えると、ユーザは表示されている医療画像に対して５つの処理を行ったことになる。

その結果、アプリケーションＡに対して判断部２６ｅが取得した「診断有効度」は、「１４０点」となる。ここでは、各課金情報において付与された点数を加算することで診断有効度を算出しているが、例えば、各課金情報を乗じたりすることで算出することも可能であり、診断有効度をどのように算出するかは任意に設定することが可能である。

判断部２６ｅにおいて「診断有効度」が「１４０点」と把握されたので、料金算出部２６ｆにおいては、「課金金額」として「１４０００円」を算出する。上述したように、料金算出部２６ｆでは、課金データベース２７に予め設定されている診断有効度と実際に算出される金額との関係を示すテーブルに基づいて課金金額を算出する。ここでは、把握された診断有効度に１００を乗ずることで課金金額とされる。

なお、診断有効度と実際に算出される金額との関係については、任意に設定することが可能である。上述したように把握された「診断有効度」にある値を乗ずることで課金金額とすることの他、例えば、「診断有効度」と「課金金額」とが複数対１の関係、つまり有効度に幅を持たせるように課金金額が定められていても良い。

次にアプリケーションＢについてである。アプリケーションＢも「起動」、「画像生成」、「画像貼付」のそれぞれの課金情報は、アプリケーションＡと同様である。つまり、起動されたアプリケーションＢを利用して医療画像の生成が行われ、検査レポートに生成された当該医療画像が貼付されている。但し、観察時間と発行されたコマンド数がアプリケーションＡと異なる。すなわち、アプリケーションＡを利用して生成された医療画像（以下、便宜上「医療画像Ａ」と表わす。）よりもアプリケーションＢを利用して生成された医療画像（以下、便宜上「医療画像Ｂ」と表わす。）の観察時間は短い。また、医療画像Ｂに対して発行されたコマンドの数は１つであり、５つのコマンドが発行された医療画像Ａよりも少ない。そのため、「観察時間」及び「コマンド発行数」に関する課金情報に対して付与される点数は、アプリケーションＡよりもアプリケーションＢの方が少ない。これら両課金情報における点数の違いが診断有効度に影響を与え、アプリケーションＢに対する「診断有効度」は「１０４点」となる。従って、料金算出部２６ｆにおいて算出される課金金額は、「１０４００円」となる。

もちろん、観察時間が長く、発行されたコマンド数が多いからといって診断により役立つとも限らないが、その辺りは各課金情報に付与される点数の設定を変更することによって、より実状に近づけることができる。

アプリケーションＣについては、「起動」のみが行われ、その後当該アプリケーションＣを利用して医療画像の生成は行われなかったため、「画像生成」以下の課金情報について点数は付与されていない。但し、全く起動も行われなかったアプリケーションＤとは異なり、実際の診断には寄与していないものの、ユーザに対して利用する意図を生ぜしめた点でアプリケーションＤよりも有効であったとも考えられる。そのためアプリケーションＣについては料金算出部２６ｆにおいて「１０点」に１００を乗じた「１０００円」の課金金額が算出される。

以上、作成された検査レポートに医療画像が貼付された後の課金処理について説明した。次に、検査レポートには生成された医療画像は貼付されなかったものの、表示された場合に関する課金処理について説明する。

図１３は、本発明の実施の形態における医療画像の表示が行われた場合における課金の流れを示すフローチャートである。まず判断部２６ｅにおいて、医療画像の表示に関する課金情報を把握する（ＳＴ６１）。図９に示す説明図では、「表示」については「３０点」が付与される。

次にユーザは、表示された医療画像について診断を行うために、当該医療画像に対して何らかの処理を行うことが考えられる。ここでの「処理」とは、上述したように、例えば、医療画像の回転、拡大、縮小、或いは、計測といったユーザの行為である。

検査レポートに貼付される医療画像はあくまでも代表的な医療画像である。一方で検査レポートに貼付されないが表示が求められる医療画像は、ユーザが診断を行うために様々な情報を得るために利用されることが多いと考えられる。この場合、対象となる医療画像が表示されると、ユーザによって上述した処理が行われ、その処理によって得られた情報は、ユーザによって検査レポートに反映されたり、或いは、診断をする上での重要な判断情報となったりする。

そこで操作履歴収集部２６ｃ及び操作履歴解析部２６ｄはユーザによる処理が行われ、ユーザによって発行されたコマンド数を把握する（ＳＴ６２）。把握されたコマンド数に関する情報は、判断部２６ｅへと送られる。判断部２６ｅでは取得したコマンド数に関する情報を基に係数を乗じて、コマンド発行数に関する課金情報を取得、保持する（ＳＴ６３）。ここで設定されている係数は、図９に示す説明図によれば「５」であり、コマンド数に係数５を乗じてコマンド発行数とする。

そして、ユーザによって処理がなされた医療画像について、次に、ユーザがどのくらいの時間、当該医療画像を観察したか、操作履歴収集部２６ｃ及び操作履歴解析部２６ｄにおいてログが解析されることによって、ユーザによる貼付された医療画像の観察時間が把握される（ＳＴ６４）。判断部２６ｅでは把握された観察時間に関する情報を取得し、観察時間に所定の係数を乗ずる（ＳＴ６５）。図９に示す説明図においては、「観察時間」に係数２を乗ずることが設定されている。そして係数を乗ずることによって把握される観察時間に関する課金情報を取得、保持する。

判断部２６ｅは、操作履歴収集部２６ｃ及び操作履歴解析部２６ｄからの情報に基づいて、処理、観察が行われた医療画像に対して、再度の処理が行われたか否か、確認する（ＳＴ６６）。これは、上述したように、ユーザが診断を行うために様々な情報を得るために医療画像を利用する場合には、何度か処理、観察という手順を踏むことも考えられるからである。そのため、判断部２６ｅでは、処理、観察という一連の流れが終了する度に、再び処理が行われるか否かを確認し、その都度、課金情報を取得、保持する。

上述した手順がこれ以上行われないと判断できる場合には、判断部２６ｅは課金情報を収集して、診断有効度を把握する（ＳＴ６７）。判断部２６ｅにおいて該当するアプリケーションに関する診断有効度が把握されると、当該診断有効度の情報が料金算出部２６ｆへと送られる。

料金算出部２６ｆでは、受信した診断有効度に基づいて課金データベース２７に格納されている、例えば金額表を基に、金額を把握する（ＳＴ６８）。この金額が当該アプリケーションの利用に応じた課金の金額として算出されることになる（ＳＴ６９）。

表示された医療画像に対する処理に関する課金の流れは、以上説明した通りである。以下ではこの流れを実際のアプリケーションに関する課金情報も交えながら説明する。図１４は、本発明の実施の形態において医療画像の表示が行われた場合に関する課金についてのテーブルの一例を示す説明図である。

当該テーブルの構成は、図１２に示されている医療画像の貼付が行われた場合に関する課金の流れを説明する際に利用したテーブルと略同じである。但し、課金情報の項目が異なる。

図１４に示すテーブルでは、上段最左端にアプリケーションの項目が設けられており、以下順に右側に向けて「起動」、「表示」、「観察時間」、「コマンド発行数」、「診断有効度」、及び「課金金額」が示されている。医療画像の表示のみがなされる場合には、医療画像の生成や検査レポートへの貼付という処理はないことから、図１４に示すテーブルにはこれらの課金情報は設けられていない。

アプリケーションとしては３つ、アプリケーションＥないしアプリケーションＧまでが図１４に示すテーブルに示されている。このうちアプリケーションＧについては、起動の課金情報の欄に点数が付与されていないことから、ユーザはアプリケーションＧを起動していないことが理解できる。従って「課金金額」も算出されず「０円」となる。

一方、アプリケーションＥ及びアプリケーションＦについては、いずれも起動後、表示されている。但し、「観察時間」及び「コマンド発行数」に違いがあり、アプリケーションＥに関する「診断有効度」は「９５点」となり、アプリケーションＦに関する「診断有効度」は「４６点」となる。そのため、「課金金額」についてもそれぞれの診断有効度に１００が乗じられて、アプリケーションＥについては「９５００円」、アプリケーションＦについては「４６００円」となる。

以上説明した通り、ユーザのアプリケーションの利用態様を基に、検査レポートの作成において利用されるアプリケーション、特に医療画像の生成、表示に利用されるアプリケーションに関する利用料金を算出する場合に、ユーザが診断を行うに当たってどのくらい役立つ医療画像を生成、或いは表示したのか、という観点をもって評価し料金算出を行うことで、利用されたアプリケーションに対する公平な課金、アプリ提供者の開発意欲の向上、及びシステム運営者による魅力的なシステム運営を図ることが可能な医療情報システム及び当該医療情報システムを利用した課金方法を提供することができる。
［医療画像の生成、処理に対する課金の別の流れ］
なお、ここまでは、課金情報に基づく診断有効度を利用して課金金額を算出する方法を説明したが、さらに以下の点を加味して課金金額を算出することも可能である。

すなわち、上述した方法では例えば医療機関に在籍するユーザが診断のために利用した場合を想定し、この利用を診断有効度に置き換えて課金金額を算出するが、この考え方を広げて、診療報酬とリンクさせることで、診断の役に立つばかりではなくユーザが在籍する医療機関の収入を向上させることができるアプリケーションに対してはより多くの利用料金を支払うことが可能となる。このような対応が可能となれば、さらに適切な利用料金の算出、アプリ提供者への支払いを行うことができ、アプリ提供者からすればさらなる開発意欲をかき立てられることになる。

また、例えば、病名の特定まで可能とする医療情報を提供することが可能なアプリケーションに対しては、この点も考慮して課金金額を決定することができれば、より診断を行うユーザにおける有効度を適切に反映させることができる。すなわち、病名まで特定できるような医療情報が提供されれば、投与する薬剤についても把握することができる。患者に対して薬剤を処方することについても後述する診療報酬の考え方が適用できるので、医療機関の収入として把握することが可能となる。

さらに、より難病である「病名」が付与されるということは、それだけユーザによる診断等も困難になると考えられる。従って、このような診断を行うに寄与したアプリケーションを開発したアプリ提供者に対しては、より適切な利用料金の支払いが要求される。

図１５は、本発明の実施の形態における医療画像の生成に関する課金に関して、診療報酬等を加味した課金方法を説明するためのテーブルの一例を示す説明図である。

図１５に示すテーブルには、アプリケーションとしてアプリケーションＡないしアプリケーションＤが示されている。当該テーブルは、図１２に示すテーブルにリンクする。従って、図１５に示されているアプリケーションＡないしアプリケーションＤの診断有効度は、図１２に示すテーブルに示される診断有効度と同じ点数が示されている。

従って、診断有効度はそれぞれ、アプリケーションＡが「１４０点」、アプリケーションＢが「１０４点」、アプリケーションＣが「１０点」、アプリケーションＤが「０点」となる。ここでは、これまでに課金情報を基に集計された診断有効度に加えて、さらに「診療報酬」と「病名」という課金情報を追加する。

アプリケーションＡにおいては、例えば、Ｘ線ＣＴ装置を利用した撮影が行われた場合の「診療報酬」が点数「９５０点」として追加される。同様に、アプリケーションＢについては「９００点」、 アプリケーションＣについては「６００点」が追加される。

またＸ線ＣＴ装置を利用して取得された内部情報を基に、アプリケーションＡを利用して医療画像が生成されることで「病名」が「Ｘ」と判断された場合には、病名が示される。当該「病名」については、点数に置き換えた上で課金情報として把握しても、或いは、図１５に示すように課金金額を算出する際に点数とは別に直接病名として把握するようにしても良い。

アプリケーションＡに関しては、元々の「診断有効度」が「１４０点」、「診療報酬」が「９５０点」、「病名」が「Ｘ」となり、料金算出部２６ｆにおいて算出される課金金額は、「１０９０点＋Ｘ」となる。また同様に、アプリケーションＢに関しては、「１００４点＋Ｘ」、アプリケーションＣに関しては「６１０点＋Ｙ」となる。

図１６は、同様に医療画像の表示に関する課金に関して、診療報酬等を加味した課金方法を説明するためのテーブルの一例を示す説明図である。

図１６に示すテーブルには、アプリケーションとしてアプリケーションＥないしアプリケーションＧが示されている。当該テーブルは、図１４に示すテーブルにリンクする。従って、図１６に示されているアプリケーションＥないしアプリケーションＧの診断有効度は、図１４に示すテーブルに示される診断有効度と同じ点数が示されている。

従って、診断有効度はそれぞれ、アプリケーションＥが「９５点」、アプリケーションＦが「４６点」、アプリケーションＧが「０点」となる。ここにこれまでに課金情報を基に集計された診断有効度に加えて、さらに「診療報酬」と「病名」という課金情報を追加する。

例えば、アプリケーションＥは、「診療報酬」として「８５点」が示される頸部等の単純撮影が行われることで得られる医療画像の処理を行う際に利用されている。その結果「病名」として「Ｘ」が判明した。そのため、「課金金額」は、「１８０点＋Ｘ」となる。一方、アプリケーションＦは、「診療報酬」として「８５点」が示される頸部等の単純撮影が行われることで得られる医療画像の処理を行う際に利用されている。なおここでは、さらに撮影の際に造影剤の使用がなされたため、別途「７２点」が加算されている。その結果「病名」として「Ｘ」が判明した。そのため、「課金金額」は、「２０３点＋Ｘ」となる。

以上の点からすれば、「診断有効度」についてはアプリケーションＦよりもアプリケーションＥの方が点数が高いにも拘わらず、アプリケーションＥよりもアプリケーションＦに対してより高い課金金額が支払われることになる。すなわち、この場合、同じ頸部等の単純撮影が行われることで得られる医療画像の処理を行う際に利用されるアプリケーションであっても、「診療報酬」の点数がより高い方が課金金額も高くなる。一般的に診療報酬の点数が高い方がより医療機関に対する収益に貢献することになるため、この点でアプリケーションＦのアプリ提供者に対して支払われる利用料金の方がアプリケーションＥのアプリ提供者に対して支払われる利用料金よりも高くなるということは、より実情に沿った利用料金の設定、支払いとなる。

以上説明したように、診療報酬や病名についても課金情報の１つとして取り扱うことによって、アプリケーションを利用したユーザに対する有効度のみならず、当該ユーザが在籍する医療機関の収入にも配慮した利用料金の算出を可能とする。このように利用料金を算出することで、より一層利用されたアプリケーションに対する公平な課金、アプリ提供者の開発意欲の向上、及びシステム運営者による魅力的なシステム運営を図ることが可能な医療情報システム及び当該医療情報システムを利用した課金方法を提供することができる。

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

例えば、上述した課金の方法では、検査レポートに統合されるまでに行われる、例えば、医療画像の生成や表示といった処理についてはリアルタイムにユーザの操作履歴（ログ）を解析し、課金情報を取得、保持している。また、統合後に行われる処理に関しては、その時点で操作履歴（ログ）を解析し、課金情報を取得し、その後に全ての課金情報を集計して診断有効度を判断している。但しこのような方法ではなく、例えば、統合ビューアによって全ての医療情報が統合され、ユーザからの検査レポートの作成を完了した旨の信号を受信した後に、検査レポートの作成に当たってユーザにより行われた全ての操作履歴（ログ）を解析し、課金情報の取得、診断有効度の判断、料金算出を行うようにしても良い。

この実施形態やその変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

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

Claims (11)

1. ユーザが使用するクライアント端末と、
   前記ユーザが医療画像診断装置によって取得された患者の内部情報を示す医療画像を基に診断を行う際に利用する前記医療画像の処理を行うアプリケーションを備えるアプリケーションサーバと、
   前記ユーザが前記診断を行うに当たって、その判断に有効な前記医療画像の生成、処理を行ったアプリケーションを提供したアプリ提供者に対して、前記医療画像の診断有効度、前記医療画像に対して行った処理の診断有効度に応じた利用金額を算出するテナント型医療情報システムと、
   を備えることを特徴とする医療情報システム。
2. 前記テナント型医療情報システムは、
   前記ユーザからの要求に応じて、前記ユーザが必要としている前記医療画像の生成、処理を行う上で適切な前記アプリケーションを選択するワークフローマネージャと、
   前記ユーザが前記診断に当たって利用する前記医療画像の生成、処理に使用した前記アプリケーションに関する利用料金を、利用した前記医療画像の診断有効度に基づいて前記アプリケーションを提供する前記アプリ提供者に支払う場合に、その金額を算出する課金エンジンと、
   前記診断有効度を判断する課金情報を記憶する設定データベースと、
   前記料金の算出の基となる情報を記憶する課金データベースと、
   前記ユーザが前記診断を行うに当たって検査レポートを利用する場合に、前記アプリケーションによって生成される医療画像を前記検査レポートに統合して前記クライアント端末に表示させる統合ビューアと、
   を備えることを特徴とする請求項１に記載の医療情報システム。
3. 前記課金エンジンは、
   前記ユーザが利用したアプリケーションを確認する利用アプリ確認部と、
   前記利用アプリ確認部において確認された前記ユーザによる利用アプリの操作履歴を収集する操作履歴収集部と、
   収集された前記操作履歴を解析する操作履歴解析部と、
   前記操作履歴解析部によって解析された前記操作履歴を基に取得され、点数化して表わされる前記課金情報から、前記医療画像の生成、処理に利用された前記利用アプリの診断有効度、前記医療画像に対して行った処理を行う際に利用された前記利用アプリの診断有効度を判断する判断部と、
   前記判断部によって判断された前記利用アプリごとの前記診断有効度を基に前記アプリ提供者に対して支払う利用金額を算出する料金算出部と、
   を備えることを特徴とする請求項２に記載の医療情報システム。
4. 前記課金情報は、前記ユーザが前記医療画像の生成、処理を行うに当たって前記クライアント端末を介して行う操作履歴を基に取得される情報であり、前記ユーザが行う前記医療画像の生成、処理の項目として、少なくとも、アプリケーションの起動、前記医療画像の生成、生成された前記医療画像の貼付、前記医療画像の表示、観察、コマンド発行の操作が含まれることを特徴とする請求項２または請求項３に記載の医療情報システム。
5. 前記医療画像の生成、処理を点数化して表わし前記課金情報として前記判断部に提供するに当たって、前記医療画像の生成、処理の項目ごとに重みづけを行い点数化することを特徴とする請求項４に記載の医療情報システム。
6. 前記料金算出部は、前記判断部が判断した前記診断有効度を基に、診療報酬に関する情報を加味して前記アプリ提供者に対して支払う利用金額を算出することを特徴とする請求項３ないし請求項５のいずれかに記載の医療情報システム。
7. 前記料金算出部は、さらに病名の情報も加味して前記アプリ提供者に対して支払う利用金額を算出することを特徴とする請求項６に記載の医療情報システム。
8. 前記統合ビューアは、
   前記統合ビューアにて受信する情報を解析する情報解析部と、
   前記情報解析部にて把握された前記ユーザが必要としている前記医療情報に関係する情報を収集する情報収集部と、
   前記シンクライアントマネージャから送信された前記ユーザが必要としている医療情報を受信し、前記ワークフローマネージャから送信された表示レイアウトに従って前記クライアント端末に表示させる前記医療情報を統合する情報統合部と、
   を備えることを特徴とする請求項２ないし請求項７のいずれかに記載の医療情報システム。
9. ユーザが検査レポートの作成を行うに当たって使用する医療画像をアプリケーションを利用して生成、表示させるステップと、
   前記生成、表示された前記医療画像に対して、前記ユーザの要求に応じて処理を行うステップと、
   前記生成、表示、処理に利用されたアプリケーションに対する前記ユーザによる操作履歴を解析し、前記生成、表示、処理に対してそれぞれ定められている課金情報を前記アプリケーションごとに取得するステップと、
   前記課金情報を基に前記アプリケーションごとの診断有効度を判断するステップと、
   前記診断有効度を基に前記アプリケーションを提供するアプリ提供者に対して支払う利用金額を算出するステップと、
   を備えることを特徴とする医療情報システムを利用した課金方法。
10. 前記アプリ提供者に対して支払われる前記利用金額の算出を行うステップにおいて、前記診断有効度に診療報酬の情報も加味して前記利用金額の算出を行うことを特徴とする請求項９に記載の医療情報システムを利用した課金方法。
11. 前記アプリ提供者に対して支払われる前記利用金額の算出を行うステップにおいて、前記診断有効度に診療報酬の情報のみならず病名の情報も加味して前記利用金額の算出を行うことを特徴とする請求項１０に記載の医療情報システムを利用した課金方法。

Images