What is HL7 and what is its relation to FHIR®?
Health Level Seven International (HL7) stands as a pioneering organization dedicated to shaping the landscape of healthcare information exchange. Since its inception in 1987, HL7 has been at the forefront of healthcare standards, introducing the very first healthcare standard – V2.
Despite its age, it is still widely used and forms the backbone of about 80-90% of medical software today. Over the years, HL7 has introduced key standards such as the Reference Information Model (RIM) in 1999 and the Clinical Document Architecture (CDA) in 2000. Both standards have played pivotal roles in 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 as it also represents a new paradigm in healthcare data sharing.
Unlike software or a specific platform, 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?
At its core, Fast Healthcare Interoperability Resources (FHIR® ) serves as a revolutionary catalyst in the realm of healthcare communication. One of its primary functions is the definition of specific resources, primarily structured formats designed for describing medical data.
FHIR® establishes crucial data exchange standards necessary for integration among disparate and often incompatible healthcare systems. This integration is pivotal as it aims to bridge the gaps between these systems, making them compatible and enhancing overall communication. FHIR® also acts as a guiding light, providing essential management tips and outlining requirements for the development of FHIR-compatible APIs.
By doing so, FHIR® not only sets a new standard for data exchange but also lays the foundation for a more interconnected and efficient future in healthcare where information flows seamlessly, leading to improved patient care and streamlined processes.
What are resource structures?
Every resource used by HL7 FHIR® has a structure. This structure incorporates a couple of factors like the resource ID, the language used in the document, and the outlines of the rules for how one should fill out the resource. It also includes metadata like what the current version of the resource is when it was updated, and what tags have been used for the resource.
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.
Enhance the efficiency of data sharing within your organziation with FHIR.
Maximize the efficiency of your healthcare services by discovering how FHIR can streamline you processes by reaching out to BGO Software’s experts.
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:
|
Patient info |
|
Healthcare Service |
|
Practitioner |
And lastly, there are connecting resources that serve to connect two separate resources in order 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:
|
Encounter |
|
Observation |
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:
|
Condition |
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® :
|
Medication Request |
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:
|
Appointment |
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:
|
Appointment |
|
Schedule |
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.
|
Slot |
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:
|
Slot |
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.
|
Coverage |
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, each serving 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, and NutritionOrder. These resources play a crucial role in documenting and managing patient health data.
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
The resources are just normal text that needs 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 includes:
- RESTful Web Services
RESTful Web Services are a type of web architecture based on Representational State Transfer
(REST) principles. They use standard HTTP methods (GET, POST, PUT, DELETE) to perform operations on resources, allowing interoperability between different systems on the internet and enabling stateless communication 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.
Get tailored advice on incorporating FHIR into your healthcare system.
Innovate your healthcare solutions by using FHIR to transform your data management strategy.
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
- noshow
One of the terms used for each of the codes that you might have noticed appearing on a couple of the resources is ‘LOINC’. This is another standard that is not related at all 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 number sequence of 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 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 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 clinical decision support and research. The above-mentioned resources and codes allow for the information in such cases to be stored, presented, and shared in the most efficient way possible.
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 the needed information about patients and cases between each of the institutions.
There are 3 main mechanisms for data exchange used by FHIR®:
- 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 is in need of information they are able to 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:
|
Composition -title: Patient Medical Record -subject: John White -author: Dr. Harry Roberts |
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
HL7 FHIR® stands as a beacon of innovation in the realm of healthcare information exchange, establishing a new era of seamless interoperability and data sharing. Its robust and flexible framework enables healthcare systems to communicate effectively, facilitating the swift and secure exchange of patient information.
By promoting standardized data formats and APIs, FHIR® not only enhances efficiency within healthcare organizations but also fosters collaborative patient care, leading to better outcomes and improved patient experiences. As FHIR® continues to evolve and gain widespread adoption, it will undeniably play a pivotal role in revolutionizing the landscape of healthcare data exchange.
