By Jeff Stollman and Martin Mateev
Background
In 2013, the US Congress passed the Drug Supply Chain Security Act (DSCSA) . This act mandated that Food and Drug Administration (FDA) drive the pharmaceutical industry (manufacturers, re-packagers, distributors, and dispensers) to develop a capability to allow the FDA to gain visibility into the industry supply chain to reduce the amount of counterfeit, gray-market, and diluted products in the market. These products not only are responsible for detrimental impacts to the public health (including deaths), but also cost the legitimate drug industry billions of dollars in lost revenue annually.
While the industry fully supports the goals of DSCSA, Members are rightfully concerned that providing the FDA with the visibility to track products through the supply-chain risks exposing proprietary sales data that could have a significant impact on their competitiveness.
In order to comply with the US FDA regulatory mandate to provide supply-chain traceability 2023, the industry has been reviewing several solution approaches. This paper explores the pros and cons of each of these approaches.
Analysis
DSCSA requires that supply-chain Members record and provide Transaction Data for changes in ownership of pharmaceuticals covered by the Act. Transaction data includes the following:
1. “the proprietary or established name or names of the product;
2. “the strength and dosage form of the product;
3. “the National Drug Code (NDC) number of the product;
4. “the container size;
5. “the number of containers;
6. “the lot number of the product;
7. “the date of the transaction;
8. “the date of the shipment, if more than 24 hours after the date of the transaction; “the business name and address of the person from whom ownership is being transferred; and “the business name and address of the person to whom ownership is being transferred.” The Act does not require Dispensers to track their sales to end customers. This shortcoming means that once products are manufactured and introduced into the supply chain, a solution that only meets the minimal requirements of the law will limit the ability to remove (“de-commission”) packages from the record once they are disseminated to end customers. This loophole allows a Dispenser to sell the same package multiple times to end consumers. Because the sale to end customers is not recorded, there is no way to detect these multiple sales that use the same package ID. This enables the introduction of counterfeit, gray market, and/or diluted product into the market in this last step in the supply chain.
By combining the Transaction Data for a particular drug package (or group of packages), the FDA gains visibility to the entire path the package has taken through the supply chain. When a suspicious package is identified (e.g., a dispensed drug that fails to offer expected relief is determined to be counterfeit or diluted), the FDA can use this Transaction Data to look upstream to determine where the package entered the supply chain. This provides investigators with a starting point to determine the source of the Suspicious Product.
Similarly, when a drug recall is required, the Transaction Data allows for discovering of the downstream path or a batch of products to rapidly and efficiently inform targeted downstream supply-chain Members of the recall.
Providing this information is straightforward. Providing this information while maintaining the confidentiality of proprietary sales data creates a more difficult problem.
Three general approaches to solving this problem are currently under consideration:
1. Single, centralized SQL database
2. Separate databases for each supply-chain Member
3. Centralized, disseminated, encrypted, blockchain database.
Each of these is discussed separately below.
1. Single, centralized SQL database
If the only mission were providing visibility to the upstream and downstream paths a package takes from manufacture to dispensing, having supply-chain Members merely contribute transaction data to a centralized database is an easy solution. The FDA could create a portal and prescribe a format for supply-chain Members to submit their data and the resulting database would be simple and cost-effective. The FDA could query this database, as needed, to track and trace any package (or group of packages both upstream and downstream and meet all of the objectives of DSCSA
But, while creating a single, centralized [SQL] database is the most simple solution, supply-chain Members fear that such a database would put the confidentiality of the proprietary sales data in jeopardy. Some of the most secured Government databases have been breached by adversaries ranging from political hackers to organized crime. Outsiders accessing the database could not only expose the data and/or threaten to disclose it for ransom, changing the competitive dynamics of the market, but once breached, adversaries could alter the data, masking suspicious transactions by providing a false upstream supply chain. Such a loss of data integrity would complicate any forensic investigation to detect the source of Suspicious Packages and extend the time that the public may be exposed to health risk
The industry has insufficient faith in the ability of the Government to keep such a database secure from such breaches. And this lack of faith is not unique to ownership of the data by the Government. The industry’s reticence would not be changed were the database to be maintained by a commercial enterprise.
Because the industry is unlikely to ever be willing to risk exposing this vital competitive information, this solution is unlikely to ever be implemented.
2. Separate databases for each supply-chain Member
In order to provide supply-chain Members with the confidence that their proprietary data will not be exposed, they have offered a decentralized “breadcrumb” solution. In this solution, each company maintains its own Transaction Data. As such, each company would record both its transactions with its immediate upstream suppliers and downstream customers. And they would keep their data in their own databases under their own security. They already do this today, since most of the Transaction Data is stored in the companies’ ERP systems. We call this approach the “breadcrumb” model because, like a trail of breadcrumbs, it requires the FDA to proceed serial from one Member database to another in order to cobble together the complete path that a product of interest has taken.
In order to implement this solution, an extract from the ERP system would be placed in a company portal. The portal would be set up to allow the FDA to access the data. In order to track a package on its trip throughout the supply chain, the FDA would start by reviewing the manufacturer’s database which would identity the Distributor(s) to which the package(s) was sold. They would then go to the Distributor’s database in order to determine which Dispenser(s) received the package. Potentially, there could be other steps in the chain and the FDA would have to serially interrogate each system to determine how the packages were disseminated through the supply chain. Similarly, packages could be tracked upstream in this same serial fashion to track its provenance
While this solution is viable in concept, as a practical matter, it is extremely complex. And this complexity will result in the loss of valuable time when the public health is at stake
This complexity manifests itself in several ways. First, having separate databases for each transaction puts data integrity at risk. If Manufacturer A’s database claims that it sold 50 packages to Distributor B and Distributor B’s database documents that it received 100 packages, there is no implicit reconciliation. The disparity will not be recognized until an investigation, triggered by an external event. And by the time this external event occurs, there may be a significant public health crisis pressuring the FDA to rapidly reconcile this transaction (which may, by now, be weeks, months, or years old), but the investigation will take time.
Second, there is the database problem. With thousands of Members of the supply chain, there would be thousands of databases to interrogate for widely disseminated products. Even if the schema for the database was standardized across the industry, it is unlikely that all would use the same underlying database product (e.g., Oracle version 11 or version 12c, IBM DB2, Microsoft SQL Server, etc.). This could result in compelling the FDA to create multiple queries to interrogate each of the different databases. Mandating a specific database product imposes the requirement on each Member to purchase the database and maintain skills to administer the database. And the thousands of Members may have different maintenance schedules. After interrogating Manufacturer A’s database to learn that a particular package was sold to Distributor B, the FDA might discover that Distributor B’s database is unavailable because of either routine or emergency maintenance.
Third, each firm will have to maintain its own Identity and Access Management (IAM) system to authenticate and authorize FDA agents seeking to access their database. This not only presents a similar problem as the brand and intricacies of negotiating each unique IAM system, it imposes a burden on each Member to maintain and support such a system.
Fourth, there is the customer support requirements of maintaining such a system for access by the FDA. Will smaller firms have to establish a 24×7 help desk to support emergency ad hoc queries of their database when a toxin has been discovered in a product that they may have innocently sold that has resulted a public health panic?
The FDA currently opposes this solution approach.
3. Centralized, disseminated, encrypted, blockchain database.
A centralized, disseminated, encrypted, blockchain solution has the potential to reconcile the confidentiality shortcomings of the single, centralized SQL database and the practical limitations of the “breadcrumb” model.
The database is centralized meaning that all transactions are recorded in it. But it is also disseminated meaning that the entire database can be distributed globally to provide higher levels of security. It is not necessary that supply-chain members each maintain a copy of the database in order to interact with the system. And, in fact, the proposed solution is structured so that no member maintains a copy of the database
This approach creates a centralized database similar to the first approach, but uses a new technology called blockchain to overcome the limitations of the standard, SQL-type database.
Many who recognize the term “blockchain” know that it is the technology that underlies Bitcoin. But Bitcoin is only one implementation of blockchain technology. And this robust technology supports a robust variety of alternative implementations.
In the currently envisioned approach tailored explicitly to address the requirements and concerns of the pharmaceutical industry, blockchain technology offers the following capabilities:
It uses a unique and robust encryption technology that has not been broken in over a decade while protecting the alluring $8 billion of value in the Bitcoin ecosystem. This encryption masks the identities of the parties involved in each transaction.
It includes integrity checks that verify concurrence of both the seller and the buyer before Transaction Data is added to the database. Records are reconciled before they are entered, removing this issue from consideration.
It is highly tamper resistant. The encryption used protects the integrity of the data, not merely its confidentiality. Additionally, the database is replicated in multiple environments and uses a consensus mechanism to resolve conflicts. If an adversary does find a way to hack and alter one version of the database, this “outlier” will be thrown out because it will be outvoted by the other versions that consistently present the true version.
Besides the level of confidentiality created by encryption of certain data (e.g., buyer and seller names are hashed), the solution architecture isolates the database from direct access. The database is inaccessible to both supply-chain Members and Regulators/Law Enforcement. The contents of the database can only be interrogated using pre-defined reports. And rules for requesting these reports impose further access requirements. Supply-chain Members are restricted to request information only about transactions to which they are a party. (And they should already have this information in their internal ERP systems, limiting their need to request such reports. ) The FDA will have the rights to submit report requests for any transaction or group of transactions. But even they do not have direct access to the underlying database. They can only request reports previously agreed to by FDA and the industry. And access rules can also limit who at FDA is authorized to request which report. In this way, disgruntled employees or “entrepreneurial” employees looking to resell information will be limited to how much they can accumulate.
By continuously tracking all inventory throughout the supply chain, the system facilitates the immediate dissemination of product recall notices to all inventory holders without having to disclose the names of these parties to the manufacturer.
Similarly, the system has the ability to automatically alert all inventory holders when a particular batch of product is approaching (or has reached) expiration.
Summary
Solving the track-and-trace problem to comply with DSCSA is a non-trivial problem. And the impacts of exposing supply-chain Member confidential competitive data (in approach 1) or delayed FDA response to a public health crisis (in approach 2) are substantial. The “blockchain” solution (approach 3) has yet to be proven, but holds the promise of a solution that will significantly reduce the likelihood of both types of exposure. It warrants further investigation and potentially, an industry pilot.