Inspecting An Electronic Pedigree

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.

6 thoughts on “Inspecting An Electronic Pedigree”

  1. Wait, are you suggesting that the technology and business process wizards at the CA Board of Pharmacy haven’t thought the practical issues before pushing ahead with the law? I’m shocked! Shocked, I tell you!

  2. Excellent observations as usual. My concern lies in the intent of the pedigree system itself- patient safety and integrity of the chain of custody. To address your final point on compliance, in a distributed pedigree environment the same laptop and software could have the authority to query the said repositories for their event information and the receiver would merely provide the one back event that they were given which is essentially the pedigree they received. In this model, it is not the responsibility of the receiver (sadly) to know what happened two events prior. They infer that if it is now in the hands of a legit distributor, it is legit to receive. In this case the receiver is compliant- “here is the pedigree we received from a legitimate source” and the inspector has the ability to view/recreate/access the entire pedigree.

    My issue of a distributed pedigree system (despite discussions surrounding “trade secrets” for distributors as to movement of product and end clients within the channel) is that in the system as described, it works for the inspector but really doesn’t do anything for the chain of custody when malevolent parties are involved. If a printed version will be accepted, along the assumption that “somewhere” there is an electronic version, then we really haven’t moved the ball forward at all. Too many solutions are based on how the inspector can make sure we are compliant, rather than the other 99.9% of the real time issues which is how do we ensure that the industries pedigree system itself has the innate ability to police and identify inconsistencies long before an inspector arrives?

    It has long been my take that a barbell system of back end authentication as step 1 is a far better leaping point. It provides what we are truly concerned with, the authentic product that gets to the patient. From an industry standpoint, it also provides the infrastructure (individual item level serialization and decommissioning) to allow the parties that be to build and agree upon repositories/data sharing etc… over time without tabling or watering down the end value of product integrity and brand protection. The channel solutions for pedigree can be step 2 since the initial infrastructure would be in place. An arguement for another day.

  3. Dirk – I agree with your logic. The creation of an on-demand pedigree would not be an indicator of what may have been certified by a supply chain partner at the time of purchase and delivery. In my non-legal mind, that would only be achieved with memorialized documentation of something signed and certified upon receipt – otherwise, if corrupted there would be no way of determining where the breach occurred – in the supply chain, the seller or somewhere within the buyers operation. In other words, massive spend and complicated processes would have been for nothing.

    There are several disconnects between the law and anticipated practices – and, and this is a big and, we really need to keep our eye on the ball as you have, and remember why all this is supposed to happen in the first place.

    I continue to believe that an end point authentication system, such as proposed through GPhA (white paper on their web site) is the best possible answer at this time for the very reasons you cite.

    I believe that there are so many gaps in the rules with this version of track and trace that there will be many unanticipated consequences when this moves forward in 2015. Hopefully this can be averted and a model can be put in place that is simpler, less disruptive and provides a leap forward in patient safety.

    1. Brian and Micheal,
      Thanks for your great comments. In my essay from last June called “Plateaus of Pharma Supply Chain Security” I discussed an approach where the second plateau would be a model similar to the ones that you both seem to advocate. I also pointed out in a later essay, “SNI’s Are Not Enough In a Plateau-Based Supply Chain Security Approach” that you don’t have to finish the full set of plateaus unless you are forced to by criminals. I pointed out that in my earlier essay,

      “…I included illustrative dates for each of the four plateaus that I offered as an example of the concept, but you could easily imagine the overall program having open-ended dates that would allow the supply chain to adopt one plateau at a time and move to the next plateau only if/when a security problem is discovered at the current plateau. That is, jump to the next plateau only when necessary. Taking this approach, you may never actually need to get to the later plateaus.”

      The point is that if the Point of Dispense (PoD) authentication plateau (plateau #2) solves the security problem, stop there. Don’t force supply chain companies to deploy more technology than is necessary to solve the problem. If, after 10 years or so criminals figure out a way to game the technology in that plateau, then perhaps it’s time to move to the next plateau.

      But both of your comments seem to imply that we can still influence the design of the pedigree regulations. That may be true at the Federal goverment but the point of this essay is:

      – The California regulations already exist and changing them is unlikely;
      – We won’t be able to define the requests that regulators make during inspections;
      – More than likely, the inspectors will make requests that allow them to determine your compliance with the law;
      – My second hypothetical request in the essay tests compliance much better than the first request does;
      – The selection of the industry-wide pedigree model will determine which way companies will be able to respond to my second hypothetical request;
      – And finally, shouldn’t this logic be used to establish a boundary around the kinds of pedigree models that will enable compliance and box out those that cannot?

      In other words, when we find needed characteristics like this that certain models are fundamentally incapable of fulfilling, shouldn’t we drop those models from our list of potential solutions? Shouldn’t we at least stop promoting those models and encouraging investments in them?

      Thanks again for your thoughts.

      Dirk.

  4. Dirk:

    I’d like to address your question at the end:

    “In other words, when we find needed characteristics like this that certain models are fundamentally incapable of fulfilling, shouldn’t we drop those models from our list of potential solutions? Shouldn’t we at least stop promoting those models and encouraging investments in them?”

    We don’t drop models that don’t match the California regulations for three reasons.

    First, this type of regulation has always been governed by GxP. I believe that California attempted to write a law that allowed for GxP compliance in this instance but made their focus too narrow when crafting the law. That would explain why they themselves seem to be misinterpreting the wording of the regulation. That realization may, coupled with outside pressure from industry, cause them to reword the law to allow for compliance with the intent.

    Second, I think that with industry powers and international Traceability regulations moving away from the DPMS, there is a distinct possibility that the California law will be superseded to allow for the possibility of an authentication-based system. That could be a repealing the law (unlikely), a change in the deadline (increasingly likely), or a federal mandate that overrides the California regulation (more likely if the deadline is pushed back).

    The final reason is one of internal business value. With both DPMS and authenticated pedigree, you need to have (1) serialized product and (2) an electronic system. In my experience, the cost of creating serialized product is similar in both models. But the electronic system for DPMS is less costly than for authentication. You also miss out on several benefits, such as leveraging your system for internal tracking, up-to-the-minute inventory reporting, and a drive for creating an internally integrated electronic system.

    My company is aware of the pros and cons of both models. Every time the industry shifts and whenever a few months pass, we reexamine our risk assessment about the model we chose. I encourage all your readers to do the same.

    Pleasure reading your column,
    Scott

    1. Scott,
      Thanks for your response. It is perfectly fine for an individual company to adjust their preparations for known regulatory requirements in California based on their calculation that the regulation will change or be supplanted prior to its effective date. That’s a risk, but as long as the risk is taken with full knowledge, there is no harm. You may win, and you may lose with that strategy. We don’t know yet. The problem is that, in this case, the industry must ultimately adopt a single model so that everyone can interoperate efficiently.

      I suspect that we have until about the end of 2012—a little more than a year, give or take a few months—before it will be necessary for the industry to settle on a single model so that software products can be completed, sold, deployed, tested and made operational across the supply chain prior to the deadline. Something could certainly happen at the Federal level within that time, but California isn’t likely to change their law or their dates before then.

      If something occurs to change reality between now and then we will have to evaluate the new reality at that time to see which models might fit and which ones might not. Until then, I’m focusing on today’s reality.

      Dirk.

Comments are closed.