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

Spirit

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.

Letter

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.