Medical Device Software Development: SaMD, IEC 62304, FDA
Medical device software is defined by intended use, not tech stack. A dose-calculation app is a device. An appointment scheduler is not. Here is how SaMD classification, IEC 62304, and FDA pathways shape what your engineering team actually builds.
Medical device software development is software engineering under a regulated quality management system (QMS). What makes software a medical device is its intended use, not its tech stack. A dose-calculation app that outputs a specific insulin dose based on a patient's glucose reading is a medical device. An appointment scheduler at the same hospital is not. A general wellness tracker with step-counting and sleep logging is usually not a device. Call it a "diagnostic tool for sleep disorders" in the marketing copy and the intended-use analysis shifts accordingly.
That line is the first thing a software team building health software needs to draw.
The short version
- Whether software is a medical device is set by its intended use, not its tech stack: a dose-calculation app qualifies, an appointment scheduler does not.
- Software as a Medical Device (SaMD) performs a medical purpose without being part of a hardware device, and the IMDRF classifies it by the healthcare situation and the significance of the information it provides.
- Most SaMD in the United States reaches market as a Class II device through the FDA 510(k) pathway by proving substantial equivalence to a predicate; novel devices use De Novo, and high-risk ones need Premarket Approval (PMA).
- IEC 62304 sorts software into safety Class A, B, or C by the severity of harm a failure could cause, and the class sets how much documentation, traceability, and ISO 14971 risk management the code needs.
- Every third-party or open-source component counts as SOUP (Software of Unknown Provenance) and must be inventoried with its version, role, and known anomalies at Class B and C.
- Calling a product a wellness app is legitimate only when it makes no diagnostic or therapeutic claims, because marketing language itself can move software into device status.
SaMD: what the term means and where the risk sits
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 performs those purposes without being part of a hardware medical device. A standalone app is SaMD. Firmware embedded in an infusion pump is not SaMD; it is part of a hardware device, subject to the whole device's regulatory pathway. An algorithm running on a general-purpose smartphone is SaMD.
IMDRF's risk framework for SaMD classifies along two axes: the state of the healthcare situation (critical, serious, or non-serious) and the significance of the information provided (inform, drive, or treat/diagnose). Software whose output treats or diagnoses in a critical situation sits in the highest risk category. Software that provides information to a clinician managing a non-serious condition sits in the lowest.
The four IMDRF categories map roughly but not exactly onto FDA or EU MDR classifications (each regulator runs its own scheme), though the underlying logic is consistent: the more directly the software output drives irreversible clinical action, the higher the regulatory scrutiny.
FDA pathways: what they mean for a software team
Most SaMD in the United States enters the market as a Class II medical device through the 510(k) premarket notification pathway. The 510(k) submission must demonstrate substantial equivalence to a legally marketed predicate device, with the same intended use and the same or equally safe technological characteristics. For software, the predicate is usually a cleared device with a comparable clinical function, not necessarily identical architecture.
When no adequate predicate exists, the De Novo pathway lets a novel low-to-moderate risk device establish its own classification and then serve as a predicate for future 510(k)s. A device classified via De Novo gains a new product code, and De Novo adds time plus a more extensive benefit-risk analysis. Note that many low-risk device classes are 510(k)-exempt, and the FDA exercises enforcement discretion for some low-risk software functions, so not every device classification automatically triggers a premarket submission.
Class III devices (high-risk, life-sustaining) require Premarket Approval (PMA) backed by clinical evidence. Most SaMD does not land here.
| FDA pathway | Device class | What you must demonstrate | When it applies |
|---|---|---|---|
| 510(k) premarket notification | Class II | Substantial equivalence to a legally marketed predicate device | Most SaMD, where a comparable predicate exists |
| De Novo | Class I or II (novel) | Reasonable safety and effectiveness for a novel low-to-moderate risk device | No adequate predicate exists |
| Premarket Approval (PMA) | Class III | Clinical evidence of safety and effectiveness | High-risk, life-sustaining software |
The 21st Century Cures Act created explicit carve-outs for certain clinical decision support software. CDS that lets a licensed clinician independently review the underlying basis of a recommendation, and is not intended to replace clinical judgment, can fall outside device status. A tool that informs reasoning qualifies; one that replaces it does not.
For a software team: find your predicate early and treat it as the scope boundary. De Novo means a longer regulatory timeline; build that into the schedule from day one.
IEC 62304: the paperwork is the product
IEC 62304 defines software lifecycle processes for medical device software. Its safety classification system (Class A, B, and C) is where the documentation requirements come from.
Class A: software failure cannot contribute to a hazardous situation or the hazard is acceptable. Minimal documentation requirements apply.
Class B: software failure could contribute to a hazardous situation that results in non-serious injury. Requires a software development plan, requirement traceability, verification records, and a SOUP inventory for every third-party component.
Class C: software failure could contribute to serious injury or death. Goes further with full unit-level traceability from every design input through every test record, anomaly resolution records for each software item, and risk management per ISO 14971 applied at the individual unit level.
SOUP (Software of Unknown Provenance) is every third-party component not developed under your quality system: open-source libraries, commercial SDKs, OS packages. For each SOUP entry at Class B and C, the team documents the version, functional role, known anomalies, and how risks from failure are addressed in the risk file. A dependency update triggers a documented review, not a routine merge.
ISO 14971 risk management applies at every safety class, because classification itself emerges from risk analysis. What changes at Class C is granularity: risk items reference specific software units, so changing a dosing calculation module means updating the risk analysis alongside the tests.
What changes in engineering practice
Standard software development practices do not disappear under IEC 62304; they gain weight.
Requirements traceability means every requirement traces forward to its design implementation and backward to its verification test. A JIRA ticket with "as a clinician I want to review alerts" is not a requirement in the regulatory sense: it must be stated precisely enough for a test to unambiguously pass or fail against it.
Change control formalizes what most teams do informally. Any change to software in a released state requires a documented analysis of what the change affects, what regression risk it introduces, and which risk file items need review. A hotfix to a Class C device without a change record is a quality system failure, not a minor process gap.
Risk-driven testing means test coverage decisions reference the risk file. High-risk software units get more rigorous verification, independent review, and documented testing to a higher standard than utility code.
Release discipline does not relax. CI/CD is compatible with IEC 62304 and automated pipelines are useful. Every release that changes device functionality still requires a release record: requirements verified, risk items reviewed, SOUP changes assessed. Cadence can be fast; documentation must keep pace.
Custom software development in a healthcare context means scoping this documentation architecture in discovery, before the first line of code, because retrofitting it onto an existing codebase is where projects spend the most time and budget for the least forward progress.
The healthcare software development practice at Idealogic runs the IEC 62304 safety class analysis alongside the intended-use statement, so the team knows the documentation depth before it is too late to design for it.
The honest section: when wellness positioning is legitimate, and when it is not
A product team may genuinely be building a wellness app, not a medical device. The distinction is available and the engineering path is substantially lighter. But the intended-use boundary is not set by the team's preference: it is set by the product's claims.
Wellness positioning is legitimate when the app genuinely provides general health information, encourages healthy behaviors, and does not make clinical determinations about a user's health status. A sleep tracker that shows hours slept and suggests a consistent bedtime is not a device. A guided breathing app is not a device.
The line blurs when marketing copy, in-app language, or clinical data integrations claim diagnostic, therapeutic, or predictive medical function. If the app claims to "detect early signs of atrial fibrillation" or "identify your risk of developing type 2 diabetes," those are medical device claims. The intended-use statement in the FDA's analysis will reflect what the product actually says to users, not what the team intended in good faith.
The discipline is in the claims, including marketing claims. FDA enforcement actions have cited promotional language alongside submission documents in intended-use determinations.
A non-device app can still handle protected health information if it operates within a covered entity's ecosystem. HIPAA obligations apply regardless of device status. For the HIPAA analysis and what the technical safeguards require, see how to build HIPAA-compliant software.
Frequently asked questions
Software as a Medical Device (SaMD) is software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. The IMDRF definition focuses on intended use, not technology: a standalone app that analyzes retinal images to detect diabetic retinopathy is SaMD; the same image-viewing app used only for photography is not. Regulatory bodies including the FDA and EU MDR bodies use this framework to determine whether a software product falls under medical device regulations.
IEC 62304 is the international standard defining software lifecycle processes for medical device software. It assigns safety classes A, B, and C based on the severity of harm that a software failure could cause. Class A software has no injury potential; Class B could cause non-serious injury; Class C could cause serious injury or death. The class determines documentation depth: a Class C system requires a full software development plan, complete requirements traceability from design input to test record, risk management per ISO 14971, full unit-level traceability, and anomaly resolution records for every software item.
It depends on intended use. Most consumer wellness apps (step counters, meditation guides, appointment schedulers) are not medical devices and do not require FDA clearance. Software that diagnoses, treats, cures, or mitigates a disease or condition using patient-specific data is generally subject to FDA oversight. The 21st Century Cures Act carved out certain clinical decision support tools: CDS that lets clinicians independently review the basis of a recommendation and is not intended to replace clinical judgment is often outside device status. A dose-calculation tool that outputs a specific drug dose without requiring the clinician to review the underlying logic does not qualify for that carve-out.
A 510(k) is the most common FDA premarket submission pathway for Class II medical devices, including most SaMD. The submission demonstrates that the device is substantially equivalent to a legally marketed predicate device, one already cleared or grandfathered before the Medical Device Amendments of 1976. Substantial equivalence means matching intended use and technological characteristics that are the same or equally safe. If no suitable predicate exists, the De Novo pathway lets a novel low-to-moderate risk device establish its own classification and become a predicate for future 510(k)s.
SOUP stands for Software of Unknown Provenance, which is any software component that was not developed under the control of the medical device software development process. In practical terms, this includes open-source libraries, commercial off-the-shelf components, and operating system packages. IEC 62304 requires a SOUP inventory for Class B and C systems: each entry documents the component version, its functional and performance requirements, any known anomalies, and how risks from SOUP failure are addressed in the risk file. The inventory must be kept current throughout the product lifecycle.
More from the journal
How to Build HIPAA-Compliant Software
HIPAA compliance is an engineering problem before it is a legal one. The Security Rule reads like a requirements document once you stop treating it as legal text. Here is how to implement it.
Clinical Trial Management Software: How It's Built
Clinical trial management software runs the operational side of a trial. Here's where it sits among EDC and eTMF, the data model, CDISC integration, 21 CFR Part 11, and what it takes to build.
Healthcare Data Analytics: Architecture and How to Build It
Healthcare data analytics turns clinical, claims, and device data into decisions. Here's the four types, the reference architecture, HL7/FHIR integration, HIPAA de-identification, and the ML pipeline behind it.