Last week I published an essay that gave GS1 some advice on how to trigger interest in adoption of their Global Data Synchronization Network (GDSN).  Those of you who read that essay in the first two days read my snarky comments about GS1 seemingly attempting to commandeer the term “Data Quality” to include the need for GDSN.  That was based on a mis-interpretation of their marketing materials for their “Data Quality Framework” and as soon as I discovered my mistake I removed that part of the essay, leaving the core point of the essay intact (see “An Open Letter to GS1, RE: GDSN Marketing”).

In fact, GS1 is saying exactly the opposite of what I originally thought regarding Data Quality and GDSN.  That is, before you start publishing your supply chain master data (SCMD) through GDSN you should ensure that the quality of your data is high.  As GS1 points out, “Good quality data is foundational to collaborative commerce and global data synchronisation.”  I couldn’t agree more.

The GS1 Data Quality program is centered on the “Data Quality Framework”, which is maintained by GS1 but, according to them, was originally developed by AIM, CIES, ECR Europe, FMI, GCI and GMA.  These organizations are predominantly focused on the food supply chain which is ahead of the healthcare supply chains in their use of automatic identification and data capture (AIDC) and in the use of GS1 GDSN.

The Data Quality Framework appears to be a giant “lessons learned” resource provided by the members of the food supply chain to other companies and other supply chains who might want to follow in their footsteps.  As such, it could be very valuable to companies in the healthcare supply chains to help streamline their move to more efficient AIDC and data exchange.  From my experience, healthcare has a long way to go.

You can download the GS1 Data Quality Framework from this GS1 webpage.  It consists of a ZIP file that contains a self-assessment scorecard, a Data Quality Presentation (2010), a Data Quality KPI Checklist and two PDF files.  One called “Implementation Guides for the Data Quality Framework”, and “Data Quality Framework”.

In my experience within the healthcare supply chains, companies resist the idea of data synchronization, but I haven’t heard anyone who thinks the quality of their master data couldn’t be improved.  In fact, it’s a perennial problem.  Of course, you will find that the Data Quality Framework that GS1 is offering expects you to make use of GS1 identifiers like GTIN and GLN.  No surprise, but somewhere the case has to be clearly made in support of all members of a given supply chain benefiting from the use of the same identifier for a given thing.  Is this it?  Maybe.  Maybe not.  Why not give it a chance?  No one knows better than you that your master data isn’t perfect.

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.

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

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

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

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

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

THE CALIFORNIA PEDIGREE LAW

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

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

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

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

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

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

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

Section 4034.

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

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

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

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

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

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

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

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

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

[…]

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

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

Section 4163.

[…]

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

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

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

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

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

[…]

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

HOW EPCIS WAS DESIGNED TO WORK

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

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

APPLYING BASIC EPCIS TO THE BASIC PEDIGREE PROBLEM

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

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

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

ENTER THE GS1 US HEALTHCARE 2015 READINESS PROGRAM

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

WHAT ABOUT GS1 (GLOBAL) HEALTHCARE?

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

WILL ANY OF THIS MAKE ANY DIFFERENCE AT ALL?

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

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

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

Dirk.

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

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

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

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

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

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

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

GS1 U.S. RESOURCES

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

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

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

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

WHY ARE COMPANIES MAKING THESE ANNOUNCEMENTS ANYWAY?

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

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

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

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

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

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

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

Dirk.

For more RxTrace essays related to this topic see:

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

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

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

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

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

SUPPLY CHAIN MASTER DATA SYNCHRONIZATION

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

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

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

INSTANCE DATA COMMUNICATION

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

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

MOTIVATION FOR ADOPTION

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

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

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

I am fortunate to have so many friends and colleagues who work in end-user and solution provider companies and who are impacted by the issues I cover in my blog. After each post I often exchange emails and phone calls with some of them and we discuss/debate what I’ve written about. These are great conversations because they sometimes confirm my opinions and sometimes challenge them, but I almost always come away with a more refined understanding of the technology or regulation we discussed. That is, I learn something.

This is exactly what has been happening with my recent series on Supply Chain Master Data (SCMD). As I’ve defined it, SCMD is just like regular old Master Data (MD) except that the identifier and the full data set behind each instance of SCMD has a single owner, and all parties in the supply chain who may encounter the identifier must have a way of obtaining the full set of data from the owner so they know what the identifier means. But this assumes that only the identifier will be used in supply chain data communications in place of the full data set that the ID refers to.

GLN’s On Electronic Invoices

Let’s take GS1′s GLN (Global Location Number), for example. You can use GLN’s in two ways: as true SCMD, or in a non-SCMD way.

An example of using GLN’s as SCMD in an invoice application would result in an electronic invoice that did not have any explicit addresses in it–no customer billing address, no customer shipping address and no “remit payment to” address. Instead, it would simply include the customer’s billing GLN, the customer’s shipping GLN and the “remit payment to” GLN. Each party in this example would have already obtained the full addresses from their respective owners in some way, either through a registry (like GS1 U.S.’s GLN Registry for Healthcare), or directly from the owner, so there is no need to include that data on each invoice between these parties.

The non-SCMD use of GLN’s occurs when a company uses a GLN identifier as a way of obtaining their trading partner’s full address, and then they would put the full address on each of their invoices for that partner. This approach makes use of GLN’s to “synchronize” the address master data that each trading partner keeps locally.

GS1′s GDSN (Global Data Synchronization Services Network) is a standard way of performing this synchronization between parties for GLN’s and for GTIN’s (Global Trade Identification Number). Subscribing to a service that conforms to the GDSN standard ensures that each trading partner has the current full data set that the GLN and GTIN’s refer to, as defined by their owners.

Applying the full addresses on each electronic invoice may seem like a throwback to the past when all invoices were printed on paper, but it really serves to freeze the identification of where each participant in the transaction was located at the time the invoice was executed. It provides a greater level of common understanding and contract enforcement because there is no doubt about what is intended by the invoice. The addresses on the invoice can’t change overnight.

GS1 publishes rules for exactly what changes should result in the generation of a new GLN and what changes can be made to existing GLN’s, but these are just guidelines. As I’ve said before, no one polices the data behind each GLN, so if you want to make sure the record of your transaction is perfectly static, even if you use a GDSN service, your electronic invoice should specify exactly which addresses were used at the time of the transaction. If tomorrow, an owner of one of the GLN’s used on your invoice changes the meaning of their address (as an owner of that GLN might choose to do, rules or no rules), your invoice is still accurate because, at the time it was created, the GLN meant what you put on the invoice.

Use of GLN’s and GTIN’s simply to keep your local copy of their meaning up-to-date through a GDSN compatible service is not true SCMD. It’s just a way of keeping your local MD up-to-date. The fact that you use the data set behind GLN’s (and presumably GTIN’s as well) in the invoice is distinctly different than if you had only used the GLN’s (and GTIN’s) by themselves.

Using only the GLN’s and GTIN’s on an invoice…now that’s true SCMD.

GLN’s and GTIN’s On Pedigrees

So what does this tell us about the use of GLN’s and GTIN’s in pedigrees? I look at it this way. If you wouldn’t use GLN’s and GTIN’s as SCMD on an invoice because you want the extra measure of common understanding and contract enforceability that the full address and product description gives you, then why would you use them as SCMD on pedigrees? Pedigrees should contain at least as much common understanding and clarity as invoices because they exist to protect patients. Any measure that increases their effectiveness should be employed.

Further, use of GLN’s and GTIN’s as SCMD on a pedigree introduces ambiguity that a criminal can hide behind and challenge in court. For this reason, pedigrees should always use full addresses and the full product information (the product information specified by the regulation, that is).

SCMD and Pedigree Models

Regular readers of this blog will know that GS1′s DPMS (Drug Pedigree Messaging Standard) is the only standard that currently exists specifically for use in compliance with U.S. pedigree laws. And if you read my post “Pedigree Models and Supply Chain Master Data” you know that DPMS does not make use of SCMD. That is, in keeping with the importance of full traceability that is encoded in the various U.S. pedigree laws today, DPMS requires full, explicit addresses and all of the regulated product information on every pedigree.

You will also know that the GS1 EPCIS (Electronic Product Code Information Services) standard does make use of SCMD for GLN’s and for GTIN’s. But from conversations and debates with my friends and colleagues over the last month or so I have come to the conclusion that, if EPCIS were to be used in the future as the basis of an alternative pedigree model, we will have to ignore its use of SCMD. That’s because SCMD is inconsistent with the goals of pedigrees.

But that’s OK. It’s easily fixed. EPCIS makes use of SCMD out-of-the-box because it is designed to be used by many industries for many purposes. Pedigree is only one of many theoretical future uses. There are lots of other possible applications that would benefit from taking advantage of the lightweight characteristic that is inherent in the SCMD concept.

As a general purpose standard, EPCIS is designed to be tailored to the needs of any specific track and trace application, so all this means is that to use it for pedigrees, we will have to add full addresses and some of the product (as regulated) information so that it results in the same level of explicit clarity as the pedigree system that is built into DPMS.

One more thing. The stated benefit of using SCMD is the reduction of data storage needed to hold all of those repeated addresses in all of your invoices and/or pedigrees. But all it takes is some creative thinking by solution providers to reduce the number of copies stored of each unique address to exactly one. This eliminates all of the repetition but retains the benefits of using explicit addresses. Space-saving is not a significant benefit of SCMD when this approach is used instead.

I really enjoy discussing and debating topics like this with my friends, but I encourage everyone to jump into the conversation by posting a comment in reply below. Or just sent me an email directly.

Conversations about the merits of various pedigree and authentication models usually start from dissatisfaction with some characteristic of the current GS1 DPMS pedigree model. I maintain that the design of DPMS—including its perceived flaws—is merely a reflection of the current state and federal pedigree laws and regulations. Characteristics that people don’t like—like digital signatures, a growing document as drugs move down the supply chain, and the fact that Supply Chain Master Data is not used by DPMS—are actually all characteristics of the laws and/or regulations, so any alternate pedigree model that would truly be usable for compliance would need those characteristics too.

But that’s not exactly what I want to discuss in this essay. Instead, I wanted to explain my theory of what U.S. pedigree laws are trying to accomplish in the first place. Forget about how they do it for now. What were the goals of those who wrote these laws and regulations? I’ll agree that this is impossible to know for sure but I think I can construct a pretty convincing theory. I don’t know any of the legislators or congresspeople who wrote these laws, but I have studied their work for over four years now. I have made the following observations.

1. The highest priority goal of the Florida and California laws appears to be to detect the introduction of illegitimate drugs (counterfeit, stolen, up-labeled, diverted, etc.) into the legitimate supply chain as early as possible, preferably at the very first transaction. These laws accomplish this by requiring companies buying drugs within the supply chain to receive the full supply chain history of those drugs at the time of the purchase (contained in a “pedigree”), and, most importantly, by requiring them to verify the legitimacy of those prior transactions. In Florida that verification can be performed by direct contact, such as a phone call, email, fax, etc., or, optionally, through the use if digital signatures. In California, this verification can only be performed through the use of digital signatures. The federal PDMA, on the other hand, does not appear to obligate the buyer to do any verification of the information provided on pedigrees they receive.Finally, Florida and California both require the recipient of the shipment to confirm that the physical drugs they received match those described by the pedigrees they received. That seems obvious, doesn’t it? Why would any legislative body require all or some supply chain participants to go through all the expense to generate and pass pedigree information but stop short of requiring anyone to actually look at it? Well, oddly, the federal PDMA appears to do just that.
2. There is a clear attempt in the laws to help identify who participated in the introduction of the illegitimate product. This is important if your goal is to efficiently and quickly investigate the suspected crime. This would aid in shutting down the criminals as quickly as possible before they are able to spread bad medical products very deeply into the supply chain. All U.S. pedigree laws require some type of information that describes each transaction affecting the change of ownership and/or possession of drugs. Florida requires the name and signatures (hand written or digital) of the individuals who are vouching for the accuracy of the information for each step in their pedigrees. California requires the same in digital form. For those transactions that require a pedigree, the PDMA simply wants the names (but apparently no signatures) of any company who had something to do with each distribution transaction.
3. There is also a pretty clear attempt to automatically generate solid evidence that can be used to prosecute criminals efficiently. Here again, signatures play an important role, but just as important is the fact that Florida and California require their pedigrees to be in a single record. I draw the conclusion that this is to ensure that pedigrees are constructed as self-contained pieces of documentary evidence for use “as is” in case a crime occurs.

Supply Chain Master Data in Pedigrees

In my opinion, the use of Supply Chain Master Data (SCMD) in pedigrees fails to meet these goals. When a criminal obtains a wholesaler’s license, they own the SCMD (the GLN, or Global Location Number) that describes the location of their operation. If pedigrees were allowed to make use of SCMD, the criminal would be in control of what their own GLN means. GS1 doesn’t police and enforce the guidelines, best practices or even the rules around GLN’s so the criminal could change the meaning of their GLN at any time it helps their case. Before they are discovered they can throw off investigators by defining their address at an empty lot. After they are caught, but before trial they might correct their “error” and make their GLN point to their actual address. In court, their lawyer might easily be able to challenge the pedigree because too many people can change the SCMD referenced by it, and that means the pedigree is not a fixed record but a dynamic one, meaning one thing today, perhaps something else yesterday and maybe something entirely different tomorrow. Leaving criminals in control of the content and meaning of all pedigrees they have ever touched might make pedigrees difficult to use for detection and identification, and potentially worthless for prosecutions.

To overcome this problem, regulators might be forced to make it a crime to ever change any SCMD after it is used on a single pedigree, which may leave a lot of non-criminal organizations open to criminal prosecution for inadvertently attempting to correct an honest mistake in the definition of their GLN’s or GTIN’s. It may also require the FDA to require a monitored GLN registry.

A distributed pedigree approach (See my earlier essay, “Fundamental Law of Commerce“) would have an even worse problem along these lines. It would take a pretty talented prosecutor to be able to make sense in the minds of a jury out of a pedigree that is composed of snippets that are held and controlled by an array of supply chain participants, including innocent parties and alleged criminals. In contrast, a fully self-contained pedigree could be presented to a jury much more convincingly because it can be fully displayed and validated in front of them without any need for a live internet connection in the courtroom. A self-contained pedigree would not use SCMD.

In Europe, A Different Approach

Pedigree laws in the U.S. are designed to protect the public by attempting to detect the introduction of illegitimate product into the legitimate supply chain as early as possible, identify those who were involved, and then help prosecute them. A current proposal for securing the drug supply in Europe takes a rather different approach. The European Federation of Pharmaceutical Industry Association (EFPIA), an industry organization, proposes a model that would only detect illegitimate drugs at the point of dispense (POD) in the pharmacy.  In many cases, this will prevent patients from consuming illegitimate drugs…at only the last opportunity.  However, with POD, there is no ability to identify who is introducing the illegitimate product and it offers no help in prosecutions.

In my view, widespread adoption of POD may actually result in an increase in the number of illegitimate drugs introduced at distribution. That’s because the criminal gets paid for their crimes and can disappear before the detection of their fake drugs occurs at the POD, the point of dispense in the pharmacies. These criminals probably don’t really want to harm anyone. They just want to get paid and to not get caught. If they can still get paid, not get caught and their illegitimate products get filtered out of the supply chain before they can do any harm, all the better for them. Currently POD is only a proposal, although you could successfully argue that regulations in Italy, China, Turkey and others are POD regulations.  It will be interesting to see if the approach continues to catch on with regulators.
What is your theory about what U.S. and POD pedigree laws are trying to accomplish? Reply below.