Software as a Medical Device (SaMD): The Complete Guide

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 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 any 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 meeting 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 a SaMD because counting steps is not for medical purposes. 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 performing a medical function, 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. You need to look for a few specific features when looking for a SaMD company.

Does Your Software Qualify as SaMD?

Before determining a regulatory class or market pathway, a team must first determine whether its software function is regulated as a medical device. This is not always obvious. A single product can include both regulated and non-regulated functions, so the analysis should begin at the feature or function level.

Use these questions as an early screening framework:

1. What is the intended use? Does the product claim to diagnose, screen for, monitor, predict, treat, prevent, mitigate, or inform a clinical decision about a disease, injury, or condition?
2. What does the software output do? Does it only store, transfer, organize, display, or communicate information? Or does it analyze data and generate a patient-specific medical output, such as an alert, risk score, or recommendation?
3. Who uses the output, and for what decision? Consider whether a clinician, patient, or caregiver could use the result to make or influence a clinical decision.
4. Does it operate medical hardware? Software that drives, controls, or is integral to a physical medical device may be Software in a Medical Device (SiMD), rather than standalone SaMD.
5. Which markets are in scope? The United States, European Union, United Kingdom, Canada, Australia, and other markets use related but not identical regulatory frameworks.

This framework is an early product-planning tool—not a legal determination. Regulatory status depends on the complete intended use, claims, functionality, target users, and jurisdiction. Even a change in marketing language can affect a product’s regulatory posture.

SaMD Classification: Four Different Frameworks

SaMD teams frequently encounter several classification systems. They are related, but they answer different questions. Treating them as interchangeable can lead to a flawed regulatory strategy.

Framework	What it addresses	Why it matters
IMDRF SaMD risk categorization	The healthcare situation and the significance of information provided by the software	Supports internationally aligned risk thinking for SaMD
FDA device classification	U.S. device class and applicable regulatory controls	Influences the U.S. market pathway and regulatory controls
EU MDR classification	EU medical-device class, including software considerations under Rule 11	Influences conformity assessment, technical documentation, and notified-body involvement
IEC 62304 software safety class	Potential effect of software failure on a patient, operator, or other person	Influences the rigor of software lifecycle activities

Do not treat an IMDRF category, FDA device class, EU MDR class, and IEC 62304 safety class as equivalent labels. A single product can have different designations under each framework because each evaluates a different regulatory or safety issue.

IMDRF categorization is a risk-thinking framework for software that already qualifies as SaMD. It does not, on its own, determine whether a wellness or health-information app is a medical device.

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 easily crosses borders. 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 and 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. SiMD vs. General Health Software

Factor	SaMD	SiMD	General health or non-device software
Primary role	Independently performs a medical purpose	Operates, controls, or forms part of a hardware medical device	Supports wellness, administration, communication, or general information
Typical deployment	Mobile app, cloud platform, desktop application, web software	Embedded firmware or device-integrated software	Scheduling app, secure messaging tool, habit tracker, billing platform
Example	Software that analyzes an image and provides diagnostic-support output	Firmware controlling a CT scanner or infusion pump	Appointment scheduling or non-medical activity tracking
Main regulatory question	Does intended use make the function a medical device, and how should it be classified?	How should the integrated hardware-software system be controlled and validated?	Do the claims or features cross into regulated device functionality?
Development emphasis	Software lifecycle evidence, risk management, cybersecurity, clinical/regulatory strategy	Hardware-software integration, system safety, verification and validation	Claim governance, privacy/security, and feature-boundary monitoring

The distinction often depends on what the software actually does—not simply where it runs. For example, an application that displays raw data from a wearable may be treated differently from software that interprets the same data and generates a clinically meaningful alert.

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 are no longer considered medical devices 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 software starts analyzing the reading, flagging it, or recommending an action, it falls under SaMD, and device-level obligations apply.

Consider a single connected glucose product to see how the line works in practice. A module that receives sensor readings and displays them in an app is behaving as an MDDS. Add a feature that detects a dangerous downward trend and alerts the patient; this feature now interprets the data to inform 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 directly covers the post-Cures Act framing.

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 produce a clinical result on their own, placing 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 automatically clear the category. The FDA evaluates each SaMD on its own intended use, evidence, and risk. A similar-looking app is not exempt from scrutiny simply because a competitor reached the market first.

For example, 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 of 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 the 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.

SaMD in Europe: EU MDR and Rule 11

For teams planning to market in Europe, medical device software is generally subject to the EU Medical Device Regulation (EU MDR). EU terminology often refers to medical device software (MDSW), and classification follows a different framework from the FDA’s Class I, II, and III system.

EU MDR Rule 11 is particularly important for software. Depending on how the software provides information for diagnostic or therapeutic decisions, monitors physiological processes, or affects clinical outcomes, the product may be classified as Class I, IIa, IIb, or III.

Topic	United States	European Union
Common terminology	SaMD or device software function	Medical device software (MDSW)
Classification approach	Class I, II, or III device classification	Class I, IIa, IIb, or III under EU MDR rules
Common market routes	510(k), De Novo, PMA, or other applicable routes	Conformity assessment, technical documentation, clinical evaluation, and CE marking
Key software consideration	Device-specific FDA classification and software documentation expectations	Rule 11 may increase classification based on the consequence of decisions informed by software
Independent review	Depends on product and pathway	A notified body is often involved above Class I, subject to applicable rules

A U.S. strategy should not be directly copied to Europe. A product’s FDA classification or clearance route does not automatically determine its EU MDR class, clinical-evidence needs, or conformity-assessment process.

FDA Regulatory Pathways for SaMD: 510(k), De Novo, and PMA

SaMD reaches the U.S. market through one of three FDA pathways for SaMD certification, 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 required evidence, costs, and 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 as it, 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 no equivalent to compare to.

PMA: high risk

Premarket Approval (PMA) is the most rigorous pathway, reserved for high-risk SaMD, typically classified as Category IV in terms of risk. It demands the strongest clinical evidence and the longest SaMD clinical evaluation 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 meet, which is a meaningful competitive advantage for the company that achieves it 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, controls are assigned, 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 product’s entire history from requirements 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 a 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.

IEC 62304 Safety Classes: What They Mean

IEC 62304 is a medical-device software lifecycle standard. Its software safety classification is based on the potential contribution of a software system failure to harm—not on the FDA device class or the product’s commercial importance.

• Class A: No injury or damage to health is possible.
• Class B: Non-serious injury is possible.
• Class C: Death or serious injury is possible.

The classification helps determine the rigor of relevant lifecycle activities, such as requirements management, architecture, verification, configuration management, and problem resolution. It is not a market-authorization category and does not replace FDA or EU MDR classification.

How SaMD Is Built Under a Controlled Lifecycle

Regulatory readiness is not a document created at the end of development. It should influence product requirements, architecture, testing, release practices, security controls, and postmarket operations from the beginning.

Lifecycle area	Evidence and controls to plan for
Intended use and product definition	Intended-use statement, target users, user needs, clinical claims, use environment, contraindications, and limitations
Requirements and traceability	System and software requirements linked to risks, design elements, verification, validation, and releases
Risk management	Hazard analysis, risk controls, residual-risk evaluation, and documented rationale for risk acceptability
Architecture and design	Architecture records, data flows, interfaces, cybersecurity design decisions, and third-party software inventory
Verification and validation	Test plans, test cases, results, integration testing, usability evaluation, and clinical-performance evidence where applicable
Configuration management	Version control, baseline management, build reproducibility, change records, and release approvals
Problem resolution	Issue triage, root-cause analysis, corrective actions, impact assessment, and documented closure
Maintenance and postmarket	Complaint feedback, vulnerability monitoring, field-performance review, and controlled change assessment

Can Agile Development Work for SaMD?

Yes. Agile methods can work for SaMD when teams retain the controls and objective evidence needed in a regulated lifecycle. The objective is not to eliminate iteration; it is to ensure that iteration remains traceable, risk-informed, tested, and controlled.

Practical controls include approved requirements, bidirectional traceability, documented risk assessments, versioned design outputs, verification evidence, release criteria, change-impact review, and controlled handling of defects and field feedback.

For early-stage teams, attempting to recreate this evidence after development is often more expensive than building it into delivery from the start.

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 evolves alongside the products, making early engagement with 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.

AI/ML SaMD: Practical Development Considerations

In addition to distinguishing between locked and adaptive algorithms, AI/ML-enabled SaMD teams should establish controls across the entire model lifecycle. The quality of the model is inseparable from the quality of its data, validation approach, clinical workflow, and postmarket monitoring.

• Data provenance, permissions, governance, and dataset documentation
• Representative datasets and performance assessment across clinically relevant subgroups
• Separation of training, validation, and test data where appropriate
• Ground truth, labeling procedures, and reference-standard definitions
• Performance metrics that match the intended use and clinical workflow
• Human factors: how users interpret, act on, override, or misunderstand model output
• Version control for data, code, models, and evaluation protocols
• Monitoring for model drift, performance degradation, unexpected use patterns, and real-world safety signals

A PCCP may be relevant for certain AI-enabled devices, but it is not a blanket authorization for future changes. The appropriateness of a PCCP depends on the device, planned modifications, supporting evidence, and applicable regulatory expectations.

Cybersecurity and Postmarket Responsibilities

SaMD obligations continue after the first release. Cloud dependencies, third-party libraries, integrations, cybersecurity vulnerabilities, software updates, and real-world use all require controlled postmarket processes.

A practical plan should address:

• Secure architecture and threat modeling
• Authentication, authorization, least-privilege access, encryption, audit logging, and monitoring where appropriate
• Third-party and open-source component governance, including software of unknown provenance (SOUP)
• Software bill of materials (SBOM) practices where appropriate
• Vulnerability intake, risk assessment, remediation, and communication processes
• Controlled patching, release approvals, deployment evidence, and rollback planning
• Complaint handling, field feedback, adverse-event assessment, and corrective action processes
• Change-impact assessment for new features, data sources, integrations, algorithms, and clinical claims

A strong postmarket process does not prevent product iteration. It helps teams decide when a change is routine maintenance and when it may require deeper safety, clinical, quality, or regulatory assessment.

What SaMD Development Costs and How Long It Takes

SaMD development timelines and costs depend on risk class, regulatory pathway, and product complexity, so any single number would be misleading. 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 of work 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 with the standards required for submission, 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 the scope of 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 presents additional considerations for adaptive algorithms, which the FDA addresses 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.

Is every health app SaMD?

No. Many health and wellness applications are not medical devices. Whether an app qualifies as SaMD depends on its intended use, claims, functionality, and applicable jurisdiction. Software intended for general wellness can be treated differently from software that diagnoses a disease, analyzes patient-specific data for clinical use, or generates a treatment-related recommendation.

Is software that displays medical data always SaMD?

Not necessarily. Software that transfers, stores, converts, or displays data without interpreting it for medical purposes may be treated differently from software that analyzes data and produces patient-specific clinical output. The full feature set and intended use matter.

What is the difference between SaMD and clinical decision support software?

Clinical decision support is a functional category. Some clinical decision-support functions may be regulated medical-device software, while others may fall outside device regulation or be subject to specific policies. The answer depends on the type of recommendation, the information presented to the user, the user’s independence, the intended use, and the applicable jurisdictional rules.

Is remote patient monitoring software SaMD?

It can be. A remote-monitoring platform may include non-device features, such as communication, data transfer, or dashboards, alongside potentially regulated analytical, alerting, or decision-support functions. Assess each function separately.

What is EU MDR Rule 11?

Rule 11 is an EU MDR classification rule relevant to software. It can place medical-device software into Class IIa, IIb, or III when the software provides information used for diagnostic or therapeutic decisions or monitors physiological processes under specified circumstances. Classification depends on the potential consequences of decisions based on the software output.

Does IEC 62304 require Waterfall development?

No. IEC 62304 does not require a particular development methodology. Agile teams can work within a compliant lifecycle by maintaining appropriate planning, risk management, traceability, verification evidence, configuration control, problem resolution, and release governance.

When does a SaMD update need regulatory assessment?

Any material change to the intended use, clinical claims, algorithms, data sources, performance, cybersecurity posture, architecture, integrations, or risk controls should undergo a controlled change assessment. Whether it requires a new or updated regulatory submission depends on the product, market, and nature of the change.

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.