AI scribe EHR integration · United States
We connect your AI scribe to Epic, Oracle Health and athenahealth so the note lands in the chart, on the right encounter, as a draft the clinician signs. We pick the write-back path each EHR actually supports, map your sections to the site's note types, stop duplicate notes, and test it all in the vendor sandboxes before a health system's go-live.
Launch from the EHR or read the schedule, so the scribe knows the patient, the encounter and the author before recording starts.
Your scribe drafts the note. The clinician reviews it in your app or in the EHR, depending on what that EHR accepts.
File the note through the path the EHR supports, on the right encounter and note type, exactly once, with every attempt logged.
The short answer
Several do, through different doors. Inside Epic, Epic's own AI Charting (now called Chart with Art) drafts the note, and partner scribes such as Microsoft Dragon Copilot and Abridge work inside Epic: Dragon Copilot records in Haiku or Canto and fills sections of the note in Hyperdrive. Oracle Health has its own Clinical AI Agent, and athenahealth offers Ambient Notes with a choice of engines plus its own athenaAmbient. Any other scribe has to write back through APIs: Epic's FHIR DocumentReference create takes plain text on an existing encounter, Oracle Health's create files final notes only, and athenahealth takes notes through its athenaOne APIs. When FHIR cannot carry the format, an HL7 v2 MDM interface is the fallback. We build that write-back layer for scribe vendors and health systems.
Write-back paths
Each EHR exposes different write paths with different rules. These are the ones we build against, with the detail that decides whether a scribe note passes a health system's review.
| EHR and path | What it accepts | Draft or final | What we design for |
|---|---|---|---|
| Epic: FHIR DocumentReference create (Clinical Notes) | Plain text only (text/plain); only the first attachment is saved; context.encounter is required and must be a clinical encounter that can hold a note | docStatus preliminary for a draft the clinician signs in Epic, or final; notes filed during pre-charting must be preliminary | Section text flattened cleanly to plain text, LOINC or site note types, and encounter lookup before the POST |
| Epic: Incoming MDM (Transcriptions) HL7 v2 interface | Rich text, In Basket routing, notes for encounters created on the fly and fuzzier encounter matching | Set by the interface build at each health system | An interface engine route, a change request with the site's Epic team and a test plan per note type |
| Epic: vendor programs and embedded scribes | Epic AI Charting, plus partner scribes such as Dragon Copilot, which records in Haiku or Canto and fills SmartSections in the Hyperdrive note | Clinician reviews and signs inside Epic | Deciding with the health system whether your product joins a vendor program or writes back through FHIR or MDM |
| Oracle Health: FHIR DocumentReference create | Exactly one content entry, base64 PDF, plain text, RTF, HTML, XML or XHTML; context.period.end required; LOINC or code set 72 type, not both | Final only under provider access; amended also allowed under system access; no preliminary option | Clinician review and sign-off inside your product before the POST, since the note lands final |
| Oracle Health: HL7 v2 document interface | MDM document messages through the site's interface engine | Set by the site's build | The same encounter and note-type rules as the FHIR path, plus acknowledgment handling |
| athenahealth: athenaOne APIs | Encounter notes on an open encounter, found through the chart encounters call, booked appointments or the check-in event; document uploads | Text sections such as the assessment, with a replace flag | Encounter discovery by event, section mapping to athena's note sections and Marketplace onboarding |
| athenahealth: Ambient Notes program and athenaAmbient | Scribe engines selected inside athenaOne; athenaAmbient is athenahealth's own scribe | Clinician reviews inside athenaOne | Whether your product belongs in the program or alongside it through the APIs |
athenahealth's FHIR R4 CapabilityStatement lists DocumentReference read and search, not create, so FHIR write-back is not the path there.
What we build
Pick the workstreams your scribe needs. Each one ships with a specification, sandbox tests and an owner.
SMART on FHIR launch from the chart, or schedule and encounter reads, so recording starts with the right patient, encounter, author and note type already known.
SMART App Launch · Patient · Encounter · Practitioner · Appointment
Epic SMART on FHIR apps →Your sections mapped to each site's note types, LOINC codes and templates, so a progress note files as a progress note and the HPI lands where clinicians look for it.
LOINC 11506-3 · 11488-4 · 34117-2 · site note types
FHIR DocumentReference for clinical notes in Epic, Oracle Health and athenahealth →A lifecycle that matches the EHR: preliminary drafts the clinician signs in Epic, review inside your product before Oracle's final-only create, and amendments that replace the right version.
docStatus · relatesTo · Provenance
HIPAA compliant AI scribe: what it takes to build one →FHIR DocumentReference create, HL7 v2 MDM through an interface engine, or athenaOne APIs, chosen per EHR and per customer, with one internal model so you do not maintain three products.
DocumentReference · MDM^T02 · athenaOne APIs
HL7 integration services →An idempotency key per visit and note, a check before retrying a timed-out write, and a review queue for notes whose encounter cannot be matched with confidence.
Idempotency keys · retry rules · review queue
A record of every write attempt, alerts when a site's interface or token fails, and a runbook your support team and the health system's analysts can both follow.
Audit log · alerts · runbook
Integration monitoring and support →Buyer decisions
Most scribe companies end up with more than one path. The choice depends on the EHR, the customer's build and who signs the note where.
| Option | Best fit | Strengths | What to plan for |
|---|---|---|---|
| The EHR vendor's own scribe | Health systems that want ambient notes with no new vendor | Lives inside the EHR, signed in the same place | Specialty templates, multi-EHR groups and features still on the vendor roadmap |
| Partner scribe embedded in the EHR | Health systems standardizing on one enterprise scribe | In-workflow capture and review inside Epic or athenaOne | Program fit, the site's configuration work and how much of the note you control |
| FHIR write-back | Scribe products serving many sites on certified APIs | Standard resources, one model across Epic and Oracle Health | Plain-text limits in Epic, final-only notes in Oracle Health, no FHIR create in athenahealth |
| HL7 v2 MDM interface | Rich text notes, In Basket routing or sites with an interface team | Mature, flexible, widely supported | An interface engine, a change request per site and longer testing |
| Copy and paste | Pilots and very small practices | No integration work | Errors, lost time and no record of what was filed; not a production answer |
The right path is the one the health system's EHR team will approve. We bring the write-back design to that conversation in the first week.
Integration boundaries
Scribe integration crosses clinical, vendor and legal lines. We write the split down before the build starts.
Reviews and signs every AI-drafted note. We never set a note to final without a clinician action recorded first.
Owns note types, templates, interface builds and go-live approval. We prepare the specification and test evidence they ask for.
Owns its APIs, programs and app review. We build to the published interfaces and the program rules you are accepted into.
Your clinical and legal owners decide how patients are told and how consent is captured; some states require every party to agree before recording. We build the consent step and its record exactly as signed off.
Launch, mapping, write-back, retries, duplicate protection, audit logging and alerts. Defects in this layer are ours to fix.
Visit audio, transcripts and notes are PHI. We sign a BAA, encrypt in transit and at rest, and work inside our ISO 27001:2022 certified management system.
Deliverables
Everything lands in your repository and your runbook.
Path, fields, note types, status rules, encounter matching and sample payloads for Epic, Oracle Health and athenahealth.
Launch, context reads, mapping, write-back and retry logic, with site configuration kept out of the code.
Per-site maps from your sections to note types and templates, with sign-off from each site's analyst.
Recorded runs against vendor sandboxes covering drafts, sign-off, amendments, timeouts, duplicates and unmatched encounters.
The documents a site's EHR and security teams ask for, so each new customer starts from a checklist.
Write-attempt log, failure alerts and a support runbook for each EHR.
Delivery phases
Plan for 8 to 12 weeks to a first live site on one EHR. Sandbox access, the health system's change process and program review set most of that date, so we request them in week one.
Weeks 1 to 2
EHRs and sites listed, write-back path chosen per EHR, sandbox and program access requested
Weeks 2 to 6
Launch, mapping and write-back built and tested against vendor sandboxes
Weeks 5 to 10
Note types mapped with the site's analysts, test patients run, sign-off rules confirmed
Weeks 8 to 12
First clinicians live, monitoring on, runbook handed over, next site scheduled
Cost drivers
You get a fixed scope and price after one scoping call. These are the factors that move it.
Each EHR has its own write path, rules and sandbox testing.
FHIR create is quicker to repeat across sites than an HL7 MDM interface, which needs each site's interface team.
Every note type and specialty template adds mapping and review.
Signing in the EHR or in your product changes the status and amendment logic.
A repeatable onboarding pack matters most when you add many health systems.
Monitoring and on-call support are priced per connection.
Proof
Client names are withheld. The work below is delivered and described without identifying the client.
We build the AI documentation assistant in a behavioral health EHR: consent before recording, bounded transcription, grounded drafts, clinician sign-off and versioned prompts. The engineering lessons are written up in our HIPAA compliant AI scribe guide.
Read the build guide →A voice platform that turns clinical conversations into structured notes for clinicians.
Read the case study →We checked DocumentReference search, renditions and create rules against Epic's and Oracle Health's published specs, live CapabilityStatements and Oracle's public sandbox, and athenahealth's note APIs.
Read the guide →We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.
FAQ
Inside Epic, Epic's own AI Charting (now called Chart with Art) and partner scribes such as Microsoft Dragon Copilot and Abridge work inside Epic's own apps. Oracle Health, the EHR formerly called Cerner, has its own Clinical AI Agent. Other scribes write back through each EHR's APIs or an HL7 interface. Availability depends on each health system's build, so confirm it for your sites.
Yes. Epic's FHIR DocumentReference create files a plain text note to an existing clinical encounter, as a preliminary draft the clinician signs in Epic or as a final note. For rich text, In Basket routing or fuzzier encounter matching, Epic points to its Incoming MDM (Transcriptions) HL7 v2 interface.
Oracle Health documents a FHIR DocumentReference create that accepts one base64 document in PDF, plain text, RTF, HTML or XML. Under provider access the note must be final, so the clinician has to review and sign it in your product before it is sent. An HL7 v2 document interface is the alternative.
Not through FHIR today. athenahealth's R4 CapabilityStatement lists DocumentReference read and search only. Notes go in through the athenaOne APIs on an open encounter, or through athenahealth's Ambient Notes program, which lets practices choose a scribe engine inside athenaOne.
A draft, wherever the EHR allows it. An AI-drafted note should be signed by the clinician, so we file Epic notes as preliminary and keep review inside your product when an EHR only accepts final notes. The note never becomes final without a recorded clinician action.
Each visit and note gets an idempotency key, and a timed-out write is checked before it is retried. The encounter is matched from the launch context or the schedule, and notes that cannot be matched with confidence go to a review queue instead of the chart.
Not always, but it helps. Launching from the chart gives the scribe the patient, encounter and user without a separate login or a guess. Without a launch, we read the schedule and encounters to find the visit.
We run every case in the vendor sandboxes first: drafts, sign-off, amendments, timeouts, duplicates and unmatched encounters. Then we repeat the note types each health system uses in its test environment with its analysts before the first clinician goes live.
Usually, and the rules vary by state. Some states require every party to agree before a conversation is recorded, and Texas requires providers to disclose AI use in care. Your legal team sets the policy; we build the consent step and keep a record of it with the visit.
Plan for 8 to 12 weeks to a first live site on one EHR. Sandbox access, the health system's change process and program review set most of that date. Each additional site on the same EHR is faster because the mappings and tests already exist.
Cost depends on the number of EHRs, the write-back path, the note types and specialties, the review model, how many sites you add each year and the support level. We give a fixed scope and price after one scoping call.
Yes. Visit audio, transcripts and notes are PHI. We sign Business Associate Agreements, encrypt data in transit and at rest, keep audit logs and work inside our ISO 27001:2022 certified management system.
Next step
Tell us your EHRs, your first health system and how clinicians sign today. An engineer replies with the write-back path for each EHR, what the site will ask for and a fixed scope.
Start with your workflow
Share the EHRs you need, your first site and your target date. Use de-identified examples only. Read by an engineer, answered within one business day.
