Global regulators publish framework for medical AI software updates

The International Medical Device Regulators Forum (IMDRF) published final principles for predetermined changes to medical-device software on August 6, 2026. The document gives regulators and manufacturers a common structure for reviewing software updates, including changes to artificial intelligence (AI) models, before those changes reach users.

A predetermined change control plan (PCCP) can let an authorized product change proceed without a separate regulatory submission in jurisdictions that accept the mechanism. It is not permission for a model to retrain and deploy anything it learns: changes must remain within the device's original intended use or purpose, meet prespecified acceptance criteria and follow the authorized plan.

A PCCP defines change before deployment

IMDRF defines a PCCP as a manufacturer-proposed plan that identifies specific software changes, the protocol for implementing and controlling them, and an assessment of their effects. The plan is an optional part of an initial regulatory submission or a later change submission, not a standing exemption from oversight.

The implementation method does not change that boundary. The 2026 document says a plan may specify automatic changes, manual changes requiring human action, or a combination of both, while each jurisdiction decides what its rules allow.

A model retrained with newer data can fit inside a PCCP when the change stays within the original intended use or purpose and the regulator has authorized the plan. A new clinical purpose or another change outside that boundary needs to follow the applicable route in each country.

Three records make a planned change reviewable

The IMDRF framework connects three records. Together they state what will change, how the change will be tested and deployed, and whether its expected benefits outweigh its risks.

• Description of Changes: the planned modifications, their rationale, their boundaries and the device characteristics or performance that can be verified.
• Change Plan: the data, evaluation methods, acceptance criteria, deployment steps and user communications for each modification.
• Impact Assessment: the effects of each change and all changes together, including benefits, risks, mitigations and possible effects on cybersecurity or interoperability.

Traceability joins these records. Each proposed change should point to its verification and validation plan, while version control should identify which PCCP a regulator authorized and whether a later revision needs another authorization.

IMDRF says acceptance criteria should be quantitative, statistically sound, appropriate to the risk and clinically meaningful, and that a change should not be implemented when it fails those criteria. The evaluation plan can also identify relevant data practices, inputs and outputs, performance measures and statistical tests.

Drift can trigger a review but does not validate an update

Changes in incoming data or observed performance can trigger an investigation or retraining step. A drift signal does not establish that a replacement model performs safely in the intended population or works in the existing clinical workflow.

Current guidance from the US Food and Drug Administration (FDA) lists observed data drift as one possible retraining trigger and asks manufacturers to define data management, retraining, performance evaluation and update procedures. It also asks how training, tuning and test data will remain traceable across the original and modified versions.

The evidence has to separate the trigger from the acceptance decision. A review can record the source population, collection sites, equipment, reference standard, missing-data treatment and subgroup coverage, then test the modified model against criteria set before release.

The US guidance recommends comparing a changed device with both the original version and the most recently modified version. That comparison can show whether an update corrected the targeted problem while preserving performance requirements that were not meant to change.

Regulatory effect varies by country

The 2026 IMDRF document establishes a common reference, not a single international authorization. It says implementation varies across jurisdictions, does not replace national laws and regulations, and notes that some jurisdictions may not accept PCCPs for regulatory review.

The current US FDA final guidance was issued on August 18, 2025, after an original version dated December 4, 2024, and applies to AI-enabled devices in the US 510(k), De Novo and premarket approval pathways. When the FDA has authorized a PCCP, a manufacturer may implement a change covered by that plan without a separate US marketing submission, provided the authorized methods are followed.

A product's authorization and change route must therefore be checked market by market. A separate APPI News comparison maps how the United States, Taiwan and the European Union place AI medical devices into different regulatory systems.

Data exchange remains a separate acceptance test

Health Level Seven International defines Fast Healthcare Interoperability Resources (FHIR) as a standard for exchanging health information electronically, built from modular Resources. FHIR can carry patient, observation and diagnostic-report data between a hospital system and an AI device, but it does not authorize the software change or validate the model.

HL7 says FHIR is not a security protocol and leaves authentication and authorization to the surrounding system. A technically valid exchange can still carry the wrong code, unit, timestamp or patient context, so local mappings, permissions and the meaning of each input and output need separate tests after an interface or model version changes.

APPI News has separately examined how FHIR can improve hospital-data exchange while leaving data quality and access control to each implementation. The same distinction applies during a model update: interface conformance and clinical performance require different evidence.

Users need the current version and its limits

Joint 2024 principles from the US FDA, Health Canada and the United Kingdom's Medicines and Healthcare products Regulatory Agency say device information should cover intended use, target populations, inputs, outputs, workflow effects, performance, limitations and change-management strategies. They also identify timely notification of software updates as a good practice.

The US FDA guidance makes that communication more specific for its jurisdiction. The agency recommends that labeling tell users when a device has an authorized PCCP, explain that updates may alter performance, inputs or use, and describe implemented changes through updated instructions or a version history.

Those documents place evidence and communication duties mainly on manufacturers and regulators. They do not create one worldwide rule assigning legal responsibility among a vendor, hospital and clinician when an updated model produces an error.

Hospitals still need a local release record

A regulatory authorization does not show that a new version has passed a hospital's interface and workflow checks. The broader APPI News medical AI deployment framework covers intended use, evidence, interoperability, human control and monitoring; a release record can apply those controls to one update.

• Regulatory scope: the product authorization, PCCP status and permitted changes in each market where the version will be used.
• Release identity: the model, software, dataset and interface versions, with the deployment date and affected sites.
• Acceptance evidence: the test population, equipment, measures, prespecified thresholds, subgroup results and unresolved failures.
• Workflow change: altered inputs, outputs, screens, training material, human review steps and fallback process.
• Stop and recovery: the monitoring trigger, investigation owner, authority to suspend use and the prior version available for restoration.

This five-part release record is an APPI News synthesis of the cited documents, not an IMDRF certification scheme or a legal test. Its purpose is to distinguish a regulator's authorization of a planned change from a hospital's decision to activate that version in a particular system.

Published frameworks do not measure hospital adoption

APPI News could not find comparable official data on how many hospitals worldwide have deployed software changes under authorized PCCPs at the time of writing. The available documents describe regulatory structures, manufacturer evidence and recommended transparency, not adoption rates or clinical outcomes after updates.

A PCCP can shorten regulatory handling for a covered software change where a regulator accepts and authorizes it. The evidence chain still has to show what changed, which data and tests were used, how users were notified and what happens when the release misses its acceptance threshold.