Telehealth Platform Development: Architecture for Video Visits, Scheduling, and Clinical Documentation

Telehealth grew from a niche offering to a mainstream care delivery channel between 2020 and 2022, and the market has since bifurcated sharply: platforms built hastily during the pandemic, showing their limitations, and platforms built with clinical workflow in mind, becoming the default channel for certain care types. Building in the second category requires understanding what telehealth platforms actually need to do beyond the video call.

This post covers the architecture of a production telehealth platform: the technical components, the HIPAA considerations at each layer, and the clinical workflow decisions that determine whether the platform actually improves patient care.

The clinical workflow model

A telehealth visit has a different lifecycle than an in-person visit, and the platform architecture must reflect that lifecycle. The stages:

1. Scheduling: Patient books an appointment, self-service or via staff. Availability is checked against provider schedules. Insurance eligibility may be verified before or after booking.
2. Pre-visit intake: Patient receives intake forms (demographics update, chief complaint, medication list, consent to telehealth). Completed intake is available to the provider before the visit begins.
3. Pre-visit preparation: Provider reviews intake, previous visit notes, and relevant history. The platform surfaces relevant information without requiring the provider to navigate through the EHR.
4. The video visit: Provider and patient connect. The session is recorded if the patient consents (and state law permits). Provider may share screen (for showing imaging, test results, patient education materials).
5. Clinical documentation: During or immediately after the visit, the provider completes the visit note, orders any tests or prescriptions, and sets the follow-up plan.
6. Post-visit: Visit summary sent to patient. Referrals routed. Orders transmitted to lab, pharmacy, or specialist. Documentation synced back to the EHR.

Platforms that focus exclusively on the video call and treat everything else as an afterthought end up with providers doing workarounds: completing notes in a separate EHR, managing their own follow-up, and losing the efficiency gains that telehealth should deliver.

Video infrastructure

Build vs buy for video

Building a WebRTC-based video stack from scratch is possible, but it is an enormous undertaking. For most telehealth platforms, the right decision is to use a HIPAA-compliant video SDK or platform (Twilio Video, Daily.co, or Amazon Chime SDK) and build the clinical workflow around it.

The HIPAA requirement: the video provider must sign a BAA. Twilio Video, Daily.co, Amazon Chime, and Zoom for Healthcare all offer BAAs for healthcare use cases. Zoom's standard consumer product does not have a BAA and should not be used for telehealth.

Video session architecture with Twilio Video

// Generate access token for a video session
async function createVideoSessionToken(
  participantId: string,
  roomId: string,
  role: 'patient' | 'provider'
): Promise {
  const identity = `${role}:${participantId}`

  const token = new AccessToken(
    TWILIO_ACCOUNT_SID,
    TWILIO_API_KEY_SID,
    TWILIO_API_KEY_SECRET,
    { identity, ttl: 3600 }  // 1 hour max session length
  )

  const videoGrant = new VideoGrant({
    room: roomId,
  })

  token.addGrant(videoGrant)
  return token.toJwt()
}

// Create the room with HIPAA-appropriate settings
async function createVideoRoom(appointmentId: string): Promise {
  const room = await twilioClient.video.rooms.create({
    uniqueName: `appt-${appointmentId}`,
    type: 'group',
    recordParticipantsOnConnect: false,  // record only with explicit consent
    statusCallback: `${API_BASE}/webhooks/video-status`,
  })
  return room.sid
}

Two operational details that matter in production. First, the waiting room is a state machine, not a UI page: the patient joins, the provider is notified, and the session begins only when the provider admits the patient. Second, connection quality degrades on real patient networks; the platform needs an automatic audio-only fallback and a documented telephone fallback, because a failed video visit that becomes a completed phone visit is billable and clinically useful, while a dropped call is neither.

Pre-visit intake and PHI handling

Intake data is PHI from the moment the patient types it. That means encryption in transit and at rest, field-level access controls, and an audit trail of who viewed what. The intake service should write to the same audit log schema the rest of the platform uses; the requirements are covered in our HIPAA technical safeguards checklist, and they apply to drafts and abandoned forms as much as submitted ones.

Design intake as structured data, not a PDF upload. Structured chief complaint, medication list, and allergy data can pre-populate the visit note, drive clinical decision support, and sync to the EHR as discrete fields. A PDF can do none of those things.

EHR integration

A telehealth platform that does not talk to the EHR creates double documentation, and providers will abandon it. The integration surface is typically:

• Read: patient demographics, problem list, medication list, allergies, and recent encounters, to give the provider context without switching systems
• Write: the completed visit note, orders, and billing codes back to the patient's chart
• Scheduling sync: telehealth slots visible in the practice's existing scheduling system

For modern EHRs this means FHIR R4 APIs; for older installations it means HL7 v2 interfaces over a VPN or an integration engine. The differences, and when you will be forced to use each, are covered in our HL7 FHIR vs HL7 v2 integration guide. Budget integration effort per EHR, not per standard: two Epic sites can differ more than an Epic and an Athena site.

Clinical documentation and AI assistance

Documentation is where telehealth platforms win or lose provider adoption. The target is a visit note that is 80% complete when the provider opens it: intake data pre-populated, relevant history summarized, and the provider dictating or typing only the assessment and plan.

AI-assisted SOAP note generation from the visit transcript is now practical, with two hard constraints. The transcription and generation pipeline must be covered by BAAs end to end, and the provider must review and sign every generated note; the AI drafts, the clinician attests. Grounding the generation in the transcript and intake data, with the anti-hallucination guardrails we use in healthcare AI work, keeps the draft trustworthy enough to actually save time.

Compliance summary by layer

Layer	Primary HIPAA concern	Mitigation
Video	Session content is PHI	BAA-covered video provider, no consumer tools, consent-gated recording
Intake	PHI at rest in form data	Encryption at rest, field-level access control, audit logging
Documentation	Notes and transcripts	BAA-covered transcription/AI vendors, provider attestation
EHR integration	PHI in transit between systems	TLS 1.2+, VPN for HL7 v2 feeds, minimum necessary data scoping
Notifications	PHI leakage into SMS/email	Content-free notifications ("You have a message") linking into the authenticated app

Where to start

The build order that has worked for us: scheduling and intake first (they create the data spine), video second (it is the most commoditized layer), documentation and EHR sync third (they determine provider adoption), and AI assistance last (it multiplies a working workflow but cannot rescue a broken one). A care team that already coordinates through a shared platform, like the one in our care coordination case study, has a natural home for telehealth as an additional encounter type rather than a separate silo.

If you are scoping a telehealth build, whether a standalone platform or a virtual care channel inside an existing product, our healthcare software development team has shipped the full stack described here, BAAs and EHR interfaces included.