FHIR + LLMs: How AI Agents Connect to Electronic Health Records Without Violating HIPAA

Why FHIR Is the Right Integration Layer for Healthcare AI

Before FHIR, healthcare integrations typically required HL7 v2 message parsing, proprietary vendor APIs, or expensive middleware. HL7 FHIR R4 (released 2019, now the CMS-mandated standard for API-based data access) provides a RESTful, JSON-native API that makes EHR integration far more tractable for AI agent development.

The 21st Century Cures Act (2016) and subsequent CMS rules require that EHR vendors certified under the ONC Health IT Certification Program expose FHIR R4 APIs for patient data access. This means that the major EHR platforms — Epic, Cerner, Athenahealth, eClinicalWorks — all expose standardized FHIR endpoints that AI agents can query.

The key FHIR concepts for AI agent integration:

• Resources: FHIR organizes clinical data into typed resources — Patient, Encounter, Condition, Observation, MedicationRequest, etc. Each resource has a defined schema and can be queried via REST.
• RESTful API: FHIR APIs follow REST conventions. A GET to /Patient/[id] returns a patient record. A GET to /Condition?patient=[id] returns all conditions for a patient.
• SMART on FHIR: The authentication and authorization layer. Apps authenticate using OAuth 2.0 with SMART-specific scopes that limit data access to what is explicitly requested.

SMART on FHIR Authentication: What AI Agents Need to Know

SMART on FHIR defines two primary authentication flows relevant to AI agent integration:

Backend Services (System-to-System)

For AI agents operating autonomously without real-time user authentication, the SMART Backend Services authorization spec is the correct approach. The agent authenticates using a registered client_id and a signed JWT, receives an access token, and can then query FHIR resources within its permitted scope.

The scope definition is critical. Backend service scopes in SMART on FHIR use the format system/[ResourceType].read or system/[ResourceType].write. An agent that only needs to read patient demographics and conditions should request system/Patient.read system/Condition.read — not blanket system/*.read access.

This scope minimization is both a HIPAA minimum-necessary requirement and a security control. An agent operating under system/*.read has access to every clinical record in the EHR — far more than any specific workflow requires.

Standalone Launch (User-Delegated)

For agents that act on behalf of a specific user — for example, a scheduling agent that a care coordinator launches from within the EHR — the SMART standalone launch flow authenticates the user first, then grants the agent a token scoped to that user's permissions. This is appropriate for workflows where human oversight is built into the launch process.

Key FHIR Resources for Common Healthcare AI Workflows

How to Safely Pass FHIR Data to an LLM

This is where most implementations introduce unintended HIPAA risk. The naive approach — dump the raw FHIR response JSON into the LLM prompt — has several problems:

• PHI in the LLM context window: Raw FHIR resources contain PHI. If the LLM provider's infrastructure logs prompts (and many do by default), PHI is now in the provider's log systems. This is a potential HIPAA violation unless the provider operates under a BAA with logging restrictions.
• Over-fetching: A prior auth workflow may only need the diagnosis code and medication name. Sending the full patient record to the LLM exposes far more PHI than the minimum necessary standard permits.
• Token cost and latency: FHIR resources are verbose JSON. A full patient record with all encounters and observations can exceed 100K tokens — both expensive and slow.

The correct pattern is extraction-before-inference:

1. Query FHIR for the specific resources needed for the workflow
2. Extract only the clinical fields relevant to the task (ICD-10 codes, procedure codes, medication names) in a middleware layer
3. Pass only the extracted, de-contextualized fields to the LLM — not the full resource
4. Apply the LLM reasoning (match criteria, generate text, classify) against the extracted data
5. Write outputs back to FHIR or the target system without logging intermediate LLM context

Rate Limits, Bulk Data, and Production Realities

FHIR APIs in production EHR environments have rate limits that catch most developers off guard. Epic, for example, enforces per-client rate limits that can throttle an agent attempting to process hundreds of patient records concurrently. Key considerations:

• FHIR Bulk Data Access ($export): For workflows that need to process large patient populations (care gap closure, population health reporting), the FHIR Bulk Data Access specification provides asynchronous export of NDJSON files rather than per-patient queries. This is the right approach for batch processing workloads.
• Vendor-specific extensions: Epic, Cerner, and Athenahealth all implement FHIR with proprietary extensions. Code that works against a reference FHIR server may behave differently against a production Epic endpoint. Plan for per-vendor integration testing.
• Write operations: FHIR read access is relatively standardized. Write operations vary significantly by vendor — many EHR implementations are read-only for external apps, or require specific Questionnaire/QuestionnaireResponse workflows for structured data entry.

Preventing Prompt Injection in Healthcare AI Agents

Healthcare EHR data is particularly vulnerable to indirect prompt injection — where malicious content embedded in clinical notes or patient-provided fields attempts to manipulate agent behavior. Consider a patient who enters the following in their "reason for visit" field:

If the agent passes this field directly into an LLM prompt without sanitization, and the LLM follows the instruction, the consequences in a healthcare context could be serious. Mitigations:

• Treat all patient-provided data as untrusted input and sanitize before including in prompts
• Use structured extraction for known fields rather than free-text summarization
• Run agent outputs through a validation layer before any actions are taken
• Require human review before high-stakes outputs (authorization decisions, prescriptions, billing) are processed