Right now there is only one industry standard that can be used to comply with the various drug pedigree laws in the United States. That’s the GS1 Drug Pedigree Messaging Standard (DPMS), which was created in 2006 by a group of technology experts and participants from nearly all segments of the U.S. supply chain culminating in GS1 ratification in January 2007. Many of those companies began using DPMS even before it was ratified because the Florida Pedigree Law went into effect in July 2006. Since then, companies are using it to comply with other state pedigree laws as well as for the pedigree provisions of the federal government’s Prescription Drug Marketing Act (PDMA) of 1988 (stayed until December 2006). Interestingly, a few companies have chosen to require DPMS pedigrees today for trading partner risk mitigation even where there is no existing regulatory requirement to do so.
A few months after GS1 ratified the DPMS standard, they ratified the Electronic Product Code Information Services (EPCIS) standard. This is a more general purpose standard intended for use in all supply chains that have a need to track and trace serialized products. Everyone acknowledges that it doesn’t make sense to try to use it for compliance with PDMA, Florida or other state pedigree laws because they do not require serialization, but in 2015 the California Pedigree Law will go into effect and one of its unique provisions requires item-level serialization. Some see this as an ideal place to apply EPCIS.
There are lots of ways to contrast these two standards and their use for pedigree law compliance, but probably the most striking difference is how they each treat Supply Chain Master Data (SCMD). I defined SCMD in a previous post as “…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.”
GLN as SCMD
Addresses are an example of a “business entity” that can be treated as SCMD. GS1 defines a location identifier they call a Global Location Number (GLN) that can be used to refer to an address. A GLN is a structured series of digits that can be assigned to refer to a single address (among other things). Refer to the GS1 General Specification for the details.
Let’s say your company shipping address is
Acme Drug Manufacturer Corp.
123 Main St.
Anytown, PA 12345
A GLN can serve as a stand-in for that address. For our purposes, let’s say you create your GLN as [gln1]. (Your real GLN would have 13 digits and would not have any letters in it.)
So far you have created a master data (MD) element. Within Acme Drug Manufacturer Corp, anytime you want to refer to your shipping address all you have to do is use [gln1] instead. Your full shipping address would be stored in a master data database somewhere in your IT organization with the index key of [gln1] and the associated full record containing the full text of the address as shown above. The [gln1] identifier is a short-hand method of referring to your full shipping address.
This is classic MD. There are several benefits to the use of MD instead of using the full address everywhere you refer to it. As you can see, the identifier takes up a lot less space than the full address. But perhaps the most important feature is that the identical address will be used wherever you use [gln1] because all references point back to the one place that the full address is stored. If you decide that you don’t like abbreviating the word “Corp.” in your company name, you can change it to “Corporation” in that one place, and, if you are using MD properly, everywhere the shipping address is reference by [gln1] from then on will extract the updated address.
But it’s still not Supply Chain Master Data because you haven’t yet told anyone outside of your organization what [gln1] means. To turn your [gln1] identifier into SCMD, all you have to do is pay GS1 a fee, and then inform your trading partners that you will begin using [gln1] in place of your shipping address as defined above. Now, just start using it in your electronic communications with those partners. Now you have achieved SCMD. You own the ID and the master data behind it. No one else can claim [gln1] and only you have the right to define what it means. Your trading partners can also use [gln1] in place of your shipping address in their electronic communications back to you (and to others if they have also been informed of what it means).
Use of SCMD in Pedigrees
I can finally explain the difference in the way DPMS and EPCIS use SCMD, and it’s now very easy to explain. The EPCIS standard makes use of SCMD and the DPMS standard does not. That’s it.
It’s no surprise that the designers of the EPCIS standard would make use of SCMD. After all, it’s a well-established software architectural pattern and any software professional worth their degree in Computer Science would naturally select an approach that capitalized on it whenever they can. Of course, the fact that EPCIS was created under the watchful eyes of GS1 certainly had an impact too. GS1 owns the GLN and GTIN (Global Trade Identification Number) standards.
But why wasn’t SCMD built into DPMS too? There were plenty of computer science professionals on the committee that produced the standard, and it was developed under the same watchful eyes of GS1. Why such a striking difference?
Requirements Drive Design
Master Data concepts are a powerful computer science pattern, but there is one concept that is a lot more powerful. That concept is the one that says your design must fulfill the requirements. You can create a wonderfully designed widget, but if you needed a doorknob and your widget doesn’t fill the specific requirements of a doorknob, then you have failed. Companies facing U.S. pedigree laws didn’t need a wonderful widget, they needed something that would comply with the laws. SCMD doesn’t comply so it wasn’t part of the design of the DPMS standard.
Use of SCMD doesn’t comply with any pedigree laws because they all specify exactly what must be contained in a pedigree, and this always includes the full address of those who owned and/or had possession of each unit. That eliminates the ability to store this information in a separate database and then simply reference it via a GLN inside the pedigrees. Remember, SCMD makes use of the identifier—the GLN in this instance—as the placeholder for the full information that is only stored in the master data repository. The pedigree laws also specify that each pedigree must contain the full description of the items covered by the pedigree. This eliminates the use of GTIN’s as a reference back to some other database that would contain the master data description of the drug.
Why can’t we just convince the regulators that SCMD is a much more efficient and modern approach to data management? Certainly they would listen to knowledgeable professionals or perhaps an impartial professor from a local university. I think that depends entirely on exactly why legislatures and Congress have created these laws in the first place. But that’s another topic.
I’ll have more to say about pedigree models in future posts, including how we might get those based on EPCIS to comply, in theory. I’ll also speculate on exactly what pedigree laws are trying to accomplish and how that affects the pedigree models used to comply with them.
3 thoughts on “Pedigree Models and Supply Chain Master Data”
In your post you indicate:
“Use of SCMD doesn’t comply with any pedigree laws because they all specify exactly what must be contained in a pedigree, and this always includes the full address of those who owned and/or had possession of each unit.”
There are some whoe would say SCMD could enable compliance with pedigree laws. Continuing your use of the GLN example, the GLN number can be used to retrieve the full address and include that in the pedigree to the regulators when needed.
The benefits of this approach are smaller amounts of data need to be passed between trading partners.
However, there are "persistency" risks with the approach:
– downstream recipients don’t have the full MD. Whoever maintains the MD could change it after the fact.
– at the point the downstream trading partner tries to retrieve the full MD the information may not be available (system down, company no longer in business, etc).
So a key question is whether the reduction in data volumes is worth the "persistency" risks?
I believe the answer is simpler than that. Unlike other systems' designs, where you may get to haggle over the requirements, laws are often pretty strict. If it states that an address is required, than you provide an address, not a pointer to an address.
Being able to use a GLN could require a change in the law or the regulation. We technologists don't get to make this call (even for a reasonable reason like reduced data volumes) if we want to call ourselves compliant with the law(s).
Both of my anonymous commenters are jumping ahead of me. I am planning an essay on what I think state legislatures and Congress are trying to accomplish when they pass pedigree or track and trace legislation. Only by knowing that will we be able to tell whether SCMD ought to be allowed by regulators or not.
As my second commenter rightly points out, unless the regulator explicitly gives you permission in writing to deviate from the text of a law or regulation, you had better follow it as it is written. If the end side-effects of the use of SCMD are in conflict with the reason these laws were created in the first place, no amount of explaining modern software patterns will cause the regulator to bend the rules to allow it.
On the other hand, if there is no conflict, then maybe they will…but don't count on it even then.
Comments are closed.