見出し画像

医療事務領域BPaaSにおけるLLMの活用事例


前置き

この記事は「BPaaS/AI+BPO Advent Calendar 2025」9日目の記事です。

こんにちは、株式会社MEBAISの代表取締役であり、エンジニアとしてLLMを開発した活用を社内で先導(扇動)している三野です。
株式会社MEBAISは
「"つらい"を減らし、"やりたい"を増やす。医療経営の常識を変える。」
をミッションに掲げて医療事務領域の仕事をAI+BPO, BPaaSと呼ばれるような方法で任せていただいているスタートアップ企業です。

MEBAIS社内でのLLM活用は多岐に渡りますが、エンジニアとしてのLLMの活用についてお話しできればと思います。

医療事務領域は、アドベントカレンダー前日のLegalAgentの朝戸さんの記事で記載されている事情とかなり似ています。
https://note.com/eager_jaguar8195/n/nf9f9d90177a8

あえて違いを挙げるとすれば

  • 単価感の違い

  • 顧客が医療法人あり、特に経営が厳しい市況である

  • 特に弊社の現在の主業務であるレセプトは医業収益そのものであるため、1つのミスが顧客のキャッシュフロー上の損失そのものである

といったところでしょうか。

LLMにレセプトを評価してもらう

さて本題ですが、この記事でのテーマは
「レセプトの分析、点検をLLMを活用してやってみる」です。
レセプトとは、日本の医療機関が保険診療を行ったときに作成する「請求書(診療報酬明細書)」のことです。
医療機関は行った診療行為に応じて報酬を受け取りますが、患者さんの自己負担分以外を「審査支払機関」と呼ばれる組織に請求します。
そのため、「この患者がこういう状態だったのでこんな診療をしました、何円ください」みたいなリストを提出するわけですが、それがいわゆるレセプトです。

レセプトデータはここでは保険診療に対する出来高、外来のデータを用いることとします。(専門の方向け)

レセプトデータは.ukeという特殊な拡張子になっていますが、中身はcsvファイルです。ただしヘッダーが固定ではなく、各行ごとに最初の1列目にどのような情報が書いてあるかをメモするための識別情報が記載してあります。

UKEファイルがどんなファイルなのかはこちらの記事を読んでいただくとイメージが湧くかと思います、他力本願。
https://qiita.com/yokenzan/items/6ee089770d8ec4913123

で、このUKEファイルを読み解く方法はhttps://www.ssk.or.jp/seikyushiharai/iryokikan/iryokikan_02.files/jiki_i01.pdf

このファイルに一通り記載してあります。多分いきなり見てもなんのこっちゃわかりませんが、解析しようとするとこれをちゃんと読む必要があります。
これと各診療行為や医薬品などのマスターファイルがまた別に存在し、それらをうまく結合すると各患者のデータが出力できるわけです。

比較的わかりやすい部分として、以下のような構造になっています。

UKEファイルの概要

これをLLMに点検してもらうとどうなるか実験していきます。

今回使うデータ

仕様書等をもとにUKEファイルをパースしたものをhuman-readableにしたマークダウン形式を使っていきます。デモ用患者データは以下のような想定患者です。(高血圧症等を患っており、2025/8に胃腸の具合が悪く来院)

# レセプト患者レポート(8月分)

## 診断(傷病名)

| 傷病名 | 開始日        | 転帰 | 主傷病 | 疑い |
|--------|------------|------|--------|------|
| 高血圧症 | 2024-01-05 | 継続 | - | - |
| 再発性逆流性食道炎(維持療法) | 2024-01-05 | 継続 | - | - |
| 脂質異常症 | 2025-03-20 | 継続 | - | - |
| 急性胃腸炎 | 2025-08-10 | 継続 | - | - |

## 診療内容

### 2025-08-10

#### 診療識別: 12 (再診)

| コード | 名称 | 数量 | 回数 |
|--------|------|------|------|
| 112007410 | 再診料 | - | 1 |
| 112015770 | 明細書発行体制等加算 | - | 1 |
| 112011010 | 外来管理加算 | - | 1 |

#### 診療識別: 21 (内服薬剤)

| コード | 名称 | 数量 | 回数 |
|--------|------|------|------|
| 620000094 | ビオフェルミン錠剤 | 3.00 | 5 |

#### 診療識別: 22 (屯服薬剤)

| コード | 名称 | 数量 | 回数 |
|--------|------|------|------|
| 612390023 | ナウゼリン錠10 10mg | 1.00 | 10 |

#### 診療識別: 80 (その他)

| コード | 名称 | 数量 | 回数 |
|--------|------|------|------|
| 120002910 | 処方箋料(リフィル以外・その他) | - | 1 |
| 120004270 | 一般名処方加算1(処方箋料) | - | 1 |

### 2025-08-15

#### 診療識別: 12 (再診)

| コード | 名称 | 数量 | 回数 |
|--------|------|------|------|
| 112007410 | 再診料 | - | 1 |
| 112015770 | 明細書発行体制等加算 | - | 1 |

#### 診療識別: 13 (医学管理)

| コード | 名称 | 数量 | 回数 |
|--------|------|------|------|
| 113707110 | 生活習慣病管理料2 | - | 1 |

#### 診療識別: 21 (内服薬剤)

| コード | 名称 | 数量 | 回数 |
|--------|------|------|------|
| 622727500 | ニフェジピン20mg徐放CR錠 | 1.00 | 42 |
| 622615600 | ピタバスタチンカルシウム1mg錠 | 1.00 | 42 |

#### 診療識別: 80 (その他)

| コード | 名称 | 数量 | 回数 |
|--------|------|------|------|
| 120002910 | 処方箋料(リフィル以外・その他) | - | 1 |
| 120004270 | 一般名処方加算1(処方箋料) | - | 1 |

このデータを使っていきます。中身に問題があると、返戻、査定と言って医療機関から支払い機関に向けての請求が正しく通らない可能性があります。

ex1. 患者情報を雑に投げてみる

{患者情報のペースト}

レセプトの問題点を教えてください。

特に審査通過しなさそうなポイントを教えてください。

まずは実験です。
結果は以下のようになりました。

ご提示いただいたレセプトデータ(患者レポート)には、**審査支払機関での自動点検(コンピュータチェック)で確実にエラー(査定・返戻)になる「致命的な矛盾」**が含まれています。また、医学的判断により査定されやすいポイントもあります。

以下に、修正すべき重要度順に解説します。

---

### 1. 【致命的】同一月内の「生活習慣病管理料(II)」と「外来管理加算」の併算定
**判定:ほぼ確実に査定(減点)されます**

* **現状:**
    * 8/10(急性胃腸炎の治療)で **「外来管理加算 (112011010)」** を算定。
    * 8/15(高血圧等の定期受診)で **「生活習慣病管理料2 (113707110)」** を算定。
* **理由:**
    * 「生活習慣病管理料(II)」は、**同一月内**における「外来管理加算」などの費用を包括(含んでいる)した点数です。
    * たとえ別の日であっても、同じ月の中にこれらが混在していると、**「外来管理加算」は算定できません。**
    * 8/10の受診が「急性胃腸炎」という別の疾患であっても、同一医療機関・同一月内であれば、包括規定が優先されるケースが一般的です。
* **対策:**
    * 8/10の「外来管理加算」を削除する必要があります。

### 2. 【要注意】「再発性逆流性食道炎(維持療法)」に対する投薬なし
**判定:査定、または傷病名の整理を求められる可能性が高い**

* **現状:**
    * 診断名に「再発性逆流性食道炎(維持療法)」があり、開始日が2024年から「継続」となっています。
    * しかし、8/10、8/15ともに、この病名に対する**治療薬(PPIやP-CABなど、タケキャブやネキシウム等)が処方されていません。**
* **理由:**
    * 「維持療法」と明記しているにもかかわらず、薬が出ていないのは医学的に矛盾します。「治癒した」のか「経過観察」なのかが不明瞭です。
    * 特に、今回処方されている「ニフェジピン(カルシウム拮抗薬)」は、副作用として下部食道括約筋を弛緩させ、逆流性食道炎を悪化させる可能性がある薬剤です。この状況で逆流性食道炎の薬が出ていないのは不自然と見られる可能性があります。
* **対策:**
    * もし投薬が不要な状態なら、転帰を「治癒」にして病名を切る。
    * もし他院で貰っているならレセプト摘要欄に「他院にて投薬」等の注記が必要ですが、基本的には病名の整理(削除)が望ましいです。

### 3. 【軽微・確認】ナウゼリン錠の用法・用量
**判定:返戻にはならないが、内容点検で目をつけられる可能性あり**

* **現状:**
    * ナウゼリン錠10 10mg:数量1.00 × **回数10**
* **理由:**
    * 急性胃腸炎に対する「頓服(とんぷく)」としての処方と思われますが、一般的に頓服は「1回1錠、10回分」と入力する場合と、内服のように入力する場合でレセコンの出力が変わることがあります。
    * 急性胃腸炎で「10回分(10錠)」の制吐剤は、やや過剰と判断される地域・審査員もいます(通常3〜5回分程度が多い)。
* **対策:**
    * 医学的に必要であれば問題ありませんが、可能であれば回数を減らすか、あるいは「数日間定時で飲む(内服扱い)」にする方が自然な場合があります。

---

### 修正後のイメージ(あるべき姿)

審査を通過させるためには、最低限以下の修正が必要です。

#### 1. 8月10日の算定修正
| コード | 名称 | 数量 | 回数 | 変更点 |
|--------|------|------|------|--------|
| 112007410 | 再診料 | - | 1 | |
| 112015770 | 明細書発行体制等加算 | - | 1 | |
| **(削除)** | **外来管理加算** | - | 1 | **削除する** |

#### 2. 傷病名の整理
もし逆流性食道炎の薬を出していないなら、転帰をつける。

| 傷病名 | 転帰 |
|--------|------|
| 再発性逆流性食道炎(維持療法) | **治癒** (日付を入れる) |

### まとめ
一番の問題は **「生活習慣病管理料を算定する月は、他の日の外来管理加算も取れない」** というルールへの抵触です。ここだけは直さないと、ほぼ確実にエラーが出ます。

あれ?結構良さそうじゃない?となりますが、実は間違いだらけです。問題点は以下のとおりです。

  • 併算定不可条件による外来管理加算の削除提案が出ているが、別日の算定の場合は条件を満たせば算定できる
    https://aichi-hkn.jp/news/16678

  • 生活習慣病管理料を算定するために高血圧症または脂質異常症を主病にする提案がでいない(https://www.credo-m.co.jp/column/detail/hosyu/15679/

  • (現場からすると)余計だと感じるかもしれない提案も出ている
    → ナウゼリン錠の用法・用量の件。

ex2. 保守的な指摘をなくしてもらう

正しくない指摘をされるのも当然嫌ですが、そこはRAG等で改善していくとして、現場としては余計な提案をたくさん出される苦労が既存のレセチェッカーでの大きなペインです。まずはそこを改善していきましょう。

レセプトデータ(電算処理システム用)を分析し、問題点を指摘してください。


ただし、以下の制約を厳守してください。



1. **指摘は「審査機関で間違いなく減点・査定の対象となる致命的な問題」に限定すること。**

2. **形式的な不備、軽微なコメント不足、または医学的に許容範囲内の判断に関する指摘は一切行わないこと。**

3. **特に「傷病名と診療行為の適応(適応病名)」について、医学的根拠を完全に欠く、または保険診療上の算定ルールに明確に違反しているケースのみを抽出すること。**

4. **提案や「確認すべきこと」などの余計な情報は一切含めず、純粋な問題点の指摘リストとして出力すること。**

5. **出力はMarkdownの箇条書きまたは表形式を使用し、簡潔にまとめること。**




特に、審査通過しなさそうなポイントを教えてください。

{患者情報のペースト}

以下が結果です。

レセプトデータ致命的問題点リスト
指定された制約に基づき、審査機関において返戻・減点・査定の対象となる致命的な不備のみを抽出しました。

1. 「生活習慣病管理料II」と「外来管理加算」の同一月併算定不可
該当箇所: * 2025-08-10:外来管理加算(112011010)

2025-08-15:生活習慣病管理料2(113707110)

違反理由: 「生活習慣病管理料」を算定する月において、同医療機関で「外来管理加算」は算定できない。日付や対象疾患(急性胃腸炎と高血圧等)が異なっていても、同一月内の算定は包括規定により認められないため、8月10日の外来管理加算は全額査定(削除)対象となる。

2. 「生活習慣病管理料II」における主傷病の未指定
該当箇所: * 診断(傷病名)データ全体

2025-08-15:生活習慣病管理料2(113707110)

違反理由: 生活習慣病管理料の算定要件として、対象となる傷病(高血圧症、脂質異常症、糖尿病のいずれか)が**「主傷病」**として登録されていることが必須である。 提出データにおいて「高血圧症」「脂質異常症」の主傷病フラグがいずれも「-(なし)」となっているため、算定要件を満たさず返戻または査定対象となる。

3. 一般名処方加算1と処方薬剤コードの矛盾(8月10日分)
該当箇所: * 2025-08-10:一般名処方加算1(120004270)

2025-08-10:ナウゼリン錠10 10mg(612390023)

違反理由: 「一般名処方加算1」は、後発医薬品が存在する全ての医薬品が「一般名(成分名)」で処方されている場合に算定可能である。 しかし、処方されている「ナウゼリン(612390023)」は先発品(ブランド名)の個別薬品コードであり、一般名処方の要件を満たしていない。加算1の要件不適合により査定、または加算2への振替対象となる。

さて、1の指摘は正しくないものの、先ほどと同じように出ました。2, 3はさっき出ていなかった指摘です。ちなみに3も間違いで、今回の場合は問題ないです。

さっきと指摘内容がかなり変わっているので、回答がどの程度ぶれるのか確認したくもう一度試してみます。

ex3. もう一度同じプロンプトで実験してみる

以下が結果です。

提示されたレセプトデータを分析し、審査機関において返戻・減点(査定)の対象となる致命的な問題点を指摘します。

1. 同一月内における「生活習慣病管理料」と「外来管理加算」の併算定違反
対象: 8月10日(外来管理加算)および 8月15日(生活習慣病管理料2)

違反内容: 診療報酬点数表の規定により、同一月内に生活習慣病管理料(Ⅰ・Ⅱ)を算定した場合、同月内の他の日であっても外来管理加算は一切算定できません。

結果: 8月10日の「外来管理加算(112011010)」は原則として全額査定(減点)されます。

2. 生活習慣病管理料の算定要件となる「主病」フラグの欠落
対象: 高血圧症、脂質異常症

違反内容: **生活習慣病管理料2(113707110)を算定するためには、対象となる疾患(高血圧症、脂質異常症、糖尿病のいずれか)がレセプト上で「主傷病(主病)」**として登録されている必要があります。提示データの「主傷病」列がすべて「-(なし)」となっているため、算定要件を満たしません。

結果: 医学管理料(生活習慣病管理料2)が全額査定、またはレセプト自体が返戻されます。

3. 一般名処方加算1と先発医薬品コードの矛盾(8月10日)
対象: 8月10日 処方箋料(一般名処方加算1)

違反内容: 一般名処方加算1(120004270)は、交付した処方箋に含まれる医薬品のうち、後発医薬品が存在する全ての医薬品が「一般名(成分名)」で処方されている場合に算定可能です。 しかし、8月10日の処方薬には先発医薬品である**「ナウゼリン錠10 10mg(612390023)」**の銘柄コードが含まれています。

結果: 「一般名処方加算1」の要件を満たさないため、加算分が査定、あるいは「一般名処方加算2」への振替査定となります。

4. 処方薬剤と適応病名の不一致(8月15日)
対象: ニフェジピン20mg徐放CR錠、ピタバスタチンカルシウム1mg錠

違反内容: 上記薬剤はそれぞれ「高血圧症」「脂質異常症」に対応していますが、これらの傷病名の診療開始日(高血圧症:2024-01-05、脂質異常症:2025-03-20)に対し、レセプト記載の傷病名データ上、これらの疾患が**「継続」**となっていても、8月15日時点で有効な診療実日数や医学管理の整合性がシステム上で厳密にチェックされる際、前述の「主病フラグなし」の問題と複合して、慢性疾患に対する投薬の正当性が医学管理料否認と共に問われるリスクがあります。 (※ただし、単体での適応不一致ではありませんが、管理料否認に連動して過剰投薬とみなされるリスクがある致命的な構成です)

1,2,3に関しては先ほどと同様の提案が出ていますが微妙に表現が違います。
1, 3は先ほども言った通り誤りで、さらに4という新しい提案が出てきています。

回りくどくやりましたが、結局現状の実験で致命的なのは「実験するたびに回答が微妙に変わる」です。LLMで避けては通れない問題ですね。

医療事務の現場で使っていくために

さて、LLMにただ投げた場合の回答は一見それっぽいが不安定であるところは見てもらったかと思います。間違った提案を出すことに関しては正しいコンテキストを与えてあげることで対策するとして、現状の課題点は

  • 余計な回答は出さない(ex1)

  • 正しい出典元の情報だけを参照する(ex1, 2)

  • 回答の再現性(ex3)

というところに落ち着いてきて、これは医療事務領域のみならず多くの業界のLLM活用の壁になっている要素と同じなのではないでしょうか。

特に回答の再現性は大事で、一度合意した事項に関してまた同じミス(点検漏れ)を起こすと大きな不安につながります。これは作業者が人間であってもAIであっても同じことですね。そうなってくるとRAG(https://qiita.com/Junpei_Takagi/items/f82d31323f00ad895579)の仕組みを使って情報源を固定してもまだ課題が残ります。

現状のアプローチ

それらの課題を解決するために現状MEBAISとして運用しているのが、チェッカーの自動開発という仕組みです。LLMを活用してチェッカーをたくさん半自動で生成して、どんどん改善していくというものです。

ここでいうチェッカーとはレセプトデータ(UKEファイル)に対して特定のルールに基づいて確認をして、提案事項を出すプログラムです。

チェッカーは具体的には

  • https://www.credo-m.co.jp/column/detail/hosyu/15679/
    の内容から、生活習慣病管理料2を算定している患者に適切な主病が存在しているかのチェック

    • 主病として登録し忘れていると思われる病名があれば主病にする提案

    • そもそも対応する病名がなければ病名の確認(生活習慣病管理料2が正しいかどうかの確認)

  • ↑の内容から生活習慣病管理料2と外来管理加算等を併算定していないかのチェック

といった条件を確認して提案してくれるものが無数に生成されると考えてください。この仕組みで作ったチェッカーであれば、提案の再現性が担保されます。と同時に人手でも生成されるチェッカーを確認することで余計な回答は出さない正しい出典元の情報だけを参照するという部分も解消されます。

またこの仕組みであれば実際の患者データをLLMに渡すわけではないので、LLMを提供している会社からの情報流出のようなセキュリティリスクはかなり小さくなります。
ただし、現状全てが完全に自動化できているわけではなく合意事項や査定・返戻事例からの要件定義や、回帰テストの最終確認はまだまだ人手でやっている部分の方が多いです。
ここはどんどんLLM自動化を加速していきたいポイントです。

ここが完全に自動化された時が、全ての医療機関にとって理想のレセチェックを全自動で提供できるようになる大きな一歩と考えています。

ネクストステップ

上記で述べたような仕組みが完成すると、とても大きな省力化になり、医療機関からすると「点検はこうして欲しい」というフィードバックを音声やチャットでした瞬間にチェッカー開発が完了するような世界が見えてきます。

しかしながら人手でチューニングをしていくレセチェッカーというのは昔から存在し、これは顧客からしてみれば「改修がとても早いレセチェッカー」が生まれたに過ぎません。

MEBAISが目指す次のステップは「チェッカーが出した提案を採用するかしないかを判断してくれるAI」だと考えています。
過去のレセプト点検の結果をもとに、どういう場合なら修正の必要があるのかを学習させ「修正の必要のないレセプトの判断」や「医療機関の傾向として必ず採用する提案」から工数を減らし、最終的には全自動でレセチェックのプロセスが完了することを目指します。

念の為の補足

実際にはこのチェッカーの結果を踏まえて人で提案を調整したり、電子カルテの修正を行ったり業務自体も多岐に渡ります。全自動の道のりは正直まだまだ遠いですが、地道に一歩ずつ改善していくのがBPaaSの醍醐味かと思います。
今回お話しした部分はレセプトチェックシステムの中のごく一部のLLM利用シーンであり、社内ではもっと至る所でLLM活用をしています。
今回は少しでも医療事務領域のLLM活用ちょっと面白そうかも、と思ってもらえたら嬉しく、特に大きなインパクトがありそうな部分を切り取りました。

まとめ

「LLM活用にはまだ壁がある。まずは使えるところから使っていく。ただし、最終的にシンプルなゲームチェンジャーになれるポテンシャルがLLMにはある。」と考えているので、その時に向けてLLMが学習、試行錯誤しやすいデータを蓄積しながら地道にBPaaSビジネスを進めています。

株式会社MEBAISでは医療機関のこれからを支えていくために引き続き開発とチーム強化を続けていきます。ご興味を持っていただけた方はTwitterでもFacebookでもLinkedinでもYOUTRUSTでもお気軽にご連絡ください。


いいなと思ったら応援しよう!