Telemedicine video call testing methodology

What are you testing when you test a video consultation?

The encounter, in four parts: who was on it, what it wrote to the chart, what happened to it when the network failed, and whether a patient using a screen reader or a keyboard could take part in it. Picture quality is the part that reports itself. A clinician can see a frozen tile. Nobody can see an encounter that never reached the receiving system, and nobody can see an admission decision that was never recorded.

That split decides the shape of the suite. The media path is exercised against the client and the network, and the failure modes there are the subject of what breaks in a telemedicine platform. The methodology below starts one layer above: each media event is treated as an input to a clinical record, and each test asserts on the record rather than on the tile.

section 164.312(e)(1), Transmission security sets the outer boundary, and the product page above describes what that section asks of a platform. What it does to a consultation test plan is a counting exercise, because one call is not one transmission. The media stream, the chat panel, the shared screen, a file dropped into the call, the recording written at the end and the write back to the clinical record are six paths that carry content off the host. They rarely share a transport, and the addressable decision at 164.306(d)(3) belongs to each one separately. A plan that names the call has enumerated one of the six. Each path enters the plan as a written input carrying the decision made for it, and the run asserts that the product behaves the way that decision says. Before any of it is exercised, the terms under which an outside team may touch PHI are settled in writing, and the answers we give to that question are at how we work with protected health information.

How is identity established before clinical content is exchanged?

By testing the join itself. A consultation has at least two parties who have never met, the join usually arrives as a link in a message, and the link is the credential for as long as it works. section 164.312(d), Person or entity authentication asks for procedures to verify that a person or entity seeking access to ePHI is the one claimed, and 164.304 defines authentication as "the corroboration that a person is the one claimed". Neither text names a mechanism. The Security Rule does not mention multi-factor authentication anywhere in 164.302 to 164.318, so the mechanism is your decision and the test asserts against the decision you wrote down.

The cases that find defects are the ones where a link outlives its encounter.

• The join link is opened after the appointment has finished, from the same device and the same inbox.
• The join link is forwarded, and a second person opens it while the first is in the call.
• The appointment is cancelled and rebooked, and the link from the first booking is opened against the second slot.
• The clinician joins from a second device without leaving the first, and both sessions stay open against one encounter.
• An interpreter, a parent or a supervising clinician is admitted after the clinical conversation has started.

The last one is an access decision taken in the middle of a live event. 164.312(a)(1) asks for technical policies and procedures that allow access only to those persons or software programs granted rights under 164.308(a)(4), and the admission control in a waiting room is exactly such a policy implemented in product code. The assertion is on the record of the admission: who admitted whom, at what point in the session, and whether the other party was told.

What has to be in the record when the call ends?

Everything a later reader needs to know that the encounter happened, without asking either participant. That list is short and each item has a place it can be read back from.

Step 6 is where the interface design shows. HL7 v2 draws the line between an observation message and a document message on this exact point: content qualifies as a medical document management message rather than an ORU where it needs succession management "to reflect the evolution of both document addenda and replacement documents". A consultation note that a clinician corrects the next morning is that case, and a suite that only ever sends the original document has tested the easy half. The pass structure for the interface itself is described in an HL7 v2 interface testing approach.

On the FHIR side, the constraint that decides your acceptance criteria is Must Support. The base specification flags no element as mustSupport, because it is written to be independent of any implementation context, and the specific meaning of Must Support for a profile has to be described in the element definition, the structure definition description, or other documentation of the implementation guide. So the question to put to the receiving hospital is element by element, and the list is the one the closing check above reads back: the start and end times, the participant list with the role each participant held, the note and its author, the consent captured during the call, and the encounter reference on every observation entered while it ran. An element the receiving system will not commit to is an element your suite cannot fail, and the write back is scripted after that answer exists, not before. Record the answer with the fixtures.

What happens to the encounter when the connection drops halfway?

One of three things, and the suite has to distinguish them: the session resumes into the same encounter, it resumes into a second encounter, or it resumes into nothing while the platform still holds the first as open. Only the first is correct, and the other two are invisible from inside the client.

Points in a telemedicine video visit where a connection drop is injected, each with what the test reads from the encounter afterwards.

Where the drop is injected	What is read afterwards
Before consent is captured	Whether an encounter exists at all, and in what state
While the note is open and unsaved	Whether the text survives the reconnection, and under which author
While a recording is running	Whether one artefact or two exist, and whether both are attached to the encounter
At the moment the clinician ends the call	Whether the end time comes from the client or from the server
After the call ends, before the write back	Whether the outbound message is retried, and whether the receiver sees a duplicate

Two required safeguards sit under this section and are usually tested as login behaviour instead. 164.312(a)(2)(ii) Emergency access procedure is a required implementation specification, and the case that exercises it is a clinician locked out during a consultation that cannot wait. 164.312(a)(2)(iii) Automatic logoff is addressable, and a session timeout that fires while a patient is mid-sentence is the reason a team writes the 164.306(d)(3) reasoning down. Both belong in the drop matrix with the media cases, because that is the state the product is in when they matter.

Duplicate encounters are the finding that costs the most to clear later. Each resumption after an injected drop is checked on the receiving system and not in the platform's own database, and the check counts every matching record. The engagement shape for that work is set out under healthcare interoperability testing.

What do the accessibility requirements do to a live call?

They put the whole appointment sequence under one claim, instead of the video screen alone. WCAG 2.1 conformance requirement 5.2.3 Complete processes states that where a web page is one of a series presenting a process, all pages in the process conform at the specified level or better. Booking, the reminder link, the waiting room and the consultation screen are a process by that definition, so a waiting room that fails takes the consultation screen down with it.

Three criteria change what a live session has to do, and each is testable only while a session is running. Success Criterion 1.2.4 Captions (Live) is one of the 20 criteria that carry the Level AA marker, inside the 50 a Level AA claim covers a Level AA claim covers. Success Criterion 4.1.3 Status Messages is Level AA and is one of the 12 criteria added in WCAG 2.1 relative to WCAG 2.0, which reaches every "reconnecting", "clinician has joined" and "recording started" indicator a consultation shows. Success Criterion 2.1.2 No Keyboard Trap applies to all content on the page under conformance requirement 5.2.5, whether or not the claim relies on the embedded call component. Whether your company is under an obligation to make such a claim at all is a separate question, answered by the WCAG 2.1 Level AA requirements for patient-facing software.

WCAG names the criterion by number, title and level. What counts as an acceptable live caption for a clinical conversation is a threshold you set against your own clinical policy, and the suite records that threshold beside each result so a later reader can see what the run asserted against.

Which failure can a support ticket never reconstruct?

The consultation whose only witness is the patient. A call that connected, carried degraded media for most of its length and ended normally leaves a support desk with a ticket, a timestamp and no way to tell what the clinician saw. A suite cannot prevent that failure. What it can assert is that the product recorded enough for somebody to answer the ticket afterwards.

The assertion is on the session record, and the state transitions it has to contain are yours to define: joined, admitted, media established, media degraded, reconnected, ended, and by whom. 164.308(a)(1)(ii)(D) Information system activity review is a required implementation specification and asks for procedures to regularly review records of information system activity, "such as audit logs, access reports, and security incident tracking reports". A review procedure has nothing to work on where the client is the only component that knew about the degradation. The corresponding safeguard testing is described under PHI security testing.

What does the run hand over?

• A session inventory. It lists every join path, every participant type and every transition the operating system can impose.
• A drop matrix. Each row names the injection point, the resumption behaviour and the state of the encounter afterwards.
• An encounter reconciliation report. It compares each scripted consultation with the record read back from the receiving system.
• An identity and admission result set. Each row names the join path and what the session record shows.
• A WCAG result set scoped to the appointment process, with the criteria checked during a live session marked as such.
• The written inputs each run asserted against: the caption threshold, the network conditions and the addressable decisions under 164.306(d)(3).

Each of the four sets is addressed to a different reader. The encounter set answers a clinician asking what the record says happened. The identity set answers a security officer holding 164.312(a)(1). The WCAG set answers a procurement question about the appointment process. The written inputs answer the one question the other three cannot: against what the run was judged, and who chose it.

Sources for this page. The quoted text and section titles at 45 CFR 164.312(e)(1) and (e)(2), 164.312(a)(1), 164.312(a)(2)(ii) and (a)(2)(iii), 164.312(b), 164.312(d), 164.306(d)(3), 164.308(a)(1)(ii)(D) and the definitions at 164.304 come from the collected HIPAA record, taken from the eCFR compilation as it stood on 31 August 2026. The success criterion numbers, titles and level markers, the counts, and conformance requirements 5.2.3 and 5.2.5 come from the collected WCAG record, read against the 5 June 2018 dated publication of WCAG 2.1. The succession management wording comes from the collected HL7 v2 record and the Must Support wording from the collected FHIR R4 record.

Which mistakes let a broken consultation pass?

• The suite ends when the call ends, so a session that ran cleanly and wrote nothing is recorded as a pass.
• Reconnection is checked in the client, where a second encounter created on the receiving system is invisible.
• Automatic logoff and emergency access are tested from the login screen and never during a live consultation, which is the only state in which either one causes harm.
• Accessibility is checked on the consultation screen alone, although conformance requirement 5.2.3 fails the whole appointment process when the waiting room fails.
• Live captions are demonstrated once in a recorded call and never asserted against a stated threshold, so no result says what was acceptable.
• The amendment path is left out, although HL7 v2 treats a document that evolves through addenda and replacements as a different message family from an observation.
• Session events are defined by whatever the logging library emitted, so 164.312(b) is answered by an accident of implementation.