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.