EPCIS Explained

At a recent GS1 discussion group meeting one of the moderators acknowledged that they need to create a clear explanation for exactly what EPCIS is.  I’ve never been very impressed with GS1’s ability to explain their own standards at a high-level for non-technical readers.  They do a great job of explaining them at the minutia-level, but that’s the problem.  Non-technical people who must make decisions about GS1 standards probably get bogged down in that minutia and end up not really understanding what it is, why it is significant, and why they should use it.  Too much technical documentation exists on how to apply EPCIS, and not enough documentation on the why.

Here is how GS1 describes EPCIS on the EPCIS Standard download page and in the introduction of that document:

“The goal of EPCIS is to enable disparate applications to leverage Electronic Product Code (EPC) data via EPC-related data sharing, both within and across enterprises. Ultimately, this sharing is aimed at enabling participants in the EPCglobal Network to gain a shared view of the disposition of EPC-bearing objects within a relevant business context.”

Hmmm.  Not very helpful, is it?  Here is more text from the EPCIS standard introduction:

“The EPCIS standard was originally conceived as part of a broader effort to enhance collaboration between trading partners by sharing of detailed information about physical or digital objects. The name EPCIS reflects the origins of this effort in the development of the Electronic Product Code (EPC). It should be noted, however, that EPCIS does not require the use of Electronic Product Codes, nor of Radio-Frequency Identification (RFID) data carriers, and as of EPCIS 1.1 does not even require instance-level identification (for which the Electronic Product Code was originally designed). The EPCIS standard applies to all situations in which visibility event data is to be captured and shared, and the presence of “EPC” within the name is of historical significance only.”

Better?  At least we know that the letters “EPC” aren’t so relevant anymore, but is that helpful?  The Introduction continues:

“With or without persistent databases, the EPCIS specification specifies only a standard data sharing interface between applications that capture visibility event data and those that need access to it. It does not specify how the service operations or databases themselves should be implemented. This includes not defining how the EPCIS services should acquire and/or compute the data they need, except to the extent the data is captured using the standard EPCIS capture operations. The interfaces are needed for interoperability, while the implementations allow for competition among those providing the technology and implementing the standard.”

There.  Do you see the word “interoperability” above?  That’s a key part of it.  The problem with this description is that it uses terms that most people are unfamiliar with, like “visibility event data”.  And, if you are familiar with GS1’s traditional standard, the Global Trade Item Number (GTIN) you don’t see any connection with it in this explanation.  And, while they explain what the letters “EPC” mean from a historical view, they don’t explain what the term “Information Services” means.


Let’s start from scratch.  EPCIS is an expansive and complex GS1 interface standard, based on eXtensible Markup Language (XML).  XML is a way of expressing data and operations in simple text files that are both human- and machine-readable.  XML is a description language.  EPCIS uses XML to describe the exact components and layout of each type of “event” and their operations.  EPCIS is primarily aimed at documenting “Events”, which are actions that can happen to physical objects within a supply chain.  EPCIS defines two interfaces that can be used to “capture” (generate new EPCIS events) and “query” those events.  An “event” is an action that contains components that describe its “What”, “When”, “Where” and “Why”. 

That’s about it, but it still won’t make much sense to non-technical people, so further explanation is necessary.  The term “objects” can refer to products, homogeneous product groupings (cases, pallets, etc.) and even things like returnable containers (reusable totes, pallets, etc.).  The type of events that can occur to objects in a supply chain include object identification, aggregation of children objects (trade items or containers) with parent objects (containers), transformation of one or more objects into one or more different objects, and association with some kind of transaction between trading partners in the supply chain.  More details can be added to further describe real-world events because EPCIS is designed to be extensible, in the extreme.   Just about anything and everything can be extended to match the requirements of the supply chain application.

GS1 also defined a companion standard to EPCIS that must be used together, called the Core Business Vocabulary (CBV).  CBV is a list of potential business steps, dispositions and business transaction types that can be used within EPCIS events to further describe the actions being taken on objects in a supply chain.  As you might expect, CBV is also extensible to allow for business-specific business steps, dispositions and business transaction types.  When combined with CBV, EPCIS can be used to describe a very wide range of actions that can occur to products and objects in any given supply chain, even without making use of their extensibility. 

Each physical object or class that is the subject of an EPCIS event can be identified within that event using a Uniform Resource Identifier (URI) syntax.  Fortunately, GS1 provides that syntax for GTIN+Serial Number (SGTIN), Serial Shipping Container Code (SSCC), Global Returnable Asset Identifier with serial number (GRAI) and ten lesser used serialized identifiers, including the syntax for non-GS1 serialized identifiers.  In addition, there are also “class-level” URIs defined, including GTIN+Batch/Lot (LGTIN), GRAI without serial number and five lesser used non-serialized identifiers, including non-GS1 class-level identifiers.  Of course, these identifiers can be depicted within GS1 barcodes or Radio Frequency IDentification (RFID) tags.


I wanted to explain what “visibility data” is because it is often a stumbling block for non-technical people to understand the power and significance of EPCIS.  GS1 likes to use that term, but I try to avoid using it because few people know what it means intuitively.  In my view, the term is a little archaic.  In short, “visibility data” is data that describes the actions and movements of products within a supply chain.  EPCIS events constitute visibility data. 

The term made more sense when GS1 expected everyone to use RFID tags on all products and shipping containers and RFID readers would be located on every dock door, conveyor and major intersection within warehouses.  An EPCIS event would have been constructed each time a physical product or container was “observed” by one of these readers.  The collection of those events would provide you with the visibility into your products as they pass through your supply chain.  Unfortunately, this concept did not account for product and data ownership rules.  I’m sure it works fine in Walmart’s supply chain, but not so much in today’s pharma supply chain.


Remember, EPCIS is an interface standard.  Technically, there is no such thing as an “EPCIS repository”, although lots of vendors and users claim they have one.  All you really have is a data repository that implements the EPCIS Capture and Query interfaces, so that all data going into and out of the repository must be formatted as EPCIS events.  EPCIS defines the format of the data as it is being moved between trading partners and between data repositories, but it says nothing about how that data must be stored while it resides within a data repository. 

The primary impetus for GS1/EPCGlobal to create the EPCIS standard was to offer a way of sharing supply chain data in an interoperable way.  To achieve interoperability, the format of the data exchanged between companies in a supply chain must be well defined and tightly controlled, as it is with EPICS, but once a company is holding that data, it can be stored in any way that makes sense locally. 


In the future, a blockchain could be defined so that the blocks either contain or point to EPCIS documents that contain EPCIS events describing a set of actions taken on a set of objects/products in a supply chain.  In fact, a lot of very smart people are trying to figure out the best way to do exactly that.  Rather than every member of a supply chain having their own repository where they capture and query EPCIS events, the blockchain would be used for that purpose.  That is, this blockchain would be EPCIS conformant because it would recognize EPCIS events and know how to store and exchange them. 

Another way to look at it is that the implementation of the EPCIS Capture and Query interfaces of this “distributed repository” would recognize and interact with this blockchain, rather than a private repository.  The security of such a blockchain is the complex part, so that unauthorized users cannot see private or semi-private data.

Wow, that was a lot of text just to explain EPCIS.  I hope you can see that EPCIS is very complex and powerful for interoperable supply chain data exchange.  As we get closer to 2023 I expect the standard to take center stage for the industry to meet their Drug Supply Chain Security Act (DSCSA) responsibilities.  We just need to get busy as an industry and with the FDA to figure out how it will all fit together.  And we are quickly running out of time.