Testing a Telehealth Platform: Booking, Video and Records

Test a telehealth platform across three journeys: appointment booking, where the risk is double-booking a clinician; the video consultation, where the risk is a call that will not start or drops with no recovery; and records, where the risk is a clinician reaching a patient who is not theirs. The happy-path demo call rarely breaks. The failures live in concurrency, device and network conditions, and relationship-based access.

This is general engineering information, not compliance or legal advice; confirm your obligations with your compliance adviser. If you would rather have it tested for you, see how RAITHub would test this below. For the build side, see telemedicine platform development; this post proves it works before real patients join.

What should you test first in a telehealth platform?

The journeys a patient and a clinician cannot complete a visit without. Name them, then test each on a production-like environment with realistic data, and crucially on real devices and throttled networks, because video is where conditions matter most.

Journey	Minimum bar to pass	Automate or manual
Booking	No two patients hold the same clinician slot; cancellations free the slot	Automate, including a concurrency test
Join the consultation	Both parties can join the right call, on common devices and browsers	Automate the join path, manual on real devices
Video failure recovery	A dropped connection reconnects or fails with a clear next step	Manual with throttling, plus automated smoke checks
Record access	A clinician sees only their patients; a patient sees only their own record	Automate at the API
Notes and after-visit summary	Notes save to the right encounter; a summary reaches the right patient	Automate

How do you test booking without double-booking?

With a concurrency test, because a check-then-write that passes one request at a time fails when two patients race for the last slot. Let the database enforce that a clinician's slots do not overlap, then prove it by firing two bookings at once and asserting exactly one wins:

import { test, expect } from '@playwright/test'

test('two patients cannot book the same clinician slot', async ({ playwright }) => {
  const api = await playwright.request.newContext()
  const body = {
    clinicianId: process.env.CLINICIAN_ID,
    start: '2027-05-01T09:00:00Z',
    end: '2027-05-01T09:30:00Z',
  }
  const [a, b] = await Promise.all([
    api.post('/api/appointments', { data: body }),
    api.post('/api/appointments', { data: body }),
  ])
  const statuses = [a.status(), b.status()].sort()
  expect(statuses).toEqual([201, 409]) // one booked, one rejected
})

Run it repeatedly, and from more than two callers, because a race that fails one time in fifty still double-books someone. Also test the date edges: a slot across a daylight-saving change in the clinician's zone, a patient in another zone seeing the correct local time, and a cancelled appointment freeing the slot. The concurrency and exclusion-constraint patterns are covered in QA for a short-let booking platform, and the booking build in building a doctor appointment booking system.

How do you test the video consultation?

Video is the part most likely to fail in the field, because it depends on the patient's device, browser and network, none of which you control. Test the join path automatically, then test the failure modes on real conditions.

• Both parties join the correct call from a scheduled appointment, and cannot join a call they are not party to.
• A patient who denies camera or microphone permission sees a clear prompt, not a frozen screen.
• Join from an unsupported browser and confirm the platform guides the patient instead of failing silently.
• Throttle the network mid-call and confirm the platform degrades (audio-only, reconnect) or ends with a clear message, not a blank screen.
• Drop and re-join, and confirm the session resumes the same appointment rather than starting a new one.
• Confirm a waiting patient sees the clinician arrive, and that neither party can join before the window if your policy forbids it.

Automated tests cover the join and the access rules; the device and network failure modes need a manual pass on real phones. If you use a third-party video provider, test your glue code and the permissions, and rely on the provider's own testing for the media transport.

How do you test record and note access?

Records in a telehealth app follow the clinician-patient relationship, not just the role. Write a matrix that includes the relationship, and test the "Refuse" cells with two accounts per role, through the API. Broken access control is A01 in the OWASP Top 10:2025, and the cross-record case is broken object level authorization (OWASP API1:2023).

Action	Patient	Treating clinician	Other clinician	Admin
Join own appointment	Allow	Allow, own patients	Refuse	Refuse
Read a visit record	Own only	Own patients	Refuse	Per policy, logged
Write a clinical note	Refuse	Allow, own patients	Refuse	Refuse
Read another patient's record	Refuse	Only if treating	Refuse	Per policy, logged

Also confirm a note saves against the correct encounter, and an after-visit summary reaches the right patient only. The full access test plan is in testing login, roles and data access, and the HealthTech-wide engineering QA plan is in testing a HealthTech app before launch.

Buy, build or hire this testing?

Option	Choose this when	Trade-off
A certified telehealth platform (test the vendor's product)	You are buying, not building, and need existing attestations	Little of your own code to test; you inherit the vendor's video and access behaviour
Your own Playwright and SQL suite	A developer can own booking concurrency and access tests	Lowest cost to run; video failure modes still need manual device testing
A freelance tester before launch	You want one outside pass across real devices	Concurrency and relationship bugs are easy to miss; check their experience
A managed QA plan or a one-off pre-launch audit	You want booking, video and records tested end to end before real visits	An outside dependency; it is engineering QA, not a compliance attestation; keep the tests in your repository

Doing it yourself is realistic: plan 4 to 6 days for a developer who knows the stack, more if video is custom rather than a provider. The main risk of going alone is testing one booking at a time and one network condition.

Why RAITHub for this

• Booking and access under concurrency are everyday work. PropDesk handles scheduled money flows across 4 roles with 1,024 tests; Sundor Skin enforces access on 146 tables with 530+ tests. RAITHub has built a healthcare scheduling app for a client.
• Tests that run concurrently and on real devices, so a race that double-books, and a join that fails on an old phone, are caught before a patient hits them.
• Honest limits. This is engineering QA, not compliance. RAITHub has not shipped a regulated health product, is not SOC 2 or ISO 27001 certified, and its security testing is application-level against OWASP guidance, not a certified penetration test. Confirm obligations with your adviser.

When you don't need us

• You use a certified telehealth product end to end and only configure it.
• You have a QA engineer and a compliance partner covering this.
• You need a certified assessment or a BAA, which require a certified vendor and your adviser.

How RAITHub would test this

• Scope: agree the booking rules, the video setup and the access relationships on a free 15-minute call.
• Plan: a risk map across booking, video and records, with a test for each risk.
• Test: concurrent bookings for the same slot, the join path and video failure modes on real devices, and the access matrix including relationship rules at the API.
• Deliver: a ranked bug report with reproduction steps and a suggested fix, plus the booking and access tests as automated tests in your repository.
• What you receive: the report, the tests and a handover note. IP is yours; an NDA is standard. This is engineering QA, not a compliance attestation.

The audit is fixed-price, quoted in writing after the call. See QA as a Service, security testing, and the HealthTech industry page. To book it, ask for a pre-launch QA audit.

General information only; confirm compliance obligations with your adviser. Documentation checked on 10 October 2026.

Frequently asked questions

What should you test before launching a telehealth platform?

Appointment booking without double-booking, the video consultation and its failure modes, record and note access scoped to the clinician-patient relationship, and the after-visit summary. Start with booking concurrency and record access, since those carry the most risk.

How do you test that a clinician slot cannot be double-booked?

Let the database enforce non-overlapping slots, then fire two bookings for the same slot at once and assert exactly one succeeds. Run the test repeatedly and from more than two callers, because a rare race still double-books a patient.

How do you test the video consultation?

Automate the join and the access rules, then test failure modes on real devices and throttled networks: denied camera permission, an unsupported browser, a dropped connection, and a re-join. The platform should degrade or fail with a clear next step, never a blank screen.

How do you test record access in a telehealth app?

Write a matrix that includes the clinician-patient relationship, not only the role, and test each cell through the API with two accounts per role. A clinician should reach their own patients and be refused another clinician's; test the refuse cases explicitly.

Can QA make a telehealth platform compliant?

No. QA proves the engineering behaves as designed. Compliance is an obligation on your organisation, decided with a professional and, where required, a certified assessor. Confirm your obligations with your adviser.

Has RAITHub shipped a regulated telehealth product?

No. RAITHub has built a healthcare scheduling app for a client and has not shipped a regulated health product. For a regulated build, pair RAITHub's engineering with a compliance partner and a certified assessor.