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