Update on Modular EHR Technology: Harvard’s SMArt Research

DAVID C. KIBBE and BRIAN KLEPPER

ONC awarded four Strategic Health IT Advanced Research Project (SHARP) grants earlier this year to

”...address well-documented problems that have impeded adoption of health IT and to accelerate progress towards achieving nationwide meaningful use of health IT in support of a high-performing, learning health care system.” 

One of these grants was awarded to a Harvard group led by Drs. Ken Mandl and Isaac Kohane, based in Children's Hospital Boston and Harvard Medical School. This research team is tackling the problems associated with developing an ecosystem of modular, plug-and-play medical applications, what we have referred to as Clinical Groupware. (Disclosure: DCK is on the Harvard SHARP grant’s advisory board.) 

The research is aimed at creating a “medical apps store” based on the iPhone/iPad model of substitutable applications running on a device or platform. The name of the project, SMArt, stands for “Substitutable Medical Applications, re-useable technology.” The approach could impact both the EHR industry and the federal regulatory and standards process, possibly within a relatively short period, i.e., 1-3 years, so we think it merits your attention. First, the problem. 

The dependence on monolithic EHR products - with pre-defined features that are presumably comprehensive - has kept health care IT expensive, difficult to implement, use, and maintain. This approach has impeded innovation, and has helped to perpetuate a fragmented health system with many disconnected “silos” and “data islands.” A vibrant, evolving health care system requires an IT infrastructure that is more like the iPhone and its app store. In other words, we believe that a more practical, contemporary approach involve general purpose platforms designed for communications and data sharing, able to support any number of simple applications, each doing a small set of tasks consistently and reliably. 


Here’s Ken Mandl on the topic:


"Under this view of a healthcare infrastructure, as one’s needs evolve, one could substitute simple applications within a platform, rather than substitute in an 'all or nothing' way one vendor product for another. The platform would allow a clinical practice or hospital to select the combination of applications that are most useful for the local environment. A practice or a hospital would be able to download, for example, a medication management application from one vendor and a notifiable disease reporting tool from another. As alternative applications are developed by competitors, the existing ones may be replaced, or new ones added."

This is not simply an academic view. It is the perspective also shared by a growing number of health IT experts and observers, including members of the Clinical Groupware Collaborative, whose modular products and platforms are entering the market in 2010. It is an approach endorsed by the Obama administration, which clearly demonstrated its support for this approach to medical app design in its ONC regulatory framework, most notably in several sections of the Final Rule on standards and implementation specifications. (See http://edocket.access.gpo.gov/2010/pdf/2010-17210.pdf.) Both “complete EHRs” and “EHR modules” may be certified under the new rules. Meaningful Use now explicitly encourages a "modular" approach to EHR technology.

Now to solving the problem. If we dig deeper, we recognize that modular applications can be difficult to integrate with one another in an ad hoc manner. Emulation of the iPhone apps store in health care is complex, and the comparison is more metaphor than strict design principle. 

There are several hundred thousand iPhone and iPad apps, and a growing number of apps for the Android OS. Most of these applications, however, do not integrate with one another in the way that, say, an ePrescribing app and a health registry app, built for meaningful use deployment in a medical practice, will have to integrate to be successful. Privacy and security is one important issue. Another is lack of generalizability of the model: one of the reasons that apps on the iPhone or Android cell phones do integrate with one another to any extent is because they have been written for the specific platform, not for all platforms. One can't get an Android app to run on an iPhone, or vice versa.

Let's make sure we understand the difference between "interoperability" and "substitutability," and how each relates to the problem of integrating modular applications. Interoperability (we prefer the term computability; never trust a word that half the population can't pronounce) is the ability of one system to share and understand the data sent from another system. We're making decent progress on interoperability, finally, with the federal recognition of the CCR standard and the CDA CCD as XML standards for clinical summaries required for EHR certification. But even were interoperability 100% achievable now, that would not get us to the level of integration required for the "app store" to work in health care.

Substitutability is required to do that. This is the notion that an application can be replaced with another of similar functionality, easily and without great cost or coordination of the parties involved. Substitutability does not require technical expertise to achieve. For example, if I want to replace one music player on my Android Incredible smart phone, I simply locate the new app in the Android Market, download it, and install it. I can begin playing MP3 files stored on my phone with the new player app immediately. It's not a requirement that the new music player mirror the functionality of the older one exactly. In fact, innovative improvements in features may be one of the reasons I chose to replace the old with the new. What is important is that I did not need any technical expertise or additional technological investments to make the substitution.

Of course, computer operating systems have long allowed one application to be substituted with another without requiring re-engineering. Yet, to date, most electronic health record vendors require very significant IT investment and re-engineering (if they allow it at all) for new functions to be implemented by third parties within their applications. This leads to the well known experience of "vendor lock in" in efforts to automate care processes in hospitals and medical practices. And it’s really dumb.

So, here is the approach that the Harvard researchers are taking to make EHR technology Substitutable Medical Apps, Re-usable Technology, or SMArt. They are using a design that has three basic components: SMArt apps, SMArt APIs, and SMArt containers. Any EMR, EHR, PHR, or research software platform can be a SMArt container by exposing data through the SMArt API to SMArt applications to use. So, by definition SMArt apps always run within the context of a SMArt container. (What does a non-SMArt EHR need to do to become a SMArt container? Hold off for a minute on this important question. It's key, but we have to finesse around this for a bit).

SMArt apps can communicate with a SMArt container in one of two ways: SMArt Connect, and SMArt REST. SMArt Connect is a javascript-based scheme for in-browser apps to use the SMArt API without having to handle explicit authentication. With SMArt Connect, the app runs in an i-frame within the SMArt container, communicating with the container via HTML5 postMessage. Since the end-user (e.g. Doctor Dave logged into his EMR) is already authenticated to the SMArt container, his apps can access permitted data through the existing web session. Apps with server-side requirements, or apps that need offline or background access to the SMArt API, use the REST interface. This interface provides a set of URLs that can be accessed via HTTP GET, POST, PUT, or DELETE to interact with health data.

Writing a SMArt REST app requires a bit more work than a SMArt Connect app, because the app must be able to:

• Interact with the SMArt container to obtain tokens (the oAuth "dance") 
• Store tokens securely on a user-by-user basis 
• Select the appropriate token and sign each SMArt REST API call 

Client-side oAuth libraries in java and python simplify tasks #1 and #3, but there's no easy way around the logistics of token management.

Using this framework and these tools, the SMArt team has built out some very simple SMArt apps that integrate with three different SMArt containers, the CareWeb EHR (from Regenstrief Institute), the Indivo PHR (from Children's Hospital Boston), and i2b2 (from Partners Healthcare System) analytics platform. For example, they have built an app that integrates with the patient's Indivo PHR or the physician's CareWeb EHR, accesses the medication list in either, and determines if the patient is taking a statin drug. It then displays the statin drugs, along with the full medication list.

The beauty of this schema is that it relies on open source code and open standards for the pieces of the puzzle that would be common to all industry participants, e.g. the APIs, but does not require native containers or apps to give up their proprietary code base, just their data. And it still would allow platform-containers to have appropriate control over who gets access to their APIs.

In Part 2 of this piece, we’ll describe the market dynamics necessary to move some critical mass of EHRs and PHRs to adopt this solution to "openness" and data liquidity, and ultimately to one or more “medical apps stores.”

David Kibbe and Brian Klepper write together on health care technology, market dynamics and economics.