動物病院で獣医師が手書きする診療記録と処置の伝票を読み取り、会計の入力にそろえて、処置・投薬・検査の会計漏れを拾う

処理の起点を決める

受付が伝票と診療記録をスキャナーに通し、共有フォルダに保存されたことを起点にします。 会計の前に下書きを出したいので、1枚ずつ、届いたらすぐに処理します。 まとめて処理すると、会計に間に合いません。

スキャンは、伝票と診療記録を1組にして、伝票が先になる順で通します。スキャナーの設定で、ファイル名に日時と診察券の番号（バーコードを伝票に貼る場合はその番号）を入れます。 番号で同じ診察の伝票と記録を結び付けるためです。

閉院後の突き合わせは、電子カルテから会計の明細の CSV を書き出し、決めたフォルダに置いたことを起点にします。 書き出しは受付の最後の作業として手で行います。電子カルテから自動で取り出せる口があれば、それを使います。

入力データを集める

質を決めるのは、略語の対応表です。 「SC」「皮下」「補液」「sub-Q」が同じ処置なら、4つの書き方を1つの項目コードに当てる行を作ります。対応表に無い書き方は、項目に当たらずに人へ回ります。

最初の対応表は、過去の診療記録から作ります。 獣医師4名がそれぞれ1週間分の記録を見て、自分の書き方を書き出すのが早道です。 獣医師ごとの癖を、本人がいちばん知っています。

データの取得方法を決める

伝票は、学習させたカスタム テンプレート モデルで読み取ります。伝票の各項目のチェックの欄を選択マークのラベル、数量の欄を文字のラベルとして学習させます。

診療記録は、レイアウト モデルで文字の行と単語を信頼度つきで取ります。行の並びをそのまま生成AIに渡し、処置・投薬・検査の記載だけを抜き出させます。

信頼度の扱いを決めておきます。 公式の説明では、分析の結果は単語・キーと値・選択マーク・署名などに0から1の推定の信頼度を返し、正確さが重要な場面では、信頼度で自動で受け入れるか人の確認に回すかを決められるとされています。カスタム モデルでは、欄の信頼度と、その欄の文字や選択マークの読み取りの信頼度の両方を見ることが勧められています。

閾値は最初から決めず、最小構成で30枚を読み、目で確かめた結果から決めます。 数量の欄は会計の金額に直結するので、チェックの欄より閾値を高くします。

AIへ渡す前に整形する

1. 形式の確認 … PDF か画像（JPEG/JPG、PNG、BMP、TIFF、HEIF）であることを確かめます
2. 画像の寸法の確認 … 50×50 ピクセルから10,000×10,000 ピクセルの間である必要があります
3. 文字の大きさの確認 … 読み取る文字の高さの下限は、1024×768 の画像で12ピクセルです。150dpi で約8ポイントにあたるので、スキャナーは300dpi に設定します
4. 伝票と記録の組み分け … ファイル名の診察券の番号と時刻で、同じ診察の伝票と記録を1組にします
5. 向きの確認 … 伝票が逆さに通されていないかを確かめます。テンプレート モデルは書式の見た目に頼るので、向きの違いで欄を外します
6. 重複の確認 … 同じ番号・同じ時刻の伝票が既にあれば、通し直しか重複かを受付に聞きます

3番目を軽く見ないでください。 獣医師の数量の書き込みは小さく、「0.5」と「5」の違いは小数点1つです。 解像度が足りないと、点が消えて10倍の数量が下書きに入ります。

AIに処理させる

Azure AI Document Intelligence にさせるのは、伝票と記録の文字とチェックを読み取ることです。 そのうえで、Azure OpenAI に診療記録の文字の行を渡し、次のことをさせます。

4行目の「予定の区別」が、この構成でいちばん大事なところです。 診療記録には「次回 エコー」「飼い主と相談の上 血液検査を検討」のように、今日は行っていない処置も書かれています。 これを今日の会計漏れとして出すと、受付は行っていない処置を請求しかけます。

1行目を生成AIにさせないのは、項目コードが会計そのものだからです。 「皮下補液」を「静脈点滴」のコードに当てれば、金額が変わります。当てはめは対応表という決まった表で行い、当たらないものは人へ回します。

指示内容を固定する

あなたは動物病院で、獣医師が手書きした診療記録から、
今日行った処置・投薬・検査の記載を抜き出す係です。
渡した文字の行だけを見てください。推測で埋めないでください。

【やること】
文字の行から、処置・投薬・検査にあたる記載を1件ずつ抜き出す。
それぞれについて、次を付ける。
- category ... procedure（処置）／ medication（投薬・処方）／ test（検査）
- written .... 記録に書かれたとおりの言葉（略語のまま。直さない）
- amount ..... 書かれた量・回数・日数（書かれたとおり。単位も写す）
- timing ..... done_today（今日行った）／ planned（次回以降の予定）／
               proposed（提案・検討）／ unclear（決められない）
- status ..... ok ／ unreadable（字が読めない）／ ambiguous（種類が決まらない）
- line_no .... 根拠の行の番号

【厳守事項】
- written は記録の言葉をそのまま写すこと。正式な名前に言い換えないこと。
  「SC」を「皮下補液」に、「CBC」を「血液検査」に直さないこと。
- 量は書かれたとおりに写すこと。計算しない、単位を変えない、
  体重から量を出さないこと。
- 「次回」「予定」「検討」「様子を見て」などの言葉が付いた記載は、
  done_today にしないこと。
- 単語の信頼度が低い語（{low_conf_words} に並べたもの）を含む記載は、
  status を unreadable とし、読めた部分だけを written に写すこと。
- 字が読めない記載を、前後の文脈から推し量って埋めないこと。
- 所見・診断・飼い主への説明は抜き出さないこと。
- 請求すべきか、会計の項目のどれに当たるかは書かないこと。
- 根拠の行の番号を必ず付けること。番号を付けられない記載は出さないこと。

【文字の行（行の番号つき）】{lines}
【信頼度の低い語】{low_conf_words}

「略語のまま、言い換えない」を明記しないと、正式な名前に直します。 直された言葉は対応表に当たらず、当たったとしても、獣医師の書いた言葉が記録から消えます。 当てはめは対応表に任せるので、生成AIの仕事は書かれた言葉を正確に写すことです。

「次回」「検討」の言葉を例で挙げているのも同じ理由です。 何も言わなければ、記録に書かれた処置を全部 done_today で返します。

出力形式を固定する

Azure OpenAI の構造化出力で抜き出しを受け取り、Python で伝票・対応表と突き合わせた結果を次の形にまとめます。

{
  "visit_id": "20261014-0815-C10423",
  "vet": "獣医師B",
  "slip_items": [
    { "code": "T-0102", "name": "皮下補液", "checked": true, "amount": "150ml",
      "confidence": 0, "status": "ok | low_confidence" }
  ],
  "chart_items": [
    { "written": "SC 150", "category": "procedure", "timing": "done_today",
      "mapped_code": "T-0102", "map_status": "mapped | not_in_table",
      "status": "ok | unreadable | ambiguous", "line_no": 7 }
  ],
  "diffs": [
    { "type": "chart_only | slip_only | amount_mismatch",
      "code": "", "detail": "", "line_no": 0 }
  ],
  "draft_lines": [ { "code": "T-0102", "qty": "150ml", "source": "slip | chart" } ]
}

1つ目の理由は、伝票と記録を別々に持ち、差を diffs に出せることです。

2つ目は、map_status で対応表の穴が見えることです。 not_in_table の書き方は、対応表に足す候補です。毎週数えて、上位から対応表に足します。

閉院後の突き合わせは、draft_lines と会計の明細の CSV を診察ごとに比べます。 下書きにあって会計に無い項目が、会計漏れの候補です。

システムへ連携する

電子カルテの会計に自動で入れないのは、会計が飼い主への請求そのものだからです。 読み取りの誤りや対応表の誤りがそのまま請求に入ると、飼い主との信頼を損ねます。 受付が下書きを見て入力し、獣医師が確かめた項目だけを足します。

人が確認する

1. chart_only を会計の前に獣医師に確かめる … 受付の画面から、診療記録の該当の行の画像を獣医師の端末に送ります
2. 信頼度の低い欄を画像で見る … 特に数量の欄の小数点を確かめます
3. 下書きを会計に入力する … 対応表に当たった項目は、コードと数量を写すだけです
4. 閉院後の会計漏れの候補を見る … 会計の担当が翌朝に一覧を見て、漏れか、意図して請求しなかったものかを獣医師に確かめます

1番目は、獣医師の手を止めない形にします。 受付が診察室まで聞きに行くのではなく、該当の行の画像と「この処置は今日の会計に入れますか」の問いを端末に送り、獣医師は診察の合間に「入れる／入れない」を押すだけにします。返事が来るまで、その飼い主の精算は待ってもらいます。

4番目で「意図して請求しなかった」を分けるのが大事です。 再診のサービス、院内で決めた割引、獣医師の判断で請求しない処置があります。漏れと決めつけずに、獣医師の判断を記録に残します。

例外に対処する

1行目は、導入の後に必ず起きます。 伝票の版を変えたのに古い伝票が引き出しに残っていると、その伝票だけ欄がずれて読み取りが外れます。 テンプレートのモデルは見た目に頼るので、版を変えるときは古い紙を処分し、新しい版でモデルを学習し直します。

記録を残す

• 伝票と記録の画像と、スキャンした日時
• 読み取りの結果の JSON（欄の値・選択マークの状態・信頼度・文字の行）
• 生成AIの抜き出しの結果と、対応表での当てはめの結果（そのときの対応表の版）
• diffs と、受付・獣医師がどう扱ったか（請求した／請求しない／記録の書き漏れ）
• 閉院後の会計漏れの候補と、翌日の扱い
• 獣医師ごとの chart_only の件数と、not_in_table の書き方の一覧

3つ目で「そのときの対応表の版」を残すのは、対応表が毎週変わるからです。 同じ「SC」が、ある週は当たらず、翌週は当たるようになります。どの版で当てたかが残っていないと、過去の会計漏れの候補を見直すときに、なぜ出たのか、なぜ出なかったのかが分かりません。

最後の行は、獣医師への声かけの材料になります。 chart_only が多い獣医師は、伝票のチェックを付け忘れやすい人です。責めるためではなく、伝票の項目の並びが使いにくいのかを聞くために使います。