How an FDA predetermined change control plan lets AI device updates ship without new submissions: the three parts, modification protocol and release controls.
FDA can authorize future model changes before a manufacturer develops the updated model. Its final guidance (issued December 2024, updated August 2025), Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions, describes how a predetermined change control plan supports that approach. Engineering teams must turn anticipated updates into testable boundaries, release evidence, and deployment controls. The practical work covers defining permitted changes, selecting validation methods, and deciding whether an update can ship under the authorized plan.
A PCCP lets a manufacturer obtain authorization for specified future modifications without a new marketing submission for every individual change. That authorization depends on both the modification staying within scope and the manufacturer following the agreed protocol. Passing a performance test alone doesn't establish that an update is covered.
FDA reviews the plan within a marketing submission. For a new device, that means planning future updates alongside the initial device evidence rather than assuming the team can document its update strategy after deployment. The mechanism is optional, as FDA explains in its January 2025 webinar on the final guidance.
The CTO's question is concrete: what evidence permits this particular release? Answering it requires an identifiable change class, an applicable validation procedure, and an acceptance decision traceable to the authorized plan.
We recommend expressing those requirements as release-gate rules. Regulatory staff determine the authorization boundary; engineering implements the controls; quality reviewers verify that the release record demonstrates conformance. The manufacturer remains responsible for the resulting device.
For teams connecting device software to broader clinical systems, healthcare AI and integration work adds another design consideration: a permitted model change can still affect downstream workflows. Keep those dependencies visible in the impact analysis rather than treating the model artifact as the entire product.
Decide what evidence authorizes a release before deciding how frequently to retrain.
FDA organizes the plan around Description of Modifications, Modification Protocol, and Impact Assessment. Its final guidance document emphasizes specific modifications that can be verified and validated, alongside version control, maintenance, labeling, and post-authorization considerations.
The sections should share identifiers. If a modification appears in the description, reviewers should be able to follow it through the applicable protocol, associated hazards, acceptance criteria, and implementation records. A generic risk assessment attached to an unrelated testing procedure leaves that relationship unresolved.
| PCCP section | What it must contain | Engineering evidence behind it |
|---|---|---|
| Description of Modifications | Specific anticipated changes and their boundaries | Change-class identifiers, permitted inputs, affected software components, excluded behavior |
| Modification Protocol | Methods for developing, validating, and implementing each change | Data procedures, training configuration, evaluation methods, release criteria, deployment procedures |
| Impact Assessment | Benefits, risks, mitigation measures, and effects of the planned changes | Hazard analysis, workflow assessment, regression evidence, mitigation verification |
Start with the Description of Modifications. Define the portions of the device that may change and the boundaries that remain fixed. Describing a change as improved performance leaves unanswered which inputs, populations, outputs, or operating conditions may differ.
The Modification Protocol supplies the repeatable method for executing the change. It should make the release decision reproducible rather than dependent on an engineer's judgment after seeing favorable results.
The Impact Assessment addresses consequences. For example, an improvement in sensitivity may change false-positive behavior and the clinical review workload. Engineering and clinical reviewers should examine those effects together, including whether combined modifications introduce risks that wouldn't appear when each change is considered separately.
These are linked submission components, not an asserted sequence in which FDA must review them. Drafting them together helps expose unsupported assumptions before they become implementation commitments.
FDA's Modification Protocol recommendations connect data management, retraining, performance evaluation, and update procedures. Update procedures cover software verification and validation, when and how updates are implemented, communication and transparency to users, and device monitoring.
For data management, specify eligible data sources, inclusion and exclusion criteria, provenance, labeling procedures, and quality checks. Engineering should retain a versioned dataset manifest so reviewers can identify exactly which records supported an update.
Separate development data from locked evaluation data. Access controls and documented dataset assignments should prevent developers from turning the evaluation set into another tuning set.
For retraining, define triggers, permitted software or model components, configuration controls, and safeguards against overfitting. Record the training code, dependencies, preprocessing, and model artifact together. A reproducible training run can still produce an unacceptable device, so reproducibility and clinical acceptability require separate checks.
Performance evaluation should identify study designs, metrics, statistical methods, and acceptance thresholds before the candidate model is evaluated. Include clinically relevant sensitivity, specificity, calibration, subgroup behavior, and false-positive and false-negative consequences where applicable.
The release procedure must also answer operational questions:
Implementation controls: Specify who approves deployment, which device versions receive the update, and how compatibility is checked.
Communication evidence: Retain applicable labeling changes, user notices, and records showing which update information was issued.
Monitoring and recovery: Define signals, review responsibilities, stop conditions, and criteria for restoring an acceptable version.
A statement that the model will be retrained on new data leaves the essential decisions unspecified. The protocol must establish which data qualify, which tests support release, and what stops deployment.
Device specifications must continue to meet their specified acceptance criteria after the change. Evaluation must also address whether specifications that the update wasn't intended to change have degraded.
A PCCP can be established through a traditional or abbreviated 510(k), a De Novo request or a PMA submission, but not through a Special 510(k). FDA has said a Special 510(k) may be appropriate later to modify an already authorized PCCP. Choose the submission strategy before drafting detailed update permissions, because the plan must fit the device and its authorization boundary.
| Submission pathway | PCCP planning boundary |
|---|---|
| 510(k) | Align planned modifications with the device's intended use and the substantial-equivalence evidence |
| De Novo | Align modifications with the device and classification being requested |
| PMA | Demonstrate continued safety and effectiveness for modifications to the approved device |
| Special 510(k) | Not used to establish a new PCCP; may be appropriate to modify an authorized PCCP when well-established methods can evaluate the change |
For PMA devices, a change consistent with an FDA-approved PCCP under section 515C may avoid a new PMA supplement. FDA's performance evaluation overview for evolving AI-enabled devices connects that regulatory mechanism to ongoing performance evaluation.
A U.S. authorization doesn't establish equivalent treatment in another jurisdiction. FDA's AI-enabled device PCCP guidance text describes the U.S. mechanism, not a transferable international approval.
Maintain a market-specific change decision alongside the common engineering evidence. The same validation package may inform several assessments, but each market needs its own release determination.
In SaMD engineering, the practical distinction is between a shared build and permission to distribute it. Regulatory owners should establish the applicable pathway and geographic boundary before engineering enables deployment.
An out-of-plan update requires assessment under the applicable change rules. It doesn't automatically require a new submission merely because the PCCP doesn't cover it, and engineering shouldn't make that determination from test results alone.
FDA's guiding principles for PCCPs emphasize bounded modifications, evidence, and predefined performance criteria. Our engineering recommendation is to implement those commitments as a controlled release process.
The model registry should identify the model artifact, training-code version, dataset manifests, preprocessing configuration, evaluation results, and applicable PCCP modification identifier. Store the approval decision against that exact bundle, not against a mutable model name.
CI/CD should assemble evidence and block promotion when required checks fail or records are missing. A passing pipeline shouldn't bypass independent review or decide regulatory scope without an authorized decision.
For ownership, assign engineering to artifact integrity and automated checks, clinical reviewers to clinically meaningful performance interpretation, quality to record completeness, and regulatory staff to authorization coverage. Adapt those responsibilities to the manufacturer's organization, but leave no approval implicit.
Consider an imaging device whose authorized plan permits retraining with additional eligible data while preserving its clinical task and specified input boundaries. This is a hypothetical example, not a reported authorization or outcome.
Register the candidate: Link the new data manifest, labeling records, training configuration, and resulting model.
Evaluate the change: Run the prespecified locked evaluations, subgroup checks, regression tests, and applicable cybersecurity and interoperability checks.
Review coverage: Confirm that the actual modifications match the authorized change class and that all acceptance criteria are satisfied.
Approve and observe: Record approval, distribute through the controlled update procedure, and activate the defined monitoring and recovery process.
If the candidate requires an input outside the permitted boundary, stop the PCCP release route even if aggregate performance improves. Regulatory staff must assess that different change.
Within an AI-assisted development framework, keep generated code and automation subject to the same evidence and approval requirements.
A release record should let an independent reviewer reconstruct what changed, what was tested, and who authorized deployment.
FDA's preference for limited, specific, verifiable modifications supports a practical engineering argument: a narrower plan can reduce release-time ambiguity. That's an operating judgment, not a measured promise about review or deployment speed.
A broad plan may require evidence across more data sources, architectures, workflows, and failure modes. Every additional permission creates another validation obligation or boundary decision.
Start with recurring changes whose evidence requirements the manufacturer can define credibly. Keep model architecture, training-data eligibility, intended purpose, workflow effects, and performance boundaries explicit.
That approach has a trade-off: an unexpected product direction may need a separate regulatory assessment. Accepting that constraint can be more useful than promising flexibility that the team can't validate.
Treat the authorized plan as a controlled operating commitment. Reference it in change approval, incident response, model registration, and audit records so engineers don't maintain a separate, unofficial definition of what they can ship.
A predetermined change control plan converts anticipated model updates into an advance-reviewed scope and evidence process. Engineering must preserve the connection between that scope, the implemented change, and the release decision.
The AI-enabled device guidance reaches beyond the narrow idea of a model learning continuously in production. For CTOs, the useful investment is a controlled update system with traceable versions, defensible evaluation, explicit ownership, and usable recovery procedures.
Ekipa works with MedQAIR as its compliance partner.
This article is general information, not legal or regulatory advice.
It authorizes specified future modifications implemented according to an FDA-reviewed plan. It doesn't authorize unrestricted model evolution or waive the plan's acceptance criteria.
No. The guidance identified above addresses AI-enabled device software functions, so teams shouldn't treat it as blanket coverage for non-AI software. FDA's separate August 2024 draft guidance covers PCCPs for medical devices in general. Its relevance also isn't limited to continuously learning models.
Compare the actual change and implementation evidence with the authorized description and protocol. If either falls outside those boundaries, regulatory staff must assess the applicable change pathway before release.
Not to establish one. A new PCCP is established through a traditional or abbreviated 510(k), a De Novo request or a PMA submission. A Special 510(k) may be appropriate in some cases to modify a PCCP that is already authorized.
No. Keep device release evidence connected to quality records, and assess privacy and security obligations separately. Model traceability alone doesn't demonstrate HIPAA compliance.
No. A U.S.-authorized plan doesn't grant permission in other markets. Maintain jurisdiction-specific decisions even when teams reuse the underlying validation evidence.
Book a consultation with Ekipa's HealthTech engineers to review your proposed change boundaries, validation evidence, and release-gate design.
How to integrate with Epic EHR: FHIR vs HL7 v2, Epic developer programs, hospital approval, sandbox-to-production gates and the blockers that stall teams.
A practical HL7 v2 to FHIR migration roadmap: side-by-side running, segment-to-resource mapping, tooling, semantic testing and safe retirement of old feeds.
How to automate prior authorization under CMS-0057-F: the 2026 and 2027 deadlines, FHIR APIs and Da Vinci guides, ONC HTI-4, and where AI should stop.
Connect with our team to explore how AI expertise can transform your business.