Medical Device Software and SaMD: A Practical Guide

Core insight:

Software becomes a medical device the moment it carries a medical intended purpose - diagnosing, monitoring, treating - whatever it runs on. Standalone software of this kind is SaMD; software embedded in hardware is SiMD. Regulators (FDA, EU MDR) assign a risk class based on what happens if the software is wrong, and that class sets how rigorous your build has to be. You build it under IEC 62304, inside a quality system (ISO 13485), with risk management (ISO 14971) running throughout. All of these ideas we will explain in this article.

Why you should be curious about what medical device software is

For sure, you have an idea how your application is going to help people that will use it in the future. Maybe you are absolutely sure it should be considered a medical device, because you are planning it to be really helpful. Or maybe you are absolutely sure it will not be, because it does nothing what a certified doctor would do. Or maybe you are not sure at all.

There's a very good reason to focus on the definition - and the implications - of whether your app is going to be a device. And it's this: the cost and the work needed to first build it, and then maintain it. 

Apps that count as medical devices are meant to help people - which means they can just as easily harm them if they're misused or break. So the law takes deep care to make sure they're built the right way. And on top of that, a medical device has access to medical data - and you know how important it is to not let that leak. All of that means building one takes more work, and more rigor, than an ordinary app. 

When an app counts as a medical device?

The deciding factor is the intended purpose, not the technology. Software that diagnoses, treats, prevents, monitors, or predicts a condition falls under medical device regulation, whether it is a native mobile app, a web platform, a cloud service, or firmware inside a hardware device.

Medical device software is the umbrella term. Underneath it sit two families: software that is the device on its own, and software that lives inside a hardware device and drives it. The line between a regulated product and an ordinary app often comes down to the claim attached to it. A step counter sold for general fitness stays outside the regulation. The same algorithm marketed to detect atrial fibrillation moves inside it. The claim defines the status.

You might be tempted to go the medical device route after all - because you believe in your product, because of how much it can help people, or because you feel it genuinely does all these things. But before you decide, let's look at what it actually involves. 

What is Software as a Medical Device (SaMD)

SaMD - Software as a Medical Device - is the standalone kind. Regulators define it as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. In plain terms: it does clinical work on its own - on a phone, in a browser, on a server.

The same idea goes by different names across regions - the EU calls it medical device software, the FDA talks about "device software functions" - but it's one concept: a medical purpose, delivered by software, independent of dedicated hardware.

You don't need a fancy scanner or embedded chip to land in SaMD territory. An app that looks at a retinal image and says "this looks like diabetic retinopathy" is already a medical device in the eyes of regulators.

What is SaMD and how is it different from SiMD

The counterpart to SaMD is SiMD - software in a medical device: code embedded in hardware that runs or controls it, like the firmware in an infusion pump. 

The practical takeaway: SaMD carries its own regulatory weight, while SiMD inherits the process of the device it belongs to.

How medical device software gets classified

Classification determines how much rigor your product needs. Three frameworks matter, and a serious medical device software product may need to be assessed against all three.

FDA risk classes. The FDA classifies medical devices as Class I, II, or III based on their level of risk and the controls needed to keep them safe and effective. Many software-based medical devices are Class II, but software can fall into Class I, II, or III depending on what it does, how it is used, and the risks involved. The FDA also maintains a public list of AI-enabled medical devices that have received FDA marketing authorization, although the list is not comprehensive.

EU MDR Rule 11. Under the European MDR, software used to provide information for diagnostic or therapeutic decisions is generally Class IIa. It moves to Class IIb when a wrong decision could lead to serious deterioration of health or surgical intervention, and to Class III when it could lead to death or irreversible deterioration of health. Rule 11 also covers software used to monitor physiological processes, while some lower-risk software can remain Class I.

IEC 62304 software safety classes. IEC 62304 uses a separate safety classification for software: Class A where no injury is possible, Class B where non-serious injury is possible, and Class C where death or serious injury is possible. The class determines how rigorous your software lifecycle processes need to be and what you need to document.

The common thread is risk. What the software is intended to do, where it is used, and what could happen if it fails all matter. But these are three different systems: FDA and MDR classify the medical device for regulatory purposes, while IEC 62304 classifies the software according to its safety significance.

How medical device software gets designed and built

Here "design" refers to the engineering discipline - software architecture, development, and the formal controls required by IEC 62304. The standard describes a set of activities, adjusted based on the assigned safety class:

• Development planning

• Software requirements analysis, traceable to system requirements and to risk

• Architectural design

• Detailed design (required for Class C)

• Implementation and unit verification

• Integration and integration testing

• System testing

• Release.

Four processes run in parallel throughout the project:

1. Risk management (ISO 14971) - continuous, shapes requirements from day one, never stops.

2. Configuration management - every version and every change is tracked and accounted for.

3. Problem resolution - defects follow a controlled path, not an ad hoc fix.

4. SOUP management - third-party and open-source components you didn't author still require oversight, because you remain responsible for the risk they carry.

A common worry is whether this forces a waterfall process. It does not. IEC 62304 specifies activities and outputs, not a rigid sequence, and AAMI TIR45 gives explicit guidance on mapping agile practices onto it. You can iterate in sprints and stay compliant, as long as traceability and documentation hold at each step.

Our approach to medical devices: Calpro

Calpro is a remote patient monitoring product for Crohn's disease, available on iOS and Android. Apzumi develops and maintains it for Calpro AS in Norway and Sweden. It lets people living with Crohn's - a chronic inflammatory bowel condition that flares and subsides - track their disease between clinic visits, and it gives their care team a continuous view of how the condition is behaving, so a deterioration can be caught early instead of at the next appointment. 

We took over the product in 2020 from a previous team - inheriting the codebase, the certification, and the compliance obligations that came with it. Since then we've been responsible for development and maintenance: restructuring the workflow, improving performance, and releasing new features - all within the constraints of a live certified medical device, where every change follows a controlled path - under ISO 13485, IEC 62304, and ISO 14971. 

You can read more about how we approached cooperation with Calpro here.

Compliance and standards for medical device software

Medical device software sits under several standards - each governing a different aspect of the work. You do not need to master all of them to plan a product, but you do need to know how they fit.

These standards don't overlap - each one covers a different part of the work. IEC 62304 governs how you build the software. ISO 14971 governs how you think about risk. ISO 13485 keeps your organization in control of both. And privacy law - HIPAA or GDPR depending on the market - governs what you do with patient data once you have it. 

At Apzumi, we've built and maintained products under all three - IEC 62304, ISO 13485, ISO 14971. We know how they fit together, where they create friction, and how to keep moving without cutting corners. 

If you're building a medical device product and want a team that knows the territory - get in touch.

FAQ

What is medical device software?

Any software with a medical intended purpose - to diagnose, treat, prevent, monitor, or predict a condition - whether it runs standalone (SaMD) or embedded in hardware (SiMD). The medical claim makes it a device, regardless of the platform it runs on.

Can you give me an example of software as a medical device?

A phone app that analyzes retinal photographs to flag diabetic retinopathy; a cloud service that interprets ECGs; or Calpro, the Crohn's disease remote-monitoring product Apzumi develops for Calpro AS. Each performs a medical purpose on general-purpose hardware, with no dedicated device required.

Is AI software a medical device?

If the AI serves a medical intended purpose, yes. AI and machine-learning SaMD is regulated like any other SaMD. The FDA maintains a public list of AI-enabled device software functions and allows predetermined change control plans, so models can be updated within limits agreed in advance. An AI tool marketed purely for general wellness stays outside the regulation.

Is IEC 62304 mandatory?

No statute names IEC 62304 as compulsory, but it is the recognized consensus standard for medical device software lifecycles. The FDA recognizes it and EU notified bodies expect conformance, so in practice it is the default way to show your software process meets regulatory expectations. Building outside it means justifying an equivalent approach - a much harder path.

What does ISO 13485 stand for?

It is a standard number, not an acronym. ISO 13485 is the international standard titled "Medical devices - Quality management systems - Requirements for regulatory purposes." It defines the quality management system a medical device organization runs.

What is the difference between the FDA and ISO 13485?

The FDA is the US regulator and the body of rules it enforces; ISO 13485 is an international quality management standard. They serve different purposes - and they are converging: the FDA's Quality Management System Regulation, in effect since February 2, 2026, incorporates ISO 13485 by reference, so meeting the standard now maps closely onto US quality-system requirements.