What an EPCIS shipping event from your wholesaler actually contains

The file you are already receiving

Since 27 August 2025, wholesale distributors have been operating under the enhanced requirements of the Drug Supply Chain Security Act. The practical result for a pharmacy is that every prescription-drug shipment now comes with an electronic file describing it at the package level. That file is written in EPCIS, the GS1 standard for event data, and it is the source of the transaction information and transaction statement the pharmacy is required to hold for six years.

Most pharmacies have never opened one. This post reads a shipping event line by line so that the words on an inspector's list, TI, TS, product identifier, map onto something you can find in the file.

Two versions of the same standard

EPCIS 1.2, ratified in 2016, is XML. EPCIS 2.0, ratified in 2022, adds a JSON and JSON-LD representation and a REST interface. Both are in use in the US pharmaceutical supply chain today, and the GS1 US implementation guideline for DSCSA describes the same events in both. If your wholesaler sends an .xml file it is almost certainly 1.2; a .json or .jsonld file is 2.0. The content is the same set of events; only the syntax differs.

The event that matters: ObjectEvent, shipping

An EPCIS file is a list of events. For a dispenser, the one that carries the transaction is an ObjectEvent whose business step is shipping. It has a fixed set of parts.

eventTime and eventTimeZoneOffset. When the shipment left the wholesaler, with the offset so that a 23:30 event in Memphis is not misread as the next day in your pharmacy.

epcList. The serialized packages in the shipment, one per line, as SGTIN identifiers. An SGTIN is the GTIN of the product, which for a US drug encodes the NDC, followed by the serial number of that specific package. This is the "product identifier" of section 582(a)(14): standardized numerical identifier, plus lot and expiry, on each package. A shipment of 24 bottles has 24 entries.

quantityList. For product still shipped at lot level, an LGTIN identifier, which is the GTIN plus a lot number, and a quantity with its unit of measure.

action. For a shipping event this is OBSERVE. The packages already exist; the event records that they were seen leaving.

bizStep and disposition. bizStep is shipping. disposition is in_transit. These two fields are how a receiving system knows the event is a shipment and not, say, a commissioning or a return.

readPoint and bizLocation. Where the event happened, as a GLN. The wholesaler's distribution centre, typically.

bizTransactionList. The business documents behind the shipment: the purchase order number and the invoice or despatch advice number, each typed. This is the field that lets a receiving system match the file to the physical delivery and the paper invoice.

sourceList and destinationList. The owning party and the location on each side of the transaction, as GLNs. The owning-party pair is the "name and address of the person from whom ownership is transferred" and "to whom ownership is transferred" from the TI definition in 582(a)(25).

Where lot and expiry live

A common surprise: the shipping event itself does not carry lot number or expiry date for serialized packages. Those sit in the commissioning event, which is the event the manufacturer or repackager created when the serial numbers were first assigned. The commissioning event's ILMD block holds the lot number and the item expiration date for every SGTIN it lists.

A well-formed DSCSA file from a wholesaler therefore contains more than the shipping event. It carries, or references, the commissioning and aggregation events needed to resolve every serial in the shipment back to a lot and an expiry. A receiving system that reads only the shipping event has serials with no dates. One that reads the whole file has the complete TI: product, strength and dosage form via the GTIN, container size and count, lot, expiry, transaction date, and both parties.

The transaction statement

The TS is not a native EPCIS field. It is carried in a GS1 US extension on the shipping event, in the healthcare namespace, and it comes in two forms. The single-affirmation form is one element stating that the seller affirms the transaction statement. The itemised form lists the seven affirmations from section 582(a)(26) individually: that the seller is authorized under the Act, received the product from an authorized person, received TI and TS from the prior owner, did not knowingly ship a suspect or illegitimate product, had systems and processes in place to comply with verification requirements, did not knowingly provide false transaction information, and did not knowingly alter the transaction history.

Whichever form your wholesaler uses, the affirmations are the statute's words, and a receiving system should store them as sent rather than collapsing them to a tick.

What is not in the file

An EPCIS shipping event does not tell you whether the packages actually arrived. It does not tell you whether a serial has been seen before elsewhere. It does not verify anything with the manufacturer. It is the wholesaler's statement of what it shipped and under what affirmations. Reconciling it against what is on the dock is the pharmacy's job, and that reconciliation is where the value is: a serial in the box that is not in the file has unknown origin, and a serial in the file that is not in the box is a short shipment to raise with the wholesaler that day.

Vendors also add their own private extensions to the file. Those are not part of the standard and a receiving system is not obliged to read them.

Reading it at the dock

The GS1 DataMatrix scanning page covers how the four application identifiers on a package, GTIN, serial, lot and expiry, are read in one scan. Matched against the epcList, that scan becomes a receipt line with its TI attached. The DSCSA compliance checklist covers the obligations around the file, and the small-dispenser exemption post explains which of them are deferred to 27 November 2027.

ShelfLifePro accepts EPCIS 1.2 XML and EPCIS 2.0 JSON-LD shipping events by file upload, or the wholesaler pushes them to an API key. The TI and TS are attached to the receipt, the expected serials are listed for scanning, and each package is verified against the pharmacy's own records when it is received and again when it is dispensed. ShelfLifePro does not send EPCIS, and it does not consume every vendor's private extension. The full set of dispenser obligations it covers is on the DSCSA for pharmacies page.

Sources: GS1 EPCIS 1.2 and 2.0 standards; GS1 US, "Implementation Guideline: Applying GS1 Standards for DSCSA and Traceability"; 21 USC 360eee-1 (FD&C Act section 582). Nothing here is legal advice.