reprint

This week’s move by HL7 to publish its eagerly awaited normative version of the Fast Healthcare Interoperability Resources is seen by industry stakeholders as the evolution of a mature, stable standard.

On Wednesday, HL7 announced the release of FHIR Release 4 (R4) and that the base platform of the standard has passed a normative ballot and will be submitted to the American National Standards Institute for designation as such.

“The publication by HL7 of Release 4 of the FHIR standard is a milestone of great import,” says Russell Leftwich, MD, senior clinical advisor for interoperability at software vendor InterSystems and assistant professor of biomedical informatics at Vanderbilt University School of Medicine.

“Conformance with this normative base will mean that applications based on FHIR R4 will have a long life cycle and greater portability,” Leftwich adds. “It will be easier to upgrade rather than replace such applications.”

Also See: HL7 publishes normative version of FHIR standard

Stan Huff, MD, chief medical informatics officer at Intermountain Healthcare, sees the FHIR R4 announcement as a significant milestone for exchanging healthcare data between information systems and as an important step towards a “higher level” of interoperability. .

Stan Huff, MD

“The new release is more mature and provides greater standardization than previous releases,” says Huff. “It makes many—but not all—of the FHIR Resources ‘normative,’ that is, they are now considered ‘standard’ with only rare changes expected in the future. This means that people can use the new release with fewer worries about needing to make future changes in their software.”

Micky Tripathi, manager of the Argonaut Project, an industry-wide effort to accelerate the development and adoption of FHIR, points out that—in practical terms—normative approval means that any future changes will require broad HL7 community approval and must be backward compatible.

“If you’re a developer that gives confidence that what you build won’t have to be thrown away when the next version is released,” says Tripathi, who is president and CEO of the Massachusetts eHealth Collaborative. “Normative approval thus gives further confidence and impetus to any vendor who is still sitting on the fence about whether they should build FHIR capabilities.”

As a result, Huff contends that R4 “creates a more stable foundation on which to build products and services,” which he believes “should cause even faster uptake of FHIR across the healthcare industry.”

Still, Tripathi observes that normative approval isn’t a prerequisite to industry adoption, as evidenced by the Argonaut Implementation Guide, which he notes “was not based on any normative content but nevertheless has been widely adopted by EHR vendors, Apple, and lab companies such as LabCorps and Quest.”

At the same time, Tripathi makes the case that normative approval further establishes FHIR as the basic application programming interface (API) building block for common healthcare transactions.

“There will always need to be room for other novel API approaches where FHIR isn’t applicable, but it’s important to have an open industry standard as the basis for common, high priority, day-to-day healthcare transactions such as transitions of care, referrals, diagnostic results delivery and patient access,” he adds.

He also sees normative approval as an important potential factor for FHIR’s Office of the National Coordinator for Health IT certification.

“It’s not a requirement but anything that becomes part of a federally approved standard should have a certain degree of stability and market ecosystem support—and, normative approval is an indicator of that,” according to Tripathi.

Leftwich adds that while grounded by the normative base of R4, the evolution of other resources that are part of the FHIR specification will continue.

“We can expect that FHIR will continue to evolve with increasing value and utility to be realized in each release,” he concludes. “I would compare this new concept of standards evolution to the evolution of other technology that we have become familiar with. For any particular brand of smartphone there is never a final version—they just continue to evolve and improve. Similarly, with Bluetooth or WiFi. the next version is better—more useful—but there is not going to be a final version.”


reprint