This is a ready-to-use Predetermined Change Control Plan for an AI-enabled device software function, the version submitted as part of an FDA marketing submission so that specified, bounded modifications can be made after authorization without a new submission. It is distinct from an internal-operations PCCP for a GxP manufacturing or laboratory model, where no device clearance is involved; for that, see the template Plan: Predetermined Change Control Plan (PCCP) for ML Model Retraining. Replace every <<FILL: ...>> placeholder and route it through Regulatory Affairs. A filled specimen follows. This content is educational reference, not legal or regulatory advice; confirm the current FDA PCCP guidance before you rely on it.
Document control
| Field | Entry |
|---|---|
| Title | Predetermined Change Control Plan (PCCP) |
| Document number | <<FILL: DOC-ID, e.g. RA-PCCP-006>> |
| Device / software function | <<FILL: AI-enabled device software function name and version>> |
| Submission reference | <<FILL: submission type and number, e.g. 510(k) / De Novo / PMA>> |
| Prepared by (Regulatory / Data Science) | <<FILL: name, date>> |
| Approved by | <<FILL: name, date>> |
1. Basis and intent
This PCCP is submitted under FDA’s authority to authorize predetermined changes to a device (FD&C Act section 515C, added by the Food and Drug Omnibus Reform Act of 2022), following FDA’s guidance “Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions” (originally issued as final on 4 December 2024, with the current version issued 18 August 2025; confirm you are working from the current version before you submit). Once authorized, modifications that fall within this plan may be implemented under the manufacturer’s quality system without a new marketing submission. Modifications outside the plan require the normal submission route.
2. Device and cleared intended use (the fixed frame)
| Field | Entry |
|---|---|
| Intended use / indications | <<FILL: the cleared intended use, which this PCCP may NOT change>> |
| Patient population | <<FILL: cleared population, which may NOT expand under this plan>> |
| Model type | <<FILL: locked / bounded-adaptive; architecture summary>> |
| Inputs / outputs | <<FILL: input data types and output form>> |
Anything in this section is off-limits to the PCCP. If a planned change would alter it, the change is outside the plan.
3. Part 1: Description of Modifications
State each intended change concretely. Vague intentions such as “improve accuracy” are not acceptable; the change must be specific enough to assess in advance.
| Mod ID | Planned modification | What may change | What may NOT change (boundary) |
|---|---|---|---|
<<FILL: M1>> | <<FILL: e.g. periodic retraining on new data of the same type>> | <<FILL: model weights within the stated architecture>> | <<FILL: intended use, population, output type, architecture family>> |
<<FILL: M2>> | <<FILL: e.g. recalibrate decision threshold>> | <<FILL: operating point within a stated ROC band>> | <<FILL: architecture, inputs>> |
4. Part 2: Modification Protocol
For each modification, commit to the methods you will follow to develop, verify, validate, and implement it. This is the engineering contract that makes the change safe.
| Element | Commitment |
|---|---|
| Data management | <<FILL: data sources, curation, representativeness, separation of training and test data, bias checks>> |
| Re-training / re-development procedure | <<FILL: exact procedure for producing the new version>> |
| Verification and validation | <<FILL: test method, locked hold-out set, prospective subset, subgroup analysis>> |
| Objective acceptance criteria | <<FILL: quantitative thresholds the new version must meet before release>> |
| Implementation / update process | <<FILL: how the update reaches the field, versioning, rollback>> |
| Transparency / labeling | <<FILL: what users are told when a change ships>> |
| Records | <<FILL: what is documented under the quality system for each change>> |
5. Part 3: Impact Assessment
Analyze the benefits and risks of the planned modifications and how the modification protocol mitigates the risks.
| Field | Entry |
|---|---|
| Benefits of the planned changes | <<FILL>> |
| Risks introduced or altered | <<FILL: performance drift, subgroup degradation, automation bias, security>> |
| How the protocol mitigates each risk | <<FILL>> |
| Effect on the safety risk file (ISO 14971) | <<FILL: ref>> |
| Effect on the cybersecurity file | <<FILL: ref>> |
| Cumulative effect of repeated changes | <<FILL: how drift across successive updates is bounded>> |
6. Acceptance criteria for the PCCP itself
- Each modification is specific and bounded, with an explicit boundary of what may not change.
- The modification protocol has objective, quantitative acceptance criteria and a defined verification method.
- The impact assessment closes the loop on every modification.
- The whole plan stays within the cleared intended use and patient population.
- A change that fails its acceptance criteria is not released and reverts to the prior authorized version.
7. Governance of in-plan vs out-of-plan changes
| Situation | Route |
|---|---|
| Change within a Mod ID boundary, passes acceptance criteria | Implement under the quality system; document; no new submission |
| Change within boundary, fails acceptance criteria | Do not release; investigate; keep prior version |
| Change outside any boundary (e.g. new intended use, expanded population) | New marketing submission required |
8. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Regulatory Affairs (owner) | <<FILL>> | ||
| Data Science | <<FILL>> | ||
| Risk Management | <<FILL>> | ||
| Quality Assurance | <<FILL>> |
Filled specimen
Illustrative PCCP for an AI-enabled SaMD that flags a finding on an image for clinician review (device and numbers illustrative).
Part 1, Description of Modifications
| Mod ID | Modification | May change | Boundary |
|---|---|---|---|
| M1 | Annual retraining on newly collected images of the same modality | Model weights | Intended use, population, output type, architecture family unchanged |
| M2 | Recalibrate the flagging threshold once per year | Operating point within a stated ROC band | Architecture and inputs unchanged |
Part 2, Modification Protocol (M1)
| Element | Commitment |
|---|---|
| Data management | New images from the same modality and cleared population; curated and de-identified; locked hold-out test set held separate from training |
| Re-training | Same pipeline and hyperparameter search space as the authorized version |
| V&V | Evaluate on the locked hold-out set plus a prospective subset; subgroup analysis by age, sex, and site |
| Acceptance criteria | Sensitivity not lower than current minus 2 percent; specificity not lower than current minus 2 percent; no subgroup performance gap exceeding 5 percent |
| Implementation | Versioned release, staged rollout, one-click rollback to prior version |
| Transparency | Release note stating the version changed and that performance criteria were met |
Part 3, Impact Assessment (excerpt)
Benefit: performance keeps pace with new imaging equipment. Risk: a retrained model could degrade on an underrepresented subgroup. Mitigation: the subgroup acceptance criterion blocks release if any subgroup gap exceeds 5 percent, and the rollback path restores the prior version. Cumulative drift is bounded because each annual version is measured against the original authorized performance, not only against the immediately prior version.
Because every change carries a numeric acceptance criterion and a fixed boundary, FDA can assess the plan in advance, which is what makes the post-authorization changes lawful without a new submission. The classic failure, a protocol that amounts to “we will retrain and decide later if it is good,” is avoided here.
Common review findings this plan prevents
- A modification protocol with no objective acceptance criteria (FDA cannot authorize what it cannot assess in advance).
- Change descriptions broad enough to alter intended use or expand the population.
- No boundary stated, so it is unclear which future changes are in-plan.
- Impact assessment that ignores cumulative drift across repeated updates.
- No rollback or fail path when a retrained version misses its criteria.
How to adapt this plan
- Fix the intended use and population in section 2 first; everything else must respect that frame.
- Write each modification as a bounded Mod ID with an explicit “may not change” list.
- Make every acceptance criterion quantitative; a threshold with a number is assessable, a qualitative one is not.
- Cross-reference the impact assessment to your ISO 14971 and cybersecurity files.
- Confirm the current FDA PCCP guidance title and date before submission.