Group change controls

A colleague asks:

hoping you can provide your perspective on “grouping changes”. That is, rules or guidance on when it is appropriate to lump several small changes into one change control.

There are lots of reason’s to want to group changes into one change control – ease of implementation, a perception of “reducing work” or just convenience. I apply three general rules for when this is a good idea:

  1. Implementation
  2. Release of product
  3. Concreteness of work package

Implementation

All changes should have the same  “Change in User” and “Regulatory Approval”

I talked about this is in “Changes become effective“:

Tell and Do Do and Tell Do and Report
Change in use After regulatory approval. When change is introduced to the ‘floor’ When change is introduced to the ‘floor’ When change is introduced to the ‘floor’
Regulatory approval Upon approvals After use, before send to market Upon reporting frequency (annual, within 6 months, within 1 year)
Sent to market After regulatory approval and change in use After regulatory approval and change in use After change in use

Ideally chose all changes that are “Do and Tell” or “Do and report”, I strongly do not recommend blending “Tell and Do,” there are just so many complexities here and it can lead to a constant revision of change controls and even increase risk of inadvertently sending products to the market.

Release of Product

All changes bundled together need to be releasable at the same time. Look at PQ/PV requirements and other testing that can be different and keep them in segregated change controls. Putting product on stability (or even needing stability data) is another good reason to separate changes.

Similarly, keep changes that have different internal product segregation requirements unbundled.

Concreteness of Work Bundles

The best reason to bundle changes is that they involve changing the same things: same documents, same automation, same piece of equipment. Once the bundling starts increasing scope of the change, it is time to have separate change controls.

If bundling changes starts changing your project management triangle (resources, time, scope)  then do a deep evaluation. You probably have separate change controls, even if they are under the same project.

Evaluate effectiveness reviews. Chances are totally separate effectiveness reviews for same impacted area are really separate changes.

What about risks?

You might notice that I do not call out risks as one of the criteria. Risks drive mitigations, which drive impact to the three criteria I gave. If a high risk’s mitigation does not trigger one of these criteria, it is usually not a problem to group the changes together. Though I’d pause and consider why the addition of a change that adds high risks does not change drive mitigations that change the amount of work I am doing and ensure that is appropriately documented.

Conclusion

Sometimes bundling changes make sense. other times you will curse the day you agreed to bundle. I find these three rules provide a framework for making the decision.

Change Control- Leveraging regulatory inspection data

The Pfizer McPherson site has been under a great deal of regulatory scrutiny, and as a result there is a lot we can learn from their findings.

In July the MHRA stated the following:

Hospira McPherson Changes

There is a lot to unpack here, and for most of it I can pull up some previous postings to start with:

Breaking down change controls is both a necessity and a difficulty. I talked about the need for a change strategy when breaking up changes. This connective tissue will help with issues like 2.4.1.1 above and can also serve as a good playbook for discussing the changes with an inspector. This is especially important when you find you need to implement related changes at different times. I talked about the various implementation dates in some detail.

Risk assessments are only getting more important, and for a company with international distribution it is important to consider the risks inherent to your regulatory strategy and distribution strategy and mitigate.

regulatory and change

If you have changes that will have long tails of regulatory approvals, then your change control needs to have the right controls to ensure appropriate and safe supply.

Build your actions to address all risks and impacts and ensure they are appropriately carried through.

action items

Finally ensure your change control process has a way to revise the plan and ensure all stakeholders are included in the decisions.

 

Computer system changes and the GAMP5 framework

Appropriate controls shall be exercised over computer or related systems to assure that changes in master production and control records or other records are instituted only by authorized personnel. Input to and output from the computer or related system of formulas or other records or data shall be checked for accuracy. The degree and frequency of input/output verification shall be based on the complexity and reliability of the computer or related system. A backup file of data entered into the computer or related system shall be maintained except where certain data, such as calculations performed in connection with laboratory analysis, are eliminated by computerization or other automated processes. In such instances a written record of the program shall be maintained along with appropriate validation data. Hard copy or alternative systems, such as duplicates, tapes, or microfilm, designed to assure that backup data are exact and complete and that it is secure from alteration, inadvertent erasures, or loss shall be maintained.

21 CFR 211.68(b)

Kris Kelly over at Advantu got me thinking about GAMP5 today.  As a result I went to the FDA’s Inspection Observations page and was quickly reminded me that in 2017 one of the top ten highest citations was against 211.68(b), with the largest frequency being “Appropriate controls are not exercised over computers or related systems to assure that changes in master production and control records or other records are instituted only by authorized personnel. ”

Similar requirements are found throughout the regulations of all major markets (for example EU 5.25) and data integrity is a big piece of this pie.

So yes, GAMP5 is probably one of your best tools for computer system validation. But this is also an argument for having one change management system/one change control process.

When building your change management system remember that your change is both a change to a validated change and a change to a process, and needs to go through the same appropriate rigor on both ends. Companies continue to get in a lot of trouble on this. Especially when you add in the impact of master data.

Make sure your IT organization is fully aligned. There’s a tendency at many companies (including mine) to build walls between an ITIL orientated change process and process changes. This needs to be driven by a risk based approach, and find the opportunities to tear down walls. I’m spending a lot of my time finding ways to do this, and to be honest, worry that there aren’t enough folks on the IT side of the fence willing to help tear down the fence.

So yes, GAMP5 is a great tool. Maybe one of the best frameworks we have available.

gamp5

 

Effective Change Management

Both Curious Cat and A Lean Journey tell me that the ASQ Influential Voices blogs are covering change management. I do love a good blog carnival, and change management is sort of my thing, so I am going to jump in.

It’s often said that people don’t resist “change” so much as they resist “being changed.” So, the job of change management is clear: In a nutshell, you must explain why the affected people should want to change, and thereby cultivate readiness instead of resistance.

 What are some recommended strategies or tactics to help achieve successful change management?

My first piece, of advice, abandon the idea that change management only involves people. Just as all systems are made of people, organization, process and technology; all changes impact all four and need to be viewed holistically.

Second, get rid of the artificial barriers between change management and change control. Change management is the how of change – assess, handle and release. Change control is the what, the execution steps. Remember that all changes are really just projects, and vice versa. The level of change determines the level of activity.

Level of Change Change Management Change Control
Transactional Minor Few

Closely clustered

Operational Major Several

Across several areas

Transformational Fundamental Many

Iterative

Often in waves

Simplify your variety of change controls and strive for scalability within one change management (and control) system. Utilize the levers, which include: regulatory (compliance), product release and risk.

Knowledge Management

Change Management and Knowledge Management are closely entwined. An effective change management system includes active knowledge management, in which information from multiple sources is integrated to identify stimuli for changes needed to improve product and/or process robustness.

There are key interactions with document management and training.

Risk Management

Risk management enables changes and helps assess:

  • The proposed change
  • The effectiveness of the change once implemented

Change Is

Propose the Change

curent and future

Make it SMART:

  • Specific – The proposal needs to be accurate and leave no doubt as to what the change will achieve.
  • Measurable – How will the system owner (sponsor) know when the project is complete.
  • Achievable – Make the change as small as possible after all it is easier to eat an elephant one bite at a time. It is far easier to manage a few smaller change than one big one. This is why operational and transformational changes are many changes and often iterative.
  • Realistic – Make the change easy to deliver, if it is over complicated then it is likely to hit problems and run over budget, be delivered late or of poor quality.
  • Timely – Does the change have to be complete by a certain date? If so put it in the scope that the project has to be complete by that date. Are there dependencies and independencies?

Evaluate

The change Project team leverages SMEs to harness the collective intelligence (synergy) for the benefit of the site.

  • Relevancy – The information gathered is of value
  • Reliability – The process by which the information is collected should be consistent
  • Accuracy – The data should be expressed in a manner that most accurately reflects its information content
  • Efficiency – The design and implementation of the tasks should minimize the burden

Evaluates all four areas (process, technology, people and organization). Includes communication of the change and training.

Vision Importance
What is the vision for this change Why is this change important to our organization
Success Measurements Process Measurements
How will we measure success How will we show progress towards our vision?
Who and what is affected?
What people, departments and processes need to change in order to realize our vision?
How will we support people?
What actions will we do to support people through the change?
What is our plan?
Detailed action plan

Build in effectiveness reviews to your plan.

Implement

Execute the change plan, provide evidence of completion. Escalate significant risks or delays.

Close

Ensure change plan was executed and benefits realized.

Hold a lessons learned.

lessons learned

Conclusion

Change management is a system. It should have its own cycles of improvement and grow as you execute changes. Change is a fundamental pillar of a quality system and spending the time to build a robust system will reap dividends and prove itself a good idea again and again.

 

 

Master and Transactional Data Management

Mylan’s 483 observation states that changes were being made to a LIMS system outside of the site’s change control process.

This should obviously be read in light of data integrity requirements. And it looks like in this case there was no way to produce a list of changes, which is a big audit trail no-no.

It’s also an area where I’ve seen a lot of folks make miss-steps, and frankly, I’m not sure I’ve always got it right.

There is a real tendency to look at the use of our enterprise systems and want all actions and approvals to happen within the system. This makes sense, we want to reduce our touch points, but there are some important items to consider before moving ahead with that approach.

Changes control is about assessing, handling and releasing the change. Most importantly it is in light the validated and regulatory impact. It serves disposition. As such, it is a good thing to streamline our changes into one system. To ensure every change gets assessed equally, and then gets the right level of handling it needs, and has a proper release.

Allowing a computer system to balkanize your changes, in the end, doesn’t really simplify. And in this day of master data management, of heavily aligned and talking systems, to be nimble requires us to know with a high degree of certainty that when we apply a change we are applying it thoroughly.

The day of separated computer systems is long over. It is important that our change management system takes that into account and offers single-stop shopping.