Standards and Open Source Make Advances in Apps and Data Exchange for Health

Andy OramI try to be optimistic about health care, and I managed to move my mood meter in that direction last month after talking about advances in data sharing, standards, and interoperability with a few people involved in the open FHIR standard: Grahame Grieve from the Core FHIR Development Team, David Hay from the FHIR Management Group, and Josh Mandel, a research scientist working on the open-source SMART Platform.

Certainly, optimism is hard to maintain as the news rolls in week after week. A few VA hospitals across the country neglected their charges and lied about it (something that could have been prevented if veterans could download the recorded wait time over Blue Button). Hospitals can't pay for analytics that would improve patient care, meaningful use keeps getting delayed (not to mention ICD-10 adoption), health information exchanges can't seem to get traction despite massive subsidies, and always, relentlessly, costs rise. Better options have been invented and have mostly languished, but now some major players are actually adopting new options with promise.

The larger scene

I asked Grieve and Hay whether organizations are starting to incorporate the FHIR standard and API into electronic health records (EHRs) or tools. This modernization could instantly rip away the current technical barriers to sharing data for both improved care and research. Efforts are proceeding at various rates in three different areas: EHR vendors, national health systems, and independent projects such as universities and open source developers.

EHR vendors

Vendors have shown up at standards meetings for FHIR and shown a lot of enthusiasm, but the only implementation announced was by Cerner (described later in this article). Accordng to Grieve, vendors sense that interoperability is becoming a requirement and are happy to find a technology that will drastically lower development efforts and hence the costs of interoperability. However, vendors will move faster when they feel pressure from outside, perhaps from independent developers who release successful apps and ultimately from patients and providers.

National health systems

The United States has the fastest moving government in the FHIR space, perhaps because we need to solve problems with data exchange that are handled better by other nations with more integrated health care systems. The ONC has shown a great deal of interest in the FHIR process and may eventually require EHRs to support FHIR in order to be certified for meaningful use. Other countries. such as Australia, New Zealand, and Canada, are at a different phase in their requirements lifecycle, and will decide when to adopt FHIR in the future.

Independent projects

Open source developers and universities have acted the fastest on FHIR, overjoyed that it can let them share data. FHIR seems to be stimulating open source software efforts in health care tools, particularly in developing nations. No projects are ready for production use yet, however. This may be due to the two ruts that perennially trap open source software projects: lack of money and a lack of strict coordination among far-flung developers. On the positive side, Grieve finds that open source software projects are more agile and more attuned to user needs.

Grahame GrieveCollecting data from consumer devices is an explicit part of FHIR, and there are device working groups. One notable project is an app that collects blood glucose data from devices, being developed in New Zealand by Orion Health.

Several FHIR connectathons have been held, but travel has been prohibitively expensive for many potential participants (mostly in the open source software space). Therefore, HL7 will hold a connectathon running on a social media platform for open source software projects, judged by John Halamka (CIO of Beth Israel Hospital in Boston and a key player in many US government standards) and offering a $10,000 prize. The prize will go the project with the "most clinically relevant use of the FHIR specification."

SMART stymied

Let's begin with by locating a role for SMART, which I covered in some detail in 2011 and 2012. The team developing SMART wants to connect apps with health records (both in clinical settings and in personal repositories). Their vision is a set of marketplaces for apps that have access to all kinds of health records and add useful functionality. Hospitals and clinics could evaluate apps and place the ones they approve of in local repositories, where doctors could download the ones they need.

To this end, the SMART team developed a simple, modern, friendly API for apps. If EHR vendors supported them, programmers could code to them and be guaranteed to run on all supporting EHRs. This definitely beats the current situation, where anyone developing a app to run on health records has to beg each separate vendor (who may not want competition with its own interfaces) for proprietary information that would allow the app to access the record.

SMART has several proof-of-concept apps, and has started to work with one vendor--Cerner--to integrate SMART. Cerner is one of the proprietary EHRs that is more open to third-party apps, so the SMART team created an interface to it on their own. Cerner later integrated it and got some of the SMART-compatible apps running. It is still at a prototype phase, though.

During this period, SMART built several proof-of-concept apps, as well as some custom integrations with various EHR systems -- including the open-source WorldVistaA, and the proprietary Cerner Millennium. But aside from a production deployment at Boston Children's Hospital, these integrations never made it from the lab to the clinic

Integration is hard. Mandel said that data storage is different in each EHR, and that an outside app developer can't be expected to understand the variations and map fields in the app to the ones in the EHR. It's up to each vendor to organize data so that it can easily be exposed through the API offered by SMART. For example, different systems might use their own local or proprietary codes to identify medication products. But to expose FHIR data through SMART, the vendors would need to map those codes to RxNorm, a naming system for medication invented by the National Library of Medicine.

The SMART team developed their API in the absence of a standard appropriate for the data they were exposing. Although vendors showed interest in SMART, they requested a more formally defined standard, and this is where FHIR can be invaluable.

A leap by HL7

Joshua MandelFor decades, health standards were in the hands of the HL7 standards development organization, whose work was hobbled by a number of complications. It's only in the past couple years that they found a solution, Fast Healthcare Interoperable Resources (FHIR), that carries the potential to bring health care into a modern age of computing power and interoperability.

Older HL7 standards had the quirky punctuation and irregular fields endemic to standards from the 1960s through the 1980s. The consortium eventually created some document formats based on XML, but in a way that reflected the legacy of poorly structured standards. Implementations do not pass XML validation (a complaint I have also heard recently about Blue Button).

In addition, standards were proprietary and costly until recently (around the time the FHIR project launched, HL7 dramatically opened up their standards) and although they were widely adopted, interoperability tended to require direct negotiation between implementers. There are many fingers pointing blame in different directions for this: the loose definitions and multiple fields available for the same information in the standards themselves, desires by vendors to lock in health care providers who licensed their products, and the providers who don't want to make it easier for patients to leave the practice. All that is coming back to bite us now that Congress and the ONC are trying to enforce interoperability through Meaningful Use requirements. So the vendors and providers are looking for a way to untie the bonds in current EHRs--and FHIR may offer the solution.

A few earlier HL7 projects showed some progress but failed to be widely adopted. For instance, MITRE developed and donated a clean format for health data called hData, but instead of offering an API, they created an abstract framework on which APIs could be built, leaving confusion about interoperability and who would use the standard.

The FHIR standard is a green field project, although the data it contains is clearly recognizable from earlier HL7 standards such as the CCD. There are things that every clinician wants to know: vital signs, dates and diagnoses of conditions, and so forth. The data can be represented in a number of popular formats, such as XML and JSON.

On top of the format is a RESTful API. Conceivably, not only EHR vendors and clinicians, but patients as well, could upload and download data using the standard.

In contrast to earlier attempts to improve interoperability, vendors are showing a lot of interest in FHIR and it has received the stamp of approval from many health reformers. Mandel tells me that he's not sure whether vendors see the full potential of the standard--they may consider it just something that client institutions can use internally, rather than as a general platform for innovation--but they are well represented at FHIR meetings. Cerner has recently partnered with Intermountain to build FHIR support into the Cerner EHR.

SMART on FHIR

Now that FHIR provides a standard API, what need is there for SMART. Mandel sees several gaps left by FHIR that SMA

RT can fill. His SMART on FHIR project has a number of working apps.

First, FHIR by design includes only the core elements that most implementations will use, allong with an extension mechanism for adding the other elements required for specific implementations. This is necessary because different regions and disciplines require different fields, either because of regulations in different countries or just because each implementation has a different focus. To create a single universal standard, all possible elements would have to be in all the resources, and new developments over time would be stifled by an unwieldy standardization process.

Thus, the FHIR developers expect that, in addition to common extensions defined by HL7 itself, health providers in a given region will cooperate to adopt a set of common extensions--collections of options called a profile. The FHIR standard defines ways for communicating parties to agree on a profile or find a profile that defines the data they're using.  For instance, given a blood pressure profile, SMART can define some additional profiles to make FHIR usable in common situations--for instance, whether the patient was standing or lying down when blood pressure was taken.

Second, FHIR contains no mechanism for authentication and authorization, because extensive experience with security exists throughout the computer industry and the FHIR team did not wish to mandate specific approaches. This is a fairly noticeable gap in the field of healthcare, where privacy is sacrosanct. It also raises the question of patient identification as a person moves between health systems. Some countries have unique patient identifiers for each person, but the US has rejected that approach. SMART is working on these areas and may add sign-in capabilities, but they would like to partner with at least two vendors in order to determine what the industry needs.

The third area where SMART can bring FHIR to fruition is user interface integration. Ideally, a clinician will see a list of apps inside the EHR and launch them without having to think of them as separate pieces of software. SMART uses the web capabilities of each EHR to do this. Nearly every EHR, as I mentioned earlier, has some web interface, although capabilities vary.

At an upcoming California Connects Interoperability Exhibition, sponsored by Redwood MedNet, Mandel will demonstrate how SMART on FHIR allows health-related apps to run on underlying EHRs without special adaptation. So long as the EHR supports the FHIR API, SMART on FHIR can handle all the interoperability issues, including authentication through OAuth2 and OpenID Connect.

Beyond the stand-alone EHR

An innovative marketplace for apps can be transformative, but I look toward a wider horizon: what can FHIR and SMART do to data exchange? Will it shake up the sclerotic HIEs and replace the hoary old CCD? Ideally, the exchange of all sorts of valuable health data could take place quickly and directly between doctors, as well as from patient to doctor and back again. And it could bring health care toward a "data culture" where we all learn from each other's treatments and their results.

Mandel's vision is that instead of a static document like a CCD, lacking many fields of interest and containing some that are irrelevant to the clinician, a referring doctor could provide a brief introduction to the patient along with a complete set of links back to data. Each specialist or could get what she wants. Furthermore, segmentation could be enforced. The patient could rule certain data off-limits to certain practitioners, and it would not appear in the links.

The health field has known for years what it would look like to make data available to treatment teams and programmers. Both technology and organizational arrangements have held the field back until recently. Now, with these new tools--as well as Blue Button, Direct, and open source software projects--we may actually see innovation and interoperability take off.