Back in January of 2013 I wrote an important essay called “Data Ownership In The Track And Trace Cloud” which analyzed a potential future where members of the pharma supply chain would need to deposit and maintain track and trace data in a centralized or semi-centralized data repository in the “cloud”. As the title implies, my main focus was on who would own that data, which was, and continues to be, a hot topic.
But now, five years on, things are getting less “potential” and more real. Over that time the “system of repositories” mandated by the Falsified Medicines Directive (FMD) and Delegate Regulation in the EU (EUDR) is under construction as a kind of central/semi-central repository in the “cloud”. And in the US, the FDA and the members of the supply chain are trying to figure out how to meet the 2023 requirements of the Drug Supply Chain Security Act (DSCSA) in some way that avoids the use of a central or semi-central repository in the “cloud”, and blockchain technology is a serious contender. With those advances since 2013, it’s time to revisit this vital topic.
Who will own the data that supply chain trading partners store in cloud-based data repository as part of compliance with track and trace regulations—whether mandated to do so or voluntarily? Back when I wrote the original essay I mentioned that I once met a potential future repository service provider who seemed to think that they would own that data. Imagine their excitement. All the data about where drugs go throughout the supply chain! Think of the value they could mine from that.
Well, that’s never going to happen because companies in the supply chain won’t sign up for handing over all of their supply chain data to some third-party just so they can comply with regulations. And regulatory agencies are not trying to destroy a company’s significant source of revenue (revenue from selling this data) by imposing track & trace regulations. That’s not the intent of these laws. Interestingly, that potential repository service provider eventually figured that out, and exited the business of offering track and trace solutions to the pharma supply chain.
In the EU, the “system of repositories” appears to me to have characteristics of a “semi-private” or “hybrid” cloud-based repositories. That is, it is made available by a third-party service provider (the European Medicines Verification Organization, or EMVO), to the limited set of companies who participate in the pharma supply chain within all or part of the markets covered by the FMD. The EU hub is more of a data routing hub, but it will also retain some of the data supplied by drug manufacturers, so I think it qualifies to be referred to as a centralized repository in addition to a routing hub.
The national medicines verification systems (NMVS) are very close to what I defined more than a decade ago as “semi-centralized, semi-distributed” repositories (see “A Semi-Centralized, Semi-Distributed Pedigree System Idea”). The main difference is that the NMVS systems are bounded by political boundaries rather than by drug manufacturers. And the system of repositories is implementing a verification at the point of dispense (PoD) system rather than a full track & trace/ePedigree system that I wrote about.
WHO SHOULD OWN THE DATA?
So if the operator of the repository technology won’t own the data stored there, who should own it? I’m not a lawyer, and I’m sure there are centuries-worth of case law that differentiates possession, custody and ownership in many scenarios. I’ll leave the full review of that to someone else, because, to me, it’s fairly obvious who should own the data.
The company who writes a given record into track & trace data repository should expect to retain all rights of ownership of the data it posts. What I mean by that is, a semi-private cloud-based data repository has no hope of being accepted by companies unless they know in advance that they will not lose key data ownership rights. That’s why, as a practical matter, the contract language has to come before the technology is used.
And that’s exactly what we see in the EU. To participate in the system of repositories mandated by the EUDR, participants must go through the EMVO “Onboarding” process. One of the first steps is to sign the EMVO Onboarding Project Agreement—a contract. Under the EU system of repositories, that contract clarifies that the onboarding partner (OBP) retains ownership of the data they provide (referred to as “OBP Data”), but signers agree to allow the EMVO and the NMVOs to control its access and use for meeting the EUDR requirements. The agreement must be signed first, before you are allowed access to the system of repositories.
I’ve written a little about this issue even earlier (see “Who owns supply chain visibility data?).
INTENTIONAL AND TARGETED DATA SHARING
But the whole point of a track & trace repository is to enable controlled data sharing…with the emphasis on the word “controlled”. The architecture chosen must provide very advanced, very granular rules that data owners can choose to invoke for each trading partner or class of trading partner that will enable them to control exactly who gets to have access to what. The default sharing setting should be “not shared” except to fulfill regulatory requirements. This is what I am calling “intentional and targeted” data sharing. The only data that is shared is the data that the owner intends to share and only with the targeted organization.
With this level of control, supply chain data owners would actually be able to sell more of their data to those who are willing to pay for it. And use of point-to-point Electronic Data Interchange (EDI) messages to convey this information would no longer be necessary. The track & trace repository would become the point of delivery to the consuming organization with the selling organization simply invoking the rule(s) that expose(s) the data to the buying organization(s). Pricing for access to the data would be a negotiating point solely between the data owner and the prospective buyer(s) and would most likely be a part of the existing Distribution Services Agreements (DSA) negotiating process.
Sharing controls must also have a configurable termination time/date so that from the beginning, the termination of the rules can be set to the termination time/date of the sharing agreement. Termination would then be automatic unless the agreement is terminated early for some reason.
HOW DOES BLOCKCHAIN FIT INTO DATA OWNERSHIP?
As currently being discussed in the industry in various forums, blockchain is a bit like a “track & trace repository”, where the way the data storage and exchange is implemented has characteristics of a semi-centralized, semi-distributed repository. All or some of the data would exist on a blockchain and some other data might exist “off-chain” in distributed repositories that are accessed through security controls by authorized parties.
By definition, the data in a blockchain would not be held in a “central repository” but a copy of it would actually be held by every “node”, which may or may not be one-to-one with the members of the supply chain (there are lots of designs under discussion at this time). That means the data would be distributed. But regardless of where the data actually resides, I contend that data held in a blockchain takes on at least some of the characteristics of centrally-held data—particularly that everyone can “see” the same data at (mostly) the same time, as if they were all looking at the data in the same cloud-based location. The “state” of the data seen at each node is the same. Ownership of the data held in the blockchain will need to be specified clearly in the future onboarding agreements.
The non-blockchain data accessible by the system would probably be held by the members of the supply chain themselves, or their chosen solution provider on their behalf. Thus, it would be distributed, as the US industry prefers for meeting the 2023 requirements of the DSCSA (see “FDA DSCSA Public Meeting #2, Still A Gulf”). Ownership of this data is never in doubt since it wouldn’t leave the possession of the owner or their contracted service provider. In theory, this seems to meet industry preferences, but it raises concerns about performance, access authorization and interoperability, at least in my mind. To avoid slowing the supply chain down, all data must be accessible very quickly to authorized parties in a standard way for DSCSA purposes.
So it looks like things are turning out a something like I predicted in that original essay, at least in the EU. We’ll have to wait to see what the FDA and the industry come up with for the US. Will it be blockchain-based? Hard to tell yet (but see “Blockchain Will Not Be Used For DSCSA Data Exchange“).
BTW, there are a number of DSCSA blockchain proof-of-concept pilots that are just about to complete. I don’t think any of them are testing performance, but they are testing interoperability, among other things. I will attend the “DSCSA and Blockchain” event hosted by the Center for Supply Chain Studies in Rockville, MD next week and will post a future essay about it.