AI Architecture for Healthcare: HIPAA-Compliant LLM Systems (2026)

Q: Do I need a Business Associate Agreement (BAA) with OpenAI or Anthropic to use their APIs in healthcare?

Yes, if you send any Protected Health Information (PHI) through their APIs, a BAA is a legal prerequisite under HIPAA. OpenAI offers BAAs under its enterprise tier (not the standard API tier). Microsoft Azure OpenAI Service includes HIPAA BAA coverage as part of Azure's standard healthcare compliance offering. Google Cloud Vertex AI offers BAA coverage. Anthropic Claude offers BAAs for enterprise customers. However, having a BAA does not make your architecture HIPAA-compliant by itself. It is a legal prerequisite that enables you to use the service for PHI — the technical compliance requirements (audit logging, minimum necessary enforcement, breach detection, de-identification) must still be implemented in your own architecture.

Q: What is the difference between de-identification and pseudonymisation in healthcare AI?

De-identification under HIPAA refers to removing or transforming the 18 HIPAA identifiers (names, dates, geographic data, phone numbers, SSNs, MRNs, and others) such that the remaining information cannot reasonably be used to identify an individual. Full de-identification produces data that is no longer PHI and therefore not subject to HIPAA. Pseudonymisation replaces identifiers with consistent tokens (e.g., PATIENT_A4F2) and stores the mapping in a secure vault. The pseudonymised data is still technically PHI because the mapping exists, but it cannot be re-identified without access to the vault. For LLM architectures, pseudonymisation is more useful than full de-identification because it preserves the semantic relationships in the data (enabling coherent LLM responses) while preventing PHI from transiting the LLM API in original form.

Q: Can I use GPT-4 or Claude for clinical decision support under HIPAA?

Yes, with the appropriate compliance architecture. The requirements are: a valid BAA with the model provider, PHI de-identification or pseudonymisation before the query reaches the API, audit logging of every query and response that touches patient data, role-based access control enforcing the minimum necessary principle, and clear clinical governance rules that frame the LLM output as a suggestion for clinician review rather than an autonomous clinical decision. For the highest-sensitivity content (psychiatric notes, substance abuse records under 42 CFR Part 2, HIV-related data), routing to an on-premise LLM that never sends data outside your controlled infrastructure is the most defensible architecture regardless of BAA coverage.

Q: What are the HIPAA audit logging requirements for AI systems?

HIPAA's Technical Safeguards (45 CFR 164.312) require audit controls that record and examine activity in information systems that contain or use PHI. For LLM systems, this means logging every query containing PHI with: the authenticated user identity, the timestamp, the PHI identifiers detected, the clinical purpose (tied to the patient encounter), the LLM endpoint used, and the response generated. Logs must be retained for 6 years. Storage must be immutable (write-once, tamper-evident) and not modifiable by application-level credentials. Logs must be accessible for audit review and integrated with breach detection monitoring. This is not optional or advisory — it is a required safeguard, and OCR breach investigations routinely request audit logs as part of the investigation.

Q: How do I handle patient consent for AI-assisted clinical documentation?

The consent requirements depend on the specific AI application and jurisdiction. For ambient AI scribing (recording and transcribing patient consultations), most US states require patient consent before recording. Some organisations satisfy this through a Notice of Privacy Practices that includes AI documentation use; others require explicit verbal consent at the start of the encounter. The recording itself is PHI from the moment it is created and must be processed under BAA-covered infrastructure or on-premise. For AI-generated content that enters the medical record, the clinical note generated by the AI must be reviewed and signed by a licensed clinician — the AI cannot be the author of record in the legal medical record. For patient-facing AI chatbots accessing the patient's own records, the patient's identity must be verified (ideally MFA), and the scope of accessible PHI must be limited to the patient's own records only.

Q: What is the cost of HIPAA-compliant LLM infrastructure?

Costs vary significantly by deployment model. For a cloud-hosted architecture using Azure OpenAI Service (with built-in HIPAA BAA), the primary additional costs over standard enterprise AI are: PHI detection and de-identification (AWS Comprehend Medical at 0.01 USD per unit, plus compute for Presidio); immutable audit log storage (approximately 50 to 200 USD per month for a mid-size deployment); and the premium for enterprise API tiers that include BAA coverage (typically 20 to 50 percent above standard API pricing). For an on-premise deployment covering 50,000 queries per day (small to mid-size hospital deployment), expect 150,000 to 400,000 USD in hardware capital cost, 30,000 to 80,000 USD annual operating costs excluding IT staff, and 50,000 to 100,000 USD in implementation and compliance validation. The ROI on clinical documentation assistance — which reduces documentation time by 30 to 50 percent for clinicians — typically justifies the investment within 12 to 18 months at hospitals with 50 or more active physicians using the system.

Q: Are there HIPAA equivalents outside the United States for healthcare AI?

Yes. In the EU, GDPR Article 9 provides special-category protection for health data, requiring explicit consent or specific legal basis for processing, and the EU AI Act classifies clinical decision support as high-risk AI subject to conformity assessment requirements. In the UK, the Data Security and Protection Toolkit (DSPT) governs NHS organisations and their technology suppliers, and NHS England has specific guidance on AI clinical safety under DCB0160. In Australia, the Privacy Act covers health information with heightened protections under the Australian Privacy Principles, and the TGA regulates AI as a software medical device. In Singapore, MAS and MOH have joint guidance on AI governance in healthcare contexts. Canada's PIPEDA and provincial health privacy acts (PHIPA in Ontario, HIA in Alberta) govern health data with requirements broadly similar to HIPAA. Each jurisdiction has specific requirements for data residency, breach notification timelines, and patient rights that must be addressed in your architecture.

Q: How should I handle AI-generated clinical notes in the electronic health record?

AI-generated clinical notes should enter the EHR only after clinician review and approval, and must be clearly attributed as AI-assisted in the documentation. Most EHR vendors (Epic, Oracle Health) have established workflows for AI-generated content that route it to a clinician inbox for review before it becomes part of the permanent record. The clinician must review, edit as needed, and electronically sign the note — establishing clinical and legal accountability. The note should carry metadata indicating that it was AI-generated and identifying the AI system used (relevant for audit purposes and for future research use of the records). AI-generated notes that enter the record without clinician review create significant liability exposure and raise questions about the legal validity of the documentation. The standard of care is clear: AI generates, clinician reviews and signs.