Why Telehealth Needs Purpose-Built Architecture
Telehealth is no longer optional. 62% of Americans have used telehealth services, and 76% of hospitals now offer virtual care as a standard service line. But the difference between a Zoom call with a doctor and a production-grade telehealth platform is vast: HIPAA compliance, EHR integration, clinical documentation, automated billing, and the security infrastructure required to protect protected health information (PHI) during real-time video communication.
Building a telehealth platform that passes security audits, integrates with Epic and Cerner, and generates revenue through proper CPT coding requires deliberate architectural decisions at every layer. This guide walks through the complete production architecture, from WebRTC video transport to SMART on FHIR launch integration and automated billing capture.
Layer 1: Video Communication (WebRTC + SRTP + DTLS)
WebRTC is the foundation of modern telehealth video. It provides peer-to-peer communication with built-in encryption, but healthcare deployments require additional configuration beyond the browser defaults.
Encryption Requirements
HIPAA requires encryption of PHI in transit. WebRTC satisfies this through two mandatory protocols:
- SRTP (Secure Real-time Transport Protocol): Encrypts media streams (audio and video) with AES-128 counter mode
- DTLS (Datagram Transport Layer Security): Provides the key exchange mechanism for SRTP, similar to TLS but for UDP-based media
These are enabled by default in WebRTC, but you must ensure your TURN/STUN infrastructure also supports encrypted relay.
NAT Traversal: STUN and TURN Servers
Healthcare networks are notorious for restrictive firewalls. Direct peer-to-peer connections fail approximately 15-20% of the time in hospital networks. TURN servers act as media relays when direct connections are blocked.
// WebRTC configuration for healthcare environments
const rtcConfig = {
iceServers: [
// STUN server for NAT discovery
{ urls: "stun:stun.example-health.com:3478" },
// TURN server for firewall traversal (TCP fallback critical for hospital networks)
{
urls: [
"turn:turn.example-health.com:3478?transport=udp",
"turn:turn.example-health.com:443?transport=tcp" // TCP on 443 passes most hospital firewalls
],
username: "hipaa-turn-user",
credential: "rotate-credentials-every-24h"
}
],
iceTransportPolicy: "all",
bundlePolicy: "max-bundle",
rtcpMuxPolicy: "require"
};
// Create peer connection
const peerConnection = new RTCPeerConnection(rtcConfig);
// Add local media stream
const localStream = await navigator.mediaDevices.getUserMedia({
video: { width: 1280, height: 720, facingMode: "user" },
audio: { echoCancellation: true, noiseSuppression: true }
});
localStream.getTracks().forEach(track => {
peerConnection.addTrack(track, localStream);
});
Recording and Storage
If your telehealth platform records sessions (for quality assurance, training, or patient request), recordings must be encrypted at rest with AES-256 and stored in a HIPAA-compliant storage backend (AWS S3 with SSE-KMS, Azure Blob with CMK, or GCP Cloud Storage with CMEK). Retention policies must align with state medical record retention laws, which range from 5 to 10 years for adult patients.
Layer 2: Scheduling (FHIR Appointment and Slot Resources)
A telehealth scheduling system must integrate with existing clinic workflows, not replace them. The FHIR standard provides two resources purpose-built for scheduling:
- Slot: Represents an available time window on a provider's calendar
- Appointment: Represents a booked telehealth visit linking patient, provider, and time slot
// FHIR Appointment resource for a telehealth visit
{
"resourceType": "Appointment",
"status": "booked",
"serviceType": [{
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/service-type",
"code": "57",
"display": "Telehealth"
}]
}],
"appointmentType": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/v2-0276",
"code": "ROUTINE",
"display": "Routine appointment"
}]
},
"start": "2026-03-16T14:00:00-05:00",
"end": "2026-03-16T14:30:00-05:00",
"participant": [
{
"actor": { "reference": "Patient/patient-12345" },
"status": "accepted"
},
{
"actor": { "reference": "Practitioner/dr-chen-456" },
"status": "accepted"
}
],
"extension": [{
"url": "http://example.com/fhir/StructureDefinition/telehealth-link",
"valueUrl": "https://telehealth.example.com/session/abc-123-def"
}]
}Layer 3: Clinical Documentation (Ambient AI Scribe)
The most valuable layer in a modern telehealth platform is automated clinical documentation. During a video visit, an AI clinical scribe captures the conversation, extracts clinical information, and generates structured documentation in real time.
The documentation pipeline has three stages:
- Speech-to-Text: Real-time audio transcription using medical-vocabulary-trained ASR models (Whisper fine-tuned on clinical audio, or cloud services like AWS Transcribe Medical)
- Clinical NLP: Extract chief complaint, history of present illness, review of systems, assessment, and plan from the transcript. Map medications to RxNorm, conditions to ICD-10/SNOMED CT
- FHIR Resource Generation: Auto-generate Encounter, Condition, MedicationRequest, and DocumentReference resources
// Auto-generated FHIR Encounter from telehealth visit
{
"resourceType": "Encounter",
"status": "finished",
"class": {
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "VR",
"display": "virtual"
},
"type": [{
"coding": [{
"system": "http://www.ama-assn.org/go/cpt",
"code": "99214",
"display": "Office/outpatient visit, established patient, moderate complexity"
}]
}],
"subject": { "reference": "Patient/patient-12345" },
"participant": [{
"individual": { "reference": "Practitioner/dr-chen-456" }
}],
"period": {
"start": "2026-03-16T14:00:00-05:00",
"end": "2026-03-16T14:28:00-05:00"
},
"reasonCode": [{
"coding": [{
"system": "http://snomed.info/sct",
"code": "38341003",
"display": "Hypertensive disorder"
}]
}]
}Layer 4: EHR Integration (SMART on FHIR Launch)
The telehealth platform must integrate bidirectionally with the EHR. SMART on FHIR provides the standard launch protocol that Epic, Cerner/Oracle Health, and other EHRs support.
EHR Launch Flow
When a clinician launches the telehealth app from within the EHR, the following sequence occurs:
- EHR sends a launch request with
launchparameter andiss(FHIR server URL) - Telehealth app redirects to the EHR's authorization server
- Authorization server returns an authorization code
- Telehealth app exchanges the code for an access token, which includes patient context (
patientfield) and encounter context - Telehealth app uses the access token to read patient demographics, allergies, medications, and active conditions from the FHIR API
- After the visit, the telehealth app writes back Encounter and DocumentReference resources
# Python: SMART on FHIR launch handler for telehealth
from fhirclient import client
import fhirclient.models.patient as p
import fhirclient.models.encounter as enc
class TelehealthSmartLaunch:
def __init__(self, iss: str, launch_token: str):
self.settings = {
'app_id': 'telehealth-platform-2026',
'api_base': iss,
'redirect_uri': 'https://telehealth.example.com/callback',
'scope': 'launch patient/*.read encounter/*.write openid fhirUser'
}
self.smart = client.FHIRClient(settings=self.settings)
def get_patient_context(self) -> dict:
patient = p.Patient.read(self.smart.patient_id, self.smart.server)
return {
'name': f"{patient.name[0].given[0]} {patient.name[0].family}",
'dob': str(patient.birthDate.isostring),
'mrn': next((id.value for id in patient.identifier
if id.system == 'http://hospital.example.com/mrn'), None),
'active_conditions': self._get_conditions(),
'current_medications': self._get_medications(),
'allergies': self._get_allergies()
}
def write_encounter_summary(self, encounter_data: dict):
encounter = enc.Encounter(encounter_data)
encounter.create(self.smart.server)
return encounter.idLayer 5: Automated Billing Capture
Every telehealth visit generates billable events. The platform should automatically determine the correct CPT code based on visit type, duration, and clinical complexity. For telehealth-specific billing in 2026, the key codes are:
| Visit Type | CPT Code | Rate | Auto-Detection Logic |
|---|---|---|---|
| New patient, low complexity | 99202 | $75 | First visit flag + visit duration under 15 min |
| New patient, moderate | 99203 | $114 | First visit + 15-29 min + 2+ problems addressed |
| Established, low complexity | 99212 | $56 | Return visit + under 10 min |
| Established, moderate | 99214 | $110 | Return visit + 25-39 min + moderate MDM |
| Established, high complexity | 99215 | $148 | Return visit + 40+ min + high MDM |
The billing engine should also capture add-on codes: modifier 95 (synchronous telehealth), RPM treatment management codes when device data is reviewed during the visit, and chronic care management time when care coordination occurs.
Layer 6: Security Architecture (Zero Trust for Healthcare)
HIPAA compliance for telehealth requires a defense-in-depth security model. Every layer of the stack must independently enforce access controls and encrypt PHI. This is not optional — a single unencrypted data path can result in breach notification requirements and OCR enforcement actions.
Technical Security Controls
- Transport encryption: TLS 1.3 for all API traffic, SRTP/DTLS for media streams, WSS for WebSocket signaling
- Authentication: Multi-factor authentication for all clinician accounts, SAML 2.0/OIDC federation with hospital identity providers
- Authorization: Role-based access control (RBAC) with principle of least privilege — nurses see patient vitals, billing staff see charges but not clinical notes
- Audit logging: Every access to PHI is logged with timestamp, user identity, resource accessed, and action taken. Logs retained for minimum 6 years per HIPAA requirements
- Session management: Automatic timeout after 15 minutes of inactivity, session tokens rotate every 60 minutes, concurrent session limits per user
For a comprehensive security checklist, see our guide on HIPAA compliance for developers.
Build vs. Buy: Video API Comparison
The build-vs-buy decision for the video layer is one of the most consequential architectural choices. Building custom WebRTC infrastructure requires 3-4 months of dedicated engineering time plus ongoing maintenance. Using a BAA-available video API reduces this to 2-4 weeks of integration work.
| Feature | Daily.co | Twilio Video | Vonage (Tokbox) | Custom WebRTC |
|---|---|---|---|---|
| BAA Available | Yes | Yes | Yes | N/A (your infra) |
| HIPAA Compliant | Yes | Yes | Yes | You build it |
| Recording | Cloud + composite | Cloud + composition | Cloud archiving | MediaRecorder API |
| Max Participants | 1,000 (SFU) | 50 (group rooms) | 3,000 (SFU) | Depends on SFU |
| TURN Relay | Global edge network | Global TURN infra | Built-in relay | Deploy own TURN |
| Integration Time | 1-2 weeks | 2-3 weeks | 2-3 weeks | 3-4 months |
| Cost (per min/participant) | $0.004-0.008 | $0.004-0.01 | $0.004-0.01 | Infra costs only |
Recommendation: For most healthcare organizations, starting with a BAA-available video API and investing engineering time in the differentiation layers (AI scribe, EHR integration, billing automation) delivers faster time-to-value than building custom WebRTC infrastructure.
Development Timeline: Basic to Advanced
| Phase | Duration | Deliverables | Team Size |
|---|---|---|---|
| Foundation | Months 1-2 | Auth system, video SDK integration, basic UI, HIPAA infrastructure | 3-4 engineers |
| Core Features | Months 3-4 | Scheduling, waiting room, recording, patient portal, notifications | 4-5 engineers |
| EHR Integration | Months 5-6 | SMART on FHIR launch, patient context, encounter write-back, Epic/Cerner certification | 3-4 engineers |
| Advanced | Months 7-8 | AI scribe, automated billing, analytics dashboard, multi-provider support | 4-6 engineers |
Total estimated development effort: 6-8 months for a basic platform, 8-10 months for advanced features. This assumes a team experienced in healthcare software development. For organizations evaluating their technology approach, our guide on choosing the right technology stack covers framework and infrastructure decisions.
Production Deployment Considerations
Infrastructure Requirements
- TURN servers: Deploy in at least 2 geographic regions for redundancy. Minimum 2 vCPU, 4GB RAM per TURN instance. Scale based on concurrent sessions
- Signaling server: WebSocket-based, horizontally scalable behind a load balancer. Redis pub/sub for cross-instance message routing
- Media recording storage: HIPAA-compliant object storage with server-side encryption, lifecycle policies for retention compliance
- Database: PostgreSQL for relational data (appointments, users, sessions), Redis for real-time session state and presence
Monitoring and Observability
Telehealth platforms require specialized monitoring beyond standard web application metrics. Track WebRTC-specific metrics: ICE connection success rate (target over 95%), average connection establishment time (target under 3 seconds), packet loss rate (target under 1%), audio/video bitrate stability, and TURN relay usage percentage.
For the broader monitoring strategy in healthcare AI applications, see our guide on observability for healthcare AI systems.
Patient Experience: The Virtual Waiting Room
The patient experience in telehealth starts long before the clinician joins the call. A well-designed virtual waiting room reduces no-show rates by 15-20% and improves patient satisfaction scores. Key features include:
- Pre-visit check-in: Patients confirm their identity, verify insurance information, complete intake forms, and sign consent documents — all before the appointment time. This saves 5-8 minutes of clinician time per visit
- Device and connectivity check: Automatically test the patient's camera, microphone, speaker, and internet bandwidth. Alert patients if their connection quality is below the minimum threshold for video. Provide fallback options (phone audio + video, or phone-only)
- Queue position and wait time: Display estimated wait time and queue position. Send push notifications or SMS when the clinician is ready. Reduce perceived wait time by showing educational content relevant to the patient's condition
- Caregiver and interpreter access: Allow patients to invite family members, caregivers, or language interpreters to join the telehealth session via a separate link. Each participant must authenticate independently
Multi-Provider and Group Session Support
Advanced telehealth platforms must support clinical scenarios beyond one-on-one visits. Group therapy sessions (behavioral health), tumor board reviews (oncology), and multidisciplinary care conferences require multi-provider video with role-based permissions. The architecture must handle:
- Selective media routing: In a multi-provider session, not all participants need to see all video feeds. A patient in a group therapy session should see the therapist but may have the option to hide their own video from other patients
- Screen sharing with PHI controls: When a clinician shares their screen (showing imaging, lab results, or EHR data), the platform must ensure that screen sharing is encrypted end-to-end and that recording controls respect PHI visibility rules
- Breakout rooms: A multidisciplinary care conference may need the ability to split into breakout rooms for specialist-specific discussions, then reconvene — similar to in-person hallway consultations
For healthcare applications handling complex clinical workflows, understanding domain-driven design principles is essential for modeling the scheduling, encounter, and documentation domains correctly.
Regulatory and Compliance Landscape in 2026
The telehealth regulatory environment continues to evolve. Key 2026 considerations include:
- DEA telehealth prescribing: The DEA has extended temporary flexibilities for prescribing controlled substances via telehealth through 2026, but permanent rules require an initial in-person visit or telemedicine-qualifying examination
- Audio-only reimbursement: CMS continues to reimburse for audio-only telehealth visits (CPT 99441-99443) in 2026, but at lower rates than video visits. Your platform should track modality for accurate billing
- Informed consent requirements: Most states require documented patient consent specifically for telehealth services, separate from general treatment consent. Some states require this consent to be renewed annually
- CMS interoperability rules: CMS interoperability requirements now mandate that telehealth platforms participating in value-based care programs support standardized data exchange via FHIR APIs
Frequently Asked Questions
Is Zoom HIPAA-compliant for telehealth?
Zoom for Healthcare (the paid plan with BAA) can be HIPAA-compliant. Standard Zoom is not. The key requirement is signing a Business Associate Agreement (BAA) with Zoom, which is only available on their healthcare-specific plans. However, Zoom lacks the clinical integration features (EHR integration, AI scribe, billing capture) that purpose-built telehealth platforms provide.
Do I need a BAA with my video API provider?
Yes. Any vendor that processes, transmits, or stores PHI on your behalf must sign a BAA. This includes video API providers (Daily.co, Twilio, Vonage), cloud hosting providers (AWS, Azure, GCP), and any third-party service that touches patient data during a telehealth session.
Can I use WebRTC without a TURN server?
Technically yes, but in practice no. Direct peer-to-peer connections using only STUN work about 80-85% of the time on consumer networks. In hospital and enterprise networks with restrictive firewalls, success rates drop to 60-70%. A TURN server with TCP fallback on port 443 is essential for reliable healthcare video.
How do I handle telehealth visits across state lines?
Provider licensure is state-specific. A physician licensed in New York cannot treat a patient physically located in California via telehealth without a California license. Your platform must capture and verify both the provider's licensed states and the patient's physical location at the time of the visit. The Interstate Medical Licensure Compact simplifies multi-state licensing for providers in member states.
What bandwidth is required for clinical-quality telehealth video?
Minimum 1.5 Mbps up/down for 720p video with audio. Recommended 3+ Mbps for 1080p. For dermatology and wound care specialties requiring high-resolution imaging, recommend 5+ Mbps with support for 4K camera feeds. The platform should implement adaptive bitrate to gracefully degrade on poor connections rather than dropping the call.
How do I ensure HIPAA compliance for telehealth recordings?
Recordings must be encrypted at rest (AES-256), access-controlled (only authorized users can view), audit-logged (every access recorded), and retained per applicable state medical record retention laws. Store recordings in a HIPAA-compliant cloud storage service with a signed BAA. Implement automatic deletion after the retention period expires.
Sources: HL7 SMART on FHIR Implementation Guide, WebRTC 1.0 W3C Specification, HHS HIPAA Security Rule, CMS Telehealth Policy Updates 2026, Daily.co HIPAA Documentation, Twilio Video Security Whitepaper.
