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 so clinical data can move out of Electronic Health Records systems to the other providers who make up a care team. Clinicians need a complete picture of patient data for patient safety and Clinical Decision Support.  

In this blog on HL7’s  FHIR®, JPSys data standards whizzes, HL7 Fellows Galen Mulrooney, HL7F and Jay Lyle, HL7F, will be sharing their expertise. They have been representing the VA’s at HL7 Working Group meetings for 20 years now, concentrating 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), working 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, who 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 and 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 being transmitted back and forth  was not human readable, and there was a lot of variability between organizations (which was allowable in the specification).  This required that time and labor intensive planning and negotiation be done 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. There would have to be a tedious data exchange agreement worked out between them as to how they would specifically format the data to be sent.  

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 than it is for Organization B, which is internally compliant, but the two organizations still won’t be able to “talk” to each other without a certain amount of negotiation between them.  

 
In the early 2000s, HL7 attempted to fix these issues with HL7 by moving to an XML based standard, and 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 they were able to support very complicated scenarios, it 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, which got traction because it took abstract models and nailed down the loose ends, and can 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 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. 

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.  

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.