A Tipping Point for EPCIS?

When I started my career in serialization some 11 years ago I was fortunate to be under the guidance of a forward-thinking Accenture executive, Paul Schmidt, who impressed two key concepts on me:

• As an early member of the GS1 working group developing EPCIS Paul would ensure our early serialization projects were understanding of the vision, positioning and importance of standards.
• To always strive for capturing ALL the data.  Regardless of the minimum requirements set by the regulations at the time, Paul would always set the bar higher, recognizing- even 11 years ago- the value that such data could provide above and beyond compliance.

I’ve stuck to these two principals throughout the years, even when they were not always adopted as part of my client’s strategies.

But when it comes to the use of standards, specifically EPCIS, I continue to be surprised- on two different fronts.

First, I am amazed by the unbelievable lack of education around EPCIS that exists broadly across the industry.  Selfishly I can count on one hand the number of people I trust with detailed EPCIS questions. 

Second, I am amazed by how much the industry doesn’t care about a strict adherence to standards.  I’ve commented before that in some cases it’s not entirely the industry’s fault- as many serialization implementations have been delivered by vendors without the customers even knowing it isn’t based on standards.   In other scenarios, however, the industry is not off the hook.   Think about what we are all trying to do here-  interconnect an ever-growing, ever-changing landscape of systems and processes- to support the ability to track items.   The very nature of ‘supply chain’ requires that all parties, at the foundational level, can speak the same language.  I realize saying the industry ‘doesn’t care’ might be a bit blunt-  but prove to me otherwise.  I certainly know there are instances where companies have adopted the ‘right’ approach to serialization- basing it off standards and the understanding the importance of fully integrating serialization into day-to-day operations.  Generally speaking, however, my experience has been that as long as “it works”, that’s all that matters to most in the industry.

Largely because of these two points a vacuum was created in pharma serialization that vendors took advantage of.   In some cases, EPCIS ‘support’ was delivered improperly out of sheer ignorance, but no one on the pharma side was any-the-wiser to push back.   In other cases,  vendors employed an intentional business strategy to not support EPCIS- understanding, as I’ve stated in previous posts, that standards are bad for business.  If every system can easily and efficiently talk to every other system then there is less barrier preventing customers from moving to a different vendor.

So, the result today is an absolute mess of integrations, often using proprietary message structures that were designed for one use case but are now shoehorned into expanding needs.   You have ‘EPCIS’ integrations as well, but (in my estimation) very few that would meet every measure of compliance with the standard.  It’s somewhat ironic (yet probably shouldn’t be) that the purest EPCIS implementation offered today is open-source and completely free.

I’ve experienced, and written past posts about, some of the worst abuses of EPCIS being pushed by vendors who will defend the practices till the end.    We had the complete misuse of GLNs/SGLNs (http://www.lifescienceserialization.com/2018/02/important-public-service-announcement.html) and  we had the practice of misrepresenting ship/sold from and to values (http://www.lifescienceserialization.com/2018/11/a-new-normal.html).   Other common abuses include replicating EPC data two or even three times in a single event as well as bloating EPCIS events with completely unnecessary and unneeded product/location master data and transactional data.   Reach out to me if you are struggling with any of these issues- happy to expand further.

In the last few weeks however I came across what is, in my opinion, the most egregious abuse of EPCIS I’ve seen to date.  So much so, that I consider it to be a tipping point for EPCIS in the industry.  If the industry and standards organizations, to the degree they can, don’t push back on these practices it threatens to render EPCIS irrelevant- not because of the standard itself, but because the implementation of the standard has gone unchecked for so long and has reached such an unrecoverable point that it no longer can be considered a ‘standard’ in pharma serialization.

A summary of the issue:

A large track and trace vendor has implemented a new version of their ‘EPCIS’ message which is sent when a batch is finished at a packaging site/CMO.  The message contains the commissioning events generated and at the very end is an event that looks something like this:   

For folks experienced in this space, a quick review can identify what’s going on here.  The vendor was looking for a way to indicate a batch was finished, and to do so, decided an EPCIS event was the best way to do that.  Never mind the event itself does not comply with the EPCIS standard for numerous reasons (and don’t take my word for it- use the free tool found at http://www.vizworkbench.com which will spell out the non-compliant items), the frightening fact is the vendor believed EPCIS was the best way to handle this need and/or truly believes that their implementation of EPCIS is compliant.  But what might be even MORE frightening is how many other L4/L5 vendors will build out support for this practice.  And thus, the potential tipping point- when you have this type of clearly incorrect practice proliferate to where it becomes accepted within the industry the standard loses its value.

Can GS1 do anything about this?  For my part I sent this off to folks I know and trust at GS1 as soon as I discovered it.  No response thus far.  When communicating to GS1 my suggestion was clear-  there obviously isnt a ‘GS1 Police’ that can enforce the standard as such- but GS1 (and its testing partners) can show they are paying attention by not extending compliance certification to these vendors.  I raised this point when GS1 US first announced its most recent compliance testing service.  

Any vendor can pass compliance tests when done in isolation, what would be more useful is if these certifications look at actual implementations for occurrences of misuse such as above.

I eagerly await GS1's response on the matter.

And I eagerly await the industry’s response as well.  I find it almost comical to be commenting on such fundamental components of any serialization implementation, while at the same time there are conferences going on around the world hyping the future of the pharma supply chain.  At some point people will have to start asking the question (or begin feeling the pain for themselves)- can I really expect to expand my scope of serialization/ traceability and start reaping all the promised ‘beyond compliance’ benefits if my vendor (and more broadly the industry) can’t even deliver the most basic data concepts?  

My unsolicited suggestions:

• L4/L5 vendors- don’t build out support for the issue noted above.  It’s a rabbit hole we can’t go down any further.
• Pharma industry- First and foremost understand if/when your vendor pushes back on supporting this approach.  But more broadly, recognize that the only way to start realizing further value from serialization begins with the data and the ability for the whole industry to efficiently exchange this data.  You can not expect all serialization vendors to sit in a room and decide to play nicely with each other when commercial interests are at stake.  Without direction from the industry clearly positioning standards like EPCIS as the unequivocal, de facto norm AND without oversight from the industry to ensure EPCIS is being implemented properly we will continue down a path towards even more inefficient data exchange.  The result of that will be higher fees paid by the industry and ultimately the vision for digital supply chain traceability will remain out of reach.