FDA for Software as a Medical Device (SaMD)

The first and most consequential question for any health software is whether it is a regulated medical device at all. The FDA draws a line between software that performs a medical function — diagnosing, treating, informing clinical decisions — and software that supports general wellness or administration. A meditation app or a hospital scheduling tool is not a medical device; software that analyses an image to detect a tumour clearly is. But between those poles sit many products whose status is genuinely arguable, and misjudging it in either direction is costly.

Getting this determination right is foundational, because it decides whether the entire regulatory apparatus applies. A company that assumes its software is unregulated and is wrong faces enforcement and a scramble to comply retroactively; one that over-regulates an unregulated wellness product burdens itself needlessly. We assess your software’s intended use and function against the FDA’s framework and the relevant guidance, so you know where you stand before you build a regulatory strategy — or decide you do not need one.

• Not all health software is a regulated device.
• The line turns on medical function versus wellness/administration.
• Misjudging it either way is expensive — get the determination right first.

Once software is established as a regulated device, it is classified and routed like any other device — but the risk logic is framed around information. What matters is the seriousness of the condition the software addresses and the significance of the decision its output drives: software informing a critical treatment decision for a serious condition is higher risk than software providing information for a minor one. That risk framing feeds into the FDA classification and the pathway, most commonly the 510(k) for moderate-risk SaMD, with De Novo for genuinely novel software types.

We classify the SaMD and select the pathway with this information-centric risk view, which is where software-specific understanding matters. A product’s risk — and therefore its route and evidence burden — depends heavily on exactly what claim it makes about the information it provides, and small differences in the intended-use statement can shift the whole regulatory picture. We help frame that intended use deliberately, so the software is positioned on the route that fits its genuine function and claim.

Software needs its development documented in a way that suits software, and the FDA has expectations for this. Rather than physical design controls, the emphasis is on software development processes, requirements and architecture, and verification and validation appropriate to code — unit and integration testing, system testing against requirements, and validation that the software does what users need in the real clinical context. The level of documentation the FDA expects scales with the software’s risk, so a higher-risk SaMD carries a heavier documentation burden.

We help build this software documentation to the FDA’s expectations without imposing process that a nimble software team cannot live with. The tension in SaMD is real: regulators want rigour and traceability, while software companies value speed and iteration. Good SaMD regulatory work finds the documentation that genuinely satisfies the FDA while fitting how modern software is actually built, rather than forcing a hardware-era process onto a software product where it does not belong.

SaMD needs clinical evaluation, but framed around what software does — provide information. The FDA and international frameworks think about this in terms of a valid clinical association (is there a genuine link between the software’s output and the clinical condition?), analytical validation (does the software correctly process the input to produce the intended output?), and clinical validation (does the output achieve the intended purpose in the target population?). This structure gives a clear way to plan what evidence a given SaMD actually needs.

We frame the clinical evaluation around this logic, so the evidence generated is the evidence the software’s claim requires — no more, no less. For some SaMD, existing literature and the software’s own validation suffice; for others, particularly novel or higher-risk products, a clinical study is needed. Identifying which, early, is exactly the kind of judgement that prevents a company from either over-investing in unnecessary clinical work or being caught short at submission without the evidence its claim demands.

• Valid clinical association: is the output genuinely linked to the condition?
• Analytical validation: does the software process input correctly?
• Clinical validation: does the output achieve its purpose in real use?

Connected medical software is a security target, and the FDA now treats cybersecurity as a core part of a device submission rather than an afterthought. For SaMD and connected devices, the agency expects to see how security has been designed in — threat modelling, security controls, a software bill of materials identifying components, vulnerability management, and a plan for handling and patching security issues over the product’s life. A submission that treats cybersecurity lightly is increasingly likely to be held up, because the FDA has made clear it will not accept devices that cannot show they are secure.

We help build the cybersecurity documentation the FDA expects, integrated with the software development rather than bolted on at the end. This has become one of the defining features of modern SaMD regulation, and it is an area that moves quickly as threats and expectations evolve. Handling it well means designing security in from the start and documenting it in the form the FDA wants — turning a potential submission blocker into a demonstrated strength of the product.

The deepest tension in SaMD is that software is meant to change, while traditional device regulation assumes a fixed product. Every update, and especially the continuous learning of AI/ML-based software, sits awkwardly against a framework built for devices that stay the same. The FDA has been developing approaches to this, including the concept of a predetermined change control plan that lets a manufacturer specify in advance the changes it may make — within defined limits and methods — without a new submission for each one. For a product that evolves, this can be transformative.

We help plan for change from the outset, so your software is not trapped needing a fresh submission for every improvement. That means thinking, at strategy stage, about how the product will evolve and how to build the regulatory approach — including a predetermined change control plan where appropriate — to permit controlled evolution. For AI/ML products in particular, this forward planning is essential, because a learning system that cannot be updated without re-clearing is a system whose greatest strength is regulatorily frozen. Getting this right is where SaMD regulation is genuinely at the frontier.