Building a HIPAA-Compliant Telehealth Platform: WebRTC, FHIR Integration, and Production Architecture

Part of our complete guide to How Custom RPM Software is Redefining Chronic Care.

Telehealth is no longer optional. Many Americans have now used telehealth, and most US hospitals 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. Hospital firewalls often block direct peer-to-peer media, so plan for TURN relay from day one. 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:

1. 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)
2. 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
3. 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:

1. EHR sends a launch request with launch parameter and iss (FHIR server URL)
2. Telehealth app redirects to the EHR's authorization server
3. The authorization server returns an authorization code
4. Telehealth app exchanges the code for an access token, which includes patient context (patient field) and encounter context
5. The telehealth app uses the access token to read patient demographics, allergies, medications, and active conditions from the FHIR API
6. 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.id

Layer 5: Automated Billing Capture

Every telehealth visit generates billable events. The platform can suggest a code from visit data such as visit type, duration and clinical complexity; a coder or the clinician confirms it before the claim is sent. Since 2021, office and outpatient E/M codes (99202-99215) are selected by medical decision making (MDM) or by total time on the date of service, not by visit length alone, so treat the detection rules below as prompts for review. The rates below are illustrative national figures from when this post was written; see the current Medicare Physician Fee Schedule for your locality. For telehealth-specific billing in 2026, the key codes are:

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 a minimum of 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.

A BAA makes the vendor a business associate; it does not make your application compliant. Check which plan each vendor requires before it will sign a BAA.

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

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.

When a visit fails: reconnection, recovery and EHR write-back

Video visits drop. Plan what happens when they do, so the patient is not lost and the chart stays correct.

• Network change: When a phone moves from Wi-Fi to cellular, the WebRTC connection breaks. Use an ICE restart (RTCPeerConnection.restartIce()) to find a new path without ending the call.
• Rejoin token: Give each participant a short-lived token to rejoin the same room. Keep its lifetime long enough to cover a reconnect (a few minutes) and short enough that a forwarded link cannot be reused later.
• What the patient sees: Show a plain message such as "Reconnecting, please stay on this page" and offer a phone fallback if the video does not return.
• Marking a dropped visit: Keep the FHIR Appointment.status accurate. A visit that started and finished is fulfilled; one the patient never joined is noshow; one that ended early stays recorded with a note of why, so billing and follow-up can act on it.
• Encounter note write-back: Send the note and Encounter with an idempotency key (for example a conditional create on a visit identifier) so a retry does not create duplicates. Retry with backoff on network errors. If the EHR rejects the write, queue it for manual review instead of dropping it.

Consent capture

Before recording starts, capture the patient's consent and store it where the record can prove it later: as a FHIR Consent resource, or on the EHR's own consent form. Record who consented, when, and to what (video, recording, or both).

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 can reduce no-shows and improve patient satisfaction; measure both before and after you launch it. 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 clinician time at the start of each 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 and HHS have extended the temporary flexibilities for prescribing controlled substances via telehealth through 31 December 2026 (Fourth Temporary Extension, 90 FR 61301, 31 December 2025). Permanent rules may require an initial in-person visit or a telemedicine-qualifying examination. Check the DEA Diversion Control telemedicine page before launch
• Audio-only reimbursement: The telephone E/M codes CPT 99441-99443 were deleted from CPT starting in 2025. For Medicare, audio-only visits are billed with the standard office E/M codes (99202-99215) plus modifier 93, where audio-only is allowed, usually with the patient at home (POS 10) (AAN telehealth coding guidance; see also CMS telehealth). 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

Related Reading

For more insights, explore our guides on RPM Program Implementation: Device to Go-Live Guide and FHIR in Modern Healthcare.

You may also find value in EHR Software Development Guide and Building a Healthtech App.

For the business side, see our guide to telehealth platform features and cost and our telehealth software solution.

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.