How to Build a Telemedicine Platform (2026)

A mental health startup ships a telehealth MVP in 14 weeks. Three months later, they discover their video session recordings are stored in an S3 bucket without server-side encryption. A third-party analytics tool they added for user tracking was processing patient names from the session metadata. Both are HIPAA violations. Both were architectural decisions made in the first two weeks of the build.

This is the most common failure mode in telemedicine development: treating compliance as a final step rather than a design constraint. This guide covers how to avoid it, and what it actually takes to build a telemedicine platform that works in production.

What "telemedicine platform" actually means

McKinsey estimates that up to $250 billion of current US healthcare spend could move to virtual care, and clinical adoption is already there. A telemedicine platform connects patients with licensed healthcare providers via video, messaging, or asynchronous consultation. The market includes direct-to-consumer apps, white-label tools that clinics use under their own brand, and specialty platforms focused on mental health, dermatology, or chronic disease management.

Your buyer is a digital health founder, a specialty clinic director, or a health system CIO. They want a platform that handles scheduling, video, clinical documentation, and billing, without creating compliance liability.

The US regulatory environment shapes every architectural choice. HIPAA governs patient data. State medical licensing governs where providers can practice. DEA registration governs e-prescribing for controlled substances. You can't build around these rules. You build with them.

"The fatal error in telehealth platform development is treating HIPAA as a legal checkbox rather than an engineering discipline. By the time your security team finds the PHI in your application logs, you've already had a reportable incident." - Eric Topol, Director of the Scripps Research Translational Institute, in Deep Medicine (2019)

Core features: MVP vs. full product

MVP (ship first):

1. Provider profiles and availability: specialty, bio, license states, calendar blocks
2. Patient appointment booking: specialty filtering, insurance or direct pay, appointment reminders via SMS
3. HIPAA-compliant video consultation: waiting room, provider-initiated session start, fallback to phone
4. Secure encrypted messaging: async follow-up between patients and providers
5. Basic EHR: SOAP visit notes, diagnosis codes, prescription records (not e-prescribing, just documentation)

Full platform (add after proving the product):

• Multi-specialty routing: match patients to providers by specialty, license state, and insurance network

• Group therapy sessions: multi-participant video for behavioral health

• Asynchronous consultation: photo and text submission for dermatology and other visual specialties

• E-prescribing via Surescripts (or DrFirst/Rcopia for faster integration)

• Lab order integration: send orders to Quest, LabCorp, or local labs

• Insurance billing: EDI 837 claims submission, ERA 835 remittance processing, CPT code mapping

• Patient mobile app: iOS and Android with wearable data ingestion

• Patient identity verification: Persona, Jumio, or Stripe Identity at onboarding

The architecture

HIPAA compliance

HIPAA is the governing constraint. Before choosing any vendor or designing any data flow, ask: does this component touch protected health information (PHI)?

PHI includes names, dates of service, diagnosis codes, prescription information, and any other data that could identify a patient in connection with their health. The governing rule: every vendor that touches PHI must sign a Business Associate Agreement (BAA) with you.

Your checklist:

• Video provider: Daily.co and Vonage both offer HIPAA BAAs and WebRTC-based infrastructure. Zoom for Healthcare also works. Do not use standard Zoom or Google Meet. They do not offer BAAs for their standard plans.

• Cloud host: AWS, GCP, and Azure all have HIPAA-eligible services. Enable them explicitly. Default configurations are not HIPAA-eligible.

• Encryption at rest: AES-256 on all data stores. Enable SSE-KMS on AWS RDS and S3.

• Encryption in transit: TLS 1.2 or higher on all connections, including internal service-to-service traffic.

• Access logs: retain for 6 years per HIPAA requirements. Use AWS CloudTrail and CloudWatch.

Video consultation

Use Daily.co or Vonage. Both have native waiting room support. The patient joins and waits, the provider sees the notification, and the provider explicitly admits the patient to start the session.

This is not optional architecture. A video call that starts automatically when both parties join creates a liability if the provider is not ready or if the wrong patient joins.

Session recording is available on both platforms but requires explicit patient consent before each session. If you enable recording, store recordings in S3 with SSE-KMS and signed URLs only. Never store recordings in a publicly accessible bucket.

Build a phone call fallback. Video fails. Rural patients have poor connections. If the video session cannot be established within 60 seconds, offer a phone call option.

Scheduling and matching

Patients select providers by specialty, availability, and (if you support insurance) payer network. Provider calendars sync via iCalendar format. Store availability as time blocks in PostgreSQL, not as iCal feeds. The iCal sync is for external calendar tools (Google Calendar, Outlook), not your internal booking engine.

Appointment reminders via Twilio SMS are standard. The critical rule: SMS cannot contain PHI. A compliant reminder says "You have an appointment on May 24 at 2:00 PM" with a link to the portal. It does not say the provider's name, the reason for the visit, or the diagnosis. This rule catches teams by surprise. Build it into your notification templates from the start.

EHR and visit notes

Use SOAP format for visit notes: Subjective (patient's reported symptoms), Objective (provider observations and vitals), Assessment (diagnosis), Plan (treatment and next steps). Store notes as structured JSON in PostgreSQL.

For interoperability with hospital systems, use HL7 FHIR R4 as your data model. FHIR is the US standard for electronic health record exchange. If you need to pull patient history from a hospital's EHR or send visit summaries to a referring physician, FHIR is the format that makes that possible. This is not required for MVP but should inform your data model early.

Render visit notes as PDFs on demand using Puppeteer. Store the PDF in S3 with a signed URL for provider download.

E-prescribing

Surescripts is the US e-prescribing network. Every major pharmacy accepts electronic prescriptions through Surescripts. The integration requires:

• DEA registration for controlled substance prescribing

• State medical board approval in each state where providers will prescribe

• Surescripts certification process: budget 6-8 weeks and $20K-$40K

If that timeline is too long for your MVP, use DrFirst (Rcopia). It provides a pre-built e-prescribing module you embed via an iframe or SDK. You skip the direct Surescripts integration. The trade-off: less control over the UX and an ongoing per-prescription cost.

State medical licensing

A physician licensed in California can only practice telehealth for California patients. This is not a gray area. The provider's license state must match the patient's state at the time of the consultation.

Build license tracking into your routing logic. Store each provider's active licenses as a state list. When a patient in Texas books an appointment, only route to providers with an active Texas license.

The Interstate Medical Licensure Compact (IMLC) simplifies multi-state licensing for physicians who want to practice in multiple states. Not all states participate. Track IMLC membership in your provider data model. It speeds up onboarding for providers who want broad geographic coverage.

Insurance billing

Skip insurance billing for MVP. It is the most complex part of the platform and has the longest integration timeline.

When you add it, the US standard format is EDI 837 for claims submission and EDI 835 for remittance (payment) processing. CPT codes for telehealth: 99441-99443 for telephone-only consultations, 99211-99215 for video consultations. Clearinghouses like Availity or Change Healthcare handle the EDI translation between your system and payers.

Direct pay is simpler: Stripe for card processing, with an optional Stripe Connect integration if providers operate as independent contractors on your platform.

Identity verification

HIPAA and SOC 2 both require that patients are who they say they are. Use Persona, Jumio, or Stripe Identity for document-based ID verification at onboarding. One verification per patient account is sufficient. You do not need to re-verify at each appointment.

The hardest technical challenge

HIPAA compliance is not a feature you add at the end. It is the design constraint that shapes every architectural decision from the first line of code.

The HHS Office for Civil Rights reported over $134 million in HIPAA enforcement settlements between 2003 and 2023, with settlements increasing 70% in the last five years. The most common mistakes:

• Video session logs contain PHI (patient names in session metadata, visit reason in the room title). Requires a full data audit and migration to fix post-launch.

• SMS appointment reminders include patient names or provider names. Violates HIPAA. Every template must be audited.

• A third-party analytics tool (Google Analytics, Mixpanel, Segment) is tracking events on pages that display patient data. This is a HIPAA violation unless that vendor has signed a BAA with you. Most analytics vendors will not sign a BAA for standard plans.

• PHI in application logs. A developer adds a debug log that prints the full request body, which contains a patient's name and appointment reason. Disable full request body logging in production.

Start with a threat model before writing the first line of code. Map every data flow: where does PHI enter the system, where does it move, where does it rest, and who can access it at each point. This takes a day. It prevents weeks of remediation.

Build timeline and cost

MVP: booking, HIPAA video, basic EHR, direct pay

• Timeline: 18-22 weeks

• Cost: $160K-$280K

Full platform: e-prescribing, insurance billing EDI, mobile apps

• Timeline: 30-40 weeks

• Cost: $350K-$600K

Infrastructure: $2K-$8K per month at launch. Scales with consultation volume. Primary cost drivers are video infrastructure (Daily.co or Vonage per-minute pricing), RDS compute, and Twilio SMS volume.

Build vs. buy

Before committing to a custom build, check what the established tools cover:

Doxy.me: $35 per month per provider for HIPAA-compliant video. Not a full platform. No EHR, no booking, no billing. Good as a video component but not a product.

Healthie: $299-$2,000 per month. Covers EHR, telehealth video, and patient booking for clinics. Limited customization and no white-label option.

Mend: $300+ per month. Telehealth plus intake automation. Strong for single-specialty clinics. No white-label.

Teladoc: B2C consumer product. Not available as a white-label platform for third parties.

Build custom when:

• You need specialty-specific workflows that standard platforms do not support (mental health crisis protocols, dermatology async photo review with clinical decision support, occupational health with employer reporting)

• You need insurance billing integrated with your own revenue cycle workflow

• You are building a white-label platform to license to multiple provider groups or health systems

• Your go-to-market depends on a branded patient experience the existing tools cannot deliver

Tech stack

Video: Daily.co (preferred, simpler HIPAA BAA process, good SDK) or Vonage. Both are WebRTC-based.

Frontend: React for the web app. React Native for the patient mobile app and provider mobile app.

Backend: Node.js or Python/FastAPI. Python has stronger medical data libraries and is worth choosing if your team has Python experience or if you plan to add ML-based clinical features later.

Database: PostgreSQL with PHI encrypted at the column level for the most sensitive fields, or AWS RDS with encryption enabled at the storage layer.

File storage: AWS S3 with SSE-KMS. Signed URLs only. Never grant public read access to any bucket that contains patient documents.

Auth: MFA required for all provider accounts. JWT with 15-minute access token expiry. Refresh tokens stored in httpOnly cookies only, never localStorage.

Messaging: Secure E2E encrypted messaging built on Signal Protocol, or a HIPAA-compliant chat SDK. CometChat and Sendbird both offer HIPAA-eligible plans with BAAs.

Notifications: Twilio for non-PHI SMS appointment reminders. SendGrid for email. All templates must be reviewed against the PHI content rule before deployment.

Hosting: AWS with HIPAA-eligible services enabled: RDS, S3, CloudTrail, CloudWatch. Enable AWS Config for continuous compliance monitoring.

If you are building a telemedicine platform for a specialty clinic, a digital health startup, or a hospital system adding telehealth capability, RaftLabs has built HIPAA-compliant digital health products at this scale. We can help you scope the architecture and avoid the compliance mistakes that derail most early builds. See our work in SaaS application development or conversational AI for healthcare.