Currently, we know that companies can use GS1’s Drug Pedigree Messaging Standard (DPMS) to comply with the California pedigree law. That’s been known for a long time now. But many companies have been hoping to use GS1’s more general purpose Electronic Product Code Information Services (EPCIS) standard instead for almost as long. For just as long, it has been known that a number of problems arise when you try to figure out exactly how to apply EPCIS to California compliance.
The problem is, EPCIS was originally envisioned by its creators to share supply chain “visibility” data. That is, event data that was to be collected automatically based on Radio Frequency IDentification (RFID) reads picked up by readers that were to be spread around the supply chain by each of its members. The collection of RFID readers were to form a kind of “visibility” of each RFID tag applied to the products in the supply chain. From this visibility would come benefits. One of those benefits was to be an automatically generated chain-of-custody report.
What happened to that vision? Well, most importantly, RFID in the pharmaceutical supply chain didn’t happen, so those who still want the benefits of EPCIS have proposed ways of capturing data using barcodes instead. Capturing barcodes—which require a human being to willfully choose to read them, and therefore enables “selective data capture”—is not quite as automatic as reading RFID tags so it’s a little hard to imagine that the resulting chain-of-custody reports can be considered true “visibility data”, but, for this essay, we’ll assume that it does.
Almost as importantly, someone needs to establish exactly how to apply the GS1 EPCIS standard across the pharma supply chain so that the result is an interoperable drug pedigree system. GS1 US has been trying to do just that and they hope to publish their proposal soon (watch for my comments on that proposal in a future essay after it is finally made public).
Because EPCIS is a general-purpose standard, there are actually many ways it could be applied so that what results is a kind of pedigree system. GS1 global has documented seven different ways to apply EPCIS for this purpose. I contend that the Semi-Centralized approach to a Network Centric ePedigree (NCeP) system—one of the seven ways GS1 documented—is the most secure and cost effective for healthcare supply chains.
However, I didn’t think that such an approach would comply with the California pedigree law. In my view, the California pedigree law was defined in such a way that it effectively dictated the use of a “document” that is passed from one owner of a drug to the next, and with each owner adding new information. This is how DPMS works so it seems like a natural fit for compliance.
CALIFORNIA BOARD OF PHARMACY WANTS TO ALLOW THE USE OF SEMI-CENTRALIZED DATA REPOSITORIES
In my last essay of 2012 I included my own transcript of an important part of the December 4, 2012 meeting of the Enforcement Committee of the California Board of Pharmacy (see “California Board of Pharmacy Clarifies Use Of GS1 EPCIS”). Earlier in the meeting the committee had heard the stock presentation by Abbott Labs, McKesson, the U.S. Department of Veterans Affairs (VA) and the Global Healthcare Exchange (GHX) that explained their recent pilot which tested GHX’s implementation of an NCeP using the EPCIS interface standard surrounding a centralized event repository (see “The Significance of the Abbott, McKesson and VA Pilot” for more about that pilot).
The Committee seemed genuinely excited about the technology demonstrated in that pilot. In the meeting, Josh Room, Deputy Attorney General, California Department of Justice, said that “…there is nothing to preclude a solution…a cloud-based solution—like GHX or something like that—from being a methodology of providing the necessary record data to your trading partner, that trading partner receiving that into either their own… internal enterprise system, or receiving it externally by way of their segregated data set at the cloud, or […] by the external data repository […] nothing about that is inconsistent.”
However, “[t]here are [still] various things that have to be included in it, [for example,] including that you have to […] certify the data that you are providing as being true and accurate. So there are some details, about how you do that differently by way of EPCIS or within an AS2 electronic message than you would by way of DPMS, but I don’t think those are irreconcilable or that the issues are really different. They may be different in type but not different in scope, from DPMS.”
Mr. Room is apparently encouraging the industry to define those details about how the specific requirements of the California pedigree law can be met—perhaps creatively—using EPCIS in a semi-centralized way.
HOW ABOUT THIS WAY?
Here is one possible way to do it. The semi-centralized model of an NCeP requires each supply chain participant to contract with one for-fee service provider, whether just a connectivity provider or a full connectivity and repository provider. During the setup phase of that contract, the service provider will need to deploy some mechanism for account authentication so that the users of the service under the contract will be properly identified as being employees of the supply chain organization. Being employees of the supply chain organization, all EPCIS events logged under those accounts would be attributed to that company.
As part of the uploading of those events, the service provider could allow these users to certify that the data being supplied is true and correct through some standard mechanism (digital signatures, or some other secure identification technology to be determined).
Assuming the State of California finds this technique acceptable for certifying the data generated by an individual company as specified within the pedigree law, we only need some way of certifying the whole pedigrees, which would contain event data that would have been uploaded to the semi-central repository by multiple companies.
Because the semi-central repository (or the set of semi-central repositories) holds all of the events necessary for constructing the full pedigree, and because each event contribution was originally accompanied by individual certifications (see above), the repository service provider should be able to provide their own over-arching certification for the full contents of the pedigrees it would provide. That certification could be done in the form of a digital signature that spans the entire ePedigree so that it becomes self-contained and secure—that is, an immutable and non-repudiable document or collection of events in a single query response file.
One way to represent the pedigree that contains the single, full-span digital signature attached by the service provider is to make use of a slightly modified DPMS format. The modification would simply make the existing nested digital signatures optional, and then include the single, full-span signature definition.
The full pedigree certifications made by the service provider would simply certify that the contents are true and correct as they were provided by each party. That is, the service provider has not modified the data in any way since it was provided by each identified party. It has simply packed the events together into a single pedigree message and signed it so it cannot be modified by someone else without easy detection.
THE PEDIGREE CHECKING SERVICE
The construction of full pedigrees would only be necessary when needed for external investigations, so they would be rare. This is because the semi-centralized service providers, as envisioned by GS1, would also provide their clients with an impartial pedigree checking service. When a supply chain company buys drugs, they would be sent the results of a pedigree check for each drug package they will receive that was performed by their contracted service provider upon shipment.
The checking service would verify things like the following for each package of drugs :
- Each prior owner provided a properly certified shipping event
- Each prior owner who was not the manufacturer provided a properly certified receiving event
- Each prior receiving event has a matching shipping event
- The drug is not in recall or indicated as stolen (for forward shipments)
- Additional optional checks as defined by the recipient or as required by regulation
The value of the checking service is that it eliminates the need for each supply chain participant to receive the entire pedigree just so they can perform these same checks themselves. This is perhaps the biggest objection to DPMS which passes all of the pedigree data downstream as the drugs move through the supply chain. In the semi-central NCeP that includes a checking service, only the serial numbers and the results of the most recent pedigree checks would be routinely passed to each buyer. If a pedigree check fails, the buyer can request a full pedigree for that individual item if necessary as part of the follow-up problem resolution investigation.
THE LAST REMAINING PROBLEM?
If we assume the California Board of Pharmacy would accept this approach to ePedigree, including the approach to the two necessary types of certifications, the only remaining problems with using an EPCIS-based NCeP is the fact that EPCIS relies heavily on the external synchronization of supply chain master data (SCMD). The law requires pedigrees to contain full product information and full names and addresses for each party that handled the drug.
But EPCIS makes use of Global Trade Item Numbers (GTIN) and Global Location Numbers (GLN) to refer to that information, with the assumption that all parties previously agreed to what those references actually refer to. GS1’s Global Data Synchronization Network (GDSN) is one way to accomplish that for product information. GS1 US Healthcare’s GLN Registry for Healthcare is a way to accomplish that for names and addresses.
However, if the semi-central repositories were able to tap into those two services (GDSN and the GLN Registry for Healthcare) the event data provided by each party could use GTINs and GLNs as GS1 intended for EPCIS events they supply. When the full pedigree is requested by any party, the service provider could resolve these references and build the full pedigree report to include both the GS1 reference numbers and their full descriptive data elements as required by the California pedigree law. Again, DPMS is all set to be the format of the full pedigree report because it already includes all of these data elements. In the rare instance a full pedigree would be necessary, it could be presented in the secure and self-contained DPMS format.
Is any of this acceptable to the California Board of Pharmacy? That is yet to be seen. But if we can trust even a conservative interpretation of the comments by Mr. Room in the recent Enforcement Committee meeting, they just might be open to a creative way like this to allow the use of EPCIS for compliance.
As I indicated in my last essay of 2012, I have now described “shadows of things that May be, only”. The only way to make them a reality is to help GS1 build them into the standards. The group that is attempting to do that is short on the necessary number of representatives from manufacturers. They can proceed for a while with that shortage, but they won’t be able to complete unless more manufacturers join the effort. Click on this link to join the Pedigree Security, Choreography and Checking Service (PSCCS) and help make it a reality. And also help figure out a way to get the California Board of Pharmacy to acknowledge that this approach might be used for compliance so companies can start planning on its use.
Dirk.
Hi Dirk,
I liked the essay and one particular point of interest that it sounds akin to the approach that we suggested in our presentation to the CA BOP of using an RFID tag to supply the data to a cloud data base that would link into an over-arching messaging and tracking application, like Verify Brand.
In addition to this one other question that was also raised at the meeting was regarding Cold Chain monitoring (management). This can be accomplished by recording the tag temperature data at the same time in the cloud data base. This would not only give change of ownership detail, but also what condition the product was in when it changed ownership.
Peter Norton