FDA Publishes Two PCCP Hypothetical Case Examples in October 2026: How Predetermined Changes for Artificial Intelligence-Enabled Devices Can Be Written into Regulatory Submissions

Published: October 22, 2026, 13:31 | Category: Registration and Market Access

On October 20, 2026, the U.S. Food and Drug Administration (FDA) added a new page under its Premarket Submissions section titled Novel Medical Devices with Predetermined Change Control Plans: Hypothetical Case Examples. The page presents two hypothetical cases that run through the full process: a hospital-local sepsis alert system and arrhythmia detection software used in inpatient ECG telemetry. Neither case represents a real product, but each step is written at the granularity of a real submission, including data sources, validation methods, deployment conditions, and post-market monitoring metrics. The cases translate the three parts of a Predetermined Change Control Plan (PCCP) - modification description, modification protocol, and impact assessment - into specific steps: pre-specified acceptance criteria, lock-then-validate, automatic blocking of deployment if criteria are not met, and retention of audit trails and version identification. FDA also states that the cases are for illustration only and are not a complete PCCP template.

What PCCP Is and Why It Is Repeatedly Discussed

The legal basis for a PCCP is Section 515C of the Federal Food, Drug, and Cosmetic Act. Manufacturers may include a plan in a 510(k), De Novo, or PMA submission to obtain pre-authorization for specified future device modifications. Once the plan is authorized, a modification that falls within the described scope and is implemented according to the modification protocol does not require a separate submission for each change. FDA states on the page that this mechanism allows improvements to authorized devices to reach clinical use more quickly while preserving the evidence chain for safety and effectiveness. The significance is greatest for software and artificial intelligence-enabled devices, where model iteration, threshold adjustment, and retraining are routine.

Case One: Localization Written Firmly Within Scope

The sepsis alert system starts with a global model trained on cross-institutional data. The case defines three modifications: adjusting the relative weight of nursing-record fields in the model; locally fine-tuning the output layer using the deploying hospital's own electronic medical record data; and adjusting alarm thresholds within a predetermined range. All three modifications have defined boundaries: the base architecture, feature set, and risk calculation method cannot change; only structured fields may be used; free text is excluded.

The implementation path is also detailed. The hospital first verifies whether its historical data meet minimum sample size and quality requirements. It then trains and locks the weights, validates them using a previously sealed independent test set, deploys through a controlled software update within the quality system, and initiates hospital-level post-market monitoring to track alarm positive predictive value, sensitivity, and clinical response. The case also specifically addresses dependencies among the three modifications: the first changes input weights and therefore affects risk scores and alarms; the second affects the third; the implementation order is therefore fixed as one, two, three. This level of granularity is precisely where reviewers are most likely to ask follow-up questions.

Case Two: Unsupervised Automatic Iteration

The arrhythmia detection software is more aggressive. The model is periodically retrained on accumulated newly labeled ECG data, and retraining is automatically triggered by a predetermined data volume without manual initiation. After each retraining, classification thresholds are re-evaluated so that sensitivity and specificity for each arrhythmia type remain within the range declared in the labeling.

Automatic validation runs, and only if all acceptance criteria are met is the update pushed to all installed systems. If any criterion is not met, deployment is blocked, the system alerts the manufacturer, and the device remains unchanged. The case also requires the interface to display the current device and model version and the most recent update time, requires the instructions for use to be updated accordingly, and requires a complete audit record: training set composition and version, validation results, deployment time, and model identification. Post-market monitoring sets drift thresholds, and performance outside the boundary triggers manual review. FDA directly identifies the risk in this section: the entire modification, validation, and deployment process has no human in the loop, so controls must be built into the protocol in advance rather than remediated afterward.

Cases Cannot Be Used as Templates

The page states clearly that these cases do not contain all information required for a PCCP submission; they only demonstrate key concepts, and the amount of information is not equivalent to a public device summary. All examples rest on three preconditions: the modifications would otherwise require a new marketing submission; after modification the device remains within its intended use; and for 510(k) devices, the device remains substantially equivalent to the predicate. If any one condition is missing, PCCP cannot be used.

Read Together with the Authorized Device List

The main PCCP page in the same section maintains a list of authorized devices, arranged by final decision date and covering the 510(k), De Novo, and PMA pathways, with the earliest entries traceable to 2023. The list itself is a searchable precedent library: for similar products, it is possible to check which modifications were previously written into a plan and under which product code. For teams preparing their first PCCP submission, this list plus the two cases essentially form a comparable drafting reference.

Sources and Applicability Notes

Sources: U.S. Food and Drug Administration, Novel Medical Devices with Predetermined Change Control Plans: Hypothetical Case Examples, content updated October 20, 2026, https://www.fda.gov/medical-devices/premarket-submissions-selecting-and-preparing-correct-submission/novel-medical-devices-predetermined-change-control-plans-hypothetical-case-examples; U.S. Food and Drug Administration, Predetermined Change Control Plans, content updated October 20, 2026, https://www.fda.gov/medical-devices/premarket-submissions-selecting-and-preparing-correct-submission/predetermined-change-control-plans; U.S. Food and Drug Administration, Predetermined Change Control Plans for Medical Devices (draft guidance, August 2024, Docket No. FDA-2024-D-2338), https://www.fda.gov/regulatory-information/search-fda-guidance-documents/predetermined-change-control-plans-medical-devices.

Verification scope and access date: The three pages above were accessed and checked on October 22, 2026, together with the CDRH New update list entry for that day. Statements in this article about the case settings, the three modifications, the dependency order, automatic deployment, and audit requirements are all taken from the original case page.

Applicability note: This article is an interpretation of FDA public materials and does not constitute a conclusion or commitment regarding any specific product, company, or regulatory application. Whether a PCCP can be authorized depends on the specific device, intended use, and evidence, and is subject to FDA's original text and formal review comments. Relevant pages may change with subsequent updates.

AIMEILI Regulatory Interpretation

FDA's two hypothetical cases show that a credible PCCP is not a general statement that the device may be updated. It is a controlled, testable, and auditable commitment. For regulatory affairs teams, the practical lesson is to separate the submission into three linked parts: a modification description that defines the boundary of change; a modification protocol that specifies triggers, data requirements, training, validation, acceptance criteria, deployment, and rollback; and an impact assessment that explains why the changes remain within the intended use and, for 510(k) devices, why substantial equivalence is preserved.

The sepsis case is particularly relevant to products that require site-specific tuning. The plan should identify which parameters may be localized, which data sources are permitted, which fields are excluded, what minimum sample size and quality thresholds apply, and how the locked model is validated on an independent set. The dependency order among modifications must be explicit because a change in input weighting can alter risk scores and alarm behavior, and a threshold change can interact with local fine-tuning. Reviewers will expect the protocol to show that these interactions are understood and controlled.

The arrhythmia case is relevant to devices that retrain periodically. The key regulatory design is to pre-specify the automatic trigger, the validated data pipeline, the acceptance criteria, and the deployment gate. If any criterion fails, deployment must be blocked automatically, the manufacturer must be alerted, and the device must remain in its prior state. The interface must display device and model version and the latest update time; the instructions for use must be updated; and the audit trail must capture training set composition and version, validation results, deployment time, and model identification. Post-market drift thresholds and manual review triggers should be written into the plan, not added later.

Teams should also confirm the three preconditions before drafting: the modifications would otherwise require a new marketing submission; the modified device remains within the intended use; and for a 510(k) device, substantial equivalence to the predicate is maintained. If any condition is not met, the change should follow a traditional submission pathway rather than a PCCP.

Business Impact for Manufacturers, Distributors, CROs and Regulatory Affairs Teams

For manufacturers, the cases support a more predictable lifecycle model for artificial intelligence-enabled and software-based devices. A well-scoped PCCP can reduce the need for repeated submissions for routine model updates and site-level tuning, shorten time to clinical deployment, and make post-market performance management more transparent. It can also strengthen competitive positioning because customers increasingly ask how updates will be controlled, validated, and audited after authorization.

For distributors and market access teams, the authorized device list and the two cases provide a practical reference for explaining to hospitals and procurement teams how a device may change after approval and what safeguards apply. For CROs and regulatory consultants, the cases set a higher bar for dossier drafting: modification protocols must be detailed enough to be operational, acceptance criteria must be objective, and audit trails must be designed before submission.

The business risk is equally clear. An overly broad PCCP description may invite reviewer concern about insufficient control, while an overly narrow plan may provide little lifecycle benefit. Companies should align regulatory, quality, software engineering, clinical, and post-market surveillance functions early, because the PCCP commitments will become binding operational requirements. The most efficient approach is to treat the PCCP as part of the quality management system from the outset, with version control, change control, validation records, deployment gates, and post-market monitoring linked together.