When does a healthcare model need FDA change control?

When the model is part of a device software function the FDA regulates, a change can need a new marketing submission. A predetermined change control plan, authorized with the device, lets the manufacturer make the described changes by the described method instead. Models outside device scope still need internal change control.

Can we train models on PHI?

Yes, within HIPAA's permitted uses and safeguards, or on data de-identified under 45 CFR 164.514. Either way, the MLOps records should show which data set trained which model, who could access it and where it was stored.

Do we need MLOps for a single model?

Yes, in a lighter form. Even one model needs a pinned version, a record of its training data, a way to roll back and someone watching its performance. Heavy platforms can wait; the records cannot, because they are hard to rebuild later.

AI & Machine Learning

MLOps (Machine Learning Operations)

MLOps, short for machine learning operations, is the practice of versioning, deploying, monitoring and retraining machine learning models once they run in production. It treats each model as a release with recorded data, code, metrics and approvals. In healthcare it adds controls for PHI in training data and for FDA change control.

Key takeaways

Covers data versioning, training, evaluation, model registry, deployment, monitoring and retraining
Each model version is pinned to its data, code, metrics and approval
PHI in training sets is de-identified under 45 CFR 164.514 or kept under HIPAA safeguards
Changes to device software can follow an FDA predetermined change control plan
Monitoring after deployment is part of the system, not a later project

What MLOps means

A model that works in a notebook is not yet a product. MLOps covers what happens next: which data and code produced the model, where the approved version is stored, how it is deployed, how its performance is watched and how a replacement is trained, tested and released without breaking what depends on it.

Healthcare changes three things. Training data often contains PHI, so it is de-identified or kept under HIPAA safeguards with access logged. Some models are part of a regulated device, where a change can need a new FDA submission unless an authorized predetermined change control plan covers it. And clinicians need to know which model version produced an output.

Agnotic Technologies sets up these pipelines as part of the machine learning systems it builds for clients. The service itself, and the stage gates for a hospital rollout, are on our ML development services page and the healthcare AI implementation checklist.

How is MLOps different from DevOps?

DevOps releases code. MLOps releases code plus a trained artifact whose behavior depends on data. The same code can produce a different model from different data, and a model can get worse with no code change at all because the data it sees has shifted.

That is why MLOps adds data versioning, a model registry and performance monitoring on top of the usual build and release pipeline.

What does each MLOps stage keep, and what does healthcare add?

Stage	Artifact kept	Healthcare control
Data versioning	Snapshot or hash of each training, validation and test set	De-identification record, or HIPAA access controls and logs for PHI
Training	Code version, parameters, environment and the training run log	Training data access limited to approved people and environments
Evaluation	Metrics overall and by patient subgroup, with the test set used	Clinical review sign-off and a check for performance gaps across groups
Model registry	Approved model version with its lineage and model card	Version pinning, so each clinical output traces to one model
Deployment	Release record, configuration and rollback plan	Change checked against the device's PCCP or quality system before release
Monitoring	Input distributions, output rates and performance once labels arrive	A named clinical owner and a threshold that triggers review
Retraining	New data snapshot and a comparison with the live model	Release only through the same evaluation and approval path

Facts and primary sources

FDA's final guidance on predetermined change control plans for AI-enabled device software functions recommends that a PCCP describe the planned modifications, the method to develop, validate and implement them, and an assessment of their impact.
Source: FDA guidance on PCCPs for AI-enabled device software functions
Under that guidance, modifications described in an authorized PCCP can be implemented without a new marketing submission for each one.
Source: FDA guidance on PCCPs for AI-enabled device software functions
Under 45 CFR 164.514(b), health information is de-identified either through a documented expert determination that the risk of identifying an individual is very small, or by removing the listed identifiers.
Source: eCFR, 45 CFR 164.514
The NIST AI Risk Management Framework organizes AI risk work into four functions, govern, map, measure and manage, and calls for post-deployment monitoring plans that include change management (MANAGE 4.1).
Source: NIST AI RMF core

Explore this on Agnotic

Where MLOps shows up in how we build.

AIMachine learning development services ResourceHealthcare AI implementation GlossaryModel drift GlossaryFDA software as a medical device (SaMD)ResourceHealthcare AI and interoperability glossary

Frequently asked questions

A practice. It runs on tools such as pipelines, experiment trackers, model registries and monitoring dashboards, but the substance is the process and the records: which data, which code, which approval and which version is live. The tools can change without the practice changing.