Serial Number Bonding

There are some discontinuities between the needs of the industry for meeting serialization regulations around the world and certain GS1 standards, including their Electronic Product Code Information Services (EPCIS) and Core Business Vocabulary (CBV) standards.  I’ve already pointed out the issue of EPCIS expecting everyone who uses it to possess, by default, a GS1 Global Location Number (GLN) (see “GLN: The Lowly Identifier That Could Kill The Use Of EPCIS For Pharma Regulatory Compliance”).  Here is one more.

SERIAL NUMBER BONDING

GS1 traditionally likes to break down their offerings into three buckets:  Identify, Capture and Share.  Just recently, they have added a forth bucket:  Use (see https://www.gs1.org/standards#use).  A big part of GS1’s current work, and the future of the organization, revolves around Identify, Capture, Share and Use of serialization within commercial supply chains.  The problem is, GS1’s current standards offerings, contained within those four buckets, fail to fulfill the needs of manufacturers who are faced with implementing serialization on their products.  To even get to the point where a supply chain can make use of serialization of products, manufacturers of those products need to be able to reliably get the serial numbers onto those products.  This is where GS1 standards are lacking.

The successful use of serialization in any supply chain relies on the unambiguous-ness of the serial numbers.  That is, everyone must be able to count on the fact that the manufacturer never produces any duplicate serial numbers, and the data associated with each serial number always accurately reflects the physical product they are attached to.  This is particularly true of pharma supply chains because regulatory penalties, reputations and even lives are at stake. 

Yes, GS1 has identifier standards (“identify”), and barcode standards (“capture”), and supply chain data formatting standards (“Share”), and high-level application standards (“use”), but they are missing important standards that are necessary to enable those they do have.  Let’s call the missing bucket of standards “bond”, as in, standards necessary for “bonding” a GS1 identifier to a physical product or entity.  In the existing sequence of GS1 standards buckets, “bond” might fall between “identify” and “capture”.

GS1 places its EPCIS and CBV standards firmly inside the “Share” bucket.  That’s because these standards are intended to help members of supply chains share data necessary to implement new and more efficient applications (those applications are in the “Use” bucket).  Up to now, EPCIS events were generally expected to document sharable business events within a supply chain.  Usually, the first EPCIS event for a given serial number is the “Commission” event, and the last event is the “Decommission” event.  (Technically there are no official EPCIS events called “Commission” or “Decommission” but there are event structures that reflect these exact operations so people refer to them using these terms.)  “Commission” is generally viewed as the first event because it is the one that establishes the association between the unique identifier (GTIN + serial number, SSCC, etc.) and a description of the physical product instance that identifier is “bonded” to. 

A Commission event by itself is not what I mean by “bonding”.  A Commission event is a logical association between an identifier and a collection of data.  “Bonding” is based on data too, but more importantly, it includes the sequence of mechanical and electrical actions necessary to actually assign, generate and encode a barcode (and/or RFID tag) with the target unique identifier, and then physically place it onto the physical package that is the instance of the product.  The Commission event associated with that unique identifier is the culmination of the bonding process but the steps that precede it are every bit as important to the success of all subsequent events.  Theoretically the GS1 EPCIS standard will allow some EPCIS events to occur prior to a “Commission” event, but I’m not aware of any in actual practice, yet (more on this below).

The “Commission” event is one step within the “bonding” processes.  In fact, it is the last step.  It turns out, the “bonding” steps necessary prior to the “Commission” event are a lot more complex than most people realize.  If the bonding processes are performed poorly, the “Commission” events produced will be unreliable, and that will have a very negative impact on the “Share” and “Use” processes.  And those are the processes that companies in the pharma supply chain will rely on for compliance with laws like the Drug Supply Chain Security Act (DSCSA), the Falsified Medicines Directive (FMD) and the comparable laws in Brazil, South Korea, China and elsewhere.  So it is important to everyone that the bonding processes are always performed as perfectly as possible.  That requires standardization.

There are many solution providers who are in the business of helping pharma manufacturers, CMOs and repackagers perform those bonding activities as close to perfect as possible.  My company, Systech International, is one of those, and there are many others.  Today, each of the solutions these companies offer make use of their own proprietary approaches to those bonding processes.  Many of these companies, including Systech, are members of the OPEN-SCS group that is working on standardizing the data communications between the various functional layers of a typical serialization bonding installation.  That way, a single solution can be more easily and safely built from “mixed and matched” components from multiple vendors (see “The Open Serialization Communication Standard, Open-SCS”).  This will be more critical in the future as the inevitable mergers and acquisitions take place between pharma manufacturers after these initial investments have been made.

Fortunately, the people working on OPEN-SCS want to ensure that their completed efforts will work seamlessly with GS1 standards wherever those standards touch theirs.  And they touch a lot.  Of course, the product identifiers and serial numbers being bonded to the drug packages are usually GS1-conformant (depending on the target regulation), and the barcodes being encoded and applied are usually GS1-conformant.  But throughout the bonding processes, data are being collected that will be used at the highest OPEN-SCS level to populate EPCIS Commission events, as well as corporate databases that will be used as part of the mandated (in some regulations) verification process (see “Drug Verification: EU Vs US”) (and other internal quality processes that are not tied directly to supply chain serialization regulatory requirements).

To accomplish this seamless operation between OPEN-SCS and GS1 standards, the OPEN-SCS standard will need to build something I will call EPCIS event “primitives”.  That is, data records that look just like EPCIS events, but are produced prior to the existence of an official EPCIS Commission event.  These are all leading up to the official publication of the Commission event.  If something goes wrong as these early bonding actions are being taken, or, in some cases, when something goes right and it just results in the termination of the bonding sequence for a given serial number, an official EPCIS Commission event may not occur for that unique identifier.  Because these “primitives” can be saved locally, an accurate history of the successful or failed bonding process for that unique identifier can be retained by the manufacturer when necessary or desirable.

As I mentioned above, in the typical time sequence of EPCIS events, the Commission event is normally the first one, but the CBV standard actually allows two types of events to occur before it.  Those contain the BizSteps “reserving” and “encoding” (see the CBV 1.2 standard).  Official EPCIS events constructed with these business steps can occur prior to the Commission event for a given instance-level identifier.  That’s great, because both of these concepts match up nicely with some of the bonding steps.  The problem is that there are not enough of these pre-commission BizSteps to properly document all of the “primitives”, as determined by OPEN-SCS.  There are just too many distinct steps in the bonding processes that need to be documented.

GS1 may view the domain of EPCIS and CBV as being defined more by data sharing between trading partners than between contract partners like manufacturers and contract manufacturers.  Although, I would argue that the existence of these two pre-commission BizSteps are an indication that some people have done some work to define it more broadly.  What we need is some cooperation between OPEN-SCS and GS1 to expand the number of pre-commission BizSteps so that these “primatives” can be fully recognized EPCIS events.  That would allow them to be stored in the manufacturer’s EPCIS repository and exchanged with their contract partners.  I can’t see any reason these events would ever be passed to their trading partners, but that’s why the question of the intended domain of EPCIS and CBV is so important.

Should EPCIS/CBV be limited to only documenting change of ownership of serialized products in a supply chain?  Or should it be sufficiently wide to also help companies and their contract partners unambiguously bond the unique identifier to the physical products?  I vote for the later.  How about you?

I’m  going to speak about how OPEN-SCS and GS1 standards interoperate next week at GS1 Connect.  Join me there.

Dirk.

2 thoughts on “Serial Number Bonding”

  1. Dirk, this was a particularly insightful essay. Let’s hope it fosters closer cooperation between OPEN-SCS and GS1 in pursuit of more comprehensive EPCIS support of “primitives”. At the least you have clearly articulated for your readers the fact of pre-commission “bonding” events that ought to be widely understood and agreed (standardized) and uniformly captured and recorded, ideally within the framework of EPCIS. It seems to me that such an enhanced EPCIS model, with its robust support for “primitives” and process documentation at the “bonding” level would certainly enhance the overall GS1 system. Whether “bonding” is separate from and then subsequent to “Identify” is something I’m not sure I agree with but I’m all in on “Identify, Capture, Share, and USE!”

    1. George,
      Right. It is not important for GS1 to add “Bonding” to their list of buckets, but it is vital that they recognize the importance of the bonding processes and the need to include pre-commissioning events to help those who make it happen.

      Thanks for your insights.
      Dirk.

Comments are closed.