The EHR does 80 percent, and people copy the rest
Your EHR holds the record well. The work around it, typing the same demographics three times, faxing a referral, filing a result by hand, is the other 20 percent, and it's still yours.
The short version
5 things that decide this
- 01Your EHR is good at what it was built for: the clinical record. It's not the source of the manual work eating your front desk and billing team's day.
- 02Demographics get typed three times, intake forms get re-keyed, eligibility gets checked by portal, referrals get faxed, and lab results get filed one at a time. None of those flows were ever your EHR's job.
- 03A vendor's '60+ integrations' logo wall describes coverage, not depth. It doesn't say what a real connection does, or where it stops.
- 04What closes the gap: FHIR or HL7 where your EHR exposes it, a vendor API where it doesn't, and a reviewed queue where neither exists, all feeding back into the chart with a clinician's sign-off.
- 05The best available randomised trial on ambient AI scribes found 41 seconds saved per note, real but modest (Lukac et al., NEJM AI, 2025). Charting was never the whole problem, just the visible part.
What actually happens around every EHR
A new patient fills out an intake form on paper or a tablet, and hands you their name, date of birth, address and insurance details. Your front desk types that into the EHR. Your billing team types the same insurance details into the clearinghouse portal to check eligibility. Somewhere along the way, someone types it again into a spreadsheet used for outreach or reporting. The patient wrote it once. Your staff typed it three times, and nothing guaranteed those three copies still matched by the end of the week.
That's the pattern, and it repeats everywhere your EHR touches something outside itself. A referral goes out by fax, because the receiving practice's system doesn't talk to yours. Someone confirms it arrived by phone the next day. A lab result comes back as a PDF and gets filed into the chart by hand, one document at a time, whenever staff have a free ten minutes. None of this is your EHR failing at its actual job. It's the work sitting at the seams, between systems that were never asked to cooperate.
- 01Demographics: typed into the EHR, then again into the clearinghouse, then again wherever reporting lives.
- 02Intake forms: collected on paper or a tablet, re-keyed by staff instead of landing in the chart directly.
- 03Eligibility: checked by logging into a payer portal one patient at a time.
- 04Referrals: faxed, then confirmed by a phone call the next day.
- 05Lab results: filed into the chart individually, whenever someone has a free minute.
"60+ integrations" is a claim about coverage, not depth
Almost every integration vendor selling into healthcare shows you a wall of logos: Epic, athenahealth, eClinicalWorks, Dentrix, dozens more, all listed as connected. None of them explain what one of those connections actually does. Does it read appointment data, or write it back? Does it pull your demographics once at intake, or keep them synced as they change? Does it touch orders, referrals or a prior-auth packet, or stop at scheduling? The logo wall answers none of that. "Connected" covers everything from a full bidirectional sync to a nightly export nobody checks.
That gap is exactly where the manual re-entry survives. You buy a tool that claims Epic integration, and it turns out to sync appointment slots and nothing else. Your demographics still get typed by hand, because the integration the sales page promised was never scoped to touch them.
What actually closes the gap
Where your EHR exposes a FHIR or HL7 interface, that's the cleanest path. Structured data moves in a format both systems understand, and nobody retypes anything. Epic's App Orchard, athenahealth's Marketplace and similar programs give you access to this. Getting listed and approved is its own process, though, with review timelines and a BAA chain that has to cover every party before your patient data moves through it.
Where a standard interface doesn't exist, a vendor API usually does, even if it's narrower than FHIR. It's often enough to write an appointment, pull a patient record, or post a result. Where neither exists, a reviewed queue is the honest fallback, not full automation dressed up to look effortless. A document, a form or a result lands in the queue, gets matched to the right chart, and waits for a person to confirm before it's filed. That's slower than a real integration. It's still faster and more accurate than the fax-and-call pattern it replaces, and every entry lands in the chart with a sign-off, never silently.
- FHIR or HL7The cleanest path, where your EHR's access model actually exposes it
- Vendor APINarrower than FHIR, but real, where a standard interface doesn't exist
- Reviewed queueFor everything neither reaches: matched to the chart, confirmed by a person
- Sign-offNothing files into the record without a clinician or staff member confirming it
The depth of any of these three depends on what your account and your EHR vendor actually expose. We confirm that during the audit rather than promising a level of access before we've seen it.
Even the note-taking part only closes part of the gap
Ambient scribes get sold to you as the fix for documentation burden, and they do help with the note itself. The best available evidence is a 238-physician randomised trial, where the better of two ambient scribes tested saved 41 seconds per note against a control group with no scribe (Lukac et al., NEJM AI, 2025). Real, and worth having. It's also small, next to the hours your practice spends on everything else this piece has covered: the demographics, the eligibility checks, the referrals, the results filing. A scribe drafts a note. It doesn't touch any of the rest, which is why documentation and integration are two different problems that happen to sit next to each other.
Some of the systems we have shipped
Related questions
01Do we need to replace our EHR to fix this?+
No. The value comes from connecting what you already run, through FHIR, HL7 or an API, or a reviewed queue where neither exists. Replacing a working EHR rarely earns back what the switch costs a practice in disruption.
02How deep can an integration actually go with our specific EHR?+
Your account's access model decides it, and that varies even between two practices on the same EHR. We confirm the real depth during the audit rather than promising a level of access before we've seen your setup.
03Is FHIR always available?+
No. Many EHRs expose FHIR or HL7 for some data and not others, and some smaller or older systems expose very little. That's exactly why a vendor API and a reviewed queue both matter as fallback paths.
04What stays a manual decision even after this is built?+
Anything clinical. The system moves data, matches it to the right chart, and drafts documents for review. A clinician or staff member still confirms what actually enters the record.
