HIPAA-Compliant AI: Building Healthcare AI Platforms

TL;DR — HIPAA compliance for AI platforms requires: (1) Signed BAAs with every LLM provider that processes PHI — OpenAI, Anthropic, AWS Bedrock, Azure, Google Vertex AI all offer BAAs. (2) PHI de-identification before sending to the LLM — use Safe Harbor (remove 18 identifiers) or Expert Determination, tokenize, send de-identified text, re-identify the response. (3) Audit logging for every PHI-touching LLM call — prompt, response, timestamp, user, model. Logs contain PHI and must be encrypted and retained for 6 years. (4) Encryption in transit (TLS 1.2+) and at rest (AES-256) for all PHI, including logs and cached prompts. (5) Zero training on patient data — the BAA must explicitly prohibit it. (6) Per-tenant access control with minimum necessary access. (7) Breach notification procedures. The safest PHI is PHI that never reaches the model in identifiable form.

What "HIPAA-Compliant AI" Actually Means

HIPAA does not have a specific section on AI. There is no "HIPAA AI Rule." Instead, HIPAA's existing requirements — privacy, security, breach notification — apply to AI systems the same way they apply to any system that processes PHI.

An AI platform is "HIPAA-compliant" when it meets HIPAA's requirements for handling PHI:

Business Associate Agreements (BAAs)

If an LLM provider will receive, process, or store PHI, you need a BAA with them. This is non-negotiable under HIPAA.

LLM Providers That Offer BAAs

The Contract Sprawl Problem

If you use multiple models — OpenAI for some tasks, Claude for others, Bedrock for something else — you need BAAs with each provider. This creates contract sprawl and increases the risk of accidentally routing PHI through an uncovered path.

Mitigation: Centralize all LLM access through an AI gateway that enforces BAA-covered providers only. Block any request to a provider without a signed BAA.

What to Verify in the BAA

• Training opt-out: The BAA must explicitly state that the provider will not use your PHI to train their models. A blog post saying "we don't train on your data" is not enforceable — the legal agreement must say it.
• Data retention terms: How long does the provider keep prompts and responses? For what purposes? Abuse monitoring? Safety research?
• Subcontractor disclosure: Does the provider use subcontractors? Are they covered under the BAA?
• Breach notification timeline: How quickly will the provider notify you of a breach? HIPAA requires notification without unreasonable delay and no later than 60 days.
• Permitted uses: What can the provider do with your PHI? Only what you authorize.

API vs Consumer Product

ChatGPT the consumer product has different data handling than the OpenAI API. Claude.ai has different data handling than the Anthropic API. Always read the API-specific policies, not the consumer product policies.

PHI De-Identification

The safest PHI is PHI that never reaches the model in identifiable form.

Two De-Identification Standards

HIPAA defines two methods under 45 CFR 164.514:

Safe Harbor: Remove 18 specific identifiers:
1. Names
2. Geographic data (smaller than state)
3. Dates (except year) related to individual
4. Phone numbers
5. Fax numbers
6. Email addresses
7. Social Security numbers
8. Medical record numbers
9. Health plan beneficiary numbers
10. Account numbers
11. Certificate/license numbers
12. Vehicle identifiers
13. Device identifiers
14. Web URLs
15. IP addresses
16. Biometric identifiers
17. Full-face photographs
18. Any other unique identifying number

Expert Determination: A qualified statistician or expert determines that the risk of re-identification is very small.

Token-Based De-Identification Pattern

import re

PHI_PATTERNS = {
    "SSN": re.compile(r'\b\d{3}-\d{2}-\d{4}\b'),
    "MRN": re.compile(r'\bMRN[:\s]?\d{6,10}\b', re.IGNORECASE),
    "DOB": re.compile(r'\b(0?[1-9]|1[0-2])/(0?[1-9]|[12]\d|3[01])/(\d{4})\b'),
    "PHONE": re.compile(r'\b\d{3}-\d{3}-\d{4}\b'),
    "EMAIL": re.compile(r'\b[\w.+-]+@[\w-]+\.[\w.-]+\b'),
}

def deidentify(text: str, mapping: dict) -> str:
    """Replace PHI with tokens. Store token -> original in mapping."""
    for phi_type, pattern in PHI_PATTERNS.items():
        for match in pattern.finditer(text):
            token = f"[{phi_type}_{len(mapping)}]"
            mapping[token] = match.group()
            text = text.replace(match.group(), token, 1)
    return text

def reidentify(text: str, mapping: dict) -> str:
    """Restore original values from token mapping."""
    for token, original in mapping.items():
        text = text.replace(token, original)
    return text

Re-Identification Key Management

The mapping table is what makes the data re-identifiable. Its lifecycle matters for compliance:

• Short lifetime: Destroy the mapping immediately after re-identification. Don't persist it.
• Encrypted storage: The mapping must be encrypted at rest with AES-256.
• Access-controlled: Only the application process should have access to the mapping — never log it, never send it to the LLM.
• Never logged alongside de-identified data: If the mapping and the de-identified text are in the same log entry, the data is re-identifiable in your logs.

Unstructured Text De-Identification

Regex patterns handle structured identifiers (SSNs, MRNs, dates). Unstructured clinical text requires NLP-based detection:

• AWS Comprehend Medical: Managed service for detecting PHI in clinical text
• spaCy with clinical NER models: Open-source NLP for entity recognition
• Presidio by Microsoft: Open-source PII/PHI detection and anonymization

The Re-Identification Risk

If the LLM responds with "[PATIENT_1] should take [MEDICATION_1] twice daily," you must restore the actual patient name and medication before showing it to a clinician. If your re-identification algorithm mixes [PATIENT_1] and [PATIENT_2], your application could recommend the wrong medication to the wrong patient.

Mitigation: Use unique, sequential tokens. Test re-identification with edge cases (multiple patients, similar names, nicknames). Log the re-identification operation (without the actual values) for audit trail.

Audit Logging for LLM Interactions

HIPAA's audit control standard (45 CFR 164.312(b)) requires mechanisms to record and examine activity in systems containing PHI.

What to Log

For every LLM interaction that involves PHI:

{
  "timestamp": "2026-07-11T10:15:00Z",
  "user_id": "dr.smith@hospital.com",
  "tenant_id": "hospital-network-456",
  "model": "gpt-4o-2026",
  "provider": "openai",
  "prompt_hash": "sha256:a1b2c3...",
  "prompt_phi_classification": "deidentified",
  "response_hash": "sha256:d4e5f6...",
  "tokens_in": 450,
  "tokens_out": 120,
  "latency_ms": 850,
  "purpose": "clinical_decision_support",
  "minimum_necessary_applied": true,
  "baa_provider": "openai"
}

Important: The log entry contains a hash of the prompt and response, not the full text. Full prompt/response logs contain PHI and must be stored in encrypted, access-controlled long-term storage. The audit log entry references the encrypted storage location.

Log Storage Requirements

• Encrypted at rest: AES-256 for all log storage
• Access-controlled: Only compliance and security teams can access PHI logs
• Retention: HIPAA requires 6 years of retention for audit logs
• Separation of concerns: Operational logs (debugging) vs compliance logs (audits) have different retention and access requirements

LLM Providers Don't Log for You

You get API responses, not audit trails. You must build infrastructure that captures PHI-touching requests and stores them in compliant log storage. This is the most commonly missed requirement.

Encryption Requirements

In Transit

TLS 1.2+ (preferably TLS 1.3) for all API calls to LLM providers. Most providers enforce this by default.

At Rest

Your responsibility for:
- Logs containing PHI (prompts, responses)
- Cached prompts or responses
- De-identification mapping tables
- Vector embeddings of PHI-containing documents
- Fine-tuned model weights (may contain PHI patterns)

Key Management

Use AWS KMS, Google Cloud KMS, or Azure Key Vault for encryption key management. If you manage keys yourself, that's additional infrastructure to build and maintain. Rotate keys regularly. Restrict key access to the minimum necessary roles.

Data Handling: Zero Training on Patient Data

What to Verify

1. Explicit opt-out in the BAA: The legal agreement must state that the provider will not use your PHI for training. Not a policy page — the contract.

2. Data retention terms: How long does the provider keep your prompts and responses? OpenAI's API policy says 30 days for abuse monitoring, then deleted. What matters legally is what your BAA says.

3. API vs consumer product: Verify you're reading the API data handling policy, not the consumer product policy. They are different.

4. Zero retention option: Some providers offer a zero-retention mode where prompts are processed in memory and never persisted. Use this where available.

Minimum Necessary Principle

HIPAA's minimum necessary principle (45 CFR 164.502(b)) requires that you send only the minimum PHI needed for the AI task. Don't send an entire patient record when the LLM only needs the medication list.

def apply_minimum_necessary(prompt: str, phi_context: dict) -> str:
    """Include only the PHI fields relevant to the specific task."""
    task = phi_context["task"]

    if task == "medication_review":
        # Only include medications, not full history
        relevant_fields = ["medications", "allergies"]
    elif task == "diagnosis_assist":
        # Include symptoms, vitals, relevant history
        relevant_fields = ["symptoms", "vitals", "relevant_history"]
    else:
        relevant_fields = phi_context["default_fields"]

    return build_prompt(prompt, phi_context, fields=relevant_fields)

Per-Tenant Access Control for Healthcare

In a multi-tenant healthcare AI platform, each tenant (hospital, clinic, health system) has its own access policies:

tenant_hipaa_config:
  tenant_id: "hospital-network-456"
  baa_providers:
    - openai
    - anthropic
    - aws_bedrock
  non_baa_providers_blocked: true
  de_identification:
    method: "safe_harbor"
    nlp_engine: "aws_comprehend_medical"
    mapping_lifetime_seconds: 300  # 5 minutes max
    mapping_encrypted: true
  audit_logging:
    log_phi_touching_calls: true
    log_storage: "s3-encrypted"
    retention_years: 6
    access_roles: ["compliance", "security"]
  encryption:
    in_transit: "TLS 1.3"
    at_rest: "AES-256"
    key_management: "aws_kms"
    key_rotation_days: 90
  data_handling:
    training_opt_out: true
    zero_retention_mode: true
    minimum_necessary: true
  access_control:
    role_based: true
    minimum_necessary: true
    break_glass: true  # Emergency access with audit
  breach_notification:
    internal_notification_hours: 1
    hhs_notification_days: 60
    affected_individuals_days: 60

Common Compliance Mistakes

No BAA with the LLM Provider

Sending PHI to an LLM API without a signed BAA. This is a direct HIPAA violation. The provider is a business associate, and PHI cannot be shared with a business associate without a BAA.

Fix: Sign BAAs with every LLM provider before sending any PHI. Block non-BAA providers at the gateway.

Consumer Product Instead of API

Using ChatGPT (consumer) or Claude.ai (consumer) with PHI instead of the API with a BAA. Consumer products are not covered by BAAs and may use your data for training.

Fix: Use only API endpoints with signed BAAs. Block consumer product domains at the network level.

Full PHI in Prompts

Sending full patient records to the LLM when only a subset is needed. This violates the minimum necessary principle and increases breach risk.

Fix: Apply minimum necessary filtering before sending to the LLM. Include only the fields relevant to the specific task.

Logging PHI in Plaintext

Storing LLM prompts and responses in plaintext logs. These logs contain PHI and must be encrypted at rest.

Fix: Encrypt all log storage. Use hashes in audit log entries, with full text in encrypted long-term storage.

De-Identification Mapping Leaked

Storing the de-identification mapping alongside the de-identified text in logs or databases. This makes the data re-identifiable in your logs.

Fix: Never log the mapping. Store it in encrypted, access-controlled memory with a short lifetime. Destroy it after re-identification.

No Breach Notification Plan

No documented procedure for notifying HHS and affected individuals if PHI is exposed through the AI system.

Fix: Document breach notification procedures. Include AI-specific scenarios (PHI in LLM logs, PHI sent to non-BAA provider, de-identification failure).

Implementation Checklist

• [ ] Sign BAAs with every LLM provider that processes PHI
• [ ] Block non-BAA providers at the AI gateway
• [ ] Verify training opt-out is in the BAA, not just the policy page
• [ ] Verify data retention terms in the BAA
• [ ] Use API endpoints, not consumer products, for all PHI processing
• [ ] Implement PHI de-identification before sending to the LLM
• [ ] Use Safe Harbor (18 identifiers) or Expert Determination
• [ ] Use NLP for unstructured clinical text (AWS Comprehend Medical, spaCy)
• [ ] Store de-identification mapping in encrypted, short-lived memory
• [ ] Never log the mapping alongside de-identified data
• [ ] Test re-identification with edge cases (similar names, multiple patients)
• [ ] Log every PHI-touching LLM call (prompt hash, response hash, user, model, timestamp)
• [ ] Encrypt all log storage at rest with AES-256
• [ ] Retain audit logs for 6 years
• [ ] Restrict log access to compliance and security teams
• [ ] Encrypt all PHI in transit (TLS 1.2+) and at rest (AES-256)
• [ ] Use managed KMS for encryption key management
• [ ] Rotate encryption keys regularly (90 days)
• [ ] Apply minimum necessary principle — send only needed PHI fields
• [ ] Enable zero-retention mode where available
• [ ] Configure per-tenant HIPAA policies
• [ ] Implement break-glass access with audit trail for emergencies
• [ ] Document breach notification procedures including AI-specific scenarios
• [ ] Train staff on HIPAA requirements for AI systems
• [ ] Conduct annual HIPAA risk assessment including AI components

Conclusion

HIPAA compliance for AI is not about a single feature or certification — it's about meeting HIPAA's existing requirements in the context of LLM systems. The requirements are clear: BAAs with every provider, de-identification before sending to the LLM, audit logging for every PHI-touching call, encryption everywhere, zero training on patient data, and minimum necessary access.

The safest PHI is PHI that never reaches the model in identifiable form. De-identify before sending, re-identify after receiving, and destroy the mapping immediately. When de-identification isn't possible, ensure BAAs are in place, zero-retention mode is enabled, and minimum necessary filtering is applied.

Healthcare breaches average $7.42 million in costs. The compliance investment — BAAs, de-identification infrastructure, audit logging, encryption — is far cheaper than dealing with an OCR investigation and breach notification. For healthcare AI platforms, HIPAA compliance is not optional. It's the price of entry.