DSCSA Exception Handling: A Preview of Your Next Surprise Headache

HDMA ASN Exception GuidelinesCompanies that participate in the U.S. pharma supply chain and are subject to the U.S. Drug Supply Chain Security Act (DSCSA) are preparing to meet the FDA’s 2015 deadlines for exchanging Transaction Information (TI)Transaction History (TH), and Transaction Statements (TS) for every shipment.  Those preparations include integrating the generation, transmission, confirmation, storage and retrieval (see “DSCSA: A Closer Look At The Six-Year Record-Keeping Requirement”) of these documents into their existing supply chain and regulatory compliance processes.  It is a big deal and it affects a large number of companies.

With the FDA’s recent announcement that they will postpone enforcement of the transaction data exchange requirement until May 1 (see “FDA Postpones Enforcement of DSCSA Transaction Data Exchange Until May 1”), everyone is hoping things start up and run smoothly from that point on.  I do too, but I fear that companies—including solution providers—are not preparing for what is likely to turn out to be the most difficult part of the data exchange implementation.  That is, handling exceptions.

An “exception” is an honest mistake in a shipment.  They happen to everyone, and in fact, for large wholesale distributors, they happen every day at every distribution center.

A drug that appears on the packing list—and in the DSCSA Transaction Data—is not found in the physical shipment.  Or, something is found in the physical shipment that is not listed in the DSCSA Transaction Data.  Or, an entire shipment is delivered to the wrong destination, but the DSCSA Transaction Data was delivered to the right destination.

When these things happened in the past, companies had various ways of correcting them.  These corrections were aimed at ensuring that the buyer was charged only for what was actually received by them.  This could have included returning extra product, shipment of missing product, billing the buyer for extra product that they decided to keep, etc.  All of these fixes were financial.  Once the buyer and seller were satisfied that the financial transaction was whole between them, the exception was considered “handled”.  How an exception was “handled” could vary from company to company and from transaction to transaction and even from day to day.  The two parties simply had to agree on a fair and financially equitable resolution.

But once companies are engaging in transactions that require compliance with the DSCSA, these common errors could become much more costly headaches.  Let’s take a closer look at one common occurrence and see what might be necessary to resolve it under the DSCSA.

Let’s assume a wholesale distributor mistakenly fills one SKU in a larger order with the wrong product in a shipment to a chain pharmacy.  The TI and TH they sent to the chain pharmacy at the time of the shipment would not match the products received and so the pharmacy would end up with one drug it did not need and would be missing one it still needs—perhaps a little more critically now because of the lost time.

As I said above, there are multiple ways this error could get fixed.  In the past, neither the buyer nor the seller cared about correcting the original Electronic Data Interchange (EDI) Advance Ship Notice (ASN) as long as their agreed upon resolution resulted in a correct invoice.  The invoice was the important thing.  That’s the part that ensures the trading partners are financially whole.

But now, under the DSCSA, the TI and TH will need to be corrected based on whatever the trading partners choose to do to fix the financial and inventory discrepancy.  If the ASN is not corrected, then both the buyer and seller are out of compliance with the DSCSA.  In my example, the DSCSA TI and TH were contained in the original ASN.  What would be necessary to correct the original ASN?

The seller would need to be able to reopen the ASN, adjust the quantities and perhaps the drugs included in the shipment, depending on the specifics of the original error and the agreed resolution.  And then they would need to retransmit the ASN to the buyer, in some cases, keeping the original shipment date and perhaps in other cases, using a new shipment date for the corrected shipment.  Does your ASN-generating program have that capability today?  Not sure?  You might want to check.  And you should also develop Standard Operating Procedures (SOPs) to document how to invoke the most common types of exceptions and the typical resolutions.

Fortunately, GS1 Healthcare US is working on a new version of their DSCSA guidance that will include a number of exception handling scenarios (for GS1 US’s current DSCSA guideline, see “The GS1 Healthcare US Guidance For DSCSA, Vsn 1.1”).  Only problem is, they will probably focus only on handling exceptions with EPCIS events rather than ASNs.  That will not really help most companies until around 2021 or so (see “Will GS1’s EPCIS Be Used Widely For DSCSA Data Exchange?”).

But most fortunately, the HDMA is right on top of this problem!  Last month, while visions of sugar-plum fairies danced in our heads, the HDMA was still working hard and published their “HDMA ASN Exceptions Guidelines for the Drug Supply Chain Security Act”.  It is another “must read” document from the HDMA for anyone using EDI ASNs for the exchange of TI, TH and TS to meet the DSCSA.  Download it, read it, understand it and implement it.  Until the FDA publishes new guidance that specifically addresses exception handling, the HDMA guideline is the best resource to follow.

The HDMA remains the undisputed best source for industry consensus guidance about meeting the DSCSA.  Make sure you check out their other vital guidelines covering:

And subscribe to RxTrace to receive release notices and analysis of future HDMA guidelines.


2 thoughts on “DSCSA Exception Handling: A Preview of Your Next Surprise Headache”

  1. Dirk,
    I work at a Dispenser. Just did another Re-read of the Exception Handling post and decided to reply. You recommend following the HDMA ASN Exceptions Guidelines for the DSCSA when using the HDMA 856 ASN for compliance until the FDA issues its own guidance. I disagree.
    The HDMA guidance significantly differs from what you wrote that compliance would look like in this post “…The seller would need to be able to reopen the ASN, adjust the quantities and perhaps the drugs included in the shipment, depending on the specifics of the original error and the agreed resolution. And then they would need to retransmit the ASN to the buyer, in some cases, keeping the original shipment date and perhaps in other cases, using a new shipment date for the corrected shipment…” This was right on point!

    HMDA acknowledges the need for the seller to provide its customer ‘accurate’ T3 data in “a single document” as outlined in the DSCSA. However, it then condradicts itself by saying there are only two scenario in which the seller would need to provide updated/new T3 to meet FDA requirements, 1)shipment qty greater than ASN; 2) incorrect NDC/Lot# match. Why not in the case of supplier shorts, NDC issues (wrong ndc shipped to what on the ASN),Damaged Product that is either returned or destroyed in place? And how do we void an ASN for a shipment sent to us intended for another end customer? They say in many of these cases the downstream customer has “adequate” T3 if the excess is returned, the mistake is returned or the misshipment is returned then no new T3 is required. But now, we all have inaccurate T3 in our archives.
    I maintain that what you wrote (copied above) is correct but not when you recommend us to follow the HDMA guidelines. What the HDMA is providing as guidance to their member community will NOT keep them in compliance with the FDA on the DSCSA.
    In the end, a dispenser – or any downstream recepient from a MFG – needs to have Accurate T3 for what was transacted/received and to have it in a single document in order to be able to respond to an inquiry from the FDA.
    If their systems can’t do that, then they have some internal work to do as long as they indend to utilize the HDMA 856 ASN as their vehicle to compliance with the DSCSA.

    1. Randy,
      Thanks for your reply and your compliments. You are exactly right that my opinions rarely line up with the HDMA exactly. In fact, the same could be said about my opinions and GS1, GS1 US, the FDA, my former employers and just about everybody else. That’s the fun of being a blogger, isn’t it!?

      But I stand by both my original description of how I think it should work (the part you agree with) and my recommendation that companies follow the HDMA guidance until the FDA provides their own guidance (the part you disagree with). The reason is that interoperability necessitates a common approach in these instances (see “Interoperability And The DSCSA“). In this case, HDMA is offering a consensus opinion of how exception handling should work–albeit, a consensus mostly of wholesale distributors–and, more than likely, many companies will follow it. That provides “cover” until the FDA provides more specific guidance.

      It is not surprising that the HDMA guidance offers a minimalist approach to exception handling. We see the same thing in their recommendation for an abbrieviated Transaction Statement (see “HDMA Has Updated Their EDI ASN Guidance For DSCSA, Again“. If the FDA eventually accepts this shortened version, great. It is not hard to incorporate it into existing EDI and EPCIS implementations. If they later say the HDMA version is insufficient, OK, then you can switch to whatever the (probably less convenient) FDA version is at that time. In the absence of particular FDA guidance, it is probably safe to assume the simple case rather than the complex case.

      The complexity (read, $$$$) of exception handling can quickly get out of hand if you always assume the complex case. The HDMA has proposed the simple case. If the FDA later instructs the industry that this is considered “non-compliant”, then make the necessary changes at that time along with everyone else. On the other hand, if you do not think you can remain in compliance without additional documentation, then inform your supplier that you will require additional/corrected documentation in every situation, or you will return the entire shipment. If you are a very large dispenser, chances are your wholesale distributor(s) will figure out a way to provide you with what you want. If you are a small chain pharmacy or an independent, you might not have much recourse but to accept what your supplier gives you. If the FDA later balks, maybe you can then bring your supplier(s) into the discussion with them at that time.


Comments are closed.