A telehealth platform that cannot talk to the EHR is a data island. The video call happens, notes get written, maybe a prescription is sent, and then someone re-keys it all into the patient's record by hand. That is how virtual care becomes a parallel system instead of part of the chart. The fix is integration, and because telehealth vendors use modern web formats while EHRs use HL7 and FHIR, you need something in the middle to translate between them. This guide is about using Mirth Connect to keep a telehealth platform and the EHR in sync, in both directions.
We have built telehealth and virtual-care products, including a production teletherapy platform and EHR integrations for 30+ healthtech startups, so the bidirectional pattern below is one we have shipped, not just sketched.
Telehealth integration is bidirectional
The thing to internalize first is that data has to move both ways. Into the EHR, you send what the virtual visit generates: an appointment when a patient books, registration details from intake, and after the visit, the clinical note, any orders, and charges. Back to the telehealth platform, you pull what the clinician needs to deliver good care, the patient's demographics, problem list, medications, allergies, and recent results, so the provider is not flying blind on a video call.
Telehealth vendors typically expose their side as JSON over REST or webhooks. The EHR side speaks HL7 v2 messages, ADT for registration, SIU for scheduling, ORU for results, MDM for documents, and increasingly FHIR R4 resources. Bridging those two languages is the core of the job. If the EHR formats are unfamiliar, our guide to HL7 and the FHIR R4 specification are useful references.
Why Mirth Connect sits in the middle
You could write bespoke code to translate between your telehealth vendor and the EHR, and many teams do, until the second EHR or the third message type turns that code into a maintenance burden. Mirth Connect gives you a translation and routing layer built for exactly this.
- Format translation. A common real-world pattern is receiving patient registration as JSON from the telehealth platform via a webhook and transforming it into an HL7 ADT message the EHR accepts. Mirth does this kind of conversion as a channel, not a custom service.
- Scheduling sync. SIU messages keep appointment data aligned between the telehealth platform, the EHR, and any other scheduling tool, so a booked virtual visit shows up everywhere it should.
- Clinical context on demand. Mirth can pull demographics, problems, and results from the EHR and deliver them to the telehealth app in the shape it expects.
- Reliability. Logging, retries, and replay mean a momentary outage on either side does not drop a booking or a note.
If the engine is new to you, start with our complete guide to Mirth Connect and the architecture and deployment guide, and the same engine connects to any EHR behind the platform, as our Cerner integration guide shows.
What flows each way
Laid out side by side, the two directions have distinct triggers and needs. Into the EHR, the trigger is a booking or intake event, the data is an appointment and patient, it arrives as webhook JSON, and Mirth translates it into SIU and ADT messages, with patient matching as the critical step. Back to the platform, the trigger is an order, result, or record update, the data is results and demographics in HL7 or FHIR, and Mirth maps it into app-ready JSON so the clinician has fresh context. One engine owns both directions, which is what keeps the virtual visit tied to the record. The real-time registration mechanics are covered in our ADT event processing guide.
The architecture
The shape is a small set of bidirectional Mirth channels between the telehealth platform and the EHR. On the inbound side, a source connector receives a webhook from the platform, a filter validates it, a transformer converts the JSON to the right HL7 or FHIR structure and matches the patient, and a destination connector posts it to the EHR. On the outbound side, a channel pulls or receives clinical data from the EHR, reshapes it to the platform's API, and delivers it. The video and audio of the visit itself stay with the telehealth platform, which is built for real-time media; Mirth handles the data, which is what needs to reach the record.
Patient matching is the linchpin. A booking from the telehealth platform has to resolve to the correct patient in the EHR, or you create duplicates and orphaned records. Our HL7 v2 to FHIR R4 mapping guide covers the field-level mapping, and consistent channel design patterns keep the inbound and outbound channels organized as the platform grows.
Post-visit data: closing the loop
The part teams forget is what happens after the call ends. A complete telehealth integration sends the visit note back to the EHR as an MDM document or a FHIR DocumentReference, so the encounter is part of the legal record, not stranded in the telehealth app. Orders placed during the visit flow as ORM messages, and charges flow as DFT so the visit gets billed. Closing this loop is what makes a virtual visit indistinguishable from an in-person one as far as the record is concerned, and it is usually the difference between a telehealth product that clinicians tolerate and one they trust. Building this on a solid foundation matters; our guide to a HIPAA-compliant telehealth platform architecture covers the broader system around these flows.
Reliability and the failure modes that matter
A few specific failures hurt telehealth integrations, and each is addressable in the engine. Duplicate patients arise when a booking does not match an existing record, so invest in matching logic before anything else. Lost bookings or notes are unacceptable, so every channel needs a dead-letter and replay path, which our guide to message replay and dead letter queues details. Timing gaps, where a clinician opens a visit before the EHR context has arrived, are eased by pulling context ahead of the scheduled time rather than at the moment the call starts. Plan for these, and the platform feels seamless to both patient and provider.
A scheduling sync example, end-to-end
Scheduling is usually the first flow teams build, because it is where the two systems most obviously need to agree. Picture a patient booking a virtual visit in the telehealth app. The platform fires a webhook with the appointment and patient details as JSON. A Mirth channel receives it, validates the payload, and resolves the patient against the EHR, creating the record if this is a new patient or matching an existing one. It then builds an SIU scheduling message and, if needed, an ADT registration message, and posts them to the EHR, so the visit appears on the clinician's schedule alongside in-person appointments.
The reverse direction matters just as much. When the EHR is the source of truth for a clinician's calendar, changes there, a cancellation, a reschedule, a room or provider change, need to flow back to the telehealth platform so the patient sees accurate information. Running both directions through the same engine, with a clear rule for which system wins in a conflict, is what keeps the two calendars from drifting apart. Without that discipline, you get the classic failure where a patient shows up for a visit the clinician's schedule no longer shows.
A realistic rollout
Sequencing keeps the telehealth integration low-risk. Begin with one-way scheduling, pushing bookings into the EHR, and confirm patient matching is solid before anything else, since matching errors are the most damaging and the hardest to unwind later. Add the return path for schedule changes once the inbound side is trusted. Then layer in clinical context to the platform, demographics, and recent results first, followed by problems and medications. Finally, close the post-visit loop with notes, orders, and charges back to the EHR. Each phase is independently useful, so the platform is never waiting on a single big launch.
Run each new channel in parallel with whatever manual step it replaces until staff trusts it, and instrument everything: track bookings posted, context delivered, and any messages that fail and get replayed. Because telehealth volume can spike, for example, around a new service line or a seasonal surge, design the channels to queue and retry rather than buckle under load, the same discipline that keeps any busy Mirth deployment healthy.
Security and compliance
Telehealth integration handles Protected Health Information, so a Business Associate Agreement is required. The data layer uses OAuth 2.0 and SMART on FHIR scopes where FHIR is involved, and secured connections for HL7 v2; the platform remains responsible for securing the video session itself. We sign BAAs with US health systems and digital health customers, and we build on HIPAA-compliant, SOC 2 Type II, and ISO 27001 certified infrastructure with FHIR R4 native architecture.
This content describes engineering patterns. It does not include actual Protected Health Information. All data examples are synthetic.
How Nirmitee.io approaches telehealth work
Healthcare is the only industry we serve, and virtual care is an area we have shipped in. We built SayHey, a mental health teletherapy platform that runs in production, and AffEx Health with a consultation flow and patient dashboard, so the bidirectional sync between a virtual-care app and clinical systems is familiar territory. Our architecture is FHIR R4 native, which makes the clinical-context direction straightforward, and we treat the post-visit loop, notes, orders, and charges back to the EHR, as part of the job rather than an afterthought. For the platform side specifically, our work on mental health telemedicine platforms goes deeper.
Connect the telehealth platform and the EHR in both directions, get patient matching right, and close the post-visit loop so virtual care lives in the record. If you want a second set of eyes on a telehealth integration, or want it built, share your use case at nirmitee.io, and we will tell you what we have shipped for similar products.
