The Same Kit, a Different Test: Change Control for Connected Diagnostics in UK Care

A home reader app updates overnight. The patient sees a new icon and a slightly different result screen. The kit on the shelf is unchanged. The numbers it produces may not be. For the clinician reviewing a trend six months later, that is not a software event. It is a change in the evidence base, and it should be documented as one.

The device is no longer only the hardware

Connected home diagnostics — lateral flow readers, home INR monitors, continuous glucose sensors and their companion apps — are software-defined devices. The result is produced by a chain: sample handling, signal capture, pre-processing, an algorithm, a threshold and a display. Any link in that chain can be revised remotely. Manufacturers call this maintenance. Clinicians experience it as version drift.

Under the UK Medical Devices Regulations, software can be a medical device in its own right or a component of one. UKCA marking, technical documentation and post-market surveillance apply. But routine updates are often judged by the manufacturer to be non-significant changes, and therefore not requiring a new conformity assessment. That judgement is legitimate only if it is recorded, reasoned and visible to the people who use the output.

Why 'the same kit' is a regulatory fiction

A kit validated in version 3.1 is not the same kit in version 4.0 if the algorithm's cut-off has moved. The analytical performance may be equivalent; the clinical interpretation may not be. A small shift in a decision threshold can reclassify a borderline result, and borderline results are precisely where home testing meets primary care.

The regulatory seam is not a gap in the rules. It is a gap in communication. MHRA guidance expects manufacturers to operate a change-control process and to notify users of changes that affect performance. In practice, notification often arrives as an app-store release note, written for consumers rather than clinicians. A practice manager in Leeds and a commissioner in an integrated care board are unlikely to read it.

A minimum change-control record

For connected diagnostics, the record should be short enough to be used and specific enough to be audited. At minimum it should contain:

• Version identity. App version, firmware version, algorithm model identifier and ruleset version, each with the date it took effect. 'Latest' is not a version.
• Change classification. Cosmetic, performance-neutral or performance-affecting, with a one-line rationale.
• Equivalence evidence. An analytical bridging study, a comparison against the previous version, or a reasoned statement of no clinical impact. The reasoning matters as much as the result.
• Revalidation triggers. A moved threshold, a new sample type, a new population, a changed reference standard or a new clinical claim. Any of these should prompt a fresh review, not a silent release.
• User notice. What patients and clinicians are told, through which channel, and when. A release note is not a notice.
• Audit trail. An immutable log linking each result to the software version that produced it. Without this, a trend line is not interpretable.
• Rollback and continuity. What happens if an update is withdrawn, and how results produced during the affected period are handled.

Who signs off

Sign-off is distributed, and that is the difficulty. The manufacturer's regulatory function signs the change-significance decision. The clinician does not sign firmware, but must be able to see the version behind a result. The ICS commissioner does not regulate software, but can require version disclosure and notification periods in contracts. MHRA acts when a field safety corrective action is needed.

In England, procurement routes such as the Digital Technology Assessment Criteria and NHS England's diagnostic programme can carry these requirements without new legislation. A contract clause asking for thirty days' notice of a performance-affecting change is not burdensome. It is basic commissioning.

Making comparability routine

Three practical steps would improve everyday care. First, add a version field to local result reconciliation: when a home result is reviewed alongside a clinic result, the software version should be visible. Second, include a version register in the annual review of any point-of-care or home diagnostic service. Third, route unexplained shifts in result distribution to the supplier as a formal query, not an anecdote.

None of this requires clinicians to become software engineers. It requires the record to travel with the result. The kit is not the test. The version is part of the test. Treating comparability as a clinical duty, rather than a technical afterthought, is how connected diagnostics earn their place in routine UK care.