Understanding the details in the latest GS1 US Healthcare Implementation Guide

In the past weeks GS1 US Healthcare released its latest Implementation guide titled "Applying GS1 Standards to U.S. Pharmaceutical Supply Chain Business Processes to support Pedigree and Track and Trace." The goal of this document is to help clarify some of the more ambiguous use cases in the application of GS1 standards and specifically focus on how EPCIS can play nicely with the Drug Pedigree Messaging standard (before it eventually kills it off). In the past I have felt that one challenge for those trying to learn and understand GS1 standards is the existence of TOO MUCH documentation. Such is the nature of a standard- always open to (mis)interpretation. Fortunately this guide does a good job of summarizing key implementation rules and best practices- but of course its not perfect and we'll review both sides in this post. Overall I give the doc a B+.

The Good
For me this is one of the first GS1 docs in the serialization and traceability space that I've reviewed which really tries to address 'where the rubber meets the road.'   Too often other standards or implementation guides had to stay up in the clouds- but this doc gets down to data-field level detail.  A few of the 'good' highlights -

• Good clarification from GS1 US that in order to allocate GTINs that work for the US supply chain the manufacturer must obtain a GS1 Company Prefix that contains their FDA labeler code (which allows for the embedding of the NDC into the GTIN).  An important point to remember- a GTIN is globally unqiue, but is not guaranteed to be accepted globally.
• Good overview of GTIN-12 vs GTIN-14 and the appropriate method for allocating item level GTINs.   Some pharmas to this day were still questioning what indicator digit to use in their item-level GTIN-14, since in their defense, the previous GTIN allocation guide for Healthcare stated that an indicator digit of 1-8 should be used (however it was referring to the ability to show packaging relationships).  It wasn't nearly as explicit as this guide in stating that an item-level GTIN is really a GTIN-12 which when padded with '00' gives you the GTIN-14.

The 'Eh'
A few areas that didnt exactly provide accurate clarifications -

• Within the span of half a page (Bottom of page 34 and top of page 35) the guide provides 2 examples of 2D barcodes
• The first example is used to make the point that fixed length fields should always be encoded before variable length fields
• A second example, however, shows a 2D with human readable text in the order GTIN (fixed), SN (variable),Lot(variable), and Expiry Date (fixed) 

GS1 recommends that human readable are printed in the same order as encoded in the barcode.  Ultimately this oversight doesn't cause mass problems as its a recommendation and not a requirement- but you'd at least like to see some consistency here.  In fact scan all 4 barcodes on that page and compare to the human readable- only 1 matches the order printed.

• Something about the statement made on page 10  "The DPMS complies with all known U.S. pedigree laws, and is currently the only pedigree format approved by regulators." doesn't sit well with me.  I'm sure the authors can argue its validity but the potential for misinterpretation is very high.  When taken literally I don't believe the statement is correct especially given the recent statements from the California Board of Pharmacy.  The board has now repeatedly stated they are not tied to any particular technology or standard and are open to any method of compliance so long as the regulation requirements are met.  Thus the fear is that this statement will be interpreted to mean "the only way I can comply with California is to use DPMS" which is simply not true.  Yes its the most well known, and likely the most adopted solution for California compliance but to say its the 'only' solution hinders the creative-thinking needed to find the best solution.

The Ugly
Some of the missteps including thoughts on whether the recommendations push EPCIS too far from its principle focus -

• Page 47-79: Summary of the recommended extension fields to use in various EPCIS events.  I completely understand what GS1 US Healthcare is trying to accomplish here - my fear is its a very short sighted and narrow focused solution to the use of DPMS for the California compliance problem.   Not only is master data introduced to EPCIS events, but significant amounts of master data, and thus the question becomes - where does it end?  Pretty soon an EPCIS shipping event will turn into a DPMS compliant document- and, to me, that is completely against what EPCIS was developed to do.    As a Solution Architect and Provider I recognize the inclusion of the recommended extension fields will simplify Pedigree solutions from an IT standpoint .  Yet what happens when another country regulation comes out that requires new data elements which are not needed for Pedigree or included in the base EPCIS standard?  My fear is that solution designers will see the precedent set by this guide for Pedigree, include all needed data fields into the EPCIS events themselves and not really question whether that is the best approach.
• Everything after Page 80-   They came so close to producing a complete guide that explained things in plain English...and then came the short-hand diagrams that look like equations out of Good Will Hunting.  Sure if you spend a few minutes to review the notation the diagrams become understandable (with a cheat sheet) but by this point in the document to throw in those diagrams will only make people stop reading.   There's valuable recommendations in those sections but whats more important is knowing your audience.  The reality is there is still a portion of the industry that is learning about serialization and traceability- it needs to be simple.  The doc truly does a great job of explaining items that previously caused confusion - clean up the last section  and it's a fantastic reference guide for the industry.

It's all about Setting Expectations

A lesson that stuck with me from my consulting days is the importance of setting expectations- never surprise a client with negative news.

So let me set expectations- Initially, your business process efficiencies will be impacted negatively by serialization.

Let's all understand that up front so that we can instead focus on the best ways to operate in a serialized world. Serialization changes the way you do business- period. It is almost ridiculous to assume that such a foundational change to manufacturing and distribution processes can be accomplished without taking some hits.

The issue in the industry, and the cause for the hyper-sensitivity, is that the focus is always, and only, on this negative. The loudest people in the room are often the packaging and distribution supervisors whose heads are on the line when throughput declines.

The unfortunate part is serialization its not being sold correctly to the business stakeholders.  I don't envy the folks in industry responsible for doing this and it's not entirely their fault.  For example we still don't have enough historical data from the industry to say "throughput is going to decline BUT here's exactly where, and how much, we'll make up in other areas."  This is changing though as companies are starting to require this level of analysis as part of their serialization initiatives.

Again my belief is the magnitude of change that serialization will bring must be made clear from Day 1.   The cost vs benefit question relative to process efficiency is a balancing act that should be documented as part of any enterprise serialization strategy.  The question at hand is:  How many events throughout the packaging and distribution processes should be captured?  The less events captured, the lower the impact to process efficiency however the more events captured, the greater process impact, but more ability to use data to facilitate process improvement.  The answer is neither extreme.

Some interesting ways how serialization data can be used (note these have nothing to do with regulations or product security) and can be used when 'selling' serialization.

• Process Monitoring-  An example, serialization data can highlight why on Tuesday afternoons two of your distribution sites seem to have higher throughput than other days.   Serialization can provide that type of data
• Supplier Contract Control-   Shhh.. don't let your CMOs and 3PLs know but essentially when asking them to capture serialization data for you you are really getting a detailed view into their operations.   How many items are damaged?  How long does it take to package a batch?  How often are orders re-worked?   All data that can be used going forward to enforce contract SLAs
• Authentication-  The concept of authentication is starting to gain traction.  The rise of mobile technology allows for the tracking of product virtually anywhere.  Authentication is often associated to consumers, however, it should be thought of in terms of internal resources as well.   Authentication represents the best way to receive immediate value from serialization from the moment the first serialized item rolls off the line.  More on this in an upcoming post.

When is a Pilot not really a Pilot?

First a quick note- Congrats to EXLPharma for putting on a successful serialization and traceability conference in Philadelphia this week.   The existence of such focused workshops and conferences is yet another positive sign the industry is doing the necessary legwork to connect with industry peers and gather what's been learned to date.

The topic for this post came in part from this week's conference.   A very popular trend among pharma's taking on serialization is to run a 'pilot' to gain education and experience with how to operate in a serialized world.   I am all for the concept of pilots and agree they provide invaluable experience.   However I have a growing concern that these 'pilots' are too focused at the packing line level alone and not with core process integration.  As an analogy, my view is that serialization needs to be as core to a packaging/distribution processes as batch records and QA checks. 

Take this simple scenario:  How many pharma companies running pilots today would actually stop an order from shipping solely because a serialization related issue exists?    Or even go one step back:  How many companies would even know they have an issue with their serialization data prior to shipping product? 

In a still largely unregulated world- the reality is product supply, getting product out the door, will always trump serialization.   I completely understand this- in an unregulated environment- but highlights my concern that companies are not designing their serialization solutions to directly integrate with their core packaging and distribution processes. We all know it will have to be that way eventually- so why not at least plan for it from day 1?   

The interesting twist on this topic is that outside of pharma, high tech as a perfect example, the integration of serialization with core manufacturing and distribution processes is found in the earliest business requirement documents- and this in an industry that's not being told they have to do it.

The industry is already hyper-sensitive about process efficiency impacts due to serialization (which I'll expand on in an upcoming post) yet hasn't even reached the point in the maturation of serialization solutions where process impacts may be the greatest. 

My suggestion is to plan for a fully integrated serialization world, even if it means you dont stop shipments until required, by having the technical components to identify serialization issues and the SOPs to handle these exception scenarios.  This will help companies ensure that January 1st, 2015 (or whenever) is truly a non-event.

Serialization in Life Sciences: How to go from Required to Desired.

You’ll likely find serialization ranked near the top of the ‘Most annoying/frustrating/irritating/just plain bad things to ask a Pharmaceutical Supply Chain executive’ list these days.  As is often true, being told you have to do something, rather than deciding to do it on your own, typically has negative connotations associated.  Not helping the cause are the occurrence of multiple delays to US state level regulations and an overall sense of confusion that still exists in the industry-  when will federal laws be defined, how do I meet the growing number of regulations around the world, who/what/when/where is needed to take on serialization at my company.

My goal with this blog is to provide some insights on how to envision the end state of serialization at your company, realizing it’s a journey, and most importantly what missteps should be avoided early in the process. 

While it’s unfortunate serialization has become a ‘dirty little word’ what’s more concerning are the initiatives that many companies have taken on to do ‘just what is needed’ to meet regulatory compliance- and not view serialization from a much broader perspective.  The narrow focus often means that process impacts are largely under-estimated and IT integration are siloed-  all topics of an upcoming blog entry.

But more impactful is the vicious cycle this creates between the industry and its serialization solution providers.   The minimalist approach of companies hasn’t pushed the majority of vendors to innovate.   As a consultant I’ve seen platforms that have gone largely unchanged in 4+ years- but in a sense can you blame the vendor?  Partially yes, but their customers were never driving them to expand and enhance their offerings.  The vicious cycle comes full circle then as pharma companies are stuck searching, confused as to where the mythical ROI, that everyone demands, will come from.

This trend (I say biasedly) is coming to an end as a crop of new vendors enter this space and push competition.  My hope is that companies expand their view of serialization, from the start, as not just bar coding unique identifiers on products to meet regulations, but as the enterprise wide, cross- discipline program it invariably becomes.