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.

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]

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.

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.

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.

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

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.

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

Welcome to the third of my memo’s on Technology Transfer. This month I would like to start looking at the workflow of a typical technology transfer project, which assumes that the product will be outsourced to a CMO. 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.

In this memo I will cover the “initiation” phase of the transfer process which covers the initial setting up of the project, information gathering and gap analysis, and will follow up with the “planning” phase in my next memo.

Select RU / CMO

No two CMOs are the same – they all have different strengths and weaknesses, and no two sponsors will look for the same requirements.

While hiring a CMO might not strictly be a function of technology transfer, it will be a critical decision regarding the success or failure of the technology transfer process.

The starting point should always be to define your own requirements, and to decide which CMO capabilities will be the most important for you such as cost, speed or history of regulatory compliance. You can score your potential CMO’s against your requirement to help you create your shortlist and decide your best fit.

There are many checklists / topics available on the internet (and I’ll expand in future memos) but I would like to add a few “practical” items to the list. Communication is key they say – so finding a CMO with key staff that speak your language fluently – and that includes technical “speak” is crucial and selecting a CMO in your time zone can be classed as important – unless you don’t mind only being able to talk to them in the early hours of the morning!

A very important point to consider, especially if your chosen CMO will be performing analytical or process development for you – you MUST consider your intellectual property, who owns it and what is the CMO’s country’s approach to protecting IP assets.

And lastly – you want to select a CMO you feel comfortable with — not only one that can handle the work. And in this respect the cultural fit — or the ability to work together — may be the most important criterion of all.

Technology Transfer Charter

It is crucial to set clear expectations and responsibilities between partners in order to avoiding confusion and/or conflict later. The initial charter agreed upon by both parties must include the scope of the project, transfer timelines, as well as the team structure, specifying clearly defined roles and responsibilities. The charter should also establish clear paths of communication and a governance structure for addressing issues. Most importantly, success criteria must be clearly documented in the project charter. 

Form / Define Steering Team

There is usually a “Governance” structure sitting above the project team who role is to:

• Oversee transfer activities
• Ensure information is effectively shared
• Identify the Project Managers
• Assign a support team and senior management steering committee
• Establish a clear RACI matrix

Tech Transfer and Regulatory Strategies

• Quality and Technical agreements

Quality and technical agreements are legal documents that defines both specific quality and technical parameters for a project and which party is responsible for the execution of those parameters. The level of detail may vary depending on the developmental stage of the project.

• Documents required

The donor (sponsor) / Sending Unit (SU) and receiving unit (RU) must gather and prepare several documents to ensure a successful technology transfer, such as:

• Technology transfer plan: This describes all the activities to be transferred, responsibilities, and the expected outcome.
• Detailed analytical methods: They are crucial to technology transfer success as the results of the analyses are used for validation & comparability assessments as well as for the release of products from the transferred process.
• Manufacturing process description: Describes the manufacturing process in detail and will be used as a reference source for all parties.
• Critical process parameters (CPPs): They are generally identified by assessing the extent to which their variation could impact the quality of the drug product.
• Critical quality attributes (CQAs): A CQA is a physical, chemical, biological, or microbiological property or characteristic that should be within an appropriate limit, range, or distribution to ensure the desired product quality.
• Technical gap analysis: This is a formal documentation of the assessment of known and potential gaps between the donor and receiving sites’ capabilities and of their readiness for the transfer. The document should include a risk assessment.
• Adequate change control management system: Any changes made to the process or equipment should be documented, assessed, and justified with regards to their potential impact on the CQAs and the Quality Target Product Profile (QTPP).

Tech Transfer Scope and Critical Success Factors

Critical success is the demonstration with data conformance of the success factors as outlined in the technology transfer agreements and plan and typically cover process parameters and control mechanisms, material supplies, analytical methods, health, safety and environmental concerns and compliance with regulatory requirements.

Technology transfer can be considered successful if there is documented evidence that the RU can routinely reproduce the transferred product, process, or method against a predefined set of specifications as agreed with the SU [WHO Technical Report Series, No. 961, 2011 Annex 7, WHO guidelines on transfer of technology in pharmaceutical manufacturing].

Appointment of Project Manager

There is often a separate project manager at each of the RU and SU sites. The Project managers have a key role in the technology transfer process, he is often the main point of reference and is responsible for effective and efficient management of the project team and technical support and for co-ordinating, leading, tracking all the project activities to ensure successful technology Transfer.

Form Project Team

Technology transfers are usually performed by dedicated cross-departmental / cross-functional and integrated teams including from both sending and from receiving sites.

Ideally, all functions from both sites are involved to a certain extent with respective partners in the other organization. In this way, subject matter experts can directly communicate with their peers.

As always with such potentially diverse teams the roles and responsibilities should be clearly defined. This is sometimes set out in the form of a RACI matrix or chart.

Information Collection

The client should provide as detailed and complete knowledge transfer package as possible with product information such as:

• raw materials
• analytical methods
• validation reports
• manufacturing procedures
• process parameters
• equipment requirements
• regulatory requirements, etc.

Contract manufacturers refer to these documents as a technology transfer package. The information supplied is assessed by the CMO to help them determine the requirements for any additional equipment and supporting studies as well as to help develop the project plan.

Process Flow Diagram / draft Process Description

Pharmaceutical process flow charts are diagrams of pharmaceutical processes, usually in the form of a series of individual blocks each block linked together to describe a specific process such as a manufacturing process. Each block can depict a specific operation or item of equipment and may include additional information such as flowrates or other operating conditions.

Alternatively, the process can be described in mainly text format.

Gap Analysis and Risk Assessment (GARA)

A gap analysis is usually performed to compare the manufacturing process at the SU and the RU to determine differences in items such as equipment, facility, and methodology.

Once any gaps or differences have been identified these are risk assessed against the impact on product quality using traditional risk assessment tools such as FMEA and mitigation actions determined against medium / high risk items. The gap analysis and risk assessment should be jointly performed by the RU and SU. The outcome of the analysis and assessment are often combined into a single document.

Blog 2 – September 2022

Technology Transfer – Regulations & Guidelines

There are few if any “rules and regulations” issued by regulatory agencies such as the FDA or EMA. There are probably several reasons for this, but high on the list must be:

• Technology Transfer is so varied that no set of rules or regulations could hope to cover all the combinations of processes, analytics and facilities.
• In the main Regulatory agencies tend to state what activities – such as equipment cleaning – need to be regulated and what standards these activities need to achieve, but they want to don’t regulate HOW these standards should be achieved.
• In order to achieve regulatory harmonisation, the agencies are instead increasingly adopting the regulatory guidelines introduced by the ICH (International Council for Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use).

EMA

ICH guideline Q12 on technical and regulatory considerations for pharmaceutical product lifecycle  management – Annexes

https://www.ema.europa.eu/en/documents/scientific-guideline/draft-ich-guideline-q12-technical-regulatory-considerations-pharmaceutical-product-lifecycle_en-0.pdf

Released for consultation. Discusses changes (with examples) to parameter classification (e.g. CPP, KPP) with enhanced process knowledge. I will cover this further when I cover CQA, CPP parameters.

ICH guideline Q10 on pharmaceutical quality system

This document describes a model and components of an effective quality management system for the pharmaceutical industry. It includes technology transfer activities as are part of knowledge management. It confirms that tech transfer is part of process performance, product quality monitoring system and change control system throughout the product lifecycle.

This describes tech transfer in terms of product and quality management, but this could be misleading as it places tech transfer between development and commercial and as we know transfer of commercial scale activities involves a great amount of tech transfer activity.  It is concerned with quality and knowledge transfer not the practice of tech transfer.

https://www.ema.europa.eu/documents/scientific-guideline/international-conference-harmonisation-technical-requirements-registration-pharmaceuticals-human_en.pdf

World Health Organization (WHO) Technical Report Series, No. 961, 2011 Annex 7 WHO guidelines on transfer of technology in pharmaceutical manufacturing

States that transfer of technology requires a documented, planned approach using trained and knowledgeable personnel working within a quality system, with documentation of data covering all aspects of development, production, and quality control.

It provides “guiding principles on transfer of technology [which] are intended to serve as a framework which can be applied in a flexible manner rather than as strict rigid guidance and concentrates on the organisational and documentation “recommendations” which would be required.

From my point of view – a good starting point and checklist but doesn’t really help with timeline of process flow.

This guideline is current being updated and is available as a draft document on the internet:

https://cdn.who.int/media/docs/default-source/essential-medicines/norms-and-standards/qas20-869-transfer-of-technology.pdf?sfvrsn=2a4723bc_5

 ISPE Technology Transfer Guide (third edition published December 2018)

The ISPE Technology Transfer Guide describes itself as being designed to provide a standardised process and recommends a minimum base of documentation in support of the transfer request, and to describe the appropriate information that needs to be compiled to support the transfer of the information and provide regulatory filing documents. It this it does what it says – concentrating on the documentation required but perhaps not showing how this interacts with the workflow of tech transfer.

It does however devote a significant amount of space to analytical technology transfer which is missing from most other guidance documents. In addition to this it covers API’s and a variety of different dosage forms but admits it doesn’t cover biologics which these days could be seen as a major omission.

PDA Technical Report 65 Technology Transfer (PDA, 2014)

Provides an overview of the technology transfer process. It “walks through” technology transfer process and while not providing a “roadmap” it does step through the main steps and describes the activities and responsibilities of each of the different functions clearly showing how each function interacts with each other as the technology process progresses. Indeed its stated purpose is to provide a “reference Guide to the Technology Transfer Activities and Deliverables” which it does well.

https://www.pda.org/bookstore/product-detail/6680-tr-65-revised-technology-transfer

EMA

Guidance for individual laboratories for transfer of quality control methods validated in collaborative trials with a view to implementing 3Rs (Replacement, Reduction and Refinement).

https://www.ema.europa.eu/en/documents/scientific-guideline/guidance-individual-laboratories-transfer-quality-control-methods-validated-collaborative-trials_en.pdf

You may also consider:

1. Eudralex Volume 4 Chapter 7 Outsourced Activities (EudraLex Volume 4 Chapter 7, 2009)

2. Food and Drug Administration. 2011. “Guidance for Industry Process Validation: General Principles and Practices.”

3. EMA/CHMP/CVMP/QWP/BWP/70278/2012. 2014. “Guideline on Process Validation for Finished Products—Information and Data to Be Provided in Regulatory Submissions.”

4. ICH Q8R2

5. ICH Q9

6. ISPE PQLI guidelines