The California ePedigree law goes into effect for manufacturers in 2015/2016.  In mid-2016 distributors and repackagers will need to comply.  The California pedigree law includes the need for manufacturers and repackagers to serialize drugs at the smallest level of distribution to pharmacies.  That’s just one of the requirements, they also need to make reference to those serial numbers in the ePedigrees that they create (manufacturers) or update (repackagers, distributors and pharmacies).  (For more on the full pedigree regulation see my essays “The California Pedigree Law” and “California Pedigree Law:  Historic Change To Commerce”).  The implications of this to repackagers are unique.  Let’s explore why.

REPACKAGING TODAY—PRE-SERIALIZATION REGULATIONS

Today companies who repackage pharmaceuticals for the U.S. market do a wide variety of repackaging operations to fill an even wider number of needs for the industry.  (This essay is not about repackaging in other countries which is often done for other reasons including localization of label language, numbering and other regulatory requirements.)  These may include:

• One-to-Multiple
  Spread the contents of larger quantity manufacturer packages to smaller quantity repackaged packs.  An example is the repackaging of 1000-count bottles into 30-count bottles (33.33 output bottles per input bottle in this instance).
• Multiple-to-One
  Combine multiple smaller quantity manufacturer packages into larger quantity repackaged packs.  An example is the repackaging of 30-count bottles into 1000-count bottles (33.33 input bottles per output bottle in this instance).
• Multiple-to-Multiple
  Combine the contents of multiple manufacturer packages into multiple repackaged packs.  This scenario occurs whenever a repackager makes use of a hopper, filler bowl or automatic bulk dispenser of some kind.  Multiple manufacturer packages of a given drug are emptied into the hopper/bowl/dispenser before the first output package is filled and the hopper/bowl/dispenser is repeatedly replenished to maintain a supply buffer as the dispensing process proceeds.
• Unit-Dose
  Spread the contents of a multi-dose manufacturer package into single-dose packages.
• Convenience kits
  Construct kits that include smaller quantities of drugs (and often one or more “devices”) than the manufacturer packaged for individual sale.

I’m not going to go into detail about why every one of these repackaging operations are done but in general they are done for the convenience of various kinds of pharmacies or clinical dispensaries.

Today, the FDA regulates repackagers very much like they regulate the packaging operations of original drug manufacturers.  There are special regulatory provisions for dealing with lot/batch (input and output) and expiration dates.  All of that is beyond the scope of this essay.

In 2006 the FDA issued a proposed rule which, among other things, if adopted into an FDA Final Rule would require repackagers to apply for their own FDA Labeler Code and use it to create and “list” their own National Drug Codes (NDCs) to identify the output packages of their repackaging operations.  Up to that time it had been common practice for repackagers to mark their output packages with the same NDC as one of the original manufacturer’s original packages.

That resulted in confusion over who “owned” the NDC and the resulting GTINs that were based on the NDC and who had the right to apply it to their packaging (see my essay “Depicting An NDC Within A GTIN“).   It sometimes resulted in confusion over the “Package Size” field of the NDC whenever the repackaging operation resulted in an output package that was a size that the original manufacturer did not make.  It also seemed to defeat the apparent purpose of the “Labeler Code” portion of the NDC which seems to imply that it identifies the entity who “labeled” the product, not necessarily the manufacturer of the drug itself (see my essay “Anatomy Of The National Drug Code“).

The proposed rule was used to collect input from the industry and interested parties.  As far as I can tell the proposed rule has not yet become an FDA Final Rule and so it cannot yet be enforced, but it has apparently caused some (perhaps many) repackagers to start complying with the potential regulation even before it is made final.  These companies have decided to list and mark their repackaged drugs with their own NDCs rather than those of the original manufacturer of the drug.  On the other hand, once the patient receives the actual drug the repackager’s package has typically already been discarded and the NDC of the actual dose will now indicate that of the repackager instead of the manufacturer of the drug itself.  It seems like that might cause its own confusion at certain times.

REPACKAGING DRUGS UNDER A SERIALIZATION REGULATION

The California pedigree law contains the following references to drug repackagers:

Section 4034 of the California Business and Professions Code “(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.”

Question 50 of the “Questions And Answers Relating To The California Electronic Prescription Drug Pedigree Law(s)” published in draft form by the California Board of Pharmacy in January 2008 says:

“Q50 What are California’s definitions of ‘manufacturer’ and ‘wholesaler’?

For the purposes of prescription drugs or devices, California law defines a ‘manufacturer’ as any person who prepares, derives, produces, compounds, or repackages any drug or device except a pharmacy that manufactures on the immediate premises where the drug or device is sold to the ultimate consumer. (B&P § 4033(a), (b), (c); see also H&S § 109970.) A ‘wholesaler’ is any person who acts as a wholesale merchant, broker, jobber, customs broker, reverse distributor, agent, or a nonresident wholesaler, who sells for resale, or negotiates for distribution, or takes possession of, any dangerous drug or device. (B&P § 4043(a).)”

Question 58 is particularly pertinent:

“Q58 What is the role of a repackager with regard to receipt and generation of pedigrees?

In California, an entity that repackages prescription drugs is licensed as a manufacturer. (B&P § 4033(a); H&S § 109970.) When a drug is repackaged, it may typically (but not always) acquire a new National Drug Code (NDC) number, a new lot number and perhaps a new expiration date. 

The pedigree law mandates that 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 NDC number. (B&P § 4034(c).) 

Accordingly, the repackager must receive (from the manufacturer, wholesaler, or other source of the drug) a pedigree with the prescription drug documenting all transactions resulting in a change of ownership up through receipt by the repackager, and all of the new pedigree information (e.g., new NDC number, etc.) must be documented on the original pedigree, certified under penalty of perjury, and passed on/ continue with the newly repackaged prescription drug.

The board is interested in further data and information on the repackaging industry, particularly on the topic of compliance with the requirement of maintenance of a single pedigree.”

The Q&A document was published in January of 2008, but in the fall of 2008 the California Legislature passed the Ridley-Thomas bill (SB 1307) that, among a few other things, set the current enforcement schedule.  While the California Business and Professions Code, as quoted above, defines a drug repackager as a drug manufacturer, the enforcement schedule enacted in the Ridley-Thomas bill explicitly sets the enforcement time for repackagers to be the same as the distributors:  six months after the last date for compliance by manufacturers.  This makes sense because repackagers can only comply with the regulations if they are able to receive valid pedigrees with the serialized drugs they purchase for repackaging.  The six month delay gives repackagers the time necessary to obtain drugs that are serialized and pedigreed from the manufacturers before they are required to comply.

There is some confusion in the industry about how to link the NDC and serial number of the repackaged drugs with the original manufacturer’s NDC and serial number on the source drug packages.  This linkage cannot be done within an RFID tag or a barcode.  That’s because these data carriers are not “the pedigree”.  The linkage can only be done properly within the external electronic pedigree itself.  For example, the GS1 Drug Pedigree Messaging Standard (DPMS) includes a repackaging pedigree layer with all of the data fields necessary to link these NDCs and serial numbers.

By the way, for those of you counting the ways that GS1’s Electronic Product Code Information Services (EPCIS) standard alone won’t work for compliance with the California pedigree law, here’s another one.  There is currently no standard way to link incoming package EPC’s to outgoing repackaged EPC’s on drugs using that standard.  There has been talk behind the scenes but nothing has been published in a standard or even otherwise.  (See my earlier essays “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 1” and “Part 2”.)

HOPPERS, FILLER BOWLS AND BULK DISPENSERS MAY BE PROBLEMATIC

The use of hoppers, filler bowls or automatic bulk dispensers in the Multiple-to-Multiple repackaging scenario may be problematic under a serialization regulation.  The need to link the original manufacturer’s NDC and serial number to the repackager’s NDC and serial number becomes complex when exact boundaries of input packages to output packages cannot realistically be determined.  The hopper/bowl/dispenser acts as a buffer so that the operation can be done at high speed.  But this is exactly what causes the package boundaries to be indeterminable.  Drugs from multiple input packages can mix and intermingle with those of other input packages before a unique mix is deposited into the output packages.

The problem is, which input package serial number(s) do you link to a give output package serial number?

One possible solution to this problem is to link all input package serial numbers that have been placed into the hopper/bowl/dispenser prior to each output package being filled.  Those serial numbers would represent every possible input package up to the moment that an output package is filled.  Each successive output package would end up being linked to more and more input packages to the point where the last package filled by the hopper/bowl/dispenser would be linked to every single input package that had been deposited into it.

That might be a lot of packages, and correspondingly, a lot of serial numbers.  As long as all of those input packages share the identical pedigree it might not be too bad, but if every input package has a different pedigree, the resulting output pedigrees could get very complex.  In fact, I’m not even sure at this moment if DPMS can properly document that complexity.

Hoppers, filler bowls and automatic bulk dispensers are critical to a significant portion of the repackaging business of most repackagers.  If they can’t use those components under a serialization regulation it would significantly change their business formula.  Fortunately it appears that the California Board of Pharmacy recognizes issues like this.  Note the last sentence in the answer to Question 58 above.  Repackagers should take advantage of that invitation and work with the board to work out this and any other issues before the regulation goes into effect.

THE FDA AND REPACKAGING USING SNI

Ordinarily the non-binding FDA guidance on Standardized Numeric Identifiers (SNI) wouldn’t offer any particular guidance on compliance with a California state law, but the SNI guidance document contains a very logical example of repackaging that I think certain repackagers should pay close attention to.  Here is the example:

“…For the purpose of this guidance, FDA considers the prescription drug package to be the smallest unit placed into interstate commerce by the manufacturer or the repackager that is intended by that manufacturer or repackager, as applicable, for individual sale to the pharmacy or other dispenser of the drug product. Evidence that a unit is intended for individual sale, and thus constitutes a separate ‘package’ for purposes of this guidance, would include the package being accompanied by labeling intended to be sufficient to permit its individual distribution. For example, if a manufacturer’s smallest unit of sale package is a container holding six drug-filled syringes, a single SNI would be the package-level identifier for the container holding the six drug-filled syringes; there would be no SNIs for the individual syringes, not intended by the manufacturer for individual sale. If a repackager then breaks that container down and repackages each syringe for individual sale, then the repackager must ensure that appropriate labeling accompanies each individual syringe and a new and unique SNI would be the package-level identifier for each individual syringe and a new and unique SNI would be the package-level identifier for each new package (e.g., each individual drug-filled syringe). SNIs applied to each new package by the repackager are to be linked back to the manufacturer’s SNI for the container of six drug-filled syringes (505D(b)(2)). …”

This example may be very instructive for repackagers who perform this specific type of unit-dose repackaging.  This may include companies who are in the business of building emergency response kits for dental and doctor’s offices.  These kits are commonly composed of single doses of various medications (like Epinephrine, Atropine and Solumedrol injections for example) that are most often needed for unexpected reactions by patients in those kind of offices.

Like the FDA’s example, the drugs included in these kits are normally sold by the original manufacturers in multi-packs that are meant by them to be the smallest unit of sale so the single-dose form doesn’t always have a specific NDC.  The single-dose form is also not packaged by the original manufacturer for distribution or sale.  These kit-makers break those multi-packs down further into the single-doses and package them into their kits.

For the purposes of the FDA SNI guidance, these companies appear to be acting as a repackager of unit-dose medication and, to properly follow the guidance, they may want to apply their own NDC to each single-dose unit and serialize them using the sNDC approach defined in that document (see my recent essay “Anatomy Of An FDA SNI”).  Applied to California, the sNDC’s on the single-dose packages could then easily be linked to the sNDC of the manufacturer’s multi-pack in the electronic pedigree.

Does the FDA SNI guidance example offer any good advice for repackagers to help them know how to comply with California?  Is the example in the FDA SNI guidance the only way for these companies to comply with the California pedigree law?  I don’t know.  Companies should review the source material, check with the California Board of Pharmacy and draw their own conclusions, but the example seems to make a lot of sense.

If you can think of other implications of the California pedigree law that are unique to repackagers leave a comment and share your thoughts.

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

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

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

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

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

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

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

A FEW QUESTIONS

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

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

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

Some of the questions are:

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

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

Dirk.

One of the most recent improvements that California made to their drug pedigree law was to spread out the compliance dates by supply chain segment.   Previously, all segments had to comply with the regulation by January 2011.   Now drug manufacturers will need to comply with half of the products (or sales) by January 2015 and the remainder one year later, distributors must comply by mid-2016 and the pharmacies by mid-2017.   As I understand it, this spread was intended to help the industry fully prepare for the new requirements in their businesses.   Companies would now have time to adjust to the changes implemented by their upstream trading partners according to their earlier deadlines.

This staggered start pleased a lot of people—particularly distributors and pharmacies.   However, to me, the staggered start of the current California regulation doesn’t address the issue of complexity very well and a different kind of ramp up to full operation would be more practical and have better odds for success.

I discussed complexity in my last essay, “U.S. Pharma Supply Chain Complexity”.   I tried to show what it is about the supply chain that leads to difficulty in the setup and execution of a drug pedigree system.   On its own, the U.S. pharma supply chain is naturally complex.   A truly workable and protective pedigree system needs to deal with that natural complexity without exploding in its own complexity and cost.   As I pointed out in that essay, the problem with the more popular pedigree models (like DPMS and the various distributed pedigree models) is the large number of the point-to-point data connections that are necessary to reflect the natural complexity of the supply chain.   That adds a lot of complexity.

THE PLATEAUS OF SECURITY

No matter which model the industry implements, starting it up will have its own complexities.   In my view, regulators and industry should define a clear endpoint for whatever track & trace and/or pedigree model is selected, but they should establish a roadmap to achieve that endpoint over a period of years using what I call “plateaus of security”.   The point of using this approach is to help the industry take smaller steps on its way toward the ultimate goal of a fully operational system.

Unlike the staggered start dates for each segment that currently exists, the plateaus approach would require all segments to add some capability and functionality at each plateau.   Plateaus would be staggered across a number of years so that all companies could spread the costs of their deployments over a number of budget cycles and they would have time to adjust to each increment of new functional and process complexity until the ultimate goal is reached.

There are many ways one could divide the full adoption of a track & trace / pedigree system across a number of years.   Some ways might vary depending on the model selected.   To illustrate the concept, here is one way it might be done.   I’m not saying this is the best way to do it—that should be worked out between the industry and the regulators.  The dates are purely illustrative.

PLATEAU 1.   SERIALIZATION, 2016

In this first plateau, pharma manufacturers would be required to put Standardized Numeric Identifiers (SNI’s) on all unit-level packages of prescription drugs, but they wouldn’t need to serialize cases and they wouldn’t need to generate any aggregation information.   All downstream trading partners would be required to begin reading the unit-level SNI’s and keep track locally of the information about them (received from, shipped to, etc.) but only if the units are removed from their cases as part of a normal business process.   Units received and shipped without being removed from cases would not be read or documented.

PLATEAU 2.   SNI AUTHENTICATION, 2018

In this plateau, pharma manufacturers would need to write simple records that define the SNI’s (GS1 EPCIS Commission events perhaps) into a secure data repository that is accessible securely through web access by downstream members of the supply chain.   Starting in this plateau, those downstream members would be required to make a web service call whenever they remove units from their manufacturer-packed cases, or when receiving units not packed in a manufacturer’s case.   The web service call would simply authenticate that the SNI is valid, return that information to the caller and record which company did the asking.   This is a big step because it requires the industry to create new large, secure data repositories and make a bunch of connections.   Which model the industry decides to implement would determine how complex this part would be.

PLATEAU 3.   AGGREGATION, 2019

In this plateau, manufacturers would be required to serialized shipping cases and document the containment hierarchy of the unit-level SNI’s in each case.   Distributors would need to do the same for containers (totes, boxes, etc.) that they ship drugs in.   Containment information would need to be passed, or otherwise made available (depending on the model selected) to the next downstream buyer of the drugs.   Distributors who sell full manufacturer-packed cases would need to pass, or make available (depending on the model), the manufacturer supplied aggregation information to their customer.

Downstream members of the supply chain would need to read the case/tote serial numbers and may use the supplied aggregation information to “infer” the unit-level SNI’s in their shipping and receiving operations.   Whenever units would be unpacked from these shipping containers in any business process the current owner would need to continue to authenticate them using the service established in Plateau 2 and confirm the aggregation against the information supplied by the upstream trading partner.

Aggregation errors would need to be reported back upstream through each prior owner to the company who originally established the aggregation.   That company would need to reply, indicating if the discrepancy indicates a potential security breach, or a simple error.   Errors would not impede the ability of the current owner to sell the product forward in the supply chain.   Of course, those units involved in a potential security breach would need to be quarantined until the issue has been investigated and resolved.

PLATEAU 4.   FULL PEDIGREE AND SUPPLY CHAIN TRANSACTION AUTHENTICATION, 2021

In this plateau, all trading partners would be required to update an electronic pedigree or a secure track & trace data repository whenever drugs are bought and sold.   Inference would continue to be used in the way described in Plateau 3.   All previous supply chain transactions would be checked whenever each drug is bought from an upstream trading partner, whether this check is performed by the buying company or by a contracted third-party (which depends on the model selected).   Drugs with incomplete histories would have to be refused by the buyer unless the seller could correct the deficiency.

HOW SHOULD WE MEASURE SUCCESS

Success in any pedigree or track & trace system intended to protect patients and the supply chain should be measured by the following outcomes:

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

Measured this way, I believe that it is possible to achieve a high level of success.   The first step is to select the industry model that has the right balance of complexity/cost and risk.   The second step is to define an adoption/deployment roadmap that provides a smooth on-ramp to the full system for the entire industry.   Failure in either step will likely result in a failed system.

Dirk.

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

Trust plays a big role in today’s U.S. pharmaceutical supply chain.  Patients trust that their doctors know what they are doing when they prescribe a medicine and they trust their pharmacist to fill their prescriptions with real medicines that were:

• manufactured to tight quality specifications,
• are well within the expiration date,
• have not been tampered with,
• have always been kept within recommended environmental tolerances,
• and have been in the control of companies who have a strong interest in supply chain integrity and in the safety of the drugs within the supply chain.

When we receive our little amber bottles of repackaged drugs from our pharmacist, we aren’t given any way to check on any of those things ourselves.  We trust that the pharmacy has done something to ensure all that.  And fortunately in the U.S., we are almost always justified in that trust.  We enjoy the safest supply chain in the world.

A WHOLE LOT O’ TRUSTIN’ GOIN’ ON

But, now if the pharmacy doesn’t get the drugs directly from the manufacturer, they trust that their wholesaler will supply them with drugs that have those characteristics too.  And if the pharmacy’s wholesaler doesn’t get the drugs directly from the manufacturer, they trust that their wholesaler’s wholesaler provides them with drugs like that too.  And if the pharmacy’s wholesaler’s wholesaler doesn’t get the drugs directly from the manufacturer, they trust that their wholesaler’s wholesaler’s wholesaler provides drugs like that too.  And so on up the supply chain until we reach the manufacturer.

“But wait a minute”, you say, “That’s a lot of trust built on top of trust.  Is that really safe?

I’m not trying to alarm you.  Please keep in mind that the vast majority of all drugs sold in the U.S. pass through only one wholesaler on its way from the manufacturer to your pharmacy.  Only a very tiny fraction of the drugs pass through more than one wholesaler.  But, for example, in the case that I dissected last week in “Lessons from “Drug Theft Goes Big”, based on the Fortune Magazine article “Drug Theft Goes Big” by investigative reporter Katherine Eban, there are—very rarely—occasions when drugs that are sold by reputable pharmacies allegedly may have passed through criminal hands on their way through the supply chain.  In these very rare cases, the whole trust-thing collapses and bad things can result.

THE “CHAIN OF TRUST” IN THE PHARMA SUPPLY CHAIN

Here is how the “chain of trust” worked in Eban’s story.  First, the pharmacy, Ph, had no means to see who had owned the drugs prior to their wholesaler, W1, so they trusted that the drugs were legitimate.

According to Eban’s story, W1 was allegedly given a pedigree by their wholesaler, W2, so rather than blindly trusting that the drugs were legitimate, they instead trusted that the pedigree they were given was legitimate.  But, unfortunately, it was allegedly forged, and because W1 had no efficient way to verify the authenticity of the pedigree they were allegedly given, all the pedigree did in reality was to remove suspicion and doubt from W2.  So in effect, W1 blindly trusted W2 because they blindly trusted the pedigree they were allegedly given.

I think the alleged forged pedigree that W2 allegedly passed to W1 will turn out to be the “smoking gun” that implicates W2, but we’ll have to see how it turns out in court.  So for now, I’ll ignore it and just say that W2 had no accurate means to see who had owned the drugs prior to their wholesaler, W3, so they trusted that the drugs were legitimate.  But, AH HA!, now we see that W3 allegedly acquired the drugs from someone who was either a thief, or who themselves acquired them from a thief.  The drugs allegedly matched those that had been stolen a few weeks before and only 150 miles away…allegedly.

This appears to be a case where the “chain of trust” collapsed because criminals exploited it.

THE “ONE UP, ONE DOWN” SUPPLY CHAIN VISIBILITY MODEL

The supply chain visibility model that is in use here, and throughout the supply chain today, is what is known as the “one up, one down” model.  Each trading partner can tell you where they acquired the drugs (one up) and where they sold them (one down).  For example, W1 can report that they bought the drugs from W2 (one up), and they sold the drugs to Ph (one down).  That’s it.  That’s all they can tell you.

Now someday, once all drugs are serialized at the unit level, this “one up, one down” visibility model may appear to be safer than in today’s non-serialized supply chain, but in reality it will just be easier to keep track of “one up, one down” accurately.  It wouldn’t have allowed W1 to know anything more about the legitimacy of the drugs in their possession.  They would still need to trust that they are legitimate.

The “one up, one down” visibility model relies totally on the “chain of trust” because it doesn’t provide any way for buyers to check the full supply chain history of the drugs they buy.  They are forced to trust their supplier.  But in reality, it isn’t a “chain of trust”, rather, it is a “chain of blind trust”!

No!  In fact, it is a “chain of blindness”.  Each trading partner is blind to where the drugs came from prior to their immediate supplier.  The “one up, one down” visibility model is not a “visibility” model at all.  It simply describes everything that today’s supply chain participants know about their drug supply and nothing more.  Not much is really visible, and in these rare cases, what is visible is insufficient to tell if the drugs are legitimate or not.

THE ULTIMATE GOAL:  AUTOMATED SUPPLY CHAIN UPSTREAM VISIBILITY

One way to build a true chain of trust and significantly decrease the ability for criminals to hide within the supply chain is to eliminate the blindness in the trust relationships.  This can be done by providing full upstream visibility of supply chain history to each participant (or to their contractual agent).  That way each buyer of drugs can see everyone who has owned the drugs they are about to buy.  In short, trust, but verify.

With unit-level serialization this could happen automatically before the drugs arrive at each stop.  Any discrepancy or unexpected aberration in the supply chain history would be exposed and that would inform the buyer who could then refuse to accept the shipment.  Of course, the concept that would enable this is electronic pedigree, whether implemented with something like the GS1 Drug Pedigree Messaging Standard (DPMS) or with a Network Centric ePedigree (NCeP) architecture like the one that GS1 is currently working on.

BUT A “BIG BANG” APPROACH ISN’T REALISTIC

As you all know, I’m a big fan of the electronic pedigree concept because of its ability to remove the blindness that exists in today’s supply chain.  But I’ve recently become convinced that neither DPMS nor an NCeP can be deployed throughout the entire supply chain in a “big-bang” approach within the timetable of the California Pedigree law.  They are too complicated.

Fully automated supply chain upstream visibility must be the ultimate goal, to be sure, but the job is just too big and complex to be achievable by every company in the supply chain, big and small, by 2015-2017.  I now think what we need is a phased approach that has a series of security “plateaus”, but which eventually gets us to the ultimate goal.  Others have been saying mostly the same thing for some time now.  I finally get it…and, I think I can explain it.

I’ll have more to say about this over the next few months, including my idea of a realistic roadmap and timeline.  Please stay tuned.

Dirk.

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

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

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

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

THE ATTRIBUTES 

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

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

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

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

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

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

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

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

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

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

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

Digital electronic messages can be transmitted from one party to another using a wide range of communications technologies.  Today, businesses that make use of the internet to transmit their business messages to and from their trading partners make use of standards-based Electronic Data Interchange (EDI) message formatting. 

EDI messages are typically transmitted point-to-point, from one business to one other business.  There are a large number of EDI message types defined but in the pharmaceutical supply chain the most common messages are purchase orders, purchase order acknowledgments, invoices and advance shipment notices (ASN’s).  (While I have the chance, I’d like to point out that ASN’s are not pedigrees for multiple reasons that I will not cover in this essay.)

In the U.S. pharma supply chain AS2 is the most common communications protocol in use for EDI message exchange.  AS2 provides generalized message security to ensure that the messages cannot be understood or tampered with by unauthorized parties during movement from sender to recipient.  According to Wikipedia, these are achieved through the use of digital certificates and encryption.  Messages can optionally be digitally signed by the sender to provide non-repudiation within the AS2 payload context.

Electronic pedigrees as defined by the states of Florida and California are messages that contain fairly complex legal documentation which describe the chain of custody or ownership of a given package of drugs, but they also contain several types of legally required certifications.  I’ve written about these certifications in the past (see “Certifications In A California-Compliant Drug Pedigree” and “Digital Signatures”) and I have more to say about them below.

Electronic pedigree messages need to be transmitted from point-to-point over the internet just like traditional EDI documents and so they have the same need for secure transmission.  In fact, AS2 is one of the protocols that has been used for transmission of pedigrees that take the form of GS1 Drug Pedigree Messaging Standard (DPMS) documents.  AS2 is also one of the protocols specified for business to business exchange of GS1 Electronic Product Code Information Services (EPCIS) events which may someday be used as components of electronic pedigrees. 

In RxTrace I usually discuss the kind of digital electronic messages that contain drug pedigree information, but in reality, almost any digital electronic business-to-business messages could have needs that are similar to pedigrees.  In this essay I want to take a closer look at the certification requirements and discuss some of the technical implications that result. 

WHAT IS A “CERTIFICATION”? 

The Merriam-Webster dictionary defines the word “certification” this way:

cer·ti·fi·ca·tion  noun \ˌsər-tə-fə-ˈkā-shən\

1. the act of certifying : the state of being certified
2. a certified statement

 It defines the word “certify” this way:

cer·ti·fy  verb \ˈsər-tə-ˌfī\

1. to attest authoritatively: as
   1. confirm
   2. to present in formal communication
   3. to attest as being true or as represented or as meeting a standard
   4. to attest officially to the insanity of
2. to inform with certainty : assure
3. to guarantee (a personal check) as to signature and amount by so indicating on the face
4. to recognize as having met special qualifications (as of a governmental agency or professional board) within a field <agencies that certify teachers>

If these words are specifically defined in the California statues I haven’t been able to find them, so when those words are used in their pedigree regulations and the Board of Pharmacy’s document, “QUESTIONS AND ANSWERS RELATING TO THE CALIFORNIA ELECTRONIC PRESCRIPTION DRUG PEDIGREE LAW(S)”, I think the first definition of “certification” and definition 1.3 for “certify” are the what they mean.  I’ve bolded those definitions above.  Let me know in a comment if you disagree with my choice. 

The dictionary definitions above strongly imply that it is a person or organization that is doing the certifying.  For that reason, for a certification to be performed, it must be bound to the person or organization that is executing it.  

The California law says that each owner of a drug must include in the pedigree for that drug “A certification under penalty of perjury…that the information contained in the pedigree is true and accurate.”  Pedigrees must also include “…the name and address of each person certifying delivery or receipt of the…drug.” 

These appear to be two different kinds of certifications.  The first is certifying that “the information contained in the pedigree” is “true and accurate”.  The second is certifying the “delivery or receipt of the drug”.  It’s an open question if these two or three certifications per owner can be combined into the execution of a single technical certification. 

HOW DOES DPMS IMPLEMENT THESE CERTIFICATIONS? 

In DPMS pedigrees, certifications are implemented through the use of digital signatures that use X509 certificates to bind the identity of a person or organization as the “signer” to a given range of data within the pedigree message.  These digital signatures provide non-repudiability of the signer’s identity and they break the signature if someone later modifies the portion of the pedigree that was signed.  X509 also defines a way to revoke the authorization of a certificate holder to sign future pedigrees. 

DPMS requires the signer to identify the “signatureMeaning” of the digital signature they are applying.  This “signatureMeaning” is the magical element that converts digital signatures in DPMS pedigrees from a collection of data that simply identifies the signer and associates him/her/it with a range of chain-of-custody/-ownership data, into the true “certification” of the target range of data that is being signed by the signer.  The “signatureMeaning” provides context to the signature by allowing the signer to clearly indicate their intent when they apply their signature.  In DPMS the “signatureMeaning” may be one of the following values (this list is extendible): 

• “Certified”  when certifying the content added to a pedigree
• “Received” use by recipient after receiving the item against the pedigree
• “Authenticated” used by recipient after successfully authenticating the pedigree
• “Received and Authenticated” used by the recipient after successfully authenticating a pedigree and receiving the item against the pedigree 

HOW CAN CERTIFICATIONS BE APPLIED TO A COLLECTION OF EPCIS EVENTS? 

That’s the million dollar question—one that has stopped efforts to move forward with an EPCIS-only pedigree solution in the past.  The question remains unanswered.  Fortunately there is another group of very bright people who are now working to answer the question.  DPMS can be used as a reference model but the goal of this group is not to simply recreate DPMS using EPCIS events.  The use of digital signatures in DPMS is the thing that is most often cited as the reason people wish to look for an alternate solution to the pedigree regulations.  

But to implement an acceptable certification without using digital signatures is a tall order.  You will need to come up with some way to clearly document the identity of the individual or organization (and provide non-repudiation of it) and then bind them to the set of events that describe the part of the pedigree that they need to certify.  Of course, once certified the certifier will demand that the set of events they just certified cannot be modified in any way without breaking their certification.  Otherwise they could be held legally liable for a change to the events that they did not authorize. 

So let’s see.  The certification will need to… 

1. Provide a mechanism to clearly document the certifier’s identity (with non-repudiation…and also with a way to revoke their authorization to certify),
2. Tightly bind the certifier to a specific set of EPCIS events, and
3. Prevent unauthorized modification of the same set of events.

Hmmm.  So far it sounds just like a digital signature to me.  Oh, but I need to add …

4.  Require less space overhead and less complexity than a digital signature.

I’m not saying it can’t be done.  Chances are you can do any two or three, but to do all four will be really hard.  In fact, if the group is successful it would mark a huge leap forward in digital technology and it would open doors to its use in many other types of legal documents and business transactions. 

For EPCIS-only to work as a pedigree system this problem will have to be solved.  Watch for the results of this effort in the next few years.

Ken Traub

Noted writer, editor, literary critic and teacher, William Zinsser, is known for the quote “writing is thinking on paper”.  Today I don’t think paper has much to do with it, but what I think he means is, the very process of writing something forces a person to think about the thing they are writing about, and then embody that thinking clearly in the written output (paper or electronic).  As you might imagine, I agree with this.  I like to write and I believe that my own experience with writing has greatly improved my thinking.  For a really great essay on the topic of writing and thinking, see The Secret About Writing That No One Has The Balls To Tell You by Pete Michaud…and don’t miss the many excellent comments below his essay.  

I’ve been writing about ideas surrounding my professional experience much longer than the year and a half I have been writing RxTrace.  In fact, I have written some pretty legendary emails and other essays over my career.  Legendary because they raised ideas that were either unpopular or otherwise not wanted by the recipient(s).  If you know me very well then chances are you’ve read one or two of those. 

In a previous job, I did a fair amount of technical writing including specifications, Request For Proposal (RFP) responses, proposals, user and technical manuals and program documentation.  I have also written a large amount of software during my career and I think that kind of “writing” definitely qualifies as “thinking”.  But RxTrace is my first experience with writing essays where my thinking is open to anonymous and public critical review.  That sharpens the mind even more.  

Because I like to write, I like to read thinking that others have written and I really like finding and meeting highly skilled writers/thinkers.  I’ve read Newsweek since my first year of college.  For two decades I read it cover-to-cover almost every week—that’s right, every article, column, essay and letter in almost every issue.  That’s 20 years times 52 magazines per year…1040 issues!  In recent years I’ve been too busy to read it cover-to-cover. 

Very recently I’ve started reading the Harvard Business Review magazine and their associated blogs which are both full of really great writing about ideas.  A lot of really great writer/thinkers have appeared in Newsweek and HBR magazines over the years I’ve been a subscriber and I like to think I’ve picked up a few things from them.  But, to paraphrase Pete Michaud and perhaps William Zinsser, reading is not thinking.  That is, reading is not enough.  To produce really new ideas, new perspectives and new thinking, one must write.

KEN TRAUB:  WRITER, THINKER 

Not long ago, my professional experience introduced me to the writing of Ken Traub.  The first time I read something that Ken wrote I knew I liked him without meeting him or even knowing who he was.  That was back in 2005 when the company I worked for at the time had issued an RFP for help with an RFID pilot.  ConnecTerra was one of the companies who submitted a response and I was very impressed with the quality of the writing.  It was written in exactly the same style that I had used in the years that I wrote many RFP responses while working for Professional Control Corporation (PCC).  It had just the right balance of technical and business information and it was very easy to understand.  Sadly, my company did not select ConnecTerra as the vendor at that time for reasons not related to their proposal, but the high quality of that proposal stuck in my mind as a missed opportunity to meet someone who thought and wrote as I did. 

Jumping ahead a year, while working on the GS1 EPCglobal Drug Pedigree Messaging Standard (DPMS), our team had an interest in creating a specification document that used the same style and approach that other good EPCglobal standards specifications had used.  Mark Frey, our excellent EPCglobal-assigned facilitator recommended the Tag Data Standard (TDS) and the Application Level Events (ALE) standard as examples of well-written specifications.  I think our Editor, Lucy Deus of SupplyScape (now TraceLink) did a fabulous job of replicating the style and structure of those two standards documents. 

As one of the co-chairs of the DPMS work group I also participated in the EPCglobal Software Action Group (SAG) co-chair’s work group, led at that time by Bryan Tracey, then with GlobeRanger, and Margaret Wasserman of ThingMagic.  It was on the calls for this group that I first encountered the voice of Ken Traub.  I remember being very impressed with the few comments he made about various forgotten issues that this group dealt with back then.  It seemed that whenever he spoke up, he always made really good points—down-to-earth, logical, clear and consistent.  When Ken spoke, there was rarely a need to challenge or follow-up.  He just always made sense. 

It wasn’t until one of the EPCglobal SAG face-to-face meetings in 2006 that I actually got a chance to meet Ken in person.  I remember chatting with him after being introduced by Bryan.  Ken explained that he had been one of the founders and the CIO of ConnecTerra before it had been acquired by BEA Systems in late 2005 (later BEA was acquired by Oracle).  I immediately made the connection.  Ken confirmed that he had been the author of the RFP response that had made such a positive impression on me the year before.  He had also served as the Lead Editor on both the TDS and ALE standards that we were using as good examples for the DPMS document. 

In addition to TDS and ALE, Ken was also the Lead Editor of the Electronic Product Code Information Services (EPCIS) standard, the Core Business Vocabulary (CBV) standard, a key member of the EPCglobal Architectural Review Committee (ARC) and a member of the EPCglobal Joint Strategy and Planning Committee.  More than any other one person, I think Ken is most responsible for the implementation of the EPCglobal architectural vision.  “Writing is thinking” indeed, and Ken is a perfect example of that.  (For a complete list of committees Ken has served on, as well as a complete career history, see  Ken’s professional website.)

When I worked for SupplyScape I had the pleasure of co-authoring a white paper with Ken, Combining EPCIS with the Drug Pedigree Messaging Standard, and participating in a two-part series of webinars on the same topic with him.  We contracted with Ken as part of that effort to help us fully understand the EPCIS standard and figure out how it could be used in a regulated pedigree context.  Ken filled the role perfectly and, while the conclusions were all made by us at SupplyScape, our work with Ken is what ensured that our conclusions and our proposal fit properly within the intent of EPCIS and within its technical context. 

More recently I have been involved in an EPCIS-based pilot with a major drug manufacturer who chose to retain Ken to help them understand EPCIS and the CBV and their application in drug serialization.  I have not been a direct party to their consulting sessions with Ken but I have benefitted indirectly from his counsel because this trading partner has made positive adjustments to our pilot as a result of Ken’s guidance. 

If you are an end-user who is trying to figure out how to invest in GS1 EPCglobal serialization standards-based systems, or if you are a developer of applications who needs to understand how to properly incorporate those same standards into new or existing products, or if you are a regulatory agency who needs to understand the realistic capabilities of those standards, then I strongly recommend that you talk with Ken about what he can do to help you. 

BTW, I feel very strongly about the exceptional quality that Ken delivers in all of his work so I feel very comfortable recommending him.  This recommendation was not solicited and I don’t have any business relationship with Ken.  This is what I believe. 

BLOGGING IS THINKING? 

My experience with Ken further strengthens the theory that “writing is thinking”.  He obviously likes to write, he’s really good at it and as a result, his great ideas are incorporated in GS1 EPCglobal’s standards.  GS1 is lucky to have his interest and his contribution.  The EPC architecture and standards are much better for it. 

So if  writing is thinking, and blogging is writing, then blogging must also be thinking.  I aspire to someday be in the same writing/thinking league as Ken.  And so I continue to think, and to write, and to blog.