Today a client asked me why we are using EDI (Electronic Data Interchange) to transmit ASN (Advance Ship Notice) data to be compliant with DSCSA (Drug Supply Chain Security Act). He had seen an article which inferred that EDI was dying and EPCIS (Electronic Product Code Information Services) was the way to go.

After having all the fun of typing a mouth full of acronyms in replying to his question, I thought I would answer this in a post.

If you have been to an HDMA (Healthcare Distribution Management Association) summit, or have been reading various articles regarding the pending serialization requirements, then you probably have come across EPCIS.

What is EPCIS?

EPCIS is a global standard for adding, querying, and otherwise sharing data regarding “events” that take place on “objects”. An “object” is something you want to track – like and item, lot, package, container, etc. An “event” is when something makes some change to an object – like moving it to a new location.

This standard for sharing data about these objects and events (let’s say items and shipments, to use more common terms) implies that the data is stored in a central place. The EPCIS standard itself does not specify where this data is stored, or by who. The bottom line, however, is that the data is stored in a central repository somewhere, and any appropriate party that is doing events on the objects in this data (distribution center is shipping pharmaceutical products) will have access to add events and/or query data.

When a transaction occurs, like a product barcode being scanned as it is shipped, this transaction is considered a “capture event”. The data captured is then written to the data repository, through some type of call, like a web service, to store the event. Should a party need to gather some information about any of the objects (items) or their past events (transaction history) then the party can execute a “query” to pull data from the repository.

How is that different from EDI?

There are some similarities between EDI and EPCIS – mainly they both use a standard format to define data to be transmitted regarding some transaction. How this happens is completely different. With EDI, all of the data gathered about the transaction is sent off from one party to the next. So the receiving party now has to load this data into its systems, add to this data as transactions occur, and then send this now larger set of data on down to the next party in the supply chain.

With EPCIS, the data is not transmitted from party to party. Instead, the central repository holds the growing set of data related to the objects (say serialized items) in one place. As products move through the supply chain, the affected parties are just adding transactions (events) to the original data set. And, at any time, these parties can query and download any of the related data from the repository.

Is EPCIS better?

Well… Yes. The concept of having one central data repository, and having each party only have to add their transactions to the repository is much more efficient and less cumbersome. This is in contrast to using EDI for DSCSA compliance where you are moving a growing set of data down the supply chain, from system to system, like a snowball.

Why not use EPCIS for Track and Trace Compliance?

The problem is, we are still about 6 years away from required serialization through the supply chain, and there are currently no approved standards for how to share DSCSA data using EPCIS. There are a number of pilot programs testing the possibilities here, and a few big pharma players are pushing for this route. But, with no standard, and no indication from the FDA on requirements right now, it would be difficult to start implementing a solution along these lines at this time.

Until key questions regarding standards of the “events” and who is holding the data repository are answered – and approved by the FDA, it’s a bit difficult to do much planning at this point. As the pilot programs move forward and begin to reveal a more clear direction, then it will be easier to start identifying a plan of action. The big players I see in the pilots are AmerisourceBergen, Cardinal, and McKesson… but I am sure there are others.


ASN’s do have the capability to transmit serialized data, and with the current FDA guidelines, this is the default plan. However, ASNs, with not only serialized data, but history of multiple ownership changes as the product moved through the supply chain, become unwieldy and cumbersome to process and pass from party to party.

With this in mind, I feel that a centralized repository with a standard like EPCIS will prevail. EPCIS, however, is not the only standard in pilot. There are also a number of pharma players looking at Open-SCS (Open Serialization Communication Standard) which is similar in concept.

I also believe that having a WMS system with the capability of transaction based web service calls to a third party will be the preference to communicate with these systems. Just as traditional EDI via a VAN has been moving to data exchange over the internet via AS2, I see sharing data via secure web services (like EPCIS and other API’s) as replacing more traditional forms of data movement.

For more reading, I would suggest these articles:

AmerisourceBergen on Pharmaceutical Commerce

Open-SCS on Pharmaceutical Commerce

EPCIS on Wiki


Steve Bardos, Director, Humanitarian Software Foundation