Workflow is how clinical work is done in a given care setting. While there are many examples of how an EMR screen or database implementation drives workflow, interoperability focuses on various points-in-time when a clinical process reaches a known state.
For example, a physician enters a lab order on an EMR and completes all steps required for the order to be “placed” into an active state within the EMR (such as clinical decision support, indications, etc.). In turn, HL7 V2 has a message structure (an ORM) which allows the EMR to send an indication of this new order to the lab system. The workflow’s point-in-time is “new order” and the sending system indicates this by sending a code in a specific ORM field.
So… now what?
Generally, unless the order’s workflow progresses through updates, cancelation, or completion, there are no more HL7 V2 transactions sent regarding the order. While V2 has the limited ability to query and ask for things like current order state, such interactions are rarely implemented—meaning the “source of truth” systems become disconnected islands of workflow state.
Where HL7 FHIR stands out is by helping with the workflow at the “points in between” the HL7 V2 known states. The Greenfield opportunity, which FHIR solved, is allowing a client system to ask a source-of-truth system for details on a resource, such as a patient or order.
This is especially critical when there is no workflow at all.
For instance, today an outpatient system rarely can query an inpatient EMR, lab, or radiology system to ask for current patient information, recent lab results, or historical reports. This new ability for a client system to query a source-of-truth system when required will dramatically reduce the friction of coordinating care, and it is a key advantage of FHIR.
Technology for every interoperability standard is rooted in the era in which that standard was born.
While HL7 V2 was created in the late 1980s and came of age in the mid-1990s, the core clinical systems in place back then were rather old-school (mostly technologies like mainframes, MUMPs-on-DEC hardware, COBOL-based financial systems, etc.). This means that concerns like line limitations due to serial port hardware buffers, or size of in-transit messages, were critical to the success of a standard.
The outcome is that HL7 V2 has somewhat cryptic encoding rules, and vendors typically misimplement various features—mostly because HL7 grew up without a mandate forcing vendors to comply with the standard.
As one of the founders of HL7 likes to say, “When you’ve seen one HL7 V2 interface, you’ve seen one.”
It is key to remember that the context of the V2 standard was not to provide plug-and-play interoperability, but rather to allow for the creation of bespoke interfaces that were “mostly standard.” In a nutshell, the technical underpinnings of V2 are pretty ugly in retrospect.
The approach taken with HL7 V3 was more modern for its time, with lots of formal modeling and an “unlimited size and complexity budget” for the representation. The large, convoluted XML documents are difficult for an average software developer to use and understand.
Like all standards at their birth, FHIR’s approach is to adopt current technology. Today that means REST web services, JSON, and the concept of exchanging workflow and data state via resources.
Combined with FHIR’s focus on making the data model approachable and tackling the Greenfield problem of allowing a client to easily query a source-of-truth system, FHIR’s unique focus on early implementation testing and built-in conformance concepts means it is outstandingly-focused on ease-of-implementation.
Most modern technologists that review FHIR for the first time should feel at home and know how to create a basic implementation quickly. This leads to a major FHIR advantage: faster industry adoption.
(What about the fifth axis? It’s business concerns, and you can read more about it in the recent Healthcare IT News article How FHIR 4 will drive interoperability progress in healthcare.)