FHIR: The Answer To Providers’ Need For Custom, EMR Connected mHealth Apps

May 13, 2015 | Stuart Hochron

Fast Healthcare Interoperability Resources (FHIR) is blazing a path to interoperability. In our opinion, RESTful interfaces based on FHIR will be an mHealth game-changer by commoditizing EHR data and reducing the cost of customized apps that providers have needed, wanted and haven’t yet imagined.

FHIR (pronounced “fire”) is new generation standard developed by Health Level Seven International (HL7) as a platform for simultaneously accessing data from different healthcare systems, regardless of how data is stored. It will allow public Application Program Interfaces (APIs) to access data that resides on all types of systems (EHRs, etc.) in a format that mobile app developers will easily use to combine and represent clinical information in user-friendly ways.

The essence of FHIR is its RESTful interface, which means that data in one server is also represented elsewhere by the interface. REST is a web technology frequently used in web services (Google, Facebook, etc.), and allows apps to interact through specified APIs with various databases in complex ways without knowing details about the server or the resources it hosts. The FHIR standard is based on resources, specifications for logically discrete chunks of health data, that allow data to be easily and quickly requested and delivered through standard APIs. FHIR is encoded in a format that is much more compact than the code currently used to exchange clinical data, and can easily live on mobile devices. Just as travel sites, such as Travelocity.com, list the flights of numerous airlines in one format and in one place, without having a database of any flights, FHIR will allow mobile devices to display a representation of data from multiple servers. An app might also similarly access clinical data for decision support services or population health analytics.

The effect on healthcare will be similar to RESTful technology’s effect on Internet commerce – it will commoditize healthcare data. The history of web-based commerce had clearly shown that, “As the data become commoditized, the applications that use them will become decommoditized – and this is where money will be made.” FHIR will support a national scaling of specialized apps that will no longer need to be customized for each EHR implementation. By adapting current privacy and security technology for web services, apps will work across different databases and across institutions.

FHIR was introduced by HL7 in response to the demand of new markets for tools and a new platform upon which to build healthcare solutions. HL7 version 3 was slow to provide answers, and the 30-year-old HL7 version 2, preferred by mobile developers, was complex and not up to the task.

According to Lloyd McKenzie, a recognized HL7 expert, FHIR was born in 2011 when “Graham Grieve, founder of Health Intersections, recognized that HL7 was ready for something different. McKenzie looked across all industries to identify best practices in the area of interoperable technology. Most places he looked pointed to a customer relationship management solution called Highrise (from 37 Signals -https://37signals.com/), which uses RESTful interoperability platform. It became apparent to the Board of Directors of HL7 that current formats were not hitting on all cylinders, and did not have a good mobile solution.” The first version of FHIR was released in January 2014.

FHIR is also unique compared to past HL7 standards in the methods used for development. It leverages the tools of open-source development and social media that enable implementers to test the standard as it is developed and generate ongoing feedback and share lessons learned to improve the FHIR standard.

Mobile interoperability through FHIR

HL7 version 2 is generally used by developers for interfacing healthcare systems with mobile devices. FHIR is a new and completely different standard from HL7 version 2 and 3. McKenzie reports that, “HL7 FHIR will be used instead of, or in parallel with, version 2.  It is difficult to build a mobile app that receives version 2 feeds. Before the introduction of FHIR there were no standards for sharing data with mobile devices.  The number of apps will be increased. A lot more people will come to the table with much less upfront negotiation. The data will be shared with more responsive mobile systems because only the data that is requested will be sent faster. FHIR has a super broad scope that will interface with all hospital systems that interface with mobile apps, including EHRs, ADTs, scheduling systems, research, financial claims, and the full gamut of all data that touches the healthcare space.”

FHIR defines a set of resources based on simple XML or JSON structures that can be managed in isolation or aggregated into complex documents using an http-based RESTful protocol, where each resource has a predictable URL. Open Internet standards are used for data representation. FHIR comes with records systems for SWIFT and JAVA, so development for mobile devices is straightforward. “Mobile works really well with a RESTful interface,” says McKenzie. “Small lightweight requests for data and updates use a small bandwidth to send only required data to a responsive user interface, and most of the work is done on the server side. … This is what RESTful does.”

The current version of FHIR, referred to as the “Draft Standard for Trial Use,” is in production today, meets clinical and business requirements and is ready for use, but has not been widely implemented. Epic and Cerner both have early versions of FHIR available for developers. According to McKenzie, “HL7 is not committed to maintaining full backward compatibility with future versions yet because development is not complete. Only implementation experience will tell us. We are in the process of a second draft, 1,500 change requests that include additional content, and various enhancements and corrections.” While FHIR can be used now, its value to developers will be enhanced with the release of upcoming versions.


Meaningful Use rules and FHIR

Currently proposed Meaningful Use 3 regulations include generic requirements for support APIs that access data, but do not specify a standard. FHIR is essentially the only standard that could apply. The final rule is expected by the end of 2015.

The Joint Argonaut Project to Advance FHIR, a working group supported by athenahealth, Cerner, Epic, Intermountain Healthcare, Mayo Clinic, MEDITECH, McKesson, The Advisory Board and others, is finalizing and accelerating the development of FHIR and tackling issues such as developing tools to enable privacy and security. Smaller EHR developers are expected to quickly adopt FHIR as they have been bearing disproportionate integration expenses. FHIR will make it much faster and less costly for them to move toward interoperability.

Unlike previous HL7 interfaces, which can be difficult to master, FHIR can be taught within a few days to any developer with a working knowledge of web services. We expect that, once the final Meaningful Use 3 rules are published, standardized healthcare APIs and the apps that rely on them will proliferate in a manner reminiscent of the growth of web services.


This post was originally published in mHealth News and co-authored with Russell Leftwich, MD,  HL7 International’s co-chairman of the Learning Health System Work Group and chairman of HL7’s Health Professional Engagement Initiative.