How the Burning FHIR Affects Healthcare Organizations?

Today we would like to have all our health information at our fingertips. Just like the access to emails, calendar, maps, etc., it would be awesome if we also had a similar arrangement to view our cholesterol levels, insulin, and other vitals on the fly.

With the boon of digitization in healthcare, care delivery became faster and easier, but interoperability got lost somewhere in this revolution of healthcare. Without it, our ‘modernized and digitized’ systems weren’t as capable as we had hoped them to be in terms of delivering the efficiency needed in health care.

Standards were developed to make for a smoother transition to make sure interoperability does not lag behind and eventually forgotten. Though slow, the progress is taking place to connect healthcare seamlessly.

HL7 FHIR, one of the most talked-about developments in healthcare, came up on the front lines with the success of RESTful based APIs. It was nothing less than a flexible idea- traditional health data exchange, but from scratch and with a modern approach. As it turns out, several ideas served as the foundation for FHIR:  

HL7 V2: the bedrock

Health Level Seven (HL7) International came up with certain interoperability standards for the smooth flow of healthcare data. Its main idea was to exchange data in a batched or grouped manner. A well-established standard created by clinical interface specialists, HL7 V2, has following features:

• An 80-20 approach, where 80% of the interface framework is fixed, and the rest 20% would reflect custom business, clinical, and administrative needs.
• Defined encoding rules, groupings, and default ASCII character set for data exchange.
• Batch processing and exchange of message files.
• Support for local variations in data exchange by allowing optional/additional message fields.
• Compatible with lower layer protocols to avoid replication of features, application protocols, and other existing health care protocols.

Why we needed something better than HL7 V2?

The lack of precision and complexity that V2 endorsed became a roadblock in time. As it became a legacy standard, its utilization for modern devices and apps trying to leverage patient data began diminishing.

Another problem was that the entire data has to be transmitted and it wasn’t possible to send data across selectively. Moreover, adding new elements into the standard became time-consuming as the entire architecture had to be recreated from bottom up.

HL7 V3: the successor

Next standard was the HL7 V3 that defined applications. This means there were fewer options to define something new within the standard. V3 addressed the challenges of V2 in these ways:

• A consistent data model with defined applications and message syntax was defined.
• Application roles were very well defined
• Message optionality was limited
• Less cost was incurred in building and maintaining mid-to-long term interfaces

What did HL7 V3 lack?

The newer had no compatibility with the older format i.e. HL7 V2 and thus, retraining and retooling became a necessity for any organization adopting it. For clinical interface specialist, the standard was heavy on the pocket to change for to customize it, as it had to be restarted and had long adoption cycle.

The unpopularity of both the standards was due in part because one was too flexible while the other too rigid and a new ‘digital divide’ was created.

The foundation and the surface of FHIR

FHIR which stands for Fast Healthcare Interoperability Resources is the brand new standard to have come out of HL7. It came about as a result of a special HL7 test called “The Fresh Look” task force. It was needed to make up for the limitations of V2 and V3. With the best features borrowed from both as also from CDA (clinical document architecture), FHIR boasts the following key features:

• It is way faster to design and implement than the previous standards.
• It is customizable, has speed and document exchange.
• It supports four interoperability paradigms – REST, Documents, Messages, and Services. FHIR resources are formatted in commonly used XML or JSON formats.
• Besides structured data, resources in FHIR contain human readable text.

As opposed to the segments in HL7V2, the resources in FHIR can be independently queried or updated and are sometimes linked together. Each can stand alone and be exchanged independent of other resources. They are easy to extend and to adapt. Therefore, resources are simple and follow a modular approach, and that’s why FHIR stands out as a more refined version of interoperability standards.

How will these changes affect healthcare?

Physicians will be able to access health data on their mobile phones through numerous API (Application Programming Interface) functions that FHIR supports. This ease of access to complete and accurate patient data will, in due course help in many ways.

As providers and health coaches work together on improving the health of the population, it becomes extremely crucial for them to be able to access accurate data from sources other than EMRs. FHIR acts as a bridge to the gaps in tools by providing care management teams with the capability to connect with the patient data seamlessly through open APIs and view patient records on the fly.

FHIR: Making digital health care easier

Consider a patient referred to some other location by his Primary care Physician. In this scenario, his immunization, lab, and vitals data will be sent to the state and stored in one of the FHIR repositories. The advantage of FHIR here is that it provides clinician and patient the flexibility to access patient data on their favorite FHIR-enabled app, instead of logging into a state-provided portal.

This process not only provides ease of access but also allows the integration of accurate patient data on one app where one can view it without visiting the EMR every time.

The future of FHIR

We now have the next generation of technology being introduced in healthcare, and we need revolutionary solutions to make these technologies create an impact on granular levels. Today, our focus should be on developing FHIR-based APIs to help healthcare organizations enable seamless information sharing on an expanded network of electronic health records and other health information technology based on the Internet and different architectures.

Interoperability has the capability to redefine the basic premise of health IT. Without it, we will stay stuck where we are and make healthcare more complex, or we can achieve true interoperability and advance coordinated care delivery.

For more updates, Subscribe

If you want to see our efforts in the area, schedule a quick demo.