Part I: FHIR 4 Terminology and Data Models
FHIR 4, the latest iteration of the HL7 interoperability standard, made its much-anticipated debut earlier this year , bringing several new components, as well as stability and backward compatibility.
In part one of this blog series, we will discuss two of the five axes — terminology and data models — that clinical interoperability aligns along, and the ways An HL7 standard that is short for Fast Healthcare Interoperability Resources and pronounced “Fire”. The standard defines a set of “Resources” that represent granular clinical concepts. The resources provide flexibility for a range of healthca... 4 is poised to help data movement for each.
Terminology represents the coded values for the clinical concepts sent in a message. These concepts vary from simple ideas like “O” for outpatient and “I” for inpatient. They then develop into more complex examples like standardized Logical Observation Identifiers Names and Codes (LOINC) applies universal code names and identifiers to medical terminology related to the EHR and assists in the electronic exchange and gathering of clinical results (such as laboratory tests, clinica... codes for lab results.
The challenge is that much of the clinical content in a message is not part of an interoperability standard like FHIR stands for Fast Healthcare Interoperable Resource. This emerging standard combines the best features of HL7 V2, HL7 V3, and CDA, while leveraging the latest web service technologies. The design of FHIR is based on RESTful web services. With REST.... Rather, HL7 is a Standards Developing Organization accredited by the American National Standards Institute (ANSI) to author consensus-based standards representing a board view from healthcare system stakeholders. HL7 has compiled a collection of message form... FHIR has a standard method for indicating the vocabulary set from which a given code is selected — like HL7 v2 — and it is often up to realm-specific profiles to constrain the allowed vocabulary for a given clinical setting.
As an example, FHIR (as well as V2 and Clinical Document Architecture (CDA) HL7 CDA uses XML for encoding of the documents and breaks down the document in generic, unnamed, and non-templated sections. Documents can include discharge summaries, progress notes, history and physical reports,... for that matter) can encode the concept of a “CBC with Differential” lab result, and the standard’s structure explicitly tells an implementer where to place the code for that test.
However, the standard does not specify if the code should be “24359-2” (a LOINC code for that concept) or “005009” (an older LabCorp code for the same idea). A profile laid atop the standard — likely Meaningful Use in the U.S. realm — can pick a specific answer.
FHIR makes terminology services a game changer for easing adoption in three key ways:
- Making more fixed choices up front, thus improving plug-and-play interoperability
- Providing consistency in vocabulary across the standard and harmonizing that effort with the V2 and CDA standards
- Building in the concept of “standards profiling” and conformance testing from the very beginning
The data model axis represents the underlying way of thinking about or representing clinical data. HL7 historically standardized via an implied (V2) or explicit (V3) data model.
While V2 focused on the wire format and was not explicit about the formal data model, V3 built a formal, complex Reference Information Model (RIM) as the basis of exchange. The primary issue with V3 (and its CDA/CCD offspring) is the deeply complex XML wire format and its difficult implementation.
HL7 FHIR takes the community’s 30 years of experience in implementation and modeling to the task of refining the data model approach. A key advantage of FHIR’s data model is that, unlike V3, FHIR has focused upon ease of implementation from the very beginning.
In focusing on implementation, the original architects of FHIR utilized an 80/20 rule. The top 80 percent of healthcare IT workflows should be handled by the core FHIR standard, but the unique workflows in the bottom 20 percent should be handled through extensibility. By embracing extensibility and keeping the unique requirements out of the core standard, the FHIR data model has been allowed to find a working balance between complexity and coverage.
In short, FHIR’s data model is an improved and modernized synergy of V2 and V3 ideas. And while no model is ever complete, the FHIR R4 standard has been refined and represents the thinking of the world’s best clinical data informaticists.
Stay tuned for Part II: FHIR 4 Workflow and Technology  where we will discuss FHIR 4’s impact on technology and workflow.