Interoperability is one of the most pressing issues in digital healthcare. Establishing a data standard that provides a smooth, flexible, and real-time exchange of information has been a long-term goal of healthcare organizations, stakeholders, and developers across the globe.
HL7, an international standards organization, sought to solve the issue of interoperability by developing a future-proof standard that would streamline the sharing of clinical records between different providers in a secure manner. Thus, the Fast Healthcare Interoperability Resources standard, or FHIR (read as “fire”), came into existence. You can think of it as a universal “language” or more precisely a set of frameworks for storing and exchanging healthcare data. The standard describes resources, approaches, and APIs that have many different contexts in healthcare.
However, when discussing unified standards, one of the most vital concerns and effectively the reason behind why it’s so challenging to develop such a standard is the unique healthcare requirements of each organization. They can vary depending on jurisdictions, legislation, practices, and organizational processes. So how does FHIR tackle this issue?
To fully explain it, we will first need to dive into the inner workings of FHIR.
The building blocks of FHIR resources
A resource defines an indivisible unit of information in a particular context. It may be a patient, medical procedure, examination, medication, insurance coverage, etc. Essentially, FHIR resources provide a way of describing context. For example, typical medical data, like a healthcare plan, observation, or diagnostic report, may also include technical (structure definition) or financial (claim, insurance plan) information. To gain a comprehensive understanding of the FHIR standard and its foundational components, it’s beneficial to explore what is FHIR.
The number of resources and resource elements, along with their naming, data types, and the relationships between the entities, are all defined by the standard.
The key requirements for FHIR resources include:
- Identical definition and representation, including the names of attributes, types of data, and relations between data arrays
- Standardized types of data for the resource attributes (1+2 = Base resources, defined by the standard specifications, have a standard list of elements, types, and relations between data arrays.)
- Standard metadata, defining the technical context of each resource: ID, version, profile, text narrative, last updated
- Human-readable format
Specifying context with FHIR profiling
FHIR is designed to standardize about 80% of healthcare information and medical records.The standard defines the majority of existing medical data processes and elements. But each case of FHIR implementation is unique, and so are the resource use cases. We specify resources to help define rules and requirements based on the context used. This process is referred to as FHIR profiling. FHIR profiles allow you to customize resource definitions by constraining which elements of a resource are required and which are not. As such, profiling becomes an essential part of FHIR adoption.
Profiling helps define the missing extensions that should be added and how API functions and terminologies should be used (terminologies in FHIR are defined using value sets and code systems). The constraints and extensions of a FHIR resource also help improve the quality of data by encouraging data consistency and manageability.
Read Also: Mapping Healthcare Data to HL7 FHIR Resources
A typical FHIR profile will consist of:
- general requirements describing its goal, category, and the original resource configured by the profile
- a snapshot section with a full configuration of the profiled resource
- a differential section focused on the differences between the profile and the base resource (This section and the profiler tool help make profile configuration easier for data analysts.)
While there are ready-made standard FHIR profiles published by HL7, these profiles still require healthcare developers and business analysts to develop their own FHIR patient profiles that meet the requirements of a specific project. There are also FHIR profiles authorized by legislative regulations in particular countries. For example, the USA has CARIN for Blue Button and the US core frameworks.
Implementing FHIR profiles
An implementation guide (IG) is a crucial document for the implementation of FHIR profiles. It describes how HL7 FHIR profiles are used or have to be used for a particular task — for instance, which patient attributes should be filled in to comply with national standards or which terminologies should be used. Typically, implementation guides are published online after being created with a FHIR IG publisher. You can find some examples of published IGs on the FHIR registry.
Useful profile-authoring tools and resources
We’ve put together some useful tools and links that will help those interested in either creating FHIR profiles or developing implementation guides to make their jobs easier. You can find an extensive comparative list of some of the FHIR profiling tools on the market here.
Tools
- Kodjin FHIR Profiler — a free tool with an intuitive UI and visual resource structure that automates many of the core aspects of profile creation, including data validation; offered as part of the low-code Kodjin FHIR Server Suite
- Forge by Firely — a manual FHIR editor for building FHIR profiles, FHIR data models, and extensions
- Trifolia-on-FHIR (ToF) — FHIR resource editor using a FHIR server natively as the back end.
Read Also: Healthcare Data Visualization: Importance, Benefits & Examples
Resources
- Simplifier.Net — a FHIR profile registry where you can find HL7 FHIR resources or share your own
- Profiling FHIR (release 5.1.0) — comprehensive documentation on FHIR profiling from HL7, including slicing in FHIR and other details (You can also find a FHIR profile example there.)
- Guidance on writing FHIR profiles — FHIR profiling guidelines, compiled by healthcare professionals participating in the IHE (Integrating the Healthcare Enterprise) initiative
As you can see, profiling is one of the features that make the FHIR standard so flexible. No matter if it’s a national patients’ records database, an insurance company, or a healthcare provider, interoperability can be achieved between them all. It’s a way to make the coordination and the exchange of information not only seamless but also cost-efficient in the long run as well. FHIR Profiles play a crucial role in healthcare data interoperability, and the HL7 FHIR Data Model serves as the backbone for ensuring that these profiles maintain consistency and accuracy in data exchange.
Read also: The Key Features of the FHIR R5
Configure your FHIR profiles yourself — or leave it to the professionals!
We are still in the early days of FHIR adoption; as such, it can be difficult to find the right subject-matter experts for FHIR implementation. At Edenlab, we have delivered numerous high-load projects for healthcare providers and organizations, including developing a 30-million-user national E-Health system based on FHIR. Whether you are struggling with FHIR implementation for your highly specialized field or seeking seamless interoperability, our team can help you fulfill your needs. Contact us, and let’s discuss your project! Also, don’t forget to check our Terminology Service.
