What Happens to a Software Medical Device After Launch

A software medical device is not finished when it ships. Launch is the moment its obligations begin, because the population it serves keeps changing, clinical practice keeps moving, and the model inside it can quietly stop matching the world it was trained on. The work that keeps a Software as a Medical Device safe comes after the press release: post-market surveillance, disciplined change control for model updates, and catching failure modes before they reach a patient. Teams that treat clearance as the finish line tend to get surprised later.

This is educational content, not medical advice, and anyone making decisions about their own care should talk with their own clinician.

Why is a software medical device never really finished?

Because the thing it measures itself against does not hold still. A physical implant barely changes for a decade; software lives in a stream of data, and that stream shifts under it. The patients who use it tomorrow are not a perfect copy of the validation set, a new guideline lands, a lab swaps its assay, and the product itself evolves over time. Any of these can degrade performance without a single line of code breaking. The software still runs. It just answers a slightly different question than the one you validated.

A definition worth keeping. Post-market surveillance is the structured, ongoing process of collecting and acting on real-world evidence about a device after it is on the market, so that performance, safety, and the original claim stay aligned with reality. It is not a complaints inbox. It is how a product keeps earning the trust granted at launch.

What does post-market surveillance actually involve?

Deciding, in advance, what you will watch, how often, and what number triggers a response. Surveillance not specified ahead of time becomes a story you tell yourself after something goes wrong. A serious plan names its metrics before launch: the performance you claimed, calibration as well as discrimination, and whether production inputs still resemble the ones you trained on. It sets a threshold where a drop is no longer noise, and names who acts when it is crossed. Under EU MDR this lives in the post-market surveillance plan and the periodic safety update report, and the FDA expects an equivalent discipline. The paperwork is downstream of a simpler question: how would we know if this stopped working, and how fast? For many teams the honest answer is a complaint, which means harm has already reached someone. Good surveillance catches the drift while it is still a chart.

The hardest part is detecting silent failure

Loud failures are easy. The server is down, the output is obviously wrong, someone files a ticket. The dangerous failures are silent. A model well calibrated for one population becomes overconfident for a subgroup that has grown in the user base. A recommendation that was sound under last year's guideline drifts behind the standard of care. Nothing errors out. This is why monitoring has to compare outputs against ground truth wherever you can get it, and why subgroup performance deserves its own line on the dashboard. A healthy-looking average can hide a group the product is failing.

How do you change a model after launch without breaking trust?

Through change control, the practice of treating every modification as a decision that has to be justified, evaluated, and recorded before it reaches users. The instinct to ship improvements quickly is good, but in a medical device without discipline it is how a safe product becomes unsafe between two ordinary releases.

The tension is specific to learning systems. A model that updates can improve as it sees more data, yet its behavior has changed without anyone re-checking the claim it was cleared against. A silent update that nudges a dose recommendation is a new version of a medical device, and the question is always the same: does this alter the safety or performance of what we validated? Change control answers by sorting modifications honestly. Some are cosmetic. Some move the product outside the envelope you validated, which means new evidence and possibly a new conversation with your notified body or the FDA. The trap is letting engineering convenience decide which bucket a change falls into. Clinical risk decides, not the size of the diff.

Predetermined change control plans

Freezing a learning system forever is its own kind of harm, because it locks in yesterday's performance. The response, developed most explicitly on the FDA side and increasingly mirrored in Europe, is the predetermined change control plan: you describe, before launch, the changes you anticipate, how you will validate them, and the limits you will respect. Approved once, it lets you make defined updates without a full new submission each time, because the hard thinking happened while you were calm rather than under pressure to ship a fix. A change that falls outside the plan is the signal to stop and re-evaluate.

How do you stay safe as data and practice shift?

You assume both will shift and build that into the product rather than hoping it holds. Drift is not a defect; it is the expected behavior of any model in a living clinical system.

When we built EASY Diabetes, the EASY-1 randomized controlled trial (NCT03258268) evaluated the decision-support system against standard of care. A trial result is a snapshot, tied to those patients under that practice. Whether it still works now is answered only by surveillance running long after the trial is published. Evidence at launch is a starting balance, not a permanent one.

My certificate work at KTH Royal Institute of Technology, covering EU MDR, IVDR, the FDA framework, and Software as a Medical Device, kept returning to this, and FDA Clinical Investigator training reinforced it. Define the purpose, prove it in proportion to the risk, then keep watching, because the proof has a shelf life. The discipline is the same in Europe and the United States.

If you maintain a software medical device, the useful question is not whether you passed review. It is whether you would notice, today, if the product had drifted from the claim you made. Build the system that answers yes.