Telemedicine Platform Development: Video, Scheduling, Records and Payments

A telemedicine platform is seven parts: video, scheduling, intake, visit notes, e-prescribing, payments and records access. Rent the video from a WebRTC provider (Twilio lists group video at $0.004 per participant-minute), integrate e-prescribing, and build the clinical workflow yourself. A 20-minute two-person visit then costs about 16 cents in video. The engineering effort goes into scheduling, access control and audit logging.

If you would rather have it built for you, see how RAITHub would build this, at the end of this guide.

What does a telemedicine platform actually need?

A patient books a slot, fills in an intake form, joins a video visit at the booked time, and later sees a visit summary and pays. A clinician sees a schedule, reads the intake, runs the visit, writes notes and, where licensed, sends a prescription. Everything else is administration around those two journeys.

The table below splits the platform into components and says which ones you should build and which you should rent. The short version: build the parts that define your service, and integrate the parts that are regulated, commoditised or both.

Component	What it does	Build or integrate?	Engineering notes
Video	Real-time audio and video, screen share, waiting room	Integrate a WebRTC provider	Short-lived join tokens per visit; no patient names in room names or logs
Scheduling	Clinician availability, booking, reminders, cancellations	Build (or integrate a calendar service)	Time zones and double-booking prevention are the hard parts
Intake	Pre-visit forms, consent, symptoms, history	Build	Versioned forms; record which version each patient saw and signed
Visit notes	Clinician notes, summaries, follow-up tasks	Build, or write into a partner EHR	Append-only edits with author and timestamp
E-prescribing	Sending prescriptions to pharmacies	Integrate a certified e-prescribing vendor	Never build this yourself; the network connections and certification are the product
Payments	Visit fees, subscriptions, refunds, insurance co-pays	Integrate a payment provider	Keep diagnosis and visit reason out of payment descriptions
Records access	Patients view summaries, documents and prescriptions	Build	Log every read, not only every change; support proxy access for carers

Which video API should a telehealth platform use: Daily, Twilio or Vonage?

All three provide WebRTC video through hosted infrastructure and SDKs, so you do not run your own media servers. The practical differences are price, how you get a Business Associate Agreement (BAA, the contract HIPAA requires with vendors handling patient data), and how much prebuilt interface you get.

Provider	Published video price	HIPAA route	Notes
Daily	$0.0015–$0.004 per participant-minute with volume discounts, and 10,000 free minutes a month (Daily pricing)	A healthcare add-on at $500 a month that includes a BAA (same page)	Cloud recording is priced separately, at $0.01349 per recorded minute
Twilio Video	$0.004 per participant-minute for group rooms of up to 50 people (Twilio pricing)	Video is listed as HIPAA eligible; a BAA needs Twilio's Security or Enterprise Edition (Twilio HIPAA page)	Recording, compositions and transcription are billed as extras
Vonage Video API	Published on Vonage's pricing page; check it for current rates	Confirm the BAA terms with Vonage sales	Web, mobile and server SDKs, recording, captions and broadcasting (Vonage developer docs)

For most first versions the price per minute is not the deciding factor. At Twilio's published rate, 10,000 two-person visits of 20 minutes each come to 400,000 participant-minutes, or about $1,600 in video. The BAA route, the recording policy your clinicians want, and how well the SDK behaves on weak mobile connections matter more. Test on a real phone on a congested network before you commit.

How do you stop the wrong person joining a video visit?

Make every room private, and issue a short-lived join token from your server only after checking that the user is the patient or clinician on that visit. Here is a minimal TypeScript version using Daily's meeting-token API. The token cannot be used before the visit window opens and the user is removed when it expires.

// Server only. The caller has already checked that userId is
// this visit's patient or clinician.
type Visit = { id: string; roomName: string; startsAt: Date; durationMin: number }

export async function createJoinToken(
  visit: Visit,
  userId: string,
  isClinician: boolean,
): Promise<string> {
  const now = Math.floor(Date.now() / 1000)
  const start = Math.floor(visit.startsAt.getTime() / 1000)
  const end = start + visit.durationMin * 60
  const opens = start - 10 * 60 // waiting room opens 10 minutes early

  if (now < opens || now > end) throw new Error('Outside the visit window')

  const res = await fetch('https://api.daily.co/v1/meeting-tokens', {
    method: 'POST',
    headers: {
      Authorization: 'Bearer ' + process.env.DAILY_API_KEY,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      properties: {
        room_name: visit.roomName, // an opaque ID, never the patient's name
        user_id: userId,           // your internal ID, 36 characters or fewer
        is_owner: isClinician,
        nbf: opens,
        exp: end + 15 * 60,        // allow a visit to overrun by 15 minutes
        eject_at_token_exp: true,
      },
    }),
  })
  if (!res.ok) throw new Error('Token request failed: ' + res.status)
  const data = (await res.json()) as { token: string }
  return data.token
}

Two details matter here. Daily saves user_name in its meeting events log, so pass a first name or role, not a full name with a diagnosis attached. And log the token issue in your own audit trail, so you can later show who was let into which visit and when.

How should scheduling, intake and visit notes work?

Scheduling is where most telemedicine bugs live. Store every time in UTC, store the clinician's and patient's time zones separately, and enforce one booking per clinician per slot in the database, not only in the interface, so two patients cannot book the same slot at the same moment. Reminders by email or SMS should say "your appointment" and a time, never the reason for the visit.

Intake forms change often, because clinicians keep refining them. Version every form, and store the version each patient completed alongside their answers and any consent they gave. When a form changes, old answers must still render exactly as the patient saw them.

Visit notes should be append-only: a correction is a new entry with an author and a timestamp, not an overwrite. That makes them defensible later, and it is the same pattern as a good audit log, described in how to design an audit log. If your clinicians already use an electronic health record (EHR), writing notes into it may beat building your own notes module; that usually means an HL7 FHIR integration, covered in the HealthTech software guide.

How does e-prescribing fit into a telemedicine app?

As an integration, never as something you build. E-prescribing vendors such as DoseSpot provide certified prescribing, including controlled substances, with options from a full API integration to a plug-and-play interface. They carry the pharmacy network connections and the certification work, which you cannot reasonably reproduce.

In the US, electronic prescribing of controlled substances adds DEA requirements, including identity proofing and two-factor authentication for prescribers, set out in 21 CFR Part 1311. Let the vendor handle that flow, and keep your own role checks in front of it so only a clinician with prescribing rights ever reaches it. Outside the US the rules and networks are national, so pick the vendor by market.

How do payments and records access work?

Payments for a cash-pay telehealth service are a standard card integration: a fee at booking, a hold or charge rule for no-shows, and refunds. The health-specific rule is to keep clinical detail out of the payment provider. A charge description of "Video consultation" is fine; "Consultation: anxiety follow-up" puts health information into a system that may not be covered by a BAA. Insurance billing is a separate, much larger project. Webhook handling for payments is covered in testing payments and webhooks.

Records access means patients can see visit summaries, documents and prescriptions, and sometimes carers can see them on a patient's behalf. Each relationship (parent, guardian, carer) needs explicit rules and an expiry. Log every view of a record, not only every edit. Role design for this is covered in how to design RBAC.

What privacy rules apply to a telemedicine platform in the US, EU and UK?

General information; confirm with your adviser. This section is engineering context, not legal advice. Whether a law applies to your service, and what it requires of you, is a question for a qualified privacy or compliance professional in each market you serve.

United States: HIPAA

If you are a covered entity (for example a provider who bills electronically) or a business associate of one, the HIPAA Security Rule's technical safeguards apply to electronic protected health information: access control, audit controls, integrity, person or entity authentication and transmission security, listed in 45 CFR 164.312. Encryption is an "addressable" specification there, which in practice means you document your decision, and most teams encrypt.

A covered entity must have written assurances, usually a BAA, from vendors that handle PHI on its behalf (45 CFR 164.502(e)). For a telemedicine stack that typically means your hosting, video, e-prescribing, email or SMS, and error-tracking vendors. HHS publishes its guidance on HIPAA and telehealth; the COVID-era enforcement discretion that let providers use ordinary consumer video tools ended with the public health emergency in May 2023, so plan for BAA-covered vendors from the start.

European Union and United Kingdom: GDPR and UK GDPR

Data concerning health is special-category data. GDPR Article 9 prohibits processing it unless one of the listed conditions applies, on top of an ordinary lawful basis. The UK's regulator, the ICO, explains that health data includes appointment details and test results, not only diagnoses, in its special category data guidance. For a telehealth product the booking record itself can therefore be health data.

Engineering consequences are similar in both regimes: data minimisation, least-privilege access, read logging, encryption, a documented list of every vendor that touches patient data, and a way to export or delete a patient's data on request.

Buy, build or hire: which route fits your telehealth service?

Route	Example	Choose this when	Watch out for
Off-the-shelf telehealth tool	doxy.me (free plan; paid plan includes a BAA), or a practice suite such as SimplePractice ($49–$99 a month for a solo practitioner)	You are a practice that needs to see patients online this month, and the workflow is standard	You cannot change the patient journey, and your data model is the vendor's
Template or low-code with a video API	A prebuilt video interface from Daily embedded in a low-code front end, plus a hosted scheduler	You are testing demand for a new service with one clinic and a few clinicians	Each tool needs its own BAA; access control and audit logs are hard to make consistent across tools
Custom build	Your own web app or PWA, with rented video and e-prescribing	Telehealth is your product: several clinics, your own triage or pricing, or workflows no suite supports	Highest upfront cost, and you own security and maintenance

If you are a single practice, buy. Custom only pays off when the platform is the business.

Why RAITHub for this

RAITHub is a founder-led, QA-first software studio founded in 2024 in Dhaka, Bangladesh, working with clients worldwide in English. Its health experience is stated plainly: a healthcare scheduling app built for a client, among 8 client projects. RAITHub has not shipped a regulated health product, and it does not claim to.

• Scheduling, roles and payments, already built. PropDesk, a property management platform, has 4 roles, Stripe rent collection and 1,024 automated tests. Booking, role checks and payment webhooks are the same engineering problems in a telehealth app.
• Data isolation in the database. Sundor Skin runs on 146 PostgreSQL tables with row-level security and 530+ tests, so one user's records cannot leak into another's screen because of a single missed check.
• PWAs that work on phones. PadhAI, an AI tutoring platform RAITHub built, ships as a PWA with 9 payment gateways. RAITHub builds web apps and PWAs only, not native mobile apps, which suits telehealth: patients join from a browser link.
• Your data stays in your account. RAITHub signs NDAs and DPAs and works inside your controls. Production and patient data stay in your own covered cloud account; development uses synthetic data.

When you don't need us

• You run one practice with a standard workflow. An off-the-shelf tool with a BAA will be faster and lower-cost than any custom build.
• You need a vendor with shipped regulated health products. If your buyers or investors expect that track record, hire a specialist health-software firm.
• You need native iOS or Android apps. RAITHub does not build them.
• You want the developer to own compliance. RAITHub builds to your compliance reviewer's requirements; it does not interpret HIPAA or GDPR for you, and it is not SOC 2 or ISO 27001 certified.
• You need developers placed in your team. RAITHub offers fixed-scope builds and dedicated teams, not staff augmentation.

How RAITHub would build this

• Scope: a web app and PWA with patient and clinician portals, scheduling with database-enforced slots, versioned intake and consent, and append-only visit notes.
• Integrations: a WebRTC video provider on its BAA plan, card payments with clinical detail kept out, and e-prescribing through a certified vendor if you prescribe.
• Controls: role-based access, row-level security, read and write audit logging, and short-lived visit tokens, all with automated tests.
• Compliance input: your compliance reviewer signs off data flows and the vendor list before build starts.

Timeline: a fixed-scope MVP (video, scheduling, intake, notes and payments) typically takes 4–6 weeks, as on the MVP development service. A larger platform with e-prescribing, EHR integration or several clinics is closer to backend and API work, at 6–12 weeks.

What you receive: automated tests and CI on every change, handover docs and runbooks, and full IP ownership under NDA.

Next step: see the HealthTech page, then book the free 15-minute technical audit. You get a written fixed quote afterwards. Please do not send patient data in your first message. To sketch a budget first, try the MVP cost estimator.

Frequently asked questions

How much does video cost per telehealth visit?

At Twilio's published rate of $0.004 per participant-minute, a 20-minute visit with one patient and one clinician uses 40 participant-minutes, about 16 cents. Daily lists $0.0015–$0.004 with 10,000 free minutes a month. Recording and BAA plans cost extra.

Can I use WebRTC directly without a video provider?

You can, but you then run and scale your own media and relay servers and handle poor networks yourself. For most telehealth products a hosted WebRTC provider is lower-cost and faster than operating that infrastructure.

Do I need a BAA with my video provider?

If HIPAA applies to you and the provider handles PHI on your behalf, generally yes. Daily offers a BAA in its $500-a-month healthcare add-on, and Twilio requires its Security or Enterprise Edition. This is general information; confirm with your adviser.

Should a telemedicine platform record video visits?

Only if your clinicians and compliance reviewer decide it is needed. Recordings are health data, they add storage cost and retention duties, and a breach of recordings is serious. Many services record nothing and keep written notes instead.

Can RAITHub build a telemedicine mobile app?

RAITHub builds web apps and PWAs, not native iOS or Android apps. A PWA can be installed on a phone's home screen and run video in the browser, which covers most telehealth patient journeys.

Is health data special under GDPR?

Yes. GDPR and UK GDPR treat data concerning health as special-category data, and Article 9 prohibits processing it unless a listed condition applies. The ICO notes that appointment details count as health data.

Should I build e-prescribing myself?

No. Integrate a certified e-prescribing vendor such as DoseSpot, which provides pharmacy network connections and controlled-substance prescribing. Building your own would mean certification and network work no early-stage product should take on.