海外の治験実施施設・検査機関から毎月届く英文の請求書を読み取り、契約の単価表と来院実績に照らして過大請求を見つける

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 請求書は月初に集中しますが、施設ごとに届く日がばらばらなので、1日1回の定時実行にはしません。 届いた日に照会を出せば、施設が月末の締めに間に合うように回答できます。

ファイル名の先頭に試験番号と施設番号を付けるところまでを人が行います。番号が付いていないファイルは、照合する単価表を決められないので、処理を始める前に止めます。 メールの添付を受付フォルダへ移す作業は、共有の受信箱のルールで自動にしてもかまいません。

S3 への保存を AWS Lambda が受け、StartExpenseAnalysis を呼びます。ClientRequestToken に施設番号とファイルのハッシュから作った値を入れると、同じトークンで呼び直しても同じ JobId が返り、同じ請求書を二度読みません。 JobTag には試験番号と施設番号を入れ、完了の通知（Amazon SNS）からどの施設の請求書かを引けるようにします。通知の状態が SUCCEEDED であることを確かめてから結果を取り、すぐ S3 に保存します。 JobId は7日間しか有効ではありません。

入力データを集める

質を決めるのは、下の3つです。 来院実績が無ければ「来院していない」と言えず、前月までの請求が無ければ二重の請求を見つけられません。言い換えの一覧は、最初は空でかまいません。 担当者が対応付けを直すたびに1行ずつ増え、翌月からその施設の行が迷わず結び付くようになります。

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

結果は GetExpenseAnalysis で取ります。1回の呼び出しで返る件数は既定・最大20で、NextToken が返る限り続けて取ります。 JobStatus が PARTIAL_SUCCESS のときは Warnings に出たページを記録し、その請求書を needs_human にします。

標準の項目に当たらないものは OTHER として返ります。 「Service Period」「Protocol No.」のような治験に固有の見出しは、多くがここに入ります。OTHER の LabelDetection の文字を見て、請求の対象期間と試験番号を拾います。

明細の行は、1行の文字が長いことがあります。 「Visit 4 (Week 12) – Subject 1012-007 – 14-Aug – incl. ECG, PK sampling」のように、来院・被験者・日付・検査が1つの ITEM に詰め込まれます。これを分けるのが、次の段の生成AIの仕事です。

AIへ渡す前に整形する

1. 形式の確認 … 請求書の分析で非同期に扱えるのは JPEG、PNG、PDF です。TIFFで届いたものはPDFに変換します
2. パスワードの確認 … PDFはパスワードで保護されていてはいけません。保護されたものは施設に解除したものを頼みます
3. ページ数とサイズの確認 … 非同期の処理でPDFは500MB・3,000ページが上限です。来院の明細書や領収書の束が添付されているものは、請求書の部分と分けます
4. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です
5. 被験者の氏名が無いかの確認 … 被験者番号ではなく氏名やイニシャル以外の個人を特定できる情報が書かれていれば、処理を止めて担当者へ回します
6. 単価表と来院実績の準備 … その施設の単価表とEDCの最新の出力を、照合用に読み込みます

5番目を省かないでください。 請求書は本来、被験者識別コードで書かれるものです。氏名が書かれた請求書を外部のAIに渡す前に止め、施設に様式を直してもらいます。

AIに処理させる

させるのは、明細の各行を被験者番号・来院・実施日・費目・回数に分け、単価表の費目のコードに対応付け、根拠の文字列を添えることだけです。

費目の対応付けには、施設ごとの言い換えの一覧を渡します。 一覧にある書き方なら、そのコードを使います。一覧に無ければ、単価表の費目の名前と見比べて候補を出し、その行には new_mapping の印を付けて人に確かめてもらいます。

5行目がいちばん起きやすい失敗です。 「Unscheduled visit」のような単価表に無い行を渡すと、AIは近い名前の「Visit」に寄せて結び付けがちです。寄せた瞬間、契約に無い請求が単価の差だけの問題に見えます。 無ければ not_in_budget と返させます。

指示内容を固定する

あなたは製薬企業の臨床開発部で、治験の実施施設から届いた英文の請求書を点検する担当です。
OCRが返した明細の行だけを見て、各行を項目に分けてください。推測で埋めないでください。

【やること】
1. 明細の各行から、被験者番号・来院の名前・実施日・回数を原文のまま切り出す
2. 各行を、下に示す単価表の費目のコードに対応付ける
3. 対応付けの根拠にした原文の文字列を evidence に入れる

【費目の対応付けの決まり】
- まず「この施設の言い換えの一覧」を見る。一覧にある書き方ならそのコードを使う
- 一覧に無ければ、単価表の費目の名前と見比べて候補を1つ選び、mapping を "new_mapping" にする
- 単価表に当てはまる費目が無ければ budget_code を "not_in_budget" にする。
  名前の近い費目に寄せないでください
- 候補が2つ以上で決められなければ "ambiguous" にする

【厳守事項】
- 金額を計算しないでください。単価や合計を検算しないでください。
- 書かれていない回数を 1 としないでください。"not_found" にしてください。
- 1行に複数の日付があるときは、来院の実施日がどれか分からなければ "ambiguous" にしてください。
- 被験者番号の桁や記号を直さないでください。読み取った文字列をそのまま写してください。
- 来院が行われたかどうか、支払ってよいかどうかを書かないでください。
- 被験者の氏名など、被験者番号以外の個人の情報を書き出さないでください。
- confidence は OCR が返した値をそのまま入れてください。

【明細の行】{line_items}
【この施設の単価表（費目のコードと名前）】{budget_items}
【この施設の言い換えの一覧】{alias_list}

「名前の近い費目に寄せない」を、対応付けの決まりの中に書いているのには理由があります。 厳守事項の側だけに書くと、対応付けの手順を優先して寄せてしまいます。手順そのものの中に「無ければ無いと返す」分岐を入れます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema" とスキーマを指定）を使い、形の崩れた応答を照合のプログラムに流さないようにします。

{
  "study_no": "",
  "site_no": "",
  "invoice_no": "",
  "invoice_date": "",
  "currency": "",
  "lines": [
    { "line_no": 1, "subject_id": "", "visit": "", "visit_date": "",
      "budget_code": "", "mapping": "alias | new_mapping | ambiguous | not_in_budget",
      "quantity": "", "billed_amount": "", "confidence": 0, "evidence": "", "page": 1 }
  ]
}

照合のプログラムは、この lines に次の判定を付けます。

理由は、AIの出力とプログラムの判定を別の層に置けることです。 lines はAIが原文から埋め、判定はプログラムが単価表とEDCを相手に付けます。契約が変わっても、直すのは単価表の行だけです。

システムへ連携する

EDCへは書き込みません。 EDCは症例のデータの仕組みで、支払の都合で触ってよいものではありません。読み取りの権限だけを持つ出力ファイルを使います。 会計の仕組みへも書き込まず、承認を通ったものだけが既存の経路で回ります。

人が確認する

担当者が開くのは query と needs_human の請求書だけです。 pass のものは一覧で施設と合計を流し見ます。全件を開く設計にすると、第10章の8分には収まりません。

1. needs_human を先に見る … unreadable の行は原本で読み、new_mapping の行は対応付けが正しいかを決めます。決めた対応は言い換えの一覧に足します
2. no_visit を確かめる … EDCの入力が遅れているだけのことがあります。施設に照会する前に、モニターにEDCの入力状況を聞きます
3. rate_diff と duplicate の根拠を確かめる … 単価表のどの版で計算したか、前月のどの請求と重なったかを見ます
4. 照会文を直して送る … 送るのは担当者です
5. 判定を変えたら記録する … どの行を、どの判定に、なぜ変えたかを残します

2番目を省かないでください。 EDCの入力は来院から数日遅れることがあり、入力待ちの来院を「来院していない」と施設に問い合わせると、施設との関係を損ねます。

例外に対処する

上から5行目が、立ち上げの時期にいちばん多く出ます。 新しい施設が試験に加わったとき、契約の締結から単価表の登録までに間があり、その間に最初の請求書が届きます。単価表の登録を契約の手続きの最後の工程に入れておくと、この行は減ります。

記録を残す

• 請求書の原本と、受け取った日時・試験番号・施設番号
• OCRが返したJSONの全文（GetExpenseAnalysis の全ページ分）
• AIの切り出しと対応付けの結果（lines）
• 照合の結果と、そのとき使った単価表の版とEDCの出力の日付
• 担当者が判定や対応付けを変えた記録
• 照会の内容と施設の回答、支払の承認の日時
• 施設ごとの unreadable と new_mapping の発生率

4つ目で単価表の版を残すのは、契約の変更で単価が後から変わるためです。 当時どの版で照合したかが分からないと、監査や施設との精算のときに説明できません。

ICH E6(R3) は、治験の財務的な事項を治験依頼者と治験責任医師・実施医療機関の間の合意文書に記録するよう求め、その取り決めを必須の記録に挙げています。 請求の照合の記録は、その合意どおりに支払ったことを示す材料になります。保存の期間は、自社の治験の文書の保存の規程に合わせて決めます。