Most Warehouse Management Systems (WMS) available on the market today do a fine job of allowing their users to manage inventories in the warehouses of drug manufacturers, distributors and chain drug stores.  A WMS is a software system that may be a part of a larger Enterprise Resource Planning (ERP) system, or it may be a third-party application that is interfaced with the owner’s ERP system.

All WMS systems that I am aware of are intended to be sold into multiple industries, not just in pharma.  That’s so that the WMS vendor can maximize their sales.  The more industries, the more sales and the more profitable it is.  Because some industries have long had serial numbers on some of their products (computers and peripheral equipment, cell phones, electronics, medical equipment, appliances, etc.) WMS vendors have included serial number handling in their software for decades.  In fact, I would bet that a serial number handling feature was included in WMS systems since the very beginning of that category of software.

However, buyers of WMS systems in the pharma supply chain should be very careful not to confuse a “serial number handling” or even “serialization” checkbox on the WMS vendor’s spec sheets with the kind of “serialization” they will need for compliance with modern pharma serialization regulations.  I include the California Pedigree Law, the potential future serialization requirements that may (or may not) be coming from the FDA, and those in the E.U.

THE DIFFERENCE BETWEEN WMS SERIAL NUMBER HANDLING AND PHARMA SERIALIZATION FOR REGULATORY COMPLIANCE

The reason is simple.  Despite the similar (or same) name, serialization in the pharma supply chain leads to significantly different functionality than dealing with serial numbers on products in other supply chains.  For example, think about what would be needed for a personal computer manufacturer.  They would need to keep track of which serial number is applied to which models.  They may want to keep track of who they shipped which serial number to, and they may want to connect their warranty registration, returns, warranty claims and service processes to their serial number database so they can make sure they know exactly which sub-model revision (hardware, firmware and software) they are dealing with and to confirm that the customer is valid (for after-sales service).  All of these serial number tasks can be easily accomplished within the WMS, within an add-on module, or within some module of the ERP system because they normally do not need to communicate with the systems of other companies.  These same kind of capabilities would be needed for all of the types of products I listed above.

But these capabilities are distinctly different from those that members of the pharma supply chain are going to need going forward and so these traditional serial number features of WMS systems are insufficient.  The pharma supply chain needs to use the serial numbers on drug packages to authenticate the supply chain history, either at each stop (California), at the point of dispense (E.U.), or somewhere in between (potential future U.S. FDA regulation).  This requires a different approach.

First, all companies within a given supply chain must follow certain standards to ensure interoperability of the serial numbers themselves and the how they will be handled across all members.  That is, a WMS vendor can’t simply make up their own serial number handling features because they will not interoperate with those from other vendors.  Second, some kind of standardized data exchange related to the serial numbers must occur between trading partners, and third, the management of the data must also be standardized so that the same functionality is made available to all parties in the supply chain.

STANDARDS ENABLE INTEROPERABILITY ACROSS THE SUPPLY CHAIN

In the U.S. and in many other countries around the world, GS1’s Global Trade Item Number (GTIN) plus serial number (or SGTIN) is the standardized serial number that has been chosen (see my essays “FDA Aligns with GS1 SGTIN For SNDC” and “California Enforcement Subcommittee Moves To Require FDA SNI” and also see the GS1 General Specifications).

In California the GS1 Drug Pedigree Messaging Standard (DPMS) is known to be usable for compliance and would fulfill the necessary standard format for data exchange and data management.  However, the industry has more recently been interested in the use of GS1’s Electronic Product Code Information Services (EPCIS) standard as the basis for the standardized data exchange and data management.  Personally I don’t think anyone has shown satisfactorily that it will comply with the current California law but it appears that companies who are members of GS1 U.S. Healthcare Traceability group are hoping that it will.  (See my essays “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 1” and “…Part 2”.)  If the California Board of Pharmacy is willing to accept it, then it can be used for compliance, but until we know that, I think it’s risky to deploy systems that are only based on EPCIS.

We won’t know which standard will fulfill the needs of whatever federal pedigree regulation, if any, may be on the horizon until the regulation is published by the FDA down the road.  So far it is probably a good bet that EPCIS will play an important role and it is very unlikely that DPMS will play any role.  We’ll see…

Ignoring the debate over which GS1 standard would be used in the U.S., the point is, the existing serial number handling features of today’s WMSs will not be sufficient because they are intended for something else.  The key characteristic that both DPMS and EPCIS have that is missing from those existing WMS features is that they are able to document supply chain events that occur to GS1 serial numbers and therefore to the products associated with those serial numbers.  This includes Commissioning, Aggregation, Shipping and Receiving, among others.  When you include the fact that they are both standards that all solution developers can follow, which results in interoperability between their solutions, DPMS and EPCIS are the only ways to address the needs of these modern requirements in the pharma supply chain.

WMS AND SERIALIZED EVENT REPOSITORIES

I once thought that WMS and Pharmacy Management System (PMS) vendors would see the difference and perhaps would add at least the standard EPCIS interfaces to their products (see my essay “The Future of Traceability Repositories and Inventory Management Systems”), but as far as I know that hasn’t happened.  Perhaps they have concluded that a WMS isn’t really the place to store supply chain events.

The whole point of a WMS is for managing inventory and warehouse processes.  Serialized supply chain events are related to things that pass through the inventories, but the life of those events could extend well beyond the life of the typical data element a WMS needs to deal with today.  The data communications and management needs of serialized supply chain events is also beyond the traditional scope of a WMS.  It now seems to make more sense to have a separate repository just for those events and maintain minimal connection between that repository and the WMS.  Perhaps the only connection would be related to the time that the serialized products are present in the inventory that the WMS is managing.

Figure 1.

That might require some interface(s) between the two systems since the serialized event repository is an inventory system of a sort.  For each product code the WMS will likely maintain an inventory count and the event repository will likely maintain a list of serial numbers in the same inventory.

If you are shopping for a new WMS and you know you will need to comply with a pharma serialization regulation, make sure you fully understand the limits of the serial number handling capability of the products from each vendor you are considering.  Don’t assume that you will be covered just because the spec sheet has a check box for “serialization”.

Dirk.

Back in 2007 the U.S. Congress passed the Food and Drug Administration Amendments Act (FDAAA) and it was signed into law by President Bush.  One of the provisions of that law was an instruction to the FDA to “…develop standards and identify and validate effective technologies for the purpose of securing the drug supply chain against counterfeit, diverted, subpotent, substandard, adulterated, misbranded, or expired drugs”, and “…develop standards for the identification, validation, authentication, and tracking and tracing of prescription drugs.”

The FDA fulfilled these instructions for one of the specific standards that the law identified when the agency published their Standardized Numerical Identifier (SNI) standard back in 2010.  That standard was fairly high level and for the vast majority of drugs, use of GS1’s Serialized Global Trade Item Number (SGTIN) (or “GTIN plus serial number”) for drug package identification would comply with it.  The text of the FDA’s standard says as much.

By defining the SNI in this way did the FDA surrender the development of the real SNI standard to GS1 (at least the sNDC portion of it)?  I don’t think so.  In my essay about the SNI standard I described it as the FDA “aligning” with GS1’s SGTIN (see my essay “FDA Aligns with GS1 SGTIN For SNDC”).  Alignment shouldn’t be confused with surrender.  The choice of alignment with SGTIN was good for the FDA, good for patients and good for the industry.

WHAT WE GOT WHEN THE FDA ALIGNED THEIR SNI STANDARD WITH GS1’S SGTIN TECHNICAL STANDARD

In the case of the SNI aligning with GS1’s SGTIN we got the following things:

• An existing robust global standard that has multiple years of use by multiple industries—including the pharma supply chain—and in multiple countries;
• Automatic interoperability with the regulatory requirements of other countries who have, or will, align with the SGTIN;
• Automatic interoperability with all of GS1’s other—current and future—standards that use the SGTIN as a key component (see my essay “GS1 Standards – Betcha Can’t Use Just One!”);
• Automatic interoperability with lots of existing third-party applications that are already designed to work with the SGTIN.  Some companies in the supply chain had already deployed these systems and now they can proceed with further deployments knowing that by doing so they will remain compliant with the FDA SNI standard;
• Widespread existing knowledge and understanding of the SGTIN and how to apply it within the industry.

These are huge benefits.

In contrast, China’s State Food and Drug Administration (SFDA) chose to expand the use of their own existing product serialization standard to include drugs, but that standard does not align with the GS1 SGTIN.  That will probably benefit the government there and perhaps domestic companies who are serving only the China market, but it could also complicate international trade in pharmaceuticals where companies from China are a party.

SO SHOULD FDA CEDE ALL STANDARDS DEVELOPMENT TO GS1?

The fact that FDA’s choice to align with GS1’s SGTIN provided so many benefits should not be taken as a sign that the FDA should simply mandate other GS1 standards to fulfill their obligation under FDAAA of 2007.  It made sense when it came to the foundational SNI to use the foundational SGTIN as the aligned standard, but that’s about as far as you can go.  GS1 doesn’t have standards that are out-of-the-box usable for “…validation, authentication, and tracking and tracing of prescription drugs”.  Those are high-level applications, not foundational standards like SNI.

Yes, you can use some of GS1’s standards as the basis for applications that might validate, authenticate and track & trace prescription drugs—likely including GS1’s Electronic Product Code Information Services (EPCIS) and related standards—but it is much harder for the FDA to “align” with those standards without a lot more FDA-specific explanation of exactly how they might be applied to implement those applications.  That FDA-specific explanation would be the description of an authentication and track & trace “model”, which might use GS1 standards under the covers.

The best thing GS1 has done that the FDA might be able to use to help them formulate their authentication and track & trace “standards” is the output of the GS1 Healthcare Network Centric ePedigree (NCeP) work group.  That group simply documented the characteristics of eight different ePedigree models that would be based on GS1 EPCIS.  The documentation amounts to a concise “catalog” of authentication and track & trace models that the FDA could use to help them select a viable model for their “standard”.  (They should also see my RxTrace essays, “The Viability of Global Track & Trace Models”, “Plateaus of Pharma Supply Chain Security”, “SNI’s Are Not Enough In a Plateau-Based Supply Chain Security Approach” and a bunch of others in my back catalog.)

Regardless of what FDA chooses to do in the development of the standards mandated by Congress, they should not and certainly will not cede it all to GS1.  The mission of the FDA is completely different from the mission of GS1 and the standards they each publish reflect that difference.  While I wouldn’t be surprised if the FDA authentication and track & trace standards include some references to GS1 technical standards, they will need to provide a lot more additional details than they did in the SNI standard.

We shouldn’t have long to wait to get an initial glimpse of where the FDA is going with their track & trace standard.  As I reported in my essay “InBrief: FDA To Publish Track & Trace Standard By Year End”, we should see the first draft by the end of the year.

Dirk.

The title is a paraphrase of a TV commercial from the 1960′s, ’70′s and ’80′s for Lay’s Potato Chips but the sentiment is the same.  You really can’t get away with using only a single GS1 standard.  That’s why they are sometimes referred to as “The GS1 System of Standards“.  It’s a “system” of standards.  Multiple standards that are designed to work for you together in concert; as a whole; not independently.

So when your customer demands that you make use of Global Location Numbers (GLN) and/or Global Trade Item Number (GTIN), they are starting you down the path of adoption of much more than just those two “entry-level” standards (see my essay “So a customer demands that you use GLN’s and GTIN’s. What next?”).  Here is a partial list of other GS1 standards that you may benefit from adopting once you fully embrace GLN and GTIN:

• GS1 UPC barcode symbology
• GS1 element strings encoded in a barcode symbology such as:
• GS1-128
• GS1 DataMatrix
• GS1 DataBar
• GS1 EANCOM EDI standard
• GS1 EPC RFID in frequencies such as
• UHF
• HF
• GS1 Electronic Product Code Information Services (EPCIS)
• GS1 Drug Pedigree Messaging Standard (DPMS)
• GS1 Global Data Synchronization Network (GDSN)

GS1 Healthcare is a community organization of end users within GS1 who are members of the global healthcare industry.  That organization created the following figure to show how GLN and GTIN are foundational to patient safety and supply chain efficiency, the ultimate end goals of its members.  At the top of that foundation is GDSN and above it are the five pillars of patient safety, which support the ceiling of supply chain efficiency and the overall roof of patient safety.  (See “Change has finally come:  U.S. Healthcare industry to implement common data standards to improve safety, reduce costs” by Joe Pleasant, CIO and SVP, Premier, Inc.)

GS1 Healthcare Patient Safety "House of Standards"

Many U.S.-based hospital Group Purchasing Organizations announced a number of years ago that they would require the use of GLN and GTIN by December 2010 and 2012 respectively.  Apparently at least one of those GPO’s also requires the use of GDSN but without specifying a date.

GS1 GLOBAL DATA SYNCHRONIZATION NETWORK (GDSN)

GS1’s GDSN is a standard that can be used by supply chains to communicate product class-level supply chain master data (SCMD) to all of the companies who participate in it.  Here is how I described it in my essay, “Supply Chain Data Synchronization and Patient Safety”:

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

Here is one way GS1 draws GDSN.  This view emphasizes the plumbing and shows the “how” of GDSN.  (See “Global Data Synchronization Network® (GDSN) Operating Roadmap for GS1, Version 7.3” November 2011.)

Click image to enlarge

Here is my rendition of GDSN use in healthcare.  I show it as a cloud-based repository where the manufacturer publishes their product master data and where downstream trading partners can subscribe to it.  That way everyone in the supply chain—right down to the healthcare professionals at the points of care—are using the exact master data as published by the manufacturer.  Admittedly this rendition doesn’t show how GDSN is implemented, but I happen to think that’s less important that showing what it is.  See GS1 for the details.

Click image to enlarge

Up to this point in time there still hasn’t been any significant use of GDSN in the U.S. medical supplies and devices supply chain and it is tough to get an entire industry to adopt something so large without some kind of incentive.  The GPO’s are trying to provide that incentive by mandating its use, so at some time after the GTIN is widely adopted on medical supplies and devices, SCMD may be synchronized between manufacturers and hospitals, and perhaps distributors as well.

USE OF GDSN IN THE U.S. PHARMACEUTICAL SUPPLY CHAIN

GDSN is also not currently used in the U.S. pharmaceutical supply chain, but in my view, it will be a necessity if/when GS1’s EPCIS standard is ever used for track and trace applications like ePedigree.  In my view, EPCIS alone can’t be used for compliance with the existing pedigree regulations in the U.S. (see my essays, “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 1” and “…Part 2”).

But EPCIS just might become the basis for the track & trace standard that the FDA will publish by the end of this year (see me essay “InBrief: FDA To Publish Track & Trace Standard By Year End”).  Many people believe that standard will be based on EPCIS, similar to the way FDA aligned their sNDC standard with GS1’s GTIN (see my essay “FDA Aligns with GS1 SGTIN For SNDC”).  Include me in that group.

But, by design, EPCIS events do not carry SCMD (see my essay, “Pedigree Models and Supply Chain Master Data”), so if EPCIS events form the basis of an ePedigree, it will be a absolute necessity that all parties who are consuming and updating those pedigrees use the identical product class-level master data.  That would be necessary because everyone would need to agree on exactly what constitutes the drug that is referenced by the GTINs in the EPCIS events.  Without that common agreement on exactly what the GTINs mean, how can there be a true pedigree?

Here is a drawing that shows how GDSN could be used in conjunction with a semi-centralized ePedigree system that is built on top of EPCIS events.

Click image to enlarge

Notice how each trading partner in the supply chain communicates with both the GDSN cloud and the Semi-Centralized ePedigree cloud.  In actual implementation these clouds might not be so distinct because the same vendors might offer both, but I show them separate here because they are serving distinctly different purposes.

The GDSN cloud is serving as the common source of product SCMD as published by the manufacturer—keyed off of the GTIN—and the Semi-Centralized ePedigree cloud, based on EPCIS, is serving as the common repository for all supply chain events that occur to the actual unit-level instances of those products—keyed off of the serialized GTIN, or SGTIN.  The clouds also communicate with each other because, to produce a usable ePedigree report the ePedigree engine would need to obtain the SCMD from the GDSN cloud.

As I said, I think something like this will be a necessity if EPCIS is used as the basis of an ePedigree system.  So far when people in the industry talk about using EPICS for ePedigree they almost always forget the SCMD.  The ePedigree solution I show in the figure above is a very efficient model since the SCMD does not travel along the same path as the instance data (the EPCIS events).  This is in stark contrast to DPMS which needs to carry that data along with each ePedigree document—a big negative for that standard that many have pointed out over the years.

All pedigree models have trade-offs.  One of the trade-offs of ePedigree models based on EPCIS is that GDSN will probably have to be adopted throughout the U.S. pharma supply chain over a fairly short period of time, but no doubt patients would benefit greatly from that.

BETCHA CAN’T USE JUST ONE

There you have it.  Not only would pharma trading partners need to adopt GLN and GTIN, in this scenario they would also need to adopt EPCIS and GDSN shortly afterward.  In the pharma supply chain you can’t use just one!

Can you see any alternatives to this scenario besides adding DPMS in some way?  Leave a comment below.

Dirk.

I stumbled across the FDA’s recently published “Guidance Agenda:  New & Revised Draft Guidances CDER is Planning to Publish During Calendar Year 2012” while surfing the PharmTech website late last week.  The guide is published each year in the spring to provide a “heads-up” on which guidance documents the FDA thinks they will be able to complete and publish by the end of the calendar year.

I first learned about the significance of the annual document about 18 months ago when an FDA official explained it in a conference presentation.  In response to a question from the audience about when she thought the FDA would publish the Track & Trace (T&T) standard for pharmaceuticals, she recommended that people watch for a notice of it in the “Guidance Agenda…” each year.  She said that the annual guidance list was usually pretty accurate.  If the T&T guidance wasn’t listed, according to the FDA official, people would know that the standard wasn’t going to be published that year.  It wasn’t included in last year’s list, but it is in this year’s edition, which apparently means that we will see the standard by the end of 2012.

Congress instructed the FDA to create standards for Track & Trace, Authentication and Validation of pharmaceuticals in section 505D of the FDA Amendments Act (FDAAA) of 2007.  That’s the same section that instructed them to create the Standardized Numeric Identifier (SNI) guidance that was published two years ago.  In that case the only difference was, Congress gave them a specific deadline for the publication of the SNI standard but no specific date for the T&T standard.  But now we know it’s coming soon.

The FDA originally published draft guidance for the SNI and then, after collecting public comments on the draft, they modified it and published it as final guidance.  In my opinion, that process worked well for the SNI considering how well the final standard turned out.  I assume they will follow the same process for the T&T standard.

Like the SNI guidance, this new T&T standard will probably be non-binding, but remember, one of my theories is that this Federal T&T standard just could be the standard that ends up being adopted by States in place of their soon-to-be non-standard pedigree laws (see my essay “What Happens If RxTEC Isn’t Adopted?”).  If that happens, it could eliminate the existing patchwork of pedigree laws over time (maybe a long time) without the Federal government adopting any binding national pedigree regulation.

It’s hard to say, but it appears that sooner rather than later we will have a new Federal Track & Trace standard to consider.

Dirk.

During the California Board of Pharmacy, Enforcement Subcommittee meeting on Wednesday the members voted unanimously to recommend to the full board the approval of a regulation that would require the use of the Food and Drug Administration’s (FDA) Standardized Numerical Identifier (SNI) as the unique identifier that is required on all drugs packages as part of their pedigree law.  That law currently requires pharmaceutical manufacturers to apply unique identifiers to 50% of all their prescription drug packages by January 1, 2015 and the remainder by January 1, 2016.

The approved text reads as follows:

Pursuant to Business and Professions Code section 4034, the “unique identification number” established and applied to the smallest package or immediate container by the manufacturer or repackager shall conform to the  Standardized Numerical Identifier (SNI) set forth in the Guidance for Industry published by the U.S. Food and Drug Administration (FDA) in March 2010, consisting of a serialized National Drug Code (NDC) identifier (or equivalent product identifier for dangerous drugs for which no NDC has been assigned) combined with a unique numeric or alphanumeric serial number that is no more than twenty (20) digits or characters in length.

The full Board of Pharmacy will consider the proposed new rule in a future session.

In my view this is a logical and unsurprising move because the FDA’s non-binding SNI guidance was produced after the current text of the California law was written and this action will bring it up-to-date with the Federal standard.  In my essay earlier this week “What If RxTEC Isn’t Adopted? I pointed out that manufacturers would likely use the FDA’s SNI anyway as the unique identifier that California requires.  This move will ensure that that all manufacturers will do that.

The move also reinforces my idea (first expressed in my essay earlier this week) that the same thing could happen for the entire pedigree model in the event that no nationwide pedigree legislation is enacted at the Federal level this year.  Within the next year or so we should expect the FDA to publish a new, non-binding federal standard for Track & Trace and Authentication for use with drugs in the supply chain, as required by the Food and Drug Administration Amendments Act (FDAAA) of 2007.  If it turns out as well-crafted as the FDA’s SNI guidance, why wouldn’t the California Board adopt it as the standard for compliance with their pedigree regulation?

Admittedly the Track & Trace and Authentication guidance will be a lot more complicated than the SNI guidance, and the existing California language about the “unique identification number” was pretty ambiguous from the start so it was fairly straightforward to prescribe the use of the SNI.  But I also wonder if the FDA isn’t looking closely at the current California language and might try to produce a standard with language that would make it as easy as possible for California to embrace it as well.

We’ll have to wait and see.

Dirk.

I did not participate in the development of the Pharmaceutical Traceability Enhancement Code (RxTEC), a proposed Congressional bill that was created by the industry lobbying group known as the Pharmaceutical Distribution Security Alliance (PDSA).  In fact, while I was aware that a group had been formed last year I wasn’t aware that they were working on drafting an actual proposed bill until their discussion draft (dated February 27, 2012) appeared on the internet about 10 days ago.  I first saw it on Ed Silverman’s Pharmalot blog.

I also saw a presentation by one of the members of the PDSA last week that touched on the RxTEC proposal.  It was characterized as a “stepping-stone” to full traceability in the U.S. supply chain someday down the road.  In other words, the PDSA apparently means that their RxTEC proposal isn’t the final destination but it is only the first step toward that ideal.  At least, that’s how I interpreted that “stepping-stone” comment.

PLATEAUS OF SECURITY

Now this is a concept that is familiar to me.  In fact, as an idea stripped of all of the RxTEC-specific details, it is identical to the idea beneath the approach I proposed in a pair of RxTrace essays last May and June called “Plateaus of Pharma Supply Chain Security” and “SNI’s Are Not Enough In a Plateau-Based Supply Chain Security Approach”.

This single underlying idea originates, on both accounts, from the fact that the amount of illegitimate activities within the U.S. supply chain is really quite small compared with the rest of the world (see my essay, “Illegitimate Drugs In The U.S. Supply Chain: Needle In A Haystack”), and to reduce it further will take significant and carefully thought out investments.  It would be very easy to throw money at this problem, but there are lots of very costly potential “solutions” that wouldn’t have any impact at all on the problem.  The goal must be to have the most positive impact on the problem using the least investment necessary.

In my “plateau” essays I proposed that the best way to achieve improved supply chain security without bankrupting companies and/or causing supply disruptions was to produce a roadmap that included a series of “plateaus of security”—a concept that is identical to “stepping-stones”.  I envisioned that the success of this approach would be measured by the following outcomes:

1. Criminals cannot introduce illegitimate drugs into the legitimate supply chain without being detected well before patients are threatened;
   
   
2. Criminals who attempt to scam the system are more easily identified and more easily prosecuted using evidence produced by the new system;
   
   
3. Legitimate supply chain members can quickly and clearly differentiate between likely criminal activity and innocent unintended errors;
   
   
4. The number of businesses in the supply chain who enter bankruptcy as the result of the additional compliance costs is minimized;
   
   
5. The cost added to finished pharmaceuticals delivered to patients as the result of the new complexity is minimized.

I proposed that a properly defined system would have the entire roadmap defined from the beginning so that solution providers could work on the next plateau/stepping-stone prior to any deadline to ensure that it could be reached with the least expense.  One problem with the RxTEC proposal is that it only identifies the first stepping-stone.  It is unlikely that outcomes 1, 2 or 3 will be achieved after the first step/plateau/phase of any multi-phase approach, not just RxTEC.

One important feature of my plateaus idea was that the dates for every plateau would not need to be defined at the beginning.  In fact, if the success criteria were met at any plateau prior to the final plateau, there would be no need to continue to the next one unless and until it was found that criminals were able to circumvent the safeguards in the current one.  For that reason, the deadlines and even the technology for the later plateaus would not need to be carved in stone from the beginning.  Only the concept of the later plateaus would need to be defined at the beginning.

The goal would be to protect patients and the supply chain with mandates that require the least investments and only those that are absolutely necessary to achieve that protection.  Of course if companies find a non-compliance-related benefit by moving to later plateaus before it might be necessary for security reasons, they may move forward voluntarily.

EVEN MORE AGREEMENT BETWEEN RxTEC AND RxTRACE

Even when you look at the details, the RxTEC proposal shares some of those that I included in mine.  For example, the RxTEC data that would be encoded on each drug package includes the SNI, lot and serial number.  I made the point that if you aren’t going to move to a full track & trace or ePedigree system for a period of years after the first plateau then you would really need to include the lot and expiration date on each package so that you could get some benefits from that first plateau.  Here’s how I put it:

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

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

[…]

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

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

[…]

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

The PDSA seems to agree with that.  The RxTEC proposal also includes increased penalties for drug counterfeiters, something I also proposed in my essay last November that I called “STEP #1: Raise Penalties For Drug Crimes To Reflect The Widespread Harm They Can Inflict”.  Fortunately the U.S. Senate passed (unanimously!) last week a bill that would do just that.

BUT RxTEC GOES WELL BEYOND RxTRACE

RxTEC includes a number of features that go well beyond anything I have ever proposed.  It is a kind of a “catchall” of pet changes to pharma regulations that members of the supply chain would like to see done—some of them for quite a while now.  Here is a partial list:

• Interim pedigree provisions similar to those that were proposed in the failed Buyer Matheson ePedigree bill proposed last year.   This “pedigree” for an authorized distributor of record (ADR) is simply a statement printed on their invoices that says that the drugs were purchased from the manufacturer.  Distributors who are not ADRs would have to provide
  
  “…a statement, whether in paper or electronic form, identifying each wholesale distribution of such prescription drug, back to the manufacturer or to the [ADR] for such prescription drug…”
  
  See the RxTEC proposal for additional provisions and the details.  The interim pedigree provisions would take effect six months after enactment and would last until the RxTEC system is required, six years after enactment.  This approach seems to address the argument that was at the center of the RxUSA v. HHS court challenge.  (See my essay, “Impact of RxUSA v. HHS On Future Pedigree Legislation”.)  However, the use of the term “paper” for a pedigree seems like a step backward to me.
  
  
• Federal licensure of wholesale distributors of drugs in a way that complements and standardizes existing state licensing.  Effective six months after enactment.
  
  
• Federal licensure of Third-Party Logistics (3PL) providers, drug manufacturers and drug repackagers.  Effective six months after enactment.
  
  
• Electronic drug information (referred to as “E-Labeling” in the proposal) that would require drug manufacturers and repackagers to replace today’s paper “outsert” drug information sheets with electronic versions.  Effective one year after enactment.  This is a great idea and it should be combined with a requirement for the development of a standardized lookup service(s) (an “app for that”) so that medical professionals and patients can simply scan the SNI on their cell phone, tablet or computer and they would be presented with the electronic drug information.
  
  
• Stiffer requirements for online pharmacies to help reduce the incidence of illegitimate online drug selling.  Effective between six months and one year after enactment.  This is a very noble attempt to address the problem of illegitimate online drug sellers which is a much bigger problem today than the problem of illegitimate drugs in the legitimate supply chain.  I hope it has the desire effect.
  
  
• Formalized creation of a Pharmaceutical Distribution Chain Community group that would allow the industry to make recommendations to the FDA related to supply chain safety, security and RxTEC implementation.  It seems like the PDSA is trying to build themselves directly into the FDA as a branch with the power to insert text into the Federal Register and on the FDA’s website.  On the surface it sounds like a good idea as a mechanism that would allow the FDA to consult with industry, but I think it would go too far in providing the industry with special influence within the FDA and could jeopardize the patient advocacy mission of the FDA.

THE PROBLEMS WITH RxTEC

RxTEC is far from perfect.  That’s not surprising considering that it was developed by a committee of people from organizations with widely diverse interests.  I’ve been in those situations before and I know how the result can appear a little odd to people who didn’t go through the debates during the construction of the document.  I assume that’s where some of this stuff came from:

1.  Mandating very specific technology
Regular readers of RxTrace will know that I believe that there is a place for mandating specific technology inside of a regulation.  That place is to ensure interoperability in areas where there are too many options (see my essay “Should Regulations Dictate Technology?”).  Lots of people disagree with that, including most of the respondents to the recent FDA RFC for the consideration of replacing the linear barcode requirement with some other, more modern technology (see my essay “Will the FDA Accept RFID for Drug Identification?”).  Paradoxically, many of the organizations who oppose idea of the FDA identifying a specific identification technology to replace linear barcodes are members of the PDSA—the organization who is now trying to do just that in a Congressional bill proposal which is much worse than doing it in a regulation.

I stand by my belief that the FDA should specify one technology (either UHF RFID or 2D barcodes) for the linear barcode replacement.  But even I think it is wildly inappropriate to identify specific technologies within a Congressional bill as the RxTEC discussion draft proposes!

RxTEC would specifically mandate GS1’s SGTIN for the Standardized Numeric Identifier (SNI) and mandate that it be depicted, along with the lot and expiration date, within a DataMatrix 2D barcode (for at least the first 12 years) on each individual package.  Remember, this would end up being in a federal law.  That means it would literally take an Act of Congress to change to a new, more modern technology before the first 12 years are up!  About the only thing worse would be if they amended the Constitution to include it.  If the members of the PDSA want it that badly why did so many of them recommend that the FDA not identify any specific technology to replace the linear barcode requirement?

No.  Technology mandates intended to establish interoperability should be made by the regulatory agency in regulations that come out of a much less-specific wording in the law.  In this instance the law should simply require the FDA to work with the industry and appropriate consensus-based standards organizations to select the technologies or standards and leave it at that.  RxTEC is way too prescriptive here.

2.  RxTEC data use and availability
The proposal doesn’t define the term “RxTEC data”, but it does define the term “RxTEC” to mean a data carrier holding the NDC, SNI (which is somewhat redundant, by the way), the lot and expiration date.  Throughout the document it is clear that in this first “stepping-stone” no one is required to ever use or even read the SNI.  That appears to be one of the foundational principles of RxTEC.  It implements “lot-based traceability” on a one-up, one-down basis, and despite the inclusion of the SNI (a unit-level serial number), the proposal is intentionally not a unit-level traceability system.

For a first phase, that seems very practical, but Section 301 in TITLE III includes a provision that would allow the FDA to

“…request RxTEC data from all pharmaceutical distribution chain participants in the event of a recall, or as determined necessary by the Secretary to investigate a suspect product.”

Even the States could request RxTEC data.  The problem is that “RxTEC” is defined to include the SNI (the unique serial number that no one is required to read or use) so if the Secretary can request “RxTEC data”, does that mean that the participants really do have to read and keep track of the SNI just in case the FDA needs it?  I suppose the FDA could request it, but since the proposed bill wouldn’t require anyone to read it, they just wouldn’t get it.  Something needs a little work there.

3.  Tying the hands of the FDA rather than requiring the FDA to work with the industry
It seems to me that Section 201 of TITLE II of the RxTEC proposal goes way overboard in tying the hands of the FDA.  Under the heading “ENSURING FLEXIBILITY” the proposal lists twelve things that the regulations developed by the FDA when implementing RxTEC must conform to.  Some are reasonable, but is it really a good idea to specifically block the FDA from:

• Prescribing or proscribing specific technologies for the maintenance of data;
• Prescribing or proscribing specific methods of verification (just visually glancing at the product appears to be sufficient for verification according to other sections);
• Requiring the manufacturer to aggregate unit level data to cases or pallets;
• Requiring dispensers or wholesalers to verify product at the unit level;
• Requiring a record of the complete previous distribution history of the drug from the point of origin of such drug or point of receipt?

Those provision make RxTEC sound more like a roadblock rather than “a stepping-stone” to full traceability down the road.

In my view a lot of the bulk of Section 201 of the proposed bill could be reduced to a few sentences that direct the FDA to develop a multi-phase (multi-plateau, or multi-stepping-stone—take your pick) solution for protecting the supply chain from illegitimate activities (counterfeiting, tampering, theft/reintroduction, diversion, etc.).  It could mandate that there be at least X number of phases to ensure that the leap to each phase isn’t too great, and it could mandate that each phase last at least Y number of years (barring any unexpected major events), and then the leap to the next phase would only occur if evidence shows that counterfeiters or drug thieves are able to work around the protections in the current level.  Now that would truly “ensure flexibility” by not tying the hands of the FDA so that they are free to react appropriately in the event of a large-scale and serious counterfeiting event—a worst-case scenario.

Overall I think the PDSA’s RxTEC discussion draft is a good start toward a multi-phased supply chain security system, but it needs some work to address the problems I mentioned above and a few lesser problems not mentioned here.  They have until the end of September, as I understand the Federal Government’s fiscal year calendar, so hopefully they will continue refining it until they have something that will start the industry on its way toward eliminating the small amount of crime that exists in the legitimate U.S. supply chain.

WHAT IF RxTEC ISN’T ADOPTED?

Even before the PDSA made their RxTEC draft bill public I was trying to assess the odds that some kind of track & trace or ePedigree bill would make it through Congress this year.  On the one hand, with the Prescription Drug User Fee Act (PDUFA) bill needing to pass by the end of the Federal fiscal year there is a “vehicle” for such an amendment, but on the other, it is an election year and partisanship seems to infect almost every debate.  (See this interesting article in Pharmaceutical Commerce online:  “House subcommittee airs out serialization issues during PDUFA discussions”.)

Even though it seems like everyone is in favor of eliminating the patchwork of State pedigree laws with a single federal regulation—even the States seem to be in favor of that—would the Congress be willing to swallow a bill that increases the enforcement responsibilities of the Federal government and could therefore be considered an expansion of government at a time when politicians seem hell-bent on shrinking the Federal government and returning regulatory responsibilities to the States?  I don’t think this issue fits very well into that mold, but I am frequently amazed how the debates on other issues have made a turn down that path.

So I wonder what would happen if no drug traceability regulation passes this year?  In fact, the FDA is already authorized to develop standards for a nationwide track & trace and authentication system (ePedigree?) as part of the Food and Drug Administration Amendments Act (FDAAA) of 2007.

The FDA has already asked for generalized public input for SNI, Authentication and Track & Trace.  That occurred way back in early 2008.  Less than a year after that the FDA published draft guidance only for the SNI and asked for public comments.  After collecting comments from interested parties the FDA modified the SNI guidance and then published the “non-binding recommendations” for SNI in the form of final guidance in March 2010, (see my essay, “FDA Aligns with GS1 SGTIN For SNDC”).

With that history as our guide, and noting that the FDA is obligated to do so by the FDAAA, I think the next thing we will see will be a draft guidance for non-binding recommendations for a full track & trace, authentication and/or ePedigree system published for comment by interested parties.  It has been over a year since the FDA held a public workshop to collect input into the system attributes for the tracking and tracing of prescription drugs.  In recent presentations the FDA has indicated that it is working on that guidance.  After collecting comments the FDA will modify their draft guidance and then publish a final guidance document.  Like SNI, it will contain non-binding recommendations.

You might think that non-binding recommendations would just sit there and not have any effect on the operation of the supply chain, but look at what is happening right now with the non-binding SNI guidance.  Because California requires the application of “a unique identifier” to each drug package, and because the FDA non-binding SNI is a valid definition of “a unique identifier”, companies are most likely going to adopt it for compliance in California (see my recent essay “The Surprise Consequence of the California Pedigree Law”).

If there are any new State drug pedigree regulations drawn up at any time in the future they would be foolish to designate anything other than the FDA non-binding SNI for their unique identifier.  What the FDA has done is to define a non-binding “standard” for a unique identifier for drugs that will be applied nationwide, all without needing to make it a federal mandate.

It is possible, even likely, that if Congress doesn’t enact new drug traceability legislation, the same thing will happen with their future non-binding track & trace and authentication (ePedigree?) guidance.  Wouldn’t you think that with a Federal “standard” defined, states like California (especially) and Florida (perhaps) might decide to abandon their “special” approaches to supply chain security and simply mandate that Federal standard?  Wouldn’t you expect that any new State ePedigree regulations would simply do that from the start?  In fact, wouldn’t you expect that the existence of a non-binding Federal standard might actually make it much easier for States that don’t currently have a pedigree law to enact their own ePedigree legislation considering the fact that they no longer have to go to the trouble to figure out and document the details of how it would work—they could simply mandate the Federal standard?

In fact, most states with existing drug pedigree regulations took the text that was offered by the National Association of Boards of Pharmacy (NABP) for their laws.  The NABP “model rules” were developed back in 2003 to help States adopt a standardize set of drug pedigree rules.  But with a Federal “standard” offered by the FDA, it is possible that it would replace the NABP model rules as the reference source for new State laws.  Over time the future FDA non-binding drug track & trace and authentication guidance may become the de-facto nationwide pedigree solution that solves the current “patchwork” problem.

It would take a long time for that to occur, but without the passing of new legislation this summer, that could be our future.  What do you think the odds are that RxTEC will be passed by the Congress and signed by President Obama this year?  If it doesn’t get enacted what do you think will happen?  Leave a comment below.

Dirk.

It has been almost two years since I published “RFID is DEAD…at Unit-Level in Pharma” and we are approaching a pivotal decision by the Food and Drug Administration (FDA) that will determine whether or not RFID will be acceptable for identifying drugs in the U.S. supply chain.  Last Thursday was the scheduled final closing of the recent request for comment issued by the FDA formally known as “Bar Code Technologies for Drugs and Biological Products; Retrospective Review Under Executive Order 13563; Request for Comments, 76 Fed. Reg. 66,235” (Oct. 26, 2011) [Docket No. FDA-2011-N-0719].

The closing of this request for comment (RFC) means that it is now time for the FDA to figure out what they might do with the original questions.  That is, should they change the requirement for all packages of prescription drugs and many over-the-counter (OTC) drugs in the U.S. to contain the National Drug Code (NDC) encoded into a linear barcode?  And if so, what should they replace it with?  The RFC doesn’t give any hints about how far they might go and simply asks a series of questions of the industry and interested parties, letting the respondents propose whatever they think the agency should do.

I have spent my Sunday afternoon reading (OK, in some instances, skimming) through all of the responses.  They are available for anyone to read (or skim) at http://www.regulations.gov (search for FDA-2011-N-0719).  Considering that the input received from this RFC may influence the FDA’s decision about what to replace the linear barcode requirement with, I think the responses are particularly pertinent to RxTrace readers.

GENERAL THEMES

My reading has taken so long that I no longer have enough time left over to cover the responses in detail (consider yourself lucky), but there are a number of general themes that emerged from them in aggregate.

“Linear barcodes are so 2004″
Nearly all of the responses that answered the FDA’s specific questions indicated that it is time to move away from the use of linear barcodes.  I think all of the responses were submitted prior to the publication of my essay “Why NOW Is The Time To Move Away From Linear Barcodes” so to them I was simply restating the obvious.

“Don’t mess with ISBT-128“
The members of the blood, tissue and organ supply chain were well represented in the responses with comments that were very similar, like this one from Pat Distler of the ICCBBA.

“…we strongly encourage FDA NOT to require NDC be bar coded on licensed products requiring biovigilance (e.g., cells, tissue, tissue derived products, organs for transplant, medical devices for which donor to recipient traceability is needed).  Instead, FDA should expand the guidance given in Securing the Drug Supply Chain-Standardized Numerical Identification for Drug Packages to include all biologics such that the SNI for these products would be the unique identification number created for each package under ISBT 128 or other recognized standards.”

“Don’t restrict our choices”
Many of the respondents do not want the FDA to simply replace the word “linear” with some other specific symbology or technology.  Here is a comment that is representative of this theme:

“…we do not believe FDA should restrict the type of machine readable technology within the regulation.  The regulation should only state that machine readable information needed for traceability (unique identifier and product code) should be required.”

I was pretty surprised at how many respondents said that they wanted manufacturers to each decide which carrier technology to encode their NDC and other data in.  This is exactly counter to my thoughts as expressed in the essay “Should Regulations Dictate Technology?” where I argued,

“It is the movement by the industry in unison that is the real benefit of carefully mandating a single technology for identifying drugs in the supply chain.  It is the key to maintaining and even improving supply chain efficiencies.”

My concern is that, if every manufacturer can use whatever machine readable technology they think is best, then within a short time we will see every conceivable carrier technology in use within the supply chain at the same time.  Every barcode symbology and every flavor of RFID—and there are some other pretty weird technologies out there.  I think that’s a recipe for the degradation of interoperability.

Fortunately some of the responses in this category are simply concerned about the ease with which the FDA could change their regulations and so they didn’t think a full regulation should identify a specific technology.  They think the FDA should issue less formal guidance documents to specify the acceptable technologies.

“The type of machine readable information (linear bar code, 2-D bar code, RFID, etc.) should be provided only in easily-changed guidance documents.”

DataMatrix…DataMatrix…DataMatrix…DataMatrix…
For those responses that weren’t in the “Don’t restrict our choices” camp (and even including some of those) the most common recommendation was to replace “linear” with “DataMatrix”, one even providing additional technical detail, “DataMatrix  ECC 200”.  A representative example,

“GEHC recommends use of the GS1 Datamatrix as an alternative to the linear bar code.”

“Let GS1 decide”
Quite a few respondents recommended that the FDA turn over the choice of technology variously to GS1, GS1 US, GS1 Healthcare, or “the user community”, which is a euphemism for “companies who are members of GS1”.  John Robert of GS1 US explains it this way.

“It is also recommended that the FDA should select one standards system; specifically, the GS1 System.”

…

“In order to accommodate a variety of environments and applications, the GS1 System supports six barcodes that industry partners can work with to support their supply chain needs.  In addition, the GS1 System also supports two RFID data carriers…”

…

“Thus, it is recommended that the FDA not specify a proprietary data carrier, or any particular type of data carrier or technology.  Instead, it is recommended that the FDA only specify automatic identification standards that can be used.  Selection of data carriers must consider the constraints of the application.  The best way to determine the right data carrier for the product/package is to embrace a user driven, global process where data carrier selections are based on the operational, regulatory, business and practical considerations of the trading partners and the drugs themselves.  Therefore, the Bar Code Rule should not be based on a specific technology or a specific symbology.  Rather, it is only necessary to embrace unique identification based on global standards, and leave the selection of symbology and technology to the user community.”

“Require Lot and Expiration Date”
Quite a few responses note that the new FDA carrier technology, whatever it turns out to be, will be able to accommodate additional data with ease and that leads them to support the requirement that the drug’s Lot and Expiration Date be included along with its NDC.  Typical of these:

“PhRMA believes that both the product lot number and the product expiration date should be included in the barcode, along with the NDC number.  This information is included in the 2D barcodes that manufacturers have begun to adopt and FDA’s rules should allow for the inclusion of these data elements in the product bar code.  The inclusion of this information should be optional until 2016 and required after 2016.”

HEY, WHAT ABOUT RFID?

I know, I know, I promised you something about RFID, so here it is.  Quite a few of the responses that didn’t want the industry to be restricted explicitly listed linear barcodes, 2D barcodes and RFID as examples of technologies that should be acceptable.  Many of those would include any future technology so as not to stifle innovation (I shudder to think how many different kinds of readers we would all need to invest in!).

The only response that pushed hard for RFID over everything else was submitted by my old friend Randy Stigall of UPM RFID, an RFID tag manufacturer.  Randy’s response was an essay called “Powerful drivers for RFID pharmaceutical serialization”, apparently a reprint of his article from a pharmaceutical magazine.  In it he makes the case for the adoption of the latest High Frequency (HF) RFID standard from the International Organization for Standardization (ISO) and GS1, ISO 18000-3m3.  It is interesting reading, but I don’t think it’s likely to sway the FDA to replace “linear” with “ISO 18000-3m3 HF RFID” (sorry Randy…hey, give me a call sometime).

On the other hand, if either the “Don’t restrict our choices” or “Let GS1 decide” arguments prevail and one of them is adopted by the FDA, maybe one or two drugs identified by ISO 18000-3m3 HF RFID will show up in your drug shipments sometime soon.  What’s that?  Your linear/2D/UHF RFID combo device can’t read ISO 18000-3m3 HF RFID?  Quick.  Time for an upgrade!

Didn’t submit a comment in response to the FDA RFC?  That’s all right.  Submit one to RxTrace below.

Dirk.

Linear barcodes have served us well for almost half a century, but NOW is the time to move on to something else in the global pharmaceutical supply chain.  I think most people already agree with that but I’m not sure everyone fully appreciates exactly why that is.  It’s important to fully understand the reason why so that your resolution to move away from linear barcodes is strong and you won’t drag your feet or look back.  So let me show you.

                      SERIALIZATION
THE DAWN OF ^ CIVILIZATION

No matter what you might think is going to happen to ePedigree or track & trace regulations going forward, more and more governments around the world are concluding that legitimate pharmaceuticals should come with unique identifiers—serial numbers—attached to them by the manufacturers and repackagers.

Serialization is upon us and I believe that in 10 years the ongoing benefits from it around the globe will significantly exceed the ongoing costs.  Whether you agree to the benefits or not you certainly must accede to the fact that serialization in pharma supply chains is being mandated by more and more governments around the world, and that trend is not likely to reverse but will likely increase.  Serialization mandates are currently in place for 2015-2016 in the state of California and they are under consideration by the two largest pharmaceutical markets in the world:  The E.U. and the U.S.

Serialization is upon us and there is no turning back.  While this is the foundation for why the industry must move away from linear barcodes, it is not the complete reason.

ADDING SERIAL NUMBERS TO PHARMACEUTICALS

Serialization mandates in countries around the world vary quite a bit but the more recent the regulation, the more likely they are to specify the use of GS1 standards, either as part of the mandate or as an example of one way to comply.  GS1 linear barcodes are the most common type of product identifier barcode in use today in the larger markets so when you need to add a serial number to a drug, the addition of a GS1 serial number makes a lot of sense.

In a recent essay, “Depicting An NDC Within A GTIN”, I showed how to depict a U.S. Food and Drug Administration (FDA) National Drug Code (NDC) with an GS1 Global Trade Item Number (GTIN) for both over-the-counter (OTC) drugs and prescription drugs.  Then, in my essay “Anatomy of an FDA SNI” I explained how to use GS1 standards to produce an FDA-compliant serialized NDC, or sNDC.  An sNDC is what is necessary if you want to (voluntarily today) add a serial number to any drug that has an NDC assigned to it for the U.S. market according to the FDA’s Standardized Numeric Identifier (SNI) document from 2010 (see also my essay “FDA Aligns with GS1 SGTIN For SNDC“).  At the end of my “Anatomy of an FDA SNI” essay I used the FDA’s own example (from their SNI Guidance document) to create the GS1 string of elements that would be encoded into a barcode and placed onto the drug package:

01003555556667762111111111111111111111

What I didn’t say in that essay is that you can’t encode this or any other sNDC in the GS1 Universal Product Code-A (UPC-A) barcode symbology that is used today for depicting NDC’s in linear barcodes on many of the pharmaceuticals in the U.S. supply chain.  The UPC-A symbology itself does not support the addition of the serial number.  For that you have to switch to another GS1 linear symbology known as GS1-128 (formerly known as UCC-128 and EAN-128).

Without the serial number, the linear UPC-A barcode for the NDC in the FDA’s example would look like this (all barcode images in this essay are courtesy of Terry Burton’s website):

That’s what the NDC barcode would look like today depicted as a GS1 GTIN-12 without the serial number.  Here is what the full NDC and the serial number from the FDA’s example sNDC would look like depicted as a GTIN-14 plus serial number and rendered in the GS1-128 symbology:

Look at these two examples and you will see why serialization triggers the need to abandon linear barcodes.  The linear barcodes that result after adding a serial number to NDCs are too long to fit onto most drug labels in a way that allows them to be scanned properly.  Yes, this example uses U.S.-specific data and requirements but the same principles will apply to almost all countries and similar results will occur.  Yes, the serial number in the FDA’s example is an extremely long one that probably exceeds the needs of 99% of companies, but the technology must accommodate the extremes or it is not usable.

And that’s not even the most extreme serial number I can think of.  Serial number “YESTHISISAVALIDSRNUM” (yes, this is a valid serial number) is the most extreme serial number I can think of, and this is what it would look like as an sNDC in the GS1-128 symbology:

In fact, I had to reduce the image considerably to get it to fit into this webpage. Click on the image to see it full scale.

That’s even less workable.

SO WE NEED TO MOVE TO 2D BARCODES, RIGHT?

2-Dimensional barcode symbologies, like GS1’s DataMatrix, will solve this problem, yes.  For example, here is what the previous two examples would look like encoded in GS1 DataMatrix:

(01)00355555666776
(21)11111111111111111111

(01)00355555666776
(21)YESTHISISAVALIDSERNM

Both of these symbols take up less space than the original UPC-A barcode that only contains the NDC.  Even if we now add a lot/batch (AI=”10) and an expiration date (AI=”17) as I recommended in my essay “SNI’s Are Not Enough In a Plateau-Based Supply Chain Security Approach”, and we do so using the maximum lengths possible, these two become:

 (01)00355555666776
(21)11111111111111111111
(17)160701
(10)22222222222222222222

(01)00355555666776
(21)YESTHISISAVALIDSRNUM
(17)160701
(10)YESTHISISAVALIDLOTNM

Whoa!  What happened with the “extreme” example to make it blow up so big?  There are two things that just happened.  First, the DataMatix symbology is highly compressed and it automatically adjusts to accommodate the type and size of the data being encoded.  Notice that the length of the lot number and the serial number in the two images above are the same, but the type of the data in the lot and serial numbers are not the same.  When only digits are used the symbology can compress the image into a smaller space than it can when alphanumerics are used.  In both examples I am using the maximum number of characters allowed, but in the extreme example I am using all alphas in both the serial number and in the lot number.  That is the worst-case scenario and, as you can see, it takes up more space.

Second, the GS1 DataMatrix symbology will split into multiple segments (four in this case) once you cross a technical boundary related to the number of bits being encoded.  Alphanumeric characters require more bits to encode them than numeric characters and in this example we crossed that boundary so the image generator split it into four segments.  This helps readers decode larger symbols without significantly lowering reliability.

Considering the fact that it required me to come up with a pretty unrealistic extreme example of both serial number and lot number before the symbols made the leap to four segments I think it is unlikely that most drugs will require more than one segment.  That’s because most drugs require many fewer than 20 characters for their lot/batch and serial numbers and most companies will probably stick with numeric-only characters in their serial numbers.

WHAT ABOUT RFID?

The pharma industry could move to Radio Frequency Identification (RFID) instead of 2D barcodes where regulations allow, but I believe that is unlikely except where the overseeing regulatory body actually requires it for all drugs in that jurisdiction.  The explanation I documented for that in my essay “RFID is DEAD…at Unit-Level in Pharma” still applies.  On the other hand, RFID would also solve the space problem that we have seen results with linear barcodes and the addition of serialization.  In fact, most RFID tags would likely be placed under the product label so they would not take up any label real estate at all, but I don’t think manufacturers will view that savings as enough to offset the cost of the tags themselves.

THE TIME IS NOW

If you are a global pharma manufacturer or repackager and you haven’t yet figured out a plan for moving away from linear barcodes on your product labels, now is the time to start.  Whether you choose 2D barcodes or RFID, the existence of serialization mandates around the world is the reason you need to take action and the time is now.

If you are a distributor, pharmacy or dispenser of pharmaceuticals in parts of the world where serialization has arrived or is coming, you need to develop a plan for reading the product codes and serial numbers using technologies that drug manufacturers and repackagers will move to.  Now is the time to find out how many different technologies you will have to deal with.  Now is the time to influence those manufacturers who are considering technologies that you don’t want and steer them toward those you do want.

Now is the time.

NOW IS THE TIME…EXCEPT FOR ONE THING!

Except, the FDA currently requires that drugs sold into the U.S. market be identified with their NDC specifically in a linear barcode.  That means that in the U.S. today, you cannot move away from linear barcodes on your drug product, even when you need to add serial numbers to them for compliance with the California pedigree law in 2015-2017.  As I show above, it doesn’t make sense to add serial numbers in linear barcodes so you are left with the probable decision to put the NDC and serial numbers in a 2D barcode or RFID tag in addition to the existing linear barcode that contains the NDC by itself.  That’s pretty space inefficient.

The FDA is aware of this unfortunate situation as indicated by their recent request for comment on eliminating the requirement for the use of linear barcodes containing the NDC on drugs.  Click here to read the responses they have collected so far.  You have until February 23, 2012 to submit your own comments to the FDA through www.regulations.gov, docket number FDA-2011-N-0719.

Pay close attention to what the FDA does with this issue.  More than likely it will impact everyone in the U.S. pharmaceutical supply chain.

Dirk.

Thank you to George Wright IV of PIPS for catching an embarrassing error in my construction of the GTIN-14′s encoded into the sample barcodes.  I have now corrected and updated them.

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

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

A REVIEW OF THE FDA SNI GUIDANCE

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

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

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

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

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

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

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

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

THE RELATIONSHIP BETWEEN sNDC AND GS1 sGTIN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

01003555556667762111111111111111111111

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

(01) 003 55555 666 77 6 (21) 11111111111111111111

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

DEPICTING AN sNDC IN AN RFID TAG USING GS1 sGTIN

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

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

IMPLICATIONS OF THE sNDC SERIAL NUMBER DEFINITION

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

Dirk.

2-13-2012:  Corrected a problem with the GS1 string of elements and the human readable example.  Thanks to George Wright IV of PIPS for reporting the problem.

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 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 Company Prefix by placing them to the right of the prefix.
   
   
3. Add your Indicator Digit
   Next you need to add the single digit “Indicator digit” to the left of the GS1 Company Prefix.  Refer to my previous essay, “Anatomy of a GTIN” to learn what this digit is for.  For a unit of use package, use the value “0″.  You should now have a total of 13 digits regardless of the length of your Labeler Code.
   
   
4. 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.