Pharmaceutical manufacturers, whole sale distributors, dispensers and re-packagers that constitute the United States drug supply chain are busy these days in a thorough restructuring around their core operations. The restructuring is part of country-wide preparations aimed at achieving total compliance with the guidelines for transaction data exchange laid down in the recently passed US Drug Supply Chain Security Act.
The involved companies are expected to establish mechanisms that track and trace Transaction Information (TI), Transaction History (TH) and Transaction Statements (TS) for every shipment. The instated mechanism must have provisions to integrate generation, transmission, confirmation, storage and retrieval of the documentation associated with the exchange, and needs to be in place before the FDA’s deadline of 1st May, 2015. That’s a whole lot of work, and a number of companies are pumping in all resources at their disposal to get done with it, hoping that the intricate transaction data exchange would work like a charm from 1st May onwards.
There’s a catch though – too much of a broad focus on the exchange mechanism might result in companies overlooking an important underlying decision: how to handle exceptions. An exception handling process gone bad is all that it takes to bring your track-and-trace mechanism to a halt.
“It turns out that an exception refers to an honest mistake (rather than an intentional malice) during a shipment. Companies makes such mistakes frequently”
So, what exactly is an exception, anyway and why should companies care? It turns out that an exception refers to an honest mistake (rather than an intentional malice) during a shipment. Companies makes such mistakes frequently – especially distributors generating exceptions is a commonplace occurring.
An exception can manifest itself in the medical supply chain in either one of the following three ways:
That said, exceptions are a novel occurrence by no means. Exceptions in the drug supply chain exist since ever. Traditionally, companies had a number of ways of handling and correcting exceptions including return of the extra product, re-shipment of the missing product, additional billing in case of surplus shipment, etc. Most of these quick fixes ensured the customer was not being overcharged in case of an exception. Upon due satisfaction exhibited by both the selling and the buying parties, an exception was mutually agreed upon as being handled. In essence, the process of exception handling was not standardized and varied across different companies at a transactional level. All that was needed was the involved parties agreeing upon a fair solution to the then prevalent situation.
Times have changed now. Once companies have established data exchange mechanisms that enable conformity to the DSCSA guidelines, exception handling is going to become a system-wide headache if not addressed properly.
Consider the example of a wrong product in a shipment sent out to a pharmacy. The TI and TH in this case would exhibit a mismatch when stacked against the products received. The pharmacy would be stuck with a drug it didn’t order in the first place and missing on an important drug that was originally ordered. Handling this simple exception is not going to be as easy as it was prior to the introduction of the DSCSA. Why? Because both TI and TH will need to be corrected at the end of multiple trading partners involved in the supply chain. This, in turn, would most likely require reopening the electronic data exchange, advance shipment notice and performing associated edits. The same would need to be done with the transaction data maintained by all trading partners involved – way easier said than it’s actually done.
And now the good news. We’ve painstakingly incorporated exception handling capabilities in our state-of the-art, cloud-based server, making compliance with transaction data exchange requirements laid down in the DSCSA ridiculously simple. Here are some examples on how we handle this:
1. Most of the EDI solutions out there won’t allow you to search and correct your old ASN’s. The TrackTraceRx EDI capabilities will allow your organization to correct any previously received ASN’s.
2. Correcting outbound T3s can be a challenge. One of the challenges is to make changes and work with downstream trading partners to apply the necessary corrections. In a scenario where an outbound T3 was sent, having communication with a downstream trading partner is essential in making these changes in a corporative manner. TrackTraceRxstreamlines this process so when changes are made, the entire supply chain is aware and onboard with the needed corrections.
3. When handling exceptions, it’s important to keep a trail of the original T3 and what was changed in case an audit verification is requested. Showing proof of your previous changes are a must. Our logging capabilities excels all other solutions by time stamping every change that is done within the system and by whom.
Feel free to drop us a lineand discover how we can help you with exception handling in particular, and DSCSA compliance in general.