For manufacturers of artificial intelligence-enabled Software as a Medical Device (SaMD), the hardest compliance question in 2026 is not how to get a first clearance. It is how to keep that clearance alive while the algorithm continues learning. The U.S. Food and Drug Administration’s final guidance on Predetermined Change Control Plans (PCCP), finalized in late 2024, was designed to solve exactly that problem. Across the Atlantic, the European Union’s Medical Device Regulation (EU MDR) offers a different but increasingly compatible framework. This roadmap explains how to design a single iterative update program that satisfies both regimes without doubling your regulatory workload.
Why Iterative AI Changes the Compliance Calculus
Traditional medical device submissions assume a frozen design. Once a 510(k) or CE mark is granted, any meaningful change triggers a new filing. That assumption collapses when the device is a continuously retrained neural network, a foundation model with downstream clinical use, or a rule-based engine that adapts to new clinical guidelines. Regulators have responded by carving out a narrow lane for pre-authorized change.
The FDA’s PCCP framework, codified in Section 515C of the FD&C Act and elaborated in the December 2024 final guidance, lets sponsors describe planned modifications in advance, including the methods for validating them and the triggers that require sponsor notification. The European Commission has not issued an equivalent PCCP rule, but Article 10a of the MDR, the MDCG 2020-16 guidance on software lifecycle, and the upcoming Annex XVI updates create a workable path through the existing “substantial modification” rules.
Manufacturers that treat these as two separate compliance silos end up doing the same documentation twice. The smarter approach is to design one global change control protocol that is robust enough to satisfy both.
What the FDA PCCP Actually Authorizes
A PCCP is a bounded, machine-readable description of the future. It is submitted with a 510(k), De Novo request, or PMA, and once the FDA authorizes it, modifications that fall inside the plan do not require a new submission. The final guidance tightened earlier drafts in three ways worth noting.
- Scope is narrow. The PCCP can describe specific modifications to the device’s software, performance, or intended use, but it cannot quietly expand indications for use. Each modification must be described with enough detail that a reviewer can foresee the risk profile.
- Modifications are grouped, not itemized. Sponsors define categories of change rather than enumerating every retraining run. A typical group might be “monthly recalibration of the segmentation model on drift-triggered data slices,” with a defined statistical envelope.
- Documentation is mandatory, not optional. The guidance makes clear that the sponsor must keep a PCCP-specific version history, including pre- and post-modification performance evidence, available for FDA inspection at any time during the device’s lifecycle.
How the EU MDR Handles the Same Problem
European regulators never had the statutory equivalent of a PCCP, so they rely on three MDR provisions that, combined, do similar work.
- Article 10a “Substantial Modification” procedure: Changes that affect safety, performance, or intended use require a new conformity assessment by the Notified Body. Changes inside an agreed change-control protocol, including the one in the original technical documentation, generally do not.
- Annex I General Safety and Performance Requirements (GSPR): Requirement 17.1 obliges manufacturers to define and document the software lifecycle, including version control, bug management, and validation of every release. A PCCP-style protocol can be slotted into the lifecycle section of the technical file.
- MDCG 2019-11 (qualification and classification of software) and MDCG 2020-16 (software as a medical device lifecycle): These guidances, currently being revised, acknowledge that iterative AI is a normal feature of SaMD and require manufacturers to demonstrate a controlled update process rather than a frozen product.
European authorities do not approve an “iterative update plan” the way the FDA does, but they routinely accept a manufacturer’s documented change-control protocol as evidence of GSPR compliance. The trick is to ensure the protocol meets FDA-grade specificity.
Building One Protocol That Satisfies Both Regulators
1. Define the Modification Categories First
Start with a clean taxonomy of every planned change type: model retraining, prompt template adjustments for clinical LLM tools, threshold tuning, expansion of input modalities, and so on. For each category, document the trigger, the validation method, the expected performance envelope, and the rollback procedure. This taxonomy becomes the backbone of both the FDA PCCP and the EU technical documentation.
2. Specify Triggers and Statistical Boundaries
Regulators on both sides of the Atlantic want to know when a change is big enough to require fresh review. Translate that question into measurable triggers: a data drift score above a defined threshold, a performance delta outside the locked confidence interval, or an expansion of patient population beyond the cleared cohort. Tie each trigger to an action, including the rare case where the modification exceeds the PCCP scope and requires a new submission.
3. Lock the Verification and Validation Method
For every category, the protocol should describe how the manufacturer will demonstrate continued safety and performance. For an AI diagnostic, this typically means a pre-specified test set that is held out from training, plus a prospective silent-mode evaluation. The FDA explicitly expects this to be detailed in the PCCP; the EU MDR expects it in the GSPR 17 evidence. Writing it once satisfies both.
4. Align the Cybersecurity and Post-Market Story
Iterative updates create an expanded attack surface. The FDA’s 2023 cybersecurity guidance and the EU MDR’s GSPR 17.2 both demand a coordinated vulnerability management process. Embed the security update procedure into the same protocol so that a model retrain and a security patch follow the same change-control rhythm.
5. Plan the Quality System Overlap
Both the FDA Quality System Regulation (now harmonized with ISO 13485:2016) and the MDR expect a documented design change procedure. The PCCP and the EU change-control protocol should be referenced in the Design History File as a single controlled document. During an FDA inspection or a Notified Body audit, the inspector should see one change record, not two.
Common Pitfalls When Bridging the Two Frameworks
Even well-resourced teams stumble on three recurring mistakes.
- Submitting a PCCP that is too vague. FDA reviewers reject generic language like “model improvements based on new data.” The protocol must describe the data sources, the statistical limits, and the validation criteria with enough specificity that the FDA can foresee the modified device.
- Forgetting that EU notified bodies still need a separate technical documentation update. A PCCP is not a substitute for an Article 10a significant change assessment. The European Notified Body must be informed of any change that affects the CE certificate, even if the PCCP describes it.
- Letting the clinical evaluation drift. Under EU MDR, every change requires a fresh clinical evaluation consideration under MDCG 2020-13. Under the PCCP, the clinical evaluation is part of the modification evidence. Treat them as the same document.
What to Expect From Regulators Through 2026
The FDA has signaled that PCCP submissions will be tracked as a metric of program maturity, and reviewers are being trained to evaluate iterative AI more routinely. In Europe, the MDR is entering its first formal review, and harmonized guidance on AI as a medical device is being drafted by the MDCG AI Task Force. Sponsors should expect EU guidance on PCCP-equivalent procedures by late 2026, with strong hints that the language will mirror the FDA’s. Designing a protocol today that already meets FDA specificity will make future EU alignment a paperwork exercise, not a redesign.
Conclusion
A well-designed Predetermined Change Control Plan is no longer just an FDA convenience. It is the operational backbone for any SaMD company that wants to ship model updates without filing a new submission every quarter. By writing one rigorous change-control protocol that meets FDA specificity, satisfies EU MDR’s substantial modification and GSPR 17 requirements, and lives inside a single ISO 13485 design change procedure, manufacturers can collapse duplicated regulatory work into a single process. The companies that invest in this harmonized roadmap now will be the ones still iterating safely while their competitors wait for the next submission cycle.
