Changes that impact multiple product

Dear all, regarding question 20 “Is the effective date of the change (completion date) recorded and when appropriate the first batch manufactured recorded?” we are not sure how to handle it for multi-product changes. At our site we manufacture products of different customers. Sometimes we have changes, where f.e. documents of several products need to be adapted. How are the requirements defined in such cases? Do we need to report the first batch only once or for each product

Correspondent

This request comes from my post “29 questions to ask about your change management/change control system.”

At heart, this requirement is to help meet the regulatory requirement that “After implementation, an evaluation of the change should be undertaken to confirm the change objectives were achieved and that there was no deleterious impact on product quality.” (ICH Q9 part IV.B.3.d)

In order to perform an evaluation, you must be able to know when to start. This evaluation must be able to be performed on each and every product. It is from here we can settle on 1st batch. There are lots of ways to do this. The requirement is, for each and every product, to be able to state definitively when the change was first applied to the product.

We can drill down to the most definitive guidance on GMP Change Control, the PIC/S Recommendation “How to Evaluate and Demonstrate the Effectiveness of a Pharmaceutical Quality System in relation to Risk-based Change Management” which further strengthens the requirement:

SectionRequirementMeans
5.4. Change Review and EffectivenessChanges are monitored via ongoing monitoring systems to ensure maintenance of a state of control, and lessons learned are captured and shared/communicated. (Note: Activities such as Management Review, Annual Product Quality Review, Continuous Process Verification, Deviation Management and Complaint Monitoring can be useful in this regard.)Having that definitive point allow all these activities to be effective.

The requirement is clear. We need to be able for any given change identify when it started impacting product.

All of the various Annual Product Review/Product Quality Review requirements also require the ability to evaluate all changes to the product in a given time frame.

There is also the need, for release purposes, to determine if a batch is impacted by a change.

Like many such requirements, there are multiple ways to do this. I think the requirement to capture first batch in a change control really stems from it, in many ways, being the easiest to do as you only have to manage it in the change control workflow. Though, in all honesty, it is also darn annoying with changes potentially being open more than a year to capture all possible products.

Based on our core requirement, there are several factors to consider:

  • There must be a way for a user to easily determine when a given change impacted a given product and to determine if a given batch was impacted by the changes
  • The user must be able to link any batch to all the changes that impacted it
  • The user must be able to run a report of all changes that impacted a product in a time frame

There are multiple ways of solving for this from the put a field in the change control to set of interfaces between the ERP and eQMS (and maybe MES).

Change Management is Bigger than Change Control So Think Beyond Individual Changes

As a pharmaceutical GXP professional with one foot in the GXP Quality camp and another in the organizational change management camp, I have a few pet peeves. And one of my biggest is whenever someone uses a phrase like “Change management may be known by different terminologies (e.g., change control, change requests, change orders).” That’s a reductionist statement that can really lead to a lot of confusion in an organization.

Change management is the how of change – assess, handle and release. Change control is the what, the execution steps. Change management is a big picture system that looks systematically at people, technology, process, and organization. Change control is the set of mechanisms for controlling the introduction of that change to the organization.

A lot of different systems and processes have change control elements. As many of these processes are supported with specific technologies, it can be very important to think about how they fit together like a puzzle.

This puzzle is usually made up of core requirements. Based on how much the change impacts them decides the rigor of the change control process.

Take for example a pharmaceutical manufacturing site. It is fairly typical to have one process for maintenance, another for IT, another for documents, etc. And then you have a change control system for things that impact established conditions, including validated state and regulatory submissions. Maybe you work at some technological utopia with a single system that manages all changes with all the deliverables, but at most places, you are trying to balance efficiency with effectiveness, and have a real need to avoid unnecessary duplication.

ICH Q12 helps by giving a nice breakdown of the major families of changes.

This helps somewhat, but for the average user it is not very specific. We need to translate it. First, we establish that only one system will be used for regulatory impact (“Tell and Do”, “Do and Tell” “Do and Report” and some of “Do and Record”), then we put the major activities that go into it. This breakdown might look like:

We are utilizing a few major criteria:

  1. Impact of regulated state
  2. Impact of validated state
  3. Risk level of change
  4. Scale of change to the organization

Using these criteria we can even drill down further, for example:

FEU Changes as a flowchart

It is usually a good idea to go down to an even deeper level to help the end-user.

Requires CCR

Does Not Require CCR

Any change that impacts the integrity of controlled classified areas, including all room and equipment surfaces

 

Changes that do not impact integrity of controlled classified areas by meeting the following criteria:

·     Does not change airflow

·     Does not impact structural integrity and maintains a smooth cleanable surface

·     Does not change means of ingress/egress

·     Does not impact current sampling sites from the Environmental Monitoring Program

·     Materials used are resistant to cleaning agents used in the area as defined in the building specifications

·     Materials are included in disinfectant effectiveness study

Any change that impacts air balancing

Work that is part of routine or preventive maintenance or calibration

Changes to equipment or replacements with a functional equivalent or different component

Changes to equipment with an exact component

Changes to facility floor layout

Instrument calibration including adjustments to field instrumentation

Changes to equipment operating and control parameters

Removal/storage of portable equipment

Changes to equipment, material and personnel ingress, egress and flow procedures

Replacement of system instrument hardware with exact components (hardware)

Changes to room classifications

Engineering studies that do not change the validated state or change anything requiring a CCR per this procedure

Changes that impact the environmental integrity of a room

Alarm set point changes that return to the previous qualified/validated state

Replacement and/or decommissioning of equipment, utilities or facilities

Remediation work (such as mechanical polishing, weld repairs, electro-polishing, filling of pits, de-rouging and chemical cleaning with already approved material)

Alarm set point or classification changes

Addition, modification or deletion to Potable Water, Plant Steam, Chilled Water, Cogeneration System, or pre-treatment reverse-osmosis

Changes in intended use of a room or area

Modification to piping tied to Potable Water, Plant Steam, Chilled Water, Cogeneration System, or pre-treatment reverse-osmosis

Changes to Preventive Maintenance that includes:

·     Decreasing frequency of preventive maintenance (i.e. making less frequent)

·     Change in intent of a preventive maintenance task

·     Adding or removing tasks

Changes to Preventive Maintenance that include:

·     Increasing frequency of preventative maintenance (i.e. making more frequent)

·     Administrative changes

·     Adding clarity to a task (e.g. changing instructions on how to execute a task without altering the intent of the task)

·     Reordering task(s) without changing intent of the task(s)

·     Changes of tools needed to execute a task; room dedicated tools must remain in the designated area

·     Changes to quantity of materials

Changes that decrease the calibration frequency (i.e. make less frequent) for GMP Critical equipment (e.g. directly related to operational control of the product)

·     Changes that increase calibration frequency (i.e. make more frequent) for GMP Non-Critical equipment (e.g. indirectly related to operational control of the product)

Tuning parameter, adjustment to the gain, reset and rate of a PID controller

New or replacement analytical equipment or instruments identified as Category A or Category B-Calibration Only with an exact component

Changes to the calibration frequency of GMP critical equipment (e.g. directly related to operational control of the product)

Changes to manufacturing report properties

Changes to the Environmental Monitoring Program, including addition, deletion or change to a sample location

Changes to alarm paging/notification recipients

Changes to the program for disinfection of a facility or equipment exterior

Creating/modifying individual user accounts

Change of materials of construction or class of polymeric materials (e.g. elastomers, tubing, gaskets and diaphragms)

Add an instrument to the calibration system during pre-commissioning

Changes to hardware or infrastructure associated with a validated system, equipment or utility

Changes to requalification frequency that do not change the intended use or validated state of the equipment or utility

Upgrade of application software or operating system for validated systems, equipment or utility

Corrective changes to an SOP to align it to the validated state

Changes to an SOP to align it to the validated state with impact to one or more regulatory filings

A corrective change to alarm set points to align with the validated state

Creating user groups and/or modifying user group privileges as part of a larger process change associated with validated systems, equipment, or utilities

Addition of a new calibration standard to be used with a new type of instrument at the Alachua site

Creating user groups and/or modifying user group privileges associated with validated systems, equipment, or utilities

Changes to alarm paging/notification recipients

Addition of a new calibration standard to be used with a new type of instrument at the Cambridge and Lexington sites

 

Modifying a phase prompt or message associated with validated systems, equipment, or utilities

 

Addition / change of a graphic associated with validated systems, equipment, or utilities

 

Addition or changing an interlock/permissive trigger

 

Addition/removal of I/O of validated systems

 

Changes to the Environmental Monitoring Program, including addition, deletion or change to a sample location

 

Changes to alarm paging/notification functionality

 

Historical data collection configuration

 

Change of equipment and spare parts storage site, including transfers between facilities and transfers to a contracted third party

 

 

All of this is change management. We utilize multiple change control mechanisms to manage the change.

Also, don’t forget that change controls can nest. For example a change to the EQMS has IT changes, document changes, training changes, and probably more.

Changes, Changes Everywhere

It is sometimes unfortunate that ICHQ10 defines Change Management as “A systematic approach to proposing, evaluating, approving, implementing and reviewing changes.” This lifecycle approach can sometimes confuse people as they are used to the definition popular elsewhere that change management is “the discipline that guides how we prepare, equip and support individuals to successfully adopt change in order to drive organizational success and outcomes.”

I tend to think this is an issue of focus and lack of coherence in the organization that stems from:

  • Not understanding that all changes are to a system that involves people, organization, technology and process
  • Balkanized change processes leads to changes being atomized or channeled though discrete processes that do not drive system thinking

Both of these can lead to a change going to a default change control process and not appropriately dealing with all aspects of the change. Teams tend to have their default (IT puts everything in as a computer change, facilities always uses a an equipment change) but those defaults are not built to deal with a change holistically.

Change is a movement out of a current state (how things are today), through a transition state, and to a future state (how things will be done). Change management needs to be about how we manage that change from the entire system – people, organization, technology and process. Only by approaching change from a full system perspective do we ensure the full benefit and avoid unintended consequences.

Change Identification

Changes come from everywhere. They are driven by other quality processes, by business needs, by innovation. To quickly address change it is important to have a good funnel system that will get the change to evaluation.

Change Evaluation

All changes should be evaluated for risk and impact. This evaluation is iterative and determines the level and form of evaluation.

Change Control

Right sized change control based on risk and impact. Some changes are one-and-done. But many are multi-faceted, and it is important to structure it appropriately.

I’ve written a lot on change management that covers this in more detail. Explore them here

2020 FDA 483s around change

The yearly database of 483s has been updated by the FDA. Lots will be written on themes as we end the year, so I decided to give a few of my immediate observations.

I find that over time what I focus in on changes, as my jobs evolve and change, and the interests I have shift. However, some things never change, so let us talk change.

Reference NumberShort DescriptionLong Description2020 Frequency2019 Frequency2018 Frequency
21 CFR 211.100(a)Changes to Procedures Not Reviewed, ApprovedChanges to written procedures are  not [drafted, reviewed and approved by the appropriate organizational unit] [reviewed and approved by the quality control unit].  Specifically, ***8139
21 CFR 211.160(a)Lab controls established, including changesThe establishment of [specifications] [standards] [sampling plans] [test procedures] [laboratory control mechanisms] including any changes thereto, are not [drafted by the appropriate organizational unit] [reviewed and approved by the quality control unit].  Specifically, ***41817
21 CFR 212.20(c)Adverse effects of changes madeYou did not demonstrate that any change does not adversely affect the [identity] [strength] [quality] [purity] of your PET drug. Specifically,***111
483s related to changes

I think its fair to say the decreases as a result of the pandemic and the reduced inspections.

Over on the device side of things we see:

Reference NumberShort DescriptionLong DescriptionFrequency
21 CFR 820.30(i)Design changes – Lack of or Inadequate ProceduresProcedures for design change have not been [adequately] established.  Specifically,***26
21 CFR 820.40(b)Document change records, maintained.Records of changes to documents were not [adequately] maintained.  Specifically, ***6
21 CFR 820.70(b)Production and Process Change Procedures, lack of or Inad.Procedures for changes to a [specification] [method] [process] [procedure] have not been [adequately] established.  Specifically, *** 5
21 CFR 820.75(c)Process changes – review, evaluation and revalidationA validated process was not [reviewed and evaluated] [revalidated] when changes or process deviations occurred. Specifically, ***5
21 CFR 820.40(b)Change records, contentRecords of changes did not include [a description of the change] [identification of the affected documents] [the signature of the approving official(s)] [the approval date] [when the change became effective].  Specifically, ***



3
21 CFR 820.50(b)Supplier notification of changesThere is no agreement with [suppliers] [contractors] [consultants] to notify you of changes in the product or service.  Specifically, ***3
21 CFR 820.75(c)Documentation – review in response to changes or deviationsThere is no documentation of the [review and evaluation of a process] [revalidation of a process] performed in response to changes or process deviations.  Specifically, ***1
Device 473s around change

I’m a firm believer that pharma should always pay attention to the medical device side for 483s. A lot of us are combination products now (or will be) and there is always good trends to be aware of.

My key takeaways:

  1. Think change management and not just change control and document control
  2. Computer change controls need to be holistic and system orientated
  3. Have a process that ensures changes are appropriately reviewed and approved
  4. Risk based and evaluate validation
  5. A robust supplier management program is critical, plan for change

Here’s a more detailed checklist to help you evaluate your change system.

PIC/S on Change Review and Effectiveness

Starting from the end, let’s review some of the requirements in the new draft PIC/S guidance.

Prior to change closure

RequirementImportant Points
Changes meet their intended objectives and pre-defined effectiveness criteria. Any deviations from those criteria are adequately assessed, accepted and managed/justified. Whenever possible, quantitative data are leveraged to objectively determine change effectiveness (e.g. statistical confidence and coverage).Clearly delineating what effective means as a date is critical to generate data.

CQV activities can tell you if the intended objective is met. Effectiveness reviews must be made up of:

Sufficient data points, as described in the implementation plan, gathered to a described timeline, before an assessment of the change is made.

The success criteria should be achieved. If not, reasons why they have not been achieved should be assessed along with the mitigation steps to address the reasons why, including reverting to the previous operating state where appropriate. This may require the proposal of a subsequent change or amendment of the implementation plan to ensure success.

Data and knowledge gathered from implementation of the change should be shared with the development function and other locations, as appropriate, to ensure that learning can be applied in products under development or to similar products manufactured at the same or other locations
As part of the quality risk management activities, residual risks are assessed and managed to acceptable levels, and appropriate adaptations of procedures and controls are implemented.These are action items in the change control.

As part of the closure activities, revise the risk assessment, clearly delineating risk assessment in two phases.
Any unintended consequences or risks introduced as a result of changes are evaluated, documented, accepted and handled adequately, and are subject to a pre-defined monitoring timeframe.Leverage the deviation system.

Prior to or after change closure

RequirementImportant Points
Any post-implementation actions needed (including those for deviations from pre-defined acceptance criteria and/or CAPAs) are identified and adequately completed.If you waterfall into a CAPA system, it is important to include effectiveness reviews that are to the change, and not just to the root cause.
Relevant risk assessments are updated post-effectiveness assessments. New product/process knowledge resulting from those risk assessments are captured in the appropriate Quality and Operations documents (e.g. SOPs, Reports, Product Control Strategy documents, etc.)Risk management is not a once and done for change management.
Changes are monitored via ongoing monitoring systems to ensure maintenance of a state of control, and lessons learned are captured and shared/communicated.Knowledge management is critical as part of the product management lifecycle.

Lessons learned are critical.