PCCP for AI SaMD: FDA Predetermined Change Control Plans
By Tammo Mueller

AI models improve. Training data grows, performance gaps get identified, new scanner types enter the field. For most software, shipping an update is a deployment pipeline away. For FDA-cleared AI SaMD, every model update is a potential regulatory event. Without a plan, each retrained model could require a new 510(k) submission, with the associated review fees, timeline, and evidence burden. A device that takes six months to clear and twelve months to retrain faces a regulatory bottleneck that no engineering effort can solve.
The FDA's Predetermined Change Control Plan (PCCP) framework addresses this directly. A PCCP is documentation submitted alongside your initial marketing submission that pre-defines what modifications you will make to your AI device, how you will validate them, and how you will assess their impact. If the FDA authorizes the PCCP, those pre-specified modifications can be implemented without a new marketing submission.
The concept is not new. The FDA's 2019 discussion paper introduced "SPS/ACP" (Algorithm Change Protocol) as an early framework for managing AI model evolution. ContourCompanion's clearance included an Algorithm Change Protocol that pre-defined how the model could be retrained on expanded datasets without filing a new 510(k). The final PCCP guidance, published in December 2024, formalizes and significantly expands that framework. It replaces the April 2023 draft, broadens scope from ML to all AI, and gives the structure statutory backing. Most teams we talk to understand the concept. The hard part is scoping a PCCP that the FDA will actually authorize.
What a PCCP Is (and What It Is Not)
A Predetermined Change Control Plan is a section of a marketing submission (510(k), De Novo, or PMA) that describes anticipated modifications to an AI-enabled device software function and the methodology for implementing them safely. The statutory authority comes from Section 515C of the FD&C Act, added by the Food and Drug Omnibus Reform Act (FDORA) in December 2022.
Three things a PCCP is not:
It is not a blanket authorization for unlimited changes. The FDA is explicit: a PCCP should include "only a limited number of modifications that are specific, can be verified and validated, and are described in sufficient detail." Vague language like "general algorithm improvements" will not survive review.
It is not a substitute for a new submission when the intended use changes. Modifications that alter the device's intended use or indications for use fall outside PCCP scope. If your autocontouring SaMD is cleared for thoracic structures and you want to add abdominal organs, that is a new intended use, not a PCCP modification.
It is not available for Special 510(k) submissions. The guidance applies to standard 510(k), De Novo, and PMA pathways only.
A key limitation worth noting: a modified device under an authorized PCCP cannot serve as a predicate device for another manufacturer's 510(k) submission, per Section 515C(c). Your PCCP-modified device is still your device, but it cannot anchor someone else's substantial equivalence argument.
The December 2024 Final Guidance: What Changed
The final guidance made several changes from the April 2023 draft that affect how teams structure their PCCPs:
Scope expanded from ML to all AI. The draft used "ML-DSF" (Machine Learning-enabled Device Software Functions). The final guidance uses "AI-DSF" (AI-Enabled Device Software Functions), covering all AI technologies, not just machine learning. Rule-based AI systems, expert systems, and hybrid approaches are all in scope.
Data categories expanded. The draft referenced "training and testing" data. The final guidance uses "training, tuning, and testing," aligning with standard machine learning practice where a tuning (validation) dataset is held out separately from the final test set.
Population-specific requirements added. The final guidance recommends that PCCPs consider population characteristics: ethnicity, gender, age, disease severity. If your modification protocol includes retraining on new data, you need to address how representativeness will be maintained or improved across these dimensions.
Automatic implementation confirmed. The final guidance explicitly states that automatic implementation of modifications is acceptable for AI-DSFs, provided the modification protocol is followed. You do not need manual review of every update if the PCCP protocol is designed to be fully automated.
Labeling updates required. Devices with authorized PCCPs must update their labeling and public-facing documents as modifications are implemented. The labeling must state that the device has an authorized PCCP.
As of early 2025, 67 devices had FDA-authorized PCCPs, with 59 authorized in the prior two years. Adoption is still low: only about 41 out of roughly 3,000 510(k) submissions in 2024 included PCCPs. The framework is new, the guidance was in draft until December 2024, and most manufacturers are still figuring out how to scope their plans. That adoption gap is an advantage for teams that get their PCCPs right early.
The Three Required PCCP Components
Every PCCP must contain three components. The guidance is clear about what each must include, and the specificity bar is high.
1. Description of Modifications
ContourCompanion's Algorithm Change Protocol, the precursor to what the December 2024 guidance now calls a PCCP, covered three categories of modifications: retraining the model on expanded imaging datasets to improve performance on the cleared anatomical structures, supporting additional imaging equipment within the same modality types, and quantitative performance improvements above the cleared baseline. Each modification was described with enough specificity that the validation protocol could map directly to it. Expanding to new anatomical regions was explicitly excluded because that would change the intended use. The structure maps directly to what the final guidance now requires.
The tension is real. Scope the description too narrowly, and the PCCP covers only trivial changes that barely justify the effort. Scope it too broadly, and the FDA rejects it for lacking specificity. The guidance provides examples of what belongs in a PCCP:
- Model retraining on new or broader data of the same signal type
- New input sources of the same signal type (e.g., supporting additional scanner models or software versions)
- Subpopulation expansion within the originally indicated population (e.g., retraining on a larger dataset for a demographic subset that was underrepresented in the original training data)
- Performance specification changes (quantitative improvements to accuracy metrics)
And what does not:
- Changes that alter the intended use or indications for use
- Modifications that are "overly complex, lack specificity, or lack sufficient testing methods"
- Any change that deviates from the authorized plan
The practical test: every modification in the description should have a corresponding entry in the modification protocol. If you cannot write the validation test for a modification, it should not be in the PCCP.
2. Modification Protocol
The modification protocol is the operational core of the PCCP. It describes how each modification will be developed, validated, and deployed. Four areas must be covered:
Data management practices. How new training data will be collected, processed, stored, and quality-controlled. This includes bias mitigation strategies. The final guidance added a requirement for "descriptive statistics: covariate range, mean, median for each dataset and comparison to intended use population." You need to show that the retraining data is representative, and you need to define how you will verify representativeness before each retraining cycle.
Retraining practices. What may change in the model (weights, hyperparameters, architecture elements), what triggers a retraining cycle (new data availability, performance drift detection, fixed cadence), and how overfitting will be controlled. The triggers matter because they define the cadence of PCCP-covered updates. A trigger of "whenever the team feels like it" will not pass review. A trigger of "when the performance monitoring system detects a statistically significant drop in Dice coefficient below the cleared threshold across a rolling 90-day window" is specific and auditable.
Performance evaluation. The specific test methods, acceptance criteria, and statistical methods for each modification type. This is where the PCCP connects to the algorithm validation framework. The acceptance criteria must be pre-defined with quantitative thresholds, not evaluated post-hoc. If the cleared model achieved a mean Dice coefficient above a defined threshold, the PCCP acceptance criterion should require the retrained model to meet or exceed that threshold on an independent test set with equivalent demographic composition.
Update procedures. Deployment mechanics, user communication, labeling updates, and rollback criteria. What constitutes an "unresolvable" failure that prevents implementation? If the retrained model fails acceptance testing, the protocol must define what happens next: root cause analysis, retraining with modified data, or escalation to a new regulatory submission.
ContourCompanion's change protocol was structured as a decision tree. Each modification type from the description mapped to a specific validation path. Retraining on expanded data required a full performance evaluation against the same test methodology used in the original clearance. Supporting a new scanner model required a targeted evaluation on data from that scanner type, with acceptance criteria defined relative to the existing performance baseline. Every path terminated in either "deploy under the change protocol" or "escalate to new submission." The December 2024 PCCP guidance formalizes exactly this pattern.
3. Impact Assessment
The impact assessment evaluates the potential risks and benefits of each planned modification, both individually and in combination. It requires:
- Risk-benefit analysis for each modification type, mapped to the device's risk management file
- Analysis showing updates do not compromise performance or patient safety, with quantitative criteria
- Post-market surveillance strategies specific to PCCP-covered modifications
- Root cause analysis processes for failures detected post-deployment
The "in combination" requirement is worth emphasizing. If your PCCP covers both retraining on new data and supporting new scanner types, the impact assessment must address what happens when both modifications occur together. A model retrained on expanded data and simultaneously validated on a new scanner type introduces compounded variability. The impact assessment must show that your testing methodology accounts for this.
ContourCompanion's change protocol included the same analysis. Each modification type mapped back to the existing risk management file. Retraining on expanded data introduced the risk that new training examples could degrade performance on previously well-performing structures. The mitigation: acceptance criteria required the retrained model to meet or exceed the cleared baseline on every anatomical structure individually, not just in aggregate. A model that improved head-and-neck performance by 3% but degraded thoracic performance by 1% would still need to pass every per-structure threshold. The "in combination" analysis addressed scenarios where retraining coincided with new scanner support, requiring the combined evaluation to use test data from the new scanner type with the retrained weights, not separate evaluations that could mask interaction effects.
The Software Modification Reporting Framework
Not every software change requires a new 510(k), even without a PCCP. The FDA's existing software modification reporting framework provides a decision tree for determining when a change triggers a new submission. The PCCP sits within this broader framework:
- Does the change affect the intended use? If yes, new submission required regardless of PCCP.
- Could the change affect safety or effectiveness? If no, document it in your quality system, no submission needed.
- Is the change covered by an authorized PCCP? If yes, implement per the modification protocol, no new submission.
- Is the change not covered by a PCCP? Follow the standard software modification decision tree. Depending on the risk assessment, you may need a new 510(k), a letter-to-file, or a design history file update.
The PCCP does not replace this framework. It adds a third option between "no submission needed" and "new submission required." For AI SaMD that will undergo periodic model updates, this middle path is the difference between a product that can evolve and one that is frozen at the clearance version.
Scoping Your PCCP: The Strategic Tradeoff
The hardest part of a PCCP is not writing the three components. It is deciding what to include.
Every modification you add to the PCCP increases the documentation burden, the validation complexity, and the review surface for FDA evaluators. A PCCP with twelve modification types and eight trigger conditions is a PCCP that will receive extensive review scrutiny and may come back with additional information requests that delay your entire submission.
At the same time, a PCCP that covers only "minor retraining on identical data distributions" barely justifies itself. The point of a PCCP is to enable meaningful model evolution without regulatory friction.
The approach that worked for us: start with the modifications you know you will make within the first two years post-clearance. ContourCompanion's change protocol covered expanded training data from additional clinical sites (addressing representativeness gaps from the initial dataset), support for imaging equipment that entered the market after the training data was collected, and targeted performance improvements on anatomical structures where the initial model had the widest performance variance.
Modifications we considered but excluded: entirely new algorithmic architectures (too broad, insufficient specificity for validation protocols), expansion to new anatomical regions (changes intended use), and real-time learning from clinical feedback (no PCCP can authorize continuous learning, per the current guidance framework).
The FDA recommends engaging early through a Pre-Submission (Q-Sub) to discuss PCCP scope. This is strongly advisable. A Q-Sub lets you test your PCCP scope with the review division before committing it to a formal submission. The feedback directly reduces the risk of additional information requests during review.
PCCP and Post-Market Surveillance
An authorized PCCP does not reduce post-market surveillance obligations. It increases them. Every modification implemented under a PCCP must be:
- Documented in the quality system with full traceability
- Version-controlled (each modification creates a new traceable device version)
- Monitored for post-deployment performance against the acceptance criteria
- Reported if the modification reveals safety or effectiveness concerns
The post-market monitoring infrastructure matters more for a PCCP device than for a locked device. A locked device performs the same way every day. A PCCP device changes, and each change introduces the possibility of performance degradation that was not captured by the pre-deployment validation. Your HIPAA-compliant cloud architecture needs to include performance telemetry that can detect drift post-update, not just during the update validation cycle.
The January 2025 draft guidance on AI-DSF Lifecycle Management reinforces this. At 67 pages covering 13 chapters, it is the most detailed AI device lifecycle document the FDA has published. It does not replace the PCCP final guidance, but it ties PCCP monitoring into the broader Total Product Lifecycle (TPLC) framework. Two points matter for PCCP planning: the draft recommends monitoring deployed AI models for performance degradation, data drift, and distributional shift, which directly feeds the retraining triggers defined in a PCCP modification protocol. And it recommends additional submission documentation (data management practices, model architecture specs, transparency) that will raise the bar for PCCP description and protocol specificity. Design your monitoring infrastructure with PCCP reporting in mind from the start, even if the initial clearance uses a locked algorithm.
Frequently Asked Questions
What is a PCCP in FDA regulatory terms?
A Predetermined Change Control Plan is documentation submitted as part of a marketing submission (510(k), De Novo, or PMA) that pre-defines specific modifications a manufacturer plans to make to an AI-enabled device and the methodology for validating and implementing those modifications. The statutory authority is Section 515C of the FD&C Act, added by FDORA in 2022. If the FDA authorizes the PCCP, those modifications can be implemented without filing a new marketing submission, provided the manufacturer follows the pre-specified protocol exactly.
Can a PCCP authorize changes to a device's intended use?
Generally, no. Modifications that alter the intended use or indications for use fall outside PCCP scope and require a new regulatory submission. The final guidance notes that changes to indications for use "may be considered" if manufacturers engage via Q-Submission first, but this is the exception, not the rule. If you need to expand your device's intended use, plan for a supplemental or new submission.
How many devices currently have FDA-authorized PCCPs?
As of early 2025, 67 devices had authorized PCCPs, with 59 authorized in the prior two years. Only about 41 out of approximately 3,000 510(k) submissions in 2024 included PCCPs, roughly 1.3%. Adoption is growing but still rare. The framework is new, and most manufacturers are still developing the internal processes and infrastructure needed to support a PCCP.
Does a PCCP replace post-market surveillance?
No. A PCCP complements post-market surveillance. Every modification implemented under a PCCP must be documented, version-controlled, and monitored. The post-market surveillance plan should include specific provisions for monitoring device performance after PCCP-covered modifications are deployed.
References
- FDA PCCP Final Guidance for AI-Enabled Device Software Functions (December 2024)
- FDA PCCP Guidance PDF
- FDORA Section 515C: Statutory Authority for PCCPs
- FDA AI-DSF Lifecycle Management Draft Guidance (January 2025)
- FDA Software Modification Reporting Guidance
- FDA Pre-Submission (Q-Sub) Program
- PCCP Adoption Statistics (npj Digital Medicine, 2025)
- Gardner Law: Streamlining Device Changes with PCCPs
- King & Spalding: FDA Publishes Final PCCP Guidance (December 2024)
- International PCCP Guiding Principles (FDA/Health Canada/MHRA, October 2023)
- FDA AI/ML SaMD Discussion Paper (April 2019)
SaMD Engineering
Part 10 of 10
- 1.What Is SaMD? Software as a Medical Device Explained
- 2.FDA Pathways for SaMD: 510(k) vs De Novo vs PMA
- 3.IEC 62304 in Practice: Medical Device Software Without the Waterfall
- 4.ISO 14971 Risk Management for SaMD: What FDA Reviewers Read
- 5.HIPAA Compliant AWS Architecture for Medical Device Software
- 6.Infrastructure as Code for Medical Devices: IQ OQ PQ with AWS CDK
- 7.Medical Device Cybersecurity: FDA Guidance, SBOMs, and Threat Modeling
- 8.Design Controls for Medical Devices: 21 CFR 820.30 in Practice
- 9.AI/ML SaMD: FDA Artificial Intelligence Guidance in Practice
- 10.PCCP for AI SaMD: FDA Predetermined Change Control Plans