What is Software as a Medical Device? A calm, plain-English starting point

If someone has just told you that your software might be a medical device, you are in good company. That sentence sounds much bigger than it is.

Plenty of small teams build medical software. They start where you are now, with a product they believe in and a list of unfamiliar acronyms. The rules they follow are written down, they are public, and they make sense once someone walks you through them. That is what this short series is for.

This short series covers the four ideas that sit underneath most medical software products:

1. What Software as a Medical Device is (this post).
2. The IEC 62304 software safety classes, and how they shape the way you build.
3. Risk, and how ISO 14971 asks you to think about it.
4. How ISO 13485 and the other standards fit together into one working system.

You do not need to master any of it today. You only need to know where you are standing.

The definition, in one sentence

The term Software as a Medical Device, or SaMD, comes from the International Medical Device Regulators Forum (IMDRF), a group of regulators from around the world, including the US FDA and the European Commission. Their definition (IMDRF/SaMD WG/N10FINAL:2013, section 5.1) is:

Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.

That sentence has two halves, and both matter.

"Intended to be used for one or more medical purposes." Medical purposes are things like diagnosing, preventing, monitoring, predicting, treating or alleviating a disease or injury. The EU Medical Device Regulation lists them in Article 2(1).

"Without being part of a hardware medical device." SaMD stands on its own. It runs on a phone, a laptop, a cloud server or a hospital workstation, rather than inside a physical device that it controls.

Some everyday examples

It helps to see the idea in practice. Here are some products that would usually be SaMD:

• An app that analyses a photo of a skin lesion and flags whether it may need a dermatologist's review.
• Software that calculates an insulin dose from a patient's readings.
• A cloud service that reads heart rhythm data from a consumer wearable and highlights a possible arrhythmia for a clinician.
• A tool that helps a radiologist prioritise which scans to read first.

And here are some that usually are not:

• Software inside a device. The firmware that runs an infusion pump is medical device software, but it is part of the pump, so it is regulated with the pump rather than as SaMD.
• Administrative software. Appointment booking, billing and staff rostering support healthcare but do not serve a medical purpose for an individual patient.
• Simple storage and communication. In the EU, MDCG 2019-11 Rev.1 (sections 3.1 and 3.3) explains that software which only stores, archives, communicates or performs a simple search on data is generally not medical device software on that basis alone.
• General wellness. A step counter or a meditation app usually sits outside the rules, provided it makes no medical claims.

That last condition is the important one, and it leads to the idea that decides almost everything.

Intended purpose is where it starts

Regulators look at your intended purpose. The EU Medical Device Regulation defines it in Article 2(12) as the use for which a device is intended according to the information the manufacturer supplies on the label, in the instructions for use, and in promotional or sales materials. The FDA uses the closely related idea of intended use.

In plain terms, your website, your app store listing, your sales deck and your instructions for use all tell a regulator what your product is for. What the software actually does matters too. The claims and the functions are read together, so careful wording alone is unlikely to take a product with a clear medical function outside the rules.

Two products can share almost identical code and be regulated quite differently. A heart rate app that says "track your workouts" is a fitness product. The same app that says "detects atrial fibrillation" is making a medical claim.

This is good news, because it means you can understand the question and answer it deliberately. It also means the decision deserves care, because both how you describe your product and what you build it to do shape the answer. We wrote a fuller walkthrough of that decision in when does software become a medical device in the EU, our guide to whether your software is a medical device works through the common cases, and our medical device check takes you through the questions step by step. If you built your product quickly with AI tools, this post on health apps built in a weekend is a good companion.

If the answer is yes, here is what follows

Being SaMD does not mean a mountain of paperwork appears overnight. It means a well-trodden path opens up, and it has four main parts.

A device classification. Regulators group devices by how much harm they could cause. In the EU, software is mostly classified under Rule 11 of MDR Annex VIII (section 6.3), which places it in Class I, IIa, IIb or III. In the US, the FDA uses Class I, II and III. Your class decides which route to market you take and whether an independent body reviews your work. Our SaMD guide to FDA and EU MDR compares the two routes, and our 510(k) and De Novo primer covers the US side. Our classifier helps you reason through this, and our earlier post on what class your medical device software is explains the logic.

A quality management system. This is the set of processes and records that shows you build, release and look after your product in a controlled way. ISO 13485:2016 is the international standard for it. In the US, the FDA's Quality Management System Regulation (21 CFR Part 820) incorporates ISO 13485:2016 by reference, alongside some FDA-specific requirements. We answer the common follow-up in do I need ISO 13485 before I can sell my product?

A software lifecycle. IEC 62304 describes how medical device software is planned, built, tested, released and maintained. It is the subject of the next post in this series.

Risk management. ISO 14971 describes how you identify what could go wrong, decide whether that is acceptable, and reduce it where it is not. That is the subject of the third post.

These pieces are designed to work together, and in the final post we will show how one change to your product flows through all of them.

A note on device class and software safety class

There is one source of confusion worth clearing up early, because it catches out a lot of founders.

Your device class (Class I, IIa, IIb or III in the EU) comes from the regulations and describes the product as a whole. Your software safety class (A, B or C) comes from IEC 62304 and decides how much rigour your development process needs.

They are related, because both depend on the harm your product could contribute to, but they are separate decisions with separate rules. A product can be Class IIa under MDR and still have parts of its software in different safety classes. The next post in this series looks at exactly how that works.

You are not doing this alone

The most useful thing to know at this stage is that none of this is secret, and none of it is designed to trip you up. The standards were written by engineers, clinicians and regulators who wanted medical software to be safe and reliable. Most of what they ask for is what a careful software team does anyway: plan the work, write down what the product must do, test it, think about what could go wrong, and keep a record.

What the standards add is a clear record: your decisions, your reasons and your evidence, written down and kept connected. That takes real effort, and it is the part we help with. QualiHQ keeps your requirements, tests, risk register and releases together as you work, with each requirement traced to the tests that verify it, so the record grows alongside the product instead of being assembled at the end.

Next in this series: the IEC 62304 software safety classes, what A, B and C mean, and how to choose yours with confidence.

Book a demo and we will walk through where your product stands, together.