To PCCP or not to PCCP: Part 2 – What does a PCCP need to include under MDR?

In our previous blog on the topic, we covered the current situation for PCCPs and expectations for future EU and UK regulatory requirements. Now let's look at the level of evidence required, and what you should consider before deciding 'to PCCP' under MDR.

What evidence should be in the technical file at initial assessment if you want to use a PCCP?

While the below remain suggestions for now, we anticipate that they will be the elements required, at a minimum, for EU and UK markets.

1. Clearly scoped description of modifications

Notified Bodies (for EU MDR, and Approved Bodies for UK MDR) will want to see that your pre-determined changes are specific and bounded. Loose plans for future modifications are likely not going to hit the mark. At a minimum, the following should be outlined in the technical documentation:

• List of modifications you want included in the PCCP (e.g. performance improvements via retraining, new scanners, new sub-populations)
• For each modification type:
  • clear inclusion criteria (what counts as “in-scope” for the PCCP)
  • explicit exclusions (what will not be handled via PCCP and will instead require a new conformity assessment or change request)
  • confirmation that the intended purpose of the device(s) is not modified from the proposed changes

2. Detailed modification protocol with evidence

Clear, methodologically sound, and consolidated protocols for modifications will enable Notified Bodies to get a strong understanding of the modifications a manufacturer intends to make. It is necessary to show how you will generate and assess evidence for each planned change. It should cover, where applicable:

• Data management practices
  • Data sources for retraining and validation, including data provenance and quality criteria
  • Inclusion/exclusion criteria, labelling processes, management of missing data
  • Dataset versioning and governance
  • Measures to mitigate bias and ensure representativeness, aligned with AI Act requirements on data governance and discriminatory impact assessment
• Retraining practices
  • Training pipelines and tooling, including configuration
  • Criteria for when retraining is triggered (e.g. monitoring thresholds, new data volume, performance drift)
  • Separation of training/validation/test datasets
• Performance-evaluation protocols
  • Pre-defined metrics (e.g. sensitivity, specificity, AUC, calibration metrics)
  • Statistical methods and acceptance thresholds, grounded in the state of the art - including how you will judge non-inferiority or required improvements
  • Subgroup analyses, particularly where the PCCP envisages new sub-populations
  • Stress testing/robustness evaluation and, where appropriate, human-factors validation and usability testing
  • A plan for maintaining test logs and formal test reports for each change
• Update and deployment procedures
  • How updated models will be packaged, deployed, rolled back, and monitored in the field (including versioning visible to users)
  • Cybersecurity controls around updated mechanisms
  • How you will ensure traceability between:
    • a specific PCCP change
    • the data and training run that produced it
    • the technical and clinical validation that supports the updated device’s deployment

3. Impact assessment and links to GSPRs

Changes to a device can impact its risk profile and performance. Similar to post-market requirements for EU & UK MDR, for each type of pre-determined change, the technical documentation should be updated to include methods for determining:

• Hazard and risk analysis of the change type
  • New or increased risks associated with the change (e.g. new failure modes, new bias risks, operational risks)
  • Justification of why these risks can be managed within the existing risk-benefit profile
• Mapping to General Safety and Performance Requirements (GSPRs)
  • Identification of which GSPRs are most impacted by each change type (e.g. clinical performance, robustness, cybersecurity, usability)
  • Evidence that the PCCP protocol ensures continued conformity with these requirements for each future update
• Human oversight and usability impacts
  • Analysis of how updates might change user interaction, and how human-oversight mechanisms will remain appropriate

4. Aligned post-market surveillance procedures

A credible PCCP depends on strong post-market surveillance, in addition to the current EU & UK MDR requirements, manufacturers should also consider: 

• A monitoring plan specific to the AI component and PCCP changes: real-world performance metrics, triggers for investigation and update, and mechanisms to detect drift and bias
• Logging and traceability: system logs sufficient to reconstruct model behaviour and performance for specific time periods and versions
• Feedback loops into retraining: how PMS data feeds into the data-management and retraining processes described in the PCCP

Things manufacturers should consider before committing to a PCCP

When you add up the evidence above, a PCCP can be a sizeable investment. When deciding whether to go down the PCCP route, ask yourself:

1. Is the intended purpose of the device stable enough? PCCPs work best when the intended purpose of the device is stable, even if you expect ongoing optimisation
2. Can you define objective criteria for changes? If you can’t express, in measurable terms, what a “good” update looks like (and when you’d roll one back), a PCCP will be hard to defend
3. Do you have the MLOps and data-governance maturity to support it? Notified Bodies will expect your PCCP protocol to be grounded in robust processes and methods
4. Are your Notified Bodies ready to engage on PCCPs? There will be a learning curve. Starting with a narrowly scoped PCCP (e.g. for one modification type) may be more productive than trying to pre-plan everything in one swoop

A credible PCCP answers three questions up front: what can change, how you’ll prove it works, and how you’ll catch it when it doesn’t. Do that well and, rather than a series of one-off change requests, updates to your device will become a controlled lifecycle you can scale.