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.

In a long awaited and much anticipated move the Healthcare Distribution Management Association (HDMA) published updated guidance for the formatting, encoding and placement of barcodes in the U.S. pharmaceutical supply chain.  The document is called “HDMA Guidelines for Bar Coding in the Pharmaceutical Supply Chain 2011”.  The guidance is aimed mostly at pharma manufacturers and repackagers who place barcodes on their drug packages, cases and pallets.  The last time the guide was published was in 2005 and this new edition includes some significant changes that everyone in the supply chain who deals with product and shipping container labeling should be aware of.

The updated document can be downloaded from the HDMA Marketplace web page.  It is free to HDMA members.  Non-members will need to pay a fee but don’t let that stop you from downloading a copy if you have any responsibility for applying or reading barcodes in this supply chain because you will need to make changes to keep up with the direction of the technology and the industry.

Full disclosure:  I work for a company that is a member of HDMA and I contributed to the development of this updated guideline, but this essay is not a marketing pitch for the benefit of HDMA or my pride.  Rather it is to help generate alignment around a common approach within the supply chain.

HDMA GUIDELINES FOR BAR CODING IN THE PHARMACEUTICAL SUPPLY CHAIN

The guidelines provide the reader with the industry-specific information necessary to know how to apply GS1 and HIBCC standards in the U.S. pharmaceutical supply chain.  It provides an excellent discussion of barcode standards, including some history which I made use of in my recent RxTrace essay “Anatomy Of The National Drug Code”.  It explains how those standards should be applied to identify drugs at all levels of packaging as they move through the supply chain so that companies can maximize the benefits of barcode technology.  This edition provides expanded guidance on the implementation of 2D barcodes and RFID on packages and shipping containers.

For the first time the HDMA now “…recommends investing in imaging scanners capable of reading Data Matrix and linear codes whenever auto-id procurement needs are under consideration.”  This HDMA recommendation aligns well with GS1 Healthcare’s position as published in 2009.

Both of those recommendations make sense because we are now standing on the threshold between two barcode eras in the U.S. pharma supply chain:  linear in our rear-view and 2D in our forward-view.  Any investment in linear-only barcode reading and writing equipment now probably won’t reach the end of its full depreciation still in use.

Imaging equipment manufacturers have made great strides in the last decade in nearly matching the read performance of linear barcode readers and the prices have come down.  Linear readers will probably always be cheaper than imagers but you should consider this lower cost a reflection of the fact that they are now in the “discount bin” of obsolete technologies.

Linear codes are not dead yet, but I think we are going to see a fairly rapid transition to 2D barcodes in this industry with the approach of serialization regulatory mandates here and abroad.  See my RxTrace essay “SNI’s Are Not Enough In a Plateau-Based Supply Chain Security Approach“ for more on this.

The development of the HDMA guideline documents over the years have benefited by the contribution of George Wright IV, Vice-president of PIPS / Product Identification & Processing Systems, Inc.  George is an automatic identification and data capture (AIDC) industry veteran and I have found him to be a bottom-less well of technical and historical knowledge in this area.  Many sections in the HDMA guidelines have a depth and quality that come directly from George’s contribution.

CHANGES

If you think you already know how to properly format and print barcodes on drugs marketed and shipped in the U.S., you need this edition of the guidelines.  There are some significant differences from the way things have been done up to now.  The first section of the updated document is a Summary of Revisions.  Here is a partial list:

• Addition of a unique serial number in the GS1-128 product identification bar code to product case labels;
• Addition of an optional but recommended 2D GS1 DataMatrix bar code symbol to drug packages and product case labels;
• Removal of ITF-14 as a Primary Data Carrier (bar code) option for product case labels;
• Removal of AI(22) as a Secondary Data structure option on product case labels.  This is a major departure from the way things are done today because AI(22) currently appears on about 75% of all product cases in the U.S. pharma supply chain.  The document provides details on what AIs to use in place of AI(22) and how to arrange them;
• Reduction in the minimum X-dimension for GS1-128 symbols.  This move enables a slightly tighter linear barcode on case labels so that serial numbers can be added to them without blowing out the available space;
• Reduction in the minimum height for GS1-128 symbols on case labels.  Another move to free up precious real estate on case labels so that serial numbers will fit in the barcodes;
• A new HDMA recommendation for adding GS1 serial numbers to units and shipping containers;
• New information on standardized numerical identifiers (SNIs).

ENFORCEMENT?

The HDMA does not enforce compliance with their guidelines.  That is, if you don’t follow their guidelines no one from the HDMA will knock on your door or send you a cease and desist letter.  The same goes for GS1.  The U.S. FDA tightly regulates everything that appears on drug primary packaging—including the linear barcode that encodes the NDC—but they don’t regulate the contents of case-level product identification or shipping labels.  While the U.S. Drug Enforcement Administration (DEA) does place certain restrictions on the information that appears on shipping labels (and they will come knocking on your door if you fail to follow them) those are limited to controlled substances.

So who enforces compliance with the HDMA guidelines?  In reality no one does and that has led to a major missed opportunity for improved efficiency, accuracy and even profitability in the supply chain.  Unfortunately very few companies follow all of the HDMA guidelines closely and that causes downstream trading partners to miss out on the opportunity to maximize the use of product case barcodes in operations like receiving, inventory management, picking and shipping.  Barcodes are certainly used extensively in all of those processes today but case-level product identification labels cannot always be trusted because there is so much variance in compliance to both GS1 standards and HDMA guidelines.  If you can’t trust the data in the barcode you can’t achieve its promise to maximize efficiency and data capture accuracy.

Some pharma manufacturers take their product case labels very seriously and have a program to ensure that they comply with the standards and with HDMA’s guidance, even without any heavy-handed enforcement.  I applaud them.  But the truth is, the majority of companies seem to take a quick stab at producing the barcodes on their case labels and then ship them out.  If no one complains, they probably think they got lucky and got it right the first time.  In other supply chains that face intense price competition these kind of inaccuracies and waste are not tolerated.

I keep thinking that something will trigger closer attention to detail in the construction of case labels in the pharma supply chain.  Maybe this newly updated guideline from HDMA is just what we need.  Do you think it will have a positive impact?  Leave a comment below.

Dirk.

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.

GS1 EPCglobal ratified and published the most recent version of the Tag Data Standard (TDS), 1.5.  I have always been a fan of TDS, but earlier versions served as much to expose embarassing disconnects in GS1 standards as they did to explain how to apply GS1 identifiers in an Radio Frequency IDentification (RFID) context.  Earlier versions of TDS tightly bound the concept of the Electronic Product Code (EPC) to RFID, and that’s just wrong.  “EPC”, even as defined in those earlier versions of TDS, is a way of uniquely identifying objects on a global basis.  It’s purely a globally unique identifier standard.  That’s a hugely important and relatively new concept.  RFID–a simple data carrier technology that’s been around for many years–is almost insignificant in comparison.

Even the name “Tag Data Standard” reflects this wrong-headed binding of EPC to RFID by seeming to place the RFID “Tag” at the center of the “standard”.  Yes, there is a need for a “Tag Data Standard”, to show how to encode an EPC into an RFID tag, but it is wrong to hide the definition of the EPC inside such a limited specification.  EPC is carrier technology independent.  RFID is only one of several carrier technologies that can carry EPC information. 

This disconnect between the standard and reality has caused a lot of confusion, even within GS1 where people seem to fall into one of two catagories distinguished by either bar codes or RFID.  People from both worlds within GS1 have assured me that and EPC can only be encoded into an RFID tag.  They are wrong, and GS1 would be a better organization if everyone associated with it would study the EPC and think about what it means to GS1 and its users.  I think it would expand their minds.

But finally, in TDS 1.5 it is made clear…  

“Nevertheless, it should always be remembered that the EPC and RFID are not at all synonymous: EPC is an identifier, and RFID is a data carrier. RFID tags contain other data besides EPC identifiers (and in some applications may not carry an EPC identifier at all), and the EPC identifier exists in non-RFID contexts (those non-RFID contexts including the URI form used within information systems, printed human-readable EPC URIs, and EPC identifiers derived from bar code data following the procedures in this standard).”

Now GS1 needs to update a lot of their documentation to reflect this reality.  Much of it continues to perpetuate the tight linkage of EPC and RFID.  See this FAQ for example.

This separation of EPC and RFID is pertinent in the pharmaceutical supply chain right now because many companies are planning to apply globally unique serial numbers to their products to comply with regulatory requirements in countries like Turkey, Brazil, Italy and in states like California.  At the same time most of them are also planning to apply globally unique serial numbers to their cases, pallets and totes.  The companies I am aware of are currently planning to use GS1 EPC’s for these serial numbers, but, as I predict in “RFID is DEAD, at Unit-Level in Pharma“, most will not use RFID to carry those numbers, but will use 2D barcodes instead.  A few will use RFID and 2D barcodes to carry a single EPC.  None of these uses would be possible if the EPC wasn’t fully distinct from the carrier technology.

TDS 1.5 IS A MASTERPIECE…BUT…

Yes, TDS 1.5 is a masterpiece.  For the first time there are separate sections for the EPC and for RFID as a carrier technology of EPC’s, and it is written in a way that is very easy to understand.  This version also includes clear information about encoding GS1 element strings into EPC’s.  GS1 element strings are values that are typically encoded into barcodes.  But if it were up to me in the future, GS1 would entirely remove the specification of the EPC from TDS.  There would be an EPC Standard, a Tag Data Standard (let’s call it TDS 2.0), and a Barcode Standard.  Or perhaps they should keep all carrier technologies in a single standard.  I’d call it the “EPC Carrier Standard” and it would have an RFID section and a barcode section.  It would show how to encode any EPC into one carrier technology or the other and how to convert from one to the other without data loss or ambiguity.  TDS 1.5 is very close to this ideal.

It seems simple and the need is great because pharmaceutical companies are moving forward right now, but GS1 has been grappling with RFID and bar code interoperability for quite a few years.  TDS 1.5 goes a long way toward resolving these issues, but full resolution is still ahead of us.  Oh well, maybe TDS 1.6 will be an even better masterpiece.  Watch for it to arrive sometime next year.

WHAT IS THE EPC AND WHY HIBCC SHOULD PAY ATTENTION

The EPC standard, encased inside of the RFID-Tag Data Standard 1.5, is so simple that it’s not surprising that people miss it.  Section 4 of TDS 1.5 expresses it this way:

“The EPC is a universal identifier that provides a unique identity for any physical object. The EPC is designed to be unique across all physical objects in the world, over all time, and across all categories of physical objects. It is expressly intended for use by business applications that need to track all categories of physical objects, whatever they may be.”

The most likely systems to recognize and operate on EPC’s are those that are based on the GS1 Drug Pedigree Messaging Standard (DPMS, a.k.a., the GS1 Ratified Pedigree Standard), or the GS1 EPC Information Services (EPCIS) standard.  Both of these standards specifically work with EPC’s.  DPMS, of course, is specificly designed for compliance with U.S. electronic document-based pharmaceutical pedigree laws like California, Florida and the federal PDMA.  EPCIS is an interface standard for use in systems that focus on documenting object visibility in a supply chain.  The future GS1 Discovery Services standard will also operate on EPC’s.

I assume that GS1 has copyrighted the acronym “EPC”, but what’s interesting is that there is nothing special–nothing GS1-specific–about creating an object identifier that can be used in systems based on DPMS or EPCIS.  That’s because those two standards simply require the use of unique identifiers that follow a set of open W3C standards, specifically RFC2396 (see also RFC2141 and RFC3406).  GS1 refers to this as an identifier in “pure identity” format, which is also known as “URN” format (“URI format” to purists).

For example, a valid identifier for use in DPMS or EPCIS for an object serial number that I took from TDS 1.5 is:

urn:epc:id:sgtin:0614141.112345.400 

GS1 was issued the namespace “epc” by the Internet Assigned Numbers Authority (IANA) and that gives them the authority to define the schema for all of the data elements to the right of the letters “epc:” in the identifier above.  TDS 1.5 specifies what each of those segments mean and their value ranges.

But DPMS and EPCIS would work just as well if the object’s unique serial number were defined with some other valid URN: namespace besides “epc:”.  Nothing stops organizations (like the Heath Industry Business Communications Council, HIBCC) from acquiring their own namespace from IANA and defining their own schema that would encode their own unique, non-GS1 serial numbers.  And those URN: formatted (URI formatted for the purists) unique identifiers would work just as well and would be fully interoperable with other “URN:EPC:” serial numbers.  Of course, just don’t call them EPC’s.

For many types of commercial objects, there are no viable alternatives to GS1 numbering so use of GS1 EPC’s are a given.  But whenever medical products are serialized at some time in the future, GS1 is only the latest entrant (though growing fast as I point out in “WAR: GS1 Vs. HIBCC“).  HIBCC was the traditional numbering not-for-profit organization for these type of devices and they recently introduced their own approach to unique identification based on their Labeler Identification Code (LIC) and an added serial number.  Like GS1, they hid it inside of their RFID specification.

With version 1.5, TDS has gone through an impressive rewrite.  It’s easy to read, especially the first 6 sections (23 pages).  I highly recommend it to anyone wishing to better understand the EPC standard at the conceptual level.

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.)

In April of last year VHA, a nationwide network of community-owned health care systems, published a viewpoint essay on their website called “The Track to Improving Health Care will be Built with IT Standards”.  The posting was written by Mike Cummins, Chief Information Officer of VHA, Inc.  In it, he draws a great analogy between the widespread adoption of a standard railroad gauge by railroad companies 150 years ago as part of the U.S. Transcontinental Railway (as set in motion by President Abraham Lincoln), and the potential benefits of widespread adoption of health care IT standards.  Mike points out that some historians believe that the nationwide adoption of a single railway gauge accelerated the evolution of the greatness of the United States.  It’s well worth reading.

I think the problem Mike sees is that there are so many incompatible IT standards in use in the healthcare industry, with different ones in use in different pockets of the industry.  There are too many proprietary approaches in use, and too many standards in use in one segment of the industry that are incompatible with similar standards in use in another.  In effect, it’s a patchwork, yet each user can claim to be using a standard.  This was exactly the case with the railroads 150 years ago as Mike’s analogy implies.  Each railroad company, or groups of companies, had their favorite “standard” gauge, but which standard was “the best”…the one worthy of becoming the national standard?  I don’t know, but I do know they eventually figured it out and settled on a single gauge for the Transcontinental Railroad and that gauge become the defacto standard.  That allowed the country to be connected and, as Mike points out, historians have dawn a direct line from that agreement to economic expansion and eventual greatness.

Mike makes several proposals that I interpret as ways to cut through the patchwork of standards and get the industry to settle, like the railroad companies, on a single standard for some key technologies like Electronic Medical Records (EMR), Health Identification Numbers and Personal Health Records (PHR).  He calls for the broad, mandatory adoption of GS1barcodes, Global Location Numbers (GLN), Global Trade Item Numbers (GTIN) and accelerated plans by the FDA to mandate the usage of Unique Device Identification (UDI).  He calls for the use of part of the federal economic stimulus money to be used for standards development. 

SLEEPY PROPOSAL BECOMES HOT TOPIC

Fast forward to January 6, 2010.  On that date, VHA issued a press release calling for actions by the FDA and the Obama Administration that were the same as the Cummins posting from last April.  The title of the press release is “VHA Inc. and 12 of the Nation’s Largest Health Care Systems Call for Government to Mandate GS1 Data Standards to Improve Health Care”.  The press release did not include Mike’s railroad analogy.  While the Cummins essay didn’t appear to get any response on the internet, the VHA press release was widely copied by many news release websites.

The very next day, ModernHealthcare.com published a brief news article based on the VHA press release titled, “VHA, member hospitals push GS1 standards”.  One day later the same website posted a comment from Ted Almon, President and CEO of Claflin Co., a Rhode Island based healthcare distributor, about the press release.  The subject of Ted’s posted comment is “Why the rush for GS1 standards?”.  In it, Ted, a veteran of past standards development efforts which led to the formation of the Health Industry Bar Code Council (HIBCC), reasons, “Many industries much smaller than healthcare have dedicated SDOs, and I’m not entirely sure a single set of standards would even present any advantage with today’s technology.”  (SDO=Standards Development Organization.)  He asks “…why all of a sudden is there this pressure to choose GS1, and eschew our own SDO, which we control?”.

Why indeed.  I’ve grappled with questions similar to Ted’s for some time now.  I’m not sure I have the answers—especially answers that Ted and others might agree with—but I have some thoughts on the subject.

ARE GS1 OR HIBCC STANDARDS THE RIGHT “GAUGE”?

I think Mike is on the right track (pardon the pun) when he sees similarities between the current standards situation in the healthcare industry and the railroad industry just prior to the adoption of a single track gauge for the Transcontinental Railroad.  Sure, the industry has been able to make do with two different sets of standards, HIBCC and GS1, for quite a few years, but that does cause inefficiencies.  To remove as much cost as possible from healthcare we need to remove as many inefficiencies as possible, thus, wide adoption of a single family of identification standards is important.  In fact, I think adoption of a single family of identification standards in our industry will result in benefits well beyond simple cost reduction, much as the adoption of the single railroad gauge went far beyond it as well.

So which family of identification standards should the industry settle on, HIBCC or GS1?  I don’t know enough about HIBCC standards to provide a full set of pro’s and con’s, but I think perhaps I can cut to the chase by pointing out the following critical differences:

• GS1 standards are truly global, are HIBCC standards?
  Is there a HIBCC affiliate in China? Brazil? Slovenia?  I don’t think so.  GS1 has affiliates—boots on the ground—in over 100 countries.  GS1 standards are receiving increased attention by governments in many places.
• GS1 standards are cross-industry, HIBCC standards are unique to the healthcare industry
  Sure, GS1 is huge in the grocery supply chain, but it’s also huge in the general merchandise supply chain in which retail pharmacies and drug wholesalers participate in a big way.  I think that’s a good thing.
• GS1 standards are more widely adopted than HIBCC standards, even in the healthcare industry
  OK, I’ll grant you that HIBCC’s HIN is currently bigger than GS1’s GLN in the healthcare supply chain, but it’s just one of many location identifiers in use.  GS1’s GTIN is more widely used than HIBBC HIBC for product identification in the healthcare supply chain.  I don’t have an internet link for this bullet.  This one comes from personal observation.

With just these three bullet points I think the picture is pretty clear.  So clear, in fact, that I think, faced with these three points, even the railroadmen from 150 years ago would tell you that the GS1 family of standards are the better candidate for a U.S. standard than the HIBCC family.  In fact, the HIBCC family of standards comes off looking more like just one of the niche railroad gauges that faded away 150 years ago.

SO GS1 WINS?

Does all that mean that GS1 wins and deserves to be selected as the sole family of standards in the healthcare industry?  Maybe, but like many families, there are good relatives and there are bad relatives.  The GS1 location and product identification standards, GLN and GTIN, are not bad, although in my view, there exist unacknowledged but important differences between the allocation rules of GS1 GTINs and those of NDC’s.  I fear that there may be some gotcha’s when using GS1 GTIN’s to carry a regulated identifier, especially when there is no authority who can arbitrate and enforce conformance.  GDSN, EPCIS and even DPMS have problems that need work.  And we don’t know yet how GS1 will implement the Data Discovery Services standard whose development is just getting underway.  Perhaps these are the kinds of things that Ted was talking about when he wrote of the benefits of having “our own” dedicated SDO.

Many people have a problem with the high fees that GS1 charges, making it look as if they are a for-profit company (they are not-for-profit).  I’ve been one of those people in the past but, for the most part, I have come to terms with it and I now recognize that to get the benefits of a truly global family of standards, it’s going to cost some money.  I hope someone is monitoring exactly how the money is being spent, but I now expect that standards development, along with encouraging adoption, is going to have some significant costs associated with it.   The users of those standards should pay for it.  A fully volunteer organization cannot accomplish what GS1 is doing.

So here is where we are.

1. We need a single family of standards to maximize the efficiency of the healthcare industry;
2. From a high level, the family of standards from GS1 seems to have the inside track;
3. But GS1’s family of standards are not yet a perfect fit and some are currently insufficient for use in this industry;
4. The pharma side of the industry is facing a pedigree deadline in 2015 in California where it will be paramount that the industry has this decision well behind them.

Why the rush for GS1 standards?  At least on the pharma side, it’s because we’re behind schedule.

Earlier this year The Association for Healthcare Resource & Materials Management (AHRMM) and the Center for Innovation in Healthcare Logistics (CIHL) at the University of Arkansas published the results of a survey they conducted in 2008 titled “The State of Healthcare Logistics”. The survey polled 1381 healthcare supply chain professionals regarding their “perceptions of cost and quality efficiencies and improvement opportunities within their organization”. I’m always a little skeptical (alright, I’m a lot skeptical) of “perception surveys”, but since this one was focused on the specific supply chain that I’m a member of, I took some interest. This survey included a series of questions about the respondent’s perception of Data Standards, which really caught my eye.

In fact, I’ve been doing a little investigating myself into the competing standards that are related to supply chain master data. My career experience in this area has almost solely dealt with GS1 standards, but that may be because the healthcare part of my career has centered on the pharmaceutical distribution corner of the full healthcare supply chain. If it had been centered on the distribution of medical devices, I would have been much more familiar with HIBCC (Healthcare Industry Business Communications Council) supply chain data standards. I’ve been trying to figure out if the industry needs multiple competing data standards and, if not, which one is a better set: GS1 or HIBCC? And should I consider some other set of standards that I just don’t know about? Are there good reasons to continue the use of either or both sets of standards in our supply chain?

In this light, I turned my attention to the AHRMM/CIHL survey results, hoping to gain some valuable insight. I quickly got stuck on their very first survey question in the Data Standards section (on page 15 of their report):

A. Is your organization moving towards the adoption of a data standards system (such as GS1) in the next five years?

Now this is an amazingly bad survey question that wouldn’t even pass a “survey questions 101” class. It is a classic example of a leading question. One where the desired answer is provided directly in the question itself. But look at the choice of answers!

1. Yes – GS1
2. Yes – Other
3. No
4. Don’t Know

Wow. Clearly this survey is trying to lead the respondents to indicate support for only GS1 data standards, and it worked. Over 50% of the respondents chose answer “1”, over 30% chose answer “4”, and about 20% chose answer “3”. What about answer “2”, indicating support for “other” data standards systems? Only about 3%.

But the authors go further. Here is part of the analysis provided in the report for this survey question:

“The majority of those that indicate that they are moving towards a data standards system other than GS1 do not know which system their organization is moving towards.”

Maybe that’s because they didn’t tell the respondent which “other” systems are out there. I’m assuming that the authors were just a little sloppy and failed to include in the report the additional question(s) that provided them with this extra information.

I wonder what they would have found if they had asked the question this way:

B. Is your organization moving towards the adoption of a data standards system (such as HIBCC) in the next five years?

1. Yes – HIBCC
2. Yes – Other
3. No
4. Don’t Know

My bet is that the results would be nearly the same.

In general, perception surveys don’t deserve much weight. This one provides a perfect example of why, and this one question destroys any remaining credibility this survey could have had. For this reason, this survey contributed absolutely nothing to my own investigation into systems of standards and it answered none of my questions. That’s sad, because I’m sure there are many other people in the supply chain who are having the same thoughts right now, and we could use some solid, unbiased information about the pros and cons of each choice.

This report has inspired me to construct my own perception survey:

C. Which standards organization (such as GS1) is most likely to have directly or indirectly funded the survey that generated Question A.?

1. GS1
2. Other
3. No
4. Don’t Know

D. Which public university (such as the University of Arkansas) should be most embarrassed by the construction of Question A. and the conclusions drawn from it?

1. The University of Arkansas
2. Other
3. No
4. Don’t Know

For more of my essays related to HIBCC, click here.