After the Launch: Post-Market Surveillance as Everyday Diagnostic Care

Diagnostic innovation is often described as a journey from bench to bedside. In practice, the more consequential journey begins after the first sale, the first deployment and the first week of routine use. A test that performed well in a controlled evaluation may behave differently when samples are taken in a busy GP surgery, when a software update changes a threshold, or when a new user group is added. The launch is not the end of evidence generation. It is the point at which a different kind of evidence begins to accumulate.

As of November 2026, the UK diagnostic and health-software market is more crowded and more connected than it was a decade ago. That is broadly welcome. It also means that post-market surveillance can no longer be treated as a regulatory afterthought or a communications problem to be managed only when something goes wrong. It is part of the clinical translation itself.

Why post-market signals are different

Pre-market evaluation tends to ask whether a product can work under specified conditions. Post-market surveillance asks how it works when those conditions are less tidy. For in vitro diagnostics, performance can shift because of sample handling, reagent lot variation, population differences, or changes in the clinical pathway around the test. For health software, the risk may lie in a revised algorithm, a changed user interface, a data-interface failure or an update that alters the way a result is presented.

These are not necessarily signs of a flawed product. They are signs of a product in use. The important question is whether the organisation behind it has a system for noticing, assessing and acting on signals in a proportionate way. A post-market surveillance plan should specify what data are collected, how complaints and incidents are reviewed, what triggers a deeper investigation, and who is accountable for decisions. For software as a medical device, clinical risk management should continue through the product lifecycle, not stop at first release.

The signals themselves are often unglamorous: a rise in repeat requests, a cluster of discrepant results, a helpdesk pattern, a user report that a result screen is being misread. Individually, they may look like operational noise. Collectively, they can be the earliest evidence that a diagnostic is drifting from its intended performance in everyday care.

The UK reporting architecture, in plain terms

In the UK, the reporting landscape is layered. Manufacturers have duties under medical device and in vitro diagnostic regulation, including post-market surveillance and vigilance obligations. Healthcare providers have local incident-reporting systems and patient-safety processes. The MHRA operates the Yellow Card scheme, which accepts reports concerning medical devices as well as medicines, and receives reports of adverse incidents involving medical devices. Serious incidents may also require notification through local NHS channels and, where relevant, national patient-safety alerting routes.

For software, the picture can be less intuitive for frontline staff. A malfunctioning device may be obvious. A software update that changes a risk score, suppresses a flag or alters a default setting may not present as a device failure at all. That is why providers need clear internal routes for reporting clinical-software concerns and why manufacturers need to treat user feedback as safety data rather than customer sentiment. The question is not only whether the product broke, but whether the clinical workflow around it became less safe.

When a manufacturer identifies a problem that requires action, the usual mechanism is a field safety corrective action, communicated through a field safety notice. The notice should explain what is wrong, which products or versions are affected, what action is required and by when. It is a regulated communication, but its practical success depends on whether busy clinical teams can understand it and act on it.

What a proportionate correction looks like

The word recall can suggest a single dramatic event. In diagnostics and health software, correction is often more gradual: a version withdrawal, a revised cut-off, a labelling update, a software patch, a restriction on certain sample types, or enhanced training. Proportionality matters. An overreaction can remove a useful test from circulation and create unintended access problems. An underreaction can leave known risks in place.

A defensible correction should be tied to the evidence, specific about the affected population or use case, and clear about residual uncertainty. It should distinguish between a product that must stop being used and one that can continue with amended instructions. It should also include a route for users to ask questions and report further issues. For providers, the operational test is simple: can a practice manager, biomedical scientist or clinical lead identify whether they are affected, and can they complete the required action without guesswork?

Communication that preserves trust

Corrections are often discussed as reputational risks. They are also trust events. A vague notice, a delayed update or a silent change to a product can do more damage than a clear admission that a problem has been found and is being managed. Transparent communication should state what is known, what is not known, what has changed and what users should do next. It should avoid minimising language that frontline staff will later find difficult to reconcile with their own experience.

This is particularly important for diagnostic tests and software that sit close to clinical decisions. A clinician who has used a test in good faith needs to understand whether previous results should be reviewed, whether certain patients should be recalled, or whether the issue affects interpretation only. Those are not public-relations questions. They are clinical-governance questions.

The operational test for providers

Providers should be able to answer a few basic questions before and after adoption. Who in the organisation receives field safety notices? How are they logged and reviewed? Which clinical lead is responsible for assessing impact? How are users informed? What happens if the product is embedded in another system or managed by a third-party supplier? For digital tools, version control and change management deserve the same attention as device maintenance.

Post-market surveillance is sometimes portrayed as the administrative tail of innovation. That framing is too narrow. It is the mechanism by which a promising diagnostic becomes a dependable one. A transparent, proportionate recall or update process is not an admission that translation failed. It is evidence that translation is being taken seriously, and that the product is being governed as part of care rather than left to succeed or fail on first impressions.