他院から届く紹介状を読み取って、受付の登録項目と予約の段取りの下書きを作る

処理の起点を決める

受付用のストレージにファイルが保存されたことを起点にします。 複合機のFAX受信の保存先をここに向けます。従量課金の Azure Logic Apps では、Azure Blob Storage のトリガー「BLOB が追加または変更されたとき (プロパティのみ)」が使えます。

このトリガーは、コンテナーのルート フォルダーで起動し、設定した時点ですでにある BLOB は無視します。 受付用の保存先は1階層にし、稼働前に溜まっていた紹介状は別の手順で流し直します。

1日1回の定時実行にはしません。 紹介元は当日か翌日には受診日の連絡を待っています。処理が終わったファイルは、成功したときだけ処理済みの保存先へ移します。残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、下の3つです。 紹介元の一覧にFAX番号が無ければ、医療機関名の読み取りだけに頼ることになり、表記ゆれで引けません。診療科の取り決め（「整形外科の紹介枠は火曜と木曜の午前」など）は職員の頭の中にあることが多く、書き出せない取り決めは下書きにも反映できません。

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

読み取りは、ワークフローからレイアウトモデル（モデルID prebuilt-layout）を呼び出し、features=keyValuePairs を指定してキーと値のペアも返させます。

outputContentFormat=markdown を指定すると、表や見出しの構造を残したテキストでも受け取れます。 生成AIにはMarkdownを、信頼度の判定には元のJSONを使います。紹介元の照合は、FAX番号が先、医療機関名が後です。

AIへ渡す前に整形する

1. 形式とサイズの確認 … PDFまたは画像であること。PDFとTIFFは最大2,000ページ、有料（S0）レベルで500MBが上限です
2. 画像の寸法の確認 … 50×50ピクセルから10,000×10,000ピクセルの間である必要があります
3. 解像度の確認 … 抽出するテキストの最小の高さは、1024×768の画像で12ピクセルです。150dpiで約8ポイントの文字に相当します
4. ロックの解除 … パスワードでロックされたPDFは、提出前にロックを解除する必要があります
5. FAX送付状の切り分け … 段落の役割（title など）と表題で送付状を見分け、本文と分けます
6. 複数の患者の分割 … 1ファイルに複数の患者分があれば、表題の繰り返しで区切ります
7. 重複の検知 … FAXのあとに届いた原本は、紹介元・氏名・日付で照合して既処理の印を付けます

3番目と7番目を軽く見ないでください。 FAXの標準的な画質はこの下限に近いことがあり、紹介元に高画質での送信をお願いするだけで読めない箇所が減ります。 FAXと原本を別々に受付すると、同じ紹介が2件の予約になります。

AIに処理させる

させるのは、受付に要る項目を紹介状に書かれたとおりに取り出し、項目ごとに「書かれている／書かれていない／読めない」を分けることです。

右端の列が、最も大事な区別です。 missing は紹介元に確認するもの、unreadable は画像を見れば職員が読めるもの、ambiguous は紹介元か診療科に確かめるものです。混ぜると、むだな電話が増えるか、確かめるべき箇所が素通りします。

1行目と2行目が、最も起きやすい逸脱です。 「胸痛、心電図でST変化」とあれば、生成AIは循環器内科と推し、急ぎと判断したくなります。当たっていても、書かれていない判断が混ざった時点で、職員は紹介状を読み直さなくなります。

指示内容を固定する

あなたは病院の地域医療連携室で、他院から届いた紹介状を受付する担当者の補助です。
OCRが返した読み取り結果だけを見て、受付に要る項目を取り出してください。
推測で埋めないでください。医学的な判断をしないでください。

【取り出す項目】
1. 患者：氏名、フリガナ、生年月日、性別、電話番号、住所
2. 紹介元：医療機関名、医師名、電話番号、FAX番号
3. 紹介の目的と傷病名
4. 紹介先の診療科と医師の指定
5. 希望日と、急ぎに関する記載
6. 添付資料の記載（画像のCD、検査結果など）とチェック欄の状態

【status の選び方】
- ok ......... 値が書かれており、読み取れている
- missing .... 値が書かれていない。欄名だけがあって値が空の場合も missing
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 値の候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 記載がなければ value は空にし、status を missing にしてください。
  他の項目や文脈から補って埋めないでください。
- 氏名は書かれた字形のまま写してください。旧字体や異体字を
  一般的な字に直さないでください。
- 生年月日は書かれた表記を raw にそのまま写し、西暦の日付を value に入れてください。
  数字が読めない場合は換算せず unreadable にしてください。
- 紹介先の診療科が書かれていない場合、傷病名や症状から診療科を
  推測しないでください。missing にしてください。
- 急ぎかどうかを判断しないでください。「至急」「本日」など、
  急ぎに関する言葉が書かれていれば、その言葉をそのまま写してください。
- 傷病名と紹介の目的は、書かれた言葉を短く写してください。
  言い換えやまとめをしないでください。
- evidence には、判定の根拠にした文字列をそのまま写してください。
- confidence は OCR が返した値のうち、その項目で最も低いものを入れてください。
- 紹介状でない書類（FAX送付状、返書、検査結果だけの紙など）と判断した場合は、
  項目を取り出さず document_type に種類を書いてください。

【読み取り結果（Markdown）】{layout_markdown}
【項目ごとの信頼度】{confidence_table}
【送信元の情報】{fax_meta}
【紹介元の一覧の照合結果】{referrer_match}

「傷病名や症状から診療科を推測しない」を明記しないと、ほぼ確実に埋めます。 禁じるのは推測の結果ではなく、推測という行為そのものです。氏名の字形の指示も省けません。 旧字体をよく使われる字に直して返すと、受付システムの検索が1文字違いで外れ、同じ人を二重に登録します。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力を使い、response_format に json_schema を指定して strict: true にします。

{
  "document_type": "referral_letter",
  "patient": {
    "name":       { "value": "", "status": "ok | missing | unreadable | ambiguous", "confidence": 0, "evidence": "" },
    "kana":       { "value": "", "status": "", "confidence": 0, "evidence": "" },
    "birth_date": { "raw": "", "value": "", "status": "", "confidence": 0, "evidence": "" },
    "sex":        { "value": "", "status": "", "confidence": 0, "evidence": "" },
    "phone":      { "value": "", "status": "", "confidence": 0, "evidence": "" }
  },
  "referrer": {
    "facility": "", "doctor": "", "fax": "",
    "master_match": "matched | not_found | multiple"
  },
  "purpose":        { "value": "", "status": "", "evidence": "" },
  "diagnosis":      { "value": "", "status": "", "evidence": "" },
  "target_dept":    { "value": "", "status": "", "evidence": "" },
  "requested_date": { "value": "", "status": "", "evidence": "" },
  "urgency_words":  [],
  "attachments":    [ { "kind": "", "status": "", "evidence": "" } ],
  "handwritten_ratio": 0
}

1つ目の理由は、項目ごとの status で、確認画面の色付けを決められることです。 2つ目は、予約の段取りを別の層に置けることです。 段取りの候補は、ワークフローが診療科の取り決めと突き合わせて作ります。

スキーマの制約も先に押さえます。 構造化出力では、すべてのフィールドを必須にして任意の項目は null との共用体型で表し、additionalProperties: false を設定します。プロパティは最大100個、入れ子は最大5階層です。文字列の pattern や format はサポートされないので、電話番号の形式の確認はワークフロー側で行います。

システムへ連携する

受付システムと電子カルテには書き込みません。 既存の患者の検索も、受付システムから書き出した一覧を読むだけにします。書き込みの経路を作らないことで、取り違えが自動で登録に進む道を最初から断ちます。

Azure Blob Storage のマネージド コネクタのアクションは50MB以下のファイルを扱い、マネージド トリガーはポーリングする仮想フォルダー内で30,000個の BLOB に制限されています。処理済みのファイルを受付用の保存先に残さないのは、この制限に近づかないためでもあります。

人が確認する

職員は全件の下書きを見ますが、見る深さを変えます。 患者の同定と予約の確定は人が行うので、1通も素通りにしません。

1. 患者の候補を先に見る … 既存の患者の候補が0件、1件、複数件のどれかを見ます。1件でも、生年月日と電話番号の両方が一致しているかを目で確かめます
2. 色の付いた項目を見る … unreadable は画像を開いて読み、missing は連絡文の確認事項に入っているかを見ます
3. 急ぎの記載を見る … urgency_words があるものは、その場で診療科に連絡します。 下書きの一覧に置いたままにしません
4. 段取りの候補を選ぶ … 候補の枠から選び、受付システムで予約を確定します
5. 連絡文を直して送る … 送信そのものは職員が行い、下書きを直した項目は記録に残します

1番目を省かないでください。 同姓同名で生年月日も同じ患者は珍しくなく、電話番号まで一致して初めて同じ人の可能性が高いと言えます。 目標は、600通をならして1通4分です。

例外に対処する

1行目が最も多く起きます。 原因はAIではなくFAXの画質と送信の設定です。「候補が複数」の行も大切です。 先頭の候補を選ぶ処理を入れると、いずれ別人に紐付けます。

記録を残す

• 元の紹介状ファイルと、受け取った日時・経路・送信元のFAX番号
• OCRが返したJSONの全文（テキスト、表、チェック欄、手書きかどうか、信頼度）
• 生成AIが返したJSONと、そのとき参照した紹介元の一覧と診療科の取り決めの版
• 患者の候補として出した一覧と、職員が選んだ患者番号と選んだ人
• 職員が下書きを直した記録 … どの項目を、どう直したか
• 予約を確定した日時と、紹介元へ連絡した日時
• 紹介元ごとの unreadable と missing の発生率

4つ目の「選んだ人」を残すのは、取り違えが起きたときに、照合の仕組みの問題か確認の手順の問題かを切り分けるためです。 最後の行は、紹介元に書式の見直しをお願いする根拠になります。