Telemedicine Platform

What is a telemedicine platform?

A telemedicine platform is the software system that runs virtual care end to end: it books and checks in the patient, confirms where the patient is, routes the visit to a licensed clinician, carries the audio and video, files the note and orders to the EHR, and turns the signed encounter into a claim.

A standalone video tool covers only the media session. The platform also owns identity, scheduling, state licensure checks, documentation, prescribing and billing. That is why architecture choices made for the video layer rarely decide whether the product works in a clinic.

Which rules fix parts of the architecture?

Six federal rules and standards set constraints that a platform team cannot design around. Each one maps to a specific layer.

• Media encryption: IETF RFC 8827 requires WebRTC media to be protected with DTLS-SRTP. With a selective forwarding unit, that protection is hop by hop, so the media server can see the stream unless the team adds end-to-end encryption on top.
• HIPAA safeguards: The HIPAA Security Rule (45 CFR 164.312) requires audit controls, unique user identification and person or entity authentication. Encryption of ePHI at rest and in transit is addressable, which means implement it or document an equivalent measure. The rule does not require end-to-end encryption of video.
• Business associates: HHS guidance on cloud computing says a cloud service that stores ePHI is a business associate even if it cannot view the data. Recording storage, transcript stores and chat archives fall in this group.
• EHR access: Under 45 CFR 170.315(g)(10), certified EHRs offer a standardized FHIR read API for patient and population services. Filing a visit note or order back needs the EHR vendor's own write APIs or an HL7 v2 interface.
• Coverage windows: The Consolidated Appropriations Act, 2026 (H.R. 7148) keeps Medicare's telehealth geographic and originating-site flexibilities in place through 31 December 2027. The DEA and HHS temporary rule for prescribing controlled substances by telemedicine without a prior in-person exam runs through 31 December 2026.
• Prescribing controls: DEA rules for electronic prescriptions for controlled substances (21 CFR Part 1311) require two-factor authentication when the practitioner signs.

Accessibility belongs on this list for many buyers. Recipients of HHS federal financial assistance must meet WCAG 2.1 Level AA for web content and mobile apps under 45 CFR 84.84, with compliance from 11 May 2027 for recipients with 15 or more employees.

How are the four platform layers wired together?

Most production platforms split into four layers that talk through events rather than shared tables. Keeping them apart lets one layer change vendors without a rewrite of the others.

• Layer 1, intake and waiting room: The patient client runs a camera, microphone and bandwidth check, records telehealth consent, asks for the patient's current location, and runs an X12 270 eligibility inquiry. The queue service then matches the visit to clinicians licensed in that state.
• Layer 2, media and asynchronous care: A selective forwarding unit and TURN relays carry the session, with TURN over TLS on port 443 for networks that block UDP. A separate state machine handles store-and-forward work such as photo uploads, questionnaires and message threads with response timers.
• Layer 3, clinical workbench: The clinician console shows the stream beside a chart view built from FHIR R4 resources (Patient, Condition, MedicationRequest, AllergyIntolerance, Observation), or launches inside Epic, Oracle Health (Cerner) or athenahealth through SMART on FHIR. Prescribing runs through an NCPDP SCRIPT network and lab orders through HL7 v2 ORM and ORU.
• Layer 4, billing and audit: Signing the encounter captures start and stop times, patient location, the clinician's license state and the modality. The billing service maps those to place of service 02 or 10 and modifier 95 or 93, builds the X12 837P, and writes the audit events.

Buying the media layer versus running it

Running your own SFU and global TURN fleet is a large operations job: capacity planning, region failover, codec upgrades and abuse handling. Most teams buy a programmable video SDK from a provider that signs a BAA and spend their engineering time on routing, documentation and billing, which are the parts a clinic actually judges.

Self-hosting makes sense when a contract forbids third-party media handling, when the platform needs end-to-end encryption the vendor cannot offer, or when visit volume makes per-minute pricing the main cost line.

How does visit data move from booking to claim?

A single visit produces a chain of events, and each step has a system of record. Mapping this chain early shows which EHR interfaces the project actually needs.

• 1. Booking: The EHR sends an HL7 v2 SIU^S12 message, or the platform creates a FHIR Appointment and posts it back through the vendor's scheduling API.
• 2. Check-in: The platform stores consent, the reported location and the 271 response against the appointment ID, so later steps never re-ask.
• 3. Session: The media service emits join, leave, reconnect and modality-change events. Audio-only fallback is recorded as its own event because it changes the claim modifier.
• 4. Documentation: The clinician signs the note in the workbench. The platform files it as an HL7 v2 MDM^T02 document or through the EHR's document write API, then waits for an acknowledgment before marking the encounter closed.
• 5. Orders: Prescriptions go out over NCPDP SCRIPT, and lab orders leave as ORM messages with results returning as ORU.
• 6. Charges: The billing service sends a DFT^P03 to the EHR or builds the 837P for a clearinghouse, then reconciles the 835 remittance.

Which design decisions should be settled first?

Five decisions shape the data model, and changing them after launch usually means a migration. Write each one down with an owner before the first sprint.

• Tenancy: One shared database with a tenant key, or one database per medical group. Per-tenant databases simplify data return at contract end but cost more to run.
• Care modes: Scheduled visits, on-demand queues, asynchronous consults or a mix. On-demand queues need wait-time estimates and overflow rules that scheduled clinics do not.
• EHR posture: Launch inside the EHR with SMART on FHIR, or run as a standalone app that syncs. Embedded launch removes double logins but ties release timing to each EHR vendor's app review.
• Identity: How patients prove who they are at join time, and whether guests such as interpreters or family members get their own tokens and audit entries.
• Recording: Whether sessions are recorded at all. Not recording removes a large ePHI store, so make recording an explicit opt-in with a retention period.

Platform failure points to test before launch

These failures rarely appear in a demo. They show up in the first weeks with real clinics, so build test cases for each one.

• Hospital firewalls: Clinicians on a hospital network often cannot reach UDP media ports. Without TURN over TLS on 443, calls fail only for those users, which makes the bug hard to reproduce.
• Home address used as location: Licensure follows where the patient is during the visit, not the address on file. A patient travelling out of state must be re-routed or rescheduled.
• Write-back without acknowledgment: If the platform marks a note filed before the EHR confirms it, notes go missing silently when an interface queue backs up.
• Hard-coded coverage rules: Place of service, audio-only rules and controlled-substance prescribing rules change by payer and by date. Keep them in configuration with effective dates.
• Tracking scripts on intake pages: Third-party analytics or chat widgets on a symptom or booking form can send identifiers and reasons for visit to vendors with no BAA.
• Clock drift between services: Visit duration feeds billing. If the media service and billing service use different clocks, durations on claims will not match the audit log.

How should a platform team stage the build?

A staged build keeps each release usable in a real clinic. The order below front-loads the parts that decide clinician adoption.

• 1. Care model and scope: Name the visit types, states and payers for release one, and the EHRs the first customers run.
• 2. Intake and routing: Build check-in, location capture, consent and the license matrix before the video room, because every later step depends on them.
• 3. Media: Integrate the video SDK with TURN over 443, audio-only fallback, captions and a guest invite for interpreters.
• 4. Workbench and write-back: Add the chart view, note signing, e-prescribing and the acknowledged write-back path for each target EHR.
• 5. Billing: Add eligibility at check-in, modality capture, the 837P builder and 835 reconciliation.
• 6. Hardening: Test on throttled mobile networks, restrictive proxies, VoiceOver and TalkBack, and older browsers, then pilot with one clinic before widening.

How Agnotic can help

Telemedicine platforms succeed or stall on the layers around the video room, and that is where Agnotic focuses. Agnotic Technologies scopes the care model with your clinical team, builds intake and licensure routing, integrates a BAA-backed media provider, and wires write-back to Epic, Oracle Health (Cerner) or athenahealth through the interfaces each site allows.

The engineering team also builds the billing path from modality capture to 837P and 835 reconciliation, with the audit events your compliance lead will ask for.

Sources

• IETF RFC 8827: WebRTC Security Architecture (DTLS-SRTP)
• 45 CFR 164.312: HIPAA Security Rule technical safeguards
• HHS: Guidance on HIPAA and cloud computing
• ASTP/ONC: Standardized API for patient and population services, 45 CFR 170.315(g)(10)
• Congress.gov: H.R. 7148, Consolidated Appropriations Act, 2026
• Federal Register: Fourth temporary extension of telemedicine flexibilities for prescription of controlled medications
• eCFR: 21 CFR Part 1311, electronic prescriptions for controlled substances
• Federal Register: Extension of compliance dates for HHS Section 504 web and mobile accessibility rule