Last month I had the opportunity to see the presentation by Abbott Labs, McKesson, the U.S. Department of Veterans Affairs (VA) and GHX about their recent and ongoing Network Centric ePedigree pilot. [NOTE: GS1 removed the PDF file from their website after my essay was published. See the comments below this essay for more. – Dirk.] I see that a presentation on the same topic is on the agenda for this week’s HDMA Track & Trace Technology Seminar. If you are attending that event, don’t miss that presentation because this pilot is an important one. I normally like to attend the HDMA event but I won’t be there this year due to a long-scheduled vacation.
The pilot implemented a “Centralized” Network Centric ePedigree (NCeP) system.
Here is the high-level architecture used in the pilot:
The GHX “External Data Repository” (the centralized event database in this case) shown in Figure 1 was used to pass shipping information to each receiving party, if needed. In this case, McKesson wanted a copy of that data so they could validate that the product they received on their dock was actually the product that Abbott Labs shipped to them. They wanted a local copy of the data so they could access it quickly during receiving and later during shipping. In this pilot, the VA did not have a local database so they did not receive McKesson’s shipping events, but when they received the product they scanned the serial numbers using a GHX-provided data capture web page.
Each party in the supply chain submitted their pedigree-significant supply chain events to the central database where they could be joined with those submitted by the other parties. The central database could see all of the events and it used that ability to perform standardized and impartial pedigree checks. Each time events from a new party were deposited the GHX service ran a supply chain consistency check on the total dataset and informed the new party of the result.
This is one of the most important features of a centralized approach: the consistency checks—a set of well-defined business rules—are performed by an independent and impartial third party who has full visibility of all supply chain events in a single location. This frees each buying trading partner from the need to obtain all of these events and running the consistency checks themselves.
The GS1 Drug Pedigree Messaging Standard (DPMS) was a way to ensure that each buyer received all of the data necessary to perform those checks, but the problem with that approach is that the pedigree data grows in size as the drug moves down the supply chain leaving the pharmacy with the largest dataset for a given package of drugs. Another alternative, one of the Distributed NCePs, would require each buyer to query each of the upstream owners for this data and then perform the consistency checks themselves. Delays in the ability to sell or dispense a drug would result if one or more previous owners were unable or unwilling to respond quickly to their request. In either approach, lots of data would be sent downstream.
The Centralized NCeP used in this pilot solves these problems by providing a single place to hold and analyze the supply chain event data. Minimal data would need to be exchanged and no supply chain party would ever need to obtain or hold data that was generated by other parties. That’s the job of the central database.
CENTRALLY CONTROLLED DATA VISIBILITY
This implementation allowed GHX to set up very controlled data visibility for each trading partner. The following sequence of figures shows the default data visibility for each of the three trading partners. It’s the default that could exist if there were no data sharing contracts between the participants. A full implementation of the service would include the ability to facilitate greater data visibility under trading partner contracts.
The following image shows the view that the pharmacy would have for a single drug package. Click the images to enlarge them. The data shown is mock data, courtesy of GHX.
Look at the “Chain of Custody” list of events in the lower right hand corner of Figure 2. The pharmacy gets to see all of the chain of custody events, from the manufacturer through any wholesalers or other stops in the supply chain, to their own receipt. And they get to see the results of any consistency checks that were performed on the events. They get to see every event before they acquired the drug because they are the latest buyer. Buyers get to see everything prior to them receiving the drugs they buy.
Figure 3 is the view that the distributor would have after the pharmacy receives and unpacks the drug. Notice that they can see all the history prior to their acquisition of the drug originally, and they can see their own events. And they can see the pharmacy’s receive event. From that point on the information they can see is filtered. They don’t get to see the consistency check that was performed on behalf of the pharmacy, and while they can see that the drug was disaggregated from its shipping container (unpacked), they can’t see what company performed that action (that is, the serialized Global Location Number, or SGLN, is not present for that event).
Figure 4 shows the view that the manufacturer would have after the pharmacy receives and unpacks the drug. Notice that they can see their own events and the receiving event of the distributor, but after that all the information is carefully filtered to remove the company location identifiers (the SGLNs) and none of the downstream consistency checks are shown (although the current result is shown in the header). In this way the manufacturer can monitor the progress of their drugs as they move down the supply chain, but they can’t see exactly where they are. Again, this would be the default behavior that would exist without data sharing contracts.
Every event shown in each of these figures can be expanded to show the full or filtered event data by clicking on the event link. In addition, the central service could provide the manufacturer and/or authorized investigators with exception reports that would include the list of all of their drugs that currently do not have a consistent supply chain history.
The system could also automate the request and authorization of data visibility that law enforcement investigators would need to quickly pursue criminal activity. In short, even though the centralized service provider would hold all of the data, the ownership rights would remain with the company who generated each event. Every member of the supply chain would own the events that they contribute. The service provider would provide the service of automated sharing of that data, as controlled by the data owners.
The GHX service that was at the heart of this pilot implemented a fully centralized NCeP model. However, the same basic approach would be taken in a Semi-Centralized NCeP where multiple competing service providers would co-exist to hold the supply chain events of the products of other manufacturers. For more on the various NCeP models, see my essays “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 2” and “The Viability of Global Track & Trace Models”.
In my view this pilot is very important because it demonstrates how powerful a central NCeP system would be, solving all of the problems that earlier models have. However, keep in mind that this approach isn’t going to satisfy today’s pedigree laws, and there isn’t any guarantee that it would satisfy the phase 2 requirements of the system that is defined by the recent Congressional discussion draft bill. Someone needs to make sure those who are responsible for defining the laws are aware of the benefits that this model would have for the members of the supply chain. That someone is you.