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.

The U.S. Food and Drug Administration (FDA) created the concept of the National Drug Code (NDC) in 1969 to “…provide an identification system in computer language to permit automated processing of drug data by Government agencies, drug manufacturers and distributors, hospitals, and insurance companies” (from 34 FR 11157, July 2, 1969).  (I can’t find a copy online of the original Federal Register article from 1969 so I’m relying on a more recent article that references it.)   Those of us in the U.S. pharma supply chain make use of NDC’s every day, but very few of us know the history of their development, exactly how the numbers are composed and what they mean.  I’ll try to explain all of that and provide sources for further reading.

HISTORY OF THE NDC

The NDC was initially a voluntary identifier (see references at the end of this essay).  We all know how that would have turned out (for more on that thought, see my recent essay “Should Regulations Dictate Technology?“) so in 1972 the FDA made the NDC mandatory for all prescription and over-the-counter (OTC) drugs.  Manufacturers were required to obtain a “Labeler Code” from the FDA, construct their NDC’s using that code as the base and print the NDC number on drug packages.  Barcodes were not required by the FDA back then.

From the quote in the first paragraph above you can see that the FDA intended the NDC to be used among the full spectrum of users who needed to unambiguously refer to specific drugs.  I can’t imagine how inefficient it must have been to refer to a specific form, size and concentration of a particular drug in every step between manufacturer, patient and insurer before the advent of the NDC.  Even from the very start the FDA intended the NDC to help with automation using computers.  Computer automation leads to greater efficiencies and much greater data accuracy–just what was needed for the drug industry and supply chain to grow in the coming decades.

The FDA recognized in the early 1970′s the automation value of encoding the NDC into barcodes, but as I said, they didn’t require them.   However, barcodes were making a big splash in the grocery industry and soon after in the consumer products goods industry around that time because of the great gains experienced in checkout efficiency and inventory control.  The Uniform Grocery Code Council (UGCC) introduced the 12-digit Universal Product Code (UPC) identifier and barcode symbology in 1974 and it quickly became the standard for all products sold at checkout counters.  Chain stores of all kinds started putting maximum pressure on manufacturers to put a UPC barcode on every product they sold.

This led to an interesting collision of mandates.  The FDA had already mandated that OTC drugs be identified by their NDC.  The UGCC mandated that the “Company Prefix” portion of the Universal Product Code that was encoded in UPC barcodes be assigned by the UGCC.  Since OTC drugs were one of the products that were being sold by chain stores, pressure was put on the UGCC to find a way to accommodate the 10-digit NDC within the 12-digit UPC.

UGCC technical experts quickly came up with a way to do it.  They came up with the scheme of pre-pending the NDC with the digit ’3′ and then adding the standard UPC checksum at the end.  The UGCC had to commit to reserving all UPC’s with a ’3′ as the first digit for drug companies and they agreed to reserve the Company Prefixes for drug companies so that they matched the FDA’s Labeler Code.  OTC drug manufacturers now had a way to satisfy both mandates and many years later that approach continued to be used as manufacturers started to apply barcodes to non-OTC drug packages.

Around that time the UGCC became the Uniform Product Code Council (UPCC), then the Uniform Code Council (UCC) in 1984, and finally became GS1 U.S. in 2005.  All along the organization has been a privately held, non-profit, tax-exempt corporation.

While the printing of the human readable NDC on drug packages was mandatory the printing of a barcode on drugs was voluntary until only relatively recently.  The FDA published a final rule  in 2004 that mandated all drug packages have a linear barcode printed on them starting in 2006.  By 2004 roughly 90% of drug packages in the supply chain already had linear barcodes on them voluntarily.  It seems odd that it took the FDA so long to mandate such a valuable automation element when it seems like it could have mandated it much earlier with little justifiable complaint from the industry.  The final rule document contains a significant amount of discussion, explanation and documentation about the benefits of barcodes on drug packages, particularly around the benefits to patient safety.

THE ANATOMY OF THE NDC

The NDC is composed of three semi-fixed-length data fields:

• FDA Labeler Code
  This is a code that is assigned by the FDA to the manufacturer, packager (“labeler”) or repackager of the drug as part of an application process.
• Product Code
  This is a code that is selected by the owner of the FDA Labeler Code.  It represents the unique combination of the drug, the dosage form and strength that will be packaged by that owner.  While the code is assigned by the owner of the Labeler Code it must be registered with the FDA.
• Package Size
  This is a code that represents the package size or package grouping of the drug.

For a short time the NDC started out in 1969 as a 9-digit code.  Initially the Labeler Code was defined as 3 alphanumeric characters long–a fixed length–but was soon changed to 4 numeric digits bringing the full code to the full 10-digits we know today.  The product code was defined as a fixed 4 digits long and the package size took up the remaining 2 digits.  But Labeler Code assignment requests came it at an alarming rate and it apparently wasn’t slowing down as they started to approach 999 sequential code assignments.

A decision had to be made.  If they crossed the border and assigned Labeler Code 1000, the NDC would forever be limited to 4 digits with a maximum of 9,999 codes and they might run out someday.  They were already approaching 10% of that number.  But if they made the fields of the NDC semi-fixed length at either 4 or 5 digits, they could continue assigning codes until a theoretical maximum of 99,999 codes.

The FDA didn’t want to expand the NDC to 11 digits so they decided to remove one digit from either the Product Code or the Package Size fields.  Rather than picking one or the other they decided to leave that choice up to each owner of the new 5 digit Labeler Codes.  Those companies could choose to have only 3 digits for the Product Code and 2 for the Package Size (written as 5-3-2), or they could choose to have 4 digits for the Product Code and only one digit for the Package Size (written 5-4-1).  The decision is made by the owner and they must register their choice and stick with it for the life of the Labeler Code.

But there is a problem with this approach.  Given a 10-digit NDC that might have a 4-digit or a 5-digit Labeler Code there could be conflicts between the NDC’s of two different companies.  Two companies might end up generating the identical NDC for two different products.  To eliminate this potential problem they decided to never assign labeler codes 1000 through 9999 (actually there is no explicit rule published that the FDA is following this technical requirement but it appears that this is what they are doing for most new Labeler Codes).  This makes the actual maximum number of Labeler Codes available equal to 90,999…not a bad compromise.

This solution provides a well-defined rule that allows systems to easily figure out the length of the Labeler Code within a given 10-digit NDC number.  All NDCs assigned by companies who own a 4-digit Labeler Code will always have a zero in their leftmost position and all NDC’s assigned by companies who own a 5-digit Labeler Code always have a non-zero digit in their leftmost position.  But there is no easy way to figure out if the owner of a 5-digit Labeler Code is using the 5-3-2 form or the 5-4-1 form without looking it up in a database.

The Package Size field is an important field used to differentiate not only the various dosage form sizes of the packages that the manufacturer or repackager produces (i.e. 30-count, 60-count, 90-count), but also the casepack quantities of each of that same set of packages.  There are no standard values for the Package Size field so the values used for one manufacturer cannot be compared with those of another.  They are simply used to differentiate package sizes and groupings within a single product type causing considerable confusion to those who wish to make use of this field.

For example, Company A might choose to use the values ’30′, ’60′ and ’90′ to represent the Package Size codes for their 30, 60 and 90 count bottles of a given drug, and the values ’31′, 61′ and ’91′ to represent a single casepack quantity of 48 bottles for the 30 pill bottle, and 24 bottles for the 60 and 90 pill bottles.  Company B might have chosen the 5-4-1 form of the NDC so they are left with only a single digit to represent their Package Sizes and groupings.  They might choose values ’1′, ’2′, and ’3′ for their 30, 60 and 90 count bottles of a given drug, and the values ’6′, ’7′ and ’8′ to represent the single casepack quantity of 96 bottles of their 30-count bottle, 48 bottles of their 60-count bottle and 24 of their 90-count bottle.  Confused yet?

So what use is this Package Size field if there isn’t any standard?  It simply allows manufacturers and repackagers to create unique NDCs for each dosage form size and casepacks so that interested parties can use it to look up the other information in a database.  You can’t just look at an NDC and know exactly what it stands for unless you have some prior knowledge about the choices the manufacturer or repackager has made for that product.  A database lookup doesn’t care what values are chosen for each packaging level or grouping as long as they are each unique.

NCPDP STEPS IN TO REDUCE AMBIGUITY

The current design of the NDC results in a number of ambiguities that stem from the fact that the length of each of the three fields can be one of two values.  The National Council for Prescription Drug Programs (NCPDP) decided to fix the ambiguity to increase the accuracy of claims submission.  They saw that all you have to do to return to a fixed length set of fields is to add an eleventh digit.  The goal was to always end up with a 5-4-2 format for all NDC’s.  To all 4-digit labeler codes (4-4-2) they added a ’0′ on the left.  To any 3-digit Product Code fields (5-3-2) they added a ’0′ on the left.  To any 1 digit Package Size (5-4-1) they added a ’0′ on the left.  All of these resulted in a 5-4-2 format (11 total digits).

For their purposes I’m sure this works great.  But it introduces its own ambiguity when an 11-digit “pseudo-ndc” is offered where a 10-digit true NDC is needed.  Which zero is the extra zero?  You can’t always tell unless you know for a given NDC.  Incidentally, the FDA apparently doesn’t recognize the NCPDP 11-digit format so it is not a real NDC.  That’s why I’ve called it a “pseudo-ndc”.

UNIT DOSE/UNIT-OF-USE NDCs

There is one more thing I want to say about NDCs.  I think the FDA made a significant error in not defining the NDC in a way that requires all pharma manufacturers and repackagers to clearly identify which NDC is a unit dose or unit-of-use for each drug.  The NDC appears to have been conceived as a way for a manufacturer to assign a unique code for each type of package they make for a given drug.  Since most manufacturers currently do not produce packages that contain a single unit dose or unit-of-use there is theoretically no need for them to define an NDC for that level.  I am told that some manufacturers do define and register an NDC for this level even if they don’t package at that level, and the rest do not.

I imagine that this has caused serious heartburn for insurers and Pharmacy Benefit Managers (PBMs) who are probably given the NDC for the original manufacturer’s bottle that a prescription was filled from.  What does it mean for a pharmacist to claim that they filled a prescription with ’1′ of NDC 9999988882 (psuedo-ndc 99999888802 for claims submission) where that NDC describes a 30-count bottle?  Did the patient receive one 30-count bottle or did they receive a single pill that the pharmacist pulled from a 30-count bottle?  There must be some convention for limiting the ambiguity that this introduces.  Perhaps someone can leave a comment to explain what happens in this instance.

In my view all manufacturers and repackagers should always generate and register an NDC for a unit dose or unit-of-use.  Ideally you’d like to think that the Package Size values of either ’00′ or ’0′ would be reserved to indicate the unit dose or unit-of-use, but since it wasn’t defined that way you will probably have lots of drugs that assign those values to some multi-dose/-use package or even a casepack.  It would be too disruptive to force that kind of change on the industry now.

REFERENCES

Normally I provide links to all my references, but there are a couple of sources that I drew from for lots of this content and so I’d like to list them here:

• George Wright IV, Vice-president, PIPS / Product Identification & Processing Systems, Inc.
• “HDMA Guidelines for Bar Coding in the Pharmaceutical Products Supply Chain”, Healthcare Distribution Management Association (HDMA), 2005
• “History of the UPC Bar Code and The Uniform Code Council, Inc.“, by Rob Cummings, Cummings Design
• George Laurer, Inventor of the UPC

Please submit a comment if you have additional information, clarifications or corrections.

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

For the first time in over two years the topic of pedigree appears on the agenda of the California Board of Pharmacy for their upcoming meeting on September 7.  Earlier this year in a presentation at the FDA Track & Trace Workshop Board Executive Office Virginia Herald mentioned that the Board would take up the topics of inference, drop shipments, decommissioning and linkage between shipping orders and invoices at a future meeting in 2011.  It’s hard to tell if those will be the actual topics discussed in next week’s meeting because they aren’t called out explicitly.  Here is the item as it actually appears on the agenda:

Discussion on the Implementation of California’s Electronic Pedigree Requirements for Prescription Drugs
a. Overview of the Law
b. Comments of the FDA
c. Presentations and Questions from the Pharmaceutical Supply Chain
d. General Discussion

Perhaps the only new thing about this discussion will center around “b. Comments from the FDA” and the other topics might be covered more directly at a later meeting.  We’ll see.  Keep in mind that the Board is made up of members today who were not on the Board when they last dealt with the pedigree regulation.  The current members will probably need a good introduction to the law and the current state of the standards and the industry before they tackle the intricacies of things like inference, drop shipments and decommissioning.

Those are topics that the Board needs to provide some guidance on, but there are some other very important questions that need to be answered before companies are likely to fully invest in pedigree solutions.  Here I’m referring to both solution providers and companies within the supply chain.

Back in 2007 a subset of the Board analyzed the GS1 Drug Pedigree Messaging Standard (DPMS) to see if companies might be able to use it to comply with the law.  Generally the Board members present at that meeting felt that the standard appeared to include features that the industry could use to comply with the law.  Of course, use of DPMS does not automatically guarantee compliance, but the takeaway by those present (myself included) was that DPMS could be used to comply with the law if you applied it appropriately as specified in the law.

Since that time, nothing has really changed with DPMS, but there have been efforts within GS1 Healthcare and GS1 US Healthcare to come up with an alternative way to comply with the law using GS1’s Electronic Product Code Information Services (EPCIS) standard.  What is needed is for the Board to analyze those approaches in a similar way to see if they too might be used by supply chain participants to comply with the law.  Without that kind of analysis by the Board it would be risky for companies to invest in solutions that are based solely on EPCIS.

A FEW QUESTIONS

There are a number of novel ideas for producing a wide-spread pedigree system based on the EPCIS standard, but which ones would allow end-users to comply?  It would help to know the answers to the following questions.

Consider a hypothetical transaction where a hospital pharmacy is in desperate need of some cancer treatment drug that is on the FDA shortage list.  In a stroke of “good luck” the pharmacy finally finds a source through a fax they recently received from a newly licensed distributor in their area.  The drug is delivered by a courier who hands the pharmacy manager a USB thumb drive that contains a pedigree file that contains the  following information in a single EPCIS Shipping event:

WHO:  a 13-digit number
WHAT:  a 14-digit number representing the Serialized Global Trade Item Number (SGTIN) of the case that was delivered
WHEN:  a timestamp representing the date and time of the shipment
WHY:  “shipping”
SHIP TO:  a different 13-digit number recognizable as the hospital’s GS1 Global Location Number (GLN)
SOURCE EPCIS:  an internet address (URL)
CERTIFICATION:  a digital signature that spans the above information

Some of the questions are:

1. Has the seller fulfilled their requirement to provide a pedigree to the buyer?
2. Has the hospital fulfilled their requirement to receive a pedigree from the seller?
3. Has the seller provided the necessary certifications?
4. What if the file were transmitted to the hospital through a more conventional EPCIS-to-EPCIS connection?
5. What if the buyer is able to use the case SGTIN contained in the “WHAT” field and the URL contained in the “SOURCE EPCIS” field to find and collect the Aggregation event that includes the SGTIN’s of all of the units inside the case and then collects the Supply Chain Master Data (SCMD) that describes the drug for those units through some separate mechanism like GS1’s Global Data Synchronization Network (GDSN), and they are also able to find and collect the Commission events of the units that contain the lots and expiration dates of the units in the case?
6. What if the buyer is able to use the contents of the “WHO” field of every one of the events obtained in question 5 above to find and collect the SCMD that describes the seller and all previous owners through another separate mechanism like GS1 US’s GLN Registry for Healthcare?
7. What if, instead of the steps in questions 5 and 6 the buyer was able to supply the entire shipping event received from the buyer to a certified third-party service that performed all of the data collection described in questions 5 and 6 and simply returned a list of the unit level SGTIN’s contained in the case, each with a pass/fail flag to indicate the status of their pedigrees, but the buyer routinely never actually receives or sees all of the information unless a separate request is made for the entire supply chain history for those units?

Lots of companies seem to want to use EPCIS to comply with pedigree regulations but there are so many ways the standard could be applied it is hard to know which way to go unless they know that the results will allow them to comply.  And they need to know soon to allow time for standards organizations to draw up standards and/or guidelines and solution providers to produce applications in time for supply chain companies to evaluate, buy, deploy and test them.   Now that the California Board of Pharmacy is about to begin to discuss their pedigree regulation again, maybe now is the time.

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.

In this essay, I’m not going to discuss the attributes of a track & trace system from a regulator’s point of view.  I’m not going to discuss input into the FDA’s Track & Trace workshop that occurs this week and I’m not going to speculate on the outcome of that meeting.  Instead, I’m going to talk about the attributes of a track & trace application from the viewpoint of any global pharma manufacturer who is facing the regulatory mandates for serialization and traceability in a growing list of countries around the world, and from the viewpoint of any solution provider who is thinking about what they need to include in their solution offering so that those global pharma companies find it attractive enough to buy.  

To those kinds of companies, the potential for new non-binding guidance from the U.S. is important, but perhaps less so than an increasing number of binding regulations from around the world.  Whatever the FDA—and especially the U.S. Congress—may do in the future will be important when selecting a track & trace solution, but the U.S. is only one of the countries in the world and pharma companies that do business in those other countries do not have time to wait for the U.S. to figure out their approach before making investments. 

The goal is to make investments today that will be flexible enough to accommodate existing laws around the globe and whatever ultimately might or might not happen in the U.S., the E.U. and elsewhere.  To accomplish that, “flexibility” is the key word and the key attribute.  The application you invest in should not be only targeted at a single regulation but should be designed to provide building-blocks of functionality which can be applied differently to the same products that will be shipped into many different regulatory environments around the world. 

Companies looking to buy a solution should look for a provider that has already made their own investments in understanding the specific regulations around the world.  You need a partner to help you understand and meet the specific requirements in Turkey, Brazil, Italy, India, China, South Korea and others that might pop up in the future.  Look for a solution provider who knows the existing global regulations and also knows exactly how to apply their solution in a way that will meet each one. 

THE ATTRIBUTES 

Here is a list of attributes to look for in a global track and trace solution. 

Interoperability.  In a phrase, “Standards-Based”.  Reject all proprietary solutions or you will find that your solution does not work with those selected by your trading partners.  It’s surprising how often I receive an email from a solution provider who thinks the world will be so much better off once their proprietary solution is deployed by everyone in the world.  In fact, no approach to track and trace will work if it is only supplied by a single company.  Interoperability demands a standards-based approach so that multiple companies can offer solutions that are fully compatible with each other.  That way pharma company A can invest in the solution from solution provider A’, and pharma company B can invest in the solution from solution provider B’, and wholesaler C can invest in the solution from solution provider C’, and so on, and they all work together without any special patching.  That’s interoperability. 

Today, the safest bet is to deploy solutions that are based on GS1 standards.  There are two major reasons for that.  First, several countries, notably Brazil, India and South Korea, have apparently explicitly named GS1 identification standards in their regulations or in their guidance.  (Be careful.  GS1 has a lot of standards.  This doesn’t mean that these countries require you to use every single standard that GS1 publishes so study the regulations carefully to learn exactly which GS1 standards are actually mandated.)  

Second, there is a lot of pharma industry activity in GS1’s end-user organizations including GS1 Healthcare (global) and GS1 US Healthcare.  This activity offers an indispensible source of adoption examples and experience.  No matter what, it’s dangerous jumping onto the cutting edge when you are forced to adopt new technology while regulations are still evolving, but at least it feels less dangerous when you are in a crowd of other companies who are forced to do the same thing.  

Don’t be lulled into thinking that GS1 or GS1 US knows what they are doing either.  Be prepared to interpret the regulations for yourself, but expect to deploy a solution that makes use of some GS1 standards.  Just because GS1 identification standards are usable today and are the most likely candidates for pharmaceuticals that are packaged for sale in certain markets doesn’t mean necessarily that GS1’s data exchange standards like DPMS or EPCIS will apply to those same markets.  GS1 isn’t done developing standards for pharmaceutical track and trace so we can’t yet tell which of their standards provide the right mix of interoperability and compliance.  That makes it tough to figure out today what the right choice is and that may lead to less efficiency than companies would like.  All the more reason to select a solution provider who is willing and able to respond to changes in regulations, and to evolving standards as well. 

Serial Number Management.  This feature of a track & trace application doesn’t need to be standardized across all industry deployments, although it must work with both standard and country-specific identifiers.  In fact, this is going to be one of the key differentiating features of the products that you will need to select between.  Serial number management is a set of functionality that will allow you to securely and accurately control and keep track of the serial numbers that you apply to your pharmaceutical products.  Again, flexibility will be crucial.  You need a single, centralized (within the corporation) place where serial numbers of all types will be allocated and then distributed to the remote facilities where the actual commissioning (association of a serial number to a physical thing) occurs.  In GS1 parlance, this includes SGTIN’s (Serialized Global Trade Item Numbers), SSCC’s (Serial Shipping Container Codes), GIAI’s (Global Individual Asset Identifiers) and GRAI’s (Global Returnable Asset Identifiers). All of these standard identifiers need to be managed by the proprietary serial number management module of your track and trace solution. 

This management must also work well for regions of the world where the local government defines the serial numbers and provides them to you, either in data form (as appears to be the case in China) or as pre-printed stickers (as appears to be the case in Italy and Brazil).  Even when the government gives you these numbers you still need to keep track of them.  Because these numbers may not always conform to GS1 standards, your solution will need to be able to deal with non-standard identifiers and serial numbers as well.  Exactly how that is done ought to be a big differentiating factor in your selection process. 

Certifications.  A certification is a way to attach individual or corporate assertions of truthfulness to the track and trace data in order to fulfill specific requirements to do so.  It’s a feature of some regulations that is intended to make it easier to prosecute criminals—one of the more important reasons for the existence of track & trace regulations.  Not all country regulations require you to include a certification within your track and trace data but your track & trace solution needs to be able to include them if you expect to use it in California after January 1, 2015.  That’s when their pedigree regulation goes into effect for the first 50% of each manufacturer’s product.  This ought to be another big differentiating factor in your solution selection process if your products end up there.  Any solution provider who has this figured out is well on the way to deserving your business. 

Pedigree Reporting.  This is a catchall term I am using here to cover any and all reporting requirements that each track & trace regulation includes.  If a regulation specifies it, your solution needs to supply it.  The problem here is that many of the global requirements are not well defined and you could easily find that the regulatory agency that oversees the regulation comes up with the need for a particular report that is not clearly spelled out in the regulation.  You need a technology partner who is going to monitor these agencies around the world on behalf of their customers so that they will be the first to know about the new reporting requirement and they will already be working on its implementation when you first become aware of its need.  

RFID and Barcode Data Capture.  Finally, the track & trace solution you select should be capable of easily handling serialization data capture from both RFID and Barcode data carriers.  Even if you don’t plan to make use of one or the other today, you may find that certain jurisdictions mandate one or the other.  For example, I understand that South Korea has, or will, mandate the use of RFID on pharmaceuticals sold there.  If I understand that right, and if you package drugs for sale in that market, then you may be faced with applying RFID tags to those units. 

These attributes may eliminate some solution providers from consideration.  Watch out for any solution provider that doesn’t have one or more people dedicated to monitoring global regulations.  If they are only in business to sell you a solution to today’s static “regulatory problem” then they aren’t worth your time.  That’s because we are in a very dynamic regulatory situation today when it comes to global pharmaceutical track and trace regulations.  You should be looking for a technology partner who has a long-term interest in meeting the shifting pharma track & trace demands of all the world’s governments.  That’s a tall order, and one that demands flexibility and constant attention.

I’ve been involved in a number of conversations lately that included differing opinions about what will be necessary to “certify” a drug pedigree in California after their pedigree law goes into effect (2015-2017, depending on your role in the supply chain).  It’s a contentious issue, especially for those who wish that a distributed pedigree model would comply. 

The California Law is fairly clear that the pedigree must contain, “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.”  And that, among a list of other things, it must include “…the name and address of each person certifying delivery or receipt of the dangerous drug.”

In the California language, a “dangerous drug” is any drug that a patient can only obtain from a licensed pharmacist by presenting a valid prescription, also known as “prescription drugs”.

SO WHAT IS A “CERTIFICATION” AND HOW CAN I COMPLY WITH THE REQUIREMENT?

In January 2008, the California Board of Pharmacy published a draft document they called, “QUESTIONS AND ANSWERS RELATING TO THE CALIFORNIA ELECTRONIC PRESCRIPTION DRUG PEDIGREE LAW(S)”.  This document contains some “frequently asked” questions and their answers about the Board’s interpretation of the pedigree law.  It’s an important document for anyone wanting to get some insight into the thinking of the California Board of Pharmacy and how they might enforce the law.  In the document, they touch on issues surrounding this certification language in eleven of the seventy-eight answers (Q10, Q21, Q22, Q23, Q25, Q58, Q64, Q67, Q68, Q72 and Q73), providing a glimpse into their thinking.

In the response to Q21, “What sort of certification of the contents of the pedigree does the law require?”, the board answered, in part, “The board anticipates that the required certifications, of delivery or receipt, and of the truth and accuracy of the pedigree, will be achieved by use of or in combination with digital signatures.”  (See the document for the full answers.) 

In the response to Q68, “Does the pedigree law mandate the type(s) of technology that must be employed?”, the board answered, in part, “The board has not yet provided specific directions or technological requirements regarding how to ensure interoperability, authenticity, integrity and non-repudiation of electronic pedigrees. It is the responsibility of the involved parties to meet these requirements.”

And, “The board expects that the trading partners will be sufficiently motivated by their shared interest with the board in security of the drug supply and protection of the public, as well as by their own responsibilities under the law to certify accurate delivery or receipt of drug products and the truth and accuracy of the pedigree data exchanged, that mandates on technology to ensure drug or data security, accuracy, integrity, interoperability and non-repudiation may not prove necessary. The board expects that industry best practices will develop optimal technology (or other) standards to control collection, transmission, and sharing of data independent of legal mandates. If this is not the case, the board reserves to itself the authority to step in as necessary to secure cooperation.”

The law itself does not specify any pedigree implementation technology.  As I understand it, the Board did not intend for the Q&A document to mandate the use of any specific pedigree implementation technology either, although one could argue that they may have crossed that line with the statement:  “The board anticipates that the required certifications, of delivery or receipt, and of the truth and accuracy of the pedigree, will be achieved by use of or in combination with digital signatures.”  But I’m also told that’s why they will always keep the document in “draft” form.  In draft form, they can’t be held to it and they can readily acknowledge that there may be “errors” in the document.  (Hey, it’s just a draft!) 

Only a court of law can really interpret the meaning of the language found in the law itself.  That’s why companies facing the law should rely on their legal counsel to help them identify their options in responding to the law at a level of risk that is acceptable to their business.  My perception is that, so far, few companies have involved their legal departments in helping them assess the risks.

No one I know disagrees that digital signatures can be used to comply with the pedigree certification requirement in California, but some people feel that they are too complex and their use for that purpose is too “heavy”, requiring too much data storage for each signature.  Perhaps the biggest complaint against digital signatures for pedigree certifications in general is that they must be generated with digital certificates that are assigned to, or “owned” by, an individual rather than the corporation. 

The California law says that the certification must be made by a “…responsible party…”—presumably someone who has the authority to bind the corporation to an oath “…that the information contained in the pedigree is true and accurate”.  Depending on your interpretation of that language, that might eliminate all but the topmost individual in a modern pharmaceutical wholesaler distribution center in the U.S., and that person isn’t routinely present in the warehouse to observe these operations and then make those certifications.  In some organizations, few people below a certain rank have that kind of authority, “…under penalty of perjury…”.

The California Q&A document seems to say that the Board of Pharmacy expects digital signatures to be used—at least in part—for the certifications (…by use of or in combination with…”), but I’ve heard recently that they, perhaps, didn’t mean to go that far, and that they currently may be open to reasonable proposals for alternate approaches that are more light-weight, but which retain an acceptable level of information security and non-repudiation.  (Remember, it’s just a draft!)  Let’s just call it an unsubstantiated rumor right now.  I’ve asked for confirmation or clarification but have not yet received a response.  This rumor apparently came through Virginia Herold’s (Executive Officer of the California Board of Pharmacy) presentation at GS1 US’s recent 2015 Readiness Program Workshop in San Francisco.  I was not present but I spoke with a number of people who were there.

But “non-repudiation” and “light-weight” seem to be two contradictory terms.  Digital signature technology was specifically designed to have the property of non-repudiation, but I have to assume that the designers were not intentionally trying to create something that was “heavy”.  (For more on the history of digital signatures and the law, see these excellent resources.)  Can someone tell us about some method to secure pedigree information using a “light-weight” approach without losing the property of non-repudiation?  That’s what would be needed if the Board and supply chain companies are to be mutually satisfied.

WHY IS ‘NON-REPUDIATION’ SO IMPORTANT?

Why is “non-repudiation” so important to the Board?  My assumption is that they believe that an oath…I mean a “certification”…would be meaningless unless they could make it “stick” to a given individual, and, because that person would be a “…responsible party…”, therefore to the corporation.  That is, make it stick in court.  Let me demonstrate.

Here is a certification that does not have the property of “non-repudiation”:

“I, President Barack Obama, certify that I will pay Dirk Rodgers of RxTrace.com $1,000,000 on January 1, 2011”.

Do you think I will collect?  Do you think it would stand up in court?  No and No.  Why?  Because, no matter how much I claim that President Obama typed that “certification”, there is no way I could possibly prove that he did.  No one would believe me because President Obama could simply refute that he typed it and it would be his word against mine.  You can tell just by looking at it.  He could easily “repudiate” that he ever made the “certification”, so no court would even bother trying it. 

Even if President Obama actually had typed the “certified” statement just like it appears above, it would still be worthless for the same reason.

Even if I wrapped the statement with a forged digital signature (one that used a private key that I made up), it still wouldn’t stick because I could not demonstrate that President Obama generated the digital signature.  My forgery would be just as obvious—or even more so—than if there were no digital signature at all.

But if President Obama had wrapped the certification above with a digital signature generated using his private key, he would not be able to repudiate it (it would be “non-repudiable”) and I should be able to use it as evidence against him in court if he failed to pay me the $1,000,000 by the deadline.

“Certification” of a drug pedigree using any technique that doesn’t include the property of non-repudiation will be just as worthless as the fake “certification” above.  It might look good, but it would have no value.  And why should the industry be forced to deploy a costly pedigree system that results in worthless documentation–documentation that is no better than my…ahem, I mean, President Obama’s… worthless fake “certification” above?  How would the public be protected by something so worthless?

WHERE TO WE GO FROM HERE?

So where do we go from here?  Well, the GS1 Drug Pedigree Messaging Standard (DPMS) was designed to comply with all existing pedigree laws in the U.S., which means that it uses digital signatures for all necessary certifications.  Digital signatures are known to comply, giving DPMS users confidence that they are covered regarding any certification requirements. 

And just for the record, compliant “certifications” is just one of the “complex features” that GS1 US (or GS1 Global for that matter) has not yet figured out how to do in a “distributed pedigree” approach, or even in an alternate non-distributed approach.  Someone could probably create an alternative, non-distributed, approach to pedigree that is based on the GS1 Electronic Product Code Information Services (EPCIS) standard which used digital signatures for certifications, but that would result in something that is even more “heavy-weight” and unwieldy than DPMS, so no one is seriously pitching an approach like that.

So if you have any ideas for producing an electronic certification that has the property of non-repudiation, but requires less overhead than digital signatures, let me know.  I know a group of folks who are looking for exactly that.  But, while we wait for that, luckily, the industry already has DPMS for certifying pedigrees compliantly.

GS1 US is dedicated to expanding the adoption of GS1 Global’s standards for supply chain interaction in the U.S. market.  Almost every country in the world has a GS1 “Member Organization” (M.O.) that is dedicated to the same thing within their borders.  With the local M.O.’s primary focus on driving adoption, their most valuable tool is that country’s government.  If they can get the government to reference GS1 standards in their laws, their work is much easier. 

This isn’t unique to GS1, or course.  All standards organizations know this and they all have various approaches to getting the attention of each country’s government.  There is nothing wrong with this.  In fact, it makes perfect sense since, unlike standards organizations themselves, countries always have very large enforcement wings.

But what happens when those governments are too big to sway easily?  What if it costs too much and takes too long to get them to see the light?  This is when a standards adoption organization needs to get creative.  In my opinion, that’s what has led GS1 Healthcare US to create the “2015 Readiness Program”.  It was out of frustration with the California State Government and with the U.S. Food and Drug Administration (FDA) and their, so far, unwillingness to create laws and regulations that mandate the use of GS1 standards.  Let me explain.

THE GS1 HEALTHCARE US 2015 READINESS PROGRAM

The GS1 Healthcare US 2015 Readiness Program is a voluntary program that is open to any company that is a member of the U.S. pharmaceutical supply chain.  You don’t have to be a GS1 US subscriber to participate in most of the program activities or to benefit from it.  The program was conceived by GS1 U.S. about a year ago and it was kicked off in January of 2010.  The program includes a series of weekly teleconferences where representatives from the member companies collaborate to document the many business processes necessary to package, distribute and dispense pharmaceuticals within the U.S. supply chain, including the many exceptions that can happen along the way.  The group then figures out how to apply GS1 Electronic Product Code Information Services (EPCIS) standard in a way that GS1 Healthcare US believes would make the whole process more efficient and would hopefully increase the safety and security of the supply chain. 

That is, it would do these things IF every company that participates in the U.S. pharmaceutical supply chain were to adopt the EPCIS standard in a uniform way by purchasing and deploying products based on that standard.  It’s a big “IF”.

But here’s the best part about the program.  As the idealized supply chain model is being developed, GS1 Healthcare US has used a third-party simulation tool to actually simulate the EPCIS data exchange that would occur in it.  Participants are allowed to take home a copy of the simulation runtime environment and they can actually make some configuration changes to the model to help them study what might happen in that world under their own special circumstances.  It’s pretty powerful stuff.

GS1 Healthcare US is offering two 1 ½ day workshops that are open to anyone wishing to learn about the program, learn how to use the simulation and get a copy of it for their own use.  These workshops are:

October 12-13, 2010 • Hotel Kabuki • San Francisco, CA

November 10-11, 2010 • Gaylord National Resort & Convention Center • National Harbor, MD
(Co-located with HDMA Track-and-Trace Technology Seminar, my favorite serialization and ePedigree event)

You can find out more about these GS1 Healthcare US events and register by clicking here.

I’m pretty excited about it and I encourage anyone who is interested to participate in the group that is continuing the development of the simulation and/or these workshops.  I’m pretty confident that GS1’s EPCIS will be used by many in the U.S. supply chain and this workshop is a great way to really understand what it can do when it is applied in a specific supply chain context.  In fact, members of other supply chains might even want to take note of this excellent piece of work and consider asking GS1 US to develop one for your supply chain.

SO WHAT’S THE PROBLEM?

The problem is, I think GS1 US is crossing the line between just advocating adoption and inducing it through mis-characterization.  Let’s start with the name itself:  “2015 Readiness Program”.  Ready for what?  What happens in 2015?  Oh, that’s the year that the first of multiple requirements of the California Pedigree Law goes into effect.  But no one has yet figured out exactly how to apply EPCIS-only to comply with that law.  In fact, even GS1 US will admit that they are not saying that use of EPCIS would make you compliant with that, or any other law, but you have to press them to hear that.

So what would you be “ready” for?  Perhaps you would be ready to deal with the serialization component of the California law?  Now that I would agree with.  Serialization is a big part of the California law, and it’s arguably the most complex and expensive component.  So, yeah, that must be it.  To say nothing of compliance with the law, you could at least be “ready” for part of the pedigree law by 2015 if you made use of EPCIS to help you deal with serial numbers on drug packages and shipping containers.

But the way the program is constructed, and the solution is implemented for simulation, it results in a distributed pedigree system—one where you have to query all the previous owners of a drug to collect the various components necessary to assemble your pedigree.  The implication is that you would only need to do that whenever a California State inspector shows up at your door and asks to see the pedigree for “this bottle”.  The GS1 Healthcare US program doesn’t try to interpret the law to make sure the proposed solution would comply with it.  That’s up to the end users. 

The introductory paragraph of the GS1 Healthcare US “2015 Readiness Program Guide” starts this way: 

“The 2015 Readiness Program was established by GS1 Healthcare US to help members of the U.S. pharmaceutical supply chain prepare for state drug pedigree requirements beginning in 2015 and learn how to leverage the same data stream used for regulatory compliance to realize additional business benefits.”

That implies that I should expect to be ready to comply with state drug pedigree laws if I participate, but so far, that won’t happen.

The ruse will be carried one step farther because GS1 Healthcare US has included speakers from the California Board of Pharmacy and the FDA in their workshops, giving the appearance of full support and an acknowledgement of compliance.  Virginia Herold, Executive Officer of the California Board of Pharmacy will be a guest speaker at the California workshop and Connie T. Jung, RPH, senior advisor for pharmacy affairs of the FDA will speak at the Maryland workshop. 

ASK THESE QUESTIONS

Those of you who will attend these workshops should ask these questions:

• Ask these guest speakers if the agency they work for would accept a distributed pedigree as compliant with their pedigree law 
• Ask GS1 Healthcare US how the system being simulated will comply with the California requirement that the pedigree you receive from your supplier, and the pedigree you provide to your customer, must include all prior supply chain ownership history, including all certifications
• Will California accept that approach? 
• Ask GS1 how you would include a certification that the necessary collection of events are true and correct
• Is that approach acceptable to California? 
• While you’re at it, ask your legal department if they will allow you to buy drugs from a supplier who would not typically provide you with the entire pedigree as defined by California once the law goes into effect
• Will your own company accept the risk that the full pedigree data might not be available from the previous owners at the time that inspector shows up?

GS1 will tell you that these things have not yet been worked out.  I say that they haven’t been worked out because GS1’s approach to pedigree using only EPCIS won’t work very well once you add the necessary steps to make it fully compliant.  They are simulating the popular track and trace part of the law, but not the unpopular pedigree compliance parts.  A simulation of an EPCIS pedigree system that included features necessary to fully comply with California wouldn’t be very compelling or generate as much interest as one without those “complex” features.

MY VIEW OF THE SITUATION

Serialization systems based on the GS1 EPCIS standard will very likely be valuable for pharmaceutical manufacturers who must keep track of all of the serial numbers they apply to their products—pedigree law or not.  It will probably be valuable for pharmaceutical distributors to keep track of which drug packages were received and shipped and when using EPCIS.  But there is no certainty that systems based on EPCIS will be justifiable for use in systems aimed at pharmacies. 

The pedigree system that would result from EPCIS event exchange would require so many undefined contortions to get it to comply with California’s existing law that the industry is unlikely to accept it, especially when all you really need to do to make those systems compliant is to simply add the use of the GS1 Drug Pedigree Messaging Standard (DPMS).  DPMS would give you the ability to comply with the law and EPCIS would give you the non-regulatory benefits that GS1 is simulating. 

Should you attend the GS1 Healthcare US 2015 Readiness Program Workshops?  Yes.  Should you expect to be ready for the California Pedigree Law by 2015 as a result?  No.  At least not yet.

In my recent essay, “RFID is DEAD…at Unit-level in Pharma”, I used relative cost estimates to theorize that Radio Frequency IDentification (RFID) will not be the predominant carrier of serial numbers applied to drug packages for compliance with U.S. pedigree laws.  My theory is that there will actually be a mix of RFID and 2D barcodes, and that barcodes will be the predominant carrier technology.  As you might expect, that was a little controversial with the RFID industry (See RFID Journal’s blog post in response to my essay).  Hey, it’s just a theory.  I too, wish everything would be RFID, and for all of the reasons cited by RFID Journal.  It’s just that I don’t believe it’s going to turn out that way and that’s based on the logic I laid out in my essay.  (Also see FiercePharma Manufacturing’s more neutral post in response to my essay.) 

BARCODES WILL PREDOMINATE.  LET’S MOVE ON… 

In a mixed-but-predominantly-barcode-serialized U.S. pharmaceutical supply chain, companies will not be able to tell which unit serial numbers are inside of each sealed case at receiving or at shipping.  Because barcodes are a “line-of-sight” technology, the only way to tell with absolute certainty what the sealed-up unit serial numbers are will be to cut the tape seal, open the case, expose the barcodes, scan each unit and tape the case closed again. 

It is a ridiculous notion to believe that this should happen at each receiving and shipping point because it would measurably elevate the risk of error introduction, damage and theft.  It would even cause greater suspicion of tampering by downstream trading partners who receive cases that have obviously been cut open and re-sealed after the manufacturer originally sealed them.  But most significantly, it cannot happen because it is super-inefficient (read:  unacceptably costly).

Notice here that if the units had been serialized with RFID tags it would not be necessary to open the case to read the unit serial number so each recipient of the case could read the contents without opening it.  Unlike barcodes, RFID does not require “line-of-sight”.  But because barcodes do, a recipient can never be sure what is hidden from sight inside a case without opening it up.

This is a well-known dilemma in the industry groups that I participate in.  The California pedigree law requires recipients of drugs to certify, under some stiff penalty, that they received specific drug units based on the serial numbers.  That’s how a pedigree works, but to be able to really certify that you have received a given set of unit serial numbers that only use barcodes, you would have to open, scan the units and reseal every case.  But if this can’t happen without a huge increase in costs, the only other way to do it is to simply trust what your upstream trading partner told you was in each case.  After all, the same pedigree law applies to them.  They are required, under the same stiff penalty, to give you a pedigree with exactly the serial numbers that they shipped to you so you should be able to trust them, right?

As long as the manufacturer puts a serial number on each case, whether RFID or barcode, and they read each of the unit serial numbers, whether RFID or barcode, as they are loading them into the cases, and if they accurately associate the case serial number with the unit serial numbers contained inside,  they would build a containment hierarchy for each case.  This is perfect for an Electronic Product Code Information Services (EPCIS) aggregation event, or a Drug Pedigree Messaging Standard (DPMS) envelope.  Both of these XML documents are designed to hold the kind of serialized containment hierarchy that I just described.

Armed with the containment hierarchy documented in this way, one could infer the unit serial numbers contained inside of a case by using the case serial number as a lookup key.  This is known as “inference” in the pharmaceutical supply chain. 

Inference can be performed at any level that the containment hierarchy allows.  If the containment hierarchy includes unit-to-bundle, bundle-to-case, case-to-pallet, pallet-to-shipping-container aggregations, then given a shipping container serial number and using inference, one could determine (infer) all of the unit serial numbers that are present inside of it without opening and without scanning(barcode or RFID). 

GS1 U.S. ON INFERENCE

The topic of inference in the drug supply chain has been getting a lot of attention in the Traceability Adoption work group of GS1 Healthcare U.S..  That group just published their paper, “The Practice of Inference in the U.S. Pharmaceutical Supply Chain Pedigree Regulatory Environment” which provides a good definition and background on the concept.  My purpose is not to reproduce the contents of the GS1 paper but, just to make sure you know what we’re talking about here I’ll give you my own definition of inference. 

Inference is an approach to identifying the contents of a shipping container without actually opening it to confirm exactly what it contains.  The types of “shipping containers” most often considered for the application of inference are cases packed by manufacturers and totes packed by wholesalers.  Being “an approach…”, the use of inference by any given company within any given business process (normally shipping and receiving), is optional and would be a conscious decision. 

When units are serialized with barcodes, if you choose not to use inference then you simply must open every container and confirm the contents by viewing and/or reading them.  Use of RFID serialization on items inside the container could be used to avoid the use of inference and still not open the container, but that assumes that you will always read 100% of the tags.  As soon as you get anything less than 100% you will have to decide whether you want to open the container to confirm the presence of those units you didn’t read, or use inference to infer that they are present. 

There is an important distinction between the use of inference with serialized and non-serialized items.  Today, very few pharmaceuticals have serial numbers applied (either barcode or RFID) at the item level.  When trading partners ship and receive a full casepack of drugs they normally never open it just to confirm that it contains exactly what the case label and the ASN says.  They infer that the case label is accurate, including NDC and quantity.  This type of inference is standard operating procedure across the entire supply chain—and has been from the beginning of time.  Use of inference specifically for serialized units is the focus of the current brainstorming activity.  This type of inference allows one to infer a given container contains the NDC and quantity, and the exact serial numbers that are specified in an ASN or pedigree. 

THE NEED FOR INFERENCE 

You can’t really understand inference unless you understand exactly why it might be needed.  The need is the result of the combination of three important things that I have previously written about: 

1. The California Pedigree Law (effective in 2015-2017) will require shippers and receivers to certify, under penalty of fines and potentially prison, that the exact item serial numbers inside of the shipping containers match the pedigree;
2. The modern U.S. pharmaceutical supply chain moves massive quantities of drugs at a high level of efficiency on a daily, overnight delivery cycle;
3. Due to the continuing relative high cost of item-level RFID, most Pharma manufacturers appear to be planning to use 2D barcodes to serialize their items.

The California Pedigree Law has a very noble purpose—to protect the public from crimes perpetrated against the pharmaceutical supply chain and ultimately against patients.  I don’t question that purpose.  I know the purpose of the pedigree law is not to destroy the efficiency of the current supply chain, but without the use of inference, it will.

When we reach the point where many pallets-worth of serialized/pedigreed products are moving through the supply chain (unlike today where it’s just a few SKU’s and the shipment quantities are small), trading partners will be forced to maximize the use of inference whenever they can to avoid having to open every case.

THE PROBLEMS WITH INFERENCE

But there are problems with the use of inference.  First, no pedigree law automatically allows its use.  Supply chain members who plan to use inference may find that law enforcement officers will not accept the excuse that they were using inference whenever the actual serial numbers in a shipping container do not match the pedigree.

Though rare, mistakes in casepacking, shipping and receiving occasionally happen today.  Even at the low occurrence frequency of these errors, the vast majority, if not all, of them are unrelated to the crimes that are targeted by the California Pedigree Law.  They are just unintended mistakes.  Today, the primary driver for trading partners to correct these errors is financial.  Once the law goes into effect, mistakes like these will open each occurrence to wider scrutiny and potentially result in a fine or worse. 

Second, the decision by a member of the supply chain to use inference must be based on their trust that the company who packed the container has very reliable case/tote packing and data collection processes.  Think about what will happen under the California pedigree law when the contents of a single case are not captured properly by the manufacturer (or their contract packager).  That is, the containment hierarchy for the case that is supplied to the wholesaler is incorrect.  Most wholesalers open the majority of the cases they receive at some point during their processes, but a few cases are shipped to customers without being opened.  Imagine that this incorrectly documented case is one of those that are passed on to their customer.  When using inference, the wholesaler will simply pass on the same containment hierarchy they received from the manufacturer. 

Now assume the wholesaler’s customer opens the case and finally finds that the serial number on one or more units are not the same as the electronic pedigree record indicates.  Those units have no value regardless of the price of the drug because the owner does not possess a valid pedigree and they cannot be sold without one.  There are only three ways to address this situation:

1. Destroy the units and take a total loss on the undocumented units;
2. Contact the wholesaler and negotiate with them to get a valid pedigree from the manufacturer and pass it to them.  This is unlikely to ever work because neither the wholesaler nor the manufacturer may have anything that confirms that they made a mistake.  Even if the greater mess gets revealed to them when someone else makes a claim that they received the matching undocumented serial number (which is far from guaranteed when only a single state has a serialized pedigree law), the manufacturer may not feel confident enough to update their original pedigree document and pass it to the wholesaler.  If they do, then the wholesaler also has to feel comfortable updating that new pedigree with shipping information that occurred in the past and finally pass it to the current owner;
3. Contact the wholesaler and negotiate a return of the undocumented units for credit.  The wholesaler may not be receptive to taking the undocumented units back because they have nothing to indicate that an inference error really did occur.  They may fear that they will get stuck with the unit and end up having to take a loss on it before it gets resolved.

All of these alternatives represent a lot of special handling and cost.

In addition to these special handling costs, inference errors will cause shortages of product in the supply chain.  That’s because the supply chain is becoming increasingly optimized through lean approaches to inventory management.  When a case of drugs arrives at a location in the supply chain, it is needed to fulfill customer orders, including patient prescriptions.  If even a handful of drugs are ordered, shipped and arrive but cannot be sold because of an inference error, chances are order fulfillment of some kind could be delayed.

WHAT THE STATE OF CALIFORNIA SAYS ABOUT INFERENCE

Surprisingly, the Ridley Thomas bill in California (SB 1307) that became law in the fall of 2008 included more detail about inference than most people realize.  See Section 4163.3 of the California Business And Professions Code, which reads, in part:

“…the board shall, by regulation, define the circumstances under which participants in the distribution chain may infer the contents of a case, pallet, or other aggregate of individual units, packages, or containers of dangerous drugs, from a unique identifier associated with the case, pallet, or other aggregate, without opening each case, pallet, or other aggregate or otherwise individually validating each unit.” 

It goes on to say:

“Manufacturers, wholesalers, and pharmacies opting to employ the use of inference as authorized by the board to comply with the pedigree requirements shall document their processes and procedures in their standard operating procedures (SOPs) and shall make those SOPs available for board review.  SOPs regarding inference shall include a process for statistically sampling the accuracy of information sent with inbound product.”

 And:

“Liability associated with accuracy of product information and pedigree using inference shall be specified in the board’s regulations.”

As I understand it, the Board of Pharmacy has deferred their mandated work on inference until we get closer to the effective date of the regulation.

SHIFTING ATTITUDES

In my last post, “The Modern Pharmaceutical Wholesaler and the Approaching Transformation” I said that I had observed a significant shift in attitudes creeping in about how a serialization-based supply chain pedigree system might operate.  I said it I thought it was a direct result of the growing realization that RFID will not be the predominant carrier technology at the unit level.  A few important manufactures are realizing that their choice of adopting barcodes instead of RFID will force their downstream trading partners in the supply chain to rely too much on the accuracy of their containment hierarchy information for use in inference.  This essay is already way too long, so in my next post I will analyze this concern and explore where it leads.