GS1’s Serial Shipping Container Code, or SSCC, has been around a long time, but the logistics identifier has recently taken center-stage in a number of controversies related to meeting several country-specific pharma traceability regulations. I’ll cover these controversies in multiple essays—in this one, Brazil.
This controversy started when ANVISA, the pharma regulator in Brazil, indicated in their regulations that they expected companies to mark every “transport package” entering their supply chain with a unique identification code so that each serialized unit inside can be associated with it (the aggregation requirement).
The problem is, a homogeneous case of product can be both a “standard grouping” of the product and a transport package. GS1 recommends that “standard groupings” of product be marked with its own GS1 Global Trade Item Number, or GTIN.
Normally, according to GS1, when you need to add a unique serial number to something that is identified by a GTIN, you must do so by combining the GTIN with a GS1 “Serial Number” data element (Application Identifier 21). The same is true whether that “something” is an individual trade item or a standard grouping of a trade item, which is, itself, a “trade item”. The GTIN of the standard grouping trade item would differ from that of the individual trade item only by the “indicator digit” (for more about constructing GTINs, see “Anatomy of a GTIN” and the GS1 General Specifications).
However, because this standard grouping (a homogeneous cases) sometimes also fills the role of a transport package, ANVISA apparently expects these cases to contain a unique transport identifier, which in the GS1 world would not be a GTIN, but instead would be a Serial Shipping Container Code, or SSCC.
The problem is, at the time manufacturers apply the case identification label, they do not know which cases will serve only as a standard grouping and which will also serve as a transport package. One way to approach this dilemma is to mark every case with a GTIN plus Serial Number at case-packing time, and then, when it is determined that a particular case will also be used as a transport package, also mark it with an SSCC (for GS1’s explanation of an SSCC, see “An Introduction to the Serial Shipping Contain Code”).
Does GS1 allow both an SSCC and a GTIN plus serial number on a single case that is used as a transport package? Yes, in fact, here is an extract from the latest GS1 General Specifications that addresses this exact situation, using the term “logistics unit” in place of ANVISA’s term “transport package”:
“Logistic units are identified with a GS1 identification number called the SSCC (Serial Shipping Container Code). The SSCC is the only GS1 Key that shall be used as the identifier of a logistic unit. The SSCC ensures that logistic units are identified with a number that is unique worldwide.
If, in addition to being a logistic unit, the item is regarded as a trade item by the brand owner, it may additionally be identified with a GTIN. The combination of a GTIN and a serial number must not replace the SSCC as the identifier of a logistic unit.”
OOPS, BUT THAT DOESN’T REALLY WORK
But this would leave two different unique serial numbers on each of these cases—one in the form of a GTIN plus Serial Number, and one in the form of an SSCC. Now, when you are trying to trace each case from point to point in the supply chain, which serial number do you use? I would think the SSCC, but that does not work because some standard grouping cases may start out their lives in the supply chain on a pallet—where they would not need their own SSCC—and later be removed from that pallet and shipped to the next party in the supply chain as logistics units—where they would need their own SSCCs. Other standard groupings (cases) might arrive at the end of the supply chain never becoming a logistics unit. For those that switch from a simple standard grouping to a logistics unit in the middle of the supply chain, who is responsible for adding the SSCC, and how is the new SSCC linked to the GTIN plus Serial Number so they are recognized as the same case regardless which identifier is scanned? Yeah I give up, that’s not going to work.
And there are problems introduced by marking cases with GTINs that reflect a standard grouping. In fact, the primary reason to generate a GTIN for a case of product, and mark the cases with it, is if the standard grouping it identifies might be ordered as a single unit by a customer. For example, they might order a quantity 1 of GTIN X, where ‘X’ is a standard grouping of some standard quantity of a product—that is, a case of product. If we imagine the fixed quantity of the standard grouping is 24, then ordering a quantity of “1” of GTIN X would result in the shipment of a single case of 24 units of the product. But this approach is overloaded with potential confusion about the intended quantity on the order.
I’m not sure how drugs are ordered in Brazil, but this is never done in the United States. Here, if someone wants to order 24 units of a trade item that is a drug, then they order a quantity of 24 of the unit GTIN (or likely, the NDC which the unit-level GTIN is based on). The fact that the manufacturer has a standard grouping of 24 units in a single case does not make much difference unless the manufacturer has a minimum order quantity (which in this example would probably be 24) or recommends ordering larger quantities in multiples of 24 since that’s what the case quantity is. But even in those situations, the quantity ordered always reflects the number of units needed.
It’s fine to define separate GTINs for standard groupings of drugs, just don’t mark your cases that enter the supply chain with them. In my view, they should be for internal purposes only.
JUST PUT AN SSCC ON EVERY CASE PACKED
Under this regulation it may make more sense to skip the GTIN plus Serial Number on cases altogether and just put an SSCC on every case at case-packing time. If it is important to also indicate the GTIN of the product contained within the homogeneous cases, then include Application Identifier (AI) “02”, which is the GTIN of a product contained in a logistics unit, and then any other related data elements, like Lot number (AI=10) and expiration date (AI=17), but do NOT include a serial number (AI=21). Also include the fixed quantity of the trade items included within the case (AI=37) for standard quantity cases.
Be aware that this very logical and GS1-conformant combination of AI’s identified in the paragraph above should not be used for drugs within the United States supply chain. Here the Healthcare Distribution Management Association (HDMA) prefers to continue keeping alive an archaic mis-application of today’s GS1 standards which forces manufacturers to take a non-standard approach that leads to a different set of AIs on cases. This short-sighted decision by the HDMA introduces illogic, confusion and an inability to indicate reality on case labels (more on this in a future essay). But fortunately, everywhere outside the U.S., you can take advantage of these GS1 AI’s to perfectly and clearly identify your logistics unit and their contents.
Using this approach, your ANVISA “transport package” is uniquely identified for tracing purposes using the SSCC’s serial number, and the contents are properly identified for other purposes. You have only one serial number which can be used to trace the transport unit through the entire supply chain, which eliminates confusion. The SSCC can also be used for documenting the shipping containment hierarchy, or “aggregation data”, as necessary.
DOES IT COMPLY WITH ANVISA REQUIREMENTS?
That’s the million dollar question. I can’t tell you that is does or it does not. I can tell you that it conforms to the GS1 General Specification. It appears to comply with ANVISA regulations, from my reading of those regulations, but ANVISA, like HDMA, is known to think differently than GS1 in some cases. The only way to know for sure if the SSCC approach I outline above will comply with their regulations is to get ANVISA to answer that question.
Good luck with that.
Dirk.
This blog post (especially its headline) gives the impression that a “SSCC controversy” was caused by Anvisa. I was a participant in the discussions here in Brazil and I can say this is not the case.
The Brazilian industry associations previously indicated to Anvisa that SSCC would be enough to identify “transportation packages”. Then, the Anvisa team incorporated SSCC in its data format for communicating traceability information.
Months later, a multinational industry justifiably asked GS1 Brazil (by e-mail) whether GTIN+SN could be used for identifying packages in some scenarios, rather than SSCC. A discussion ensued, with a lot of people in different organizations (esp. industries and solution providers) being added in the e-mail “CC:” field, including Anvisa, which was asked to participate in the discussion.
After some e-mail message exchanges, the Anvisa team proposed a data format solution that was flexible enough to acomodate a) SSCC, b) GTIN+SN, and c) other formats. Some messages later, and a consensus was reached on that proposal: after some analysis, the proposed solution was perceived as acceptable to GS1 Brazil, and the original multinational industry that started the discussion was very happy with the outcome on this particular issue.
The situation was perceived as a “SSCC controversy” just because it took about 2 months from the start of the discussion to its conclusion, with everybody agreeing. Of course, before an agreement was reached, industry was afraid an acceptable outcome wouldn’t occur; since the perspectives were initially diverging, no one could be sure at that time. Since the discussion involved a variety of stakeholders, with many details to be sorted out, and with the discussions happening by e-mail (instead of teleconference or presential meeting), the time to reach the consensus was not that long.
While this issue has been overcome, many other topics are under discussion today, however. Supply chain traceability is *very* challenging, and many details need to be sorted out by all stakeholders for it to become an operational reality in Brazil.