An Important Fact about 'One-Off' GLNs

Up until recently GS1 US (and likely other GS1 organizations) offered a 'One-Off' GLN Subscription service to help organizations obtain GLNs at a reduced cost.   The key difference with the GLNs which were allocated through this service is they did not contain a Global Company Prefix specific to the organization.   On the surface this causes issues when trying to translate the 13-digit GLN Element String into its corresponding URN format, such as urn:epc:id:sgln:0614141.12345.400.

GS1 US recently stopped offering the 'One-Off' GLN and instead restructured its pricing so that companies who only needed a small number of GLNs could obtain a valid GS1 Global Company Prefix at a very reasonable price.

However, if your organization is dealing with CMO,3PL or other supply chain suppliers/partners which obtained their GLNs through the 'One-Off' subscription service then ensure you follow the rules below provided by GS1 Global:

One off GLNs are handled as though they have a 12-digit GCP.

Example 1:

“one-off” GLN: AI (414):  0312345678913

Extension:  AI (254):  none

implied 12-digit GCP:  031234567891

EPC Pure Identity URI:   urn:epc:id:sgln:031234567891..0

Example 2:

“one-off” GLN: AI (414):  4012345678918

Extension:  AI (254):  4711ekW

implied 12-digit GCP:  401234567891

EPC Pure Identity URI:   urn:epc:id:sgln:401234567891..4711ekW

As companies move into later stages of implementation these are the details which can cause frustrating issues and delays.  Ensure your serialization systems are configured properly to parse these GLNs using the rules above.   And of course reach out if you'd like any more insight....

A Plea, A Hope and A Fear for Pharma Track and Trace

In general I try to stay out of the political on-goings at the Federal, State, and international level in regards to pharma serialization and track & trace regulations primarily because there are plenty of other folks who are involved in that space and they do it quite well.   

But over the last few days I too have found myself listening in to the CA board meeting and checking the house/senate schedule for when pharma supply chain security will be discussed.   I have no more insight into what will happen in the coming days/weeks/months than anyone else but I do have a plea, a hope, and a fear for the pharma industry in expectation that a Federal bill will pass and California E-Pedigree rides off into the sunset.

A Plea
Re-evaluate strategically.  Should California go away and be replaced with federal regs that push serialization timelines out a number of years every pharma is going to have to analyze their own situation- Are they subject to enough international regulations that it makes sense to push forward with a global solution?  How to harvest value out of what's been done to this point?   Would the Federal Bill be a get-out-of-serialization-hell-for-free card?

I certainly couldn't blame the pharmas who decide to shut everything down and re-allocate serialization funds elsewhere- let's be blunt- in general I don't get the warm-and-fuzzy from those in industry that they were really excited about serialization in the first place so why should things suddenly change?

But therein lies my plea-  I challenge the industry to change the tune of serialization and do a reality check.   The concept of serialization and traceability isn't the problem here, the problem has been the constant up-and-down, on-and-off wrangling of politics.

My plea is for the industry to demand more.....demand more in understanding how serialization and traceability can actually help you, not hinder you

• Implement serialization because you understand how it will help your patients
• Implement serialization because you understand how it can differentiate your product
• Implement serialization because you understand its importance to your supply chain's future

I think the big players in the industry are already somewhat down this path- but I can't say its true for the majority of the industry.  

A Hope

I think its safe to say that most in the industry never really viewed the Pedigree Document model as the best way to achieve traceability in a supply chain.  Moreover, I was never a fan of the GS1 Implementation guideline that came out in last year which proposed how to use EPCIS to meet Pedigree requirements.   So my hope is in fact the Federal Bill does pass so that the industry can reach a more comprehensive understanding for how to implement product traceability (the right way).   As we speak, the industry is barreling down a path of procuring and building solutions based so heavily on Pedigree and so heavily on the GS1 Implementation guideline.   Don't get me wrong- I am a huge supporter of GS1- but if you blindly think the world will always follow GS1 you're backing yourself into a corner.

I'm a big fan of EPCIS, but a fan of pure EPCIS, not one that is bloated with master and transactional data.   Here's just a tiny glimpse of what I'm saying-  there are 3 major data sets in play in any serialization and traceabilty implementation  1) Traceability data   2) Master Data   and 3) Transactional Data.    EPCIS, GDSN, GS1 Business XML and/or EDI represent these data sets that must work hand-in-hand in order to provide complete visibility.

My hope is someday enterprise solutions will enable the collaboration between these three data sets while also maintaining there independence and integrity because that is the key to scalability and value in traceability solutions.  And oh by the way- if the day comes that solutions reach this level of maturity- the ability to meet new regulations, even as complex as E-Pedigree, becomes a much simpler effort.

A Fear

The fear is quite simple- that history repeats itself.  That the industry turns it's back on serialization and decides to play out this scenario again in 4 years.   The fear is that interest in the concept is lost, people move on, knowledge dies, and solution's capabilities essentially remain stagnant.  If that in fact happens then passing a federal law giving people another 4 years really does nothing at all.  Again let's be honest- it's a very distinct possibility that I could write this exact same post in the Fall of 2017-2018 and it be just as relevant.   That would be unfortunate.   But there could be a unique difference 5 years from now.  It's highly likely that 5 years from now people will be buying everything from computers to mattresses to coffee and have the ability to see that specific product's entire history- from manufacturing to your doorstep. Think its far fetched?  For some companies its already a reality today.  So when that becomes the norm- even for consumer goods- can you imagine the reaction when people learn that a majority of our most life-saving drugs don't offer the same clarity?   Why must we reach the point that things have to be 'inexcusable' or 'inexplicable' before we do something about it?     

Should be a fun ride over the next month.....

Don't Slack on Your Serial Number Manager

In the early days of enterprise pharma serialization solutions the Serial Number Manager (SNM) component was somewhat of an after-thought.    SNMs were typically looked upon to provide ranges of sequential numbers with an ability to report which ranges were allocated to which locations.  The prevalence of GS1 standards pushed SNMs to have native support for GS1 SGTINs and SSCCs but little flexibility beyond that.  

As long as SNM didn't allocate duplicate numbers everybody was happy. 

As I've stated in the past the big issue I see with most pharma serialization solutions is they are so specific to GS1 and so specific to E-Pedigree.  As serialization implementations heat up, whether it be for the US or abroad, the industry may be in for a rude awakening.

International regulatory requirements for randomization (EU), non-GS1 support (China), and support of serialization pre- SNM have introduced use cases for Serial Number Managers that many solution providers are struggling to keep up with.

A few key requirements that I consider to be must-haves in any SNM:

• Must offer a non-pattern based Randomization option- Seems obvious but some leading providers don't utilize true randomization.

• Complete control over the length and composition of Serial Numbers - Again seems like an obvious ones but too often pharma's are settling for solutions that limit the ability to generate SNs of specific lengths or using specific character sets.

• Ability to assign SN configuration at a product level (i.e GTIN in the GS1 world)- Global pharma manufacturers need to assign different SN compositions at a product level to deal with regulatory differences across markets.   SNMs must also provide simple mechanisms to account for SNs that were allocated prior to SNM implementation, again at a product by product level.

• Support for Non- GS1 keys- Understand that an SGTIN and SSCC are just two types of Unique Identifiers (UIDs) that exist in this world.   SNMs must be rooted in the ability to generate UIDs of any format or structure so that when something other than SGTIN or SSCC is needed it’s a matter of simple configuration. 

Contact me to review if your Serial Number Manager passes the test.

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.