What you will learn
By the end of this topic, you should be able to distinguish ordinary AI change control from a predetermined change control plan, describe the modification description, modification protocol and impact assessment, define an authorised change envelope, and operate updates under configuration, verification, monitoring and regulatory controls.
A PCCP is controlled permission, not blanket permission
It defines which future modifications are anticipated and how they will be developed, verified, validated, assessed and implemented while maintaining safety and effectiveness.
Define the claim, control the complete system, generate independent evidence and monitor the product in real use.
Core concepts
Modification description
The specific types of anticipated changes, their scope, boundaries and relationship to the intended use.
Modification protocol
The data, development, verification, validation, implementation and monitoring methods used for each change.
Impact assessment
The rationale that the planned modifications and protocol maintain safety, effectiveness and benefit–risk acceptability.
Change envelope
The approved boundaries beyond which a new regulatory assessment or submission may be required.
Configuration baseline
The released model, data, code, threshold, dependencies, labelling and product configuration before and after change.
Implementation control
Approval, deployment, traceability, rollback, communication and monitoring of each authorised modification.
A practical lifecycle
Create the plan from foreseeable product evolution, then execute every change through the quality system.
Anticipate modifications
Identify likely changes to data, architecture, weights, thresholds, inputs, outputs or performance while preserving intended use.
Typical evidence: Modification inventory and scope rationale.Define the protocol
Specify data controls, development methods, acceptance criteria, validation, impact review and implementation safeguards.
Typical evidence: Modification protocol.Assess cumulative impact
Consider interactions between changes, repeated updates, subgroup effects, labelling and post-market signals.
Typical evidence: Benefit–risk and impact assessment.Obtain the required authorisation
Include the PCCP in the applicable regulatory route and preserve the authorised plan and conditions.
Typical evidence: Approved plan and regulatory correspondence.Execute a change
Confirm it is within scope, follow the protocol, approve evidence, update baselines and deploy controllably.
Typical evidence: Change record, validation report and release note.Monitor and learn
Confirm expected performance after deployment and reassess the plan when evidence or context changes.
Typical evidence: Post-deployment review and PCCP maintenance record.Controls to build in
The plan must be specific enough that a reviewer can understand both the permitted change and the evidence that will control it.
- Link each anticipated modification to a defined protocol and acceptance decision.
- Keep intended-use expansion and unsupported input changes outside the authorised envelope unless explicitly covered.
- Define data representativeness, partitioning and test-set protection for update datasets.
- Assess cybersecurity, privacy, usability, interoperability and labelling impacts—not only model metrics.
- Maintain version traceability and the ability to stop, roll back or contain deployment.
- Aggregate repeated changes so cumulative risk is not hidden by individually small updates.
Evidence to retain
PCCP
Modification description, modification protocol and impact assessment in the expected jurisdictional form.
Change-screening record
Evidence that a proposed update is within the authorised scope and protocol.
Update evidence package
Data, development, verification, validation, risk, labelling and approval records.
Deployment record
Released configuration, affected installations, communication, monitoring and rollback readiness.
Common pitfalls
Vague future improvement
“We may improve performance” does not define a reviewable modification or control method.
Metrics only
An update can alter workflow, privacy, security or subgroup risk without reducing aggregate accuracy.
Automatic equals authorised
Technical capability for continuous learning does not establish regulatory permission to deploy every change.
One change at a time
A sequence of acceptable updates may create cumulative effects that require renewed assessment.
Action checklist
- List foreseeable modifications and define the boundaries of each.
- Specify data, development, validation and implementation protocols.
- Assess risks, benefits and cumulative effects of the planned changes.
- Align the plan with each jurisdiction and regulatory submission route.
- Screen every proposed update against the authorised envelope.
- Baseline, deploy, monitor and retain the ability to contain or roll back.
Specify a change before deciding how to release it
Describe a bounded modification
A useful change plan explains what may change and what must remain fixed. ‘Improve the algorithm as data become available’ is too open-ended to evaluate. Specify the eligible data, affected model or processing components, populations, inputs, outputs and intended-use boundaries. Distinguish a planned performance adjustment from a new clinical purpose or new input modality. This allows reviewers to ask whether the proposed evidence can support the entire range of changes. It also gives the release team an objective way to identify a change that falls outside the plan.
Separate the change description, method and impact
FDA’s August 2025 final PCCP guidance describes planned modifications, the methodology to develop, validate and implement them, and assessment of their impact. Treat these as connected questions: what changes, how will it be controlled, and what does it mean for safety and effectiveness? A plan needs acceptance rules and a response when they are not met. An authorised PCCP is not blanket permission to deploy any model update. Check the applicable authorisation and market-specific requirements; an international framework or acceptance in one jurisdiction does not itself authorise a change everywhere.
Preserve independence across repeated updates
Repeatedly selecting new models against one test set gradually exposes information about that set, even if its raw records remain hidden. Explain how the evaluation strategy manages this risk across the update programme. Control incoming data, labels, retraining, software dependencies, thresholds and deployment configuration. Consider cumulative effects: several individually small changes may alter behaviour materially. Include communication, rollout, rollback and post-release monitoring. A successful technical test is necessary evidence within the plan, but release also depends on scope, risk assessment and the applicable regulatory conditions.
New adult data versus a new paediatric population
A fictional manufacturer has a controlled plan for retraining an adult imaging model using additional data from specified compatible scanners. The intended purpose, adult population and output remain fixed. Two proposals arrive: include another eligible adult dataset, and extend the product to children.
1. Check eligibility before performance
The adult-data proposal is assessed against the precise plan: source eligibility, scanner compatibility, labelling, representativeness and affected configuration. It is only a candidate within the plan until all requirements are met. The paediatric proposal changes the defined population and is treated as outside this fictional plan even if an exploratory benchmark looks promising.
2. Run the modification protocol
For the eligible proposal, the team records data qualification, reproducible retraining and independent evaluation of overall and subgroup criteria. It assesses whether preprocessing or dependency changes introduce additional effects. A missed subgroup criterion blocks release under the stated procedure; the team does not substitute a higher average score.
3. Make and preserve the release decision
Reviewers confirm scope, evidence, impact assessment, labelling and deployment controls against the applicable authorisation. They identify the released version and rollback baseline. The paediatric proposal enters a separate change and regulatory assessment with appropriate evidence planning. Neither proposal is approved merely because the team calls it a PCCP change.
Example change eligibility and release record
This abbreviated teaching example shows the reasoning to capture. Adapt it to the product, risk and quality-system procedures, and link to the underlying evidence.
- Proposed change
- Adult-data retraining; exact affected model, data and processing components identified.
- Scope check
- Each change boundary linked to the applicable plan and authorisation; exceptions explicitly recorded.
- Evidence gate
- Protocol execution, independent results, subgroup criteria, risk impact and cumulative-change assessment.
- Implementation
- Approved baseline, controlled rollout, user information, monitoring owner and tested rollback procedure.
Make the decision yourself
An update is within the planned data sources and improves overall performance, but the team changed the output from a score to a treatment recommendation. Can it rely on the same plan?
Write down your decision, the missing evidence and the next action before opening the answer.
Read the model answer
Do not infer eligibility from the data source or performance result. The output and its clinical role have changed, so compare those changes with the exact authorised scope and reassess intended purpose, risk, evidence and market requirements. Under a plan restricted to the original score, this proposal is outside scope. Hold deployment and follow the appropriate change-assessment route. A strong answer checks every relevant boundary rather than treating the presence of a PCCP as permission for unrelated functionality.
Apply this to your project
Use the example record above to document one real decision. Identify the assumption most likely to change the conclusion, the evidence needed to test it and the person responsible for the next step.
Read alongside this lesson: FDA: final PCCP guidance, August 2025 — read the modification, protocol and impact-assessment recommendations together
Authoritative starting points
- FDA — Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions
- IMDRF — Essential Principles and Content of Predetermined Change Control Plans
- UK Government — PCCP guiding principles for machine learning-enabled medical devices
- FDA — Good Machine Learning Practice for Medical Device Development: Guiding Principles
- IMDRF — Machine Learning-enabled Medical Devices: Key Terms and Definitions
- NIST — Artificial Intelligence Risk Management Framework
- Regulation (EU) 2024/1689 — Artificial Intelligence Act
This module provides educational guidance, not a product-specific regulatory determination. Confirm the legislation, guidance and submission expectations applicable to each intended market.
Make planned learning auditable
A strong PCCP turns foreseeable evolution into a bounded, evidence-led and regulator-visible change process without weakening ordinary design and change controls.
Continue through the MedTechLearning AI-enabled medical-device pathway to connect this topic with the wider lifecycle.