Software as a medical device: deciding scope before you build
Write the intended use first, check it against the device definition and the 520(o) exclusions, then size documentation to risk.
In Short
- Intended use decides scope.
- 520(o) excludes some functions.
- Basic or Enhanced Documentation.
Software as a medical device (SaMD) is software intended for a medical purpose that performs that purpose without being part of a hardware device. In the United States the starting point is the device definition in 21 U.S.C. 321(h) and the software functions excluded from it by 21 U.S.C. 360j(o), added by the 21st Century Cures Act. FDA's June 2023 guidance on premarket submissions for device software functions sets documentation expectations. IMDRF definitions were not opened for this review. This guide summarises the sources named here; it is orientation, not legal advice. Sources checked 5 Oct 2026.
Start with intended use
Whether software is a device depends on what it is intended to do, shown by labelling, claims and marketing, not on the code. Software intended for diagnosis, cure, mitigation, treatment or prevention of disease can meet the device definition in 21 U.S.C.
More on start with intended use
321(h). Write the intended use and indications in one controlled statement early, because it drives scope, classification, risk analysis and every later change assessment. Marketing teams should work from the same statement so claims do not drift beyond it.
The 520(o) exclusions
Section 520(o)(1) of the FD&C Act, codified at 21 U.S.C. 360j(o), excludes several software functions from the device definition.
Is this software function excluded? (examples)
- Administrative support of a health care facility.
- Section 520(o)(1)(A).
- Record the rationale.
More on the 520(o) exclusions
They include functions for administrative support of a health care facility, for maintaining or encouraging a healthy lifestyle unrelated to disease, certain electronic patient record functions, and functions for transferring, storing, converting or displaying laboratory or other device data. Certain clinical decision support functions are also excluded when all statutory criteria are met. Each exclusion has conditions; record which one you rely on and why.
Documentation Level for a Submission
FDA's June 2023 guidance replaces the older level-of-concern approach with two documentation levels. Enhanced Documentation applies where a failure or flaw of a device software function could present a hazardous situation with a probable risk of death or serious injury, assessed before risk controls.
Documentation level (June 2023 guidance)
| Question | If yes | If no |
|---|---|---|
| Could a failure present a hazardous situation? | Assess severity | Basic Documentation |
| Probable risk of death or serious injury, before controls? | Enhanced Documentation | Basic Documentation |
| Rationale recorded? | Include in submission | Complete before submitting |
- Could a failure present a hazardous situation?
- If yes
- Assess severity
- If no
- Basic Documentation
- Probable risk of death or serious injury, before controls?
- If yes
- Enhanced Documentation
- If no
- Basic Documentation
- Rationale recorded?
- If yes
- Include in submission
- If no
- Complete before submitting
More on documentation Level for a Submission
Basic Documentation applies otherwise. The level decides how much software design, architecture and testing detail goes into the submission, not whether you need a controlled lifecycle. Your regulatory team records the rationale.
Lifecycle records a SaMD team keeps
Expect to maintain a software description, risk management file, requirements, architecture, verification and validation evidence, a list of third-party components, version history and an assessment of known unresolved defects. FDA lists ANSI/AAMI/IEC 62304 among consensus standards relevant to software lifecycle processes.
More on lifecycle records a SaMD team keeps
Keep design changes under change control with impact assessment against the intended use and risk file, so every release has a traceable reason, review and approval by named people.
When a change needs a new submission
Software changes quickly, but a release that changes intended use, adds a new clinical function or alters risk may need a new regulatory submission. Decide this before release, not after.
More on when a change needs a new submission
A predetermined change control plan, where authorised, can cover planned modifications described in advance. Record the assessment for each release, link it to the change request and test evidence, and have regulatory and quality approve it. The record shows the decision; people make it.
Questions
Is all health software a medical device?
No. Section 520(o) excludes several software functions, such as administrative support and general wellness functions unrelated to disease, when their statutory conditions are met.
What replaced the level of concern?
FDA's June 2023 premarket guidance uses Basic and Enhanced Documentation levels, based on whether a failure could present a probable risk of death or serious injury.
Does FDA require IEC 62304?
FDA lists ANSI/AAMI/IEC 62304 as relevant to software lifecycle processes; following a recognised standard is one way to show lifecycle control, not the only one.
Who decides whether software is excluded?
Your regulatory team decides, based on intended use and the statutory conditions, and should record the rationale. FDA can disagree, so keep the reasoning current.
Practical orientation, not legal advice. Rules differ by jurisdiction; your quality and compliance team decides what applies.
Keep reading
IEC 62304 Readiness: Software Lifecycle Evidence for Device Makers
Predetermined Change Control Plans (21 U.S.C. 360e-4) for Medical Devices
Australia Medical Device Regulatory Readiness Guide
Brazil medical device regulatory readiness guide (ANVISA)
Canada Medical Devices Regulations (SOR/98-282) Readiness
China Medical Device Regulatory Readiness Guide 2026