Healthcare Disclosure Decision Gate Prompt

This prompt is an engineering control for health-tech applications that must evaluate a proposed disclosure of protected health information (PHI) before it leaves the system. The ideal user is a backend engineer, an AI product developer, or a compliance architect integrating an LLM into a clinical data pipeline, a patient portal, or a data export service. The prompt's job is not to make the final legal determination but to act as a deterministic, auditable gate that enforces your organization's disclosure policy at the application layer. It expects a structured input containing the proposed content, the recipient's role and authorization status, and the specific HIPAA provision under which the disclosure is requested.

You should use this prompt when your application generates a response, prepares a data export, or services an access request that may contain PHI. It is designed for synchronous, pre-transmission checks where latency is acceptable in exchange for a documented decision. The prompt produces a structured JSON decision with a clear allow, deny, or needs_review status, a minimum necessary determination, and a concise audit trail entry. This output should be logged immutably before any data is released. The prompt is not a replacement for legal counsel or a HIPAA compliance officer; it is a software control that ensures every automated disclosure is evaluated against a consistent policy before execution.

Do not use this prompt for real-time clinical decision support, de-identification of data sets, or as a substitute for a patient's right to access their own records under 45 CFR § 164.524. It is also not designed to interpret complex, multi-party information blocking rules. The prompt's strength is in evaluating a single, well-scoped disclosure request against a provided policy snippet. For any output marked needs_review, you must route the request to a human reviewer and block the automated release. The next section provides the copy-ready prompt template you can adapt to your specific policy language and output schema.

This prompt template is designed to be the core decision engine for a healthcare disclosure gate. It forces the model to act as a compliance analyst, evaluating a proposed AI-generated response or data access request against HIPAA's Privacy Rule. The template is structured to produce a machine-readable JSON output that includes a clear decision, a minimum_necessary_determination, and a detailed audit_trail. This structured output is critical for integrating the gate into an automated pipeline where the decision can be parsed and acted upon programmatically.

textCopy
You are a HIPAA compliance analyst. Your task is to evaluate the following proposed disclosure of Protected Health Information (PHI) against the HIPAA Privacy Rule. You must determine if the disclosure is permitted without patient authorization for the stated purpose.

## INPUT DATA
- **Proposed Disclosure:** [PROPOSED_DISCLOSURE_TEXT]
- **Purpose of Disclosure:** [PURPOSE_OF_DISCLOSURE]
- **Patient Authorization Status:** [PATIENT_AUTHORIZATION_STATUS]
- **Relevant Patient Directives:** [PATIENT_DIRECTIVES]
- **State Law Preemption Notes:** [STATE_LAW_NOTES]

## CONSTRAINTS
1.  Apply the **Minimum Necessary Standard**: Only disclose the PHI that is minimally necessary to accomplish the stated purpose.
2.  **Psychotherapy Notes**: If the proposed disclosure contains psychotherapy notes, the decision must be `BLOCK` unless there is specific, separate patient authorization.
3.  **Marketing & Fundraising**: Disclosures for marketing or fundraising purposes without authorization must be `BLOCK`.
4.  **De-identification**: If the text has been de-identified according to the Safe Harbor method, the decision should be `PERMIT`.
5.  **Law Enforcement**: Disclosures to law enforcement are only `PERMIT` if they meet specific conditions (e.g., court order, to identify a suspect). Clearly state the condition in the audit trail.

## OUTPUT SCHEMA
You must respond with a single JSON object conforming to this schema:
{
  "decision": "PERMIT" | "BLOCK" | "NEEDS_HUMAN_REVIEW",
  "minimum_necessary_determination": {
    "is_minimal": boolean,
    "rationale": "string explaining why the data is or is not minimally necessary"
  },
  "phi_categories_identified": ["string"],
  "audit_trail": {
    "rule_applied": "string",
    "reasoning": "string",
    "risk_level": "LOW" | "MEDIUM" | "HIGH"
  },
  "recommended_redactions": ["string"]
}

## EVALUATION INSTRUCTIONS
1.  Analyze the [PROPOSED_DISCLOSURE_TEXT] for any of the 18 HIPAA identifiers.
2.  Check the [PURPOSE_OF_DISCLOSURE] against permitted uses (Treatment, Payment, Operations) and any [PATIENT_DIRECTIVES].
3.  If the [PATIENT_AUTHORIZATION_STATUS] is `VALID`, you may `PERMIT` the disclosure, but still apply the Minimum Necessary Standard.
4.  If any condition is ambiguous or you are uncertain, set the decision to `NEEDS_HUMAN_REVIEW` and explain the ambiguity in the audit trail.
5.  If the decision is `BLOCK`, you must provide a clear, specific reason in the audit trail.

To adapt this template, start by replacing the placeholders with your actual data sources. The [PROPOSED_DISCLOSURE_TEXT] should be the exact output from your AI system. The [PATIENT_AUTHORIZATION_STATUS] should be a boolean or string pulled from your application's consent management database. The most critical adaptation is the OUTPUT SCHEMA; ensure the decision enum values (PERMIT, BLOCK, NEEDS_HUMAN_REVIEW) map directly to the control flow in your application code. Before deploying, run this prompt through a battery of eval cases, including edge cases like disclosures involving minors, deceased patients, or data mixed with state-law-protected categories like HIV/AIDS status, to ensure the NEEDS_HUMAN_REVIEW path is correctly triggered. Never allow a PERMIT decision to bypass a final human review step for any output flagged as MEDIUM or HIGH risk.

The Healthcare Disclosure Decision Gate Prompt is designed to be a synchronous, blocking step in a larger AI pipeline—not a standalone chatbot interaction. The application layer must enforce the gate: if the prompt returns a decision of BLOCK or NEEDS_REVIEW, the downstream disclosure action must be programmatically halted. The prompt itself is an advisory decision engine; the application code is the enforcement mechanism. This separation ensures that even if the model hallucinates a PROCEED decision under adversarial conditions, the surrounding harness can apply additional checks before any protected health information (PHI) is transmitted.

Wire the prompt into a structured API call with explicit JSON mode enabled. The application must supply the required inputs—[DISCLOSURE_REQUEST], [PATIENT_CONTEXT], [DISCLOSURE_POLICY], and [AUDIT_TRAIL_ID]—from trusted upstream sources. After receiving the model response, validate the output against a strict schema: decision must be one of PROCEED, BLOCK, or NEEDS_REVIEW; minimum_necessary_determination must be a non-empty string; patient_authorization_status must be one of AUTHORIZED, NOT_AUTHORIZED, or NOT_APPLICABLE; and audit_trail_entry must be a valid JSON object containing timestamp, decision, rationale, and reviewer fields. If validation fails, retry once with the validation error appended to the prompt as a correction instruction. If the retry also fails, escalate to a human reviewer and log the failure for prompt debugging.

Human review is mandatory for any NEEDS_REVIEW decision and strongly recommended for all PROCEED decisions in high-risk contexts. The application should route NEEDS_REVIEW cases to a designated review queue with the full prompt context, model output, and a pre-formatted approval UI that allows the reviewer to override the decision with a required justification. For PROCEED decisions, implement a sampling-based audit where a configurable percentage of approvals are surfaced for retrospective human review. Log every decision—including the model's raw output, validation results, retry attempts, and human overrides—to an immutable audit store indexed by [AUDIT_TRAIL_ID]. This creates a defensible record for HIPAA compliance and enables ongoing evaluation of the prompt's accuracy and safety.

Model choice matters: use a model with strong instruction-following and low hallucination rates on structured output tasks. GPT-4o, Claude 3.5 Sonnet, or equivalent frontier models are appropriate. Avoid smaller or older models that may conflate NEEDS_REVIEW with PROCEED under ambiguous policy language. Set temperature to 0 or near-zero to maximize deterministic behavior. Do not implement caching on this prompt—each disclosure decision must be evaluated fresh against the current policy and patient context. If latency is a concern, run the gate check in parallel with other pre-disclosure validations, but never allow the disclosure to proceed before the gate returns a valid, non-blocked decision.

Common failure modes in production include: the model approving disclosure when the patient authorization is expired or absent; the model failing to apply the minimum necessary standard and allowing full record access when a subset would suffice; and the model producing a valid JSON structure but with a rationale that contradicts the decision field. Mitigate these by implementing a secondary validation step that checks semantic consistency between the decision and rationale using a lightweight LLM judge prompt. If the judge flags an inconsistency, escalate to human review regardless of the primary decision. Finally, treat the disclosure policy text as a versioned artifact—when the policy changes, run the new prompt version against a golden test set of historical disclosure scenarios before deploying to production.