Product Lifecycle Management in

Pharmaceutical and Biotechnology

 Published on October 13, 2016

Don Rackham
FollowFollow
Director QA at Asterias Biosciences
2 articles
 11
Like

 0
Comment

 0
Write an article

Recently I made a career move from medical device and pharmaceutical back to biotechnology.
Having been in medical devices for the past decade design control and product lifecycle
management are familiar concepts and important documents and processes for any company but
get more important the more technical the product and the more risk associated with the product,
however these concepts do not appear to be well defined in the biotechnology and
pharmaceutical product space. I think it’s worthy of discussion on how the product lifecycle
management (PLM) principles are applied to a cell-based or biotechnology product and why
PLM is important. There are also some inconsistencies and definitions within the ICH and other
guidance’s that should be addressed and discussed. The following is my version of PLM.

One of the first questions that arises, is “where does it say we need to do this in the
regulations”? The short answer is it doesn’t… yet. However it is implied in several locations and
even a brief attempt to define it is in ICH Q10. For example, ICH Q7 is about Good
Manufacturing Practices, ICH Q8 is about Pharmaceutical Development, ICH Q9 is about
Quality Risk Management, ICH Q10 about the pharmaceutical quality systems, ICH Q11 is
about the Development and Manufacture of Pharmaceutical Drug Substances, and ICH Q12,
while not yet published is titled “Lifecycle Management”. All of these ICH standards refer to the
product lifecycle and even the FDA Guidance on Pharmaceutical Process Validation refers to the
principles of validation over the lifecycle of the product. The PLM process is important because
it defines how all these systems are interrelated and defines key product stages, documentation
and required outputs that are produced by each stage. This ensures a couple of things, 1) that a
good plan for the PLM is in place, 2) that there is a good documentation trail on how the product
was realized (designed), and 3) clear communication and agreement to each aspect of the product
as it is realized/designed. It is unfortunate the ICH waited until Q12 to get to a PLM process, as
it might have been better to start with PLM and then provide the details of the different elements
in subsequent standards. In any case, let’s look at what a PLM system might look like as a
prediction of what ICH Q12 will eventually look like and be ahead of the game.
Any product has a product lifecycle to it. The lifecycle can be viewed in a linear fashion or in a
cyclic fashion as the name implies. Figure 1 below depicts the standard stages of a products
lifecycle, and any product can be viewed this way regardless of the product. I’m going to use the
term “stage” to differentiate it from clinical phases. One source of confusion is the terminology
“design” vs. “development”. If we talk about Quality by Design, or QbD, we are talking about
the entire product lifecycle, although it should be noted that the ICH standards don’t appear to
consistently use the term in this manner they should have. The design of the product occurs over
the entire lifecycle of the product or until the product is obsoleted. This is opposed to product
development which is a specific stage of the PLM. Even during the commercialization stage we
are gaining product knowledge in the form of complaints, on-going product monitoring and new
technologies which may arise and will lead to both major and minor changes in the product and
add to the general design knowledge of the product and improvements. We also break down the
product lifecycle into additional stages beyond what the ICH does and remove an important
factor which is Technology Transfer (or Tech Transfer) because this isn’t actually a stage as the
ICH has it, but rather a process. In the following paragraphs we will break down each stage with
important elements of each and in this particular case we will refer to a cell-based technology as
we think about the PLM. These details would simply be altered depending on the specifics of the
product.

Figure 1: General Product Lifecycle Management Stages of product realization.

Feasibility:
The first stage of product design is the feasibility stage. Feasibility provides the basic proof of
concept. This stage may be poorly documented, and often exists in notebooks and reports. It may
include animal studies or bench testing and general product characterization. The outputs of this
stage should be summarized into a feasibility report. This report would list what is known about
the product and its’ functionality and what data exists to support the basic feasibility of the
product including references to known publications. It also defines the initial products
requirements and why they are important. Using our cell-based product as an example, it likely
defines required cell numbers and viability as well as the presence or absence of certain proteins
and cell markers. It also likely includes what’s known about the mechanism of action and
identifies several potential therapeutic uses.

Another output from this stage should be a marketing report. The marketing report should
evaluate the market landscape for this particular product. The marketing report should include
existing treatments, including costs, benefits, side effects, market size for potential treatment
areas (a product may have several potential uses, for example, a breast cancer product may also
be used to treat ovarian cancer or other types of cancer) by both number of patients, costs of
treatments, costs of the disease, and broken down by geography. The marketing reports should
also evaluate potential changes to the market, such as emerging technologies and other areas
which could impact the target market. The final summary of the marketing report would
recommend which market is being targeted and why and also potentially define important
product requirements based on the needs to ensure a successful product. The marketing report
should be independent from the feasibility.

Planning:
Dwight Eisenhower said, “Plans are nothing, planning is everything”. What he meant by that is
that the plan in of itself is not important because even the best plans will change as we gain
additional knowledge, but the act of planning is critical for success. The plan WILL change, but
documenting the plan provides evidence of the planning that took place. This is applicable to
product design as well. A plan should include a detailed look at the various remaining PLM
stages and what outputs will be required at each stage and details of how each task will be
accomplished. Most critical is a laid out plan for the development stage, but the plan should also
include information for each product stage, and should include factors such as scale, regulatory
pathways for different geographies, cleaning validations for both production and commercial
scale, how validation will be performed, packaging requirements, which factors need to be
considered for product obsolescence (compassion uses, retention of reference and/or retain
samples, ongoing stability, retention of documentation etc.), analytical methods, facility
requirements, etc.. Putting the plan in the document system as a controlled document is also
important as it establishes evidence of the planning activity. The revision history will track
changes and updates to the plan which should be reviewed at each stage end review.

Probably the most important output of this phase is the TPP or Target Product Profile. This is
typically a table that is similar to what your label will look like. This document may have TBD
(to be determined) entries, or blanks, as initially we might not know exactly, but formally
controlling this document and tracking the changes allows traceability to the product history. For
more see the FDA guidance on TPP as a strategic development process tool. The FDA and other
agencies will ask for this document as a product summary when meetings or discussions are
needed.

In addition to the product plan, a risk plan for the specific product should also be drafted,
although it may be incorporated into the product plan. The risk plan should cover how the risks
will be evaluated during each of the product stages. As an example for an aseptic, cell-based
product, the risk plan might state that a preliminary hazard analysis (PHA) will be performed
during the development stage evaluating all of the raw materials, which will take into account
each materials contact with the finished product, the biological and chemical complexity of the
material, the origin or source of the material (bovine, human, porcine, etc.) and the materials
known or expected impact on the final products safety and efficacy. This PHA will be used to
identify critical materials, vs. non critical, vs. general materials and focus the development
efforts on understanding of the critical materials and what the critical quality attributes (CQA’s)
for each of these critical materials are and what failure mode each critical material has on the
product. Once these are identified a dFMEA (Design Failure Modes and Effects Analysis) will
be performed to determine a risk priority index and document mitigations for each component
material. The dFMEA would then be part of the technology transfer (or tech transfer) to the
production stage and will be updated and reviewed when changes to the product are being
considered and as product knowledge is gained during production and commercialization stages.
Just as we did for the materials, we would do an analogous process for prioritizing the risks of
the process and ultimately document this in a pFMEA (Process Failure Modes and Effects
Analysis). These aren’t the actual risk activities, which will take place in the development stage,
but rather a plan of how they will be managed and what documentation will be generated and
when in order to document the plan was executed accordingly. The final output of the planning
stage is minimally a product project plan which either plans out the risk activities, or is combined
with a separate product risk plan. Once this is completed and approved in a document control
system, there is a stage review signoff, documenting the planning stage has been completed, and
the project is officially in the development stage. In this case the stage review could be foregone
if the signoff and approval of the plan is used in lieu of a stage end review.

Development:
The ultimate goal of the development stage is to characterize and understand which process
parameters, materials, and material attributes are important to ensuring that the product will
consistently meet the requirements needed for its’ safety and efficacy.

While development activities will vary within each product type and even from product to
product, there are some key elements to any product development. First of all, product
development should utilize sound and practical scientific methods. While this may seem obvious,
often experiments are done poorly, lacking appropriate controls and clear documentation. A
good understanding of design of experiments, or DOE, provides the foundation for good
development work. Multifactorial experimental designs are particularly useful. Creating the risk
documents discussed in the planning stage is of particular importance. These risk evaluations not
only drive the development process, but also will provide the basis for key decision making and
should feed directly into the CMC section for IND’s and ultimately NDA’s or BLA’s.

In addition to the experimentation it’s important to identify and source the materials that will be
needed. If it’s preferred to identify and use GMP grade or USP grade materials in the
development process this may save time later and should be defined in an SOP. Outputs from the
Development stage should include risk documentation, material specifications, a master batch
record, initial evaluation of container closure systems, analytical methods, etc. A stage end
review is critical at the end of the development stage. This is because it implements what is
known in the device world as a “design freeze”. The design freeze doesn’t mean the product is
frozen forever, but it marks the implementation of change control. During the development
process documents may be changed and managed under the document control system with little
regard for the impact on the product. But demarking the end of the development stage with a
formal stage review puts the product under change control where changes have to be evaluated
for their impact.

Production:
In our example, we’ve split the ICH’s commercialization stage into Production and
Commercialization. The reason for this is that we would like to make clinical material in small
scale batches and we’d like to do that in a production environment. In the ICH version this
occurs under development, but in reality it’s better to transfer this to a production or pilot stage,
where the product is made under GMP, with various caveats, such as process validation, method
validation, packaging system validations, not yet having been completed. During this stage we
are using GMP, we are qualifying equipment and facilities prior to use and we are ultimately
going to end up at commercial scale. These materials will be used to support Phase II and Phase
III clinical materials, they may also be used to support Phase I materials, but these may be made
during the development stage as well. Any changes will be made under change control and
changes will be evaluated for their impact to the risk of the product.

Commercialization:
The commercialization stage is the final stage where the product is on the market. The key
factors between this stage and the production stage is process validation has been completed, the
regulatory filings have been completed and approved and the product is under full GMPs and all
supporting validation is in place. We have defined the manufacturing process scale and are
making product at that scale. We are now at a stage where we are monitoring in-process and final
product control parameters and looking for intra and inter lot variability. We are monitoring
critical quality attributes and critical process parameters and each production lot is being
verified.

Obsoletion:
Obsoletion of the product is the exit strategy. As previously mentioned it is how and when we
stop manufacturing, and how we phase out the various aspects of monitoring the process, such as
product complaints, discontinuing or wrapping up ongoing stability studies, planning out the
destruction of reserve samples and records, and determining the regulatory impact of withdrawal
from the markets where the product is currently marketed.

Technology Transfer:
You might have noticed, we skipped over the technology transfer stage defined in the ICH
standards. This is intentional as this is another problem with the ICH’s use of Tech Transfer.
Technology transfer is not a stage per say but a process which is implemented whenever
technology is transferred from one group to another or from one facility to another. It’s a method
and process for transferring all of the known design information. Most typically the technology
transfer occurs between development and production stages as the product and process moves
from a development department to the manufacturing department. However, the technology
transfer may occur at other times as well. For example, in our depiction here of PLM it may also
occur between a pilot plant during the production stage and the full-scale manufacturing plant at
the commercialization stage. It also may occur anytime during the development, manufacturing
or commercialization stages, if we transferred the product/process to a CMO (Contract
Manufacturing Organization). We would also use it if we setup a second manufacturing plant to
increase the capacity.

Documentation:
Lastly, being in quality we have to discuss documentation. Another gap in all the ICH
documentation is now that we have all this documentation of the stage end reviews, the risk
assessments, the experimentation and validation activities how do we keep track of it all? In the
device world we refer to the Design History File, or DHF. The same concept applies to
pharmaceutical and biotechnology products. As part of the development activities, we initiate a
product history file or design history file (we might refer to it as a PHF, or a DHF). This allows
anyone to review the design or product history and look for the information in an organized
manner and allows for us to provide this as evidence, so what we did and how we did it and the
reasons we did it are documented and well understood.

I hope this brief discussion of the product lifecycle management process has been useful. It really
is a good way to realize product. I’ve realized over the past few years working with different
companies that this concept is not very well understood, and even less so in the biotechnology
and pharmaceutical space. More often than not quality gets stuck on single-line, cross-out
corrections and whether or not documents are in a fire-resistant cabinet, and those are important
things, but recent 483’s and warning letters indicate FDA and other regulating agencies are
becoming less focused on these details and more and more on how we make the decisions we do
and document the process of realizing product over its’ entire lifecycle, how we validate the
processes and methods and how we analyzed the risks associated with the product. A good SOP
with clear direction and distinction of the various product stages will go a long way in providing
this evidence.