外国人の患者が持参する英文の紹介状・診療記録・処方記録を読み取り、既往歴・服薬・アレルギーを受付の登録項目と医師向けの要約にそろえる

処理の起点を決める

受付フォルダ（Amazon S3）に書類が保存されたことを起点にします。 受付でスキャンしたもの、受付の端末で撮影した写真、アシスタンス会社からメールで届いたPDFを、受付番号の名前のフォルダに入れます。保存の通知で AWS Lambda が動きます。

事前に届く書類は、来院の前に処理を終えておきます。 アシスタンス会社から前日に送られてきた診療記録は、その日のうちに読み取りと要約の下書きまで済ませ、来院時には職員の確認だけが残るようにします。

来院してから受け取る書類は、受付から診察までの待ち時間で処理します。 読み取りから要約の下書きまでが待ち時間に収まるかを、試すときに必ず測ります。

入力データを集める

質を決めるのは、受付の登録済みの値です。 書類の患者と受付の患者が同じ人かを、氏名と生年月日の2つで照らします。 家族の書類が混ざることがあるので、照合を省きません。

医学略語の一覧は、院内の薬剤部と一緒に作ります。 一覧にある略語だけ意味を添え、一覧に無い略語は原文のまま残して印を付けます。

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

読み取りは StartDocumentAnalysis にS3の場所と FeatureTypes を渡して始めます。完了は NotificationChannel に指定した Amazon SNS のトピックに通知され、状態が SUCCEEDED なら GetDocumentAnalysis で結果を取ります。

質問の答えは要約の材料の1つにすぎません。 答えが見つからなければ空のまま返り、空の答えは「書類に書かれていない」の候補として扱い、全文で確かめてから not_documented にします。 薬の一覧は質問の答えより TABLES の表のほうが確実で、行ごとに名前・用量・回数が分かれたまま取れます。

結果は1回最大1,000ブロックで区切られます。NextToken が返る限り呼び直し、退院時の要約の後半のページが抜けないようにします。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。スマートフォンの HEIC の写真は JPEG に変換します
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。患者向けのポータルから出したPDFは保護されていることがあるので、その場で患者に解除してもらいます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページ、JPEGとPNGは10MBまでです
4. 写真の解像度の確認 … 文字の高さは最小15ピクセルで、150 DPIで8ポイントの文字に相当します。処方記録の小さな字は、画面を撮った写真では下回りやすいので、受付の端末で撮り直します
5. 書類の言語の確認 … 受付で患者に確かめ、6言語に入らない書類は読み取りに回しません
6. 識別番号の伏せ字 … 保険の証券番号、国民識別番号、医療機関の患者番号は、生成AIへ渡す前に下4桁以外を伏せます

4番目がいちばん効きます。 服薬の行が unreadable になる多くは、スマートフォンの画面をさらに撮った写真です。受付で「PDFを送ってください」と頼める仕組みを先に作ります。

AIに処理させる

させるのは、読み取り結果から受付の項目を取り出し、アレルギーに区分を付け、原文の語を添えた日本語の要約を下書きすることです。 判断はさせません。

アレルギーの4つの区分は次のとおりです。

NKDA は「薬のアレルギーが知られていない」で、食物やラテックスについては何も言っていません。 documented_none の範囲を scope: drug として残し、食物のアレルギーは not_documented のまま問診で聞く項目にします。

2行目の誤りは、日本語にする段階で起きます。 「1日2回」と訳したつもりで「1日1回」と書く、0.5mg の小数点を落とす。要約では、薬の行に必ず原文の文字列を括弧で並べます。

指示内容を固定する

あなたは病院の国際診療の窓口で、外国人の患者が持参した英文の書類を
受付の項目にそろえ、医師向けの要約を下書きする担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。
あなたは診断・処方・薬の評価をしません。

【取り出す項目】
patient（氏名・生年月日）、history（既往歴・診断）、
medications（服薬）、allergies（アレルギー）、referral（紹介元）。
各項目に raw（読んだ文字列そのまま）、status、source を入れてください。

【アレルギーの区分】
- documented ....... 物質と反応が書かれている
- documented_none .. 無いことが明記されている（NKDA、No known allergies など）。
                      scope に drug / food / all のどれが明記されているかを入れる
- not_documented ... アレルギーについての記載がどこにも無い
- ambiguous ........ 別の書類を指している、または読み方が複数ある
記載が見当たらないことを「アレルギーなし」としないでください。

【服薬の扱い】
- name、dose、unit、frequency、route を原文のまま分けてください。
- 単位（mg、mcg、g、mL、IU）と回数の略語（QD、BID、TID、QID、PRN）を
  書き換えないでください。略語の意味は abbreviation_note に別に書いてください。
- 一覧に無い略語は意味を書かず、unknown_abbreviation に入れてください。
- 国内の商品名に置き換えないでください。
- 読めない文字を、よくある用量で埋めないでください。status を unreadable にしてください。

【要約の書き方】
- 日本語で書き、病名・薬の名前・用量・アレルギーは原文の文字列を括弧で添えてください。
- 「書類からは分からない項目」を最後に箇条書きにしてください。
- 診断の推測、検査や治療の提案、薬の評価を書かないでください。

【厳守事項】
- 伏せ字（****）を復元しないでください。
- 書類の患者が誰かを推測しないでください。氏名と生年月日は原文のまま返してください。
- 英文の医療の書類でないと判断した場合は document_type を other としてください。

【読み取り結果】{textract_result}
【医学略語の一覧】{abbreviation_list}

「よくある用量で埋めない」を明記しないと、読めない数字を埋めます。 Metoprolol __mg の空白に、もっともらしい数字を入れます。もっともらしいほど、職員が画像と見比べるときに見落とします。

出力形式を固定する

Claude API の構造化出力（output_config.format に json_schema を指定）で、次の形のJSONを受け取ります。

{
  "reception_id": "",
  "patient": { "name_raw": "", "dob_raw": "", "dob": "", "status": "" },
  "allergies": {
    "category": "documented | documented_none | not_documented | ambiguous",
    "scope": "drug | food | all | unknown",
    "items": [ { "substance_raw": "", "reaction_raw": "", "source": "" } ]
  },
  "medications": [
    { "name_raw": "", "dose_raw": "", "unit_raw": "", "frequency_raw": "",
      "route_raw": "", "abbreviation_note": "", "status": "ok | unreadable", "source": "" }
  ],
  "history": [ { "term_raw": "", "term_ja": "", "source": "" } ],
  "unknown_abbreviation": [],
  "summary_ja_draft": "",
  "not_in_documents": []
}

1つ目の理由は、アレルギーの区分を文字列ではなく決まった値で持てることです。 受付の画面の「アレルギー」欄に何を出すかを、区分ごとに決めておけます。

2つ目は、薬の行を _raw の項目に分けて持てることです。 職員は画像の行と JSON の行を左右に並べ、名前・用量・単位・回数を1つずつ見比べられます。 要約の文章の中から数字を探すより、確かめる時間が短くなります。

3つ目は、not_in_documents で問診で聞き直す項目が残ることです。 要約を読んだ医師が、何が書類から分かっていて何が分かっていないかを、最初の1分で把握できます。

システムへ連携する

電子カルテへは、この構成から直接書き込みません。 アレルギーの欄や薬の欄に読み取りの結果が確認を経ずに入ると、誤りが処方の画面まで一息に進みます。 職員が確認した要約を、既存の文書の取り込みの手順で入れます。

人が確認する

窓口の職員は、アレルギーと服薬の行を書類の画像と1行ずつ見比べます。 既往歴と紹介元は、根拠の文字列と並べて流し見ます。

1. 患者の特定を確かめる … 書類の氏名と生年月日が受付の登録と合っているか。合わなければ、家族の書類が混ざっていないかを患者に聞きます
2. アレルギーの区分を確かめる … documented_none は原文で範囲を確かめ、not_documented は問診票の先頭に置きます
3. 服薬を1行ずつ照合する … 名前・用量・単位・回数を画像と見比べ、unreadable は患者に薬の現物か写真を見せてもらいます
4. 要約を確かめて医師に渡す … 原文の文字列と訳が合っているかを見ます

3番目の照合を省かないでください。 この構成で誤りが患者に届くとしたら、ほとんどがここです。1件15分の大半をここに使う想定です。

例外に対処する

下から2行目を最初に決めてください。 急いでいる患者に、仕組みの処理を待たせる理由はありません。この構成は、待ち時間がある受診のためのものです。

記録を残す

• 元の書類ファイルと、受け取った日時、受付番号、受け取った経路
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSONと、要約の下書き
• 職員が直した箇所の記録 … アレルギーの区分、薬の行、要約のどこを直したか
• 医師へ渡した要約の版と、電子カルテへ取り込んだ日時

4つ目は、指示と略語の一覧を直す材料になります。 同じ略語で毎回直しているなら一覧に足し、not_documented を documented_none に直した記録が続くなら、指示の書き方を見直します。