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.

Dirk.