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 FHIR 4 is poised to help data movement for each.
Terminology
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 LOINC codes for lab results.
The challenge is that much of the clinical content in a message is not part of an interoperability standard like HL7 FHIR. Rather, HL7 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 CDA 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
Data Model
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.
