DQSA: How Should Transaction Data Be Exchanged?

FDALogoThe U.S. FDA just published a docket asking for public input into standards for the interoperable exchange of information for tracing of human, finished, prescription drugs in paper or electronic format.  Ironically, they will accept responses to the docket in either paper or electronic format.  Comments should be submitted to the FDA within 60 days.  If my calculation is correct, you have until April 21st to submit your comments.

This docket was expected because the Drug Supply Chain Security Act (DSCSA), enacted last November, gives the FDA one year to publish a draft guidance document that establishes standards for the interoperable exchange of that type of information, and they are required to consult with the industry and other interested parties [see Section 582(a)(2)].  I have written about this requirement and the short time after the guidance is published before the members of the supply chain must make use of those standards (see “The Flaw That Must Be Addressed in H.R. 3204, The Drug Quality and Security Act” and “DQSA: Getting To Electronic Transaction Data Exchange“).  This docket fulfills the first of many mandates that the FDA is facing in

their own road to compliance with the wishes of Congress as expressed in the DSCSA.

The request contains some specific questions that people may wish to respond to, or you are welcome to provide your pertinent ideas and preferences without responding to those questions.  The questions are designed to draw out those ideas and preferences.  In effect, the FDA wants to know what standards and techniques are already in use by companies in the supply chain for exchanging transaction information, transaction history and transaction statements (all of these terms are defined in Section 581 of the DSCSA and in the RFC) in paper or electronic form.  No sense reinventing the wheel.

But they also want to know what practices, processes or systems are in use today to exchange information about prior transactions, and for providing, receiving and terminating notifications that an illegitimate product has been found in the supply chain.  If you currently use paper methods for exchanging this kind of information, the FDA wants to know when you are planning to move to an electronic format?  They want to know if there are any standards or current practices that you would recommend for the FDA to consider as a model, and if there are other technologies, systems, or solutions you are aware of that are available now that would enable that exchange.


For those of us who have been working on the technology standards and processes for protecting the pharma supply chain for a while now, this is the age-old question.  Which technology?  Which standard?  And since not everyone is going to agree on “the one”, who should decide?  Of course, now it will be the FDA, but Congress has made sure that they will listen to the industry and other interested parties.  As I pointed out last fall, the industry needs to organize and really drive the decision—and they should not just leave it up to GS1 Healthcare US—(see “DQSA: The U.S. Pharma Supply Chain Must Organize, Or Risk Failure”).

Click on image to enlarge.
Click on image to enlarge.

Interestingly, the 2014 RxTrace U.S. Pharma Traceability Survey, sponsored by Frequentz, asked a couple of questions designed to find out what people are thinking along these lines.  One of those questions was,

Which technologies will be used to fulfill the requirement to pass transaction information, transaction history and transaction statements immediately after January 1, 2015?

As you can see from the graph (click the image to enlarge it), more than half of the respondents thought that Electronic Data Interchange (EDI) would be used, half thought that paper packing lists would be used, more than 40% thought that GS1’s EPCIS would be used, and so on.

I was a little surprised that the GS1 Drug Pedigree Messaging Standard (DPMS) was so far down the list with only about 25% of respondents thinking it would be used.  DPMS was designed first to carry exactly what is contained in the DSCSA transaction information, transaction history and transaction statements at the lot level.  It was “purpose-built” for exactly that.  But, of course, applications based on GS1’s Electronic Product Code Information Services (EPCIS) standard would probably be better suited after the 10 year point, when serial numbers will need to be included in the transaction information, and the requirement for passing transaction history (the “pedigree”) is eliminated.

Overall I think it will be very difficult to introduce any new technology or standards for exchanging this information in the face of EDI already being used so pervasively by the larger companies in the industry.  That goes for DPMS and EPCIS.  But EDI is currently designed as a point-to-point data exchange technology that is intended to describe the current shipment.  It will be necessary to come up with a way to include previous Advance Ship Notices (ASN) to fulfill the transaction history requirement, and some way to meet the requirements of the transaction statement.  How ever this is done, it needs to be standardized and described in a way that solution providers can produce products that are compatible and therefore interoperable.  All that takes time.

It will be very interesting to read the comments that the FDA receives.  They will then need to prepare a response of their own to each of the most valid comments and publish that along with their draft guidance, when they will probably ask for more comments later this year.

By the way, the survey question above was just one of the many interesting questions that were asked in the RxTrace survey.  Also asked was,

“Which technology(ies) do you think the industry will eventually settle on after a year or two to fulfill the requirement to pass transaction information, transaction history and transaction statements?”

Download a free copy of the results here.  You will need to create an account on the Frequentz site to get to the download link.