A Closer Look At Software as a Medical Device (SaMD)

Software is no longer just a component of medical devices. Increasingly, it is the device.

From AI-powered diagnostics to mobile apps that guide dosing decisions, software as a medical device (SaMD) is transforming patient care. But that innovation comes with intense regulatory scrutiny. And for growing life sciences teams, the stakes are high. One misstep in documentation, risk management, or validation can delay approvals and invite audit findings that compound over time.

The challenge is that most teams are building in two worlds at once. They’re operating at the speed of agile development while trying to satisfy frameworks built for hardware-based devices. When you’re running lean, managing both worlds without rework, gaps, or compliance risks requires more than good intentions.

This guide breaks down the most common questions quality, regulatory, and product leaders ask about SaMD. More importantly, it shows how real teams are building compliant, scalable infrastructure that supports rapid innovation. Whether preparing a first 510(k) or scaling a CE-marked platform across markets, this is a playbook for modern SaMD operations.

Section 1: What Qualifies as SaMD and Why It Matters Early

Regulators define software as a medical device (SaMD) as software intended to be used for medical purposes without being part of a hardware medical device. That includes applications that diagnose conditions, recommend treatment plans, or support clinical decisions, whether running on a phone, in the cloud, or embedded within a health system.

At first glance, it might seem like a simple distinction. But getting it wrong can trigger serious regulatory misalignment. Teams that assume their software is just a tool or accessory often skip essential controls, only to find out later they’ve been operating under the wrong classification.

Early misclassification can undermine your entire product strategy. Regulatory pathway, documentation requirements, clinical evaluation standards, and post-market obligations all hinge on whether your software qualifies as SaMD. In regions like the EU, a mobile app with a dosing algorithm can carry the same risk classification as a Class IIb device.

Understanding how your product is categorized shapes every downstream decision. Whether you need IEC 62304 documentation. How you validate updates. How you manage change control. It determines the burden your QMS must support and how your regulatory team scopes the design and development file.

Teams that define this early avoid rework later. Teams that guess end up rewriting DHFs and scrambling through CAPAs when notified bodies or FDA reviewers spot inconsistencies.

This foundational call isn’t just about labels. It’s about ensuring your infrastructure matches the regulatory demands your product is going to face.

Section 2: How SaMD Is Regulated in the U.S. and EU

In the U.S., the FDA regulates SaMD through its medical device framework. Most products fall under Class I, II, or III, depending on risk. A Class I wellness app faces minimal oversight. A Class II digital diagnostic likely requires a 510(k). For novel or high-risk software, a De Novo or PMA pathway is often required.

The FDA applies traditional medical device standards to SaMD, including requirements for design controls, software validation, cybersecurity risk assessments, and labeling. But its guidance also acknowledges the iterative nature of software development. Submissions should reflect a controlled, traceable process with an appropriate level of rigor based on the risk classification.

In the EU, SaMD falls under the Medical Device Regulation (MDR). Many software products that previously avoided regulation under the old MDD are now classified as medical devices. Classification depends on intended use and the information provided by the software. Under Rule 11 of the MDR, even decision-support tools can be Class IIa or IIb if they influence treatment decisions.

CE marking under MDR requires a notified body review for most SaMD products. Teams must build a technical file that includes software documentation, risk analysis, clinical evaluation, and post-market surveillance planning. The bar is high, even for standalone digital tools.

Comparison of U.S. vs. EU SaMD Regulatory Frameworks

Regulatory pathways affect more than submissions. They define the level of control your QMS needs to support. They shape testing protocols, traceability matrices, and release validation workflows. Misalignment between your process and the regulatory framework adds friction, slows approvals, and can erode reviewer confidence.

Understanding these frameworks early, ideally before writing a line of code, helps teams scope what compliance infrastructure they need to build.

Section 3: Which Standards Apply to SaMD and How to Operationalize Them

Software as a medical device isn’t exempt from traditional medical device standards. In fact, it’s subject to some of the most rigorous, especially when safety-critical algorithms or clinical decisions are involved. Regulatory bodies expect software teams to demonstrate not just functionality, but repeatable, traceable, and risk-aware development processes. That expectation is codified in several globally recognized standards.

IEC 62304 is the core lifecycle standard for SaMD. It defines how software must be developed, maintained, and tested across its full lifecycle. But it doesn’t operate in isolation. ISO 13485 sets the foundation for quality management. ISO 14971 defines how to assess and control risk. And for many teams, IEC 82304-1 adds additional requirements around safety, usability, and cybersecurity.

Complying with these standards isn’t about filling out templates. It’s about embedding compliance into your day-to-day systems. If your design history file lives in Google Drive and your risk file is in Excel, mapping requirements across documents becomes a manual burden that grows with every iteration.

Teams that operationalize these standards early avoid costly rewrites and rushed audits. They don’t rely on static SOPs to prove control. They use infrastructure that links requirements to test cases, risk mitigations to code modules, and validation plans to real-world usage scenarios.

That’s why many teams turn to purpose-built systems early in their journey. Kivo helped Hyloris double its clinical programs in two years by giving their team a quality system that mapped each software update to the right standard, linked documentation to risk controls, and eliminated the need for duplicative paper trails across functions.

SaMD compliance is not just about meeting the letter of the standard. It’s about designing systems that make the right way the easy way.

Section 4: What Regulatory Bodies Want to See in Your Submission

Submitting a SaMD product isn’t about convincing reviewers that your software works. It’s about demonstrating that every requirement, test, and decision has been documented, justified, and tied back to patient safety.

Regulatory bodies expect a full technical documentation package. In the U.S., that typically includes a Design History File (DHF), software description, software requirements specifications, architecture diagrams, verification and validation protocols, traceability matrices, cybersecurity documentation, labeling, and user documentation. For the EU, these elements are wrapped into the Technical File required for CE marking under MDR.

Each document tells a story:

• How the software was built
• How risks were identified and mitigated
• How each feature supports the intended medical purpose

Reviewers aren’t just checking for completeness. They’re assessing whether your documentation reflects a disciplined, risk-based development process.

Missing or mismatched documentation is one of the most common reasons for delays. Teams often write requirements after code is developed, or skip traceability entirely. These shortcuts might save time upfront, but they create major gaps that need to be backfilled under pressure.

The strongest submissions are built incrementally. Each requirement, test plan, and risk analysis is created and linked as the software evolves. Kivo helped Elpida prepare its GxP infrastructure to support the documentation demands of regulatory submission. Their team didn’t wait for validation to start writing. They used a system that connected documentation with execution from day one.

Documentation is not a separate process. It’s how you prove that the process you followed was controlled, compliant, and focused on patient outcomes.

Section 5: SaMD Risk Management Isn’t Optional

For software that influences clinical decisions or automates critical functions, risk isn’t theoretical. It’s operational. Every missed error message, incorrect output, or design flaw has the potential to affect patient safety—and regulators expect teams to show they’ve accounted for that from the start.

ISO 14971 is the global standard for medical device risk management. For SaMD, it must be interpreted through a software lens:

• Identify software-specific hazards, such as algorithmic bias, failure of decision logic, or incorrect data parsing

• Document how risks are evaluated, mitigated, and traced

• Map mitigations through architecture, requirements, and verification

Risk management doesn’t live in a spreadsheet. It lives in your architecture, your documentation, and your decision-making. A strong risk process:

• Surfaces potential hazards early

• Shapes design decisions

• Drives testing and control strategies

Where teams fall short is in traceability. Risk mitigations are often documented but not connected to user needs, software requirements, or verification steps. Reviewers notice. So do auditors.

Kivo helped SSI set up its entire quality system with traceability in mind from day one. Their risk controls were tied directly to functional requirements and test cases inside a structured, audit-ready environment.

Effective SaMD risk management requires more than a FMEA or a checklist. It requires a system where risk thinking is built into the software lifecycle itself.

Section 6: What Validation Really Means for SaMD

Validation isn’t just about confirming that your software works. It’s about proving that it works as intended, under expected use conditions, and within a controlled environment.

For SaMD, validation must cover the full software lifecycle. That includes:

• Verification of code and functions against documented requirements

• Validation of the software system in its intended use context

• Testing under worst-case scenarios and edge conditions

• Documentation that links user needs, risks, requirements, and test results

Regulators expect independent validation. That doesn’t mean an outside vendor is required, but it does mean teams need separation between development and validation activities. The person who wrote the code shouldn’t be the one approving its release.

Where teams run into trouble is during updates. Each software change must be assessed for impact, documented, and revalidated where necessary. Without infrastructure to support change control and regression testing, teams fall into the trap of treating validation as a one-time event.

Validation is not a checkbox. It’s a repeatable practice.

That’s why Kivo designed its platform to support validation across the full product lifecycle. Kivo's QMS is designed for medical devices  and provides pre-validated infrastructure that meets regulatory expectations out of the box (while also supporting customer-specific configurations and workflows). Teams don’t have to choose between speed and compliance.

When validation is built into the way teams work, inspections go faster, submissions are cleaner, and development can move without constant slowdowns.

Section 7: Tools That Help (and Hurt) SaMD Compliance

Early-stage teams often default to generic tools: SharePoint for document storage, Excel for traceability, email for approvals, and Jira or GitHub for development tracking. But these tools weren’t designed for regulated environments. They lack audit trails, version control, and the controls required under Part 11 or ISO 13485.

The result is fragmentation. Documents live in one place. Risk logs live in another. No one has confidence in what’s final, what’s draft, or what’s been approved.

SaMD development demands systems that:

• Maintain immutable audit trails for all activity

• Support role-based access and electronic signatures

• Allow traceability from user needs to validation tests

• Provide structured, reportable views for internal and external review

That’s why SSI replaced its spreadsheets with Kivo. As a service provider, they needed audit-ready documentation from day one. Their team used Kivo to establish controlled, compliant processes that didn’t slow their scientists or consultants down.

Generic tools can work in the early stages, but they accumulate compliance debt that becomes harder to unwind as you approach submission or inspection.

For SaMD teams, compliance needs to be built into daily operations rather than treated as an afterthought.

Section 8: What Is The Difference Between SaMD vs. SiMD?

Not all software used in medical devices is considered SaMD. Some is classified as SiMD, or software in a medical device. The distinction has major implications for how your product is regulated.

SaMD refers to software that performs a medical function without being part of a physical device. Examples include mobile apps that analyze heart rate data or cloud-based platforms that assist in diagnosing diabetic retinopathy.

SiMD, on the other hand, is software that is part of a medical device’s internal system. Think of firmware in a pacemaker or code running a hospital infusion pump. It is inseparable from the hardware and is evaluated as part of the device itself.

The difference changes how the product is scoped, classified, and reviewed.

Comparison of SaMD vs. SiMD

With SaMD, the software is the product. It must meet all relevant device requirements independently. That includes safety, performance, risk management, and post-market surveillance. With SiMD, the software is part of a larger device system and is evaluated within that context.

Getting the classification wrong leads to documentation gaps, testing errors, and misalignment with regulatory expectations. Teams building modular systems or digital companions must pay close attention. Regulators will expect clear rationales for how the software is categorized and how that shapes the development and quality approach.

When in doubt, align your documentation and infrastructure with the stricter interpretation. The cost of over-preparing is almost always lower than the cost of rebuilding when notified bodies or the FDA ask for more.

Section 9: How To Stay Compliant Post-Market

Bringing SaMD to market is only half the battle. The real work begins once it’s in the hands of users.

Regulators expect teams to maintain oversight of software products after launch. That includes monitoring for bugs, cybersecurity vulnerabilities, and performance issues. It also includes assessing whether software updates require revalidation, new risk assessments, or regulatory notification.

Post-market compliance for SaMD requires systems that can:

• Track changes to code, documentation, and risk files in a controlled manner

• Link post-market surveillance findings back to risk management and design controls

• Automate change impact assessments

• Document and validate updates according to classification and intended use

Without these systems, post-launch updates become a source of compliance drift. Teams make quick fixes without full traceability. Documentation gets skipped or delayed. What was once a validated, inspection-ready product becomes a black box.

This is where many SaMD teams get caught off guard. What worked during development doesn’t scale in production. Kivo's QMS helps medical device teams stay inspection-ready by embedding change control, risk tracking, and documentation management into a unified platform. Updates are tracked, linked, and auditable, so nothing slips through the cracks.

Compliance doesn’t end at launch. For SaMD, it must evolve alongside the product.

Section 10: QMS Purpose-Built for SaMD, SiMD, and What Comes Next

The path to market for software-based medical products isn’t getting simpler. Whether you're building SaMD, SiMD, a digital diagnostic, or a combination product, regulators expect more structure, more traceability, and more control.

Compliance isn’t a checklist. It’s a system that supports how your team builds, validates, and evolves your product across development, submission, and post-market.

Kivo was built with these challenges in mind. Our platform supports:

• SaMD and SiMD teams managing complex design control and validation requirements

• Combination product developers integrating device and drug documentation

• Fast-moving teams who need inspection-ready traceability without losing agility

We bring QMS, document control, validation, and submission-readiness into one system. No silos. No duplications. Just a foundation you can scale on.

If you'd like to discuss any of this with our helpful team of life sciences experts, click below to schedule a chat. We'd love to hear about what you're working on, whether or not Kivo is a good fit for your team.