Healthcare PHI De-identification Prompt Template

This prompt is a repair and validation tool, not a content generator. It is designed for healthcare compliance teams and security engineers who already have a model output—such as a clinical note, a patient summary, or a care coordination message—and need to strip it of protected health information (PHI) before it can be logged, stored, or shared. The prompt instructs the model to scan the provided text, identify PHI across all 18 HIPAA Safe Harbor identifier categories, and redact each instance with a consistent, non-reversible placeholder token. The output is a structured JSON payload containing both the de-identified text and a detailed audit log of every redaction decision, making the process explainable to auditors and downstream reviewers.

Use this prompt when the model output is already generated and you need a programmatic, auditable de-identification step. It is most effective when paired with a deterministic regex post-processor that handles high-precision identifiers like Medical Record Numbers (MRNs) and standardized dates before the text reaches the model. The prompt itself excels at contextual disambiguation—for example, distinguishing a patient's name from a clinician's name or a provider ID from a generic number. Do not use this prompt as your only line of defense for real-time streaming outputs, for de-identifying structured JSON payloads field-by-field, or for generating new clinical content. It is a repair step for free-text outputs that may contain PHI.

The prompt requires human review for any redaction flagged as low confidence. It is not a substitute for a formal de-identification pipeline, but it is a practical, auditable safety net when a model output must be sanitized quickly and the cost of a PHI leak is high. Before implementing, ensure you have a clear definition of your environment's PHI categories, a test set of known PHI examples to measure recall, and a process for logging and reviewing the audit trail this prompt produces.

This prompt template is designed to be placed in your system instructions or sent as a user message for post-generation PHI scrubbing. It instructs the model to act as a de-identification engine, applying the HIPAA Safe Harbor method to locate and redact 18 specific identifiers from unstructured text. The prompt is structured to produce a consistent JSON output that includes the redacted text, a change log, and a re-identification risk assessment, making it auditable and integrable into a compliance pipeline.

markdownCopy
You are a de-identification engine operating under the HIPAA Privacy Rule. Your task is to receive unstructured text and apply the Safe Harbor method to redact all 18 Protected Health Information (PHI) identifiers.

## INPUT
[INPUT]

## CONSTRAINTS
- Redact the following 18 identifiers if present: names; geographic subdivisions smaller than a state; all elements of dates (except year) related to an individual; telephone 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; device identifiers and serial numbers; web URLs; IP addresses; biometric identifiers; full-face photographs and comparable images; any other unique identifying number, characteristic, or code.
- Replace redacted text with a placeholder describing the PHI category in square brackets, e.g., [PATIENT_NAME], [MRN], [DATE].
- Do not alter any text that is not PHI.
- Preserve the original structure, line breaks, and non-PHI punctuation.
- If no PHI is found, return the original text unchanged.

## OUTPUT_SCHEMA
Return a single valid JSON object with the following keys:
- "redacted_text": The fully redacted string.
- "phi_detected": A boolean indicating if any PHI was found.
- "redaction_log": An array of objects, each describing a redaction with keys "original_value", "redacted_placeholder", and "phi_category".
- "reidentification_risk": A string assessment: "LOW", "MEDIUM", or "HIGH", based on the remaining context and the specificity of redacted values.
- "risk_note": A brief string explaining the re-identification risk assessment.

## EXAMPLES
Input: "Patient John Doe, MRN 12345, was admitted on 01/15/2023."
Output: {
  "redacted_text": "Patient [PATIENT_NAME], MRN [MRN], was admitted on [DATE].",
  "phi_detected": true,
  "redaction_log": [
    {"original_value": "John Doe", "redacted_placeholder": "[PATIENT_NAME]", "phi_category": "Name"},
    {"original_value": "12345", "redacted_placeholder": "[MRN]", "phi_category": "Medical Record Number"},
    {"original_value": "01/15/2023", "redacted_placeholder": "[DATE]", "phi_category": "Date"}
  ],
  "reidentification_risk": "LOW",
  "risk_note": "All direct identifiers have been redacted. Remaining context is generic."
}

## RISK_LEVEL
[HIGH]

To adapt this template, replace the [INPUT] placeholder with the text you need to scrub. The [RISK_LEVEL] placeholder should be set to "HIGH" for production healthcare workflows, which signals the model to apply maximum scrutiny. For lower-stakes testing, you can set it to "MEDIUM" or "LOW" to observe how the model's strictness changes. The output schema is designed for direct ingestion by a downstream validator; you should implement a post-processing check that ensures the redacted_text does not contain any of the original_value strings from the redaction_log, as this is a common failure mode where the model identifies PHI but fails to replace it in the text. Always log the full JSON output for audit trails, and route any output with a "HIGH" re-identification risk for human review before it leaves the system.

This prompt is not a standalone safety net. It must be embedded inside a deterministic application harness that controls input, validates output, logs decisions, and enforces human review for any ambiguous or high-risk case. The harness should treat the model as one component in a defense-in-depth strategy: upstream filtering, the de-identification prompt itself, downstream schema validation, and a final audit log are all required before any output reaches a database, log, or user-facing surface.

Input preparation starts with a strict allowlist. Before the prompt receives [INPUT_TEXT], the harness should strip any known PHI using deterministic regex patterns for MRNs, SSNs, and standard date formats. The prompt then handles the ambiguous remainder. Model choice matters: prefer a model with strong instruction-following and low refusal rates on security tasks. Set temperature=0 and disable sampling to maximize output determinism. Output validation must parse the JSON response and verify that every field in the original text is accounted for in the redactions array. If the model returns malformed JSON, retry once with a repair prompt; if it fails again, escalate the entire record to human review. Logging must capture the original text hash, the redacted output, the model's confidence scores, and the reviewer decision for every record—never log the raw PHI itself.

Human review integration is mandatory for any record where the model's re_identification_risk score exceeds low or where the redactions array contains confidence below 0.95. Build a review queue that presents the original text side-by-side with the proposed redactions, highlighting low-confidence decisions. Reviewers should be able to approve, modify, or reject each redaction. The harness must block downstream consumption until review is complete. Retry logic should be limited: one retry for format errors, zero retries for content decisions. If the model hallucinates a redaction that does not exist in the source text, the harness must flag it as a false positive and revert it. Testing requires a golden dataset of 200+ clinical text samples with known PHI positions, including edge cases like hyphenated names, abbreviated dates, and provider IDs that resemble MRNs. Run this prompt against the dataset weekly and track precision, recall, and false positive rate. Any regression in recall below 0.98 must block deployment.

What to avoid: Do not send raw PHI to external model APIs without a BAA in place. Do not rely solely on this prompt for HIPAA compliance—it is a technical control, not a legal one. Do not skip the audit log. Do not assume the model will catch every PHI instance; the harness must combine deterministic rules, this prompt, and human review into a single pipeline. If your use case involves real-time streaming outputs, buffer chunks until you have complete sentences before running de-identification, and implement a circuit breaker that blocks output if the pipeline latency exceeds 500ms.