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 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:
| - Test Plan<br>- Test Script(s)<br>- Test Execution<br>- Test Report(s) | - Incident Report<br>- Creation or update of Trace Matrix<br>- Update of risk management files if needed<br>- Other |
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.
