A telehealth platform needs four integration points with the EHR, and the video call is not one of them. Scheduling has to stay in sync so a virtual visit appears on the same calendar as an in-person one and does not double-book a clinician. Clinical context has to flow into the visit, so the provider opens the call already seeing the problem list, medications and recent results. Documentation has to flow back out, which is the hard part: the note, any orders and the visit record all belong in the chart, and writing into the chart is a governed path rather than an API call. Finally, billing data has to reach the revenue cycle with the right place-of-service and modifier coding. A telehealth product that skips the write-back leg does not merely lose convenience — it creates a second parallel medical record, which is a compliance problem rather than a feature gap.
The Video Call Is the Easy Part
Let me reframe this immediately, because it’s what separates this post from every telehealth feature-list article you’ve already read: the video layer is a commodity. WebRTC infrastructure is bought, not built, and priced per minute or per participant. Where a telehealth product actually lives or dies is everything around the call — and that’s what the rest of this post covers.
The Four Integration Points
Every real telehealth-EHR integration comes down to the same four points, and I’ll go through each below: scheduling sync, clinical context into the visit, documentation back out of it, and billing.
Scheduling Sync
A virtual visit has to live on the same calendar as an in-person one, or you get double-booking and a scheduling team maintaining two systems by hand. This runs over HL7 v2 SIU messages in older estates or FHIR’s Appointment, Schedule and Slot resources in a modern one — the choice follows the same event-driven-vs-request-driven logic I go through in FHIR vs. HL7 v2. Cancellations and provider-availability changes need to propagate both directions, not just one.
Getting Clinical Context Into the Visit
A provider opening a telehealth call cold, with no chart context loaded, is working at a real disadvantage compared to walking into an exam room with the chart already open. The problem list, current medications, allergies and recent results need to be pulled in before or as the visit starts — which, if you’re embedding directly in the EHR’s own interface rather than building a fully separate platform, is exactly the SMART on FHIR launch pattern I cover in embedding an app in the chart.
Getting Documentation Back Into the Chart
This is the hard part, and it’s the part most telehealth vendors underbuild. The visit note, any orders generated during the call, and the encounter record itself all belong in the patient’s actual chart — and writing into the chart is a governed process, not a simple API call, exactly as I cover in how Epic write-back integration actually works. That governance review doesn’t disappear because the visit happened over video instead of in person.
Here’s the argument I want to make plainly, because it’s more persuasive than a feature list: a telehealth platform that skips this write-back leg isn’t losing a convenience feature. It’s creating a second, parallel medical record that other providers can’t see — and depending on how PHI moves through the platform, that’s a clinical continuity and compliance problem, not a missing checkbox.
Billing and Place-of-Service Coding
Telehealth billing has genuinely tightened, and stale assumptions here will produce real claim denials. As of March 2026, CMS made POS 10 (patient at home) mandatory for most Medicare telehealth claims, and using POS 02 (patient anywhere else) when the patient was actually at home now triggers automatic denials from most payers. The two codes reimburse at different rates — POS 10 at the non-facility rate, POS 02 at the facility rate, a gap that can run 10% to 25% per claim — and critically, it’s the patient’s location that determines the code, not the provider’s. Congress has extended most Medicare telehealth flexibilities through December 31, 2027, but CMS has simultaneously tightened exactly how the codes, place-of-service designations and modifiers have to be applied. If your product touches Medicare telehealth billing, verify current CMS guidance directly before assuming any of this is stable — it has changed repeatedly and will likely change again.
Build vs. Embed vs. Buy
Three real architecture options, and none is automatically right: a standalone platform your patients and providers use separately from the EHR, a SMART-embedded app that lives inside the EHR’s own interface, or an EHR’s native telehealth module if the platform already has one. The honest trade-off is between control and integration depth versus speed to launch — a standalone platform ships faster but owns the full integration burden across all four points above; embedding gets you native context and write-back more naturally but ties you to that EHR’s governance and registration process.
Next Steps
With telehealth utilization climbing 10.1% quarter-over-quarter into Q1 2026 and mental health now representing over half of all telehealth claims nationally, this isn’t a shrinking category to under-invest in. If you’re scoping a telehealth build, our telehealth app development team has built the harder half of this — the EHR integration, not the video call — more than once. Talk to us before you architect around the video layer as though it’s the whole project.