Tuesday, December 29, 2020

EPCIS woes continue.....

Another day…another woefully non-compliant EPCIS message supported by some of the ‘biggest’ players in the space.  Most will say  “Hey Scott, lighten up, it gets the job done so who cares if a few things here-and-there are not compliant”     

So as a year-end message I’ll get back on my soapbox again-   The reality is most of these ‘infractions’ (except the last one discussed below) likely don’t have a material impact on how the EPCIS communicates the necessary information from point A to point B….  the real risk/concern is this is yet again just one small example in an absolute ocean of examples where the industry is not just lax in its attempts to strictly adhere to EPCIS but is fully welcoming of it.

I’m not some private investigator with special tools that can detect these issues- I’ve praised/linked to the FREE tool that will reveal most of the issues below in a matter of seconds (https://epcisworkbench.gs1.org/ui/home)….so this can’t be about it being too hard to root out non-compliance…its simply that:

1) To this point, there hasn’t been an overwhelming reason to be air-tight on EPCIS compliance-   No EPCIS police to come around and stop product from flowing and not nearly enough interconnectivity across the industry for these issues to start causing bigger issues.

2) It’s hard to push back when some of the ‘biggest’ players in the space are the ones openly generating non-compliant EPCIS and/or willing to accept non-compliant EPCIS

Previously I’ve raised the notion of one simple way that non-compliance with EPCIS directly impacts the industry:

Take the last issue highlighted below.  Its black-and-white- both entries are simply not compliant.   But it’s happening out there in the wild (which by the way I would be interested to know if either the sending or receiving vendors are ‘certified’ by an EPCIS conformance testing service) which means the system generating this EPCIS was built in such a way that allows that to happen and, even worse, the system receiving these messages either A) didn’t catch these as issues and/or B) was built (and even possibly ‘enhanced’) to support receiving these messages.   The development it takes to support not only compliant EPCIS but now also the ocean of non-compliant EPCIS costs money.  And do you think the vendors just eat those costs?  Of course not, it goes back on the industry through increased annual fees or baked into some new ‘module’ that will be marketed.  

Now extrapolate that out over the massive number of ‘connections’ that have to be put in place by 2023 for the US market to achieve compliance.    If every vendor can go off and define what they feel is acceptable use of EPCIS then it’s the pharma industry who ultimately feels the pain.

In this space, 2021 will be the year of collaboration (or non-collaboration depending on how it plays out).   The technical issues below are likely viewed by many (not me) as minor, but what needs to be in focus is whether the industry maintains the mindset that’s been attached to EPCIS compliance…. There should be no ‘minor’ or ‘major’ non-compliance- it needs to be black-and-white… you’re either compliant or you’re not….and unfortunately, we are long past the point where non-compliant practices have become the norm.

I wrote a blog post nearly a year and a half ago that pondered whether EPCIS had lost its value as a standard within pharma serialization….  Instances such as below would seem to indicate nothing has really changed….and I still think we are just at the tip of the iceberg when it comes to understanding the impact that these seemingly insignificant and incredibly detailed ‘misses’ will have when trying to accomplish end to end traceability in pharma.

My last few posts have focused on the need for the industry to do a reality-check on whether we are moving forward with serialization/traceability in pharma in the best way possible.  Non-compliance with EPCIS is yet another reason why this reality check is needed.


Note: X’s are mine- used to preserve confidentiality

Thursday, November 12, 2020

Quick Thoughts on HDA's EPCIS Implementation Guidance....

Quick thoughts on the EPCIS implementation strategy released by the HDA in September... (https://www.hda.org/~/media/pdfs/government-affairs/position-statements/2020-09-29-getting-ready-for-epcis.ashx)

Few important highlights for me, with one being especially timely given my last post regarding the necessity for options centered around open governance industry networks.

Currently, EPCIS is the only internationally recognized standard that will meet these DSCSA requirements. 

Always good to to see the commitment to standards and specifically EPCIS.   Yet still amazing how many current connections across the industry (and even new connections continue to be established) which either do not use EPCIS or use a non-compliant EPCIS structure.

An additional complicating factor is that given the many supply chain entities that must meet the DSCSA’s 2023 requirements, competition for the services of the limited number of experts and consultants to advise on EPCIS execution will be keen. We anticipate a very high demand for this expertise -- potentially limiting trading partners’ ability to obtain the timely help they need just as they face the DSCSA’s critical deadline.  

Of course as a consultant myself I have to biasedly agree with this.     But, in my opinion, the real importance of this statement is not that I'm going to be busy the next 3 years, but rather what am I going to be busy doing?    My guess is most people read that paragraph and think "Yea think of all the connections that have to be set up between every manufacturer and their wholesalers and the wholesalers and pharmacy/hospitals.   Yikes that's a lot of work!!!"

And in fact that's exactly where the HDA guidance continues to....

At the outset, the bulk of this implementation will center on each manufacturer achieving successful EPCIS data exchange with each of its wholesale distributor trading partners. 

We encourage each pair of manufacturer and wholesale distributor trading partners to work together to establish a joint implementation plan for EPCIS execution that builds in adequate time for putting the necessary infrastructure in place, evaluating data quality, onboarding, testing, and stabilization.

And here is where my opinion starts to diverge...

The statement above sends a very clear message to the industry that we will follow the same path as we've been on for the past 10+ years...spending the dollars and resources to set up connections between each partner.   As I said in my last post- if that is the direction the industry chooses to go then c'est la vie.   I wish the guidance here wouldn't explicitly assume that's the best path forward....

My central point is-  We will have missed the boat again if we spend the next 3 years setting up integrations between each trading partner.   Those dollars and resource time should instead be allocated to deploying an open, industry governed collaborative network  (and no, despite whatever claims might be made, none of the traditional solutions/vendors fit this mold today).    Take the learnings from the last 10 years- recognize the good parts but also own up to the bad parts- and simply just look to improve over the next 3 years...staying on the same path isn't improvement....   As stated in my last post- that's the industry's call to action.....   

But there also is a call to action for solution providers.....   In HDA's defense, it would have been hard to even make reference to an open industry network in this guidance because, frankly, we havent heard nearly enough about them yet..... The messaging is starting, as we saw from the Linux Foundation announcement last month, but we need more info, more education and more tangible understanding of exactly how such a network operates and can meet the needs of 2023.... and we need all of that ASAP.

My view is, at a bare minimum, we at least owe ourselves the time/effort to more deeply consider the open network concept before assuming its not an option at all....So while I fully agree that it will take a lot of work to achieve 2023 compliance I hope that work is focused on the right efforts...

Wednesday, October 21, 2020

A must read article for anyone in pharma serialization/traceability...

Last night I came across a fantastic post by Robert Miller.  If you are not familiar with Robert's work, he has a great depth of knowledge and experience focused on the intersection of technology and healthcare.   In particular, many of Robert's recent articles have centered on healthcare (communication/collaboration) networks and the consideration (my interpretation: importance) that these networks are neutral and open.

Here is Robert's Newsletter:  https://bert.substack.com/

And the link to the specific article:  https://bert.substack.com/p/the-linux-foundations-open-governance

As is often the situation, when a subject matter (pharma serialization in this case) is evolved only by those who are uber-focused in that singular area it has the tendency to lose perspective of the bigger picture.   We often hear of the benefit to bringing in a 'fresh-set-of-eyes' to review a challenge and get new perspectives.    I think that is the critical point that pharma serialization is, and has been, at for some time now.   I am the first to admit that my blinders are often on when it comes to my work in this space- but fortunately there have been a few experiences over the past year which have made me recognize the value of 'new' voices entering into the mix.   This article is one of those experiences.

I've had the chance to speak with Robert in the past and discuss my impressions of how his articles so accurately describe both the big challenges ahead, but also some of the key missteps that (in my opinion) the industry has made with implementing serialization/traceability.   Robert will be the first to admit he has not been knee-deep in pharma serialization for years and years- and I cannot stress enough how GOOD that is.

So reading his article last night was once again a breath-of-fresh-air that I hope other folks like myself who have been knee-deep in this space will intently read.    In my opinion, the 'test' here is quite easy-  Read this article and form a clear Yes/No opinion on whether you think pharma serialization is on the path that Robert describes (and share your thoughts/opinion in the comments).  I'll provide my answer at the end of this post.

The goal here is to let Robert's article shine-  so the following are my favorite excerpts (bold/underline added by me for emphasis):

In several industries domain, like pharma supply chain traceability, there are many different networks all vying to become the network for the entire industry. Each of these networks is backed by a business that seeks to not only provide a solution to the immediate problem, like tracing prescription drug supply chains, as well as a more general platform for others to build on. But this structure poses two potential issues related to the neutrality of the business creating the platform.

[SP]: Fortunately, Robert uses our exact industry/use case as his example- and sets up the key premise for the article.....which is....

First, the end user of these platforms worry about being locked into using a single platform: without competition the platform creator may seek undue rents. Alternatively, the platform creator may pivot and shut their platform down, leaving users scrambling to find an alternative

[SP]: Three paragraphs in and, for me, he's already highlighted one of the most critical, yet also one of the most ignored, risks facing pharma serialization...   Take this statement in the context of a post I made a year ago on this topic-  "Consider the reality that some vendors are arbitrarily raising their annual fees year over year for no justifiable reason while customer’s feel ‘trapped’." (http://www.lifescienceserialization.com/2019/10/what-history-tells-us-about-why-future.html)

The vision of Open Governance Networks is that competing businesses will collaborate together on open source software instead of building distinct, competing, and proprietary platforms and networks....... Businesses could then build and sell proprietary applications on top of the open source core technology, and they would be able to deploy them to a ready-made network instead of standing up their own network. All of this allows businesses to focus on building applications instead of competing on creating platforms or convening networks.

Open Governance Networks would allow companies to focus on building value-adding apps instead of the underlying pipes.

In many cases platforms will need to be credibly neutral to gain adoption. 

[SP]: The article concludes with what I consider to be a slam-dunk- Simultaneously offering a vision for how pharma serialization/traceability should operate in the future while also providing a measuring stick for how well the industry has adopted this vision thus far.

Remember the 'test' I noted earlier? Read this article and form a clear Yes/No opinion on whether you think pharma serialization is on the path that Robert describes  

My answer-  A resounding No.  Why?   Think about the state of pharma serialization currently: 

  • Most participants largely locked into one, or a few, vendors.   
  • Emphasis still placed on achieving minimal compliance while disregarding long term implications.   
  • A misperception that the industry has somehow already achieved significant interconnectivity when in reality the industry is only scratching the surface in terms of exchanging data with partners.  
  • Many participants are literally unable to source complimentary/ancillary solutions from an open market because their primary enterprise serialization vendor either cannot support or will not allow integrations with 3rd party solutions    (Not sure what I mean by this one?  As a solution provider myself I see first-hand the true 'openness' of the enterprise serialization vendor landscape and happy to share my experiences)
  • We are operating in an environment where certain participants can exert significant influence over who their immediate partners should select as their serialization vendor- simply based on who they've 'connected' with in the past. (Think CMOs 'suggesting' vendors to their manufacturing customers)  That is absolutely bonkers- but it happens everyday and is simply proof that we are not operating in a open, standards-based, neutral-governance ecosystem.

I'm encouraged that at least one initiative (that I'm aware of) which could make a play in the pharma serialization/traceability space is involved with the Linux Foundation.  Having said that- the time is now for these initiatives to become more visible and start educating the industry.  That's the vendor's call-to-action.

What is the industry's call-to-action you might ask? As a very first step I think the industry needs to put a stake in the ground on this decision:  

  • Either continue down the path of proprietary and commercially-backed networks and accept the higher costs, lower competition and inflexibility that brings
  • Recognize the vision of open, neutral-governed platforms as laid out in Robert's article and start moving in that direction. Accept that the best chance to not only achieve serialization compliance but also actually realize other value opportunities on top of that comes by commoditizing the collaboration layer and opening up competition to those who can best extract value from the data.
Probability right now says the industry chooses Option #1 simply because it's the easy choice.   Either the industry can explicitly choose Option #1 or the industry makes no choice and Option #1 becomes reality by default. And if that's how it plays out then c'est la vie.

But if the industry takes a stand and genuinely wants to choose Option #2 then it cannot be done through words or endless roundtables/meetings or intent alone.  It must be through action.  Companies need to start taking positions, as we speak, to ensure their strategies and vendors/partners are aligned to Option #2.    And maybe here is the real true test-  for a large number of companies out there- manufacturers, CMOs, 3PLs, wholesalers and pharmacies- if you think your vendors are already aligned to Option #2, I'm sorry to be the bearer of bad news but in fact you just made the decision for Option #1.   

The industry has already spent so many years and so many millions (billions?) of dollars rolling out serialization/traceability- the presence of serialization 'fatigue' is real-  but to get anywhere close to the vision Robert lays out- now, maybe more than ever, is the critical time for the industry to get on the right path.

Tuesday, November 12, 2019

A few quick thoughts on the recent AmerisourceBergen letter covering 2020 serialization expectations...

Some quick thoughts on the recent AmerisourceBergen update letter covering 2020 serialization expectations…
  • ABC gives two options for meeting their saleable returns verification needs- maybe I’m reading too much into it but interesting to see the first option listed as EPCIS exchange and the second option as VRS.   Also, important to see that after the first option (EPCIS) is an “and/or”.    Why is this important?  If I’m a manufacturer I must recognize the scoping decision between putting focus on EPCIS data exchange vs VRS implementation.   For those who are already far down the VRS path this won't likely lead to a decision to scrap the concept all together- but this could have interesting impacts on those who are just now evaluating serialization vendors and are being presented with a hefty VRS price tag.   It’s important to re-iterate that, for some manufacturers, having EPCIS data exchange in place could alleviate the need for VRS (if you even need VRS in the first place-  See http://www.lifescienceserialization.com/2019/04/do-i-or-do-i-not-need-vrs.html)
  • “For those planning on sending serialized data, which implies that you are aggregating and your 3PL or distribution center can send EPCIS data….”  This is a seemingly straight forward comment, but it still gets confused often.  Certain serialization L4/L5 vendors have pushed a very bad (meaning risky) process of generating ‘shipping’ events with non-aggregated items. (Reach out if you’d like to learn why this is a risky process).  With more pressure to provide downstream EPCIS data exchange many manufacturers will recognize that just because their vendor generates shipping events doesn’t mean they're covered for EPCIS data exchange.  Unless you are fully aggregating you are better off not implementing data exchange with distribution/3PL, and therefore, with downstream customers, however, as this letter indicates the beginning-of-the-end for no aggregation is here.
  • "AmerisourceBergen is onboarding and testing now – and we must start receiving production data, via EPCIS 1.1 or 1.2 by May 1, 2020”    The time to get your EPCIS exchange capabilities in place is right now.  This raises interesting considerations for companies who are evaluating serialization vendors for the first time (or looking to switch). Up until this point emphasis was so often placed on picking vendors that could seemingly facilitate the ‘easiest’ integration with packaging sites/CMOs- now the equation must include who can best integrate with distribution/3PL and downstream customers- and that’s a very different equation.  Make sure to ask vendors for their experience integrating downstream data exchanges (using EPCIS) and make sure your vendors are in good standing with the distribution/wholesaler segment in general. (….but don’t worry most vendors are in good standing, it’s not like anyone went off and sued organizations in that segment of the industry….oh wait )
  • ...and on the topic of vendors… ABC urges manufacturers to consider their VRS provider- SAP ICH leveraging MediLedger.   Two key points here:  First, the very nature of VRS is that all providers must be interoperable- otherwise this doesn’t work for anyone.    However, we’ve already seen an enforcement delay and at least one of the reasons for that delay was due to inadequate progress (meaning vendors solutions not always working) when it comes to interoperability.  As such there is an argument that a ‘safe’ choice could be to select providers who are leveraging the MediLedger network.  The second key point is look more broadly then just ABC.   Across the Big 3 wholesalers a common characteristic is that all of them are using and/or piloting a VRS provider that leverages the MediLedger network.  (Note:  The decision to leverage MediLedger for VRS doesn’t mean you have to select SAP as your provider.  There are many VRS providers out there leveraging MediLedger)
  • Finally, ABC outlines their expectations for companies who do decide to initiate VRS testing and, ultimately, production use ahead of the now Nov 2020 deadline.   ABC recommends, smartly so, that manufacturers manage their use of VRS by uploading product GTINs into the lookup directory only when those products are ready to receive verification requests.    Second, and most importantly, ABC states “We will treat any negative verification responses as potentially suspect and quarantine and investigate per our internal procedures.”     This couldn’t be more clear- if you are a manufacturer and decide to turn on your VRS services, then any failed verification responses you provide must be handled through DSCSA-defined suspect and illegitimate product handling processes which (I’m a broken record on this point) are processes that all manufacturers must have in place today.  Make sure your suspect and illegitimate systems/processes are in place to handle the inevitable spike in failed verification requests that will occur as VRS use ramps up (https://www.jennason.com/dvm)

Wednesday, October 2, 2019

What history tells us about why the future of pharma serialization solutions hinges on the question of open vs closed

One of the most widely referenced examples of new technology adoption is the classic tale of VHS vs Betamax.  In the 1970’s and 80’s a ‘war’ was being waged as to who would dominate the home video recording space.  Two primary technologies emerged- VHS and Betamax- but only one would survive as the defacto ‘standard’.  In many ways the VHS vs Beta example shows the importance (and potential outcomes) when ‘open’ and ‘closed’ systems compete- and interestingly has some very strong parallels to the current state of pharma serialization solutions.

Let’s briefly look a little deeper into the VHS vs Beta battle.  Credit goes to two editorials on this topic (¹:https://www.everything80spodcast.com/vhs-vs-beta/ and ²:https://www.netquest.com/blog/en/blog/en/legendary-products-vhs-vs-beta)

In the mid 1970’s the Betamax format dominated the emerging video recording space through its use in professional studios and other commercial applications.  When time came to adapt this technology for home consumer use, competition arose.  Shortly after Betamax another recording format emerged known as VHS.  VHS was viewed as having inferior picture quality but took a drastically different approach when considering its market positioning.  The creator of VHS, JVC, outlined the following: ¹
  • The system must be compatible with any ordinary television set.
  • Tapes must be interchangeable between machines.
  • The overall system should be versatile, meaning it can be scaled and expanded, such as connecting a video camera, or dub between two recorders.
  • Recorders should be affordable, easy to operate and have low maintenance costs.
  • Recorders must be capable of being produced in high volume, their parts must be interchangeable, and they must be easy to service.
Additionally, JVC set out a strategy to license the VHS format to any interested manufacturer. “JVC preferred to sacrifice the profits of licensing their VHS technology for the sake of instituting a dominating standard. In 1984, only 12 companies supported the Betamax format compared to the 40 manufacturers that supported VHS.” ²

In short, JVC set out on a path of ‘openness’, compatibility and adoptability.

Meanwhile, the creators of Beta maintained a ‘closed’ position.  They relied more on marketing efforts rather than recognizing the desires of the market (e.g. longer recording times, lower cost) and most importantly they kept licensing extremely restrictive and expensive. ²

It’s important to note that the creator of Beta was a little-known-company called Sony.  Sony bet on its perceived market position to drive adoption of the Beta standard- so much so that “There [had] always been this idea that Beta was vastly superior [to VHS]… but when you look back at the technical details of two average machines they ended up being almost identical. A big reason for this idea was as much due to [Beta] being marketed that way by Sony. People began to just buy into it… Sony actually could have controlled the whole industry but their attempt to dictate the industry standard backfired.” ¹

So how does this relate to pharma serialization solutions? Those who have been in this space, working with serialization vendors, will immediately recognize the many parallels between the VHS vs Beta story and the current landscape of serialization providers.  And in my opinion, some of the parallels are almost eerily on-point. 

As such the question of open vs closed should be top-of-mind as the industry marches towards DSCSA 2023 and other global requirements which will demand greater interoperability. Companies who have been down the serialization road for many years as well as those that are just now starting their serialization journey have some new things to consider when evaluating their solution options.

First let’s provide some context into what ‘open’ means in pharma serialization.    Open does NOT simply mean open-source software nor does open mean unsecured, unobstructed access to data.  My view of ‘open’ means two key things:

  1. The industry recognizes the advantages of normalizing (e.g. standardizing) and centralizing (albeit through de-centralized technologies) end-to-end serialization/traceability data in an industry-wide data platform- which is owned collectively by the industry and not any single for-profit entity
  2. The industry promotes, and quite frankly demands, permissioned access to this data be given to any viable provider-  which in turn fosters a competitive landscape that rewards solutions based on their ability to deliver value from the data. 
Of course, these are not new concepts by any means.   These are concepts- easily identifiable by the existence of solution ‘marketplaces’- that have already been proven in other industries and by other solution landscapes (See: Google, Amazon, Salesforce among many, many others).

But let’s consider these points in the context of today’s pharma serialization space- despite any and all marketing claims- hopefully most of you would agree that the current tangled-web of serialization data exchange deployed between largely ‘closed’ systems is not sustainable for 2023 and beyond.  Moreover, the current landscape of solutions certainly does not adhere to the characteristics of ‘openness’ noted above.  The industry, however, has managed to get by largely due to the fact there has not yet been a need/requirement which demands such broadscale interoperability.  (Remember: as I’ve noted in past posts- there are many manufacturers who are fully compliant with DSCSA today and are doing nothing more than physically serializing items and then holding on to the data- no significant data exchange or interoperability is required)

Simply put the current approach won’t work for 2023 and quite frankly the industry shouldn’t want the current approach to work.  Continuing to build upon what’s been done to date (I’m a broken record in saying this) will only lead to unnecessarily higher fees, even less flexibility and lower potential for additional value creation.  Consider the reality that some vendors are arbitrarily raising their annual fees year over year for no justifiable reason while customer’s feel ‘trapped’.  That’s a scary proposition if it were to continue to play out over the next 5/10/15 years.

But there is some reason for optimism-  as I’ve noted before there are efforts underway, whether as part of FDA pilots and otherwise, that are evaluating and demonstrating other approaches to traceability.  And likely for the first time we have providers that have the scale to drive such disruptive change.   Be it SAP/MediLedger’s collaboration or IBM’s re-emergence in this space (and I’m sure other providers as well- before I get the nasty-grams), the common thread is these efforts are centered on concepts rooted in openness.  Now of course commercial interests will always be in play, so I’m certainly not insinuating that SAP or IBM (or anyone else) are taking on these efforts out of the pure goodness of their hearts.  Their approaches must represent something noticeably different than what we’ve seen from vendors to this point- restating again- the focus must shift from building a business model based on simply owning/maintaining/exchanging data to one that can justify its value based on what it does with the data.

For me the most fascinating part of the next 12 months will be watching which vendors give signals of ‘openness’ and which vendors give signals of staying ‘closed’.   There are very clearly vendors who have already obtained a perception of being ‘closed’ through their promotion of alternative ‘standards’, limitation of 3rd party integrations and inflexibility to cater to customer’s specific needs (I see you Betamax).  It will be fascinating because, in fact, the marketing blitz has already started- and many of the attempts at showing 'openness' have in fact made clear these vendors will very much stay 'closed'.   I have a unique perspective in this area because in addition to supporting pharma's through their serialization journey I am also a solution provider- one that specifically provides solutions that are designed to be complimentary to the traditional enterprise serialization platforms- so quite literally on a daily basis I am engaging serialization vendors to understand their position on 'open' integrations.

So let me offer some thoughts on the marketing perception vs reality-   offering a 'platform' component does not automatically qualify one as an 'open' solution.  In fact there is quite a big divide between over-using typical buzzwords that portray 'openness' and actually demonstrating it.  The real test comes in proving ones support for fostering collaboration with any provider- be it a close partner or the fiercest competitor.  That's the true test that pharma companies need to pay attention to- because that's the signal of whether their vendor's approach is in the best interest of the industry or solely the best commercial interest for themselves.

I look forward to continued engagement with vendors on pursuing truly 'open' integrations.

If by-and-large the industry agrees that ‘openness’ at the core is the only sustainable method for 2023 compliance and beyond than many companies have some serious thinking to do about the future of their serialization solutions.

And if you’re a pharma at the start of your journey, especially if your timelines and/or scope allow you to consider one of the now many alternative solutions to meeting serialization compliance- why not see how things play out over the next few months as the FDA pilots complete and other initiatives pick up steam?  

Best to make strategic decisions based on where the collective industry is going rather than where it’s been.

Wednesday, June 12, 2019

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.

Thursday, April 11, 2019

Do I or do I not need VRS?

Predictably after the Nov 2018 DSCSA serialization milestone passed serialization vendors needed to find their next marketable offering.   Enter VRS.

The result has been a flood of marketing materials highlighting the advantages and/or readiness of  one VRS service over another.  In turn this has resulted in pharma manufacturers raising questions to me about how best to approach their "VRS requirements".

My immediate response to that question is-  "Are you sure you need a VRS?"

The purpose of this post is to clarify what is required under DSCSA as it relates to verifications and the role VRS plays in meeting those requirements in certain scenarios.   My hope is to help some manufacturers avoid being 'sold' a new solution feature by their provider when its actually not necessary to meet their requirements.  Moreover, I hope to make clear that by simply signing up for a VRS a manufacturer doesn't magically meet all the verification/suspect/illegitimate product handling requirements under DSCSA.

First let's define what DSCSA says about verifications and the upcoming milestone in the regulation that is making this such a hot topic.

Come November of this year wholesalers will be required to perform a verification of any returned  items which they hope to resell. (e.g. saleable returns).    To meet this requirement wholesalers will be reliant on manufacturers to provide the data necessary to decide if the item is 'verified'.    There are generally two ways to achieve this:  Either the manufacturers share their serialization/traceability data (e.g. EPCIS) downstream with the wholesalers or the manufacturers respond to a verification request.

Since many manufacturers are far away from being able to provide serialized/aggregated data to their downstream partners, the focus has largely turned to responding to verification requests.

For manufacturers, the ability to respond to verification requests is nothing new- in fact- the ability to respond to certain verification requests for non-serialized items has been in place since the first milestones of DSCSA went live.   And as of last November, manufacturers are required to respond to verification requests for serialized items.

Most importantly, nowhere in DSCSA does it state that in order to meet the verification requirements one must leverage VRS. While DSCSA does define the timelines for when each segment of the supply chain must be able to respond to verification requests, it does not define how those verification requests may be made nor does it define how the responses must be provided.

Point being, the industry could meet DSCSA verification requirements by leveraging phone calls, emails and carrier pigeons if it wanted to.

But alas, the industry, largely driven by the big wholesalers, recognized the absolute efficiency nightmare such non-automated approaches would have on their operations.  In response VRS was born- a way to systematically submit verification requests to a manufacturer and rapidly receive a response.  VRS meets DSCSA requirements for saleable returns verifications and saves big wholesaler's operational efficiency-  happy days.

But what happens if I'm a small manufacturer who only sells to small specialty wholesalers or skips wholesalers altogether and sells direct to pharmacies... do I need VRS?  The answer is possibly (and probably) no you don't.    It all comes down to your customers because VRS is not a DSCSA requirement, it's a US pharma industry requirement if you do business with customers who require you have a VRS capability in order to ship product to them.

So, if you are unsure the next step is to talk to your customers.  Ask them their plans for meeting the Nov 2019 wholesaler salable returns requirements. Ask them if they will be requiring their suppliers (i.e. you) to leverage VRS.  You might find many of your customers are not even planning to use VRS.  You might find instead they prefer to receive the EPCIS data for the items you ship them (which means aggregation and ensuring your L4/5 system can adequately handle such downstream exchange becomes your top priority).  Or you might find they are perfectly fine relying on emails/phone calls/carrier pigeons as the volumes of saleable returns verifications is anticipated to be quite low.

If none of your customers say they will require VRS then, for the present time, you are safe not having a VRS capability.   What you must do however, no matter what your customers say, is ensure you have the proper processes in place to respond to verification requests and further have the processes to handle suspect/illegitimate product.  (See https://www.jennason.com/dvm)

But if you do have customers that expect/require you to have a VRS capability then shop around.  The very nature of VRS requires it be inter-operable- meaning it doesn't matter who your customer's VRS provider is or your neighbors VRS provider- you can choose whomever you like.  Go with your current provider's VRS feature if you don't want the headache of introducing a new vendor.   Or if you think your vendor is charging an astronomical amount for the service there are plenty of offerings out there that will layer on top of your existing providers system. (but be prepared its not a 'flip of the switch' if you go that route)

As always my message to manufacturers is- maintain oversight of your serialization program, and in the case of VRS-
A) Don't let your vendor simply sell you on a feature that may not be needed
B) Recognize that VRS covers the ability to respond to saleable returns verification requests - it does not satisfy your legal requirements of having processes and systems in place to respond to all types of verification requests and, moreover, it does not satisfy your legal requirements of having the processes and systems in place for handling suspect and illegitimate products.

Popular Posts