SaMD FDA Submissions: How Software Architecture Becomes Your Regulatory Evidence

SaMD, software that performs a medical purpose on its own (diagnosing, monitoring, or informing treatment) without being part of a physical device, is where I've seen good engineering and good regulatory strategy either reinforce each other or work against each other. This article maps five architecture decisions made as good practice to the FDA regulatory equivalents, so you can see which parts of your submission you're already building and which still need attention. 

This is the first piece co-created with Janet Kwiatkowski, founder and CEO of MAE Group, a strategic partner in the Monterail Universe. Janet and her team guide medical device and in vitro diagnostic companies through government submissions, verification and validation reviews, regulatory training, and the full route to market. MAE Group covers the regulatory gap between a working prototype and a device that's cleared, funded, and on the market. What follows draws on her read on FDA expectations and Monterail's experience building the software side.

Executive Summary

A medical device engineering team and an FDA reviewer rarely use the same words: product teams talk about traceability, test coverage, and clean module boundaries; reviewers talk about design controls, verification, and risk files. Underneath the vocabulary, both want the same thing: evidence that the software does what it claims and that the team can prove it. Most of what FDA needs already exists before submission preparation starts. If you skip that, you risk a rebuild under deadline pressure instead.

What's the Difference Between SaMD, SiMD, and AI-Enabled Device Software?

FDA doesn't treat all medical software the same, so before getting into architecture, ask: is the software function actually a medical device, and if so, how will FDA regulate it? For software that's regulated as a medical device, three concepts matter:

Each of these changes what a reviewer looks for. This post focuses on Software as a Medical Device, the case where the code is the product. Most of what follows applies to the other three, but the depth of evidence shifts, and AI carries its own rules that we cover near the end.

How Software Architecture Becomes Regulatory Evidence: Five Architecture Decisions 

Here's where that shows up across five architecture decisions your team is already making, one way or another. 

How Does Traceability Satisfy FDA Design and Development Controls?

Traceability means every requirement links forward to the design that implements it and the test that proves it, and links backward from any line of code to the reason it exists. If your team keeps this chain intact, they'll easily be able to tell why each part of the system is there and where a change occurred.

FDA expects traceability to show a coherent story: what the software was required to do, how that requirement was implemented, what risks were considered, and what testing demonstrates it works as intended. For a Class II SaMD, a reviewer should be able to follow that chain, from requirement to design to test, without reconstructing it from separate documents. - Janet Kwiatkowski, MAE Group 

The most common gaps are surprisingly simple: requirements with no linked verification, tests that cannot be traced back to a requirement or risk control, software changes that are not carried through the risk and test documentation, and different documents referencing different software versions. The problem becomes most visible when traceability is assembled retrospectively for the FDA submission. At that point, the team may have plenty of documentation but struggle to demonstrate that the requirements, risks, implementation, and verification all describe the same device.

What Does FDA Expect From Configuration Management in a SaMD Release?

Version control tracks every change to the code. For a SaMD product, configuration management captures the exact combination of code, dependencies, configuration, and environment that produced a given build, so the team can recreate that build later. Each released version becomes a fixed, identifiable state, and you can point to any two versions and say what changed between them and why.

FDA expects more than a log of who edited a line and when. The team should be able to define exactly what makes up a released version of the device. You need to name the software, its dependencies, its configuration, and any other controlled components, and show how you evaluated, approved, tested, and folded each change into that release.

This matters most at clearance. The version in users' hands must trace back to the version FDA reviewed and to the evidence behind it. If the final release differs from the version used for verification, validation, or clinical testing, you must understand, document, and assess that difference before release. — Janet Kwiatkowski, MAE Group

We saw this during an 11-year collaboration building Elvie's connected FemTech devices. FDA Class II exemption and MDR documentation requirements shaped the architecture at every layer, including a screenshot-generation system that kept validation artifacts current for every release. The evidence was produced alongside the code.

Version control tells you what changed, while configuration management proves which device those changes produced. The goal is to know exactly what was tested, exactly what was released, and exactly what changed.

Is Automated Testing Enough for FDA Verification and Validation?

Automated tests answer two different questions. Verification asks whether the software was built correctly against its specification. Validation asks whether the software meets the user's actual clinical need and intended use. A mature testing strategy supports both. Unit and integration testing can provide verification evidence, while validation considers the software in the context of its intended users, intended use, and real-world use conditions. Automation makes testing repeatable and consistent across builds, but the results still need to be controlled, traceable, and connected to the requirements and risks they are intended to address.

From FDA's perspective, verification and validation answer related but different questions: did you build the software correctly, and did you build the right software for its intended use? Teams sometimes conflate the two by assuming that because every software requirement passed its test, the device has been validated. FDA looks beyond whether the code passed. It looks at whether the overall evidence demonstrates that the software can safely and effectively perform its intended medical function.

Automated testing can provide strong objective evidence, but a passing test result needs context. The test should be traceable to the applicable requirement and risk, use predefined acceptance criteria, identify the software configuration tested, and preserve the results. 

How Does ISO 14971 Risk Management Connect to Your Software Architecture?

Risk-based development means the highest-risk parts of the system get the most design attention, the most testing, and the clearest controls. The team identifies how the software could contribute to a hazardous situation or patient harm, decides how the software prevents or mitigates it, and builds those controls into the architecture from the beginning. The risk analysis and the code evolve together, so a mitigation in the risk file has a matching control you can point to in the system.

ISO 14971 is the standard framework for identifying hazards, evaluating the risks they present, implementing controls, and judging whether remaining risk is acceptable across the device's lifecycle. For SaMD, FDA expects risk management to connect directly to the software design as it's built.

A reviewer should be able to follow a meaningful risk from the hazardous situation to the control implemented in the software, the requirement that defines that control, and the verification evidence demonstrating that the control works. When the software changes, the risk analysis should evolve with it.

For example, if invalid patient data could produce an incorrect clinical output, the software might include an input-validation control that prevents incomplete, corrupted, or out-of-range data from reaching the clinical algorithm. That control should be traceable from the identified risk to the software requirement, its implementation, and the testing that demonstrates it works. - Janet Kwiatkowski, MAE Group 

If the risk control is implemented in software, a reviewer should be able to find it in the architecture, not just in the risk file.

How Does Modular Design Support Regulatory Scope? 

Modular design keeps components with different responsibilities separate, with clear boundaries between them. For a medical product, that separation can carry regulatory value. Device functions can be distinguished from functions that do not perform a medical-device purpose. Good boundaries also make it easier to understand how a change to one function could, or could not, affect the safety, effectiveness, or performance of another.

This practice pays off most when a team is moving fast. FDA regulates software based on function and intended use, not on where code physically sits in the architecture. A single product can contain both regulated device functions and functions that aren't subject to FDA oversight at all. 

That separation becomes particularly valuable when the software changes. If a non-device feature is separated from the medical-device function, it is easier to demonstrate whether the change could affect the regulated function. When everything is tightly coupled, even a seemingly unrelated change can create a much larger regulatory impact assessment.

The better the separation, the easier it is to demonstrate what a change does, and does not, affect.

How Much Evidence Does Your Device Require?

The five principles hold across the board. What changes is the depth of evidence needed to support them. Many regulated SaMD products are Class II, making the 510(k) pathway a useful baseline for this discussion. But software is not classified simply because it is SaMD. The pathway depends on what the software does, its intended use, and the risk it presents.

The evidence burden follows both the regulatory pathway and the software's risk, not the class number alone. A 510(k) generally builds on an established device classification and predicate; a De Novo addresses a novel device without an appropriate predicate and must establish that its risks can be appropriately controlled; and a Class III PMA requires substantially greater evidence to demonstrate reasonable assurance of safety and effectiveness.

FDA also scales the software documentation itself according to risk. Its current guidance uses Basic and Enhanced Documentation Levels, with Enhanced Documentation expected when a software failure or flaw could create a hazardous situation with a probable risk of death or serious injury. That means two Class II SaMD products may not necessarily carry the same software evidence burden.

How Does AI Change FDA Requirements for SaMD?

When a SaMD product includes AI, what matters most is what the AI actually does and how its output is used. Software that generates a diagnosis, treatment directive, risk score, or time-critical clinical output raises very different regulatory considerations from software that supports a healthcare professional with information or recommendations they can independently evaluate. But simply putting a clinician "in the loop" does not make an AI-enabled function non-device software. The intended use, type of input, nature of the output, clinical risk, and the clinician's ability to independently review the basis for a recommendation all matter. The same discipline applies to the AI itself.

Calling a product "AI-enabled" means being prepared to explain what the AI does, what data were used to develop and validate it, how its performance and limitations were evaluated, and how it will be controlled as the product evolves. In a medical device, "AI" isn't a marketing adjective. It's a technology you have to stand behind. - Janet Kwiatkowski, MAE Group

That ability to explain, validate, and control the AI starts with the build itself, which is why architecting an AI pipeline for medical diagnostics is where much of that evidence is created or lost.

Open-source and third-party models or software components are not inherently a regulatory problem, but they do create responsibilities. Teams need to understand what is incorporated into the device, its dependencies and vulnerabilities, the cybersecurity risks it introduces, and how those risks will be managed throughout the product lifecycle.

With AI-enabled SaMD, architecture decisions, regulatory strategy, and clinical claims need to develop together, because changing one can change the evidence required for the others.

What a Strong Submission Looks Like 

By the time a Class II SaMD reaches FDA, the reviewer should not have to assemble the story from disconnected documents. 

The submission should make three things clear: what the software is intended to do and what evidence supports those claims; what could go wrong and how those risks are controlled; and how the requirements, risks, architecture, testing, and released software version connect.

That is where the five architecture principles in this article come together. Traceability connects the evidence. Configuration management establishes exactly which software the evidence supports. Verification and validation demonstrate that the software performs as intended. Risk management connects potential harm to actual controls. Modular architecture also makes the boundaries of regulated functionality and the impact of changes easier to understand.

A submission ultimately results from regulatory decisions made throughout development. Decisions about intended use, clinical claims, FDA pathway, risk, AI functionality, and the evidence needed to support the product can influence the software long before a submission is prepared. When teams make those decisions early and carry them through development, the submission reflects the work already done.

The strongest submission is the one where the evidence tells a consistent, traceable, and defensible story.

Aligning Architecture and Regulatory Strategy

Good architecture underpins compliance. The best FDA submissions are built before they're written.

When should regulatory and software development expertise enter the conversation? Earlier than many teams think. Whether you're still determining if your software is a regulated medical device, defining the FDA pathway and clinical claims, incorporating AI, planning an FDA Pre-Submission, designing the software architecture, or discovering that regulatory evidence is being rebuilt, bringing MAE Group and Monterail into the project together can align regulatory and technical strategy before critical decisions get hard to change.

Through our strategic partnership, MAE Group and Monterail work alongside SaMD companies as an integrated commercialization and technology partner. MAE Group brings FDA regulatory, clinical, quality, risk-management, and commercialization expertise. Monterail brings the software architecture, engineering, and development capability to turn those requirements into the product itself. Together, we connect regulatory strategy with software development from the outset, so companies build SaMD that is technically strong, clinically purposeful, and designed with FDA clearance and commercialization in mind.

The best time to align software architecture and regulatory strategy is before either one becomes expensive to change.