FHIR R4 is frequently invoked as a guarantee of interoperability. In vendor conversations, it often functions as a shorthand for "we integrate with Epic" or "we connect to athenahealth." What FHIR R4 actually provides is a common data model and a set of REST API conventions. What it does not provide is uniformity in how any given EMR implements those conventions, which endpoints they expose, what their authorization flows look like, or how they handle the specific resource types that a voice agent needs to write appointment and refill data.
For clinical operations staff evaluating voice AI for their practice, the distinction matters. Understanding what a FHIR-based integration actually involves helps you ask better questions before signing anything.
What FHIR R4 Actually Standardizes
The HL7 FHIR R4 specification defines resource types, like Patient, Appointment, MedicationRequest, and Encounter, along with a REST API pattern for creating, reading, updating, and deleting records. It defines how data should be structured in JSON or XML payloads. The 21st Century Cures Act's information blocking rules require certified health IT systems to expose patient data access through FHIR R4 interfaces, which is why most major EMRs now have at least a partial FHIR R4 implementation.
What the specification does not define is implementation depth. Two EMRs can both claim FHIR R4 compliance while exposing radically different sets of endpoints, applying different authorization requirements, returning data in different structures within the spec's allowed variations, and implementing different behaviors when a write-back fails. The spec defines the vocabulary and grammar. It does not define the full sentence.
This is not a criticism of FHIR. The flexibility is by design, to allow for diverse implementation contexts. For integration engineers, it just means that each EMR requires its own integration work, and "we support FHIR" is the starting point of a conversation, not the conclusion.
Epic's FHIR Implementation: What Vendors Navigate
Epic's FHIR implementation is one of the most mature in the market. The Epic on FHIR developer program provides a substantial set of supported APIs, and their documentation is more complete than most EMR vendors. For a vendor building a voice agent integration with Epic, the relevant resources are primarily Appointment, Patient, and MedicationRequest.
The practical complexity starts with Epic's authorization requirements. Epic uses OAuth 2.0 with SMART on FHIR scopes, and the credential provisioning process requires going through Epic's App Orchard marketplace or, for enterprise health system integrations, a direct agreement with the Epic customer. For an ambulatory specialty practice running Epic, the IT team at their health system intermediary controls API access provisioning, which means integration timelines depend on their IT department's queue, not just the vendor's technical readiness.
Epic's appointment write-back through FHIR R4 works well for practices where slot availability is exposed through the API. Where it gets complicated is in specialty practices with complex scheduling templates, where slot availability logic lives in Epic configuration rather than in simple slot records. A voice agent trying to write an appointment into a specialty template that has provider-specific overrides or complex recurring blocks will encounter edge cases that require practice-level configuration review, not just API integration.
One thing Epic does well is audit logging. Writes through the FHIR API are logged in the same audit trail as any other interaction with the record. For HIPAA compliance purposes, this is important. The integration audit trail is not a separate system, which simplifies compliance documentation.
athenahealth's FHIR Implementation: Different Trade-offs
athenahealth's FHIR R4 implementation takes a different approach than Epic's. athenahealth has historically been a cloud-native system, and their API surface for partners has been available longer than many competing EMRs. The athenahealth Marketplace and their partner API documentation cover appointment, patient, and clinical data endpoints with reasonable depth.
Where athenahealth differs from Epic in a way that matters for voice agent integration is in appointment management. athenahealth's scheduling model distinguishes between appointment types, providers, and departments in a way that affects how slots are presented through the API. A voice agent that needs to book an appointment must resolve those three dimensions before it can confirm availability, and the mapping between a patient's verbal request ("I need to see Dr. Chen for a follow-up on my knee") and the correct appointment type in athenahealth requires configuration work upfront.
athenahealth also uses their own integration credential process through the Marketplace. For smaller practices, the timeline from application to approved credentials can vary, which is a procurement consideration for clinics wanting to deploy quickly.
One significant advantage of athenahealth from an integration standpoint is their webhook support for appointment events. A voice agent that books an appointment through the API can receive confirmation webhooks when the booking is reflected in the practice's schedule, enabling more reliable real-time write confirmation than a polling approach.
Where HL7 v2 Still Matters
FHIR R4 gets most of the attention in vendor discussions, but HL7 v2 messaging remains the dominant interface standard for many older EMR deployments. eClinicalWorks, NextGen, and older versions of Allscripts are frequently integrated through HL7 v2 message feeds, particularly in practices that implemented these systems before FHIR became prevalent.
For voice agent write-back in HL7 v2 environments, the practical approach is usually a message engine or integration engine that translates structured data from the voice agent into HL7 v2 ADT or SIU messages. This adds an integration layer but is workable in practices where FHIR is not available. The trade-off is that HL7 v2 pipe-delimited message structures are more brittle than FHIR JSON, and errors in message formatting can cause silent failures that do not generate error responses at the API level.
What This Means for a Clinic Evaluating Voice AI
For a practice manager or clinical IT contact evaluating voice AI vendors, the questions worth asking directly are: Which FHIR resource types does your write-back cover? What is your integration process with our specific EMR version? How do you handle appointment write failures, and what notification goes to our staff when one occurs? What does your BAA cover in terms of the data that passes through your integration layer?
Vague answers to those questions are informative in a different way than precise ones. A vendor who responds to "how do you handle Epic appointment write failures" with a high-level description of retry logic is telling you something about their integration maturity. A vendor who describes their specific error handling, what state the system enters when a write fails, and how your staff is notified is telling you something else.
At Tivara, our integration work starts with reading the practice's EMR configuration before building the connection. The appointment type mapping, the provider-to-slot resolution logic, and the failure notification protocols are not generic settings. They are determined by the specific configuration of that practice's EMR instance. This work happens before a voice agent goes live, and it is the part of the integration that vendors often underestimate in their scoping conversations.
FHIR R4 is a meaningful standard, and it has made EMR integration substantially more tractable than it was in the HL7 v2 era. But "we support FHIR" is still the beginning of the conversation about what integration actually involves for a given practice's EMR environment. The detail is in the implementation.