Medical AI

Medical AI covers machine learning applied to clinical purposes, including detection, diagnosis, triage, treatment recommendation, and monitoring. A recurring regulatory question is how evidence of safety and effectiveness carries forward when a device’s software changes.

FDA’s discussion of AI-enabled medical devices identifies a challenge for a framework built around evaluated configurations: adaptive software and later model updates can alter the behavior that was reviewed. The following discussion concerns the United States and software regulated as a medical device; other jurisdictions have their own systems.

Why adaptiveness is the problem

A regulated device is evaluated for a particular intended use and configuration. Changes can require further assessment or a new submission depending on their nature and risk. FDA’s software-change guidance addresses that decision; not every modification requires a separate premarket review.

Retraining on recent patient data produces a candidate update, not an automatic clinical improvement. Changes to data, preprocessing, or learned parameters can alter both benefits and harms. Validation must establish whether the candidate meets its intended use and acceptance criteria; the relevant safety evidence cannot simply be assumed to carry over from the previous version.

FDA’s August 2025 PCCP guidance recommends describing planned modifications, how they will be developed, validated, and implemented, and their impact. The agency reviews that predetermined change control plan as part of a marketing submission. A modification implemented within an authorized PCCP can avoid an additional submission for that change; a change outside its scope needs the applicable change assessment. The guidance contains nonbinding recommendations and does not replace statutory or regulatory requirements.

The table traces the development of a mechanism for planned changes alongside development and transparency principles. FDA’s March 2024 publication, Artificial Intelligence and Medical Products: How CBER, CDER, CDRH, and OCP are Working Together, also describes coordination across its centers. For the PCCP recommendations discussed here, use the August 18, 2025 guidance linked in References rather than treating the December 2024 row as the current endpoint.

What it asks of an ML team

These engineering practices help produce evidence for review. Their implementation depends on intended use, the device, and applicable requirements; the PCCP guidance does not make every practice a universal legal mandate.

1. Plan the changes you intend to make. “We will retrain when we have more data” is not a plan; what may change, how it will be validated, and what would be out of scope is. This is the opposite of the usual habit of deciding retraining policy after launch.
2. Version everything that determines behavior — data, preprocessing, weights, thresholds — because a claim about safety attaches to a specific configuration, and “which version saw this patient” must be answerable. The general practice is reproducible pipelines; here it is an evidentiary requirement.
3. Retain decisions and inputs. A clinical question about a past output is about one patient on one date, and that must be reconstructable — see audit log.
4. Monitor population changes and their effects. Patient mix, scanners, protocols, or input pipelines can change. Performance may decline, remain stable, or improve, and failures may emerge gradually or abruptly. Distribution monitoring signals a need to investigate; it does not measure clinical impact by itself. Pair it with performance and safety monitoring appropriate to the intended use. See drift detection.

Documenting intended use, evaluation, and limitations in something like a model card is a reasonable practice here and is not a substitute for the regulatory submission — the two have different audiences and different consequences.

Three things that get assumed wrongly

• That statistical performance is clinical performance. Discrimination and calibration on a held-out set say nothing about whether use of the output improves patient outcomes, which is a different study with a different design.
• That a decision-support role removes the stakes. A recommendation a clinician can override still shapes the decision, and “a human is in the loop” is only a safeguard if that human has the information and the time to disagree.
• That improving the model is always allowed. An update that makes average accuracy better can still be a change requiring review, and deploying it because the metric improved is the specific failure the predetermined-change mechanism exists to prevent.

The general framing for all of this — who is accountable, what evidence exists, what is reviewed when — is AI governance; medical AI is the case where it is enforced by an agency rather than by internal policy, which makes it a useful place to see what the practices look like when they are not optional.

This entry explains a term and is not regulatory or medical advice.

References:

• FDA, Artificial Intelligence in Software as a Medical Device — regulatory background and guidance history
• FDA, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions (August 18, 2025)