Technology Transfer Notes 14 – Transferring Operational Ranges (CPP, PAR, NOR)

I’m sometimes asked if a transferred process should use the same Critical Performance Parameters (CPP), Proven Acceptable Range (PAR) and Normal Operating Range (NOR) parameters and values and what parameter values should be used in the manufacturing documentation for such a newly transferred process. Two questions really, but my thoughts are as below.

Transfer the same Critical Process Parameter (CPP) & values?

The first reaction may well be “yes – of course” – it’s the same product and manufacturing method that is being transferred, but that’s not always the case. While it may well be the case if you are using the same equipment, and the process is being manufactured at the same scale. And some parameters such as temperature or pressure transfer can easily. However, even with the best of intentions there are often minor differences in some of the equipment used between sending and receiving sites (previous sites older equipment size / model is not available or been “updated”) and sometimes the opportunity to “optimise” the process during the transfer is irresistible.

While the fact that a particular CPP’s will remain a CPP unless the process has been redesigned some CPP’s will likely have changed value (e.g. mixing speed and mixing time of a liquid mixer) due to even slight differences in impeller type or positioning, in such cases the Proven Acceptable Range (PAR) values will have to be re-evaluated.

Even more so for more significant changes such as a change from say a vertical to a horizontal granulator, as previous studies cannot be used to establish the new PAR values for each affected CPP’s and need to be re-established experimentally. This can be done by performing a series of engineering runs but it is more usual to study only the affected unit operations in separate “support studies” such as separate granulation or mixer studies to define new PAR values. The material produced during these studies is often used to demonstrate comparability with material previously produced.

If process changes are significant enough, then full scale demonstration batches may have to be run and CPP’s re-evaluated. Such batches and studies are often call bridging studies (linking both previous manufacturing parameters with the new ones).

I’ve often seen the Normal Operating Range (NOR) values being transferred as well as part of the technology transfer process, and to my mind this is an absolute no–no. Why? Well in part it just demonstrates that the receiving site doesn’t understand what this value represents or how it is established.

The NOR is primarily the natural variation around the target value as experienced at the receiving site. This natural variation is unique to the receiving site equipment, environment, process control systems and people and it has to be measured at each specific manufacturing site. The NOR is not a limit, it’s a measure of that sites capability and acts an alert point for that site’s specific manufacturing process. During technology transfers it is often the case that the receiving site does not have sufficient specific process experience to assign this at the receiving site.

NOR values are used to:

  • Account for natural variation.
  • Ensure that any abnormal variations are detected before they become a process issue.
  • Demonstrate process control.

NOR values can be assessed at the receiving site by using:

  • Data from engineering runs.
  • Previous equipment history (historical data).

If the receiving site has no history to base a value on, the sending sites NOR value may give a guide (but general guide only as a starting point.

  • Manufacturers equipment capability specifications.
  • Instrument / sensor calibration accuracy.

And should take into account:

  • Some computer-controlled equipment can maintain tight limits.
  • If manual input is required, the difficulty, ease or precision capability of the operation.
  • The accuracy / resolution of equipment / readout of equipment or analytical instrument
  • Digital / rounding up-down errors.

Although NOR values cannot (or should not) be transferred, they are usually required as part of the receiving sites product licence application. This means that it is incumbent of the receiving site to monitor the process variations during pre-PPQ studies and runs (and indeed during PPQ runs) to determine the NOR values for their equipment on their site.

Once you have transferred a process, what process parameter value should you include in your manufacturing documents?

Each PAR value will have its own study derived or product specification target value. However, these target values are usually expressed as a range of values e.g. net weight +/- 10g in manufacturing documentation.

It is not advisable to use the CPP / PAR limits as the range value, this builds in too much process variability to start with while at the same time using any NOR values means that you will be working at the edge of the process equipment’s limits and is likely to cause unnecessary out of specification alerts or deviations. The manufacturing documentation values you use should be tight enough to ensure control, but wide enough so that natural variation doesn’t result in unnecessary deviations.

So any value between the PAR and the NOR value would be OK. The temptation is to use a documented value as close to NOR as possible – but that can be counterproductive. A + 5% over the NOR value or +10% against target value might be used as a starting point. Sometimes it may be best to go a little wider provided PAR isn’t approached / exceeded. You can always tighten this once process experience is gained and NOR value understood it’s much easier to justify the tightening of a range than seeking to widen it, (as my QA colleagues I’m sure will agree). Widening limits after process failures will only leave you open to accusations of widening it to avoid deviations.

About The Author:

Trefor Jones is a technology transfer specialist with Bluehatch Consultancy Ltd. After spending over 30 years in the pharmaceutical / biopharmaceutical industry in engineering design, biopharmaceutical processes, and scale-up of new manufacturing processes, he now specializes in technology transfer especially of biotechnology and sterile products.

He can be reached at trefor ”at” bluehatchconsultancy.com.

Memo 12 – clinical trials

Blog 12 – Technology Transfer of Clinical trial manufacturing.

Firstly, what is Technology Transfer – I suppose putting simply it, includes everything that’s needed to move a technical process from one location to another. See my Blog #1 for more detailed definitions.

While most discussions are around the transfer to commercial scale manufacturing, it should be remembered that process and assay information (tech) transfer also occurs at all points through a products life cycle from development to production end of life, including through the clinical trial phases.

Based on: “Unraveling the Complexities of Technology Transfer” – Thomas ChattawaySeptember 2020 in Bioprocess International

However transferring products still at the clinical phase stages have specific problems and challenges:

The main one being that the manufacturing process has not yet been defined and can still be modified / developed (even at phase 3 stage) and is subject to change, and analytical tests may not have been fully developed, validated, or verified. Indeed these aren’t strictly necessary for early clinical manufacturing, filter validation for instance being one of these – although it should be performed as early as possible.

Some of the challenges can be:

  • Product specification not yet defined.
  • Analytical methods not yet finalised – or even been fully defined.
  • Product may not yet have been characterised.
  • Manufacturing process not developed – indeed in its current form it may not even be GMP compliant.
  • Current manufacturing process may not be scalable.

Key documents and items of information traditionally relied on for technology transfer to commercial manufacturing scale may only be in draft form if at all.

Let’s take a look at some of the most crucial tech transfer points between these stages:

Preclinical to Phase 1

Challenges:

  • Scalability of the process; whether it can be replicated at scale
  • Needed materials, which may not comply with GMP requirements.
  • Equipment between sites is likely to different
  • R&D often based in another country with different cultures and time zone
  • “Tribal” knowledge may be prevalent and not always be captured on paper – a prime task of technology transfer at this stage is to try and capture all of this knowledge. The problem is that a massive amount of data is needed to encompass all the different procedures, equipment setups, protocols and reports, methods, output, validation, parameters, and equipment guidelines.
  • Remote workforce, which has become the new normal. Teams are now distributed across sites and even continents, making ad hoc meeting and document review often difficult.

At the preclinical phase, there is little or no process information. Product characterization, information, procedures, and early stability data may be present.

One of the key roles of the technology transfer at this stage is to ensure that the process being transferred is or at least capable of being GMP compliant (yes, I’ve heard R&D staff say “but GMP doesn’t apply to us” and in a sense they can be right) but failure to ensure that a product cannot be manufactured in a GMP compliant manner at this stage is planning for failure. Such an example could be the reliance of raw materials or excipients that were either not GMP grade or could not be sourced as GMP compliant materials and would waste time / money re-formulating the product.

Other examples could be:

  • Equipment that could not be scaled up (e.g., rotary dryers)
  • Processes that could not be performed easily or at all at manufacturing scales (e.g., fast heating or cooling rates required – O.K. at test tube scale, but unfeasible at 2,000L scale).

So, the main role of technology transfer at this stage is probably to ensure that as much data as possible is captured about the product and process (at this stage what is important or not is usually unknown) and to ensure that the process being transferred is at least potentially GMP compliant.

Perhaps a word of caution is appropriate at this time, you should be careful to protect your intellectual property, not only regarding the product, but also in respect of the analytical methods and process methods used as it would otherwise be possible for any entity performing further development work to be able to patent the methods themselves.

Early phase Clinical Phase transfers

This is where the development teams hard work starts, turning an R&D (possibly non-GMP compliant) into something that resembles a GMP / regulatory compliant process that can be scaled up through pilot plant to commercial scale, and produces a product that is safe for animal and human trials.

Technology transfer at these stages may require:

  • A Quality Target Product Profile (QTPP) to have been created.
  • Product characterisation data to be available.
  • Critical Quality Attributes to have been determined.
  • Preliminary Critical Process Parameters to have been developed (what they are even if numeric values are not yet available).
  • A draft process description, although at early clinical phase stages this is expected to change significantly before a commercial scale process is defined.
  • Details of development work and batch records of previous manufacturing especially at the pilot scale. – what went right, but also what went wrong), any process development reports.
  • Scale up and regulatory strategies may also be developed at this stage.
  • Analytical methods to be used – these should be developed in parallel with the process to ensure that appropriate tests were defined and appropriate sensitivities for the developing process were possible. This may require some preliminary values for critical process parameters to ensure analytical requirements and capabilities are matched. it is not expected that all methods and specifications be defined for a Phase I biologic. For a Phase I biologic, analytical methods should be in place; however, at this early stage, they do not need to be validated. 

Process validation at this stage of technology transfer can seem a long way off – something to be thought about later. However, it is worth emphasising that planning for eventual process validation is something that should be incorporated in the technology transfer at this stage of product development as decisions taken now can greatly affect the ability of the process to be validated without having to either repeat studies incorrectly performed or indeed not at all.

Late phase (phase 2 and 3) Clinical Phase transfers

At these stages the product should be characterised and the process should be being developed in a way that is GMP compliant, taking all the data that has been generated to date and then using it to replicate the early phase clinical process  under GMP conditions, using GMP compliant materials.

Quite often the process changes during these phases and it is vital that bridging studies are performed to demonstrate that the product is still comparable with the product from earlier clinical stages.

The process description should be in late draft stage, and process Critical Quality Attributes and Critical Process Parameters should have been defined (even if their values are still to be confirmed), the Design Space should be in draft state.

Risk assessments should be performed during these phases and remaining studies (i.e. confirmation of formulation) that may still be required to “fill the gaps” in the process knowledge such as scale-up or scale down studies should be planned and performed. Analytical methods if not compendial need to be defined and any validation required planned.

If technology transfer is performed during these stages the main aim should be to transfer what is known, and what is yet to be defined / determined.

By the end of these clinical phases all studies, process parameters, process descriptions and analytical methods should be complete and validated as necessary, as this will be the process that is used for the Process Validation.

Commercial manufacturing stage

At the commercial stage the process validation studies will have been completed and product licences granted. Although the clinical stages have been completed. However Technology Transfer has not – contrary to popular belief – been completed. Demonstrating that the transferred process is controlled and stable must surely be the aim of a successful transfer, and this requires careful post Process Validation monitoring and analysis as part of the process Continued Process Validation (CPV). Of course, I’m not suggesting that like CPV technology transfer never actually ends, just that a statistically significant number of initial commercial batches be studied to demonstrate consistency and control. How many is “significant” is probably another topic for another blog.

Some of the references used are:

  1. Chattaway, T. (2020, September 22). Tech Transfer: Unraveling the Complexities. BioProcess International. bioprocessintl.com
  2. Fallentine, B. (2019, February 1). Mind the Gap: Tech Transfer from Early Stage Cell Culture to Phase I Clinical Manufacture. Pharmaceutical Technology. pharmatechassociates.com
  3. Jones, T. (2018, January 16). 4 Steps for Successful Tech Transfer of Gene and Cell Therapy Products. Bluehatch Consultancy Ltd. bioprocessonline.com
  4. Makowiecki, J. (2020). Best Practices for A Successful Bioprocess Technology Transfer. Cytiva Life Sciences. lifescienceleader.com
  5. O’Sullivan, C., Rutten, P., & Schatz, C. (2020, July 23). Why tech transfer may be critical to beating COVID-19. McKinsey & Company. mckinsey.com
  6. Witcher, M. (2020, September 23). Can We Eradicate Tech Transfer and Other 20th Century Pharma Manufacturing Practices? BioProcess Online. bioprocessonline.com
  7. Agrawal, M., Eloot, K., Mancini, M., & Patel, A. (2020, October 20). Industry 4.0: Reimagining manufacturing operations after COVID-19. McKinsey & Company. mckinsey.com
  8. Best Practices for Technology Transfer. (2011, June 1). BioPharm International. biopharminternational.com
  9. National Institutes of Health: National Cancer Institute. (2020). Technology Transfer Considerations. PREVENT Cancer Preclinical Drug Development Program. prevention.cancer.gov
  10. Steinmetz, K. L. (2009, June 12). The basics of preclinical drug development for neurodegenerative disease indications – BMC Neurology. BioMed Central. bmcneurol.biomedcentral.com

About The Author:

Trefor Jones is a technology transfer specialist with Bluehatch Consultancy Ltd. After spending over 30 years in the pharmaceutical / biopharmaceutical industry in engineering design,  biopharmaceutical processes, and scale-up of new manufacturing processes, he now specializes in technology transfer especially of biotechnology and sterile products.

He can be reached at trefor ”at” bluehatchconsultancy.com.

Blog #11 – How many Process Performance Qualification batches are required?

The question of how many batches have to be run is a recuring question, not always easy to answer and there is a great temptation to just say three (3)!

Although industry has typically used three batches during the process performance qualification (PPQ) phase to demonstrate that a process is capable of consistently delivering quality product, this “rule of three” batches or runs is no longer appropriate and the regulations do not now prescribe the number of runs required for process validation activities.

The FDA just state that, “each manufacturer should judge whether it has gained sufficient understanding to provide a high degree of assurance in its manufacturing process”, The EMA guidelines state “a minimum of 3 production scale batches should be submitted unless otherwise justified”.

ICH Q7 (12.50) says “3 consecutive batches should be used as a guide, but . . . “

The past typical use of three batches has always seemed very much a “finger in the air” to me as how (statistically) confident can you be after only three batches – a statistician friend tells me that for 95% confidence and 90% reliability, 30 runs would be required, however that is neither practical nor cost effective.

So – how do you determine how many batches to run?

There are two main approaches:

a) Risk based.

This uses a comprehensive risk analysis to assess how much process variation risk remains after applying existing process knowledge and process design data.

This is performed by establishing or assessing the main sources of process risk, perhaps using such techniques as Failure Modes and Effects Analysis (FMEA).

Another method that can be used to identify and characterize the significant process factors and parameters is based upon the design of experiments (DOE). Again, this method can require a large number of pre-PPQ DOE experiments to demonstrate the significant and interactive factors and can require a relatively high number of PPQ batches to be run (two significant interactive factors would require 4 PPQ runs, while 3 interactive factors would require 8 PPQ runs etc.to cover the minimum and maximum values of each parameter in combination.

A risk method is not statistically based and may lead to a high number of PPQ batches required if more than 2 sources of variation are determined, and for that reason alone is probably not practicable for anything other than for simple processes.

b) Statistical / pre-knowledge based.

Where practical and meaningful, a statistical method of determining the number of batches is recommended, although there is no standard industry approach.

The statistical: based process relies on calculations targeting capability, tolerance intervals, or overall reliability of meeting CQA acceptance criteria.

The concept of this approach is that sufficient historical data from development, engineering or pre-PPQ runs is obtained to develop a deep enough understanding of the process so that you can have a high enough statistical confidence to be able to predict the behaviour of the PPQ batches. the PPQ runs themselves are then confirmatory runs of your predicted process performance. The number of PPQ runs can be as low as 2 runs if your % confidence level can be shown to be high enough.

The downside of this approach is that it requires a relatively high number of batches to have been manufactured and sufficiently well monitored to be able to build up this statistical “model” of the process prior to PPQ.

There is a third approach, – being a “structural” approach with the number of PPQ batches required being determined by reference to the process’s complexity, dosage form strengths, and number of equipment trains. This can include bracketing and matrix strategies and may involve separating groups of unit operations into separate PPQ protocols. However, bracketing and matrix strategies are difficult and time consuming to justify and not all regulatory bodies will accept such a method.

A statistical approach to determining the number of PPQ batches is often used in combination with risk-based or structural strategies.

So – to come back to the original question – how many PPQ batches are requires?

The number of batches should be based on the variability of the process, the complexity of the process / product, process knowledge gained during development, supportive data and the overall experience of the manufacturer.  As such there can never be a single answer to this question but in general the number of three (3) consecutive would be the general answer and is the one usually chosen by the industry. Even this should be justified but I rarely see this done. These should be full size commercial batches, however some process validation studies may be conducted on pilot scale batches if the process has not yet been scaled up – but again a justification of this approach is required.

However if you have extensive process development history and data and can write a well thought out justification then less than 3 batches may be acceptable.

If you have little or no prior knowledge of the equipment, process or product then it would be wise to plan on more than 3. Likewise, if you have a complex process or are looking to use a matrix style approach then the likelihood is that you will need significantly more than 3.

Tech Transfer #9 Engineering batches

Tech Transfer Blog #10 – Engineering runs – Just an expensive Insurance policy?

An Engineering Run can be also called many other names such as an engineering trial run, engineering lot or practice runs or demonstration runs but they are usually non-GMP runs used to demonstrate that the manufacturing equipment and processes work as required and that the end product can meet the required quality specifications.

Engineering batches do not have to use the actual API but may just simply be run with simply media, buffer, and other components, often called a “water batch.”

However, the term “engineering run” can also be used for any non-GMP trial, for example commissioning runs following the installation of new equipment or the installation of a new manufacturing line. It should be noted though that all validation runs must be run under full GMP conditions and are thus not engineering runs.

The scale of an engineering trial can vary according to the purpose and complexity of the trial; however, engineering runs are not mandatory, just a good idea in most situations.

From the Technology Transfer point of view, engineering runs can be used for:

  • Demonstrating that the manufacturing equipment itself works, such as being able to fill 2ml. vials at the speed required. A water run can be used in this respect although the use of product is recommended to demonstrate viscosity or foaming issues would not be a problem. If the actual product cannot be used due to scarcity, cost or toxicity concerns, then a substitute with close physical or chemical properties could be used.
  • Demonstrating that individual process steps or unit operations work as required and that the process step produces product to the right quality.
  •  Demonstrating that individual process steps work as part of an integrated process.
  • Optimizing process equipment.
  • Developing or optimising manufacturing parameters.
  • Optimise sampling regimes.
  • Finalising the process control strategy.
  • Identifying and resolving any potential issues before the formal cGMP documentation and activities. Challenges will inevitably be encountered before or during manufacturing and addressing these in a non-GMP situation is easier, an engineering batch run can help avoid many predictable and unpredictable issues.

Quite often a transferred process will be new to both operators and engineers, and an engineering run allows for familiarisation and training of operational staff. And don’t forget that quality staff will also need to become familiar with sampling methods and actual product to use for analytical process and verification activities.

Rarely are such process related Standard Operating Procedures (SOP) and manufacturing documentation such as batch records complete, error free and ready for use prior to GMP use, and engineering batches are often used to “red line” these documents prior to being used in anger.

Engineering batches can be of any scale, from “pilot” scale up to full scale depending on what aspect of the process is to be studied and the full process or only part of the process.

In fact, an engineering run can be run at any time before or after the product has been launched such as for process improvement purposes.

As stated before, engineering runs are not mandatory, but form part of the company’s risk assessment process, it’s a risk assessment thing with the balance depending on project costs and timelines versus confidence in the GMP production process and brand reputation.

It’s a Risk Thing

If something goes wrong with the GMP run, the consequences could be severe but there is no easy way to attribute a hard number to the amount of time or money that could be lost, it partially depends on the stage of the process the error occurs. Moreover, if you are using a CMO then remember that many CMO’s book GMP slots back-to-back, so if an organization misses its scheduled GMP run, another slot may not be immediately available.

If you have a lot of confidence in the process development work and you already have experience with this process in other plants and at other scales, and that the product is easy to work with then the risk may be in your favour. However, it is a mistake to assume that a particular drug product will run the same as similar drug products. One common issue is viscosity, where mixing or filling systems must be adjusted to accommodate the characteristics of the product.

If process unit operations can be run independently then it might make sense to just execute engineering runs on the higher-risk operations particularly if they have a well-known or a relatively common process for other process operations.

Disadvantages: – Of course, there are also disadvantages associated with engineering runs in that they arerun at GMP scale and, as such, demands the same resources as a GMP run meaning that they can be costly and time-consuming.

If viable material is used to execute the run, the resulting product usually is lost, since it was not produced according to GMP standards.

Engineering runs can use scarce single-use media, an issue all to frequent during the last pandemic manufacturing operations.

Engineering runs can be viewed as a very expensive insurance policy.

Blog 9 – Technology Transfer Success Criteria

What do I mean by the “Success Criteria”  – often call acceptance criteria – for technology transfer, and why do you need it?

The WHO Technical Report Series, No. 961, 2011 Annex 7 WHO guidelines on transfer of technology in pharmaceutical manufacturing considers Technology Transfer to be successful if there is documented evidence that the receiving Unit (RU) can routinely reproduce the transferred product, process or method against a predefined set of specifications as agreed with the Sending Unit (SU).

The key points here are “documented evidence” & “predefined set of specifications”.

WHY?

Well, as is frequently stated, the key to successful technology transfer is “communication”. You would never set off on a journey without knowing where you were heading, and it’s the same for technology transfer, success criteria define the journey and its end point, moreover predefining and agreeing these criteria provides the communication for everyone to understand the common goal, and their part in achieving it.

 Of course, defined success criteria also have other major benefits,

  • Defines the required deliverables – what and by who.
  • Defines responsibilities.
  • Defines the point at which responsibility for the manufacturing moves from Technical Transfer to Manufacturing. This quite often is a commercial and legal milestone triggering legal responsibilities and payments. And here, documented evidence of acceptance criteria being met is key.

This last point is quite important in that many times I have seen technology transfer projects just drag on with no one actually knowing who was responsible for the product manufacture, completion of technology transfer becomes a moving target.

Sometimes defining the success / acceptance criteria is relatively straightforward, such as successful completion of all required PPQ batches, but may not be so easy to define if the technology transfer is from say research and development to clinical trials where the technology transfer is part of a continuing process.

If you don’t define the success criteria, how can you tell if the technology transfer has been successful?

PREDEFINED

The success criteria should be defined, documented, and approved and agreed by both sending and receiving sites at the start of the technology transfer project. More importantly, it should be clear and unambiguous – there should be no doubt about whether the success criteria has been achieved or not. The document should contain:

  • Scope and objective 
  • Resources and budget 
  • Timeline and milestone dates 
  • Roles and responsibilities 
  • Key deliverables

For transfer to commercial operations the focus would be on the stages towards being ready for process validation, but other aspects of the technology transfer may also be considered, such as

  • Initial risk assessment
  • Knowledge Transfer
  • Analytical TT
  • Packing TT
  • Design Transfer
  • Cleaning Validation Plans for Process Validation.

Once the Technology Transfer is completed evidence that the transfer is successful (i.e., has achieved its acceptance criteria) can be documented in a summary technology transfer report which should summarise the scope of the transfer, the critical parameters as obtained in the SU and RU (preferably in a tabulated format) and the final conclusions of the transfer. Possible discrepancies should be listed and appropriate actions, where needed, taken to resolve them [Ref: WHO Technical Report Series, No. 961, 2011 Annex 7 WHO guidelines on transfer of technology in pharmaceutical manufacturing]

Memo 8 – tech transfer documentation

Documentation is a keystone of Technology transfer so in this memo I thought I would have a quick look at some of the baseline documents that would be needed from both the sending and receiving sides. I believe that the FDA once said that “if it isn’t documented then its only a rumour, and we don’t deal with rumours”.

I once made a list of documents / work packages that would probably be required for a vaccine technology transfer and listed some seventy five (75) work packages that would be needed.

Each project is different and has different requirements, but I have tried to list some of the key documents below.

At the onset of the project the rules / responsibilities and scope of the project should be defined. You really shouldn’t start on a journey unless you know where you are heading. Unless of course chaos and uncertainty are your food of life.

  • Quality and Technical agreements – quality and technical agreements are legal documents that defines both specific quality, technical parameters, and responsibilities. It is crucial to set clear expectations and responsibilities between partners to avoiding confusion and/or conflict later.
  • “Technology Transfer Charter” or at least a Project Scope and any required by / anticipated timeline in the form of a Technology Transfer Plan. Projects without a scope and anticipated timeline will be subject to constant amendment and change, doomed drift on forever like the Flying Dutchman.
  • -clarifies the technology transfer in sufficient detail for all parties to understand the scope of work, their role, the timing, and the resource needed.

Once the project has been initiated you will need to know what to make and how to make it – the details of the product and the process are documented in:

  • Research and Development Reports – historical data of pharmaceutical development of a new drug substance and drug products at stage from early development the final application of approval – Quality profiles of manufacturing batches (including stability data) –
  • Process Flow diagram / draft process description: Describes the manufacturing process in detail and will be used as a reference source for all parties.
  • Critical quality attributes (CQAs): typical properties or characteristics that should be within an appropriate limit or range to ensure the desired product quality.
  • Critical process parameters (CPPs): They are generally identified by assessing the extent to which their variation could impact the quality of the drug product.

CQA’s and CPP are often detailed in a “Control Strategy” document

  • Bill of material – List of all components and where in the process they are used.
  • Analytical methods to be used, the results of the analyses are used for validation & comparability assessments as well as for the release of products from the transferred process. These methods should include test methods for drug substances, intermediates, drug products, raw materials, and components.

The above are sometimes collected in the form of a “technology transfer file” which may include additional detail such as safety, environment / stability, packaging (cold chain requirements etc), cleaning processes, shipment characteristics.

  • Technical gap analysis: This is a formal documentation of the assessment of known and potential gaps between the donor and receiving sites’ capabilities. Quite often this can take the form of a Gap Risk Assessment.

After the details of the process and any gaps have been identified & understood

  • Process risk assessment (such as a process FMEA). Where are the risk in the receiving site process – how can these risks be evaluated, eliminated, or mitigated? In my experience this is poorly performed, and often treated as just a tick-box exercise or a justification as to why a high-risk item is really just a low risk. This item should be regularly updated as process knowledge increases but rarely is so.
  • Detailed / updated process description.
  • Detailed project plan.
  • Sampling plan for both routine and non-routine (e.g., process validation) samples.
  • Supporting studies, there can be many of these but depend on the type of product being manufactured:
  • Media fills (process simulations) for sterile products.
  • E& L assessments (especially important if single use components are used.
  • Filter studies
  • Container closure integrity studies
  • Dissolution studies
  • Validation activities: These are usually detailed in the site Validation Plan (VMP) and can give rise to various sub-plans:
  • Cleaning validation plan
  • Process validation plan

PPQ preparation & execution

  • SOP’s – if not already covered by existing SOP’s, training plans and records for these should also be contemporary.
  • Rationale for the number of PPQ batches to be manufactured. There is no longer a requirement to perform 3 PPQ batches – however whatever number is chosen; it must be substantiated by a science-based rationale.
  • Protocols – for each activity performed, especially for those validation activities described in the Validation Master Plan. All validation protocols must include pre-determined acceptance criteria.

Post PPQ

  • PPQ report – listing results (and any deviations) from all PPQ batches. If any PPQ batches have been invalidated, then this and the reason why should also be disclosed.
  • Technology Transfer Report- This can be a full detailed description of all technology transfer activities and results but is often simply an update of the “Technology Integrated Technology Transfer Strategy (ITTS) / technology transfer protocol Transfer Charter” demonstrating that all the agreed activities have been performed and that all acceptance criteria have been met. This can in effect be the end of project or handover document.
  • Data recording list – online and offline data to be monitored and recorded during the process, and how this will be recorded and assessed as part of the Continued Process Verification.
  • Deviation inventory – description in details of the deviations, status, and reporting of the impact on the product quality.

Technology Transfer Blog #7 – Risk Assessments (use & misuse)

The recently published (August 2022) EU GMP volume 4 Annex 1 introduces several changes. In particular there is an increased requirement for the use of risk assessment and risk management methodologies.

These are probably one of the most mis-used and mis-understood pharmaceutical activities.

Firstly, what is “risk assessment”?

This has been defined by the FDA as A systematic process of organizing information to support a risk decision to be made within a risk management process. It consists of the identification of hazards and the analysis and evaluation of risks associated with exposure to those hazards.

ICH Q9 (Quality Risk Management) – defines this as a systematic process of organizing information to support a risk decision to be made within a risk management process. It consists of the identification of hazards and the analysis and evaluation of risks associated with exposure to those hazards and focuses the behaviours of industry and regulatory authorities on the two primary principles of Quality Risk Management, which are:

  • The evaluation of the risk to quality should be based on scientific knowledge and ultimately link to the protection of the patient; and
  • The level of effort, formality and documentation of the Quality Risk Management process should be commensurate with the level of risk.

Ideally, risk assessments are used to identify areas of process risk or weakness, allowing the company to identify, prioritise and  focus their resources on the most important risks and to eliminate them or implement mitigation activities.

Current Issues

However, all too often these are not properly performed, seen as a “tick box” activity or even used to create / validate a reason or excuse as to why some activities don’t need to be done.  I was once asked “if we upgrade our filling machine, will we have to revalidate it or can we just risk assess it”.

Risk assessments are typically used at the time of process sign-off or approval from the customer, then “Archived” and thus fail to be properly updated and communicated to the team. 

The resulting “risk number” or “risk priority number” is usually the result of arbitrary assignment of severity and occurrence, risks sometimes manipulated to try and demonstrated a process or system is “low risk” or worse still, intentionally ranking failure modes lower than true risk in order to avoid required improvement activities.

I’ve also seen them being used to try and retrospectively justify and action or decision already taken.

In the main, risk assessments are only every as good as the team behind them and this is where the majority of risk assessments fall down:

  • The amount of time needed to complete a comprehensive risk assessment is almost always underestimated.
  • The team used to create the risk assessment are limited. Issues beyond the team members knowledge aren’t likely to be assessed, detected or resolved, thus it stands to reason that a team composed of widely diverse experience knowledge and disciplines perform better. In the past I have seen risk assessments written by a single person, not ideal as this negates fact the team concept is one of the values of risk assessments such as FMEA.  

The wrong risk assessment tools for the task are often used. While there are many risk assessment methodologies and tools available, unless they are used by those with some expertise in the field of risk assessment the tools recommended by the ICH should be used:

  • Failure Mode Effects (Criticality) Analysis (FMEA & FMECA)
  • Fault Tree Analysis (FTA)
  • Hazard Analysis and Critical Control Points (HACCP)
  • Hazard Operability Analysis (HAZOP)
  • Preliminary Hazard Analysis (PHA)

One weakness of theses is they concentrate on the consequence of the risk and do not relate to the source of the risk event, or the circumstances linking the two.

However, the biggest issue with many risk assessments is that they only assess the “risk” of an end results happening, without understanding risks are not just events. Risks are fundamentally the relationships between events. To manage risks, you must focus on understanding the system mechanisms that control the cause-and-effect relationships.

Of course, there are many others such as “bow Tie” assessments used mainly in engineering-based industries. Other tools such as Ishikawa diagrams can also be used but while these are useful in identifying possible causes for an effect or problem, they are not usually suitable for use as a risk assessment tool.

The Upside.

Although I have looked at the issues surrounding the mis-use of risk assessments, I would not like to give the impression I was “anti-risk” assessment, to the contrary I believe risk assessments if performed correctly provide a structured and an easy to understand method identifying potential risks and communicating these risks to all – from senior management to those on the shop floor.

When used correctly risk assessments are not only a regulatory requirement, they provide you with the right information to allow you to make the right decisions and to prioritise the right actions. They provide a structured and thus consistent way of identifying probable design or process failures that impacts product quality, process reliability and safety or environmental hazards.

Risk assessments also:

  • Provide a method for prioritising the importance of potential risks, and indeed allows you to choose which risks are worth accepting and which are not.
  • Provides a method for capturing “lessons learned” about failures or potential failures from similar situations and processes as a means of minimizing risk.
  • Helps to define actions and responsibilities in cross functional teams.
  • When combined with Control Plans or Control Strategies they can help optimise process control and reliability and most importantly product quality.
  • Substantially reduce costs by identifying design and process improvements early in the development process when relatively easy and inexpensive changes can be made.
  • Provide new ideas for improvements in similar designs or processes.
  • If used early enough in process design or during technology transfer, they can save great amounts of time and money by identifying issues before they become complex or expensive to rectify.

Memo #6 – PAR and NOR misconceptions

PAR:      – Proven Acceptable Range

DSp:       – Design Space.

NOR:     – Normal Operating Range

 In reviewing technology transfer documents, I often see process specifications and Process Parameters (PAR and NOR) values quoted which demonstrate a certain amount of misunderstanding as to what these ranges actually represent.

1) In particular I often see Sending Units (SU) including their process NOR values and see the Receiving Units (RU) using these NOR values in their own process without consideration as to whether they are valid or not.

So, just to be clear, the PAR values are process defined values determined during product development that demote the minimum and maximum values of a particular parameter that have been shown (i.e. proven) to allow the process to remain in control and produce a product within the required specifications and these are perfectly alright to transfer across.

The NOR however is a measure of the variability of the Sending Units own equipment and process as performed at the Sending Units site (defined as describing “a region around the target operating conditions that contain common operational variability – variability that can’t always be controlled) [ref.1]. – and are more than likely to be different from the variability seen at the Receiving Unit.  The Receiving Unit cannot simply use the Sending Units NOR values.

e.g. SU vs RU variability. NOR depends on individual sites systems & equipment.

The NOR value cannot be simply risk assessed – granted those parameters which can be designated as CPP, non-CPP, KPP etc can be defined by risk assessment, but the actual values cannot be, the PAR values come from process development, and the NOR values come from RU measurement or experience.

2)  I often see identical NOR & PAR values quoted, well the two are not equivalent, and should never be so otherwise it just demonstrates that your process is operating on the known acceptable limits of the process and can thus be regarded as being unstable.

Diagram from Dr Anthony Melvin Crasto (DRUG REGULATORY AFFAIRS)

3) As in the diagram above, exceeding the NOR is NOT a deviation or discrepancy unless the PAR is also exceeded, it is merely an observation..

4) process ok if each PAR is within spec.

Another common misconception is that if the process operates on the limits of more than one PAR value but still remain within their individual PAR values then the process can be said to be fully in-control and the product quality will remain acceptable – this is NOT always the case. The limits of each of the PAR values do not take into account any interactions between individual PAR’s. It is probably true though that as long as all the other parameters remain within their NOR values then product quality will probably be maintained. To quote the ICH [2] “a PAR allows deliberate change in one parameter without changing the others outside their NOR/ target values”

The EMEA [1] states that “where interaction effects between different parameters exist and the acceptable range for one process parameter depends on the setting of another parameter, the parameters should be included in a Design Space.

Design Space

Which brings us to the Design Space (DSp). Well, helpfully the International Conference on Harmonisation (ICH) Q8 (R2) defines Design Space as: The multidimensional combination and interaction of input variables (e.g. materials attributes) and process parameters that have been demonstrated to provide assurance of quality. Note the word “demonstrated” is used – not “determined by risk assessment” which means data, usually from product development work, should be used.

This means that the interaction between different parameters has been studied and their interaction determined so that how changes in one parameter can affect the PAR values of another parameter. The PAR of a single parameter alone is not a design space.

The Design Space can sometimes be a difficult concept to grasp at first, but I recently came across a presentation which describes it well and much better than I can do in a short blog, but perhaps this is a subject I can return to later.

http://www.slideshare.net/shettyuc/qbd-for-beginners-design-space

However, there are no regulatory requirements to have to define a Design Space.

References

  1. Improving the understanding of NORs, PARs, DSp and normal variability of process parameters EMA/604040/2016EMA/CHMP/CVMP/QWP/354895/2017 EMA/CHMP/CVMP/QWP/354895/2017 https://www.ema.europa.eu/en/documents/scientific-guideline/questions-answers-improving-understanding-normal-operating-range-nor-proven-acceptable-range-par_en.pdf
  2. ICH Q8R2

Memo 5 – Tech Transfer flow last part – execution and beyond.

Blog #5 – November 2022

Welcome to the fifth of my memo’s on Technology Transfer.

This month I am looking at the last section of a typical technology transfer project workflow. Depending on the exact circumstances these steps can be different or be performed in a different order. Usually, these steps are not performed in isolation and often in parallel.

The “GMP batch execution” and “Post Validation” phases of the transfer process which follows on from last month’s blog on project initiation are shown below. Next month I will start to consider specific aspects of Technology Transfer.

GMP run / Pre-PPQ run

This can refer to both non-GMP engineering batches and to GMP-compliant product runs.

Often a company will perform a “test” pre-PPQ run under full GMP conditions prior to the PPQ runs. This can be looked upon as a dress rehearsal. The batch (or batches) will be treated as full commercial runs and tested in exactly the same way as the PPQ batches will be run. Such runs can provide product for stability samples with the aim of shortening the time between PPQ batches and the first stability results, or for initial comparability trials.

Provided that there are no (or acceptable & QA approved) deviations, this pre-PPQ batch can be commercialised, but only once all PPQ batches have been satisfactorily completed and a product licence obtained.

Such a batch can be used for the provision of stability batches.

Details for a pre-PPQ run will probably need to be included within any product licence submission.

PPQ protocol

This isa written protocol that, according to the FDA [Process Validation – General Principles and Practices – Jan 2011] “specifies the manufacturing conditions, controls, testing, and expected outcomes is essential for this stage of process validation”.

Recommendations for its content include as a minimum:

  • Manufacturing conditions including operating parameters, limits & component / raw material inputs.
  • Data collection and evaluation
  • Tests and acceptance criteria
  • Sample plan
  • Criteria and process performance indicators that allow for a science- and risk-based decision about the ability of the process to consistently produce quality products.
    • Status of the validation of analytical methods used in measuring the process, in-process materials, and the product.
    • Deviation handling.

As this is a GMP document, it will have to be approved prior to use by the QA department.

PPQ execution

These are the GMP runs used to demonstrate that a drug is produced that is fit for its intended use. In terms of the validation lifecycle concept, this would be “Stage 2 – Process Qualification” as defined in the FDA Process Validation: General Principles and Practices document https://www.fda.gov/files/drugs/published/Process-Validation–General-Principles-and-Practices.pdf These batches are manufactured and the testing evaluated to determine if the process is capable of reproducible commercial manufacturing.

How many PPQ batches should be run is a common question. Industry has typically used three batches during the process performance qualification (PPQ) phase to demonstrate that a process is capable of consistently delivering quality product. The “rule of three” batches is no longer appropriate for process validation activities, the number of batches to manufacture now has to be “risk assessed” based on current knowledge and past history of the product. Even with my somewhat limited knowledge of statistics it is clear that a run of three batches cannot be statistically significant – although there are some statistically based methods available, and this is a topic I am going to cover in later blogs.

PPQ report

This report should document the performance of the PPQ runs and demonstrate that the acceptance criteria have either been met, or document the deviations concerned and the conclusions of any deviation investigations and any corrective actions to be taken.

A summary of all data collected should be included and this should be assessed and analysed as described in the PPQ protocol.

Very specifically, it must state a clear conclusion as to whether the data indicates the process met the conditions established in the protocol and whether the process is considered to be in a state of control, and if not, what actions will be required to be able to do so.

Deviations / CAPA

A deviation can be defined as any unwanted event that differs from the approved processes, procedures, instructions, specifications, or established standards.

Deviations can occur at any point in the manufacturing or associated operations of a drug product.

For a deviation to have occurred implies that either the process or its implementation has not “gone to plan”. All deviations need to be promptly investigated, a root cause found and corrective actions taken to prevent such deviations occurring again (referred to as Corrective Actions Preventive Actions – CAPA). Usually, these investigations should be conducted in a formal manner in line with ICH Q9. The level of effort, formality, and documentation of the investigation should be commensurate with the level of risk.

If the deviations have occurred during the performance of a PPQ batch, this might lead to the need to repeat the PPQ stage of the technology transfer.

Data Acquisition

Performance and analytical data – from both the PPQ batches and the subsequent commercial batches should be collected, preferable in a single location that can be accessed by all, including manufacturing, regulatory, QA, engineering etc. This data will be necessary for licence applications, manufacturing reviews and subsequent statistical analysis.

Once sufficient data has been collected to demonstrate statistically significant control of the process (say 30 batches), the number and frequency of the data points can be reduced.

The data points collected should be double-checked / confirmed by a second checker if possible.

Memo 4 – Tech transfer Flow chart Pt2 – Planning & Readiness

Welcome to the fourth of my memo’s on Technology Transfer – Planning & Readiness.

This month I am continuing my look at the workflow of a typical technology transfer project. As I said last month, depending on the exact circumstances these steps can be different or be performed in a different order. Usually, these steps are not performed in isolation and often in parallel.

This month I am looking at the “planning” and “readiness” phase of the transfer process which follows on from last month’s blog on project initiation.

At this stage in the technology transfer the process flow usually divides into two streams, the analytical method technology transfer and the process technology transfer. This month I will concentrate on the process technology transfer but will delve into the analytical methos transfer in a later post.

Detailed Project plan

A transfer plan is created by the Project Manager with the help of Subject Matter Experts (SMEs). The plan should cover all proposed activities, deliverables and their respective timelines. Although the first thing most people think of in this respect is the familiar Gantt chart, but this only forms part of the project plan.

It should also include the different functional strategies, roles and responsibilities as well as the resources required for each step so that resource planning is also addressed.

If the projects objectives and scope have not been finalised previously, then the project plan should also include these, beware of “scope creep” where the scope gradually expands, with no corresponding cost or resource increase.

The Plan is approved and executed by all the functional teams, and a kick-off meeting is held to ensure the team is aligned with the scope, strategy, and overall timeline.

Integrated Technology Transfer Strategy (ITTS)

The purpose of the technology transfer strategy is to clarify the technology transfer in sufficient detail for all the involved functions at the sending unit and the receiving unit to understand the timing, their role and the resource needed. You should consider including such items as Knowledge Transfer, Analytical Technology transfer, Packing Technology transfer, Design Transfer, Cleaning Validation, and draft plans for Process Validation. The ITTS is based on current product knowledge, identified key risks to the project and patient and mitigations to these risks.

The ITTS should be agreed by both the sending unit and the receiving unit.

The ITTS also provides documented evidence of the technology transfer process, for use in support of any regulatory inspections prior to product approval.

Define receiving unit (RU) process

A draft receiving unit either in text or flow chart form will usually have been created during the process initiation phase of the project and this should now be finalised, bearing in mind that the process description is a “dynamic” document, and should be upgraded during project execution.

It is usual to create and agree a sample plan at this point as well which can be included in the process description or created as a separate document.

Process Failure Mode Effect Analysis (pFMEA)

Having defines the RU process, the next step should really be a risk assessment of the process. FMEA is a widely used tool for identifying and evaluating the potential failures of a process. It evaluates each process step and assigns a risk score. This helps to establish the impact of any potential failure and to identify and prioritize the action items with the aim of mitigating any risks.

A crucial element is that the FMEA should be created using as many discipline functions as possible and not be completed by one person.

It is a living document that should be initiated prior to process of production and maintained through the lifecycle of the product.

Bill of Material (BOM)

This is not just a list of the materials that will be used in the process, (raw materials, ingredients, sub-assemblies etc.) but also their cost, vendors etc. This is used to help cost the process, compile parts lists for Extractables and Leachables data, it can also help in identifying critical of long lead time items.

Comparability protocol

This a written plan for demonstrating that a product manufactured as part of the technology transfer will be substantially the same as the product produced by the sending unit in terms of strength, quality, purity, and potency.

It is important to realise that it is highly unlikely that the transferred product will be EXACTLY the same or meet EXACTLY the original products variability (and the regulators do not expect that) but there should be a reasonable correlation between the various parameters and test results between the two sites.

Validation Master Plan (VMP)

A good summary of the requirements of the VMP can be found in the PIC/s 006-3 document. The VMP should present an overview of the entire validation operation, its organisational structure, its content and planning. The core of the VMP being the list / inventory of the items to be validated and the planning schedule.

The VMP should be a summary document and should be brief, concise and clear. It should refer to existing documents such as Policy Documents, SOP’s and Validation Protocols/Reports. The VMP should be agreed by management.

Quite often the Validation Master plan will refer to more detailed (Sub) Master Plans for Process Validation, Cleaning Validation, Analytical Method validation etc.

Define SUS and cleaning validation plan

At this stage a detailed cleaning plan is not necessary, but which parts of the process will use stainless steel / reusable equipment and will thus need cleaning validation and which parts will use “single-use-system” and thus not require cleaning validation should be defined.

Although defined as “single-use” there is no regulatory requirement preventing their re-use, and I know of occasions (such as during great component shortage during pandemic vaccine manufacture) where this was contemplated.

Material specifications / mass balance

Whilst most if not all materials used in the manufacturing process will be known by now (and listed in the Bill of Material- see earlier) it is important that the exact specifications of the materials used are defined and agreed. It is also important to ensure that a Mass Balance is performed to account for all material used in the process, and as a check on the amount of material (both waste and product) produced. This can be simple (as per a dilution stage) or more complicated (as in a biotechnology bioreactor). This is probably more important for reaction-based processes as this can help to confirm process understanding.

Demonstration / pilot batches

These are also sometimes called engineering runs.

These are manufacturing runs performed (often under non-GMP conditions) to confirm the feasibility of the process, capability of the equipment used, effectiveness of process parameters and controls. These runs can also be used to confirm the sampling and analytical methods used as well as being an operator training opportunity and confirmation of procedures and SOPs being used.

Product from these batches may also be used to demonstrate that the product manufactured at the Receiving Unit is comparable with that manufactured from the Sending Unit – in which case the runs may be termed “comparability runs”.

Process VMP / Cleaning VMP

Sometimes just called Process Validation Plans & Cleaning Validation Plans or validation sub-plans.

These are basically sub-sets of the Validation Master Plan referred to above, providing a more detailed overview of a specific validation process. Process validation, cleaning validation, analytic method validation, transport validation etc. can all have their own specific validation master plans relevant to that validation process. The content of the Process validation Plan etc. can be similar to the top-level Validation Master Plan but dealt only with the details and strategy of its own validation process.

Finalise Control Strategy

Following the execution of engineering / demonstration batches, the Critical Process Parameters (CPP) and their values will have been confirmed and these should be detailed in the products Control Strategy document and approved by both the sending unit and receiving unit.

Create / Train protocols & SOPs

Normally I would have expected SOP’s to have been written to cover all the tasks that are required for the transferred process prior to the Demonstration / Pilot / Engineering batch(es) and to have been used to both trial the draft SOP’s and train staff at that time. If not, SOP’s must now be finalised and approved, and staff trained on them.

Readiness review

Prior to starting the PPQ batches, a readiness review should be performed in order to demonstrate that all functions have completed their tasks, all documents and protocols are available and approved, all supporting validation & supporting studies have been completed and approved and all preventative maintenance plans are in place. This includes all third party (e.g. outsourced analytical laboratories) as well.

At this point no new conditions or changes should be made without a “re-review”.

It is often helpful to create a checklist for the readiness review.

There is no regulatory requirement for such a review, however it is recommended in the PDA publication “Technical Notes #65 (2022), Technology Transfer”.