GP-023 Change control management

Procedure flowchart

Purpose

This procedure describes a systematic approach to managing all the changes made to the product and/or processes throughout the product lifecycle of our medical devices. This includes the design and development phases until validation (per GP-012 Design, redesign and development), post-market activities, and any change related to regulatory requirements and QMS documentation.

Scope

This procedure applies to:

Product changes

• Design Freeze Phase (Pre-market): After Product release (submission for product approval ongoing).
• Design Freeze Phase (Post-market): After Product release, Product approval and already in the Market (CE certificate already done).
• Design History Phase (Post-market): After Product release, Product approval and already in the Market (CE certificate already done).

Process changes (QMS)

• Changes to quality management system processes and activities.

Out of scope: Development Phase

Important

This procedure (GP-023) is NOT applicable for the Development Phase, i.e., before the Design Freeze and before internal product releases.

During the Development Phase, changes to the product design are managed directly through the GP-012 Design, redesign and development procedure, where requirements are added, modified, or removed as part of the normal design and development workflow. These changes are tracked in the Design History File (DHF) through the standard design control process (design reviews, verification, validation).

GP-023 Change Control applies only after:

• The product has reached Design Freeze (Pre-market: submission for approval ongoing)
• The product has been released to market (Post-market: CE certificate obtained)

For any changes during active development, refer to GP-012 Design, redesign and development.

Definitions

• Change: A Change refers to any adjustment made to an existing product/design or process that results in a modification to the fit, form, function, or process used to produce the product, or changes a specification for the design.
• Design Master Record (DMR): The file that consists of all the relevant records on the product that is developed and all relevant records specific to the design history of the product developed.
• Change Control: A process that manages changes, non-conformity to the design and/or production processes of medical devices.
• Validation: Pieces of evidence that show the medical device specifications meet the user's needs and its intended use (design inputs meet user needs).
• Verification: Evidence that shows the medical device specifications met its respective design requirements (design outputs meet design inputs).
• Device Master Record (DMR): The DMR contains a comprehensive set of data for manufacturing your device. There is a significant overlap between DHF and DMR requirements, so the design files are intended to encapsulate the product, items the product specifications and item numbering and packaging aren't covered in the design outputs step - they should already be part of the DHF.
• Design History File (DHF): The DHF includes a full history of the device design, from the establishment of user needs to the records of your design reviews and the device specifications created in the design transfer process.
• Device History Record (DHR): This record contains information about specific batches, lots, or units of product that you produce. It is meant to facilitate traceability of your products throughout their life cycle and to help with root cause analysis by connecting customer feedback and audit results to specific batches of product.
• Device Master File (DMF): refers to a comprehensive set of documents maintained by an organization that contains proprietary information related to the design, manufacture, and quality of medical devices.
• CCR: Change Control Responsible.
• Significant change: A change intended to significantly affect the safety or effectiveness of the device is considered to be a change that "could significantly affect the safety or effectiveness of the device and that requires submission of a new 510(k)".
• Substantial change: The EU MDR and IVDR refer to "substantial changes" in the context of those quality system or device range changes that must be notified to Notified Body in the post-certification phase, i.e. major modifications either to the device and/or in the quality management system in accordance with MDR that could affect conformity with MDR and necessarily require a formal approval from the notified body.

Responsibilities

JD-001

To approve the proposed design and QMS changes and to provide the organization with a set of appropriate documents and resources to guarantee the clarity and precision of the information.

To have a meeting with JD-005, JD-003 and JD-004 to analyse any substantial change and describe the actions requested due to the change.

JD-005

To document, supervise and control the communications and the design and QMS changes to verify the adequacy of the process. To notify the Notified Body (BSI) as appropriate.

To perform the analysis if the change is a substantial change to be notified to the regulatory authorities (EU and/or FDA). To propose the change classification using the T-023-001 Change Control template.

JD-003

To evaluate the proposed design and QMS changes, establish their category (significant or non-significant) and approve them together with JD-001.

To ensure that the change management process helps to ensure the ongoing safety and effectiveness of devices in the face of ongoing changes in the practice of medicine (referred to as "TPLC - Total Product Life Cycle").

JD-004

To ensure that the change management is performed following this procedure and that all the records required are properly generated, reviewed, approved and archived accordingly.

To document changes in the T-023-001 Change control template.

To update the device master file with all changes made and preserve traceability.

Inputs

• Design change necessity coming from users, regulatory, technical, security and other requirements.
• QMS change necessity coming from different sources: nonconformity, CAPA, post-market surveillance activities, company needs, new regulatory requirements.
• Risk mitigation process (GP-013 Risk Management)
• Non-conformity report (GP-006 Non-conformity. Corrective and preventive actions)
• CAPA (GP-006 CAPA)
• Internal audit (GP-003 Internal audit)
• Customer feedback and complaints handling (GP-014 Feedback and complaints)

Reference documents

• ISO 13485:2016 — Medical devices — Quality management systems — Requirements for regulatory purposes, 4.2 Documentation requirements
• FDA 21 CFR Part 820 (QMSR 2026)
  • 21 CFR 820.40 Document control
  • 21 CFR 820.180 General requirements
  • 21 CFR 820.181 Device master record
  • 21 CFR 820.184 Device history record
  • 21 CFR 820.186 Quality system record
  • 21 CFR 820.30 Design controls
  • 21 CFR 820.70 Production and process controls
  • 21 CFR 814(E) states that a premarket notification must be submitted when:
    • A change or modification in the device could significantly affect the safety or effectiveness of the device, e.g., a significant change or modification in design, material, chemical composition, energy source, or manufacturing process.
    • A major change or modification in the intended use of the device.
• Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on Medical Devices. Medical Device Regulation. Annex IX Chapter II Section 4.10.
• Deciding When to Submit a 510(k) for a Software Change to an Existing Device Guidance for Industry and Food and Drug Administration Staff. Document issued on October 25, 2017
• FDA draft guidance: Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions.
• NBOG 2014-3 Guidance for manufacturers and Notified Bodies on reporting of Design Changes and Changes of the Quality System

Outputs

• Communications with the Notified Body (BSI).
• A Design history file per product or family of products manufactured.
• Change control record (T-023-001 Change control).
• Updated Device Master Record (DMR).
• Regulatory submissions (510(k), De Novo) when required.

Development

Change initiation

Any proposed change in the scope of this procedure will adhere to the Change Control procedure. A change request could be triggered as part of:

• A risk mitigation process (GP-013 Risk Management)
• A non-conformance report (GP-006 Non-conformity)
• Corrective and preventive action (GP-006 CAPA)
• Internal audit (GP-003 Internal audit)
• A regulatory change
• Customer feedback (GP-014 Feedback and complaints)

Regardless of the source of a change request, it should be analysed by the team by applying this procedure. Once a change is required, JD-004 will ensure that the team initiates the change through the Change Control Request (T-023-001 Change control). The Originator is the employee who is proposing the change.

The Originator must provide the following information to initiate the change control process:

• Originator details
• Details for a QMS/process change (document, software) - if applicable
• Details for a product change if applicable - if applicable

The purpose of the software change should be to:

• Minimize disruption to current operations
• Ensure that other affected documents have been identified so they can be amended accordingly.

When introducing a proposed change, the following aspects (non-exhaustive) should be considered and if required, to mitigate any risk:

• Function
• Performance
• Usability
• Safety
• Software version
• Existing released software in the market
• Medical devices or other software systems that it interfaces
• Risk management (to evaluate if the proposed changes, including SOUP, will result in additional hazardous situation and determine if additional risk control measures are required)
• Labelling
• Regulatory requirements (to check with local respective regulations if any notification to the authorities is required for this product change, as well as the timeline and cost)
• Possible product and software classification changes due to the proposed changes
• Quality management system
• Cybersecurity

Finally, the Originator must approve Part 1 of the Change Control Request Form with JD-003 and JD-004. Upon approval, the team can carry out the work as planned.

Impact analysis of proposed changes

JD-005 must analyse the impact of the proposed change through a meeting between those involved: JD-001, JD-003, JD-005, and JD-004. This meeting should describe the impact of the change internally (documentation), and the necessary communication, or not, with the BSI and/or the Notified Body.

Substantive or non-substantial change classification

Classification of the change shall be done for changes included in the T-023-001 Change control template (Part II).

To perform the analysis if the change is a substantial change to be notified to the regulatory authorities (EU and/or FDA), the team that proposed the change, and JD-004, will have a meeting and complete a full report about the context of the proposed change. This analysis will be recorded using the T-023-001 Change Control template.

Substantial changes for devices marketed in Europe

Substantial changes need to be communicated to the notified body and/or to the related competent authorities, depending on the market where the devices are distributed. For the European market, the notification of substantial changes to the notified body shall be performed, as per the single agreement between the Notified Body and BSI. Substantial changes can be related to the device, the quality system, or the product range covered by the quality system.

For devices with CE marking, changes to the approved device shall require approval from the Notified Body which issued the EU technical documentation assessment certificate where such changes could affect the safety and the performance of the device or the conditions prescribed for use of the device. For the evaluation of whether the change is considered substantial or not, the following guidance shall be used: NBOG 2014-3 Guidance for manufacturers and Notified Bodies on reporting of Design Changes and Changes of the Quality System.

Notification timelines for BSI

Change type	Notification timing	BSI review	Implementation
Substantial change	Immediately upon identification	BSI must validate the action plan before implementation	Once BSI approves the action plan, the change can be implemented. BSI will verify the implementation during the next annual surveillance audit.
Non-substantial change	No immediate notification required	BSI reviews during the next annual surveillance audit	Can be implemented after internal approval. Update technical file accordingly.

Important - Substantial Changes

For substantial changes, do NOT implement the change until BSI has validated the action plan. The process is:

1. Identify and classify the change as substantial
2. Prepare a detailed action plan using T-023-001 Change Control
3. Immediately notify BSI and submit the action plan for validation
4. Wait for BSI approval of the action plan
5. Implement the change only after BSI validation
6. BSI will verify the implementation during the next annual surveillance audit

Top Management (JD-001), Technical Responsible (JD-005) and JD-004, will have a meeting to analyse the substantial change and describe the actions requested due to this change. A detailed action plan will be created and followed using T-023-001 Change Control template.

Substantial changes for devices marketed in the United States

Changes considered "substantial" for the FDA require a new 510(k)/De Novo application.

If the change is made with the intent to significantly improve the safety or effectiveness of the device, the change is considered substantial and it needs a new 510(k)/De Novo.

Instead, if the change is related to labelling, technology, engineering, or performance change or materials change, a specific checklist shall be followed, as per guideline Deciding When to Submit a 510(k)/De Novo for a Change to an Existing Device published by FDA on October 25, 2017.

Moreover, for Software-related changes, an analog guidance document has been published titled Deciding When to Submit a 510(k)/De Novo for a Software Change to an Existing Device.

In any case, the justification for not performing a new 510(k)/De Novo file shall be detailed. Top Management, Technical Responsible and JD-004, will have a meeting to analyse the Substantial change and describe the actions requested due to this change. A detailed action plan will be created and followed using T-023-001 Change Control template.

The change management process helps to ensure the ongoing safety and effectiveness of devices in the face of ongoing changes (referred to as "TPLC"). However, certain changes to AI/ML (Artificial Intelligence/Machine Learning enabled Medical Devices), such as changes to a model or algorithm, may be substantial or significant. For this reason, they can require regulatory oversight, such as additional premarket review. Such regulatory submissions may not always correlate with the rapid pace of AI/ML development.

The only way to approve substantial changes without a new 510(k)/De Novo submission is to include a PCCP (Predetermined Change Control Plan) in the previous 510(k)/De Novo submission and obtain FDA approval for these future changes. This is the way to manage certain device changes for which regulatory clearance is normally required prior to marketing. The FDA-approved PCCP will apply and no further communication with the FDA will be necessary.

JD-004 shall update the device master file with all changes made and preserve traceability.

Non-Substantial changes for devices marketed in Europe

If after analysis of the change it is determined that the change is not substantial, applying the criteria described in the reference guide, a Notification of Change will be made to BSI who will review the technical file of the device when it is scheduled for the next re-certification audit. JD-004 shall update the product's technical file with all the changes made and always keep the technical file up to date with all changes made.

Non-Substantial changes for devices marketed in the United States

If after analysis of the change it is determined that the change is not substantial, and no further communication with the FDA will be necessary. JD-004 shall update the device master file with all changes made and preserve traceability.

Implementation of proposed changes

Once the change request is approved by JD-001, the changes can be implemented. The implementation details are to be provided using Part II of the T-023-001 Change Control Request.

The Risk review of the effect of the change on any work, product or the process (in delivery or already delivered), inputs or outputs of the risk management, and any other product-related processes, must be reviewed before the change is approved officially.

If the changes are due to an adverse event or field safety issues, refer to GP-007 Vigilance for any further reporting requirements to regulatory authorities. If the changes are due to an upgrade or modification, JD-005 will consider if the existing software needs to be upgraded and the consequences of continued un-changed use. If this upgrade is required, it is important to define the strategy on how to implement the software changes (described in GP-029 Software Delivery and Commissioning).

Verification of effectiveness

After the official implementation of the Change, it is important to monitor if the changes have been implemented effectively and if their outcomes have met the initial objectives. This can be identified through the next reviews of procedures or by observing the relevant activities over the next 3-6 months or as needed, if necessary. Once this information is available, the team can close all Part II of the Change Form with the relevant reviewing and approving signatures.

Change Control forms are maintained as part of the DHF/DMR File.

Associated documents

• GP-006 Non-conformity. Corrective and preventive actions
• GP-007 Post-market surveillance
• GP-011 Service provision
• GP-012 Design, redesign and development
• GP-013 Risk management
• GP-014 Feedback and complaints
• GP-024 Predetermined Change Control Plan
• GP-029 Software Delivery and Commissioning
• T-023-001 Change control

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003 Design & Development Manager, JD-004 Quality Manager & PRRC
• Approver: JD-001 General Manager

ㅤ ㅤ