Introduction to FHIR

The digital world runs by exchanging information in the form of transactions and messages electronically. Millions of transactions are created and exchanged every moment. What if the information in each transaction is not in an understandable format, and does not make sense to its receiver? That will be a chaotic situation, rendering the information useless. Therefore, a common set of standards is required to keep data interoperable and available for processing. The healthcare industry, as any modern industry, depends on digitization and standardization.

To address this issue in the healthcare industry, Health Level Seven® (HL7®), the standards development organization, has created the Fast Health Interoperability Resources (FHIR) standard. The standard lays out instructions to exchange information between different computer systems regardless of how it is generated and stored in those systems. It provides a secure access to healthcare information, including clinical and administrative data, to those who have a need to access it, and to those who have the right to do so for the benefit of a patient receiving care. The standard is based on a modular approach, which makes it easy for implementation. HL7® uses a collaborative approach to develop and upgrade FHIR.

The standard is comprised of resources for both administrative, as well as clinical, concepts. Administrative concepts include patient, provider, organization, and device. In addition, clinical concepts include problems, medications, diagnostics, care plans, financial concerns, and more. Each resource serves as a basic building block in the whole process of standardization. Assembling each resource together provides a feasible environment to implement complex use cases in the healthcare industry. The resources are scalable in nature, making basic features of the resources extensible and flexible to serve requirements covering many jurisdictions, domains, and different functional approaches.

What about past standards and their versions?

Before FHIR was developed, older versions of the HL7, such as, HL7 v2, HL7 v3, and CDA, were used for the exchange of clinical and administrative data, typically for applications in clinical settings such as hospitals. Sharing of data between providers and payers using these standards was limited. However, implementing FHIR does not make the older versions obsolete. FHIR was developed after taking the best practices from them, such as event-based messaging, granularity, extensibility, compatibility, human readability, optionality, profiles, referencing, implicit or explicit context, markup language, etc. The most significant technical change is the use of XML and JSON data formats to simplify application development.

Also, please note that the FHIR standard is separate and distinct from the HIPAA transaction standards, which define a limited set of administrative and financial transactions that are typically exchanged between healthcare providers and payers (claims, payments, enrollments, etc.). HIPAA is mandated by CMS rules for certain application use cases. HIPAA transactions are a specialized implementation of specifications based on the X12 standard. FHIR supports many use cases that are outside the scope of the HIPAA transaction set.

Where to Start?

To develop a good understanding of FHIR, go through the concepts as defined below:

  • First, learn the concepts of Electronic Data Interchange (EDI) and how exchange of healthcare data put patients at the center, thereby impacting the healthcare outcomes.
  • Second, learn about the FHIR resources. A list of resources can help to see what resources exist, their definition, and how they relate each other. Also, use examples of the resources to understand their use in specific circumstances.
  • Finally, implementers can refer to resources’ notes and Implementation guides. Resource notes are used to understand the design rationale underlying it, and Implementation guides contains a set of rules to solve a particular interoperability or standards problem - typically through the use of FHIR resources.

Components

Resources are the basic building blocks in FHIR. These are data packages used to communicate with a FHIR repository. To communicate well, Resources must share the following set of characteristics:

  • Each one of them must have a common way of definition and representation. Data types that define common reusable patterns of elements must be used to build them.
  • Each one of them should represent a common set of metadata.
  • A human-readable part.

Approach

The primary working principle of FHIR is to build a set of resources that can act as a base to fulfill the requirements of majority of use cases. In other words, FHIR uses a composition approach.

Although a single resource may be sufficient for a given use case, it is a more common and standard practice to combine all the resources and then customize them to meet a use case specific requirement. The following two special kinds of resources are used to describe how resources are defined and used:

  • Capability Statement - Describes the interfaces that an implementation exposes for exchange of data.
  • Structure Definition - Provides additional rules to constrain the optionality, cardinality, terminology bindings, data types and extensions defined in the resources used by the implementation.

Advantages to Software Developers

FHIR is derived from internet standards that are extensively used by industries outside of healthcare. For example, the use of RESTful web services, which describes how to identify resources, exchange messages, and manage stateful interactions. Adoption of familiar standards and technologies to software developers has significantly reduced the learning curve for new software developers to support healthcare needs.

Additionally, the FHIR standard provides the following advantages to software developers:

  • Easy Implementation – Provides a strong focus on fast and easy implementation; developers have reported they experienced simple interfaces being implementable in a single day.
  • Open-Source – Provides free to use configurations with no restrictions.
  • Extensive Support – Provides support from major vendors including Apple, Microsoft, Google, Epic, Cerner, and most other EHR vendors.
  • Tools Availability – Provides an availability of many free, online, and downloadable tools, including reference servers and implementation libraries.
  • References – Abundance of existing examples available publicly to use as a reference to develop new applications.
  • Interoperability out-of-the-box – base resources can be used as is, but can also be adapted for local requirements (the process of Profiling).
  • Evolution from Older Versions - An evolutionary development path from earlier HL7 healthcare standards, Version 2 and Clinical Document Architecture (CDA®), enabling them to co-exist and leverage each other.
  • Foundation in Web Standards – Provides a strong foundation in web standards including XML, JSON, HTTP, and OAuth.
  • Easy Specification – Provides concise and easily-understood online specifications.
  • Human-readable Format – Provides a human-readable serialization format for ease of use by developers.
  • Helping Hands – Assists implementers with a global community.