DSCSA Compliance, Done Right

EPCIS Events Explained

The Electronic Product Code Information Services (EPCIS) standard, maintained by GS1, is the backbone of DSCSA interoperable data exchange. Every transaction in the pharmaceutical supply chain generates EPCIS events that document who handled a product, when, where, and why. Under EDDS, trading partners must exchange these events at the package level using standardized formats.

There are four core EPCIS event types relevant to DSCSA. ObjectEvent records an observation or action on one or more products — this is the most common event type and covers shipping, receiving, and dispensing. AggregationEvent captures parent-child relationships, such as when individual packages are packed into a case or cases onto a pallet. TransactionEvent links business transactions (purchase orders, invoices) to specific product identifiers. TransformationEvent handles repackaging or kit assembly where input products are transformed into different output products.

Each event contains a standardized set of dimensions known as the "what, when, where, why" framework. The "what" identifies the specific products using their serialized GS1 identifiers (SGTINs). The "when" captures the event timestamp in UTC. The "where" specifies the business location using GLN (Global Location Number) and optional sub-site identifiers. The "why" describes the business context through a combination of business step (e.g., "shipping," "receiving") and disposition (e.g., "in_transit," "in_progress").

Here is an example of an EPCIS ObjectEvent representing a dispenser receiving a shipment of serialized drug products. DSCSA implementations use XML-based EPCIS 1.2, though we show a simplified representation below for readability:

<ObjectEvent>
  <eventTime>2026-09-15T14:30:00.000-05:00</eventTime>
  <eventTimeZoneOffset>-05:00</eventTimeZoneOffset>
  <epcList>
    <epc>urn:epc:id:sgtin:0363391.012345.100000001</epc>
    <epc>urn:epc:id:sgtin:0363391.012345.100000002</epc>
    <epc>urn:epc:id:sgtin:0363391.012345.100000003</epc>
  </epcList>
  <action>OBSERVE</action>
  <bizStep>urn:epcglobal:cbv:bizstep:receiving</bizStep>
  <disposition>urn:epcglobal:cbv:disp:in_progress</disposition>
  <readPoint>
    <id>urn:epc:id:sgln:0363391.00001.0</id>
  </readPoint>
  <bizLocation>
    <id>urn:epc:id:sgln:0363391.00001.0</id>
  </bizLocation>
  <bizTransactionList>
    <bizTransaction type="urn:epcglobal:cbv:btt:po">
      urn:epc:id:gdti:0363391.00001.PO-2026-4521
    </bizTransaction>
  </bizTransactionList>
  <extension>
    <sourceList>
      <source type="urn:epcglobal:cbv:sdt:owning_party">
        urn:epc:id:pgln:0341234.00000
      </source>
    </sourceList>
    <destinationList>
      <destination type="urn:epcglobal:cbv:sdt:owning_party">
        urn:epc:id:pgln:0363391.00000
      </destination>
    </destinationList>
  </extension>
</ObjectEvent>

GS1 Identifier Formats

DSCSA mandates that all prescription drug packages carry a unique product identifier encoded as a 2D data matrix barcode. This identifier combines four data elements defined by GS1 standards: the National Drug Code (NDC) expressed as a GTIN-14, a unique serial number, the lot number, and the expiration date. Together, these elements form the Serialized Global Trade Item Number (SGTIN).

The GTIN-14 is a 14-digit number derived from the NDC. The FDA provides a specific mapping: the NDC's labeler code, product code, and package code are zero-padded and combined with a GS1 Company Prefix indicator digit and a check digit. For example, NDC 12345-678-90 maps to GTIN-14 00312345006789 with check digit 0. Getting this conversion right is critical — a single digit error means the product cannot be verified.

The 2D data matrix barcode encodes these elements using GS1 Application Identifiers (AIs):

AI (01)  GTIN-14:     00312345006789  (14 digits)
AI (21)  Serial:      ABC123XYZ456    (up to 20 alphanumeric)
AI (17)  Expiry:      261130          (YYMMDD format)
AI (10)  Lot Number:  LOT2026A        (up to 20 alphanumeric)

Full barcode string:
(01)00312345006789(21)ABC123XYZ456(17)261130(10)LOT2026A

URN format (used in EPCIS):
urn:epc:id:sgtin:0312345.006789.ABC123XYZ456

A common source of errors is the NDC-to-GTIN conversion. The FDA's NDC Directory uses three formats (4-4-2, 5-3-2, 5-4-1), and each must be converted differently to reach the correct GTIN-14. Many pharmacy systems store NDCs without leading zeros, which silently produces incorrect GTINs. This is the single most common technical failure in DSCSA implementations — and one of the first things we check during any assessment.

VRS Verification Flow

The Verification Router Service (VRS) is the industry-standard mechanism for product verification under DSCSA. When a dispenser (pharmacy) needs to verify the authenticity of a product, they send a verification request containing the product's SGTIN to the VRS network. The VRS routes the request to the appropriate manufacturer's verification responder based on the GTIN's GS1 Company Prefix.

The verification flow works as follows. First, the pharmacy scans the 2D data matrix barcode on the product package, extracting the GTIN, serial number, lot, and expiry date. The pharmacy's system formats a verification request and sends it to a VRS Lookup Directory — this is a centralized registry maintained by participating solution providers that maps GTIN prefixes to manufacturer verification endpoints.

The VRS Lookup Directory returns the URL of the appropriate manufacturer's verification responder. The pharmacy system then sends the full verification request (GTIN + serial + lot + expiry) to that endpoint. The manufacturer's system checks whether the serial number was legitimately produced, has not been recalled, and has not been flagged as suspect. It returns a response indicating whether the product is verified, along with the verification timestamp and any applicable status codes.

The entire round trip must complete within seconds to be practical for pharmacy operations. Under EDDS, dispensers must have the capability to verify products upon request from the FDA or a trading partner. Suspect and illegitimate products must be quarantined immediately, and the FDA must be notified within 24 hours. This means your VRS integration cannot be a theoretical capability — it must be tested, operational, and understood by your staff.

LSPedia OneScan integrates directly with the VRS network and handles both sides of the verification flow — the requestor role (for dispensers verifying products they receive) and the responder role (for manufacturers responding to incoming verification requests). The platform manages the entire VRS workflow end to end: barcode scan at the point of receipt, GTIN lookup against the product master data, VRS Lookup Directory query to resolve the manufacturer's verification endpoint, the actual manufacturer endpoint call with full product identifiers, response processing and status interpretation, and automatic exception flagging for any verification that returns a "not verified" or inconclusive result. Failed verifications are immediately routed into OneScan's exception management workflow for investigation and resolution.

ATP Credentialing

Authorized Trading Partner (ATP) credentialing is the trust layer of the DSCSA ecosystem. Before exchanging transaction data or responding to verification requests, trading partners must confirm that the other party is a legitimate, licensed participant in the pharmaceutical supply chain. This prevents counterfeit operators from injecting fraudulent data into the system.

ATP credentialing involves verifying state pharmacy licenses, DEA registrations, and FDA establishment registrations against authoritative databases. Several third-party credentialing services exist to automate this process, cross-referencing multiple data sources and maintaining continuously updated registries of credentialed partners.

For pharmacies, the practical implication is that you must maintain current, accurate licensing information with your credentialing provider. If your state license lapses, your DEA registration expires, or your business information changes (name, address, ownership), your ATP credential may become invalid — and your trading partners will be unable to share transaction data with you until it is resolved. We can help you establish credentialing processes that prevent these disruptions.

xATP by LegisYm is the leading digital ATP credentialing platform, enabling real-time credential verification through the Open Credentialing Initiative (OCI). Rather than manual license lookups and periodic batch verification, xATP provides a continuously updated, digitally signed credential that trading partners can verify programmatically before every data exchange. LSPedia OneScan integrates directly with xATP for automated ATP verification — when your organization exchanges EPCIS data through OneScan, the platform automatically checks your trading partner's ATP credential status before processing the transaction. No manual license lookups, no spreadsheets of expiration dates, no compliance gaps from overlooked renewals. The combination of LSPedia and xATP gives trading partners a fully automated trust layer: every data exchange is preceded by an automated credential check, ensuring that you are only sharing sensitive pharmaceutical transaction data with verified, licensed participants in the supply chain.

The 2% Problem

In industry discussions — including at HDA conferences — a persistent theme is the "2% problem." While the vast majority of pharmaceutical transactions flow smoothly through serialized systems, roughly 2-5% of packages encounter issues: unreadable barcodes, mismatched serial numbers, incorrect GTIN mappings, damaged labels, or data discrepancies between what the sender shipped and what the receiver scanned.

At scale, 2% is enormous. A mid-size distributor processing millions of packages per month faces tens of thousands of exceptions requiring manual investigation. For pharmacies, even a small percentage of unscannable or unverifiable products creates workflow disruptions, quarantine backlogs, and potential patient care delays.

Solving the 2% problem requires a combination of better barcode quality (GS1 DataMatrix print specifications), robust exception handling workflows, clear escalation procedures with trading partners, and systems that can gracefully handle mismatches without halting operations. This is where deep implementation experience matters — we understand which failures are systemic versus one-off, and how to build systems that handle both.

Exception Handling

DSCSA defines specific procedures for handling suspect and illegitimate products. When a pharmacy identifies a product that fails verification — meaning the manufacturer's system does not confirm the serial number — the product becomes "suspect" and must be quarantined. The pharmacy must then conduct an investigation to determine if the product is illegitimate (counterfeit, diverted, stolen, or intentionally adulterated).

If a product is determined to be illegitimate, the pharmacy must notify the FDA and all immediate trading partners within 24 hours. The product must not be dispensed and must be disposed of according to applicable regulations. If the investigation concludes the product is not illegitimate (e.g., the verification failure was due to a data error), the product can be returned to saleable inventory once the discrepancy is resolved.

Common triggers for suspect product investigations include: verification response indicating "not verified," physical evidence of tampering or counterfeiting, a product received from an unauthorized trading partner, or a notification from the FDA or a trading partner about a specific lot or serial number. Your SOPs must clearly define who in your organization is responsible for these investigations, what documentation is required, and how to contact the FDA's Office of Criminal Investigations (OCI) if needed.

Saleable Returns

Saleable returns are one of the most operationally painful aspects of DSCSA compliance. When a pharmacy returns a product to a wholesale distributor — for reasons like overstock, short dating, or formulary changes — the distributor must verify the product before placing it back into saleable inventory. This verification requirement fundamentally changes the economics and logistics of the returns process.

Under EDDS, the distributor must scan the 2D DataMatrix barcode on each returned package, extract the SGTIN, and send a verification request through VRS to the original manufacturer. The manufacturer must confirm the product is legitimate, has not been recalled, and has not been reported as suspect. Only after receiving a positive verification response can the distributor return the product to saleable inventory.

The challenge is scale. A large distributor may process tens of thousands of returns per day. Each return requires individual package-level scanning and verification — a dramatic change from the pre-DSCSA process of accepting returns at the case or lot level. Many pharmacies have also discovered that returned products with damaged or unreadable barcodes cannot be verified and may be rejected outright, creating financial losses.

To minimize returns friction, pharmacies should invest in proper barcode label protection (avoiding label damage during storage and handling), maintain accurate internal records linking physical product to EPCIS transaction data, and establish clear returns SOPs that include pre-verification scanning before shipment back to the distributor. Catching a verification failure before you ship the return saves time, money, and trading partner frustration.

Release 1.3 Requirements

The GS1 US EPCIS Implementation Guideline for DSCSA Release 1.3 introduces several important refinements to the existing XML-based EPCIS 1.2 standard. While the core data format remains XML, Release 1.3 tightens requirements around event granularity, master data exchange, and aggregation handling.

Release 1.3 also tightens requirements around event granularity. Prior versions allowed some flexibility in how aggregation events were captured — for example, some implementations only tracked case-level movements. Under Release 1.3, the full hierarchy from pallet to case to package must be captured and maintained throughout the supply chain. When a case is opened and individual packages are distributed, the disaggregation event must be recorded.

The master data requirements have also been clarified. Trading partners must exchange CBV (Core Business Vocabulary) master data — including product descriptions, GLN locations, and party information — using standardized formats. This master data must be kept current and shared with trading partners to enable meaningful interpretation of EPCIS events.

For pharmacy systems that implemented EPCIS support based on earlier releases, an upgrade assessment is critical. The differences between Release 1.2 and 1.3 are not cosmetic — they affect data formats, required fields, event types, and master data exchange patterns. Our assessment includes a gap analysis against Release 1.3 requirements and a migration plan that minimizes disruption to your daily operations.

Common EPCIS Error Patterns

One of the most frequent EPCIS validation failures we encounter is a missing eventTimeZoneOffset element. This is a required field in the EPCIS 1.2 schema, but many systems omit it because the eventTime already contains a timezone offset in its ISO 8601 value. The problem is that lenient internal validators accept the event, but when it reaches a trading partner running a strict schema validator — which is standard practice at the Big Three distributors — the event is rejected outright. The fix is simple, but finding it requires knowing that the two fields serve different purposes in the EPCIS specification.

Another common issue is incorrect use of Core Business Vocabulary (CBV) URN prefixes. The original EPCIS specification used the urn:epcglobal:cbv:bizstep: namespace prefix, but GS1 has since updated this to a new namespace structure. Some systems still generate events with the deprecated prefix, and while many receivers accept both for backward compatibility, others do not. During the Release 1.3 migration, trading partners are increasingly enforcing the updated namespace, and events using the old prefix are being flagged or rejected. We see this most often in systems that were implemented early in the DSCSA timeline and have not been updated since.

SGTIN formatting errors are particularly insidious because they produce URNs that look valid but encode the wrong product identity. The SGTIN URN format urn:epc:id:sgtin:CompanyPrefix.ItemRef.Serial requires that the partition indicator — which determines where the GS1 Company Prefix ends and the Item Reference begins — matches the actual length of the company's GS1 prefix. When a system constructs an SGTIN URN from a scanned barcode, it must know the correct partition value for that company prefix. Many implementations hardcode a single partition value, which works for their own products but produces malformed URNs when processing products from manufacturers with different prefix lengths.

Finally, extension element ordering causes subtle failures in EPCIS 1.2 XML documents. The XML schema defines a specific sequence for elements within the event body, and extension elements (such as sourceList and destinationList) must appear in the correct order within the <extension> block. Out-of-order elements pass lenient parsers but fail strict XSD validation. This error is especially common when development teams build EPCIS event generators from documentation examples rather than validating against the actual GS1 schema files. We always recommend automated schema validation as part of every EPCIS implementation pipeline.

Choosing the Right DSCSA Platform

LSPedia is the leading DSCSA serialization and compliance platform in the United States, and their OneScan platform is what we recommend for the vast majority of organizations. LSPedia is not limited to a single trading partner type — their platform is used by manufacturers, wholesale distributors, dispensers (pharmacies), repackagers, and 3PLs. OneScan supports the full DSCSA lifecycle: serialization and commissioning, EPCIS data exchange, VRS verification (both requestor and responder roles), exception management, ATP credentialing integration, and audit-ready reporting. No other platform covers all of these capabilities with the same depth and reliability.

What sets LSPedia apart is their trading partner network. OneScan connects to all major wholesale distributors including McKesson, Cardinal Health, and Cencora — the Big Three that control the majority of U.S. pharmaceutical distribution. LSPedia's network is the largest in the industry, which means that when you onboard to OneScan, you are connecting to a live, proven infrastructure that already handles EPCIS data exchange at massive scale. You are not building connections from scratch — you are joining an existing network where most of your trading partners are already participating.

For independent pharmacies and small chains, OneScan is purpose-built for dispensers with pharmacy-friendly workflows. The onboarding process is straightforward, the interface is designed for pharmacy staff (not IT engineers), and LSPedia's support team understands dispensing operations — not just the technical standards. For multi-site chains, OneScan provides a centralized compliance dashboard with per-location exception tracking and management, aggregated reporting across all sites, and automated credential monitoring. You get a single pane of glass for compliance across your entire organization.

For manufacturers, LSPedia provides serialization line integration, commissioning event generation, VRS responder capabilities, and master data management across hundreds of downstream trading partners. For distributors, OneScan handles EPCIS exchange at scale with hundreds of trading partners, returns verification, and exception management with automated workflows. SAP ATTP (Advanced Track and Trace for Pharmaceuticals) remains the enterprise option for global manufacturers with multi-market serialization requirements across different regulatory regimes — but for organizations focused on U.S. DSCSA compliance, LSPedia delivers equivalent or superior functionality with significantly less implementation complexity and cost.

RedSail Technologies (BestRx and PioneerRx) offers integrated DSCSA modules for pharmacies running those specific pharmacy management systems. If your stores are on BestRx or PioneerRx, RedSail's embedded approach puts compliance directly into the dispensing workflow without requiring a separate application. For pharmacies on any other PMS platform, LSPedia OneScan is the clear choice.

Regardless of which platform you choose, remember that interoperability is the foundational principle of the EPCIS standard — any compliant platform can exchange data with any other compliant platform. Do not let trading partner pressure drive your platform decision. That said, choosing a platform with the largest existing network of connected partners reduces your onboarding friction and time to compliance. This is where LSPedia's market position provides a tangible operational advantage.

FDA Enforcement and Inspection Readiness

The FDA has taken a phased enforcement approach to DSCSA compliance, initially focusing on good-faith compliance efforts rather than punitive action. During the stabilization period following the November 2023 deadline, the agency prioritized education and engagement — working with trading partners who were actively implementing systems rather than penalizing those still in progress. However, this leniency is narrowing as each deadline passes. The FDA has made it clear that the window for "we're working on it" is closing, and organizations that cannot demonstrate meaningful progress toward full compliance face increasing regulatory risk.

Understanding what an FDA inspection looks like in practice is critical for readiness. When FDA investigators arrive — or more commonly, when they issue a data request remotely — they will ask for transaction data for specific products identified by GTIN or serial number. You must be able to produce the complete chain of custody for that product within 24 hours: who manufactured it, who distributed it, when you received it, what the EPCIS events show, and whether verification was performed. This is not a summary or a spreadsheet — they want the actual transaction data, the EPCIS event records, and evidence that your systems are operational and your staff know how to use them.

The consequences of failing to produce this data are severe. Products for which you cannot demonstrate a complete chain of custody may be quarantined, effectively removing them from your saleable inventory. For importers, the FDA can issue import alerts that block future shipments. Civil monetary penalties can reach up to $500,000 per violation, and intentional violations — such as knowingly accepting product without proper documentation or falsifying transaction records — can result in criminal charges under the Federal Food, Drug, and Cosmetic Act.

LSPedia OneScan's audit reporting module is specifically designed for FDA inspection readiness. The platform can generate FDA-ready response packages directly from your EPCIS data — complete chain of custody reports for any product by GTIN or serial number, verification history, exception investigation records, and ATP credential status at the time of each transaction. When the FDA asks for data, you should be able to produce it in minutes, not days. OneScan makes that possible.

Data Quality and Exception Management

Data quality is the number one operational challenge in DSCSA compliance. It is not the technology that creates the most pain — it is the data flowing through it. Every trading partner in the pharmaceutical supply chain generates and consumes EPCIS data, and the quality of that data varies enormously. When the data is clean, compliance is automated and invisible. When it is not, you get exceptions — and exceptions require human intervention, investigation, and resolution.

The most common exception categories fall into predictable patterns. Barcode scan failures due to damaged labels, poor print quality, or ink bleeding on the 2D data matrix are the most visible. EPCIS data mismatches — where what was shipped according to the sender's EPCIS event does not match what was received at the scanning station — are the most operationally disruptive. NDC-to-GTIN mapping discrepancies, where the national drug code on the product does not correctly resolve to the expected GTIN in the master data, cause silent failures that may not surface until an audit. Missing master data — a product that exists in the physical world but has no corresponding record in the serialization system — creates verification dead ends.

Exception rates compound at scale. A 2% exception rate sounds manageable in isolation, but a distributor processing one million packages per month generates 20,000 exceptions requiring manual investigation. Each exception requires root cause analysis, communication with the trading partner, documentation, and resolution. Without a systematic approach, exception backlogs grow faster than your team can resolve them, and unresolved exceptions create compliance risk.

LSPedia OneScan's exception management dashboard is built specifically for this problem. The platform categorizes exceptions by type, prioritizes them by severity and age, and provides root cause analysis tools that identify patterns — for example, if 80% of your barcode scan failures come from a single manufacturer's packaging line, OneScan surfaces that insight so you can escalate directly with the trading partner. The platform tracks exception resolution workflows, maintains audit trails for every investigation, and provides escalation tools for communicating with trading partners about recurring issues.

The most important step in managing data quality is measuring it. If you do not know your baseline exception rate, you cannot improve it. We help organizations establish exception rate benchmarks, identify their top exception categories, and build systematic reduction plans. The goal is not zero exceptions — that is unrealistic in a system with millions of daily transactions. The goal is a known, measured, and continuously declining exception rate with clear ownership and resolution timelines.

Multi-Site Compliance Management

Maintaining consistent DSCSA compliance across multiple pharmacy locations, distribution centers, or manufacturing sites introduces a category of challenges that single-site operations never encounter. Each location needs its own Global Location Number (GLN) — this is non-negotiable, as the GLN is how the EPCIS system identifies where a product was received, stored, or dispensed. Each location also needs its own scanning hardware, its own trained staff, and its own exception handling procedures. But compliance oversight must be centralized — you cannot have fifty locations making independent decisions about suspect product investigations or ATP credential management.

LSPedia OneScan's multi-site capabilities address this directly. The platform provides a centralized compliance dashboard that aggregates data across all locations while maintaining per-location granularity. Compliance officers can see exception rates by site, identify locations that are falling behind on scanning compliance, monitor ATP credential status across the entire organization, and generate aggregated reporting for FDA requests. Per-location exception tracking ensures that when a problem occurs at a specific site, it is routed to the right people for investigation — not lost in a centralized queue.

The most common pitfalls in multi-site deployments are avoidable with proper planning. Sharing a single GLN across multiple locations — which some organizations attempt to simplify setup — makes it impossible to determine which site actually received a shipment, rendering your EPCIS data useless for chain of custody purposes. Inconsistent scanning procedures across locations, where one site scans every package and another only scans exceptions, creates gaps in your transaction data. Staff turnover at individual locations is particularly dangerous — when the one person who understood the DSCSA scanning workflow leaves, that location's compliance can silently degrade until the next audit or FDA inspection exposes the gap. Automated credential monitoring across all locations ensures that a lapsed license at a single site does not disrupt data exchange for your entire organization.