Over the last year in GS1, in many of the members of the U.S. pharma supply chain and even in the FDA, the focus has turned to the analysis and discussion of three classes of electronic pedigree models:
- Fully Centralized,
- Semi-Centralized, and
- Fully Distributed.
I’ve discussed some of the pros and cons of these models here in RxTrace too (see “The Viability of Global Track & Trace Models”, “Should Regulations Dictate Technology?”, and “Could This Be Your Future Track & Trace/ePedigree Exchange Solution?”).
One of the characteristics included in many of these discussions is the “points of failure” of each model. For example, I’ve heard it said several times that the Fully Centralized model suffers from a “single point of failure”, with the implication being that Fully Distributed models do not have this problem. In fact, this is incorrect and in reality, both the Fully and Semi-Centralized models are much less likely to fail than models that fall within the Fully Distributed category when “failure” is defined as not being able to provide an ePedigree on demand in any given instance.
RELIABILITY ENGINEERING OF COMPLEX SYSTEMS
Wikipedia has a pretty good article on Reliability Engineering so I’ll spare you the background of the discipline that studies points of failure. The mistake people sometimes make when comparing the centralized and distributed ePedigree model classes is to think that a single central repository is like “putting all your eggs in one basket”, and the distributed models is like “spreading your eggs out”, but this is wrong. When it comes to the ability to produce an ePedigree on demand in a given instance, a model where all of the data is held in a single location is going to come out better in the failure analysis than one where the data is fragmented and spread out among multiple distributed databases and needs to be collected to produce a complete ePedigree.
In fact, all things being equal in each repository, the likelihood of failure would be at least n times greater, where n is the number of distributed repositories holding the fragmented ePedigree data. That’s because, all things being equal in each repository, if any one of the distributed repositories experiences a failure, the overall system fails because it is incapable of producing the ePedigree.
BUT ALL THINGS WON’T BE EQUAL
In a Fully Centralized or Semi-Centralized ePedigree model the central repositories would be designed and maintained under contracts issued by multiple parties who would share an interest in high availability (HA) and disaster recovery (DR) so you can bet that there would be multiple online copies of the data hidden behind the façade of a single point of access. More than likely those multiple copies would include copies that are widely separated geographically to mitigate the risks of major weather events (hurricanes, tornadoes, ice storms, etc.), natural disasters (tsunamis, fires, earthquakes, floods, etc.) and man-made disasters (terrorist attacks, war, etc.). Even Twitter applies these principles to ensure that we won’t have to miss out on the latest celebrity drivel during and after one of these disasters.
The investment in the centralized repositories would be spread across multiple parties so more could be spent on ensuring that the data is protected without causing any one participant to pay excessively. The costs would be spread out.
But in a Fully Distributed ePedigree model each data contributor—each supply chain participant—would be independently responsible for designing and maintaining their own repository to hold their fragment of the ePedigrees for the drugs they make, buy, sell and/or dispense. Even many of the larger corporations in the supply chain may not have the expertise in-house—or the willingness—to apply the principles of HA and DR when designing their repositories. It is extremely unlikely that all members would be able to do what is necessary to minimize the odds that some disaster would prevent them from providing their fragment of the ePedigrees requested.
For this reason we can’t use the phrase “all things being equal” between the repositories in the two centralized models and the distributed models. Things are not going to be equal, and so the odds of a failure in the distributed models would be much worse than even n times greater than those of the centralized models.
WOULD A CRIMINAL CONTRIBUTE THEIR PEDIGREE FRAGMENT?
Now let’s throw into our scenario what happens when one of the supply chain participants is actually a criminal in disguise (for an example of how that can occur, see my essay “Lessons from ‘Drug Theft Goes Big’”). In either of the two centralized models they would need to supply their ePedigree fragment data to the centralized repository before they could sell a given drug package. The central repository would need to validate the data they contributed and if it doesn’t check out, the criminal activity would be exposed immediately and the illegitimate drug would not be able to move further down the supply chain.
But in a distributed approach the criminal wouldn’t need to supply their ePedigree fragments until later, perhaps only when someone becomes suspicious and requests the full ePedigree for a particular package of drugs. When the criminal receives a request to supply their ePedigree fragment for a package that they know has an illegitimate history do you think they would supply that data? Certainly not! They would claim that they are having “system problems” and if pressed, the data would get “lost” somehow. They are criminals, after all, and that data would be self-incriminating!
I hope you can see that a centralized ePedigree model is actually much less susceptible to failure—whether unintentional or intentional—than a distributed model. I’ve grown to really appreciate the centralized models—particularly the semi-centralized model for free-enterprise countries. I don’t see any characteristic where a distributed model outperforms the supply chain protections of a centralized model. Do you? Leave a comment below and set me straight!