Archive for the ‘pedigree’ Category

If you are a regular reader of RxTrace but you still haven’t read Fortune Magazine’s recent article, “Drug Theft Goes Big” by Katherine Eban, then I suggest that you stop reading this essay right now and spend the next 15 minutes absorbing her article carefully.  And then return here for my analysis.  It’s that good and that important.

Many of you will remember Katherine Eban as the author of the excellent book “Dangerous Doses, A True Story of Cops, Counterfeiters and the Contamination of America’s Drug Supply”.  See my comments on the book here where I point out that a lot has changed since the events that are documented so well in the book.

The new Fortune article is a great update on what drug supply chain criminals have been up to since “Dangerous Doses” was published back in 2005.  The greatest thing about the article is Read the rest of this entry »

Four years ago the GS1 EPCglobal Software Action Group (SAG) Drug Pedigree Messaging Work Group was wrapping up the standard specification for the GS1 Drug Pedigree Messaging Standard (DPMS, aka GS1 Pedigree Ratified Standard).  That standard was developed through collaboration between U.S. pharmaceutical supply chain members, industry associations, solution providers and GS1.  DPMS 1.0 was ratified by the EPCglobal Board in early January 2007.

DPMS has many benefits.  It results in a self-contained, self-secure electronic document that clearly shows the chain of ownership and/or custody of a given drug package (or a set of packages if they all have the same history).  It works equally well with serialized and non-serialized products.  The security of DMPS documents comes from within the electronic documents themselves rather than just from a security layer wrapped around a given server.  A self-contained, self-secure document model should work well as evidence in a criminal trial.

But even before DPMS was ratified people were raising questions and concerns about it.  Those concerns were Read the rest of this entry »

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

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

GLN’s On Electronic Invoices

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

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

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

The original California Pedigree Law was passed back in 2004 and it was subsequently modified by the State Legislature in 2006 and again in 2008. In all three instances, I understand that members of the legislature and the Governor’s office worked closely with the State Board of Pharmacy to develop the final content and language.

I heard that one of the goals was to create a better law than the one in Florida. Did they succeed? In order to find out, let’s take a closer look at how they compare.

The law that is currently on the books in California differs from the Florida Pedigree Law in the following ways:

1. It is fully electronic (it is NOT paper-based)
   The law and all of the discussion of the law by the Board of Pharmacy make it clear that the only acceptable form of a pedigree is electronic. This make it much more reasonable to implement because supply chain members can make use solely of computers to exchange, store and validate pedigrees, without fear that their trading partners can only handle paper pedigrees.
2. Pharmacy returns must be reflected on pedigrees
   This was an original requirement of the Florida Pedigree Law too, but it was removed under pressure from lobbyists before the law went into effect. So far, it remains intact in California, but the law is not yet in effect. What it means is that when a pharmacy buys drugs from someone and they return those drugs, regardless of how little time has transpired, they must provide a pedigree update so that subsequent buyers of those drugs can see their purchase, and return transactions. This is no different from the requirements faced by all other segments.
3. It starts with the manufacturer
   In Florida the first wholesaler started the pedigree. In California, the pedigree must be started by the manufacturer or it is not valid. If you are looking to expose the full history of package of drugs, how could you not start with the manufacturer? I even think the manufacturers generally agree with that notion.Interestingly, the Law doesn’t actually require anything of the manufacturers directly. It is directed at wholesalers who are licensed to operate within the state. Distribution of a drug without a pedigree that was started by the manufacturer is illegal and subject to penalties, but it is the wholesaler who violates the law and is punished, not the manufacturer. Thus, if a given manufacturer fails to provide California wholesalers with serialized product and compliant pedigrees by the time the law goes into effect, it will be up to the wholesaler to decide not to distribute those drugs within California in order to avoid violation of the law and avoid the associated penalties. The only risk a manufacturer takes on is that their drugs may no longer reach patients in California (and the subsequent PR firestorm that would follow).
4. It requires item-level serialization
   California is very clear that they consider the concepts of “electronic track and trace” and “item-level serialization” as being inseparable. That is, if you have one but not the other, then you don’t have a pedigree system. Every drug package must have a unique identifier on it, applied by the manufacturer or repackager, and that UID must be included in the pedigree (the electronic record). This is a substantial difference from the Florida law which has no such requirement.
5. No holes designed to accommodate special interests
   I’m not aware of any special treatment in the Law for any particular segment of the supply chain. Florida opened several holes that seriously compromise the intent of their law. So far, California has resisted opening holes, unless you consider pushing back the effective date to 2015-2017 a “hole”.

Attentive readers will notice that I have listed these differences in the same order as my list of failures of the Florida Pedigree Law in my earlier post about the Florida Law. This is my way of showing that California has, so far, created a pedigree regulation that does not have any of the major failures of the Florida regulation.

These are the major differences, but what about the common characteristics? Here are the key things that the California Law has in common with the Florida Law:

• Reliance on Digital Signatures
  Florida allows a pedigree to be created, stored and passed in electronic form, though they don’t require it. But if a Florida pedigree is in electronic form, digital signatures are required for the same purpose as a hand-executed signature on a paper document. The digital signature legally binds the signing person or entity to the content of the electronic document. Florida identified some specific standards that ensure that the digital signatures possess the all-important quality of non-repudiation. The California Pedigree Law does not, itself, specify any standards for digital signatures, but the Board of Pharmacy’s Q&A (see their Q72) calls out the fact that the California Code of Regulations identifies the specific characteristics that must result from a compliant digital signature architecture for electronic documents. The digital signature standards that are compliant in Florida would also be compliant in California.The fact that California included the use of digital signatures is significant because it ensures that each pedigree can stand on its own as a self-contained, self-secure package. This maximizes the value of the entire pedigree architecture because the security mechanism that prevents tampering goes with the package itself. No one has to rely on the access security of a given server or group of servers to prevent tampering. And, if tampering does occur, it can be easily detected, unlike tampering of pedigree approaches that rely solely on server access security. In that case, if server security is breached, you can’t tell which pedigrees were modified and which were not, rendering them all suspicious.
• It distributes responsibility for monitoring supply chain security to all supply chain participants
  This is the one genius concept of the Florida Law and California retained it, thus qualifying those involved for genius status as well. It’s a regulatory approach that is relatively new but is likely to become much more common in the face of perpetual budget “crises” in state and federal government agencies. Instead of requiring trading partners to simply keep records of their own buying and selling history for each drug so that they can be audited by an inspector at some later date, these laws require them to check the validity of the full pedigree at the time of each purchase transaction, in near real-time.Notice the difference. In the first instance, it is up to the State Board of Pharmacy inspector to detect suspicious activity in the supply chain. But how often will a state inspector visit, and how many records will they be able to review? It’s inconceivable that this approach would result in the detection of illegitimate activity.But when every purchase of a drug as it passes down the supply chain requires the buyer to run a validity check on the full transaction history of that specific bottle, it greatly increases the odds that most suspicious transactions will be detected. And for most suspicious events in the history there will normally be multiple opportunities for detection. Here, digital signatures are the enabling technology. They allow all of this supply chain monitoring activity to occur reliably and automatically inside computers that are distributed throughout the supply chain, without human intervention and without slowing the movement of drugs.

So did California succeed in creating a better law than Florida? I propose that there is almost no comparison so the question may be moot. The California Pedigree Law is so much more far-reaching than the one in Florida. While Florida focused on disrupting some very troublesome practices being performed by a few nefarious licensed and unlicensed wholesalers, California’s law is designed to cause a major reorientation of the pharmaceutical supply chain approach to security, monitoring and policing (see also The Deputized Supply Chain). This has major implications that go well beyond those of the Florida law.

Faced with that, it is not surprising that it was necessary to push out the effective dates to 2015-2017. Transformation this big takes time to implement.

Digital signatures are commonly mis-understood, but they play an important role in securing the pharmaceutical supply chain. The Florida pedigree regulations allow the use of digital signatures on electronic pedigrees so that they can be “self-authenticated”. That is, so the pedigree can be authenticated on receipt without employing methods that require some kind of communication with each upstream owner of the drug—like phone calls, faxes, emails, etc.

Digital signatures employed in pedigrees can self-authenticate without any kind of communication. This can be a huge timesaver because it can fully automate the detection of improper supply chain behavior. Large volumes of “clean” pedigrees can be processed without human review or intervention with only those that have a problem being presented to a user for manual review and handling.

It’s not necessary to understand the technical details, but understanding some of the non-technical characteristics of digital signature technology is important for those in the pharmaceutical supply chain. Florida encoded the use of FIPS (Federal Information Processing Standards) digital signature standards directly into their regulations. California seems poised to do something similar.

I want to explain digital signatures without getting too technical. That’s hard to do, but here’s a common misconception that is easy to dispel. The term “digital signature” does not mean something that looks like this:

This is a scanned image of a hand written signature (compliments of a spam/scam email I received this morning). You could call this a “digitized signature”, but it is far from a “digital signature”. The digitized signature may mean something to people when the image is displayed so they can see it, but it means nothing to a computer. Nothing more than a photograph. It’s just a bunch of bits.

A true digital signature is one that a computer can make sense out of. The “sense” it can make is to determine whether the signature is valid or not. For that to work, the digital signature has to be composed of data. Here is an example of a long-form demo digital signature in XML format like those found inside DPMS pedigrees. It includes the core signature as well as the signer’s public key for use in decoding the signature, and a certificate that is digitally signed by a certificate authority who is willing to attest to the signer’s identity.

It looks pretty technical, doesn’t it? It is, but don’t get bogged down in the details. The point is, with this type of data, a computer can verify that a known trusted authority (the certificate authority) is positively willing to attest to the identity of the signer and that the public key included is positively from the signer. The computer can then use the public key to verify that the information being signed (not visible in this example) has not been modified since the signer applied the digital signature. All of this can be determined without the computer needing to go elsewhere for additional information.

Probably the most important thing a digital signature provides is the quality of “non-repudiation”. That is, because the certificate authority has pre-identified the signer in a way that can include the review of legal records, and as long as the signer has kept their private key secret, the signer cannot later claim that they did not sign a set of digital information that bears their digital signature. They cannot disclaim it. The signer is tightly bound to the signed data.

That’s a lot more than your bank can tell from the handwritten signature on your checks. Digital signatures are better in almost all respects.

The FDA, other federal government agencies and most U.S. state governments have embraced the use of digital signatures in digital legal documents. In pedigrees, digital signatures provide strong evidence that the information signed can or cannot be trusted. That’s why they are an obvious choice by regulators who want to move beyond paper pedigrees.

In summary, digital signatures provide the following benefits when used in electronic documents:

• Positive identification of the signer
• Non-repudiation of the information that is signed
• Positive confirmation that the signed information has, or has not been modified since being signed
• Signature validation can be performed without needing to communicate with external entities

The use of digital signatures in DPMS pedigrees is the feature that turns, what would otherwise be just a blob of data, into a standalone legal document that can be easily validated without needing to acquire any other information. It’s what allows DPMS pedigrees to be used as evidence in court for prosecution of counterfeiters, diverters and thieves.

For a more technical description of digital signatures and the PKI (Public Key Infrastructure) technology behind it, start with the definition in Wikipedia.

Now that I have covered digital signatures in general I can move on to discuss their use in specific pedigree approaches. Stay tuned.

I’ve written before about the importance of supply chain standards and how pedigree standards can be categorized as “communications standards”. I drew the analogy of the importance of standards in making cell phones work together. Because U.S. cell phone companies agreed to make use of certain standards, you are able to call your friends who chose to buy service from Sprint, when you have chosen to buy your service from Verizon, or any of a number of other U.S. carriers. Without those standards and the agreement of each company to use them, you would only be able to call people who happened to sign up with the same phone company that you did.

I won’t reproduce the whole article here but its contents are just as pertinent today as they were two years ago when it was published in Pharmaceutical Commerce magazine. That article stressed the importance of the GS1 Drug Pedigree Messaging Standard (DPMS, a.k.a. the GS1 Pedigree Ratified Standard), but any approach selected by an individual company to address pedigree legislation has to consider interoperability with whatever approach their trading partners choose. Interoperability is the goal of standards but right now there are two standards-based approaches to pedigree out there and they are not currently interoperable. That’s a problem for everyone, because the supply chain is so interconnected and diverse at the same time.

The two standards are DPMS and EPCIS–both from GS1. The history of these two standards and the differentiating characteristics of each one is too complex to cover in a single post so I’ll just provide an introduction here. I’ll continue the discussion in later posts, although I don’t plan to make the whole thing contiguous because there are other topics that I also want to cover over the same timeframe.

EPCIS (Electronic Product Code Information Services) is a GS1 standard that defines a set of interfaces for the purpose of capturing and querying serial number “visibility” data. “Visibility” data is meant to be observations and transactions that are based on observations of serial numbers that are attached to items and logistical containers of products within supply chains. I still haven’t found an easy-to-understand way to explain it, but I think those two sentences describe it fairly concisely and accurately. If you have a better way to explain it, please post a comment below.

Notice that the description doesn’t say anything about pedigree or regulatory compliance. EPCIS is a standard, but it’s a general purpose IT thing that you have to apply a specific way in order to make it work as a pedigree system. The standard is designed to be very flexible and for serialized product, it could be quite powerful if used right. There are a couple of problems for those who want to use it as a pedigree system, however.

• There is currently no standard that describes exactly how to apply it as a drug pedigree system that would ensure interoperability across the supply chain;
• There is the general tendency to talk about ways to turn EPCIS into a pedigree system, but I haven’t heard one yet that is likely to comply with existing pedigree laws.

I’ll cover those issues in more detail in later posts.

DPMS (Drug Pedigree Messaging Standard) is a GS1 standard that was specifically created to assist the pharmaceutical supply chain with creating an interoperable system to trace drugs in a way that can comply with existing pedigree laws. That includes Florida, California, the PDMA and all of the other states that currently have pedigree laws. The problem is, it doesn’t do much to assist companies with all of the many problems they face dealing with serial numbers on items. DPMS can take serial numbers and use them to trace those items, but there are a lot of other, non-compliance issues that must be dealt with first.

So there are problems with both standards. Perhaps an obvious solution is one that I, and others, proposed last year to combine EPCIS and DPMS to create a system that benefits from the best of both standards.

As you might imagine, there is a lot more I could discuss on this topic in later posts. But I’m going to try to stay out of the details and talk more about implications of each approach. Stay tuned…