For the first time since GS1 produced the Drug Pedigree Messaging Standard (DPMS) standard in 2005, GS1 has just published a call-to-action for the formation of a new standards development group to focus on a new pedigree-related standard. The new group will be called the “Pedigree Security, Choreography and Checking Service (PSCCS) Mission Specific Work Group (MSWG)”. According to the call-to-action:
“This group will develop standards to allow pharmaceutical supply chain parties striving to meet pedigree regulation requirements, by gathering and checking pedigree event data. Standards will also address data confidentiality and security. This MSWG will create
A) standard for security framework applicable to EPCIS and,
B) pedigree checking services.”
This group’s output will not be a self-contained pedigree standard, per se, but it will be components that are known to be necessary before GS1’s Electronic Product Code Information Services (EPCIS) standard can be used as the basis for large-scale ePedigree systems. These components could be used for many of the seven ePedigree models that the GS1 Healthcare Network Centric ePedigree (NCeP) work group identified last fall, including any model that needs any kind of centralized service to operate. This includes the Centralized, Semi-Centralized and the Distributed models that need discovery services and/or a checking service.
The “standard for security framework applicable to EPCIS” component would have many similarities to the security framework that was being developed for the unfinished GS1 Discovery Services standard and so all of the work that has been done toward that standard will likely be immediately transferrable to this new effort. The security and access controls of pedigree data turns out to have a lot of technical characteristics in common with that of data discovery.
The “pedigree checking services” component would result in a flexible framework to allow users to define a set of checks necessary for compliance with whatever law is applicable in a given locality so that the same service could be used everywhere. The framework would allow users to easily check ePedigrees supplied by upstream trading partners to determine if they comply with the applicable regulation in the pertinent locality.
Because these frameworks will be designed to work with centralized, semi-centralized and distributed models, pedigree acquisition and exchange are not part of this effort. The standard(s) that will result from this effort will not actually result in full ePedigree standards, but they will be prerequisite components for full NCePs.
This is pretty big news for companies in the pharmaceutical supply chain at least, and probably those in a number of other supply chains that would benefit from pedigrees. But just because there was a call-to-action doesn’t mean that the group will form and begin work anytime soon. GS1 has strict minimum participation rules before any of their work groups are allowed to proceed. Until a sufficient number and mix of companies sign up the group will sit dormant and waiting. The call-to-action lists the following needed expertise:
“Expertise Needed: The group should be comprised of trading partners from all sides of the trading relationship as well as subject matter experts that have familiarity with one or more of the following:
- Security Frameworks for networked information systems
- Authentication techniques and standards (e.g. SAML)
- Access Control techniques and standards (e.g. XACML)
- The GS1 EPC Information Services (EPCIS) standard
- Industry/country regulations for traceability (e.g. pedigree, authentication)”
I plan to participate.
WILL IT WORK FOR CALIFORNIA?
The California Pedigree law doesn’t specify how ePedigrees must be implemented except to identify their contents at a data field level. The standard(s) that this new GS1 effort may result in could theoretically be used to assist companies with compliance with that law. However, it isn’t the only necessary standard that is missing right now. We would also need a standard that would specify exactly how to construct, store and exchange EPCIS events to conform to whichever NCeP is being implemented in a given locality.
GS1 is on a path that, we hope, will lead to the ability for companies to develop interoperable applications that implement one or more of the seven EPCIS-based NCePs. Once they arrive at that point, whether the systems that result will allow users to comply with specific ePedigree laws like the one in California is hard to say.
The California law is particularly problematic because, like the Florida pedigree law, it assumes an exchange of electronic pedigree “documents”. The GS1 DPMS pedigree standard was designed to implement that approach and so it is known to be usable for compliance (assuming it is applied properly). But it would likely be necessary for California to either change their law to accommodate the use of an NCeP for compliance, or adopt a well-defined approach to “enforcement discretion” that would allow it. In other words, don’t hold your breath. See my essays “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 1 and “…Part 2”.
The real value of this effort is to provide other regulatory bodies—like the FDA and all of the other countries in the world that haven’t yet enacted a drug pedigree requirement—with an idealized model, or set of models, that have technical characteristics that enable the exchange of pedigree information in a secure and efficient way that is standards-based and interoperable.
HERE’S THE PROBLEM WITH THAT
But there is a problem with that for GS1. I noted in my last RxTrace essay, “FDA Proposed UDI: The GUDID Database”, that GS1’s Global Data Synchronization Network (GDSN) was a poor candidate for the FDA to select as their proposed Global Unique Device Identification Database (GUDID) because, among other reasons, GS1’s GDSN only works with GS1 Global Trade Item Numbers (GTINs). By selecting GS1’s version of a supply chain master data (SCMD) repository and distribution standard for the GUDID they would be requiring all medical device companies to switch from the other UDI “issuing agencies” and only use GS1 from then on.
Obviously the FDA can’t do that because so many companies have invested in the use of UDIs from the Health Industry Business Communications Council (HIBCC) and the International Council for Commonality in Blood Banking Automation (ICCBBA), and probably others. A U.S. government agency can’t force everyone to exclusively use some single third-party for-fee service because it would be anti-competitive.
So likewise, how could the FDA ever mandate the use of some future GS1 pedigree standard that would require the use of only GS1’s SGTIN as the unique drug identifier? They can’t. They won’t. One way it could work is if the GS1 pedigree standard allowed the use of both GS1 and non-GS1 globally unique identifiers. That would be a hard pill for GS1 to swallow. They can’t. They won’t.
Another way for it to work would be if the GS1 pedigree standard was just one of multiple ways to fulfill the potential future FDA pedigree requirement, much like the way that a GS1 SGTIN is just one of multiple ways to fulfill the FDA’s Standardized Numerical Identifier (SNI) guidance. Like SNIs, it would be essential that any future pedigree technology be fully interoperable with all other systems in use within the same locality. Interoperability between different SNI systems is practical. Interoperability between different ePedigree systems is not.
So is it futile for GS1 to develop standards for NCeP? In some ways, yes–the standard(s) will probably never be wholly adopted by the FDA or other large countries because of the problem I raise above, but at least someone is working on it. This raises bigger questions, like:
- Shouldn’t application standards like the FDA GUDID and ePedigree be developed so that they are able to use any conforming globally unique identifiers?
- Are organizations who are in business to promote their own proprietary unique identifier, like GS1, the right place to develop open and interoperable standards for government regulated applications—particularly those that would be best implemented on a global scale—like ePedigree?
- Should GS1 continue developing ePedigree standards?
How would you answer these questions? Leave a comment below.
2 thoughts on “Should GS1 Continue Developing ePedigree Standards?”
Suggest GS-1 not over-reach by trying to develop a standard which would lock industry into licensing ONLY GS-1 or otherwise lock industry into paying fees to GS-1. To the best of my knowlege and belief:
The fees assessed by GS-1 are, set at the sole discretion of GS-1.Those fees are substantially higher than HIBCC. HIBCC could also change their fee structure. That may be why FDA has indicated that they would allow and might evenm have to define other systems.
Small and medium sized enterprises (SMEs) have little role in the GS-1 process. While SMEs are engines of innovation, limitations on the resources of SMEs restrict their ability to participate in GS-1 and like organizations. SMEs have historically not participated in the ISO process. Hopefully that will change. Several trade and professional associations which include SMEs are discussing the importance of participating in the standrads process.
I hope to learn more in Orlando about what ISO and other organizations are doing in standards for UID of medical products.
Great to finally meet you in Orlando.
We discussed that not-for-profits, like GS-1 and HIBCC can play a valuable roles in assisting with a societal or governmental functions, but that they can abuse their position. Examples of such abuse are Fannie Mae and Freddie Mac in the US housing market and the British Banking Association (and/or their members) in the LIBOR manipulation.
I suggest that the fees of the UDI issuing agencies be published, that restrictions be placed on issuing agency fee increases, and that no harmonized country (IMDRF) should be allowed to restrain trade by mandating any one isuing agency. Thoughts?
Comments are closed.