HIPAA Compliance Document Field Extraction Prompt Template

This prompt is designed for healthcare compliance engineering teams who need to extract structured, auditable records from HIPAA-related documentation. The core job-to-be-done is converting unstructured or semi-structured documents—such as Business Associate Agreements (BAAs), breach notification policies, and internal safeguard inventories—into a machine-readable schema. The ideal user is a developer or compliance engineer building an automated document ingestion pipeline where manual review is too slow or inconsistent. The required context includes the full text of the source document and a clear understanding of the target output schema, which must capture PHI safeguards, breach notification details, and BA agreement terms with regulatory citations.

Use this prompt when you need field-level extraction with explicit grounding to the HIPAA Privacy, Security, and Breach Notification Rules. It is appropriate for documents where the presence or absence of specific obligations must be recorded, such as identifying whether a BAA specifies a timeframe for breach notification or whether a policy lists all required administrative safeguards. The prompt is built to handle missing information explicitly, flagging absent fields and redacted content rather than hallucinating values. This makes it suitable for high-stakes workflows where a silent null is more dangerous than a flagged gap. However, do not use this prompt for general medical record summarization, clinical decision support, or any workflow where the model's output directly dictates patient care or legal liability without human review.

Before implementing this prompt in production, you must establish a human-in-the-loop review process for all extracted records, especially those with low confidence scores or flagged missing obligations. The prompt is a component in a larger system, not a standalone compliance solution. Pair it with a validation layer that checks for required safeguard categories, missing BA obligation fields, and regulatory citation consistency. If your document set includes heavily degraded scans or handwritten notes, pre-process them with a dedicated OCR pipeline and route low-confidence OCR outputs for manual review before they reach this extraction prompt.

This template is designed to extract PHI safeguards, breach notification details, and Business Associate agreement terms from HIPAA compliance documentation. It produces structured JSON records with regulatory citation grounding and explicit redaction detection. The prompt enforces strict schema compliance, requires source citations for every extracted field, and flags missing or illegible content rather than hallucinating values. Use this template as the core extraction instruction in a document processing pipeline where accuracy and auditability are non-negotiable.

textCopy
You are a HIPAA compliance document extraction system. Your task is to extract structured fields from the provided healthcare compliance document with precise regulatory citation grounding.

## INPUT
Document text: [DOCUMENT_TEXT]
Document type: [DOCUMENT_TYPE]

## OUTPUT SCHEMA
Return a valid JSON object with the following structure. Every extracted field must include a `source_citation` referencing the exact section, paragraph, or page where the information was found. Use `null` for fields where information is absent, redacted, or illegible, and set `confidence` to 0.0 in those cases.

```json
{
  "document_metadata": {
    "document_type": "string",
    "effective_date": "string | null",
    "covered_entity_name": "string | null",
    "business_associate_name": "string | null",
    "agreement_reference_id": "string | null"
  },
  "phi_safeguards": [
    {
      "safeguard_category": "administrative | physical | technical",
      "safeguard_description": "string",
      "implementation_status": "implemented | partially_implemented | planned | not_addressed",
      "source_citation": "string",
      "confidence": 0.0
    }
  ],
  "breach_notification": {
    "breach_discovered": true,
    "discovery_date": "string | null",
    "affected_individuals_count": "number | null",
    "phi_types_exposed": ["string"],
    "notification_timeline_days": "number | null",
    "notification_method": "string | null",
    "law_enforcement_delay": true,
    "source_citation": "string",
    "confidence": 0.0
  },
  "business_associate_obligations": [
    {
      "obligation_type": "string",
      "obligation_description": "string",
      "permitted_uses": ["string"],
      "prohibited_uses": ["string"],
      "subcontractor_provisions": "string | null",
      "termination_conditions": "string | null",
      "source_citation": "string",
      "confidence": 0.0
    }
  ],
  "missing_fields": [
    {
      "field_path": "string",
      "absence_reason": "not_present | redacted | illegible | below_confidence_threshold",
      "location_searched": "string"
    }
  ],
  "redaction_detected": true,
  "redaction_locations": ["string"],
  "extraction_notes": ["string"]
}

CONSTRAINTS

1. Every extracted field must include a source_citation with section, paragraph, or page reference.
2. Set confidence between 0.0 and 1.0 for each extracted entity. Use 0.0 when information is absent or unreadable.
3. Never fabricate values. If a required field is missing, add it to missing_fields with the reason.
4. Flag all redacted or blacked-out regions in redaction_locations.
5. For phi_safeguards, classify every safeguard into exactly one category: administrative, physical, or technical.
6. For business_associate_obligations, extract all permitted uses, prohibited uses, subcontractor provisions, and termination conditions explicitly stated in the document.
7. If the document type is a Business Associate Agreement, prioritize business_associate_obligations extraction. If it is a breach notification letter, prioritize breach_notification.
8. Include an extraction_notes array with any observations about document quality, ambiguous language, or extraction difficulties.

EXAMPLES

[EXAMPLES]

RISK LEVEL

HIGH — This extraction involves PHI and regulatory compliance data. Human review is required before using extracted fields in any compliance determination or legal filing.

Adapt this template by replacing [DOCUMENT_TEXT] with the full text of the HIPAA document after OCR or native text extraction. Set [DOCUMENT_TYPE] to one of business_associate_agreement, breach_notification, privacy_policy, security_risk_assessment, or incident_response_plan to trigger the appropriate extraction priorities. The [EXAMPLES] placeholder should be populated with 2–3 few-shot examples showing correct extraction patterns for your specific document types, including examples of missing field handling and redaction detection. For production use, add a post-extraction validation step that checks for required safeguard categories (administrative, physical, technical) and flags any Business Associate Agreement that lacks explicit permitted-use or termination-condition fields.

Before deploying this prompt into a production pipeline, run it against a golden dataset of 20–30 annotated HIPAA documents and measure field-level precision, recall, and citation accuracy. Pay special attention to false negatives in missing_fields detection and false positives in redaction_detected. If the model consistently misses Business Associate obligations or misclassifies safeguard categories, add targeted few-shot examples rather than lengthening the constraint list. Always route extractions with confidence below 0.7 or with critical missing fields to a human review queue before they enter any downstream compliance system.

This prompt is designed to be called from a document processing pipeline, not a free-text chat interface. The typical integration pattern is: (1) a document ingestion step that splits the source PDF into manageable sections, (2) a model call using this prompt template with the section text and extraction schema injected, (3) a validation layer that checks the output against required HIPAA safeguard categories and field completeness rules, and (4) a routing decision that either accepts the extraction, queues it for human review, or triggers a retry with additional context. Because HIPAA compliance workflows carry regulatory risk, the harness must treat the model output as a draft that requires verification before it enters any system of record.

Wire the prompt into your application by constructing the [INPUT] variable from pre-processed document sections. For a Business Associate Agreement, extract the relevant clauses before calling the prompt—do not send the entire 40-page document in one request. The [OUTPUT_SCHEMA] placeholder should contain a JSON Schema definition that includes required fields for PHI safeguards (administrative, physical, technical), breach notification timelines, BA obligation categories, and detected redactions. Implement a post-extraction validator that checks: (a) all three safeguard categories are present or explicitly marked as null with a reason, (b) any detected BA obligations include a citation to the source paragraph, and (c) redacted regions are flagged with a confidence score. If the validator fails, route the section to a retry prompt that includes the validation errors as feedback. After two failed retries, escalate to a human review queue with the original document section, the failed extractions, and the validator output attached.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities—Claude 3.5 Sonnet or GPT-4o are appropriate for production use. Avoid smaller models that may silently drop required fields or hallucinate citations. Set temperature to 0 or near-zero to maximize extraction consistency. Enable structured output mode (JSON mode or tool calling with a defined schema) rather than parsing free-text responses. Log every extraction attempt with the prompt version, model identifier, input hash, output, validator results, and routing decision. This audit trail is essential for demonstrating due diligence if an extraction error is later discovered. For documents containing actual PHI, ensure your model provider has a BAA in place and that PHI is not logged in plaintext in your observability pipeline.

The redaction detection logic deserves special attention in the harness. When the prompt flags a region as redacted, your application should not attempt to extract content from that region. Instead, record the redaction location, the surrounding context, and a redaction_confidence score. If the confidence is below your threshold (we recommend 0.85 for redaction detection), route that section for human verification. Similarly, when the prompt returns null for a required field with a reason like 'field not present in source,' your validator should distinguish between 'legitimately absent' and 'model failed to find it.' A common failure mode is the model returning empty objects {} instead of explicit nulls with reasons—your harness should treat empty required objects as validation failures and trigger a retry.

Before deploying to production, build a regression test suite using de-identified HIPAA documents with known ground-truth extractions. Run the prompt against at least 50 document sections covering BA agreements, notices of privacy practices, and breach notification policies. Measure precision and recall on required field extraction, citation accuracy, and redaction detection. Set acceptance thresholds before shipping: we recommend ≥95% recall on required safeguard fields and ≥90% precision on citation grounding. If your use case involves real PHI, add a human-in-the-loop approval step for all extractions until your eval metrics demonstrate sufficient reliability. Never auto-commit extracted PHI safeguard data to a compliance system without either passing validation thresholds or human approval.