IMDRF N90 Finalizes PCCP Framework for Medical Device Software

The International Medical Device Regulators Forum (IMDRF) published IMDRF/SaMD WG/N90 FINAL:2026, Essential Principles and Content of Predetermined Change Control Plans, on August 6, 2026. The final document gives regulators and manufacturers a common framework for planning certain future changes to medical device software before those changes are implemented.

The central opportunity is familiar: when a jurisdiction authorizes a predetermined change control plan (PCCP), a manufacturer may implement changes covered by that plan without seeking a separate authorization for each change. The central limitation is equally important: IMDRF N90 is an international harmonization document, not a law or jurisdiction-specific guidance. It does not make PCCPs available in a market that does not accept them, and it does not override local submission requirements.

For global software teams, N90 is best used as a common design architecture. Whether that architecture can be submitted, authorized, or relied upon still has to be decided market by market.

What changed on August 6

N90 has moved from consultation to a final IMDRF technical document. It applies to the subset of software that meets the definition of a medical device, using the term medical device software as described in IMDRF N81.

The document is deliberately high-level. It is intended to:

• identify essential principles for developing a PCCP;
• establish the core elements of a PCCP for medical device software modifications;
• describe the types of boundaries that make planned changes reviewable; and
• explain benefits and challenges for users, regulators, and manufacturers.

N90 does not define a universal list of acceptable changes. It also does not establish a regulatory requirement to submit a PCCP. IMDRF states that not all jurisdictions may accept PCCPs or similar plans for regulatory review.

The five principles of a robust PCCP

IMDRF organizes the framework around five principles.

Focused and bounded

The planned changes must be described with enough specificity to support an assessment of continued safety and effectiveness. They must remain within the medical device software's original intended use or intended purpose.

This is more than a drafting preference. A broad ambition such as “future model improvements” is not a usable change boundary. A reviewable PCCP needs to state what can change, how far it can change, and what remains fixed.

Risk-based

The PCCP should be designed and implemented through the manufacturer's existing risk-management framework. The level of detail, evidence, controls, and acceptance criteria should match the risk and complexity of the planned change.

Evidence-based

Evidence generated across the total product lifecycle must support the conclusion that the changed software remains safe and effective and that its benefits continue to outweigh its risks.

Transparent

Manufacturers should provide clear, meaningful, timely information to intended users consistent with the authorized PCCP. Transparency also applies to the regulator: the submission must make the change boundaries, evidence, controls, and impact understandable.

Total product lifecycle perspective

A PCCP is not a one-time appendix that can be separated from production controls. User input, new data, risk management, quality processes, deployment, monitoring, and communication remain connected throughout the software lifecycle.

The three elements manufacturers need to connect

N90 describes a PCCP as three interconnected elements: the Description of Changes, the Change Plan, and the Impact Assessment.

1. Description of Changes

This section identifies each planned change and its rationale. It should establish verifiable boundaries, describe the characteristics or performance that may change, and explain how the change will be implemented.

Depending on the software, the implementation may be uniform across all deployed devices or adapted for particular sites or patients. It may be automatic, manual, or a combination. N90 does not say that every jurisdiction will accept every implementation model; it says the model should be made explicit.

2. Change Plan

The Change Plan explains how each planned change will be verified, validated, deployed, and communicated. N90 highlights relevant data, data-management practices, analysis methods, performance metrics, statistical tests, and pre-defined acceptance criteria that are quantitative, statistically sound, risk-appropriate, and clinically meaningful.

The plan also needs a failure path. If a proposed change does not meet its pre-defined acceptance criteria, the manufacturer should have a documented mechanism to prevent implementation and record the failure under applicable requirements.

Deployment is part of the plan, not an afterthought. The document points to labeling updates, user communication or training, post-market surveillance, real-world monitoring, and notification requirements where applicable.

3. Impact Assessment

The Impact Assessment links the proposed changes to the controls in the Change Plan. It evaluates benefits, risks, and mitigations for each change and for the changes collectively.

That cumulative view is a major operational point. A sequence of individually acceptable changes may interact, alter cybersecurity or interoperability risk, or move performance in a direction that is not visible when each release is assessed alone.

What N90 means for a global submission strategy

One core plan does not mean one regulatory outcome

A manufacturer can use N90 to create a global core PCCP, but each target market may differ on whether PCCPs are accepted, what changes require authorization, when a plan may be submitted, and how an authorized plan may be modified.

The practical output should be a jurisdiction matrix attached to the core plan. For each market, track:

• whether a PCCP or comparable mechanism is accepted;
• eligible device and submission types;
• acceptable change scope;
• submission timing and review route;
• local terminology and document placement;
• user-communication obligations;
• post-market and reporting consequences; and
• the regulatory treatment of revisions to the PCCP itself.

Without that matrix, a team may wrongly assume that authorization in one market eliminates a filing in another.

Version control becomes regulatory evidence

N90 emphasizes that both the regulator and manufacturer must know which PCCP version was authorized. Revisions to an authorized PCCP will generally be likely to require re-authorization because the plan covers changes that would otherwise require a new submission, although some jurisdictions may allow minor revisions without re-authorization.

The authorized PCCP version should therefore be connected to the corresponding device authorization, software baseline, risk file, release controls, labeling, and market-specific regulatory status.

Traceability should run change by change

The document recommends connecting each item in the Description of Changes to its verification and validation activities in the Change Plan. Manufacturers should extend that traceability through the Impact Assessment and release decision.

A useful control model is one row per planned change, with links to:

• the authorized boundary;
• the applicable requirements and hazards;
• verification and validation protocols;
• acceptance criteria;
• individual and cumulative impact conclusions;
• deployment and communication controls;
• the released software version; and
• the markets in which implementation is permitted.

That structure makes it easier to stop a change that falls outside the plan or passes testing in one market but lacks authorization in another.

What N90 does not allow manufacturers to assume

The final document does not support the following shortcuts:

• A PCCP is not automatic authorization. The applicable regulator must accept and authorize the plan under its own framework.
• The scope is not unlimited. Changes remain within the original intended use or intended purpose and within the authorized boundaries.
• Quality-system controls still apply. Change management, risk management, verification, validation, release, and post-market processes remain necessary.
• An authorized plan is not necessarily freely editable. A revised PCCP may itself require regulatory authorization.
• Unimplemented changes should not appear as current labeling. N90 says marketed labeling should reflect implemented changes, not future changes merely listed in the PCCP.
• International reliance is not automatic. Jurisdictional differences can affect generalizability, evidence, and recognition.

A practical readiness test

Before investing in a PCCP submission, a manufacturer should be able to answer five questions.

1. Can every proposed change be described within a specific, testable boundary?
2. Are the evidence methods and acceptance criteria mature enough to define before the future change is developed?
3. Can the quality system prevent deployment when criteria are not met or when a market has not authorized implementation?
4. Can individual and cumulative impacts be monitored across successive releases?
5. Is there a verified market-by-market route for submitting and using the plan?

If the first four answers are weak, the PCCP may be too immature for review. If the fifth answer is weak, the technical plan may be sound but the global rollout assumption is unsafe.

What manufacturers should do now

Medical device software manufacturers can use the final N90 framework immediately for internal planning, even before every jurisdiction adopts a PCCP route.

• Compare existing change-control-plan templates with the five principles and three elements in N90.
• Replace broad change categories with bounded, verifiable change statements.
• Connect each planned change to evidence, acceptance criteria, impact analysis, deployment, communication, and failure controls.
• Establish controlled versioning for the PCCP and its relationship to each authorized device configuration.
• Build and maintain the jurisdiction matrix before relying on a multi-market implementation plan.
• Engage target regulators early where pre-submission interaction is available, particularly for novel or locally adapted changes.

Pure Global's SaMD regulatory guide provides additional context for classifying and registering software across major markets. N90 can provide the common PCCP architecture; the market strategy still has to translate that architecture into each jurisdiction's actual rules.

Bottom line

IMDRF N90 gives the medical-device-software sector a final international reference for PCCP design. Its value is a shared structure: focused change boundaries, risk- and evidence-based controls, user transparency, lifecycle governance, and a connected Description of Changes, Change Plan, and Impact Assessment. Its limit is jurisdictional adoption. Manufacturers should use N90 to standardize the core plan, then verify authorization and implementation requirements separately in every market.