Configuration Management in a Regulated Environment

Configuration Management is something that is critical to the sucess of any regulated facility; especially those utilising IT/IS, however it is also something that often overlooked from a point of view of criticality. This is something that seems to be reinvented on project to project, site to site.

Save time and money with configuration management

Managed configurations are extremely worthwile and save a hell of a lot of time in the future (often unplanned) when this has been done properly. Configuration Management is a core component of PRINCE2 and ITIL (IT Infrastructure Library) – these methodologies have been proven to consistently work.

This article will give a brief insight into some of the fundamentals of configuration management and exemplify how something that seems so small can have such a large effect – moving a computer.

The jargon explained

From a terminology point of view, bear these in mind, as with all IT related articles this one contains jargon:

  • CM = Configuration Management
  • CI = Configuration Item
  • CMDB = Configuration Management Database

Find the right balance

Firstly we will look at the reasons why this is either not deployed, not deployed properly or simply so cut down it doesn’t work. A starting point is something that most people struggle with at the best of times, sometimes we just can’t get the vision right, largely due to a lack of experience and/or knowledge; couple this with personality clashes and a workplace culture, implementing configuration management is going to get difficult. Can you see where this is going? Sponsorship from superiors is often difficult to obtain due to departmental/supplier barriers and boundaries. Mix this with people, processes and technology and usually the whole thing never gets mentioned again.

The reality is that there is already lot of data, yes it’s there but to varying degrees of accuracy. Maintained? Some. But more often than not there is a LOT of informal data and local knowledge that is, well, just there! In a multi-site organisation this data is often just inconsistent.

We have chosen the ITIL CM approach because it’s, in our opinion the best and therefore we’ll use this to portrait the concept in the hope that more people will take this onboard. The ITIL CM process contains 5 core components:

Planning: Self explanatory but for those how aren’t sure: “Failing to plan, is planning to fail”. Job done.

Identification: This is deciding on what exactly is going to be controlled by the CM process and then..

Control: Link to change management (very important); a question is yeilded from the control component, “Are you allowed to change it and how is the change to the configuration controlled?”.

Status Accounting: This is about what has changed and why!

Verification and Audit: Is this what we said we’d have? Have we done it correctly?

More changes than you think

The CMDB holds the details of each CI in an organisation, especially those items used to support the manufacturing operations of a GMP environment. Let’s say, for example we’re going to move 5 servers from a control room in building A to a computer room or data centre in Building B. Sounds simple, they’re just computers, put them on a trolley move them to building B and then as log as there is power and a network socket it’s a case of plug and play. Bob’s your uncle. Now can we go to the pub?

But wait, lets look deeper what has actually changed about that computer? Their room number has changed; they are connected to different network outlets. Does they need UPS power and are they still connected to the UPS? Were they connected the the UPS anyway? How do we tell? Do we need to know or does it just have to look like it is working? Will there be enough power in the new room, is there sufficient cooling – will the environment condition changes affect the service level agreement? Is there sufficient LAN / SAN outlets? There is a lot of change going on here.

Standardise your approach

In addition to all this, there are a lot of views of the situation – The cost view, the service view, the system view (logically are the specifications suitable; physically – is there room and capacity). Parts of these views are crossing over as well, they’re overlapping into areas of common concern and it is these components whose configurations must be managed (not leaving out others but merely highlighting the importance of configuration managment). These should be controlled.

The first thing is to make sure you’ve got the right team; each and every business has a different way of working – prototype the process until it is correct. Standardise naming conventions for everything: services, locations, cabinets, devices and so forth. Identify any gaps and where the knowledge lies – this is usually a combination of formal knowledge and informal knowledge (what people know that they haven’t documented). Make sure that ownership is clear and unambiguous and most importantly make sure that visible sponsorship and support is present.

Can you afford not to use configuration management?

This all sounds like a lot of work, but in the long run this is a completely valuable exercise and demonstrates control for numerous purposes. For example, every time a new IT project comes up does someone have to survey the datacentre for capacity for power, network, rack space, air conditioning capacity? These are all jobs that can be done from the desk when an efficient, up-to-date CMBD is setup and active – in addition a good system will give everyone confidence in their planning of anything from a small upgrade to a massive MES project implementation.

Without CM, change management is of limited effectiveness; its change management that we rely on so heavily in this industry to demonstrate our control in making changes to validated systems and qualified platforms. An end-to-end view is created with CM with each task rather than being able to plan, confidently in bulk. Service reporting will always be risky and therefore not trusted, even though it is required and finally and crucially, without CM the impact of faults and changes cannot be predicted with confidence.

Can you afford not to do configuration management?

Premier Infrastructure

If you would like to learn more about configuration management feel free to contact Premier Infrastructure anytime.

0
shares

  • it seems that you are saying configuration management is the same as change management. the example you used I would have said was one of change management. so is there a difference between the two?

    In one company that I worked at we put some IT systems under configurration management (a lesser version of change management). this entailed identifying the system and allowing IT staff to alter settings in software but each alteration had to be documented in a specific log. this enabled IT staff to make changes quickly where necessary i.e. roll out patches and security updates.

  • it seems that you are saying configuration management is the same as change management. the example you used I would have said was one of change management. so is there a difference between the two?

    In one company that I worked at we put some IT systems under configurration management (a lesser version of change management). this entailed identifying the system and allowing IT staff to alter settings in software but each alteration had to be documented in a specific log. this enabled IT staff to make changes quickly where necessary i.e. roll out patches and security updates.

  • Mark Richardson

    Configuration Management isn’t a lesser version of Management. All changes should be carried out under approved change management processes/procedures; released under release management procedures.
    When implementing changes in a regulated industry, especially IT changes there is always or nearly always at least two components, firstly the change to the system, secondly the change to the specifications for that system. By deploying an efficient change management system, the CI would have a corresponding component on the computer system, this would be documented in the CMDB as well, therefore, when the requirement for change originates and is approved, the change will happen to both the CI in the CMDB and the system. This provides a structured approach and helps to ensure that the system and the documentation is aligned at all times.

    In summary, both Change and Config Management are different, in regulated environments the config management will be changed in accordance with approved change control procedures, otherwise as you have mentioned logbooks can be updated to roll out quick-changes as long as this method is proceduralised in an approved SOP or Work Instruction.

    I hope this clarifies.

  • Mark Richardson

    Configuration Management isn’t a lesser version of Management. All changes should be carried out under approved change management processes/procedures; released under release management procedures.
    When implementing changes in a regulated industry, especially IT changes there is always or nearly always at least two components, firstly the change to the system, secondly the change to the specifications for that system. By deploying an efficient change management system, the CI would have a corresponding component on the computer system, this would be documented in the CMDB as well, therefore, when the requirement for change originates and is approved, the change will happen to both the CI in the CMDB and the system. This provides a structured approach and helps to ensure that the system and the documentation is aligned at all times.

    In summary, both Change and Config Management are different, in regulated environments the config management will be changed in accordance with approved change control procedures, otherwise as you have mentioned logbooks can be updated to roll out quick-changes as long as this method is proceduralised in an approved SOP or Work Instruction.

    I hope this clarifies.

Similar articles:

The Difference Between Qualification and Validation [Video]

There is a general saying within the life sciences:

“We qualify a system and/or equipment and validate a process”

A system and/or equipment must be qualified to operate in a validated process.

For example:

“You qualify an autoclave, whereas you validate a sterilization process”

Manufacturers should identify what validation and qualification work is done. All systems, equipment, processes, procedures should be reviewed and the manufacturer should decide what qualification and validation work needs to be performed.

Direct, Indirect or No Impact

All facility areas, utilities and process equipment must be assessed and classified as direct impact, indirect impact or no impact following an analysis of their impact on the identity, strength, quality, purity or safety of products manufactured at the facility and also the safety of the operators & environment.

Impact on Quality

Each system or item of equipment having direct or indirect impact on the product quality must be validated. The extent of validation or qualification should be determined by performing the risk assessment of that particular system or equipment.

Join the Discussion

Use our community to find our more about validation and qualification.
http://community.learnaboutgmp.com/t/qualification-vs-validation/874

13
shares

Similar articles:

The Difference Between Prospective, Concurrent and Retrospective Validation

Unless you’re starting a new company you will need to plan on a variety of approaches.

Prospective validation occurs before the system is used in production, concurrent validation occurs simultaneously with production, and retrospective validation occurs after production use has occurred.

In this article we will discuss all three and also discuss the role the master validation plan (MVP) performs for each one.

1. Prospective Validation

Prospective validation is establishing documented evidence, prior to process implementation, that a system performs as is intended, based on pre-planned protocols.

This is the preferred approach.

Production is not started until all validation activities are completed.

The MVP need not go into much detail about this approach since it’s the standard method, however, prospective validation follows a step wise process illustrated here.

The process commences with the development of a Validation Plan and then passes through the DQ, RA, IQ, OQ and PQ phases after which process, computer, analytical and cleaning validations are performed which are followed by a final report.

After which the instrument or equipment will be subject to preventative maintenance and requalification on a routine basis.

Periodic Basis

On a periodic basis all instrumentation and equipment should be reviewed. This review is intended to identify any gaps which may have developed between the time it was last qualified and current requirements.

If any gaps are identified a remediation plan will be developed and the process will start again.

The MVP

The MVP may need to describe what is done with product produced during prospective validation. Typically, it is either scrapped or marked not for use or sale.

The product may be suitable for additional engineering testing or demonstrations, but appropriate efforts need to be made to ensure this product does not enter the supply chain.

Ideally, all validation is done prospectively; i.e., the system is validated before use. However, there are cases and conditions which may prevent this.

2. Concurrent Validation

Concurrent validation is used to establish documented evidence that a facility and process will perform as they are intended, based on information generated during actual use of the process.

In exceptional circumstances (for example, in a case of immediate and urgent public health need) validation may need to be conducted in parallel with routine production. The MVP needs to define how product is managed throughout the process.

Typically, the product batches are quarantined until they can be demonstrated (QC analysis) to meet specifications.

The Right Decision?

The decision to perform concurrent validation should not be made in a vacuum. All stakeholders including management, Quality Assurance and the government regulatory agencies should all agree that concurrent validation is an acceptable approach for the system under consideration.

As always the principal requirement is patient safety is not compromised. The rationale to conduct concurrent validation should be documented along with the agreement to do so by all the stakeholders. This can be part of the Validation Plan or documented as a deviation.

The Process

The concurrent validation process is identical to that of prospective validation. The process starts with the development of a Validation Plan, followed by the DQ, RA, IQ, OQ and PQ phases after which process, computer, analytical and cleaning validations are performed, ending with a final report.

Again, routine preventative maintenance, requalification and periodic review are performed.

3. Retrospective Validation

Retrospective validation is validating a system that has been operating for some time. There are various schools of thought on how to approach retrospective validation. Some may feel that a full-blown validation is required to assure the system is functioning properly.

Others may feel that since the system has been in use, presumably without issues, validation is not necessary and a memo to file justifying why validation is not necessary may be issued.

Doing a full validation may not be required, since you already have proof that the system functions as required – at least in the situations in which production was conducted. Doing nothing, though, is a risk.

It’s likely that the controls haven’t been challenged so there may be some hidden flaws that haven’t been identified that could lead to non-conforming product, hazardous operating conditions, extended delays, etc.

Historical Data

Historical data can certainly be used to support validation. For example, if there is detailed and statistically-significant evidence that production runs are well controlled you could rationalize and justify not doing full validation.

During retrospective validation, it’s advisable that existing product be quarantined, and production put on hold until validation is complete.

As an exception, producing product as part of the validation exercise would follow concurrent validation. This may not be practical since product may have already been distributed, but caution is advised for the reasons outlined.

General Process

The general process for retrospective validation follows the same process as for prospective and concurrent validation except DQ is seldom performed, as the system has already been in use for some time.

Instead a survey and review of available information is performed. This normally occurs before the validation plan is created.

The MVP should also provide guidance on managing inventory during retrospective validation.

One Major Issue

One potential major problem that can occur with retrospective validation the determination of what action should be taken if an issue is found with the system during retrospective validation?

As with everything else, a risk-based decision is warranted. This could be anything from product recall, to customer notifications, to just documenting the justification of the decision why nothing was done.

Again, the MVP should provide guidance on dealing with situations concerning out of specification conditions revealed during retrospective validation, which should also definitely include involving regulatory support.

17
shares

TOP

Similar articles: