On October 20, 2026, the FDA published two new hypothetical examples showing how Predetermined Change Control Plans (PCCPs) could be used for AI-enabled medical devices. The examples involve a hospital system that predicts sepsis and software that detects dangerous heart rhythms. Both show how AI could improve over time without requiring a new FDA submission for every planned update. More importantly, they show how manufacturers are expected to prove that those changes remain safe for patients.
For anyone developing medical devices that use artificial intelligence, these examples are worth reading. They move beyond general discussions about AI and explain what controlled changes could look like in a real hospital. They also raise an important question for manufacturers working in both the United States and Europe: How much can a medical device change before it needs another regulatory review?
A PCCP allows a manufacturer to describe certain planned changes before they happen. The manufacturer explains what may change, how it will test those changes, and how it will assess their impact on safety and performance. If the FDA authorizes the plan as part of a device submission, the manufacturer can make changes covered by that plan without submitting a new application every time. However, the changes must stay within the authorized limits and follow the agreed testing process.
That is an important distinction. A PCCP is not permission for an AI system to change however it wants. It is a defined plan with limits, tests, and responsibilities.
Example 1: Two hospitals, one AI system, very different patients
The FDA's first example involves software designed to help clinicians identify patients who may develop sepsis within the next 24 hours. Sepsis is a serious condition that can develop when the body's response to an infection begins damaging its own tissues and organs. Finding patients at risk early can help clinicians respond sooner.
The software looks at information already collected by the hospital, including vital signs, laboratory results, and nursing assessments. It then calculates a risk score and alerts the care team when a patient may need further evaluation.
But imagine this software being used at two very different hospitals.
Hospital A is a large teaching hospital in Chicago. It treats many older patients with complex medical conditions, including diabetes, heart failure, and kidney disease. These patients may already have abnormal laboratory results before developing an infection. The hospital also has detailed electronic nursing records, frequent laboratory testing, and established sepsis response protocols.
Hospital B is a smaller community hospital in rural Wyoming. It serves a different mix of patients, uses different laboratory equipment, and may document nursing assessments in a different way. Its electronic health record may collect some information at different intervals or use different codes for the same clinical observation.
These are hypothetical hospitals, but the differences are realistic. An elevated laboratory value that is unusual for one patient population might be common in another. A nursing assessment recorded every hour at one hospital might be recorded less frequently at another. Even the way staff document changes in mental status can differ.
Now imagine that the same AI system is installed at both hospitals. At Hospital A, it might generate too many alerts because some patients already have abnormal baseline laboratory values. At Hospital B, it might miss useful warning signs because certain clinical observations are recorded differently. These are possible performance problems, not inevitable outcomes, and they would need to be demonstrated through testing.
This is exactly the type of challenge the FDA's example addresses.
Under the hypothetical PCCP, the manufacturer could adjust how certain nursing data are weighted, retrain the final layers of the AI model using local hospital data, and modify the alert threshold within defined limits. But each adapted version must be tested using appropriate independent data before deployment. The manufacturer must also show that it continues to perform safely and monitor how well the system works at that hospital after release.
The manufacturer cannot simply assume that a model performing well in Chicago will perform equally well in Wyoming.
The important lesson is that AI performance depends on the people, data, and clinical setting in which it is used. A single model can encounter very different conditions across hospitals, and manufacturers need a controlled way to manage those differences.
This topic may walk the line of "was the system clinically validated with sufficient detail in the first place." Manufacturer's should not rely on PCCP to correct poorly validated devices, but rely on them as methods to redirect the trajectory of their devices once real world data becomes available.
Example 2: An AI that learns to detect dangerous heart rhythms
The FDA's second example takes the concept further. It describes software that continuously monitors ECG signals and helps identify potentially dangerous heart rhythms, including atrial fibrillation, ventricular tachycardia, and third-degree heart block.
Imagine a large cardiac center treating patients after heart surgery. Many patients may have pacemakers, complex rhythm abnormalities, or changes in their heart's electrical signals following treatment. Now consider a smaller general hospital monitoring patients admitted for other medical conditions. The types of rhythms encountered, the quality of recorded ECG signals, and the frequency of certain abnormalities may differ.
A system trained using data from both hospitals could learn from a broader range of ECG patterns. Perhaps it previously struggled to recognize an abnormal rhythm in patients with certain implanted devices. Or perhaps it generated unnecessary alerts when movement or poor electrode contact created electrical noise that resembled an abnormal heartbeat.
As more carefully reviewed ECG recordings become available, the manufacturer may be able to retrain the model and improve how it recognizes these patterns.
The FDA's hypothetical PCCP describes something significant: The system could retrain, validate, and deploy updated models automatically, without a person approving each individual update.
That sounds like a major responsibility to place on software, and it is.
The proposed controls are what make the example meaningful. Every updated model must pass predefined performance tests before deployment. These include testing its ability to detect each type of arrhythmia, its rate of false alerts, and its performance across defined patient groups. If the updated model fails any required acceptance criterion, the update is blocked and the currently deployed model remains in place.
Even after passing validation, the update is introduced through a controlled rollout. Its performance continues to be monitored, with predefined limits that trigger investigation if the system begins performing differently than expected.
Consider the consequences of getting this wrong. If a model becomes better at identifying atrial fibrillation but worse at detecting ventricular tachycardia, an overall improvement in accuracy would not necessarily mean that the updated device is safer.
A successful AI update must do more than improve an average performance score. It must continue to meet the safety and performance requirements for every clinically important function.
This is why validation, risk management, and post-market monitoring need to remain connected throughout the AI lifecycle.
What does this mean under the European MDR?
The European approach is different from the FDA's, but manufacturers already have established ways to control changes to certified medical devices.
Under Regulation (EU) 2017/745, many Class IIa and IIb devices are certified through a quality management system and applicable technical documentation assessment procedures. Manufacturers routinely make changes to software, components, manufacturing processes, and device documentation under their quality systems.
Not every change requires a new certificate or a fresh conformity assessment. Many changes can be implemented under the manufacturer's existing change-control procedures, provided they remain within the applicable certification scope and do not trigger additional notified body requirements. However, every change still needs an appropriate assessment of its impact on safety, performance, risks, and regulatory compliance.
The MDR sets out relevant requirements in Annex IX, including Section 2.4 concerning substantial changes to the approved quality system or device range, and Section 4.10 concerning changes to devices covered by EU technical documentation assessment certificates. Annex VII, Section 4.9 also requires notified bodies to establish procedures and contractual arrangements for assessing changes.
A useful historical reference is NBOG BPG 2014-3, which provides examples of substantial and nonsubstantial device and quality system changes. Although written for the former Medical Device Directives rather than specifically for the MDR, it remains a helpful reference when considering how changes affect safety and performance.
For example, updating the appearance of a software interface without affecting clinical interpretation may be relatively straightforward. Updating an algorithm that changes diagnostic results, patient alerts, or treatment decisions requires much closer evaluation. NBOG 2014-3 specifically identifies several types of software changes affecting diagnosis or therapy as potentially substantial.
This creates an important distinction when comparing FDA PCCPs with European change control.
A change covered by an FDA-authorized PCCP is not automatically a nonsubstantial change under the EU MDR.
The manufacturer still needs to evaluate the change against the European requirements, the device's certification arrangements, and the applicable notified body's change procedures. The existence of a predefined testing plan does not, by itself, remove these obligations.
Europe may be moving toward a more formal PCCP approach
There is also a new development in Europe.
On December 16, 2025, the European Commission published a proposal to revise parts of the MDR and IVDR. Among the proposed changes is a more clearly defined process for managing changes to certified devices.
The proposal would require notified bodies to distinguish between changes that manufacturers can implement without prior notification, changes that must be reported but do not require prior approval, and changes that require approval before implementation.
It also proposes that, where appropriate, manufacturers and notified bodies could agree on a Predetermined Change Control Plan, allowing certain planned changes to be implemented under that agreement.
This would bring the European framework closer to the idea behind the FDA's PCCP approach, while retaining the role of the notified body and the existing conformity assessment system.
As of October 2026, these amendments remain proposals and are not yet binding law.
The potential benefit is greater clarity for manufacturers. Rather than repeatedly determining whether a planned series of changes requires a new notified body review, manufacturers and notified bodies may eventually be able to agree on defined changes, validation methods, and implementation conditions in advance.
That could be especially useful for AI-enabled devices, where models may need updating as new clinical data become available.
The real responsibility begins after the change
Whether a manufacturer follows the FDA's PCCP framework or the EU MDR's existing change-control process, the most important question remains the same: How will the manufacturer know that the changed device is still safe?
For AI-enabled medical devices, this question cannot be answered by software verification alone. A manufacturer needs to understand the clinical impact of a change, including the risks of incorrect outputs, missed diagnoses, delayed treatment, unnecessary alerts, and performance differences across patient populations.
Manufacturers should establish clear performance limits, appropriate independent testing, procedures for failed updates, and ongoing monitoring after deployment. When performance begins to drift, there should be a defined process to investigate the problem and determine whether corrective action, retraining, or rollback is necessary.
Post-market surveillance should not be limited to counting complaints and reviewing incidents once a year. For AI-enabled medical devices, it should also include meaningful monitoring of the system's clinical performance over time.
The FDA's new examples show a possible future in which medical devices can improve more frequently while remaining subject to defined safety controls. Europe's proposed changes suggest that more predictable approaches to planned modifications may also become part of the MDR framework.
The goal should not be to make changes easier simply because AI technology can change quickly. The goal should be to make changes more predictable, better controlled, and supported by evidence.
A medical device should not be considered safe because its algorithm passed a test six months ago. It should remain safe because the manufacturer understands how it performs, knows when performance changes, and has effective controls throughout its lifecycle.
The question for medical device manufacturers is simple:
If your AI changes tomorrow, how will you prove that it is still safe for the patients who depend on it?
Should Europe adopt a formal PCCP approach similar to the FDA's, or does the existing MDR change-control framework already provide much of the flexibility manufacturers need?
References and further reading
- FDA (October 2026): Novel Medical Devices with Predetermined Change Control Plans: Hypothetical Case Examples
- FDA: Predetermined Change Control Plans: Overview
- FDA (August 2025): Marketing Submission Recommendations for a PCCP for AI-Enabled Device Software Functions
- European Union: Regulation (EU) 2017/745, particularly Annex VII and Annex IX
- NBOG: Best Practice Guide 2014-3: Guidance on Reporting Design Changes and Changes of the Quality System
- European Commission (December 2025): COM(2025) 1023: Proposed amendments to the MDR and IVDR
- European Parliament: Legislative procedure 2025/0404(COD)
#MedicalDevices #MedicalDeviceRegulation #RegulatoryAffairs #EUMDR #MDR2017_745 #FDA #PCCP #PredeterminedChangeControlPlan #ArtificialIntelligence #MedicalAI #AIMedicalDevices #SaMD #SoftwareAsAMedicalDevice #DigitalHealth #HealthTech #MedTech #ClinicalAI #MachineLearning #MedicalDeviceSoftware #RiskManagement #ISO14971 #QualityManagement #PostMarketSurveillance #ClinicalEvaluation #PatientSafety #NotifiedBody #RegulatoryCompliance #SoftwareValidation #AIGovernance #AIValidation #MedicalDeviceInnovation #Bevrik
Originally published on LinkedIn.