HL7 FHIR

What exactly is Health Level 7’s FHIR®? 

Healthcare data has to move. FHIR and other HL7 data standards provide guidelines and data structures. These standards allow clinical data to move out of Electronic Health Records systems to the other care providers. Clinicians need a complete picture of patient data for patient safety and Clinical Decision Support.  

In this blog, JPSys data standards whizzes, HL7 Fellows Galen Mulrooney, HL7F and Jay Lyle, HL7F, will share their expertise. They have been representing VA at HL7 Working Group meetings for 20 years now. They concentrate on areas regarding clinical informatics, interoperability, and clinical terminologies at several HL7 Work Groups including the Vocabulary and Patient Care Work Groups. Galen was the Co-chair of the Service Oriented Architecture working group and the Clinical Informatics Modeling Initiative (CIMI). He worked very closely with the people who were developing the FHIR standard when it was first proposed in 2011.  Jay is a Terminology Subject Matter Expert and a Data Standards Architect. He specializes in FHIR implementation and FHIR mapping for API development and has also co-chaired numerous HL7 Standards Working Groups.   

Here Galen and Jay will discuss current topics in HL7 FHIR®, such as Implementation Guides, the US FHIR CORE, and API best practices. First, we will dive into the history of HL7 before FHIR® and why it was needed. Remember the overall goal here is to facilitate the sending of electronic healthcare messages. 

A Brief History of HL7 

Historically business to business transactions, termed Electronic Data Interchange, have used comma delimited files to send data between different organizations. HL7 is a Standards Development Organization (SDO) that has created data standards for electronic transmission of clinical messages. HL7 primarily started off with establishing standard formats for laboratory results reporting and order requests. It branched out into other areas such as prescriptions and admissions, discharges and transfers (ADT) for patients.

In the early 2000s, HL7 realized that there were some deficiencies in the EDI approach. The actual data transmitted back and forth was not human readable. There was a lot of variability between organizations (which was allowable in the specification). This required time, labor intensive planning and negotiation between any organizations who wanted to exchange and use data safely. The standard, which has to work for the whole world, is not very specific in its requirements. Just because two organizations both use the same HL7 data standard didn’t mean that they could talk to each other. A tedious data exchange agreement was required to know how to specifically format the data sent. 

Three HL7 Issues

There were three main sources in an HL7 message where issues manifested. The first is an optional task or optional segments. The standard says you can optionally send a specific piece of data, (e.g., the county a person lives in). That data might be part of one organization’s optional demographic information, but it might be required information for another. If you, as Organization A, send a message that doesn’t have the county, Organization B might reject it.  

The second source is repeatability. For example, some segments, like phone numbers, can repeat. But there might be multiple numbers assigned to a person, such as home phone, work phone, cell phone, etc. One organization might require a cell phone number, but another might not. If Organization A sends a message that doesn’t have the cell phone number to Organization B, it will be rejected.  

The third source of problems is coding. Most EDI standards organizations tend not to be prescriptive on vocabulary, which is what coding boils down to. For example, for medication management, one drug coding system may be different for Organization A vs. Organization B. This is internally compliant, but the two organizations still won’t be able to “talk” to each other without some negotiation.  

HL7 Solutions

In the early 2000s, HL7 attempted to fix these issues. HL7 moved to an XML based standard. In doing so, they attempted to start modeling the data structures and standards, while creating use cases for the models. However, this ended up becoming too complicated. They were trying to think of every possible scenario that might happen. They created very complicated standards that, while able to support very complicated scenarios, made the simple things too difficult.  

In an effort to remediate this, HL7 has developed several standards. First was Version 2 (V2), which was very widely adopted and embedded, especially in laboratories and admission, discharge, and transfer (ADT) systems. The V2 standard was highly successful. The V3 standard was more flexible, though very hard to learn and use. Clinical Document Architecture, CDA, was then created as a subcategory of the V3 standard. This got traction because it took abstract models and nailed down the loose ends. It could also be used for a variety of transmission purposes.  

HL7 defines the specifications, but they don’t enforce the specification. The Office of the National Coordinator (ONC) in the Department of Health and Human Services enforces it. In some countries, the healthcare system is centralized, and the central entity can dictate architectures and can enforce interoperability. In the U.S., we have a free enterprise system without a centralized dictator.  Here, the ONC & Centers for Medicaid and Medicare Services have come together to establish standards in systems that would want to bill Medicare. The ONC administers the regulation of standards and the rules around how they’re to be used.  

Concepts of FHIR 

After CDA came FHIR. HL7 created FHIR to invent a use case driven methodology to allow health systems interoperate with common web based technologies and support specific needs. This time the programmers of the standard received primary consideration as the previous Ver 3 standard had fallen short on practicality. FHIR created specifications in tech that are agile and flexible and offer change. FHIR can fill any gap because it is a general-purpose API standard for interoperability. Anytime you want to communicate, you can use FHIR.  

In the process of building most data standards, HL7 would issue a ballot to test the standard, work for three months on it, and then issue another ballot so that affected parties could have an opportunity to improve and comment. EDI standards were all focused on the data going back and forth between two different organizations, and while they would describe the scenarios or the actions that triggered the transfer of that data, they weren’t prescriptive on what scenarios or situations for which data should be sent, received, or expected. 

FHIR

FHIR is very different. The FHIR standard specifications are tested as they are being developed. It’s much more understandable by programmers, takes advantage of modern technologies like REST, and considers behaviors in the standard. FHIR started out with a prime directive, i.e., guiding principle of looking at the scenarios which people most wanted to implement and then supported 80% of the most common ones. They wanted to purposely move away from the issues that bogged down the previous data standards development work. FHIR  can also facilitate  operations to get data in a certain way, get data for certain purposes, or just to trigger some kind of action on the server.  

One of the things that FHIR does that earlier standards didn’t is it requires a server to publish a capability statement. The capability statement electronically describes what FHIR capabilities it supports, and if it says it supports a particular capability and it doesn’t, then that FHIR server software can be marked as being non-compliant. This is important when getting into regulatory affairs such as Meaningful Use where the government is requiring systems to be certified based on their capabilities. You want to be able to submit your software to be certified and pass the tests based not only on the requirements, but also on whether your server can support a particular operation.

FHIR in Practice 

In a typical business transaction, a computer could act as both the FHIR client one minute and the server the next. For example, a doctor’s office sends a lab order for a patient to a lab. Later, the  software will send a query for that order to a laboratory system about the status of the order placed last week. In that second use case, the doctor’s office system is the FHIR client, and the laboratory system is the server. But when the laboratory system then contacts the ordering system with the results, the laboratory system is now the FHIR client and the doctor’s computer system is the server. In most cases, there are many more FHIR clients out there than there are FHIR servers, but a single system can act as either a client or a server depending on the business need. 

This flexibility is the difference between FHIR and earlier standards, and that’s why  so many people are excited about FHIR: business processes can be split between more and more organizations. The ability to have an electronic contract between the data center and the data receiver is important.

The FHIR Difference

One of the things that FHIR does that earlier standards didn’t is it requires a server to publish a capability statement. The capability statement electronically describes what FHIR capabilities it supports and if it says it supports a particular capability and it doesn’t, then that FHIR server software can be marked as being non-compliant. This is important when getting into regulatory affairs such as Meaningful Use where the government is requiring systems to be certified based on their capabilities. If your server says it could support a particular operation, then it better be able to not only accept the call to that operation but be able to do what that operation is intended to do.