PCCPs under the Dec 2024 guidance — defensible vs vague

FDA's final PCCP guidance dropped December 4, 2024. It's the biggest change to AI/ML device regulation since De Novo, and in the fifteen months since, I've watched the early submissions sort cleanly into two groups: the ones that specified everything quantitatively, and the ones that talked about "continuous improvement." The first group is clearing. The second group is getting rejected PCCPs and being told to submit the change as a new 510(k).

The difference isn't sophistication. It's specificity. FDA reviewers need to read your PCCP and be able to determine — without asking you — whether a future change is in scope and whether the evidence you'd generate would be sufficient. Anything less is a vague PCCP, and vague PCCPs don't clear.

Here's what's in the guidance, what makes a PCCP defensible, and a worked example on a diabetic retinopathy device that shows the specificity bar.

Why the PCCP exists at all

Traditional device regulation treats any modification as a potential new submission. For devices whose value proposition is continuous improvement — the whole point of most AI-enabled SaMD — that creates a conflict between the intended behavior of the product and the regulatory mechanism.

The PCCP resolves the conflict by moving the review upstream. You describe in advance what kinds of changes you anticipate, how you'll implement and validate each type, and what ongoing performance you'll monitor. FDA accepts the plan as part of initial clearance. Subsequent changes within the plan's scope proceed without a new submission, provided you follow the protocol.

The PCCP doesn't grant unlimited modification freedom. It grants specific modification freedom, subject to specific evidence standards, that you defined and FDA accepted. The discipline is the same discipline that validates the device originally — just applied prospectively to changes you haven't made yet.

The four components FDA requires

Section IV of the December 2024 guidance specifies four components. All four must be present. A PCCP missing any of them will come back as a Refuse-to-Accept or as a hold letter with specific deficiencies.

1. Description of anticipated modifications. The scope statement. What kinds of changes are covered; what kinds aren't. FDA expects enough specificity that both reviewer and manufacturer can determine unambiguously whether a future change is in scope.

Vague: "Future modifications to improve model performance."

Specific: "Retraining the classification algorithm on additional patient data from the same imaging modality (chest X-ray) and same intended use (pneumonia detection), without changes to model architecture, input preprocessing pipeline, or output format. Modifications to intended use, target population, imaging modality, or clinical decision support function are outside the scope of this PCCP."

The more precisely you define scope, the more freedom you have within it and the clearer the boundary is for changes that require separate review. Vague scope language always gets interpreted in the narrow direction by FDA. Write it narrow. Commit to it.

2. Modification protocol. Prospective validation plan, written before the changes happen, describing exactly how each modification type will be implemented and validated.

For a retraining modification, the protocol must specify: data governance (collection protocol, labeling process, quality checks, demographic representativeness requirements), retraining procedure (architecture constraints, hyperparameter bounds, stopping criteria), evaluation dataset (minimum size, independence from training data, representativeness of intended use population), and performance thresholds that the retrained model must meet before deployment.

The modification protocol is the hardest component to write well. It's a document describing a process that hasn't happened yet, committing to specific numeric thresholds that you can't renegotiate later. Get this right and the rest of the PCCP is straightforward. Get it wrong and every future modification becomes a new submission anyway.

3. Impact assessment methodology. The procedure for determining, before deployment of any modification, whether the change alters the risk profile enough to exit PCCP scope. This section explicitly connects PCCP to your ISO 14971 file.

The methodology needs to name: which risk analysis sections are reviewed for each modification type, what triggers a change-is-out-of-scope determination, how the risk file is updated to reflect accepted changes, and who approves each step. A change that shifts the model's sensitivity/specificity trade, alters the validated patient population, or touches any safety-critical output should trigger risk review regardless of whether it nominally fits PCCP scope.

4. Updated performance testing. The evidence each modification must produce before deployment. Specific enough to be recognizable as sufficient by a reviewer who hasn't read the rest of the PCCP.

For a retraining modification: minimum test set size, patient population requirements, statistical analysis approach, minimum performance thresholds on primary and secondary endpoints, stratified analysis required for demographic subgroups identified in the risk analysis. If you can't list the specific thresholds, the component isn't finished.

Worked example — diabetic retinopathy retraining PCCP

Class II SaMD, detects diabetic retinopathy from fundus photographs. Cleared via 510(k) with performance characterized on 10,000 images from three clinical sites. Manufacturer anticipates retraining periodically as new data accumulates.

Scope. Retraining of the classification model on additional fundus photography data from patients with the same intended use (diabetic retinopathy screening), no changes to model architecture, image preprocessing, or clinical output categories (no DR / mild / moderate / severe / proliferative). Training data must be collected under IRB-approved protocol and labeled by certified ophthalmologists using the ETDRS grading scale. Changes to intended use, output categories, imaging modality, or model architecture are out of scope.

Modification protocol.

1. Training data governance: minimum 5,000 new images, multi-site collection (at least 3 sites not represented in original training data), demographic distribution within 15% of intended use population baseline on age, sex, and race.
2. Retraining procedure: same architecture, same preprocessing pipeline, same loss function. Learning rate schedule per model card. Early stopping on held-out validation set with patience of 5 epochs.
3. Test set: minimum 2,000 images, independent from training data, collected after training data freeze, demographically representative of intended use population.
4. Deployment gating: retrained model must meet or exceed all thresholds in Section 4 before deployment. Approval by named Quality Manager and Chief Medical Officer after review of modification report.

Impact assessment. Pre-deployment review of ISO 14971 risk analysis sections covering: false negative rate for moderate-or-worse retinopathy, false positive rate for unnecessary referrals, performance in subgroups named in hazard analysis (age ≥65, patients with cataracts, Fitzpatrick IV–VI skin types). Any change in primary endpoint performance >3% versus original cleared performance triggers full risk analysis review. Any demographic subgroup falling below minimum threshold triggers out-of-scope determination and submission as new 510(k).

Updated performance testing. Primary endpoint: AUC for moderate-or-worse retinopathy detection ≥0.92 on test set. Secondary: sensitivity ≥0.87 and specificity ≥0.89 at the clinical operating threshold. Stratified analysis by age (≥65 vs <65), sex, and presence of cataracts. Fitzpatrick stratification I–III vs IV–VI for dark-skin performance. Each stratum must meet minimum thresholds defined in the risk analysis.

Every decision in that PCCP has a number attached to it. That's the bar. Reviewers should be able to run the protocol in their head and determine whether the output would be acceptable. If they can't, it's vague.

The failure modes I see in early submissions

Three patterns dominate the PCCP deficiency letters I've seen since the guidance finalized.

Scope written to maximize flexibility. "Modifications that improve device performance or expand clinical utility." This reads to reviewers as "any change we want." It gets rejected as insufficiently specific, and the modification the team actually wanted to make now has to go in as a new submission anyway. Scope should be narrow and committed. Flexibility comes from covering multiple narrow modification types, not one broad one.

Protocol without numbers. "Retrained model will be evaluated against baseline performance." What threshold? What baseline? What statistical test? No numbers means the reviewer can't determine whether your future evidence will be sufficient. They have to assume it won't be.

Impact assessment disconnected from the risk file. PCCP references "risk analysis review" without specifying which sections, which hazards, which controls. The impact assessment then doesn't connect mechanically to the risk file. Reviewer reads the disconnect and writes it up. Fix: name the specific hazards, the specific risk controls, and the specific thresholds in both the PCCP and the risk file, with explicit cross-references.

How PCCP connects to the DHF and risk file

A PCCP is not a standalone document. It's a layer of your design history connecting to risk analysis, validation records, and post-market monitoring.

Your risk management file references the PCCP for every risk control involving post-market monitoring or model performance thresholds. Your validation documentation includes the test protocols called out in the modification protocol. Your post-market monitoring plan references the performance thresholds that trigger PCCP impact assessment.

When a PCCP modification is executed, the documentation it generates — impact assessment, updated performance testing results, risk file updates — becomes part of the DHF. Each model iteration has its own evidence record, connected to the PCCP that authorized it and the original validation that established baseline.

MANKAIND structures this documentation model from the start. PCCP, risk analysis, and validation exist as connected layers of the same engineering record. When a modification is documented, it connects to the risk controls it touches, the performance thresholds it must meet, and the design history it extends. The team owns every modification decision. The platform ensures the evidence record is complete and the cross-references are live, not archaeological.

Frequently asked questions about PCCPs

What is a Predetermined Change Control Plan (PCCP)?

A PCCP is an FDA-authorised plan that describes specific planned modifications a manufacturer intends to implement for an AI/ML-enabled medical device after market authorisation — without requiring a new 510(k), De Novo, or PMA submission for each change, provided the changes stay within the pre-specified modification protocol.

When did FDA finalise PCCP guidance?

FDA finalised the PCCP guidance in December 2024. It represents the most significant change to AI/ML SaMD regulation in years, providing a structured pathway for continuously-learning medical device software.

What are the required components of a PCCP?

A PCCP must contain four components: a description of the planned modifications, a modification protocol that specifies how modifications will be implemented and validated, an impact assessment evaluating effects on device safety and effectiveness, and ongoing performance monitoring commitments.

How does a PCCP connect to the risk management file?

Every modification contemplated in the PCCP must be evaluated against the ISO 14971 risk management file. The modification protocol should reference hazard analysis outcomes, residual risk evaluations, and the risk controls affected by each planned change — creating a live link between the PCCP and the risk file.