The Viability of Global Track & Trace Models

At the end of my last essay I said I had recently concluded that the jump to a fully automated pharma supply chain upstream visibility system is too big and complex to be achievable by every company in the U.S. supply chain by the California dates.  I want to explain that statement in a future essay (soon), but before I do I want to explore some of the track and trace models that are being considered by both GS1 and the FDA.  I particularly want to look at the viability of each model because I think we will find that some just aren’t (viable), and that will help narrow the search.

I’ll look at the three basic models that the FDA mentioned in their recent workshop:  Centralized, Semi-Centralized and Distributed (or Decentralized as the FDA called it).  There are others, but it seems that they can all be either based on, or reduced to, one of these three basic models.

In this essay I am looking at track & trace models from a global viewpoint, which is something that GS1 is doing but the FDA may not.  Attacks on the pharma supply chain are a global problem and global problems demand global solutions or gaps will be left for criminals to exploit.

GS1’s goal is to develop standards that apply globally as much as possible and the FDA will likely find that global manufacturers are more willing to implement something that is the same–or similar to–something they are already deploying elsewhere in the world.  It’s a good idea because any approach that has been demonstrated to be viable elsewhere in the world is probably more likely to be viable here…though that’s not guaranteed.

THE CENTRALIZED TRACK & TRACE MODEL

I would draw a Centralized track & trace model with a single, central track & trace repository (or at least a single system) for the entire world.  That’s what centralized means.  (Click on the drawings to enlarge them.)

Figure 1.   Global Centralized Track & Trace Model. Not viable!

Most people probably don’t think of the Centralized model as requiring a single repository/system for the entire world but if you have more than one, you are talking about a “Semi-Centralized” model.  That’s a different model, which I will talk about below.

In my view, the concept of a Centralized track and trace model depicted in Figure 1 above is not viable at all.  For something like this to work you would probably need some kind of central global government that mandates its use, or at least a global law enforcement agency.  I don’t think we’ll see that any time soon.  Until then, this model is not viable.

THE DISTRIBUTED TRACK & TRACE MODEL

The Distributed track & trace model is one where each trading partner communicates with their immediate upstream and downstream trading partners under normal circumstances, and with other companies in the supply chain who may not be direct trading partners when necessary for certain applications.  ePedigree is one of the applications that would most often require a company to need to communicate with another company in the supply chain that is not an immediate trading partner.  The method for finding these other companies is one of the things that differentiates various flavors of the Distributed track & trace model.

The concept being followed in GS1 US Healthcare‘s EPCIS-based “2015 Readiness Program” is a Distributed track & trace system.  Some flavors of the Distributed model make use of GS1’s future Discovery Services standard and some do not.

Regular readers of RxTrace already know that I am not a fan of distributed models for implementing ePedigree in the U.S. pharma supply chain.  I have several problems with the concept.

The California Pedigree Law requires that each drug sold in the supply chain be accompanied by a valid and complete ePedigree.  If a seller can’t supply one, then they can’t sell the drug.  That means that the value of their inventory is totally dependent on their ability to supply ePedigrees.

In a Distributed model, the seller’s ability to supply a valid ePedigree is totally dependent on each of the previous owner’s ability to respond with their part of the ePedigree at the time of the sale.  The value of the drug can be completely destroyed if any one of them can’t respond.  In my view, that will introduce a level of risk that companies will find very distasteful at best and unworkable at worst.

For more on my concerns about the Distributed track & trace model, see the RxTrace essays in this list.

But when you consider how the Distributed model would fit into the current global situation, with several countries already having adopted their own central repositories, you realize that any adoption of a Distributed model in the U.S. would result in a very mixed model globally.  If the E.U. adopts a Point of Dispense (POD) authentication model it would be even more mixed.

Here is my depiction of that situation.

Figure 2.  Global Mixed Track & Trace Models. Problematic for global manufacturers.  Is it viable?

I’m showing a single manufacturer (blue) and a few distributors (red) and some of their pharmacy customers (black) in the U.S. using a distributed model, and that same manufacturer with a similar mix of distributors and pharmacies in the E.U. using a POD Authentication model.  The drawing shows the same manufacturer communicating with the national repositories of China, Brazil, Turkey and Italy.

This diversity of models around the globe could be problematic for global manufacturers because it will force them to use different approaches and different systems to deal with each model.  Note that U.S. distributors and pharmacies won’t be affected by the different approaches used in other regions.  This is only an issue for the many manufacturers that sell their products globally.

Is the Distributed model viable?  I don’t think it is if you assume it would have to be deployed in every country, thus making it truely global.  Is the mixed global track and trace model of Figure 2 viable?  That’s a question for global manufacturers to answer.  If you focus only on the U.S., a Distributed model would necessitate less rigid regulatory requirements than we currently have in California for it to be viable.

THE SEMI-CENTRALIZED TRACK & TRACE MODEL

The Semi-Centralized model is characterized by multiple “central” repositories of track & trace data around the globe.  What data is stored in each repository, and which repository must be used for a given transaction, is determined by local regulations and/or by the businesses involved.

The national track & trace repositories of China, Turkey, Brazil and Italy fit into this model like a glove.  The track & trace data for any drug that is distributed within those countries would be easy to find…it’s in that nation’s repository.

But in free-market countries where the model would be adopted without national repositories there are a number of ways you could design the implementation.  Most likely, solution providers would enter the business of providing repositories that conform to the regional regulatory requirements.  To solve the problem of a growing number of repositories that each end-user company would need to deal with, other solution providers (or the same ones) would likely offer connection services.

Here is one way a global Semi-Centralized track & trace model might look if there were three companies in the business of offering free-market repository services and six companies offering free-market connection services:

Figure 3. A Global Semi-Centralized Track & Trace Model.   Notice that national repositories, free-market repositories and even POD Authentication fit nicely into this model.

The particular depiction shown in Figure 3 is the version of this model that I originally described in “A Semi-Centralized, Semi-Distributed Pedigree System Idea“, but with more details.  The Free-Market Repositories shown in this example would each contain all of the supply chain history of every serialized instance of specific GTIN’s as determined by contracts with the manufacturers (blue).  Therefore, each manufacturer only needs to connect to that one repository.  This would include GTIN’s that are labeled for sale in any “free-market” region.

For drugs labeled for sale in the U.S., distributors and pharmacies would find the supply chain history in a known location for each manufacturer’s product, but because they would buy and sell the products for all manufacturers, they would each need to connect with all of the free-market repositories.  They would obtain assistance in doing that from one of the free-market connection service providers shown.

In the E.U., POD Authentication would be done by querying the free-market repository that contains the information for that specific GTIN, through one of the free-market connection services.

The complete ePedigree (as defined by local regulations) for a single serialized drug package would always be held in a single repository, whether free-market or national, no matter where the product was distributed in the world.

In this model, global manufacturers would need to connect to a small, fixed number of repositories and could easily fulfill their free-market regulatory obligations, including ePedigree and POD Authentication, through contracts with their chosen repository service provider.  U.S. distributors and pharmacies could count on the availability of ePedigrees to fulfill local regulations like the California Pedigree Law without fear of loss of inventory value.

The Semi-Centralized track & trace model seems particularly viable to me because it solves so many of the problems for global pharma manufacturers without the added expense of GS1’s future Discovery Services.

Interestingly, certain implementations of the Distributed model could actually collapse slowly over time, into a distorted Semi-Centralized model.  This would happen if individual companies get tired of dealing with responding to queries from upstream trading partners and decide to turn that responsibility over to a service provider.  As that service provider increases the number of trading partners they are servicing, the model starts looking more “semi-centralized”.

I’d also like to point out how the Semi-Centralized model can be built over time in stages that each enable some supply chain security and other benefits.  For example, manufacturers could begin by posting only their EPCIS Commission events to their contracted repository service provider and that could enable a number of low cost serial number authentication technologies (cell phone, web page, web services) before the industry moves to the next stage–perhaps POD Authentication.  I’ll talk more about these stages, or “security plateaus” in a future essay.

Which of these global track & trace models is your favorite and why?

Dirk.

3 thoughts on “The Viability of Global Track & Trace Models”

  1. Dirk,
    very thoughtful analysis. The semi-centralized model shares characteristics with the data pools for synchronizing GS1 static data – a model which seems to work (although the number of transactions is far smaller, and the pools synchronize between themselves, eliminating the need for connection services).
    I’m curious what you think the business model is for a free-market repository or connection service – in other words, who pays for what?
    Elliott

    1. Elliott,
      Thanks for your comment. I can imagine several different funding models for a semi-centralized ePedigree system, but in the end it will probably be up to the industry and the solution providers to settle on how they want it to work. One possibility is for the manufacturer’s to pay for the entire cost to the repository provider of their choice. That payment would be per NDC and lot combination and would cover all downstream pedigree transactions that could occur until some period of time after the expiration date associated with the lot. These known values would enable the service provider to calculate their costs fairly accurately and once paid, the service would be provided for all units currently in the supply chain even if the manufacturer went out of business, stopped making the product or sold the product line to someone else. Downstream trading partners would pay fees for connection services but would not have to pay to access or add to the pedigree data for the units that they buy and sell.

      Downstream trading partners (distributors and pharmacies) may not like that funding model because they may fear that it could give the manufacturer ownership rights to all of the pedigree data in the repositories for the units they manufactured. In my view this can be addressed with contract language but I acknowledge that it is a sticking point.

      So here’s another funding model to think about. What if the ePedigree repository service providers didn’t charge the manufacturers anything to handle the ePedigree data for their SKU’s? They would attract manufacturers to their service by differentiating the type and quality of their service to the manufacturer’s customers. The repository service providers would collect fees from the downstream trading partners who must deposit shipping and receiving transactions and request ePedigree reports and perhaps other services. Since the manufacturers don’t pay anything at all they cannot claim ownership of any of the data.

      Of course, a mixed funding model might make the most sense where everyone pays for their contribution of data and their data usage. That way data ownership aligns well with the payments to hold it and make it available to downstream owners.

      Can you think of other funding models?

      Dirk.

  2. Dirk,
    The semi-centralized ePedigree system you’ve described resembles a Federated database system, somewhat a similar architecture evolved by Yahoo, Amazon and Google for email, eCommerce and Search.

    Yahoo open sourced Hadoop leading to bigdata. Amazon’s Dynamo paper inspired a legion of NoSQL databases. Google published Pregel inspiring Graph technologies.

    Yet few of these technologies have entered the traditional enterprise space. About the only enterprise company operating at the level multitennant scalability to push database innovation has been Salesforce.com. The Force.com platform uses an Oracle-on-Oracle pattered database (NoSQL or SQL) advanced thinking circa 2003.

    The ePedigree system for traceability at scale may be the proper use-case to inspire (if not require) the adoption of distributed or federated databases designed for scalability of big graph databases.

    In my opinion it be almost criminal to provision SQL database technologies for ePedigree. Instead we should learn from the online and cloud innovators, and perhaps the national security agencies (they must have rethought long and hard about collecting and sharing data at scale across agencies after 9/11). Though I’m sure incumbents will chase a funded ePedigree opportunity like dogs protecting favorite old bones.

    http://en.wikipedia.org/wiki/Apache_Hadoop
    http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
    http://googleresearch.blogspot.com/2009/06/large-scale-graph-computing-at-google.html
    http://ororke.com/paul/blog/?p=64
    http://accumulo.apache.org/
    http://graphlab.org/

    Next a comment on funding (much harder)

Comments are closed.