Questions about the FHIR standard? We have expert answers

to take a close look at what many would call the lynchpin -- the FHIR standard API, a software development building block designed to make it easier to exchange information.

At the recent American Medical Informatics Association meeting in San Francisco, a room full of clinicians spent a half-day learning about what the Fast Healthcare Interoperability Resources standard can and can't do from a panel of experts who volunteer their time working on the API. Here's a look at some of the key takeaways.

FHIR is a draft standard, but that's not a bad thing

To date, the FHIR API is in use in hundreds of organizations around the world, according to Laura Heermann Langford, director of nursing informatics at Intermountain Healthcare and COO of the Healthcare Services Platform Consortium and an active participant in shaping the API.

It is a draft standard that is constantly evolving, but that's no reason to not start using it, she said. "With respect to the idea of draft, the reality is we need to start thinking differently, more like we do about smartphones," she said. "With the iPhone 3, we know the iPhone 4 can do more functions and the iPhone 10 has incredible functions, but we would still have bought the iPhone 3 [at the time]. We're on our third release of FHIR and we can do things with it we couldn't do before."

FHIR is only as good as the data beneath it

One way to think about the complexity of the FHIR standard is to consider a zebra, attendees were told. There are two ways to describe a zebra -- a black animal with white stripes or a white animal with black stripes. Both are correct, but in the computing world, they're different. And that is why getting everyone to agree on how data is described in healthcare IT is so important.

"Different versions of a procedure may be a perfectly reasonable problem in the real world," explained Russell Leftwich, M.D., senior clinical advisor for interoperability for InterSystems. "But it is one of the challenges of interoperability. The reason FHIR itself doesn't solve that in healthcare is because there are often different, reasonable ways to describe a data concept. If it's really going to be interoperable, all parties involved have to be doing it the same way."

Now that the FHIR standard API exists, the next (and much harder) step is to achieve semantic interoperability where every hospital refers to a temperature reading or a heart attack or the flu in exactly the same language. (Interested in contributing to this discussion? The Clinical Information Modeling Initiative meets regularly and is seeking input.)

FHIR standard resources are important (and a complicated work in progress)

The FHIR standard API allows developers to create "resources," or chunks of information that can be joined together and transmitted from one place to another. A FHIR resource could be a patient, a procedure or a list of conditions. Putting the resources together to create a "scenario," like a transferrable medical record, is a good way to understand how FHIR creates relationships between pieces of information.

Those working on the FHIR standard want to keep the list of resources down to 120 and make sure that they're defined and organized by group, said James McClay, M.D., director of biomedical and health informatics graduate education at the University of Nebraska Medical Center. "Some of these resources are immutable and some are mutable and have a timeline associated with them," McClay said, referring to the complex nature of this project. He stressed the importance of widespread agreement not only on what the resources are but also how they're organized and referenced.

ClinFHIR, the hands-on tool used to practice scenario making during the session, is also available to the public, and there are step-by-step instructions in a separate document. (After playing around with the tool, attendees around me definitely had "aha!" moments.)

Is SMART on FHIR different than FHIR?

Attendees learned the answer to that question was yes, though they're closely related. SMART stands for Substitutable Medical Applications, Reusable Technologies, and while it began life on a similar track with FHIR, it is now largely used as an add-on.

SMART is responsible for the standards involved with interacting with an electronic health record, launching an application and keeping everything secure. Applications that use both SMART and FHIR are known as SMART on FHIR programs.

How to get to know FHIR better

For everything else you need to know about the FHIR standard, the HL7 FHIR resource is the best place to start.