by: Russell Leftwich, MD, FAAAAI, FCCP the CMIO of the State of Tennessee Office of eHealth Initiatives
This is the first of a two-part installment. Additional FHIR questions will be address in a blog post on Tuesday, April 14.
HL7® FHIR® (Fast Healthcare Interoperability Resources, pronounced “fire”) is a platform and a set of rules for clinical data exchange. It is a standard that was developed with implementers in mind and is based on a concept of logically discrete self-defined data groupings called Resources rather than the concepts of v2 messages or CDA® documents. The HIMSS Interoperability and Standards Committee has recently published a set of FHIR FAQ resources as an introduction for those new to FHIR and wanting to know more.
Perhaps the most commonly envisioned application of FHIR is use in RESTful interfaces to create open APIs. But FHIR will also be used as the basis of interoperable exchange in messages, documents and in the creation of services, like web services that serve as clinical decision support. Building on existing messaging and document standards, efforts are ongoing in HL7 to align FHIR with Consolidated-CDA document templates and with specific HL7 v2 messages. One of the fundamental concepts in FHIR is that the content of a FHIR resource is unchanged whether it is part of RESTful exchange, a message, a document, or a service. With FHIR, however, the RESTful approach means an individual resource can be queried, updated, or exchanged without the need to exchange an entire document or message.
FHIR is getting tremendous attention in the health IT media and community over the past year as the awareness about this latest generation HL7 standard spreads. Some of that attention is a cautious skepticism whether the leap forward in interoperability that many envision from FHIR is achievable. Part of that skepticism seems to arise from the view that FHIR is something entirely new and untested. And while it is true that FHIR is still a draft standard, it is also true that it leverages existing technologies that are in widespread use across the domains of Google, Twitter, Facebook and others and builds on concepts and lessons learned from existing HL7 standards – Version 2, Version 3, and CDA. And it anticipates the need for a standard that can enable interoperability in a new era of connectivity between disparate systems that hold data about an individual and mobile devices and apps that create value from accessing that data and contributing data.
Some of the caution about FHIR’s potential stems from frequent misunderstanding of guidelines like the “80/20 rule” and from lack of awareness of the existing implementations of FHIR that are already live and in production. The 80/20 rule is a guideline used in the development of FHIR Resources that encourages the inclusion of data elements only if they are implemented in 80 percent or more of existing electronic systems. This is often misconstrued as an assertion that this equates to what is important or required in clinical care or in transforming care under a new paradigm. This guideline is instead intended to support the flexibility and ease of implementation that are part of the fundamental intent of FHIR. The “other 20” that may be critical to specific use cases based on clinical specialty or jurisdictional requirements are handled as Extensions. These Extensions may vary from base Resources in their content, but not in the technology upon which they are built.
There is one frequently considered question that is not addressed by the FAQ: Is there any restriction on creation of puns that play on the pronunciation of FHIR? No. FHIR is available under an open source license at no charge and there is also free license to create or reuse existing FHIR-puns. Just be sure to share them.