Predetermined Change Control Plans, and what your quality system has to hold

Seven years of regulatory work on one mismatch

Software improves on a release cadence. Regulatory authorisation works on a submission cadence. Every meaningful update to marketed medical device software sat between the two, and adaptive AI made that gap a structural problem rather than an inconvenience. A PCCP closes it by moving the review earlier: the manufacturer describes changes it has not made yet, and authorisation covers them in advance.

Changes consistent with an authorised plan need no further authorisation when they are implemented. They stay inside the software's original intended use or intended purpose.

Period	What happened
2019 to 2021	FDA published a discussion paper on modifications to AI and ML software, then an action plan, then good machine learning practice principles with Health Canada and the MHRA.
Dec 2022	FDORA added section 515C to the FD&C Act, giving FDA explicit authority to authorise a predetermined change control plan. The mechanism moved from concept paper into law.
2023 to 2024	FDA issued draft marketing submission guidance, then trilateral PCCP guiding principles, then final guidance in December 2024.
2026	IMDRF published essential principles so that jurisdictions adopting PCCPs converge on one shape instead of diverging from a shared idea.

Where you can use one today

Jurisdiction	Position	What it means for your plan
United States	A named statutory route with final guidance behind it.	The most developed practice today, and the reference point most reviewers and partners will have in mind.
European Union	The MDR has no PCCP mechanism. The AI Act is the nearest analogue.	Under the AI Act, changes to a high-risk system that the provider predetermined at initial conformity assessment, and documented in the technical documentation, are not a substantial modification. That is a different instrument with narrower reach, and MDR change obligations still apply.
Elsewhere	Adoption is uneven. Some jurisdictions do not accept PCCPs for review at all.	One plan written once for every market is not a safe assumption. Self-certification routes and reliance frameworks each add a compatibility question the manufacturer owns.

Read N90 for what it is. It identifies essential principles, establishes the elements of a plan, indicates the scope of changes that could sit inside one, and sets out benefits and challenges. It does not interpret or replace any jurisdiction's law, establish regulatory requirements, define which change types are acceptable, or serve as guidance anywhere.

What changes, how it is proven, and what it does to the risk

A plan generally holds a description of changes, a change plan, and an impact assessment, with detail proportionate to the risk and complexity of what is changing. The three elements are not independent chapters.

1. Description of changes, what changes

• Each change named on its own, with its own rationale, specific enough to assess continued safety and effectiveness.
• Explicit boundaries on the range of what may change. Only changes that can be verified, validated, and deployed belong in a plan.
• Whether a change applies uniformly across the market or is adapted per site or patient, and the controls that keep those apart.
• Whether implementation is automatic, manual, or both, and the expected update frequency where it is known.

2. Change plan, how it is proven and shipped

• Performance evaluation methods: the data, test and analysis methods, metrics, and statistical tests per change, individually and in aggregate.
• Acceptance criteria set in advance that are quantitative, statistically sound, proportionate to risk, and clinically meaningful.
• A stated mechanism that stops a change from shipping when it misses those criteria, and that records the failure.
• Update procedures: deployment, post-market monitoring, user notification and training, and labelling that stays true to the version in use.

3. Impact assessment, what links the other two

• Each change compared against the version with nothing changed, with its anticipated benefits, risks, and mitigations.
• The risk introduced by the act of changing software already in the field, not only the risk of the change itself.
• How each change may interact with the others, and the cumulative effect of implementing all of them.
• Updated cybersecurity and interoperability risk where relevant, framed by the existing quality system rather than beside it.

The link that is often missing. Connect every entry in the description of changes to the specific verification and validation plan that proves it. A reviewer can then find the evidence for a single change without reading the whole plan, and can see how that change bears on safety and performance. Without that connection, reviewers infer coverage, and inferred coverage produces questions.

Five principles a robust plan satisfies, worth testing any draft against before submission. Focused and bounded: specific changes, all inside the original intended use. Risk-based: intent, design, and implementation driven by your risk framework and held inside it. Evidence-based: evidence across the whole product lifecycle, not only at submission. Transparent: users know how the software performs before and after a change is implemented. Lifecycle view: user input, new data, and risk practice applied continuously rather than once.

A plan is a commitment about processes you already have to run

A PCCP is developed and managed within the manufacturer's existing quality management system, including risk management. Changes authorised through one are expected to be implemented according to that system, in particular change management and risk management, in line with existing requirements and standards such as IEC 62304. This is the central requirement in the whole subject.

Accelerating implementation is the purpose of a plan. Shortening the record is what makes it indefensible.

Process	What the plan commits you to
Change management	A change inside an authorised plan skips the submission, not the process. Each one still needs a change record, an approver independent of the author, verification against the criteria you stated, and a release decision that can be reconstructed later.
Risk management	The impact assessment asks more than an ordinary risk assessment, because it has to address the cumulative effect of changes you have not made yet. That works only if hazards, controls, and residual acceptance are maintained records, not a file written at submission and reopened at audit.
Version control of the plan	Manufacturer and regulator have to agree which version was authorised. Revising an authorised plan is generally treated as affecting safety and performance, and will likely need re-authorisation. Some jurisdictions may allow minor revisions without it. Ask rather than assume.
Failure handling	The plan has to state how a missed acceptance criterion is recorded, and how the change is prevented from being implemented when it misses. A plan with no failure path implies every planned change succeeds. No reviewer believes that.
Labelling control	Users should see labelling for the version they are running, and changes not yet implemented should not appear in it. That requires the deployed version per user population to be a fact you can retrieve, not one you reconstruct from a deployment log.
Post-market monitoring	A plan redistributes risk across the lifecycle, so it needs ongoing monitoring of cumulative change and confirmation that the growing body of evidence still supports the intended use. Monitoring that cannot be attributed to a deployed version cannot do that.

One test worth running before you draft anything. Take one change you would want inside a plan. Try to produce, today, the record trail it will need after authorisation: the dataset version it trained on, the criteria agreed before evaluation, the independent approver, the deployed version per site, and the rollback that was exercised. If that trail has to be assembled by asking people, the plan is committing to control the quality system cannot yet demonstrate.

The cost falls at submission, and the benefit returns later

A PCCP moves planning, risk analysis, and documentation into a submission that would otherwise have been simpler, and returns that investment across the following years of updates.

	The benefit, across the lifecycle	The cost, at submission
Speed	Authorised changes reach the field without a separate submission cycle, so new clinical evidence arrives while it is still current.	More planning, risk analysis, and documentation, a higher initial cost, and a longer run-up. Time to market for the first release can lengthen.
Scope	Improvements that were deprioritised because the submission cost exceeded the benefit can return to the roadmap.	A plan drafted too tightly becomes a liability, and one drafted too broadly will not be authorised. Changing an authorised plan generally means re-authorisation.
Operations	Planned deployment disrupts clinical workflows less than reactive change does, and one authorisation replaces a series of submissions.	Stepwise development demands stronger traceability and continuous monitoring of cumulative change than a submission per change ever did.
Markets	Agreeing planned modifications up front aligns both sides and shows authorities what is coming.	Jurisdictions differ on which changes need a submission at all, and that changes what belongs in a plan.

Two ways to make it manageable: keep the first plan to a small number of changes a reviewer can genuinely review, and consider attaching it to your first change submission rather than the initial one.

This is Qity's own interpretation and commentary. It is not legal or regulatory advice, and it is not endorsed by or affiliated with IMDRF. Concepts discussed here are adapted from Essential Principles and Content of Predetermined Change Control Plans, IMDRF/SaMD WG/N90 FINAL:2026, available at imdrf.org. IMDRF is not responsible for this adaptation. N90 establishes no regulatory requirements. PCCP availability, form, and acceptance are determined by each jurisdiction, and not all jurisdictions accept them.