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 ( and  we had the practice of misrepresenting ship/sold from and to values (   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 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

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.

Wednesday, February 6, 2019

VRS is critical.... but don't ignore the other (and more significant) verification requirements under DSCSA (Marketing Material)

Under DSCSA all segments of the pharmaceutical supply chain are required to have systems/processes which manage requests for product verifications.   For manufacturer’s all DSCSA provisions related to product verifications are live today, meaning not only are manufacturers responsible for meeting the law, but also that the FDA and other agencies may audit these systems/processes.   Such audits have already resulted in 483s (

Much attention has been placed recently on the ability for manufacturers to handle saleable returns verifications in advance of the Nov 2019 deadline for wholesalers. While saleable returns and related solutions (VRS) address direct compliance requirements of DSCSA, it is critical for all segments of the pharma supply chain to recognize that the ability to handle saleable returns verification is only one small piece of DSCSA verification management.

Jennason performed a thorough review of verification requirements under DSCSA and related guidance’s and identified the following:
  • There are no less than 6 high level quality and regulatory policies which must be developed and/or integrated into existing SOPs.  These polices must cover critical procedures including the handling of verification requests,  FDA requests for information, suspect and illegitimate product handling and trading partner and FDA notifications
  • In total the 6 high level policies must define no less than 25 DSCSA required tasks, data capture points, notifications and record retention activities.
  • The overwhelming majority of these required tasks/activities are performed outside of your serialization system.  In most cases, your serialization system will only address the requirement to perform product identifier verifications.
  • Many verification requirements have strict timing for when responses must be returned to the requestor- often within 24 to 48 hours.
  • Verification requirements impact a broad set of functional teams within an organization including, at a minimum, quality, regulatory, supply chain, manufacturing/distribution operations, R&D/testing and legal.
DSCSA Verification Workflow Map
Blurred for confidentiality. 
Reach out to Jennason for a full review

In response to these complex requirements Jennason developed a suite of offerings to help companies understand their total exposure to DSCSA verifications and ensure proper capabilities are in place.

DSCSA Verifications Workshop-  A half day workshop designed to educate internal teams on the full extent of DSCSA verification requirements.  The workshop also facilitates a gap analysis between current quality/regulatory processes impacted by DSCSA verification requirements and desired future state.  Participants are also given a demonstration of the Jennason DSCSA Verifications Manager.

Jennason DSCSA Verifications Manager.   DSCSA Verifications Manager provides an automated workflow solution which ensures companies are completing all required steps in a DSCSA verification process including
  • Managing requests for verification from/for trading partners, FDA and saleable returns.
  • Capturing verification results and generating response reports to provide to requestors.
  • Managing the required suspect product process including quarantine and product investigation.
  • Managing the required illegitimate product process including quarantine, sampling and disposition.
  • Automated generation of required FDA forms (3911) and trading partner notifications.
  • Automated e-mail reminders to ensure verification responses are provided within the required 24hr time period.
  • Reporting dashboard which tracks frequency of verification requests, breakdown of requests by product, lot and other attributes and measuring of on-time verification response performance.

More information can be found at

Jennason Serialization Test Tool.   Jennason’s industry-leading automated testing solution for L3/L4/L5 serialization systems supports DSCSA product identifier verification testing.  Every serialization system has different parameters by which product identifier verification is performed.   To understand how your system operates its critical to test the product identifier verification process with items in a variety of statuses and locations.  Pharma companies leverage the Serialization Test Tool to simulate common serialization use cases, such as commissioning, aggregating, shipping/receiving and end-of-life (e.g. decommissioning, destroying), generate the corresponding test data and communicate that data to their L3/L4/L5 serialization system.  This enables the rapid testing of your system’s product identifier verification process under any business scenario.

More information can be found at

Contact Jennason today for more information on these offerings.

Wednesday, January 30, 2019

Is there an inherent risk in DSCSA’s approach to verifications?

A constant battle which has waged since the beginning of serialization regulations in pharma is the notion of “Spirit of the Law” vs “Letter of the Law”.  In the case of DSCSA companies have, undoubtedly, aligned their strategy and implementations on the “Letter of the Law” more-often-than-not.

If the law doesn’t say I have to aggregate- I’m not aggregating. 

If the law doesn’t say I have to randomize serial numbers- I’m using sequential.   

Which brings us to our next “Spirit” vs “Letter” debate- how to support verifications under DSCSA.  Verifications are an intriguing component because while so much focus has been on what has to be done for DSCSA- generating serial numbers, printing barcodes on products, capturing data- verifications are really the industry’s first foray into actually using DSCSA.

Let me start by providing what I think the “Spirit” and “Letter” of verifications are under DSCSA

Members of the pharma supply chain, the FDA and ultimately patients themselves should gain value from the presence of a unique identifier (and other associated data) on their prescription drugs and subsequently should have tools to use that data to request feedback whether, to the greatest degree of certainty feasible, the unique identifier is legitimate or not.   

Of course, even the purest supporters of serialization/traceability must recognize that a unique identifier (and associated data) alone can never be trusted to say with 100% certainty whether a product is legitimate or not.  The only way to truly verify a product is with scientific testing or other evaluation of the product itself (Thanks John Keogh).

But in the “Spirit” of verifications under DSCSA the industry should strive to put in place processes and systems that use all information available to them to provide the most accurate verification responses possible.  Verifications are, after all, at the heart of why DSCSA even exists.  If we are not making every effort to ensure verifications provide value (e.g. accurate responses) then in fact DSCSA may actually hinder product security by forcing a unique identifier onto items that can be easily exploited by counterfeiters.

Under DSCSA, the term “`verification' or `verify' means determining whether the product identifier affixed to, or imprinted upon, a package or homogeneous case corresponds to the standardized numerical identifier or lot number and expiration date assigned to the product by the manufacturer or the repackager, as applicable in accordance with section 582.”

In the simplest terms, DSCSA requires that when presented with a product identifier (GTIN, SN, Lot, Expiry) someone or some system must provide a response whether those data values match with the values assigned to a product that is, to the best of their knowledge, still a valid product.   Any burden of proof as to how the verification response was determined is entirely on the industry and individual vendors to define.

For most companies the required product identifier verification will be done by their serialization systems.  Thus, in functional terms, serialization systems have some procedure that can take in a product identifier, do some checks, and spit out a response.  

At that point every company will have to decide for themselves whether the product identifier check, the only one required by DSCSA, is the only check that will be performed.    

History says most pharma companies will take that approach and proof of that is already apparent with the rapid adoption of VRS.  VRS was built to support the needs of large wholesalers who have to deal with the highest volumes of saleable returns, which now under DSCSA must be verified before they can be sold again. VRS itself is a great accomplishment, building a standards-based approach which facilitates the routing and communication of verification requests and responses- all done in a matter of seconds. However, that alone tells me all I need to know- the industry is rallying around the “Letter of the Law”- do the product identifier verification, provide a response quickly and move on.

But even when inclined to follow the “Letter of the Law” companies must surely recognize that the product identifier verification, which will often be the only check done, has a tremendous amount of importance and responsibility placed on it, right?    And serialization vendors, recognizing the same criticality and importance, must be investing significant R&D and leveraging advanced algorithms and technologies like AI to ensure the most accurate verification responses are provided, right?   (Do you sense my sarcasm?)

Here’s where things get intriguing- take a poll of the 5 major serialization system vendors and ask them how, systematically, they verify a product identifier?  You’re likely to get 5 different answers.

That alone is cause for concern-but again doesn’t mean any one vendor is more-or-less compliant under DSCSA.  More intriguing is to dig deeper and question how robust are these ‘checks’ being done by the serialization systems to determine if a product identifier is verified or not?

Unfortunately, serialization vendors have never been a model of transparency when it comes to demonstrating how their platforms work, but nonetheless, I welcome all vendors to state their position on how they perform verifications. (and actually show it working).  I hope I get some replies!!

Given my experience with serialization implementations here is what I would *hope* is a feasible set of checks which serialization systems use to verify a product identifier.   To be clear, I am a “Spirit of the Law” guy so I don’t consider the checks below to necessarily be adequate, I simply think this is a feasible set given the maturity of serialization implementations/systems I’ve seen to date.  At the same time, I also know some serialization systems are not capable of these checks.
  • Unique identifier (SGTIN) must be commissioned and associated to the corresponding lot and expiry
  • Unique identifier must not have reached an ‘end-of-life’ (e.g. decommission, destroyed, etc.)
  • Unique identifier must not be associated to a lot or itself directly marked in any status which should prevent further distribution (e.g. quarantine, recall, suspect)
  • If verification request is from a trading partner, unique identifier must have been shipped and associated to a DSCSA transaction

I was fortunate to gain experience with a solution provider who had in-depth serialization and authentication solutions in use by companies outside of pharma who leveraged the tools for brand protection purposes.  What I can say with the utmost confidence is if those companies were presented a solution that used the criteria noted above, they would swiftly dismiss it- identifying it as an inadequate solution.  The reason being is such a set of criteria would result in more false positives than acceptable within their margin of error- meaning it would too often provide ‘verified’ responses when in fact the item was not legitimate.   

In fact, the authentication solutions used outside of pharma leveraged no less than a dozen different rules and data checks to determine, with the highest degree of certainty feasible, whether the unique identifier was legitimate.  Beyond the surface checks noted above, true authentication systems consider other factors such as request source, frequency and dispersion of requests over time, evaluation of traceability history relative to expected supply paths and, in some cases, even automated visual packaging inspections.

So, if these types of solutions exist and are used outside of pharma- in industries which have no regulatory requirements- why should the bar be set any lower in pharma?  Ah yes…. “Spirit of the law” vs “Letter of the Law”.

Now let’s address the risk that pharma companies face.  I certainly would not want to be the serialization lead at a manufacturer who is getting questioned why items, which ended up harming patients, were given the ‘thumbs up’ by their serialization system’s verification response.  If anything, I would want my systems to error on the side of caution- offering any number of false negatives over even a single false positive.  Of course, that’s the last thing wholesalers want to hear- as a spike in failed verifications means a major hit to their efficiency.  But back to the original point- “Spirit” vs “Letter”- is DSCSA in place to make sure the industry’s efficiency stays in tact or is it to protect patients?  So much focus has been on VRS and the battle between who’s VRS solution is better/faster/more widely used- but who’s paying attention to the actual content of the verification responses that will be flying all over the place- and more importantly the significant impact those verification responses have on the downstream flow of legitimate and illegitimate product.

Outside of the DSCSA text itself, guidance from other key organizations clearly indicates that the product identifier check is only one of the checks that should be done.  Over 2 years ago the FDA put out a guidance entitled “Identification of Suspect Product and Notification” (Link) which explicitly laid out several additional checks that should be done in order to determine if a product is suspect or not. (product sourcing, current supply/demand, visual appearance).  More recently GS1’s Verification Messaging standard (Link) did its best to ensure they are not liable for verification responses by stating “It should be noted that verification of product identifiers is only one element of ensuring security of products; further checks may involve physical inspection of the product and its packaging, including the integrity of any tamper-evident seals.”

So, you have some key organizations saying, “Yea the law requires you verify the product identifier but you reaaallly should do these other basic checks as well”.   Where will the industry fall?  “Spirit of the Law” vs “Letter of the Law”?

As always, maintain oversight of your serialization/traceability programs and ensure your implementation meets DSCSA verification requirements.   Challenge your vendors to provide hard evidence of how their systems are performing DSCSA verifications.   Manufacturers are now solely responsible for the verification responses they provide.

Jennason has the experience and solution offerings to help.  In addition to evaluating and testing serialization platform’s verification capabilities, Jennason also offers the DSCSA Verification Manager- a workflow solution ensuring companies complete all required verification tasks, retain required verification records and generate required FDA and trading partner notifications.  To Learn more, click here.

Sunday, January 13, 2019

What to Expect in 2019 (Caution: Marketing Material Ahead)

I hope everyone had a great holiday season and found time to spend with family and friends.   I am looking forward to a great 2019.

Towards that end I wanted to offer a few of my own personal insights for the pharma serialization space in 2019 followed by an update on new consulting, solution and service offerings from Jennason.

Predictions for pharma serialization in 2019

With the Nov 2018 DSCSA serialization milestone having passed the industry is in a unique position.   As more and more companies enter a fully serialized world, we will experience the first true test of how well implementations are performing.   

Some bumps have already been experienced- the question is whether it will become a trend?

Some bold predictions for 2019
1.    As the industry starts to tackle aggregation and integration with distribution/3PL operations (on a mass scale) the robustness of enterprise serialization platforms will be tested- and many will recognize their solutions are not up to par.
2.    The major players in the enterprise serialization space will see some shakeup-   with both current players losing steam and new players entering the mix
3.    The progression towards "value beyond compliance" will be slowed by efforts to resolve issues with current implementations

Jennason Consulting in 2019

As always Jennason continues to provide the pharmaceutical industry with expert consulting support and purpose-built solutions based on over 10 years of serialization and commercial supply chain experience.  

At the end of 2018 Jennason consulting engagements could generally be put into 3 categories:  
1.    Emerging biotech/pharma manufacturers looking to launch products in the next 12-24 months and needing to be serialization compliant.
2.    Manufacturers who have had an ongoing serialization project/program for 1+ years but need additional support to resolve vendor issues to ensure compliance with DSCSA is achieved.
3.    Manufacturers with an interest to extract further value out of their serialization investments- but to do so first need an assessment on the current state of their implementations.

Jennason looks forward to an intriguing 2019- the consistent goal remains the same- making sure pharmas are educated on serialization/traceability/compliance while promoting proper use of GS1 standards to ensure best, long-term implementations.

New/Updated Solution Offerings

Jennason Master Data and Workflow Manager- As a company's commercial supply chain demands grow so too does the importance of master data management.   The Jennason MD&W Manager provides a cost-effective and robust alternative to spreadsheets and manual processes.  More information

Jennason DSCSA Verification Manager- Last fall the FDA released guidance for Verification Systems under DSCSA.    The Jennason DSCSA Verification Manager provides a workflow for companies to ensure compliance with all required tasks (verification, quarantine, investigations) as well as manages required FDA and trading partner notifications.  More Information

EU FMD EMVO Gateway Translation Tool - Built in collaboration with Be4ward Consulting, the EMVO Gateway Translation Tool is geared towards companies needing an immediate EU FMD compliance solution.  The Tool is capable of translating serialization data files from packaging sites/CMOs into the EMVS format which can then be manually uploaded via the EMVO Gateway web portal.  More Information

Jennason Serialization Test Tool- Launched over 4 years ago the Serialization Test Tool continues to be the leading off-the-shelf testing solution specifically designed for pharma serialization implementations.  The Tool is capable of simulating common serialization scenarios (commissioning, aggregation, shipping, end of life) and generating the corresponding EPCIS test data.  All major L4/L5 serialization platform vendors are supported.    More Information

New Service Offerings  

In late 2018 Jennason launched Jennason Design Services.  The purpose of Design Services is to support companies in need of building custom applications which supplement or enhance their serialization and commercial supply chain operations. Design Service engagements range from developing implementation tools to reporting dashboards to proof of concepts for companies looking to unlock additional value from their serialization investments.    More information

Thank you again and look forward to hearing from you in 2019.

Monday, January 7, 2019

EU FMD: Leveraging the ‘EMVO Gateway’ option for manual serialization data entry/file upload to the EMVS.

With just over a month until the EU FMD deadline pharma manufacturers should be putting the final touches on their compliance solutions- most integral of which is how they will communicate serialization and related data to the European Medicine Verifications System.

For manufacturers of any significant size/scale this communication of data is being handled by 3rd party vendors who directly integrate with the EMVS.   This enables a largely ‘hands off’ approach for the manufacturers- as their product gets serialized at packaging sites/CMOs the data flows to their 3rd party vendor system who, in turn, re-formats and communicates to the EMVS (at least this is how it should work :))

Another, fairly under-publicized, option exists however- known as the EMVO Gateway.    The Gateway is a web user interface which manufacturers can access and perform all the necessary data communications to the hub.   The Gateway generally provides two options for uploading data- manual entry (via typing or scanning of a barcode into the web user interface) or file upload (uploading a pre-populated file)

The EMVO Gateway is an intriguing option for the following use cases:

  1. For companies whose 3rd party vendor is having issues and/or not on track to meet the upcoming deadline.
  2. Companies who wish to maintain a secondary (back-up/fallback) solution to reduce overall compliance risk or dependency on a 3rd party vendor.
  3. For companies who serialize product infrequently and/or at low volumes such that a more manual option is feasible.

A few key insights about the EMVO Gateway:
  1. The Gateway connection can be maintained in parallel to a 3rd party vendor connection.  Credit to the EMVO for recognizing that most manufacturers would see the value in having two connections enabled at the same time.  This means there is little to no risk (and cost) for a manufacturer to enable the EMVO Gateway as a backup option.
  2. The file formats which can be uploaded via the Gateway are NOT the same as files sent directly to the EMVS interfaces.  Don’t assume you can simply take files from your 3rd party vendor and upload them via the Gateway in case your 3rd party vendor fails.
  3. EMVO Gateway supports all necessary functions (master data upload, pack upload, pack update, batch update, recall, report requests).
Whatever the use case may be there are some key hurdles which must be cleared in order to properly register and initially set up the EMVO Gateway access- and even more importantly these tasks can be time-consuming.  To ensure your EMVO Gateway access is available come Feb.9 it is strongly advised that you begin the process ASAP.

If you need help getting access to your EMVO Gateway or have questions as to how the EMVO Gateway option may be best positioned in addition to, or in place of, a 3rd party vendor connection reach out to Be4ward for expertise.  Jennason is proud to have developed a solution in collaboration with Be4ward (Link) which ensures companies can use the EMVO Gateway option effectively and efficiently.

Popular Posts