At times like these I often think of an old movie from 1981 called “Modern Problems” which starred Chevy Chase as a hapless air traffic controller who faced problem after problem, some of which wouldn’t even have existed 20 years earlier. For some reason I can’t explain, I sometimes think of that movie when I’m about to click the “Publish” button on an essay. As soon as that button is clicked, my thoughts are instantly transmitted to the world (hundreds of people in the case of RxTrace) in a neat little package.
Almost immediately after clicking the Publish button on last Friday’s essay, “IBM Divests EPCIS and ePedigree Suite” I had thoughts of another possibility that IBM’s recent action might explain. Too late. My thoughts were already being read by people. A “modern problem”. Fortunately I can send this follow-up.
Like a commenter to my Friday essay, I wondered why IBM would chuck their entire traceability repository product if the problem were simply that ePedigree only makes sense for boutique solution providers? They could have just sold off the ePedigree application and kept the more generally marketable ITS product. There has to be more to it than that.
MY NEW THEORY: THE CLOUD
Here is my new theory. It may be that the experts at IBM have concluded that it doesn’t make any sense to store track and trace data in a traditional local relational database, such as the one that their Infosphere Traceability Server (ITS) was built around (IBM’s DB2 product), and that it makes much more sense to store that kind of data in a non-traditional cloud-based repository. As transaction volumes spike, there are too many bottlenecks and limitations in a traditional relational database server, and so performance suffers as the volume of data already stored there goes up.
Cloud-based repositories are perfect for high transaction counts from a large number of users, especially those that make use of Hadoop and MapReduce, technologies that some companies who offer internet-based services have been focusing attention on lately. In a full supply chain track and trace application there will potentially end up being massive quantities of transactions, each having very low value by themselves. It isn’t until something like a chain-of-custody trace report, or an ePedigree must be generated that the specific individual transactions involved elevate in value.
But traceability applications would only involve truly massive numbers of these transactions if they were kept in a centralized or semi-centralized multi-trading partner cloud-based nationwide repository rather than in a distributed manner as would exist in the traditional GS1 model. In that traditional model each supply chain member would hold their traceability data in their own local EPCIS-based repository (like ITS) and they would respond to query requests from upstream and downstream trading partners.
Some people are starting to recognize that the traditional GS1 model is a brittle and may even be an unworkable approach, and so I think that larger, centralized traceability data repositories are looking more likely in the future. See my essay “The Viability of Global Track & Trace Models”.
If this is what IBM has concluded, then their ITS product—which uses a traditional relational database design—was implemented using yesterday’s technology and an entirely new architecture will be needed going forward.
DOES ANYONE HAVE A PRODUCT THAT USES THIS NEWER APPROACH?
There already exists an of example of a traceability service that makes use of this kind of cloud-based approach and I have written about it before. It is a prototype that was built by the Global Healthcare eXchange (GHX) as a trial service that uses the GS1 Electronic Product Code Information Services (EPCIS) interface standard to implement a centralized event exchange service. See my essay, “Could This Be Your Future Track & Trace/ePedigree Exchange Solution?”.
The GHX service could be used as a simple event exchange hub. But if the industry and regulators eventually embrace one of the GS1 Network Centric ePedigree (NCeP) models that are compatible with some form of a centralized approach (fully central, semi-central and at least one of the distributed models), GHX could tweak their service to offer such a repository. They have implemented it and tested it with the kinds of massive quantities of transactions that you would expect of that type of service and they have apparently proved that it will be able to handle them just fine.
Earlier this year GHX worked with Abbott Labs, McKesson and the Veterans Administration to test the system using a small amount of data. The pilot team delivered a group presentation about their experiences at a recent GS1 US meeting and I hope to write more about that in future essays.
Other vendors of serialization and pedigree applications offer Software as a Service (SaaS) models that host the software and the data repository, but these are generally still using traditional database servers to hold the data. As far as I know, only GHX has gone the non-traditional route.
Of course, there is always the caveat that we are talking about track and trace data here and not necessarily ePedigree (see my essay, “Terminology: Track and Trace, and Pedigree”). It isn’t clear if the California Board of Pharmacy will accept simple track and trace data in place of a document-based ePedigree as their law defines it. I’ve gone on record in the past saying that EPCIS alone won’t be usable to meet that definition in the California law, but perhaps the Board of Pharmacy will give in to industry pressure and reinterpret their definition to accept EPCIS events. (See my essays “Why GS1 EPCIS Alone Won’t Work For California Pedigree, Part 1” and “…Part 2”.)
One clue to IBM’s motivation in this recent move might be to look at which companies have recently signed up for the latest GS1 work group that is yet to be kicked off, which will develop components necessary for an NCeP. That group is called the “Pedigree Security, Choreography and Checking Service (PSCCS) Mission Specific Work Group (MSWG)”. Any company looking toward this future cloud-based approach would probably have already signed up. Those who aren’t paying attention probably would have pass it up so far.
So which one company from the following list do you think is already signed up at this moment for the PSCCS? Send me an email and I’ll tell you.