Healthcare PHI Detection and Refusal Prompt

This prompt is a pre-processing gate for health-tech engineers who must prevent a Large Language Model (LLM) from processing, echoing, or reasoning about Protected Health Information (PHI). Its sole job is to inspect free-text user input—such as clinical notes, patient messages, or medical documents—and return a deterministic, structured detection result. If PHI is identified against the 18 HIPAA Safe Harbor identifiers, the prompt instructs the model to refuse any further engagement with the content. This is not a redaction or de-identification prompt; it is a binary detection-and-refusal boundary that stops the model from touching PHI at all, preventing downstream leakage in summarization, extraction, or agentic workflows.

Use this prompt when your AI pipeline handles unvetted text that may contain PHI and you need a hard refusal layer before any other processing occurs. The ideal user is an engineer integrating an LLM into a healthcare application, a compliance architect designing AI safety guardrails, or a security engineer building a data loss prevention (DLP) control for model inputs. You must provide the raw user input as the [INPUT] variable. The prompt works best as a synchronous check before the input reaches any other prompt, tool, or retrieval step. It is designed for single-turn classification and refusal, not for multi-turn conversations where a user might try to bypass the gate through follow-up rephrasing.

Do not use this prompt as a standalone HIPAA compliance solution. It is a probabilistic defense, not a legal guarantee. It will not catch PHI embedded in images, scanned PDFs, or audio files without a separate OCR or transcription step. It is also not a substitute for data masking or tokenization in your application layer. If your workflow requires using PHI for a legitimate treatment, payment, or operations purpose, this prompt is the wrong tool—you need a secure data handling pipeline with access controls, audit logs, and a Business Associate Agreement (BAA) in place. The next step after reading this section is to review the prompt template, understand its required inputs, and prepare a test suite of PHI-positive and PHI-negative examples to measure its detection accuracy before deployment.

This prompt template is designed to sit at the system level of a health-tech AI application. It instructs the model to inspect every user input and any attached context for protected health information (PHI) as defined by the HIPAA Safe Harbor method. Instead of echoing, summarizing, or reasoning over PHI, the model must refuse to process the request and return a structured JSON object that your application harness can act on—logging the incident, stripping the data, or escalating for human review. The template uses square-bracket placeholders so you can adapt the risk tolerance, the list of identifiers to scan for, and the exact refusal message without rewriting the core logic.

textCopy
You are a privacy-preserving AI assistant operating in a HIPAA-regulated environment. Your primary directive is to prevent the processing, storage, or exposure of Protected Health Information (PHI).

## INPUT
You will receive user input and, optionally, retrieved context. Inspect all text for the 18 HIPAA Safe Harbor identifiers listed below.

[USER_INPUT]
[RETRIEVED_CONTEXT]

## IDENTIFIERS TO DETECT
[PHI_IDENTIFIER_LIST]

## RULES
1. If you detect any direct identifier (names, SSNs, medical record numbers, email addresses, etc.) OR any combination of quasi-identifiers (dates, ZIP codes, ages over 89) that could reasonably re-identify an individual, you MUST refuse to process the request.
2. Do not echo, summarize, translate, or reason about any text that contains PHI.
3. Do not attempt to de-identify the data yourself. De-identification is a separate, audited process.
4. If no PHI is detected, you may proceed with the user's request, but you must still exclude any incidental identifiers from your response.

## OUTPUT SCHEMA
Respond ONLY with a valid JSON object. Do not include any text outside the JSON.
{
  "phi_detected": boolean,
  "identifiers_found": ["string"],
  "refusal_message": "string",
  "risk_level": "[RISK_LEVEL]"
}

## REFUSAL MESSAGE
If phi_detected is true, set refusal_message to: "[REFUSAL_MESSAGE]"

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## CONSTRAINTS
- Do not include any PHI in the identifiers_found array. Use category labels only (e.g., "NAME", "EMAIL", "DATE_OF_BIRTH").
- If you are uncertain whether a data element qualifies as PHI, err on the side of refusal and set risk_level to "HIGH".
- Never output the original user input or context if PHI is detected.

To adapt this template, start by populating [PHI_IDENTIFIER_LIST] with the specific Safe Harbor identifiers relevant to your data. A standard list includes 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 plates, device identifiers and serial numbers, web URLs, IP addresses, biometric identifiers (including finger and voice prints), full-face photographic images and any comparable images, and any other unique identifying number, characteristic, or code. Next, define [RISK_LEVEL] as a static value like "HIGH" or wire it to a dynamic variable from your application's risk scoring system. The [REFUSAL_MESSAGE] should be a user-facing string that explains the refusal without revealing what was detected—for example, "I can't process this request because it appears to contain personal health information. This incident has been logged." Finally, provide 2–3 [FEW_SHOT_EXAMPLES] that show both a clean input (phi_detected: false) and a PHI-positive input with the correct refusal JSON. This template is designed to be the system prompt; do not let user or developer messages override these rules. In your implementation harness, validate that the model's output is parseable JSON and matches the schema before any downstream action.

This prompt is designed to be a pre-processing gate in a health-tech pipeline. It should sit between the user's input and any downstream model that might process, store, or summarize clinical text. The primary job of the harness is to call this prompt, parse its structured refusal or detection result, and enforce a hard block before PHI reaches another model, a vector database, or an observability log. Do not treat this as an advisory check—the application must halt processing on a positive detection unless an authorized human reviewer explicitly overrides it.

The recommended implementation pattern is a synchronous validation layer with a strict schema contract. Wrap the prompt call in a function that: (1) sends the user input with the [INPUT] placeholder populated; (2) parses the JSON response against a schema that requires phi_detected (boolean), detected_identifiers (array of objects with type, value, and safe_harbor_match fields), and action (enum of BLOCK, REDACT, or PASS); (3) validates that every detected identifier maps to one of the 18 HIPAA Safe Harbor categories; and (4) logs the detection result to a dedicated audit store that is excluded from model training and general observability pipelines. If the model returns malformed JSON, retry once with a repair prompt that includes the raw output and the expected schema. If the retry also fails, escalate to a human review queue and block the request.

For model choice, prefer a model with strong instruction-following and structured output support, such as gpt-4o or claude-3.5-sonnet, with response_format set to json_object and a JSON schema provided in the [OUTPUT_SCHEMA] placeholder. Set temperature to 0 to minimize variance in detection boundaries. If you are running in a local-first or air-gapped deployment, test open-weight models like llama-3.1-70b against your PHI test suite before committing—smaller models often miss partial identifiers and de-identified re-identification risks. The [RISK_LEVEL] placeholder should be set to high for production, which instructs the prompt to err on the side of blocking ambiguous cases. For lower-stakes internal tooling, you can set it to moderate to reduce false positives, but never set it below moderate when real patient data is possible.

Eval integration is mandatory before production. Build a test harness that runs this prompt against a golden dataset containing: (a) clearly identified PHI with known Safe Harbor categories, (b) de-identified text that should pass, (c) borderline cases like doctor names, hospital names, and dates that could be re-identified when combined, and (d) adversarial inputs that try to hide PHI through character substitution, whitespace manipulation, or clinical jargon embedding. Measure precision, recall, and F1 against the Safe Harbor categories. A recall below 0.98 on known PHI is a release blocker. Also test for over-refusal by running 500 de-identified clinical notes through the prompt and verifying that the false-positive rate stays below 2%. Log every mismatch for human review.

What to avoid: Do not send the raw user input to a logging system, analytics pipeline, or LLM observability tool before this prompt runs. Do not cache the prompt response in a shared context window that could leak PHI across sessions. Do not rely on this prompt alone for HIPAA compliance—it is a technical control that must be paired with access controls, audit trails, BAAs with model providers, and regular security review. If the prompt returns REDACT, your application must perform the redaction before any downstream processing; do not pass the original text and the redaction instruction to another model and trust it to self-censor. Finally, if you are processing high volumes, batch inputs and monitor latency—this prompt should complete in under 2 seconds for inputs under 4,000 tokens; slower responses indicate a need for model routing or prompt compression.