Software as a Medical Device (SaMD)

What it is

Software as a Medical Device (SaMD) is standalone software intended for one or more medical purposes—such as diagnosis, prevention, monitoring, prediction, or treatment—without being part of a hardware device. Regulators treat SaMD as a medical device based on intended use and risk (IMDRF SaMD definition; EU MDR 2017/745 Art. 2(1), Annex VIII Rule 11; US FD&C Act §201(h)). SaMD must demonstrate safety, performance, and a positive benefit–risk profile across its lifecycle.

Regulatory framework

• EU (MDR): Definition and scope (Art. 2(1)); classification by Rule 11 (Annex VIII); GSPRs (Annex I); technical documentation (Annex II–III); clinical evaluation/PMCF (Art. 61; Annex XIV); labeling/UDI (Annex I Ch. III; Arts. 27–29).
• US (FDA): Device status per intended use (FD&C Act §201(h)); quality system (21 CFR 820 QMSR, including design validation §820.30 and software validation §820.70(i)); submissions via 510(k), De Novo (21 CFR 860), or PMA (21 CFR 814); labeling/UDI (21 CFR 801/830). FDA adopts IMDRF principles for SaMD clinical evaluation.
• Core standards: IEC 62304 (software lifecycle), IEC 82304-1 (health software), ISO 14971 (risk), IEC 62366-1 (usability), IEC 81001-5-1 (cybersecurity), plus relevant interoperability standards.

Key elements

• Intended use & claims: Clinical function, target condition, user, setting, and output/impact on care.
• Risk & classification: EU Rule 11 (information significance and patient condition); US class/panel by predicate, risk, and claims.
• Architecture & SOUP: Document software items, external services/APIs, and third-party components with maintenance strategy.
• Clinical evaluation: Analytical/clinical validation and, where appropriate, clinical performance per claims (MDR Art. 61; IMDRF SaMD clinical eval).
• Cybersecurity: Threat modeling, secure design, SBOM, update policy, and vulnerability handling aligned to IEC 81001-5-1/FDA guidance.

Process — how it works

• Define & classify: Write precise intended use; apply EU Rule 11 or US class logic; choose the pathway (CE route/510(k)/De Novo/PMA).
• Plan & design: Create a software development plan (IEC 62304); manage requirements, risk (ISO 14971), usability (IEC 62366-1), and security.
• Verify & validate: Unit/integration/system tests, software validation, and clinical evaluation that match claims and outputs.
• Prepare the file: Build technical documentation (Annex II–III) or US submission; include cybersecurity, SOUP, algorithms, and human factors.
• Release & monitor: Control versions, communicate intended use/limitations, collect PMS/real-world data, and run PMCF if needed.
• Change control: Assess updates (bug, minor, feature, algorithm change); determine if regulatory submission or NB/FDA review is required.

Common pitfalls

• Underestimating EU Rule 11 class (e.g., diagnostic/therapeutic impact ⇒ higher class).
• Claims that exceed validation evidence or omit clinical performance metrics.
• Weak cybersecurity posture (no SBOM, patch policy, or vulnerability response).
• Poor control of third-party code, cloud services, or machine-learning models.
• Inadequate change control and real-world performance monitoring after release.

Quick checks / Tips

• Can you trace every claim to analytical, clinical, and usability evidence?
• Does your risk file cover data quality, connectivity, alarms, and misuse?
• Are updates versioned, tested, and assessed for regulatory impact before release?
• Is cybersecurity designed in (secure defaults, logging, SBOM) and maintained post-market?