Telemedicine EHR integration is the set of connections that lets a virtual care product work inside a provider's electronic health record: the clinician opens the visit from the EHR schedule, sees the chart in context, and the signed note lands back in the record without retyping.
This guide covers each touchpoint a virtual visit needs, how launch and schedule sync are built, which write-back path suits a note or a charge, the federal rules that limit the options, and what breaks when a product moves from its first EHR to its second.
What is telemedicine EHR integration?
Connecting a telehealth product to EHRs?
Agnotic builds telehealth EHR integration for the client, from SMART on FHIR launch and schedule sync to acknowledged note write-back.
Telemedicine EHR integration connects a video or messaging care product to the provider's EHR so that appointments, patient context and visit documentation move between them. It usually combines a SMART on FHIR launch for context, a scheduling feed or API, and a write-back path for notes and charges through vendor APIs or HL7 v2 interfaces.
The integration is what decides whether clinicians accept the product. A video room that needs a second login, a manual patient search and a copy-and-paste note adds work to every visit, however good the call quality is.
Each EHR exposes these functions differently, and each health system decides which ones to switch on. A telemedicine product therefore needs one integration design with a per-site configuration, not one custom build per customer.
Which EHR touchpoints does a virtual visit need?
A virtual visit touches the EHR at five points, and each point has its own interface choice. Listing them per customer before any build shows the real scope.
- Patient identity: The product must resolve its patient to the EHR's patient record, using the identifier passed at launch or a demographic match through a FHIR Patient search. A wrong match files a note in the wrong chart.
- Scheduling: Telehealth appointments are created in the EHR, in the product, or in both. One side must own the slot, and the other must receive bookings, reschedules and cancellations.
- Launch and context: The clinician opens the visit from the EHR schedule or chart, and the product receives the patient, the encounter and the user without a second search.
- Documentation: The signed note, and any discrete data such as vitals the patient reported, goes back to the chart as a document or as structured results.
- Orders and charges: Prescriptions, lab orders and the charge for the visit leave either through the EHR's own ordering screens or through interfaces the site has approved.
Not every customer needs all five on day one. A common first release launches from the EHR and files a note, while scheduling stays in the EHR and the clinician places orders there after the call.
How should the clinician open the visit?
The clinician should open the visit from inside the EHR with a SMART on FHIR EHR launch wherever the site allows it. In the HL7 SMART App Launch guide, the EHR starts the app with a launch parameter and the address of its FHIR server, and the app exchanges them for an access token tied to the current patient and user.
SMART also defines a standalone launch, where the app starts on its own and asks the authorization server for patient context through scopes such as launch/patient. Patient-facing telehealth apps often use this pattern from a portal link or a text reminder.
- EHR launch from the schedule: The clinician clicks the appointment, the app receives patient and encounter context, and the video room opens beside the chart. This removes most patient-matching risk.
- EHR launch from the chart: Useful for unscheduled follow-ups, but the app must create or find the encounter itself, since none came with the launch.
- Standalone clinician login: Works for networks of independent clinicians with no shared EHR, but every visit needs a patient search and a match check.
- Deep link with a signed token: Some sites put a link to the visit in the appointment record. The token must be short-lived and single-use, because links end up in emails and screenshots.
Launch is also where user identity is settled. Map the EHR user to the product's clinician record once, and log the mapping, because the audit trail for every later note depends on it.
Keeping telehealth schedules in sync
Schedule sync works when one system owns each appointment and the other only listens. Two-way editing without an owner produces double bookings and orphaned video rooms.
When the EHR owns the schedule, the usual feed is HL7 v2 scheduling messages: SIU^S12 for a new booking, S13 for a reschedule, S14 for a modification and S15 for a cancellation. The product opens or closes a video room for each message and stores the EHR appointment ID as its key.
When the product owns booking, for example in an on-demand queue, it must write appointments into the EHR through the vendor's scheduling API, where the vendor offers one. Each site then decides which provider schedules and visit types an outside app may book into, and that list belongs in the site configuration.
Visit type mapping is the detail teams underestimate. A telehealth slot in the EHR carries a department, a provider, a visit type and often a modality. If the product cannot read those fields, it cannot tell a video follow-up from an in-person new patient visit.
Store the video link where clinicians and front-desk staff already look. Some sites put it in an appointment note field; others want it only in the product, reached through launch. Agree on one place per site, because a stale link in appointment notes sends patients to a room that no longer exists.
Which write-back path fits the visit note?
The write-back path depends on what the EHR vendor and the site support, because the certified FHIR API cannot file a note. Under 45 CFR 170.315(g)(10), certified EHRs offer a standardized API for patient and population services, and that API is for reading data.
Writing therefore goes through a vendor FHIR write API, an HL7 v2 interface or a vendor-specific web service. This decision list matches each kind of data to its usual route.
- Vendor FHIR document write: Epic's open.epic catalog lists DocumentReference.Create (Clinical Notes) (R4). Oracle Health documents a POST /DocumentReference operation for Millennium FHIR R4 that takes the note as base64 content in text/plain, text/html or application/pdf. Choose this when the site has enabled it for your app.
- HL7 v2 document message: An MDM^T02 message carries a new document with its content, and other T events cover status changes, addenda and replacements. Choose this when the site's interface team already runs inbound transcription feeds through its engine.
- Discrete results: Patient-reported vitals and device readings can file as structured results through an ORU^R01 feed or a vendor write API, so they trend in flowsheets instead of sitting inside note text.
- Charges: A DFT^P03 message or the EHR's own charge entry posts the visit charge. Many sites prefer the clinician to drop the charge in the EHR, which keeps coding inside their existing review.
Every route needs a confirmation. With HL7 v2, the receiving system returns an ACK, and only an accept code should close the visit in the product. With FHIR, a successful create returns the new resource ID, which the product stores against its own encounter.
Vendor write rules also shape the signing step. Oracle Health's documentation says that for provider-authorized access the document status must be final and the single author must be the authorized provider, so the clinician who signs in the product must be the user the token belongs to.
What should be agreed with each site before the build?
Agree the integration scope with each site's EHR and interface teams in writing before any code is written. This checklist covers the items that otherwise surface during go-live week.
- Enabled operations: Which launch types, read scopes and write operations the site will switch on for the app, and who approves changes later.
- Note destination: The document type, note template and department the visit note should file under, plus how addenda and corrections are handled.
- Interface route: Whether writes go straight to the EHR's API or through the site's interface engine, and which engine channel owns them.
- Test environment: A non-production EHR with test patients, test providers and the same visit types as production, plus a named contact who can reset it.
- User provisioning: How clinicians get access to the app, how EHR user IDs map to app accounts, and what happens when a clinician leaves.
- Audit and logging: Which events the site expects the product to log, such as launches, note submissions and failed write-backs, and how long logs are kept.
- Downtime plan: What clinicians do when the EHR or the interface is down during a visit, and how queued notes are released afterwards.
Carry modality and patient location in the data sent to the EHR as well. Telehealth coverage and billing rules change by payer and by date, and the site can only apply the rule in force if those fields arrive with the visit.
What breaks when the second EHR is added?
Most failures appear when a product built against one EHR goes live on another. This failure-point list covers the gaps to test before the second site.
- Hard-coded identifiers: Patient, encounter and provider IDs arrive in different formats and namespaces. Store the issuer with every external ID.
- One note format: A note that files cleanly as plain text in one system may need a specific document type code or a PDF in another. Keep note rendering separate from the transport.
- Assumed write access: An API listed in a vendor catalog is not switched on at every site. Confirm per customer which write operations are enabled before promising the feature.
- Missing acknowledgments: An interface queue that backs up returns no error to the product. Track every submission until an ACK or resource ID arrives, and alert on age.
- Time zones: Appointments are sent in site local time, stored in UTC and shown in the patient's zone. A visit that shifts by an hour after a daylight saving change is a scheduling bug, not a user error.
- Duplicate rooms: A reschedule sent as a cancellation plus a new booking can leave two video rooms, with the patient waiting in the old one.
- Stale user mappings: When a clinician gets a new EHR user ID, notes can fail authorship checks. Re-validate the user mapping on each launch.
Teams that keep a per-site configuration record, covering endpoints, enabled operations, note types and message variants, usually add the next EHR as a setup task rather than a new project.
How Agnotic can help
A telemedicine product earns its place in a clinic when visits open from the EHR and notes file back without retyping. Agnotic Technologies builds that connection for telehealth companies and provider groups: SMART on FHIR launch, schedule sync from SIU feeds or vendor booking APIs, and note and result write-back with acknowledgment tracking.
Agnotic designs one integration layer with per-site configuration, so adding an Epic, Oracle Health (Cerner) or athenahealth site means mapping endpoints and note types rather than writing a new interface each time.
Plan your telehealth EHR integration with Agnotic
Explore telehealth EHR integration, or browse more articles in our Telehealth hub.
Related reading on Agnotic
Continue with telemedicine platform architecture, telemedicine software, telemedicine requirements, telemedicine in Florida and Epic SMART on FHIR integration.
