Protected Health Information (PHI) Extraction Prompt

This prompt is designed for a single, high-stakes job: identifying and extracting the 18 HIPAA Safe Harbor identifiers from unstructured clinical, operational, or patient-generated text before that text enters any downstream AI workflow, model training pipeline, or analytics system. The ideal user is a healthcare compliance architect, a security engineer on a health-tech platform, or an MLOps engineer responsible for the data sanitization layer. The required context is any free-text string that may contain PHI—this includes clinical notes, patient messages, call transcripts, or email bodies. The prompt is not a general-purpose medical NLP tool; it is a focused classification and extraction gate.

You should use this prompt when the primary goal is to prevent regulated data from leaking into general-purpose models, logs, or vector databases. It is appropriate as a pre-processing step before RAG indexing, before sending data to an external model API, or as part of an on-premises data loss prevention (DLP) pipeline. The prompt is designed to output a structured, machine-readable JSON object that flags each identifier's presence, location, and a confidence score, making it directly integrable into a redaction or quarantine service. It is not a substitute for a full de-identification pipeline that includes date shifting or synthetic data generation; it is the detection and extraction component.

Do not use this prompt as a clinical decision support tool or to infer medical diagnoses. It is not designed to understand medical context, only to recognize the syntactic and semantic patterns of the 18 identifiers. For ambiguous cases—such as a string of numbers that could be a medical record number or a lab value—the prompt is instructed to flag the finding with low confidence and mark it for human review. Relying on this prompt for automated de-identification without a human-in-the-loop review for low-confidence extractions creates a direct risk of non-compliance with the HIPAA Privacy Rule. The next step is to copy the prompt template and adapt the [CONSTRAINTS] and [OUTPUT_SCHEMA] placeholders to match your specific data model and compliance requirements.

The following prompt template is designed to identify the 18 HIPAA Safe Harbor PHI identifiers within a provided text block. It is structured to be dropped directly into an AI pipeline, with square-bracket placeholders for the dynamic inputs your application will provide at runtime. The prompt instructs the model to extract findings into a strict JSON schema, include confidence scores, and flag any ambiguous context for mandatory human review, which is a critical control for healthcare compliance workflows.

textCopy
You are a HIPAA compliance analysis engine. Your task is to extract all instances of the 18 Protected Health Information (PHI) identifiers from the provided text, as defined by the HIPAA Safe Harbor method.

INPUT TEXT:
[INPUT_TEXT]

OUTPUT_SCHEMA:
Return a valid JSON object with the following structure. Do not include any text outside the JSON object.
{
  "findings": [
    {
      "phi_type": "String (one of the 18 HIPAA identifiers)",
      "value": "String (the exact extracted text)",
      "position": {
        "start": Integer,
        "end": Integer
      },
      "confidence": "String (HIGH, MEDIUM, LOW)",
      "requires_review": Boolean
    }
  ],
  "review_required": Boolean,
  "review_reason": "String (explain why human review is needed, or null if not required)"
}

CONSTRAINTS:
1. Extract only identifiers that match the 18 HIPAA Safe Harbor categories: Names; Geographic subdivisions smaller than a State; Dates (except year) directly related to an individual; Phone numbers; Fax numbers; Email addresses; Social Security numbers; Medical record numbers; Health plan beneficiary numbers; Account numbers; Certificate/license numbers; Vehicle identifiers and serial numbers, including license plate numbers; Device identifiers and serial numbers; Web URLs; IP addresses; Biometric identifiers, including finger and voice prints; Full-face photographic images and any comparable images; Any other unique identifying number, characteristic, or code.
2. If a potential identifier is ambiguous (e.g., a name that could be a common word or a non-PHI entity), set confidence to LOW and requires_review to true.
3. Do not extract the year from a date unless it is part of a full date (e.g., month-day-year) directly linked to an individual.
4. If no PHI is found, return an empty findings array and set review_required to false.
5. Set the top-level review_required to true if any finding has requires_review set to true.

To adapt this template for your environment, replace the [INPUT_TEXT] placeholder with the unstructured text your application needs to scan. The OUTPUT_SCHEMA and CONSTRAINTS sections are the core of the prompt's reliability; modify the schema only if your downstream ingestion expects a different JSON shape. The constraints are designed to minimize false positives and enforce the Safe Harbor standard. Before deploying, run this prompt against a golden dataset of de-identified records to calibrate the confidence thresholds and ensure the requires_review flag triggers correctly for ambiguous cases, preventing automated redaction errors.

The PHI extraction prompt is not a standalone chatbot interaction—it must be embedded in a controlled pipeline that enforces data handling rules before and after model invocation. The implementation harness should treat the LLM call as one step in a broader compliance workflow. Before the prompt runs, the system should verify that the input source is authorized for PHI processing, log the processing purpose, and ensure the model endpoint meets your HIPAA Business Associate Agreement (BAA) requirements. After the prompt returns, the harness must validate the output schema, apply confidence thresholds, and route ambiguous extractions to human review before any downstream system consumes the results.

Wire the prompt into your application with a structured request wrapper that includes: [INPUT_TEXT] as the raw clinical note or message, [EXTRACTION_MODE] set to strict (safe harbor) or relaxed (flag potential PHI for review), and [CONFIDENCE_THRESHOLD] as a float between 0.0 and 1.0. The model should return a JSON array of extracted PHI objects, each containing phi_type (mapped to the 18 HIPAA identifiers), value, start_char, end_char, confidence, and needs_review (boolean). Implement a post-processing validator that checks: (1) all phi_type values are valid HIPAA identifier categories, (2) character offsets align with the original input text, (3) needs_review is true when confidence falls below your threshold, and (4) no PHI object is missing required fields. Failed validation should trigger a retry with the same prompt and a repair instruction appended, not silent acceptance.

Human review integration is mandatory for any extraction where needs_review is true or where the validator rejects the output after maximum retries. Route these cases to a review queue with the original text, the model's extraction attempt, and the specific validation failure. Log every extraction request and result—including the prompt version, model ID, timestamp, reviewer decision, and final disposition—to an append-only audit store. This audit trail is essential for demonstrating HIPAA compliance during an OCR investigation. Do not send PHI-containing text to non-BAA-covered model endpoints, and never cache PHI inputs or outputs in shared prompt caches unless the cache is explicitly scoped to your compliant environment. For high-throughput pipelines, consider batching non-PHI text through a pre-filter before invoking the extraction prompt to reduce cost and latency on clean inputs.