EHR Integration Without the Six-Month Surprise
What connecting to an EHR actually involves, which integrations are straightforward, and the questions to ask before you commit to a timeline.
"Does it integrate with our EHR?" is the question that most often gets a confident yes and then quietly consumes a quarter.
The honest answer is: it depends enormously on which EHR, what you need to move, and in which direction. Those three things separate a two-week integration from a six-month one.
What "integration" usually means
Before scoping anything, get specific about which of these you actually need. They are wildly different amounts of work.
Push a new patient record in. Someone completes intake on your site, a record appears in the EHR. Usually the easiest, and often enough on its own.
Pull availability out. Provider schedules live in the EHR and your booking flow needs to respect them. Moderate, and gets harder if the EHR was not designed to expose it.
Two-way sync. Changes in either system reflect in the other. This is where cost jumps, because now you own conflict resolution: what happens when both sides changed the same record?
Clinical documentation. Notes, orders, results. Hardest, most regulated, and the place to be most conservative.
Most telehealth companies genuinely need the first one and think they need the third.
The FHIR situation, honestly
Modern EHRs increasingly support FHIR, a standard API for health data. US regulation has pushed hard on this, and it is genuinely better than what came before.
What FHIR gives you: a common vocabulary, predictable resource shapes, and documentation that mostly exists.
What FHIR does not give you: uniformity. Vendors implement different subsets, extend it in vendor-specific ways, and vary in what is read-only. Two "FHIR-compatible" systems can still need meaningfully different code.
Treat FHIR support as a good sign that shortens the work, not a guarantee that it is plug-and-play.
The rough tiers
Without naming names, integrations tend to fall into three groups.
Modern, API-first platforms. Built recently, documented APIs, sandbox access you can get in a day, sensible webhooks. Integration measured in weeks.
Large established EHRs with app programs. Real APIs and real capability, wrapped in a partner program. The engineering is manageable; the timeline is driven by their approval process, which can take months and carries its own requirements. The paperwork is the critical path, not the code.
Legacy and on-premise systems. Limited or no API. Integration might mean flat file exchange, an HL7 interface engine, or a database-level connection. Feasible, slow, and dependent on their IT team's cooperation.
The dangerous one is the middle tier, because the engineering estimate is accurate and the calendar estimate is wrong by a factor of three.
Questions to ask before you commit
Ask your EHR vendor, in writing:
- Is there a sandbox, and how long does access take?
- Which FHIR resources are supported, and which are read-only?
- Is there an approval or partner process, and what is the realistic timeline?
- Are there API costs — per call, per patient, or a platform fee?
- What are the rate limits?
- Will you sign a BAA, and what does it cover?
Question 3 has sunk more project timelines than anything technical. Question 4 catches the case where the integration works and then costs more per month than the tool it is feeding.
Design for the integration failing
The EHR will be unavailable sometimes. Maintenance windows, rate limits, an expired credential nobody noticed.
The wrong response is losing the patient's data. If intake completes and the EHR push fails, that patient must not disappear.
The pattern that works:
- Write locally first, then sync. Your system is the source of truth for its own data.
- Queue the sync and retry with backoff.
- Alert a human after repeated failures, rather than retrying silently forever.
- Make it replayable, so when the connection returns, the backlog clears without manual re-entry.
This is not exotic engineering, but it is frequently skipped in the first version and painful to add once you have live patients.
Don't sync everything
The instinct is to mirror everything into both systems. Resist it.
Every synced field is a field that can conflict, drift, and generate a support ticket about which system is right.
Decide, per field, which system owns it. Scheduling might be owned by the EHR. Marketing preferences owned by yours. Then sync deliberately in one direction wherever possible, and only go two-way where the business genuinely requires it.
One-directional sync eliminates conflict resolution entirely, and conflict resolution is where the long tail of bugs lives.
Data mapping is the unglamorous majority of the work
The API is rarely the hard part. The hard part is that your intake asks a question one way and the EHR expects it another.
Free-text medication names have to map to coded values. Your custom questions have no obvious destination. Their required field is something you never collect. Dates, units, and code systems all need translation.
Budget real time for this, and get a clinician to review the mapping. An engineer guessing at clinical field semantics is how bad data gets in.
A realistic sequence
- Scope precisely. Which direction, which data, which system owns what.
- Get sandbox access early, before committing to any timeline. This alone reveals which tier you are in.
- Build one direction first. Usually pushing patients in.
- Run it in parallel. New records go both ways, staff verifies, for a couple of weeks.
- Add the second direction only if you actually need it.
And if a vendor tells you they can integrate with any EHR in two weeks without having seen the documentation, that is worth pausing on. Send them the docs and see whether the answer changes.
We build telehealth platforms and integrate them with the systems you already run — after reading the documentation, not before. See how we work.