FDA Drug Approval Document Extraction Prompt Template

This prompt is designed for regulatory affairs and compliance engineering teams who need to extract structured data from FDA drug approval documents, including NDAs, BLAs, ANDAs, and supplemental submissions. It targets indication statements, clinical trial endpoints, adverse event tables, and labeling sections. Use this prompt when you need machine-readable outputs with precise section-level citations and per-field confidence scores that can feed downstream regulatory intelligence systems, submission tracking dashboards, or compliance review workflows.

This prompt assumes you have already extracted clean text from the source PDF. If you are working with scanned documents, apply OCR and text cleanup before using this prompt. The prompt expects a complete text block as input and will not compensate for missing pages, garbled characters, or misordered text from layout extraction failures. For best results, ensure your document preprocessing pipeline preserves section hierarchy, table structure, and footnote associations before passing text to this prompt.

Do not use this prompt for real-time clinical decision support or diagnostic workflows. It is not designed for medical device submissions, veterinary drug approvals, or international regulatory filings that follow non-FDA structures such as EMA or PMDA formats. The prompt also should not be used as a substitute for regulatory judgment—outputs must be reviewed by qualified regulatory professionals before inclusion in submission packages or compliance determinations.

This prompt template is designed to extract structured data from FDA drug approval documents, including New Drug Applications (NDA), Biologics License Applications (BLA), and supplemental approval packages. It targets regulatory affairs teams who need to pull indication statements, clinical trial results, adverse event data, and labeling information into schema-conforming JSON with precise citations back to the source document sections. The template uses square-bracket placeholders that you replace with your specific document content, output schema, and operational constraints before wiring it into your extraction pipeline.

textCopy
You are an FDA regulatory document extraction assistant. Your task is to extract structured data from the provided FDA drug approval document according to the output schema below.

## DOCUMENT CONTENT
[DOCUMENT_TEXT]

## OUTPUT SCHEMA
Extract the following fields as valid JSON matching this schema exactly:
[OUTPUT_SCHEMA]

## EXTRACTION RULES
1. For every extracted value, include a "citation" field with the section heading, page number, or paragraph reference where the information was found.
2. For every extracted field, include a "confidence" score between 0.0 and 1.0 indicating how certain you are about the extraction.
3. If a required field is not present in the document, set its value to null and include a "missing_reason" field explaining why it could not be found (e.g., "not mentioned in document", "redacted", "illegible").
4. For numeric values, preserve the original units and include a "normalized_value" field with standard units where applicable.
5. For adverse event data, include MedDRA preferred terms where identifiable and flag any events that appear in tables but not in narrative sections.
6. For clinical trial results, distinguish between primary endpoints, secondary endpoints, and exploratory endpoints.
7. Do not fabricate or infer data. If information is ambiguous, set confidence below 0.5 and include an "ambiguity_note".

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## OUTPUT FORMAT
Return ONLY valid JSON. No markdown fences, no commentary, no additional text.

To adapt this template, replace [DOCUMENT_TEXT] with the full text of the FDA submission document you are processing. Define [OUTPUT_SCHEMA] as a complete JSON Schema object specifying the fields you need—typical fields include drug_name, active_ingredient, indication, approval_date, clinical_trial_results (array of trial objects with endpoints, sample sizes, p-values), adverse_events (array with event terms, frequencies, severity grades), and labeling_sections (array of section texts with headings). Use [CONSTRAINTS] to add domain-specific rules such as required field lists, enum values for regulatory categories, or numeric range validations. Use [EXAMPLES] to provide few-shot demonstrations of correct extractions, especially for complex nested structures like clinical trial result arrays. After adapting, run the prompt through your validation harness to verify schema compliance, citation accuracy, and confidence score calibration before deploying to production.

This prompt is designed to be a single step in a larger document processing pipeline. It expects pre-processed text from an FDA submission document (PDF parsed, OCR cleaned, and chunked by section) as its primary input. The application layer is responsible for document ingestion, chunking strategy, and post-extraction validation. Do not send raw binary PDFs to this prompt; the model's performance degrades significantly with unparsed or poorly segmented text. The ideal harness feeds the prompt one major section at a time (e.g., 'Clinical Studies', 'Adverse Reactions') to stay within context windows and improve citation accuracy.

Validation and Retries: The output schema includes a confidence_score for each extracted field. Implement a post-processing validator that checks: (1) JSON schema conformity, (2) required fields are not null unless explicitly flagged as missing: true, (3) source_citation fields contain valid section references present in the input, and (4) numeric fields like p_value or sample_size parse correctly. If validation fails, use a retry recovery prompt that feeds the original prompt, the failed output, and the specific validator error messages back to the model. Limit retries to 2 attempts before routing to a human review queue. For high-risk fields like adverse_events and boxed_warnings, set a confidence threshold (e.g., < 0.9) that automatically triggers human review regardless of schema validity.

Model Choice and Tool Use: This extraction task benefits from models with strong instruction-following and large context windows. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable starting points. The prompt is designed for a single LLM call without external tools, but you can extend the harness with a RAG retrieval step if the input document exceeds the model's context window. In that case, use the [CONTEXT] placeholder to inject retrieved chunks and instruct the model to cite the specific chunk IDs. For production, log every extraction attempt—including the prompt version, model, input hash, raw output, validation results, and final accepted/rejected status—to enable prompt observability and regression testing.

Next Steps: Start by running this prompt against a golden dataset of 20 FDA documents with known, human-verified extractions. Measure field-level accuracy, citation precision, and the false-positive rate for missing field detection. Use these metrics to calibrate confidence thresholds and decide whether the prompt alone is sufficient or if fine-tuning on FDA-specific language is warranted. Avoid deploying this prompt directly to a user-facing application without the validation harness and human review escape hatch described above.