What You Will Get In This Article -
Your clinic group wants to offer remote consultations. Your digital health startup has a clear use case and investors ready. You've picked a name, maybe even designed the logo. Now someone asks: what does it actually take to build the platform?
Most telehealth builds go wrong not because the idea was bad, but because the team underestimated two things - the compliance surface area and the infrastructure complexity. A video call between patient and doctor sounds simple. Add HIPAA requirements, EHR data exchange, prescription workflows, multi-state licensing rules, and real-time queue management across device types, and you're looking at a system that can take 12–18 months to build right.
By the end of this guide, you'll know exactly how to build a telehealth platform - what the architecture looks like, which technology choices are non-negotiable, where the real complexity hides, and what to build vs. buy at each layer.
Why Most Telehealth Platforms Fail Before They Scale
The group of failed telehealth products is full of platforms that worked perfectly in a demo environment. The video connected. The calendar showed available slots. The doctor could see the patient. But your own workflow, real usage, time duration for tele-consultations calls etc business details are missing.
Compliance is not a feature you add later. HIPAA (Health Insurance Portability and Accountability Act) governs how you store, transmit, and access Protected Health Information (PHI). Every vendor in your stack that touches PHI needs a signed Business Associate Agreement (BAA). That includes your video provider, your cloud hosting, your messaging layer, and your analytics platform. Building the product first and adding compliance later is far more expensive than designing for it from day one.
The EHR integration is always harder than estimated. Connecting to a clinic's existing Electronic Health Record system — Epic, Cerner, athenahealth, eClinicalWorks — is not a weekend API project. HL7 FHIR R4 is the standard, but each EHR vendor's implementation has quirks, rate limits, scoping rules, and certification requirements.
Async and sync are two completely different product surfaces. Synchronous telehealth (live video consultations) and asynchronous telehealth (store-and-forward, where a patient submits photos and symptoms and a clinician reviews later) have fundamentally different architecture, workflow, and regulatory treatment. Most platforms try to serve both from a single codebase and end up doing neither well.
If you're at the architecture stage of your telehealth product, CoreFragment's healthcare app and IoT development team has built medical device dashboards, glucometer data platforms, and healthcare analytics systems — and can help you avoid the expensive mistakes before you commit to a stack.
Choosing Your Telehealth Architecture: Monolith vs. Microservices
The first architectural decision — monolith or microservices determines your deployment complexity, your team structure, and how fast you can iterate.
For most telehealth MVPs, start with a modular monolith. A single, well-structured backend application with clearly separated modules (appointments, video sessions, messaging, prescriptions, billing) is easier to build, deploy, and debug at the early stage. You can extract services later when traffic patterns and team size justify the overhead.
Move toward microservices when:
Your video infrastructure, notification service, or EHR sync layer has distinctly different scaling requirements
Your team grows beyond 10 engineers and service ownership becomes necessary
Compliance audit trails benefit from isolated, independently deployable services
The mistake most teams make is jumping to microservices at MVP because it "feels more scalable." The result is distributed complexity without distributed benefit - 15 services talking to each other with no traffic to justify the architecture.
Core Architecture Layers
Every telehealth platform needs these six layers, regardless of monolith or microservices:
Layer | What It Does |
|---|---|
Identity & Auth | Patient and provider login, MFA, session management |
Scheduling Engine | Calendar management, slot availability, booking, reminders |
Video Infrastructure | Real-time audio/video consultation |
EHR Integration | Clinical data exchange with existing records systems |
Messaging & Notifications | In-platform chat, SMS reminders, push notifications |
Billing & Claims | Insurance verification, co-pay collection, claims submission |
Building the Video Layer: What WebRTC Actually Requires
Video is the centrepiece of synchronous telehealth. Most teams either over-engineer it (building their own WebRTC signalling server) or under-engineer it (embedding a generic video SDK without thinking about clinical context).
WebRTC (Web Real-Time Communication) is the open protocol that powers peer-to-peer audio/video in browsers and mobile apps. Every major video SDK — Twilio Video, Daily.co, Amazon Chime — sits on top of WebRTC. The protocol handles peer connection negotiation, ICE (Interactive Connectivity Establishment) for NAT traversal, and SRTP (Secure Real-Time Transport Protocol) for media encryption.
For most telehealth platforms, use a managed WebRTC SDK rather than building on raw WebRTC. Here's why: NAT traversal alone requires STUN/TURN server infrastructure, and maintaining that at any meaningful session volume is operationally expensive. Twilio and Daily.co handle STUN/TURN, regional media routing, recording, and transcription — all with HIPAA BAAs available.
Recommendation: For a first telehealth product, Daily.co or Twilio Video is the right call because they provide BAAs out of the box, have solid uptime SLAs, and remove the burden of managing media infrastructure. Self-hosting Jitsi only makes sense once you're at a volume where per-minute costs become significant and your DevOps team is equipped to manage the compliance obligations.
Clinical-Specific Video Requirements
A telehealth video session is not a Zoom call. Your video layer needs to handle:
Waiting room logic: Patient enters a virtual waiting room; provider joins and admits them. State management here is non-trivial — handle dropped connections, timeout logic, and re-join flows.
Session recording consent: Most jurisdictions require explicit patient consent before recording. Build consent capture into the pre-session flow, not as an afterthought.
Bandwidth degradation handling: Rural patients on poor connections are a primary use case for telehealth. Your video layer should gracefully downgrade resolution and frame rate rather than dropping the call.
In-session document sharing: Doctors frequently need to share imaging results, prescription information, or care plans during a session. Screen sharing alone is insufficient — build a structured document sharing panel.
HIPAA Compliance: What You Actually Need to Implement
HIPAA compliance is not a checklist you submit to a regulator. It's a set of technical and organisational safeguards you implement and maintain continuously. The technical safeguards that directly affect your platform build are:
Encryption at rest and in transit. All PHI stored in your database must be encrypted at rest — AES-256 minimum. All data in transit must use TLS 1.2 or higher. This applies to API calls, WebSocket connections, and file storage. Storing patient notes in an unencrypted S3 bucket is a HIPAA violation regardless of how the bucket is permissioned.
Access controls and audit logging. Every access to PHI must be logged — who accessed what record, at what time, from what IP. Role-based access control (RBAC) must ensure a front-desk administrator cannot read clinical notes. Build audit logging from day one into your data access layer, not as a middleware wrapper you add later.
Business Associate Agreements. Every vendor that stores or processes PHI on your behalf requires a signed BAA. This is a legal agreement that makes them responsible for their portion of PHI handling. Common services that require BAAs in a telehealth stack: AWS (available via console), Twilio, SendGrid, Stripe (limited scope), and any analytics tool that receives session data.
Minimum necessary standard. Don't expose more PHI than a given role needs. Your API responses should return only the fields required for each endpoint's purpose. Don't return a full patient record when a booking API only needs name and appointment slot.
EHR Integration: The Layer That Takes Longest
Connecting your telehealth platform to a clinic's EHR is where most timelines slip. Understanding why helps you plan for it.
HL7 FHIR R4 (Fast Healthcare Interoperability Resources) is the current standard for healthcare data exchange. FHIR defines resource types — Patient, Appointment, Observation, MedicationRequest, Encounter — and a RESTful API for reading and writing them. In theory, any FHIR R4-compliant EHR exposes the same API. In practice, Epic's FHIR implementation, Cerner's implementation, and athenahealth's implementation all have differences in scope, rate limiting, and authentication requirements.
SMART on FHIR is the OAuth 2.0-based authorisation framework layered on top of FHIR. Use SMART on FHIR for launching your app from within an EHR context (a doctor opens your telehealth platform directly from Epic) and for patient-facing access to their own records.
What Takes the Most Time in EHR Integration
EHR sandbox access and credentials: Getting developer access to Epic or Cerner's sandbox environment takes 2–4 weeks and requires an application review
Scope approval: Read/write scopes for clinical data (especially MedicationRequest and DiagnosticReport) require clinical justification and sometimes CURES Act compliance review
Data mapping: Your internal data model will not map cleanly to FHIR resources — building a robust transformation layer takes time
Testing against production data: Sandbox environments don't always behave like production — budget for a production validation phase
Telehealth Platform Development: Decision Checklist
Before committing architecture and budget, verify each of these:
Sync vs. async scope defined: Are you building live video consultations, asynchronous store-and-forward, or both? Each has different infrastructure, regulatory treatment, and UX requirements. Don't conflate them.
PHI boundary mapped: List every service in your stack that will touch PHI. For each one, confirm a BAA is available and obtain it before building that integration.
Video provider BAA confirmed: Never build video infrastructure into your product with a provider that doesn't offer a HIPAA BAA. No exceptions.
EHR integration scope and timeline confirmed with the target clinic: Don't estimate EHR integration based on the API docs alone — talk to the clinic's IT team about their existing setup, version, and any existing third-party integrations.
Audit logging designed in the data layer: Retrofitting audit logging after the fact means touching every data access point in your codebase. Build it in from the start.
Patient consent flows designed: Consent for recording, consent for data sharing with insurance, consent for treatment — all must be captured, timestamped, and stored. Design the consent data model before you design the booking flow.
Multi-state licensing considered: If your platform operates across US states, provider licensing is per-state. Your scheduling system needs to match provider license jurisdiction with patient location. Build this constraint into the data model early.
Mobile vs. web strategy decided: Telehealth works on web browsers (WebRTC is fully supported in Chrome and Safari) and native mobile apps. A React Native or Flutter app covers both platforms and can use native WebRTC bindings. Decide before starting frontend development.
Conclusion
Building a telehealth platform is a full-stack product engineering challenge, not just a mobile app with a video call bolted on. The compliance architecture, EHR integration layer, video infrastructure, and clinical workflow design all need deliberate decisions made before a line of code is written.
The teams that ship successful telehealth products are the ones who map their PHI boundary before picking vendors, choose a video provider with a HIPAA BAA before building any consultation flow, and scope their EHR integration with real input from the target clinic's IT team, not just the public API docs.
If you're building a telehealth platform and want to validate your architecture, tech stack, or compliance approach before committing to a build - CoreFragment's healthcare app and web development team has built medical device dashboards, patient-facing mobile apps, and healthcare analytics platforms. We can review your stack and tell you where the gaps are before they become schedule problems.