FDA PCCP: Updating AI Medical Devices Post-Clearance

AI models improve with more data and retraining, but a cleared medical device's behaviour is supposed to be fixed at the point of clearance. FDA's predetermined change control plan is the mechanism that reconciles these two facts, and it's worth understanding well before you submit, not after your first planned model update is ready to ship. It belongs inside the full route to FDA clearance, planned alongside the original submission.

In short: A Predetermined Change Control Plan (PCCP) is FDA's mechanism for AI-enabled devices to implement pre-specified model changes, retraining, performance tuning, input expansions, without a new submission. The PCCP is reviewed and authorized as part of the original clearance, and only changes within its bounds are covered.

The problem PCCPs solve

Traditional FDA device regulation assumes a fixed product: you submit evidence for a specific, static device configuration, FDA reviews that configuration, and any subsequent change significant enough to affect safety or effectiveness requires a new submission or supplement before it can ship. This model works reasonably well for hardware and for software that changes infrequently. It works poorly for AI-enabled devices whose underlying value proposition often depends on continuous improvement: better performance as more data becomes available, adaptation to new patient populations, refinement based on real-world performance.

Without a mechanism to plan for this, AI device manufacturers faced an uncomfortable choice: freeze the model at clearance and accept the product would degrade in relative usefulness over time, or plan for frequent new submissions to ship legitimate improvements, absorbing significant regulatory cost and delay for changes that, in many cases, were genuinely anticipated and low-risk. The PCCP framework gives manufacturers a third option: define the anticipated changes and how they'll be controlled and verified, in advance, and get that plan authorised alongside the original clearance, so qualifying changes within its bounds don't require a new submission each time. This isn't merely a guidance construct: PCCPs have an explicit statutory basis in section 515C of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360e-4), added by the Food and Drug Omnibus Reform Act of 2022 (FDORA), which FDA's guidance — building on years of pilot programme experience — then operationalises. And although this article defaults to "clearance" language, a PCCP is not a 510(k)-only tool: it's available whichever route your device takes to market — 510(k) clearance, De Novo authorization, or PMA approval.

It's worth being precise about which PCCP guidance applies where. FDA's final guidance specifically for AI-enabled device software functions — the guidance's own defined term is "AI-enabled device software functions" (AI-DSF); "AI/ML" is the common informal shorthand this article keeps for readability — was issued 4 December 2024, and that's the document on firm regulatory footing for the AI/ML use case this article is about. FDA has separately proposed a broader PCCP framework covering non-AI device changes generally, but that guidance remains in draft form, dated August 2024, and hasn't been finalised. If you're scoping a PCCP for an AI-enabled device, the December 2024 final guidance is your primary reference; the draft general-device guidance is relevant mainly as a signal of where FDA's thinking on change control is heading for products outside the AI/ML category.

The three parts of a PCCP

FDA's framework structures a PCCP around three connected components.

The Description of Modifications specifies exactly what changes are anticipated: which aspects of the device, the model's performance envelope, its input data types, its intended population, may change, and the range or nature of those changes. This needs to be specific enough that FDA can evaluate the change in advance, not an open-ended commitment to "improve the model over time."

To make that concrete: an illustrative (not real) example of a bounded Description of Modifications for a diabetic retinopathy screening algorithm might read something like this.

Illustrative example only, not an actual submission excerpt: "This PCCP covers periodic retraining of the retinal image classification model on newly collected, labelled fundus images from the same imaging device models and patient population described in the original clinical validation. Anticipated modifications are limited to: (1) retraining on an expanded dataset that grows the training set by no more than 3x its original size within the plan's two-year horizon, and (2) recalibration of the model's decision threshold within a pre-specified sensitivity and specificity envelope. This PCCP does not cover extension to paediatric patients, to imaging devices from manufacturers not included in the original validation, or to detection of conditions beyond diabetic retinopathy."

Notice what that sample does. It names the specific mechanism of change (retraining on new data of a defined type), bounds the magnitude (no more than 3x growth, a defined performance envelope), and explicitly excludes the changes that would take the device outside its original clearance. A Description of Modifications that instead said "the model will be improved periodically as new data becomes available" gives FDA nothing concrete to evaluate, and that's the pattern reviewers push back on.

The Modification Protocol describes how you will implement and control each anticipated change: the data management practices governing retraining data, the re-training and re-validation methodology, and the specific performance criteria a modified model must meet before it ships. This is where the plan does most of its regulatory work, since it's effectively pre-authorising a verification process rather than a specific future model, and FDA needs confidence that process will reliably catch a problematic update before it reaches patients. Continuing the example above, the Modification Protocol would specify exactly how the expanded training data is sourced and labelled, what validation dataset the retrained model is tested against, and the minimum sensitivity and specificity thresholds it must clear before release, along with who signs off internally.

The Impact Assessment analyses the benefits and risks of the anticipated modifications and the modification protocol itself, including how the plan addresses risks specific to the anticipated changes, and how the device's labelling will communicate its adaptive nature to users. For the retinopathy example, this would cover the risk that an expanded training dataset skews toward certain imaging conditions or demographics not well represented in the original validation, and what specific check in the Modification Protocol catches that before a retrained model ships.

What FDA will and won't accept inside a plan

FDA's guidance and public device authorisations to date give a reasonably clear sense of what falls inside a workable PCCP: performance improvements from retraining on an expanded but clearly bounded dataset; recalibration or fine-tuning within a defined performance envelope; and input specification expansions, such as compatibility with an additional device or data source, where the underlying clinical claim doesn't change.

What tends to fall outside what a PCCP can cover: a fundamentally new intended use or clinical claim, expansion to a patient population meaningfully different from the one originally studied, or a change to the core algorithmic approach itself rather than a refinement within the existing one. In the retinopathy example, adding paediatric patients or a new disease target would fall outside the plan for exactly this reason, which is why the sample text excludes them explicitly rather than leaving the boundary implicit.

The dividing line FDA applies is broadly whether the change is a refinement within the original clearance's clinical claims, or a change substantial enough that it raises new questions the original clearance didn't evaluate.

Writing the PCCP alongside the original submission, not after

The practical, and frequently underappreciated, implication of this framework is that a PCCP is not something to add after your device is cleared and you discover you want to update the model. It's authorised as part of the original submission, reviewed alongside your device's initial safety and effectiveness evidence, which means the modification protocol needs to be designed, and its verification methodology validated, before you have submitted at all.

Teams that treat PCCP planning as a late addition to an otherwise-finished submission tend to write overly broad or underspecified plans that FDA is unlikely to authorise as written, generating review cycles that a more deliberately scoped plan, developed alongside the core submission from the start, would have avoided. The more effective pattern is to ask, during initial product and evidence planning, not just "what does our device do today" but "what do we already know we will want to change in the first one to two years," and build the modification protocol around those specific, foreseeable changes rather than a generic commitment to future improvement.

A useful gut check while drafting: if you can't write a specific illustrative sentence like the retinopathy example above, describing a concrete, bounded change your device will actually make, you probably aren't ready to submit that piece of the PCCP yet. Vague plans get vague FDA feedback, usually in the form of a request for additional information that costs weeks you didn't need to lose. If you want FDA's read before locking anything in, a Q-Submission (Pre-Sub) is the natural vehicle for testing a draft PCCP's scope: early written feedback on whether your proposed bounds look reasonable is exactly the review-cycle-saving lever this section is describing.

PCCP vs EU thinking on AI change management

The EU AI Act doesn't yet have a direct equivalent to the PCCP mechanism, though the underlying problem, how to manage anticipated AI model change without triggering a full re-assessment for every update, is one both frameworks eventually have to solve. When Medical Device AI Becomes High-Risk covers the current EU change-management expectations, which currently lean more heavily on the manufacturer's existing MDR change-notification framework than on a dedicated pre-authorised change plan.

For agentic and continuously-updating AI systems specifically, where the underlying model itself may be updated by a third-party provider outside the manufacturer's direct control, Agentic AI Governance in Healthcare covers why the PCCP's core idea, defining bounds in advance, is a useful pattern to borrow even in contexts no regulator has yet formally extended it to. The retinopathy example above is a relatively clean case because the manufacturer controls the entire retraining pipeline. Agentic systems built on third-party foundation models don't have that luxury, and that gap is exactly where the agentic AI governance piece picks up.

Practical scoping advice

Scope your PCCP around changes you can specify with real precision now, not aspirational future capability. A modification protocol that commits to a specific, verifiable performance threshold for a retrained model is authorisable; one that commits to "continued improvement" without defined bounds is not.

Build the verification methodology in your protocol to be genuinely executable by your team on an ongoing basis, since FDA will hold you to running it exactly as described for every change you ship under the plan, not just for the first one. If your Modification Protocol specifies a validation dataset of a certain size and composition, your team needs the actual operational capacity to assemble that dataset every time you invoke the plan, not just once during development.

Treat your PCCP as itself subject to future revision: if your product roadmap changes in ways your original plan didn't anticipate, that likely requires a new submission or a formal PCCP amendment, not a stretch interpretation of your existing plan's bounds. A team that quietly expands what counts as "within the plan" because a genuinely new capability is commercially urgent is creating exactly the kind of unreviewed change the framework exists to prevent, and it's the sort of gap an FDA inspection or a post-market issue is likely to surface.

How this plays out over the life of a device

It helps to walk through what invoking a PCCP actually looks like in practice, once it's authorised, rather than treating it as an abstract regulatory instrument. Say the retinopathy screening device from the earlier example has been on the market for a year. The manufacturer has been collecting newly labelled fundus images from clinical sites as part of routine use, consistent with the data management practices described in the Modification Protocol. At the point they've accumulated enough new data to justify a retraining cycle, and within the 3x dataset growth bound the PCCP specifies, they retrain the model exactly as the protocol describes: same validation dataset, same minimum sensitivity and specificity thresholds, same internal sign-off process.

If the retrained model clears those pre-specified thresholds, it ships without a new FDA submission, because this exact scenario is what the authorised PCCP anticipated and bounded. The manufacturer documents the retraining run, the validation results, and the sign-off, and keeps those records available for inspection. If the retrained model doesn't clear the thresholds, it doesn't ship, and the manufacturer either retrains again with adjusted data or investigates why performance didn't hold, but this failure stays internal to their quality system rather than becoming an FDA reportable event on its own, provided the original device already on the market continues performing as cleared.

Compare that to a manufacturer without a PCCP who wants to make the same retraining update. They'd need to determine whether the change is significant enough to require a new 510(k) or PMA supplement, likely conclude that it is, since retraining changes model weights that were part of the original evidence base, and then prepare and submit that filing before shipping the update. The PCCP doesn't eliminate the underlying engineering or validation work. It eliminates the repeated submission-and-review cycle for changes FDA has already agreed, in advance, are properly controlled.

Common mistakes worth naming directly

A few patterns show up repeatedly in early PCCP planning conversations. The first is treating the PCCP as a formality to satisfy near the end of preparing a submission, bolted on after the core clinical and technical sections are finished. This produces exactly the vague, underspecified plans FDA pushes back on, since a rushed Description of Modifications tends to default to broad, aspirational language instead of the specific bounds a reviewer needs.

The second is scoping the plan too broadly in an attempt to future-proof it against every change the team can imagine wanting eventually. A PCCP that tries to cover a wide range of hypothetical future capabilities, rather than the specific changes the team can already describe with precision, is harder to get authorised and, even if authorised, harder to actually operate faithfully, since the Modification Protocol has to specify a real verification process for everything the Description of Modifications covers.

The third is underestimating the ongoing operational burden the plan creates. Authoring a PCCP is not the end of the work; running the Modification Protocol correctly every time the plan is invoked is an ongoing quality system obligation — one that, since 2 February 2026, lives inside FDA's QMSR (21 CFR Part 820, incorporating ISO 13485:2016 by reference) rather than the old QSR — and a team that scoped a verification process it can't realistically execute on a recurring basis has created a compliance gap it will discover the next time it tries to ship a change under the plan.

Frequently asked questions

Does a PCCP mean we never need another FDA submission for this device? No. It means changes within the plan's specified bounds don't require a new submission. A change outside those bounds, a new clinical claim, a substantially different population, a different core algorithmic approach, still requires its own submission or supplement.

Can we add a PCCP to a device we already have cleared without one? Generally this requires a new submission or supplement establishing the plan, since the original clearance didn't evaluate one. It's not something FDA will retroactively authorise onto an existing clearance without its own review.

Who verifies that a change we ship actually stayed within our PCCP's bounds? You do, as the manufacturer, following the modification protocol's specified verification methodology, with records FDA can inspect. This is a significant ongoing compliance obligation, not a one-time authorisation you can set and forget.

Does the EU have anything equivalent to a PCCP? Not as a distinct, dedicated mechanism at this time. EU AI-enabled medical device changes are currently managed through MDR's existing significant-change and quality management system change-control processes, layered with the AI Act's own risk management and monitoring obligations once those apply.

Is a PCCP required for every AI-enabled device, or optional? Optional. A device without a PCCP is simply held to the standard change-management expectations, meaning any change significant enough to affect safety or effectiveness needs its own submission or supplement. A PCCP is a tool for devices where the manufacturer wants to plan for specific anticipated changes in advance.

Is the PCCP guidance final, or could the requirements still shift? For AI/ML-enabled device software specifically, FDA's guidance is final, issued 4 December 2024, and that's the version governing how AI/ML PCCPs are reviewed today. Separately, FDA has draft guidance from August 2024 proposing a broader PCCP framework for device changes generally, not specific to AI/ML. That draft hasn't been finalised, so if your device sits outside the AI/ML category, treat that framework as directional rather than settled.

How detailed does the Description of Modifications actually need to be? Specific enough that a reviewer could tell, from reading it alone, exactly what would and wouldn't be covered if you invoked the plan. The illustrative example earlier in this guide, bounding a retraining dataset's growth and a recalibration envelope while explicitly excluding population and disease-target expansion, is closer to the right level of specificity than a general statement about ongoing model improvement.

What happens if we invoke our PCCP and the retrained model doesn't meet the pre-specified performance thresholds? The update doesn't ship. This stays an internal quality system matter, not an automatic FDA reportable event, provided the version already on the market keeps performing as originally cleared. Your Modification Protocol should specify what happens next: whether the team retrains with adjusted data, investigates the shortfall, or shelves that particular update, since a PCCP that only describes the success path isn't fully specified.

Does a PCCP need to specify an exact retraining schedule, like every six months? Not necessarily a fixed calendar, but it does need clear triggering conditions for when a modification under the plan would occur, whether that's a data volume threshold, a scheduled cadence, or a performance-monitoring trigger. An open-ended "whenever we feel like it" isn't specific enough for FDA to evaluate what it's authorising, but a rigid calendar isn't required either if the plan clearly defines what has to be true before a change is invoked.

A structured conversation about scoping a PCCP for your specific device and anticipated update cadence is the right next step if you're planning an initial FDA submission for an AI-enabled device. Getting the modification protocol right at this stage saves real review time later.

---

Where next: 510(k) vs De Novo vs PMA: Which FDA Pathway · Agentic AI Governance in Healthcare · Does My Health AI Need FDA Clearance? · QMSR: What Replaced FDA's Quality System Reg

Talk through scoping a PCCP for your device. Book an expert conversation →