文献情報
文献番号
199800787A
報告書区分
総括
研究課題名
電子診療録における医療情報交換技術の標準化とその仕様拡張に関する研究
課題番号
-
研究年度
平成10(1998)年度
研究代表者(所属機関)
吉原 博幸(宮崎医科大学附属病院医療情報部)
研究分担者(所属機関)
- 荒木賢二(宮崎医科大学附属病院医療情報部)
研究区分
厚生科学研究費補助金 健康安全確保総合研究分野 医療技術評価総合研究事業
研究開始年度
平成10(1998)年度
研究終了予定年度
平成12(2000)年度
研究費
4,000,000円
研究者交替、所属機関変更
-
研究報告書（概要版）
研究目的
医事会計-電子カルテ連携のためのデータ交換フォーマット(CLinical Accounting InforMation; CLAIM)の開発を行った。電子カルテシステムと医事会計システム(いわゆるレセコン)との電子的データ交換を標準化、粗結合化(オープン化)することのメリットとして、電子カルテシステム開発促進が挙げられる。現在、多くのメーカーが電子カルテ事業に新規参入を図っている。医事会計システムを独自に持たないベンダーが電子カルテ事業に参入しようとする際に、これらのベンダーは大手の医事会計システムごとにインターフェイスを開発する必要がある。CLAIMを策定しておけば、電子カルテベンダーはCLAIMに対する一種類のインターフェイスを開発するだけで済み、開発効率の向上とコスト削減につながる。また、医事会計システムベンダーにとっても、ユーザから電子カルテ導入を依頼された際に、独自に新たな開発を行う必要がなくなり、さらに、紙カルテから得ていた情報の一部を、電子カルテから自動的に抽出することが可能となり、メリットが生じると考えられる。
研究方法
1. 以下の方針に沿って、CLAIMの設計を行った。
1) CLAIMの使用目的
使用目的は、電子カルテシステムと医事会計システムの情報交換である。将来的には、病院の財務管理や経営分析にも応用されるべきものであるが、今回はとくに診療報酬請求情報(レセプト情報)を中心に開発を行った。
2) 電子カルテシステムとの関係
診療所において外来受付に医事会計システムを設置し、医師の診察室に電子カルテシステムを設置して、2台のコンピュータで全てを行うケースを想定した場合、CLAIMには、両システムでやりとりを行う項目がタグとして準備されている。患者の外来受付時には、医事会計システムから個人情報、健康保険情報などが入力され、電子カルテシステムに渡される。診療が終わると、病名情報、診療情報および点数を含まない医事請求情報が医事会計システムに渡され、点数計算等の医事会計処理を行う。さらに、その結果は電子カルテシステムに渡され、電子カルテ側からも、診療報酬請求額などの医事会計情報が参照できるようにしておく。
3) 柔軟性の重視
CLAIMは、たびたび行われる薬価や点数表の改訂はもとより、包括医療の導入などの大きな改訂にもなるべく影響を受けない構造とすべきと考える。よって、タグの種類はなるべく少なくし、タグによって表されるデータ(コード表、マスタあるいはテーブル)の書き換えで改訂に対応できるように設計を行う。
4)MMLとの関係
医療情報学会課題研究会「電子カルテ研究会」は、医療情報を施設間、あるいは異なる情報システム間で交換するための医療情報交換規約であるMML(Medical Mark-up Language)の策定を1994年から開始し、1997年にはバージョン1。0を公開し、実際の電子カルテシステムに実装する段階に入っている。MMLとCLAIMは、患者識別情報、健康保険情報、診断情報など共通のデータを持つため、共通部分は極力同じ構造とした。
5) 使用言語
CLAIMは当面MMLと同様にSGML(標準化タグ付き言語)のサブセットとする。将来的には、HL7やXML(eXtensible Markup Language)などの利用も考えられるが、SGMLで構造化しておくことにより変換可能と考えられる。
以上の基本方針の下に、CLAIMの設計を行い、評価のために実際の診療報酬請求書(レセプト)を用いてデータの構造化を試みた。
1) CLAIMの使用目的
使用目的は、電子カルテシステムと医事会計システムの情報交換である。将来的には、病院の財務管理や経営分析にも応用されるべきものであるが、今回はとくに診療報酬請求情報(レセプト情報)を中心に開発を行った。
2) 電子カルテシステムとの関係
診療所において外来受付に医事会計システムを設置し、医師の診察室に電子カルテシステムを設置して、2台のコンピュータで全てを行うケースを想定した場合、CLAIMには、両システムでやりとりを行う項目がタグとして準備されている。患者の外来受付時には、医事会計システムから個人情報、健康保険情報などが入力され、電子カルテシステムに渡される。診療が終わると、病名情報、診療情報および点数を含まない医事請求情報が医事会計システムに渡され、点数計算等の医事会計処理を行う。さらに、その結果は電子カルテシステムに渡され、電子カルテ側からも、診療報酬請求額などの医事会計情報が参照できるようにしておく。
3) 柔軟性の重視
CLAIMは、たびたび行われる薬価や点数表の改訂はもとより、包括医療の導入などの大きな改訂にもなるべく影響を受けない構造とすべきと考える。よって、タグの種類はなるべく少なくし、タグによって表されるデータ(コード表、マスタあるいはテーブル)の書き換えで改訂に対応できるように設計を行う。
4)MMLとの関係
医療情報学会課題研究会「電子カルテ研究会」は、医療情報を施設間、あるいは異なる情報システム間で交換するための医療情報交換規約であるMML(Medical Mark-up Language)の策定を1994年から開始し、1997年にはバージョン1。0を公開し、実際の電子カルテシステムに実装する段階に入っている。MMLとCLAIMは、患者識別情報、健康保険情報、診断情報など共通のデータを持つため、共通部分は極力同じ構造とした。
5) 使用言語
CLAIMは当面MMLと同様にSGML(標準化タグ付き言語)のサブセットとする。将来的には、HL7やXML(eXtensible Markup Language)などの利用も考えられるが、SGMLで構造化しておくことにより変換可能と考えられる。
以上の基本方針の下に、CLAIMの設計を行い、評価のために実際の診療報酬請求書(レセプト)を用いてデータの構造化を試みた。
結果と考察
1) CLAIMエレメント
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(包括区分)とは診療項目が包括医療保険制度の適応になっているかを示すもので、医事計算上必要と考えた。
従来の病院情報システムでは、同一ベンダーにより全システムが構築されるのが普通であったため、オーダリングシステムと医事会計システムのようなシステム間では、ベンダー固有の通信プロトコールが用いられてきた。しかし、電子カルテが現実のものとなりつつある今日では、全システムを同一ベンダーに依存することは必ずしも適切とは言えず、異なるベンダーのシステムを組み合わせて、全体のシステムを構築することも十分に考えられる(マルチベンダー化)。この様な場合には、システム間メッセージ交換には標準化された通信プロトコールを用いる方が効率がよい。 そのために、医事会計システムと電子カルテシステムの標準通信プロトコールを目指してCLAIMの試作を行った。
ヨーロッパ諸国では、データを構造化し電子的に交換を行うことために、国連が制定した貿易のためのメッセージ交換の基準であるUN/EDIFACT(United Nations/Electronic Data Interchange For Administration、 Commerce and Transport standard)に準拠したelectronic data interchange (EDI)が主に用いられている。さらに、オランダではEDIFACT標準を利用したMEDEURと呼ぶプロトコールをとくに医療用に開発し、オランダ医師会で管理運営している。さらに、これらのEDIは、会計処理にも用いられようとしている。一方米国では、医療メッセージの交換のためにHealth Level Seven (HL7)がもっとも一般的に用いられている。しかし、日本固有の診療報酬請求業務を考慮すると、医事会計情報交換規約には外国のものをそのまま流用するのは難しく、独自に開発する必要があると判断した。
今回開発したCLAIMは、少なくともレセプト発行業務には使用可能と考えられるが、電子カルテシステムと医事会計システムの情報交換と言う意味では、不十分な点がいくつかある。第1に、特定疾患療養指導料などの指導管理料の処理方法である。これは、現在の多くの医療機関では、医事職員がマニュアルで行っていると考えられる。すなわち、医師の判断で患者に指導を行い、その内容を紙のカルテに記載し、レセプト作成時に医事職員が紙のカルテを見て指導管理料を算定する。電子カルテ導入後は、この処理をなるべく効率化すべきである。このためには、指導が算定できる時期になれば、医事会計システム側から電子カルテシステム側にメッセージを送り、電子カルテシステムでは一種のオーダリングのように指導管理業務を行い、指導を行ったという医事会計情報を医事会計システムに渡すような機能が必要である。第2に、各種加算の処理方法である。加算は極めて多岐にわたり、また、頻繁に改訂されるため、CLAIMでサポートするには問題があると判断した。従って、医事職員によるマニュアルによる処理が必要となるが、電子カルテによりカルテの物理的移動がなくなれば、若干の効率化は期待できる。第3に、点数算定に必要な情報の医事会計システムへの受け渡しである。例えば、創傷処理において、傷の長さの情報などが挙げられる。これも、加算と同様にCLAIMではサポートできないと判断した。しかし、医事会計業務の効率化を考えれば、加算も含めて今後取り組むべき課題と考える。
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(包括区分)とは診療項目が包括医療保険制度の適応になっているかを示すもので、医事計算上必要と考えた。
従来の病院情報システムでは、同一ベンダーにより全システムが構築されるのが普通であったため、オーダリングシステムと医事会計システムのようなシステム間では、ベンダー固有の通信プロトコールが用いられてきた。しかし、電子カルテが現実のものとなりつつある今日では、全システムを同一ベンダーに依存することは必ずしも適切とは言えず、異なるベンダーのシステムを組み合わせて、全体のシステムを構築することも十分に考えられる(マルチベンダー化)。この様な場合には、システム間メッセージ交換には標準化された通信プロトコールを用いる方が効率がよい。 そのために、医事会計システムと電子カルテシステムの標準通信プロトコールを目指してCLAIMの試作を行った。
ヨーロッパ諸国では、データを構造化し電子的に交換を行うことために、国連が制定した貿易のためのメッセージ交換の基準であるUN/EDIFACT(United Nations/Electronic Data Interchange For Administration、 Commerce and Transport standard)に準拠したelectronic data interchange (EDI)が主に用いられている。さらに、オランダではEDIFACT標準を利用したMEDEURと呼ぶプロトコールをとくに医療用に開発し、オランダ医師会で管理運営している。さらに、これらのEDIは、会計処理にも用いられようとしている。一方米国では、医療メッセージの交換のためにHealth Level Seven (HL7)がもっとも一般的に用いられている。しかし、日本固有の診療報酬請求業務を考慮すると、医事会計情報交換規約には外国のものをそのまま流用するのは難しく、独自に開発する必要があると判断した。
今回開発したCLAIMは、少なくともレセプト発行業務には使用可能と考えられるが、電子カルテシステムと医事会計システムの情報交換と言う意味では、不十分な点がいくつかある。第1に、特定疾患療養指導料などの指導管理料の処理方法である。これは、現在の多くの医療機関では、医事職員がマニュアルで行っていると考えられる。すなわち、医師の判断で患者に指導を行い、その内容を紙のカルテに記載し、レセプト作成時に医事職員が紙のカルテを見て指導管理料を算定する。電子カルテ導入後は、この処理をなるべく効率化すべきである。このためには、指導が算定できる時期になれば、医事会計システム側から電子カルテシステム側にメッセージを送り、電子カルテシステムでは一種のオーダリングのように指導管理業務を行い、指導を行ったという医事会計情報を医事会計システムに渡すような機能が必要である。第2に、各種加算の処理方法である。加算は極めて多岐にわたり、また、頻繁に改訂されるため、CLAIMでサポートするには問題があると判断した。従って、医事職員によるマニュアルによる処理が必要となるが、電子カルテによりカルテの物理的移動がなくなれば、若干の効率化は期待できる。第3に、点数算定に必要な情報の医事会計システムへの受け渡しである。例えば、創傷処理において、傷の長さの情報などが挙げられる。これも、加算と同様にCLAIMではサポートできないと判断した。しかし、医事会計業務の効率化を考えれば、加算も含めて今後取り組むべき課題と考える。
結論
1. SGML技術を用いて、電子カルテシステムと医事システムを結ぶインターフェイスとしてのDTDを作成した。
2. 昨年度実証したMIME形式のマルチメディアパッケージによるオフラインや電子メイルベースの医療情報の交換をさらに発展させ、オブジェクトを用いたインターネットベースでの情報交換が実用レベルで可能であるとを実証した。
3. MMLの普及を加速するため、MML文書を解析するための移植性の良いプログラムを開発・公開し、ベンダーが自由に利用できるようにした。移植性を保証するために、JAVA beanを用い、可能な限りコンポーネント化し、各ベンダーが開発するアプリケーションに部品として組み込むことが出来るよう配慮した。
2. 昨年度実証したMIME形式のマルチメディアパッケージによるオフラインや電子メイルベースの医療情報の交換をさらに発展させ、オブジェクトを用いたインターネットベースでの情報交換が実用レベルで可能であるとを実証した。
3. MMLの普及を加速するため、MML文書を解析するための移植性の良いプログラムを開発・公開し、ベンダーが自由に利用できるようにした。移植性を保証するために、JAVA beanを用い、可能な限りコンポーネント化し、各ベンダーが開発するアプリケーションに部品として組み込むことが出来るよう配慮した。
公開日・更新日
公開日
-
更新日
-