Data Interchange Format between an Electronic Health Record System and a Financial System
Kenji Araki, Yoichi Ogushi, Hiroyuki Daimon, Hiroyuki Yoshihara
1: 宮崎医科大学附属病院医療情報部
889-1692 宮崎県宮崎郡清武町木原5200
Medical Informatics, Miyazaki Medical College Hospital
5200 Kihara, Kiyotake, Miyazaki 889-1692, Japan
電話：0985-84-4572
fax： 0985-84-2549
2:東海大学医学部医学情報学
259-1193 神奈川県伊勢原市望星台
Medical Engineering and Informatics, School of Medicine, Tokai University
Bosei-dai, Isehara, Kanagawa 259-1193, Japan
3:診療システム研究フォーラム
102-0083 東京都千代田区麹町3丁目2番4号丹波屋ビル5階
Medical System Research Forum
3-2-4 Koji-machi, Chiyoda-ku, Tokyo 102-0083, Japan
抄録
電子カルテと医事会計システム間のデータ交換をオープン化，標準化し，電子カルテ開発を促進するために，両システム間の電子的データ交換フォーマット（以下CLAIM）の開発を行った．CLAIMの設計方針としては，電子カルテ側から診療報酬請求業務（レセプト作成業務）に必要な最低限のデータを医事会計システムに渡せること，請求額などの医事会計処理結果を電子カルテに渡せること，医療情報交換規約（MML）と共通のデータは極力同じ構造とすること，法改定の影響を受けにくい柔軟な構造とすること，当面はSGMLを用いることなどが挙げられる．CLAIMは，大きく5つのセクションよりなる．すなわち一般ヘッダ情報，患者識別情報，健康保険セクション，診断履歴セクション，受付セクション，請求セクションである． 今回試作したCLAIMを用いて，実際のレセプトを構造化した． 今後は，実装試験に向けてさらに改善を重ねていきたい．
We developed data format for electronic interchange between an electronic health record system and a financial system, which was named CLAIM (clinical accounting information), with the architecture open and standardized, which may result in promoting the development of an electronic health record system. We considered at designing CLAIM that it should support the data for claiming to insurance organizations, that it was described as a subset of SGML and that it should coordinate Medical Mark-up Language (MML). The broadness of its usage is also key concept. The CLAIM consists of 5 sections; GENERAL-INFORMATION-SECTION, PATIENT-ID-SECTION, REGISTERED-DIAGNOSIS-SECTION, REGISTRATION-SECTION and CLAIM-SECTION. The developed CLAIM can successfully structure the actual patient data as feasibility testing. The future problems include how to express advanced insurance data such as patient management fare. We will sophisticate the developed CLAIM for implementation to hospitals.
（キーワード：医療情報交換規約，MML， SGML，EDI，医事会計，レセプト）
(Keywords:Medical Mark-up Language, SGML, EDI, financial account, claim)
1.はじめに
今回われわれは，医事会計-電子カルテ連携のためのデータ交換フォーマット（CLinical Accounting InforMation; CLAIM）の開発を行った．電子カルテシステムと医事会計システム（いわゆるレセコン）との電子的データ交換を標準化，粗結合化（オープン化）することのメリットとして，電子カルテシステム開発促進が挙げられる．現在，多くのメーカーが電子カルテ事業に新規参入を図っている［1］．医事会計システムを独自に持たないベンダーが電子カルテ事業に参入しようとする際に，これらのベンダーは大手の医事会計システムごとにインターフェイスを開発する必要がある．CLAIMを策定しておけば，電子カルテベンダーは一種類のインターフェイスを開発するだけで済み，開発効率の向上とコスト削減につながる．また，医事会計システムベンダーにとっても，ユーザから電子カルテ導入を依頼された際に，独自に新たな開発を行う必要がなくなるとともに，紙カルテから得ていた情報の一部を，電子カルテから自動的に抽出することが可能となり，メリットが生じると考えられる．本研究では，開発したCLAIMを紹介するとともに，医事会計情報とくにレセプト作成に必要な情報の構造化が可能かについて検討したので報告する．
2.方法
以下の方針に沿って，CLAIMの設計を行った．1)CLAIMの使用目的
使用目的は，電子カルテシステムと医事会計システムの情報交換である．将来的には，病院の財務管理や経営分析［2］にも応用されるべきものであるが，今回はとくに診療報酬請求情報（レセプト情報）を中心に開発を行った．
2)電子カルテシステムとの関係
MMLおよびCLAIMを用いた電子カルテシステムと医事会計システムのデータ交換の一例を示す（Fig）．本例では，診療所において外来受付に医事会計システムを設置し，医師の診察室に電子カルテシステムを設置して，2台のコンピュータのみで全てを行うケースを想定している．MMLおよびCLAIMには，両システムでやりとりを行う項目がタグとして準備されている．患者の外来受付時には，医事会計システムから個人情報，健康保険情報などが入力され，電子カルテシステムに渡される．診療が終わると，病名情報，診療情報および点数を含まない医事請求情報が医事会計システムに渡され，点数計算等の医事会計処理を行う．さらに，その結果は電子カルテシステムに渡され，電子カルテ側からも，診療報酬請求額などの医事会計情報が参照できるようにしておく．
3)汎用性の重視CLAIMは，たびたび行われる薬価や点数表の改訂はもとより，包括医療の導入などの大きな改訂にもなるべく影響を受けない構造とすべきと考える．よって，タグの種類はなるべく少なくし，タグによって表されるデータ（コード表，マスタあるいはテーブル）の書き換えで改訂に対応できるように設計を行う．
4)MMLとの関係
医療情報学会課題研究会「電子カルテ研究会」は，医療情報を施設間，あるいは異なる情報システム間で交換するための医療情報交換規約であるMML（Medical Mark-up Language）の策定を1994年から開始し，1997年にはバージョン1.0を公開し，実際の電子カルテシステムに実装する段階に入っている［3-5］．MMLとCLAIMは，患者識別情報，健康保険情報，診断情報など共通のデータを持つため，共通部分は極力同じ構造とした．
5)使用言語
CLAIMは当面MMLと同様にSGML（標準化タグ付き言語）［6］のサブセットとする．将来的には，HL7［7］やXML（eXtensible Markup Language）［8］などの利用も考えられるが，SGMLで構造化しておくことにより変換可能と考えられる．
以上の基本方針の下に，CLAIMの設計を行い，評価のために実際の診療報酬請求書（レセプト）を用いてデータの構造化を試みた．
3.結果
1)CLAIMエレメントTable1. CLAIM ver1.0 エレメント一覧表（PDF形式）
Table2. テーブル（PDF形式）
Table3. 診療行為，および診療種別区分テーブル（PDF形式）
Table1. CLAIM ver1.0 エレメント一覧表（csv形式，テキストで保存しエクセル等で読み込んで下さい）
Table2. テーブル（csv形式）
Table3. 診療行為，および診療種別区分テーブル（csv形式）
Table 1にCLAIMエレメント一覧表を示す．タグはレベルに応じてインデントされており，半角英数字で表記されている．タグは<>（パーレン）で囲まれるが，表では省略した．同様に，終了タグ</ >も省略している．表中の省略，反復，型の記法は，MMLに則った．CLAIM独自に使用するテーブルは，参照デーブル番号を附し，Table2，3に記した．
メッセージの内容はイベントにより変わるため，CLAIMでは外来診療における代表的な3種類のイベントに的を絞って，それぞれのエレメントについて，電子カルテと医事会計システムのどちらに入力義務があるかを明確にした．表中イベントの項目に，トランザクション発生のタイミングを記した．「受付時」は，外来受付時に医事会計システムから電子カルテシステムへ送信するタイミングを意味する．同様に，「診察終了時」は，オーダーが完了し，電子カルテシステムから医事会計システムへの送信タイミングを，さらに，「会計終了時」は，医事会計システムでの会計処理が終了し，点数や金額の情報を電子カルテに送信するタイミングを意味する．それぞれのタイミングにおいて，該当のエレメント（ないしセクション）は，送信アプリケーションにより値を入力されなければならない．ただし，メモは随時使用可とする．入院患者のイベントについては，外来に準じて行うものとする．
CLAIMは，構造的に大きく5つのセクションよりなる．すなわちGENERAL-INFORMATION-SECTION，PATIENT-ID-SECTION ，HEALTH-INSURANCE-SECTION, REGISTERED-DIAGNOSIS-SECTION, REGISTRATION-SECTION, CLAIM-SECTIONである．以下，個別に解説を加える．
- GENERAL-INFORMATION-SECTION（一般ヘッダ情報）には，使用したCLAIMのバージョンと，基本的に使用するコード体系名を記載する．ローカルに別のコード体系を用いる場合は，そのつど記載できるようにも配慮している．
- PATIENT-ID-SECTION（患者識別情報）は，MMLと全く同じ構造である．
- HEALTH-INSURANCE-SECTION（健康保険セクション）は，MMLの同名セクションのエレメントに，INSURANCE-REF-CLASS（保険組合せ区分），START-DATE（開始日），PUBLIC-INSURANCE-SECTION（公費負担医療セクション）を追加したものである． 保険組合せ区分は，診断履歴セクションや請求セクションからの保険参照のためのものであり，施設ごと，患者ごとにIDを振る．開始日は，当該保険有効期間の開始日（交付日）である．公費負担医療セクションは，結核などの公費での医療を受けている場合の情報を格納する．
- REGISTERED-DIAGNOSIS-SECTION（診断履歴セクション）は，MMLの同名セクションのエレメントに，前出のINSURANCE-REF-CLASS（保険組合せ区分），PRINT（レセプト印字フラグ），INSURANCE-DISEASE-CLASS（保険特定疾患区分）を追加したものである．
- REGISTRATION-SECTION（受付セクション）は，患者受付時に必要な情報や，患者の所在情報を格納するためのセクションである．それぞれ施設ごとのテーブルを作成し使用する．
- CLAIM-SECTION（請求セクション）の構造は，現行のレセプト記載を完全に行い得るように設計した．
- SERIAL-CLAIM-SECTION（一連請求セクション）は，同一医師の実施した一連の診療行為を収めるセクションで，外来では一回の診療に相当する．
- CLAIM-INFORMATION-SECTION（請求ヘッダ情報）で注意しなければならないのは，診療科名を示すエレメントが3種類あることである．すなわち，医師の所属科，診療した科，診療した病棟である．3者は同じものであることが多いが，例えば，外科医が内科に呼ばれて，3階病棟でオーダーを出した場合は，それぞれの診療科名が，外科，内科，3階病棟ということになる．
- CLAIM-BUNDLE-SECTION（診療括りセクション）は，一血液検査，一処方などの一つのオーダーを一括りにするためのセクションである． この内部には，投薬や検査といったCLAIM-CLASS （診療行為区分），適用する保険を示すINSURANCE-CLASS（保険組合せ区分），個々の診療項目を記載するCLAIM-COMPONENT-SECTION（診療項目セクション），点数を記載するCLAIM-AMOUNT-SECTION（診療点数セクション），そして，繰り返しのある場合に記載するREPEAT（回数）が含まれる．
- CLAIM-COMPONENT-SECTION（診療項目セクション）は，レセプトでは通常一行で記載されているような最小の診療単位に相当する．心臓超音波検査のように部位を示すような修飾語がつく場合には，「超音波検査」と「心臓」の2つの診療項目に分解する．また，診療行為区分が検査であっても，この中に薬剤が含まれることがあるため，診療行為区分とは別個に，それぞれの診療項目ごとにCLAIM-SUBCLASS（診療種別区分）を設け，現行のレセプト記載に対応した．使用する医事コード体系名はすでにGENERAL-INFORMATION-SECTIONにて記載されているが， ローカルに別のコードを用いる場合に対応して，診療項目セクション内にも設けた．NAME（名称）は医事コードだけでは表現できないものにも対応するためにある．一つの診療項目で2つの数値を持つ場合に対応して，数値は1と2を用意した．使用する医事コードにもよるが，レントゲン写真の分割数と枚数などがこれに相当する可能性がある．AMOUNT（点数）は請求点数や請求金額ではなく，記載診療項目の点数や金額がコードにない場合に対応するためのものである．実際の請求点数はCLAIM-AMOUNT-SECTION（診療点数セクション）に記載する．PPS-CLASS（包括区分）とは診療項目が包括医療保険制度の適応になっているかを示すもので，医事計算上必要と考えた．
2)CLAIMの試用
Table4. Sample of CLAIM（PDF形式）
Table4. Sample of CLAIM（csv形式，テキストで保存しエクセル等で読み込んで下さい）
今回試作したCLAIMを用いて，レセプトを構造化したサンプルをTable 4に示す．
4.考察
従来の病院情報システムでは，同一ベンダーにより全システムが構築されるのが普通であったため，オーダリングシステムと医事会計システムのようなシステム間では，ベンダー固有の通信プロトコールが用いられてきた［9］．しかし，電子カルテが現実のものとなりつつある今日では，全システムを同一ベンダーに依存することは必ずしも適切とは言えず，異なるベンダーのシステムを組み合わせて，全体のシステムを構築することも十分に考えられる（マルチベンダー化）．この様な場合には，システム間メッセージ交換には標準化された通信プロトコールを用いる方が効率がよい． そのために，医事会計システムと電子カルテシステムの標準通信プロトコールを目指してCLAIMの試作を行った．ヨーロッパ諸国では，データを構造化し電子的に交換を行うことために，国連が制定した貿易のためのメッセージ交換の基準であるUN/EDIFACT（United Nations/Electronic Data Interchange For Administration, Commerce and Transport standard）に準拠したelectronic data interchange (EDI)が主に用いられている［10-12］．さらに，オランダではEDIFACT標準を利用したMEDEURと呼ぶプロトコールをとくに医療用に開発し，オランダ医師会で管理運営している［13］．さらに，これらのEDIは，会計処理にも用いられようとしている［14］．一方米国では，医療メッセージの交換のためにHealth Level Seven (HL7)がもっとも一般的に用いられている［15］．しかし，日本固有の診療報酬請求業務を考慮すると，医事会計情報交換規約には外国のものをそのまま流用するのは難しく，独自に開発する必要があると判断した．
今回開発したCLAIMは，少なくともレセプト発行業務には使用可能と考えられるが，電子カルテシステムと医事会計システムの情報交換と言う意味では，不十分な点がいくつかある．第１に，特定疾患療養指導料などの指導管理料の処理方法である．これは，現在の多くの医療機関では，医事職員がマニュアルで行っていると考えられる．すなわち，医師の判断で患者に指導を行い，その内容を紙のカルテに記載し，レセプト作成時に医事職員が紙のカルテを見て指導管理料を算定する．電子カルテ導入後は，この処理をなるべく効率化すべきである．このためには，指導が算定できる時期になれば，医事会計システム側から電子カルテシステム側にメッセージを送り，電子カルテシステムでは一種のオーダリングのように指導管理業務を行い，指導を行ったという医事会計情報を医事会計システムに渡すような機能が必要である．第2に，各種加算の処理方法である．加算は極めて多岐にわたり，また，頻繁に改訂されるため，CLAIMでサポートするには問題があると判断した．従って，医事職員によるマニュアルによる処理が必要となるが，電子カルテによりカルテの物理的移動がなくなれば，若干の効率化は期待できる．第3に，点数算定に必要な情報の医事会計システムへの受け渡しである．例えば，創傷処理において，傷の長さの情報などが挙げられる．これも，加算と同様にCLAIMではサポートできないと判断した．しかし，医事会計業務の効率化を考えれば，加算も含めて今後取り組むべき課題と考える．
以上，CLAIMの開発と問題点について述べた．今後は，実装試験に向けてさらに改善を重ね，また，問題点についても検討していきたい．
文献