Who owns supply chain visibility data? Does the manufacturer of a product retain any rights to track that product after it enters the supply chain? What if the product is a pharmaceutical and it is found to have a life-threatening defect? Should technology or standards availability play any role in answering these questions?

These kinds of questions come up occasionally in discussions of track and trace systems design when people talk about the future of “full supply chain visibility” and how easy recalls will be executed because of it. The implication is that the manufacturer of a drug will be able to perform a targeted recall because they will be able to see exactly where their product is in the supply chain.

But one could easily make the argument that it is no longer “their product” once it enters the supply chain. True, they invented, manufactured and labeled it, and in a recall situation we all have a strong desire for them to get it back quickly and efficiently, but that doesn’t change the simple fact that they don’t own it anymore. And if they don’t own the product anymore then they don’t automatically own the knowledge of where it is either.

I’m not a lawyer but it seems to me that once a product is sold the seller gives up all rights to that product. The buyer can do whatever they want to with it, within the law of course. Recalls that are necessary for reasons that might be life-threatening are special and supply chain members should do everything they can to find and return any item that is involved in a recall. But is it necessary for the manufacturer to have instant access to the location of all of the affected product?

Serialization and track and trace will allow all supply chain participants to know a lot more than they do today about the location of recalled items just using the data that they clearly own. Compared with today, an individual company will know very quickly if they have ever received, shipped or currently have in stock the recalled units. If they currently have them in stock they will be able to place an immediate hold on those items to prevent them from being shipped to a customer until they have been collected and returned. If they have previously shipped the items to a customer they will know exactly which customers were involved and which unit went where. But that’s it. The knowledge of what their customers might have done with those products once they receive them is not owned by the seller.

WHO OWNS WHAT DATA?

I think it’s clear that each company owns the data that they create. Would anyone dispute that? But some of that data is shared with trading partners in the normal course of the selling and buying process. In that case, one could argue that both the buyer and the seller subsequently own that data. For example, the fact that pharmacy X bought drug Y from wholesaler Z is data that is known through direct experience by both X and Z. Did either company “create” that data? It seems to me that both X and Z can rightfully claim to own this data. Unless somehow bound by a contract, either one might choose to sell that data or give it away for free without consulting or negotiating with each other.

If data such as the one in my example above has value then it can be treated as any other asset that can be packaged, priced and sold. Today, supply chain data similar to this is collected, aggregated, priced and sold under terms that are determined by contracts.

THE VALUE OF SERIALIZED SUPPLY CHAIN DATA

But what about tomorrow? Things might get interesting when the sales transaction in my example above includes item-level serial numbers. The data available for that transaction would now include serialized references to the prior history of each item. Would that add any value to the original, non-serialized data? Depending on the needs of the data buyer, I think it might.

Now, I’m not predicting that data needed to properly execute a recall would ever be held for ransom. All I’m saying is that the supply chain visibility data that will come from serialization and track and trace technologies might have more value than the current data that is a source of revenue for some companies. This information is like any other intangible company asset. For this reason we should acknowledge that data ownership must be recognized and retained in the track and trace systems that we design for the future or those systems are unlikely to be adopted widely.

What does this mean for the ability to execute recalls efficiently in the future? I’m confident that supply chain visibility for recalls can be achieved without having to give data away at a financial loss, but it will require very selective visibility–some might call it selective blindness. With serialization and a well-designed supply chain track and trace system, recalls will execute very fast and efficiently without the need for end-to-end supply chain visibility by any single party.

GS1 has spent the last two years collecting end-user requirements for their next crown jewel standard, Discovery Services. Discovery Services, as envisioned by GS1, will be the cloud computing service that supply chain companies will go to initially to get more information about a serial number in their possession. I was a member of the requirements work group early on but I was unable to stay involved so I lost track of exactly where their efforts ended up. Having missed out on the development of these requirements I’m hoping that they strongly support the concept of data ownership. If that’s not in the completed requirements then the future standard may not be very attractive to some supply chains.

I understand that the GS1 Discovery Services standards-making work group is just about to kick off its work. If you have an interest in track and trace and/or data ownership, I suggest that you join. I’m going to.

Have a Happy New Year!

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

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

GLN’s On Electronic Invoices

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

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

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

GS1′s GDSN (Global Data Synchronization Services Network) is a standard way of performing this synchronization between parties for GLN’s and for GTIN’s (Global Trade Identification Number). Subscribing to a service that conforms to the GDSN standard ensures that each trading partner has the current full data set that the GLN and GTIN’s refer to, as defined by their owners.

Applying the full addresses on each electronic invoice may seem like a throwback to the past when all invoices were printed on paper, but it really serves to freeze the identification of where each participant in the transaction was located at the time the invoice was executed. It provides a greater level of common understanding and contract enforcement because there is no doubt about what is intended by the invoice. The addresses on the invoice can’t change overnight.

GS1 publishes rules for exactly what changes should result in the generation of a new GLN and what changes can be made to existing GLN’s, but these are just guidelines. As I’ve said before, no one polices the data behind each GLN, so if you want to make sure the record of your transaction is perfectly static, even if you use a GDSN service, your electronic invoice should specify exactly which addresses were used at the time of the transaction. If tomorrow, an owner of one of the GLN’s used on your invoice changes the meaning of their address (as an owner of that GLN might choose to do, rules or no rules), your invoice is still accurate because, at the time it was created, the GLN meant what you put on the invoice.

Use of GLN’s and GTIN’s simply to keep your local copy of their meaning up-to-date through a GDSN compatible service is not true SCMD. It’s just a way of keeping your local MD up-to-date. The fact that you use the data set behind GLN’s (and presumably GTIN’s as well) in the invoice is distinctly different than if you had only used the GLN’s (and GTIN’s) by themselves.

Using only the GLN’s and GTIN’s on an invoice…now that’s true SCMD.

GLN’s and GTIN’s On Pedigrees

So what does this tell us about the use of GLN’s and GTIN’s in pedigrees? I look at it this way. If you wouldn’t use GLN’s and GTIN’s as SCMD on an invoice because you want the extra measure of common understanding and contract enforceability that the full address and product description gives you, then why would you use them as SCMD on pedigrees? Pedigrees should contain at least as much common understanding and clarity as invoices because they exist to protect patients. Any measure that increases their effectiveness should be employed.

Further, use of GLN’s and GTIN’s as SCMD on a pedigree introduces ambiguity that a criminal can hide behind and challenge in court. For this reason, pedigrees should always use full addresses and the full product information (the product information specified by the regulation, that is).

SCMD and Pedigree Models

Regular readers of this blog will know that GS1′s DPMS (Drug Pedigree Messaging Standard) is the only standard that currently exists specifically for use in compliance with U.S. pedigree laws. And if you read my post “Pedigree Models and Supply Chain Master Data” you know that DPMS does not make use of SCMD. That is, in keeping with the importance of full traceability that is encoded in the various U.S. pedigree laws today, DPMS requires full, explicit addresses and all of the regulated product information on every pedigree.

You will also know that the GS1 EPCIS (Electronic Product Code Information Services) standard does make use of SCMD for GLN’s and for GTIN’s. But from conversations and debates with my friends and colleagues over the last month or so I have come to the conclusion that, if EPCIS were to be used in the future as the basis of an alternative pedigree model, we will have to ignore its use of SCMD. That’s because SCMD is inconsistent with the goals of pedigrees.

But that’s OK. It’s easily fixed. EPCIS makes use of SCMD out-of-the-box because it is designed to be used by many industries for many purposes. Pedigree is only one of many theoretical future uses. There are lots of other possible applications that would benefit from taking advantage of the lightweight characteristic that is inherent in the SCMD concept.

As a general purpose standard, EPCIS is designed to be tailored to the needs of any specific track and trace application, so all this means is that to use it for pedigrees, we will have to add full addresses and some of the product (as regulated) information so that it results in the same level of explicit clarity as the pedigree system that is built into DPMS.

One more thing. The stated benefit of using SCMD is the reduction of data storage needed to hold all of those repeated addresses in all of your invoices and/or pedigrees. But all it takes is some creative thinking by solution providers to reduce the number of copies stored of each unique address to exactly one. This eliminates all of the repetition but retains the benefits of using explicit addresses. Space-saving is not a significant benefit of SCMD when this approach is used instead.

I really enjoy discussing and debating topics like this with my friends, but I encourage everyone to jump into the conversation by posting a comment in reply below. Or just sent me an email directly.

Earlier this year The Association for Healthcare Resource & Materials Management (AHRMM) and the Center for Innovation in Healthcare Logistics (CIHL) at the University of Arkansas published the results of a survey they conducted in 2008 titled “The State of Healthcare Logistics”. The survey polled 1381 healthcare supply chain professionals regarding their “perceptions of cost and quality efficiencies and improvement opportunities within their organization”. I’m always a little skeptical (alright, I’m a lot skeptical) of “perception surveys”, but since this one was focused on the specific supply chain that I’m a member of, I took some interest. This survey included a series of questions about the respondent’s perception of Data Standards, which really caught my eye.

In fact, I’ve been doing a little investigating myself into the competing standards that are related to supply chain master data. My career experience in this area has almost solely dealt with GS1 standards, but that may be because the healthcare part of my career has centered on the pharmaceutical distribution corner of the full healthcare supply chain. If it had been centered on the distribution of medical devices, I would have been much more familiar with HIBCC (Healthcare Industry Business Communications Council) supply chain data standards. I’ve been trying to figure out if the industry needs multiple competing data standards and, if not, which one is a better set: GS1 or HIBCC? And should I consider some other set of standards that I just don’t know about? Are there good reasons to continue the use of either or both sets of standards in our supply chain?

In this light, I turned my attention to the AHRMM/CIHL survey results, hoping to gain some valuable insight. I quickly got stuck on their very first survey question in the Data Standards section (on page 15 of their report):

A. Is your organization moving towards the adoption of a data standards system (such as GS1) in the next five years?

Now this is an amazingly bad survey question that wouldn’t even pass a “survey questions 101” class. It is a classic example of a leading question. One where the desired answer is provided directly in the question itself. But look at the choice of answers!

1. Yes – GS1
2. Yes – Other
3. No
4. Don’t Know

Wow. Clearly this survey is trying to lead the respondents to indicate support for only GS1 data standards, and it worked. Over 50% of the respondents chose answer “1”, over 30% chose answer “4”, and about 20% chose answer “3”. What about answer “2”, indicating support for “other” data standards systems? Only about 3%.

But the authors go further. Here is part of the analysis provided in the report for this survey question:

“The majority of those that indicate that they are moving towards a data standards system other than GS1 do not know which system their organization is moving towards.”

Maybe that’s because they didn’t tell the respondent which “other” systems are out there. I’m assuming that the authors were just a little sloppy and failed to include in the report the additional question(s) that provided them with this extra information.

I wonder what they would have found if they had asked the question this way:

B. Is your organization moving towards the adoption of a data standards system (such as HIBCC) in the next five years?

1. Yes – HIBCC
2. Yes – Other
3. No
4. Don’t Know

My bet is that the results would be nearly the same.

In general, perception surveys don’t deserve much weight. This one provides a perfect example of why, and this one question destroys any remaining credibility this survey could have had. For this reason, this survey contributed absolutely nothing to my own investigation into systems of standards and it answered none of my questions. That’s sad, because I’m sure there are many other people in the supply chain who are having the same thoughts right now, and we could use some solid, unbiased information about the pros and cons of each choice.

This report has inspired me to construct my own perception survey:

C. Which standards organization (such as GS1) is most likely to have directly or indirectly funded the survey that generated Question A.?

1. GS1
2. Other
3. No
4. Don’t Know

D. Which public university (such as the University of Arkansas) should be most embarrassed by the construction of Question A. and the conclusions drawn from it?

1. The University of Arkansas
2. Other
3. No
4. Don’t Know

For more of my essays related to HIBCC, click here.

We need to make a clear distinction between traditional Master Data (MD), Supply Chain Master Data (SCMD), and Instance Data (IData). This will help us understand some important differences in various supply chain track and trace technologies.

Master Data

Wikipedia defines “Master Data” like this today:

“…Master Data is that persistent, non-transactional data that defines a business entity for which there is, or should be, an agreed upon view across the organization.”

This isn’t detailed enough for me. MD must include a data element that serves as an identifier. An identifier that refers to a given MD record must be unique within the organization.

Good candidates for MD are customer information, location information, product information and employee information. The characteristic these all have in common is that the data behind them rarely change. For example, I have been issued an employee number by my company. My employee number is the unique identifier for the MD that describes me to the company. My mailing address, phone number, marital status, social security number rarely change.

Most organizations make use of MD so that they can maintain the definition of these entities in a single place, and they can simply refer to these definitions through the corresponding unique identifier. The identifier provides a quick way to get to the full set of information. In many cases, the identifier can serve as a stand-in for the full set of information.

Supply Chain Master Data

Wikipedia doesn’t yet have a definition for Supply Chain Master Data. I’ve coined the term to describe something that is similar, but distinctly different than Master Data as described above. I’ll define it like this:

“Supply Chain Master Data is that persistent, non-transactional data that defines a business entity for which there is, or should be, an agreed upon view across the supply chain.”

The only difference from the definition of MD above is that the definition of the business entity spans the supply chain, not just a single organization. For that to work, you need a standard so that everyone agrees on the definition of the data elements, the identifier and the rules for maintaining the data.

GS1 has defined the GLN (Global Location Number) standard for location identifiers and GTIN (Global Trade Item Number) for product identifiers. When you combine these standards with their GDSN (Global Data Synchronization Network) standard, you have what I have defined as SCMD. The GLN and GTIN standards are carefully defined to ensure that every identifier created by any entity in the supply chain is unique from every other one.

To learn the full details of these GS1 standards, including the rules that surround them, you have to read the GS1 General Specification. GS1 likes to sell it to you, but you can usually find it for free download by searching for it on the internet.

An important characteristic of SCMD that differentiates it from simple MD is that it has a property of ownership. That is, instances of SCMD may be used by entities throughout the supply chain, but each instance is owned (controlled) by only a single entity–the one that created it in the first place.

For example, the manufacturer of a product will generate (create) a GTIN identifier for that product and they will fill in the pertinent data fields that describe it. The manufacturer will use a GDSN service (or some other means) to distribute the SCMD to its trading partners for their use, but only the manufacturer has the right and the responsibility to maintain the content of the data associated with the GTIN. This is pretty easy because, like MD, SCMD should rarely change.

Also like MD, supply chain transactions will often refer to the product only by its GTIN as a shorthand way of referring to the full set of information contained in GDSN for that product.

Understanding the concept of SCMD and its characteristics is very important when discussing the characteristics of various pedigree models. I will finally return to the discussion of those in one of my next posts.

Instance Data

Instance Data also doesn’t have a definition in Wikipedia yet, but the name and the concept has recently been raised in some of the work groups within GS1. Here is my definition:

“Instance Data is data that is specific to a small set of instances of a particular serialized object class.”

IData is not a type of master data because there is no identifier involved and so there can be no separate set of information that describes it. Instead, it is simply data that can vary across each instance. For example, a serialized pharmaceutical always has a lot/batch number associated with each unit. A finite set of the serialized instances share the same lot/batch number (an “instance” is simply a single unit of the product).

I can’t think of another real example of instance data, but I suspect that once item-serialization becomes widespread there will be more types of IData defined. One possibility would be for a manufacturer to vary some characteristic of their covert anti-counterfeiting mechanism so that each unit of a product would be more unique than it is today. This IData would indicate which units received which polarity, or which color, or whatever characteristic that is being varied. This type of IData would not be shared with supply chain partners but would be retained by the manufacturer for use in an authentication scheme. Of course, IData can only exist if every unit has a unique serial number on it.

I hope this hasn’t been too technical for you. If you’re still reading, well done. You are now prepared for the next level of discussion of pedigree models.

I’ve been an active GS1 participant since EPCglobal was first acquired by GS1 in 2003. It is an interesting organization, often both vital and frustrating at the same time. GS1 is a single source for essential supply chain standards that have global applicability. Rather than attempting to dictate those standards they invite people and companies to work with them on the definitions and the application of their standards. They have really great facilitators for some of their work groups with the very best being Mark Frey and Gena Morgan. The quality of their standards documents is quite high. And they have some really smart people in their EPCglobal Architectural Review Committee (ARC), notably Ken Traub, John Williams and Sanjay Sarma.

My hope is that this blog will be of some value to both members and non-members of GS1, but, I can only cover topics related to the organization and their public documents. Specific details about work group activities cannot be covered. However, I do not think that is too limiting and I think members and non-members will find something of interest.

GS1 is a not-for-profit member organization. The way it is organized reminds me of something out of the UN with affiliate “Member Organizations”, or M.O.’s—one for each country in the world—which participate in developing and maintaining their global standards on behalf of end-user companies within their borders. End-user companies are also able to represent themselves … if they can afford the membership fee which is based on company global revenue (and that’s on top of the fees paid for use of your GS1 Company Prefix). Consequently, standards development proceeds mostly with input from employees of GS1 affiliates and from employees of large corporations. There are notable exceptions and GS1 has made a significant effort to recruit participation from hospitals and smaller pharmacies, traditionally under-represented because they are small.

My own experience as one of those employees of an end-user member company, who has participated in standards-making work groups and the end-user groups within GS1 and EPCglobal, has been very positive. I have met and collaborated with a wide range of very smart people from my own industry and others, from the U.S. and from around the globe. I’ve learned a lot about supply chains in general and about how to perform the kind of “techno-negotiations” necessary to move forward a work group of people with very diverse backgrounds and interests toward a positive conclusion. Sometimes it’s thrilling. Sometimes it’s aggravating. It’s always a lot of hard work, but I highly recommend it to anyone considering it.

GS1 also runs “adoption” end-user groups out of their M.O.’s. The purpose of these groups is to encourage the adoption of GS1 standards within the country that the M.O. represents. For example, the GS1 U.S. Member Organization operates the GS1 Healthcare U.S. group which has work groups targeted at accelerating the adoption of GTIN, GLN, GDSN and Traceability the GS1 way in the healthcare sector. These work groups do not work on standards, but they work on guidelines for use in applying those standards to solve various supply chain problems within the U.S. (also known as “toolkits”).

Actual standards have traditionally been developed in two different sub-organizations of GS1: EPCglobal and GSMP (Global Standards Management Process). GS1 is currently in a state of transition as they move the standards development arm of EPCglobal into GSMP. That’s a good thing, because these two organizations have had different approaches and, at times, seemed to operate as two independent organizations. Unfortunately, in my view, EPCglobal’s process operated better than GSMP. So far I am encouraged by the little evidence I have seen that they are retaining the good parts of the EPCglobal approach. We’ll see how far it goes.

One very commendable thing that EPCglobal has done that GSMP has not is to make their ratified standards documents freely available for download on the internet. The GSMP approach is to roll all of their diverse standards into a single and very large document known as the “GS1 General Specification” (or, “GenSpec”) and they’d like to charge you for a copy of it. Fortunately there are enough M.O.’s around the world that make it available that you can usually find a copy for free download by simply Googling it. I hope that the merged GSMP does not fold the individual EPCglobal specifications into the GenSpec and keep them hidden until you pay, but I must admit, even ANSI and ISO charge for their ratified standards documents.

GS1 also has a lobbying arm which applies pressure to governments around the world to adopt policies that are favorable to GS1 and the technologies that their standards are based on. For example, they applied considerable effort to get governments around the world to open up RF frequency bands around 915MHz so that UHF passive RFID tags could operate worldwide without violating the law somewhere. They have been very successful in that effort, as I understand it.

Another example of GS1 lobbying is when they act as technology experts before U.S. state and federal regulatory agencies. Here GS1 provides guidance toward the adoption of regulations and laws that can be met through the use of their standards. I get a little concerned about this type of lobbying because I fear that GS1 makes themselves out to be unbiased when, in fact, they do have a bias. I hope these agencies are aware of that and take it into consideration.

GS1 will be a frequent topic of this blog since they are focused on the same “intersection” as I am (see the tag line for this blog on the masthead).

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

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

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

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

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

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

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

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

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

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