Substitutability is a property of software applications that allows the users of such systems fine grained choice and control of the way their computing environment works for them without. This is in marked contrast to existing healthcare applications, particularly electronic health records which are typically monolithic and do not allow substitution for functions by other vendors without extensive technical support, it at all possible. I review here early questions that follow from the adoption of a substitutability model in health care information technology.
Authors
Published
Creative Commons Attribution 3.0 License
Version 6
Last edited: Oct 5, 2009
Exported: Aug 16, 2012
Original URL: http://knol.google.com/k/-/-/3i90c8q8d11mj/1
Introduction
In the fall of 2008 after the electoral victory of the Obama administration it became apparent that there was going to a very large investment, as promised in the campaign, in the implementation of electronic health records. With my colleagues, I wondered what single bit of guidance would most insure that this investment would be durable and create the conditions necessary for growth and richness and capability of electronic health records but more broadly automation in health care. The obvious idea that we bandied about was the enforcement of interoperability. This, the technical capacity of one system to “talk” to another system such that data is preserved accurately seemed like an obvious stipulation. On reflection it seemed insufficient. After all, not only have standardization efforts been underway (that include a huge academic industrial establishment including committee meetings, national meetings, and regulatory meetings) for the last thirty years, but also many commercial vendors had already undergone extensive and expensive technical compliance and certification efforts. Yet it was obvious to anybody involved in the purchase or implementation or deployment of health automation systems that sharing data across different vendor applications or systems was difficult, at best. Despite certified interoperability with existing standards, achieving true data liquidity (the untrammeled flow of data across applications from different vendors) required at least extensive collaboration and cooperation with the vendor and better yet extensive onsite expertise in systems integration. It then occurred to me that interoperability was not the necessary precondition but it was a quite different property that could eventually lead to interoperability. That property is substitutability.
Substitutability is the capability inherent in a system of replacing one application with another of similar functionality. A deep commitment to substitutability enforces, of necessity, several important features. Most importantly it puts the consumer or purchaser of these applications in the “driver’s seat” in defining what constitutes appropriate substitution. That is because substitutability, as we have come to define it, requires that the purchaser of an application can replace one application with another without being technically expert, without requiring re-engineering other applications that they are using, and without having to consult or require assistance of any of the vendors of previously installed or currently installed applications. It did not matter if the applications that substituted for a previous one did not mirror its functionality perfectly. In fact the lack of equivalence might be a virtue when in allowed for true innovation. Importantly the main guiding principle in substitutability is that the purchaser or user of this new application can substitute it for the prior one without any special technical assistance. Just as importantly she could revert to the old application without any additional technological investment.
It was not coincidental that at the time we were discussing a concept of substitutability, there was in the commercial realm a remarkable successful example of substitutability. The iPhone, which in the fall of 2008 had less than 10,000 applications (and in the Summer of 2009, over 50,000) and the iPhone “app store” showed how easy it was for any consumer to substitute one application for another. It also showed the virtuous cycle of allowing relatively easy access (modulo an Apple tax and vetting process) to innovative developers to a user community. It was only a small leap to recognize that providing this substitutability function for electronic health records would allow similar innovation in healthcare IT. Of course, there were those who insisted that health care was a lot more complicated than an iPhone, but as the richness of the iPhone platform increased this particular concern diminished. Nonetheless, the iPhone is only one of several platforms that allow for easy substitutability. Computer operating systems have long allowed one application to be substituted with another without requiring an extensive re-engineering and with none of the vetting process required for the iPhone. Yet, to date, most electronic health record vendors require very significant IT investment (if they allow it at all) for new functions to be implemented by third parties within their applications [1]. This leads to the well known “vendor lock in” in health automation. It certainly does not allow thousands of creative developers to have an opportunity of developing their wares for healthcare automation without either having their own sizable salesforce and/or formal co-development relationships with existing healthcare IT vendors.
So what are the big questions?
Do we need regulation around substitutable applications? For example, let’s suppose a medication management application is substituted for another, should the patient and/or provider be provided assurances that the new application does not create new risk for disclosure? What about the flow of liability if two applications from two vendors interact in a way that results in harmful medical decision-making? Are their technical approaches that reduce the regulatory burden?
Do platforms for substitutable applications in health work better open or closed? If closed, by whom, the government, IT companies, healthcare providers, or a consumer consortium? Should a set of software services be made available for all substitutable health IT applications (e.g. patient data selections, communication to the consumer, communication to the public health authorities) or should the common services be allowed to evolve organically? On the iPhone, for example, applications have access to common services (e.g. GPS, contact lists) but at this time, they cannot directly share data between each other (short of user-initiated cut and paste).
Should there be enforcement of data standards or do leading applications de facto determine the standard? In the short term, lack of standards will mean that there is little data liquidity until there are popular applications that demonstrate the value of such liquidity. Are there societal imperatives that trump this market-driven expediency? Conversely, should utility as determined by users be limited by the pronouncements of standards organizations? Should competitors be free to create platforms capable of seamlessly hosting substitutable applications from other platforms (as is not the case between the iPhone or Android platforms) or can an owner of a platform prevent compatibility, legally or technically?
Should we nurture the development of one or more market’s for alternative applications for similar functions much like the Apple iPhone App Store? Should there be commercial or federal subsidy of these markets? Will consumer-facing personal health record applications populate the same markets as those for healthcare institutions?
What are the better mechanisms for certifying safety, quality and efficacy of substitutable applications? Is it through a purchaser’s feedback in the marketplace (as in the App Store) or by a third party evaluator (e.g. Consumer Reports or Underwriters Laboratories) or a regulatory oversight agency?
References
Kibbe DC. Toward a modular EHR. Fam Pract Manag. 2009 Jul-Aug;16(4):8-9. PubMed PMID: 19621865.