The U.S. Food and Drug Administration (FDA) published their “Standardized Numerical Identification (SNI) for Prescription Drug Packages – Final Guidance” document almost two years ago (see my essay “FDA Aligns with GS1 SGTIN For SNDC” from back then).  The guidance was published as purely non-binding recommendations that reflected the Agency’s current thinking, but in my opinion it is a nice piece of work and can be used as a practical guide, as far as it goes, for implementing drug serialization programs today.

Why is that?  It’s because drug manufacturers and repackagers need to serialize all of their prescription drugs that enter the state of California in 2015/2016.  Can those companies make use of the FDA’s SNI guidance to comply with the serialization requirements of the California Pedigree Law?  I will answer that question in this essay, but first…

A REVIEW OF THE FDA SNI GUIDANCE

According to the FDA, an “SNI” is a unique identifier that is attached to a prescription drug by the original manufacturer.  Presumably “unique” means unique within the United States.  Specifically, an SNI is either a “serialized National Drug Code (sNDC)” or one of the existing recognized standards for identifying and labeling certain blood and blood components and certain minimally manipulated human cells, tissues and cellular and tissue-based products (HCT/Ps) which do not currently use NDC numbers.  The guidance document mentions only ISBT 128 for this latter class of SNI and implies that there may be others.  Apparently those standards always result in a unique identification number for each product package.  The important thing to realize is that an the sNDC is only one type of SNI but it is the kind that should be used on any prescription drug product that has been assigned an NDC.  In this essay I am only going to discuss the sNDC type of SNI.

The FDA defines the sNDC as being composed of the drug’s 10-digit NDC plus an alphanumeric serial number that can be up to 20 characters long.  The guidance applies to prescription drugs only so Over-The-Counter (OTC) drugs that are identified by an NDC apparently aren’t covered.  But since the guidance is non-binding anyway this distinction isn’t really significant.  Perhaps it will if the SNI guidance ever becomes a required regulation.

Example of the components of an sNDC borrowed from the FDA SNI Guidance document. March 2010. Click image to enlarge.

The SNI guidance document itself defines the SNI “for package-level identification only”, but it also makes it clear that SNIs can also exist for levels other than the package-level, like cases and pallets.  It’s just that this guidance document doesn’t cover those.  The FDA defines the “package-level” this way:

“…the smallest unit placed into interstate commerce by the manufacturer or the repackager that is intended by that manufacturer or repackager, as applicable, for individual sale to the pharmacy or other dispenser of the drug product.”

Repackagers that break the manufacturer’s package down and repackages the contents in any way must apply a new and unique SNI to the new package-level and that new SNI must be linked (in some unspecified way that I assume is a database) back to the manufacturer’s original SNI.  The guidance document contains an excellent example of a package of six drug-filled syringes that would be the lowest packaging level that the hypothetical manufacturer intended pharmacies or other dispensers to buy, but is then repackaged by another hypothetical party acting as a repackager into single syringe packages for sale to pharmacies or other dispensers.

The original hypothetical manufacturer would only need to assign an SNI to the package of six drug-filled syringes since it does not intend the syringes for individual sale.  However, the hypothetical repackager would need to assign each drug-filled syringe its own unique SNI and link those six SNI’s to the original manufacturer’s SNI that was assigned to the specific package of six that the individual packages came from.  If you repackage drugs you should study the example in the FDA SNI guidance document.  Of course, since this guidance is not binding the FDA isn’t saying that you have to do this today.

The FDA recommends that the SNI should generally “…be applied to each package in both human-readable and machine-readable forms.”  However, the FDA guidance document explicitly states that “…at this time, FDA is not specifying the means of incorporating the SNI onto the package.”  But it goes on to say that “The SNIs described in this guidance are compatible with, and flexible for, encoding into a variety of machine-readable forms of data carriers, such as 2-dimensional bar codes and radio-frequency identification (RFID)…”.  The document also explicitly doesn’t specify a location on the package where the SNI should be placed, but it does say that any human-readable form could be printed “…in a non-contiguous manner…” from the existing NDC printed on the package.

THE RELATIONSHIP BETWEEN sNDC AND GS1 sGTIN

Finally, the guidance document points out that the sNDC “…is compatible with, and may be presented within, a [GS1] GTIN…”.  GTIN is a GS1 standard for general product/service class-level identification and the letters stand for “Global Trade Item Number” (see my essays “Anatomy of a GTIN” and “Depicting An NDC Within a GTIN”).  It is quite clear that what the FDA meant to say is that the sNDC can be depicted as a serialized GS1 GTIN, or “sGTIN”.  It does not say that an sGTIN is the only way to depict an sNDC or that you must depict it that way, it simply says that it may be presented that way.

The document doesn’t identify any other way to do it but I’m pretty confident you could present an sNDC using HIBCC standards too if you wanted to.  HIBCC product identification standards are very rare in the U.S. pharmaceutical supply chain (they are much more common in the medical devices supply chain) so I’m not covering them in this essay.  For more on HIBCC standards click here.

CAN THE sNDC BE USED TO COMPLY WITH THE CALIFORNIA SERIALIZATION REQUIREMENT?

This question is frequently asked these days.  Fortunately the answer is definitively “yes” in my opinion.  You should read the source documents to convince yourself one way or the other, but here is my logic.

The text of the California pedigree law says that each drug package distributed within the state must have a “unique identification number” attached to it.  Presumable “unique” here means unique within the state of California.  The law doesn’t specify any specific characteristics of the identifier itself other than its uniqueness and that it be “…contained within a standardized nonproprietary data format and architecture, that is uniformly used by manufacturers, wholesalers, and pharmacies…“.  The FDA sNDC is a “unique identification number” and by definition it must be unique, presumably within the U.S., and it is a standardized nonproprietary data format and architecture and it is certainly capable of being uniformly used by all parties in the U.S. pharma supply chain, which fulfills the California requirement.

The language in the California law and the Questions and Answers about the law that was published by the California Board of Pharmacy in 2008 regarding who must apply a unique identifier, to what and when it must be done is comparable to the language in the FDA’s SNI guidance.  This includes the definition of the “package-level” and the need for a unique identifier attached to repackaged drugs and how that identifier must be linked to the original manufacturers unique identifier.  Of course, the language in the California documents was available to the FDA when they were constructing their language.

So far I haven’t found a single significant difference in characteristics of the unique identifier defined by California and the sNDC defined by the FDA.  This leads me to conclude that California will very likely accept the use of unique identifiers that conform to the FDA sNDC guidance for compliance with the serialization requirements of their pedigree law.  It also makes perfect sense that they would.  Again, that’s my opinion.  You form your own.

DEPICTING AN sNDC IN A BARCODE USING GS1 GTIN PLUS SERIAL NUMBER

OK, so you agree with me and you want to print an FDA-compliant sNDC on your drug packages within a machine-readable barcode using GS1 standards in advance of the compliance dates for the California pedigree law.  The way to do it is to make use of “The GS1 System”.  Here I’m referring to the GS1 Application Identifier standard and certain barcode symbologies that are documented fully in the GS1 General Specification. Search for this specification on the internet or contact your local GS1 Member Organization (MO) to obtain a copy.

The GS1 System Application Identifier standard defines a way of encoding multiple pieces of information within a string of characters in an exact way so that a reader can extract them back into their original decomposed form.  There are lots of Application Identifiers (AI) covering a wide spectrum of data types needed in a supply chain context.  An AI is a two-to-four-digit code that identifies the type of data that follows it in an “element string”.  In our particular instance, we are interested in just two AIs: one for the GTIN (AI=”01”) and one for the serial number that is associated with that GTIN (AI=”21”).

A GTIN element string is always 14 digits long when it is depicted using AI “01”.  Remember that the FDA defined their serial number as being up to 20 alphanumeric characters.  That means that it is a variable length value ranging from 1 to 20 characters.  It is a happy coincidence that GS1 defines their serial number element string for AI “21″ in exactly the same way!  Well, in fact, the FDA made the decision to specifically align their definition with that of GS1’s existing AI “21″ definition so that there wouldn’t be any conflict if people chose to use GS1 standards to implement the sNDC.

If we put together the technique I described in my essay “Depicting An NDC Within a GTIN” with the information above, we get the following shortcut for the GS1 string of elements that depict an sNDC:

sNDC to GS1 string of elements shortcut. Click image to enlarge.

Now all we need to do is encode this string of characters into one of the GS1 barcode symbologies that accommodate a GS1 string of elements.  These include GS1-128 and DataBar for linear barcodes and GS1 DataMatrix for 2D barcodes.  See the GS1 General Specification for details on how to properly construct these barcodes.

(NOTE:  According to the HDMA only a subset of the possible DataBar family of symbologies should be used on pharmaceuticals in the U.S. supply chain and they should only be used on products that are very tiny.  See my recent essay “Updated HDMA Barcode Guidance: A Must Read”.)

To construct the human readable string for an sNDC that is encoded in a GS1 string of elements you may insert spaces between the end of the GTIN and the “21” and you may set off the AIs by wrapping them in parentheses.  These “decorations” are commonly used to help make these long numbers more readable and they should never be included in the string that is encoded in the barcode.

Here is an example GS1 string of elements that uses the same data that the FDA included for an example sNDC in their guidance document (shown in the image above).  In their example they used a fictitious NDC of 55555 666 77 and a serial number of 11111111111111111111.  Applying the shortcut technique I show above the GS1 string of elements would be:

sNDC example from the FDA Guidance document encoded into a GS1 string of elements. Click image to enlarge.

The string that would be used to encode the GS1 barcode would be:

010355555666772111111111111111111111

and the human readable to be printed on the drug package might look like this:

(01) 03 55555 666 77 (21) 11111111111111111111

Notice the extra decorations I included in the human readable that are not included in the string that is encoded in the barcode.

DEPICTING AN sNDC IN AN RFID TAG USING GS1 sGTIN

In a departure from the GS1 General Specification, GS1’s RFID tag standards do not make use of AI’s when encoding an sGTIN for product identification.  In fact, in their RFID standards the concept of a GTIN and a serial number are merged together to produce a single indivisible  identifier they explicitly call a Serialized Global Trade Item Number, or SGTIN (see the GS1 Tag Data Standard for the details).

A full explanation of how to encode an SGTIN within a GS1 RFID tag is more complex than the barcode explanation above and it is beyond the scope of this essay (and of RxTrace, really) but you will find the GS1 Tag Data Standard document (now in revision 1.6) to be quite well written (see my essay “Masterpiece:  GS1 Tag Data Standard 1.5”).  And don’t miss my widely read essay “RFID Is DEAD…At Unit Level In Pharma”.

IMPLICATIONS OF THE sNDC SERIAL NUMBER DEFINITION

There are some surprising implications that result from the definition of a serial number in the way the FDA defines the sNDC.  I hope to cover those implications in a future essay.  Stay tuned.

Dirk.

In recent essays I have covered the “Anatomy of an NDC”, the “Anatomy of a GTIN” and the “Updated HDMA Bar Code Guidance: A Must Read“.  Now let’s put them all together.  Why would we need to do that?  Because the U.S. FDA requires many Over-The-Counter (OTC) and all prescription drugs marketed in the United States to have their National Drug Code (NDC) presented in the form of a linear barcode on the package.  Pure and simple.  To do that in a way that your trading partners can understand—that is, to do it interoperably—you need to follow a standard.  You have two realistic choices for standard approaches to this problem:  HIBCC or GS1.

The use of HIBCC standards is fairly common in the U.S. medical surgical devices supply chain but in the pharmaceutical supply chain it is very rare.  Most companies choose GS1’s barcode standards so that’s all I’m going to focus on in this essay.  If you want more information about how to do this with a HIBCC barcode find it here.

OVER-THE-COUNTER DRUGS:  GTIN-12

If your drug is sold over the counter (OTC), like aspirin and cold medications, the barcode on your packages will need to be scanned at point of sale (POS) terminals in the same way that any other consumer good is.  For that reason you need to put your National Drug Code (NDC) into a Universal Product Code (UPC) barcode in the United States.  A UPC-A barcode symbol contains a GS1 GTIN-12 data structure.  Here is what you need to do to convert your NDC into a GS1 GTIN-12:

1. Register your FDA Labeler Code with GS1 US who will convert it into a GS1 Company Prefix (GCP) and grant you the right to use it
   Recall from my previous essays that your FDA Labeler Code is either 4 or 5 digits long and a GCP can be anywhere from 6 to 10 digits depending on the fee you pay GS1 US when you register it.  In the case of FDA-regulated pharmaceuticals GS1 US will register a 4-digit FDA Labeler Code as a 6-digit GCP and a 5-digit FDA Labeler Code as a 7-digit GCP.  The reason is that they need to synchronize the length of the Item Reference portion of the resulting GTINs with the combined length of the Product Code and Package Size fields of your NDC.  This is to ensure that you are able to generate valid GTIN-based barcodes for every possible NDC that your Labeler Code enables you to generate.  You only need to register your FDA Labeler Code with GS1 US once as long as you keep up with the annual subscription fees so for subsequent drugs that use a Labeler Code that is already registered you can skip this step.  If you have multiple FDA Labeler Codes you need to register each one with GS1 US once.
   
   GS1 US has reserved GCPs that start with “03″ for owners of FDA Labeler Codes as shown in the following table.
   

   Click images to enlarge

2. From your new GS1 Company Prefix construct your U.P.C. Company Prefix
   Ah ha!  This is an esoteric step.  It is necessary because of the way GS1 merged the formerly North American-only Uniform Code Council’s (UCC) Universal Product Code (UPC) company prefixes with the European Article Numbering Association’s (EAN) European Article Number (EAN) company prefixes and made the whole combined scheme suitable for global company prefixes and yet retained backward compatibility with the UPC and EAN.  But you don’t have to follow any of that.  Here’s what you do.
   
   You take the GCP that GS1 US assigned you and you strip off the leftmost digit.  That digit is always going to end up being a zero because we are dealing with an FDA regulated pharmaceutical and GS1 US will make sure that it is a zero on your behalf.  The remaining digits make up your new U.P.C. Company Prefix, usable only for generating UPC-A barcodes  and a few other less common things (see the GS1 General Specification for what else you can do with a U.P.C. Company Prefix).  For an NDC that has a 4-digit Labeler Code your U.P.C. Company Prefix will now start with a “3” and it will be 5 total digits long.  For an NDC that has a 5-digit Labeler Code your U.P.C. Company Prefix will now start with a “3” and it will be 6 total digits long as shown below.
   

   Click images to enlarge

3. Combine your U.P.C. Company Prefix with the Product Code and Package Size fields from your NDC
   For an NDC that has a 4-digit Labeler Code your Product Code and Package Size fields will be a total of 6 digits long.  Combine them with the GS1 U.P.C Company Prefix by placing them to the right of the prefix.  For an NDC that has a 5-digit Labeler Code your Product Code and Package Size fields will be a total of 5 digits long.  Combine them with the GS1 U.P.C. Company Prefix by placing them to the right of the prefix.  You should now have a total of 11 digits regardless of the length of your Labeler Code as shown in the table below.
   

   Click images to enlarge

4. Calculate the Check Digit and add it to complete your GTIN-12
   GS1 provides an algorithm to calculate the Check Digit in section 7.2.7 of the GS1 General Specification.  They also provide a handy calculator at this webpage(although where they say to enter the “Item Reference”, they really mean for you to enter the full prefix and item reference together).  Add check digit to the right of the code constructed in step 3.  You should now have a 12-digit code as shown below.  This is the GTIN-12 that can be encoded into a UPC-A barcode and printed on your product.
   

   Click images to enlarge

If you look closely at the table above you may see a short-cut that would get you directly to your GTIN-12.  All you need to do is take your 10-digit NDC and put a “3” in front of it and put a calculated check digit at the end as shown in the following table.

Click on images to enlarge

It is true that you can get there this way but then you might be tempted to skip step #1 and not obtain your official GCP.  As I understand it, since GS1 owns a copyright on the UPC family of barcode symbologies they could make a claim against your company if you encode your NDC into the copyrighted UPC-A symbology without first registering your FDA Labeler Code with them and paying whatever fee they place on that.  Talk to GS1 US to get the full story for your particular situation.  On the other hand, if you have already registered your Labeler Code with GS1 US then this short-cut should always produce your GTIN-12 for subsequent products that share the same FDA Labeler Code.

PRESCRIPTION DRUGS:  GTIN-14

Any drug distributed in the U.S. that is regulated by the FDA as a prescription drug must be dispensed by a registered pharmacist.  In that case it will not be scanned at a retail POS station.  For that reason you do not need to encode your NDC within a GTIN-12 but should encode it into a full GTIN-14.  GTIN-14s should also be used on all case labels whether OTC or prescription (see the HDMA Bar Code Guidance for details).  You can render a GS1 GTIN-14 identifier into a GS1-128, GS1 DataMatrix, or GS1 DataBar symbology depending on the application.

Here is what you need to do to properly convert your NDC into a GS1 GTIN-14 data structure:

1. Register your FDA Labeler Code with GS1 US who will convert it into a GS1 Company Prefix (GCP) and grant you the right to use it
   This is the same as step #1 for GTIN-12 above.
   
   
2. Combine your GS1 Company Prefix with the Product Code and Package Size fields from your NDC
   For an NDC that has a 4-digit Labeler Code your Product Code and Package Size fields will be a total of 6 digits long.  Combine them with the GS1 GS1 Company Prefix by placing them to the right of the prefix.  For an NDC that has a 5-digit Labeler Code your Product Code and Package Size fields will be a total of 5 digits long.  Combine them with the GS1 GS1 Company Prefix by placing them to the right of the prefix.  You should now have a total of 13 digits regardless of the length of your Labeler Code.
   
   
3. Calculate the Check Digit and add it to complete your GTIN-14
   GS1 provides an algorithm to calculate the Check Digit in section 7.2.7 of the GS1 General Specification.  They also provide a handy calculator at this webpage.  Add check digit to the right of the code constructed in step 2.  You should now have a 14-digit code.  This is the GTIN-14 that can be encoded into a GS1 Code-128, GS1 DataMatrix, or DataBar barcode and printed on your product or case.  (NOTE:  DataBar should only be used on packages that are too small to accept one of the other symbologies.  See the HDMA Bar Code Guidelines for details.)

Finally, if you have already registered your Labeler Code with GS1 US you can use the following short-cut to construct your subsequent GTIN-14s.

Click image to enlarge

The following figure summarizes the contents of all forms of the NDC for both GTIN-12 and GTIN-14 data structures.

Click images to enlarge

IMPLICATIONS

There is an important implication stemming from the use of GS1 identifiers and barcodes to encode and render your NDC that I think needs to be explained.  This applies to any company that already possesses a GCP that does not match their FDA Labeler Code.  I can think of two ways that this might happen:

1. Any company in the U.S. that distributes non-drug products and already obtained a GCP from GS1 US for those products,
2. Any drug manufacturer that is based outside of the United States and that already possesses a GCP that was issued by their local, non-U.S. GS1 Member Organization.

Neither of these types of GCP’s can be used to encode an NDC for distribution within the U.S.  That’s because these GCPs do not match your FDA issued Labeler Code.  Only GS1 US, the U.S.-based GS1 Member Organization, can issue you a GCP that is properly based on your Labeler Code.  So these companies should contact GS1 US to register their Labeler Code, whether the company is based in the U.S. or not.

Systems and their associated databases should always be designed to accommodate the full GTIN-14 even when the application may seem to only need to deal with GTIN-12′s.  See GS1′s position paper on this topic for more explanation.

There are a few more “Anatomy of…” essays I want to write including the FDA’s Standardized Numeric Identifier (SNI), and GS-128 in the U.S. Pharma supply chain.  Watch for those essays in the near future.

Dirk.

2012 is the year of the GTIN in the U.S. healthcare supply chains as christened by the largest hospital group purchasing organizations (GPOs) in their so-called “Sunrise 2012″ program.  They have asked all of their suppliers to switch from proprietary product codes to GS1’s Global Trade Item Number (GTIN) standard in catalogs, B2B communications and shipment labeling by the end of this year.  They did the same thing with GS1’s Global Location Number (GLN) back in 2010 (“Sunrise 2010″) but so far it appears to have had only a small (but still growing) impact.

The GTIN can be a mysterious concept.  I received an email recently from a sales person who wanted to know what this “G-ten” thing was that her customer kept claiming was so important to her future business with them.  I’ve also sometimes had difficulty convincing people that GTIN adoption is important.  “We don’t need another product identifier.  We already have the NDC!”

I hope to pull back the veil just a little bit and explain not only the anatomy of the GTIN but also why it is so important to all supply chains in all regions of the world.

WHAT EXACTLY IS A GTIN?

GS1 explains the GTIN this way:

“As the name implies, the GTIN helps automate the trading process – basically buying and selling.  GTINs are therefore assigned to any item (product or service) that may be priced, or ordered, or invoiced at any point in any supply chain.  The GTIN is then used to retrieve pre-defined information about the item.  The key benefit is that information about the item can be retrieved about the product from the GTIN whether it is read in a GS1 BarCodes symbol, exchanged via a GS1 eCom message or accessed from the Global Data Synchronisation Network.”

Hmmm…Let me try.  First, a “Trade Item” is any product or service that may be manufactured, priced, advertised, bought, sold, traded, invoiced, returned or consumed within a commercial supply chain.  GTIN (Global Trade Item Number) is a GS1 standard that defines the structure and usage rules for a numeric identifier that can be assigned to a very specific, idealized description of a “trade item” and which can then be used in any part of the world to refer to instances of trade items that conform to that description.

For another attempt at a definition, see the one on Wikipedia here.

In everyday usage “a GTIN” is the number that is encoded into the product barcodes found on pretty much every product you can find in any store.  In the U.S. you know it as the UPC, or Universal Product Code, a 12-digit number (and technically known as a GTIN-12).  In the E.U. you know it as the EAN, or European Article Number, a 13-digit number (and technically known as a GTIN-13).  The GTIN-12 and GTIN-13 are “retail” GTINs.  That is, these are the GTINs placed on products that are typically sold through a retail Point of Sale (POS) station (a store checkout counter).  This includes most over the counter (OTC), non-prescription drugs.

Today, nearly all OTC drugs and many prescription drugs in the U.S. supply chain are marked with a National Drug Code (NDC) or a Universal Product Code (U.P.C.) that is encoded in a GTIN-12 data structure and rendered on the package in a UPC-A barcode.  Non-retail products like those that are typically sold only B2B (business to business) (GS1 refers to these as “Trade Items Intended for General Distribution Scanning Only”)—including prescription pharmaceuticals—should be assigned a 14-digit GTIN (technically known as a GTIN-14).

You may yawn, but this is powerful stuff if you can get everyone on the bandwagon.  The GPOs in the U.S. and GS1 plan to do just that.

The most important aspect of the GTIN standard is that when one is properly assigned to a given product or service it is globally unique.  That means that no other product or service anywhere in the world can ever be assigned that same GTIN so that number can be used anywhere and everywhere to refer to that specific type of product or service.  This eliminates product code ambiguity globally.

Another important feature is that the GTIN standard is applied in the same way regardless of product type, service type or supply chain.  The same rules apply to all GTIN identifiers.  These rules are defined in GS1’s General Specification—the specification of “The GS1 System”, of which GTIN is just one part.  See also “GS1 GTIN Allocation Rules for Healthcare” for some of these rules in a healthcare context.  (For a great non-technical explanation of “The GS1 System” of standards, check out this great PDF:  “The Value and Benefits of the GS1 System of Standards”.)

ANATOMY OF A GTIN-14

I mentioned above that a GTIN can take form in 12, 13 or 14 digits (it can also take the form of an 8-digit value but that’s very rare in healthcare), but since my focus is primarily in the B2B healthcare supply chains I’m only going to concentrate on the 14-digit form in this essay.  This is the only form that will fit into barcodes that make use of GS1 Application Identifiers (AI) (like GS1-128 linear barcodes and GS1 DataMatrix 2D barcodes) although the other forms can always be converted into the 14-digit form (by padding with zero[s] on the left).  Note that OTC drugs at the unit-level cannot make use of the GTIN-14 structure, AIs or the barcodes that carry them because they need to be scanned at POS.

There are four components that make up a GTIN-14 and they appear in this order:

• Indicator Digit
  This digit only appears in the GTIN-14 and is primarily used to indicate standard groupings (inner pack, case, pallet, etc.) of packages of the same GTIN using values 1 through 9.  A zero indicates that the GTIN is representing a single unit.  For products where the actual units sold can be a variable measure (weight, size, volume, etc.) the indicator digit should be set to 9.  Indicator values 1 through 8 have no specific standard meaning other than that they indicate a grouping.  That is, there are no standard groupings that values 1 through 8 may indicate so you can’t assume any particular value means an inner pack, a case, a pallet or anything else.  Each company is free to choose any of these values to indicate any grouping they wish.
  
  
• GS1 Company Prefix (GCP)
  This is the variable length number that is assigned by the local GS1 Member Organization (MO) to the company that manufactures, packages or repackages the product that the GTIN represents.  This is the number that those companies must apply to GS1 for assignment.  In the U.S. the GCP ranges in length between 6 and 10 digits and the length partially determines its cost.  Shorter company prefixes cost less than longer ones (see Item Reference below for why this is so).
  
  Pharmaceutical companies who already possess an FDA Labeler Code (see my previous essay, “Anatomy Of The National Drug Code” for more on this) just need to register that code with GS1 US (the local GS1 MO in the United States) to obtain a license to use that same code as the basis for their GCP within the context of GS1’s copyrighted barcode, RFID, EDI, pedigree and track & trace standards.
  
  The GS1 Company Prefix is itself composed of a 1 to 3 digit GS1 Prefix which is assigned by the GS1 Global Office to each GS1 MO to ensure global uniqueness of all GCP-based GS1 keys (GS1 keys include GTIN, GLN, SSCC, GRAI, any EPC, GSRN, GIAI, GDTI, GSIN, etc.).  This prefix is sometimes incorrectly referred to as a “country code” although because MOs are fairly country-specific this is not too far off.  The remainder of the GCP—known as a Company Number—is assigned by the Local MO.  See the GS1 General Specification for more details.
  
  When a company is assigned a GCP by GS1 they are granted exclusive rights to use that prefix to construct any of the GS1 keys (see the list in the paragraph above) and use them in any way they see fit as long as it is within the rules established in the GS1 General Specification.  GS1 keys generated by the owner of the GCP do not need to be authorized, approved or registered with GS1.  There is no additional cost to generate new GS1 keys once a company obtains a GCP.
  
  GCPs are a company asset that should be addressed in any merger or divestiture strategy (see this topic in the GS1 General Specification).  GCP usage within a given company should ideally be controlled at a single point within an organization.  This generally isn’t an issue for smaller companies but multinational corporations should ensure that they have a strategy for centrally assigning and distributing GCP-based GS1 keys to their operations to ensure uniqueness and to ensure that the GCP resource is used to its maximum potential.
  
  Companies may obtain multiple GCPs from their local GS1 MO if they use up the available reference values in one or more GS1 keys.  They may also obtain additional GCPs (partly “used”) as the result of a merger with another company.
  
  Neither GS1 nor the MOs police adherence to any of their standards, but they carefully control the assignment of GCPs to always maintain global uniqueness.  As long as the GCP assignments are all globally unique, all of the keys generated by the owners of all GCPs will also be globally unique.  This is a very important design feature of the entire GS1 System.
  
  
• Item Reference
  The Item Reference is a variable length number that must be chosen by the owner of the GS1 Company Prefix and assigned to the specific description of a single product class.  This specific description must remain unchanged for the life of the GTIN (see the GS1 General Specifications for details and exceptions).  The combination of the owner’s GCP and the Item Reference must be exactly equal to 12 digits.  Since the length of the GCP is determined when it is obtained from the local MO, the length of the Item Reference must take up the remainder of the 12 digit space.
  
  For example, if company A obtains a 6-digit GCP, the Item Reference field within their GTIN-14′s must be 6 digits long (12 – 6 = 6).  If company B obtains a 10-digit GCP, their GTIN-14 Item References must be only 2 digits long (12 – 10 = 2).  From these two examples you can see that company A can identify up to 1,000,000 unique products or services but company B can only identify 100.
  
  There is a comparable limitation in the other GS1 keys.  Shorter GCPs result in more digit space available in the reference portion of the key which results in vastly more usable unique numbers (each extra digit represents an order of magnitude more unique values the owner can assign).  This is why GS1 charges more for the shorter GCPs than they do for longer ones and this provides a measure of affordability to smaller companies who will likely never need more than a small number of unique GTINs or other keys.
  
  
• Check Digit
  The Check Digit is a single digit that is mathematically calculated based on the contents of all of the other digits in the GTIN-14.  The purpose of the Check Digit is to help barcode readers and applications detect data entry errors.  See Section 7.10 of the GS1 General Specification for the algorithm.

EXAMPLE GTIN

Here is an example of a GTIN-14 that I found on an inner-pack of Epinephrine injectors.

Click image to enlarge. Image Copyright RxTrace 2012.

An “inner-pack” is a grouping of trade items and so we see the Indicator Digit is set to “1″, a valid value for a grouping.  We can’t tell by looking at this example exactly how long the GCP is because it could be anywhere from 6 digits to 10 digits long.  Fortunately GS1 provides a service they call Global Electronic Party Information Registry, or GEPIR.  If we select “Search by GTIN”, enter ’10304094921348′ and click “Search”, we are told that this GTIN contains a 6-digit GCP of ’030409′ and it is registered to Hospira, Inc. in Lake Forest, Illinois.  Now we know that the Item Reference that Hospira happened to choose for this GTIN must be ’492134′.  The Check Digit is calculated based on all of the previous digits as “8″.

This particular inner-pack contained about 10 or 12 unit-level packages that were shrink-wrapped together and labeled with the GTIN-14 above.  Each of the units contained a barcode with the unit-level GTIN-14 encoded in it.  It was exactly the same GTIN as the inner-pack except for the Indicator Digit which was correctly set to zero.  These were unit dose injectors.  There are probably about 4 inner-packs per casepack but I didn’t note that information.  The case GTIN would be exactly the same as the inner-pack and units except for the Indicator Digit which would have been been a value in the range of 2 to 8 to reflect that it is a standard grouping that is different than the inner-pack.

Normally we don’t need to deconstruct GTINs like this.  In fact the whole point of a GTIN is to use it as a single whole identifier and not to break it down into its constituent parts like we have done here but I wanted to show you how this one was intelligently constructed by Hospira, the owner of this particular GCP.

BENEFITS OF THE GTIN

The benefits of GTIN adoption by a supply chain are different between manufacturers and non-manufacturers (distributors, pharmacies and retailers).

Manufacturers gain because they can potentially use the same standard product/service identifier in multiple markets/countries.  Well, as long as the packaging doesn’t vary (same language, etc.) and there aren’t any regulatory reasons for using a different identifier (national numbering like the U.S FDA NDC, different units for the unit of measure, etc.).  Even when a different identifier is necessary for different markets/countries the manufacturer benefits from the use of a standardized identifier because modern Manufacturing Execution Systems (MES), Warehouse Management Systems (WMS),  Electronic Data Interchange (EDI) systems and Enterprise Resource Planning (ERP) systems should come with full GS1 System support built in (admittedly not all do yet).  This includes enforcement of many of the GS1 rules for dealing with GTINs and the other pertinent GCP-based identifiers.

Like manufacturers, non-manufacturers in the supply chain make use of WMS, EDI and ERP systems in addition to pharmacy management systems and  Hospital Materials Management Inventory Systems (HMMIS) that ought to have standardized GS1 System support built in.  These companies also benefit because they can trust that GTINs are globally unique and all product identifiers used by all of their suppliers refer to the same product or service and those identifiers are constructed using the same format.  This allows them to eliminate their own internal product codes for each manufacturer’s products and services, simplifying inventory management, sales, purchasing, order fulfillment, shipping, receiving and dispensing and thus reducing errors that generate waste and in the healthcare supply chain can cause injury or even death.  This is why the GPOs are so hot to make 2012 the year of the GTIN.

ADOPTION OF THE GTIN

Manufacturers of products or services can decide to unilaterally adopt the GS1 GTIN standard for all of their products and they can reap some small internal benefits from that decision as I’ve outlined above.  That may not offer enough of a gain to offset the cost of conversion from proprietary product identifiers.  The problem is, for the downstream trading partners to benefit from GTIN use, more than just one manufacturer has to switch to GTINs.  In fact, the benefits don’t start accruing to those companies until a significant number of manufacturers switch to GTINs, and until all manufacturers in a given supply chain switch to them the benefits do not reach their maximum potential.  For this reason, GTINs should be adopted by a supply chain as a whole and not just one company here and there.

How do you trigger a switch within an entire supply chain like that?  The GPOs may have it figured out.  Like Walmart in the fast-moving consumer goods (FMCG) supply chain and the big automakers in their supply chain, they have to start dictating the switch and they have to be hard-nosed about it.  Can the GPOs fill the role of the “800-pound gorilla” like Walmart and the automakers?  We’ll see.

There are some encouraging signs and some discouraging signs in the recently released results of a survey in a document called “GS1 Data Standards Adoption Survey, Progress toward Global Trade Item Numbers (GTINs), December 2011” conducted by the University of Arkansas Center for Innovation in Healthcare Logistics (CIHL) on behalf of the Healthcare Supply Chain Association (HSCA) (the industry association of GPOs, formerly HIGPA) and the Healthcare Industry Supply Chain Institute (HISCI).  I’ll have more to say about this paper and the results it documents in a future essay.

I’ll stop here for now.  Watch for future related essays on “Depicting an NDC Within a GTIN”, and “Anatomy of an SNI”.

I am going to attend the 2012 National Pharmacy Forum in Tampa on February 9th.  The full conference runs from the 8th through 10th and is co-hosted by HCSA and HISCI.  If you run into me there please introduce yourself and tell me what you like and don’t like about RxTrace.

Dirk.

For the application of unique serial numbers, or Standard Numerical Identifiers (SNIs), to packages as part of compliance with the California Pedigree Law in 2015-2017 , GS1′s Electronic Product Code (EPC), particularly in barcode form, is the clear winning standard.  But there seems to be a very common misconception going around that for pedigree data management, all you need to do to comply with that law is to deploy a system that is based solely on the GS1 Electronic Product Code Information Services (EPCIS) standard.  The  misconception assumes that there is a formula that can be followed to achieve compliance and that EPCIS is the whole formula.

In truth, EPCIS will almost certainly be an important component in the compliance formula but exactly how it fits, and whether there are other necessary components, has not yet been determined.

There are probably several reasons that this misconception persists.  First, GS1 US continues to promote their 2015 “Readiness” Program as if it is that formula.  The program documentation strongly implies that, if you simply follow their program, you will “be ready” to comply with the law; but it stops short of actually saying that you will be compliant.

Second, it seems like people are either able to understand the law well but not the technical standards, or they are able to understand the technical standards well but not the law.  The legal folks are left to trust what the technical people say about EPCIS, and the technical people assume that as long as the data elements identified in the law are present somewhere then EPCIS must comply.

Now I am not a legal expert but I’ve been looking at the text of the California Pedigree Law for a few years now and I think I understand it at a level that allows me to estimate how various technical approaches might fill its requirements.  Let me show you how the text of the law compares to the capabilities of the EPCIS standard.  From that analysis I think you will either be able to see that EPCIS by itself is insufficient to comply with the law, or you may see some flaw in my logic.  In that latter case, please leave a comment below to point out the flaw.  My intent is not to provide you with legal advice but to explain how the EPCIS technical standard would likely be applied when using it in an attempt to comply with the law.  Decide for yourself what you think will or won’t comply.

THE CALIFORNIA PEDIGREE LAW

The California Pedigree Law is now part of the California Business and Professions Code.  There are a number of resources that the California Board of Pharmacy provides to help you study and interpret the code.  Unfortunately all of the material on their website is a little out-of-date, but it still has some value.

• A page containing a copy of the pertinent text from the California Business and Professions Code.  The text on this page is the way the regulations were prior to the most recent modification of the law that pushed the effective date out to 2015-1017.  Most of it is still accurate.
• A draft of a PDF called “Questions and Answers Relating to the Electronic Prescription Drug Pedigree Law”.  Dated January 2008 please note that this document was written for the regulation as it existed prior to the last modification that pushed the effective date out to 2015-2017.  It is still a useful guide to the Board of Pharmacy’s interpretation of the law except when related to the effective dates and perhaps some of the exceptions to the law;
• A PDF called “Background and Summary of the California ePedigree Law”.  The document doesn’t have a date but it is obviously describing the law as it was prior to the latest revision that pushed the effective date to 2015-2017.  It is still useful because it provides some of the history leading up to that revision.

It would be nice if the Board would update these resources now that people are beginning to pay more attention to the current deadlines and are preparing for compliance.

To read the actual text of the current California Business and Professions Code click here and then search for the word “pedigree”, then click on the sections where your search finds that word.  That should take you to the actual text of those sections of the Code.  Now search for key words related to pedigrees.

I have written about the California Pedigree Law in the past.  You might find these essays of interest.  Click here for a list of RxTrace essays that contain references to it.  Dr. Adam Fein of Pembroke Consulting has written frequently about pedigree in general including the California Pedigree Law over the last 5 years or so.  Click here for a list of his DrugChannels blog essays about Pedigree.

THE CALIFORNIA CODE THAT IS PERTINENT TO THE TECHNICAL IMPLEMENTATION AIMED AT COMPLIANCE

First, what constitutes “a pedigree” under California Law?

Section 4034.

(a) “Pedigree” means a record, in electronic form, containing information regarding each transaction resulting in a change of ownership of a given dangerous drug, from sale by a manufacturer, through acquisition and sale by one or more wholesalers, manufacturers, repackagers, or pharmacies, until final sale to a pharmacy or other person furnishing, administering, or dispensing the dangerous drug. The pedigree shall be created and maintained in an interoperable electronic system, ensuring compatibility throughout all stages of distribution.

(b) A pedigree shall include all of the following information:

(1) The source of the dangerous drug, including the name, the federal manufacturer’s registration number or a state license number as determined by the board, and principal address of the source.

(2) The trade or generic name of the dangerous drug, the quantity of the dangerous drug, its dosage form and strength, the date of the transaction, the sales invoice number or, if not immediately available, a customer-specific shipping reference number linked to the sales invoice number, the container size, the number of containers, the expiration dates, and the lot numbers.

(3) The business name, address, and the federal manufacturer’s registration number or a state license number as determined by the board, of each owner of the dangerous drug,  and the dangerous drug shipping information, including the name and address of each person certifying delivery or receipt of the dangerous drug.

(4) A certification under penalty of perjury from a responsible party of the source of the dangerous drug that the information contained in the pedigree is true and accurate.

(5) The unique identification number described in subdivision (i).

(c) A single pedigree shall include every change of ownership of a given dangerous drug from its initial manufacture through to its final transaction to a pharmacy or other person for furnishing, administering, or dispensing the drug, regardless of repackaging or assignment of another National Drug Code (NDC) Directory number.

Dangerous drugs that are repackaged shall be serialized by the repackager and a pedigree shall be provided that references the pedigree of the original package or packages provided by the manufacturer.

[…]

The key to my argument is that all of this information (I’ve highlighted it for you above) must be present in “a record” or it isn’t a valid “Pedigree” according to this part of the Code.  A “single pedigree” must include information about every change of ownership of a given drug or it’s not a valid pedigree.

We only need parts of one more section to be able to determine why EPCIS by itself won’t work for California pedigree.  That’s section 4163.  I’m leaving out parts that aren’t needed for my argument, including the exceptions, so feel free to review the entire section to convince yourself that I haven’t bent anything to benefit my case:

Section 4163.

[…]

(c) […] commencing on July 1, 2016, a wholesaler or repackager may not sell, trade, or transfer a dangerous drug at wholesale without providing a pedigree.

(d) […] commencing on July 1, 2016, a wholesaler or repackager may not acquire a dangerous drug without receiving a pedigree.

(e) […] commencing on July 1, 2017, a pharmacy may not sell, trade, or transfer a dangerous drug at wholesale without providing a pedigree.

(f) […] commencing on July 1, 2017, a pharmacy may not acquire a dangerous drug without receiving a pedigree.

(g) […] commencing on July 1, 2017, a pharmacy warehouse may not acquire a dangerous drug without receiving a pedigree.

[…]

So once the law goes into effect, wholesalers, repackagers and pharmacies cannot sell, trade or transfer a drug without providing the buyer with “a pedigree”, and, separately, wholesalers, repackagers and pharmacies cannot buy a drug without receiving “a pedigree” from the seller.  Notice that this obligates both the buyer and seller independently.  If “a pedigree” isn’t provided with the transaction, both buyer and seller are breaking the law.

HOW EPCIS WAS DESIGNED TO WORK

EPCIS was designed to be used to implement a distributed network of repositories that each contain records describing the WHO, WHAT, WHEN and WHY of supply chain events that occur as serialized products move through a supply chain.  The original vision of EPCIS as applied to the U.S. pharmaceutical supply chain would expect each pharma manufacturer, each distributor and each pharmacy to have their own event repository that conforms to the EPCIS specification.

In their repositories, these companies would save records—or, events—that describe all of the serial number-based events that would occur while the drugs were under their control.  That is, the manufacturer’s repository would hold all of the events related to each drug package that occurred during manufacturing through shipment to the their customer, but it would not hold any of the events that occurred on the properties of downstream owners of those drugs.  Likewise, the distributor who bought the drugs from the manufacturer would typically hold only the events for those drugs from the point of receipt from the manufacturer through their own shipment to their customer.  And so on down the supply chain.

APPLYING BASIC EPCIS TO THE BASIC PEDIGREE PROBLEM

To get a full “trace”, or “supply chain history”, of a given package of a drug you would need to query each of the EPCIS repositories of all previous owners back to and including the manufacturer.  This “trace report” that would result would be a good example of a “chain of custody” report, but it would fall short of what California calls “a pedigree”.  It may be a valid pedigree in other jurisdictions under different laws but in California it would be missing the following necessary data elements from their definition:

• “Name”, “registration number or a state license number and principle address of the source”
  These data elements would be missing because, by definition, EPCIS makes use of Supply Chain Master Data (SCMD) references to save space.  Instead of the explicit information called out in the law the trace records produced by EPCIS queries would contain GS1 Global Location Numbers (GLNs) which are 13-digit numbers that are supposed to represent most of this data.  That representation is defined by the owner of the GLN and they are under no obligation to maintain it or to ensure that the data has a single, fixed association with the GLN.
• “Trade or generic name”, “dosage form”, “strength”, and “container size”
  These data elements would be missing because, like its use of GLN’s, EPCIS is designed to also use SCMD references for product data to save space.  In place of this data, each event would include only a GS1 Global Trade Item Number (GTIN) which is a 14-digit number that is supposed to represent most of that product data.  The manufacturer of the drug owns the relationship between the GTIN and the associated product data, but they are under no obligation to ensure there is only one, unchanging set of product data associated with that number.
• “Business name”, “address”, “federal manufacturer’s registration number or a state license number”…”of each owner” of the drug, including the “name” and “address of each person certifying delivery or receipt” of the drug
  Again, EPCIS events would hold a representation of this information as a set of GLN’s to save space.  The actual data would only be implied.
• “A certification under penalty of perjury from a responsible party of the source of the dangerous drug that the information contained in the pedigree is true and accurate”
  The EPCIS standard doesn’t define anything like this kind of data.
• “A single pedigree shall include every change of ownership…”
  The chain of custody report that is built as the result of the set of queries mentioned above would be a set of records that would need to be interpreted and the information combined into a single record.  But this would only be possible if the current owner knows who to query and then only if all of the previous owners of the drug were willing and technically able to reply at that particular moment with their contribution of the events they hold about that particular drug.

That’s a lot of missing information.  It may seem like the EPCIS standard is so far away from what the law calls for that it is hopeless to expect it to ever work.  Not quite.  EPCIS has an important feature that is intended to allow users to extend its operation in multiple ways.  This feature allows EPCIS to be shaped into solutions that can fit problems much more flexibly than previous general purpose systems might have in the past.  Can this extensibility feature address all of the missing information in some way and turn the chain of custody report into a compliant pedigree?  Perhaps.  I will consider that possibility in future essays in this series.  But first…

ENTER THE GS1 US HEALTHCARE 2015 READINESS PROGRAM

GS1 US saw these problems with EPCIS a number of years ago.  Since that time their Healthcare Traceability group has been working on potential solutions to some of the problems I listed above.  I can’t write about exactly how they propose to do that because they have policies that prevent the disclosure of that kind of internal information.  However, it appears that GS1 US is just about to make that kind of information public themselves in the next few weeks.  As soon as they do I will pick up this topic again and explain how their ideas might or might not address this list of deficiencies.

WHAT ABOUT GS1 (GLOBAL) HEALTHCARE?

That’s a good question.  That organization has been busy working on pedigree-related ideas as well, though at a global level, and, not coincidentally, they too are about to make public their latest thoughts on how to use the EPCIS standard for network-centric ePedigree applications.  Although their work is intentionally not aimed at meeting the exact requirements of the California law (because it is a global effort), their work does beg for an explanation of how it might fit if those ideas were applied in that State Law.  This release of information will probably occur in the next few weeks as well.  So we will shortly have lots of ideas in the public domain that we can discuss and analyze.  In fact, I hope we are not overwhelmed!

WILL ANY OF THIS MAKE ANY DIFFERENCE AT ALL?

Another great question.  In fact, it may all become moot, because a new federal pedigree bill was apparently introduced into the U.S. Congress a couple of weeks ago by Representative Jim Matheson [D-UT].  If that bill, or some modified version of it eventually makes it out of committee and then passes both Houses of Congress and then if the President signs it, it would almost certainly pre-empt the California Pedigree Law.  In that case, we will all shift our attention to the peculiarities of the Federal regulation and the likely FDA guidance that would certainly follow.

However, it is very hard to estimate the likelihood that this, or other bills like it in the future, will pass.  Similar bills introduced in past sessions have not made it out of committee.  So until one of these bills make it through the entire process, it makes the most sense to keep our eyes on the realities of the California requirements.

Stay tuned for Part 2 as soon as the GS1 US and GS1 (global) documents are made public.

Dirk.

For Part 2 in this series, see “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 2“.

I recently published an essay on RxTrace called “Plateaus of Pharma Supply Chain Security” in which I proposed that a better timeline for the introduction of technology to secure the U.S. pharmaceutical supply chain was one based on plateaus.  Each succeeding plateau would add the adoption of new technology and/or data communications among the participants in the supply chain with the intent of elevating the security over the previous plateau.

In that essay I included illustrative dates for each of the four plateaus that I offered as an example of the concept, but you could easily imagine the overall program having open-ended dates that would allow the supply chain to adopt one plateau at a time and move to the next plateau only if/when a security problem is discovered at the current plateau.  That is, jump to the next plateau only when necessary.  Taking this approach, you may never actually need to get to the later plateaus.

For example, imagine that the first plateau were for manufacturers to serialize all drugs at the pharmacy-saleable package level (what I normally call “unit-level”) with an FDA Standardized Numeric Identifier (SNI) and all supply chain owners of drugs were to read the SNI’s and simply keep records of who they bought them from and who they sold them to.

With no data communications between trading partners that includes the SNI’s it might seem that little
security has been gained over what is done today.  But this small step (“small” compared to a full pedigree or track & trace system) would allow criminal investigators to make quicker progress in finding the path of suspicious drugs than they can today.  Limited recalls and drug cargo theft notices could be issued based on the exact SNI’s that are involved and supply chain organizations could almost instantly search their current inventory and their shipping history to determine if they have ever seen those units.

This would be a powerful achievement because it would prevent thieves from easily dumping stolen drugs back into the supply chain through an unsuspecting legitimate member.  But criminals may progress to the point where they would create new labels or cartons with different SNI’s for the drugs that they steal.  In that case, it will be time for the next plateau, and so on.

The time between plateaus would provide supply chain companies time to spread their costs and adjust to the technologies and processes added in the latest or next plateau.

SNI’s ARE NOT ENOUGH

If you were to do a big bang going from zero to full supply chain ePedigree system in a short period of time (like in 2 ½ years as the current California Pedigree Law does), all you would really need are GS1 SGTIN’s (Serialized Global Trade Item Numbers) to fulfill the SNI requirement (see my essay “FDA Aligns with GS1 SGTIN For SNDC“).  That’s because, in this instance, everyone is going to have some kind of repository that would be able to tell them everything they need to know about a given unit of drugs, all keyed off of that SNI.

ACRONYM REFRESHER

Here is a brief interlude to explain some of the acronyms I’m using in this essay.  The U.S. FDA (Food and Drug Administration) intended their SNI (Standardized Numeric Identifier) to be a new identifier that combined the existing NDC (National Drug Code) with a unique serial number.  The result is a unique identifier that refers to a specific single bottle or package of a given drug of the kind referred to by the NDC portion of the identifier.  Prior to the publication of their SNI guidance they were calling it the “Serialized NDC”, or “sNDC”.

They allow and, in fact, they expect the SNI to be encoded using existing industry standards, like HIBCC’s serialized HIBC (Health Industry Bar Code) or GS1’s “GTIN plus serial number”, or SGTIN (Serialized Global Trade Item Number).  These are industry standard ways of combining a general product code—which is what the NDC is—with a unique serial number.  So, in effect, an SGTIN (or a serialized HIBC) is a industry standards-based way of depicting an SNI, which is a way of combining your existing product NDC with a unique serial number (chosen by you), as defined by the FDA.  I try not to use the terms sNDC, SNI and SGTIN interchangeably, I try to use the term that is appropriate, but in some contexts they can all mean the same thing.

But if you imagine that my plateaus idea were to be implemented, it would take a number of years between the time that all drugs contain SNI’s and the time when a full pedigree or track & trace system is fully operational.  During the time of the interim plateaus, especially the first few, all any company would have is the SNI’s that they read off of each package of the drugs they handle.  There would be no data repository containing information about the drugs and no data exchanged.

As I pointed out above, these SNI’s would be helpful for any process that could benefit from specific serial numbers, like reacting to cargo thefts and execution of limited recalls, but what about normal, full-lot recalls and stock rotation?  It is unlikely that manufacturers will switch from just identifying the lot number(s) involved in a large drug recall to identifying every single unit-level SNI in the lot(s) being recalled.  That seems impractical.

But because downstream trading partners would have no way of translating a specified “lot number” into a set of “unit-level SNI’s”, execution of these most common type of recalls would not be helped in these early plateaus.  And SNI’s alone provide no help with stock rotation.  For these reasons, in a plateau’ed approach, SNI’s are not enough.

What would be very helpful on each package of drugs is the lot number and expiration date in addition to the SGTIN—not as optional data elements, but everyone would need to supply them.  With these three data elements—readable by electronic reading equipment—on every drug package, big benefits would start right away in the first plateau without any data repository or communication needed.  These includes:

• Efficient SGTIN-based recall execution;
• Efficient full-lot-based recall execution;
• Efficient stock rotation based on expiration dates;
• Efficient SGTIN-based stolen product monitoring.

ENCODING SNI, LOT NUMBER AND EXPIRATION DATE

These three data elements can be combined in a single RFID tag using the GS1 SGTIN EPC (Electronic Product Code) as the base, then adding the lot and expiration date in “user memory” as specified in the latest GS1 Tag Data Standard.  To encode them in a barcode GS1 handles it a little differently but the result is the same.  In this instance, there would be four data elements in a single barcode encoded using GS1’s GS1-128 Application Identifier standard as specified in the GS1 General Specification:

• The NDC-based GTIN (AI=01, exactly 14 digits)
• The Serial Number (AI=21, 1 to 20 alphanumeric characters)
• The Expiration Date (AI=17, exactly 6 digits)
• The Lot Number (AI=10, 1 to 20 alphanumeric characters)

THE LEAP FROM LINEAR TO 2D BARCODES

Back in 2004 the FDA mandated the use of linear barcodes—that’s right, very explicitly and specifically, linear barcodes—for encoding the NDC on all unit-level drug package labels.  So if you have recently replaced the linear barcode that contained your NDC on your drug package labels with a 2D barcode (you know who you are), you are in violation of the current FDA barcode regulation 21 CFR 201.25.

The problem is, if you tried to encode all four of the data elements I listed above in a linear barcode it would be way too big to fit onto most drug package labels.  The proper barcode would have at least 30 characters (which would be totally impractical because to make it that small the lot and serial numbers would both have only one character in them) to a maximum of 68 characters (which would be very unusual because drugs usually don’t necessitate 20 character lot numbers and 20 character serial numbers).  The typical length would probably be somewhere around 50 characters.  That’s pretty long considering that NDC barcodes today are only 12 digits long.

So this is when people start talking about adopting 2D barcodes like GS1 DataMatrix.  2D barcodes can store a lot more information in a smaller space than linear barcodes, but you need a more modern (read: more expensive) readers to read them.  A 2D-specific barcode reader can read linear barcodes, but a linear-specific barcode reader cannot read 2D barcodes (purists might find rare examples where one or both of these statements might not be totally accurate, but I consider these inconsequential).

The problem is that every participant in the U.S. pharmaceutical supply chain has maintained a large investment in linear barcode readers for many years.  These readers are spread all over the place.  Any abrupt switch from linear barcodes for NDC’s on drug packages to a 2D code to encode the NDC, serial number, lot and expiration is going to require all of these organizations to abruptly toss out their existing equipment nationwide and replace them with more modern (again, read: more expensive) readers.  Omni-directional readers used in some applications for reading the linear NDC barcodes have not yet been perfected as 2D readers so those business processes may slow down.

So far the industry is sticking with linear barcodes because of that one little word in the FDA barcode regulation (“linear”!), but I’ve recently heard an FDA official say in a presentation that they were considering changing it to allow 2D barcodes on drugs.  In fact, last summer the FDA asked for comments on an idea to allow 2D barcodes to include lot and serial number on some vaccines and that generated support from GS1 and AIM but a mix of support and opposition from around the industry.  Daphne from PMPNews breaks it down in her interesting essay “Can FDA’s Bar Coding Efforts Help Standardize Healthcare?“.

WHERE IS IT ALL LEADING?

Most manufacturers are currently planning to add SNI’s to their drug packages, but because the California Pedigree Law doesn’t require lot and expiration it is unlikely that many will voluntarily choose to add them.  Without a change to the FDA’s barcode regulation those SNI’s will either have to be encoded in a linear barcodes (or RFID tags), or the SNI 2D barcode will have to be placed on the packages in addition to the existing linear NDC barcode.

At some point I think we will see the addition of more information on drug packages than just the NDC and serial number in electronic-readable form, no matter if my “plateaus of security” concept is ever picked up or not, but the timing is hard to tell.  Without those additional data elements the industry will be forced to implement a full ePedigree or Track & Trace system to get any value out of the SNI’s, something that more and more people are opposed to as they see what it will cost.

Where do you think it is leading?

Dirk.

At the end of my last essay I said I had recently concluded that the jump to a fully automated pharma supply chain upstream visibility system is too big and complex to be achievable by every company in the U.S. supply chain by the California dates.  I want to explain that statement in a future essay (soon), but before I do I want to explore some of the track and trace models that are being considered by both GS1 and the FDA.  I particularly want to look at the viability of each model because I think we will find that some just aren’t (viable), and that will help narrow the search.

I’ll look at the three basic models that the FDA mentioned in their recent workshop:  Centralized, Semi-Centralized and Distributed (or Decentralized as the FDA called it).  There are others, but it seems that they can all be either based on, or reduced to, one of these three basic models.

In this essay I am looking at track & trace models from a global viewpoint, which is something that GS1 is doing but the FDA may not.  Attacks on the pharma supply chain are a global problem and global problems demand global solutions or gaps will be left for criminals to exploit.

GS1′s goal is to develop standards that apply globally as much as possible and the FDA will likely find that global manufacturers are more willing to implement something that is the same–or similar to–something they are already deploying elsewhere in the world.  It’s a good idea because any approach that has been demonstrated to be viable elsewhere in the world is probably more likely to be viable here…though that’s not guaranteed.

THE CENTRALIZED TRACK & TRACE MODEL

I would draw a Centralized track & trace model with a single, central track & trace repository (or at least a single system) for the entire world.  That’s what centralized means.  (Click on the drawings to enlarge them.)

Figure 1. Global Centralized Track & Trace Model. Not viable!

Most people probably don’t think of the Centralized model as requiring a single repository/system for the entire world but if you have more than one, you are talking about a “Semi-Centralized” model.  That’s a different model, which I will talk about below.

In my view, the concept of a Centralized track and trace model depicted in Figure 1 above is not viable at all.  For something like this to work you would probably need some kind of central global government that mandates its use, or at least a global law enforcement agency.  I don’t think we’ll see that any time soon.  Until then, this model is not viable.

THE DISTRIBUTED TRACK & TRACE MODEL

The Distributed track & trace model is one where each trading partner communicates with their immediate upstream and downstream trading partners under normal circumstances, and with other companies in the supply chain who may not be direct trading partners when necessary for certain applications.  ePedigree is one of the applications that would most often require a company to need to communicate with another company in the supply chain that is not an immediate trading partner.  The method for finding these other companies is one of the things that differentiates various flavors of the Distributed track & trace model.

The concept being followed in GS1 US Healthcare‘s EPCIS-based ”2015 Readiness Program“ is a Distributed track & trace system.  Some flavors of the Distributed model make use of GS1′s future Discovery Services standard and some do not.

Regular readers of RxTrace already know that I am not a fan of distributed models for implementing ePedigree in the U.S. pharma supply chain.  I have several problems with the concept.

The California Pedigree Law requires that each drug sold in the supply chain be accompanied by a valid and complete ePedigree.  If a seller can’t supply one, then they can’t sell the drug.  That means that the value of their inventory is totally dependent on their ability to supply ePedigrees.

In a Distributed model, the seller’s ability to supply a valid ePedigree is totally dependent on each of the previous owner’s ability to respond with their part of the ePedigree at the time of the sale.  The value of the drug can be completely destroyed if any one of them can’t respond.  In my view, that will introduce a level of risk that companies will find very distasteful at best and unworkable at worst.

For more on my concerns about the Distributed track & trace model, see the RxTrace essays in this list.

But when you consider how the Distributed model would fit into the current global situation, with several countries already having adopted their own central repositories, you realize that any adoption of a Distributed model in the U.S. would result in a very mixed model globally.  If the E.U. adopts a Point of Dispense (POD) authentication model it would be even more mixed.

Here is my depiction of that situation.

Figure 2. Global Mixed Track & Trace Models. Problematic for global manufacturers. Is it viable?

I’m showing a single manufacturer (blue) and a few distributors (red) and some of their pharmacy customers (black) in the U.S. using a distributed model, and that same manufacturer with a similar mix of distributors and pharmacies in the E.U. using a POD Authentication model.  The drawing shows the same manufacturer communicating with the national repositories of China, Brazil, Turkey and Italy.

This diversity of models around the globe could be problematic for global manufacturers because it will force them to use different approaches and different systems to deal with each model.  Note that U.S. distributors and pharmacies won’t be affected by the different approaches used in other regions.  This is only an issue for the many manufacturers that sell their products globally.

Is the Distributed model viable?  I don’t think it is if you assume it would have to be deployed in every country, thus making it truely global.  Is the mixed global track and trace model of Figure 2 viable?  That’s a question for global manufacturers to answer.  If you focus only on the U.S., a Distributed model would necessitate less rigid regulatory requirements than we currently have in California for it to be viable.

THE SEMI-CENTRALIZED TRACK & TRACE MODEL

The Semi-Centralized model is characterized by multiple “central” repositories of track & trace data around the globe.  What data is stored in each repository, and which repository must be used for a given transaction, is determined by local regulations and/or by the businesses involved.

The national track & trace repositories of China, Turkey, Brazil and Italy fit into this model like a glove.  The track & trace data for any drug that is distributed within those countries would be easy to find…it’s in that nation’s repository.

But in free-market countries where the model would be adopted without national repositories there are a number of ways you could design the implementation.  Most likely, solution providers would enter the business of providing repositories that conform to the regional regulatory requirements.  To solve the problem of a growing number of repositories that each end-user company would need to deal with, other solution providers (or the same ones) would likely offer connection services.

Here is one way a global Semi-Centralized track & trace model might look if there were three companies in the business of offering free-market repository services and six companies offering free-market connection services:

Figure 3. A Global Semi-Centralized Track & Trace Model. Notice that national repositories, free-market repositories and even POD Authentication fit nicely into this model.

The particular depiction shown in Figure 3 is the version of this model that I originally described in “A Semi-Centralized, Semi-Distributed Pedigree System Idea“, but with more details.  The Free-Market Repositories shown in this example would each contain all of the supply chain history of every serialized instance of specific GTIN’s as determined by contracts with the manufacturers (blue).  Therefore, each manufacturer only needs to connect to that one repository.  This would include GTIN’s that are labeled for sale in any “free-market” region.

For drugs labeled for sale in the U.S., distributors and pharmacies would find the supply chain history in a known location for each manufacturer’s product, but because they would buy and sell the products for all manufacturers, they would each need to connect with all of the free-market repositories.  They would obtain assistance in doing that from one of the free-market connection service providers shown.

In the E.U., POD Authentication would be done by querying the free-market repository that contains the information for that specific GTIN, through one of the free-market connection services.

The complete ePedigree (as defined by local regulations) for a single serialized drug package would always be held in a single repository, whether free-market or national, no matter where the product was distributed in the world.

In this model, global manufacturers would need to connect to a small, fixed number of repositories and could easily fulfill their free-market regulatory obligations, including ePedigree and POD Authentication, through contracts with their chosen repository service provider.  U.S. distributors and pharmacies could count on the availability of ePedigrees to fulfill local regulations like the California Pedigree Law without fear of loss of inventory value.

The Semi-Centralized track & trace model seems particularly viable to me because it solves so many of the problems for global pharma manufacturers without the added expense of GS1′s future Discovery Services.

Interestingly, certain implementations of the Distributed model could actually collapse slowly over time, into a distorted Semi-Centralized model.  This would happen if individual companies get tired of dealing with responding to queries from upstream trading partners and decide to turn that responsibility over to a service provider.  As that service provider increases the number of trading partners they are servicing, the model starts looking more “semi-centralized”.

I’d also like to point out how the Semi-Centralized model can be built over time in stages that each enable some supply chain security and other benefits.  For example, manufacturers could begin by posting only their EPCIS Commission events to their contracted repository service provider and that could enable a number of low cost serial number authentication technologies (cell phone, web page, web services) before the industry moves to the next stage–perhaps POD Authentication.  I’ll talk more about these stages, or “security plateaus” in a future essay.

Which of these global track & trace models is your favorite and why?

Dirk.

Earlier this month the Healthcare Distribution Management Association (HDMA) published newly updated guidance documents for the use of Accredited Standards Committee (ASC) X12 Electronic Document Interchange (EDI) messages in the U.S. healthcare supply chain.  This is a very important update that supply chain participants should take notice of because it includes new information about how to properly communicate GS1 identifiers, including GLN’s, GTIN’s, and Electronic Product Codes (EPC’s) like SGTIN’s and SSCC’s, within the four document types that are in common use for Order-to-Cash transactions.

The EDI document types included in the updated guidance includes:

• 810, Invoice
• 850, Purchase Order
• 855, Purchase Order Acknowledgement, and
• 856, Advance Shipment Notice (ASN)

Technically, these guidance documents are in four separate documents, but the HDMA has chosen to package all four into a single PDF file.  That seems like an odd choice, but at least you only need to download one (large) file.  You can submit an order for the document at the HDMA Online Store.  There are many useful documents on this site for sale or free download (to members).  The newly updated document I’m referring to is called

“EDI Guidelines For Order-to-Cash (810, 850, 855, 856) in the Healthcare Product Supply Chain (Electronic Download)”

The file download is free for HDMA members.

You can use the file as it is, although the page numbers start over at page 1 at the beginning of each of the sub-documents and that can be confusing.  I found it very slow to work with the single file so I downloaded a free utility from the SourceForge.net called PDF Split and Merge which allowed me to split the one large PDF file into the four separate PDF files.  This is the way they originally intended them to be and this way the page numbering in each document is accurate.

WHY THIS UPDATE IS SO IMPORTANT

As I said above, this update contains important new information about how to properly represent GS1 identifiers in the four standard EDI document types.  Each participant in the U.S. healthcare supply chains who plans to make use of EDI document to carry GS1 GLN’s, GTIN’s and EPC’s should follow this guidance so their EDI documents will be compatible and understandable by their trading partners.  The HDMA has determined the proper EDI segment type and representation for each type of GS1 identifier.  They include two detailed examples for each of the four document types.  In the EDI 856 ASN document, examples are included that show how to represent a detailed serialized packaging hierarchy.

Someday companies will probably make use of ePedigrees to pass unit, inner-pack, case and pallet serialized packaging hierarchy to their customers rather than ASN’s, but until the California pedigree regulations go into effect, this new HDMA guidance update shows how that data can be passed within existing EDI exchanges.  ASN’s are not ePedigrees, and companies should not expect to use them to comply with pedigree regulations, but for now, adding serial numbers to these common B2B messages can be a low cost way to pass this valuable data to your downstream trading partners.

If you are interested in sending or receiving GS1 identifiers and/or serial numbers within standard EDI messages, check with your trading partners to see if they are willing to adopt the changes in this important update.

In the healthcare supply chain a significant number of hospital group purchasing organizations (GPO’s) have stipulated, to varying degrees, that their suppliers begin making use of GS1 Global Location Numbers (GLN’s) in all of their trade with their member hospitals by the end of 2010 (Sunrise 2010) and GS1 Global Trade Item Numbers (GTIN’s) by the end of 2012 (Sunrise 2012).  Here are the announcements from Novation, Premier, MedAssets and Amerinet.  From the wording of their announcements it appears that you have little choice, especially if you have competitors who are planning to comply with their requirements.

Companies who supply these hospitals are faced with how to comply with those requirements.  The best advice I can give to companies that are facing these requirements is to contact the respective GPO offices and get their specific direction.  Each GPO may have a different interpretation of their own requirements.  GS1 U.S. is the second place you can go for additional information about the proper way to establish the necessary capability in your IT systems.

Here is a list of questions you may want to ask of each GPO to help you understand what you have to do to comply:

1. Do they require the use of GLN’s in addition to HIBCC’s Health Industry Number (HIN) or instead of it?
   
   
2. Do the GTIN requirements only cover medical devices or does it include everything a hospital purchases including pharmaceuticals and over-the-counter (OTC) products?  Does it include implants?  As I understand it, most implants currently use HIBCC product codes because they use alphanumerics which offers an expanded number of possible codes.  I’ve heard people speculate that the GPO requirements only cover medical devices, but when I read their announcements it sounds to me like they mean everything they purchase.
   
   
3. Are the 2010 and 2012 dates the earliest time you are allowed to begin using GLN’s and GTIN’s respectively in transaction documents, or can you begin using them as soon as you are ready?  In other words, can the GPO assure you that their member hospitals are ready to accept them whenever you are ready to supply them, or do you have to wait until the actual sunrise date, or worse, selectively turn on the capability, one hospital at a time, as they become capable of receiving them?
   
   
4. If you have every intention of making the necessary system changes to comply, but you just can’t get the resources necessary in time (remember, GLN by the end of this year), can you continue to do business with the member hospitals after the sunrise dates?  This is a test of how “hard” these deadlines really are.
   
   
5. The point of GLN’s and GTIN’s is to allow you to remove all of the supply chain master data (SCMD) elements that are associated with these numbers from all transaction documents.  But it’s unclear if that’s what the GPO’s are really asking for.  SCMD elements for GLN’s include things like the company name, street address, phone numbers ,etc.  SCMD elements for GTIN’s include things like the product name, size, color, form, weight, temperature requirements, etc.  Do they expect you to remove all of the master data elements that are associated with your GLN’s and GTIN’s from your transaction documents (printed and electronic), or do they want to keep all of that data in your documents, but just add the GLN numbers and GTIN numbers?
   
   
6. Do they require you to subscribe to and register your GLN’s in the GS1 U.S. GLN Registry for Healthcare, or can you just provide them with your GLN(s) and their associated supply chain master data?  If they don’t require you to use the GLN Registry, what mechanism will they accept for transmitting your supply chain master data?
   
   
7. Similarly, do they require you to subscribe to a GS1 GDSN data pool and maintain your product’s supply chain master data there?  If not, what mechanism will they accept for conveying your product master data?  (Depending on their answer to #5 above, they may not need you to give them your SCMD, yet.)
   
   
8. What if you are a wholesaler and the manufacturer’s of the medical devices and pharmaceuticals you supply to their member hospitals do not even have GS1 GTIN’s defined for their products but have HIBCC-based product codes instead?  (GS1 GTIN allocation rules prevent you from creating GTIN’s on behalf of the original manufacturers.)  Will the HIBC code fulfill the requirement? 
   
   Be aware that the GS1 U.S. GLN Registry for Healthcare will not accept HIN’s and GDSN data pools will not accept HIBC codes.  Will the GPO’s accept the use of HIBCC’s HIN System database in addition to the GS1 Registry?  Will they accept the use of HIBCC’s UPN Repository in addition to GS1’s GDSN?  Don’t get your hopes up, but these are important questions for you to ask just to get clarity on what is expected of you.

I’m told that many ERP systems are able to define a custom set of item number aliases for each of your customers.  That’s one way to force the use of GTIN’s for each SKU on your transaction documents for GPO members.  Of course, GS1 is hoping you decide to cascade the GPO requirements to all of your internal systems and then to your suppliers as a GPO-like requirement.  That approach would spread the use of GS1 identifiers throughout all of your IT systems that deal with supplier and customer addresses (GLN’s) and item information (GTIN’s).

That might be a pretty big change, but you should evaluate the pros and cons of both approaches before you decide which way is best for you.  One thing to keep in mind is that the Sunrise dates are not regulatory requirements and GS1 has no authority to place requirements on anyone.  At this writing, it’s only a requirement of some GPO’s.  On the other hand, it’s hard to imagine that the supply chain can achieve a steady state with a mixture of HIBCC and GS1 location and product identification codes once the GPO mandates are operational.  More than likely the switch from HIBCC standards to GS1 standards will accelerate until only GS1 remains.

GS1 U.S. RESOURCES

GS1 U.S. has prepared a number of documents to help GPO suppliers meet the Sunrise requirements.  Most of them can be found in the GS1 U.S. Healthcare Document Library.  I’ve already provided hyperlinks to some of these resources above but here are a few more that you will find helpful:

• JUST RELEASED!  2010 GLN Sunrise Explained:  Industry Implementation Plan 
• Mayo Clinic – Cardinal Health GLN White Paper
• GS1 U.S. Healthcare Industry Sunrise Dates web page with links to toolkits and white papers
• Introduction to GS1 Standards in Healthcare
• GS1 U.S. Healthcare web site

SO YOUR SUPPLIER HAS ANNOUNCED THAT THEY ENDORSE GS1 STANDARDS, WHAT DOES THAT MEAN TO YOU?

At least one medical products wholesaler has recently stated that they endorse GS1 standards, specifically GLN and GTIN.  See a copy of their statement on page 3 of this report.  It appears that they are not requiring their suppliers or customers to support these standards, but if you are from a company who buys medical supplies from a company who has made an announcement like this and you prefer to continue using HIN for location codes and HIBC product codes, make sure you read their statement yourself and decide what it means to you.  If you have any questions you should contact them directly.

WHY ARE COMPANIES MAKING THESE ANNOUNCEMENTS ANYWAY?

There are two primary goals that underlie the movement to GS1 identifiers in the healthcare supply chains:  Patient Safety and Efficiency.  In my observation, companies who have decided to throw their weight behind the GS1 sunrise dates are doing it to remove as much ambiguity as possible from supply chain transactions.  Ambiguity is the enemy.  Ambiguity causes inefficiencies and it can harm patients, or worse.  And we have tolerated way too much ambiguity in the supply chain for too long.

Most of the ambiguity in the healthcare supply chains today occurs when companies use different master data than their trading partners are using for the same product or location.  That is, each company is maintaining their own local master data (MD) for each product code and each customer and supplier location.  They are using MD when they should be using Supply Chain Master Data (SCMD).  SCMD removes ambiguity because there is a single version of the truth across the entire supply chain for each product and location.  With SCMD, there is only one company responsible for maintaining the master data for each identifier on behalf of the entire supply chain, and that company is the owner of the data.  That is, each manufacturer is responsible for maintaining the SCMD for the products they manufacturer, and all of the other companies in the supply chain are provided that data, along with each update as soon as it occurs.  The same for each location in the supply chain.

GS1’s standard for the synchronization of supply chain master data (SCMD) is Global Data Synchronization Network (GDSN).  So why are we hearing about requirements for the adoption GLN and GTIN and not for GDSN?   The reason is simple.  The adoption of GS1’s GDSN standard for the synchronization of supply chain master data (SCMD) can only occur when there is a surge of trading partners who agree to implement it all at once, and who then put pressure on their other trading partners to adopt it at the same time.

It’s a very high threshold that must be overcome before GDSN can provide benefits to the supply chain.  So the first thing you have to do is get your supply chain to use the same standards for product and location identifiers.  That’s a prerequisite to GDSN.  GLN and GTIN are the only identifier standards that work with GDSN so that’s why we have Sunrise 2010 and 2012.  I will be very surprised if we don’t eventually see a Sunrise date issued for the adoption of GDSN by the same GPO’s once the supply chain is using only GLN’s and GTIN’s.  Use of a single standard for SCMD is the least complex way to remove ambiguity, which will finally elevate patient safety and supply chain efficiency, the ultimate goals.

HOW DOES HIBCC FIT INTO THE GLN, GTIN AND GDSN WORLD?

Short answer:  it doesn’t.  As I pointed out in my previous essay, the success GS1 has had in capturing the attention and support of the GPO’s is the biggest blow to HIBCC’s future.  GS1’s standards are currently designed to work only with GS1 identifiers, and that’s unlikely to ever change.  Part of the removal of ambiguity is narrowing the supply chain to a single set of standards and GS1 has the upper hand right now.  The fact that the block that is driving toward GS1 standards is composed of hospitals is significant.  Hospitals are large consumers of medical devices that have traditionally been identified with HIBC codes, more so than pharmaceuticals anyway.  Once that domino falls, it’s hard to imagine where HIBCC’s support will come from.

This is not my last word on the war between GS1 and HIBCC but I’m not sure if I will have time to complete the subject before the FDA releases their Serialized Numeric Identifier (SNI) guidance, which is due by the end of this month.  I hope to post my thoughts on SNI shortly after they publish.  Watch for it.

Dirk.

For more RxTrace essays related to this topic see:

• “WAR: GS1 Vs. HIBCC “
• “Anatomy of a GTIN“,
• “FDA Aligns with GS1 SGTIN For SNDC “,
• “Updated HDMA Bar Code Guidance: A Must Read “
• “Anatomy Of The National Drug Code“.

That’s right.  GS1 and HIBCC are in a multi-year fight over the dominance of their standards within the U.S. healthcare supply chain.  The U.S. healthcare supply chain is split into two chains:  pharmaceuticals and medical devices.  While the FDA regulates both supply chains and many companies participate in both, there are differences in the standards that have been used historically in each.  The biggest differences are in the unique product identification and location identification.  

HEALTHCARE PRODUCT CODE STANDARDS

FDA created the National Drug Code (NDC) system back in 1972 and mandated its use for all drugs.  At the same time, FDA also created a compatible numbering system called the National Health Related Item Code (NHRIC) for devices but it was apparently voluntary and is apparently now obsolete.  FDA is currently working on the definition of a new numbering system for devices—known as the Unique Device Identification (UDI) system.  The development of the UDI system was one of the initiatives kicked off by the Food and Drug Administration Amendments Act of 2007.  Until UDI is complete, identifiers used for medical device have not been governed by the FDA so companies have been left to make their own decisions about them. 

The U.S. Department of Defense (DoD) didn’t like this situation because it caused confusion in their product ordering and receiving so in 1995 they created the Universal Product Number (UPN) system for medical devices.  They defined a UPN in such a way that the product numbering systems of two competing industry standards organizations could be used.  The Health Industry Business Communications Council (HIBCC) applied their Labeler Identification Code (LIC), and the Uniform Code Council (now GS1 U.S.) applied their GS1 Company Prefix (GCP) as the basis of their UPN’s.  HIBCC appended their 4-alphanumeric-character LIC with a 1 to 18 alphanumeric character product code to form their UPN.  GS1 appended their variable length numeric GCP with a variable length numeric product code to form their 14-digit UPN (also known as a Global Trade Item Number, GTIN-14).  A company must pay a fee to HIBCC if they want to obtain a LIC and a fee to GS1 U.S. if they want to obtain a GCP.

Because the DoD doesn’t need to buy every possible type of medical device, not all devices currently passing through the U.S. supply chain have a DoD-compliant UPN.

HEALTHCARE LOCATION CODE STANDARDS

HIBCC and GS1 U.S. also compete in the healthcare location code standards arena.  HIBCC has the Health Industry Number (HIN) standard and GS1 has the Global Location Number (GLN) standard.  The HIN and GLN differ in multiple ways.  First, the HIN is composed of nine alphanumeric characters assigned by HIBCC, while the GLN is 13-digit number composed of the same GCP found in the GTIN UPN plus a Location Reference that is selected by the owner of the GCP.  It’s an important difference that HIBCC assigns the entire HIN because it means that there is a single point of control for these numbers.  Because each end-user company can define their own GLN’s, GS1 U.S. has to have a GLN registry so that companies can find the GLN’s for their trading partners.  It’s called the GS1 U.S. GLN Registry for Healthcare.

The funding of the HIN and GLN systems are another important difference because of what results.  The assignment of HIN numbers is done by HIBCC for each manufacturer, wholesaler, pharmacy and provider location in the supply chain without those organizations requesting it.  The cost of this “automatic” number assignment is covered by HIBCC.  GS1 GLN’s are only defined when a GS1 GCP subscriber decides to create one.  This means that companies who already own a GCP do not have to pay additional fees to create GLN’s for their locations.  (GS1 also sells individual GLN’s for a lower fee for smaller companies who do not need the full capability of a GCP.)  HIBCC does not charge for listing a company’s HIN’s in their HIN databases, but they do charge for access to those databases.  GS1 charges a fee to list and access their GLN registry.  For these reasons, the HIBCC HIN databases should contain the HIN’s for every location in the entire healthcare supply chain, but the GS1 U.S. GLN Registry for Healthcare will contain only those locations for companies who choose to pay for a GCP or an individual GLN, and who choose to pay to be listed in their registry.  Currently, that’s not as many companies.

One of the problems with industry reliance solely on the GS1 GLN for location identification is that smaller companies, like independent pharmacies, are unlikely to bother acquiring a GCP or a GLN.  Industry reliance solely on the HIBCC HIN doesn’t have this problem because smaller organizations don’t have to pay anything or initiate any action whatsoever for a HIN to be created for their locations.  HIBCC does that on their behalf.

HIBCC was originally formed with the purpose of developing standards for use in the medical devices side of the healthcare supply chain.  On the other hand, the HIBCC HIN was widely adopted on both sides of the supply chain.  GS1 GTIN’s have be used in the pharmaceutical side for many years because early on, GS1 reserved the FDA Labeler Code number space used as the basis of the NDC within their GCP number space.  Pharmaceutical manufacturers still had to register their Labeler Code and pay a fee to GS1 before they used their FDA Labeler Code as a GCP, but this reservation ensured that there would not be any clashes in the future.

STANDARDS WAR

In the title of this essay I called it a war.  That’s not much of an exaggeration.  In my observation, what is going on right now between HIBCC and GS1 is aimed at the total elimination of the other.  GS1 is usually the aggressor and HIBCC is usually found in a defensive posture.  There is lots of evidence of this on the internet.  Here are a few pieces I have found. 

• Check out the opinion of the “Editor” in his/her remarks at the top of this Loftware Blog post from last year.  Yow, that’s blunt. 
• Here is a copy of an article called “Standards Movement Shifts Toward GS1 Version”, from a March 2009 edition of the Hospital Materials Management Newsletter that is hosted on the HIBCC website.
• Here is a HIBCC newsletter from 2008 that contains multiple articles about the war from HIBCC’s perspective.  In fact, most of the articles in the issue take up various aspects of the war.
• Here is a recent article about the HIBCC Vs. GS1 “debate” from the February 2010 edition of Repertoire Magazine called “Is One the Loneliest Number?”.
• Perhaps the salvo that GS1 has made that is the most harmful to HIBCC is their success in getting multiple large hospital group purchasing organizations (GPO’s) and other healthcare organizations to announce that they are adopting/embracing GS1 standards—presumably at the expense of HIBCC standards.  GS1 is rightfully so proud of these and other related announcements that they have collected links to them all on a single page.
• The GPO’s have established two programs designed to push the supply chain to adopt GS1 GLN’s and GTIN’s on an aggressive schedule.  These are Sunrise 2010 for GLN and Sunrise 2012 for GTIN.  GS1 promotes these programs at every opportunity, but they carefully point out that these are not GS1 programs but those of “organizations and companies throughout the U.S. healthcare supply chain”, yet you can’t find anyone else who claims to own them.  Obviously GS1 owns them, but for some reason they don’t want to admit it.
• I have covered several aspects of this debate in previous posts.  This one about a flawed AHRMM sponsored survey that clearly favored GS1 and this one about the perceived “rush” to GS1 standards in the healthcare supply chain.
• GS1 has signed “memorandums of understanding” (MoU’s) with a number of other standards development organizations which, in effect, establishes a treaty between them that defines the type of standards that each organization can develop without encroaching on the other.  GS1 has MoU’s with HL7 and ICCBBA.  No such understanding exists between GS1 and HIBCC because there is already too much overlap in their standards.
• In 2008 HIBCC adopted their own RFID standard that follows ISO standards so that it is at least interoperable with GS1’s EPCglobal RFID standards.  See also this.

Will this war ever end as long as both sides are still standing?  Maybe.  If HIBCC is to survive they will have to find a way to co-exist with GS1 standards.  I have an idea that could remove part of the wedge that seems to force companies to think they have to align with one standards company or the other.  I’ll share my idea in a future post.  (See that future post at Masterpiece: GS1 Tag Data Standard 1.5.)

Does the supply chain itself make any contribution to patient safety?  The legitimate pharmaceutical supply chain is that complex web of companies that move drugs from the manufacturers to the pharmacies that dispense them to patients.  The supply chain always includes both of those end points (manufacturer and pharmacy) and, in the U.S., normally also includes at least one wholesaler.  The supply chain is typically viewed as “Manufacturer to Wholesaler to Pharmacy”, whether the pharmacy is within a hospital, clinic, retail independent, chain store, grocery store, or mail order.  The great majority of prescription drugs arriving in the hands of U.S. patients have passed through this supply chain.

So what contribution does this chain make toward the safety of those patients?  In my view, it comes in three ways:

1. Supply Chain Integrity
   This includes the responsibility of each supply chain company—and by extension to each of their employees—to be ever vigilant for attempts by criminals to introduce illegitimate drug products into the legitimate supply chain.  Trading partners should know their suppliers very well (to prevent the introduction of counterfeit, tampered or stolen drugs) and they should also know their customers (to detect and stop diversion).  The protection of patients here is fairly obvious.  They can trust that the prescriptions they receive at any legitimate pharmacy in the U.S. will contain exactly the legitimate drug their Doctor or Pharmacist prescribed.  When supply chain integrity breaks down, very sad things happen.
2. Recall Execution
   This includes extremely fast (near instant?) blockage of any shipment of units covered by a recall, communication of the recall notice to supply chain customers who have been shipped the recalled units any time in the past, and a tight quarantine of the recalled units to ensure that they cannot make their way back into regular stock.  Once a recall is issued—especially a safety recall—there should be no way for these units to move forward in the supply chain again.  Patients are protected by the immediate removal of a large pool of the recalled items from their availability, thereby reducing the problem to those remaining units that have already been dispensed to patients by pharmacies (and those drugs are outside the supply chain).  When this breaks down, patients may end up being dispensed prescriptions that contain the recalled medicine even after the recall has been issued.
3. Data Quality
   This includes the use of accurate data about each drug by every company in the supply chain.  The drug manufacturer creates this data and each successive owner in the supply chain must ensure that they are using that exact data as part of their buying, selling and dispensing.  Patients are protected mostly by their pharmacy’s use of accurate data, but because the supply chain arm of a pharmacy company may rely—at least in part—on data received from their supplier, in those instances, the quality of the data supplied will have a direct impact on patient safety.  When this breaks down there is a slight, but unnecessarily elevated risk that a patient somewhere could receive the incorrect dosage, the incorrect drug entirely, or a drug that is covered by a known recall.

Interestingly, all of these contributions to patient safety become much easier to implement and are much more reliable in execution when the drug packages are serialized and all companies in the supply chain make use of those serial numbers to maintain pedigrees.  For downstream trading partners to be able to make use of these serial numbers it is essential that manufacturers also supply two types of data for each product they serialize:  Supply Chain Master Data (SCMD) for each Stock Keeping Unit (SKU), and Instance Data (IData) for each serial number.

SUPPLY CHAIN MASTER DATA SYNCHRONIZATION

SCMD is the data that describes each product that is traded in the supply chain.  The synchronization of that data requires the creator (with a lower case “c”…I’m referring to the drug manufacturer here, not God) to pass it to every potential supply chain owner of their products, and keep it up-to-date, so that they always have the correct information.  The product code is the identifier that is used by supply chain members to link to, and reference, the SCMD.  In the case of drugs in the U.S., that product code is the NDC.

As you might expect, GS1 has a series of standards that can be used to implement SCMD.  They include the Global Trade Item Number (GTIN) and Global Data Synchronization Network (GDSN) standards.  In the pharmaceutical supply chain a GTIN can be composed from the combination of an FDA-issued Labeler Code and FDA-registered Product Code (the two components of the NDC) as a base, although manufacturers are expected to register with GS1 and pay a fee before doing so.

GS1’s GDSN is a standard that can be used by supply chains to communicate SCMD to all of the companies who participate in it.  Generally, its use requires all trading partners in a given supply chain to subscribe to a GDSN-conformant Data Pool service provider.  Unilateral adoption of GDSN by a single company doesn’t make any sense.  It’s a high bar for a large and complex supply chain to achieve through voluntary means.  Right now the pharma supply chain in the U.S. has not achieved it and so the quality of SCMD in the supply chain is currently dependent on ad hoc relationships and data passing.  Some of this includes manual data entry into the local master data systems at many points in the supply chain. 

INSTANCE DATA COMMUNICATION

Instance data is data that describes the unique and specific identity of individual units, or a relatively small collection of units of a given SKU.  For the pharmaceutical supply chain this always includes the lot and expiration date of each unit, but in the future it could also include covert security elements that could vary and therefore could be unique by the individual unit.  Like SCMD, only the creator (again, the manufacturer, but also repackagers) can create the instance data.  The unique identifier—typically composed of the product code plus a serial number—is the identifier that is used by supply chain members to link to, and reference, the instance data.  Some instance data, like information about individualized covert security elements, are not shared with downstream trading partners but are kept by the creator for use in their product or package authentication system, but data like lot and expiration date must be shared with downstream trading partners.

Again, as you might expect, GS1 has a standard to help supply chains exchange instance data.  The Electronic Product Code Information Services (EPCIS) standard can be adopted by supply chains for this purpose.  Unlike GDSN, there may be reasons a company can find value in applying EPCIS unilaterally, but the adoption of EPCIS for communicating instance data with trading partners only makes sense if all of your trading partners agree to adopt it as well.  So far the pharma supply chain in the U.S. has not yet adopted EPCIS widely for the purpose of exchanging instance data, but the standard has caught the attention of a number of the larger corporations within the supply chain.  Some of those companies are working with GS1 U.S. to figure out how this instance data can be exchanged in an interoperable way.  Currently there is no widely adopted alternative approach for communicating instance data because serialization, the enabling prerequisite technology, is only just now starting to be deployed on a handful of products in the supply chain.

MOTIVATION FOR ADOPTION

Deploying applications that serialize units, synchronize SCMD and communicate instance data through the supply chain is expensive.  Generally, companies look for hard financial returns on any investments they consider.  It’s nearly impossible to find a positive ROI from serialization and the associated data synchronization and communication.  That is, depending on how you measure “return”, and that depends on your motivation. 

Richard Feldman, Vice President of Trade and Product Safety at EMD Serono, a manufacturer of biopharmaceuticals, and Ron Bone, Sr. Vice President, Distribution Support at McKesson, a U.S. pharmaceutical wholesaler, both spoke about motivation as it relates to adoption of this type of technology at the Track and Trace Technology Seminar held by the Healthcare Distribution Management Association (HDMA) this past December.  Feldman spoke about his company’s high-level commitment to patient safety and how that commitment motivated the corporation to view funds spent on technologies designed to protect the supply chain as sound investments.  They measured the return on their investments differently than those who looked only for the hard financial returns that are so hard to come by.  Bone spoke of a similar commitment at McKesson.  Both referred to understanding and support from the highest levels of the company leadership. 

These are true supply chain organizations who realize that their very existence as participants in the pharma supply chain comes with a responsibility to contribute to its integrity.  The “return” on those investments may be immeasurable because it is most directly collected by their ultimate customers—the patients.  The result is a more secure supply chain, and a more secure supply chain is a healthier one.  One that will continue to operate well, and that ensures their ongoing participation in it.  Now that’s a “return” that every company should recognize and embrace.