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.
SEMI-CENTRALIZED, SEMI-DISTRIBUTED
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.
FUNDING
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.
THE TECHNOLOGY
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.
Dirk, good article. As a solution architect, I’ve considered a central repository that would eliminate the need for both ONS and GDSNs. The challenges isn’t technological as you indicate, but is rather a business one (“I recognized the need for a central repository ….a way to pay for these costs). What you depict in pictorial can very well be implemented by a single vendor using “single tenancy” SaaS model. As suggested above, the wholesaler and retailers would have to interface with multiple parties (though probably less than the number of manufacturers), which is less desirable. With a single vendor, at least this will be less of a challenge, as retailers will not want to interface with parties based on vendor selection decision by manufacturers. Wholesalers often sell the information to manufacturers and I can see wholesalers being interested in wanting to host the data to then be able to sell it – which ofcourse the manufacturers won’t be able to digest cause they are the ones who actually made the infrastructure investments to create the data in the first place!
Can we agree on a single vendor to host this data? Chances are not. This is the classic Game Theory Prisoner’s Dilemma problem! (http://en.wikipedia.org/wiki/Prisoner's_dilemma) The cooperation in this case would point to a single entity as has been done in the case of Belgium’s APB using Aegate (http://www.aegate.com/partners/associates.html) I believe since 2002.
Sanju,
Thanks for your well-thought reply. Your points are well taken. My idea was that the manufacturers would have the contract with a single service provider but the contract would not give them automatic access to all data. I know that sounds unlikely, but I believe it could be worked out. One of my guiding principles was to not change the data ownership model that exists today. Belgium and Turkey’s “successes” aside, I believe that the U.S. supply chain is too massive for any single service provider to handle all products from all companies. Competition would be key here.
Also, notice that I only call it an “idea” rather than a proposal. That’s a recognition that the politics are likely to prevent this kind of model from getting established.
Dirk.
Hi Dirk,
Thanks for another great blog posting. The model I had envisioned is very close to your proposal. Based on what I am seeing the role of “PEDIGREE REPOSITORY PROVIDER” can be best fulfilled by DS, and role of ONS is exactly how you prescribed it.
The feature and information sets that “PEDIGREE REPOSITORY PROVIDER” requires exactly matches Discovery Services. They both require to:
1) authenticate organizations in open-loop supply chains.
2) have granular access control at the level of serialized items, for authorization
3) to open for signup and registration by any partner in the supply chain
4) allow for publishing of information by any partner, because any supply chain partner can receive any product
5) hide and share information based on the identity of the requester and product serial
6) be hosted by providers with certified SLAs for HA & DR.
However _core_ DS does not offer specialized services such as product authentication service or pedigree management application. There would be auxiliary services that interrogate DS iteratively on behalf of clients to provide those services.
For example there could be varying level of tolerance for missing product pedigree information across the world for a particular product class. E.g. a particular GTIN is distributed across US, Canada and Mexico, which don’t have common pedigree laws however they have a single ONS record. So analyzing and interpretation of pedigree requirement would be a local matter, subject to the business context and the access control privileges of the requesting party.
Because of cases like this, _core_ DS has been designed to be enhanceable with auxiliary services to offer complementary functionalities that leverage common requirements 1 thru 6 met by _core_ DS, and the additional specialized service to directed at an industry challenge.
Best Regards,
Ali
Ali,
Thanks for your excellent comment. In my essay I said that I didn’t see any need for GS1 Discovery Services (DS), but others may see a place for it. In fact, when I wrote that statement, I was thinking of you. I am glad that you provided us this view of how DS could be used to implement this pedigree model. I agree that it could work, assuming that GS1 adopts the features that you are proposing. There is still a long way to go in its definition and development and I am glad that you are one of the core group who is doing just that. I am doubly glad that you are a regular reader of RxTrace so you can help ensure that DS is developed with enough flexibility to accomodate the pedigree use case. But keep in mind that my Semi-Centralized Semi-Distributed Pedigree model is just an idea and the odds that it would be accepted by the industry are probably not high.
Dirk – Fine job here. I like a different model, but for the purposes of this discussion would like to comment on the funding section of your writeup.
In your funding proposal, manufacturers pay for the lions share of the pedigree data services. We need to keep in mind three factors associated with this:
1. Item-level serialization, which is the enabling technology for any of these models, will be paid for exclusively by the manufacturers as well the cost of the pedigree data services you describe.
2. Generics, which are very rarely – if ever, diverted or stolen account for about 3/4ths of the volume of drugs – meaning these manufacturers would pay 3/4ths of the cost of serialization and the pedigree data model you describe.
3. The data servivces provider must be agreed upon by all – meaning that organization MUST survive. Since the California “delay” we’ve seen several organizations leave the market. There would need to be assurances that this would not happen in the future – this likely leads to government ownership of this data.
Taking these factors into account, if the goal of these laws and resulting strategies is increased safety for consumers, I believe there are more efficient and less-costly models than full track and trace to achieve this goal.
Thanks Brian. You make very good points about the cost distribution I described being unlikely. I think the model would work even if it had any of a number of alternate funding models.
Regarding the fact that several pedigree service providers have gone out to business, I assume that once the pedigree laws result in a large number of pedigrees being generated, the Software-as-a-Service (SaaS) companies who are in business at that time will remain because they will finally achieve their projected revenue streams. But even so, the model should have some ability for data to be moved from one service provider to another due to mergers and acquisitions.
On another note, I must apologize to all of my regular subscribers for the extra RxTrace email that you all received yesterday with two essays listed. There was a glitch in the Feedburner service that I use and it pushed out notices of essays that were about 6 weeks old. In truth, there were no new essays posted on the website today. Sorry for the duplication.
Dirk.