Datamint knowledge base

Predetermined Change Control Plans (PCCP)

How to plan for post-market model updates before your initial submission. What a PCCP contains, why the FDA created this framework, and how it enables continuous learning without resubmission.

One of the most important challenges of AI models is the discrepancy between lab results and real-world results. There ar Let me set up a frustrating scenario you’ve probably imagined. You’ve launched your diagnostic AI model. It’s been approved by FDA. Your team has collected six months of real-world data. You retrain the model on this new data, performance improves by 2% across all metrics, and you want to push the update to your users.

Without a Predetermined Change Control Plan, here’s what happens: that improvement is a significant modification of an approved device. You need to file a 510(k) submission. You wait two to four months for FDA review. Your competitors have already released their updates. Your model keeps running on slightly stale training data. Meanwhile, your team spends 200 hours on regulatory documentation instead of, you know, improving the model further.

With an approved PCCP, you update the model, run your validation checks, document everything in your quality management system, and ship it within weeks.

This is why PCCP is one of the most strategically important concepts in medical device AI development.

The Frozen Algorithm Problem

PCCP was an important addition to regulatory thinking for AI medical devices. Medical device software is governed by 21 CFR Part 820 and FDA’s software validation guidance. Once you submit and get clearance, your software is officially “approved.” Any significant change to that software is technically a modification of the approved device. Modifications require new submissions.

But machine learning models are inherently dynamic. They improve with more data, and they generalize better when you retrain on broader populations. A model trained on 2,000 images performs differently (often better) than the same model trained on 10,000 images. Furthermore, being released into the real world often reveals weaknesses in your training set that need to be rectified with targeted additions.

Prior to PCCP, companies were stuck. They could either (1) freeze the model and accept that it would gradually become less competitive, or (2) constantly chase 510(k) submissions for incremental improvements, which is expensive and slow. Neither option was particularly appealing.

PCCP solves this by essentially asking: instead of telling us about each change after the fact, why don’t you tell us in advance what kinds of changes you plan to make? If we agree that those changes are safe and appropriate, you can implement them according to your pre-specified plan without coming back for approval every time.

What FDA Expects in a PCCP

FDA’s 2024 guidance on modifications to AI/ML-based software and Health Canada’s parallel 2025 MLMD guidance both treat PCCP as a foundational element. A defensible PCCP needs four components:

1. Description of Anticipated Modifications

You need to explicitly name the kinds of changes you expect to make. Examples include:

  • Retraining on new data collected from clinical use
  • Expanding the device to support additional input modalities (adding a new imaging protocol, for instance)
  • Improving performance on specific subgroups (retraining with intentional focus on data from women or older patients)
  • Adding new output classes (your model currently outputs “normal” or “abnormal”, but you plan to expand to “normal”, “borderline”, “abnormal”, and “refer for specialist review”)
  • Adjusting model confidence thresholds based on clinical feedback

The word anticipated means something to the FDA. You’re not committing to everything, but you’re being specific about what you foresee. Vague PCCPs (“we might improve performance through various means”) don’t work, you have to be somewhat specific about the changes you foresee.

2. Methodology for Implementing Changes

A successful PCCP will also describe how you will actually do these retrainings and modifications. Your PCCP should specify:

  • Data requirements: how much new data, what type, from which patient populations, what time period
  • Training procedure: model architecture (will you freeze some layers and retrain others, or start fresh?), hyperparameters, any domain adaptation techniques
  • Performance thresholds: what metrics matter, and what are your pass/fail criteria? If retraining improves sensitivity by 1% but drops specificity by 0.5%, do you accept that? Your PCCP answers this.
  • Validation approach: will you test on a held-out test set, on subgroups, against a clinical reference standard?

This is where a lot of teams get a bit squirmy, since they worry that being too specific locks them in. They’re not wrong, it does kind of lock you in, but in return you get predictability and protection. If you say “we’ll retrain when we’ve collected 5,000 new images, we’ll use the same architecture, and we’ll require sensitivity and specificity to each stay within 1% of the approved version”, you’ve created a clear, defensible process that you can follow without ambiguity or regulatory risk.

3. Performance Expectations and Acceptance Criteria

These are the guardrails that the regulators want to see to convince themselves you’re not going to change-control yourself into a device that never would have received clearance in the first place. You’re saying: we will make changes as described above, and we commit to these performance standards:

  • Sensitivity no lower than X%
  • Specificity no lower than Y%
  • No degradation in performance for subgroup Z
  • Positive predictive value above threshold W

(These are obviously just examples, the specific metrics will depend on the type of model you’ve got.) The acceptance criteria protect patients. They also protect you, because they’re transparent and predictable. FDA reviewers know exactly what you’re aiming for.

4. Impact Assessment Protocol

When you implement a change, what do you do to make sure nothing broke? Your PCCP should describe:

  • How you’ll assess whether the change affected other parts of the system (does improving accuracy on one output class degrade accuracy on another?)
  • How you’ll monitor real-world performance post-deployment
  • Thresholds for when you’d roll back a change or file a new submission (things went wrong and we can’t fix it within our agreed framework)
  • Documentation and reporting: what records you’ll maintain, and how often you’ll review them

Where to Include Your PCCP

The best time to include a PCCP is in your initial submission. This is because it’s easier to get agreement upfront than to add one retrospectively. If you submit your 510(k) or PMA with a well-thought-out PCCP, reviewers see that you’re being thoughtful about governance and future maintenance. They’re more likely to accept it than if you come back a year later asking for permission to retrain your model.

Include the PCCP as part of your design history file and software documentation. Make it clear and specific. Avoid language like “we may from time to time improve the model” or “we anticipate various enhancements.” FDA reviewers read hundreds of these and they can spot a placeholder a mile away.

A Pre-Submission Strategy: Q-Sub

Before you formally submit your PCCP to FDA, use the Q-Submission process to get their feedback (if you’ve been reading these articles in order you might see a theme emerging here). This is a non-binding meeting where you present your planned PCCP and ask: “Does this look reasonable to you?”

The Q-sub takes a bit of time to prepare for, but the payoff is substantial. You can identify misunderstandings or gaps before you spend hundreds of hours writing your final submission. Your Q-Sub meeting notes become part of your regulatory record, and if you follow the guidance FDA gives you, you have strong documentation that your PCCP was reviewed and approved.

For example, let’s say you want a PCCP that covers retraining every time you accumulate 1,000 new annotated images. You Q-Sub this and FDA says, “We think 1,000 images is too small a dataset; we’d want to see 3,000 minimum to ensure statistical stability.” Now you know. You adjust your PCCP before submission, saving loads of time and avoiding multiple migranes due to deficiency letters.

Aligning PCCP with Your Quality Management System

A PCCP is only useful if it’s integrated into your actual QMS workflow.

  • Your development team has documented procedures for when a PCCP-covered change is triggered (someone needs to formally declare “we’re executing planned modification type B”)
  • Your change control board reviews the modification against the PCCP criteria
  • Your validation team has a checklist tied to your PCCP acceptance criteria
  • Your documentation system captures all the records: new training data, retraining logs, validation results, sign-offs
  • Your post-market surveillance plan monitors deployed changes for any unexpected issues

Many teams write an excellent PCCP, then implement changes in an ad hoc way that doesn’t actually follow it. When (not if!) FDA audits, the misalignment becomes obvious (“Your PCCP says you’ll validate on a held-out test set, but your records show you retrained and deployed without any held-out validation”). This is a credibility (and company) killer.

Key Takeaways

  • A PCCP allows you to make pre-approved changes to your model without new FDA submissions, solving the “frozen algorithm” problem
  • Your PCCP must specify: what modifications you anticipate, how you’ll implement them, what performance standards you’ll maintain, and how you’ll assess impact
  • Include your PCCP in your initial submission, not later
  • Use Q-Sub to get FDA feedback on your draft PCCP before formal submission
  • Integrate your PCCP into your QMS so changes are actually implemented according to the pre-specified plan
  • A disciplined PCCP is a competitive advantage in regulated AI (your model stays current, competitors are stuck with old 510(k) cycles)

This article is part of the AI in Clinical Research Knowledge Base. For regulatory guidance, consult FDA’s Software Validation guidance and 2024 AI/ML modifications guidance, or Health Canada’s 2025 MLMD guidance.