A model passes the new dataset by two percentage points, yet the subgroup failure rate moves in the wrong direction. Without a predeclared boundary, the team must decide under release pressure whether the change is an improvement, a new device behavior, or a reason to stop.
An FDA AI device change control plan, commonly called a predetermined change control plan or PCCP, is designed to move that decision earlier. It describes which changes are planned, how they will be developed and validated, and how their impact will be assessed.
What the FDA AI device change control plan covers
The FDA’s final PCCP guidance applies to AI-enabled devices reviewed through 510(k), De Novo, and PMA pathways, including device constituent parts of device-led combination products.
The agency recommends that the plan describe planned modifications, the methodology for developing, validating, and implementing them, and an assessment of their impact. The FDA reviews the plan as part of a marketing submission so authorized modifications can be implemented without a new submission for every covered change.
For a product team, the essential question is concrete: what may change, within which bounds, using which evidence, and what stops the release?
A PCCP does not make future modifications automatically safe. It makes the intended change process reviewable before the pressure and uncertainty of a live update.
Case study: a bounded segmentation-model update
Consider a hypothetical imaging device that segments an anatomical structure for clinician review. The manufacturer wants to improve performance on scans from a named acquisition protocol without changing the intended use, clinical user, output type, or supported anatomy.
The planned modification can be bounded by model component, input protocol, training-data source, output behavior, and performance range. The change protocol can then specify dataset separation, site representation, subgroup analysis, reader evaluation where relevant, software verification, cybersecurity review, and rollback conditions.
Evidence packet for the hypothetical update
| Claim | Required evidence | Stop condition |
|---|---|---|
| The update improves target performance | Locked external test set and prespecified metric | Benefit misses the acceptance threshold |
| Safety remains acceptable | Error analysis by clinically relevant subgroup | A key subgroup crosses its risk limit |
| Workflow remains consistent | Human-factors and integration verification | Use error or output interpretation changes |
| Deployment is controllable | Version traceability, monitoring, and rollback test | State cannot be reconstructed or reverted |
The five questions every modification needs
- What exactly changes? Name the model, data, threshold, preprocessing, output, or workflow component.
- What stays fixed? State intended use, population, environment, user, hardware, and clinical role boundaries.
- How is benefit measured? Choose metrics and thresholds justified for the task rather than whatever improves after training.
- How is new risk detected? Include subgroup, edge-case, integration, security, and use-related failure analysis.
- How is the change controlled? Bind data lineage, version identity, approval, monitoring, communication, and rollback.
The international PCCP guiding principles emphasize focused and bounded changes, risk-based planning, evidence, transparency, and a total-product-lifecycle view. Those principles make useful design-review headings even before a submission package exists.
Use the authorized-device list as context, not a template
The FDA maintains an AI-enabled medical device list with links to public authorization records. The agency says the list is not comprehensive and is identified largely through AI-related terms in public summaries.
That list helps a team inspect product codes, panels, decision dates, and public summaries in its area. It does not reveal every submitted detail and cannot substitute for a product-specific regulatory strategy.
Use neighboring devices to sharpen questions about intended use and evidence, not to copy thresholds or claims. A metric appropriate for radiology segmentation may be irrelevant to monitoring, pathology, cardiology, or a patient-facing function.
Common failure patterns
The first failure is an unbounded modification such as retraining on “new real-world data.” A reviewer cannot know which populations, acquisition systems, labels, prevalence, or performance changes that sentence permits.
The second is a single aggregate metric. A global result can improve while performance worsens for a site, device, demographic group, disease presentation, or low-frequency but high-consequence case.
The third is monitoring without an action boundary. A dashboard matters only when a named owner can pause rollout, revert a version, investigate data drift, and communicate a material change.
The fourth is confusing algorithm validation with clinical and workflow evidence. The device is used by people inside a care process, so integration and interpretation can create risk even when the model output is numerically stable.
Build the plan as an operating system
Maintain a change register that links each proposed modification to its covered PCCP scope, training data, validation protocol, risks, approvals, released version, and post-deployment monitoring. If the change falls outside the authorized boundary, stop and route it through the appropriate regulatory decision before implementation.
Keep test datasets and acceptance thresholds versioned, with controlled access and documented rationale. Run a negative control that must fail so the team knows the gate can detect unacceptable performance.
Neyrotex’s AI early cancer detection analysis discusses diagnostic evidence and clinical promise. Our neural bionic prosthetics report covers shared autonomy and sensory feedback; this PCCP guide focuses on governing a defined post-authorization model change.
Follow the Neyrotex MedTech section for technical and regulatory analysis. The product lesson extends beyond compliance: a controlled update is easier to debug, explain, and reverse.
