What Is HL7 FHIR® and How It Helps Data Management

What is HL7 and what is its relation to FHIR®?

Health Level Seven International (HL7), a pioneering organization in healthcare information exchange, established HL7 FHIR® certification as a key milestone for advancing healthcare data standards. 

Since 1987, HL7 has led healthcare standardization, beginning with V2 – which remains backward compatible and powers 80-90% of today’s medical software. Building on this foundation, HL7 introduced the Reference Information Model (RIM) in 1999 and Clinical Document Architecture (CDA) in 2000, both providing a universal reference model for healthcare data integration.

In 2014, HL7 unveiled Fast Healthcare Interoperability Resources (FHIR®), a groundbreaking standard that has garnered significant attention in the industry. 

FHIR®, meaning Fast Healthcare Interoperability Resources, is not just a standard but a more comprehensive messaging standard. It also represents a new paradigm in healthcare data sharing. 

Unlike software or theoretical models, FHIR®is a comprehensive specification designed to enhance the exchange, integration, and sharing of healthcare data. Its adaptability and innovation are evident in its multiple releases, with the current focus being on the R5 release. 

What does FHIR® do?

Fast Healthcare Interoperability Resources (FHIR®) transforms healthcare communication by standardizing how medical data is structured and shared. It defines specific resources—structured formats that describe medical information—ensuring consistency and interoperability across systems.

FHIR® sets data exchange standards that enable integration across disparate and often incompatible healthcare systems. It bridges these gaps to improve communication and ensure seamless data sharing. Additionally, FHIR® provides guidelines for API development. It outlines management practices and technical requirements to support interoperability.

By doing so, FHIR® sets a new standard for data exchange and builds a foundation for a more interconnected and efficient healthcare ecosystem. It ensures seamless information flow, which improves patient care and streamlines processes. 

What are resource structures? 

Every resource consists of a structure used by HL7 FHIR®, composed of essential data elements including patient demographics. This structure incorporates key factors like resource ID, document language, and rules for completion. It also includes metadata like the resource version, update history, and associated tags.

The most important bits are the data fields. Every field has a designated type of data that corresponds exclusively to it. The types of data fields range anywhere from texts, IDs, and URLs to numbers, dates, and responses to yes and no questions. 

There are also more complex data types consisting of a smaller number of simpler data fields. An example of that is the address data field which includes data types like the user’s country, city, line, and postal code information. 

A similar pattern is followed when users have to fill out a section about their name. Due to name formats being quite different depending on the country or origin the user is from, a new order of data fields has been implemented by the creators of the HL7 to ensure an easier-to-follow standard for filling out this data. 

The order goes with the family name first, followed by the given (or first) name and the name prefix.  Other complex data types include money, periods, electronic signatures, laboratory data range, attachments, and many others.

On top of this, we can have lots of external resources stacked in a single data field. To make this system more user-friendly, it also includes a narrative field. With this feature, the data field needs to have a human-readable text, that just includes the information in a summarized way that is easier to read by someone browsing through all the data.

If all of these resources don’t actually help us describe and summarize your case, there are extensions and modifiers designed to provide a solution to this exact problem. The FHIR® specification was made for medical cases that concern humans but it has turned out to be extremely useful for veterinarians too. The reason for this lies in its capability to enable users to depict the animal while identifying its type, race, and breed.

Real-life resource application 

Let’s take someone called Jack who has had an accident and needs to go to the hospital to have a check-up. 

Now when he enters the hospital, there is a certain amount of information that he needs to fill out. Here is a sample to give you an idea of what it looks like:

And lastly, there are connecting resources that serve to connect two separate resources to clarify the relationship between them when cases are more complex. In the first case, it connects the doctor to the institutions they work for. 

In the second it provides an overview of the encounter between the doctor and the patient. Here is an example to give you an idea of the format:

In order to give somebody a diagnosis for their problem, Hl7 FHIR® uses a resource called ‘condition’. With the data types included in this resource, it would look something like this:

After the problem has been identified, the patient is going to receive a prescription. This data is presented using the resource called ‘medication request’. Using the same example as before, this is how it’s going to look like using HL7 FHIR® :

After the observation has ended, the patient has taken some time off by using the medication, it is time for that patient to book another appointment post-treatment to serve as a check-up. To reflect this step of the process, the resources are structured in the following way:

It is very similar to the digital calendars and task management tools that allow us to schedule meetings. Using the same type of resource we are able to check the schedule of the doctor to know when the patient can arrange for their control checkup. Here’s the structure used by HL7 FHIR® for dealing with that information:

The available times are stored as slots that all need to have a very specific definition (busy or free) since they are connected to the doctor’s calendar. 

If the proposed appointment is not compatible with the schedule of the doctor then another slot resource is being created with a new proposed time that will look like this:

Using HL7 FHIR® to deal with processing payments

Luckily for us in the example case study we have been dealing with so far, John White does have a medical insurance plan with the hospital he ended up in. To reflect that, the information is presented in the following format:

He can then file a claim with his insurance provider and use the invoice provided to him by the hospital as proof of treatment. After the insurance provider checks the information and processes the payment, John can get his payment notice digitally.

Resource categories

FHIR® encompasses a comprehensive array of over 150 defined resource types, including lab results and diagnostic reports that follow industry standards. Each serves distinct functions, as demonstrated in the example above. 

To facilitate understanding, these resources can be categorized into several distinct groups.

Foundation resources 

At the core of FHIR® are the foundation resources, acting as fundamental building blocks upon which all other resources are constructed. These resources establish the essential framework for the entire system. 

Basic functional categories 

The second category comprises resources that form the bedrock of various healthcare functions. Within this category, there are resources such as person, patient, practitioner, organization, encounter, appointment, and device. These resources are instrumental in managing fundamental aspects of healthcare interactions. 

Clinical resources

This category includes resources vital to clinical contexts, such as:

• Condition;
• Observation;
• Medication;
• Procedure;
• Care;
• Immunization;
• Nutrition order. 

These resources play a crucial role in documenting and managing patient health data across every healthcare process.

Financial resources 

Another significant category consists of financial resources, including coverage, claims, and invoices. These resources are pivotal in handling financial aspects within the healthcare domain, ensuring seamless transactions and billing processes. 

Specialized resources

Finally, there are specialized resources such as ResearchStudy, MedicalProductDefinition, ClinicalUseDefinition, and Questionnaire. These resources cater to specific and specialized areas within healthcare, serving unique purposes in research, product definition, clinical usage, and data collection.

Presenting the resources: languages and data protocols

The resources, consisting of clinical documents, need to be presented using the following languages:

• XML

The Extensible Markup Language (or ΧΜL) is a versatile format used for structuring and organizing data in a readable manner. It uses custom tags to define elements and their relationships, making it widely employed for data exchange between different systems and platforms.

• JSON

JavaScript Object Notation (or JSON) is a lightweight data interchange format. It is easy for humans to read and write, and easy for machines to parse and generate, making it a popular choice for data transmission and configuration settings in web applications.

• RDF (Turtle)

Resource Description Framework (RDF) in Turtle format is a standard syntax for representing and exchanging semantic data. It uses triples (subject-predicate-object) and a simple, human-readable syntax, allowing the expression of relationships between resources, making it fundamental for semantic web applications and linked data.

• UTF-8 encoded text

UTF-8 is a character encoding standard that represents text in computers. It can encode virtually every character from every writing system and is widely used on the internet, ensuring compatibility for various languages and symbols in digital communication.

The data protocols used and supported by HLA include:

• RESTful Web Services

RESTful Web Services, based on Representational State Transfer, provide web architecture for seamless integration. FHIR® APIs and modern web technologies enable this integration through standardized methods.

• (REST) principles

They use standard HTTP methods (GET, POST, PUT, DELETE) to perform operations on resources, allowing interoperability between different healthcare platforms on the internet and enabling stateless communication and information sharing between client and server.

• OAuth 2.0

OAuth 2.0 is an industry-standard protocol for authorization, allowing secure access to resources without sharing user credentials. It enables applications to obtain limited access to user accounts on HTTP services, commonly used for authentication and authorization in APIs and third-party applications.

• RBAC and ABAC

RBAC (Role-Based Access Control) is a security approach that restricts system access to authorized users based on their roles within an organization. ABAC (Attribute-Based Access Control) is a more flexible access control method where permissions are granted based on attributes associated with users, resources, and the context of the access request, providing fine-grained access control.

• SMART on FHIR®

SMART on FHIR® is a healthcare standard that combines SMART (Substitutable Medical Applications, Reusable Technologies) and FHIR® to create interoperable and secure healthcare applications. It allows developers to build apps that can run on different healthcare systems, providing seamless integration, data access, and patient interactions.

Even if you are not a tech expert, you can still navigate the resources in all the formats by just looking at the text field where all the useful information will be given as output by the software.

Numerical medical codes

In some of the resources in the case study, you can see how each category connected to a patient’s diagnosis and research has been given a code. The observation category can be about an exam, a survey, a lab test, the patient’s vital signs, and others. 

Similarly, the appointment status can be updated with the following status updates that are often encoded:

• Proposed;
• Pending;
• Booked;
• Canceled;
• Arrived;
• No-show.

One of the terms used for each of the codes you might have noticed appearing on a couple of the resources is ‘LOINC’. This is another standard that is unrelated to the one offered by HL7 FHIR®, as it is more focused on giving a number sequence to a certain medical diagnosis. For example, blood pressure systolic and diastolic as a condition has been given the sequence number 85353-1. 

Despite it being an external standard it has been incorporated into the HL7 FHIR® framework. This type of integration of external standards and resources is quite typical.

Here are some of the other standards integrated into FHIR®:

• SNOMED CT (Systematized Nomenclature of Medicine Clinical Terms
• ICD (International Classification of Diseases)
• DICOM (Digital Imaging and Communications in Medicine)
• CPT (Current Procedural Terminology
• HCPCS (Healthcare Common Procedure Coding System)
• RxNorm (by the National Library of Medicine)

The last few are mainly used by health practitioners and developers in the USA but they have also been adopted as standards in other countries too. 

What do we use FHIR® for?

Before we define data interoperability, we need to first take a look at the purpose of FHIR® and what it is commonly used for. Its main function is to act as a bridge between different incompatible systems by managing to integrate the information so it can be shared between those same systems. 

Secondly, it is used for the storage of Electronic Health Records (EHR) like patient profiles and report cards. That is the case because of how easy it is to describe each of the cases using the FHIR® standard.  

Thirdly, it is extremely useful to developers and users of mobile health applications (mHealth). Each of the resources and standards is vital for specific use cases – devices and products like the Apple Watch and other fitness and health trackers. 

And last but not least, when it comes to more complex cases it is also used for automated clinical decision support and research. 

The above-mentioned resources and codes allow for clinical information in such cases to be stored, presented, and shared in the most efficient way possible. 

How FHIR improves data management

FHIR® makes healthcare data management simpler and more effective. Instead of dealing with scattered patient information across different existing systems, healthcare providers can now find everything they need in one place.

The system organizes patient records in a clear way that any healthcare facility can understand and use. When doctors need to check medical history or add new information, they can do it quickly and accurately. This means less paperwork and more time for patient care.

Security is a key feature of FHIR®‘s data management through rigorous mechanism and custom formats. The system carefully tracks and controls all access to patient records, ensuring healthcare data remains safe and private.

Most importantly, FHIR® helps different healthcare systems work together smoothly. When hospitals share patient information, the data transfers clearly and completely. This cooperation leads to better patient care and fewer mistakes in medical records.

What is interoperability?

Imagine that you have a couple of different medical institutions (e.g. two public hospitals) and each of them is using a different computer system that is incompatible with the one used by the second institution. 

This means that if John White had to be transferred to another hospital his medical record would not be successfully sent to or processed by the new hospital. Similarly, for John to pay the other hospital using his insurance provider would be nearly impossible because of the transfer.

If each of these systems used by the hospitals was or became compatible with FHIR® would be able to use the above-mentioned resources. As a result, they would be able to properly communicate and share data about patients and cases between each of the institutions. 

FHIR® uses three core mechanisms for data exchange, each enabled by the FHIR® HL7 interface engine. These mechanisms follow a detailed implementation guide to ensure standardized communication:

• REST API;
• Documents exchange;
• Send/Receive Messages.

Now, let’s take a look at what each of them means.

REST API

Imagine all health records, documents, medication prescriptions, and checkup schedules stored under a single roof. This mechanism ensures that if a medical expert or a doctor requires information they can get access to it immediately.

It ensures that they get all the data that they need and filters out unnecessary information depending on the doctor’s request. There is also the possibility for this request to be denied if the doctor does not have the right to access certain sensible information (e.g. personal patient records).

Documents

All the resources can be collected, packed, and given a title using a separate special resource with the name ‘Composition’ that would look something like this:

This information is then stored in a folder and that is what we call a document. This document can then be sent to the different medical institutions that need access to it. 

Messages

This mechanism is very similar to the documents type but they are less full and function more like notes. Notes can be stacked and then sent around. For example, if John goes to the hospital, the hospital can send John’s record to the doctor. After the checkup, the doctor can request an analysis of an X-ray report card. 

Lots of different reminders can then be sent depending on who needs them. A patient can get a reminder about taking or buying their medication while a doctor – about a newly-scheduled appointment. 

Whether you’re a startup, a Fortune 100 company or a government organisation, our team can deliver a solution that works for you.

BGO Software

Final words

FHIR® is transforming how healthcare information is shared. It helps bridge data exchange gaps across the healthcare industry. The way FHIR® works is simple – it provides basic building blocks that make implementing healthcare systems easier.

During the implementation process, the standard ensures that patient data flows smoothly between different healthcare organizations. It also helps measure and improve the quality of care through built-in quality measures.

Looking ahead, FHIR® will continue making healthcare data exchange simpler and more reliable. Its practical approach to sharing medical information means better care for patients and more efficient work for healthcare providers.

This new way of handling healthcare data isn’t just a technical improvement – it’s making a real difference in patient care and healthcare delivery every day.

Lachezar Gorchev

Lachezar is a senior software developer and consultant with over 20+ years of experience building and developing different projects in various business sectors. Good team player with the ability to explain difficult topics in an understandable way.