When software becomes a medical device: quality thinking for health apps and AI

Software now diagnoses, monitors, predicts and guides treatment. When it does, it is no longer “just an app” — it is Software as a Medical Device (SaMD): software intended for medical purposes that performs those purposes without being part of a hardware device, as the US Food and Drug Administration describes it.^[1] This deceptively simple idea carries a profound consequence: medical-grade purposes call for medical-grade evidence, quality and lifecycle care.

Why SaMD thinking is challenging — and valuable

Software behaves differently from physical devices. It updates frequently, runs on hardware its makers do not control, and — when machine learning is involved — may change behaviour as data changes. Post-market surveillance research in the medical-device field emphasises the importance of systematic, harmonised monitoring of devices in real use,^[2] and software amplifies that need. The teams that thrive treat these characteristics not as burdens but as design questions:

• Intended use, precisely stated. The single most important sentence in any SaMD project defines what the software is for — it drives classification, evidence and claims.
• Risk-proportionate evidence. A wellness tracker and a diagnostic algorithm deserve different scrutiny; matching evidence to risk keeps innovation moving safely.
• Change under control. Updates, retraining and new features flow through defined change processes, so improvement never silently becomes a different device.
• Real-world vigilance. Monitoring performance, complaints and incidents after release closes the loop between design assumptions and clinical reality.

The way forward

SaMD competence is becoming one of medtech’s most portable skills — the same quality thinking applies to a start-up’s first app, a hospital’s home-grown tools and a multinational’s AI portfolio. Professionals who can hold both the software and the medical perspective in one mind are in structurally short supply.

From accessory to therapy: a short history

For most of medical-device history, software was an accessory — the code inside an infusion pump or imaging scanner, regulated as part of the hardware it served. The conceptual turn came when regulators recognised that software alone, running on ordinary phones and servers, could perform medical functions. The International Medical Device Regulators Forum gave this class its name and framework in 2013 with its foundational Software as a Medical Device documents, defining SaMD and proposing risk categorisation based on the significance of the information the software provides and the seriousness of the condition it addresses. Europe’s Medical Device Regulation, adopted in 2017, then brought many health apps and algorithms decisively into regulated territory, with classification rules that treat clinically consequential software with the seriousness previously reserved for physical devices.

This evolution reframed a cultural question for the software industry: development speed and iteration are virtues, but in health they must coexist with the discipline of quality management, clinical evaluation and traceability. The teams that thrive are those that stopped seeing these as opposites.

Quality thinking across the lifecycle

• Intended purpose as the anchor. A precise statement of what the software claims to do — and for whom — drives classification, evidence expectations and marketing boundaries alike; vagueness here propagates everywhere.
• Risk management as design input. Hazards are analysed before code is written, and mitigations become requirements, not patches.
• Clinical evaluation proportionate to claims. The evidence question is simply: does the software achieve its clinical purpose, for its intended population, with acceptable risk? Analytical validation alone rarely answers it.
• Change control with clinical eyes. Every update is triaged for clinical impact; the version running in the field is always known, always supportable.
• Post-market surveillance as product telemetry. Complaints, incidents and real-world performance feed a living safety file — the same loop good software teams already run for reliability, pointed at patient safety.

Looking ahead

The frontier is adaptive software: AI-enabled devices designed to change after deployment. Regulators are responding with concepts such as predetermined change control plans, which let manufacturers pre-specify the boundaries within which a model may be updated without a fresh submission. It is an elegant compromise between innovation velocity and oversight — and it rewards exactly the organisations whose quality systems are strong enough to be trusted with it. For professionals, the message is consistent: regulatory fluency in software is no longer a niche specialism but a core competence of digital health.

Recognised expertise with EUSTM

The Professional Certification in Software as a Medical Device & AI (PCSaMD) from the EUSTM Academy recognises exactly this combined competence, and pairs naturally with the Professional Certification in Regulatory Affairs (PCRA) for professionals working across the full product lifecycle.

Disclaimer. This Expert Insight is provided by EUSTM for general informational and educational purposes only. It does not constitute medical, clinical, legal, regulatory or other professional advice, and it should not be relied upon as the basis for clinical, regulatory or business decisions. While care is taken in preparing this content, EUSTM makes no representation or warranty as to the accuracy, completeness or currency of any scientific, medical or other statements, and accepts no liability arising from the use of this content. Readers should consult the cited sources, the current official guidance of the relevant authorities and frameworks, and appropriately qualified professionals in their own jurisdiction. References to third-party organisations, publications or frameworks are for information only and do not imply affiliation or endorsement.

← All Expert Insights