FDA Adverse Event Extraction Prompt for Safety Reports

This prompt is built for pharmacovigilance and drug safety teams who need to convert unstructured narrative reports (CIOMS forms, MedWatch reports, clinical trial SAE narratives, call center intake notes) into structured, auditable records suitable for safety database ingestion and regulatory submission. Use this prompt when you need typed extraction of adverse events with MedDRA coding, suspect product identification with dosage and route, patient demographics, seriousness criteria assessment against FDA definitions, and causality confidence scoring. The ideal user is a safety data analyst, PV operations engineer, or drug safety physician who understands ICH E2B(R3) data elements and needs extraction output that maps directly to safety database fields without manual rework.

This is not a general clinical extraction prompt. It assumes the source text describes a suspected adverse reaction to a medicinal product and requires domain-specific output fields aligned with E2B(R3) and ICH guidelines. The prompt is designed for a single-report extraction workflow, not batch processing or cross-report signal detection. Do not use this prompt for extracting clinical findings from discharge summaries, for general medical coding without the adverse event context, or for processing social media mentions where the reporter-product-reaction relationship is ambiguous. The prompt expects narrative text that contains at minimum an identifiable patient, a suspect product, and a described adverse event—if any of these three elements is missing, the prompt should return null fields with confidence annotations rather than hallucinating values.

Before deploying this prompt, ensure your input pipeline can isolate individual case narratives from batch submissions, redact reporter and patient identifiers according to your privacy requirements, and validate that the source text contains sufficient clinical detail for extraction. The prompt includes explicit instructions for handling missing data, ambiguous seriousness criteria, and multiple suspect products. It also requires the model to flag cases where causality cannot be assessed due to insufficient information. Wire the output through a validation layer that checks MedDRA code validity against your licensed terminology version, verifies date formats against E2B(R3) specifications, and confirms that seriousness criteria selections are mutually consistent. Cases with low confidence scores or failed validation should route to human review rather than automatic database insertion.

This section provides the complete prompt template you will paste into your AI system. It is split into a system prompt, which establishes the model's role as a pharmacovigilance extraction specialist and enforces strict output discipline, and a user prompt, which carries the source text and specific extraction instructions. The system prompt defines the exact JSON schema, MedDRA coding requirements, seriousness criteria, and causality assessment rules. The user prompt is where you inject the narrative report and any run-specific constraints. Every square-bracket placeholder must be replaced with your actual data before execution.

textCopy
SYSTEM:
You are an expert pharmacovigilance data extraction specialist. Your task is to read narrative adverse event reports and extract structured information with high precision. You must adhere strictly to the output schema. Do not infer or hallucinate data not present in the text. If a field is not mentioned, its value must be null. For every extracted field, you must include a confidence score (HIGH, MEDIUM, LOW) and a direct quote from the source text as evidence. Use MedDRA Preferred Terms (PT) for adverse event names. Classify seriousness according to FDA criteria (death, life-threatening, hospitalization, disability, congenital anomaly, other serious). Assess causality using the WHO-UMC scale (Certain, Probable, Possible, Unlikely, Unclassified).

USER:
Extract the adverse event information from the following safety report narrative. Return ONLY a valid JSON object conforming to the schema below. Do not include any text outside the JSON.

[OUTPUT_SCHEMA]
{
  "report_id": "string | null",
  "patient": {
    "age": "number | null",
    "age_unit": "string | null",
    "sex": "string | null",
    "weight_kg": "number | null"
  },
  "suspect_products": [
    {
      "name": "string",
      "active_substance": "string | null",
      "dosage_form": "string | null",
      "dose": "string | null",
      "route": "string | null",
      "indication": "string | null",
      "start_date": "string | null",
      "end_date": "string | null"
    }
  ],
  "adverse_events": [
    {
      "meddra_pt": "string",
      "verbatim": "string",
      "onset_date": "string | null",
      "outcome": "string | null",
      "seriousness_criteria": ["string"],
      "causality_assessment": {
        "score": "string",
        "rationale": "string"
      }
    }
  ],
  "evidence": [
    {
      "field_path": "string",
      "quote": "string",
      "confidence": "string"
    }
  ]
}

[CONSTRAINTS]
- All dates must be in ISO 8601 format (YYYY-MM-DD).
- The "outcome" field must be one of: Recovered/Resolved, Recovering/Resolving, Not Recovered/Not Resolved, Recovered with Sequelae, Fatal, Unknown.
- The "seriousness_criteria" array must only contain values from: Death, Life Threatening, Hospitalization, Disability, Congenital Anomaly, Other Serious.
- The "causality_assessment.score" must be one of: Certain, Probable, Possible, Unlikely, Unclassified.
- If multiple suspect products exist, list them all.
- If the narrative contains no adverse event information, return a valid JSON object with empty arrays and null fields, not an error message.

[SOURCE_TEXT]
[INSERT_NARRATIVE_REPORT_HERE]

How to adapt this template: Replace [INSERT_NARRATIVE_REPORT_HERE] with the full text of the safety report. If your downstream system requires a different schema, modify the [OUTPUT_SCHEMA] block, but keep the field names and types consistent with your ingestion contract. If you are using a model that does not support a separate system prompt, prepend the system instructions to the user message. For high-risk production use, always pair this prompt with a post-extraction validation step that checks schema compliance, MedDRA code validity, and confidence thresholds before the data enters your safety database. If any field has LOW confidence, route the record for human review rather than automated ingestion.

This prompt is not a standalone tool—it is one step in a regulated safety data pipeline. The implementation harness must enforce schema compliance, handle extraction failures gracefully, and maintain a complete audit trail. In a production pharmacovigilance system, every extracted field that flows into a safety database or E2B submission must be traceable back to the source narrative and the model's confidence in that extraction. The harness described here assumes the prompt is called via an API (such as OpenAI, Anthropic, or a self-hosted model) and that the response is processed before any downstream ingestion.

Validation and retry logic is the first line of defense. After the model returns a JSON payload, validate it against the expected schema: check that required fields like [SERIOUSNESS_CRITERIA], [SUSPECT_PRODUCT], and [EVENT_TERM] are present and correctly typed. Use a library like Pydantic or JSON Schema validators to catch missing fields, incorrect enums, or malformed MedDRA codes. If validation fails, construct a retry prompt that includes the original input, the failed output, and the specific validation errors. Limit retries to a maximum of 2 attempts. After the second failure, route the case to a human review queue with the partial extraction and error log attached. Never silently drop a failed extraction in a safety context.

Logging and audit evidence must capture every model interaction. For each extraction request, log: the prompt template version, the full model request payload, the raw model response, the validated output, any retry attempts with their error messages, and the final disposition (auto-accepted, auto-rejected, or escalated). Store these logs in an append-only system with retention aligned to your organization's record-keeping obligations—typically 10+ years for adverse event records. Include a unique extraction_id that ties the log entry to the source document and any downstream ICSR (Individual Case Safety Report) it generates.

Human review integration is required for high-risk or low-confidence outputs. The prompt includes a [CONFIDENCE_SCORE] field for each extracted element. Define a confidence threshold (e.g., below 0.7 for seriousness criteria or suspect product identification) that triggers mandatory human review. Build a review interface that presents the original narrative side-by-side with the extracted fields, highlights low-confidence spans, and allows a safety professional to accept, edit, or reject each field. The reviewer's actions must be logged as part of the audit trail, and corrected fields should be fed back into the system of record—not used to fine-tune the model without appropriate governance.

Model choice and deployment decisions affect reliability and latency. For high-stakes pharmacovigilance, prefer a model with strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) and enable structured output mode if the provider supports it. Run the prompt in a dedicated, private deployment if source narratives contain patient-identifiable information. Do not send PHI to consumer-grade model endpoints. If using a self-hosted open-weight model, validate extraction quality against a golden dataset of 200+ annotated safety narratives before production use, and re-validate after any model or prompt change.

What to avoid: Do not treat this prompt as a replacement for a certified safety database or a qualified human assessor. Do not auto-submit extracted data to regulators (e.g., FDA E2B gateway) without human review. Do not use the model's output to close a case or determine causality without a qualified safety professional's assessment. The prompt is an acceleration tool for structured data entry, not a clinical or regulatory decision-maker. Build the harness to stop and escalate when uncertain, and design your workflow so that every automated extraction can be overridden by a human with domain expertise.