Change control management is an essential part of any quality assurance system. It enables us to maintain control of the validated status and always be in compliance, for even the most complex computerized systems, during their entire life cycle.
In the world of life sciences, regulatory compliance is of the utmost importance, but there is more. Well-established change control management will reduce the risk of breakdowns, resulting in better products, increase patient safety,… and ultimately, increase quality and reduce cost. That sounds like a win, right?
What changes are we talking about? What triggers the need for change? Simply said: The need for change could come from anywhere, at any time, and for any reason.
For computerized systems, especially changes during the operational phase are inevitable as the process suffers from satisfying the demand of the market, resolving potential hurdles, implementing improvements, and changes due to compliance, …
Some common examples of changes in the operational phase are:
- Hardware component replacement
- Configuration change due to an improvement in a process
- Configuration change required by an error
- Temporary change due to a process temporary modification
- Migration from one system to another
- Digitalization project
- Implementation of a new system
- Change of regulations
What questions do we need to ask ourselves as part of the change control process and what do we want to achieve on the one hand and control on the other hand? Some changes are needed to resolve a quality event, while others are just nice to have. Should you handle all those changes in the same way? What actions should be taken to ensure that the system is maintained in a validated state?
In this article, we will go into these questions, hoping to expand your knowledge about:
- What is change management?
- Which are the types of changes?
- How is change management applied to the lifecycle of computerized systems?
Enjoy the read, and don’t be afraid of change.
(my sincere apologies, I could not hold myself back)
What is change control management?
Change control management is defined as a formal process by which qualified representatives of the different disciplines involved, propose, implement, and review changes, that may affect the validated status of facilities, systems, equipment, or processes.
Written standard procedures should be in place to describe the actions to be taken when a change is proposed to a:
- Product component (e.g., raw materials suppliers)
- Process equipment (e.g., new equipment to be installed)
- Process environment (or location) (e.g., change of servers)
- Production or test method (e.g., changes in analytical methods)
- Resolve defects identified by users (e.g., customer complaints)
- Or other changes that may affect product quality or the operation of the support system
A complete guide to Computer System Validation
This +100 page guide aims to bring context and define the necessary and appropriate strategies for the validation of computerized systems for Pharmaceutical Industries, Biologics, Biotechnology, Blood Products, Medicinal Products, and Medical Devices, used in activities related to compliance with Good Practices (GxP). Download it now for free:
FREE E-BOOK
How is change management applied to computerized systems?
For computerized systems used in life science companies, the GAMP5 (Good Automated Manufacturing Practice) is the document that provides guidelines for the validation and management of these systems.
This guide is published by the International Society for Pharmaceutical Engineering (ISPE) and is used as an international reference for regulatory compliance.
The change management process is based on the PDCA principle for continuous improvement, also known as the Shewhart cycle or Deming circle:
Figure 1 – PDCA principle for continuous improvement
But first, we cannot talk about change management without mentioning configuration management. These two are inherently connected to each other. The GAMP5 guideline Appendix 06 provides us with an answer to how these are connected.
Configuration management comprises the activities necessary to define a computerized system or service, while change management is a process by which changes to the configuration items (s) are managed. Therefore, when changes are proposed, both activities need to be considered in parallel.
How does it work in practice?
The proposed steps to follow a change process is illustrated in the following scheme and each one of the steps will be explained further:
Figure 2 – Change management is a process with defined steps.
Proposal for change
The proposal for change is where it all starts. Any of the proposed changes should be requested and recorded by submitting a change request form.
It is important to indicate what the business and/or technical reasons are for change, and which existing or new requirements are involved. Clearly identify what the current situation is and what the future situation will be. This is where you should think: does the configuration change, and how?
If not already in place, it sometimes might be a good idea to add a business case to the proposal for change to reflect the financial side.
To make the next steps easier, do not forget to include which type of change it is:
Some additional keywords you might encounter are:
Like for Like
This is a low-risk change often used for maintenance activities where one part is replaced by a part that is identical to the original part. For computerized systems, often the term like-for-kind is used. This is almost the same, with the exception that the replacing part will not be identical, but very similar to the original part. For example, replacing a hard drive with another hard drive with a higher capacity. Replacement parts need to be approved prior to integration.
Temporary changes
These are changes that will be in effect for a limited period. This limited period should be defined. This is often used as a temporary fix in emergency situations. For example, a work instruction is temporarily altered so that the operator will manually write down the unique identifier of a product because the automated scanner is out of order. New or increased risks should be assessed. Many companies use specific deviation management to handle this type of change.
Impact assessment
One of the most important parts of change control is impact assessment. Unfortunately, this step often does not get the attention it deserves. A thorough impact assessment will not only describe what you will need to do to implement the change but will also prevent you from implementing solutions that could have an unwanted negative effect.
The impact assessment should describe which processes, configuration items, documents and SOPs are impacted, and how.
Risk assessments should also be included and should determine if the change impacts patient safety, product quality, or data integrity.
The impact assessment also includes a change plan. This is a document that will provide all detailed actions that need to be completed to have the change developed and implemented. Look at it as a roadmap.
Some thought should be given to the testing phase as well. It is good to create a view on how testing will be performed. This is based on the type of change and the criticality. This might seem early, but it will help you to develop a testable solution. Specifically, the consideration on the amount of regression testing to be done on parts of the system that do not seem to be impacted by the change but are nevertheless at risk due to the changed configuration.
Optionally, for high-risk changes, you might want to consider taking the time to develop a backout plan to revert to the situation before implementation. Just to be sure.
In some cases, it might be a good idea to create a business case as well to also reflect the financial side.
Decision
Not every proposed change is a good one. Therefore, an authorization or decision step should be in place to acquire formal approval to proceed. This consists of a thorough review of the impact assessment, the risk assessment, the budget, and the change plan. Make sure to involve all stakeholders and agree on who is responsible for what, to avoid unnecessary discussions after.
Change control execution
Development
Once the green light has been given, the development phase can start. This is where the impacted hardware, software, documents, etc. will be updated, purchased, or created to reflect the new desired situation. Do not forget to develop training as well, if needed.
In essence, this is where the change plan gets executed. So, the better the change plan, the easier the development step will be.
It is important that all steps are executed before proceeding to the next step. This is because it could have an impact on the validated status. For computerised systems, the use of development or validation environments should be considered. This is a sort of “playground” for development and testing activities.
Testing
How do you know that the newly created situation is good? This is done by the quality assurance process called validation. Validation is where we will verify that after the change is made (but before the formal implementation), the computerised system meets the needs and requirements of the stakeholders, which are translated into user requirements. So, in practice, testing needs to be performed to prove that all user requirements are met. This form of testing is often referred to as user acceptance testing.
This comes with a list of deliverables:
- Test Plan
- Test Script(s)
- Test Execution
- Test Report(s)
- Incident Report
- Creation or update of Trace Matrix
- Update of risk management files if needed
- Other
Approve and Implement
The next step is to review all performed efforts and to either approve or reject the developed solution. Once approved, it becomes authorised for implementation. This step is sometimes referred to as “Release to Operation”.
If applicable, in this phase the change is transferred from the test/validation environment to the production environment. Don’t forget to provide training if needed.
Close
In the final step, confirmation that the change has successfully been implemented will be given. This concludes the process flow, and the change can come to a closure.
Conclusions about change control management
Change control management is a crucial part of any quality assurance system and is inherently connected to configuration management.
For computerized systems used in life science industry, the GAMP 5 guideline describes Operational Change and Configuration Management to implement enhancement changes without compromising established processes or generated records and with minimal service disruption.
Change management should include the following steps:
- Proposal for change
- impact assessment
- authorisation
- Change control execution
- development
- testing
- approval & implementation
- Review and closure (final approval)
Need help with change control management?
New to systems validation and need help to get started? Our experts will be happy to support you in your change management procedures for computer systems, depending on your available resources. Please do not hesitate to contact us if you have any questions. Please do not hesitate to contact us if you have any questions.
Expert knowledge in Computer Systems Validation
- PIC/S GUIDANCE GOOD PRACTICES FOR COMPUTERISED SYSTEMS IN REGULATED “GXP” ENVIRONMENTS, PI 011-3 25 September 2007.
- GAMP 5: A risk-based approach to compliant GxP Computerized System, ISPE, 2008.
- https://healthcareitskills.com/information-technology-change-control-process-change-board/
- General Principles of Software Validation; Final Guidance for Industry and FDA Staff Document issued on: January 11, 2002.
