What must a PCCP actually contain?
According to the guidance, a robust plan rests on five essential principles:
- Focused and bounded. Changes must be specific enough to assess, and must stay within the device’s original intended use.
- Risk-based. The plan has to be driven by, and integrated into, the manufacturer’s existing risk management process.
- Evidence-based. Data generated across the Total Product Lifecycle (TPLC) must continue to demonstrate that benefits outweigh risks.
- Transparent. Intended users need clear, timely information about how the software performs before and after each change.
- TPLC-oriented. The plan should keep incorporating new data and user input throughout the product’s life, not just at launch.
Structurally, a PCCP is built from three interlocking parts. The Description of Changes lists exactly which modifications are planned and why, including whether they will be rolled out identically across all deployed devices (a homogeneous, or “global,” change) or tailored to a specific clinical site or patient population (a heterogeneous, or “local,” adaptation). The Change Plan then supplies the technical backbone: verification and validation methods, pre-defined acceptance criteria, and a documented procedure for what happens if a change fails to meet those criteria, since a failed change must not be deployed. Finally, the Impact Assessment ties the two together, weighing the anticipated benefits and risks of each change individually and cumulatively, and confirming that the device’s safety and effectiveness remain intact once everything is implemented at once.
Version control deserves particular attention here. Because a PCCP effectively pre-clears changes that would otherwise trigger a new submission, any later revision to an already-authorised plan is generally treated as its own safety-relevant change, meaning it will likely need re-authorisation, though the guidance notes that some jurisdictions may permit minor edits without going through that process again.
Why manufacturers should care?
For notified bodies and regulatory authorities, PCCPs promise fewer duplicate submissions and earlier, more structured dialogue with manufacturers. For manufacturers themselves, the appeal is administrative: once a plan is authorised, subsequent updates that fall within its scope can reach the market without a new regulatory filing, which the guidance suggests can meaningfully shorten time-to-market for iterative software improvements.
That efficiency comes at a cost, however. Preparing a PCCP demands more extensive planning, risk analysis and documentation than a conventional submission, which can lengthen the initial filing timeline even as it shortens every filing after that. IMDRF also flags that adoption is uneven. Not every jurisdiction currently accepts PCCPs, and where reliance frameworks exist, manufacturers remain responsible for reconciling differing definitions of what counts as a “significant” change across markets.
Link to the document: