Four years ago the GS1 EPCglobal Software Action Group (SAG) Drug Pedigree Messaging Work Group was wrapping up the standard specification for the GS1 Drug Pedigree Messaging Standard (DPMS, aka GS1 Pedigree Ratified Standard). That standard was developed through collaboration between U.S. pharmaceutical supply chain members, industry associations, solution providers and GS1. DPMS 1.0 was ratified by the EPCglobal Board in early January 2007.
DPMS has many benefits. It results in a self-contained, self-secure electronic document that clearly shows the chain of ownership and/or custody of a given drug package (or a set of packages if they all have the same history). It works equally well with serialized and non-serialized products. The security of DMPS documents comes from within the electronic documents themselves rather than just from a security layer wrapped around a given server. A self-contained, self-secure document model should work well as evidence in a criminal trial.
But even before DPMS was ratified people were raising questions and concerns about it. Those concerns were:
- While it is great for providing a “trace” of a drug through the supply chain–that is, it provides a supply chain history to each buyer of a drug–DPMS does not provide any mechanism for “track”–that is, providing a downstream view of the supply chain history to previous owners including the manufacturer. This would be important for some non-regulatory applications of track and trace.
- As DPMS pedigrees move down the supply chain, they get bigger, and thus the storage burden gets bigger as they move. This is because the chain of ownership/custody is longer and so more data is contained in each pedigree. Because DPMS electronic documents are complete and self-contained, trading partners near the end of the supply chain, pharmacies in particular, must hold larger documents than trading partners near the beginning. While this is partly offset by the fact that manufacturers will need to store pedigrees for many many more drug units than pharmacies, wholesalers fall somewhere in the middle.
- The DPMS pedigree model results in duplication of data across the supply chain. That is, most of the data contained in a pedigree that a pharmacy holds will also be held by the wholesaler, and some of it will also be held by the manufacturer. This duplication would help investigators figure out exactly what happened to a given drug as it moved through the supply chain, but it results in greater data storage requirements for all non-manufacturer trading partners than would exist in a distributed pedigree model. In theory, this duplication lowers the risk that a given trading partner would be falsely accused of criminal activity by allowing them to hold their own copy of the clean pedigree as they received it and as they sent it to their customer. They would not need to rely on a third-party to keep their pedigrees secure.
- Because an electronic document must be passed from the buyer to the seller in every distribution of a drug, a data communications channel must be established between each seller and each of their customers. This represents a huge increase in the number of channels that are in use today.
Faced with these challenges just as DPMS was being ratified I drew up an alternative approach to pedigree and presented it in an EPCglobal Joint Action Group (JAG) meeting in Orlando in January 2007. I called the idea “A Semi-Centralized, Semi-Distributed Track and Trace Pedigree System”. My goal was to eliminate or reduce the magnitude of the problems raised over DPMS, but I also wanted to retain its benefits.
The only alternative to DPMS that has been proposed by others is what I call the “distributed pedigree“, where no one would hold the complete pedigree unless a regulatory inspector demands to see it. In that case, a local system would query all of the prior owners of the drug for their part of the pedigree. These partial pedigree components would be collected and then pieced together to form the complete pedigree, just for the inspector.
In my view, this distributed pedigree fails to secure the supply chain because it turns the pedigree validation step into a rare, after-the-fact activity instead of an automatic and routine activity performed every time a drug is acquired from a supplier. We lose the ability to monitor for the introduction of illegitimate drugs into the legitimate supply chain at every step and it becomes the responsibility of the government to monitor the supply chain. On the other hand, DPMS keeps the complete pertinent data set in the hands of each member of the supply chain and distributes the responsibility for monitoring supply chain integrity to all trading partners. In the distributed pedigree concept, the data is distributed and the responsibility for monitoring it is centralized with the government.
My goal was to retain the centralization of the data but keep the ability for validating the pedigree at every step. I recognized the need for a central repository for pedigree data, but not a single, massive and impractical “database in the sky”. Because the central repositories would need to be very high performance, highly available and disaster recoverable, they would be costly. The pedigree model would need to include a way to pay for these costs.
My idea started with the requirement that each drug manufacturer establish a contract with a pedigree service provider that would host all of the supply chain pedigree data for the drugs that the manufacturer introduces into the supply chain. They would pay for this service and all downstream trading partners would be given controlled access at no additional charge to allow them to deposit their part of the pedigree whenever the drugs of the associated manufacturer are sold. In this way, the pedigrees are semi-distributed across all manufacturers, but they are also semi-centralized in that all pedigrees of a given manufacturer would be in one place.
Access to the data would be tightly controlled by the pedigree service provider so that no one, including the manufacturer who is paying for the service, could see the data contributed by other parties unless they currently own the drug, or did so in the past. And then, they could only see the supply chain history prior to their owning the drug. Any trading partner could request a full pedigree, rendered in a DPMS document, that would show their ownership of the drug and all prior owners (a “trace”). A view the other direction, down the supply chain (a “track”), would be allowed only when data sharing agreements are in force between trading partners, thus enabling non-regulatory uses of supply chain history data.
Each time a seller sells a drug to a trading partner the seller and the buyer would provide data about the transaction to the pedigree service provider of that drug. When the service provider receives the data they would run a validation check to make sure that the pedigree is complete and consistent. If it is not, all pertinent parties would be notified. This includes the buyer and seller and could include the manufacturer and/or regulators.
The funding model of any given pedigree model is very important. A pedigree model might sound great, but if it can’t be funded fairly, it won’t work. For my proposed model, the cost to the manufacturer for the pedigree service would depend on the volume of drugs that the manufacturer introduces into the supply chain. That payment would cover pedigree data services for the life of the product so that if the manufacturer goes out of business, the pedigree service for the product made and sold prior to that would already be paid for and would continue. This cost would be added to the cost of the drugs and governmental drug pricing administrators would need to acknowledge and allow these true costs to be added.
Each trading partner would need to contract with a single Connectivity and Information Exchange service provider that would provide services to seamlessly connect them to the pedigree service providers of all drug manufacturers. The trading partner would pay for this service. These fees should be much smaller than those paid by the manufacturer and so these costs would be absorbed by each trading partner. It would become an additional cost of doing business in the pharmaceutical supply chain. This is a fair and equitable way to fund supply chain security.
I envisioned that trading partners would make use of a data repository based on GS1’s Electronic Product Code Information Servicers (EPCIS) standard to hold their part of the pedigree data. Because they would provide this data to the pedigree service provider, the official copy of the data would be the one held by that third-party and there would be no need for directly querying another trading partner’s EPCIS. Each trading partner’s pedigree system would need to be able to understand the DPMS document format as well since that would be the format that a complete pedigree would be rendered in by the pedigree service provider whenever it is needed.
(Click on image to enlarge)
The pedigree service provider’s system would likely be partly based on the EPCIS interfaces but this software would be specialized to understand DPMS as well since it would need to construct DPMS pedigrees on demand. The data would not be stored as DPMS pedigrees to avoid the duplication of data. The digital signatures of each trading partner contained in a DPMS pedigree could now be replaced with a digital signature applied by the pedigree service provider as a way to stamp it as having been produced by the official service provider for that drug. The EPCIS events contributed by each trading partner could also be digitally signed to provide DPMS-like non-repudiation, but only the pedigree service provider would need to validate those signatures so they would not appear in the DPMS pedigree report.
I don’t see any need for GS1’s Discovery Services, but others may see a place for it. Back in 2007 I created a series of drawings that steps through the operation and it made use of GS1’s Object Naming Service (ONS) for each trading partner (via their connection and info exchange service provider) to find the pedigree service provider that is handling the pedigrees for each unit by serial number (EPC, that is).
THE KEY FEATURES
In 2007 I listed these key features of my design:
- Third-party hosts Pedigree Repository Services (Semi-Centralized)
- Pedigree Repositories distributed across multiple Service Providers (Semi-Distributed)
- Enables competition for Pedigree Repository Services and Connection & Info Exchange Service contracts
- Concentrates the need for High Availability and Disaster Recovery in service provider organizations rather than trading partners
- Minimizes the number of “hops” necessary to obtain the pedigree (also, # of hops does not grow)
- Enables optional item authentication at the same time pedigree is updated
- Data Security is maintained by service providers who are under contract
- GS1 ONS prevents counterfeiter from serving bogus pedigree and enables data to be moved from one service provider to another, preventing vendor “lock-in”
- Provides a practical and flexible data visibility control mechanism based on contracts
- Third-party is responsible for deleting pedigree data only after expiration of the longest legal deadline of the last pedigree transaction
WHAT EVER HAPPENED TO THIS IDEA?
What happened? In short, nothing. At the meeting where I presented this approach, a number of solution providers had joined forces to pitch the EPICS plus Discovery Services model and the distributed pedigree concept was born. Since that time GS1 has pursued the development of Discovery Services, which is still far from completion.
I continue to believe that my Semi-Centralized, Semi-Distributed Pedigree idea is still the most viable alternative to a pure DPMS pedigree model but the idea won’t progress any farther than this unless others in the supply chain recognize its strengths in comparison to either a pure DPMS or a distributed pedigree model based on EPCIS.