Software as a Medical Device is one of the fastest-growing areas in MedTech — and one of the most misunderstood from a regulatory perspective. This guide explains what SaMD teams need to get right from the start, and where the most common mistakes happen.
Many software teams assume that because their product is digital, regulatory compliance will be lighter or more flexible than for traditional medical devices. In reality, software often raises complex regulatory questions very early.
SaMD falls under the same medical device regulations as hardware — intended use and classification, not the technology, determine your regulatory obligations. The EU and UK are separate regulatory jurisdictions requiring independent assessment. Defining intended use correctly from the start prevents costly rework across your entire technical file.
SaMD refers to software that performs a medical purpose without being part of a physical medical device hardware system. That can include software intended for:
The key issue is not whether the product uses AI, an app interface, or cloud infrastructure. The key issue is whether the software has a medical purpose. If it does, it may fall within medical device regulation.
Software teams are often strong on product, UX, engineering, and speed. But regulatory requirements introduce a different set of questions:
These questions need answering early, because the wrong regulatory assumptions can affect product claims, product design, and launch strategy.
A common mistake is to think of the UK as simply an extension of the EU plan. It is often related, but not identical. UK market access needs its own regulatory review.
One of the most important issues for SaMD in the EU is classification. Software that drives or influences clinical decisions may fall into a higher class than founders expect. That can change the conformity assessment route and trigger Notified Body involvement.
This is critical for software. A small wording difference can affect whether the product is regulated, how it is classified, and what evidence is required.
This is often where software founders are surprised. Classification should never be guessed based on what competitors appear to be doing.
For SaMD, documentation needs to address not only general medical device requirements, but also software-specific issues such as software architecture, development process, validation, version control, and change management.
Software risk is not just about physical harm. It can include incorrect outputs, delayed outputs, user misunderstanding, interoperability issues, or cybersecurity impacts.
SaMD still needs evidence. The question is not whether the product is digital. The question is whether the clinical and performance evidence supports the intended use.
Software changes frequently. That means post-market processes, updates, and change assessment must be thought through from the start.
That is often not the case. Classification depends on the medical purpose, not the format.
This creates regulatory ambiguity and future rework across the entire technical file.
Regulatory documentation is broader and must align with the medical purpose, not just the software architecture.
The strategic overlap is real, but the market access route still needs separate analysis.
This often leads to painful redesign of documentation, claims, and evidence strategy.
A strong SaMD regulatory approach usually starts with:
This does not mean building a giant compliance machine too early. It means making the right strategic decisions early enough that you avoid rework later.
At Regvo, we support software and digital health teams that need clarity on how medical device regulation applies to their product. This usually includes:
SaMD regulation is not just a technical compliance issue. It affects product claims, launch strategy, investment readiness, and long-term scalability. The earlier you define the right regulatory framework, the easier it becomes to build with confidence.
Book a free discovery call and we can help you clarify your SaMD regulatory pathway.
Book a free discovery callSaMD is software that performs a medical purpose — such as diagnosis, monitoring, prediction, or treatment support — without being part of a hardware device. Under EU MDR, whether it uses AI or cloud infrastructure is irrelevant; what determines regulatory status is the intended medical purpose.
Yes. If your software has a medical purpose such as diagnosis, monitoring, or treatment support, it falls within EU MDR regardless of how it is built or hosted. Regulatory status is determined by intended use, not by the underlying technology.
Under MDR Rule 11, most software that influences clinical decisions is classified at minimum as Class IIa. Software that provides diagnostic or therapeutic decisions without human override often reaches Class IIb or III. Classification depends on intended use and the clinical impact of the software output.
Start with a clear intended use statement, classification rationale, and risk management framework (ISO 14971). Software-specific documentation — including architecture, development process, validation, and change management — must be addressed as part of your technical file.
No. Since Brexit, Great Britain is a separate regulatory jurisdiction. EU MDR compliance does not automatically satisfy UK requirements. You need to review UK-specific obligations — including MHRA registration and a UK Responsible Person — independently of your EU pathway.
Assuming software is automatically low risk, defining intended use too broadly, or leaving regulatory planning until late in development. These lead to ambiguous classification, rework across technical documentation, and costly delays.