1-E-4-4 電子カルテ / ワークショップ: 口腔領域の医療情報電子化はここまできた −診療録の電子化と保険請求業務の電子化−

病名と処置のリンク、保険請求の整合性チェックについて

○矢嶋 研一

東京都開業 矢嶋歯科医院

抄録: 医科と歯科では同じ保険請求業務であっても治療行為そのものの違いや保険の体系の違いからその仕組みはかなり異なっている。
歯科治療は基本的に小手術の連続としてみることができる。保険における治療行為の単位はその手術の中のさらに細分化された個々の治療行為に分割され、また、その行為が算定可能かどうかは複雑なルールに則っている。このため歯科用のレセコンは単純に処置や病名を集計するという機能だけでは不十分で、正しい算定をするためのチェック処理が必須である。
チェックは部位(あるいは対象臓器)につけられた病名、行われた検査やその結果、施された処置や手術、そしてそれらの時間的な経過などのあらゆる情報を条件として、病名や治療行為が正しいものか、算定可能かどうかということを判断する非常に複雑な処理である。
実際の実装では、まず第一に記録される医療情報が、病名と処置そして部位などのが互いに関連づけらたデータ構造となっている必要がある。
チェックルーチンは、病名や処置のプロパティ(性質)として用意されたルール(対象は小臼歯、単位は「歯」など)や、病名-処置、病名-病名、処置-処置などの関係と時間的な経過を加味した複合的な条件式(スケーリングは、直前までに基本検査が行われていれば算定できる、しかし、2回目の検査が行われた以後には算定できない。など)を使ってデータを評価する。なお、これらのルールは純粋に保険のものというわけではなく、その多くは歯科治療の流れや常識をも含んだものとなる。
チェックルーチンは、すでに入力された項目が正しいかどうかを判断させるだけでなく、病名と歯牙の状態からもっとも確度の高い治療行為をナビゲートしたり、逆に入力された治療行為から妥当な病名の候補を挙げたりといった入力支援機能としても使われる。

Linking disease names and treatment procedures to consistency check for dental insurance claim

Kennichi Yajima

Yajima Dental Clinic,Tokyo

Abstract: Structure of Japanese dental insurance claim is complex, so that we need an appropriate error check system in order to make our insurance claim more precisely.
This check system should have many complexed functions to check consistency of disease name and treatment procedure on many actual conbinations of disease name with tooth position, examinations and their resuls, treatment procedures and their elapse of the time.
Furthermore, the system expected to have an inteligent function to support dentists not only to judge the accurecy of input data but also to nabigate them to decide a highly reliable dental procedure from good mixes of disease names and tooth status.

Keywords: electronic patient recorderror checkinsurance claim


1. はじめに

 医科と歯科では同じ保険請求業務であっても治療行為そのものの違いや保険の体系の違いからその仕組みはかなり異なっている。
 歯科治療は基本的に小手術の連続としてみることができる。保険における治療行為の単位はその手術の中のさらに細分化された個々の治療行為に分割され、また、その行為が算定可能かどうかは複雑なルールに則っている。このため歯科用のレセコンは単純に処置や病名を集計するという機能だけでは不十分で、正しい算定をするためのチェック処理が必須である。
 今回は、自身で開発している歯科用システムの中で実装しているチェックルーチンを例に、その仕組みの概要を報告する。

2. 診療データの構造

 診療データには、病名データと処置データがある。チェックを前提とした場合これら2つのデータはなんらかの形で相互にリンクされていなければならない。
 リンクの仕方には、幾つかの方法が考えられる。
 診療データ中に直接病名を埋め込む方法、診療データと病名データをポインターあるいはリレーションとしてリンクする方法などがある。前者はチェックルーチンが簡単になるが、病名を修正する場合の整合性をとるのが面倒である、後者はその逆になるが、どちらも本質的な違いはない
。 診療データには、処理を簡単にするために付加的なデータを加えてある。処置をグループわけしたデータである。グループとは抜歯、感根治、形成といったものである。

3. チェックの概要

 チェックは部位(あるいは対象臓器)につけられた病名、行われた検査やその結果、施された処置や手術、そしてそれらの時間的な経過などのあらゆる情報を条件として、病名や治療行為が正しいものか、算定可能かどうかということを判断する非常に複雑な処理である。また、それは単一の処理ではなく、複数の方法に分かれており、チェックのレベルや対象により、それらを組み合わせて処理される。

4. 病名-病名チェック

 病名には同一部位に対して同時に指定できないものがある。これは、病態として同時に発症しない場合と、病名の定義上同時につけられないものなどの場合がある。このような場合が発生するのは、入力時に対象の部位を間違える等のケアレスミスや、う蝕の処置を済ませたあとで、歯髄炎に移行したなどという併発ではなく継発である場合なのである。
 いずれの場合でも、これらの誤りはオペレータが意識して操作しているわけではないので、システム側が適切な警告を出さないと、そのまま登録されてしまう危険がある
。 具体的な実装は比較的簡単な方法である。病名はグループ化されており、同一グループは同時に指定できないという方法でこれを実現している。
 同一グループが同時に指定された場合は、警告をだしてオペレータにどのように処理するかを確認する。

5. 病名-処置チェック

 処置や手術には、それを行うために必須な病名がある。それぞれの処置にはどの病名が必須であるかというデータが登録されている。入力時には処置の対象部位につけられている病名と比較して、適切な病名がなければ警告が発生する。
 また、このデータには評価対象が個々の歯であるか、指定された部位全体であるかといった情報も折り込まれている。

6. 処置のプロパティ

 処置は対象とする部位に応じて算定されるかどうか、算定されるとすれば幾つかということが計算される。これらの元になるデータはそれぞれの処置の中でプロパティとして定義される。
 具体的には、対象とする歯の種別、上下顎、支台歯かダミーか、残存歯か欠損歯かなどで対象の部位を絞りこみ、残った部位を指定された単位でカウントする。義歯なども場合、さらにカウントした結果が指定範囲内にあるかどうかで算定可能かどうかを判断する。
 このチェックは履歴を参照しないで、与えられた部位だけを評価するものである。

7. 処置-処置チェック

 エラーチェックの中心となる処理である。主に過去にどのような処置が施されているかを評価することで、注目している処置が選択可能か、あるいは算定可能かを判断する。
 このチェックは評価式として表現される。対象とする処置、期間、単位をパラメータとして関数を作用させる。関数には、存在するかどうかを確認する、数を数える、年令をかえす、などさまざまなものが用意されている。この関数がそのまま評価となる場合もあるし、この関数の結果をさらにある数値と比較演算したものを結果とする場合もある。最終的な評価は、「算定」「警告」「選択不可」「算定不可」の4段階となる
 また、より複雑かつ柔軟なチェックができるように、複数の評価式を論理演算子で結合して評価することができる。

8. チェックから入力支援へ

 初期のレセコンにおいてエラーチェックは月末に一括して行われるものであった。しかし、現在のレセコンではチェックは入力時にリアルタイムで行われるのが常識となっている。
 このリアルタイムのチェックと診療パターン入力を組み合わせることで、病名と歯牙の状態、過去の履歴を元にもっとも確度の高い診療行為をナビゲートしたり、逆にある診療パターンから妥当な病名の候補を挙げたりという入力支援機能という側面がより重要視されるようになってきた。
 これに伴ってチェックの内容も純粋な保険のルールは相対的に少なくなり、チェックの大部分は歯科治療の流れや常識を表現するものへと変化している。

図1 病名-処置チェックの例
図2 処置のプロパティの例
図3 評価式の例
図4 入力支援機能