Avoid these EPCIS interoperability pitfalls

Pfizer recently shared the results of an EPCIS pilot test it conducted with McKesson, during a webinar it conducted with Tracelink  in April 2012. All participants in the pilot were well-versed in EPCIS, yet they still ran into interoperability issues because different companies were using and interpreting the standards in different ways.

Because the EPCIS standard was designed to be highly flexible to support a variety of use cases across many industries, there is room for different interpretations of how those standards might be applied.

Here are the interoperability pitfalls Pfizer uncovered:

1. All trading partners must adopt the EPCIS guidelines in the same way.  This includes:
• Rules for common use of GLN, DEA, or HIN for identifying Sold From, Ship From, Sold To, and Ship To parties
• Common interpretation of what value to assign to data elements: Sold To is different from Bill To
• How to represent the Sold From and Sold To party if they lack a GLN
• Agreement on which method should be used for the business transactional identifier, since several are allowed in the GS1 core business vocabulary—for example, PO Number, ASN Number, RMA Number, etc.

2. All trading partners must follow a common interpretation of EPCIS events and extensions for each use case. This includes:
• Shipping product, confirming product receipt, returning product, confirming return receipt, shipping a repackaged product, exception use cases, etc.
• Which combination of EPCIS events is used for each use case
• Which event business steps and dispositions are used
• Which GS1 US Healthcare extension data elements are used
• Which data elements are truly required versus optional for each use case
• When a data element is optional in the XML schema, when is it conditionally required for a specific use case
• The GS1 US Rx Guideline spells out the exact format of each and every EPCIS event and attribute.

3. Watch out for dependencies, repurposed data elements, and precedence relationships:
• Avoid creating dependencies on the presence of optional data elements.  Otherwise your software application may break when that data element is not present in a given transaction.
• Avoid repurposing data elements for different meanings.  Not everyone may provide a given data element in the way you expect. Always try to follow the intended meanings of the guidelines. This can be hard sometimes, because the standards can be a bit ambiguous.
• Avoid building in restrictive precedence relationships for events created by business processes managed by upstream supply chain partners. A classic example is the relationship between the commissioning event and the aggregation event. If your software assumes that the event time for when the aggregation occurs must always be after the commission time, it creates a potential point of failure. That’s because it is possible for the item- and case-level aggregations to have identical event times, depending on how aggregation capture is implemented on the packaging line. Overly restrictive rules that make assumptions about one event preceding the other could cause product to be rejected by a downstream trading partner.

If in doubt, check with your supply chain partners to confirm you are both following and interpreting guidelines in the same way before you begin exchanging event data.

Making exceptions for the exceptions
Not all supply chain events can yet be depicted in EPCIS events. These are known as exceptions, and they tend to fall into the area of reverse logistics, such as returns or recalls. The Rx Secure Supply Chain Working Group within GS1 US maintains a list of exceptions. The list can be found in the current Rx Guideline. The next version of the guideline is expected to provide the choreography of EPCIS events that trading partners can use to address problems if they occur.

Exception 1: Overage
Exception 2: Shortage
Exception 3: Pedigree Serial# Discrepancy
Exception 4: Pedigree Lot# Discrepancy
Exception 5: Pedigree Serial# And Lot# Incorrect
Exception 6: Product Inference Problem
Exception 7: Quantity Inference Problem
Exception 8: Physical Inventory Overage
Exception 9: Physical Inventory Overage (Concealed Overage)
Exception 10: Physical Inventory Shortage (Concealed Shortage)
Exception 11: Pedigree Contains Incorrect Customer/Location Information
Exception 12: Pedigree Contains Incorrect Product Information
Exception 13: Pedigree Contains Incorrect Reference# Information
Exception 14: Pedigree (Or EPCIS Ship Event) Not Received By Customer
Exception 15: Undelivered Shipment
Exception 16: Lost Shipment
Exception 17: Received Physical Product From An Unidentified Sender
Exception 18: Missing
Exception 19: Could Not Read Pedigree Data Due To Security Mismatch
Exception 20: Pedigree Data Not In Correct Format
Exception 21: Good Product - Damaged Barcode Or RFID
Exception 22: Damaged Product - Good Barcode Or RFID
Exception 23:  Damaged Product - Damaged Barcode Or RFID
Exception 24: Damaged Shipment
Exceptions 25 And 26: Resolved – Have Been Accounted For In Other Exceptions
Exception 27: No Parent-Child Aggregation
Exception 28: Pedigree Data Incomplete
Exception 29: Pedigree Data Has Broken Chain
Exception 30: Shipped Product To Wrong Customer & Pedigree Data To Correct Customer
Exception 31: Customer Refuses Order
Exception 32: Unauthorized Return
Exception 33: Shipment For Wholesaler “Y” Arrives At Wholesaler “X”

Liked this article? Download the entire playbook here.