JPWO2014188476A1 - ヘルスケア情報処理システム - Google Patents

Abstract

質の良いヘルスケア情報／医療データを効率的に蓄積するシステムを提供する。ヘルスケア情報を蓄積するシステムが、前記ヘルスケア情報をデータ提供者のコンピュータから受信する受信部と、前記ヘルスケア情報を評価する医学ないし医療に関する条件を記憶する記憶部と、前記受信したヘルスケア情報と前記条件から前記ヘルスケア情報の価値を評価する評価部と、及び、前記価値に基づいて、前記ヘルスケア情報を蓄積する料金を決定する課金部を有する。

Description

本発明は、ヘルスケア情報を処理するシステムに関係し、特に、ヘルスケア情報を蓄積するシステムに関係する。

本技術分野の背景技術として、特許文献１がある。この文献には、最終的な診断を行う診断医が利用する各検査項目の読影レポートについて、作成元の読影医の所見の内容および検査依頼との整合性を客観的に評価することで、レポートの品質を評価する記載がある。この文献では、診断医の依頼に対して、どれだけ明確に返答しているかの観点でレポートの品質を評価している。一方、特許文献２には、ストレージ課金に関する内容が記載されているが、データアクセス速度の観点で課金料金を算定している。

特開2006-059063号 特開2006-113824号

診療データは多種多様であり、限られた診療時間内で、詳細な情報を全て記録できないことが多い。例えば、電子カルテは診療データを記録するシステムであるが、検体検査や処方などのオーダ情報や診療報酬請求情報など、日常業務を遂行するに必要な範囲の記録にとどまり、臨床研究などのデータの2次利用を目的とした、データの充実（一定の条件を満たすデータの充実）は優先されない傾向にある。したがって、ＥＨＲ（Electronic Health Record）などの診療データの電子保管が進展しても、複数医療プロバイダー間でのデータ共有は可能になるものの、そのデータを分析して、費用対効果の高い診断治療ガイドラインを探索するなどの使い方に関しては限界がある。

本発明の目的は、質の良いヘルスケア情報／医療データを効率的に蓄積するシステムを提供することである。

上記目的は、ヘルスケア情報を蓄積するシステムが、前記ヘルスケア情報をデータ提供者のコンピュータから受信する受信部と、前記ヘルスケア情報を評価する医学ないし医療に関する条件を記憶する記憶部と、前記受信したヘルスケア情報と前記条件に基づいて、前記ヘルスケア情報を蓄積する料金を決定する課金部を有することによって、達成される。

本システムにより、データ提供者のヘルスケア情報を蓄積する際に、医学ないし医療に関する条件に基づいて、データ提供者に対するヘルスケア情報を蓄積する料金を決定することが可能となる。この結果、蓄積されるヘルスケア情報が医学に関する条件に合っているか否かによって、ヘルスケア情報を保管する料金を変えることが可能となり、医学に関する条件に合った質の良いヘルスケア情報（２次利用可能なデータ）の入力を促し、効率的に質の良い医療データを効率的に蓄積可能となる。

実施例１、実施例２に関わるシステム構成図である。 実施例１を説明するフローチャートである。 対象エピソードテーブルの例である。 患者テーブルの例である。 エピソードテーブルの例である。 診療行為テーブルの例である。 検査結果テーブルの例である。 処方テーブルの例である。 関連テーブルの例である。 診断治療知識に関するデータ構造の例である。 検査-適応疾患テーブルの例である。 薬剤-適応疾テーブルの例である。 実施例１を説明するフローチャートである。 実施例１を説明するフローチャートである。 医療機関テーブルの例である。 所見ファイルに関するデータ構造の例である。 質評価用所見テーブルの例である。 実施例１を説明するフローチャートである。 課金情報テーブルの例である。 データ購入量テーブルの例である。 データ購入量と割引率の基準値の関係を説明する図である。 実施例１、実施例２で使用する所見入力画面に関するフローチャートである。 所見入力情報に関するデータ構造の例である。 所見入力画面の例である。 課金情報明細書の例である。 実施例２を説明するフローチャートである。 実施例２を説明するフローチャートである。 実施例２を説明するフローチャートである。 検索テンプレートのデータ構造の例である。 類似症例テーブルの例である。 質評価用類似症例テーブルの例である。 実施例２を説明するフローチャートである。 実施例１、実施例２に関わるハードシステム構成図である。

以下、本発明の実施例を、図面を用いて説明する。
（実施例１）
図１は、本実施例のシステム全体の構成を示す。ヘルスケア情報サービス事業者１０１は、データ提供者１０２が提供する患者の病状や健診データ等の診療データを保管するサービスを、データ提供者に対して提供する。一方、データ消費者１０３は、ヘルスケア情報サービス事業者が保管した診療データから必要な診療データを購入し、研究開発等に役立てる。この際、ヘルスケア情報サービス事業者は、データ消費者が要求する条件（診療データの項目、品質、量、等）を満たす診療データを選択し、データ消費者へ提供する。そして、ヘルスケア情報サービス事業者１０１は、データ消費者に提供するデータの条件によって販売するデータの価格を変化させ、また、データ提供者が提供するデータの項目、品質、量、等によって保管に係る費用を変化させる。

ヘルスケア情報サービス事業者１０１は、コンテンツ管理システム１０４、会員管理システム１０９、課金システム１１０を有する。コンテンツ管理システム１０４は、データ提供者から預かるデータを管理するデータ管理部１０５、データ提供者のデータの価値をデータの量、品質、項目等で、評価するデータ価値評価部１０６、データ消費者１０３へデータ販売を管理するデータ販売部１０７、データ管理部１０５が管理するヘルスケアデータを保管するストレージ１０８からなる。会員管理システム１０９は、本ヘルスケア情報サービス事業者１０１のサービスの提供を受ける、データ提供者１０２およびデータ消費者１０３を管理する。また、課金システム１１０は、データ提供者１０２のデータ保管料やデータ消費者１０３のデータ購入料の課金情報を管理する。

データ提供者１０２は、病院や診療者や健診施設等であり、ここで発生する各種診療データ（患者毎の病名、症状、診療行為、処方）、健診データ（定期健康診断における診療行為、等）に関して、これらのデータ保管をヘルスケア情報サービス事業者に依頼する。データ保管料は、ヘルスケア情報サービス事業者からデータ提供者に請求され、データ提供者はデータ保管料をヘルスケア情報サービス提供者に、銀行振り替え等を利用し支払う。

データ消費者１０３は、医療研究機関や保険者や製薬会社であり、患者の治療方法の研究や、健康増進のための健康状態の管理や予防や、薬の治験対象者の選定等のために、ヘルスケア情報サービス事業者に、データ提供者が預けたデータから必要なデータの提供を依頼し、データを入手する。データ消費者は、必要な情報の提供を受けると、その代金（データ購入料）をヘルスケア情報サービス事業者に支払う。この支払いが、ヘルスケア情報サービス事業者の収益となり、また、データ提供者が支払うヘルスケア情報サービス事業者へ支払うデータ保管料の割引に利用される。これにより、データ提供者は低料金で診療データを保管できるようになり、診療データをヘルスケア情報サービス事業者に診療データを更に保管する動機付けになり、結果として、データ保管が更に進むことになる。一方、データ保管が進み大量のデータが保管されるようになれば、データ消費者は必要なデータを入手可能となり、所望のデータ入手が容易になる。

ここで、図１を実現するハードシステム構成について図３３を用いて説明する。

ヘルスケア情報サービス事業者１０１は、データセンタやサーバ等のコンピュータ３３０１でプログラム（会員管理システム１０９用のプログラム、課金システム１１０用のプログラム、データ管理部１０５のプログラムやデータ価値評価部用１０６のプログラムや、及び、データ販売部１０７のプログラム等を含むコンテンツ管理システム１０４用のプログラム、等）を実行することで実現される。コンピュータ３３０１は、プログラムを実行しデータを処理する演算装置であるＣＰＵ３３０２、前述のプログラムやデータ等を記憶するメモリ／記憶装置３３０５（図１のストレージ１０８はここに配置される）、データ提供者やデータ消費者と、通信回線やインターネット等の通信ネットワーク３３０７を介してデータを送受信する通信インタフェース３３０６、管理端末３３０４との入出力インタフェース３３０３、等から構成される。管理端末（管理装置）は、入出力装置を有し、オペレータによる、コンピュータへのプログラムやデータの入力、または、診療データのストレージでの記憶状況や課金状況等を表示することに使用される。

データ提供者１０２は、データ提供者が使用するコンピュータ３３１０を用いて、医者や健康指導者等がコンピュータの入出力機器３３１３から入出力インタフェース３３１２を経由して入力した診療データを、ヘルスケア情報サービス事業者に、診療データを所定のフォーマットで、通信回線等を介して送信する。ここで、コンピュータは、ＣＰＵ３３０８、メモリ／記憶装置３３０９、通信ネットワーク３３０７との通信インタフェース３３１１、入出力機器３３１３、入出力機器の入出力インタフェース３３１２等で構成され、メモリ／記憶装置上のプログラムを実行することで、入出力機器から入力される診療データをコンピュータに取り込み、ヘルスケア情報サービス事業者へ診療データが送信する。また、データ提供者のコンピュータは、ヘルスケア情報提供業者のコンピュータから発行されるデータ保管料の請求する請求書を受信すると、自動的に銀行に支払い指示を出し、銀行からヘルスケア情報サービス事業者に支払いをするようにしてもよい。

データ消費者１０３は、ヘルスケア消費者が使用するコンピュータ３３１５を用いて、希望する診療データを指定した要求を含む要求メッセージ／信号／パケット等をヘルスケア情報サービス事業者が有するコンピュータへ送信する。そして、データ消費者１０３のコンピュータは、指定した診療データをヘルスケア情報サービス事業者のコンピュータから受信し記憶する。データ消費者はこの記憶した診療データを分析することで、データ消費者が本来の研究や健康増進業務を進めることが可能となる。ここで、コンピュータ３３１５は、ＣＰＵ３３１４、メモリ／記憶装置３３１５、通信ネットワーク３３０７との通信インタフェース３３１７、入出力機器３３１９、入出力機器との入出力インタフェース３３１９等で構成され、メモリ／記憶装置上のプログラムを実行することで、必要な診療データをヘルスケア情報サービス事業者へ依頼し、また、依頼したデータを受信する。データ消費者のコンピュータは、依頼した診療データを受診すると、自動的に銀行に支払い指示を出し、銀行からヘルスケア情報サービス事業者に支払いをするようにしてもよい。

以下、上記を実現するシステムが扱うデータ構成について説明する。

図３は対象エピソードテーブル３０１を示す。本テーブルは、個々のエントリの通し番号である通番３０４、データ価値評価等の処理対象とするエピソードを特定する対象エピソード番号３０２、当該エピソードを表す状態名３０３から構成される。ここで、状態名ごとに対象エピソード番号は一意に決まる。また状態名は、病名、身体所見名称、抗がん剤投与等の治療計画名称からなる。また、定期健康診断も状態名となり得る。本テーブルは、データ価値評価等の処理対象となるエピソードを管理するマスターテーブルであり、データ管理部１０５によりヘルスケア情報サービス事業者が管理端末３３０４から作成するものである。ヘルスケア情報サービス事業者は、この対象エピソードテーブルを作成して、収集するデータの対象を指定する。データ提供者が提供するデータは、この対象ごとに整理され管理されることになる。例えば、データ消費者のニーズが高いエピソードにのみ、データ価値評価等の処理対象を制限するために活用するが、全エピソードを登録しても問題はない。

図４は、患者テーブル４０１を示す。本テーブルは、患者の基本情報を管理するマスターテーブルであり、患者を識別する患者ＩＤ４０２，患者の氏名４０４、患者の生年月日４０５、患者の性別４０６、患者が診療を受けている医療機関を識別する識別子である医療機関ＩＤ４０３から構成される。これらのデータは、データ提供者１０２がヘルスケア情報サービス事業者１０１に提供するものであり、データ管理部１０５がこれらデータをストレージ１０８に格納する。

図５は、エピソードテーブル５０１を示す。本テーブルは、個々のエントリの通し番号であるエピソード番号５０２、患者を識別する患者ＩＤ５０３、エピソードを表す状態名５０９、当該状態名に対応するレコードを図３の対象エピソードテーブルから参照するための対象エピソード番号５０６、エピソードの開始日５０７と、治癒や死亡など当該エピソードの帰結である転帰５０８、当該エピソードに関係するデータの総量であるデータ量５０４、当該エピソードに関連したデータに対して診断治療知識にもとづき計算したデータの整合度５０５から構成される。対象エピソード番号５０６であるが、図３の対象エピソードテーブルに、該当する状態名がない場合には空値となる。また、データ量は、図９の関連テーブル、図６の診療行為テーブル、図７の検査結果テーブル、図８の処方テーブルから、当該エピソードに関連するレコード全ての合計バイト数とする。

図６は、診療行為テーブル６０１を示す。本テーブルは、個々のエントリの通し番号であるオーダ番号６０２、患者を識別する患者ＩＤ６０４、当該患者に実施された診療行為に関する行為名６０３、当該診療行為に関する開始日６０５と終了日６０６から構成される。行為名６０３には、検査、処置、手術などの医療行為に関する名称が記載される。

図７は、検査結果テーブル７０１を示す。本テーブルは、図６の診療行為テーブルにエントリされた検体検査に関する結果を管理するテーブルであり、診療行為テーブルにおける、どの検体検査の結果であるかを特定するためのオーダ番号７０２、患者を識別する患者ＩＤ７０６、検査名称である検査名７０３、この検査名の検査結果数値である値７０４と、その単位７０５から構成される。一つの検体検査に関して複数の検査が実際されるので、同じオーダ番号に関して複数のレコードが存在することがある。図６は２つの場合を示している。

図８は、処方テーブル８０１を示す。本テーブルは、個々のエントリの通し番号である処方番号８０２、患者を識別する患者ＩＤ８０４、処方された薬剤に関する薬剤名８０３、当該薬剤の処方量８０５および処方日８０６から構成される。

図６、図７、図８は、ある患者に対して行われた医療行為に関する記録であるが、これららのテーブルだけでは、各医療行為が、どのエピソードに関係するか判断できない。図９の関連テーブル９０１では、この関係を特定するために用いる。本テーブル９０１は、個々のエントリの通し番号である関連番号９０５、患者を識別する患者ＩＤ９０６、図５のエピソードテーブルから対象となるエピソードを参照するためのエピソード番号９０２、図６の診療行為テーブルと図８の処方テーブルのうち、どちらの医療行為に関係するか指定するためのテーブル名９０３、当該テーブル名で指定されたテーブル内のレコードを参照するための参照番号９０４から構成される。この参照番号９０４は、診療行為の場合は図６の診療行為テーブル６０１のオーダ番号６０２を参照し、処方の場合は図８の処方テーブル８０１の処方番号８０２を参照することになる。

また、図４、図５のデータ量と整合度以外のデータの部分（エピソード番号、患者ＩＤ、状態名、対象エピソード番号、開始日、転帰）、図６、図７、図８、及び、図９のデータは、データ提供者がヘルスケア情報サービス事業者に提供する情報であり、データ管理部が、データ提供者のコンピュータからネットワークを介して受信したとき、受信したデータにもとづき、ストレージの各テーブルに格納する。

図１０は、診断治療知識の例を示す。図１０に示す例では、診断治療知識はファイルの構造を有しており、患者の症状を表す状態（「強い胸痛」、等）、前記状態のとき通常行われる検査と検査結果から判断される病名（セクション１００１）、前記状態のとき通常患者に投与される「アスピリン」、「モルヒネ」、等の投薬（投薬名）（セクション１００２）、前記状態のとき通常行われる医療処置である「心臓カテーテル」等の診療行為（診療行為名）(セクション１００３)、更に、病名を検査結果から判断するための条件（CK>197、トロポニン>０．２５）（セクション１００４）等の複数の項目から構成される。これら診断医療知識は、医療分野で広く認知された定説となっている知識である。ヘルスケア情報サービス事業者は、種々の症状に対するこのような知識を、事前に、例えば管理端末３３０４からストレージ１０８に格納しておく。この診断医療知識は、データ提供者が提供する診療データの質を評価する際に使用される。診療データの質は、この知識と、どの程度一致するかで質／価値が評価されることになる。

図１１は、検査-適応疾患テーブル１１０１を示す。本テーブルは、各検査の適応疾患を管理するマスターテーブルであり、診断治療知識の一つである。本テーブルは、検査名１１０２、当該検査に適応する病名から構成される。ここで、ある検査がある病名に対して適応であるとは、当該病名（１１０３）が疑われる場合に、当該検査の実施に妥当性があることを意味する。検査-適応疾患テーブルは、図１０と同様に、データ管理部１０５によりヘルスケア情報サービス事業者が、事前に、ストレージに格納しておく。この診断医療知識は、データ提供者が提供する診療データの質を評価する際に使用される。診療データの質は、この知識と、どの程度一致するかで質が評価されることになる。

図１２は、薬剤-適応疾患テーブル１２０１を示す。本テーブルは、各薬剤の適応疾患を管理するマスターテーブルであり、診断治療知識の一つである。本テーブルは、薬剤名１２０２、当該薬剤に適応する病名１２０３から構成させる。ここで、ある検査がある病名に対して適応であるとは、当該病名が疑われる場合に、当該薬剤の処方に妥当性があることを意味する。検査-適応薬剤テーブルは、図１０と同様に、データ管理部１０５によりヘルスケア情報サービス事業者が、事前に、ストレージに格納しておく。この診断医療知識は、データ提供者が提供する診療データの質を評価する際に使用される。診療データの質は、この知識と、どの程度一致するかで質が評価されることになる。

図２は、ヘルスケア情報サービス事業者のコンピュータのＣＰＵで実行されるデータ価値評価部１０６（プログラム）の処理フローを示す。データ価値評価部１０６は、データ管理部１０５がストレージ１０８に格納したヘルスケア（診療）データのデータ価値を評価する処理を実行する。データ価値評価部１０６は、データ提供者１０２が提供したデータの記載内容に基づきデータの価値を評価する価値評価部２０３と、評価されたデータ価値に基づきデータ保管に対するビット単価を計算するビット単価計算部２０４と、ビット単価を基に課金する際の課金額を更新する課金情報更新部２０５とから構成される。

記載内容に基づく価値評価部２０３は、エピソード、診療行為、検査結果、等のデータが、所望の対象や項目や内容や品質で収集されているかを評価するためのチェック（例えば、事前に準備された指標や事前に定義された項目との整合性をチェック）を行うステップ２０６と、エピソードごとの所見（検査項目、検査結果、診断結果、処方、等）が入力されているか否かをチェックするステップ２０７とから構成される。なお、所見は、フリーテキストデータ定型入力で行われるものとする。ビット単価計算部２０４は、この評価したデータ価値に基づき、当該データ提供者のデータ保管に対するビット単価を計算し、課金情報更新処理２０５では、単価計算部２０４で計算したビット単価情報を、図１の課金システム１０９に通知する。

このように、データ価値評価部は、データ提供者が提供したデータを評価し、評価結果に基づきデータを保管するためのビット単価を計算し、保管費用を決定する。データを評価してビット単価を定めるので、例えば、評価結果が良いデータに対する保管料金を、評価結果が良くないデータに対する保管料金を安くすることで、データ提供者はデータ保管料を安く押さえる目的で質の良いデータを提供しよとし、ヘルスケア情報サービス事業者は効果的に質の良いデータを収集することができる。

図１３は、記載内容に基づく価値評価部２０３の整合性チェック２０６の処理フローを示す。記載内容に基づく価値評価部２０３のステップ１３０１では、図３で示す対象エピソードテーブル３０１より全レコードを取得し、処理対象のエピソードのリストとしてメモリ３３０５上に管理する。ステップ１３０２では、このリストから対象エピソード（対象エピソード番号）を一つ選択する。ステップ１３０３では、もし対象となるエピソードが存在するなら、ステップ１３０４に進む。もし対象エピソードが存在しないなら、ステップ１３１９に進み処理を終了する。

ステップ１３０４では、図４の患者テーブル４０１から１レコードを取り出し患者（患者ＩＤ）を選択する。ステップ１３０５では、もし患者が存在すればステップ１３０６に進む。存在しないなら、ステップ１３０２に戻る。

ステップ１３０６では、ステップ１３０４で選択したレコードの項目４０２の患者ＩＤ、および、ステップ１３０２で選択したレコードの項目３０２の対象エピソード番号にもとづき、図５のエピソードテーブル５０１から、当該患者に対する当該エピソードを検索し、その一つを選択する。具体的には、エピソードテーブル５０１の項目５０３の患者ＩＤと項目５０６の対象エピソード番号に適合するレコード／エピソードを選択する。

ステップ１３０７では、もしレコード／エピソードが存在するならステップ１３０８に進む。存在しないなら、ステップ１３０２に戻る。エピソードが存在する場合、このエピソード（対象エピソードに一致する患者）に関するデータが、整合性を評価される対象である。

ステップ１３０８では、ステップ１３０６で選択したエピソード／レコードについて、項目５０２のエピソード番号に基づき、図９の関連テーブル９０１を検索する。具体的には、関連テーブル９０１における項目９０２のエピソード番号と一致するレコードを選択する。ステップ１３０９では、もし上記レコードが存在するならステップ１３１０に進む。存在しないならステップ１３０４に戻る。

以上のステップ１３０１から１３０９までのステップを纏めると、データ提供者が依頼し保管されているデータから、状態名３０３毎に患者がいるか否か検索し、患者がいれば、その組合せ（状態名３０３と患者（患者ＩＤ））が選択されることになる。また、対象エピソードが複数あり、また、患者が複数いる場合は、ステップ１３１０から１３１８を実行毎に、その組合せで順次選択されることになる。

ステップ１３１０では、当該レコードのテーブル名９０３が診療行為であればステップ１３１１に進む。診療行為でなければ、ステップ１３１５に進む。

図９のテーブル名９０３が「診療行為」の場合、ステップ１３０８で選択したレコードについて、参照番号９０４にもとづき、図６の診療行為テーブル６０１のオーダ番号６０２を検索する（ステップ１３１１）。具体的には、参照番号９０４とオーダ番号６０２が一致するレコードを探索し、「人工透析」、「心臓カテーテル」、「検体検査」等の、行為名６０３を取得する。次に、ステップ１３１２では、ステップ１３１１で検索したレコードについて、行為名６０３が、「検体検査」の場合は、ステップ１３１３に進み、「検体検査」でないならばステップ１３１７に進む。「検体検査」の場合（ステップ１３１３）では、図７の検査結果テーブル７０１に対して、ステップ１３０８で選択したレコードの参照番号にもとづき検索を行う。具体的には、左記参照番号と検査結果テーブル７０１の項目７０２のオーダ番号と一致するものを探索する。一致したレコードについては、検査の名称である検査名７０３、検査の結果（数値）である値７０４、検査の結果の値の単位７０５を取得する。

ステップ１３１４では、図１０に示される診断治療知識を検索する。ステップ１３１４の検索では、ステップ１３０２で選択した対象エピソード番号３０２に基づき、図１０の病名セクション１００１におけるエピソード番号と一致するファイルを探索する。このファイルに含まれる診断治療知識は、前述のステップで選択した対象エピソード番号と患者ＩＤで指定される、データ提供者からの診療データの質を評価するのに使用される。

図９のテーブル名９０３が「診療行為」でない場合、ステップ１３１５では、ステップ１３０８で選択したレコードのテーブル名９０３が「処方」であればステップ１３１６に進む。ステップ１３１６では、図８の処方テーブル８０１に対して、ステップ１３０８で選択したレコードの参照番号にもとづき検索を行う。具体的には、左記参照番号と処方テーブル８０１の処方番号８０２とが一致するものを探索する。一致したレコードについては、の薬剤名８０３（「Ｂブロッカー」等）を取得する。ステップ１３１５で、テーブル名９０３が「処方」でないなら、即ち、選択したレコードが「診療行為」でも「処方」でもない場合は、本レコードに対する処理を終了し、ステップ１３０８へ戻る。

ステップ１３１７では、ステップ１３１４で選択した診断治療知識ファイル、図１１の検査-適応疾患テーブル１１０１、図１２の薬剤-適応疾患テーブル１２０１に基づき、ステップ１３１１、ステップ１３１３、ステップ１３１６で取得した、診療行為名、検査結果、処方薬剤の整合性チェックを行う。即ち、ある状態名に対して行った、診療、検査結果、処方薬剤、等が、事前に準備された医学知識（図１０、図１１、図１２）（事前に準備された医学に関する条件「医学条件」）との一致度合い（整合度）のチェックを行う。

また、ステップ１３１７では、ステップ１３０６の対象エピソード番号に関係する、図５のエピソードテーブル５０１、図６の診療行為テーブル６０１、図７の検査結果テーブル７０１、図８の処方テーブル８０１、図９の関連テーブル９０１の全レコードのバイト数を求める。すなわち、図５のエピソードテーブルについては、当該対象エピソード番号に関し、対象エピソード番号５０５をサーチしてヒットしたレコードのバイト数、図９の関連テーブルについては、ヒットしたエピソードテーブルのレコードに含まれたエピソード番号５０２により、エピソード番号９０２をサーチしてヒットしたレコードのバイト数、図６の診療行為テーブルについては、ヒットした関連テーブルのレコードのうち、テーブル名９０３が「診療行為」のものに対して、その参照番号９０４によりオーダ番号６０２をサーチしてヒットしたレコードのバイト数、図７の検査結果テーブルについては、ヒットした診療行為テーブルのレコードのうち行為名６０３が「検体検査」のものに対して、そのオーダ番号６０２により、オーダ番号７０２をサーチしてヒットしたレコードのバイト数、図８の処方テーブルについては、ヒットした関連テーブルのレコードのうち、テーブル名９０３が「処方」のものに対して、その参照番号９０４により処方番号８０２をサーチしてヒットしたレコードのバイト数を求め、その合計バイト数を求める。

ステップ１３１８の結果記録では、上記求めた整合度、データ量（バイト数）は、図５の整合度５０５、データ量５０４に格納される。

以下、上記の整合チェック処理（ステップ１３１７）について具体例で説明する。図３の対象エピソードテーブル３０１の対象エピソード番号０００２の「心筋梗塞」を取り上げる。図５のエピソードテーブル５０１のエピソード番号０００２のレコードは、状態名が「心筋梗塞」である。このエピソード（心筋梗塞（エピソード番号０００２））について図９の関連テーブル９０１において、テーブル名が「診療行為」については２つのレコードが、テーブル名が「処方」については１つのレコードが登録されている。診療行為の参照番号は、０００２と０００３である。図６の診療行為テーブル６０１において、診療行為の参照番号０００２と０００３とに対応するのは、オーダ番号０００２と０００３のレコードであり、そのレコードの行為名はそれぞれ、「心臓カテーテル」および「検体検査」である。この検体検査の結果は、図７の検査結果テーブル７０１において、オーダ番号０００３のものであり、検査名が「CK」と「トロポニン」の２つがある。その値と単位は、「ＣＫ」に対して1500U/Lであり、「トロポニン」に対してである。一方、エピソード番号０００２に関する関連テーブル９０１の処方については、参照番号は０００２である。処方の参照番号０００２に対応する図８の処方テーブル８０１の処方番号０００２のレコードは、薬剤名がアスピリンとなっている。整理すると、エピソード番号０００２の心筋梗塞に対する診療行為として、心臓カテーテルと検体検査が行われていたこと、そして、その検体検査はＣＫとトロポニンの２つが行われており、そのＣＫの結果は1500U/Lであり、トロポニンの結果は0.3Ng/mlであったこと、また、心筋梗塞に対する処方としてアスピリンが投与されたことが、データ提供者からヘルスケア情報サービス事業者に提供され、ストレージに格納されていたことが分かる。以上の検索結果に基づき、まず図１１の検査-適応疾患テーブル１１０１、図１２の薬剤-適応疾患テーブル１２０１、図１０の診断治療知識ファイルに基づき整合性チェックを行う。

まず、検査-適応疾患テーブル１１０１において、項目１１０２の検査名の心臓カテーテルの適用疾患として、項目１１０３の病名１に心筋梗塞が記載されており、エピソード番号０００２の心臓カテーテルと整合している。次に、薬剤-適応疾患テーブル１２０１において、項目１２０２薬剤名のアスピリンの適応疾患として、項目１２０３に心筋梗塞が記載されており、エピソード番号０００２のアスピリンと整合している。

次に、図１０の診断知識ファイルに基づき整合性をチェックする。まずセクション１００１において、対象エピソード番号０００２が記載されており、整合する。セクション１００２の投薬において、アスピリンが記載されており整合するが、モルヒネは処方されていない。セクション１００３の診療行為では、心臓カテーテルが記載されており整合する。また、セクション１００４の検査結果判定では、CK>197とトロポニン>０．２５となっており、エピソード番号０００２は、この条件を満たしており整合している。

以上、エピソード番号０００２では、モルヒネが処方されていない以外は、図１０の診断治療知識ファイルと整合している。ここで整合度は、検査-適応疾患テーブル１１０１に整合している場合に０．３、薬剤-適応疾患テーブル１２０１に整合している場合に０．３、図１０の診断治療知識ファイルに完全に整合しているときには０．４点、部分的に整合している場合には０．３とする。エピソード番号０００２の場合には、診断治療知識ファイルに対する整合度が０．３となり、全体として、整合度は０．９となる。なお、整合度の値は、過去のデータの分析結果等に基づき、手変更可能である。

最後にステップ１３１８では、ステップ１３１７で求めた整合度とデータ量を、図５のエピソードテーブル５０１の項目５０５の整合度および項目５０４のデータ量に記録する。

図１４は、ヘルスケア情報サービス事業者のコンピュータで実行される、記載内容に基づく価値評価部２０３のエピソードごとの所見入力チェック２０７の処理フローを示す。最初に、図１４の処理フローで使用するデータについて説明する。

図１５は、医療機関テーブル１５０１を示す。本テーブルは、会員管理システム１０９により、ヘルスケア情報サービス事業者が作成するものであり、データ提供者である医療機関を管理するためのマスターテーブルであり、医療機関を識別する医療機関ＩＤ１５０２と医療機関名１５０３から構成される。

図１６は、診断データの経過記録ファイルであり、データ提供者１０２がヘルスケア情報サービス事業者に、診療等の経過の記録を依頼する際のデータ項目、データフォーマット例を示す。データの項目としては、患者を識別するための患者ＩＤ（Identifier、識別子）<Patient ID>１６０８、個々の病院や個々の診療所や個々の診断施設を識別する識別である医療機関ＩＤ<Provider ID>１６０７、年月日を識別するための日付<Date>１６０９、患者自身のコメントである<Subjective>１６０２、医者の所見である<Objective>１６１０、医者の解釈である<Assessment>１６１１、病気名である<Problem>１６０１、等を有する。前述の所見には、<Physical findings>１６０３（身体所見）、<Vital Signed>１６０５等で表記される、検査の種類、検査結果、治療行為、投薬、等が含まれ、所見の項目や内容に応じて自由に追加できる。データフォーマット構造は、例えば、図に示すようなＸＭＬの構成である。

図１７は、質評価用所見テーブル１７０１を示す。本テーブルは、データ提供者である医療機関ごと、所見にもとづくデータの質評価を行うための、評価指標を管理するテーブルである。評価対象である医療機関を識別する医療機関ＩＤ１７０２、評価対象となった対象エピソードを識別する対象エピソード番号１７０５、当該対象エピソードに関する経過記録に含まれる所見項目数である所見数１７０３、当該医療機関および対象エピソードに関する経過記録に対して、左記所見項目がどれくらい記載されているかの割合を示す記載割合１７０４、所見数および記載割合をエントリした登録日１７０６から構成される。このテーブルのデータは、ヘルスケア情報サービス事業者のデータ価値評価部１０６のエピソードごとの所見入力チェック２０７により生成される。

図１４のステップ１４０１では、図３で示す対象エピソードテーブル３０１から全レコードを取得し、処理対象のエピソードのリストとしてメモリ上に管理するステップ１４０２では、このリストから対象エピソードを一つ選択する。ステップ１４０３では、もし対象となるエピソードが存在するなら、ステップ１４０４に進む。もし対象エピソードが存在しないなら、ステップ１４１０に進み処理を終了する。

ステップ１４０４では、図１５の医療機関テーブル１５０１から１レコードを取り出し医療機関を選択する。ステップ１４０５では、もし医療機関が存在すればステップ１４０６に進む。存在しないなら、ステップ１４０２に戻る。

ステップ１４０６では、ステップ１４０２で選択した対象エピソードおよびステップ１４０４で選択した医療機関IDに関する全ての経過記録ファイルを、図１のヘルスケアデータが格納されているストレージ１０８から検索する。具体的には図１６の構造を持つ経過記録ファイルに関し、タグ１６０１のProblemタグおよびタグ１６０７のProvider IDタグを調べ、当該医療機関IDと当該対象エピソードが記載された全ファイルを、図１のストレージ１０８から検索することになる。

ステップ１４０７では、ステップ１４０６で収集した経過記録ファイルに対して、タグ１６０３のObjective（所見）に現れるタグを調べ、その数をカウントする。なおステップ１４０７では、タグObjectiveを対象としているが、調べる対象となるタグをObjectiveに制限するわけではない。図１６の場合、タグ１６０３のPhysical Findingsの中にタグ１６０４のKillipが存在する。これは、急性心筋梗塞に伴う左心不全の重症度分類（Killip分類）を表す。そのClassIIは、心不全（肺野の５０％以下にラ音聴取、等）を示す。また、タグ１６０５のVital Signedの中に、タグ１６０６のSBPタグが存在する。これは、収縮期血圧を表す。以上から、図１６の場合、所見タグが２つあることになる。このような探索を、ステップ１４０６で収集した全経過記録ファイルについて行う。

ステップ１４０８では、ステップ１４０７で収集した所見タグについて、ステップ１４０６で収集した全経過記録ファイルを対象に、実際に記載がなされている記載割合を求める。図１６の場合は、KillipタグにはClass IIが記載されており、SBP タグには900mmHgが記載されている。もしステップ１４０７で収集した所見タグがKillipタグとSBP タグだけだとすると、このファイルの場合、両方とも記載があるので記載割合は100％になる。片方の場合は、５０％となる。

ステップ１４０９では、ステップ１４０２で選択した対象エピソード、ステップ１４０４で選択した医療機関の医療機関ID、および、当該医療機関に関するステップ１４０７でカウントした所見タグの数と、ステップ１４０８で求めた記載割合を、図１７の質評価用所見テーブルの項目１７０２の医療機関ID、項目１７０３の所見数、項目１７０４の記載割合に登録する。また、登録の日付である登録日１７０６を登録する。結果記録が終了すると、ステップ１４０４へ戻り、再度病院選択を行う。

全ての対象エピソードと全ての病院とに関して、記載割合の計算および記録が終了するまで、ステップ１４０２からステップ１４１０を実行する。

以上、図１４を用いて説明したように、病院毎に、かつ、対象エピソード毎に、データ提供者が提供するデータの記載割合を記録することができる。この結果、この記載割合に応じた診療データの質の評価が可能となる。

図１８は、ヘルスケア情報サービス事業者のコンピュータで実行される、図２のビット単価計算部２０４の処理フローを示す。まず、この処理フローで用いるテーブル（図１９、図２０）について説明する。

図１９は、課金情報テーブル１９０１を示す。本テーブルは、データ提供者１０２である医療機関ごとに、データ保管料金の基準となるビット単価１９０４、および、ビット単価を計算するために必要となる評価情報を管理するテーブルである。医療機関を識別する医療機関ＩＤ１９０２、ビット単価を計算するに際して、割引のないビット単価１９０４である基準額に対し、何割割り引いたかの数値である割引率１９０３、当該医療機関のデータ保管量１９０５、このデータ保管量に対してデータの価値にもとづき割り引いたデータ量を表すデータ総量１９０６、診断医療知識にもとづき整合性をチェックし算出した整合度の当該医療機関の平均値である平均整合度１９０７、当該医療機関の所見項目数である所見数１９０８、当該医療機関における経過記録に対して、左記所見項目がどれくらい記載されているかの割合を示す平均記載割合１９０９から構成される。このテーブルのデータは、ヘルスケア情報サービス事業者のデータ価値評価部１０６が生成する。

図２０は、データ購入量テーブル２００１を示す。本テーブルは、各データ消費者１０３が購入したデータ量を、データ提供者ごとに管理するテーブルであり、データ消費者を識別するデータ消費者ＩＤ２００２、データ提供者を識別するデータ提供者ＩＤ２００３、当該データ提供者から購入したデータ量を表す購入量２００４から構成される。本テーブルのデータは、ヘルスケア情報サービス事業者のデータ販売部１０７がデータの販売実績にもとづき生成する。

ビット単価計算部２０４は、図１８のステップ１８０１では、図１５の医療機関テーブル１５０１から１レコードを取り出し医療機関を選択する。ステップ１８０２では、もし医療機関が存在すればステップ１８０３に進む。存在しないなら、ステップ１８１５で、終了する。

ステップ１８０３では、図３で示す対象エピソードテーブル３０１から全レコードを取得し、処理対象のエピソードのリストとしてメモリ上に管理する。ステップ１８０４では、このリストから対象エピソードを一つ選択する。ステップ１８０５では、もし対象となるエピソードが存在するなら、ステップ１８０６に進む。もし対象エピソードが存在しないなら、ステップ１８１２に進む。

ステップ１８０６では、上記医療機関について、ステップ１８０４で選択した対象エピソードにもとづき、図５のデータ量５０４と整合度５０５が記入されたエピソードテーブル５０１と、図１７の所見数１７０３と記録割合１７０４が記入された質評価用所見テーブル１７０１を検索する。

まず、図５のエピソードテーブル５０１については、図４の患者テーブル４０１の医療機関ID４０３を検索して、当該医療機関を受診している患者リストを作成する。そして、エピソードテーブル５０１から、前述の患者リストに含まれる患者IDを含むレコードを、患者ID５０３に着目して抽出した後に、抽出したレコードの項目５０６の対象エピソード番号によりさらに絞り込む。ここで絞り込んだ全レコードに対して、項目５０４のデータ量を取り出し、その合計を計算する。纏めるとステップ１８０６では、選択した医療機関に対して、対象エピソードを対象に、該当する全患者分のデータ量の合計値を計算する。

更に、ステップ１８０６では、図１７の質評価用所見テーブル１７０１について、対象エピソード番号１７０５で探索され選択されたレコードの所見数１７０３を取り出す。最後に、図５の項目５０４のデータ量の合計値と、図１７の所見数との和を計算して、当該医療機関のデータ保管量を求める。即ち、図１８のステップ１８０６において、選択した医療機関に関して、対象エピソードに対して、ストレージに格納されているデータ保管量（データ量の合計値と所見数との和）を計算する。

ステップ１８０７では、ステップ１８０６にてエピソードテーブル５０１から選択した全レコードに対する、項目５０５の整合度の平均値（平均整合度）を計算する。

ステップ１８０８では、ステップ１８０６にてエピソードテーブル５０１から選択した全レコードに対する、項目５０４のデータ量の合計値を計算する。なお、この値は、図５のエピソードテーブル、図６の診療行為テーブル、図７の検査結果テーブル、図８の処方テーブル、図９の関連テーブルに関係するデータに対するデータ保管量であり、ステップ１８０６のデータ保管量は、これに所見数が加わったものである。ステップ１８０９では、ステップ１８０７で求めた整合度の平均値とステップ１８０８で求めたデータ量の合計値の積により、重み付きデータ総量を求める。すなわち、実際のデータ保管量を、平均整合度により重み付けを行うことで、整合度の高いデータ量がどれだけあるか算出していることになる。

ステップ１８１０では、ステップ１８０６にて質評価用所見テーブル１７０１から選択した全レコードに対する、所見数１７０３と記載割合１７０４との積により、重み付き所見数を求める。

ステップ１８１１では、ステップ１８０７で求めた重み付きデータ総量と、ステップ１８１０で重み付き所見数の和をとる（この和の値をＢとする）。

ステップ１８１２では、ステップ１８１１にて、対象エピソードごとに求めた重み付きデータ総量と重み付き所見数の和に対して、対象エピソードに関する線形和を計算する。ここでは、その結果をCとおく。

ステップ１８１３では、割引が無いビット単価である基準単価に対して、どれだけ割り引くかの割合を決める割引率と、基準単価と割引率の積によりビット単価を計算する。
割引率は、Ｃを用いて次のように求める。ステップ１８０６で求めた対象エピソード毎のそれぞれのデータ量の合計値を用いて、当該対象とした医療機関のデータ保管量を求め、この医療機関のデータ保管量に占めるCの割合（この値をＤとする）を求める。この割合Dは、当該医療機関が保管するデータに占める重要データの割合を示すことになる。ここで所定の下限値をEとしたとき、D-Eを求める。D-E>0なら、D-Eを割引率とする。また、D-E≦0なら割引はなしとする。たとえば、E=50とすれば、Dが80%であれば、30%の割引を受けることができることになる。ここで、下限値Eは、割引率の幅を制御するために設ける数値である。例えば、E=50の場合、割引率は1〜50%であり、E=40の場合、割引率は1〜60%となり、Eの値を引き下げるほど、割引率の幅は大きくなる。

ステップ１８１４では、図１９の課金情報テーブル１９０１に対し、ステップ１８１３で求めた当該医療機関に対する割引率とビット単価を、それぞれ項目１９０３の割引率、項目１９０４のビット単価に記録する。また、ステップ１８０６で求めたデータ保管量について、ステップ１８０３で検索した全対象エピソードに関する和をとり、項目１９０５のデータ保管量に記録する。また、図５エピソードテーブル５０１の整合度５０５について、ステップ１８０３で検索した全対象エピソードに関する平均をとり、項目１９０７の平均整合度に記録する。同様に、図５エピソードテーブル５０１のデータ量５０４について、ステップ１８０３で検索した全対象エピソードに関する和をとり、項目１９０６のデータ総量に記録する。また、図１７の評価用所見テーブル１７０１の所見数１７０３について、ステップ１８０３で検索した全エピソードに関する和をとり、項目１９０８の所見数に記録する。また、図１７の評価用所見テーブル１７０１の記載割合１７０４については、ステップ１８０３で検索した全エピソードに関する平均をとり、項目１９０９の平均記載割合に記録する。

以上説明したように、ステップ１８０１および１８０２で選択した医療機関に対し、ステップ１８０３からステップ１８１４を実行することで、図１９のある特定医療機関に対する項目１９０３から１９０９を記録する。これらステップを繰り返すことで、全ての医療機関それぞれに対して項目１９０３から１９０９を記録する。

以上では、保管するデータの整合度、質（所見の記載の割合い）に基づくビット単価の計算（データ提供者に対するデータ保管料の割引）を説明したが、以下では、データ購入者が購入したデータ量の多いデータ提供者のデータ保管料を割り引く場合を説明する。ここで、図１８のステップ１８１３で説明した、所定の下限値Eは、データ消費者１０３のデータ購入量に応じて調整しても良い。

図２０は、データ購入量テーブル２００１であり、データ消費者ＩＤ２００２で管理されるデータ消費者ごとに、どのデータ提供者（データ提供者ＩＤ２００３で管理される）からどれだけデータを購入したかを管理している。ここで、項目２００３のデータ提供者IDごとに、項目２００４の購入量の集計値を計算する。

図２１は、集計値にもとづき、下限値Eを変化させる場合を示す。図２１では、購入量が１ＴＢ（点２１０２）までは下限値Eが50だが、購入量が２ＴＢ（点２１０１）と購入量が増えるにつれて、下限値Eを40、30と引き下げる。下限値Eの値を引き下げるほど、割引率の幅は大きくなるので、下限値Eを設定すれば購入量が多いデータ提供者１０２ほど、多くの割引率を得ることができる課金モデルを構築できる。下限値Ｅの値は、ヘルスケア情報サービス事業者が、管理端末３３０３から事前に入力し、メモリ／記憶装置３３０５に記憶しておく。

一方、データ提供者の入出力インターフェースにもとづく、図１６の経過記録ファイルを構成するデータの入力であるが、データ消費者１０３が欲しい所見情報を提示するという運用が考えられる。この運用により、データ提供者は、データ消費者がどのような所見を入力して欲しいか知る事ができ、この所見データの入力を増やすことで、データ保管料の更なる割引を享受することが可能になる。この処理フローを図２２により説明する。まず、データ消費者による、入力してほしい所見項目の指定について図２３を用いて説明し、データ提供者が所見等を入力する入力画面について図２４を用いて説明する。図２３は、データ消費者が、入力して欲しい所見項目を規定するＸＭＬファイルであり、データ消費者が作成するテンプレートである。データ管理部１０５は、データ消費者のコンピュータからネットワークを介して受信した当該ＸＭＬファイルを、ストレージに保管する。本ファイルは、Subjectタグ２３０７、Objectiveタグ２３０２、Physical Findingsタグ２３０３、Killipタグ２３０４、Vital Signedタグ２３０５、SBPタグ２３０６、Assessmentsタグ２３０８、Problemタグ２３０１から構成されている。この図では、ProblemタグによるProblemセクションに、「心筋梗塞（対象エピソード番号０００２）」が記載されている。また、Physical FindingsタグによるPhysical Findingsセクションに、KillipタグによるKillipセクションが指定されていることから、「心筋梗塞（対象エピソード番号０００２）」の場合に、Killipの入力を促す。同様に、Vital SignedタグによるVital Signedセクションには、SBPタグによるSBPセクションが指定されていることから、「心筋梗塞（対象エピソード番号０００２）」の場合に、SBPの入力を促すこと意味している。

図２４は、データ提供者が所見等を入力するデータ入力画面２０４１の例を示す。データ入力画面は、患者ＩＤ、患者氏名、プロブレム２４０３、Subjective２４０３、Objective２４０４、Assessment２４０７等から構成される。データ提供者である医師等はこの画面に従って、所見等の入力を行う。

次に、図２２に基づき、データ提供者がデータを入力するときのフローについて説明する。医師は、図２４の所見入力画面に従い、患者ＩＤ，患者氏名等の入力を開始する。ステップ２２０１において、図２４のプロブレム入力領域２４０２にエピソードとして病名を入力する。この入力は、データ提供者のコンピュータから、ネットワーク経由でヘルスケア情報サービス事業者１０１のコンピュータに送信される。ステップ２２０２では、サービス事業者１０１のコンピュータは、ステップ２２０１で入力されたエピソード（病名）に関する、図２３で説明したデータ提供者が入力項目を指定したテンプレートが、ストレージ１０８に記憶されていないかを、テンプレートのProblemタグ２３０１のエピソード情報にもとづき、検索される。なお、このテンプレートは、事前にデータ消費者が図２３のフォームで指定してストレージに登録されているものとする。検索して、エピソードに関係するテンプレートが見つかると、このテンプレートを選択する。ステップ２２０３では、ステップ２２０２の結果として、指定したエピソードに対応するテンプレートがある場合は、テンプレート表示ステップ２２０４へ進む。無い場合は、ステップ２２０１へ戻る。なお、戻った後は、本エピソードに関してはテンプレートが無いものとして、医師が自分の判断で所見等の入力を継続する。なお、検索結果は、データ提供者のコンピュータへ、テンプレートの内容と共に、通知される。

ステップ２２０４では、データ提供者のコンピュータは結果を受信すると、選択されたテンプレートにもとづき、所見入力画面２４０１を変更する。たとえば、図２３のテンプレートの場合、タグ２３０３のPhysical Findingsの中に、タグ２３０４のKillipが存在する。また、タグ２３０５のVital Signedの中に、タグ２３０６のSBPタグが存在する。この情報にしたがい、図２４の所見入力画面２４０１のObjective２４０４の領域では、タグ２３０４のKillipに対応する領域２４０５、タグ２３０６のSBPタグに対応する領域２４０６が出現する。一方、Subjectiveタグ２３０７、Assessmentタグ２３０８の内部は詳細なタグはないので、所見入力画面２４０１のSubjective領域２４０３とAssessment領域２４０７には、詳細な情報は表示されない。

ステップ２２０５において、ステップ２２０４で表示された所見入力画面２４０１にもとづきデータ入力が行われる。データ入力が終了すると、データ提供者のコンピュータは、ヘルスケア情報サービス事業者のコンピュータへ、テンプレートに指定された項目が入力されたデータをネットワークを介して送信する。

上記により、データ消費者が入出力端末を介して指定した所見等のデータが、ヘルスケア情報サービス事業者のコンピュータのストレージに格納される。

また、図１８のステップ１８１４では、図２５に示すような課金情報明細書２５０１を、各データ提供者に発行する運用が考えらえる。これにより、各データ提供者は、割引率の根拠を把握することが可能になる。具体的には、課金システム１１０は、図１９の課金情報テーブル１９０１から、医療機関ごとの割引率１９０３、ビット単価１９０４、データ保管量１９０５、データ総量１９０６、平均整合度１９０７、所見数１９０８、平均記載割合１９０９を検索する。これらの情報をそれぞれ、図２５の割引率２５０３、ビット単価２５０４、データ保管量２５０５、データ総量２５０６、平均整合度２５０７、所見数２５０８、平均記載割合２５０９に表示する。

また、図２０の購入量テーブル２００１から医療機関ごとに、購入量２００４を検索する。この情報を、図２５の購入量２５１０に表示する。

なお、図２５の課金明細書の発行は、ヘルスケア情報サービス事業者のコンピュータが、上述のようにデータを収集して、ネットワークを介して、データ提供者に、電子データとして送信することで提供しても良いし、入出力機器を介して印刷し、紙の明細書として報告しても良い。

（実施例２）
図２６は、図１のデータ価値評価部１０６の処理フローの一部を変形したものを示す。本実施例（実施例２）では、実施例１の記載内容に基づく価値評価に加えて、類似症例にもとづく価値評価部２６０１を設ける。類似症例にもとづく価値評価部２６０１は、類似症例のデータ量評価２６０２、データ量に基づく価値評価２６０３からなる。ここでは、データ消費者が集めたい類似症例数を提供するデータ提供者ほど、データ保管料の割引が受けられる課金モデルを説明する。

以下、上記を実現するシステムが扱うデータ構成について説明する。

図２９は、データ消費者が欲しい類似症例を検索するための検索条件に関わるＸＭＬファイルであり、データ消費者が作成する検索テンプレートである。データ管理部１０５は、データ消費者のコンピュータからネットワークを介して受信した当該ＸＭＬファイルを、ストレージに保管する。本ファイルは、ＩＤタグ２９０８、Episodeタグ２９０１、Predictor variablesタグ２９０６、Physical Findingsタグ２９０２、Vital Signedタグ２９０３、Lab Resultsタグ２９０４、Target variablesタグ２９０７、Sample Sizeタグ２９０５から構成されている。この図２９では、EpisodeタグによるEpisodeセクションに、「心筋梗塞（対象エピソード番号０００２）」が記載されている。また、Physical FindingsタグによるPhysical Findingsセクションに、Killipが指定されていることから、「心筋梗塞（対象エピソード番号０００２）」の場合、検索条件としてKillipが入力されている類似症例が欲しいことを示している。同様に、Vital SignedタグによるVital Signedセクションには、SBPが指定されており、Lab ResultsタグのLab ResultsセクションにはCKが指定されていることから、「心筋梗塞（対象エピソード番号０００２）」の場合、検索条件としてSBPとCKが入力されている類似症例が欲しいことを示している。最後に、Sample SizeタグによるSample Sizセクションでは2000が指定されており、「心筋梗塞（対象エピソード番号０００２）」の場合、上記の検索条件にマッチした類似症例として2000以上の症例が欲しいことを示している。

図３０は、類似症例テーブル３００１を示す。本テーブルは、対象エピソードごとの類似症例に関する情報を管理するものであり、対象とするエピソードを特定する対象エピソード番号３００２、類似症例検索のための検索条件に関するテンプレートを特定する検索テンプレート番号３００３、当該テンプレートに基づく検索によりヒットした類似症例数３００４、当該類似症例に関しユーザ消費者が設定する目標サンプル数３００５、および当該レコードの登録日３００６から構成される。類似症例数を除く本テーブルのデータは、データ消費者が作成し、データ管理部が、データ消費者のコンピュータからネットワークを介して受信した当該データを、ストレージに保管する。

図３１は、質評価用類似症例テーブル３１０１を示す。本テーブルは、医療機関ごとの類似症例に関する情報を管理するものであり、医療機関を特定する医療機関ＩＤ３１０２、対象となるエピソードを特定する対象エピソード番号３１０３、類似症例検索のための検索条件に関するテンプレートを特定する検索テンプレート番号３１０４、目標サンプル数に占める、検索テンプレート番号による検索テンプレートにより検索した類似症例数の割合を示す割合３１０５、および、当該レコードの登録日３１０６から構成される。本テーブルのデータは、ヘルスケア情報サービス事業者のデータ価値評価部１０６が、図３２に示す処理の過程で作成する。

図２７は、図２６の類似症例にもとづく価値評価部２６０１の処理フローを示す。

ステップ２７０１では、図３で示す対象エピソードテーブル３０１より、処理対象のエピソードのリストを取得する。ステップ２７０２では、このリストから対象エピソードを一つ選択する。ステップ２７０３では、もし対象となるエピソードが存在するなら、ステップ２７０４に進む。もし対象エピソードが存在しないなら、ステップ２７１０に進み処理を終了する。

ステップ２７０４では、対象エピソードを含む検索テンプレートファイルをすべて検索する。ステップ２７０５では、この検索テンプレートファイルの一つを選択する。ステップ２７０６では、もし検索テンプレートファイルが存在するなら、ステップ２７０７に進む。もし無いなら、ステップ２７０２に戻る。

ステップ２７０７では、ステップ２７０５の検索テンプレートにより、類似症例を検索する。検索テンプレートのファイル構造は、図２９で説明した通りである。ステップ２７０７の検索では、Episodeタグ２９０１の記載内容に着目して行われる。図２９の例で説明すると、Episodeタグ２９０１、Physical Findingsタグ２９０２、Vital Signedタグ２９０３、Lab Resultsタグ２９０４にはそれぞれ、心筋梗塞（対象エピソード番号：0002）、Killip、SBP、CKが記載されている。本実施例では、所見のKillip、SBPと検体検査CKが対象とする。なお、処方など他の診療行為が検索対象となることがある。

最初に、検体検査ＣＫを対象とする場合を説明する。ステップ２７０２で選択した対象エピソード番号にもとづき、図５のエピソードテーブル５０１から、項目５０６の対象エピソード番号を検索し、ヒットしたレコードから項目５０２のエピソード番号を取得する。次に、このエピソード番号にもとづき、図９の関連テーブル９０１の項目９０２を検索する。ここで、Lab Resultsは検体検査の結果であるから、項目９０３のテーブル名が診療行為のレコードを抽出し、項目９０４の参照番号を取り出す。次に、図６０１の診療行為テーブル６０１に対し、左記参照番号にもとつき、項目６０２のオーダ番号を検索し、項目６０３の行為名が検体検査のレコードを抽出、その項目６０２のオーダ番号を取り出す。このオーダ番号にもとづき、図７の検査結果テーブル７０１を検査し、項目７０３の検査名がCKのレコードを検索する。検査名がCKのレコードが存在するなら、ステップ２７０２でヒットしたレコードは、当該検索テンプレートの類似症例候補となる。

次に、所見のKillip、SBPを対象とする場合を説明する。まず、図１６のタグ１６０１のProblemが対象エピソード番号0002の所見ファイルすべてを検索する。当該所見ファイルにおいて、タグ１６０３のPhysical Findingsの内部にKillipタグがあり、かつ、タグ１６０５のVital Signedの内部にSBPタグがあるものが、当該検索テンプレートの類似症例候補となる。

ステップ２７０８では、ステップ２７０２で選択した対象エピソードに対し、ステップ２７０５で抽出した類似症例候補の数をカウントする。

ステップ２７０９では、ステップ２７０２で選択した対象エピソードの対象エピソード番号、ステップ２７０５で選択した検査テンプレートの検査テンプレート番号、ステップ２７０７でカウントとした類似症例数、当該検査テンプレートのタグSample Size２９０５に記載の目標サンプル数について、図３０の類似症例テーブル３００１の、項目３００２の対象エピソード番号、項目３００３の検索テンプレート番号、項目３００３の類似症例数、項目３００４の目標サンプル数に、それぞれ記載する。結果記録が終了すると、ステップ２７０５へ戻り、次の検索テンプレートを検索する。

以上説明したように、図２７のフローを実行することで、対象エピソード毎、検索テンプレート毎の類似症例候補を検索することができる。

図２８は、データ量に基づく価値評価部２６０３の処理フローを示す。

ステップ２８０１では、図３で示す対象エピソードテーブル３０１より、処理対象のエピソードのリストを取得する。ステップ２８０２では、このリストから対象エピソードを一つ選択する。ステップ２８０３では、もし対象となるエピソードが存在するなら、ステップ２８０４に進む。もし対象エピソードが存在しないなら、ステップ２８１４に進み処理を終了する。

ステップ２８０４では、図１５の医療機関テーブル１５０１から、医療機関すべてを検索する。

ステップ２８０５では、この医療機関の一つを選択する。ステップ２５０６では、もしレコードが存在するなら、ステップ２８０７に進む。もしないなら、ステップ２８０２に戻る。

ステップ２８０７では、ステップ２８０２で選択した対象エピソードを含む検索テンプレートファイルをすべて検索する。ステップ２８０８では、この検索テンプレートファイルの一つを選択する。ステップ２８０９では、もし検索テンプレートファイルが存在するなら、ステップ２８１０に進む。もしないなら、ステップ２８０５に戻る。

ステップ２８１０では、ステップ２８０８で選択した検索テンプレートにもとづき、ステップ２８０５に選択した医療機関に関して、類似症例検索を行う。まず、ステップ２８０４で選択した医療機関を受診する患者を図４の患者テーブル４０１から選択する。具体的には、患者テーブル４０１における項目４０３の医療機関IDに着目し、当該医療機関を受診する患者のリストを作る。

ここでは、前述の図２９の検索テンプレートにもとづき説明する。

また、ステップ２８１０では、ステップ２８０２で選択した対象エピソード番号および上記患者リストの患者IDにもとづき、図５のエピソードテーブル５０１から、項目５０６の対象エピソード番号および項目５０３の患者IDを検索し、ヒットしたレコードから項目５０２のエピソード番号を取得する。

次に、ステップ２８１０では、このエピソード番号にもとづき、図９の関連テーブル９０１の項目９０２を検索する。ここで、Lab Resultsは検体検査の結果であるから、項目９０３のテーブル名が診療行為のレコードを抽出し、項目９０４の参照番号を取り出す。次に、図６の診療行為テーブル６０１に対し、取り出した参照番号にもとつき、項目６０２のオーダ番号を検索し、項目６０３の行為名が検体検査のレコードを抽出、その項目６０２のオーダ番号を取り出す。このオーダ番号にもとづき、図７の検査結果テーブル７０１を検査し、項目７０３の検査名がCKのレコードを検索する。検査名がCKのレコードが存在するなら、ステップ２８０２でヒットしたレコードは、当該検索テンプレートの類似症例候補となる。

次にまた、ステップ２８１０では、所見ファイルについて、図１６（診療データの経過記録ファイル）のタグ１６０１のProblemが対象エピソード番号0002およびタグ１６０８のPatient IDが上記患者IDのものを検索する。当該所見ファイルにおいて、タグ１６０３のPhysical Findingsの内部にKillipタグがあり、かつ、タグ１６０５のVital Signedの内部にSBPタグがあり、両タグともに記載があることから、当該検索テンプレートの類似症例候補となる。最後に、上記類似症例候補の個数をカウントして、類似症例数を求める。 ステップ２８１１では、図３０の類似症例テーブルの項目３００５から、ステップ２８０２で選択した対象エピソードに関する目標サンプル数を取り出す。

ステップ２８１２では、ステップ２８１１で検索した目標サンプル数に対する、ステップ２８１０で求めた類似症例数の割合を計算する。ここで、この割合が1以上の場合は、1とする。この目標サンプル数に対する類似症例数の割合は、１に近いほどデータ消費者の要望に沿うことになる。

ステップ２８１３では、ステップ２８０５で選択した医療機関の医療機関ID、ステップ２８０２で選択した対象エピソードの対象エピソード番号、ステップ２８０８で選択した検索テンプレートの検索テンプレート番号、ステップ２８１２で計算した類似症例数と目標サンプル数の比を、図３１も質評価用類似症例テーブル３１０１の、項目３１０２の医療機関ID、項目３１０３の対象エピソード番号、項目３１０４の検索テンプレート番号、項目３１０５の割合に、それぞれ記録する。また、登録日３１０６を記録する。ステップ２８１３が終わると、ステップ２８０８へ戻り、次の検索テンプレートに対して同様な手続を繰り返す。

以上、図２８で説明したように、対象エピソード、医療機関、かつ、検索テンプレート毎に、質評価用類似症例テーブル３１０１が記録される。

次に、図２６のビット単価計算部２６０４について、図３２によって説明する。この図３２は、ステップ３２０１、ステップ３２０２とステップ３２０３以外は、図１８のフローと同じであり、これらステップのみ説明する。ステップ３２０１は、図１８のステップ１８０６に加えて、ステップ３２０２への分岐フローを持つ。ステップ３２０２では、ステップ１８０４で選択した対象エピソードに対して、図３１の質評価用類似症例テーブル３１０１の項目３１０５の割合を取り出す。ステップ３２０３では、重み付けデータ総数と、重み付け所見数との和に対して、ステップ３２０２で取り出した割合との積をとり、この値を図１８のステップ１８１１の値「Ｂ」とする。この後のステップは、図１８の処理と同じである。データの価値評価の観点では、データ消費者の求める目標サンプル数に近いほど、重み付けデータ総数＋重み付け所見数の役割が大きくなる。つまり、図３２のステップ３２０２およびステップ３２０３により、目標サンプル数の割合が、ヘルスケア情報のデータ保管料金に反映されることになる。

以上説明したように、２次利用を可能とする充実したデータを蓄積した病院などの医療機関に対して、当該医療機関がデータ保管にかかる費用を、そのデータの質に応じて割り引くことを可能とするシステムを提供する。そのため、医療機関は、保管費用を抑えるというインセンティブが働き、その結果、質の高い、２次利用に適する医療データの収集が進められる。このシステムの核は、記載内容の質と充実度に基づくデータの評価であり、その評価結果に基づいて保管費用の割引率を算定する。記載内容の質と充実度に基づく評価は、病名などのエピソードに対して、処方・検体検査などの診療行為および検査結果について、その関係性を規定する診断治療知識にもとづき整合性をチェックすることで行い、整合度の高いデータが多いほど、データの質が良いと判断する。加えて、所見入力におけるフリーテキストデータの定型入力箇所の記載割合を評価し、この記載割合が大きいほど、データの質が高いと評価する。ここで、データ消費者のデータ購入量が大きいほど、割引率を高める処理を追加しても良い。さらに、所見入力の質と充実度を高めるために、データ消費者がその入力項目を指定し、医療機関のデータ入力画面に表示する運用を付け加えても良い。また、上記の質と充実の評価結果、割引率、データ購入量を医療機関に提示する運用を付け加えても良い。

言い換えれば、上記説明したシステムは、臨床研究等のデータ２次利用のための、データの質と充実度の改善努力が、ストレージ利用料の割引という形で還元される機能を提供するので、データ提供者の努力が金銭的に正当化されることを可能とする。また、本システムの機能により、データ提供者が提供するデータの質と充実度の改善が期待されるので、結果として、データ消費者は、データの２次利用に必要となるデータセットを容易に取得することが可能になる。更に、本システムの機能により、ヘルスケアサービス事業者は、蓄積するデータの質と充実度が改善することが期待できるので、多くのデータ消費者を引き付けることが可能になる。

１０１ ヘルスケア情報サービス事業者
１０２ データ提供者
１０３ データ消費者
１０４ コンテンツ管理システム
１０５ データ管理部
１０６ データ価値評価部
１０７ データ販売部
１０８ ストレージ
１０９ 会員管理システム
１１０ 課金システム
２０３ 記載内容に基づく価値評価部
２０４ ビット単価計算部
２０５ 課金情報処理部
２６０１ 類似症例に基づく価値評価部
２６０２ 類似症例のデータ評価部
２６０３ データ量に基づく価値評価部

データ消費者１０３は、データ消費者が使用するコンピュータ３３１６を用いて、希望する診療データを指定した要求を含む要求メッセージ／信号／パケット等をヘルスケア情報サービス事業者が有するコンピュータへ送信する。そして、データ消費者１０３のコンピュータは、指定した診療データをヘルスケア情報サービス事業者のコンピュータから受信し記憶する。データ消費者はこの記憶した診療データを分析することで、データ消費者が本来の研究や健康増進業務を進めることが可能となる。ここで、コンピュータ３３１６は、ＣＰＵ３３１４、メモリ／記憶装置３３１５、通信ネットワーク３３０７との通信インタフェース３３１７、入出力機器３３１９、入出力機器との入出力インタフェース３３１９等で構成され、メモリ／記憶装置上のプログラムを実行することで、必要な診療データをヘルスケア情報サービス事業者へ依頼し、また、依頼したデータを受信する。データ消費者のコンピュータは、依頼した診療データを受診すると、自動的に銀行に支払い指示を出し、銀行からヘルスケア情報サービス事業者に支払いをするようにしてもよい。

図１２は、薬剤-適応疾患テーブル１２０１を示す。本テーブルは、各薬剤の適応疾患を管理するマスターテーブルであり、診断治療知識の一つである。本テーブルは、薬剤名１２０２、当該薬剤に適応する病名１２０３から構成される。ここで、ある薬剤がある病名に対して適応であるとは、当該病名が疑われる場合に、当該薬剤の処方に妥当性があることを意味する。検査-適応薬剤テーブルは、図１０と同様に、データ管理部１０５によりヘルスケア情報サービス事業者が、事前に、ストレージに格納しておく。この診断医療知識は、データ提供者が提供する診療データの質を評価する際に使用される。診療データの質は、この知識と、どの程度一致するかで質が評価されることになる。

記載内容に基づく価値評価部２０３は、エピソード、診療行為、検査結果、等のデータが、所望の対象や項目や内容や品質で収集されているかを評価するためのチェック（例えば、事前に準備された指標や事前に定義された項目との整合性をチェック）を行うステップ２０６と、エピソードごとの所見（検査項目、検査結果、診断結果、処方、等）が入力されているか否かをチェックするステップ２０７とから構成される。なお、所見は、フリーテキストデータ定型入力で行われるものとする。ビット単価計算部２０４は、この評価したデータ価値に基づき、当該データ提供者のデータ保管に対するビット単価を計算し、課金情報更新処理２０５では、単価計算部２０４で計算したビット単価情報を、図１の課金システム１１０に通知する。

このように、データ価値評価部は、データ提供者が提供したデータを評価し、評価結果に基づきデータを保管するためのビット単価を計算し、保管費用を決定する。データを評価してビット単価を定めるので、例えば、評価結果が良いデータに対する保管料金を、評価結果が良くないデータに対する保管料金を安くすることで、データ提供者はデータ保管料を安く押さえる目的で質の良いデータを提供しようとし、ヘルスケア情報サービス事業者は効果的に質の良いデータを収集することができる。

以下、上記の整合チェック処理（ステップ１３１７）について具体例で説明する。図３の対象エピソードテーブル３０１の対象エピソード番号０００２の「心筋梗塞」を取り上げる。図５のエピソードテーブル５０１のエピソード番号０００２のレコードは、状態名が「心筋梗塞」である。このエピソード（心筋梗塞（エピソード番号０００２））について図９の関連テーブル９０１において、テーブル名が「診療行為」については２つのレコードが、テーブル名が「処方」については１つのレコードが登録されている。診療行為の参照番号は、０００２と０００３である。図６の診療行為テーブル６０１において、診療行為の参照番号０００２と０００３とに対応するのは、オーダ番号０００２と０００３のレコードであり、そのレコードの行為名はそれぞれ、「心臓カテーテル」および「検体検査」である。この検体検査の結果は、図７の検査結果テーブル７０１において、オーダ番号０００３のものであり、検査名が「CK」と「トロポニン」の２つがある。その値と単位は、「ＣＫ」に対して1500U/Lであり、「トロポニン」に対して0.3Ng/mlである。一方、エピソード番号０００２に関する関連テーブル９０１の処方については、参照番号は０００２である。処方の参照番号０００２に対応する図８の処方テーブル８０１の処方番号０００２のレコードは、薬剤名がアスピリンとなっている。整理すると、エピソード番号０００２の心筋梗塞に対する診療行為として、心臓カテーテルと検体検査が行われていたこと、そして、その検体検査はＣＫとトロポニンの２つが行われており、そのＣＫの結果は1500U/Lであり、トロポニンの結果は0.3Ng/mlであったこと、また、心筋梗塞に対する処方としてアスピリンが投与されたことが、データ提供者からヘルスケア情報サービス事業者に提供され、ストレージに格納されていたことが分かる。以上の検索結果に基づき、まず図１１の検査-適応疾患テーブル１１０１、図１２の薬剤-適応疾患テーブル１２０１、図１０の診断治療知識ファイルに基づき整合性チェックを行う。

次に、図１０の診断治療知識ファイルに基づき整合性をチェックする。まずセクション１００１において、対象エピソード番号０００２が記載されており、整合する。セクション１００２の投薬において、アスピリンが記載されており整合するが、モルヒネは処方されていない。セクション１００３の診療行為では、心臓カテーテルが記載されており整合する。また、セクション１００４の検査結果判定では、CK>197とトロポニン>０．２５となっており、エピソード番号０００２は、この条件を満たしており整合している。

ステップ１４０７では、ステップ１４０６で収集した経過記録ファイルに対して、タグ１６１０のObjective（所見）に現れるタグを調べ、その数をカウントする。なおステップ１４０７では、タグObjectiveを対象としているが、調べる対象となるタグをObjectiveに制限するわけではない。図１６の場合、タグ１６０３のPhysical Findingsの中にタグ１６０４のKillipが存在する。これは、急性心筋梗塞に伴う左心不全の重症度分類（Killip分類）を表す。そのClassIIは、心不全（肺野の５０％以下にラ音聴取、等）を示す。また、タグ１６０５のVital Signedの中に、タグ１６０６のSBPタグが存在する。これは、収縮期血圧を表す。以上から、図１６の場合、所見タグが２つあることになる。このような探索を、ステップ１４０６で収集した全経過記録ファイルについて行う。

一方、データ提供者の入出力インターフェースにもとづく、図１６の経過記録ファイルを構成するデータの入力であるが、データ消費者１０３が欲しい所見情報を提示するという運用が考えられる。この運用により、データ提供者は、データ消費者がどのような所見を入力して欲しいか知る事ができ、この所見データの入力を増やすことで、データ保管料の更なる割引を享受することが可能になる。この処理フローを図２２により説明する。まず、データ消費者による、入力してほしい所見項目の指定について図２３を用いて説明し、データ提供者が所見等を入力する入力画面について図２４を用いて説明する。図２３は、データ消費者が、入力して欲しい所見項目を規定するＸＭＬファイルであり、データ消費者が作成するテンプレートである。データ管理部１０５は、データ消費者のコンピュータからネットワークを介して受信した当該ＸＭＬファイルを、ストレージに保管する。本ファイルは、Subjectiveタグ２３０７、Objectiveタグ２３０２、Physical Findingsタグ２３０３、Killipタグ２３０４、Vital Signedタグ２３０５、SBPタグ２３０６、Assessmentsタグ２３０８、Problemタグ２３０１から構成されている。この図では、ProblemタグによるProblemセクションに、「心筋梗塞（対象エピソード番号０００２）」が記載されている。また、Physical FindingsタグによるPhysical Findingsセクションに、KillipタグによるKillipセクションが指定されていることから、「心筋梗塞（対象エピソード番号０００２）」の場合に、Killipの入力を促す。同様に、Vital SignedタグによるVital Signedセクションには、SBPタグによるSBPセクションが指定されていることから、「心筋梗塞（対象エピソード番号０００２）」の場合に、SBPの入力を促すこと意味している。

次に、図２２に基づき、データ提供者がデータを入力するときのフローについて説明する。医師は、図２４の所見入力画面に従い、患者ＩＤ，患者氏名等の入力を開始する。ステップ２２０１において、図２４のプロブレム入力領域２４０２にエピソードとして病名を入力する。この入力は、データ提供者のコンピュータから、ネットワーク経由でヘルスケア情報サービス事業者１０１のコンピュータに送信される。ステップ２２０２では、サービス事業者１０１のコンピュータは、ステップ２２０１で入力されたエピソード（病名）に関する、図２３で説明したデータ消費者が入力項目を指定したテンプレートが、ストレージ１０８に記憶されていないかを、テンプレートのProblemタグ２３０１のエピソード情報にもとづき、検索される。なお、このテンプレートは、事前にデータ消費者が図２３のフォームで指定してストレージに登録されているものとする。検索して、エピソードに関係するテンプレートが見つかると、このテンプレートを選択する。ステップ２２０３では、ステップ２２０２の結果として、指定したエピソードに対応するテンプレートがある場合は、テンプレート表示ステップ２２０４へ進む。無い場合は、ステップ２２０１へ戻る。なお、戻った後は、本エピソードに関してはテンプレートが無いものとして、医師が自分の判断で所見等の入力を継続する。なお、検索結果は、データ提供者のコンピュータへ、テンプレートの内容と共に、通知される。

図２９は、データ消費者が欲しい類似症例を検索するための検索条件に関わるＸＭＬファイルであり、データ消費者が作成する検索テンプレートである。データ管理部１０５は、データ消費者のコンピュータからネットワークを介して受信した当該ＸＭＬファイルを、ストレージに保管する。本ファイルは、ＩＤタグ２９０８、Episodeタグ２９０１、Predictor variablesタグ２９０６、Physical Findingsタグ２９０２、Vital Signedタグ２９０３、Lab Resultsタグ２９０４、Target variablesタグ２９０７、Sample Sizeタグ２９０５から構成されている。この図２９では、EpisodeタグによるEpisodeセクションに、「心筋梗塞（対象エピソード番号０００２）」が記載されている。また、Physical FindingsタグによるPhysical Findingsセクションに、Killipが指定されていることから、「心筋梗塞（対象エピソード番号０００２）」の場合、検索条件としてKillipが入力されている類似症例が欲しいことを示している。同様に、Vital SignedタグによるVital Signedセクションには、SBPが指定されており、Lab ResultsタグのLab ResultsセクションにはCKが指定されていることから、「心筋梗塞（対象エピソード番号０００２）」の場合、検索条件としてSBPとCKが入力されている類似症例が欲しいことを示している。最後に、Sample SizeタグによるSample Sizeセクションでは2000が指定されており、「心筋梗塞（対象エピソード番号０００２）」の場合、上記の検索条件にマッチした類似症例として2000以上の症例が欲しいことを示している。

図３０は、類似症例テーブル３００１を示す。本テーブルは、対象エピソードごとの類似症例に関する情報を管理するものであり、対象とするエピソードを特定する対象エピソード番号３００２、類似症例検索のための検索条件に関するテンプレートを特定する検索テンプレート番号３００３、当該テンプレートに基づく検索によりヒットした類似症例数３００４、当該類似症例に関しデータ消費者が設定する目標サンプル数３００５、および当該レコードの登録日３００６から構成される。類似症例数を除く本テーブルのデータは、データ消費者が作成し、データ管理部が、データ消費者のコンピュータからネットワークを介して受信した当該データを、ストレージに保管する。

最初に、検体検査ＣＫを対象とする場合を説明する。ステップ２７０２で選択した対象エピソード番号にもとづき、図５のエピソードテーブル５０１から、項目５０６の対象エピソード番号を検索し、ヒットしたレコードから項目５０２のエピソード番号を取得する。次に、このエピソード番号にもとづき、図９の関連テーブル９０１の項目９０２を検索する。ここで、Lab Resultsは検体検査の結果であるから、項目９０３のテーブル名が診療行為のレコードを抽出し、項目９０４の参照番号を取り出す。次に、図６の診療行為テーブル６０１に対し、左記参照番号にもとつき、項目６０２のオーダ番号を検索し、項目６０３の行為名が検体検査のレコードを抽出、その項目６０２のオーダ番号を取り出す。このオーダ番号にもとづき、図７の検査結果テーブル７０１を検査し、項目７０３の検査名がCKのレコードを検索する。検査名がCKのレコードが存在するなら、ステップ２７０７でヒットしたレコードは、当該検索テンプレートの類似症例候補となる。

ステップ２７０９では、ステップ２７０２で選択した対象エピソードの対象エピソード番号、ステップ２７０５で選択した検索テンプレートの検索テンプレート番号、ステップ２７０８でカウントとした類似症例数、当該検索テンプレートのタグSample Size２９０５に記載の目標サンプル数について、図３０の類似症例テーブル３００１の、項目３００２の対象エピソード番号、項目３００３の検索テンプレート番号、項目３００４の類似症例数、項目３００５の目標サンプル数に、それぞれ記載する。結果記録が終了すると、ステップ２７０５へ戻り、次の検索テンプレートを検索する。

ステップ２８０５では、この医療機関の一つを選択する。ステップ２８０６では、もしレコードが存在するなら、ステップ２８０７に進む。もしないなら、ステップ２８０２に戻る。

次に、図２６のビット単価計算部２６０４について、図３２によって説明する。この図３２は、ステップ３２０１、ステップ３２０２とステップ３２０３以外は、図１８のフローと同じであり、これらステップのみ説明する。ステップ３２０１は、図１８のステップ１８０６に加えて、ステップ３２０２への分岐フローを持つ。ステップ３２０３では、ステップ１８０４で選択した対象エピソードに対して、図３１の質評価用類似症例テーブル３１０１の項目３１０５の割合を取り出す。ステップ３２０２では、重み付けデータ総数と、重み付け所見数との和に対して、ステップ３２０３で取り出した割合との積をとり、この値を図１８のステップ１８１１の値「Ｂ」とする。この後のステップは、図１８の処理と同じである。データの価値評価の観点では、データ消費者の求める目標サンプル数に近いほど、重み付けデータ総数＋重み付け所見数の役割が大きくなる。つまり、図３２のステップ３２０２およびステップ３２０３により、目標サンプル数の割合が、ヘルスケア情報のデータ保管料金に反映されることになる。

Claims (15)

1. ヘルスケア情報を蓄積するヘルスケア情報処理システムであって、
   前記ヘルスケア情報をデータ提供者のコンピュータから受信する受信部と、
   前記ヘルスケア情報を評価する医学ないし医療に関する条件を記憶する記憶部と、
   前記受信したヘルスケア情報と前記条件から前記ヘルスケア情報の価値を評価する評価部と、及び、
   前記価値に基づいて、前記ヘルスケア情報を蓄積する料金を決定する課金部を有することを特徴とするヘルスケア情報処理システム。
2. 請求項１記載のヘルスケア情報処理システムであって、
   前記条件は、複数の項目を含み、
   前記評価部は、前記ヘルスケア情報に含まれる複数の項目と前記条件の複数の項目との整合度から前記価値を評価することを特徴とするヘルスケア情報処理システム。
3. 請求項２記載のヘルスケア情報処理システムであって、
   前記評価部は、前記ヘルスケア情報に含まれるフリーテキストデータ定型入力箇所の記入割合に基づいて前記価値を評価することを特徴とするヘルスケア情報処理システム。
4. 請求項３記載のヘルスケア情報処理システムであって、
   前記課金部は、前記整合度と前記記入割合に基づいて、蓄積された前記ヘルスケア情報のデータ量に重みをつけ、保管データ量に占める前記重み付けデータ量の割合から前記料金を決定することを特徴とするヘルスケア情報処理システム。
5. 請求項４記載のヘルスケア情報処理システムであって、
   前記課金部は、前記記入割合が前記記憶部に記憶された所定の数値以上のときに、前記記入割合から前記料金を決定することを特徴とするヘルスケア情報処理システム。
6. 請求項１記載のヘルスケア情報処理システムであって、
   前記課金部は、データ消費者からの、前記システムに蓄積された前記ヘルスケア情報のデータ購入量に基づいて、前記料金を決定することを特徴とするヘルスケア情報処理システム。
7. 請求項１記載のヘルスケア情報処理システムであって、
   前記受信部は、前記ヘルスケア情報を使用するデータ消費者のコンピュータから、前記ヘルスケア情報に含まれるフリーテキストデータ定型入力箇所の入力内容を指定する定型入力情報を受信し、
   更に、前記ヘルスケア情報処理システムは、前記定型入力情報を、前記データ提供者のコンピュータのデータ入力画面に表示するために、送信する送信部を有することを特徴とするヘルスケア情報処理システム。
8. 請求項６記載のヘルスケア情報処理システムであって、
   前記データ提供者に対して、当該ヘルスケア情報処理システムに保管している前記ヘルスケア情報のデータ量、前記データ購入量、及び、前記料金を通知することを特徴とするヘルスケア情報処理システム。
9. 請求項３記載のヘルスケア情報処理システムであって、
   前記評価部は、データ消費者が指定するデータ項目に適合した前記ヘルスケア情報の保管データ量と、前記データ項目に関する目標サンプル数にもとづき、前記目標サンプル数に対する保管データ量の割合を求め、当該割合から前記ヘルスケア情報の価値を評価することを特徴とするヘルスケア情報処理システム。
10. 請求項９記載のヘルスケア情報処理システムであって、
    前記課金部は、前記整合度と前記記入割合に基づいて、蓄積された前記ヘルスケア情報のデータ量に重みをつけ、保管データ量に占める前記重み付けデータ量の割合からと、前記目標サンプル数に対する保管データ量の割合とから、前記料金を決定することを特徴とするヘルスケア情報処理システム。
11. 請求項９記載のヘルスケア情報処理システムであって、
    前記課金部は、データ消費者からの、前記ヘルスケア情報処理システムに蓄積された前記ヘルスケア情報のデータ購入量に基づいて、前記料金を決定することを特徴とするヘルスケア情報処理システム。
12. 請求項９記載のヘルスケア情報処理システムであって、
    前記受信部は、前記ヘルスケア情報を使用するデータ消費者のコンピュータから、前記ヘルスケア情報に含まれるフリーテキストデータ定型入力箇所の入力内容を指定する定型入力情報を受信し、
    更に、前記ヘルスケア情報処理システムは、前記定型入力情報を、前記データ提供者のコンピュータのデータ入力画面に表示するために、送信する送信部を有することを特徴とするヘルスケア情報処理システム。
13. 請求項９記載のヘルスケア情報処理システムであって、
    前記データ提供者に対して、当該ヘルスケア情報処理システムに保管している前記ヘルスケア情報のデータ量、前記データ購入量、及び、前記料金を通知することを特徴とするヘルスケア情報処理システム。
14. ヘルスケア情報を蓄積するヘルスケア情報処理システムであって、
    前記ヘルスケア情報をデータ提供者のコンピュータから受信する受信部と、
    前記ヘルスケア情報を評価する医学ないし医療に関する条件を記憶する記憶部と、及び、
    前記受信したヘルスケア情報と前記条件に基づいて、前記ヘルスケア情報を蓄積する料金を決定する課金部を有することを特徴とするヘルスケア情報処理システム。
15. ヘルスケア情報を蓄積するヘルスケア情報処理システムにおける課金計算方法であって、前記ヘルスケア情報処理システムが、
    前記ヘルスケア情報をデータ提供者のコンピュータから通信ネットワークを介して受信するステップと、
    前記ヘルスケア情報を評価する医学ないし医療に関する条件を記憶部に記録するステップと、
    前記受信したヘルスケア情報と前記記録された条件に基づいて、前記ヘルスケア情報を蓄積する料金を決定するステップを有することを特徴とするヘルスケア情報処理システムの課金計算方法。

Images