SaMD vs SiMD: What They Are and Why the Difference Decides Your Regulatory Path

SaMD stands for Software as a Medical Device. SiMD stands for Software in a Medical Device. The one-line difference: with SaMD the medical function belongs to the software itself, while with SiMD the medical function belongs to the hardware and the software exists to make that hardware work.

The most common mistake is to define SaMD by where it runs. It is tempting to say “SaMD runs on general-purpose hardware like a phone or a cloud server, and SiMD runs on the device.” That is usually true, but it is not the actual test. The load-bearing criterion for SaMD is functional independence. A diagnostic image-analysis application can sit on a scanner’s own console and still count as SaMD, as long as the scanner does not need that application to fulfill its own intended use. The reverse anchor for SiMD is necessity: the device cannot do its medical job without the software.

Keep those two words in mind as you read the rest: independence for SaMD, necessity for SiMD.

What Is Software as a Medical Device (SaMD)?

The International Medical Device Regulators Forum (IMDRF) defines SaMD as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. Three parts carry the weight of that definition: the software has a medical purpose, it performs that purpose itself, and it is not part of a hardware device.

Where SaMD typically lives

SaMD usually runs on general-purpose computing platforms: the cloud, a smartphone, a tablet, or a standard clinical workstation. That is the common case, but remember it is the usual deployment, not the defining property.

SaMD examples

• Diagnostic image-analysis software that flags a suspected finding on a general workstation.
• A clinical decision support application that recommends a medication dose from patient data.
• Software that analyzes continuous glucose readings to surface trends and alerts, running on a phone rather than on the sensor itself.
• A triage algorithm that prioritizes radiology worklists.

In each case the software delivers the medical value on its own. No single piece of hardware is required for it to do its job.

The market reflects how quickly this category is growing. Mordor Intelligence estimates the global SaMD market at roughly USD 3.81 billion in 2025, projected to reach around USD 19.58 billion by 2030, driven largely by clinically validated AI algorithms and cloud-native delivery. That trajectory is exactly why classification discipline matters: more teams are shipping standalone medical software than ever before, and many discover their regulatory obligations only after the architecture is set.

If you are early in scoping and unsure whether your product even qualifies, our guide on whether your app is medical device software walks through the qualifying questions in plain language.

What Is Software in a Medical Device (SiMD)?

SiMD is software that is integral to, and necessary for, a physical medical device. The software drives, controls, or is essential to the hardware’s medical function, and the device fails its intended purpose without it.

Firmware is the common form, not the boundary

SiMD is usually embedded firmware, so “embedded firmware” is a fair shorthand. It is not the actual boundary, though. The test is essentiality to the physical device, not whether the code technically counts as firmware. Some SiMD lives in higher-level application layers running on the device’s own processor. What makes it SiMD is that the device cannot achieve its medical purpose without it.

SiMD examples

• The control firmware in a pacemaker.
• The dosing and safety logic inside an infusion pump.
• The embedded measurement code in a blood glucose meter that converts a sensor signal into a reading.
• The control software in a ventilator that regulates airflow and pressure.

Pull that software out and the hardware becomes an inert shell. That dependency is the signature of SiMD.

SaMD vs SiMD: Side-by-Side Comparison

The table captures the mechanics, but the practical takeaway is simpler. SaMD is a product you can reason about, submit, and update largely on its own terms. SiMD is one component of a larger regulated device, and it moves at the pace of that device.

Why the Distinction Actually Matters

It sets your regulatory pathway

SaMD carries its own risk categorization and its own submission logic. When you build SaMD, you are building something a regulator will evaluate as a device in its own right. SiMD generally rides along inside the whole-device submission and is assessed as part of that package rather than on its own. Teams that plan for the correct pathway from day one avoid the expensive surprise of discovering, late in development, that their software needs an independent evidence base. This is one of the first decisions we help clients lock down in medical device software development engagements, because it shapes everything that follows.

It shapes your documentation and evidence burden

SaMD often requires independent clinical evaluation to show the software does what it claims safely and effectively. SiMD tends toward device-level verification and validation, where the software’s behavior is proven as part of the device’s overall performance. The volume and structure of your evidence trail differ accordingly.

It affects your post-market and update strategy

This is where the two diverge most sharply in practice. A SaMD product can be updated on a software cadence, subject to change-control rules. SiMD updates are gated by the device lifecycle and can trigger reassessment of the whole device. For anyone building modern, AI-driven software, this update question becomes the hardest part of the plan.

How SaMD Is Classified: The IMDRF Risk Framework

The IMDRF risk framework classifies SaMD along two axes.

Axis one: the significance of the information the software provides to a healthcare decision. Does the output treat or diagnose, drive clinical management, or merely inform clinical management? Software that directly informs a treatment decision sits higher on this axis than software that provides supporting context.

Axis two: the state of the healthcare situation or condition. Is the condition critical, serious, or non-serious? Software touching a critical condition sits higher than software touching a minor one.

The intersection of these two axes produces four risk categories, labeled I through IV in ascending order of impact. A worked example: software that provides diagnostic information to treat a critical condition lands in the highest category, while software that informs the management of a non-serious condition lands in the lowest.

One caution worth stating plainly. The FDA maps these concepts into its own risk-based approach rather than adopting the IMDRF grid one-to-one, so the category label is a starting point for reasoning about risk, not a substitute for the specific pathway analysis your product needs. If your software is a component sitting inside a larger device, the safety class you assign under IEC 62304 also flows from this risk thinking; our explainer on IEC 62304 software safety classes covers how Class A, B, and C map to potential harm.

The AI/ML Wrinkle: Why This Question Keeps Getting Harder

Most modern SaMD questions now involve AI or machine learning, and that is where classification collides with the regulatory model. A traditional device is fixed at clearance. A continuously learning model, by design, changes after clearance. The old assumption that a cleared device stays the same no longer holds.

The scale of this shift is visible in the authorization data. According to MedTech Dive’s tracking of the FDA’s device list, the FDA authorized 331 AI-enabled medical devices in 2025, the most in a single year in the agency’s history, out of well over a thousand cumulative authorizations since the 1990s. A large share of these are SaMD, which is precisely why the update problem has moved to the center of regulatory strategy.

The FDA’s answer is the Predetermined Change Control Plan (PCCP), whose final guidance was issued in December 2024. A PCCP lets a manufacturer pre-specify the kinds of model changes it intends to make, and the methods it will use to validate them, so that certain updates can ship without a brand-new submission each time. If you are building adaptive AI, designing the PCCP in from the start is the difference between iterating freely within agreed limits and filing a fresh clearance for every model refresh.

Two other 2024-to-2026 developments matter for software teams. The Quality Management System Regulation (QMSR) took effect in February 2026, aligning FDA quality-system requirements more closely with ISO 13485, which changes how software teams structure their design controls and quality processes for both SaMD and SiMD. And the FDA’s Computer Software Assurance (CSA) final guidance, issued in September 2025, modernized how manufacturers validate the software behind production and the quality system, favoring a risk-based approach over blanket documentation. Note the scope carefully: CSA covers the tools used to manufacture devices and run the quality system, not the SaMD or SiMD product itself, which stays under design-control validation. It shapes your operating environment rather than your device software directly.

These are moving targets. Before you commit an architecture, confirm the current state of each guidance against primary FDA sources, because the practical rules here are still evolving quarter to quarter.

How to Tell Which One You Are Building

Work through three questions in order.

1. Does the software perform a medical purpose on its own? If no, it may be general wellness software, or an accessory, or not a medical device at all.
2. Can it fulfill that purpose without being part of a specific hardware device? If yes, you are almost certainly looking at SaMD.
3. Is a physical device dependent on this software to achieve its intended medical use? If yes, you are looking at SiMD.

Watch the gray zones, because misclassifying here is a common and expensive early-stage mistake:

• General wellness products that make no medical claim usually fall outside device regulation, until a feature quietly crosses into diagnosis or treatment.
• Accessory software that supports a device without performing a medical purpose itself needs careful analysis.
• Medical device data systems (MDDS) that only transfer, store, or display data sit in their own lightly regulated space, until they start interpreting that data.

The trap that catches the most teams is marketing language. A wellness app that “detects” a condition has just described a diagnostic claim, and a diagnostic claim can convert an unregulated app into an unapproved medical device overnight. If you are unsure which bucket you fall into, an early assessment with a team experienced in medical device software development can save months of rework later.

Ailoitte Insight: Turning the Classification Into an Engineering Plan

The regulatory distinction only earns its keep when it changes how you build. Here is how we translate SaMD versus SiMD into concrete engineering decisions on medical device software development projects.

For SaMD teams, the work centers on an independent software lifecycle governed by IEC 62304, standalone risk management under ISO 14971, and interoperability and cybersecurity treated as first-class requirements rather than afterthoughts. Because SaMD so often lives in the cloud or on a phone, data handling and HIPAA readiness sit at the core of the architecture, not at the edges. The update pipeline needs to be designed around change control from the first sprint, especially for AI-driven products where a PCCP will govern what you can ship without re-clearance.

For SiMD teams, the work is tight hardware and software co-design. Real-time behavior and safety constraints dominate, verification is bound to the device lifecycle, and change control is gated by the device submission rather than a software release calendar. You cannot move faster than the hardware program allows, so the discipline is in planning software milestones around device milestones.

The shared ground is larger than teams expect. IEC 62304 lifecycle processes apply to both. Risk management applies to both. Rigorous documentation applies to both. The difference is the scope and independence of evaluation, not whether the rigor is optional.

We put this into practice on a connected glucose monitoring build, where the on-device measurement layer and the companion analytics software had to be reasoned about as different regulatory objects even though they shipped as one experience for the patient. You can see how that separation played out in our connected glucose monitor case study.

Cost tracks classification too. Independent SaMD evidence and standalone submissions carry a different budget profile than SiMD verification folded into a device program. If you are scoping numbers, our breakdown of medical device software development cost lays out where the money actually goes across classes and pathways.

The Bottom Line

SaMD and SiMD are not two flavors of the same thing. They are two different relationships between software and a medical purpose. SaMD is the medical device. SiMD makes a medical device work. That single distinction sets your regulatory pathway, your evidence burden, your update strategy, and your budget, which is why classification is the first design decision on any serious build, not a compliance box to tick at the end.

If you are scoping a medical software product and want to get the classification and the pathway right before writing a line of code, our team builds regulated software across both categories. Start with our medical device software development capability to see how we approach it.

Discover how Ailoitte AI keeps you ahead of risk

Let's Talk

Sunil Kumar

Sunil Kumar is CEO of Ailoitte, an AI-native engineering company building intelligent applications for startups and enterprises. He created the AI Velocity Pods model, delivering production-ready AI products 5× faster than traditional teams. Sunil writes about agentic AI, GenAI strategy, and outcome-based engineering. Connect on LinkedIn