Most Warehouse Management Systems (WMS) available on the market today do a fine job of allowing their users to manage inventories in the warehouses of drug manufacturers, distributors and chain drug stores.  A WMS is a software system that may be a part of a larger Enterprise Resource Planning (ERP) system, or it may be a third-party application that is interfaced with the owner’s ERP system.

All WMS systems that I am aware of are intended to be sold into multiple industries, not just in pharma.  That’s so that the WMS vendor can maximize their sales.  The more industries, the more sales and the more profitable it is.  Because some industries have long had serial numbers on some of their products (computers and peripheral equipment, cell phones, electronics, medical equipment, appliances, etc.) WMS vendors have included serial number handling in their software for decades.  In fact, I would bet that a serial number handling feature was included in WMS systems since the very beginning of that category of software.

However, buyers of WMS systems in the pharma supply chain should be very careful not to confuse a “serial number handling” or even “serialization” checkbox on the WMS vendor’s spec sheets with the kind of “serialization” they will need for compliance with modern pharma serialization regulations.  I include the California Pedigree Law, the potential future serialization requirements that may (or may not) be coming from the FDA, and those in the E.U.

THE DIFFERENCE BETWEEN WMS SERIAL NUMBER HANDLING AND PHARMA SERIALIZATION FOR REGULATORY COMPLIANCE

The reason is simple.  Despite the similar (or same) name, serialization in the pharma supply chain leads to significantly different functionality than dealing with serial numbers on products in other supply chains.  For example, think about what would be needed for a personal computer manufacturer.  They would need to keep track of which serial number is applied to which models.  They may want to keep track of who they shipped which serial number to, and they may want to connect their warranty registration, returns, warranty claims and service processes to their serial number database so they can make sure they know exactly which sub-model revision (hardware, firmware and software) they are dealing with and to confirm that the customer is valid (for after-sales service).  All of these serial number tasks can be easily accomplished within the WMS, within an add-on module, or within some module of the ERP system because they normally do not need to communicate with the systems of other companies.  These same kind of capabilities would be needed for all of the types of products I listed above.

But these capabilities are distinctly different from those that members of the pharma supply chain are going to need going forward and so these traditional serial number features of WMS systems are insufficient.  The pharma supply chain needs to use the serial numbers on drug packages to authenticate the supply chain history, either at each stop (California), at the point of dispense (E.U.), or somewhere in between (potential future U.S. FDA regulation).  This requires a different approach.

First, all companies within a given supply chain must follow certain standards to ensure interoperability of the serial numbers themselves and the how they will be handled across all members.  That is, a WMS vendor can’t simply make up their own serial number handling features because they will not interoperate with those from other vendors.  Second, some kind of standardized data exchange related to the serial numbers must occur between trading partners, and third, the management of the data must also be standardized so that the same functionality is made available to all parties in the supply chain.

STANDARDS ENABLE INTEROPERABILITY ACROSS THE SUPPLY CHAIN

In the U.S. and in many other countries around the world, GS1’s Global Trade Item Number (GTIN) plus serial number (or SGTIN) is the standardized serial number that has been chosen (see my essays “FDA Aligns with GS1 SGTIN For SNDC” and “California Enforcement Subcommittee Moves To Require FDA SNI” and also see the GS1 General Specifications).

In California the GS1 Drug Pedigree Messaging Standard (DPMS) is known to be usable for compliance and would fulfill the necessary standard format for data exchange and data management.  However, the industry has more recently been interested in the use of GS1’s Electronic Product Code Information Services (EPCIS) standard as the basis for the standardized data exchange and data management.  Personally I don’t think anyone has shown satisfactorily that it will comply with the current California law but it appears that companies who are members of GS1 U.S. Healthcare Traceability group are hoping that it will.  (See my essays “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 1” and “…Part 2”.)  If the California Board of Pharmacy is willing to accept it, then it can be used for compliance, but until we know that, I think it’s risky to deploy systems that are only based on EPCIS.

We won’t know which standard will fulfill the needs of whatever federal pedigree regulation, if any, may be on the horizon until the regulation is published by the FDA down the road.  So far it is probably a good bet that EPCIS will play an important role and it is very unlikely that DPMS will play any role.  We’ll see…

Ignoring the debate over which GS1 standard would be used in the U.S., the point is, the existing serial number handling features of today’s WMSs will not be sufficient because they are intended for something else.  The key characteristic that both DPMS and EPCIS have that is missing from those existing WMS features is that they are able to document supply chain events that occur to GS1 serial numbers and therefore to the products associated with those serial numbers.  This includes Commissioning, Aggregation, Shipping and Receiving, among others.  When you include the fact that they are both standards that all solution developers can follow, which results in interoperability between their solutions, DPMS and EPCIS are the only ways to address the needs of these modern requirements in the pharma supply chain.

WMS AND SERIALIZED EVENT REPOSITORIES

I once thought that WMS and Pharmacy Management System (PMS) vendors would see the difference and perhaps would add at least the standard EPCIS interfaces to their products (see my essay “The Future of Traceability Repositories and Inventory Management Systems”), but as far as I know that hasn’t happened.  Perhaps they have concluded that a WMS isn’t really the place to store supply chain events.

The whole point of a WMS is for managing inventory and warehouse processes.  Serialized supply chain events are related to things that pass through the inventories, but the life of those events could extend well beyond the life of the typical data element a WMS needs to deal with today.  The data communications and management needs of serialized supply chain events is also beyond the traditional scope of a WMS.  It now seems to make more sense to have a separate repository just for those events and maintain minimal connection between that repository and the WMS.  Perhaps the only connection would be related to the time that the serialized products are present in the inventory that the WMS is managing.

Figure 1.

That might require some interface(s) between the two systems since the serialized event repository is an inventory system of a sort.  For each product code the WMS will likely maintain an inventory count and the event repository will likely maintain a list of serial numbers in the same inventory.

If you are shopping for a new WMS and you know you will need to comply with a pharma serialization regulation, make sure you fully understand the limits of the serial number handling capability of the products from each vendor you are considering.  Don’t assume that you will be covered just because the spec sheet has a check box for “serialization”.

Dirk.

Back in 2007 the U.S. Congress passed the Food and Drug Administration Amendments Act (FDAAA) and it was signed into law by President Bush.  One of the provisions of that law was an instruction to the FDA to “…develop standards and identify and validate effective technologies for the purpose of securing the drug supply chain against counterfeit, diverted, subpotent, substandard, adulterated, misbranded, or expired drugs”, and “…develop standards for the identification, validation, authentication, and tracking and tracing of prescription drugs.”

The FDA fulfilled these instructions for one of the specific standards that the law identified when the agency published their Standardized Numerical Identifier (SNI) standard back in 2010.  That standard was fairly high level and for the vast majority of drugs, use of GS1’s Serialized Global Trade Item Number (SGTIN) (or “GTIN plus serial number”) for drug package identification would comply with it.  The text of the FDA’s standard says as much.

By defining the SNI in this way did the FDA surrender the development of the real SNI standard to GS1 (at least the sNDC portion of it)?  I don’t think so.  In my essay about the SNI standard I described it as the FDA “aligning” with GS1’s SGTIN (see my essay “FDA Aligns with GS1 SGTIN For SNDC”).  Alignment shouldn’t be confused with surrender.  The choice of alignment with SGTIN was good for the FDA, good for patients and good for the industry.

WHAT WE GOT WHEN THE FDA ALIGNED THEIR SNI STANDARD WITH GS1’S SGTIN TECHNICAL STANDARD

In the case of the SNI aligning with GS1’s SGTIN we got the following things:

• An existing robust global standard that has multiple years of use by multiple industries—including the pharma supply chain—and in multiple countries;
• Automatic interoperability with the regulatory requirements of other countries who have, or will, align with the SGTIN;
• Automatic interoperability with all of GS1’s other—current and future—standards that use the SGTIN as a key component (see my essay “GS1 Standards – Betcha Can’t Use Just One!”);
• Automatic interoperability with lots of existing third-party applications that are already designed to work with the SGTIN.  Some companies in the supply chain had already deployed these systems and now they can proceed with further deployments knowing that by doing so they will remain compliant with the FDA SNI standard;
• Widespread existing knowledge and understanding of the SGTIN and how to apply it within the industry.

These are huge benefits.

In contrast, China’s State Food and Drug Administration (SFDA) chose to expand the use of their own existing product serialization standard to include drugs, but that standard does not align with the GS1 SGTIN.  That will probably benefit the government there and perhaps domestic companies who are serving only the China market, but it could also complicate international trade in pharmaceuticals where companies from China are a party.

SO SHOULD FDA CEDE ALL STANDARDS DEVELOPMENT TO GS1?

The fact that FDA’s choice to align with GS1’s SGTIN provided so many benefits should not be taken as a sign that the FDA should simply mandate other GS1 standards to fulfill their obligation under FDAAA of 2007.  It made sense when it came to the foundational SNI to use the foundational SGTIN as the aligned standard, but that’s about as far as you can go.  GS1 doesn’t have standards that are out-of-the-box usable for “…validation, authentication, and tracking and tracing of prescription drugs”.  Those are high-level applications, not foundational standards like SNI.

Yes, you can use some of GS1’s standards as the basis for applications that might validate, authenticate and track & trace prescription drugs—likely including GS1’s Electronic Product Code Information Services (EPCIS) and related standards—but it is much harder for the FDA to “align” with those standards without a lot more FDA-specific explanation of exactly how they might be applied to implement those applications.  That FDA-specific explanation would be the description of an authentication and track & trace “model”, which might use GS1 standards under the covers.

The best thing GS1 has done that the FDA might be able to use to help them formulate their authentication and track & trace “standards” is the output of the GS1 Healthcare Network Centric ePedigree (NCeP) work group.  That group simply documented the characteristics of eight different ePedigree models that would be based on GS1 EPCIS.  The documentation amounts to a concise “catalog” of authentication and track & trace models that the FDA could use to help them select a viable model for their “standard”.  (They should also see my RxTrace essays, “The Viability of Global Track & Trace Models”, “Plateaus of Pharma Supply Chain Security”, “SNI’s Are Not Enough In a Plateau-Based Supply Chain Security Approach” and a bunch of others in my back catalog.)

Regardless of what FDA chooses to do in the development of the standards mandated by Congress, they should not and certainly will not cede it all to GS1.  The mission of the FDA is completely different from the mission of GS1 and the standards they each publish reflect that difference.  While I wouldn’t be surprised if the FDA authentication and track & trace standards include some references to GS1 technical standards, they will need to provide a lot more additional details than they did in the SNI standard.

We shouldn’t have long to wait to get an initial glimpse of where the FDA is going with their track & trace standard.  As I reported in my essay “InBrief: FDA To Publish Track & Trace Standard By Year End”, we should see the first draft by the end of the year.

Dirk.

The title is a paraphrase of a TV commercial from the 1960′s, ’70′s and ’80′s for Lay’s Potato Chips but the sentiment is the same.  You really can’t get away with using only a single GS1 standard.  That’s why they are sometimes referred to as “The GS1 System of Standards“.  It’s a “system” of standards.  Multiple standards that are designed to work for you together in concert; as a whole; not independently.

So when your customer demands that you make use of Global Location Numbers (GLN) and/or Global Trade Item Number (GTIN), they are starting you down the path of adoption of much more than just those two “entry-level” standards (see my essay “So a customer demands that you use GLN’s and GTIN’s. What next?”).  Here is a partial list of other GS1 standards that you may benefit from adopting once you fully embrace GLN and GTIN:

• GS1 UPC barcode symbology
• GS1 element strings encoded in a barcode symbology such as:
• GS1-128
• GS1 DataMatrix
• GS1 DataBar
• GS1 EANCOM EDI standard
• GS1 EPC RFID in frequencies such as
• UHF
• HF
• GS1 Electronic Product Code Information Services (EPCIS)
• GS1 Drug Pedigree Messaging Standard (DPMS)
• GS1 Global Data Synchronization Network (GDSN)

GS1 Healthcare is a community organization of end users within GS1 who are members of the global healthcare industry.  That organization created the following figure to show how GLN and GTIN are foundational to patient safety and supply chain efficiency, the ultimate end goals of its members.  At the top of that foundation is GDSN and above it are the five pillars of patient safety, which support the ceiling of supply chain efficiency and the overall roof of patient safety.  (See “Change has finally come:  U.S. Healthcare industry to implement common data standards to improve safety, reduce costs” by Joe Pleasant, CIO and SVP, Premier, Inc.)

GS1 Healthcare Patient Safety "House of Standards"

Many U.S.-based hospital Group Purchasing Organizations announced a number of years ago that they would require the use of GLN and GTIN by December 2010 and 2012 respectively.  Apparently at least one of those GPO’s also requires the use of GDSN but without specifying a date.

GS1 GLOBAL DATA SYNCHRONIZATION NETWORK (GDSN)

GS1’s GDSN is a standard that can be used by supply chains to communicate product class-level supply chain master data (SCMD) to all of the companies who participate in it.  Here is how I described it in my essay, “Supply Chain Data Synchronization and Patient Safety”:

“Generally, [GDSN’s] use requires all trading partners in a given supply chain to subscribe to a GDSN-conformant Data Pool service provider.  Unilateral adoption of GDSN by a single company doesn’t make any sense.  It’s a high bar for a large and complex supply chain to achieve through voluntary means.  Right now the pharma supply chain in the U.S. has not achieved it and so the quality of SCMD in the supply chain is currently dependent on ad hoc relationships and data passing.  Some of this includes manual data entry into the local master data systems at many points in the supply chain.”

Here is one way GS1 draws GDSN.  This view emphasizes the plumbing and shows the “how” of GDSN.  (See “Global Data Synchronization Network® (GDSN) Operating Roadmap for GS1, Version 7.3” November 2011.)

Click image to enlarge

Here is my rendition of GDSN use in healthcare.  I show it as a cloud-based repository where the manufacturer publishes their product master data and where downstream trading partners can subscribe to it.  That way everyone in the supply chain—right down to the healthcare professionals at the points of care—are using the exact master data as published by the manufacturer.  Admittedly this rendition doesn’t show how GDSN is implemented, but I happen to think that’s less important that showing what it is.  See GS1 for the details.

Click image to enlarge

Up to this point in time there still hasn’t been any significant use of GDSN in the U.S. medical supplies and devices supply chain and it is tough to get an entire industry to adopt something so large without some kind of incentive.  The GPO’s are trying to provide that incentive by mandating its use, so at some time after the GTIN is widely adopted on medical supplies and devices, SCMD may be synchronized between manufacturers and hospitals, and perhaps distributors as well.

USE OF GDSN IN THE U.S. PHARMACEUTICAL SUPPLY CHAIN

GDSN is also not currently used in the U.S. pharmaceutical supply chain, but in my view, it will be a necessity if/when GS1’s EPCIS standard is ever used for track and trace applications like ePedigree.  In my view, EPCIS alone can’t be used for compliance with the existing pedigree regulations in the U.S. (see my essays, “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 1” and “…Part 2”).

But EPCIS just might become the basis for the track & trace standard that the FDA will publish by the end of this year (see me essay “InBrief: FDA To Publish Track & Trace Standard By Year End”).  Many people believe that standard will be based on EPCIS, similar to the way FDA aligned their sNDC standard with GS1’s GTIN (see my essay “FDA Aligns with GS1 SGTIN For SNDC”).  Include me in that group.

But, by design, EPCIS events do not carry SCMD (see my essay, “Pedigree Models and Supply Chain Master Data”), so if EPCIS events form the basis of an ePedigree, it will be a absolute necessity that all parties who are consuming and updating those pedigrees use the identical product class-level master data.  That would be necessary because everyone would need to agree on exactly what constitutes the drug that is referenced by the GTINs in the EPCIS events.  Without that common agreement on exactly what the GTINs mean, how can there be a true pedigree?

Here is a drawing that shows how GDSN could be used in conjunction with a semi-centralized ePedigree system that is built on top of EPCIS events.

Click image to enlarge

Notice how each trading partner in the supply chain communicates with both the GDSN cloud and the Semi-Centralized ePedigree cloud.  In actual implementation these clouds might not be so distinct because the same vendors might offer both, but I show them separate here because they are serving distinctly different purposes.

The GDSN cloud is serving as the common source of product SCMD as published by the manufacturer—keyed off of the GTIN—and the Semi-Centralized ePedigree cloud, based on EPCIS, is serving as the common repository for all supply chain events that occur to the actual unit-level instances of those products—keyed off of the serialized GTIN, or SGTIN.  The clouds also communicate with each other because, to produce a usable ePedigree report the ePedigree engine would need to obtain the SCMD from the GDSN cloud.

As I said, I think something like this will be a necessity if EPCIS is used as the basis of an ePedigree system.  So far when people in the industry talk about using EPICS for ePedigree they almost always forget the SCMD.  The ePedigree solution I show in the figure above is a very efficient model since the SCMD does not travel along the same path as the instance data (the EPCIS events).  This is in stark contrast to DPMS which needs to carry that data along with each ePedigree document—a big negative for that standard that many have pointed out over the years.

All pedigree models have trade-offs.  One of the trade-offs of ePedigree models based on EPCIS is that GDSN will probably have to be adopted throughout the U.S. pharma supply chain over a fairly short period of time, but no doubt patients would benefit greatly from that.

BETCHA CAN’T USE JUST ONE

There you have it.  Not only would pharma trading partners need to adopt GLN and GTIN, in this scenario they would also need to adopt EPCIS and GDSN shortly afterward.  In the pharma supply chain you can’t use just one!

Can you see any alternatives to this scenario besides adding DPMS in some way?  Leave a comment below.

Dirk.

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 improved economics and 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.

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

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

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

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

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

WHAT DOES IT MEAN?

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

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

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

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

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

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

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

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

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

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

Plus, analysis of:

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

HAPPY HOLIDAYS!

Dirk.

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

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

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

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

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

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

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

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

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

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

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

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

COULD THE SEMI-CENTRALIZED NCeP MODEL WORK IN CALIFORNIA?

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

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

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

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

WHERE ARE WE NOW?

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

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

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

Dirk.

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

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

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

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

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

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

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

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

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

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

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

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

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

HOW TO INSPECT AN ELECTRONIC PEDIGREE

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

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

WHAT IF THE INSPECTOR MAKES A SLIGHTLY DIFFERENT REQUEST?

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

But what if the inspector makes the following request instead?

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

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

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

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

With this logic, I contend that a true distributed pedigree model, by its nature, doesn’t comply with the California Pedigree Law.  Do you disagree with this logic?  Leave a comment below.

Dirk.

For the application of unique serial numbers, or Standard Numerical Identifiers (SNIs), to packages as part of compliance with the California Pedigree Law in 2015-2017 , GS1′s Electronic Product Code (EPC), particularly in barcode form, is the clear winning standard.  But there seems to be a very common misconception going around that for pedigree data management, all you need to do to comply with that law is to deploy a system that is based solely on the GS1 Electronic Product Code Information Services (EPCIS) standard.  The  misconception assumes that there is a formula that can be followed to achieve compliance and that EPCIS is the whole formula.

In truth, EPCIS will almost certainly be an important component in the compliance formula but exactly how it fits, and whether there are other necessary components, has not yet been determined.

There are probably several reasons that this misconception persists.  First, GS1 US continues to promote their 2015 “Readiness” Program as if it is that formula.  The program documentation strongly implies that, if you simply follow their program, you will “be ready” to comply with the law; but it stops short of actually saying that you will be compliant.

Second, it seems like people are either able to understand the law well but not the technical standards, or they are able to understand the technical standards well but not the law.  The legal folks are left to trust what the technical people say about EPCIS, and the technical people assume that as long as the data elements identified in the law are present somewhere then EPCIS must comply.

Now I am not a legal expert but I’ve been looking at the text of the California Pedigree Law for a few years now and I think I understand it at a level that allows me to estimate how various technical approaches might fill its requirements.  Let me show you how the text of the law compares to the capabilities of the EPCIS standard.  From that analysis I think you will either be able to see that EPCIS by itself is insufficient to comply with the law, or you may see some flaw in my logic.  In that latter case, please leave a comment below to point out the flaw.  My intent is not to provide you with legal advice but to explain how the EPCIS technical standard would likely be applied when using it in an attempt to comply with the law.  Decide for yourself what you think will or won’t comply.

THE CALIFORNIA PEDIGREE LAW

The California Pedigree Law is now part of the California Business and Professions Code.  There are a number of resources that the California Board of Pharmacy provides to help you study and interpret the code.  Unfortunately all of the material on their website is a little out-of-date, but it still has some value.

• A page containing a copy of the pertinent text from the California Business and Professions Code.  The text on this page is the way the regulations were prior to the most recent modification of the law that pushed the effective date out to 2015-1017.  Most of it is still accurate.
• A draft of a PDF called “Questions and Answers Relating to the Electronic Prescription Drug Pedigree Law”.  Dated January 2008 please note that this document was written for the regulation as it existed prior to the last modification that pushed the effective date out to 2015-2017.  It is still a useful guide to the Board of Pharmacy’s interpretation of the law except when related to the effective dates and perhaps some of the exceptions to the law;
• A PDF called “Background and Summary of the California ePedigree Law”.  The document doesn’t have a date but it is obviously describing the law as it was prior to the latest revision that pushed the effective date to 2015-2017.  It is still useful because it provides some of the history leading up to that revision.

It would be nice if the Board would update these resources now that people are beginning to pay more attention to the current deadlines and are preparing for compliance.

To read the actual text of the current California Business and Professions Code click here and then search for the word “pedigree”, then click on the sections where your search finds that word.  That should take you to the actual text of those sections of the Code.  Now search for key words related to pedigrees.

I have written about the California Pedigree Law in the past.  You might find these essays of interest.  Click here for a list of RxTrace essays that contain references to it.  Dr. Adam Fein of Pembroke Consulting has written frequently about pedigree in general including the California Pedigree Law over the last 5 years or so.  Click here for a list of his DrugChannels blog essays about Pedigree.

THE CALIFORNIA CODE THAT IS PERTINENT TO THE TECHNICAL IMPLEMENTATION AIMED AT COMPLIANCE

First, what constitutes “a pedigree” under California Law?

Section 4034.

(a) “Pedigree” means a record, in electronic form, containing information regarding each transaction resulting in a change of ownership of a given dangerous drug, from sale by a manufacturer, through acquisition and sale by one or more wholesalers, manufacturers, repackagers, or pharmacies, until final sale to a pharmacy or other person furnishing, administering, or dispensing the dangerous drug. The pedigree shall be created and maintained in an interoperable electronic system, ensuring compatibility throughout all stages of distribution.

(b) A pedigree shall include all of the following information:

(1) The source of the dangerous drug, including the name, the federal manufacturer’s registration number or a state license number as determined by the board, and principal address of the source.

(2) The trade or generic name of the dangerous drug, the quantity of the dangerous drug, its dosage form and strength, the date of the transaction, the sales invoice number or, if not immediately available, a customer-specific shipping reference number linked to the sales invoice number, the container size, the number of containers, the expiration dates, and the lot numbers.

(3) The business name, address, and the federal manufacturer’s registration number or a state license number as determined by the board, of each owner of the dangerous drug,  and the dangerous drug shipping information, including the name and address of each person certifying delivery or receipt of the dangerous drug.

(4) A certification under penalty of perjury from a responsible party of the source of the dangerous drug that the information contained in the pedigree is true and accurate.

(5) The unique identification number described in subdivision (i).

(c) A single pedigree shall include every change of ownership of a given dangerous drug from its initial manufacture through to its final transaction to a pharmacy or other person for furnishing, administering, or dispensing the drug, regardless of repackaging or assignment of another National Drug Code (NDC) Directory number.

Dangerous drugs that are repackaged shall be serialized by the repackager and a pedigree shall be provided that references the pedigree of the original package or packages provided by the manufacturer.

[…]

The key to my argument is that all of this information (I’ve highlighted it for you above) must be present in “a record” or it isn’t a valid “Pedigree” according to this part of the Code.  A “single pedigree” must include information about every change of ownership of a given drug or it’s not a valid pedigree.

We only need parts of one more section to be able to determine why EPCIS by itself won’t work for California pedigree.  That’s section 4163.  I’m leaving out parts that aren’t needed for my argument, including the exceptions, so feel free to review the entire section to convince yourself that I haven’t bent anything to benefit my case:

Section 4163.

[…]

(c) […] commencing on July 1, 2016, a wholesaler or repackager may not sell, trade, or transfer a dangerous drug at wholesale without providing a pedigree.

(d) […] commencing on July 1, 2016, a wholesaler or repackager may not acquire a dangerous drug without receiving a pedigree.

(e) […] commencing on July 1, 2017, a pharmacy may not sell, trade, or transfer a dangerous drug at wholesale without providing a pedigree.

(f) […] commencing on July 1, 2017, a pharmacy may not acquire a dangerous drug without receiving a pedigree.

(g) […] commencing on July 1, 2017, a pharmacy warehouse may not acquire a dangerous drug without receiving a pedigree.

[…]

So once the law goes into effect, wholesalers, repackagers and pharmacies cannot sell, trade or transfer a drug without providing the buyer with “a pedigree”, and, separately, wholesalers, repackagers and pharmacies cannot buy a drug without receiving “a pedigree” from the seller.  Notice that this obligates both the buyer and seller independently.  If “a pedigree” isn’t provided with the transaction, both buyer and seller are breaking the law.

HOW EPCIS WAS DESIGNED TO WORK

EPCIS was designed to be used to implement a distributed network of repositories that each contain records describing the WHO, WHAT, WHEN and WHY of supply chain events that occur as serialized products move through a supply chain.  The original vision of EPCIS as applied to the U.S. pharmaceutical supply chain would expect each pharma manufacturer, each distributor and each pharmacy to have their own event repository that conforms to the EPCIS specification.

In their repositories, these companies would save records—or, events—that describe all of the serial number-based events that would occur while the drugs were under their control.  That is, the manufacturer’s repository would hold all of the events related to each drug package that occurred during manufacturing through shipment to the their customer, but it would not hold any of the events that occurred on the properties of downstream owners of those drugs.  Likewise, the distributor who bought the drugs from the manufacturer would typically hold only the events for those drugs from the point of receipt from the manufacturer through their own shipment to their customer.  And so on down the supply chain.

APPLYING BASIC EPCIS TO THE BASIC PEDIGREE PROBLEM

To get a full “trace”, or “supply chain history”, of a given package of a drug you would need to query each of the EPCIS repositories of all previous owners back to and including the manufacturer.  This “trace report” that would result would be a good example of a “chain of custody” report, but it would fall short of what California calls “a pedigree”.  It may be a valid pedigree in other jurisdictions under different laws but in California it would be missing the following necessary data elements from their definition:

• “Name”, “registration number or a state license number and principle address of the source”
  These data elements would be missing because, by definition, EPCIS makes use of Supply Chain Master Data (SCMD) references to save space.  Instead of the explicit information called out in the law the trace records produced by EPCIS queries would contain GS1 Global Location Numbers (GLNs) which are 13-digit numbers that are supposed to represent most of this data.  That representation is defined by the owner of the GLN and they are under no obligation to maintain it or to ensure that the data has a single, fixed association with the GLN.
• “Trade or generic name”, “dosage form”, “strength”, and “container size”
  These data elements would be missing because, like its use of GLN’s, EPCIS is designed to also use SCMD references for product data to save space.  In place of this data, each event would include only a GS1 Global Trade Item Number (GTIN) which is a 14-digit number that is supposed to represent most of that product data.  The manufacturer of the drug owns the relationship between the GTIN and the associated product data, but they are under no obligation to ensure there is only one, unchanging set of product data associated with that number.
• “Business name”, “address”, “federal manufacturer’s registration number or a state license number”…”of each owner” of the drug, including the “name” and “address of each person certifying delivery or receipt” of the drug
  Again, EPCIS events would hold a representation of this information as a set of GLN’s to save space.  The actual data would only be implied.
• “A certification under penalty of perjury from a responsible party of the source of the dangerous drug that the information contained in the pedigree is true and accurate”
  The EPCIS standard doesn’t define anything like this kind of data.
• “A single pedigree shall include every change of ownership…”
  The chain of custody report that is built as the result of the set of queries mentioned above would be a set of records that would need to be interpreted and the information combined into a single record.  But this would only be possible if the current owner knows who to query and then only if all of the previous owners of the drug were willing and technically able to reply at that particular moment with their contribution of the events they hold about that particular drug.

That’s a lot of missing information.  It may seem like the EPCIS standard is so far away from what the law calls for that it is hopeless to expect it to ever work.  Not quite.  EPCIS has an important feature that is intended to allow users to extend its operation in multiple ways.  This feature allows EPCIS to be shaped into solutions that can fit problems much more flexibly than previous general purpose systems might have in the past.  Can this extensibility feature address all of the missing information in some way and turn the chain of custody report into a compliant pedigree?  Perhaps.  I will consider that possibility in future essays in this series.  But first…

ENTER THE GS1 US HEALTHCARE 2015 READINESS PROGRAM

GS1 US saw these problems with EPCIS a number of years ago.  Since that time their Healthcare Traceability group has been working on potential solutions to some of the problems I listed above.  I can’t write about exactly how they propose to do that because they have policies that prevent the disclosure of that kind of internal information.  However, it appears that GS1 US is just about to make that kind of information public themselves in the next few weeks.  As soon as they do I will pick up this topic again and explain how their ideas might or might not address this list of deficiencies.

WHAT ABOUT GS1 (GLOBAL) HEALTHCARE?

That’s a good question.  That organization has been busy working on pedigree-related ideas as well, though at a global level, and, not coincidentally, they too are about to make public their latest thoughts on how to use the EPCIS standard for network-centric ePedigree applications.  Although their work is intentionally not aimed at meeting the exact requirements of the California law (because it is a global effort), their work does beg for an explanation of how it might fit if those ideas were applied in that State Law.  This release of information will probably occur in the next few weeks as well.  So we will shortly have lots of ideas in the public domain that we can discuss and analyze.  In fact, I hope we are not overwhelmed!

WILL ANY OF THIS MAKE ANY DIFFERENCE AT ALL?

Another great question.  In fact, it may all become moot, because a new federal pedigree bill was apparently introduced into the U.S. Congress a couple of weeks ago by Representative Jim Matheson [D-UT].  If that bill, or some modified version of it eventually makes it out of committee and then passes both Houses of Congress and then if the President signs it, it would almost certainly pre-empt the California Pedigree Law.  In that case, we will all shift our attention to the peculiarities of the Federal regulation and the likely FDA guidance that would certainly follow.

However, it is very hard to estimate the likelihood that this, or other bills like it in the future, will pass.  Similar bills introduced in past sessions have not made it out of committee.  So until one of these bills make it through the entire process, it makes the most sense to keep our eyes on the realities of the California requirements.

Stay tuned for Part 2 as soon as the GS1 US and GS1 (global) documents are made public.

Dirk.

For Part 2 in this series, see “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 2“.

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.

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