Last week the FDA announced it will coordinate one or more pilot(s) to assist in the development of the electronic, interoperable system that will identify and trace drugs in the U.S. under the Drug Supply Chain Security Act (DSCSA) in its Enhanced Drug Distribution Security (EDDS) phase starting in 2023. Once they start work on pilot planning, they will call for proposals from stakeholders and others. But they can’t start until they get permission from the Office of Management and Budget (OMB), and they won’t even ask OMB for permission until they collect comments on the proposed collection of information associated with establishing the pilot program. Believe it or not, that was the whole point of the announcement last week…not to ask for pilot proposals, but to ask merely for comments on the collection of information necessary to establish the pilot program.
No, they don’t want your ideas yet for what to pilot, and they don’t want your application to do a pilot under the program. Not yet. They just want comments about the collection of information, which would eventually include all of those things. The comment phase will run through September 18, 2017. After that, they will package up the comments and perhaps make adjustments to the proposed program, and send it to OMB. If we estimate they will do that, say, by the end of October, then the OMB will need to review the documentation provided and construct a response to the FDA. If we estimate that part will take a couple of months, we are not likely to see the pilot program start until early next year. And that’s when they will want our ideas and proposals for what to pilot.
So why even talk about it until later this year or early next year? Because the decision of what to pilot will likely determine the broad strokes of the design of that system we will need to adopt by the end of 2023.
WHAT’S THE POINT OF PILOTING?
The point of these pilots should be to help identify the processes, technologies, standards and architectures needed to, as the FDA says, “…assist in [the] development of the electronic, interoperable system that will identify and trace certain prescription drugs as they are distributed within the United States.” That “system” is what all trading partners will need to use after November 27, 2023 to meet the requirements of the DSCSA—and, frankly, to stay in business. The DSCSA is pretty vague when it comes to what that system should be made of and how it will operate. That’s why it requires the FDA to hold public meetings and one or more pilots—to help figure all that out in partnership with the industry.
The biggest changes that will go into effect in the EDDS are that serial numbers must be included in all Transaction Information (TI) documents, and the Transaction History (TH) will no longer be passed from seller to buyer (see “DSCSA: Transaction Information“, “DSCSA: Transaction History”). Instead, whenever an investigation requires TH, it must be constructed “promptly” using the “secure, interoperable, electronic” system. No one wants to create a “system” that costs more than the minimum necessary to meet the requirements.
Unfortunately, the FDA is starting this process late. With 2018 being the DSCSA “pilot” year, 2019 and 2020 will have to be the high-level design years when the overall supply chain data exchange architecture is determined and agreed to. That is, the FDA and the industry will have to use those years to design the “electronic, interoperable system” that everyone will need to use by November of 2023. That’s because 2021 will be the year when solution providers develop their product and service offerings, and 2022 and 2023 will have to be the years for companies to invest, deploy and test those solutions. This timeline leaves little room for debate and then alignment around the one architecture and its associated processes, technologies and standards. So, let’s get started.
WHAT SHOULD FDA PILOT?
FDA and interested parties already drew up a list of things that might be good ideas to pilot last year when they held their pilots workshop (for the full list of topics, see “The 2016 FDA Pilots Workshop”). But that list is too detailed. Individual companies might want to pilot some of the smaller topics on that list and contribute the final paper to the FDA, but the number of pilots the FDA will be a part of will likely be small—hopefully more than just one but just one is all they need to comply with their mandate. So the official FDA pilot(s) need to focus on the big questions.
Here are my extracts of big things to pilot from last year’s list the FDA collected from their workshop:
- Interoperability [see “Interoperability And The DSCSA”—Dirk]
- Central database vs. peer-to-peer (decentralized)
- [see “InBrief: The Rx-360 Traceability Data Exchange Architecture White Paper”, “DQSA: How Should Transaction Data Be Exchanged?”, “The Viability of Global Track & Trace Models”, “InBrief: ePedigree Models and Points of Failure”, “How To Make The Semi-Centralized Track & Trace Model A Reality” and “A Semi-Centralized, Semi-Distributed Pedigree System Idea”—Dirk]
- Trading partners with systems vs. others with little to no systems or using someone else’s system
- Maintaining visibility of the serialized product throughout the distribution supply chain
- What to do when a trading partner goes out of business
- Central database vs. peer-to-peer (decentralized)
- Data Issues
- Use of technical data standards that data attributes to enable interoperable transfers [see “Will EPCIS Event Exchange Replace EDI ASNs for DSCSA Someday?” and “Will GS1’s EPCIS Be Used Widely For DSCSA Data Exchange?”—Dirk]
- Test different methods to handle the Master data vs. transaction data separately
- Feasibility and acceptability of sending master data only once per shipment [see “Pedigree Models and Supply Chain Master Data”—Dirk]
- Controlling master data to minimize redundancy [see “Master Data, Supply Chain Master Data and Instance Data” and “Supply Chain Data Synchronization and Patient Safety”—Dirk]
- Evaluate data format or processes for data transfer [see “DQSA: How Should Transaction Data Be Exchanged?”—Dirk]
- Performance measures (e.g., how to evaluate data from beginning to end of the product lifecycle, and vice versa, can you ascertain the actual change of ownership and transaction flows when examining data extracts)
- Maintain data integrity/accuracy through distribution [see “InBrief: ePedigree Models and Points of Failure”—Dirk]
- Performance of the database when full or partially loaded [see “Could It Be The Cloud? More Thoughts On IBM’s Divestiture Of Its EPCIS And E-Pedigree Suite”—Dirk]
- Database/System Issues
- Controlled/limited access to data by trading partners, FDA or other federal or state officials (data governance) [see “Who owns supply chain visibility data?”, “Data Ownership In The Track & Trace Cloud” and “Global Traceability Data Exchange: Troubled Waters Ahead”—Dirk]
- Status of product at all levels (each, case, pallet): e.g., expired, illegitimate, data error, associated decommissioned product identifier [see “The Coming Battle Over Decommissioning At The Pharmacy” and “Should Pharmacies Decommission EPCs Upon Dispense?”—Dirk]
- Process for redaction of data (may not need to provide all data downstream)
- Verification scenarios [see “Drug Verification: EU Vs US”—Dirk]
- Using 2D barcode at the dispenser level (for verification or other purposes, determine training of personnel or equipment needed)
- Process for investigation of suspect or illegitimate product (including all applicable trading partners), including testing boundaries of the system
- Re-packager Scenarios – how to effectively and reliably link newly-issued product identifier back to original manufacturer product identifier [see “Who Is A DSCSA Repackager?” and “Repackaging Drugs Under A Serialization Regulation”—Dirk]
- Notification Scenarios
- Communication to brand owner when a suspect product is found or when illegitimate product is found and reported to FDA [see “The FDA’s Draft Guidance on Suspect Product, and Farewell Columbus”—Dirk]
- Capabilities of the supply chain and data exchange mechanisms to achieve the statutory reporting timelines due to security, access to data, personal availability
- Exception Handling/Errors/Inconsistencies [see “DSCSA Exception Handling: A Preview of Your Next Surprise Headache”—Dirk]
- Focus on ‘honest mistakes and errors’ (includes aggregation error)
- Fixing over/under shipments (when more data needed or more product needed)
Most of these things can be combined into just one or two pilots. FDA should get the industry to agree on two or three possible high-level supply chain data exchange architectures and design the same pilot around them. Each pilot should deal with a common sequence of data, events and include all of the DSCSA trading partner types, including the full range of sizes from tiny dispensers to multinational companies. In the end, the results should be compared to determine which high-level architecture the FDA and industry to align behind. That is, the goal should be to make a selection. To make a selection, you need to discard those that are not selected, and everyone in the industry must agree to invest resources from that point forward only in that one “winning” selection.
The worst thing the FDA could do is waste time performing a single big pilot with a single high-level architectural approach because it would not allow comparing that approach against others. With that kind of a pilot, someone would have to choose the architecture first, with little more than theory to assist them, and then use the pilot just to demonstrate that it might work. Odds are, that choice of architecture would be made by the most powerful segment. That would be based on politics, not reality. Let’s use the outcome of the pilots to select the architecture that is best overall when considering all segments in the supply chain. Otherwise, why bother “piloting”?
I suggest these high-level architectures for piloting all of the things listed above. These would just be my choices. As long as there are multiple, they don’t have to be these:
- Distributed EPCIS repositories using GS1 EPCIS event formats over AS2 or equivalent for data movement and querying (see “The Viability of Global Track & Trace Models”);
- Semi-Central repositories using GS1 EPCIS event formats over AS2 or equivalent for data movement and querying (see “A Semi-Centralized, Semi-Distributed Pedigree System Idea”);
- Distributed ledger (blockchain) using GS1 EPCIS event formats in the underlying repositories (if not within the blockchain itself) (see “Could Blockchain Technology Be Used For DSCSA Compliance?”).
These would be big pilots so they would need to be designed well to ensure they returned usable results with the least effort/expense.
PICK JUST ONE
The industry and the FDA must choose just one approach for 2023—and they need to choose it several years before 2023—because you can’t allow all of these approaches at the same time and it takes time to develop and deploy the software. My fear is that the FDA and the industry will be too afraid to pick a “winner” in the debate because that also forces them to pick “losers”. But by not picking just one, the resulting “system” would be the opposite of “interoperable”.