Software as a medical device (SaMD) is any program that performs a medical job on its own, without being part of a physical machine. An app that examines a photo of a mole and flags possible melanoma fits the description. The code that runs an MRI scanner doesn’t qualify, because it’s part of the hardware.
That distinction decides far more about your product than you might expect. It shapes the records you keep, the testing you have to prove you did, and in some markets whether you’re allowed to sell at all. Many teams don’t ask the question themselves. They hear it first from an investor, a hospital buyer, or a lawyer.
One honest note before we go further: this article doesn’t offer legal or regulatory advice. Redwerk takes on healthcare IT software development, while classifying your product and filing with the FDA belongs with a qualified consultant. What we do is build a solution and stand with you through every check and audit, working closely with your team to ensure full compliance. We link to the official documents throughout, so you can read the source rather than trust our summary of it.
What follows is the engineering half of the picture. You’ll find out what qualifies, how the risk categories are built, and what a compliant build actually asks of the people writing the code.
What Qualifies as Software as a Medical Device
The FDA and the International Medical Device Regulators Forum, usually shortened to IMDRF, define the term as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”
Unpack that and you get two questions:
- Does the product serve a medical purpose, meaning it helps diagnose, treat, prevent, or monitor a disease or condition?
- Does it do that job independently, rather than as a component inside a piece of equipment?
A yes to both puts you in scope.
Three familiar groups sit inside the definition:
- Imaging analysis tools that measure or interpret a scan, then hand a finding back to a radiologist
- Clinical decision support that suggests a diagnosis, a dose, or a course of treatment
- Certain health monitoring apps, particularly those that read sensor data and warn a user about a specific condition
That third group is the one that surprises people. A heart rate reading on its own is just a number. However, once a product interprets the pattern and tells someone they may have an irregular rhythm, it has crossed into medical territory.
Two kinds of health software stay outside the definition, and both matter commercially. The first is anything built into a device’s core function. Firmware inside an infusion pump falls under the rules as part of that hardware, not as a product in its own right. The second is administrative technology: billing engines, appointment scheduling, staff rostering, and records management all touch patient data without making a clinical claim. Those tools still carry privacy duties. They’re also a common target for robotic process automation in healthcare, which we cover separately.
Where a Wellness App Becomes a Medical Device
The boundary is easiest to see in a product that sits right beside it. Redwerk rebuilt and now maintains Pridefit, a subscription fitness app for the LGBTQIA+ community that runs coaching plans, personal challenges, and performance tracking. It handles health data every day, and it changes user behavior by design.
None of that makes it a regulated product. Pridefit makes no claim about diagnosing or treating anything, so it stays on the general wellness side of the line. Give that same app one new feature that reads the workout data and warns a user about a possible cardiac problem, and the conversation changes immediately. The gap between a wellness tool and a regulated one can be a single sentence in your marketing copy.
How SaMD Classification Works
SaMD classification doesn’t start with your technology stack or your company size. It starts with two questions about consequences, and the answers combine into a risk category.
The first is how much weight your product’s output carries in a clinical decision:
- Informs clinical management, meaning a clinician uses the output as one input among several
- Drives clinical management, meaning the output shapes the next step in care
- Treats or diagnoses, meaning the product itself delivers the finding or the therapy
The second is how much danger the patient is already in:
- Non-serious, where a wrong answer is unlikely to cause lasting harm
- Serious, where a delay or an error could cause real injury
- Critical, where the wrong output could contribute to death or irreversible damage
Put both answers together and you land in one of four IMDRF categories, I at the lowest and IV at the highest. The scale describes how much risk your product carries, and nothing more.
Informs clinical management
I
I
II
Drives clinical management
I
II
III
Treats or diagnoses
II
III
IV
Notice how the same capability moves across the grid depending on context. A tool that drives clinical management lands at I in a minor situation and at III in a life-threatening emergency. Your feature list alone will never tell you where you sit.
FDA Classes vs IMDRF Categories: What Each One Decides
Two separate SaMD classification systems use similar numbers, and each answers a different question. Mixing them up is the most common mistake teams make here.
You’ve already met the IMDRF categories above. SaMD FDA requirements run on a separate track, built on three classes that reflect how much oversight a device needs:
- Class I covers the lowest-risk devices, and most need no premarket filing at all.
- Class II sits in the middle, and usually calls for a 510(k) notification showing your product is equivalent to something already cleared.
- Class III carries the highest risk, and faces the most demanding review the agency runs.
Something genuinely new, with no existing equivalent, follows its own route, because there is nothing to compare it against. Your product’s class comes from what it’s intended to do and how much harm it could cause, not from how it was built.
Here’s how the two systems compare at a glance:
What it is
An international way to describe how much risk the software carries
The US regulatory classification for a medical device
What it decides
No legal force on its own. It gives regulators and developers a shared way to talk about risk
What you must file with the FDA before selling in the US
Where it comes from
The IMDRF working group, which the FDA chairs
US medical device law
Neither scale is something to work out on your own. Use the categories to understand your risk, then let a regulatory specialist confirm the American classification. The FDA’s Digital Health Policy Navigator is a reasonable place to start reading before that conversation. Requirements also differ by market and shift over time, so check rather than assume.
What Building Compliant SaMD Software Involves
Here’s what lands on an engineering team building software as a medical device, and where a development partner earns or loses its place. Most of it is good practice on any serious project, but regulated work makes it mandatory and makes you prove it. The FDA expects the whole effort to sit inside a quality management system: documented processes, plus evidence you followed them every time. Its guidance on clinical evaluation covers how you show the product does what you claim.
Four practices carry the weight in SaMD software development:
- Traceability. Someone should be able to pick a line in your specification and follow it to the design decision that answered it, the code that implements it, and the test that proves it works, then run that journey backward from a test result. Traceability is nearly free when you build it in from the first sprint, and brutally expensive to reconstruct later, which is the problem IEC 62304 was written around.
- Documentation written during the work. Regulated projects need a clear specification early, because anything assembled at the end describes what the team wishes it had built. Writing requirements first also surfaces disagreements while they’re cheap to settle, the same reason our functional specification services exist for unregulated clients.
- A record, not just testing. Every serious team tests. The harder part is keeping a record of what happened each time: which version was checked, who ran it, which requirement it covered, and what the outcome was. That record is what a reviewer asks for, and nobody can recreate it months afterward from memory. Maintaining it as you build is what our quality assurance consulting services are for, and it needs planning from the start.
- Privacy and security, on top of device rules. Any product touching patient information carries obligations that run alongside the device rules rather than replacing them. In the United States that usually means HIPAA. The steps are familiar: encrypt data in transit and at rest, restrict access by role, log who saw what, and hold your vendors to the same standard. Our HIPAA compliance checklist for healthcare software walks through each one. Plan for security as an ongoing obligation too, with a way to find vulnerabilities and ship fixes across the product’s whole life, rather than one review before launch.
A software development audit is where you learn whether these four practices were actually followed. When Redwerk reviewed the codebase behind Adoorabelle, a mobile marketplace, the assessment turned up 80 issues. Two of them matter most for regulated work: the project had no developer tests, and it kept no activity logs. Missing both is expensive in ordinary commercial software. However, in a regulated one, it can stop the product reaching patients at all. You cannot show which requirement a piece of code was written for, and you cannot prove that it works.
Common SaMD Examples by Risk Category
Abstract categories are hard to hold onto, so here are SaMD examples arranged from lower risk to higher. Treat them as illustrations of the pattern rather than rulings on any specific product:
- Lower risk: tools that inform a decision in a situation that isn’t urgent. A symptom reference app that helps a patient describe a rash before an appointment informs without deciding anything. Move outside the framework entirely and a general fitness tracker isn’t regulated at all, since it makes no clinical claim.
- Moderate risk: products whose output genuinely shapes care. These include software that reviews a patient’s medication list and flags a dangerous interaction, driving the next clinical step. The same goes for a tool that triages incoming cases and moves urgent ones up the queue, where their seriousness pushes it higher up the grid.
- Higher risk: products that diagnose or treat directly, especially in critical conditions. Imaging software that identifies a suspected stroke and alerts the on-call team is a well-known instance. So is any application that calculates a radiotherapy dose, where an error carries irreversible consequences.
The pattern is consistent across all three tiers. Risk climbs when the product’s answer replaces human judgment rather than supporting it, and it climbs again when the patient has less room to survive a mistake.
Where a Development Partner Fits, and Where It Does Not
Whether your product counts as software as a medical device, which category it falls into, and what you have to file are regulatory questions. These questions should be answered by a qualified consultant. As a development company, we cannot categorize your product, and you should be wary of any vendor who claims otherwise.
However, whether your product can provide the evidence a regulator wants is an engineering question, and we can help you with that. The answer comes from reading the code, the tests, and the documentation you already have. A software audit does exactly that, and it’s usually the cheapest first step.
Most teams who run into trouble didn’t start with a regulatory plan. They shipped a health product quickly, found customers, and then heard the classification question from a buyer. If that sounds like your company, talk to us about your healthcare software project and find out where your code and documentation actually stand.
FAQ
What is the difference between SaMD and software in a medical device?
Software as a medical device works on its own. Software in a medical device is built into hardware and makes that hardware function, like the firmware running an infusion pump. Both fall under regulation, but the second is assessed as part of the equipment it belongs to rather than as a product in its own right.
Is a fitness or wellness app software as a medical device?
Usually not. Tracking workouts, steps, or sleep makes no claim about diagnosing or treating anything, so general wellness apps sit outside the rules. The deciding factor is intended use, meaning what you say your product is for. Add one feature that flags a possible medical problem and the answer can change.
Do you need FDA clearance to sell health software?
Not always. Administrative tools such as billing and scheduling need none, and general wellness apps usually do not either. Software that diagnoses, treats, or guides a clinical decision normally does. Because the answer follows from what you claim your product does, settle that question with a regulatory consultant well before launch.
What happens if you find out your product is SaMD after launch?
This is common, and it usually surfaces when an investor or a hospital buyer asks. Begin with a regulatory consultant, who can tell you where you actually stand. In parallel, an audit of your code, tests, and records shows how much of the required evidence already exists and how much has to be rebuilt.
See how Redwerk audited Complete Network’s Project Science software and boosted code maintainability by 80% before scaling nationwide
