The Quest for FHIR: Managing Emerging Standards in Healthcare Data and Emergency Response

What is FHIR?

In simple terms, FHIR is a set of software components designed to share healthcare information using a standard set of resources. These resources can be used and combined to model and implement a vast number of healthcare scenarios.The FHIR standard is known for its flexibility; developers can use resources independently or combine them to create complex data structures that suit a wide range of clinical and administrative scenarios. This modular approach allows healthcare providers, app developers, and researchers to create applications that can interact seamlessly with diverse systems, whether in hospitals, clinics, or other healthcare environments.

By exchanging models made of standard building blocks, loosely based on design principles like object-orientation, Terazo built a number of triage solutions using this standard. These solutions were made to rapidly integrate Electronic Medical Record data from various vendor systems across the various custom tools healthcare organizations used to manage the health care crisis. After quickly bringing these tools to production, we’ve used FHIR not just as a basis for data exchange between otherwise incompatible medical systems, but as a basis for persistence in its own right.

Achieving greater healthcare data interoperability

The need for healthcare data interoperability isn’t anything new. Standards like Health Level 7 (HL7) have been used since the late 1980s to facilitate data integration. Version 2, with its segmented, character-delimited format has likely seen the widest adoption. The later XML-based Version 3 provided a human-readable basis of message exchange. While HL7 remains widely used as a basis of integration, both system participants exchanging data must conform to the HL7 v2.x or v3.x standards.  This standard, while rich, is complex to implement and maintain. It requires specialized skills that are not always easy for a development team to acquire.

2011 saw allied health data trend in a new direction. The emergence of FHIR, managed by Health Level Seven International, saw a need for a more democratized format for healthcare data exchange. Developers now had a toolkit based on well-established universal design and development principles called Resources, that any IT professional could rapidly learn and adapt. Healthcare professionals could work with architects to develop their own models for specific sectors of the healthcare ecosystem, unhindered by the complexities and standards of HL7.  HL7 wasn’t phased out, but FHIR added new tools to the development toolkit that could facilitate custom EMR system integrations, at scale, at speed.

Creating a central source of healthcare data truth

FHIR provides API development and data engineering integrators, including Zennify, with REST API standards—a familiar development paradigm and an easy movement of data from programmatic resources to JSON, XML or RDF. It is the rare EMR vendor solution that does not provide a FHIR-compliant interface, and Zennify has used these interfaces to enhance scheduling systems, enhance patient portals and facilitate telemedicine solutions.

The most exciting aspect of opportunity is the use of FHIR as a persistence solution in its own right. A model flexible enough to capture most healthcare scenarios has now been identified as a basis for the actual healthcare itself. The emergence of FHIR servers, such as HAPI or Medplum, has opened up the possibility where the central source of truth for healthcare data can be a custom model based on FHIR. In this case, the server component provides both standard FHIR endpoints and a high-performance ORM that typically maps FHIR resources to an underlying relational database.

With Medplum as our server of choice, Zennify adapted this more recent innovation in the managed care healthcare space to design and implement a FHIR-based data model specifically for managing emergency scenarios for the elderly and infirm. Our solution was designed to provide an operational basis for managing patients, their providers, recording emergency scenarios and how they were handled. The FHIR resources provided a set of building blocks that could model the process of emergency and non-emergency healthcare our client required, but also exposed potential for future services.

Our client specialized in providing emergency care in the event of a fall, the most common cause of traumatic brain injury. The FHIR model was flexible enough to provide the basis for new services in the IoT space, particularly smart devices for monitoring heart health, blood oxygen, and other relevant vitals. Finally, the model was built using what we call vanilla FHIR, the basic abstractions present in the standard and nothing else, allowing the data to be easily shared as part of a broader healthcare ecosystem.

Overcoming generic abstractions with extension points

FHIR is well-established as the standard toolbox of resources for healthcare model design and construction. However, the trade-off is sometimes that the abstractions are too generic. For example, in FHIR, a Patient resource can represent any individual receiving healthcare services. In an environment with a wide range of different patient “types”, data specific to that resource needs to be supplied to differentiate it from others. This can make it more difficult for practitioners to understand what the model represents in certain circumstances.

Fortunately, FHIR provides numerous extension points in each resource for full customization to specific requirements. These extension points in each resource are numerous and provide multiple documented vectors of modification.  While the standard does not yet allow new resources to be derived, there are ample ways to change it to meet specific customizations.

Our customers typically use a combination of HL7 and FHIR for interoperability and persistence requirements. HL7 is a perfectly serviceable standard with systems that interchange data using v2 and v3 - data that doesn’t require any “updates” simply because it’s the newest system. That said, healthcare presents a dynamic problem and opportunity space, from regulatory change to new avenues of healthcare. Working with numerous healthcare systems, we often service clients that aspire to use FHIR in new forms.

FHIR is still very much an emerging standard. The current Release 5, or R5, version is very much a release for production uses and is already deployed all over the world—but FHIR has not yet achieved parity with the healthcare ecosystem coverage supported by its older healthcare sibling, HL7. For example, in areas as diverse as medical billing or clinical lab management, FHIR only provides basic resources, sufficient for many scenarios but still requiring more specific abstractions to round out the resource library. Nevertheless, with an open process the HL7 committees are open for new enhancements that are sourced from the healthcare community.