IEC 62304 and the SaMD Software Lifecycle

IEC 62304 still tells medical device software teams how to classify safety, control SOUP, and govern change. Early 2026 raised the stakes: FDA’s Quality Management System Regulation (QMSR) is live, and eSTAR filings expect a software story that maps cleanly to design control and risk. A lifecycle that only looked tidy on a slide deck will not survive inspection or a structured submission.

Why the lifecycle is under fresh scrutiny

For years, many SaMD programmes treated IEC 62304 as a documentation checklist: assign a software safety class, list third-party components, and file a change-control procedure. That was never enough, but it was often enough to pass a light review. Two forces now make shallow compliance expensive. First, QMSR, effective 2 February 2026, incorporates ISO 13485:2016 into 21 CFR Part 820 and shifts FDA inspection toward risk-based, lifecycle-focused scrutiny. Software design, supplier control, and post-market feedback are no longer peripheral “IT topics”; they sit inside the quality management system FDA expects to see working. Second, eSTAR and similar structured electronic submissions force manufacturers to present evidence in consistent sections. Gaps between the intended-use claim, the software architecture, the SOUP inventory, and the verification strategy become visible immediately.

Teams building or maintaining SaMD should therefore re-read IEC 62304 as an operating system for how software is planned, built, verified, released, and changed — not as a binder of templates. The same discipline supports CE marking under MDR software expectations and international filings that lean on IMDRF language for SaMD.

Safety class drives the depth of evidence

IEC 62304 ties process rigor to software safety classification (Classes A, B, and C). Class is not a marketing label; it is a statement about the contribution of software failure to hazardous situations. If a wrong output can contribute to serious injury or death, the architecture, detailed design, unit verification, and integration testing expectations rise accordingly. Under-classifying to reduce paperwork is a regulatory and patient-safety risk. Over-classifying without adjusting architecture and tests creates noise and delays without improving control.

In practice, classification must be defended against the intended use and the clinical decision context. A triage score that merely “informs” still needs a clear boundary: what the clinician must still do, what the software must not decide alone, and how failure modes are mitigated. When AI models sit inside SaMD, classification and change control become even more sensitive because model updates can alter behaviour without a classic “feature release” narrative. The lifecycle process has to treat those updates as controlled design changes with predefined acceptance criteria.

SOUP is a supply-chain problem, not a spreadsheet

Software of unknown provenance (SOUP) — libraries, runtimes, operating systems, cloud SDKs, model weights obtained as packages — is where many SaMD programmes quietly fail. Listing package names is not SOUP control. Control means knowing why each component is needed, which version is locked for release, what known anomalies matter for your use, how you verify behaviour at the integration boundary, and how you monitor security and defect notices after release.

QMSR’s attention to outsourcing and purchasing makes this harder to ignore. If your product depends on a third-party imaging stack, an authentication library, or a hosted inference service, the quality system must show evaluation, monitoring, and escalation — not a one-time vendor questionnaire archived in email. For cloud-hosted SaMD, configuration drift and managed-service version bumps are change events. Treat them as such in the configuration management plan.

Rule: If you cannot name the software safety class, the locked SOUP set for the released build, and the change path that would trigger re-verification, you do not yet have an IEC 62304 lifecycle — you have a release checklist.

Change control after QMSR and eSTAR

Change control is where lifecycle theory meets production reality. Under IEC 62304, changes are analysed for impact on safety class, architecture, requirements, and verification. Under QMSR-aligned inspections, investigators will look for evidence that risk management and design changes stay connected — that a defect from the field, a SOUP CVE, or a model retrain leads to a documented decision, not an ad hoc hotfix. eSTAR mapping pressure adds another constraint: the narrative in the submission must match the process you actually run. If your filing describes unit tests for Class C software but your CI only runs end-to-end smoke tests, the inconsistency is discoverable.

A practical change-control pattern for SaMD teams:

• Intake — every change (feature, bugfix, SOUP bump, prompt or model update) enters a single queue with an owner and a preliminary impact screen.
• Impact analysis — map to requirements, risk controls, architecture interfaces, and verification artifacts that must be updated or re-run.
• Decision — release as-is, release with additional verification, or hold for a new marketing submission when the change exceeds the authorised change envelope.
• Evidence pack — keep the build identity, test reports, and residual risk statement tied to the released configuration.

For AI-enabled device software functions, FDA’s predetermined change control plan (PCCP) thinking is especially relevant: planned modifications need a methodology for development, validation, and impact assessment before they land in production. Even when you are not filing a PCCP in the US, the engineering habit — define the change space in advance — improves IEC 62304 change control worldwide.

What “good” looks like in delivery

High-performing SaMD programmes make the lifecycle visible in engineering tools. Requirements live where developers work, not only in a regulatory share drive. Traceability from hazard to risk control to software item to test case is queryable. Builds are reproducible. Anomalies are linked to CAPA when systemic. Post-market signals (complaints, near misses, performance drift) feed back into risk files on a schedule that matches clinical criticality.

That operating model is exactly what SaMD and AIaMD development engagements should establish early: classify honestly, design for the class you claim, and keep SOUP and change evidence continuous. Broader healthcare software development programmes that might later become regulated benefit from the same habits before the first filing deadline arrives.

A short mapping table for programme leads

Definitions still matter

Before arguing process maturity, align on definitions. The IMDRF SaMD key definitions remain the shared vocabulary for software intended for medical purposes that is not part of a hardware medical device. FDA’s Digital Health Center of Excellence maintains a practical Software as a Medical Device (SaMD) overview that teams should keep beside their quality manual when drafting intended use and labelling. Vocabulary alignment prevents the common failure mode where engineering, clinical, and regulatory staff use “device,” “tool,” and “decision support” to mean different risk postures.

What to do in the next quarter

If you already have IEC 62304 procedures, run a gap review against QMSR-ready evidence: medical device file completeness, supplier control for SOUP and cloud services, and end-to-end change records for the last three releases. If you are starting a new SaMD, freeze intended use and safety class before architecture freezes, and design verification so that eSTAR sections can be populated from living artifacts rather than rewritten under deadline pressure.

If you want a structured review of safety classification, SOUP governance, and change-control readiness for an upcoming filing or inspection, explore Yoctobe’s approach to SaMD / AIaMD development and how it sits alongside broader healthcare software development delivery — without turning the lifecycle into theatre.