When a specialty practice evaluates ambient clinical documentation, the first clinical question is usually: how good is the transcription? The first operational question is usually: how does it integrate with our EHR? The integration question matters more to long-term adoption than transcript quality, because if the generated note doesn't land cleanly in the chart, every efficiency gain from ambient documentation is offset by manual copy-paste work or parallel system maintenance.
There are three meaningfully different integration architectures available for connecting ambient AI to an existing EHR system: FHIR R4 API integration, HL7 v2 message-based integration, and direct proprietary API integration with specific EHR vendors. Each has different tradeoffs across workflow disruption, data fidelity, rollout timeline, and long-term maintainability. We've worked through all three as we've built Prioriq's integration layer, and the right path depends heavily on the specific EHR stack a practice runs.
FHIR R4: The Modern Standard and Its Current Limits
FHIR R4 (Fast Healthcare Interoperability Resources, Release 4) is the current standard for health data exchange, finalized by HL7 International and required for API access by the 21st Century Cures Act's information blocking provisions. Most major EHR vendors — Epic, Cerner, Athenahealth, eClinicalWorks — expose FHIR R4 APIs, and those APIs are standardized enough that a well-built FHIR client can read patient data and write clinical notes using the same base code across multiple EHR implementations.
The FHIR resource types relevant for ambient documentation integration are primarily DocumentReference (for attaching the generated clinical note to the patient's record) and Composition (for structured clinical documents with defined sections). Reading prior visit context uses Patient, Condition, Observation, MedicationRequest, and Procedure resources — all well-defined in R4.
What FHIR R4 does well: write operations through DocumentReference are supported by every major EHR vendor's FHIR server, and the response to a successful document write means the note is in the chart, accessible through the normal EHR interface. For reading clinical context before an encounter — pulling a patient's active problem list, current medications, recent lab values — FHIR provides consistent query patterns that work across EHR vendors without per-vendor custom code.
What FHIR R4 currently doesn't handle well in practice: deep EHR-specific workflow integration. Writing a note via FHIR DocumentReference creates a document that appears in the chart, but it may not appear in the same location in the chart as a note written natively within the EHR. Epic's FHIR server, for example, routes externally-written notes into a specific "external documents" section unless the integration is configured through Epic's App Orchard certification pathway, which requires a formal vendor relationship and validation. For practices running Epic, this is a real consideration — a note that shows up in a non-standard location in the chart creates cognitive overhead for the physician reviewing it.
HL7 v2: Legacy Standard, Still Dominant in Practice
HL7 v2 is the older message-based integration standard — predating FHIR by decades — and it remains the most widely deployed integration technology in U.S. healthcare IT. Many clinical systems that are actively in use today, particularly in hospital-affiliated specialty practices, still exchange data primarily through HL7 v2 messages: ADT (Admit-Discharge-Transfer), ORM (Order), ORU (Observation Result), and MDM (Medical Document Management) message types.
For ambient documentation, the relevant message types are MDM^T02 (Original Document Notification) and MDM^T04 (Document Status Change Notification) — these are the v2 messages used to send a clinical document from an external system into an EHR's document management workflow. HL7 v2 MDM integration lands the note in the EHR's standard document inbox, where it appears in the physician's review queue exactly like a dictated note routed through a traditional transcription service.
The advantage of HL7 v2 MDM for ambient documentation is precisely this familiarity. The EHR's document management workflow already exists, already works, and already has physician review steps built into it. An externally-generated note arriving via MDM message is operationally identical to a transcribed note from any other source. There's no new workflow to teach. The note shows up where notes show up.
The limitation is bidirectionality. HL7 v2 is fundamentally a message transport protocol — it pushes data, it doesn't support the rich query semantics of FHIR. Reading clinical context for encounter preparation (pulling the patient's current medication list, recent diagnoses, prior authorization history) requires separate integration work, typically through a dedicated HL7 v2 query interface if the EHR supports it, or through a separate FHIR read even if document delivery goes through v2. Most production ambient documentation integrations in HL7 v2-heavy environments end up using a hybrid: FHIR R4 for reading context, HL7 v2 for writing notes back to the chart.
Direct EHR API: Deeper Integration, More Constraints
Several major EHR vendors have built their own proprietary API layers beyond what their FHIR servers expose. Epic's APIs (accessed through the App Orchard program) support deep integration including note templates, SmartText insertion, context-sensitive display within the Epic Hyperspace interface, and encounter-aware note placement. Athenahealth's API (through the More Disruption Please program) provides similar context-aware integration with Athena-specific workflow components.
Direct proprietary API integration provides the best user experience when it works. A note generated by an ambient system can be delivered into the exact note template a physician normally uses, pre-populated with the structured sections the EHR expects, ready for inline editing in the same interface the physician uses for everything else. There's no context switching, no separate review queue, no non-standard document location.
The cost is vendor dependency and certification overhead. Epic App Orchard certification requires a formal application, technical review, compliance attestation, and ongoing maintenance of the certification as Epic versions change. This is appropriate for a product with scale — Epic's customer base is large enough that certification investment amortizes across many deployments. For a smaller ambient documentation vendor, the certification timeline (which can run 6 to 18 months) creates a real delay in being able to offer the best integration experience to Epic customers.
We are not saying proprietary API integration is wrong or should be avoided — for practices that run Epic or Athenahealth and where the integration investment is justified by volume, it provides the best clinical workflow experience. What we're saying is that the decision to invest in deep proprietary integration should be made explicitly, with realistic timelines, rather than assumed to be the obvious choice.
Practical Integration Path Selection
For a specialty practice evaluating ambient documentation today, the integration decision depends on three variables: which EHR you run, how many physicians you're deploying to, and what your existing IT infrastructure looks like for integration middleware.
For practices running Epic (the most common EHR in academic medical centers and large health systems), the realistic near-term integration path for most ambient documentation vendors is FHIR R4 read + HL7 v2 MDM write, with the note landing in the standard Epic document management workflow. Full App Orchard integration is available from vendors who have completed certification, but it's worth asking specifically which version of Epic they're certified against and what happens when Epic upgrades.
For practices running Athenahealth, the native Athena API provides direct integration that works well, and Athena has been relatively open about API access compared to Epic. For eClinicalWorks and NextGen-based practices, FHIR R4 write support exists but is less consistent in note placement. For smaller specialty-specific EHRs — systems built around cardiology, orthopedics, or ophthalmology workflows — integration often requires HL7 v2 MDM because FHIR support is limited or recent.
The Context Pull: What the System Needs to Read Before the Encounter
The integration architecture discussion usually focuses on writing the note back into the EHR. Equally important — and often overlooked — is reading clinical context before the encounter begins. An ambient documentation system that generates a better note because it knows the patient's active medications, recent lab values, and current ICD-10 problem list is more useful than one that transcribes in a contextual vacuum.
Context pull via FHIR R4 reads is now reliable across major EHR vendors for standard clinical resources. A pre-encounter context query can pull Patient demographics, Condition (active problem list), MedicationRequest (current medications), AllergyIntolerance, recent Observation (labs and vitals), and relevant DiagnosticReport resources — enough to give the ambient system meaningful clinical context for note generation.
Where context pull gets complicated is in the prior authorization relevance filter. For Prioriq specifically, we want to know before an encounter which of the patient's medications or planned procedures are going to require prior auth, so the ambient documentation can capture the relevant clinical narrative in the encounter note rather than having a coordinator extract it later. That requires reading not just the clinical data but cross-referencing it against payer-specific PA requirement data — which isn't in the EHR. It's in Prioriq's PA criteria database. That cross-reference is what makes the ambient documentation downstream-useful for PA, rather than just generating a note that looks good but doesn't capture what the payer is going to need.
PHI in Transit and Storage: The Integration Security Considerations
Any EHR integration that involves ambient documentation is, by definition, transmitting protected health information from the EHR to an external system and back. The security requirements for that data transit are non-negotiable: TLS 1.2 or higher for all data in transit, encrypted storage for any PHI that persists in the ambient system's infrastructure, and a signed Business Associate Agreement (BAA) between the practice and the ambient documentation vendor.
Beyond the BAA, audit logging of data access is important from a HIPAA compliance standpoint. Every FHIR read that pulls patient data should be logged with a timestamp, the user or system that triggered the read, and the resources accessed. Every note write-back should be logged as a PHI-containing transaction. The integration layer isn't just a data pipe — it's a PHI access channel that needs to be audited like any other system touching patient data.
For practices concerned about data residency — particularly practices affiliated with health systems that have strict data governance policies — it's worth asking specifically where the ambient documentation system processes audio and generates notes, whether any audio is retained after transcription, and whether generated notes are stored on the vendor's infrastructure or only on the EHR-side after write-back. Different vendors handle these questions differently, and the answers matter for compliance review.
What a Clean Integration Actually Requires
A well-functioning ambient documentation integration in a specialty practice looks like this: the physician opens the day's schedule in the EHR; the ambient system has already pulled encounter context for each patient; during the encounter, note generation happens; within minutes of the encounter ending, the structured note is in the physician's review queue in the EHR; the physician reviews, edits minimally, and signs; the signed note is the source of record for any subsequent PA submission.
Getting there requires upfront integration work — typically 2 to 6 weeks depending on EHR complexity and IT resource availability — but it's not a years-long project. The standards exist. The APIs are available. The biggest variables are the specific EHR's integration surface area and the practice's IT coordination capacity. Start by identifying whether your EHR IT team will support the integration or whether the ambient vendor's team leads it. That organizational question usually determines timeline more than technical complexity.