治験の実施医療機関から届く重篤な有害事象の報告から、社内の安全性情報の報告書の下書きを作り、記載の欠けと報告期限の区分を担当者が確かめられるようにする

処理の起点を決める

報告が受領用の場所に保存されたことを起点にします。 保存するのは受付の担当者で、保存と同時に受付日時と報告の識別番号を記録します。 この受付日時が、期限の候補日を計算する起点になります。

起点の日付を AI に決めさせないのが、この構成の前提です。 施行規則第273条は、治験の依頼をした者が事項を「知つたとき」から定められた期間内に報告することを求めています。いつを「知った日」とするかは、自社の手順書で決めることです。 システムはその手順に沿って記録された日時を使い、本文の日付を起点にしません。

届いた順に1件ずつ処理し、まとめて夜に流すことはしません。 7日の期限に当たりうる報告は、1日待つだけで余裕が大きく減ります。報告が届いて数分で下書きが出る状態を目指します。

入力データを集める

質を決めるのは、下の2つです。 治験薬概要書の版が引けないと、予測可能性の材料を出すときに、どの版で照らしたかが残りません。 様式の定義が無いと、経過の要約が担当者ごとの書き方に戻ります。

被験者の氏名や診療録の番号は入力に含めません。 治験では、実施医療機関から依頼者へ届く記録は被験者識別コードで管理されます。報告の原本に氏名が書かれていた場合は、前処理で外します。

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

EDC からは、その被験者の記録だけを取ります。 治験全体の記録を渡すと、ほかの被験者の記録が混ざります。被験者識別コードで絞り、事象の発現日の前後の期間に限ります。 期間は治験ごとに設定します。

前回の確定版は、人が確定したものだけを取ります。 前回の下書きを渡すと、前回 AI が書いた誤りを今回の材料にしてしまいます。下書きと確定版を別の場所に置くのは、このためです。

AIへ渡す前に整形する

1. 形式の確認 … Word・PDF・表計算のファイルから本文を取り出します。画像だけの PDF は取り出せないので、担当者へ戻します
2. 識別情報の除去 … 氏名・診療録の番号・生年月日が書かれていれば外し、被験者識別コードに置き換えます
3. 第一報か追加の報告かの判定 … 受付の記録の区分を使います。本文から推し量りません
4. 被験者の照合 … 報告の被験者識別コードと治験の識別番号で EDC を引きます。一致しなければ処理を止めます
5. 期間の切り出し … EDC の記録を、発現日の前後の設定した期間に絞ります
6. 治験薬概要書の版の固定 … 受付日時の時点で有効な版を引き、版番号を入力に添えます
7. 前回との差分の準備 … 前回の確定版の項目を並べ、今回の報告の項目と比べられる形にします

2番目を軽く見ないでください。 施設によっては、報告の余白や添付の検査結果に氏名が残っていることがあります。外部のサービスに渡すのは、報告に必要な範囲だけです。

4番目で止めるのは、取り違えがいちばん重い失敗だからです。 被験者識別コードの書き間違いで別の被験者の記録を引くと、別人の投与歴で経過の要約が書かれます。 一致しないものは下書きを作らず、受付の担当者に戻します。

AIに処理させる

させるのは、下書きの生成と、欠けている項目の書き出しです。 評価そのものはさせません。

右端の列が、この構成で大事な区別です。 書かれていない項目は空にし、推測した値で埋めません。 投与の最終日が無いときに EDC の最後の来院日で埋める、転帰が無いときに「回復」と書く、どちらも起きやすい失敗です。

副作用の一覧との照合は、材料を並べるところで止めます。 「一覧に記載あり」という結論は書かせず、一覧の該当の文を写させます。 事象名が似ていても、程度や発現の仕方が違えば、予測できるとは言えないことがあるからです。

4行目がいちばん誤解されやすいところです。 報告に「死亡」と書かれていれば7日だと AI に書かせたくなりますが、施行規則第273条では、副作用によるものと疑われ、かつ予測できないものであることが条件に入っています。 予測できるかどうかは評価の結果なので、AI が区分を決めると評価を先取りすることになります。

指示内容を固定する

あなたは製薬会社の安全性情報の担当部署で、治験の重篤な有害事象の
社内の報告書の下書きを作る立場です。
渡す資料だけを使い、書かれていないことを推測で埋めないでください。

【渡す資料】
- 報告の本文（第一報または追加の報告）
- 被験者の記録（投与の記録、併用薬、既往歴、検査値）
- 前回までの社内の報告書の確定版（あれば）
- 治験薬概要書の副作用の一覧（版番号つき）

【作るもの】
1. 社内の様式の各項目の値
2. 経過の要約（時系列。日付のある出来事から順に）
3. 欠けている項目と、その分け方
   - ask_now：いま実施医療機関に問い合わせるべきもの
   - wait_followup：追加の報告で届くのを待つもの
4. 判断の材料
   - 報告に書かれた重篤と判断した理由（原文のまま）
   - 治験責任医師の因果関係の評価（原文のまま）
   - 副作用の一覧の中で、事象と同じ・近い記載の文（原文のまま）と版番号
5. 前回の確定版から新しく分かったこと

【厳守事項】
- 書かれていない項目は null にし、missing_items に入れてください。
  ほかの資料や一般的な経過から補って埋めないでください。
- 投与の最終日、転帰、検査値の単位が無いとき、別の日付や値で
  代用しないでください。
- 報告の本文と被験者の記録で日付や値が食い違うときは、
  どちらかを選ばず、conflicts に両方を書いてください。
- 重篤かどうか、予測できるかどうか、因果関係があるかどうか、
  報告期限が何日かを書かないでください。
- 副作用の一覧に記載があるかの結論を書かないでください。
  近い記載の文を写すだけにしてください。
- 迷う項目は ask_now に入れてください。
- 経過の要約には、資料に無い医学的な解釈を書かないでください。
- 各項目の evidence には、根拠にした文をそのまま写してください。

【社内の様式の定義】{form_definition}
【報告の本文】{report_text}
【被験者の記録】{edc_extract}
【前回の確定版】{previous_final}
【副作用の一覧】{rsi_list}（版番号：{ib_version}）

「別の日付や値で代用しない」を明記しないと、もっともらしく埋めます。 EDC には来院日や採血日が並んでいるので、投与の最終日が無いと、最後の来院日を投与の最終日として書きます。 書かれていないことを示すのは空欄で、埋まった値ではありません。

「食い違うときは両方を書く」も同じ理由です。 報告では発現日が5日、EDC では6日となっていることがあります。どちらかを選ばせると、食い違いがあったという事実が消え、問い合わせの機会がなくなります。

出力形式を固定する

次の形の JSON で受け取ります。 スキーマは構造化出力で指定し、すべての項目を必須にして、値が無いときは null を返させます。

{
  "report_id": "",
  "subject_code": "",
  "report_type": "initial | followup",
  "fields": [
    { "name": "", "value": null, "evidence": "" }
  ],
  "narrative_draft": "",
  "missing_items": [
    { "name": "", "bucket": "ask_now | wait_followup", "reason": "" }
  ],
  "conflicts": [
    { "name": "", "report_value": "", "edc_value": "" }
  ],
  "materials": {
    "seriousness_reason_quote": "",
    "investigator_causality_quote": "",
    "rsi_quotes": [""],
    "ib_version": ""
  },
  "changes_from_previous": [""],
  "inquiry_draft": ""
}

1つ目の理由は、空欄を空欄のまま運べることです。 スキーマで全項目を必須にし、値の型を null との組み合わせにしておくと、「書かれていない」が null として届きます。 自由な文章で受けると、空欄が「不明」「記載なし」「—」と揺れ、プログラムで数えられません。

2つ目は、評価の材料と評価の結果を別の場所に置けることです。 materials は AI が写した原文で、評価の結果は人が別の項目に入れます。期限の区分は、その人の入力からプログラムが決めます。

この表は施行規則第273条第1項の区分を写したもので、外国での使用で生じた症例などは別の行が要ります。 社内の手順書に合わせて表を持ち、AI のプロンプトには入れません。

3つ目は、conflicts と missing_items から問い合わせが組めることです。 inquiry_draft は、ask_now と conflicts だけを使って書かせます。

システムへ連携する

安全性情報の管理システムへは、この構成から書き込みません。 登録は確定版を人が入れます。AI の出力を自動で登録すると、原本と照らす前の値が規制当局への報告の元データになります。

問い合わせの文面も、送るのは人です。 実施医療機関とのやり取りは記録に残る正式な連絡なので、下書きを直して担当者が送ります。

人が確認する

人の確認は2段に分けます。 1段目は安全性情報の担当者、2段目は医学的な評価の担当者です。

1. 原本との照合 … 下書きの各項目を、evidence の文と原本で照らします。evidence が原本に見つからない項目は、値を消します
2. 欠けた項目の振り分けの確認 … wait_followup に入ったもののうち、評価に要るものを ask_now へ移します
3. 食い違いの確認 … conflicts の項目は、両方の値を残したまま問い合わせに入れます
4. 評価 … 医学的な評価の担当者が、重篤性・予測可能性・因果関係を入れます。期限の区分はこの入力から決まります
5. 直した箇所の記録 … どの項目を、どう直したかを残します

1番目を省かないでください。 経過の要約は文章として整っているほど、原本との違いに気づきにくくなります。項目ごとに根拠の文を突き合わせる手順を、確認の画面に組み込みます。

目標は、40件をならして1件30分です。 第一報は項目が少なく短く済み、追加の報告で経過が長くなったものは時間がかかります。

例外に対処する

最後の2行が、この構成でいちばん大事な例外です。 AI が止まっても、期限の計算と通知は受付の記録から独立して動かします。 下書きの仕組みが止まったことで期限を落とすと、元の手作業より悪くなります。

記録を残す

• 報告の原本と、受付日時・報告の識別番号・第一報か追加の報告か
• AI に渡した入力の全文（識別情報を外したもの）と、使った治験薬概要書の版番号
• AI が返した JSON の全文と、呼び出した日時・デプロイ名
• 人が直した項目の記録 … どの項目を、どの値からどの値に変えたか
• 評価の担当者が入れた評価と、そこから決まった期限の区分
• 問い合わせを送った日時と、追加の報告で埋まった項目

治験薬概要書の版番号を残すのは、予測可能性の判断が版に依存するためです。 改訂で副作用の一覧が変わると、同じ事象でも区分が変わりえます。当時どの版で照らしたかが残っていないと、後から確かめられません。

直した記録は、指示の見直しの材料になります。 同じ項目が毎回直されているなら、様式の定義かプロンプトの書き方に理由があります。