Pharma Aggregation: How Companies Are Achieving Perfection Today

Bottle ID photo courtesy of Optel Vision

One of the biggest challenges for companies in the U.S. pharmaceutical supply chain when the California pedigree law becomes operational after December 31, 2014 will be the need to maximize the efficiency of dealing with serial numbers on each drug package.  One way to do that is to maximize the use of “inference” where the case serial number is read and the unit package-level serial numbers are “inferred” from the unit-to-case aggregation information supplied by the upstream trading partner (See my essays “Inference in the Pharmaceutical Supply Chain” and “Will The Pharma Supply Chain Be Able To Use Inference? Maybe Not!”).

But the problem with the use of inference is that you need to be able to rely on the accuracy of the aggregation information that your supplier provides to you.  There is an element of trust in that—not just that you trust your supplier to be truthful with you but that you trust that your supplier’s case packing processes and systems will always accurately capture and document the unit-to-case hierarchy—or “aggregation”.  You must be able to trust that the aggregation information your supplier provides to you will be 100% accurate.  That’s a lot of trust.

If you trust that the aggregation information you were given by your supplier is 100% accurate, then you don’t need to take the time to explicitly read every unit package-level serial number on every unit packed inside each case.  Instead, all you need to do is read the one serial number on the outside of each case.  You would use that serial number to find the unit package serial numbers of all of the unit packages inside each case and then update the ePedigrees for those packages.  Remember, ePedigrees are not maintained at the case-level, they are maintained at the unit package-level.

Inference saves time and physical system operation—especially if the serial numbers attached to each unit package are encoded in 2D barcodes, which appears to be the direction most pharma manufacturers are going for serialization for California (see my essay “RFID is DEAD…at Unit-Level in Pharma”).

Without the use of inference, companies would have to open every single case of pharmaceuticals they receive or ship, pull the contents out, scan the serial numbers on each package to capture exactly what they are receiving or shipping and then pack them all back up again and reseal the case.  With the massive volume of drugs that pass through the large companies in the U.S. supply chain today, this would slow the movement of drugs and would cause distribution costs to skyrocket, not to mention opening the door to the introduction of new errors and theft (thus actually lowering the security of drugs in the supply chain).

The use of inference is critical to the successful operation of serialized drug ePedigree laws.

HOW INFERENCE WORKS

Manufacturers generally pack their serialized unit packages of drugs into shipping cases—themselves serialized—shortly after the packages are produced.  That way they can stock them in their own distribution centers before they are shipped to their customers.  When they ship cases of drugs to their customers they won’t want to open the cases either so even they would need to rely on their own unit-to-case aggregations to infer the unit serial number so they can create the unit-level ePedigrees at the time of shipment.

After drug distributors receive the cases from the manufacturer’s distribution center they open most cases and fulfill their customer orders by packing small quantities of unit packages in totes for delivery.  Once the manufacturer’s case is opened by the distributor and individual packages are removed the case-level aggregation information is no longer needed.  The distributor would typically read the unit-level serial numbers on each package as they are fulfilling customer orders and update the ePedigrees to reflect the shipment to the customer.

However, some customers order in quantities large enough for the distributor to simply deliver one or more entire cases of a drug.  In that instance, the distributor doesn’t need to open the manufacturer’s case and so they would rely on the manufacturer’s aggregation information to know exactly which unit package serial numbers are being shipped to their customer and so that they can update and pass the correct unit-level ePedigrees to their customer.  The distributor would pass on the manufacturer-supplied aggregation information to their customer for the cases that were shipped, along with the ePedigrees for the packages contained within them.

Since the distributor’s customer will also want to receive their shipment as efficiently as possible, they will likely make use of the aggregation information to update the ePedigrees that they received from the distributor so that they do not have to open every case and read the serial numbers on every package inside them.

Notice that in this scenario, the manufacturer distribution center, the distributor and the distributor’s customer are all relying on the accuracy of the aggregation information that was originally captured by the manufacturer at the time that the drug packages were packed into the cases.

BUT WHAT HAPPENS IF AGGREGATION INFORMATION IS NOT ACCURATE?

If the aggregation information is perfect every time, no problems ensue.  But what if the information is incorrectly crossed between two cases?  That is, the unit package-level serial numbers are attributed to the case serial number of a case that actually contains the serialized packages of another case, and vice versa.  And now assume that one (not both) of those cases is received by the distributor’s customer in the example above.

In that instance, once the customer eventually opens the case and reads the serial numbers on the packages they will find that they do not have any record of those serial numbers, and they will not have a valid ePedigree for those packages.  Without a valid ePedigree the drugs cannot be sold, returned or dispensed in California after the regulation goes into effect so these drugs cannot be used until the discrepancy is fixed.

And the same problem will occur at whatever company received the other case that was involved in the error.  Both companies will need to work backward through their supplier until someone reaches the manufacturer where the error may be solvable.  If the manufacturer agrees that a mistake has been made, they may be able to transmit the corrected ePedigrees to the distributor, who may then be able to update those updated ePedigrees to reflect their corrected shipment and pass it on to their customer who would then have to update the corrected ePedigree and thus finally allowing the customer to sell, return or dispense the drugs.

That’s a lot of very inefficient customer service interaction and in the mean time the drugs must sit on the shelf unusable.  I hope you can see that for inference to work, there is a lot of reliance being placed on the accuracy of the aggregation information generated by the manufacturer.

IS IT EVEN POSSIBLE TO GENERATE 100% ACCURATE AGGREGATION INFORMATION?

Yes, it is possible.  The way to always generate 100% accurate aggregation information is to use a special approach to the case packing operation.  The key is to read the unit-level serial numbers only after the packages are bound together in a serialized grouping (inner-pack or full case grouping).

This is easy to do when the drug packages are serialized with RFID.  Each drug package would have a unique RFID tag attached to it and the case packing operation can be done in any way that it is today—nothing special…no changes.

Then, after the cases are sealed and an RFID tag containing the case-level serial number is attached, the case would be run through an RFID reader where all of the unit-level serial numbers and the case-level serial number would be read and associated with each other to form the aggregation information for that case.  Since the cases are already sealed, there is no chance of a mix-up of the contents between two cases, or some other discrepancy.  If the RFID reader doesn’t pick up all of the expected serial numbers the case would be rejected for quality inspection and rework.

The reason this works is that RFID doesn’t require a “line-of-sight” to work.  That is, the RFID reader can read directly through the cardboard case material and pickup all of the tags in a short time.

But, remember, I pointed out above that few, if any, companies are likely to put their unit package-level serial numbers into RFID tags and instead the vast majority of drugs will be serialized using 2D barcodes.  Barcodes require “line-of-sight” to work.  So how do you read the unit-level serial numbers only after the packages are bound together (remember, that’s the key to 100% accurate aggregation information) when the labels that contain the 2D barcode are on the side of the bottles?  Once you bundle them together many of these labels will be covered and so the barcodes are no longer within a single “line-of-sight”.

A NEW IDEA SOLVES THE 100% ACCURACY WITH BARCODES DILEMMA

Bottle ID photo by Omega Design

I don’t know who first thought of this idea, but the solution is out there and in use by multiple pharma manufacturers.  It entails the use of a “temporary” 2D barcode that is inkjet printed onto the bottom of all empty bottles.  This barcode contains a unique “bottle identification number”, or, bottle ID, that is unique for all of the bottles within the current batch of the drug being bottled.  The purpose of this barcode is to keep track of the bottles within the packaging and case packing operation.  I call the barcode “temporary” because it is only used within the packaging operation.

After the bottle ID barcode is printed on the bottom of each bottle the bottles are filled with the drug, capped and then the serialized drug label is applied.  The drug label would have the unique serialized National Drug Code (sNDC) (and hopefully the drug lot and expiration date…see my essay “SNI’s Are Not Enough In a Plateau-Based Supply Chain Security Approach”) encoded in a 2D GS1 DataMatrix barcode image.

Bottle ID and sNDC Photo courtesy of Optel Vision (click to enlarge)

Immediately following the label applicator is the traditional vision system camera that verifies that the barcode, lot and expiration date is readable.  But in this new approach there would be a second camera that would simultaneously capture the bottom of the bottle to read the bottle ID barcode.  The line management system would associate the sNDC in the DataMatrix barcode with the bottle ID.  Since these two serial numbers are unique, the association is also unique.

Inner-pack bundle. Photo by Omega Design

Now the bottles can be bundled together into inner-packs that are wrapped in clear heat-shrink plastic film so that they are bound together in a single unit and an inner-pack serial number label applied to the top of the bundle.  The sNDCs are not all visible, but the bottle ID on the bottoms of the bottles are all still visible.  Because of the associations between the bottle IDs and the sNDCs, reading all of the bottle IDs in the bundle in a single image allows the line management system to know exactly which sNDCs are present in each bundle.  Now the sNDCs of the bottles bound together in the inner-pack bundle can be reliably and accurately aggregated to the inner-pack serial number.

Packaging Hierarchy. Drawing by Omega Design.  Click to enlarge

Multiple inner-packs can then be assembled into a case using an automated case packing machine that has 2D barcode imagers strategically placed to capture the inner-pack barcodes as they are being loaded into a pre- or simultaneously-serialized case.  Now the case to inner-pack aggregation can be made accurately—100% of the time.

Again, the key to perfection is to capture the aggregation at each level only after the packages are already bound together.

WHERE CAN YOU BUY SYSTEMS THAT ARE BUILT AROUND THIS APPROACH?

In this essay I wanted to highlight the principle that allows RFID-based serial number aggregation to be so perfect, and which has recently been applied to 2D barcode-based serial number aggregation.  I have not done an exhaustive search to find all of the system integrators or machine builders who offer systems based on this principle.

I am not promoting or recommending any specific company, but I will say that I first became aware of this approach being used in the pharma industry by actual pharma manufacturers who were using systems made by a collaboration of four companies known as 4Serialization (which includes Omega Design).  I also know that Optel Vision has adopted the approach in systems.  I would not be surprised if there were other companies using it (leave a comment below if you know of others).  I have not worked with either of these organizations so I cannot vouch for the quality of their work.

Please do your own investigation before deciding which integrator is best for you.  The Pharmapack trade show is coming up in May.  That sounds like a great opportunity to talk with each vendor and find out what they’re capable of.  Just make sure they are following this principle and your aggregations will be perfect every time!

Dirk.

7 thoughts on “Pharma Aggregation: How Companies Are Achieving Perfection Today”

  1. Dirk – great post but the notion that aggregation using RFID is “easy” is quite a stretch, at least as a general statement. Injectable products and products blistered with foil continue to provide challenges with interference and read rates. Introducing new packaging configurations becomes a requalification nightmare as well. The points about aggregation and inference are good ones though, and I will suggest that it is only the beginning to be perfect in packaging….perfection/precision is needed in every transaction impacting aggregation from time product leaves packaging line until shipped from distribution center. WMS functionality has to be robust to maintain and update the aggregation data.

    Great blog!

    1. Anonymous,
      Thanks for your comment. You make an excellent point about the additional complications of RFID. Even better is your point that perfection in the collection of aggregation information doesn’t mean everything else that needs to happen along with it will be perfect. Even if the aggregation is performed perfectly by the manufacturer every time, the data could still be fumbled in several ways as it moves down the supply chain. That’s particularly true in a distributed pedigree model where the aggregation data would have to be passed from partner to partner–lots of opportunities to fumble the data there. It gets a little better in a centralized, or semi-centralized model where the manufacturer would deposit the data in a single, secure location and the each downstream partner would retrieve it from there.

      A lot of new things will need to happen correctly for inference to work properly under a serilized ePedigree regulation. Perfect manufacturer aggregation collection is only the start. The approach that I wrote about in this essay is simply that first step.

      Dirk.

  2. Hi Dirk
    Once again, an excellent and well-timed piece. I have two questions.
    First, regarding the scenario of wrong aggregation that you describe: “the unit package-level serial numbers are attributed to the case serial number of a case that actually contains the serialized packages of another case”: if the NCeP were used for the erroneous pedigree rather than DPMS, wouldn’t the investigation back to the manufacturer be rather easier since the pedigree anomaly can be fixed far quicker than with a document that has accumulated all the aggregations in one “fixed” place?
    Second, do you see the additional assurance of the “shrinkwrap+temporary barcode” concept as requiring both? In other words, might there be a value in only doing shrinkwrap without the barcode, or in only doing the barcode without the shrinkwrap? My feeling is that they are both *required*, since the rationale for printing in one fixed and always accessible location – the base of the bottle – is determined by the very fact that they will be shrink wrapped with (HOPEFULLY!) the bottom of the bottles always facing the same way.

    regards

  3. Dirk –
    First let me say great article. This is a great summarization of what we tell our clients. As a 4serialization partner, Acsis, Inc. offers an ERP-driven serialization management solution within pharmaceutical packaging lines to enhance product visibility and ensure compliance with ePedigree regulations. On top of this, we also have the ONLY fully-integrated rework solution available on the market.
    Our ProducTrak SPDM (Serialized Packaging Data Management) solution is intended primarily for life sciences industries subject to mandatory compliance and e-Pedigree regulations. SPDM manages the packaging, labeling and movement of serialized (and non-serialized) product throughout manufacturing and distribution, including outsourced operations. For more info on this an other Acsis, Inc. offerings, please head over to http://www.acsisinc.com.

    Thanks again for your insight Dirk; we’re glad we found your blog!

  4. Does anyone else wonder what information is REALLY in those 2D barcodes? I scanned the first & third images. (They seem to be the same bottle. I couldn’t read the 2nd image.) Running the application identifiers (AI codes) against the GS1 GenSpec yields the following:

    “Bottle ID”
    010030012345678591002508 -> (01)00300123456785 (91)002508

    “Bottle ID and sNDC”
    ]d2010030012345678521202165452885 -> (01)00300123456785 (21)202165452885

    Observations:
    1) The GTIN-14 value of “00300123456785” is indicated on BOTH barcodes.

    2) The temporary Bottle ID value is “002508”. Interesting that they use AI 91 for “company internal information” per the GS1 Gen Spec.

    3) The Bottle ID barcode does not start with an FNC1 identifier of “]d2”. So it may be DataMatrix, but isn’t GS1 compliant (see GenSpec section 5.7.2). That’s probably a good thing because it is TEMPORARY and not for use outside the company. However it does use GS1 AI codes to tag fields.

    4) The serial number value is “202165452885”. This matches the printed label text.

    It is very interesting that the LOT and EXP data are printed on the label text but not the barcodes. So we have not achieved full machine-readability! Has anyone seen DataMatrix barcodes that include the magic 4 fields (GTIN, S/N, LOT, EXP)? I want example images.

    Encoding all 4 fields requires another level of complexity in software to generate & scan these DataMatrix codes. Specifically, the GTIN + S/N example does not use an FNC1 separator between the GTIN and S/N. That’s because the GTIN is fixed-length and does not require a separator. You could even encode the GTIN, EXP, and S/N because the EXP date (AI 17) is fixed-length as well. But once you try to encode two variable-length values like S/N and LOT (AI 10), you must include the FNC1 separator between them. Here are two ways to encode the data:

    ]d20100300123456785212021654528851715120110123456*01
    ]d20100300123456785212021654528851715120110123456*01

    Is this issue a hidden barrier to adoption? Is anyone discussing the technical hurdles of parsing variable-length data?

    – Eric B

    P.S. That little asterisk in the LOT number throws another wrench in the works. It creates a larger 2D barcode because you must switch from the alphanumeric coding to ASCII to get that character.

    1. Eric,
      Thanks for the comment and thanks for the detailed analysis of these barcode images. Here are my thoughts on the points you raise.

      1. I have to assume those photos are from prototypes so I wouldn’t put too much weight on their contents. The concept my essay highlights could be done successfully with just a unique serial number, although I assume the addition of the GTIN would narrow the serial number range appropriately.
      2. Photos 1 and 3 are from the same bottle (I took those two photos myself from a sample I picked up at Pack Expo last year) so that explains why they contain the same bottle ID.
      3. I think AI 91 is not a bad choice for the bottle ID because the use of that value is temporary and should remain within the four walls of the company doing the packaging. I’ve been told that these barcodes could even be printed with ink that is (nearly) invisible to the naked eye so that it doesn’t confuse the barcode readers of downstream trading partners.
      4. On the other hand, the bottle ID-to-SGTIN association presents a very interesting unique relationship that has parallels with the tag ID-to-SGTIN relationship of some RFID tags. Some have proposed that the RFID relationship could be used to help identify when a criminal has attempted to copy SGTINs. However, it is a lot harder to copy the tag ID of an RFID tag than it is to copy the bottle ID, but there might still be some merit in retaining it and passing it downstream for an additional security layer if this approach gains wide adoption. If a criminal is only guessing at the copied SGTINs without actually being able to read them then they obviously wouldn’t be able to guess both the SGTIN and real associated the bottle ID.
      5. In my view the bottle ID barcode SHOULD always be fully GS1 compliant with the FNC1 character present. It’s detection and validation should be at a lower level in the decoding algorithm than the detection of the AI and the bottle ID. It’s a common oversight when it is not included but in my opinion that should not be an valid excuse anymore. Likewise, parsing variable length data that includes the proper FNC1 characters should also not be a valid excuse.
      6. I agree with you that the lot and expiration date should be encoded in the SGTIN DataMatrix image on the side of the bottle. I assume this sample didn’t include it because they probably wanted the barcode size to look as small as possible. A little “false advertising” perhaps?
      7. Regarding the sequence of the AI’s in an attempt to minimize the number of FNC1’s needed, I think that reading applications should be designed to accommodate ANY sequence that is compliant with GS1 standards, but you will find those who disagree and would ask manufacturers to always follow a prescribed sequence. See the HDMA Bar Code Guidelines for an example of that (see “Updated HDMA Bar Code Guidance: A Must Read“).
      8. The asterisk (*) included in the sample lot number shouldn’t be valid in the U.S. for drugs. GS1 specifies that a lot/batch number must be composed of up to 20 characters and they include upper and lower case letter, numerals and many symbols. However, I recently came across the MH10.8.2-2011 ANSI standard for “Data Identifier and Application Identifier Standard” which states that the character set for the contents of a data field are the upper case characters A-Z and the numeric characters 0-9. In that standard, Lot/Batch numbers are defined as a “data field” when identified by a “Data Identifier” like a GS1 Application Identifier. I wonder if this is followed in actual practice by pharmaceutical manufacturers? Anyone care to comment? Does the FDA limit the character set of lot/batch numbers?

      Dirk.

  5. Dirk,

    Kudos on a very well researched and written article. We here at Omega Design wanted to thank you for mentioning us and our line-level solutions. We’re also not sure when the idea for bottom coding might have first gotten its legs but it began as an original idea to us around 2007 and we actually exhibited the first pharma-related bottom-coding solution at Pack Expo in 2008. We spent a lot of time analyzing various serialization aggregation scenarios and always with the perspective that our customers will want the most secure and unimpeachable solution possible. After a lot of trials and what-if’s, we settled on combining a unique top-or-bottom code linked to the unique side-label code as the most bullet-proof means of aggregation since, as you correctly highlighted, the aggregate membership of any grouping should never be assumed, but instead should always be determined with absolute certainty only after the membership is physically assembled. After 2008 we set about developing a suite of supporting machines starting at the very front of the packaging line (our bottle unscrambler/orienter/feeder), where we actually apply the bottom code) and to the very tail end of the packaging line (where the aggregation occurs). All intended to create and assure the highest level of aggregation integrity and leveraging the benefits of this second ‘line code’. Dirk, you are absolutely correct: cost-effective technology is available now for line level implementation and we’ve fielded many systems already leveraging our capabilities. Thanks again for a thoughtful and well researched article and especially for confirming Omega’s contribution to helping pharma manufacturers protect their supply chains through 100% error-free aggregation.

Comments are closed.