Change control is one of the crucial but more difficult aspects to tackle within a quality system. In this post, we give a possible approach to managing changes to either your QMS as well as your medical devices.
What can change?
In order to define how to manage changes, it's a good idea to know what kind of changes can happen. This is an non-exhaustive list of possible items that can change:
- Source code
- Hardware design
Different kind of changes require different approaches. Changing a critical supplier is not the same as changing your software code and therefore should not follow the same procedure in terms of change control.
What is required?
Both FDA 21 CFR Part 820 and ISO 13485:2016 refer to change control in several sections:
- Part 820.30(i) Design changes. Manufacturers must establish and maintain procedures for the identification, documentation, validation, review and approval of design changes before they are implemented.
- Part 820.40(b) Document changes. Changes to documents shall be reviewed and approved by a designated individual. Each manufacturer shall maintain records of changes to documents.
- Part 820.70(b) Production and process changes. Manufacturers must establish and maintain procedures for changes to a specification, method, process or procedure. They should be verified, validated or approved when appropriate.
- Part 820.70(i) Automated processes. Software changes shall be validated before approval and issuance.
- Part 820.75(c) When changes or process deviations occur, the manufacturer shall review and evaluate the process and perform re-validation when required.
- Part 820.100(a)(5) Each manufacturer should establish procedures for implementing CAPA, including procedures for implementing and recording changes in methods and procedures needed to correct and prevent quality problems.
- Control of documents and records (4.2.4 and 4.2.5)
- Quality management system planning (5.4.2)
- Management reviews (5.6.1 and 5.6.3)
- Review of product requirements (7.2.2)
- Design and development changes (7.3.9)
- Purchasing process (7.4)
- Process validation (7.5.6 and 7.5.7)
- Need for change (8.5.1)
How to cover these different changes?
Things to take into account:
- How critical is the subject of change?
- How much control is needed?
=> In order to determine how much control is needed, you can use a risk-based approach. You can for example list the possible risks related to changes and change control and make a distinction based on impact. After making this list, you can define which kind of change control process should be implemented for which risk category.
High Risk Changes
- Critical changes
- High business impact
- Extensive documentation required
- Big impact on products and processes
- Requires extensive planning
Medium Risk Changes
- Medium business impact
- Specified changes in product or production
- Planning required
- Documentation required
Low Risk Changes
- None to little business impact
- Administrative changes
- No impact on product design or production process
- Less documentation required
Before going full throttle with implementing changes, it's important to plan ahead:
- What is the change?
- Why is the change needed?
- What is the impact of this change on other processes/products/...?
- Which process needs to be followed?
- Who can approve the change?
- Who needs to be trained?
When the request for a change has been approved, the implementation can start. It's important to implement the change in the way it has approved. In order to verify this, it's key to document all the important information regarding the change:
- What has been implemented?
- Who changed what?
- When was the change implemented?
- Why has it been implemented?
- Was it reviewed adequately?
- Has the change been approved correctly?
- Has everyone been trained appropriately?
4. Check and Act if needed
After the change has been implemented, it's important to verify:
- When it was put into action?
- Was the change effective?
- Did people understand the change?
If the change is not effective or training was not optimal, adaptations should be made in order to improve.
After the change has been implemented and checked for its effectiveness, make sure to close the change in order to wrap up the documentation. At this point you have a final check that everything has been done according to the right process. By closing out the change in your documentation, it becomes clear that all phases have been finalized.
From the above, it's clear that the very basic principle of a Quality Management System, P-D-C-A (Plan-Do-Check-Act) forms the basis on how to manage changes.
Not only adopting this principle is important to make changes in an effective and structured way, also the documentation in this matter is key. There is a reason why legislations and standards put so much focus on properly documenting changes. If you neglect to document changes in an organized way, it will be extremely difficult to find back the information later on and to verify that everything has actually been covered.
How to manage changes in Matrix?
In Matrix, we give the possibility to create items for each change, which can be linked to risks and processes to be followed. All items created in Matrix can be linked in order to show and maintain the traceability in between.
One example of how you can manage design changes in Matrix can be found here.