Predetermined Change Control Plans for AI Medical Devices: A Practical Guide

An AI-enabled medical device may need to change after authorization. New data can reveal performance gaps, an input format can evolve, or a carefully bounded model update may improve performance. The traditional regulatory question is whether a modification requires a new marketing submission before distribution. A predetermined change control plan, or PCCP, lets a manufacturer propose certain future modifications and the process for controlling them as part of a device submission.

The “predetermined” part is essential. Regulators review the boundaries, development and validation methods, impact analysis, and safeguards before those changes are implemented under the plan; a PCCP is not a general license for continual self-modification, and it does not turn postmarket monitoring into a substitute for evidence before release.

Why ordinary software updates become a medical-device question#

Consumer software can change rapidly, but a medical device makes claims connected to health decisions. A modification can alter sensitivity, specificity, or calibration. It can alter workflow, alarm frequency, or which patients receive a recommendation. Even a change described as technical may affect clinical performance.

AI systems create additional lifecycle pressure. Their performance depends on data distributions, input pipelines, labels, feature definitions, and model implementation. A new scanner, coding convention, patient mix, or clinical pathway can change behavior without an obvious software failure. Updating the model may help, yet every update can introduce a new failure mode.

Without a reviewed plan, a significant modification may need a new submission before distribution. That pathway protects patients but can make a series of well-understood, low-risk improvements cumbersome. A PCCP aims to preserve premarket scrutiny while allowing specific changes through an authorized control process.

The legal and regulatory frame#

Section 515C of the Federal Food, Drug, and Cosmetic Act, codified at 21 USC 360e-4, provides for predetermined change control plans for devices. The FDA's final guidance, issued in August 2025, explains recommendations for AI-enabled device software functions in marketing submissions.

A guidance document states the agency's current thinking and does not replace the statute or regulations. The practical requirements depend on the device, submission type, risk, intended use, and exact modification. If you are evaluating a public claim, the point to hold onto is that a company cannot create its own post hoc PCCP after an update and treat that as prior authorization. The plan is reviewed with the device submission. International guiding principles developed by the FDA, Health Canada, and the United Kingdom's MHRA emphasize the same total product lifecycle, patient safety, transparency, and bounded changes, though jurisdictions retain their own legal pathways, so a plan accepted in one system should not be assumed to authorize distribution in another.

Part 1: the description of modifications#

The first element states what may change. A useful description is concrete enough that a reviewer can picture the future device and distinguish an allowed modification from an unreviewed one.

Examples might include retraining within a defined model architecture, adding data from specified sources, adjusting a decision threshold within a justified range, or extending compatibility to a bounded input specification. Whether any example is suitable depends on the device and risk.

Weak language such as “improve performance as new data become available” does not set a meaningful boundary. The plan should specify which components may change, which remain fixed, the intended purpose of each modification, and whether multiple changes may be combined. It should explain how the change relates to the authorized intended use and device labeling. A modification that changes the patient population, clinical purpose, output meaning, or role in decision-making may carry risks that cannot be handled as a routine update under the original plan, which is why clear exclusions matter as much as the allowed list.

Part 2: the modification protocol#

The modification protocol explains how each allowed change will be developed, validated, implemented, and controlled. It turns an idea about future updates into a reproducible quality process.

Data management should address source selection, representativeness, and provenance. It should address labeling, quality checks, and missingness. It should address duplication and separation of training from evaluation. If real-world data will be used, the protocol should explain how drift, coding changes, and feedback created by the deployed device will be detected.

Model development controls may specify architecture constraints, feature handling, tuning, versioning, and acceptance criteria. Validation should match the intended use and include clinically meaningful endpoints, uncertainty, relevant subgroups, and comparison with the authorized device. A large pooled test set cannot hide poor performance in a subgroup where errors have serious consequences.

Implementation controls should cover software verification, configuration, and release approval. They should cover rollback, cybersecurity, and distribution. The protocol should identify who reviews evidence, who authorizes release, what records are retained, and what triggers a stop or investigation.

Monitoring completes the loop. The manufacturer needs a way to detect performance deterioration, unexpected use, and data drift. It also needs to detect complaints, adverse events, and unequal error patterns after deployment. Monitoring thresholds and responses should be defined before a problem occurs.

Part 3: the impact assessment#

The impact assessment explains the benefits and risks of implementing the modifications and how the protocol controls those risks; it considers the device as a system rather than treating the model as an isolated file.

An updated model can alter downstream workflow, user interpretation, alarm burden, and reliance. It may affect interoperability, cybersecurity, labeling, training materials, or compatibility with other components. Several individually modest changes can interact. The assessment should examine cumulative effects and the possibility that a sequence of allowed updates moves the device farther from the originally evaluated state.

This element also connects each risk to evidence and mitigation, and if adding data from new sites could shift subgroup performance, the protocol might require site-diverse validation and subgroup acceptance criteria. If a threshold adjustment changes false-positive burden, the evaluation should measure workflow and user consequences, not only overall discrimination.

A PCCP is not an “autonomous learning” permission slip#

Marketing language sometimes implies that an authorized AI device continuously learns from every new patient and upgrades itself. That is not what a PCCP establishes. The plan governs specified modifications through defined controls. Data collection, model development, and validation remain accountable activities. So do approval, release, and monitoring.

The distinction between locked and adaptive behavior also needs care. A model may produce dynamic outputs from new inputs while its parameters remain fixed. That ordinary operation is not a model update. Conversely, periodic retraining can change parameters even if each released version stays fixed between controlled updates. So ask which component changes, when it changes, whether the update lands on the device itself or arrives as a manufacturer release, and how you are meant to know which version is in use.

Transparency for clinicians and patients#

Transparency should be proportionate to the decision and audience. Users may need to know the device's intended use, required inputs, and relevant limitations. They may need to know performance population, update status, and any workflow changes. A version identifier and accessible change summary can support incident review and local validation.

Transparency does not mean publishing confidential code. It means providing enough information for safe use and informed governance. If an update changes the output's interpretation or expected error profile, silent distribution can undermine training, consent, and oversight even if average technical performance improves.

Healthcare organizations also need inventory controls. They should know where an AI device is deployed, what version is active, how updates are accepted, and how local performance signals reach the manufacturer. A PCCP does not remove the deploying organization's responsibility for safe integration.

Common evidence mistakes#

One mistake is validating an update on data used to design it, and another is comparing the updated model only with an obsolete version rather than the authorized baseline and current clinical practice. A third is reporting aggregate accuracy while omitting calibration, operating thresholds, and subgroup errors.

Small numerical improvements may not be clinically meaningful. An update that improves one metric can worsen another, such as increasing sensitivity while producing an unsustainable false-alert burden. Changes to data pipelines can also create hidden leakage or label inconsistency. So the evaluation has to account for the full chain from raw input to user action: technical performance is necessary, but human factors and clinical workflow can determine net benefit.

How to read a PCCP claim#

Ask seven questions:

1. Which authorized device and intended use does the plan cover?
2. What exact modifications are allowed, and what is explicitly excluded?
3. What data and validation methods govern each change?
4. What acceptance criteria must be met before release?
5. How are subgroup performance, human factors, cybersecurity, and cumulative effects assessed?
6. How will users identify the version and understand material changes?
7. What monitoring, stop, rollback, and reporting processes apply after release?

Public information cannot answer every proprietary detail, but it should still make the boundaries and the safety logic understandable to you.