Today's post provides a
current assessment of the integration of serialization into common pharma
manufacturing processes. Certainly not a new topic and one that has been
covered in numerous articles from colleagues and vendors. As a point of
reference- nearly 18 months ago a great overview was provided by David Colombo
of KPMG in Pharmaceutical Online (Read it here).
How far have we come since
then? Did the industry heed the message or are we still treating
serialization 'in a vacuum' and missing integration into key operations?
Let''s dive into two key manufacturing processes where
ensuring proper serialization integration is critical.
Serial Number
Reconciliation-
No pharma manufacturer (following GMP) would release product without quantity
reconciliations being performed and documented in batch records. Quantity
of items packed, quantity of items sampled, quantity of items
damaged/destroyed- this is the norm of any packaging
operation. So why should it be any different with serialization?
With serialization an
entirely new data set exists (serial numbers) which must align with the
quantities documented in a batch record- So it stands to reason that checking
the quantity of SNs against the quantities in batch records each and every time
seems like a painfully obvious concept- many will assume it's being
done. But if you are a manufacturer and have ever experienced mismatches in your serialization data then quite clearly reconciliation was
missed somewhere along the way. (Comment and let me know your
experiences!!)
So, what's preventing
serial number reconciliations from being a pervasive concept? In many cases it
comes down to limitations of serialization solutions. Many vendor
solutions don't support the ability to do serial number reconciliations in two
main areas:
- Packaging site/CMO solutions which only allow the collation and communication of serialization data to manufacturers at the time of shipment. Following good practices- if a manufacturer only receives the serialization data for a batch after the product has been loaded onto a truck it is way too late in the process. When designing packaging site/CMO integrations identify trigger points during the batch process which will support reconciliation (such as upon lot closure). If either your CMO's system or your system can only support integration at time of shipment- be prepared to justify the risk of not being able to perform serial number-to-batch record reconciliation until 1) after you've had to provide batch release and 2) after your product is already in transit. What's the preferred capability in this area? Some solutions are able to take in batch record inputs (even better if they are electronic batch records!!) and automatically compare against processed serialized data- providing alerts when quantities do not reconcile.
- Solutions which do not support capture/communication of 'end-of-life' data (end-of-life covers any scenario where a serial number is no longer continuing in the commercial supply chain). This has long been a heated debate within the industry with organizations deeply rooted on both sides of the fence- in regards to DSCSA some choose to follow the regulations and only capture data for the 'good' items that get shipped/sold while others will require tracking of all allocated serial numbers. For what it's worth- I've always been firmly planted on the latter side. I summarize the debate like this- there is no right or wrong answer, but if you are only tracking the 'good' items then the extent of your organization's capability is serialization compliance, not true traceability. Again, for many organizations there is nothing wrong with that as they're likely still 'checking the box', it just means additional areas will have to be addressed before being able to take advantage of other benefits of true traceability (e.g. brand protection, process/quality efficiency monitoring, etc.)
Serialized Shipments- For many
organizations, capturing serialized shipping information is still a future
endeavor. But as 2019 requirements (both regulatory and industry
driven) start to surface the need to track items from manufacturing through
distribution arises. One practice, however, that appears time and
again is the concept of 'Ship by Lot'. In the old, quantity-based
world this concept had merit as it was an easy way to update quantities of
items in ERP systems. In a serialized world, however, continuing this
practice brings significant risk. The principle is
simple- You don't ship lots, you ship shipments.
What allows this
practice to continue in a serialized world is that often a shipment equals a
lot. Again, in the old, quantity-based world it was easy to say
"Ship Lot 123" and then enter the quantity actually being
shipped. In a serialized world, performing the same action "Ship Lot
123" makes a big assumption that all serial numbers which have been previously associated to that lot are now being shipped. The problem is that
organizations are not going through and actually scanning each serial number as
part of an explicit shipping step and therefore systems have to 'infer' which
items are now being shipped. The serialized world relies on
inference in situations where aggregations exist (physical product packed and
sealed in larger physical containers) but shouldn't rely on inference for creating significant traceability steps (e.g. shipping).
This practice is most
commonly seen at companies who have chosen not to aggregate for the time being
but are often 'forced' into generating a shipping step by either their vendor
or a downstream customer. Additionally, certain vendors have made
this practice too accessible by making it a standard (and even recommended)
capability in their platforms.
My summary: Wait
until you are aggregating before you start capturing serialized shipping
information unless your volumes are so small you can warrant doing an explicit shipping step. Moreover, once you are aggregating there is no reason
to continue a practice like 'Ship by Lot'. Instead perform a true shipping step which includes scanning of parent level containers.
No comments:
Post a Comment