Beyond Change Control: Toward Adaptive SaMD Lifecycle Management

Adaptive SaMD lifecycle management is a way of running software as a medical device (SaMD) so that expected change is planned, risk-assessed and evidenced before it happens, rather than reviewed one ticket at a time after engineering has finished. It does not replace change control under FDA's Quality Management System Regulation (QMSR) in 21 CFR Part 820. It builds on it: the same design-change, risk-management and verification obligations apply, but the team decides in advance which kinds of change are likely, what evidence each one needs, and who must agree before release.

That shift matters because software teams now ship faster than traditional quality systems were designed to absorb. A model retrained on new data, a third-party library patched for a vulnerability, a reworded alert, or a move to a new cloud region can each affect safety, effectiveness or labeling. Treating every one of them as a surprise slows good improvements and lets risky ones slip through as "minor." This post sets out practical principles for anticipating software evolution, planning evidence proportionate to risk, and keeping engineering, quality, clinical and regulatory functions working from one shared picture across the product lifecycle.

Why traditional change control strains under continuous delivery

Classic change control assumes that changes are infrequent, discrete and easy to classify. A change request is raised, an impact assessment is written, verification is run, and a reviewer signs off. For hardware and for slow-moving software, that works.

Continuous software delivery breaks three of those assumptions:

• **Volume.** Dozens of merges per sprint make case-by-case regulatory review a bottleneck, so teams start batching or under-classifying changes.
• **Coupling.** A small code change can alter model behavior, performance on a subgroup, or how clinicians read an output. Impact is rarely visible from the diff alone.
• **Timing.** Regulatory questions — does this need a new submission? — are often asked after the work is done, when the cheapest answer is the one nobody wants to hear.

FDA's guidance on deciding when to submit a 510(k) for a software change to an existing device remains the key decision tool for many cleared products. The adaptive approach does not bypass that logic; it applies it earlier and more consistently.

Principle 1: Anticipate software evolution

Start by writing down the changes you already expect over the next two to three years. Most SaMD roadmaps are predictable: performance improvements, new input sources, extended device or browser support, cybersecurity updates, UI refinements and, for machine-learning products, periodic retraining.

For each anticipated change type, record:

• what will change and what must stay fixed (intended use, indications, core clinical claims);
• the modification method — how the change will be developed, tested and released;
• acceptance criteria that would show the change is safe and performs as intended;
• the regulatory route you expect, confirmed with regulatory affairs.

For AI-enabled software, FDA's predetermined change control plan (PCCP) framework lets manufacturers obtain authorization for specified future modifications in the original submission, provided they follow the agreed protocol and impact assessment. Even where a PCCP is not pursued, the same discipline — describe the change, the method and the limits up front — makes internal change control faster and more defensible. Our PCCP guide walks through eligibility and outline building.

Principle 2: Plan evidence proportionate to risk

Not every change deserves the same evidence package. Proportionality means the depth of verification, validation and documentation scales with the potential for harm and with how far the change moves the device from its validated state.

Link each tier to your ISO 14971 risk analysis rather than to a gut feeling. If a change touches a hazardous situation or a risk control, it moves up a tier automatically. FDA's content of premarket submissions for device software functions guidance is a useful reference for what documentation level reviewers expect as risk rises.

Principle 3: Make cybersecurity and dependencies part of the lifecycle

For connected SaMD, many of the most frequent changes come from outside your own code: operating-system updates, open-source libraries and hosting platforms. FDA's cybersecurity guidance expects a software bill of materials (SBOM), vulnerability management and a plan for timely updates.

Build these into the change tiers above. Pre-define how a routine security patch is assessed, tested and released so it can move quickly, and define the triggers — such as a change in a validated output — that escalate it.

Principle 4: Run one lifecycle across four functions

Adaptive lifecycle management fails when each function keeps its own version of the truth. Engineering tracks tickets, quality tracks change records, clinical tracks evidence and regulatory tracks submissions — and nobody sees the whole picture until an audit.

Practical ways to close the gap:

• **Shared change taxonomy.** Use the same change tiers in the issue tracker, the change record and the regulatory assessment.
• **Early regulatory touchpoint.** Ask the submission question at backlog refinement, not at release.
• **Clinical input on high-tier changes.** Clinicians judge whether an output change could alter decisions at the point of care.
• **Traceability by default.** Each released change links to requirements, risk items, tests and the regulatory rationale.
• **Postmarket feedback loop.** Complaints, real-world performance monitoring and field data feed the next planning cycle, consistent with FDA's Good Machine Learning Practice guiding principles for AI products.

Adaptive lifecycle readiness checklist

Download the Adaptive SaMD Lifecycle Change Planner to map anticipated changes, risk tiers, evidence, regulatory routes and owners across engineering, quality, clinical and regulatory. It is a preparation aid, not an FDA form or a substitute for product-specific regulatory judgment.

• Anticipated change types for the next two to three years are documented with fixed boundaries.
• Each change tier has defined evidence, acceptance criteria and decision owners.
• Risk-file links automatically escalate changes that touch hazards or risk controls.
• Cybersecurity patches and dependency updates follow a pre-defined, tested route.
• Regulatory assessment happens at planning, not after release.
• A PCCP has been evaluated for AI-enabled modifications where appropriate.
• Postmarket performance data feeds the next lifecycle planning cycle.

Frequently asked questions

What is adaptive SaMD lifecycle management?

It is a planned approach to software medical device change in which likely modifications, their risk level, required evidence and regulatory route are defined in advance, so teams can release improvements quickly while staying within QMSR design-change and risk-management requirements.

Does adaptive lifecycle management replace change control?

No. Change control under 21 CFR Part 820 and ISO 13485 still applies to every change. The adaptive approach makes change control faster and more consistent by classifying changes against agreed tiers instead of starting each assessment from scratch.

Is a PCCP required to use an adaptive approach?

No. A PCCP is one FDA mechanism for pre-authorizing specified modifications, most relevant to AI-enabled devices. Teams without a PCCP can still anticipate change, tier evidence by risk and align functions; they simply apply existing submission-decision guidance to each change.

How do you decide how much evidence a software change needs?

Scale evidence to risk: consider whether the change affects a hazardous situation, a risk control, a clinical output or the intended use. Low-risk changes need regression testing and records; high-risk changes need targeted performance, clinical and regulatory assessment.

FDA primary sources

Start with FDA's QMSR overview and current 21 CFR Part 820. For change decisions, use deciding when to submit a 510(k) for a software change and FDA's predetermined change control plans page. For documentation and security, see content of premarket submissions for device software functions and the cybersecurity in medical devices guidance. For AI products, review the Good Machine Learning Practice guiding principles.

Related reading: Digital pathology software QMSR checklist, QMSR for AI/ML medical devices, QMSR design controls and the PCCP guide.

Plan your next release with evidence in place

Use MedTech Copilot to map anticipated software changes to risk tiers, evidence plans and regulatory routes, and to keep engineering, quality, clinical and regulatory decisions traceable in one workspace. Qualified human owners remain responsible for release and regulatory determinations. The goal is practical, evidence-backed, inspection-ready lifecycle management — not automated assurance of compliance.