Software as a Medical Device (SaMD) is one of the fastest-growing categories in healthcare technology, and one of the most misunderstood. A single app on a phone can now detect an irregular heart rhythm, flag a stroke for a radiologist, or screen for diabetic eye disease, all without being wired into any hardware device. That capability is powerful, and it is also heavily regulated.
The confusion usually starts with the boundaries. Teams building a health app often cannot tell whether their product is a regulated medical device or a wellness tool that sits outside FDA oversight, and the answer changes everything about how they build, fund, and launch. Get it wrong in one direction, and you invite regulatory trouble. Get it wrong in the other, and you spend a year building compliance you never needed. Understanding where SaMD begins and ends is the first real decision a medical software company makes.
This guide explains what SaMD is, how it is defined and classified, how the FDA regulates it, and what it takes to build it. It is written for the teams who most often confront these questions for the first time: startup medical device companies moving an idea toward a real, regulated product. Along the way, it links to deeper resources on each subtopic, and to how Sequenex helps companies build SaMD they own.
What Is Software as a Medical Device (SaMD)?
Software as a Medical Device (SaMD) is software intended to perform one or more medical purposes without being part of a hardware medical device. It runs on general-purpose computing platforms such as smartphones, tablets, and cloud servers, and it delivers its medical function through software alone.
That last point is what sets SaMD apart. A blood glucose meter is a hardware device. An app that takes glucose readings and calculates an insulin dose is software performing a medical purpose on its own, which makes it SaMD. The software does not drive a piece of hardware; the software is the medical product.
SaMD can diagnose, screen, monitor, or support treatment decisions. Because it operates independently of dedicated hardware, it can be updated, distributed, and scaled like any other software, while still being held to the safety and effectiveness standards of a medical device. The rest of this guide covers how regulators define SaMD, how they classify it by risk, the FDA pathways it follows, and how it is engineered.
It helps to see what SaMD is not. A fitness tracker that counts steps is not SaMD, because counting steps is not a medical purpose. An electronic health record that stores a doctor’s notes is not SaMD, because it is not performing a medical function on the data. A messaging app that lets a patient chat with a nurse is not SaMD. The line is always the same question: is the software itself doing something medical, such as diagnosing, screening, or guiding treatment? If yes, it is likely SaMD. If it is only supporting, storing, or communicating, it usually is not.
The IMDRF Definition of SaMD and Why It Matters
SaMD is formally defined by the International Medical Device Regulators Forum (IMDRF) as software intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device. This is the definition regulators around the world have converged on, and it is the one the FDA applies.
A shared definition matters because SaMD crosses borders easily. The same app can be downloaded in a dozen countries, so regulators benefit from a common starting point for what counts as SaMD and what does not. The IMDRF framing gives them that foundation, then each regulator applies its own rules on top.
The load-bearing phrase in the definition is that it is not part of a hardware medical device. This is the test that separates SaMD from software embedded in devices, and it is the phrase every founder should be able to apply to their own product. If the software performs its medical purpose on its own, it is SaMD. If it exists to operate a piece of hardware, it is something else, which the next section explains.
The IMDRF framing also clarifies that a medical purpose is what makes software SaMD, not the platform it runs on or the data it touches. Software running in the cloud, on a phone, or on a hospital workstation can all be SaMD if the intended use is medical. The intended use, stated by the manufacturer, is central: the same underlying technology can be a wellness product or a regulated medical device depending on what the maker claims it does. That is why intended-use statements are written with such care in this field, and why changing a claim can change a product’s regulatory status.
SaMD vs. Software in a Medical Device (SiMD)
SaMD differs from Software in a Medical Device (SiMD) in one decisive way: whether the software stands alone or is embedded in hardware. SaMD performs its medical function independently. SiMD exists to drive, control, or support a hardware device it lives inside.
The firmware that runs an infusion pump is SiMD. It is essential, it is regulated, but it is not a standalone medical product; it exists to make the pump work. By contrast, an app that analyzes data and returns a clinical result on its own is SaMD. The distinction is not about how sophisticated the software is. It is about whether the software is the product or a component of a hardware product.
Question | SaMD | SiMD |
Relationship to hardware | Runs independently on general-purpose computing | Embedded in and drives a specific hardware device |
Example | An app that screens images for disease | Pacemaker or infusion pump firmware |
What is regulated | The software as its own medical product | The software as part of the hardware device |
Getting this distinction right early matters, because it shapes the entire development and regulatory path. A team that mistakes its SaMD for a simple companion app, or its SiMD for a standalone product, can plan for the wrong requirements from day one.
The distinction also affects how a product is maintained and updated after launch. Because SaMD is independent software, it can often be updated over the air, which is convenient but means each significant update may need its own regulatory consideration. Software embedded in hardware is typically updated on the hardware’s cycle and validated as part of that device. Understanding which model a product follows helps a team plan not just the initial launch but the years of maintenance and updates that follow, which for most medical software is where the bulk of the lifecycle cost actually sits.
SaMD vs. Medical Device Data Systems (MDDS)
SaMD and Medical Device Data Systems (MDDS) sit on opposite sides of a line that determines how heavily a product is regulated. SaMD analyzes or acts on data for a medical purpose. An MDDS only transfers, stores, converts, or displays medical data without interpreting it.
That difference carries real regulatory weight. Following the 21st Century Cures Act of 2016, software-only MDDS is no longer considered a medical device under U.S. federal law. Software that moves a glucose reading from a sensor to a dashboard, without interpreting it, generally falls outside device regulation. The moment that software starts analyzing the reading, flagging it, or recommending an action, it crosses into SaMD, and device-level obligations apply.
Consider a single connected glucose product to see how the line works in practice. A module that receives readings from a sensor and displays them in an app is behaving as an MDDS. Add a feature that detects a dangerous downward trend and alerts the patient, and that feature is now interpreting the data to drive a health decision, which is SaMD. The same product can contain both, which is why teams map their features against this line individually rather than labeling the whole product at once. A product is not simply MDDS or SaMD; specific functions within it can fall on either side.
For a founder, this line is one of the most consequential distinctions in the entire field, because it determines whether the product carries the full regulatory burden of a device or sits outside it. Our full comparison of MDDS and SaMD works through the boundary in detail, and our overview of the FDA’s MDDS guidance covers the post-Cures-Act framing directly.
Real-World SaMD Examples: Products in the Market Today
SaMD already powers products used by millions of patients today. Looking at real, cleared examples is the fastest way to understand what the category covers, because the range is wider than most people expect. The products below span cardiac care, radiology, ophthalmology, and pathology, and each reached the market through an FDA pathway.
What unites them is that the software itself delivers the medical result. In each case, the value is not in a piece of hardware but in what the software concludes from data: a rhythm is irregular, a scan shows a likely stroke, an eye shows signs of disease. That is the essence of SaMD, and seeing it across very different clinical areas makes the definition concrete in a way an abstract description cannot.
Diagnostic and screening SaMD
IDx-DR, from Digital Diagnostics, autonomously detects diabetic retinopathy from retinal images and was authorized through the FDA De Novo pathway. Paige Prostate applies software to digital pathology slides to help detect prostate cancer. These products return a clinical result on their own, which places them squarely in SaMD. You can confirm any product’s status through the FDA device databases.
Monitoring and notification SaMD
The Apple Watch ECG and AFib History features analyze heart-rhythm data and notify the user of possible atrial fibrillation. iRhythm’s Zio service analyzes ambulatory cardiac data to identify arrhythmias. Viz.ai’s stroke-triage software analyzes brain imaging and alerts a specialist when it detects a suspected large-vessel occlusion, compressing the time to treatment for stroke.
One caution worth stating: the fact that one product in a category was cleared does not make the category automatically cleared. The FDA evaluates each SaMD on its own intended use, evidence, and risk. A similar-looking app is not exempt because a competitor reached the market first.
For examples in a specific therapeutic area, see our look at SaMD opportunities in diabetes care.
SaMD Classification: The IMDRF Risk Framework
SaMD is classified by the risk it poses, using a framework built on two factors: the significance of the information the software provides to a healthcare decision, and the seriousness of the healthcare situation or condition it addresses. Together, these two axes place a given SaMD into one of four risk categories.
The significance axis runs from software that informs a decision, to software that drives a decision, to software that treats or diagnoses. The healthcare-situation axis runs from non-serious, to serious, to critical. A SaMD that diagnoses a critical condition sits at the top of the risk scale. A SaMD that informs a decision about a non-serious condition sits at the bottom.
IMDRF category | Roughly means | Example |
Category I (lowest) | Informs a non-serious situation | An app suggesting general wellness adjustments |
Category II | Drives a non-serious case, or informs a serious one | Software helping triage a non-critical condition |
Category III | Drives a serious case, or informs a critical one | Software guiding treatment of a serious disease |
Category IV (highest) | Diagnoses or treats a critical situation | Software diagnosing a life-threatening condition |
The FDA does not use these IMDRF categories as its formal device classes, but it uses the same risk logic to decide how much scrutiny a SaMD receives and which pathway it follows. How a product is classified also shapes how its software should be structured, which we cover in component architecture for SaMD development.
Classification is not an academic exercise. It determines the evidence a product must generate, the pathway it will follow, the cost of reaching market, and the timeline. A founder who understands early that their product lands in Category III or IV can plan for the clinical evidence and regulatory investment that level demands, rather than discovering it late, when the software is built, and the runway is short. Misjudging risk downward is one of the most expensive mistakes in SaMD, because it surfaces at exactly the moment it is hardest to fix.
FDA Regulatory Pathways for SaMD: 510(k), De Novo, and PMA
SaMD reaches the U.S. market through one of three FDA pathways, and which one applies depends largely on the product’s risk and whether a similar device already exists. Choosing the right pathway early is one of the highest-leverage regulatory decisions a startup makes, because it shapes the evidence required, the cost, and the time to market.
510(k): substantial equivalence
The 510(k) pathway applies when a SaMD is substantially equivalent to a legally marketed device, called a predicate. If a comparable product already exists and the new SaMD is as safe and effective, 510(k) is usually the fastest route. Many moderate-risk SaMD products clear this way.
De Novo: novel, low-to-moderate risk
The De Novo pathway is for novel SaMD that has no suitable predicate but is low-to-moderate risk. Several of the AI-driven products named earlier, including IDx-DR and Viz.ai, reached the market through De Novo, because they were genuinely new and had nothing equivalent to point to.
PMA: high risk
Premarket Approval (PMA) is the most rigorous pathway, reserved for high-risk SaMD, typically Category IV in risk terms. It demands the strongest clinical evidence and the longest review.
Before committing to a pathway, many teams use the FDA Pre-Submission (Q-Sub) program to get the agency’s feedback early, which can prevent expensive missteps. Our SaMD regulatory pathways guide walks through each route with typical costs and timelines, and our comparison of US and EU SaMD regulations covers what changes when you take a product to both markets.
The pathway is not purely a compliance question; it is a business one. The route a SaMD takes determines how quickly it can reach patients, how much capital it needs before revenue, and how defensible its market position becomes once cleared. A De Novo authorization, for example, can create a new device category that later products must measure against, which is a meaningful competitive advantage for the company that gets there first. Founders who treat the pathway decision as strategic, rather than as a box to tick, tend to make better use of their runway.
The SaMD Development Lifecycle: IEC 62304, ISO 14971, and ISO 13485
SaMD is engineered under a lifecycle discipline defined by three standards working together. IEC 62304 governs the software development lifecycle, ISO 14971 governs risk management, and ISO 13485 governs the quality management system around it all. A credible SaMD program aligns with all three.
IEC 62304 defines how SaMD is planned, developed, verified, and maintained, and it classifies software by safety risk to decide how much rigor each part requires. ISO 14971 runs in parallel, identifying and controlling risks across the whole lifecycle rather than at a single checkpoint. ISO 13485 sits underneath both as the quality system that makes the process repeatable and auditable.
These three interlock. Risk management under ISO 14971 feeds the software safety classification in IEC 62304, and both are documented within the ISO 13485 quality system. When they are treated as one integrated discipline from the start, rather than bolted on before a submission, the path to market is far smoother.
In practice, the standards translate into concrete engineering habits. Requirements are written and traced before code is built, so every feature connects back to a documented need. Risks are identified and assigned controls, and those controls are verified. Changes move through a controlled process rather than ad hoc. Verification and validation produce evidence that the software does what it is supposed to and is safe for its intended use. None of this is unfamiliar to a strong software team; the difference in regulated development is that the discipline is formalized, documented, and auditable, so an outside reviewer can trace the whole history of the product from requirement to release.
Sequenex builds SaMD engineered under the rigor of an ISO 13485-certified quality management system, with lifecycle practices aligned to these standards. For the deep dive on the software lifecycle standard specifically, see our IEC 62304 guide, our guide to developing SaMD in conformance with ISO 13485, and for the full development picture, our SaMD development guide. Verification and validation are covered in our SaMD software validation guide.
AI/ML SaMD: The Special Regulatory Considerations
SaMD that uses artificial intelligence or machine learning carries regulatory considerations that traditional SaMD does not. The core challenge is change: a model that learns and updates over time behaves differently from fixed software, and regulators built their systems around software that stays the same between clearances.
AI-enabled SaMD is also where the fastest growth and the most regulatory attention are converging. The FDA has authorized a growing list of AI-enabled devices, most of them in radiology and cardiology, and it continues to refine its approach as the technology moves faster than traditional regulatory cycles. For a company building in this space, the regulatory framework is not a fixed target; it is evolving alongside the products, which makes early engagement with the current guidance especially important.
The key distinction is between locked and adaptive algorithms. A locked algorithm produces the same output from the same input every time, and it fits the traditional regulatory model well. An adaptive algorithm changes as it learns from new data, which is exactly what makes machine learning valuable and exactly what complicates regulation. If the model changes after clearance, is it still the product that was cleared?
The FDA’s answer is the Predetermined Change Control Plan (PCCP). A PCCP lets a developer specify in advance the kinds of changes a model may undergo and how those changes will be validated so that certain updates can happen without a new submission each time. Alongside it, the FDA promotes Good Machine Learning Practice (GMLP), a set of principles for developing safe, effective AI-enabled devices.
For teams building AI-driven products, this is fast-moving territory, and getting the regulatory strategy right early matters more here than almost anywhere else. The FDA’s guidance on AI-enabled medical devices is the authoritative reference, and our work on AI in wearable medical devices looks at how these systems are built in practice.
What SaMD Development Costs and How Long It Takes
SaMD development timelines and costs depend on risk class, regulatory pathway, and product complexity, so that any single number would mislead. A low-risk 510(k) product with a clear predicate is a very different undertaking from a high-risk PMA product requiring extensive clinical evidence. The honest answer is a range that widens with risk.
The biggest cost drivers are usually not the code itself. They are the regulatory class and the clinical evidence it demands, and the rework that comes from architectural resets, when a team builds a fast prototype, then has to rebuild it to meet regulatory expectations it did not plan for. That rebuild repeats validation, regenerates documentation, and stalls momentum. Avoiding it is one of the largest levers on both cost and timeline.
Documentation is another underestimated cost. In regulated software, the design history, risk analysis, verification records, and traceability are not paperwork produced at the end; they are engineering artifacts created alongside the code throughout the lifecycle. Teams that treat documentation as a final step almost always face a scramble before submission, reconstructing evidence for work that was done months earlier. Building that discipline in from the start turns the regulatory submission into a compilation of existing evidence rather than a late-stage emergency.
This is where the build-versus-partner decision matters. Building SaMD infrastructure and regulatory documentation from scratch is slow and easy to get wrong. Starting from a foundation engineered for regulated use lets a team focus on what makes its product distinct.
Sequenex helps startup medical device companies build SaMD on exactly that kind of foundation, through the NEX Platform, and delivers it into infrastructure the customer owns, with complete source code ownership and no vendor lock-in. The software is engineered under an ISO 13485-certified quality management system and aligned to the standards a submission requires, while regulatory responsibility and intended use remain with the sponsor. For the full engineering picture, see our SaMD development guide, or connect with our team to talk through your product.
Frequently Asked Questions About Software as a Medical Device
What is Software as a Medical Device (SaMD)?
SaMD is software intended to perform a medical purpose, such as diagnosis, screening, monitoring, or treatment support, without being part of a hardware medical device. It runs on general-purpose platforms like phones, tablets, and cloud servers.
What is an example of SaMD?
SaMD examples include the Apple Watch ECG feature, IDx-DR for diabetic retinopathy screening, iRhythm’s Zio cardiac analysis, and Viz.ai’s stroke-triage software. Each performs a medical function through software alone.
Is SaMD regulated by the FDA?
SaMD is regulated by the FDA when it meets the definition of a medical device. Depending on risk, it reaches the market through the 510(k), De Novo, or PMA pathway. Software that only stores or displays data without interpreting it may fall outside device regulation.
What is the difference between SaMD and MDDS?
SaMD analyzes or acts on medical data for a medical purpose and is generally regulated as a device. An MDDS only transfers, stores, converts, or displays data without interpreting it, and software-only MDDS is no longer considered a device under U.S. law following the 21st Century Cures Act.
What standards apply to SaMD development?
SaMD development aligns with IEC 62304 for the software lifecycle, ISO 14971 for risk management, and ISO 13485 for the quality management system. Alignment with these standards supports a regulatory submission.
Is an AI-based health app a medical device?
An AI-based app is SaMD when it performs a medical purpose, such as detecting disease or informing treatment. AI-enabled SaMD carries added considerations around adaptive algorithms, and the FDA addresses these through Predetermined Change Control Plans and Good Machine Learning Practice.
How long does it take to develop SaMD?
SaMD development time varies widely by risk class and regulatory pathway. The largest drivers are the clinical evidence a pathway requires and rework caused by architectural resets, which is why starting on a foundation engineered for regulated use shortens the path.
Software as a Medical Device is reshaping how care is delivered, and the companies that succeed treat its regulatory demands not as an obstacle but as a foundation built in from the start. If you are moving a medical software product toward market, Sequenex can help you build it with the rigor, ownership, and clarity the category requires.
