Predetermined Change Control Plans (PCCP) for AI/ML Medical Devices: An Interpretive Guide

The FDA finalized its guidance on Predetermined Change Control Plans (PCCP) for artificial intelligence and machine learning-enabled medical devices in December 2024. As of October 2026, the agency has reviewed PCCPs submitted as part of dozens of 510(k), De Novo, and PMA submissions, and patterns in both strong and deficient submissions have become visible. This guide explains what the PCCP framework requires, who it applies to, how to implement it practically, and where companies most commonly go wrong. --- ## What Is a PCCP and Why Does It Exist? A **Predetermined Change Control Plan** is a document — submitted to FDA as part of a marketing authorization — that describes modifications a manufacturer anticipates making to an AI/ML-enabled device *after* clearance or approval, along with the methods that will govern those modifications and the performance standards they must meet. The regulatory problem PCCP solves is straightforward: traditional 510(k) and PMA oversight was designed for static devices. A hardware revision or a software bug fix is a bounded change. An AI/ML model that continuously retrains on real-world data is not. Without a prospective framework for managing model drift and planned algorithmic updates, every meaningful change to an AI/ML device could theoretically require a new premarket submission — an untenable burden that would also slow down beneficial improvements. The PCCP authority is grounded in **21 CFR Part 807** (for 510(k) devices) and **21 CFR Part 814** (for PMAs), as modified by Section 3308 of the 21st Century Cures Act and further clarified by the **FD&C Act Section 515C**, added by the Consolidated Appropriations Act of 2023. The FDA guidance document — *Predetermined Change Control Plans for Artificial Intelligence-Enabled Devices: Guidance for Industry and FDA Staff* (December 2024) — is the controlling interpretive document. ### Who Does This Apply To? PCCP is relevant to any manufacturer submitting a premarket notification or application for a device that: * Incorporates an AI/ML algorithm as a device function (not merely as a manufacturing or administrative tool) * Anticipates making post-market modifications to that algorithm — whether through retraining, architecture changes, or threshold adjustments * Seeks to make those modifications without submitting a new premarket application for each change PCCP is optional, not mandatory. You can clear an AI/ML device without one. But if your device's value proposition depends on learning from post-market data, operating without a PCCP means every substantive modification triggers a **Special 510(k)** or **PMA Supplement** — an outcome most AI/ML developers cannot sustain commercially. --- ## The Three Core Components of a PCCP The FDA guidance specifies that every PCCP must contain three elements. Deficiency letters from FDA in 2025 and 2026 overwhelmingly cite incomplete treatment of at least one. ### 1. Description of Planned Modifications This section defines the scope of changes the PCCP covers. You must describe: * **What will change**: algorithm architecture, training dataset composition, preprocessing pipeline, output thresholds, or some combination * **The bounds of change**: the specific parameters within which modifications are permitted — for example, "retraining on datasets that include up to 40% data from non-US clinical sites, provided site-level performance metrics meet the criteria in Section 4" * **What will not change**: indications for use, intended patient population, and device inputs/outputs that are locked for the life of this authorization FDA expects specificity. A description that reads "the model may be retrained as new data becomes available" will generate a deficiency. A description that specifies training data volume thresholds, acceptable demographic distributions, acceptable shifts in class balance, and prohibited architecture changes will not. ### 2. Methodology for Implementing and Validating Changes This section describes *how* you will execute changes safely. It must address: * **Algorithm change protocol**: the internal process for deciding when a change is warranted, who approves it, and what documentation is generated * **Performance evaluation framework**: the test datasets, evaluation metrics, and acceptance criteria that a modified model must meet before deployment * **Reference standard**: how ground truth labels are generated and validated — a persistent weak point in submissions * **Subgroup analysis plan**: how the manufacturer will ensure the modified model does not degrade performance for protected or clinically significant subgroups (consistent with FDA's 2023 AI/ML Action Plan emphasis on algorithmic equity) * **Cybersecurity and usability considerations**: whether a model change could affect attack surface or user interaction The methodology section is where most submissions underinvest. Companies describe *what* they will measure but not *how* they will generate the data to measure it, who will adjudicate disagreements, or what happens when a model passes aggregate metrics but fails on a subgroup. ### 3. Impact Assessment The impact assessment connects the planned modifications back to the device's safety and effectiveness profile. For each category of planned change, you must explain: * Why the change is unlikely to introduce new risks not addressed by the original premarket submission * How the validation methodology in Section 2 is sufficient to detect performance degradation before deployment * Whether the change could affect the device's substantial equivalence basis (for 510(k) devices) or the performance data underlying approval (for PMAs) Think of the impact assessment as the clinical rationale for why FDA should trust your self-governance. It requires genuine risk analysis — preferably structured using ISO 14971 risk management methodology, which FDA explicitly encourages — not boilerplate assurances. --- ## Practical Implementation ### Integrate PCCP Development Into Design Controls Under **21 CFR Part 820.30** (Design Controls, now reorganized under the 2024 Quality Management System Regulation at **21 CFR Part 820**), design outputs must include documented performance specifications. For AI/ML devices, those specifications should be defined at a level of granularity that makes your future PCCP defensible. Practically: if you are still in development, build your PCCP infrastructure now. Define your locked test set. Establish your subgroup analysis categories. Write your algorithm change protocol before you submit, not after you receive clearance. ### Define a Locked Evaluation Dataset One of the most operationally important decisions you will make is the composition of your locked evaluation dataset — the dataset that is held out from training and used to assess model performance at authorization and for every subsequent change covered by the PCCP. Requirements for this dataset: * Must be representative of the intended use population * Must include sufficient subgroup representation to enable meaningful disaggregated analysis * Must not be used in any training run during the life of the PCCP * Should be documented with a data card or equivalent artifact describing provenance, collection dates, site characteristics, and labeling protocol ### Build a Change Classification System Not every model modification is equal. A strong PCCP includes a tiered classification system that distinguishes: | Change Type | Example | PCCP Covers? | Additional Submission Required? | |---|---|---|---| | Minor retraining | Same architecture, 10% new data added | Yes, if within defined bounds | No | | Threshold adjustment | Decision threshold moved within pre-specified range | Yes, if bounds specified | No | | Architecture change | New model backbone | Typically no | Usually yes | | New intended use | Expanded to pediatric population | No | Yes | | Labeling change | New contraindication added | No | Yes | FDA will scrutinize any PCCP that appears designed to avoid submissions for changes that genuinely alter the risk profile. Draw your scope conservatively in initial submissions; you can expand with a supplement later. ### Post-Market Monitoring and Reporting A PCCP does not eliminate post-market obligations — it adds to them. Under **21 CFR Part 803** (MDR) and your **21 CFR Part 820** QMS, you must: * Monitor deployed model performance against the metrics established in your PCCP methodology * Document when a model update is triggered, executed, and validated * Maintain records sufficient for FDA inspection — including all training runs, evaluation results, and change rationale documentation * Report adverse events attributable to algorithm performance failures, same as any other software malfunction FDA's position, articulated in multiple device-specific interactions since 2025, is that a PCCP is a commitment, not a permission slip. If your monitoring data shows the model is degrading and you do not act, that is a potential recall situation — regardless of whether the PCCP authorized the type of change you needed to make. --- ## Common Misinterpretations and Pitfalls ### Pitfall 1: Treating PCCP as a Blanket Authorization A PCCP authorizes specific modifications within specified bounds. It does not authorize whatever the company decides is reasonable after clearance. FDA has issued warning letters to companies that implemented changes technically within their PCCP's literal description but outside the spirit of the methodology they committed to. ### Pitfall 2: Submitting a PCCP Without a Mature Algorithm Change Protocol FDA reviewers look for evidence that the algorithm change protocol in the PCCP reflects a real internal process — version control, designated approvers, change request documentation. A PCCP that describes a robust protocol but was authored by regulatory affairs without input from the ML engineering team will show seams under review. ### Pitfall 3: Inadequate Subgroup Analysis Planning The agency's emphasis on algorithmic equity has not diminished. A PCCP that defines overall AUC or sensitivity as the only acceptance criterion — without specifying subgroup performance floors — will receive a deficiency requesting disaggregated analysis plans. Define your clinically relevant subgroups (age bands, sex, race/ethnicity where clinically relevant, site type) in the PCCP, not in a response to a deficiency. ### Pitfall 4: Scope Creep in Planned Modifications Some submissions describe modifications so broadly — "the model may be updated to improve performance" — that FDA cannot assess whether the PCCP appropriately bounds risk. Broad language signals to reviewers that the manufacturer has not thought rigorously about what it is actually going to do post-market. ### Pitfall 5: Ignoring the Software as a Medical Device (SaMD) Risk Categorization FDA's risk framework for SaMD, drawn from the International Medical Device Regulators Forum (IMDRF) framework, affects how strictly the agency will scrutinize your PCCP. A device that drives a diagnosis or treatment decision without clinician override (high impact, serious condition) will face more rigorous PCCP review than a low-impact informational device. Calibrate your methodology's rigor to your SaMD risk category. --- ## PCCP Compliance Checklist Use this checklist before submitting a PCCP as part of any premarket submission: * [ ] Planned modifications are described at the parameter level, not conceptually * [ ] Explicit bounds are defined for each category of planned modification * [ ] Changes that are out of scope (new indications, major architecture changes) are explicitly excluded * [ ] Locked evaluation dataset is defined, documented, and representative * [ ] Subgroup analysis plan identifies clinically relevant subgroups and performance floors * [ ] Reference standard for ground truth labeling is documented * [ ] Algorithm change protocol reflects a real internal process with named roles and documentation requirements * [ ] Impact assessment uses structured risk analysis (ISO 14971 recommended) * [ ] Post-market monitoring plan specifies trigger thresholds for corrective action * [ ] PCCP has been reviewed by both regulatory affairs and ML engineering leadership * [ ] SaMD risk category has been assessed and PCCP rigor calibrated accordingly * [ ] Cybersecurity implications of planned model changes have been addressed --- ## Key Takeaways * **A PCCP is a scope-limited commitment, not a blanket authorization.** Every modification must fall within explicitly defined bounds — vague language will generate deficiencies and may create post-market compliance exposure. * **Start PCCP development during design, not during submission preparation.** The locked evaluation dataset, algorithm change protocol, and subgroup analysis categories must be built into your development infrastructure to be credible at review. * **Subgroup performance is not optional.** FDA expects disaggregated analysis plans as part of the methodology section. Define your clinically relevant subgroups and set performance floors before you submit. * **Post-market monitoring under a PCCP is an active, documented obligation.** Clearance with a PCCP means FDA will expect to see your monitoring data and change records at inspection. Build the QMS infrastructure before your device launches. * **Your SaMD risk category determines scrutiny level.** Calibrate the rigor of your validation methodology to the clinical impact of your device — a PCCP for a high-impact diagnostic AI will be held to a materially higher standard than one for a low-impact screening support tool.