Part II: FHIR 4 Workflow and Technology
Part I: FHIR 4 Terminology and Data Models  detailed 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 helps solve for healthcare interoperability in terms of terminology and data models. In this second installment, workflow and technology take front stage. And while 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... supports data movement on several axes, it is the most helpful with these two.
Workflow is how clinical work is done in a given care setting. While there are many examples of how an Electronic Medical Record (EMR), as defined in Defining Key Health Information Technology Terms (The National Alliance for Health Information Technology, April 28, 2008): An electronic record of health-related information on an individual that can be... 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 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... 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 (Representational State Transfer) is a web services approach used heavily in social media sites. Uses HTTP in conjunction with GET, POST, PUT, and DELETE. 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 .)