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