PCCP: How to Plan Medical Software Changes in Advance and Get Regulatory Approval Without Going Back to the Authority Again and Again
IMDRF recently published its final document on PCCPs, Predetermined Change Control Plans. N90:2026 is the document meant to give this field a common language across jurisdictions, after several years in which each authority treated the subject a little differently. If you have medical software that gets updated, and certainly if it is an AI or machine learning based product, it is time to get to know this tool in depth, not just at the headline level.
What a PCCP actually is, and the problem it solves
Medical software changes. That is its nature. You improve an algorithm, add support for a broader patient population, refine accuracy. The problem is that in most cases, a change like this to software that has already been cleared requires a new regulatory submission, and that process takes time, while the software is already on the market and customers are waiting for the update.
A PCCP solves this in a fairly simple way. Instead of submitting each change separately after it has already happened, you submit a plan in advance that describes which changes you are planning, how you will test them, and how you will know they are safe. The regulatory authority reviews and approves the plan once. From the moment of approval, you can implement the changes described in it without going back for separate approval, as long as you operate exactly according to what was defined.
It is important to understand the boundary: a PCCP is not a license to change anything. The changes must stay within the device's original intended use. If you want to expand use to an entirely new population or change the intended purpose, that is no longer a PCCP; it is a new submission.
The five principles behind it all
IMDRF defines five guiding principles for a strong PCCP, and they are worth knowing before getting into the formal structure, because they are the basis from which all the other requirements are derived:
Focused and bounded. The changes are described in enough detail to allow an assessment of safety and effectiveness, and they stay within the limits of the original intended use.
Risk-based. The intent, design and implementation of the PCCP are guided by a risk-based approach that is integrated into your existing risk management framework, not detached from it.
Evidence-based. Throughout the total product lifecycle, evidence is gathered showing that the benefits continue to outweigh the risks.
Transparent. Intended users need to know what is happening, before and after each change. Labeling that reflects only what has actually been implemented, not what is planned, is an explicit requirement.
A TPLC (Total Product Lifecycle) perspective. The PCCP is a living plan throughout the life of the product, with ongoing feedback from users and integration of new data as it accumulates.
The three components every PCCP must include
Description of Changes
Here you write exactly what is planned, at a level of detail that allows the authority to assess continued safety. Two aspects that are easy to miss here deserve special attention:
Homogeneous versus heterogeneous. The PCCP needs to state whether the change will be implemented uniformly across all devices on the market (a homogeneous change, or "global adaptation"), or implemented differently according to the characteristics of a specific clinical site or individual patients (a heterogeneous change, or "local adaptation"). This is not a minor technical choice. If you are planning for the possibility of local adaptations, you need to describe the control procedures that will ensure proper implementation, including independent monitoring and documentation mechanisms for each deployment. IMDRF also states explicitly that local adaptations at the level of a single institution or a single patient may not be permitted in some jurisdictions, so if your product targets several markets, this is something to check early, not after the fact.
Automatic versus manual. You need to specify whether the change is implemented automatically by the software, or whether it involves a step that requires input, action or a decision by a user, the manufacturer, a medical institution or a healthcare provider. This difference directly affects the level of oversight the authority will require, and sometimes also the risk classification of the change itself.
For example, a company developing an AI-based diagnostic support tool for detecting polyps in colonoscopy plans to update the detection model once a quarter with new data from real-world use. In its PCCP it writes: "The model will be updated up to four times a year, based on an expanded training set, homogeneously across all marketed devices (with no local adaptations for an individual site), with no change to the intended use (polyp detection, not final diagnosis), and with manual approval by the QA team before each version is released."
Change Plan
The change plan has two purposes: to identify the performance evaluation methods that will show the change meets the criteria, and to identify the update procedures that will actually bring the change to the user.
Performance evaluation methods. This requires real detail, not general statements: a summary of the software's performance at the time of submission compared with the expected performance after the change, a description of the data and data management methods, relevant inputs and outputs, performance metrics, quantitative and clinically meaningful acceptance criteria, and specific statistical tests for each planned change. "The model will improve" is not a sufficient level of detail. "Sensitivity will not drop below 92% on an independent validation set of 500 cases, tested with a one-sided t-test at a significance level of 0.05" is.
A point that is easy to miss: a strong change plan must also include a failure mechanism. What happens if a version does not meet the predefined acceptance criterion? The PCCP needs to document how such a failure will be recorded in line with the regulations of the jurisdiction, and to include a mechanism that ensures the specific change is not implemented if it does not meet the criteria. Without this section, the plan is missing the very part the regulator will ask about first.
Update procedures. This covers how you will actually deploy the change, including labeling update plans, post-market follow-up, real-world monitoring and user notification requirements. A change with minimal operational impact (for example, a routine release note) does not require the same level of notification as a significant change that could affect clinical workflows. For local adaptations, this section also needs to describe the interaction between the manufacturer and the local healthcare institutions.
Impact Assessment
This is the section that links the previous ones and shows that the benefits outweigh the risks. IMDRF offers a concrete methodology rather than just a general principle: a comparison between the software version with each change implemented individually and the version without the change. In other words, it is not enough to describe the change; you need to show the "before and after" in a structured way.
Beyond that, four more things are required:
A discussion of the benefits and risks of each individual change, including risks that arise from the change process itself in the post-market phase (not only from the change itself)
An explanation of how the methods in the change plan will maintain safety and effectiveness
A discussion of how implementing one change may affect other planned changes
A description of the cumulative impact of implementing all the changes together, to the extent possible.
The last point is usually the weakest in the change plans I see (regardless of AI). It is easy to show that a single change is safe. It is harder, but no less important, to show what happens when three such changes run in parallel over two years. New risks around cybersecurity or interoperability, for example, can arise precisely from that kind of accumulation, even when each individual change is sound.
The benefits, by who gains from them
IMDRF breaks down the benefits by stakeholder, and this breakdown is useful because each audience needs a different angle when you present the idea:
For patients: faster access to software improvements, integration of new clinical evidence without waiting for a round of approvals, and the manufacturer's ability to respond quickly to the specific needs of patient populations.
For healthcare systems: updates that are planned and scheduled in advance, and therefore disrupt clinical workflows less and cause less unexpected downtime.
For regulatory authorities: fewer separate submissions to review, and better insight into future market trends, which supports their horizon scanning efforts.
For manufacturers: earlier planning, shorter time to market for updates, and less administrative burden over the product's life. IMDRF also notes that this flexibility can open the door to methodologies and fixes that were previously pushed aside because of cost, since no single change justified a separate submission.
The challenges, including those that fall on the regulator
Preparing a PCCP is work, and IMDRF does not try to hide it. It will take comprehensive planning, risk analysis and documentation beyond a regular submission, which may extend the time to the initial submission and raise costs early on. But the challenge does not end with the manufacturer.
From the regulatory authority's point of view, including a PCCP makes the review process more complex, especially for relatively new types of proposals, such as those that include site-specific changes. IMDRF explicitly recommends early engagement with the regulatory authority to discuss the proposed PCCP, even before the formal submission. That is practical advice: align expectations early, especially if the plan includes a less routine mechanism.
There is also a strategic choice worth considering here: submit the PCCP with the initial submission, or submit it later, together with the submission for the first change. If you are close to clearance and the plan is not yet mature, you do not have to hold everything until it is one hundred percent ready. You can launch the product and add the PCCP with the next change submission. This reduces the risk of delaying the launch, at the cost of investing additional resources later.
Another practical recommendation from the document: a PCCP that focuses on a limited number of proposed changes is easier for the authority to review. The temptation to push every possible change into one big plan is there, but it works against you.
Across borders, not every jurisdiction is the same
Not every jurisdiction accepts PCCPs today, and those that do do not necessarily define the same things in the same way. What counts as a significant change requiring a new submission in one place may be considered a minor change somewhere else, and this directly affects what is appropriate to include in your PCCP. If your product is intended for several markets, you cannot build one PCCP and assume it will be accepted the same way in all of them.
There are two more mechanisms worth checking in advance if you operate internationally:
Jurisdictions that use self-certification routes for regulatory compliance, where it is your responsibility to make sure the PCCP fits that route.
Jurisdictions with a reliance framework, where differences between jurisdictions affect generalizability, the accepted standards and the evidence requirements that will be accepted.
The practical point: it is better to build the PCCP around your main jurisdiction and treat expansion to additional markets as a separate project with its own suitability check. Trying to solve every jurisdiction in one plan too early usually leads to a clumsy plan that no authority is fully happy with.
What this means for your quality management system
The point the document stresses again and again is that a PCCP does not stand on its own. It relies entirely on your existing change management and risk management processes, and on compliance with standards such as IEC 62304. If those processes are not mature, a PCCP will only expose that to the regulator; it will not fix it.
Before you start writing a PCCP, it is worth checking four points:
Do you have a traceability mechanism that links each change in the description of changes to its specific verification plan in the change plan?
Are your acceptance criteria already quantitative and predefined, including a defined statistical test for each change, or are they still general wording?
Who in your company is responsible for documenting a failure against an acceptance criterion, and what exactly happens in the process when it occurs, including who prevents the implementation?
How do you document and manage versions of the PCCP itself, so that it is clear exactly what was approved and when?
Remember that a change to a plan that has already been approved is usually considered a change that requires re-approval, so it is worth planning the boundaries of the plan carefully from the start.
When a PCCP is really worth the effort
These are the products that will really benefit from a PCCP:
AI/ML-based SaMD products that are updated regularly with new data
Software that is expected to receive frequent performance updates, not only bug fixes
Products whose future changes are already reasonably known during development, so they can be described in the required detail
These are the cases that probably do not need the effort:
Products with a slow and unpredictable update pace, where most changes are not known in advance anyway
Changes that go beyond the original intended use and will require a new submission in any case, regardless of a PCCP
The practical starting point
If you are considering a PCCP for your product, my recommendation is to start not from the document itself but from the question: which changes can we really predict in advance, at a level of detail that includes quantitative acceptance criteria and a defined failure mechanism? If the answer is vague, it is a sign that your internal process is not yet mature enough to write a convincing PCCP. If the answer is clear and specific, you already have the raw material for the description of changes, and from there it is easier to build the rest of the plan.
A PCCP is an up-front investment that replaces repeated rounds of approvals with one structured process, provided your quality management system can truly support it. For products that are updated at a high pace, it can be the difference between months of waiting for approval on every update and a process that runs inside your quality management system rather than outside it.