FDA SaMD Classification

Software as a Medical Device (SaMD) is defined by the International Medical Device Regulators Forum (IMDRF) as software intended to be used for one or more medical purposes without being part of a hardware medical device. The FDA has adopted this framework and operationalized it through multiple guidances: the 2017 Digital Health Innovation Action Plan, the Software as Medical Device guidance (2017), and the 2022 Digital Health Center of Excellence policy documents. The FDA uses a risk-based framework aligning IMDRF's four SaMD categories (Category I-IV based on healthcare situation significance and intended use significance) to its existing device classification (Class I/II/III). Most SaMD requires either a 510(k) Premarket Notification (demonstrating substantial equivalence to a predicate device) or a De Novo classification request for novel low-to-moderate risk software. High-risk SaMD may require a PMA (Premarket Approval). The Predetermined Change Control Plan (PCCP) guidance (2023) enables manufacturers to pre-specify modifications that can be made post-clearance without a new submission.

The engineering reality of FDA SaMD compliance centers on the Quality Management System (QMS) obligation. All Class II and III medical device software — and many Class I devices that are not exempt — must be manufactured under a QMS meeting 21 CFR Part 820 (Quality System Regulation) or the harmonized ISO 13485:2016 standard. The FDA's transition to the Quality Management System Regulation (QMSR, finalized 2024) aligns Part 820 with ISO 13485, making ISO 13485 effectively the baseline. For software specifically, FDA references IEC 62304 (medical device software lifecycle) as the technical standard for software development processes. Practically, this means formal requirements traceability, risk management per ISO 14971, design controls with documented design history files, and validation testing — all with audit trails. Agile development is not prohibited but requires specific adaptation: the FDA's Agile guidance recommends documentation practices that capture design decisions within sprints without creating waterfall-style overhead.

The scope question — is this software a medical device? — is the most consequential engineering decision and the most frequently litigated. The 21st Century Cures Act created statutory exclusions from device definition for administrative software, general wellness products, and certain clinical decision support (CDS) software. The CDS exclusion applies when software displays, analyzes, or prints medical information; is not intended to replace clinical judgment; and provides clinicians with the basis for recommendations. Software that meets all four statutory criteria is not a device. AI/ML-based software adds further complexity: the FDA's 2021 action plan for AI/ML-based SaMD acknowledges that continuously learning algorithms present challenges to the traditional "locked" software paradigm, and the PCCP framework is the current primary mechanism for managing AI model updates within cleared indications.

We conduct SaMD determination analyses as part of initial architecture review, documenting the intended use, user interface design decisions, and algorithm logic in terms that directly map to FDA regulatory criteria and IMDRF risk categories. For software determined to be SaMD, we implement IEC 62304-compliant software development lifecycle processes integrated into modern CI/CD tooling — requirements traceability in Jira, automated test evidence capture, and design history file generation. Our PCCP templates define modification types, impact assessment criteria, and pre-specified testing protocols to maximize post-clearance flexibility.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.