Pharma Industry: Anyone Experience Deja Vu when attending serialization conferences?

I have to first admit that I have not been in the serialization world nearly as long as some veterans of the industry...but it didn't take me long to realize that 95% of every serialization-related conference over the past 5+ years might as well be scripted....I've attended conference after conference, listening to the same 'user experiences' and hearing panel after panel tout the importance of getting executive stakeholders involved (is that ever not important?).  I will stop well-short of saying the conferences are not valuable - the opportunity to gather with industry peers and exchange ideas will always be a worthwhile activity....  But for someone who's perspective in this space has always been down at a detailed level the typical conference discussions are lacking.. even frustrating at times.

What sparked this topic for me was an article reviewing a recent conference (http://www.healthcarepackaging.com/trends-and-issues/traceability-and-authentication/could-federal-bills-supersede-california%E2%80%99s-e)

DISCLAIMER:  My comments from this point forward are in no way critical of this article, the publication, or the conference it covered.  Rather this article, in my mind, highlights some of the misconceptions (and misunderstandings) still so prevalent in the industry.

#1 "On the heels of a Healthcare Packaging survey of more than 1,000 stakeholders that reveals one half of the respondents have not started a serialization project yet"
This comment is one more from curiosity as I am not familiar with the survey referenced in the quote.  My knee-jerk reaction was to be skeptical of the statement that half of respondents have not started a serialization project yet.  But as I thought about it more its only because we don't know the context of that statistic -

• Is it half of Manufacturers?  (I'd actually find that hard to believe - but selfishly also hope it is true because I will be an even busier man than for the next year and half!!)  
• Is it half of all supply chain participants?  (more believable).  
• What constitutes a 'serialization project'?  strategy, pilot, implementation?   

I will continue to search for the raw results of the survey to get this context.

#2 "One speaker talked about the challenge of getting top management to agree that serialization is a regulatory necessity, not promising any ROI in the near future. "Meet with your C-level Suite executive individually and then collectively as a team to make sure all buy in.""
It cannot be denied that the majority of pharma, despite what's stated in project charters and strategic planning sessions, is being driven far and away by compliance- not by a desire to improve product security, or process efficiency, or supply chain visibility.  It's unfortunate, however, if this quote (in my interpretation) effectively says to give up hope of making a positive ROI anytime soon.  (See earlier posts about how other industries take on serialization and traceability with full expectations of achieving positive ROI)

#3 "While the vast majority of pharmaceutical companies use SAP, they need a bridge from another supplier to do e-pedigree. But one attendee said SAP is meeting to discuss what kind of module would be necessary to accomplish this. "Hey, if we are on SAP and our trading partner is on SAP, can’t you make it advantageous for both of us?"
I'm focusing mainly on the last sentence here - "Hey, if we are on SAP and our trading partner is on SAP, can’t you make it advantageous for both of us?".   For a technical guy like myself, and someone who advocates the use of standards, this just breaks my heart...  how often do we see the term 'interoperable' littered throughout pedigree and proposed federal legislation?  The whole purpose of EPCIS and DPMS is to ensure that any two systems, large or small, can communicate with each other.  This isn't a knock on SAP, it's a knock on the lack of understanding the underlying technical details of how serialization and traceability data, regardless of format, is traded between supply chain partners.


How interesting would it be to have a conference attended by the Solution Architects, DBAs, and Developers that have been deep in this space for so many years? Or better yet do we need to start sprinkling in sessions for these resource groups at the existing conferences?  I think it would be an eye opening experience...

Traceability Tip of The Day: Determine Proper Ownership of Data in Your Serialization and Traceability Solution

Leverage best practices from Enterprise Integration to retain proper data ownership in your global serialization and traceability solution..... In most cases, the system to manage traceability data, often referred to (incorrectly) as an EPCIS repository, is being introduced for the first time to company’s enterprise IT architecture.  Whenever a new system is introduced, especially one that should be considered truly enterprise, two questions have to be asked:   

1. What Data will this system own?
2. What functionality will this system own?

Traceability systems introduce a new data set to enterprises which is the event-based information about activities that occur to their products.  In a GS1 standards-based solution this data is communicated in and, in many cases is known as, EPCIS.  In its purest form EPCIS is simply a bridge which connects key elements from other data-sets (i.e. product, location and others) together to create context-rich traceability information that is useful to business users.  A quick example - an EPCIS event may include an item identifier (SGTIN), a location identifier (GLN), and a business transaction identifier.  On their own these data elements are nothing more than strings of characters.  Additional data is needed to give the data context and meaning.  I group these different data sets into 3 categories (which will be expanded upon in future posts)

1. Event Data  (i.e. EPCIS)
2. Master Data  (i.e Products, Locations)
3. Transactional Data (i.e. business transaction details, Lot details)

In almost all enterprise environments systems already exist which 'own' master and transactional data (such as ERP and other 'Systems of Record').  A dangerous path emerging however is to include significant amounts of master and transactional data into the EPCIS events directly.   My tip is to keep EPCIS for what it was intended to communicate - and leverage enterprise integration capabilities to push/pull/subscribe to master and transactional data feeds when needed.   This will result in less duplication of data across your enterprise and better defined data management.    Reach out to me to learn more about how to properly architect your serialization and traceability solutions.

The Dichotomy of Supply Chain Traceability

There are undoubtedly endless ways you can slice the concept of supply chain traceability into competing sides - feasible vs not achievable, valuable vs ineffective, strategic vs a pain-in-my-a**.  My experience has made me (or better yet, allowed me to) view traceability from 2 vantage points:

• Those who must do it
• Those who want to do it

Those who must do it vs those who want to do it.  I've written on this topic in the past - the fact pharma, by and large, is being regulated into traceability places a dark shadow over both its perceived value and the potential for implementing the absolute best solutions.  

I've had the unique experience in past roles to see both sides of this equation- sometimes in a matter of minutes.  I've held meetings with pharma companies looking ultimately for compliance and, quite frankly, wishing 'serialization' would just magically go away.

I then turned around and had meetings with non-pharma companies who couldn't implement traceability fast enough.  They recognized product security, process efficiency, and marketing benefits that ultimately elevated traceability to be a strategic driver for the company.

The drastic range in views always interested me -and honestly I can't say I know exactly why such opposite views exist, and thus I always return to the one obvious differentiator - regulation and compliance in pharma (i.e. being told what to do). 

Nonetheless, both sides can stand to learn from the other.  Pharma has championed the adoption of global standards- a critical component since traceability is really all about the sharing of data

  

Outside of pharma, however, I would often educate companies on this group known as 'G-S-1'.

On the other hand, outside of pharma companies are approaching traceability not as a supply chain capability but as their supply chain. Period.  And isn't that how it should be?  And to be clear these are companies that have just as complex packaging processes and global supply chains as pharma - in some cases you could argue even more complex when it involves tracking of upstream raw materials or components, as is often the case.  More folks in pharma need to be aware that traceability exists outside their industry and plenty of lessons can be learned.

The call to action for Pharma is to broaden the vision for traceability.  Embrace the fact that serialization and traceability are two independent concepts in which one isn't required in order to have the other.  Most pharma's use the terms 'Serialization' and 'EPedigree' to name their global programs but is that really inclusive enough?  I certainly can have traceability without serialization and without E-Pedigree.  Here's a litmus test - where does non-serialized item traceability fit into your global 'serialization' program?  A perfect starting point for an upcoming post.

Welcome to Jennason LLC - Let's Get Started...

It is with great excitement and pleasure that I announce the launch of Jennason LLC.   Jennason is focused on providing professional services to companies at all phases of product identification, serialization, and traceability initiatives.  Jennason is unique for one simple reason - the experience of actually doing serialization and traceability implementations for over 5 years.   It's a time of critical mass in the pharmaceutical industry as many have finalized 'pilots' of their packaging lines and distribution centers and have now reached the point where key questions arise:

• How will all my IT systems 'talk' to each other?
• How can I ensure I provide the traceability data needed to be compliant?
• How is this all actually going to work?

Jennason's goal is to leverage past experience to help companies avoid the all-to-common pitfalls seen in serialization programs and instead design and implement solutions that meet the compliance requirements of today while laying the foundation for transformational supply chain capabilities of the future. 

Jennason is about acting and doing.   The phrase "The devil's in the details" is all too true when it comes to traceability solutions and that's exactly where Jennason can help.   From helping design some of the first enterprise serialization solutions to the pharmaceutical industry in the mid 2000s to bringing innovation and creativity to this space in the recent years Jennason's experience has always focused on the details.  

Even before this official launch the response from those in industry has been tremendous and I couldn't be more excited about getting things started.  For more information visit www.jennason.com and reach out to me directly at scott.pugh@jennason.com.        

Some UDI Thoughts...

I recently responded to an industry member's question around the use of GTINs for purposes of meeting UDI compliance... As is true with any requirement and regulation everything is up for interpretation.... but I felt others may find this information helpful so I decided to post.  

The question mainly centered around the proper allocation of GTINs to devices in a few different situations- specifically devices that are sold as part of kits, identical devices with different internal SKUs, and proper use of the GTIN-14 'indicator digit'.

My two cents below:

The first key is to evaluate whether the devices in question fall under the requirements defined for 'Combination' or 'convenience' kits. As the UDI rule states all devices in a convenience kit, except single use devices, must bear its own UDI in addition to the UDI assigned to the entire kit. I'll assume for now that [the] device in question either falls under this rule or that you simply prefer to mark your device to improve identification and tracking.

As for the proper GTIN to use on an implantable device- the first step is to take your GS1 assigned company prefix. I'll use 1234567 for purposes of this example The next step is to assign an 'item reference' number which is completely up to you. Med device is fortunate in that it doesn't have to deal with the issues the pharma industry encountered in having to encode the pre-assigned NDC into the GTINs for all of their products. In your situation the recommended approach is to assign GTINs sequentially, thus a valid GTIN-12 that could be assigned to an implantable device would be 123456700017 (the 7 is the check digit). To convert the GTIN-12 into a GTIN-14 which would be encoded in the 2D barcode and stored in any IT system you simply add '00'.

The next key point is that the GTIN assigned to the implantable part does not have to link in any way to the SKU used internally at [your company] to identify that part. A common best practice that I recommend to companies is to utilize the GS1 field AI(240) which represents your legacy SKU. Many companies will continue to encode the legacy SKU into the barcode using this GS1 field to help minimize the impact to exiting IT systems which are based off the legacy SKU. This should only be used temporarily however as IT systems should be converted to use the GTIN as the primary identifier for the device.

Using the logic above you should not have identical parts that have different GTINs because the mapping between your legacy SKUs and GTIN will not be 1 to 1. In the case you assign a different legacy SKU to a device because of its manufacturing location, going forward the device should use the same GTIN regardless of mfg location. Again you can utilize a GS1 field for mfg location (AI 422) in the 2D barcode to minimize impact on IT systems which may need to map the now common GTIN to its legacy SKU based on mfg location.

Finally your question around indicator digit. For all unit-level items the indicator digit will always be '0'. You can not use the indicator digit to differentiate one device type from another. Indicator digit is only used to portray some level of packaging hierarchy. In the case you describe you would have two different GTINs for the two different devices included in the kit (e.g 00123456700017 and 00123456700024). Additionally you would have a 3rd GTIN assigned to the kit as a whole. this GTIN would still use an indicator digit of '0' since the kit itself is a sellable-unit. (e.g. 00123456700031)

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.