Healthcare PHI Redaction Prompt for Clinical Notes

This prompt is designed for healthcare AI developers and privacy engineers who need a reliable, pre-inference step to de-identify unstructured clinical text. The primary job-to-be-done is to strip the 18 HIPAA Safe Harbor identifiers from free-text clinical documentation—such as progress notes, discharge summaries, or radiology reports—before that text is sent to an external model endpoint for summarization, analysis, or research. The output is a two-part payload: a redacted version of the clinical note and a structured audit map that records what was redacted, its type, and its position. This allows downstream tasks to proceed without exposing protected health information (PHI) to a third-party API, while the audit map provides traceability for compliance and debugging.

The ideal user is a developer or engineer integrating this prompt into a data pipeline, not a clinician or compliance officer performing a manual review. The required context is a raw, unstructured clinical note as a string. You should use this prompt when you have a clear, bounded task that requires a model to process clinical text, and you need a programmatic, repeatable redaction step that fits into an automated workflow. It is particularly useful in research pipelines, clinical note summarization services, and internal tooling where data must leave a secure environment. However, this prompt is not a substitute for a formal compliance review or a complete data governance framework. It is a single control in a defense-in-depth strategy. Do not use it as the sole mechanism for de-identification in a regulated production system, and never use its output for direct clinical decision-making or billing without mandatory human review of the redacted text.

Before implementing, understand the key constraints. The prompt assumes the input is English-language clinical documentation; performance on other languages or highly structured data like FHIR bundles is not guaranteed. It operates on the 18 Safe Harbor identifiers, not on a broader definition of PHI or on re-identification risk analysis. The redaction is a text replacement operation, not a cryptographic transformation. Your next step should be to integrate the prompt into a pre-processing layer, wire its output to a human review queue for high-risk use cases, and establish a regression testing suite using a golden dataset of de-identified notes to measure recall and precision over time. Avoid deploying this as a 'set and forget' component; its performance must be continuously monitored against your specific data distribution.

The following prompt template is designed to be pasted directly into your prompt assembly layer. It instructs the model to identify and redact all 18 HIPAA Safe Harbor identifiers from unstructured clinical text, replacing them with safe placeholder tokens. The template uses square-bracket placeholders that your application must substitute at runtime. Do not send this template to the model with the brackets still present; unresolved placeholders will cause the model to hallucinate or fail silently.

textCopy
You are a HIPAA compliance redaction engine. Your task is to identify and redact all 18 HIPAA Safe Harbor identifiers from the clinical note provided below.

Replace each identified identifier with a typed placeholder token using the format [REDACTED-<TYPE>]. Use the following type labels exactly:
- NAME
- GEOGRAPHIC_SUBDIVISION
- DATE
- PHONE
- FAX
- EMAIL
- SSN
- MRN
- HEALTH_PLAN_BENEFICIARY
- ACCOUNT_NUMBER
- CERTIFICATE_LICENSE
- VEHICLE_ID
- DEVICE_ID
- URL
- IP_ADDRESS
- BIOMETRIC
- PHOTO
- OTHER_UNIQUE_IDENTIFIER

Do not modify any text that is not a HIPAA identifier. Preserve all clinical terminology, measurements, observations, and medical codes exactly as written. Return only the redacted text. Do not add explanations, summaries, or commentary.

[CONSTRAINTS]

Clinical Note:
[INPUT]

Redacted Note:

Adaptation guidance: The [INPUT] placeholder must receive the raw clinical note text. The [CONSTRAINTS] placeholder is optional and can be used to inject additional organization-specific redaction rules, such as masking internal patient ID formats or preserving specific date ranges for research. If your use case requires partial redaction (e.g., keeping the year but removing the month and day), modify the type labels and instructions accordingly. Always test the adapted prompt against your golden evaluation set before deployment. For high-risk clinical workflows, the output of this prompt must be reviewed by a human or a secondary automated validator before it is used for summarization, research, or any downstream task.

Integrating this prompt into a production application requires treating it as a high-risk data processing step, not a simple API call. The core workflow involves receiving unstructured clinical text, assembling the prompt with the text inserted into the [CLINICAL_NOTE] placeholder, calling a model with a low temperature setting (e.g., 0.0–0.1) for deterministic redaction, and then parsing the structured JSON output. The application must never log the raw clinical note or the unredacted prompt to any observability system. Instead, log only the redacted output, a unique trace ID, and the validation result. This separation ensures that PHI does not leak into debugging tools, error tracking, or audit logs.

The implementation must include a strict post-generation validation layer before the redacted text is used downstream. Parse the model's JSON output and verify that every redacted_text field contains no matches against a regex library of the 18 HIPAA Safe Harbor identifiers (e.g., dates, phone numbers, SSNs, MRNs). Additionally, confirm that the redaction_map array correctly maps each original_phi to a placeholder_id and that the placeholder appears in the redacted_text. If validation fails, the system should not fall back to the raw note. Instead, implement a retry loop with a maximum of two additional attempts, each time appending the specific validation errors to the [CONSTRAINTS] section of the prompt. If all retries are exhausted, the note must be routed to a human review queue and flagged as a redaction failure. This hard-failure design prevents any unredacted PHI from reaching a downstream summarization or research model.

For model choice, prefer a model with strong instruction-following and JSON mode capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid small or general-purpose models that may hallucinate PHI or produce malformed JSON under strict schema constraints. The prompt is designed for a single-turn, stateless call; do not include prior conversation history. If processing high volumes of clinical notes, batch the requests and use prompt caching for the static instruction prefix to reduce latency and cost. The [OUTPUT_SCHEMA] placeholder should be replaced with a JSON Schema object, not a natural language description, and the model should be configured to use its native structured output or JSON mode feature. Finally, ensure that any downstream system consuming the redacted text is identified in your data flow documentation, and that the entire pipeline is covered by a Business Associate Agreement (BAA) if the underlying model API processes PHI before redaction is applied.