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.

FDA issues new guidance on Post Approval Changes

This past week the FDA issued a draft guidance “Post Approval Changes to Drug Substances” from the Center for Drug Evaluation and Research on post-approval changes for drug substances to provide clarity to holders of drug master files and holders of new and generic drug applications on which reporting category manufacturing changes fall into as well as the information required to support these changes.

Like any guidance this is supposed to “describe the Agency’s current thinking on a topic” and in this case this is a pretty important guidance as it is the first on the subject of change management published after the draft of Q12. It also clearly builds on the concepts of Q11 and is the first time the agency has published a guidance on drug substance post approval changes.

The guidance covers changes to facility; scale and equipment changes; specification changes to starting materials; synthetic manufacturing process changes; and, changes to the container closure systems for the drug substance.

It uses the traditional breakdown of major changes (prior approval supplement category), Moderate changes (changes-being-effected-30 (CBE-30) category) and Minor changes (annual report).

The guidance provides some solid requirements for risk assessments, and requires the risk assessment be included with the filing of change. This will require some companies to improve their risk management process, and may cause some to question decision making about their internal formulas for level of effort and the formality of risk management.

The deadline for public comment on the draft is Nov. 13. Submit comments to the docket at: https://www.regulations.gov/docket?D=FDA-2018-D-3152.

Sometimes quality requires forgetting

DeHolan and Phillips introduced the concept of organizational forgetting to our concepts of knowledge management. While unintentional forgetting is something we usually want to avoid, there is a time when we want to intentionally forget. Perhaps after a corporate merger we are combining systems or replacing systems. Perhaps it is the result of a large step forward in technology, or an out-right replacement. Some major cultural transformation comes along. And the last thing we want is for no-one to be able to forget the old. For those concepts to linger in our memory and our decisions. For that is a risk that can easily lead to deviations.

4529-si1-lo8

Take for example changes in document numbering. Fairly simple of the surface but remember that procedure number is the tag which we use in conversation. No-one ever gives the whole title; we throw around these tags left and right and for our own coded language (another topic worthy of a blog post). Then we change our numbering format and a year later everyone still uses the old number. And mistakes start creeping up. Or just the perception of mistakes builds. Or perhaps everyone still thinks in the manner of the old ERP’s logic, and forget to do crucial aspects of master data management when a change is made. You get the idea

This purposeful frogetting, an aspect of knowledge management (and change management) – that of the purposeful removal of knowledge — is a critical step in our systematic approach and an important part of our strategic toolkit. However, it is very difficult, as deeply embedded pieces of organizational knowledge are generally locked in place by various other pieces of organizational knowledge that depend on them, and removing one implies modifying the others as well. We need to develop the tools to dismantle the previous way of doing work — the unneeded routines and formerly dominant logics of our changed systems.

One of the best way to do this is to get rid of cues. All the little breadcrumbs left behind. If you want people to stop using old document numbers, ensure that no document folks would use on their daily basis has those numbers. However, this ideal model of radical elimination of all cues associated with the old routine seems rather unlikely in all changes from old to new . So when we are working on our change its important to select those cues that will have the biggest bang for our buck. Some general ideas to help inform this are:

Look for opportunities to drive out mix-messages – aim for consistency in message
Ensure there are positive reinforcements for use of the new routine
Actively constrain the to-be-forgotten activity. Reduce the time in two different processes. Do a radical transformation. Reduce the confusion.
Reward the individual for participating in the new way. The group can’t change faster than the sum of the individuals, so incentive the change.

When doing a change it is important to consider these as risks, and build into your change plan. Incorporate into your training. For the basis of your communications. Drive out the old, embrace the new. Otherwise you are just increasing the risks inherent in your new way of working. But like many aspects of change management, easy in concept, difficult in execution.

Document Management

Today many companies are going digital, striving for paperless, reinventing how individuals find information, record data and make decisions. It is often good when undergoing these decisions to go back to basics and make sure we are all on the same page before we proceed.

There are three major types/functions of documents:

Functional Documents provide instructions so people can perform tasks and make decisions safely effectively, compliantly and consistently. This usually includes things like procedures, process instructions, protocols, methods and specifications. Many of these need some sort of training decision. Functional documents should involve a process to ensure they are up-to-date, especially in relation to current practices and relevant standards (periodic review)
Records provide evidence that actions were taken and decisions were made in keeping with procedures. This includes batch manufacturing records, logbooks and laboratory data sheets and notebooks. Records are a popular target for electronic alternatives.
Reports provide specific information on a particular topic on a formal, standardized way. Reports may include data summaries, findings and actions to be taken.

Often times these types are all engaged in a lifecycle. An SOP directs us to write a protocol (two documents), we execute the protocol (a record) and then write a report. This fluidity allows us to combine the types.

Throughout these types we need to apply good change management and data integrity practices (ALCOA).

All of these types follow a very similar path for their lifecycle.

Everything we do is risk based. Some questions to ask when developing and improving this system include:

What are the risks of writing procedures at a “low level of detail versus a high level of detail) how much variability do we allow individuals performing a task?) – Both have advantages, both have disadvantages and it is not a one-sized fits all approach.
What are the risks in verifying (witnessing) non-critical tasks? How do we identify critical tasks?
What are the risks in not having evidence that a procedure-defined task was completed?
What are the risks in relation to archiving and documentation retrieval?

There is very little difference between paper records and documents and electronic records and documents as far as what is given above. Electronic records require the same concerns around generation, distribution and maintenance. Just now you are looking at a different set of safeguards and activities to make it happen.