What Should FDA Pilot?

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.


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.


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:

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:

These would be big pilots so they would need to be designed well to ensure they returned usable results with the least effort/expense. 


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”.