GS1's Messaging Standard For Verification Of Product Identifiers
For companies in the US pharma supply chain, 2019 is going to be a year of an important milestone of the Drug Supply Chain Security Act (DSCSA). In November, wholesale distributors will be required to begin issuing verification requests to manufacturers, at the Standardized Numerical Identifier (SNI) level, for any returned drug that is still saleable, before they resell it. I’ve written a lot about this change in the past.
The Healthcare Distribution Alliance (HDA) has facilitated the design and development of an architecture called the Verification Router Service (VRS) (see “First Meeting of the HDA Verification Router Service Task Force”). VRS is intended to be used by wholesale distributors to submit these verification requests to the appropriate manufacturer for a fast verification response. That's why manufacturers need to take notice. It’s a complex, supply chain-wide solution that already has two different interoperable expected implementations.
A critical aspect to interoperability of a solution like this is to make sure everyone uses the same messaging between entities, regardless of their technical implementation. These are the messages that will be exchanged between the various components and users of the VRS. Early on in the development of VRS, GS1 volunteered to create a verification messaging standard that would help ensure the needed interoperability. Earlier this month, GS1 delivered it. It’s called “GS1 Lightweight Messaging Standard for Verification of Product Identifiers” release 1.0.1. You can download a copy here.
Here is a traditional GS1 element string as it might be encoded within a barcode (taken from GS1’s new standard specification):
Without further explanation (except to say that GS1’s new standard specification gets this example wrong), here is the same data encoded as a GS1 Digital Link:
Watch for more about this exciting new way to depict GS1 element strings in a future RxTrace essay. But for now, let’s move on.
I did not participate in the development of this new verification messaging standard for verification of product identifiers beyond the first one or two meetings. The time to raise issues with GS1 standards in a helpful way is during their development. I should have done that, but I have been raising certain issues with verification ideas in general since before the development process for this standard was started, so I’m going to raise them again anyway. I think any verification solution—particularly a messaging standard—should enable companies to meet the law as written. GS1’s standard properly includes a “context” parameter to allow the requester to indicate what kind of rules they want imposed. In this case “dscsaSaleableReturn”. This allows the GS1 standard to be used for just about any current or future verification needs in other industries or other countries, applying the industry- or country-specific rules for their unique definition of “verification”.
For DSCSA Saleable Return verification, I am concerned about the way the standard only allows two responses: verified (true) (green light) or not verified (false) (red light). I’m not alone in that concern. In a DSCSA context, this forces companies to always respond one way or the other.
I’ve advocated for a third response that would allow companies to indicate that the answer is more complex than either a red light or a green light can convey (see “DSCSA Red Light Green Light: Verification Responses”). It appears that GS1 has attempted to address this need by adding an optional “additionalInfo” parameter for use whenever there are extenuating circumstances, like “recalled” (the only value currently allowed in the “additionalInfo” parameter).
The DSCSA defines “verification” as:
“(28) VERIFICATION OR VERIFY.—
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.” DSCSA Section 581(28).
And the manufacturer is required to initiate an investigation into any product that they cannot “verify” (applying the definition above). That is, every “false” response to a verification request must result in the initiation of some kind of investigation by the manufacturer. If you respond “false” + “recalled”, you are saying that the manufacturer did not assign the product identifier to a package that matches the request…and, that product is in a “recalled” state. This is nonsense. How could a serialized unit be in a recalled state if the manufacturer determines that they did not even make that unit? I am aware, however, that some manufacturers might choose to issue a “recall” to help find and remove all illegitimate units masquerading as their legitimate product, should that ever happen.
Companies using this standard need to keep in mind that it is a verification request messaging standard, not an “is this product OK to sell” request standard. For units that are under a normal (non-counterfeited) recall, the correct response to a verification request should be “true” with the additionalInfo parameter set to “recalled” (see GS1’s example). No further investigation by the manufacturer is necessary.
Wholesale distributors have complained about the use of “recalled” as additionalInfo because they don’t want manufacturers to start using the VRS as a way of notifying them of recalls. There are better ways to do that in use today. So why is “recalled” the only allowed value for “additionalInfo”?
There are other real conditions—conditions that manufacturers will want to convey to the caller—that this messaging does not currently allow. What happens if someone submits a verification request and the product is known by the manufacturer to be stolen? In this case the response should be “true”, additionalInfo = “stolen”. That is, yes, we did make a product that matches the one you asked about, but it should not be sold because it was stolen somewhere in the supply chain. That makes sense. But GS1’s standard does not include “stolen” as a valid value for “additionalInfo”. This was apparently not an oversight because, near the definition of “additionalInfo” in the Open API Schema they note that:
“…EPCIS IS THE PREFERRED MECHANISM FOR INDICATING CHANGES IN PRODUCT DISPOSITION (e.g., recalled, stolen, decommissioned)”
Is this a justification for not including “stolen” as a valid value for “additionalInfo”? If so, then it makes the standard something less than practical.
It doesn’t stop with stolen either. What should the manufacturer do if they have previously marked the matching product “suspect”? That is, it is currently the subject of a DSCSA suspect product investigation at the time another verification request arrives. This situation is exactly what would occur if a counterfeiter floods the market with units that all have the identical product identifier of a single, real unit. All of a sudden, the manufacturer might begin receiving requests for verification of that same unit all over the United States. The first request would be verified. Maybe the second request would too, but eventually, additional requests within a short time from multiple requesting GLNs should cause the manufacturer to get suspicious and start an investigation. While that investigation is ongoing, they will want to respond “true” with additionalInfo = “suspect”, but the messaging standard doesn’t currently allow that value.
We could go through the same sequence with a verification request for a drug that is known to already be dispensed or destroyed. In both cases the current state of the unique identifier would be “decommissioned” (something that will rarely be known by drug manufacturers under any currently known regulation in the world, but would be known by many governments where this messaging could be used). This would be the case when someone goes “dumpster diving” and refills an empty bottle with counterfeits and reintroduces it to the supply chain. Despite GS1’s note, it is unlikely there will ever be a time when all members of the US (or EU) pharma supply chain use EPCIS events to transmit and monitor changes in a unit’s disposition.
OK. I see I’ve made too big a deal over the additionalInfo parameter—something that can easily be fixed in a future minor update. Besides that, I think the new standard is a nice piece of work and should be in use very shortly in pilots and then in production within the VRS solutions.
- 308 views
- 0 previews
- 2 versions
- 0 replies
- 1 follower
- Posted By:
- Dirk Rodgers
- January 30, 2019
About this forum
- 239 views
- 5 topics
- 2 followers