Written and maintained by CASRAI Editorial Board
Last updated
Telehealth EHR integration is the bidirectional architectural coupling of synchronous audio-video communication, asynchronous store-and-forward messaging, and remote peripheral telemetry with an Electronic Health Record (EHR) system so that scheduling, identity verification, single sign-on (SSO) launch, clinical documentation, e-prescribing, and claim generation operate inside a unified clinical workflow.
Whether a health system is integrating an enterprise virtual care vendor (such as Zoom for Healthcare or healow TeleVisits) or a digital health engineering team is evaluating how to build a telemedicine platform from modular APIs, the reference architecture relies on three foundational standards: HL7 FHIR R4 / US Core FHIR for clinical data exchange, HL7 SMART App Launch for embedded authentication and patient context passing, and WebRTC (RFC 8825) for encrypted real-time media transport.
Telemedicine Platform Architecture: Core Reference Layers
A production-grade telemedicine platform architecture separates real-time media routing from protected health information (PHI) persistence across five decoupled architectural tiers:
- Client Presentation & Peripheral Capture Layer: Browser-based WebRTC clients (HTML5/JavaScript) and native iOS/Android mobile SDKs that capture camera, microphone, screen-share streams, and Bluetooth/USB diagnostic peripherals (digital stethoscopes, otoscopes, blood pressure cuffs).
- Real-Time Media & Signaling Layer (WebRTC STUN/TURN/SFU): A WebSocket signaling server negotiates Session Description Protocol (SDP) offers and Interactive Connectivity Establishment (ICE) candidates. Media packets flow through STUN/TURN relays and a Selective Forwarding Unit (SFU) using mandatory DTLS-SRTP (Datagram Transport Layer Security for Secure Real-Time Transport Protocol) encryption.
- Identity, Access & SMART on FHIR Launch Layer: An OAuth 2.0 / OpenID Connect (OIDC) authorization server that authenticates clinicians (via SAML 2.0 / OIDC enterprise IdP or EHR SMART launch) and patients (via patient portal credentials or tokenized SMS/email magic links with date-of-birth verification).
- Clinical Workflow & Headless EHR / FHIR Server Layer: A FHIR R4 data repository that manages `Schedule`, `Slot`, `Appointment`, `Encounter`, `QuestionnaireResponse`, `Consent`, `Condition`, and `DocumentReference` resources, paired with an e-prescribing module (NCPDP SCRIPT v2017071) and ambient AI documentation APIs.
- EHR Interoperability & Legacy Bridge Layer: A bidirectional integration engine that synchronizes with hospital EHRs (Epic, Oracle Health, MEDITECH, Athenahealth, eClinicalWorks) via RESTful FHIR R4 APIs or legacy HL7 v2 vs FHIR interface messages (`SIU^S12` scheduling, `ADT^A04` registration, and `MDM^T02` clinical document write-back).
Comparison of Telehealth EHR Integration Models
| Integration Pattern | Authentication & Context Mechanism | Scheduling & Video Launch Workflow | Clinical Documentation & Order Write-Back |
|---|---|---|---|
| Standalone (Swivel-Chair) Telehealth | Separate telehealth login; manual patient lookup | Manual link generation sent via SMS/email outside EHR | Clinician copies and pastes notes manually between browser tabs |
| HL7 v2 Interface Bridge (`SIU` / `MDM`) | Tokenized URL written into HL7 `SIU^S12` appointment note | EHR schedule triggers HL7 `SIU^S12` to provision virtual room automatically | Completed visit note or PDF summary pushed back to EHR via `MDM^T02` or `ORU^R01` |
| Native SMART on FHIR Embedded Launch | OAuth 2.0 `launch` scope passes `patient` and `encounter` IDs in EHR iframe | 1-click launch directly inside Epic Hyperspace/Hyperdrive or Oracle PowerChart | Real-time FHIR `Encounter`, `Observation`, and `DocumentReference` write-back inside EHR |
How to Build a Telemedicine Platform and Integrate It with EHRs
Engineering teams researching how to create telemedicine platform infrastructure or building telemedicine platform workflows for clinical trials and virtual care delivery follow a standardized 5-step technical sequence:
1. Provision Slot/Appointment --> FHIR Schedule / Slot / Appointment (or HL7 v2 SIU^S12)
2. Pre-Visit Digital Intake --> FHIR Consent + QuestionnaireResponse + X12 270/271 Eligibility
3. Contextual EHR Launch --> SMART on FHIR OAuth 2.0 (scope: launch/patient openid fhirUser)
4. Encrypted Media Session --> WebRTC SFU (DTLS-SRTP + TURN over TLS 443)
5. Encounter Write-Back --> FHIR Encounter + DocumentReference + Observation (LOINC vitals)Step 1: Scheduling Synchronization (`Appointment` and `SIU^S12`)
When a virtual visit is booked in the EHR or patient portal, the system creates an HL7 FHIR `Appointment` resource (`Appointment.appointmentType` coded for virtual care, and `Appointment.supportingInformation` or an extension storing the unique patient and provider video room URIs) or emits an HL7 v2 `SIU^S12` (New Appointment Booking) message. The telehealth backend provisions an isolated session ID and schedules automated SMS/email check-in notifications.
Step 2: SMART on FHIR Contextual EHR Launch
To prevent clinicians from logging into a separate application or searching for the patient twice, the telehealth application registers as a SMART on FHIR app inside the EHR (such as Epic Showroom / App Orchard or Oracle Health Code Console). When the clinician clicks “Launch Video Visit” inside the EHR chart, the EHR passes an `iss` (FHIR server issuer URL) and a `launch` token. After the OAuth 2.0 handshake completes, the access token payload returns "patient": "Patient/123" and "encounter": "Encounter/456", allowing the telehealth widget to render inside the EHR frame with full chart context.
Step 3: Open-Source Telemedicine Platform vs White-Label Stacks
Organizations evaluating an open-source telemedicine platform (or open source telemedicine platform components) vs commercial white-label telehealth platform APIs typically assemble proven open-source health IT building blocks:
- Headless Open-Source FHIR & EHR Cores: Medplum (open-source TypeScript/PostgreSQL FHIR R4 server with built-in SMART on FHIR auth and React UI components), HAPI FHIR (Java FHIR server), OpenEMR (ONC-certified open-source EHR with integrated telehealth modules), and OpenMRS.
- Open-Source WebRTC Media Servers: LiveKit, Jitsi Videobridge / Jitsi Meet, Mediasoup, and Janus WebRTC Server, paired with coturn for STUN/TURN NAT traversal over TCP/TLS port 443 so corporate hospital firewalls do not block UDP video traffic.
Step 4: Post-Encounter Documentation and Coding Write-Back
When the virtual consultation concludes, the platform updates `Encounter.status = finished`, records actual call duration (`Encounter.period.start` and `Encounter.period.end`) to support time-based CPT coding and telehealth modifiers (POS 02/10, Modifier 95), and writes the signed clinical note back to the host EHR via `POST /DocumentReference` (using LOINC `11488-4` Consultation note or `34117-2` History and physical note) alongside discrete vital signs via `POST /Observation`.
Frequently Asked Questions
How to create a telemedicine platform that integrates with hospital EHRs?
To create a telemedicine platform that integrates with hospital EHRs, decouple the real-time video layer (built on WebRTC with DTLS-SRTP encryption and STUN/TURN/SFU media routing) from the clinical data layer built on an HL7 FHIR R4 server. Implement the HL7 SMART App Launch framework (OAuth 2.0 / OpenID Connect) so clinicians can launch video sessions in-context from Epic or Oracle Health, and map scheduling and clinical notes to FHIR `Appointment`, `Encounter`, `Observation`, and `DocumentReference` resources.
What open-source telemedicine platform options exist for healthcare developers?
Healthcare engineering teams commonly build on Medplum (an open-source FHIR R4 server and developer platform with telehealth starter templates), OpenEMR (an ONC-certified open-source EHR with telehealth support), or HAPI FHIR for clinical data management, paired with open-source WebRTC Selective Forwarding Units (SFUs) such as LiveKit, Jitsi Meet, or Mediasoup and coturn for firewall-friendly TURN relay infrastructure.
What security and regulatory standards apply when building a telemedicine platform?
In the United States, a telemedicine platform handling protected health information (PHI) must comply with the HIPAA Security Rule (45 CFR § 164.312), including end-to-end DTLS-SRTP media encryption, TLS 1.2+ API transport, AES-256 encryption at rest, role-based access controls, immutable audit logs (45 CFR § 164.312(b)), and executed Business Associate Agreements (BAAs) for all cloud hosting and video sub-processors.
