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
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:
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:
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 computerized 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 computerized 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:
|
|
Approve and Implement
The next step is to review all efforts that have been performed and to either approve or reject the developed solution. Once approved, it becomes authorized 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.
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.