I think there is a significant difference between the traceability repositories we see on the market today and those that I think we are likely to see in the future.  Today, traceability repositories are typically implemented by software suppliers as standalone applications or modules that we end users refer to as “an EPCIS”.  We call it that because the most defining characteristic of these modules is that they implement GS1’s Electronic Product Code Information Services (EPCIS) standard.  Today, traceability repository vendors expect customers to buy their traceability module and integrate it with existing applications.  For a long time now I have felt that this approach was less than optimal and I think we will eventually see a switch occur in the software market toward existing application vendors adding traceability repositories and EPCIS interfaces as new features added to their existing functionality.  Let me explain.

FIRST, SOME BACKGROUND

EPCIS is not an application and it is not a repository.  The standard simply defines a set of software interfaces and event definitions that would pass through those interfaces.  The two primary interfaces defined by the standard are the Query interface–for extracting EPCIS events based on specific user-determined criteria–and the Capture interface–for pushing events “into” the EPCIS implementation.  Yes, that implies a repository, and no EPCIS-based system or module could operate properly without one, but the standard doesn’t include any definition of requirements around that repository.  It is left up to the system designer.  Too often, we all (myself included) get lazy and refer to the repository or application included in a specific implementation as “the EPCIS”.  Unfortunately, that kind of lazy reference can lead to blindness to some very useful applications of the standard.  That’s why I’m now trying harder to use the terms “traceability repository”, or “EPCIS-based repository or application”, when that’s what I mean.

According to the GS1 EPCglobal EPCIS standard certification web page, there are currently 17 different software vendors offering certified products that are built around the GS1 EPCIS standard.  These include some of the big names in ERP and business software: SAP, IBM and Microsoft (Oracle is notably missing).  The EPCIS-based products these vendors offer are just that:  traceability repositories that offer a foundation on which other supply chain serial number event-based applications can be built.  Some offer one or more optional applications that are built on top of their own traceability module–applications like returnable shipping container management (often the first application built), and perhaps ePedigree or track and trace for the extended supply chain.

NOT THAT THERE’S ANYTHING WRONG WITH THAT

There is nothing fundamentally wrong with building certain applications “on top” of an EPCIS-based repository module.  For the most part, the kind of applications I listed above are fairly separate from other business applications with few, if any, links so they can be implemented and operate separately.  The problem comes in when you need to integrate traceability into existing business applications like inventory management for example.  In the pharmaceutical supply chain, the two inventory management applications I am aware of are Warehouse Management Systems (WMS) and Pharmacy Management Systems (PMS).

WMS systems help businesses with warehouses and distribution centers–this includes pharma manufacturers, wholesalers and chain pharmacies–keep track of the product in their physical inventories.  PMS systems do the same for individual pharmacies.  PMS systems are very specialized applications that are intended for use by pharmacists and pharmacy technicians within a single pharmacy.  They typically include basic inventory management capabilities in addition to many other functions necessary to operate a modern pharmacy including dispensing, claims submission and tracking, customer management, replenishment order submission and tracking, pharmacy point-of-sale, etc.

Once all drug packages that pass through the U.S. supply chain have serial numbers attached to them (currently anticipated around 2015) these WMS and PMS applications will need to become serial-number-aware.  That’s because the traditional inventory database will have to be kept in lock-step with the serial number inventory that is held in the traceability repository.  They will refer to the same units.  Inventory management in a regulated serialized pedigree environment will not work very well without tight integration with traceability repositories.

In theory, this tight binding will only be necessary for the serialized drugs that are currently in physical inventory.  That’s because it will be vitally important to prevent units received from being added to physical and logical inventory unless a valid pedigree has been received for those exact units.  The same is true of shipments, or removals from physical and logical inventory.  Shipping and receiving operations are an integral part of inventory management applications.  On the other hand, the traceability repository will need to hold a historical record of old events long after the units have been shipped out of the inventory database.  Admittedly, the size of this historical event data will eventually dwarf the size of the current inventory events, but that doesn’t diminish the importance of keeping the two current inventories tightly coordinated.

One way to do it is to add one of today’s traceability repository modules and bind it to one of today’s WMS/PMS systems as closely together as possible through integration code that exercises the standard EPCIS interfaces.  Figure 1 above shows this kind of binding (click the images to enlarge).

Another way to get a tighter binding between the inventory application and the EPCIS-based module is to develop a proprietary interface between them as shown in Figure 2.

Because the interface would be proprietary, both modules would probably have to be offered by the same vendor.  And in fact, some of the current traceability system vendors also market WMS modules (SAP and Oracle).  Those companies are at a theoretical advantage over the others because they could develop a high-performance proprietary interface between their WMS and their traceability modules to accomplish this tight binding (I don’t know whether or not these particular vendors take advantage of that approach).  In my view, this proprietary interface is the key to successful integration of these two types of modules because performance will be essential in an inventory management application and to accomplish that, the integration will have to be very tight.  I don’t think the standard EPCIS interfaces are sufficient for truly high performance interaction between these two kinds of modules.

I’m much less optimistic about the possibility of success in binding a traceability repository from one vendor with the WMS or PMS modules from another vendor because, more than likely, they would be forced to make use of the standard EPCIS interfaces, as depicted in Figure 1.  I’m sure that would work, but I believe that the performance hit this approach would likely take would make it much less desirable compared to the tight integration of a proprietary interface where there are almost limitless opportunities for optimization.

WHERE ARE THE WMS AND PMS VENDORS?

So if all this is true, where are the WMS and PMS software vendors today?  Why haven’t we seen the traditional best-of-breed WMS and PMS systems adding the standard EPCIS interfaces to their existing product offerings as I depict in Figure 2 and 3?

The type of integration shown in Figure 3 should allow for even more performance optimization because everything inside the application box can be optimized for the specific application.

I don’t know why we haven’t yet seen this type of WMS or PMS design, but maybe it has something to do with the time it takes to develop that additional functionality.  Maybe it’s just a matter of time before we see the introduction of this type of product.  Or, maybe these vendors aren’t paying attention to the future needs of the pharmaceutical supply chain.  Or maybe the market isn’t ready yet.  Or maybe they see something I don’t see that would make this architecture less desirable.

It will be interesting to see what develops in the next few years.