Telemedicine app testing

What actually breaks in a telemedicine consultation?

The failure is rarely a stack trace. A consultation degrades. Video holds on the last decoded frame while audio keeps running, and the clinician goes on describing a rash nobody can see any more. No bug is filed, because the application never threw one. The call ended, the patient hung up, and the only trace of the degradation is a clinical decision taken on a frozen frame.

A functional suite exercises the parts of the product that behave like an application: booking, the waiting room, the consent screen, the notes field. The live session behaves differently. It is a real time media path over a network the product does not own, negotiated against a device the product does not control, and the defects that matter live in the transitions rather than in the steady state.

• The network changes under a running session, when a patient walks from wifi to cellular mid consultation. The question is whether the session resumes, and whether it resumes into the same encounter or into a new one.
• Bandwidth collapses instead of dropping. The connection stays up and the media stalls, so nothing in the client reports a failure and no retry is triggered.
• The operating system takes the capture device: an incoming phone call, a screen lock, an app switch, a low power mode. The other party sees a frozen tile with no indication of why.
• A camera permission granted at the first visit is revoked in system settings before the second, and the client renders a black frame where it should render a prompt.
• A clinician reconnects and ends up holding two sessions against one encounter, with the note written into whichever one the tab was focused on.

The second half of the product starts when the call ends. Whatever the consultation produced still has to reach the chart: the encounter itself, the note, the consent, any observation captured during the call, and the diagnosis code attached afterwards. A session that ran perfectly and wrote nothing is a clinical event with no evidence that it happened.

Which standards reach a telemedicine platform?

Four instruments reach it, and they arrive from different directions. Three of the rows below sit inside one of them, the HIPAA technical safeguards at 45 CFR 164.312.

Telemedicine platform functions mapped to the HIPAA technical safeguards, IEC 82304-1, WCAG 2.1 Level AA and EU MDR Rule 11 requirements that reach each.

What the product does	Which requirement reaches it
Carries ePHI over a network you do not own	45 CFR 164.312(e)(1) transmission security, integrity controls and encryption both addressable
Lets clinicians and patients reach the record	164.312(d) person or entity authentication and 164.312(a)(1) access control, which covers software programs as well as people
Has to show who opened a chart	164.312(b) audit controls, required in itself, with no named event list
Ships as software onto phones and browsers you do not build	IEC 82304-1 clause 4.6, verification of system requirements
Puts a consultation interface in front of patients	WCAG 2.1 Level AA, including Success Criterion 1.2.4 Captions (Live)
Triages, scores or recommends	EU MDR Annex VIII Rule 11

IEC 82304-1 is the one most telemedicine teams do not expect. Clause 1.1 applies to health software products designed to operate on general computing platforms and intended to be placed on the market without dedicated hardware, and the note to subclause 1.2 states that it also applies to health software products intended to be used in combination with mobile computing platforms. A client distributed through an app store and a browser is inside that scope. Clause 4.6, verification of system requirements, is where the device matrix stops being a QA convenience: each result carries the platform, the OS version and the build it ran on. Testing health apps across real devices and OS versions is where that evidence comes from.

Accessibility arrives through the same door as the video. A live consultation is live synchronised media, which puts Success Criterion 1.2.4 Captions (Live) inside the 50 success criteria a Level AA claim covers, rather than on a feature backlog. Which federal instrument makes such a claim binding, and which WCAG version each instrument names, is set out in the WCAG 2.1 Level AA requirements for patient-facing software.

Is your telemedicine product a medical device?

The intended purpose decides it, and the video stack has nothing to do with the answer. A product that carries a clinician and a patient to each other is a channel. The moment it does something with the clinical content, symptom triage before the call or a risk score presented to the clinician, the question is open.

In the EU the deciding text is Annex VIII Rule 11 of Regulation (EU) 2017/745. Its first limb classifies software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes as class IIa, with class IIb where the decision may cause serious deterioration of health or a surgical intervention, and class III where it may cause death or irreversible deterioration. The second limb catches software intended to monitor physiological processes. All other software falls to the residual class I.

Article 2(12) takes the intended purpose from the label, the instructions for use and the promotional material, so the marketing description of a triage feature is an input to the classification. Testing does not answer the question, and a test plan that assumes an answer is worse than one that leaves it open. What testing establishes is what the product actually does, so the classification argument is written against observed behaviour. Where the answer turns out to be yes, SaMD testing covers the regime that follows.

Which test scenarios are specific to a telemedicine session?

The ones that put the session into a state the product cannot create for itself.

Step 4 finds the most, because the operating system is a participant in the session and it does not negotiate. Step 2 finds the reports that support cannot reproduce, since a held degradation and a clean disconnect drive a reconnection strategy down different paths.

The waiting room and the admission path need their own runs. A telemedicine encounter frequently has more than two participants: an interpreter, a supervising clinician, a parent joining from a different address. Each admission is an access decision taken in the middle of a live clinical event, and 164.312(a)(1) access control covers the software programs holding rights as well as the people. A recording that starts before the third participant is admitted is a disclosure question rather than a rendering defect. A run book for the media path itself is in telemedicine video call testing.

Where does the encounter record go wrong?

Most telemedicine platforms reach the hospital through HL7 v2. Scheduling leaves as SIU, the visit as ADT, the consultation document as MDM. Each of those is a family rather than a message, and the family is where suites stop early. ADT_A01 is the structure used by trigger events A01, A04, A08 and A13, so a suite that exercises ADT_A01 once has covered one of the four events sharing it. MDM_T02, which HL7 table 0003 gives as "MDM/ACK - Original document notification and content", is used by T02, T04, T06, T08 and T10, and a consultation note that is amended after the call travels as one of the events the suite skipped. SIU_S12 is used by fourteen events running from S12 to S26, which is the whole life of an appointment that gets cancelled and rebooked.

On the FHIR R4 side, the resources a consultation needs are the least settled in the specification. Eleven of the 145 resources in R4 carry the Normative marker, and Patient and Observation are among them. Encounter and Consent sit at maturity level 2, and DocumentReference at level 3. A telemedicine encounter therefore writes into exactly the resources whose definitions R4 still allows to change. A conformance claim covers one document, the CapabilityStatement, and nothing outside it, so a statement that a product supports FHIR says nothing testable about an Encounter the receiving system will accept.

The diagnosis code attached after the consultation carries a date problem that remote care makes routine. 45 CFR 162.1000(a) pins each code to the date the care was furnished, and the ICD-10-CM and ICD-10-PCS releases change on 1 October each year, with FY2027 effective from 1 October 2026. A store and forward encounter opened in late September and documented in October is coded against the release in force on the service date, while the coder's browser is holding the new one. The interface work behind all three protocols is described in healthcare interoperability testing.

Where does telemedicine testing go wrong in practice?

• The media path is exercised on the office network, so every defect that needs a degraded link is found by a patient.
• Reconnection is tested by switching wifi off and on again, which is a clean cut. The failure that matters is the connection that stays up and stops carrying anything.
• The device matrix names phone models and not OS versions, so clause 4.6 evidence cannot say which build a result came from.
• The encounter record is verified in the platform's own database and never on the receiving system, so the outbound HL7 message is read by nobody until the hospital interface team reads it.
• Captions and the accessibility of the consultation interface are scheduled after launch, although 1.2.4 Captions (Live) sits inside a Level AA claim from the first release that carries live audio.
• The test environment holds copies of real consultations for reproduction, which makes it an ePHI store under the same 164.312 standards as production, and it usually inherits none of them.
• Audit controls record that a clinician opened the application rather than that a clinician opened a chart, which leaves 164.312(b) unanswered for the session itself.

What do we run against a telemedicine platform?

Work starts from the session inventory: every path that carries media or ePHI, every participant type that can join a consultation, and every transition the operating system can impose on a client. From that inventory we build the degraded network runs and the platform matrix clause 4.6 asks to be recorded, then check whatever leaves the platform after the call against the system that receives it.

The safeguard side of it is described in PHI security testing, and the record side in HIPAA compliance testing, which produces the artefacts named for the section each one answers. The compliance position stays with the covered entity or business associate that ships the product. What testing hands over is the evidence underneath it.