Healthcare records are increasingly becoming digitized. As patients navigate the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. Further, to support automated clinical decision support, interoperability, and other machine-based processing, the data must also be structured and standardized.
FHIR is a new specification based on emerging industry approaches and informed by years of lessons about requirements, successes, and challenges gained through defining and implementing HL7 v2, HL7 v3, RIM (Reference Information Model), and CDA (Clinical Document Architecture). FHIR is used as a stand-alone data exchange standard. FHIR standards are based on the latest tech stack – JSON, RESTful APIs, XML, HTTP, etc. However, it also has its uses in partnership with widely used standards. FHIR has resources (data formats and elements) and API (Application Programming Interface) to exchange the data from EHR (Electronic Health Record).
Components
The basic building block in FHIR is a Resource. All exchangeable content is defined as a Resource. All Resources share the following set of characteristics:
- A common definition and representation, built from data types for common reusable patterns of elements
- A common set of metadata
- A human readable part
Different types of resources can be used to exchange and/or store data to solve a wide range of healthcare related problems, both clinical and administrative. This specification also defines several different ways of exchanging the resources.
A resource is an entity that:
- has a known identity (an URL) by which it can be addressed
- identifies itself as one of the types of resource defined
- contains a set of structured data items as described by the definition of the resource type
- has an identified version that changes if the contents of the resource change
Resource Example: Patient
This simple example shows the important parts of a resource: a local extension, the human readable HTML presentation, and the standard defined data content.
FHIR has resources for administrative concepts such as a patient, provider, organization and device as well as a wide variety of clinical concepts covering problems, medications, diagnostics, care plans, financial concerns and more.
The resources are described in several different ways:
- A hierarchical table that presents a logical view of the content
- An UML diagram that summarizes the content graphically
- A pseudo-XML syntax that provides a visual sense of what the end resource instances will look like in XML
- A pseudo-JSON syntax that provides a visual sense of what the end resource instances will look like in JSON
- A pseudo-Turtle syntax that provides a visual sense of what the end resource instances will look like in Turtle
FHIR Implementation
FHIR aims to simplify implementation without sacrificing information integrity. FHIR has built-in mechanisms for traceability to the HL7 RIM and other important content models. This ensures alignment to HL7’s previously defined patterns and best practices without requiring the implementer to have intimate knowledge of RIM or any HL7 V3 derivations.
In a nutshell, FHIR is the future of healthcare interoperability given that it can be extended to mobile, iPads, etc. One does not need to be an HL7 expert but an understanding of FHIR structure components and resources, how to use them, backward compatibility use will suffice the need for implementation. FHIR will help data exchange and data integration to progress by leaps and bounds so that we can achieve global ideals such as ehealth and connected health.
The upcoming topics that you can find shortly are:
- Detail analysis to early adopters of FHIR standards
- Migration Roadmap to FHIR from your current HL7 version
Do reach out to us to learn more about our services.
