A predetermined change control plan lets you improve a cleared AI model without going back to FDA each time. That only works if your data, retraining, testing and release pipeline can prove you followed the plan.
Your AI model is cleared. Six months later you have more data and a better model. Under the normal rules, a significant change to a cleared device can mean a new marketing submission before you ship it. For a model you want to retrain every quarter, that is slow.
A predetermined change control plan, or PCCP, is FDA's answer. You describe the changes you expect to make, and how you will make and test them, in the original submission. Once FDA authorizes the plan, changes made exactly as the plan says do not need a new submission each time.
Most articles on PCCPs are written for regulatory teams. This one is for the people who build the software. The plan is a promise, and the pipeline is how you keep it.
FDA first issued its final guidance on PCCPs for AI-enabled device software functions on 4 December 2024 and reissued it on 18 August 2025 (FDA guidance page, docket FDA-2022-D-2628). Like all guidance, it contains nonbinding recommendations. It covers devices that go through 510(k), De Novo or PMA, and it covers both changes your team makes by hand and changes the software makes automatically.
A PCCP has three parts:
The Modification Protocol is where engineering lives. FDA splits it into four components: data management, re-training, performance evaluation and update procedures. Figure 1 shows how they fit together as one release pipeline.
FDA asks how new data will be collected, labelled, stored and kept, and how it relates to the data behind every earlier version. Most of all, it asks how you keep test data separate from training and tuning data.
In practice that means:
The protocol should say which processing steps can change, how, and what triggers a retrain. FDA gives examples of triggers: enough new data has arrived, or drift has been seen over time. If the architecture can change, the plan needs a reason for each change.
For engineers, this means the training run itself must be repeatable. Pin the code commit, the dataset versions, the hyperparameters and the environment for every run. If a released model behaves oddly in a clinic, you need to rebuild that exact model and test it again.
This is the part teams most often underbuild. FDA expects each modified model to be compared with both the original cleared version and the last released version. The study design, metrics, statistical tests and acceptance criteria are set in the plan, before testing.
The guidance also asks for a clear rule. If a change fails its pre-set criteria and the failure cannot be resolved, you record the failure and do not ship that change. Build this as an automated gate in your release pipeline, not as a meeting.
Keep the original version runnable for as long as the plan is in use. Without it, you cannot do the comparison.
Once a change passes, the update procedures cover how it reaches devices and users. FDA's points include:
That last point closes the loop in Figure 1. Field monitoring is also where your next round of data and your drift triggers come from.
The hardest call is often whether a better model is still the change you described. The guidance includes a worked example for AI patient monitoring software that raises an alarm at the onset of physiologic instability. The table sums up its two scenarios.
| What the team did | Inside the PCCP? | Result |
|---|---|---|
| Retrained to cut false alarms. Sensitivity stayed within the pre-set margin. Labeling updated and users told. | Yes | No new submission. Document it in the quality system. |
| Retrained, then found the model could now predict instability before onset, and wanted to claim that. | No | New marketing submission needed. The plan never covered predicting a future state. |
The lesson for engineers: a new capability is not a free bonus. Your release gate should check a change against the Description of Modifications as well as the metrics. If a model starts doing something the plan never described, stop and talk to your regulatory lead.
FDA also treats failing to follow the plan as a deviation, for example a data management or retraining failure, or missing a pre-set criterion. The guidance says such deviations would generally make the device adulterated and misbranded. That is why the pipeline records matter as much as the model.
The guidance says changes under a PCCP must be made in line with the manufacturer's quality system. FDA's Quality Management System Regulation, which brings ISO 13485:2016 into 21 CFR Part 820, took effect on 2 February 2026 (FDA QMSR page). The August 2025 guidance still cites the older Part 820 section numbers and says FDA will update them, so check current references with your regulatory lead.
For the software team, the point is the same either way. Changes, approvals and test records must be traceable. A pipeline that writes those records as it runs beats documents filled in after the fact.
Innometrique is a software engineering partner, not a regulatory consultant, and Innometrique holds no FDA clearances. Work on a PCCP should be led by your regulatory and quality team. We build the pipeline that lets you keep the plan. Innometrique was founded in 2025. Before that, the founder's earlier company, Hashtaag Technologies (later acquired by Biofourmis), built software including beatHF and the biovitals analytics engine. That is founder background, not Innometrique client work. The founder track record page has the detail.
For the wider system around a monitoring model, see wearable and remote patient monitoring software. For lifecycle practice in general, read AI Development Lifecycle Management. For a rough budget, the AI project cost estimator shows every assumption it uses.
Tell us what your model does and what you expect to change after clearance. We will look at your data, retraining and release pipeline and tell you plainly where the gaps are.
Talk to Us →