Shipping AI in Healthcare: HIPAA, FHIR, and What Actually Matters

Healthcare AI is where the highest-impact opportunities meet the strictest regulatory requirements. We have built three AI systems that handle protected health information (PHI), and the compliance requirements changed how we architect everything from data storage to model deployment. Here is what we wish someone had told us before the first project.

HIPAA in Plain Language

HIPAA is not one law. It is a set of rules that govern how organizations handle PHI (any health information that can be tied to an individual). The parts that matter for AI systems are the Privacy Rule (who can access PHI and under what conditions), the Security Rule (technical safeguards for electronic PHI), and the Breach Notification Rule (what happens when something goes wrong).

The practical implication: every system that touches PHI needs encryption at rest and in transit, access controls with audit logs, and a documented security plan. For AI systems specifically, this includes the training data, the model inputs, the model outputs, and any logs that might contain PHI.

Business Associate Agreements

If you are a vendor building AI for a healthcare organization, you need a BAA (Business Associate Agreement) with every subprocessor that touches PHI. That includes your cloud provider, your LLM API provider, your vector database, and any third-party service in the data path.

AWS, Azure, and GCP all offer BAAs. OpenAI offers a BAA for their enterprise tier. Anthropic offers one as well. If a vendor will not sign a BAA, you cannot use them for PHI workloads. This is non-negotiable and eliminates a lot of tools from consideration.

Data De-identification

One approach to simplify compliance is to de-identify data before it enters your AI pipeline. HIPAA defines two methods: Safe Harbor (remove 18 specific identifiers) and Expert Determination (a statistician certifies the data is not re-identifiable). Safe Harbor is more common because it is prescriptive.

For training data, de-identification often makes sense. You get the medical value without the compliance burden. For inference, it depends on the use case. A clinical decision support tool needs the patient's actual data to be useful. A population health analytics model does not.

We use NER (Named Entity Recognition) models to automatically detect and redact PHI from free-text clinical notes. This works well for obvious identifiers (names, dates, MRNs) but requires human review for edge cases (references to rare conditions that could identify a patient).

FHIR Interoperability

FHIR (Fast Healthcare Interoperability Resources) is the standard for exchanging healthcare data between systems. If your AI system needs to pull patient data from an EHR (Epic, Cerner, etc.), you will almost certainly use FHIR APIs.

The good news: FHIR is well-designed and has strong tooling (HAPI FHIR for Java, fhir.resources for Python). The challenge: every EHR implements FHIR slightly differently. Epic's FHIR API has different quirks than Cerner's. Budget extra time for integration testing with each EHR system.

For AI applications, FHIR R4 is the version to target. It has the broadest adoption and covers most clinical data types you will need: Patient, Observation, Condition, MedicationRequest, DiagnosticReport.

LLM-Specific Concerns

Using LLMs with PHI introduces additional considerations:

• Data residency: PHI should not leave the country (or region, depending on the customer). Use region-specific deployments and verify that your LLM provider processes data in the required geography.
• Data retention: LLM providers may retain inputs for model improvement. Verify that your provider does not train on your data and does not retain prompts or completions beyond the API call.
• Audit logging: Every LLM call that includes PHI must be logged with who made the request, what data was included, and what the model returned. These logs themselves contain PHI and need the same protections.
• Output filtering: LLMs can generate PHI in unexpected ways (e.g., repeating a patient name from the context in a summary). Post-processing filters should catch and redact any PHI that appears in the output where it should not.

Our Compliance Checklist

Before deploying any healthcare AI system, we verify:

• BAAs in place with every subprocessor
• Encryption at rest (AES-256) and in transit (TLS 1.2+)
• Role-based access control with least-privilege principle
• Audit logs for all PHI access with 6-year retention
• De-identification pipeline tested and validated
• Data residency requirements documented and verified
• Incident response plan documented and tested
• Security risk assessment completed
• Employee training on PHI handling documented

It Sounds Harder Than It Is

HIPAA compliance adds real engineering work, but it is not the blocker people expect. The key is to design for compliance from day one rather than trying to retrofit it. Pick cloud services and vendors that already have BAAs. Use a de-identification pipeline early. Build audit logging into the data layer, not as an afterthought. If you do these things from the start, the incremental effort is manageable.