Standards organization Health Level Seven (HL7) has published Release 4 of its Fast Healthcare Interoperability Resources (FHIR) Standard, marking the first release with normative content.
“R4 is the culmination of 18 months of extensive work to finalize the base parts of the specification, and incorporate changes and enhancement requests received from implementation partners across the world,” Grahame Grieve, HL7 FHIR Product Director, wrote in a blog post.
FHIR is a standards framework that leverages the latest Web standards and applies a tight focus on implementation. FHIR includes a RESTful application programming interface (API), which is an approach based on modern Internet conventions and widely used in other industries. FHIR can be applied to mobile devices, Web-based applications, cloud communications, and EHR data-sharing using modular components. The FHIR Maturity Model helps implementers understand how the various parts of the standard are advancing through the standards development lifecycle.
FHIR Release 4 marks a significant milestone with the introduction of a normative base. “This new maturity will help support our very active and growing community,” Grieve wrote in the blog post.
“What we have now is a solid foundation which provides a framework for implementers to rely upon and that they know they can use it, and implementers should have more confidence in using the tool moving forward,” says Wayne Kubick, HL7’s chief technology officer. “Our expectation is that this will sort of diffuse some of the arguments and some of the fence-sitters who kept saying that FHIR is still in development, and while that’s true, it’s widely in use in thousands of applications and countries all around the world now. With FHIR R4, implementers should have confidence that it’s going to be around a long time and it’s going to be stable.”
Between release 3 and release 4, there have been nearly 3,000 change proposals applied to the specification, including more than 1,000 substantive changes, according to the organization.
The most significant change in FHIR Release 4 is that the base platform of the standard has passed a normative ballot, and will be submitted to ANSI as a normative standard. This means that future changes should be backward compatible, so that applications that implement the normative parts of R4 no longer risk being non-conformant to the standard, the organization said.
“The message to the community is that we are asserting they should not expect breaking changes in the future; if they adopt this version, they should expect whatever they build off this version to be supported for the foreseeable future. That should give implementers the confidence to invest more of their time and effort in using the FHIR standard,” says Wayne Kubick, HL7’s chief technology officer.
The following portions of the standard are now normative:
- The RESTful API, the XML and JSON formats, and the basic datatypes
- The Terminology layer (CodeSystem and ValueSet)
- The Conformance Framework (StructureDefinition and CapabilityStatement)
- The key resources Patient and Observation
Creating and publishing normative content is critical for allowing health IT developers to implement FHIR consistently and uniformly, according to HL7 officials.
Recent data from the Office of the National Coordinator for Health Information Technology (ONC) found that adoption and implementation of the HL7 FHIR standard in health IT is steadily progressing. Approximately 32 percent of certified health IT vendors said that they are using FHIR, specifically the “FHIR Release 2” API (application programming interface) standard. Nearly 51 percent of health IT developers appear to be using a version of FHIR combined with the OAuth 2.0 standard, according to ONC.
Kubick notes that with the publication of FHIR release 4, not all of FHIR is normative. “The features that have been defined as normative and submitted for approval as normative are essentially the infrastructure pieces—the pieces that determine how to use terminologies, how to build APIs, as well as resources around defining about how you recognize a patient and how you record observations about a patient. That’s a lot of the data you collect in healthcare, but by no means all of it,” he says.
The plan is to release FHIR, new releases on an 18- to 24-month release cycle. “We’ll expect to see another version of FHIR coming out around 2020. With the next release, we expect more of these medical content-type pieces, working on the resources defining drug products, for example,” Kubick says.
Moving forward, the HL7 FHIR working group will likely focus on fleshing out clinical content, Kubick says. “We will be building up more of the content resources that we currently have, as well as broadening capabilities for interacting with devices and images. We want to be able to get, with R5, a more complete view of as much of the types of health information necessary in place. We’ve got the Infrastructure solid and pretty much in place now with R4, and now we want to focus more on content, which is a much more complex issue, because we’re trying to move to a more structured, consistent way of representing health information, as recorded by doctors,” he says, adding, “The content is the tricky part, there is still a lot of variation in place. Reaching the level where the definition of the clinical content is much more consistent, we help us to get closer to interoperability, and that is really our next horizon.”
