History of FHIR: How the Data Exchange Standard Began

The rise in mobile app technology, along with the increasing digitization of healthcare information, means we have faster, easier and better access to healthcare data.

“Interoperability” refers to how this data is actually shared. To standardize this process, Health Level Seven (HL7, a non-profit ANSI-accredited standards development organization) is dedicated to health data interoperability. Older HL7 interoperability standards included HL7 version 2 (HL7v2), now considered out-of-date; and HL7 version 3 (HL7v3), which was never widely adopted. They also include HL7’s Clinical Document Architecture (CDA) product lines.

The Fast Healthcare Interoperability Resources (FHIR) specification combines the best features of HL7’s versions two and three and CDA. The difference? FHIR leverages the latest web standards and applies a tight focus on implementability.

Today, FHIR is widely used in thousands of applications that benefit providers, patients and payers around the world. The future promise of FHIR for interoperability lies in how well it coexists and can be used in partnership with other widely used standards, like the ones on which Web applications are commonly built.

But what is the history of FHIR?

Graham Grieve’s Vision For Better Healthcare

Image credit: hisa.org.au

FHIR’s development began in 2012 as Graham Grieve and a small team worked through HL7 to create an entirely new standard for data exchange. Originally called “Resources for Healthcare”, the idea behind the standard began after Grieve spent 10 years in a “spiritual wilderness” after a family health emergency revealed how fragmented modern healthcare was.

“One of the reasons for this was it was really hard to share information, that it’s really hard to get the right information at the right time, in a timely context,” Grieve said at last year’s Health Informatics Conference in Melbourne, Australia. “I said ‘I can do something about that’.”

He committed to working towards solving the problem. He was able to grow a community dedicated to solving the issue. For him, connecting the technical obstacles to the tangible improvements and real-world outcomes was the motivation.

Grieve said connecting healthcare data using online standards wasn’t all that revolutionary, but the commitment of everyone who got involved took his initial vision to its successful conclusion. FHIR was allowed for free access and went through several iterations before publication as a Draft Standard for Trial Use in 2014.

“I threw a rock into a pond,” he said. “As time has gone on, it’s had a further and further reach. The rings are expanding. The principal issue we have now is how to scale the community without losing some of the things that have made the community work well.”

This means involving standards organizations and worldwide governments in the ongoing process to ensure continual improvement of the FHIR standard.

“The hard thing is to get people to sit down, talk to each other, agree with each other, then hold to those agreements and then leverage them,” Grieve said.

By 2015, The Argonaut Project was one of those shareholders making and leveraging agreements. The project’s stated goal was to promote FHIR-based API and Core Data Services for digital electronic health records and health information technology exchange for patients, providers, and payers. The private sector got involved before long. These players included EHR vendors such as Cerner, EPIC, AllScripts and athenahealth and health systems such as Mayo Clinic and Intermountain.

FHIR’s development in the next few years addressed healthcare interoperability challenges by enabling the creation of applications using modern web technologies developers were familiar with (e.g., HTML, JSON, XML and OAuth). As FHIR adoption spread across various EHRs, the U.S. government, Apple, Microsoft and Google were also soon on board.

Why FHIR’s Time Has Come

The modular FHIR approach lends itself to more flexibility when developing applications for patients and providers. Thanks to FHIR’s concise and easy-to-understand specifications, public examples are available to help kick-start app development. Base resources can be used as-is for out-of-the-box interoperability or adapted for local requirements (“profiling”). This gives new software developers a low barrier to entry.

“We’re making progress, we’re seeing transitions, clinical providers are starting to look at what we’re doing and saying ‘we can imagine a different world’ – right now all we can do is imagine a different world, and I want to turn that from imagination to reality,” Grieve said.

Developed from earlier HL7 healthcare standards and rooted in web standards such as XML, JSON, HTTP, and OAuth, FHIR can co-exist and leverage those earlier standards. Put another way, FHIR was built on Internet standards and technologies already used by industries outside of healthcare. For example, the REST approach was one such standard. REST describes how individual packets of information (resources) can be shared.

For a full list of available FHIR versions, see the directory of published versions.

FHIR encloses a document exchange format that allows for the exchange of APIs, messages, resources, and various documents (including doctor notes). In this way it represents an improvement over CDA, which was only specific to clinical data. C-CDA is a consolidated form of CDA focused on the most essential and common healthcare data elements. The CDA approach was initially intended to provide a data dump of the full medical history of a patient; FHIR can also do this. By breaking data into smaller, discrete pieces, there is better uniformity than what was possible with CDA (which can be messy for processing larger documents).

Quick FHIR and The Next Steps for FHIR Integration

FHIR has developed via the process that created HL7 v2 and HL7 v3—via consensus. Prolifics is excited to help enterprise businesses implement FHIR 4 because the standard has achieved mass consensus and mass implementation.

Each resource is individually maintained and versioned, with “Maturity Levels” assigned to them to indicate how reliable a given component is for use.

“As with any new standard there’s an adoption curve and a maturity curve,” explains Greg Hodgkinson, Chief Technology Officer at Prolifics. “Vendors and other players in the healthcare ecosystem have been dipping their toe into FHIR but waiting to implement on a wide basis. There is now general consensus that with the FHIR 4 release, it’s ready for wide scale adoptions.

“Because of the previous versions of FHIR, these businesses need to be able to transform messages from the older standards to the new standard,” Hodgkinson explains.

Prolifics’ Quick FHIR solution can help transform information either in real-time (using something like IBM® App Connect Enterprise) or at a data level (using something like IBM InfoSphere DataStage) to transform it to the new FHIR standard API.