• There are no suggestions because the search field is empty.

Change Control Management: how to keep your systems compliant?

Author Avatar
Appelmans, Life Science consultant at QbD Group
Software Solutions & Services
Medical Devices
In this article, you will learn a structured approach to ensure regulatory compliance and proper operation of your computer systems, throughout their life cycle.
Change Control Management: how to keep your systems compliant
10:38

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:

 

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
  • 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 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.

 

Stay ahead in life sciences

Keeping up with the fast-paced life sciences industry doesn’t have to be overwhelming.

Our newsletter delivers the latest insights, industry updates, and expert content directly to your inbox, helping you stay informed and make smarter decisions.

Circles-banner-short

Discover more expert content

preview_image
Webinar

From Requirements to Code: a unified MDSW development cycle that covers all requirements

Watch our webinar on demand to master medical device software development. Learn about IEC standards, cybersecurity, AI integration, and FDA expectations.
preview_image
Whitepaper

Mobile health on the rise: exploring the regulatory landscape for reimbursement

This whitepaper will help you navigate the maze of the DTx regulatory environment, highlighting several important countries and regulations.
preview_image
Whitepaper

GAMP 5 Software Validation Approach for GMP, GCP and GLP regulations

Learn how to comply with GMP, GCP, and GLP regulations using the GAMP 5 Software Validation Approach. Download the whitepaper for more insights.
preview_image
Webinar

Getting Started: Overcoming Initial Obstacles in Medical Device Software Development

Watch our webinar on demand and learn about regulatory obstacles, MDR, AI Act, and best practices for medical device software development and market entry.