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

Changes become effective

Change Effective, implementation, routine use…these are all terms that swirl in change control, and can mean several different things depending on your organization. So what is truly important to track?

regulatory and change

Taking a look at the above process map I want to focus on three major points, what I like to call the three implementations:

  1. When the change is in use
  2. When the change is regulatory approved
  3. When product is sent to a market

The sequence of these dates will depend on the regulatory impact.

  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

I’m using ‘floor’ very loosely here. “Change in use” is that point where everything you do is made, tested and/or released under the change. Perhaps it’s a batch record change. Everything that came before is clearly not under the change. Everything that came after clearly is.

You can have the same change fit into all three areas, and your change control system needs to be robust enough to manage this. This is where tracking regulatory approval per country/market is critical, and tracking when the product was first sent.

A complicated change can easily look like this (oversimplification).

building actions

Is this 1, 2 or 3 processes? More? Depends on so many factors, the critical part is building the connections and make sure your change control system both receives inputs and provides outputs. Depending on your company, the data map can get rather complicated.

29 questions to ask about your change management/change control system

While these questions are very pharma/biotech specific in places, they should serve as thought process for your own system checkup.

  1. Is there a written SOP covering the change control program that has been approved by the Quality Unit?
  2. Do procedures in place describe the actions to be taken if a change is proposed to a starting material, product component, process equipment, process environment (or site), method of production or testing or any other change that may affect product quality or reproducibility/robustness of the process?
  3. Does the SOP ensure that all GMP changes are reviewed and approved by the Quality Unit?
  4. If changes are classified as “major” or “minor,” do procedures clearly define the differences?
  5. Does your change management system include criteria for determining if changes are justified?
  6. Are proposed changes evaluated by expert teams (e.g. HSE, Regulatory, Quality…)?
  7. Is there a process for cancelling a change request prior to implementation? And Is a rationale for cancellation included?”
  8. Does your Change control management site procedure describe clearly the process to close a change request (After all regulatory approvals…)?
  9. Are any delays explained and documented?
  10. Is there a written requirement that change controls implemented during normal or routine maintenance activities be documented in the formal change control program?
  11. Is your change management system linked to other quality systems such as CAPA, validation, training?
  12. Does your change management system include criteria for determining if changes will require qualification/requalification, validation/revalidation and stability studies?
  13. Are “like for like” changes (changes where there is a direct replacement of a component with another that is exactly the same) clearly defined in all aspects (including material of construction, dimensions, functionality,,,) ? Are they adequately documented and commissioned to provide traceability and history?”
  14. Is there an allowance for emergency and temporary changes under described conditions in the procedures?
  15. Are the proposed changes evaluated relative to the marketing authorization and/or current product and process understanding?
  16. Does your change management system include criteria to evaluate whether changes affect a regulatory filling?
  17. When appropriate are regulatory experts involved? Does the regulatory affairs function evaluate and approve all changes that impact regulatory files?
  18. Are changes submitted/implemented in accordance with the regulatory requirements?
  19. Is there a defined system for the formalization, roles and responsibilities for change control follow-up?
  20. Is the effective date of the change (completion date) recorded and when appropriate the first batch manufactured recorded?
  21. Is there a periodic check of implementation of Change controls?
  22. Following the implementation, is there an evaluation of the change undertaken to confirm the change objectives were achieved and that there was no adverse impact on product quality?
  23. Is all documentation that provides evidence of change, and documentation of requirements, controlled and retained according to procedure?
  24. When necessary, are personnel trained before the implementation of the change?
  25. Are change controls defined with adequate target dates?
  26. If the change control goes beyond the target date, is there a new date attributed, evaluated and documented by Quality Assurance?
  27. Are there routine evaluations of the Change controls and trends (number, Change controls closure, trends as defined)?
  28. Are changes closed on due date ?
  29. Are the Change controls and follow-up formalized in a report and/or periodic meetings?

These sort of questions form a nice way to periodically checking up on your system performance and ensuring you are moving in the right direction.

Training assessment as part of change management

One of the key parts of any change (process improvement, project, etc) is preparing people to actually do the work effectively. Every change needs to train.

Building valid and reliable training at the right level for the change is critical. Training is valid when it is tied to the requirements of the job – the objectives; and when it includes evaluations that are linked to the skills and knowledge started in the objectives. Reliability means that the training clearly differentiates between those who can perform the task and those who cannot.

A lot of changes default to read-and-understand training. This quite bluntly is the bane of valid and reliable training with about zero value and would be removed from our toolkit if I had my way.

There are a lot of training models, but I hold there is no single or best method. The most effective and efficient combination of methods should be chosen depending on the training material to be covered and the specific needs of the target group.

For my purposes I’ll draw from Edgar Dale’s Cone of Experience, which incorporates several theories related to instructional design and learning processes. Dale theorized that learner’s retain more information on what they “do” as opposed to what is “heard,” “read” or “observed.” This is often called experiential or action learning.


Based on this understanding we can break the training types down. For example:

  • Structured discussions are Verbal and some Visual
  • Computer Based Trainings are mostly Records
  • Instructor Led Trainings are a lot about Demonstration
  • On-the-job training is all about the Experience

Once we have our agreed upon training methods and understand what makes them a good training we can then determine what criteria of a change leads to the best outcome for training. Some example criteria include:

  • Is a change in knowledge or skills needed to execute the procedure?
  • Is the process or change complex? Are there multiple changes?
  • Criticality of Process and risk of performance error? What is the difficulty in detecting errors?
  • What is the identified audience (e.g., location, size, department, single site vs. multiple sites)?
  • Is the goal to change workers‘ conditioned behavior

This sort of questioning gets us to risk based thinking. We are determining where the biggest bang from our training is.

Building training is a different set of skills. I keep threatening a training peer with doing a podcast episode (probably more than one) on the subject (do I really want to do podcasts?).

The last thing I want to leave you is build training evaluations into this. Kilpatrick’s model is a favorite – Level 4 Results evaluations which tell us how effective our training was overtime actually makes a darn good effectiveness review. I strongly recommend building that into a change management process.

Every change is a project, every project is a change

Project Management, the structured approach for managing tasks, resources, and budget to achieve a defined deliverable, is an important part of the quality management toolbox, and an important aspect to build into your change management program.

There are a lot of project management methodologies, but they all boil down to having an understanding of the tradeoffs between time, cost, and scope of a change; and then motivating a team towards delivering the change.

project and change comparison

Evaluate is best seen as a gate at the end of the project’s design (or a phase of design). A well-designed project, with appropriate stakeholders and team members ideally, will flow nicely into an evaluate change control (or set of change controls). Having this as part of your gate to develop will ensure that the right subject-matter-experts have been involved, that all potential risks and impacts are understood, and will ensure the site is ready to implement.

Small projects and the change management lifecycle are usually one and the same.

For projects with a large impact, it is often important to create more than one change control, to ensure appropriate implementations. In these cases it is often useful to create a change strategy (or incorporate in a project deliverable, such as a gate document) which can include:

Scope Describe the project, indicating the current and future state.
Roles/ Responsibilities Indicate what functions/departments will serve what role in the change controls

Indicate the role and responsibilities of project management.

Methodology/ Strategy What activities are included and how they will be organized.

How many change controls will be created as part of this strategy.

How change controls will be organized and linked together (e.g. dependencies).

Provide a methodology for managing changes and ensuring all change control activities happen according to the provided timetable.

Things to Consider:

Are there other changes that affect the same room/area or equipment?

How are affected rooms/areas/equipment being taken out of and placed back into service as to not to interfere with the provided timetable?

Will these change controls affect daily operations/sampling?

How will changes be organized? For example, will changes be organized along install, validate and implement?

If multiple areas are to be affected, will there be changes in Material and Personnel Flow that will need to be modified to execute the multiple changes?

Effectiveness Review If the project will have one effectiveness review (e.g. a process validation, comparability protocol, stability study) indicate, provide the effectiveness review criteria and justify. Provide a timeline for completion of the effectiveness review.
Regulatory Strategy Regulatory strategy for filing the project (e.g. will the changes be filed independently or together, at what point, which changes will require regulatory assessment)
Planned Timetable Timelines for writing, approving, implementing and closing change controls.

Take the dependencies written in the Methodology/Strategy into consideration when developing the timetable

Closure Plan How will the strategy be closed? What are the criteria for a successful project closure?

For larger projects, the change evaluation will start in the project design phase but can continue through implementation as individual changes are put in place.

The advantage of writing this strategy allows the project to consolidate deliverables and ensure the right level of effort is put into the changes across the project.

Regulatory Impact of Changes

In a regulated industry, such as pharmaceuticals or medical devices, knowing your changes impact your regulatory partners is a critical aspect of change management. For example, the MHRA in their yearly summarizations of GMP inspection deficiencies consistently cites failure to perform adequate review of need of regulatory notification (for example, see 2016 trends). And to be frank, we in the industry are often looking for more guidance, which drives responses like ICHQ12 and the FDA’s March 2018 draft guidance CMC Changes to an Approved Application: Certain Biological Products and all the other similar guidances out there.

These all follow a similar risk-based approach, and this approach should be built into your change management system (and applicable change control process).

regulatory structure2

The major difference between Supportive Information and Do-and-Record is usually what goes in your product quality report (APR/PQR). Fro example, I often see qualification of facility fit into the Do-and-Record area. These changes may not be fillable, but you certainly want to review and account for.

Many companies manage this through their regulatory affairs organization, but that can be time consuming. It is better to take the time to identify the supportive and do-and-record categories out front, thus removing the need for an extra assessment. The PQR review process is a great tool for ensuring consistent execution.

This risk based approach should look at the dossiers, taking into account any special market considerations, as well as current best practices in the regulations. For those companies lucky enough to be more towards the QbD model, established conditions will greatly help here.

Then build a matrix to help guide your changes. An example could include items like these:

Facility, Equipment, Manufacturing Systems, Utilities & Automation Equipment/instrument maintenance
Decommissioning of equipment not classified as critical equipment
Computer programming that affects non-production equipment
Alarms (i.e., notification system for out of tolerances)
Cleaning and Sanitization of Manufacturing facilities and non-product Contact equipment
Upgrade of Application Software or operating system
Alarm setpoint changes
Creating user groups and modifying user group privileges
Tuning parameter, adjustment to the gain, reset and rate of a PID controller
Manufacturing Processes In-process labeling
Changes to Process Control and Operating Parameters (tightening/shifting) within current non-established conditions
Change in equipment sterilization times
The addition of in-process or final product samples
Changes to sample volume for in-process or finished product samples
Addition of new ancillary equipment (e.g. no product contact, does not control process steps) to the process

You can then further delineate between Supportive Information and Do-and-Record on a few other criteria, such as qualification/validation impact.

Like many areas of good system management, this is an area where a forethought and design can reap dividends in making your changes more nimble while preventing a compliance mishap. Tapping into the PQR makes all this part of your knowledge management system, and allows you to grow as your needs grow. This is definitely not a once-and-done process.



Change Management and Communication

All changes need to be communicated to internal and external stakeholders. The development of the communication plan should be part of the change management system.

One of the better models I’ve used is Prosci’s ADKAR.


This is a good model because it matches very nicely to the 4 major phases of change.

  • In Propose we focus on Awareness and Desire
  • In Evaluate we focus on Knowledge and Ability
  • in Implement we focus on Ability and Reinforcement
  • And in Close, we focus on sustained Reinforcement and perhaps Awareness of a new change.

Not every change is the same size, and not every change uses the same tactics of communication. Often these tactics are training.

A table, such as the one below, can help.

Item Description of What it is Audience Publication Date
List each of the proposed elements of your communication plan Be sure to include key stakeholder outreach along with all other tactics Who List the date you want the communication delivered

There are lots of good tools out there for communicating. This post was prompted by this post on elevator pitches, which are one of my favorite items in my toolkit. Every change, big or small, should have an elevator pitch ready to go. And make sure it evolves according to the change/process improvement lifecycle.