Telehealth adoption increased by 3800% during the COVID-19 pandemic and, unlike most crisis-driven behavior changes, has not reverted. The most widely cited figure — that 60-80% of patients who used telehealth for the first time during the pandemic want to continue using it — understates the shift. Telehealth is no longer a feature; it is infrastructure.
This guide covers the technical architecture of telehealth platform development: video consultation infrastructure, remote patient monitoring (RPM) system design, wearable device integration patterns, clinical workflow requirements, and the HIPAA and security controls that determine whether a telehealth system is deployable in clinical settings. By the end, you will have a clear technical roadmap for building or evaluating telehealth platforms.
Telehealth Platform Development: Architecture Overview
A production-grade telehealth platform is not a video conferencing tool with a healthcare skin. It is an integrated clinical system that happens to include video. The components are:
Video consultation engine: Real-time, encrypted peer-to-peer video with adaptive quality, screen sharing, and session recording. This is the most visible component but typically the least complex to build.
Patient engagement layer: Appointment scheduling, intake forms, virtual waiting rooms, post-visit instructions, and follow-up communication. This determines the patient experience and significantly affects show rates and satisfaction scores.
Clinical documentation integration: The visit must be documented. Notes generated during telehealth visits must enter the patient's EHR record in structured form — not as free-text PDF attachments. This requires FHIR or HL7 v2 integration with the EHR.
Remote patient monitoring subsystem: Between-visit data collection from devices and wearables, threshold-based alerting, and trend visualization for clinical review.
Analytics and reporting: Utilization metrics, patient outcomes, no-show rates, and quality metrics for payer reporting.
Video Consultation Infrastructure
WebRTC Architecture
WebRTC (Web Real-Time Communication) is the open standard for browser and application-based real-time communication. It is the foundation of virtually all telehealth video implementations, either used directly or abstracted by commercial SDKs.
WebRTC establishes peer-to-peer encrypted connections using a three-component architecture:
Signaling: WebRTC peers discover each other and negotiate connection parameters through a signaling server. The signaling protocol is not standardized (common choices include WebSocket-based custom protocols and SIP). The signaling server must be available and low-latency, but it does not handle media — only connection setup.
ICE (Interactive Connectivity Establishment): ICE discovers the best network path between peers. It tries direct peer-to-peer first (best latency, no media server costs). If direct connection is blocked by NAT or firewall, it falls back to STUN (Session Traversal Utilities for NAT) relay. If STUN relay fails, it falls back to TURN (Traversal Using Relays around NAT) relay — a media server that routes traffic.
Media encryption: All WebRTC media is encrypted by the standard. DTLS (Datagram Transport Layer Security) negotiates keys; SRTP (Secure Real-time Transport Protocol) encrypts audio and video streams. This encryption is mandatory and cannot be disabled — it is architecturally built into the protocol.
TURN Server Infrastructure
In clinical settings, TURN servers are necessary for a significant percentage of connections. Hospital networks, corporate networks, and many home networks use symmetric NAT configurations that block direct peer-to-peer WebRTC. A TURN server relays media between peers, ensuring reliable connections at the cost of server bandwidth and latency.
TURN server sizing:
- Each concurrent bidirectional video connection requires approximately 1.5-3 Mbps of server bandwidth
- A telehealth platform expecting 100 concurrent sessions needs 150-300 Mbps of TURN server capacity
- TURN servers should be geographically distributed close to clinician and patient populations to minimize relay latency
Commercial WebRTC platforms (Twilio, Vonage, Daily.co, Agora) include managed TURN infrastructure in their pricing. Self-hosted TURN using open-source software (coturn) reduces costs for high-volume platforms but requires operational expertise.
Video Quality for Clinical Assessment
Clinical video requirements differ from consumer video in one important way: the video must support clinical assessment. A dermatology telehealth platform needs higher resolution skin visualization than a general GP video consult. An ophthalmology platform may require specific lighting protocols and resolution specifications for fundus photography.
Resolution and frame rate:
- Minimum for clinical use: 720p at 24fps
- Preferred: 1080p at 30fps for general medicine
- High-acuity specialties (dermatology, wound care): 1080p at 30fps with high dynamic range
Adaptive bitrate: Connections degrade in real-world conditions. WebRTC implementations must support adaptive bitrate — reducing quality smoothly as bandwidth decreases rather than freezing. For clinical video, a graceful degradation strategy (maintaining frame rate at reduced resolution rather than reducing frame rate) is preferred because clinical assessment depends on seeing movement accurately.
Codec selection: VP9 provides better compression than H.264 at equivalent quality, reducing bandwidth requirements by approximately 40%. H.264 has broader hardware acceleration support (important for mobile battery life). AV1 is emerging as the next-generation choice with superior compression, but hardware support is still maturing. For a new platform in 2026, VP9 with H.264 fallback is a reasonable choice.
Screen Sharing and Document Sharing
Clinical video consultations often require document sharing (imaging reports, lab results, patient education materials). WebRTC screen sharing API (getDisplayMedia) supports sharing specific application windows or screens. For clinical use, document sharing should use a controlled mechanism — sharing specific documents from the EHR, not arbitrary screen sharing — to prevent inadvertent PHI exposure of other patients' data visible on the clinician's screen.
Remote Patient Monitoring Architecture
Remote patient monitoring (RPM) extends telehealth beyond video consultations to continuous physiological monitoring between visits. RPM is most valuable for chronic disease management — patients with heart failure, diabetes, hypertension, COPD, and post-surgical recovery have demonstrated improved outcomes when physiological data is monitored continuously.
Device Integration Patterns
Consumer wearables: Apple Watch, Fitbit, Garmin, Samsung Galaxy Watch, and similar devices provide continuous heart rate, activity, sleep, and (increasingly) SpO2 and ECG data. Integration is via platform health APIs:
- Apple HealthKit: iOS SDK that aggregates health data from Apple Watch and third-party devices. SMART on FHIR authorization is not required — HealthKit uses its own permission model. Clinical platforms read HealthKit data and translate it to FHIR Observation resources.
- Google Health Connect: Android equivalent, aggregating data from Samsung Health, Fitbit (Google subsidiary), and other Android health apps. Similar permission model.
Clinical-grade connected devices: For accurate physiological measurement, consumer wearables are supplemented by medical-grade connected devices:
- Continuous glucose monitors (CGM): Dexcom G7, Abbott FreeStyle Libre 3, and Medtronic Guardian 4 provide 5-minute glucose readings via NFC and Bluetooth. APIs (Dexcom Share, LibreView) expose glucose time-series data.
- Blood pressure monitors: Omron Connect, withings BPM Connect, and Garmin Index BPM provide connected blood pressure readings via Bluetooth and cloud APIs.
- Pulse oximeters: Nonin and Masimo offer clinical-grade connected pulse oximeters with APIs for continuous SpO2 monitoring.
- Digital stethoscopes: 3M Littmann CORE and Eko DUO support remote auscultation — transmitting heart and lung sounds to the provider's device in near-real-time.
Bluetooth Low Energy (BLE) integration: Many clinical devices use BLE for local connectivity, syncing to a mobile app which then uploads to the cloud. The mobile app must implement BLE device discovery, pairing, and data parsing for each device protocol. The GATT (Generic Attribute Profile) specification defines standard profiles for common health measurements (blood pressure profile, glucose profile, heart rate profile), but many device manufacturers use custom profiles.
Alert Threshold Management
RPM clinical value depends on alert quality. Poorly configured alerts — too sensitive (too many false positives) or too specific (missing genuine deterioration) — either paralyze clinical teams or fail to protect patients.
Threshold configuration: Alert thresholds must be patient-specific and clinically defined. The FHIR Goal resource stores patient-specific targets. For a patient with heart failure, the goal might be:
- Daily weight gain > 2 lbs from baseline → Level 2 alert (call patient, review medications)
- Daily weight gain > 4 lbs from baseline → Level 3 alert (urgent telehealth visit or in-person evaluation)
- SpO2 < 92% for > 5 minutes → Level 3 alert
Alert routing: Alerts must route to the appropriate clinical team member based on alert severity, time of day, and care team availability. A Level 2 alert during business hours routes to the care coordinator. A Level 3 alert at 2 AM routes to the on-call nurse with escalation to the on-call physician if not acknowledged within 15 minutes.
Alert fatigue mitigation: Machine learning models trained on the RPM data stream can reduce alert fatigue by:
- Filtering transient artifact (a momentary SpO2 drop during sensor repositioning is different from sustained hypoxia)
- Predicting deterioration using multi-parameter trends rather than single-threshold breaches
- Personalizing thresholds by learning each patient's normal range
Wearable Device Integration Deep Dive
HealthKit Integration Architecture
Apple HealthKit provides a central data store on-device that aggregates health data from Apple Watch, third-party devices, and manual entry. HealthKit data is private to the device — it is not stored in Apple's cloud by default. Clinical applications must explicitly request HealthKit permission for each data type they intend to read.
Permission request best practice: Request permissions only at the moment they are needed, with clear explanation of why each data type is requested. Users who understand the clinical reason for data access grant permissions at significantly higher rates.
Background delivery: HealthKit supports background delivery — the app can register to receive notifications when new data of a specific type becomes available, even when the app is not in the foreground. This is essential for RPM: the app must collect glucose readings, heart rate data, and weight measurements continuously without requiring the patient to manually open the app.
FHIR translation: HealthKit data types must be mapped to FHIR Observation resources with appropriate LOINC codes before transmission to the clinical system:
- HealthKit
HKQuantityTypeIdentifierHeartRate→ FHIR Observation with LOINC 8867-4 - HealthKit
HKQuantityTypeIdentifierBloodPressureSystolic→ FHIR Observation with LOINC 8480-6 - HealthKit
HKQuantityTypeIdentifierBloodGlucose→ FHIR Observation with LOINC 41653-7
Android Health Connect
Google Health Connect is the Android equivalent, launched in 2022 and now the standard for Android health data aggregation (replacing Google Fit). The permission model is similar to HealthKit — explicit per-data-type permissions with clear user-facing explanations.
For cross-platform telehealth development, the health data integration layer should abstract HealthKit and Health Connect behind a common interface. Flutter's health package provides a cross-platform abstraction, but as of 2026, some Health Connect data types are not yet fully supported in third-party packages — verify coverage for your specific use case.
HIPAA and Security Architecture
PHI Identification in Telehealth Systems
Telehealth systems generate multiple categories of PHI:
- Video session recordings (if recorded, with patient consent)
- Chat/messaging transcripts
- Clinical notes generated during visits
- RPM physiological data
- Device and platform metadata (appointment times, care team members, diagnosis codes)
Each category requires appropriate technical controls. Video recordings require encrypted storage with access controls limited to the treating care team and the patient. Physiological data requires HIPAA-compliant storage with audit logging.
Security Requirements for HIPAA-Eligible Video
If the video infrastructure does not have a BAA with your organization, you cannot use it for telehealth with PHI. Major providers with healthcare BAA coverage include Zoom for Healthcare, Twilio HIPAA, Vonage, Daily.co, and Agora. Generic consumer video platforms (FaceTime, WhatsApp, regular Zoom) are not suitable for clinical telehealth.
End-to-end encryption consideration: In E2EE video calls, even the platform provider cannot access the media stream. This is the highest security configuration but may conflict with compliance recording requirements. Clinical telehealth platforms typically use encrypted video that the platform can access (for recording and compliance) rather than true E2EE.
Session Recording and Retention
Telehealth session recordings are health records and must be treated accordingly. Retention requirements vary by jurisdiction:
- US: State-specific, typically 7-10 years for adults; longer for pediatric patients
- EU: GDPR data minimization principles apply — retain only as long as necessary for the specified purpose
- UK: NHS records retention schedules apply to NHS-funded telehealth
Clinical Workflow Integration
EHR Integration Requirements
A telehealth platform that does not integrate with the EHR forces clinical staff to document visits in two places — which they will not do consistently. EHR integration is not optional for clinical telehealth.
Pre-visit: Patient demographics, insurance coverage, and active problem list should be visible to the clinician before the telehealth visit starts. This requires a read integration (typically FHIR Patient, Condition, MedicationStatement queries) that populates the telehealth platform's session view.
During visit: Clinicians should be able to create and save clinical notes directly from the telehealth interface. At a minimum, notes should be transferred to the EHR as a DocumentReference FHIR resource. Preferred: structured note entry that creates coded diagnoses (Condition resources), orders (MedicationRequest, ServiceRequest), and follow-up appointments (Appointment resources) directly in the EHR.
Post-visit: After-visit summaries, prescription confirmations, and follow-up instructions should be delivered to the patient through the patient portal or the telehealth app, with a copy in the EHR record.
Measuring Telehealth Platform Success
The metrics that matter for telehealth operational success are:
| Metric | Target | Why It Matters |
|---|---|---|
| Connection success rate | > 98% | Failed connections undermine clinical and patient trust |
| Video quality score (MOS) | > 3.5/5 | Clinical assessment quality depends on video fidelity |
| Patient show rate | > 85% | Below-average indicates scheduling or access friction |
| Documentation completion rate | > 95% | Incomplete notes create care gaps |
| Average technical support time | < 2 min/session | High support volume indicates UX or infrastructure issues |
| RPM alert actionability | > 70% | Low actionability indicates threshold misconfiguration |
Frequently Asked Questions
What is the difference between synchronous and asynchronous telehealth? Synchronous telehealth is real-time video or phone consultation — the patient and provider are present at the same time. Asynchronous telehealth (store-and-forward) allows patients to submit symptoms, photos, or questionnaires that clinicians review and respond to later. Dermatology and ophthalmology commonly use asynchronous telehealth for initial screening. Most telehealth platforms support both modes.
What is RPM (Remote Patient Monitoring) vs. RCM? RPM is Remote Patient Monitoring — continuous collection of physiological data from patients at home. RCM is Revenue Cycle Management — the financial processes for billing and collections. They are unrelated. RPM generates clinical and reimbursement value; CMS reimburses RPM services under CPT codes 99453, 99454, 99457, and 99458.
Can telehealth platforms be used for mental health? Yes, and mental health is one of the strongest use cases. Access to mental health services is severely constrained by provider availability, geographic barriers, and stigma. Telehealth removes the geographic barrier and reduces stigma-related barriers to seeking care. Platforms used for mental health must support secure messaging and appropriate crisis response protocols (detection of crisis language and escalation workflows).
How are telehealth billing codes handled? In the US, telehealth services are billed using standard CPT codes with telehealth-specific modifiers. CMS has specific rules about which services can be billed as telehealth, which care settings are eligible, and what documentation is required. Commercial payers have their own telehealth coverage policies, which vary considerably. The platform should support documentation that meets payer requirements for telehealth reimbursement.
What is the video quality floor for clinical telehealth? 720p at 24fps is the minimum for most clinical use cases. For assessments requiring high visual acuity (skin lesions, wound assessment, ophthalmology), 1080p at 30fps is required. For neurological assessments requiring fine motor observation, high frame rate (60fps) may be needed.
Conclusion
Telehealth platform development is a systems integration challenge as much as it is a software development challenge. The video engine is the most visible component, but the clinical workflow integration, RPM data pipeline, alert management, and EHR connectivity collectively determine whether the platform is a standalone tool or genuine care infrastructure.
Organizations that approach telehealth platform development by starting with clinical workflow requirements — how do clinicians document visits? how do alert thresholds get configured? how does RPM data enter the patient record? — produce systems that clinical staff actually use. Organizations that start with the video engine and add clinical workflow as an afterthought produce systems that require workarounds.
Smart Maple builds telehealth platforms with clinical-grade FHIR integration, HIPAA and GDPR compliant architecture, and proven RPM data pipelines. Contact us at smart-maple.com to discuss your telehealth platform requirements.
Related Articles
MLOps Guide: Taking Machine Learning Models to Production [2026]
87% of machine learning models built by data science teams never reach production. The models work — they pass cross-validation, they score well on holdout sets, they demonstrate genuine predictive value. The problem is not the modeling. The problem is everything that happens between a notebook experiment and a reliable, monitored, production system. MLOps is the discipline that closes that gap. This guide covers the full MLOps stack: maturity levels, tooling choices (MLflow, DVC, Kubeflow
Read More: MLOps Guide: Taking Machine Learning Models to Production [2026]LLM Fine-Tuning Guide: Custom Model Training with LoRA and QLoRA [2026]
General-purpose LLMs are impressive. They can write code, summarize documents, answer questions, and translate between languages with reasonable accuracy. But "reasonable" is not good enough when your application requires consistent output format, domain-specific terminology, a particular tone, or behavior that the base model was never trained to exhibit. That gap is where fine-tuning matters. Fine-tuning updates a model's weights on your specific data, changing how the model behaves — not
Read More: LLM Fine-Tuning Guide: Custom Model Training with LoRA and QLoRA [2026]Computer Vision Applications: Object Detection, OCR, and Industrial AI [2026]
Computer vision has moved well past the research phase. The models are trained, the frameworks are mature, the hardware is accessible, and the use cases are generating measurable returns. What was a specialized capability requiring deep expertise in 2018 is now deployable infrastructure — if you know which component to reach for and where the real complexity lives. This guide covers computer vision applications across industrial, medical, logistics, and document processing domains. It expl
Read More: Computer Vision Applications: Object Detection, OCR, and Industrial AI [2026]