A telehealth platform is more than a video call
When a healthcare buyer first considers telehealth, the mental model often looks simple: patient logs in, provider joins a video call, appointment ends. This makes it feel like a video-conferencing product with a healthcare skin. But a production telehealth platform is a different order of complexity from that description.
The full workflow a platform must support looks more like this:
Each of those stages requires its own product logic, data model, integration, and operational support. The video call is one step in the middle. The stages before and after it are where most of the engineering and compliance complexity lives.
Start with the care model, not the feature list
The technical architecture of a telehealth platform must follow the clinical and business operating model. The same feature list can mean very different implementations depending on how and where care is being delivered.
Consider three illustrative scenarios. A behavioral-health platform serving patients across five states needs to verify and enforce provider licensure by patient location, potentially supporting multiple licensing pathways (full license, Interstate Medical Licensure Compact, PSYPACT, temporary practice rules) depending on the state and profession. A hospital integrating virtual visits into an existing EHR needs SMART on FHIR or API integration with its clinical system, provider scheduling tied to the existing hospital calendar, and documentation flowing back into the EHR's native format. A direct-to-consumer telehealth company adding e-prescribing needs pharmacy integration, medication history workflows, provider identity verification, auditability of prescription events, and a clear understanding of the controlled-substance prescribing rules that apply to its specific medications and operating states.
These are not variations of the same product. They are different products with some overlapping technology. The operating model must come before the feature list, because the model determines what actually needs to be built.
Core technical architecture: what a production platform requires
| Layer | Core components | Why it matters |
|---|---|---|
| Patient application | Registration and identity, appointment scheduling, intake forms, consent, visit access, secure messaging, documents | The patient's first and lasting impression of the care experience. Friction at intake or login directly reduces conversion and completion rates. |
| Provider application | Provider schedule and queue, patient context and clinical history, visit controls and communication tools, clinical documentation, prescription workflow where applicable, post-visit follow-up | Provider workflow efficiency directly affects care quality and adoption. A platform clinicians find cumbersome will be avoided, regardless of patient experience quality. |
| Backend services | Authentication and authorization, appointment engine, business logic, notifications, data services, APIs | The scheduling and authorization layer is often more complex than it appears: timezone handling, provider availability rules, overlapping bookings, appointment state management. |
| Communication layer | Audio and video, secure chat, notifications, waiting rooms, session management, reconnection handling | Reliability under variable network conditions is the most commonly underestimated engineering problem in telehealth. |
| Data and clinical layer | Patient information, clinical data, encounter records, documents, audit logs | Every state in which the platform operates, and every payer it bills, will have expectations about documentation, retention, and audit capability. |
| Administration | User and provider management, organization settings, permissions, reporting, operational monitoring | Without operational visibility, issues in production are discovered by patients rather than by the team. |
The communication layer: more than WebRTC
WebRTC is the foundational open standard that most telehealth video is built on. It provides peer-to-peer or server-mediated audio and video in the browser and in native applications. That is a meaningful starting point. It is not a complete telehealth communication implementation.
A production telehealth communication layer additionally requires: audio and video quality tuning and fallback behavior; browser and mobile compatibility testing across the combinations patients and providers actually use; graceful handling of connectivity variation, including reconnection logic when sessions drop; session security including access control to each session; properly implemented waiting rooms with queue management; provider controls over session state (mute, camera, admit, dismiss, end); clear participant identity tied to authentication rather than self-reported names; screen sharing where clinically appropriate; device and permission handling across operating systems; monitoring of session quality and failure events; a defined recording policy and technical controls aligned with that policy; and accessibility considerations for patients with disabilities. HHS guidance specifically highlights encryption, authentication, session controls, and the specific privacy risks associated with recorded or transcribed sessions and stored electronic protected health information.
Buyers may choose between building their own communication infrastructure and using a specialized communication provider with healthcare-oriented features. The right choice depends on scale, budget, control requirements, and the specific features required. Neither approach eliminates the need for appropriate security controls, proper session management, and alignment with applicable privacy obligations.
EHR integration: the part buyers most often underestimate
Nearly every telehealth platform eventually needs to exchange data with an EHR or practice management system. This is commonly described as "EHR integration" as if it were a single feature. In practice it is a family of engineering work that varies significantly by EHR, use case, and data flow.
Before scoping an EHR integration, a buyer needs to define: which specific EHR or EHRs must be connected; what data needs to flow in which direction (read, write, or both); which specific FHIR resources or HL7 v2 message types are involved; which FHIR version and implementation guide applies (US Core, relevant specialty guides); what authentication and authorization approach is required (SMART App Launch for EHR-launched experiences, standalone launch for patient-facing apps, SMART Backend Services for system-to-system access); how patient identity is matched across the telehealth platform and the EHR; whether encounters and clinical documentation must be written back into the EHR; and how real-time versus batch data needs are distinguished.
ONC's current interoperability materials, including the 2026 Interoperability Standards Advisory Reference Edition, support FHIR-based APIs and SMART App Launch as current standards for applicable healthcare interoperability. But FHIR itself is not a plug-and-play connector. An integration with one EHR ecosystem may not transfer directly to another, because each major EHR platform implements FHIR differently, supports different resource types, enforces different permission scopes, and may require participation in its developer program before access is granted.
A read-only integration retrieving patient demographics from a single EHR for a narrow workflow is a different engineering scope from a bidirectional integration that pulls clinical history, schedules appointments, and writes encounter notes back into the record across multiple EHR environments. The first might take weeks; the second might take months, independent of the telehealth application it is connected to.
Compliance is a system requirement, not a checkbox
Privacy and security
Telehealth platforms that create, receive, maintain, or transmit protected health information (PHI) as covered entities or business associates are subject to HIPAA's Privacy and Security Rules. This means implementing administrative, physical, and technical safeguards appropriate to the risk environment: access control, audit logging, encryption in transit and at rest, authentication, session management, risk analysis, workforce training, business associate agreements with relevant vendors, breach notification procedures, and data retention and destruction policies. There is no "HIPAA certification" that software can receive from a government authority. The obligation is on the organization to implement appropriate safeguards and to work with technology vendors who can support compliance. HHS states that covered entities and health plans using telehealth technology need vendors that comply with applicable HIPAA requirements and enter into business associate agreements where applicable.
Provider licensure and patient location
Telehealth does not allow a licensed clinician to practice in any state simply because the encounter is virtual. As HHS notes at telehealth.hhs.gov, health professionals must be licensed or legally permitted to practice in the state where the patient is located. The patient's physical location at the time of the visit, not their home address, determines the applicable jurisdiction in most frameworks.
Depending on the profession and the states involved, a provider may be authorized to treat patients in a given state through a full state license, a license through an interstate compact such as the Interstate Medical Licensure Compact (now covering 44 states plus DC and Guam as of July 2026), PSYPACT for psychologists, a nurse licensure compact, temporary practice rules, or a state telehealth-specific registration pathway (available in approximately 20 states as of 2025-2026). The patient location verification workflow is therefore not just an operational step; it is a compliance requirement that the platform must actively support, including collecting and documenting the patient's location before each visit.
E-prescribing and controlled substances
If the telehealth platform includes prescribing functionality, the scope extends significantly beyond adding a prescription interface. E-prescribing requires integration with a prescription routing network or pharmacy system, provider identity and DEA registration verification, medication history, auditability, state-specific prescription rules, and a clear distinction between controlled and non-controlled substance workflows.
For controlled substances, DEA and HHS published a fourth temporary extension of COVID-19-era telemedicine prescribing flexibilities in January 2026, taking effect January 1, 2026 and extending through December 31, 2026. Under this extension, DEA-registered practitioners may continue to prescribe Schedule II-V controlled medications via telemedicine for patients they have not previously seen in person, without the standard in-person examination requirement under the Ryan Haight Act. This is a temporary rule, not a permanent policy change. Permanent regulations have not yet been finalized as of this writing. Organizations building prescription functionality must monitor this area and design workflows that can adapt when the regulatory environment changes.
Reimbursement and billing
Payer reimbursement for telehealth varies significantly by payer, state, plan type, and service type. Medicare telehealth policy continues to evolve through annual rulemaking, with the CMS telehealth page updated in April 2026. Commercial payer parity laws differ by state and may or may not apply to the specific plan types a telehealth business encounters. Documentation and coding requirements for telehealth reimbursement differ from in-person visits in ways that directly affect the encounter documentation and billing workflows the platform must support. A telehealth business that does not design its platform around the specific payer mix and billing model it will operate will encounter claim denials, documentation gaps, and revenue cycle problems that require expensive rework.
The operational features that separate a demo from a real platform
The demo proves the video works. Production proves the healthcare workflow works. Many telehealth platforms demonstrate well in controlled conditions and fail operationally because the operational layer was treated as a post-launch concern.
Production operational requirements include: provider scheduling with timezone handling, buffer rules, cancellation logic, and no-show workflows; automated patient reminders and multi-channel notification management; consent capture and documentation with version tracking; intake form logic with conditional branching and clinical validation; waiting room management with queue visibility for providers and administrators; escalation paths for patients who need immediate or urgent care outside the platform's scope; billing and claims data capture integrated with documentation workflows; detailed audit trails meeting applicable retention and access requirements; administrative dashboards with real-time visibility into appointment, provider, and platform status; and support workflows for patients and providers who encounter technical problems during an encounter.
Build vs buy: an honest architecture decision
Not everything in a telehealth platform should be custom-built. The relevant question is not "Do we build or buy?" but "Which parts of this platform are commodity infrastructure, and which parts are genuinely proprietary to our care model and patient experience?"
Infrastructure that is generally reasonable to purchase from specialized providers includes: video and audio communication infrastructure; SMS and email notification delivery; payment processing; cloud hosting and managed infrastructure; identity and authentication infrastructure; certain interoperability infrastructure and integration middleware; and commodity analytics and monitoring tooling.
Elements more likely to require custom development include: the proprietary patient workflow and experience; the provider workflow and clinical decision support specific to the care model; scheduling rules tied to the clinical workflow; specialty-specific intake and documentation logic; billing and claims workflows tied to the specific payer mix; integration orchestration logic connecting the clinical workflow to EHR and pharmacy systems; and the differentiated elements that make this particular telehealth product different from a generic one.
Choosing to use a specialized video infrastructure provider does not simplify the surrounding product. It simplifies one layer. The patient flow, provider workflow, clinical logic, EHR integration, security architecture, and operational instrumentation still require the same careful design whether the video layer is custom-built or purchased.
What changes at scale
| Area | Early MVP | Scaled production platform |
|---|---|---|
| Users | Limited pilot cohort | Large concurrent patient and provider base requiring tested capacity |
| Provider network | Small, known team | Multi-organization, multi-specialty, multi-state requiring credential and licensure management |
| EHR | One integration or no integration | Multiple EHR ecosystems each with different APIs, resources, and behaviors |
| Scheduling | Basic availability | Complex rules: capacity management, provider availability, state restrictions, appointment types |
| Video | Standard concurrent sessions | High-concurrency management, geographic performance, failover, monitoring |
| Security | Core controls | Mature access governance, monitoring, third-party assessment, incident response programme |
| Billing | Single payer or out-of-pocket | Multiple payer contracts, state parity rules, claims workflows, RCM integration |
| Compliance | Core HIPAA safeguards and licensure for initial states | Multi-state licensure management, audit programme, risk analysis, BAA management, breach readiness |
| Support | Manual, ad hoc | Structured support workflows for patients, providers, and administrators |
| Reliability | Basic availability | Formal uptime commitments, recovery objectives, redundancy, monitoring programme |
Scale does not simply mean more servers. It means more workflows, more integrations, more failure modes, more operational requirements, and more governance obligations. Organizations that build an MVP without planning for the scaling path routinely incur significant rework costs when growth requires capabilities the initial architecture cannot support.