Over the last year in GS1, in many of the members of the U.S. pharma supply chain and even in the FDA, the focus has turned to the analysis and discussion of three classes of electronic pedigree models:

• Fully Centralized,
• Semi-Centralized, and
• Fully Distributed.

I’ve discussed some of the pros and cons of these models here in RxTrace too (see “The Viability of Global Track & Trace Models”, “Should Regulations Dictate Technology?”, and “Could This Be Your Future Track & Trace/ePedigree Exchange Solution?”).

One of the characteristics included in many of these discussions is the “points of failure” of each model.  For example, I’ve heard it said several times that the Fully Centralized model suffers from a “single point of failure”, with the implication being that Fully Distributed models do not have this problem.  In fact, this is incorrect and in reality, both the Fully and Semi-Centralized models are much less likely to fail than models that fall within the Fully Distributed category when “failure” is defined as not being able to provide an ePedigree on demand in any given instance.

RELIABILITY ENGINEERING OF COMPLEX SYSTEMS

Wikipedia has a pretty good article on Reliability Engineering so I’ll spare you the background of the discipline that studies points of failure.  The mistake people sometimes make when comparing the centralized and distributed ePedigree model classes is to think that a single central repository is like “putting all your eggs in one basket”, and the distributed models is like “spreading your eggs out”, but this is wrong.  When it comes to the ability to produce an ePedigree on demand in a given instance, a model where all of the data is held in a single location is going to come out better in the failure analysis than one where the data is fragmented and spread out among multiple distributed databases and needs to be collected to produce a complete ePedigree.

In fact, all things being equal in each repository, the likelihood of failure would be at least n times greater, where n is the number of distributed repositories holding the fragmented ePedigree data.  That’s because, all things being equal in each repository, if any one of the distributed repositories experiences a failure, the overall system fails because it is incapable of producing the ePedigree.

BUT ALL THINGS WON’T BE EQUAL

In a Fully Centralized or Semi-Centralized ePedigree model the central repositories would be designed and maintained under contracts issued by multiple parties who would share an interest in high availability (HA) and disaster recovery (DR) so you can bet that there would be multiple online copies of the data hidden behind the façade of a single point of access.  More than likely those multiple copies would include copies that are widely separated geographically to mitigate the risks of major weather events (hurricanes, tornadoes, ice storms, etc.), natural disasters (tsunamis, fires, earthquakes, floods, etc.) and man-made disasters (terrorist attacks, war, etc.).  Even Twitter applies these principles to ensure that we won’t have to miss out on the latest celebrity drivel during and after one of these disasters.

The investment in the centralized repositories would be spread across multiple parties so more could be spent on ensuring that the data is protected without causing any one participant to pay excessively.  The costs would be spread out.

But in a Fully Distributed ePedigree model each data contributor—each supply chain participant—would be independently responsible for designing and maintaining their own repository to hold their fragment of the ePedigrees for the drugs they make, buy, sell and/or dispense.  Even many of the larger corporations in the supply chain may not have the expertise in-house—or the willingness—to apply the principles of HA and DR when designing their repositories.  It is extremely unlikely that all members would be able to do what is necessary to minimize the odds that some disaster would prevent them from providing their fragment of the ePedigrees requested.

For this reason we can’t use the phrase “all things being equal” between the repositories in the two centralized models and the distributed models.  Things are not going to be equal, and so the odds of a failure in the distributed models would be much worse than even n times greater than those of the centralized models.

WOULD A CRIMINAL CONTRIBUTE THEIR PEDIGREE FRAGMENT?

Now let’s throw into our scenario what happens when one of the supply chain participants is actually a criminal in disguise (for an example of how that can occur, see my essay “Lessons from ‘Drug Theft Goes Big’”).  In either of the two centralized models they would need to supply their ePedigree fragment data to the centralized repository before they could sell a given drug package.  The central repository would need to validate the data they contributed and if it doesn’t check out, the criminal activity would be exposed immediately and the illegitimate drug would not be able to move further down the supply chain.

But in a distributed approach the criminal wouldn’t need to supply their ePedigree fragments until later, perhaps only when someone becomes suspicious and requests the full ePedigree for a particular package of drugs.  When the criminal receives a request to supply their ePedigree fragment for a package that they know has an illegitimate history do you think they would supply that data?  Certainly not!  They would claim that they are having “system problems” and if pressed, the data would get “lost” somehow.  They are criminals, after all, and that data would be self-incriminating!

I hope you can see that a centralized ePedigree model is actually much less susceptible to failure—whether unintentional or intentional—than a distributed model.  I’ve grown to really appreciate the centralized models—particularly the semi-centralized model for free-enterprise countries.  I don’t see any characteristic where a distributed model outperforms the supply chain protections of a centralized model.  Do you?  Leave a comment below and set me straight!

Dirk.

In a recent essay I discussed GS1 Healthcare’s proposed Network Centric ePedigree (NCeP) models that are currently available for review and discussion by the industry.  By the way, GS1 is giving everyone until December 15 to respond to a survey to provide them with your thoughts on the various NCeP models.  To review the videos and respond to the survey click on this link.

In a somewhat related news item, Pharmaceutical Commerce recently published an online article by Nick Basta about the Global Healthcare Exchange’s (GHX) project to build a new prototype for a track and trace data exchange hub called “GHX updates progress on a prototype data exchange for track-and-trace“.  That article was an update to a more in-depth article by Nick about the project from last April in the same online magazine called “Healthcare Exchange Bids for Prototyping a Track-and-Trace System“.  Combined, the two very interesting articles describe the prototype that is now complete and ready for piloting.

In fact, the GHX prototype implements a track and trace event data exchange hub that would allow companies in the pharmaceutical supply chain to store and exchange GS1 EPCIS event data that comprise the full chain of custody for drugs as they move down the supply chain.  Effectively, the GHX prototype implements an NCeP where GHX provides connection pooling and all of the centralized services inherent in the ePedigree model.  Larger companies would probably still want to have their own EPCIS-based applications in-house but it appears to me that smaller enterprises might only need a small data capture application that relies on the GHX service to hold all of their data.

GHX has a lot of experience with receiving, holding and sending sensitive company data between supply chain companies as an Electronic Data Interchange (EDI) exchange ecommerce hub, among many other services, primarily aimed at the U.S. medical/surgical supply chain.  According to the original Pharmaceutical Commerce article the company has an interesting history which has resulted in it being owned today by about 20 different companies who are members of that same supply chain.  A few of them are important members of the pharmaceutical supply chain as well (full disclosure:  one of them is my day-job employer).

Keep in mind, as I pointed out in the essay, “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 2”, the GS1 NCeP models are not intended to meet existing ePedigee laws so the GHX service isn’t going to help with any of those today.  The apparent assumption is that the Congress and/or the FDA will embrace one of the GS1 NCeP models and pre-empt the existing state laws in the next year or so and in that case, GHX will be ahead of the game with a service that is designed to handle data volumes in the range of what social media sites like Twitter and Facebook handle.  According to Margot Drees, Director of Corporate Strategy at GHX, the service can already handle a sustained rate of more than 1,000 messages per second and burst rates of more than 5,000 per second.  I’m told they expect to go well beyond those stats in the very near future.  Contact Margot if you want more information.

WHAT DOES IT MEAN?

Pay close attention to what GHX has done with this new prototype and where they end up taking it in the future.  It will likely be significant to the industry.  The GHX prototype turns out to be a cloud-based service that they could mold into one of several of the NCeP models that have been defined by GS1, including either of the two Centralized models and at least one of the Distributed models (maybe more).  The core functions in the GHX prototype are currently setup to implement a Semi-Centralized model but they could fairly easily be tailored to one of the others if future federal regulations turn out to favor one of the others.  See my essay from last spring, “The Viability of Global Track & Trace Models” for more on pedigree models.

Because of their existing ecommerce business, GHX already has over 12,000 companies in the pharma and medical products supply chains connected to their infrastructure, according to one of the Pharmaceutical Commerce articles.  What that means is that the setup costs for those companies to begin using a GHX NCeP could be minimal.  The “pipe” to GHX—and by extension to up to 11,999 of their potential trading partners—already exists in the GHX “community”.  This represents an advantage that would likely give GHX a leg up on any competitive NCeP service provider.

It is also very likely that the companies that are joint member-owners of GHX could be counted on to purchase their future NCeP exchange services from GHX.  Take another look at the list of companies who fall into that category and you will see that they would represent a considerable portion of the transactions that would likely occur under a full, nationwide pedigree requirement.  These are probably the reasons GHX was willing to invest the significant resources it must take to develop a cloud-based service that has the performance capability in the neighborhood of modern social media sites in such a short time.

But there are risks for GHX.  First, what happens if Congress doesn’t enact a nationwide pedigree law that embraces an NCeP approach, or if they take so long to do so that the industry is forced to be ready for the California effective dates first?  While the GHX prototype is only aimed at an NCeP approach right now it may be possible for them to redesign it to help companies store, validate and exchange DPMS pedigrees if the NCeP concept doesn’t take hold.

Another risk is the possibility that the NCeP model that the government and industry settle on could be one of the fully distributed versions that do not have any need for centralized components.  In that case the value of the GHX service would be significantly decreased, but I think they could still attract customers because of the value of the connection pooling service they could offer.  (See my essay, “Impact of RxUSA v. HHS On Future Pedigree Legislation“ for my thoughts on the likely failure of a distributed pedigree model in the U.S.)

Whatever ultimately happens I think GHX is a company to watch.  What do you think?  Leave a comment below and tell us.

2012:  IT’S GOING TO BE A GREAT YEAR!

I’m planning on making this my last posting for 2011 so I can enjoy the holidays with my family and friends.  I hope you all can do the same.

Keep reading RxTrace in 2012.  A lot is going to happen and I will continue to provide you with my perspectives.  Here is a short list of topics that I am already planning for 2012:

• FDA UDI proposed guidance
• The real pro’s and the real con’s of DPMS
• The complexities of pedigree compliance faced by kit makers
• More about applying standards to solve pharma supply chain problems
• A history of pharma supply chain security regulations and technology

Plus, analysis of:

• Whatever the FDA decides to do about updating their barcode rule
• Any action taken by Congress on Track & Trace or ePedigree
• Action by any state on ePedigree
• Industry preparations for California pedigree compliance

HAPPY HOLIDAYS!

Dirk.

There are more than one reasons why you shouldn’t expect to use GS1’s EPCIS by itself to comply with the California pedigree law.  Part 1 of this series showed that the traditional distributed network of EPCIS repositories in the U.S. pharma supply chain doesn’t work.  But that analysis assumed the use of the “vanilla” EPCIS standard, without the use of any “extensions”.  That’s not really the way GS1 intended EPCIS to be used.  In this and future essays of this series I will explore some of the approaches that make full use of the extensibility that is built into the standard.

In this Part of the series I want to take a closer look at the work of the Network Centric ePedigree work group of the GS1 Healthcare Traceability group.  I am one of the leaders of that group along with Dr. Mark Harrison of the Cambridge University AutoId Lab, Dr. Ken Traub, Independent Consultant, and Gena Morgan of GS1, along with strong contributions from Janice Kite of GS1 and Dr. Dale Moberg of Axway.  The larger group consists of people who work for companies in the pharmaceutical supply chain, GS1, and solution providers from around the globe, although I think the majority are from the U.S.

The NCeP group published a very interesting recording of a presentation that explains the details of their work.  It is called “NCeP – Technical Analysis Sub-Group, Event Based Pedigree”.  The purpose of this recording is to help people outside of the close-knit NCeP group to learn about the pedigree models developed there, evaluate them and provide feedback to the group about which model(s) should be considered for ePedigree and traceability regulations in the future.

WAIT…”REGULATIONS OF THE FUTURE?”  BUT WHAT ABOUT CALIFORNIA?

That’s right.  One of the first decisions the NCeP group made back when they were formed was that they would purposely avoid trying to create a solution that would specifically work in California.  The group recognized that the current California pedigree law as written leads you down a path that only ends up at a document-based approach to compliance.  If the group had chosen to go down that path, it would have only led to the creation of a duplicate of the existing GS1 Drug Pedigree Messaging Standard (DPMS).  The DPMS standard defines a document-based ePedigree model that was purposefully designed in 2006 to help companies comply with document-based ePedigree laws like the Federal Prescription Drug Marketing Act (PDMA), the Florida Pedigree Law, the California Pedigree Law and all of the “normal distribution” state pedigree laws that exist around the U.S. today.  There would be no benefit in reproducing the same kind of functionality by shoe-horning the non-document-based EPCIS standard into a document-based solution.

So instead, the group decided to focus on defining models that would allow the EPCIS standard to be used as it was designed to be used with the hope that the result could be used to persuade legislators in the U.S., the E.U. and elsewhere to produce new legislation that would embrace one of those models.  This was a much better approach because it removed the constraints imposed by the existing laws that come from their document-centric design.  In the U.S. the thinking is a new Federal pedigree law may define a network-centric approach to pedigree that aligns with one of the models defined by the NCeP group, and—most importantly—that it will pre-empt the California pedigree law so that the industry can veer away from document-based compliance before the deadline.

If Congress does not enact a new law that can be met using a network-centric approach by 2015 then companies will need to invest in DPMS-based systems.  Those systems would almost certainly also make use of the EPCIS standard to capture and hold serial number events but those events would be encapsulated in DPMS pedigree documents for exchange.  The same would occur if Congress enacts a new law but follows California’s lead and makes it document-specific.  How long can companies wait for Congress before they need to start investing in DPMS systems in preparation for California?  Maybe another 12 to 18 months I’d say.

WHAT ARE THE PEDIGREE MODELS DEFINED BY THE GS1 NCeP GROUP?

The NCeP defined seven different models that make use of EPCIS to create a network-centric pedigree system.  The best way to find out about them is to listen to the recorded presentation that the group produced, but here is a listing:

1. Single centralized model
2. Semi-centralized model
3. Distributed Push model
4. Distributed Query Model Using ASN to Push Links
5. Distributed Query Model with Discovery Services
6. Distributed Model Using Centralized Discovery and Checking Services
7. Push All Events Model

Personally I think that models 1 and 7 are equally impractical and probably shouldn’t be on the list for free-market countries.  Model 1 assumes only a single repository for pedigree data and would probably be implemented as a government-run entity.  Smaller countries might consider a model like that but because the volume of transactions would be so huge, larger countries should avoid it.  Model 7 is basically the shoe-horning of a document-model into an EPCIS-based approach.

What you are left with are the Semi-Centralized model and four distributed models.  For California compliance specifically, the distributed models have the fatal flaw that they are, well…distributed (see Part 1 of this series, “The Viability of Global Track & Trace Models”  and “Inspecting An Electronic Pedigree”).  That leaves us with the Semi-Centralized model.

COULD THE SEMI-CENTRALIZED NCeP MODEL WORK IN CALIFORNIA?

The Semi-Centralized model requires all trading partners to push their EPCIS event contributions to a drug’s pedigree up to one of multiple pedigree repositories.  From that repository a pedigree “report” (a modified DPMS pedigree message perhaps that contains an overarching digital signature applied by the central service) could be requested that could contain all of the data elements that the California law requires (see the full list in Part 1 of this series).  Only the certifications required by California would require some special extension work but that could be done.  This model can even fulfill the need for each trading partner to validate the full transaction history on the pedigrees at each transaction without downloading the full report every time (the central checking service would perform the analysis and simply notify the data owner of the results).

I think it may be possible that the Semi-Centralized model could fill the requirements of the California regulations but it would take some work to add the elements that would be necessary.  This would take some special work by technical experts to accomplish properly.  See my essay “A Semi-Centralized, Semi-Distributed Pedigree System Idea”.  At this point in time, it would require a group of people to jump right on it so that the concept definition and development work gets done quickly and decisively.

I’m not sure there is sufficient interest in formalizing a true alternative to DPMS of any kind in California now that there appears to be some chance that the Congress might act soon, which would potentially pre-empt the California law entirely.  We have a tendency in this effort to put all our eggs into one basket and hope for the best.  That’s a lot of hope on top of hope in my view.

Technically this approach would not use EPCIS-alone because the pedigree report would need to be implemented with all the same characteristics of a DPMS pedigree with some modifications.  So I believe this model would be a combination of both the EPCIS and DPMS standards—a concept I have supported for many years (see this essay from 2008 “Combining EPCIS with the Drug Pedigree Messaging Standard”).

WHERE ARE WE NOW?

This essay is Part 2 of why a pedigree solution for California’s existing law cannot be based only on EPCIS and still comply.  We found that there is at least one NCeP model that might enable compliance but it would take an effort that may not get organized because of the distraction of the work that appears to be just starting in Congress.  Maybe that work will be fruitful and any work on alternate California models would turn out to be a waste of time.  That possibility may easily dampen the interests of those who are qualified to do the work.  In that case, we’d better do more than hope that Congress is successful.  I understand there is a coalition of companies who are pursuing just that.  We’ll see if they are successful in the next 10 months or so.

Which direction do you think we should spend our time and efforts on right now?  If the lobbying effort in Congress doesn’t work by the end of this session, are we happy enough with DPMS to move forward with that document-based approach there as the effort to get action out of the next session of Congress?

Leave comments below, either named or anonymously, or just send me an email with your thoughts (I won’t publish those).

Dirk.

I attended the Partnership for Safe Medicines (PSM) Interchange 2011 conference on October 27 in Washington DC.  (I’ll cover that event more fully in a future essay.)  For me, the event couldn’t have been better, but I measure events like this perhaps a little differently than most people.  The agenda is important and the quality of the speakers is absolutely important, but in my view those are simply the things that lead to the one thing that can transform a merely good conference into a great conference:  the quality of the attendees.

(The quality of the attendees is exactly why I like the HDMA Track and Trace Seminar.  BTW, this year’s HDMA event starts this Thursday).

In the case of this year’s PSM event, I rate the quality of the attendees very high, and that’s because I had a number of great conversations with some very knowledgeable people during the breaks and at the social event the evening before.  That was my interaction with the attendees, not the speakers.  One of the topics of conversation surrounded the question of what exactly it was the led to the successful challenge to the Prescription Drug Marketing Act (PDMA) pedigree provisions in the RxUSA v. HHS court case and appeal and whether or not the same thing might occur with other drug pedigree laws.

AN IMPORTANT QUESTION GOES UNANSWERED

One of the first speakers at the PSM event was U.S. Representative Jim Matheson (D-UT), sponsor of H.R.3026, the “Safeguarding America’s Pharmaceuticals Act of 2011” which was introduced into the House of Representatives on September 22, 2011.  There are some differences, but the core of this new bill is basically the same as the Buyer-Matheson-sponsored H.R.5839 “Safeguarding America’s Pharmaceuticals Act of 2008” which was referred to the Subcommittee on Health in the House Committee on Energy and Commerce back in 2008 where it was allowed to die.  H.R. 3026, the new bill, is now sitting in that same subcommittee.

Representative Matheson spoke about his latest bill.  The whole time he was speaking I kept wondering if this new bill makes any attempt to address the deficiencies in the PDMA pedigree provision that were the subject of the RxUSA v. HHS court challenge.  RxUSA, a small drug distributor, was successful in obtaining a court ordered preliminary injunction against the implementation of some of the FDA’s regulations [specifically within 21 C.F.R. § 203.50(a)].  The U.S. Food and Drug Administration (FDA) believed that those provisions were soundly based on the PDMA law.  The Department of Health and Human Services (HHS), the larger federal agency that the FDA resides within, appealed the lower court’s ruling and lost the appeal.  The FDA finally removed the enjoined provisions just this last summer.

Certainly, given that history and the resulting four-plus year delay in some protection of the supply chain, the authors of this new bill would have spent considerable effort making sure that they addressed any deficiency that existed in the PDMA that led to the successful court challenge.  In fact, these flaws in the PDMA are one of the main reasons you would even need new legislation.  And being the sponsor of that bill, certainly Representative Matheson should be aware of any effort to address those flaws.

By the end of his speech he hadn’t touched on that particular topic so I raised my hand to ask the question.  Representative Matheson had limited time and could only take three questions.  By the time the third questioner had been selected, I wasn’t one of them so I lowered my hand thinking that I wouldn’t get my question answered.  But then the person who had been chosen to ask the final question asked almost the exact same question that I had in mind.  The questioner was a VP at Pfizer.  Apparently we were thinking the same thing.  She asked if this new bill addresses the problems that apparently exist in the PDMA?

Representative Matheson’s answer:  “I don’t know”.

THE ARGUMENT UNDER THE RxUSA CHALLENGE

What was it that made RxUSA’s challenge so solid that the preliminary injunction stood up on appeal in the Federal Appellate Court?  RxUSA claimed that the FDA’s requirement that a pedigree must extend all the way back to the drug’s original manufacturer was potentially an “arbitrary and capricious” interpretation of the PDMA’s requirement that a wholesaler must provide a statement “identifying each prior sale, purchase, or trade of such drug.“  Both the District Court and the Appellate Court agreed and upheld the preliminary injunction on enforcement of that requirement.

It’s important to note that neither court determined with certainty that the PDMA or the FDA’s interpretation of it were arbitrary and capricious.  Instead, they determined that there is a “better than 50%” chance of proving them so, and that’s apparently enough to retain the preliminary injunction against enforcement until the issue can be fully determined in a different court action.  It doesn’t look likely that either party will pursue that question now.

RxUSA argued that since, under the PDMA, all Authorized Distributors of Record (ADRs) are exempt from the statute’s pedigree requirements,

“Thus, if the FDA’s regulation were put into effect as written, all lower-level distributors would be required to provide pedigree information that is currently held only by authorized distributors. The [lower] court determined that this would effectively make it impossible for lower-level distributors to comply with the law.”  (quote from the Appellate Court decision)

That is, because the ADR was not required to record and maintain any pedigree, or statements “identifying each prior sale, purchase, or trade of such drug”, it would be impossible for a lower-level distributor to acquire the information necessary to generate a pedigree that extended all the way back to the original manufacturer, which was part of the FDA’s interpretation of the PDMA.  That’s because the pedigree that the lower-level distributor needed to produce would have to include the information about the ADR’s purchase and sale of the drug–information that only the ADR could provide.  Since the ADR wasn’t required to keep that information, they could choose not to keep it, or not to provide it and then the lower-level distributor could not fulfill the requirement.

DOES THIS CASE HAVE ANY IMPACT ON THE SELECTION OF PEDIGREE MODELS?

I think it may.  First, I think it shows just how important it is for pedigree legislation to cover all the bases and leave little for interpretation.  Second I think it shows how closely the exact wording of a pedigree law must be followed.  This Court followed the letter and not merely the spirit of the law.  That’s not really surprising I suppose.

Of course, the Court did not review the entire PDMA, it looked at only the specific challenge brought by RxUSA.  But the argument that a downstream trading partner in the supply chain cannot fulfill their legal requirement because an upstream trading partner is unwilling or technically incapable of providing certain information that was necessary for them to comply, sounded familiar to me.  That’s very close to what would happen within the operation of a true “Distributed Pedigree” model.

In a distributed pedigree model, upstream trading partners (like manufacturers and the first distributor of a given drug) won’t feel threatened because their ability to obtain the information they need to comply is fairly well assured.  The farther down the supply chain you get, however (like “lower-level” distributors and pharmacies) the more complex and difficult it will be for companies to obtain the information they need at the moment it is necessary for them to prove that they can construct a pedigree.  If any one of the upstream previous owners of a drug cannot or will not provide the information that is necessary to the downstream trading partner for compliance it will be impossible for that downstream partner to comply with the law.  Fundamentally that sounds to me just like one of the arguments that RxUSA successfully made in their case.

Another thought is that it appears that none of the existing state pedigree laws have the flaw that exists within the PDMA.  None of them exempt ADR’s.  Most either exempt the pedigree entirely for certain types of supply chain movements—so called “normal distribution”—and/or they require all parties in the supply chain to update a pedigree document with all the information that downstream parties will need and passed it down the supply chain along with the drug—the so called “document pedigree” model.  In the document model downstream parties don’t have to obtain additional information from upstream parties, but the document gets larger as it moves down the chain since it is carrying all of the information contributed by prior owners.

IS A RATIONAL PHARMA SUPPLY CHAIN SECURITY LAW EVEN POSSIBLE?

I’m not a lawyer, so don’t take my theories as facts but check with your lawyer before taking any action.  The PDMA’s exemption of the ADR is at the core of the successful RxUSA challenge.  It’s pretty clear why the Congress might have preferred to make such an exemption.  Distributors who are authorized by the manufacturer to distribute their drugs are most likely to buy those drugs only from them, and in very high volumes.  To place strict record-keeping requirements on those companies would be pretty onerous because of the huge volumes of product involved, and would not likely be necessary considering that they buy almost exclusively from the manufacturer—a source generally considered safe.  So, on the surface, it seems logical to exempt them.  But that’s the flaw.

So what’s the solution?  Is it even possible to create a meaningfully protective law that doesn’t have that flaw and yet is capable of being mirrored in a technical pedigree model that is affordable for all participants?  This is the link between law, regulations, standards and technology.  All of these pieces need to fit together intelligently so that costs are minimized at the same time that protection of the supply chain against criminal activity is maximized.  Producing a pedigree or track & trace law in a vacuum without considering the all these elements is very likely to fail from some legal challenge as the PDMA pedigree has, or because the costs throughout the system are too high, or because it fails to stop criminals from gaming the system.

But I think it is possible to craft a law that meets all of these challenges.  It’s just going to take a concerted effort.  What do you think?  Leave your comments below.

Dirk.

Within conversations held during the development of standards for electronic pedigrees it is sometimes common to hear people apply the following test to any pedigree proposal:

“A state inspector arrives at your facility without prior warning, enters the warehouse, picks up any random package of drugs and asks to see ‘the pedigree’ for this package.”

The point being made is that, according to the California Pedigree Law, at the very least, supply chain members will need to be capable of producing a full pedigree for any and every package of drugs in their possession at any time in case of a surprise inspection.

This scenario is an important one when selecting a pedigree model, but it often causes me to think about exactly what the company being inspected would show the inspector, and how they would do that.  To comply with the law, ‘the pedigree’ must be electronic.  That is, it would be in the form of computer-friendly data.  The only electronic pedigree format that is known, with some confidence, to be usable for compliance in California is the GS1 Drug Pedigree Messaging Standard (DPMS) and it carries the data in an XML (eXtensible Markup Language) file.  Even GS1’s Electronic Product Code Information Services (EPCIS) –based systems that many people are hoping will comply with the law stores the data that would constitute ‘the pedigree’ in XML.

But XML isn’t really very readable to humans, with the possible exception of computer programmers.  It’s not likely that the inspector is going to want to see a printout of the pedigree XML data when he or she asks to see ‘the pedigree’.

Instead, most people I know assume that companies will need to show a fancy formatted report that represents the data that is in ‘the pedigree’ XML.  Remember that the Florida pedigree regulations stipulate a specific form that constitutes a valid paper pedigree format and, while they allow pedigrees to be held and exchanged electronically, they apparently expect the electronic pedigree to be presented to them as a printout that is formatted to look just like the paper form.  That may be what leads people to think that California will accept a formatted paper printout that contains all the same data that is in the electronic XML data that is the actual pedigree.

In fact, even the California Board of Pharmacy seems to agree with this kind of presentation of pedigree data to an inspector.  In their January 2008 draft document called “Questions and Answers Relating to the California Electronic Prescription Drug Pedigree Law(s)” the very last question and answer is:

“Q78 Can a wholesaler or pharmacy maintain/store the pedigree record electronically?

Yes. California law requires that records of the manufacture, sale, acquisition and distribution of prescription drugs be available on the licensed premises for three years from the date of making (B&P §§ 4081, 4105, and 4333.) The pedigree record may be kept electronically so long as a hard copy and an electronic copy can during that period immediately be produced (B&P § 4105.)”

The pedigree record may be kept electronically so long as a hard copy and an electronic copy can…be produced.  Hhmmm…Personally, I think the board has mis-interpreted their own law, but I’m not a lawyer and you should consult with yours to decide if you agree or not.

WHY ACCEPTING A PRINTED REPRESENTATION OF AN ELECTRONIC PEDIGREE IS A BAD IDEA

One of the whole points of pedigrees is to help detect criminal activity within the legitimate supply chain.  The California law is quite clear on the requirement that pedigrees be electronic and it doesn’t mention paper, hard copies or printouts.  The reason is fairly obvious, I think.  Electronic pedigrees can take advantage of modern electronic security mechanisms that have been developed over the last 40 years.  DPMS takes advantage of digital signatures to make even the slightest tampering plainly obvious.  But these mechanisms don’t work when they are printed out.  There is no effective protection retained from a digital signature when you print it.

In fact, a criminal wouldn’t even need to bother investing in pedigree management software if an inspector only expects to see a printed representation of an electronic pedigree.  They would simply use a word processor and maybe some simple scripts to print a very nice looking fake “pedigree” that contains a believably proper chain of custody.  It doesn’t need to be true because, unlike an electronic pedigree, with a printout the inspector can’t easily check its accuracy or consistency while he or she is on the premises.  Checking it later would provide the criminal with the time to pack up and disappear.

HOW TO INSPECT AN ELECTRONIC PEDIGREE

So if a printout is a bad idea, how should an electronic pedigree be inspected?  In my view inspectors should carry a laptop computer that has some standard pedigree checking software on it and they would ask the company to provide them with a copy of the electronic pedigree data on a USB thumb drive.  Or in a Semi-Centralized pedigree model the company would give the inspector temporary access to the pedigree data stored in the cloud-based third-party repository.  (See my essay “A Semi-Centralized, Semi-Distributed Pedigree System Idea”.)

The inspector would then use their own checking software to check the digital signatures and present the results on their screen in a format that would look just like the printout might have looked.  The difference here is that the analysis of the electronic pedigree would be performed by software, brought by the inspector, that has been certified against whatever pedigree standard is in use.  If a pedigree has been faked or tampered with, this software would easily detect it and would display that result.

WHAT IF THE INSPECTOR MAKES A SLIGHTLY DIFFERENT REQUEST?

So far in this essay I haven’t differentiated between a distributed pedigree system and a non-distributed one.  (For a discussion of various track & trace models see my essay “The Viability of Global Track & Trace Models”.)  People think that the logical pedigree-related request for an inspector to make is the one I started this essay with.  If the data necessary to produce a pedigree is distributed across multiple trading partners (the previous owners of the drug) and needs to be collected before it can be presented to the inspector, everything still works as I’ve described above (assuming those trading partners’ systems are responding at the time the inspector makes the request to see your pedigree).

But what if the inspector makes the following request instead?

“Show me the pedigree that you received from the seller at the time you acquired this drug”

This may seem like an insignificant variation of the earlier request above but it’s actually an entirely different request.  With this request the inspector is testing the requirement that, as the buyer, you “may not acquire a dangerous drug without receiving a pedigree”.  The trouble is, in a distributed pedigree model companies would not actually receive the full dataset necessary to build ‘a pedigree’ at the time they receive each drug package.  That would only occur at the time an inspector asks to see the pedigree.

If the company being inspected is using a distributed pedigree model and they respond to this request by collecting the necessary data from the previous owners and constructing the pedigree for the inspector, it seems like they are committing a form of fraud (check with your lawyer) since the resulting pedigree is not the pedigree they received at the time they acquired the drug.  It was constructed just now for the first time.

In fact, in a distributed pedigree model, they did not receive ‘a pedigree’ at all at the time they acquired the drug, which appears to be a violation of the law.  (For an explanation of what constitutes ‘a pedigree’ in California see my previous essay “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 1”.)

With this logic, I contend that a true distributed pedigree model, by its nature, doesn’t comply with the California Pedigree Law.  Do you disagree with this logic?  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“.

© Copyright 2011 Duncan Champney. used with Permission. This image was created with FractalWorks, a high performance fractal renderer for Macintosh computers. FractalWorks is available on the Mac App Store (Click on image).

The debate over pedigree regulatory models in the U.S. pharmaceutical supply chain often centers around how much data for each package of drugs needs to be moved between trading partners as those drugs move down the supply chain from the manufacturer to distributor(s) and ultimately to the pharmacy.  The ideal model would minimize the amount of data moved yet always allow each member of the supply chain to check the prior history—the pedigree—of the drugs they are about to buy.

At a superficial level this appears to be all you need to do, but when you take a closer at the details of how the supply chain actually works in the U.S. you will see that there are other characteristics besides data volume per package that need to be considered.

FOUR VIEWS OF THE U.S. SUPPLY CHAIN

In the debates and discussions over pedigree regulatory models we are used to seeing a view of the supply chain that shows one manufacturer, one distributor and one pharmacy.  That view masks so much important complexity that if we were to select a regulatory model or solution based on that view it would be far from ideal.

Here is a view of the supply chain where the vertical scale shows something closer to the true proportions between those three segments. (Click images to enlarge.)

Figure 1. Proportions of the three primary segments of the U.S. pharmaceutical supply chain. Counts for the manufacturers and pharmacy delivery points are from the HDMA (2009). I estimated the number of pharma distributors based on the list of corporate entities found in the Authorized Distributors of Record (ADR) lists of several large pharma manufacturers found on the internet. Keep in mind that more than 90% of the volume of drugs passing through the supply chain goes through only three distributors.

The most striking thing about this view is that it shows how few distributors there are compared with the number of manufacturers and especially compared with the number of pharmacy delivery points.  If you would take the total volume of drugs that pass through this supply chain in a given year and divide it evenly among each of the entities in each segment you would find that the percent of product that the average distributor handles is much higher than that of the average manufacturer and would be huge compared with that of the average pharmacy.  Of course, the reality is much different–some handling more product and some handling much less than the average–because the sizes of the companies in the supply chain vary widely.

Now let’s take a magnified look at the immediate view of the supply chain from the perspective of an average drug manufacturer.

Figure 2. View of the U.S. pharma supply chain from a typical manufacturer. Most manufacturers ship the drugs they make to many of the licensed distributors.

Manufacturers typically want to maximize the availability of their products to all licensed pharmacies in the U.S. so they work to setup and maintain connections with as many licensed distributors as they can handle.  The largest manufacturers deal with most or all of the roughly 70 distributors in the U.S.  Of course, there is bound to be some selectivity by smaller manufacturers but probably not as much as you might find with many non-commodity consumer products.

Now let’s take a magnified look at the immediate view of the supply chain from the perspective of an average pharmacy.

Figure 3. View of the U.S. pharma supply chain from a typical pharmacy. The typical pharmacy in the U.S. buys their drugs from a primary distributor, and only if that primary distributor is out-of-stock do they buy from one of a small number of secondary sources. Chain pharmacies are an important exception but are not depicted in this drawing.

The great majority of drugs dispensed in U.S. pharmacies is initially sold by the manufacturer to a distributor, who then sells it to the dispensing pharmacy.  Pharmacies typically only buy their drug supplies from a small number of the distributors.  In fact, most have a single primary distributor and a small number of secondary sources which they usually order from only when their primary supplier is out-of-stock of a given drug that they need.

This is even true of chain pharmacies, although these companies maintain their own internal distribution networks and the largest chains are big enough to buy the highest volume drugs directly from the manufacturers.  This is an important exception when considering pedigree models, although even these pharmacies buy a large number of lower volume drugs from distributors.

Now let’s take a magnified look at the immediate view of the supply chain from the perspective of an average distributor.

Figure 4. View of the U.S. pharma supply chain from a typical distributor. The typical distributor in the U.S. buys their drugs from most of the drug manufacturers, and sells those drugs to many pharmacies. The three largest distributors each sell and deliver to tens of thousands of pharmacies.

Distributors are at the center of the typical drug supply chain for most drugs in the U.S.  To offer a complete catalog, the typical pharma distributor buys their stock from many of the 1,400 manufacturers.  The larger the distributor, the more likely they are to buy from most if not all of these manufacturers.

The typical distributor sells to a large number of pharmacies, whether as a primary source or as a secondary source.  The number of pharmacies that a given distributor sells and delivers to is one of the primary components in the determination of how “large” they are.  The three largest distributors each sell and deliver to tens of thousands of pharmacies.

PEDIGREE IMPLICATIONS OF THE FOUR VIEWS

These four views of the supply chain expose an implication about the various pedigree models that wouldn’t be obvious if you only looked at the simple three-trading-partner view of the supply chain.  Because some data would need to move somewhere in all pedigree models, these views can help us evaluate those movements.

In the drawings I refer to “connections” between trading partners.  These refer to direct business relationships, but they can also refer to data connections in any model that requires data to be passed directly from seller to buyer.  For example, the basic model defined by the GS1 Drug Pedigree Messaging Standard (DPMS) would need to pass data along these connections.

Distributed pedigree models like those that make use of GS1’s Electronic Product Code Information Services (EPCIS) standard would also need to pass data along these connections.  But in these models, each downstream trading partner would also need to communicate directly with every prior owner of the drugs they buy.

For example, each pharmacy would need to have a data connection to each of the manufacturers that made the drugs that they received, even those they bought from one of the distributors.  You can see that the number of connections that a given pharmacy would need to deal with would become much greater than just the small handful they would need to deal with in a DPMS model.

On the other hand, Centralized and Semi-Centralized models would not need to pass data along these connections because in these models each trading partner communicates directly with a relatively small set of pedigree data repositories.  See my last essay, “The Viability of Global Track & Trace Models”.

One common thread between all current pedigree model solutions under consideration in the U.S. right now is their use of Applicability Statement 2, or just AS2, for the secure transmission of data between entities.  AS2 is already in use within the U.S. pharma supply chain for the exchange of EDI (Electronic Data Interchange) documents, but not all companies make use of EDI and not all companies have AS2 capability.  Few pharmacies do.

As used today in the supply chain, each AS2 connection has a setup cost which entails, among other things, exchanging encryption keys between the parties.  For every pharmacy to do this with every pharma manufacturer, as would apparently be needed in a distributed pedigree approach, is almost inconceivable.  Once set up, keeping up with the changes stemming from mergers and acquisitions activity alone would be a reoccurring nightmare for any company, including the largest distributors and chain pharmacies.

But now look at it from the perspective of a pharma manufacturer who, in a distributed pedigree environment would have to deal with an AS2 connection to every single pharmacy that buys their drugs–up to 166,000 of them–and you can see how unreasonable and impractical this is.

THE COMPLEXITY OF CONNECTIONS MUST BE MINIMIZED

A single AS2 connection is not overly complex as long as you understand the technology and make an investment in the right software to handle it for you.  Once you have the software, a few dozen connections are reasonable to deal with if you have an IT person who can handle their setup and maintenance.  Setting up and maintaining a thousand AS2 connections would be a major complexity.  Clearly, any viable U.S. pedigree model must keep the number of AS2 connections that any given company must deal with to a minimum.

DPMS does a better job of minimizing the number of AS2 connections than a distributed pedigree model based on EPCIS.  The Centralized model would limit the number to just one per company regardless of supply chain segment, and the Semi-Centralized model could also limit the number to just one per company if a connection service provider is used.

A POSSIBLE ALTERNATE APPROACH

The reason AS2 connections are used in all of the pedigree models under discussion is that they all need a means to authenticate the sender and receiver of the pedigree messages/data.  EPCIS “events” are nothing more than XML documents that conform to the GS1 EPCIS specification.  These XML document have no protective mechanism that prevents them from being modified without detection along the way from point A to point B.  AS2 provides that protection.  Any model that relies on EPCIS event exchange or posting to a repository absolutely must make use of AS2, or something equivalent, to transport the data.

DPMS pedigree documents are also XML documents that follow the GS1 Ratified Pedigree specification, but that specification requires the pedigree information to be wrapped, within the document itself, with digital signatures as the way of protecting them from undetected modification during transmission.  These signatures also give pedigrees of this type the property of “non-repudiation”, which means that the author cannot deny that they generated or updated them.

The net effect of these digital signatures in DPMS pedigrees is that it is not absolutely necessary that they be transmitted via AS2.  In fact, DPMS pedigrees are self-secure.  You could hand over a DPMS pedigree on a thumb-drive directly to a known criminal and let them hand deliver it to a buyer of drugs a week later, and still trust that the buyer could easily determine that the pedigree was either still untouched and valid, or tampered with and therefore not valid.

So to reduce the complexity of all those connections, perhaps what we should be working on is a way of transmitting DPMS pedigrees without using AS2.

How about sending them as simple email attachments?  Email is a simple point-to-point transmission of data that is fairly reliable these days, as long as you don’t need any significant security.  Since DPMS pedigrees are already self-secure, it seems like an almost natural fit.  You would never want to do that with EPCIS events because they are not self-secure, and there’s one of the differences between the two types of models.

But there’s a problem with this approach.  DPMS pedigrees, while self-secure against undetectable tampering and repudiation, are not encrypted, so the criminal in my example above would be able to read the Standardized Numeric Identifiers (SNI’s) included in the pedigree.  That would allow the criminal to generate counterfeit product that use the same SNI’s that are known to be real.  That’s one step that makes a lot of people uncomfortable.

Encryption is another optional feature of AS2.  Email attachments can optionally be encrypted too.  Unfortunately encryption of data in email requires the exchange of digital “keys” in advance of transmission just like AS2.  Encrypting the DPMS attachments in email would require something akin to the setup and maintenance of an AS2 connection.  So this approach to eliminating the use of AS2 in the DPMS model probably won’t work.

Do you see any solution to massive number of AS2 connections that would be necessary in a distributed pedigree approach?  Without a solution, the Centralized, Semi-Centralized and even DPMS models look more practical.  Submit a comment below.

Dirk.

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

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

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

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

THE CENTRALIZED TRACK & TRACE MODEL

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

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

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

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

THE DISTRIBUTED TRACK & TRACE MODEL

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

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

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

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

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

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

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

Here is my depiction of that situation.

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

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

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

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

THE SEMI-CENTRALIZED TRACK & TRACE MODEL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dirk.

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

The California Law is fairly clear that the pedigree must contain, “A certification under penalty of perjury from a responsible party of the source of the dangerous drug that the information contained in the pedigree is true and accurate.”  And that, among a list of other things, it must include “…the name and address of each person certifying delivery or receipt of the dangerous drug.”

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

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

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

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

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

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

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

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

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

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

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

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

WHY IS ‘NON-REPUDIATION’ SO IMPORTANT?

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

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

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

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

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

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

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

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

WHERE TO WE GO FROM HERE?

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

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

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

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

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

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

THE GS1 HEALTHCARE US 2015 READINESS PROGRAM

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

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

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

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

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

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

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

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

SO WHAT’S THE PROBLEM?

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

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

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

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

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

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

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

ASK THESE QUESTIONS

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

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

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

MY VIEW OF THE SITUATION

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

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

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