EDDS: The New Data Exchange Requirements

The Enhanced Drug Distribution Security (EDDS) phase of the Drug Supply Chain Security Act (DSCSA) is due to begin on November 27, 2023.  That’s the first day that the US pharma supply chain is supposed to fully operate with serial numbers.  Yes, serial numbers in human readable and encoded into 2D barcodes will be on every drug packaged after November of this year, but there is only limited use of those serial numbers in the supply chain until 2023.  But when the EDDS starts, everything changes.  From that point on, every Transaction Information (TI) document must include the full DSCSA Unique Identifiers—including the serial numbers for the first time—that are physically included in the shipment, the Transaction History (TH) no longer needs to be exchanged, and the data exchange requirements change.  Let’s focus in on those data exchange changes.

Because the TH goes away in the EDDS, the only transaction documents that must be passed from seller to buyer in the supply chain are the TI and the Transaction Statement (TS).  Currently (prior to the start of the EDDS), TI, TH and TS are being exchanged by manufacturers, wholesale distributors and larger dispensers through Electronic Data Interchange (EDI) file exchange (see “Will EPCIS Event Exchange Replace EDI ASNs for DSCSA Someday?”).  Today, both the sender and recipient save those documents away for six years in case of an investigation (see “DSCSA: A Closer Look At The Six-Year Record-Keeping Requirement”).  For smaller dispensers, their wholesale distributor probably stores their transaction documents in an online portal for their access in case of an investigation (see “A Closer Look At Web Portals for DSCSA Transaction Data Exchange”).


When the EDDS begins, data exchange will have to change.  According to DSCSA Section 582(g)(1)(A), in the EDDS,

“The transaction information and the transaction statements as required under this section shall be exchanged in a secure,  interoperable, electronic manner in accordance with the standards established under the guidance issued [by the FDA]…”

In preparation for the start of the EDDS, the FDA is required to update their existing draft guidance on data exchange that was originally issued back in 2014 (see “FDA Publishes Draft Guidance For DSCSA Data Exchange”) and this time publish it as “final guidance”, “…not later than 18 months after holding the public meeting on the interoperable standards necessary to enhance the security of the pharmaceutical distribution supply chain…”.  The existing draft guidance published in 2014 was for the exchange of lot-based transaction data, and it must be updated to the final guidance published in the next 18 months so that it:

“(i) identifies and makes recommendations with respect to the standards necessary for adoption in order to support the secure, interoperable electronic data exchange among the pharmaceutical distribution supply chain that comply with a form and format developed by a widely recognized international standards development organization;

(ii) takes into consideration standards established pursuant to subsection (a)(2) and section 505D;

(iii) facilitates the creation of a uniform process or methodology for product tracing; and

(iv) ensures the protection of confidential commercial information and trade secrets.”

The cryptic language in (ii) above, “…section 505D…” refers to the Standardized Numerical Identifier (SNI) guidance that was published by the FDA in early 2010 and was originally commissioned by Congress in the FDA Amendments Act way back in 2007 (see “FDA Aligns with GS1 SGTIN For SNDC”).  FDA indicated at that time that they intended to publish other guidance documents aimed at fulfilling the mandate of section FD&C 505D but they never did.

As I pointed out last week, the December FDA DSCSA Public Meeting appears to have included the topics necessary to trigger the 18 month clock on the final data exchange guidance (see “2018: The Year of FDA DSCSA Public Meetings”).  We’ll see if they can get it done in that time.  If you have anything you want to say to the FDA about data exchange in 2023 before they finalize that guidance, you’d better submit a written comment to their current DSCSA docket.  They are required to publish it in draft form, collect comments and update it before they publish it in final form, but comments now will help ensure their first draft is closer to your preferences.

Just like the exchange of lot-based TI, TH and TS today, the exchange of TI and TS in the EDDS phase will be point-to-point.  That is, only two parties will be involved in each exchange and they know each other because they just engaged in a significant financial transaction—the sale/purchase of prescription drugs.  The content of the TS will not change, but the TI will need to include all of the serial numbers in the shipment.  That will cause these documents to grow significantly for larger shipments, like those from manufacturer to wholesaler.

I’ve said in the past that today’s use of EDI ASNs will not likely be used to carry those future TI documents.  GS1 Electronic Product Code Information Services (EPCIS) makes more sense because it is specifically designed to carry information about events occurring with serialized product.  EPCIS does not have any security built into it because it only defines how data would be formatted, not how it would be secured or transmitted.  For that, you just need a secure point-to-point transmission protocol, like AS2 for instance.  For smaller dispensers, EPCIS documents can be made available by larger wholesale distributors via the same portals that they currently offer to their customer.  Of course, these approaches only make sense if the FDA includes them in their final data exchange guidance.


That takes care of the point-to-point data exchange of TI and TS, but what about the new need placed on all members of the supply chain in the EDDS by Section 582(g)(1)(E) to “…promptly facilitate gathering the information necessary to produce the transaction information for each transaction going back to the manufacturer…”?  That is, the TH would only be constructed when it was necessary, for things like dealing with recalls and investigating suspect product.

As far as I can tell, this is why the industry is investigating blockchain technology (see “Blockchain Reigns At GS1 Connect 2017“).  Blockchain isn’t needed for the exchange of TI and TS, because those transaction documents only need to be transmitted from seller to buyer, point-to-point, just like they are today.  But when you start thinking about what it will take for the members of the supply chain to facilitate gathering the TIs for each transaction going back to the manufacturer, and then add in all of the security issues, data ownership rights, access rights and data possession preferences in the industry, you start searching for technologies like blockchain.

The question is, if we need blockchain—or something else—to meet the surprisingly difficult requirement to promptly facilitate gathering the TIs back to the manufacturer, should we expect that technology to also do the mundane point-to-point data exchange of the TI and TS documents?  I’m not so sure.  What if we only use blockchain—or whatever we end up with—in the rare instance when someone needs to collect the TIs back to the manufacturer?  In this approach, that would be its only role.  Yes, everyone would need to make all of their TIs accessible to that solution, but the technology would not be made to do multiple unrelated things.  It would not be used to do the simple, everyday point-to-point exchange of TI and TS for every shipment AND the rare instances when gathering all of the TIs for a given set of SNIs is necessary.

Likewise, neither EPCIS nor blockchain should be expected to distribute supply chain master data, whether product or party.  Just use GS1 GDSN for that (or HDA’s Origin) (see “What The TraceLink v HDA Lawsuit Teaches Us About The Value of Supply Chain Master Data”).

Instead of trying to find one silver bullet technology that solves all three requirements, maybe each of these requirements should be implemented with the technology that makes the most sense independently.  We might end up with a more reliable solution for all requirements, and in that case they could end up being less expensive to operate over time.  Think about it, and leave a comment whether your agree or disagree.