Predetermined Change Control Plans: How AI Medical Devices Get FDA Clearance to Keep Learning

Artificial intelligence gets better by changing. It learns from new data, adapts to new populations, and improves as the world it operates in shifts. Medical device regulation, historically, was built on the opposite premise: a cleared device is a fixed device, and any modification that could affect its safety or effectiveness triggers a fresh trip through the FDA. For AI-enabled medical software, those two worldviews collide directly. The very thing that makes your model valuable — its ability to improve — is the thing that traditional clearance freezes in place.

For years, the workaround was to "lock" the model at submission and treat every meaningful update as a new regulatory event. That is slow, expensive, and fundamentally at odds with how good machine learning is built. The Predetermined Change Control Plan (PCCP) is the FDA's answer. It is a mechanism that lets you get cleared not just for what your device does today, but for a defined set of changes you plan to make to it tomorrow — without a new marketing submission each time.

This guide explains what a PCCP is, where it came from, the three components the FDA requires, and — the part most articles skip — what committing to a PCCP actually demands of your engineering team long after clearance.

Key Takeaways

• Traditionally, modifying a cleared AI device could require a new FDA submission — a poor fit for models designed to keep improving.
• A PCCP lets you get authorization upfront for specific, planned future changes, so you can implement them without a new marketing submission as long as you follow the plan.
• The FDA's authority comes from the 2022 FDORA law; the operative playbook is the FDA's December 2024 final guidance on PCCPs for AI-enabled device software functions.
• Every PCCP has three required parts: a Description of Modifications, a Modification Protocol, and an Impact Assessment.
• Changes must stay within your device's intended use — a PCCP lets you improve the device, not quietly turn it into a different one.
• A PCCP is an engineering commitment, not just a regulatory document: you have to actually build the data pipelines, monitoring, and version control the plan promises.

The Problem: A Cleared AI Device Is a Frozen One

When the FDA clears a Software as a Medical Device (SaMD), it clears a specific version of that software with specific, documented behavior. The clearance rests on evidence that this device, doing this thing, is safe and effective. Change the software in a way that could significantly affect safety or effectiveness, and you have — in regulatory terms — a different device that may need its own submission.

For conventional software, that is manageable. For an AI model, it is a straitjacket. Retraining on more representative data to reduce bias, improving accuracy as you collect real-world results, extending the model to a new imaging device or patient subgroup — these are exactly the improvements that make an AI product better over time, and each of them is precisely the kind of change that could trigger a new submission.

The traditional coping strategy was the "locked" model: freeze the algorithm at submission, ship it, and batch improvements into infrequent, expensive regulatory events. It works, but it means your device gets worse relative to the state of the art every month it sits frozen, and it puts your engineering roadmap on the FDA's timeline. The PCCP exists to break that trade-off.

---

What a Predetermined Change Control Plan Actually Is

A Predetermined Change Control Plan is a section of your original marketing submission (your 510(k), De Novo, or PMA) in which you describe, in advance, the modifications you intend to make to your device after it is cleared — and the methodology you will use to make them safely. If the FDA authorizes the PCCP, you can then implement those specific changes, following your own plan, without submitting a new marketing application for each one.

In plain terms: instead of asking permission every time you improve the model, you get permission once for a defined envelope of improvements and the process you will follow to make them. As long as a change falls inside that authorized envelope and you follow your protocol, you can ship it.

This is not a regulatory loophole — it is an explicit statutory mechanism. It comes from Section 3308 of the Food and Drug Omnibus Reform Act (FDORA) of 2022, which amended the Federal Food, Drug, and Cosmetic Act to give the FDA clear authority to approve or clear PCCPs. The operational detail lives in the FDA's final guidance, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions, issued in December 2024. That guidance is the document your regulatory strategy should be built against.

The underlying philosophy is the FDA's Total Product Lifecycle approach: rather than treating clearance as a one-time gate, regulate the device across its whole life, including the improvements you make after launch. A PCCP is how that philosophy becomes concrete for a learning system.

---

The Three Components of a PCCP

The FDA's guidance is specific about what a PCCP must contain. There are three parts, and each answers a different question: what will change, how you will change it safely, and why those changes will not compromise the device.

1. Description of Modifications

This is the "what." You list the specific modifications you plan to make — not a vague promise to "improve the model," but concrete, enumerated changes. Typical examples include retraining the model on new data, improving performance metrics, or expanding inputs to support a new compatible device or an additional patient subpopulation.

For each modification, the guidance expects you to characterize it clearly: whether it will be implemented automatically or manually, and whether it applies uniformly to every deployment (a global change) or is tailored to individual sites or patients. Specificity is the entire point — the FDA is authorizing these changes, so they have to be described precisely enough to be recognizable when you make them.

2. Modification Protocol

This is the "how." The Modification Protocol is the methodology you will follow to develop, validate, and implement each planned change while keeping the device safe and effective. It is the most engineering-heavy part of the plan, and it generally covers four areas:

• Data management practices — how new data is collected, curated, labeled, checked for quality and representativeness, and kept independent between training and test sets.
• Re-training practices — the procedures for retraining or updating the model, including what triggers a retrain and how the process is controlled.
• Performance evaluation protocols — the predefined tests and acceptance criteria a modified model must pass before it can be deployed, so "improved" is a measured claim rather than an assumption.
• Update procedures — how an authorized change is actually rolled out, how it is communicated to users, and how you handle and, if necessary, roll back a problematic update.

The Modification Protocol is where a PCCP stops being a document and becomes a set of promises about systems you must actually have. If your protocol says every retrain is validated against a held-out, representative test set with fixed acceptance thresholds, you need the infrastructure to do that, every time, reproducibly.

3. Impact Assessment

This is the "why it is still safe." The Impact Assessment documents the benefits and risks of each planned modification and demonstrates that your Modification Protocol adequately controls those risks. Critically, it must consider not just each change in isolation but the cumulative and collective effect of the changes — verifying that a sequence of individually reasonable updates does not add up to a device that behaves outside its cleared performance. It ties the other two components together: given what you plan to change and how, here is the evidence that safety and effectiveness are maintained throughout.

---

What You Can and Cannot Include

A PCCP is powerful, but it has firm boundaries. Understanding them early prevents you from building a regulatory strategy on changes the FDA will not pre-authorize.

• Changes must stay within the device's intended use. A PCCP lets you improve how your device performs its cleared function — it does not let you quietly expand into a new intended use or a fundamentally different device. Changes that alter the intended use still require a new marketing submission.
• Modifications must be specific and verifiable. "We will make the model better" is not a modification the FDA can authorize. "We will retrain on data from these additional sources and require the updated model to meet these sensitivity and specificity thresholds on this test set" is.
• Anything outside the plan still needs a submission. The PCCP defines an envelope. A change that falls outside it — because it was not described, or because it exceeds the protocol's bounds — goes through the normal premarket route.
• The plan must be grounded in good engineering practice. The FDA's expectations here align with Good Machine Learning Practice (GMLP) principles. A protocol that does not reflect sound data management and validation discipline will not inspire authorization.

The mental model that works: a PCCP is a pre-negotiated boundary around your model's evolution. Inside the boundary, you move at engineering speed. Cross it, and you are back to the regulator's timeline.

---

What a PCCP Demands of Your Engineering

Here is the part that regulatory-focused articles tend to underplay: a PCCP is only as good as your ability to execute it. The moment the FDA authorizes your plan, you have committed to running the systems it describes — reliably, reproducibly, and with an audit trail. That is an engineering mandate, and it should shape your architecture from the start.

• Reproducible training pipelines. Every model version must be reproducible from versioned data, code, and configuration. If you cannot reconstruct exactly how a deployed model was produced, you cannot demonstrate you followed your protocol.
• Rigorous data and model versioning. Datasets, model weights, and the boundaries between training and evaluation data all need to be versioned and traceable. This is regulatory evidence, not just good hygiene.
• Automated performance evaluation. Your acceptance criteria should be enforced by an evaluation harness that runs on every candidate model, not by a manual review that can drift. The protocol promised fixed thresholds — the pipeline has to enforce them.
• Real-world performance monitoring. You need to detect data drift, performance degradation, and subgroup disparities in production, because the case for a retrain — and the evidence that it helped — comes from monitoring.
• Controlled, reversible deployment. Authorized updates need a rollout process with the ability to communicate changes to users and roll back a bad update quickly and cleanly.

None of this is exotic — it is disciplined MLOps. But it is MLOps that must exist and function before you claim it in a plan the FDA relies on. This is why a PCCP cannot be bolted on at the end. The infrastructure your protocol describes has to be designed into the product, and the least expensive time to build it is the first time.

---

Getting a PCCP Right From the Start

A few principles separate teams that use PCCPs effectively from teams that treat them as an afterthought:

• Decide your evolution strategy before you submit. The improvements you expect to make over the next few years should inform the Description of Modifications now. Retrofitting a PCCP onto a device you have already frozen wastes its main advantage.
• Scope the envelope deliberately. Too narrow and you will be back for a submission the first time you want to improve anything meaningful. Too broad and vague and the FDA will not authorize it. The art is defining a boundary that is specific, verifiable, and genuinely useful.
• Build the protocol you can actually run. Do not promise validation and monitoring rigor your infrastructure cannot deliver. An authorized plan you cannot execute consistently is a compliance liability, not an asset.
• Engage the FDA early. Pre-submission interactions let you test your PCCP approach with the reviewers before you commit to it in a full submission — cheap insurance against a strategy the agency will not accept.

Done well, a PCCP turns FDA clearance from a wall into a runway. Your model can keep learning, your team can ship improvements on an engineering cadence, and your regulatory position stays sound — because you defined, in advance, exactly how you would change and exactly how you would prove it was still safe.

---

FAQ

Is a PCCP only for AI and machine learning devices?

PCCPs are most closely associated with AI-enabled device software functions, and the FDA's December 2024 final guidance is written specifically for them, because learning models are where the need is most acute. The broader change-control concept can apply to other device software as well, but if you are building an adaptive or regularly retrained AI model, the PCCP framework for AI-enabled functions is the one that matters to you.

Does a PCCP mean my model can update itself automatically without oversight?

Not in the unsupervised sense people sometimes imagine. A PCCP can cover automatic modifications, but only ones you described in advance and that follow an authorized Modification Protocol with predefined validation and acceptance criteria. The point is not to remove control — it is to move the control upfront, into a plan the FDA reviews, so that qualifying changes do not each need a fresh submission. Every change still passes through the protocol's checks.

What happens if I want to make a change that is not in my PCCP?

A change outside your authorized PCCP is handled the traditional way: you assess whether it significantly affects safety or effectiveness, and if it does, it requires a new marketing submission before you can deploy it. The PCCP does not remove that path — it creates a faster lane for the specific, pre-authorized changes inside your plan, while everything outside the envelope follows the normal route.

When in development should we think about a PCCP?

As early as possible — ideally while you are still designing your data and training infrastructure. The Modification Protocol commits you to specific data management, retraining, evaluation, and deployment practices, and those are architectural decisions that are cheap to make early and expensive to retrofit. Teams that treat the PCCP as a late-stage regulatory document often discover their systems cannot actually execute the plan they want to submit.

Does having a PCCP replace the need for a quality system and good ML practice?

No — it depends on them. A PCCP sits on top of your quality management system and your Good Machine Learning Practice discipline; it does not substitute for them. The FDA's willingness to authorize a plan rests on confidence that your organization can execute it reliably, which comes from a functioning quality system, sound data and validation practices, and reproducible engineering. The PCCP is the mechanism; the quality foundation is what makes it credible.

Last updated: July 2026