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.
- IBM
- SAP
- Oracle
- Microsoft
- Frequentz
- GHX
Dirk.
Always good to see your insights. Who has signed up? Will you go to mHIMSS?
Thanks for you insightful, if speculative analysis. Which company? IBM?
Thanks Lew
I have not seen the internals of ITS, but I expect the relational database would only be part of the issue in deploying in a cloud.
I think there is a huge distinction between a system that itself is implemented on a cloud infrastructure versus one that is effectively a traditional SaaS that calls itself a cloud to the market. Calling something cloud doesn’t allow it to shed its baggage of being old technology and in the end its customers have to pay for its inefficiencies.
By implementing a solution with a modern architecture on a cloud, you can pass on benefits to your customers in terms of capability, flexibility, scalability, availability, and cost that the other guys simply can’t match (at all or without spending a lot of money).
I agree with Peter,
But to put it more simply…
a “non-traditional cloud-based repository” will still use a “relational database”.
The transaction volume spikes that you talk about will still need to be handled by an IT group somewhere. Only different their infrastructure will be used to handling large volumes assuming you put the repository with a big “cloud”! but a local group if they spend a lot can handle it as well.
Interesting article, Dirk. I would assume that it will be just a matter of time that big data and Cloud come together in one solution…
Is it GHX?
Dirk,
In the current market, there are quite a few solution providers who provide cloud based access for track and trace. A notable mention in pharma market in Tracelink. Even though, they use cloud – they will use traditional servers and relational database (although will leverage from providers like Amazon EC2, Azure, etc.). The cloud is the ‘single’ answer to the problem of connecting diverse databases of a vast complex supply-chain. Can’t IBM offer that?..you bet they can. Maybe this spin off is to make their offering light, yet realize more profitability by delivering software solutions that are hardware agnostic. That’s what they do best and continue to do so.
Dirk,
First of all, we are the only distributor of IBM ITS before sold it to Frequentz. ITS can be run in the cloud. I do agree that the only way to make e-Pedigree work is the cloud. Only in US that the supply chain is short and efficient. In Europe, the drug sold over internet has the large share of the market and the industry is fragmented. IBM is too big for running SaaS and it will make the price too high. The money is in service for large coporations and hospitals to link up with the e-Pedigree cloud. Since the sale of ITS is not published, I bet that IBM will have some percentage of the e-Pedigree cloud that it will offer. It is a win-win and a head start over competitors!!!