What counts as Software as a Medical Device (SaMD)?

SaMD is software intended for a medical purpose that performs that purpose without being part of a hardware device, a diagnostic or screening algorithm, clinical decision support, or a mobile app that interprets data. The FDA regulates it as a medical device in its own right, so the design controls, risk management, and clinical evidence apply to the software itself.

How is SaMD different from software inside an instrument?

Software embedded in an instrument (sometimes called SiMD) is one part of a larger device; SaMD is the device. The engineering discipline is the same, IEC 62304 lifecycle, ISO 14971 risk management, IEC 62366 usability, but for SaMD there is no hardware to carry any of the safety argument, so the software has to carry all of it.

Is my app a medical device, an MDDS, or unregulated wellness software?

It depends on the intended use and the claims you make. Software that only transfers, stores, or displays data may fall under Medical Device Data Systems (MDDS); general wellness software may be unregulated; software that interprets data or drives a clinical decision is usually SaMD. We help you pin the intended-use statement down before it drives the whole regulatory strategy.

Does IEC 62304 apply to SaMD?

Yes. IEC 62304 applies to any medical device software, including standalone SaMD. We confirm the software safety classification (Class A, B, or C) and build the lifecycle artifacts, architecture, detailed design, SOUP inventory, and verification, to match that class.

How do you handle cybersecurity for SaMD?

As part of the lifecycle, not a bolt-on. For a connected SaMD subject to FDA Section 524B we build the threat model, generate the SBOM, and write the premarket security documentation as the software is built, so the security file is a by-product of the work rather than a scramble before filing.

Which FDA pathway does SaMD use?

The same pathways as other devices, 510(k), De Novo, or PMA, chosen by the device's risk and predicate landscape, not by the fact that it is software. We identify the software and clinical evidence your chosen pathway expects and build the documentation to line up with it.

Services · Teams whose product is the software, diagnostic algorithms, clinical decision support, mobile medical apps

Software as a Medical Device (SaMD)

When the product is the software itself, a diagnostic algorithm, a clinical decision support tool, a mobile medical app, it is Software as a Medical Device (SaMD), and the full FDA burden lands on the code. RND builds SaMD to IEC 62304, ISO 14971, and IEC 62366 usability, with the cybersecurity and submission evidence review expects.

Talk to us about your SaMD

SaMDIEC 62304ISO 14971IEC 62366ISO 13485:201621 CFR Part 11FDA Section 524BSBOM510(k)De NovoPMAEU MDR

Cloud & web deploymentiOS / AndroidClinical decision supportAlgorithm validationSOUP analysisRequirements traceability

The software carries the whole argument

With Software as a Medical Device there is no instrument to anchor the safety case, the code is the device, so every regulatory expectation lands on it. We build SaMD the way we build the software inside instruments: an IEC 62304 lifecycle scaled to the software safety class, ISO 14971 risk management traced from hazard to requirement to test, and IEC 62366 usability engineering where a user’s interpretation is part of the intended use.

What we build

Diagnostic and screening algorithms, with a validation strategy that stands up to review, and a clear boundary between the algorithm and its claims.
Clinical decision support, where the line between informing and directing a clinician determines whether, and how, it is regulated.
Mobile and web SaMD, iOS, Android, and cloud, with the deployment and update story documented rather than assumed.

Getting the intended use right first

More SaMD programs are derailed by a loose intended-use statement than by the engineering. Whether your product is an unregulated wellness tool, an MDDS, or full SaMD flows from what it claims to do, and that decision shapes the lifecycle, the risk file, and the pathway. We help you fix it early, so the software is built to the right standard from the first sprint.

Built for the submission

Connected SaMD is a “cyber device” under FDA Section 524B, so the threat model, the SBOM, and the premarket security documentation are generated by the lifecycle, not assembled at the end. Where the software creates electronic records or signatures, we build the 21 CFR Part 11 controls in from the start. Independent verification and validation produces the evidence, and a quality and compliance review confirms it lines up with your 510(k), De Novo, or PMA before you file.

25+: 25+ years in business
15+ yrs: Engineers average 15+ years of experience
2 teams · 1 QMS: Separate development and V&V teams under one quality system

One partner, end to end

Software built alongside the instrument.

RND writes and verifies the software. Gener8 designs and manufactures the instrument, cartridges, and consumables around it, mechanical, electronics, optics, and microfluidics, under one roof. Software, device, and disposables from a single partner.

Explore Gener8 capabilities

Frequently asked questions

What counts as Software as a Medical Device (SaMD)?: SaMD is software intended for a medical purpose that performs that purpose without being part of a hardware device, a diagnostic or screening algorithm, clinical decision support, or a mobile app that interprets data. The FDA regulates it as a medical device in its own right, so the design controls, risk management, and clinical evidence apply to the software itself.
How is SaMD different from software inside an instrument?: Software embedded in an instrument (sometimes called SiMD) is one part of a larger device; SaMD is the device. The engineering discipline is the same, IEC 62304 lifecycle, ISO 14971 risk management, IEC 62366 usability, but for SaMD there is no hardware to carry any of the safety argument, so the software has to carry all of it.
Is my app a medical device, an MDDS, or unregulated wellness software?: It depends on the intended use and the claims you make. Software that only transfers, stores, or displays data may fall under Medical Device Data Systems (MDDS); general wellness software may be unregulated; software that interprets data or drives a clinical decision is usually SaMD. We help you pin the intended-use statement down before it drives the whole regulatory strategy.
Does IEC 62304 apply to SaMD?: Yes. IEC 62304 applies to any medical device software, including standalone SaMD. We confirm the software safety classification (Class A, B, or C) and build the lifecycle artifacts, architecture, detailed design, SOUP inventory, and verification, to match that class.
How do you handle cybersecurity for SaMD?: As part of the lifecycle, not a bolt-on. For a connected SaMD subject to FDA Section 524B we build the threat model, generate the SBOM, and write the premarket security documentation as the software is built, so the security file is a by-product of the work rather than a scramble before filing.
Which FDA pathway does SaMD use?: The same pathways as other devices, 510(k), De Novo, or PMA, chosen by the device's risk and predicate landscape, not by the fact that it is software. We identify the software and clinical evidence your chosen pathway expects and build the documentation to line up with it.

Last reviewed September 4, 2026.