Will the ambient scribe actually work with our EHR? Six questions to ask any vendor

Every ambient scribe demo ends the same way. The note appears on screen, it is good, the room nods, and then someone from IT asks the only question that decides whether the product ever ships: how does that note get into the EHR?

What happens in the next thirty seconds tells you most of what you need to know about the vendor. If the answer involves a clinician copying text out of one window and pasting it into another, you have not bought an integration. You have bought a new chore. The whole reason ambient documentation exists is that physicians already spend nearly two hours on EHR and desk work for every hour of direct patient care, by the American Medical Association backed time-and-motion study published in Annals of Internal Medicine. A scribe that adds a copy-paste step is paying down that debt with one hand and running it back up with the other.

So here is an evaluation lens: what “works with your EHR” should actually mean, and the questions that separate a real integration from a demo. Use them on every vendor, including us.

“Integration” is two different claims

When a vendor says they integrate with your EHR, they may mean one of two very different things, and it is worth forcing them to say which.

Reading means the product pulls patient context out of the chart before the visit: who the patient is, the active problem list, the care team, the day’s appointments. Reading makes the note better, because the AI is not starting from a blank page.

Write-back means the finished, clinician-approved encounter goes back into the chart without anyone retyping it. Write-back is where the time savings actually live, and it is the harder half. Plenty of products read. Far fewer write back, and fewer still write back structured data rather than a blob of text.

A vendor who is vague about which half they do is usually telling you the answer.

Standards beat brittle interfaces

The second thing to pin down is how the connection is built. For years, EHR connectivity meant custom point-to-point interfaces: bespoke feeds, site-specific mappings, occasionally outright screen-scraping. Those interfaces work until the EHR upgrades, and then someone gets paged.

There is now a better default. Under the 21st Century Cures Act, ONC-certified EHRs have been required to expose a standardized HL7 FHIR R4 API since the end of 2022. FHIR R4 gives every system a shared vocabulary, a Patient resource, an Encounter, a coded Condition, instead of a pile of one-off translations. An integration built on that standard survives upgrades, transfers across vendors, and can be inspected rather than taken on faith.

A custom interface built just for your site is not a feature. It is a liability with a maintenance contract.

Where the clinician sits in the write-back path

One more thing to check before the questions: what stands between the AI and your legal medical record. Our answer, and the answer you should require from anyone, is the clinician. Nothing posts to the chart until the treating clinician has reviewed and approved it. Write-back automates the transport of the note, never the authorship of it. The note stays a byproduct of the visit, and the clinician remains its author of record.

If a vendor’s architecture allows an unreviewed note to reach the chart, that is not efficiency. That is a documentation-integrity problem waiting for an audit.

The six questions

Put these to every vendor, in writing if you can.

1. Do you read from the chart before the visit, or only write after it? Ask which FHIR resources they pull. (Ours: Patient, Encounter, Condition, CareTeam, Appointment, Practitioner.)
2. Is the connection standards-based or custom-built for us? If it is FHIR R4, say so plainly. If it is a bespoke interface, who maintains it when the EHR upgrades, and on whose budget?
3. What exactly do you write back? Free text pasted into a notes field is the floor. The ceiling is discrete, coded resources (the encounter, coded diagnoses as Conditions, orders as ServiceRequests, the note as a DocumentReference), which is also what makes downstream coding accuracy possible instead of aspirational.
4. Is coded write-back live in production for our specific EHR today? Not “supported”, not “on the roadmap”. Live, for your system, now. Ask for per-EHR status. Most vendors will not volunteer this distinction.
5. How is the connection authenticated, and where does PHI live? Look for the SMART backend-services OAuth flow rather than shared passwords, a signed BAA, US data residency, and encryption in transit and at rest.
6. Can a note reach the chart without a clinician approving it? The only acceptable answer is no.

Our own answers, including the uncomfortable one

Question 4 is the one vendors duck, so here is our answer first. Pinotage Health connects to the EHR through our Redox partnership over HL7 FHIR R4. Epic, Oracle Health (Cerner), athenahealth, MEDITECH, Veradigm, eClinicalWorks, and NextGen are all reachable through that connection. Document and encounter write-back works in our integration sandbox today. Production coded write-back is rolling out and being validated per-EHR, which means that depending on your system, it may not be live for you on day one. If it is not, we will tell you that before you sign anything, along with where your EHR sits in the rollout.

We would rather state that plainly than let a demo imply something the contract cannot deliver. You should hold every vendor, us included, to the same standard.

The takeaway

“Works with your EHR” is a claim with parts: read versus write-back, standard versus bespoke, text versus coded data, and a clinician’s approval standing in front of the chart. Six direct questions will get you the real shape of any vendor’s integration in a single meeting.

If you want to see ours in detail (the resources we read, what we write back, and how the connection is secured), start at the interoperability section of our platform page, or talk to us and ask us question 4 yourself.