Software as a Medical Device (SaMD) Regulatory Consultants
Software as a medical device (SaMD) is software intended for a medical purpose that works on its own, without being part of a hardware medical device. I3CGlobal’s SaMD consultants help software manufacturers qualify, classify and certify their products for the US FDA, EU MDR and IVDR, and the UK.
What is software as a medical device?
The International Medical Device Regulators Forum (IMDRF) defines software as a medical device as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” In plain terms, if your software diagnoses, monitors, predicts or treats a condition on its own, it is SaMD.
SaMD can run on a phone, a laptop, a hospital server or in the cloud. It may analyse images, calculate a dose, flag an abnormal ECG or suggest a treatment. What makes it a medical device is the manufacturer’s intended purpose, not the technology. A step counter for general fitness is usually not a medical device; the same algorithm sold to detect atrial fibrillation is.
Regulators in the USA, the EU and the UK all build on the IMDRF SaMD definitions, but each applies its own law. In the USA the FDA calls these products device software functions. In the EU, software is qualified under the MDR or IVDR using MDCG 2019-11, revised in June 2025. Getting this first decision right saves months, because it decides which rules, which class and which evidence apply.
,%20CE%20mark,%3C/text%3E%3Ctext%20x='972'%20y='292'%20fill='%235a6378'%20font-size='16'%3Ethen%20maintain%3C/text%3E%3C/svg%3E)
What is the difference between SaMD and SiMD?
SaMD works on its own. Software in a medical device (SiMD) is part of a hardware device and drives or controls it, such as the firmware in an infusion pump or the software inside an ultrasound scanner. Both are regulated, but SiMD is assessed as part of the hardware device, while SaMD is assessed as a device in its own right.
| Type of software | What it does | Example | Regulated as |
|---|---|---|---|
| Software as a medical device (SaMD) | Performs a medical purpose on its own, on general computing platforms | AI app that detects diabetic retinopathy from retinal photos | A medical device in its own right |
| Software in a medical device (SiMD) | Drives or controls a hardware device | Control software in an insulin pump | Part of the hardware device |
| Accessory software | Enables or assists a specific medical device | App that sets up and reads data from a blood glucose meter | Usually as an accessory to that device |
| Non-device software | Administrative, wellness or general purpose functions | Appointment booking, general fitness tracking | Not a medical device |
The line is not always obvious. For a detailed look at software that changes inside an existing cleared device, see our guide to software in a medical device.
What are examples and types of software as a medical device?
SaMD covers a wide range of products, from simple calculators to complex machine-learning models. These are the types our SaMD consultants work on most often:
AI image analysis
Software that detects or measures findings in X-ray, CT, MRI, retinal or pathology images, often using machine learning.
Clinical decision support
Tools that calculate risk scores, suggest diagnoses or recommend treatment options to clinicians.
Remote monitoring apps
Apps that analyse ECG, blood pressure, glucose or other physiological data and alert patients or clinicians.
Digital therapeutics
Software that delivers a therapeutic intervention, for example cognitive behavioural therapy for insomnia.
Dose and treatment calculators
Software that calculates drug doses, radiotherapy plans or insulin boluses from patient data.
IVD software
Software that interprets laboratory or genetic test results. In the EU this falls under the IVDR; see IVD software CE marking.
Hospital information systems, laboratory information systems and electronic prescribing systems are often discussed alongside SaMD. Whether they qualify depends on their functions: storing and displaying data is usually not a medical purpose, but software that creates new clinical information or recommendations may be.
How is software as a medical device classified?
Software as a medical device classification (SaMD classification) depends on two things: how important the software’s information is to the clinical decision, and how serious the patient’s condition is. The IMDRF framework expresses this as four categories, I to IV. Each regulator then applies its own classes, so the same software can be Class II in the USA and Class IIa or IIb in the EU.
| State of the condition | Treat or diagnose | Drive clinical management | Inform clinical management |
|---|---|---|---|
| Critical | IV (highest risk) | III | II |
| Serious | III | II | I |
| Non-serious | II | I | I (lowest risk) |
This is the IMDRF SaMD risk categorisation framework. It is a shared reference, not a legal classification. The legal class comes from each market’s rules:
FDA Class I, II or III
Based on the product code and regulation of similar devices. Most SaMD is Class II and needs a 510(k), or De Novo when there is no predicate. Our FDA 510(k) clearance guide covers the general route. Some clinical decision support software is excluded from device rules if it meets all four statutory criteria.
MDR Rule 11
Software that provides information for diagnostic or therapeutic decisions is at least Class IIa, rising to IIb or III if a wrong decision could cause serious harm. Software that monitors physiological processes is IIa, or IIb for vital parameters.
UK MDR 2002
Software is classified under the UK Medical Devices Regulations 2002, and CE marked software is currently accepted in Great Britain. The MHRA is updating its rules through its Software and AI as a Medical Device Change Programme.
What are the regulatory requirements for software as a medical device?
Every software as a medical device needs four things, whatever the market: a quality management system, a controlled software life cycle, a risk management file and evidence that the software is safe and performs as claimed. The table shows how these map to each region, and the standards that regulators expect.
| Requirement | United States (FDA) | European Union (MDR / IVDR) | Key standard or guidance |
|---|---|---|---|
| Quality system | QMSR, 21 CFR Part 820 (since 2 Feb 2026) | MDR Article 10 QMS | ISO 13485 |
| Software life cycle | Design controls and software documentation | Annex I, section 17 | IEC 62304 |
| Risk management | Risk analysis in the submission | Annex I general requirements | ISO 14971 |
| Usability | Human factors evidence where relevant | Annex I, section 5 and 22 | IEC 62366-1 |
| Cybersecurity | Section 524B for cyber devices, SBOM | Annex I, section 17.2 and 17.4; MDCG 2019-16 | IEC 81001-5-1 |
| Clinical evidence | Performance testing, clinical data where needed | Clinical evaluation (MDR) or performance evaluation (IVDR) | MDR clinical evaluation |
| Product safety | Health software product safety and labelling | IEC 82304-1 | |
AI-enabled SaMD: the FDA finalised its guidance on predetermined change control plans for AI-enabled device software in December 2024. In the EU, AI medical devices will also fall under the AI Act; its high-risk deadlines are being postponed through the Digital Omnibus package, so check the latest timetable. See our EU AI Act for medical devices guide.
Is your software a medical device? A five-question check
Use these questions as a first screen before you plan development or fundraising. If you answer yes to question 1 and to any of questions 2 to 4, your product is very likely software as a medical device and needs a regulatory strategy.
Medical purpose?
Is the software intended to diagnose, prevent, monitor, predict, treat or alleviate a disease, injury or disability?
Patient-specific output?
Does it produce results, alerts or recommendations for an individual patient rather than general information?
New clinical information?
Does it calculate, interpret or analyse data, images or signals, rather than only storing, sending or displaying them?
Clinical decisions?
Will clinicians or patients rely on the output to make diagnostic or treatment decisions?
Which markets?
Where will you sell it? The answer sets the rules: FDA in the USA, the MDR or IVDR in the EU and the UK MDR in Great Britain.
Next step
Ask our SaMD consultants for a written qualification and classification opinion before you build the evidence.
For the full EU decision tree, see our guide to software CE marking. For US product codes and classes, see FDA medical device classification. When your software is confirmed as a device, you will need a technical file and, for most software as a medical device, an ISO 13485 certified quality system.
Which SaMD consulting services do we offer?
Our SaMD consultants cover the whole route for software as a medical device from first idea to market and beyond. You can use a single service, such as a classification opinion, or hand us the full regulatory project. Each service links to a page with full details.
Qualification and classification
A written opinion on whether your software is a medical device, its class in each market and the fastest compliant route.
FDA 510(k) for SaMD
Predicate search, software documentation, cybersecurity, eSTAR preparation and FDA question responses.
Software CE marking
MDR Rule 11 or IVDR classification, technical documentation and Notified Body support for medical software.
IEC 62304 implementation
Software development plans, safety classification, SOUP management, verification and maintenance records.
Medical device cybersecurity
Threat modelling, SBOM, security risk management and FDA section 524B documentation.
AI and machine learning SaMD
EU AI Act readiness, data management, model validation and FDA predetermined change control plans.
We also support ISO 13485 quality systems for software companies, usability engineering, clinical evaluation and the EU Authorised Representative role for manufacturers outside Europe.
How does our SaMD regulatory consulting work?
SaMD projects move fast, so we fit regulatory work into your development sprints rather than adding a separate paperwork phase at the end. Every software as a medical device project follows six steps, with a fixed scope agreed in writing before we start.
Intended purpose
We help you write a precise intended purpose and indications for use, because they drive qualification, class and evidence.
Regulatory strategy
We confirm the class in each target market and choose the route, such as 510(k), De Novo or MDR certification.
Gap analysis
We compare your code base, documents and QMS with IEC 62304, ISO 14971 and the applicable regulations.
Build the evidence
We prepare the software documentation, risk file, cybersecurity file, usability and clinical evidence with your team.
Submission
We compile the 510(k) or technical file and handle FDA or Notified Body questions until clearance or certification.
Release and change control
We assess each new version, so updates and AI model changes stay compliant after launch.
Why work with our SaMD consultants?
Software teams are used to shipping every few weeks. Regulators expect traceable requirements, controlled changes and documented risk decisions. Our job is to make those two worlds work together so your software as a medical device reaches the market without slowing your releases.
Common SaMD problems we fix
- Intended purpose written too broadly, pushing the software into a higher class
- Agile development with no traceability from requirements to tests
- SOUP and open-source libraries not listed or risk assessed
- Cybersecurity left until the end, with no SBOM or threat model
- AI models retrained after clearance without a change plan
What you get from us
- A clear class and route for the USA, the EU and the UK in one plan
- IEC 62304 processes that fit your existing tools and sprints
- One evidence base reused for FDA and Notified Body submissions
- Specialists in software, cybersecurity and clinical evidence
- Support after launch for updates, PMS and new markets
See how we have helped software manufacturers in our FDA 510(k) case studies and EU MDR case studies.
Speak with our SaMD consultants
Send us the intended purpose of your software as a medical device and your target markets. We will reply with a classification opinion, the right regulatory route and a fixed-fee proposal.
Software as a medical device: frequently asked questions
What is software as a medical device (SaMD)?
Software as a medical device is software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. Examples include AI image analysis, clinical decision support tools, remote monitoring apps and digital therapeutics.
What is the difference between SaMD and SiMD?
SaMD performs a medical purpose on its own, on general computing platforms. Software in a medical device (SiMD) is part of a hardware device and drives or controls it, such as the software in an infusion pump. SiMD is assessed as part of the hardware device.
Is a mobile health app a medical device?
It depends on the intended purpose. An app that diagnoses, monitors, predicts or treats a disease is usually a medical device. An app for general wellness, fitness tracking or administration usually is not. The FDA’s device software and clinical decision support guidance and the EU’s MDCG 2019-11 explain where the line sits.
How is SaMD classified under the EU MDR?
MDR Rule 11 makes most decision-support software at least Class IIa. It becomes Class IIb if a wrong decision could cause a serious deterioration of health or surgery, and Class III if it could cause death or irreversible deterioration. Software that monitors physiological processes is Class IIa, or IIb for vital parameters.
Does SaMD need a 510(k)?
Most Class II SaMD needs a 510(k) before it can be sold in the USA. Novel software with no predicate may use the De Novo route, and high-risk software may need a PMA. Some software functions are exempt or excluded. Our SaMD 510(k) process page explains the steps in detail.
Which standards apply to software as a medical device?
The core standards are IEC 62304 for the software life cycle, ISO 14971 for risk management, ISO 13485 for the quality system, IEC 62366-1 for usability, IEC 82304-1 for health software product safety and IEC 81001-5-1 for cybersecurity.
Are there extra requirements for AI and machine learning SaMD?
Yes. In the USA, a predetermined change control plan lets you update an AI model within agreed limits without a new 510(k). In the EU, AI medical devices will also need to meet the AI Act requirements for high-risk AI systems, in addition to the MDR or IVDR.
Can you help a software start-up with no quality system?
Yes. Many of our SaMD clients are start-ups. We set up a right-sized ISO 13485 quality system and IEC 62304 processes that fit your existing development tools, then build the documentation alongside your product.