In this blog post, I want dive deeply into the benefits of HL7® FHIR®. I have also planned a follow-up post, a practical how-to about using FHIR on the SAP Business Technology Platform. Specifically, the second part will be about utilizing our new cloud-native service SAP Health Data Services for FHIR, currently available as part of an open beta to our partners and SAP BTP customers. But first things first. I want to start with FHIR and its benefits, and I want to start with the beginning: What is FHIR exactly? What are the benefits of using it?
The not-for-profit, ANSI-accredited standards-developing organization HL7® is well-known for establishing industry standards for multiple decades in the healthcare IT ecosystem. Healthcare applications use these standards to facilitate the exchange of patient-related information between different systems. The predominant approach for this has been the messaging standard HL7v2. Fast Healthcare Interoperability Resources (HL7® FHIR®) is the modern standard that replaces and improves previous interoperability approaches. It has gained significant traction in recent years thanks to its simplicity, ease of implementation, and flexibility.
While the often quoted "FHIR Manifesto" did not exist at the inception of FHIR, some important efforts resulted in an official document called the Fundamental Principles of FHIR.
These principles are well understood in the community and nicely explained in the above link. There are a few focus points that you can derive from these principles:
There is an evident focus on implementers. Only standards that are implemented and adopted by others are beneficial. As various environments and use cases use FHIR, it must be able to adapt to these. And there is also the notion of following the 80% principle, e.g., "the core specification only includes those elements used by approximately 80% of implementers - other elements are handled using extensions". Finally, many other principles focus on the community and ensure scalability throughout a potential FHIR-based ecosystem.
In my last blog post, I outlined some advantages of using FHIR. Now, I want to drill down into each of these and explain them in more detail. Naturally, these benefits also mirror the principles outlined above.
Implementability is one of the main priorities of the FHIR specification. Hence, many aspects listed below help to facilitate this goal precisely. To start with, the FHIR specification is also well structured. The FHIR R4 specification is layered in five levels and contains detailed content about the various sections. By the way, the name R4, which you can often see, refers to the version of the specification.
In addition to the core definition, various summaries, introductions, and examples are available to help implementors get started immediately.
FHIR uses web standards, such as RESTful APIs, JSON, and XML, which are widely used and familiar to developers. This familiarity makes it easier to understand and implement than legacy standards like HL7v2 or CDA. Ultimately, any FHIR-compliant app can communicate with FHIR-enabled systems, building the foundation for interoperability.
FHIR is based on modular components called "resources," representing different aspects of healthcare information (e.g., Patient, Condition, Procedure, Consent). It is the format to provide the content and build the domain model. The 80% principle also guides the specification regarding what is defined and needs to be delivered to implement the standard. Hence, these resources can be combined and extended, providing high flexibility and customization.
Let’s have a detailed look what this could look like. Imagine we want to exchange patient information between two applications. The standard Patient resource of FHIR R4 already provides an excellent starting point. It also renders the model as a UML Diagram - see the screenshot below.
Based on this domain model and some sample data set of a given patient, we can represent a patient using the JSON format like this:
As many properties are optional, this very lean data structure is sufficient to let me create a patient in a system. By directly supplying my known identifier to the system, I also ensure I can use this identifier to search for the data later. This approach is already an excellent cutover to the topic of interoperability.
Overall, health information sharing is becoming increasingly important. As data is collected in multiple places, physicians, nurses, but also patients require this data to be available at any point. Without standardization, the necessary point-to-point integration is becoming too complex and costly.
Following the data representation above, let's consider how best to publish this into a given FHIR server. The FHIR standard is open to security, transport, and persistence approaches. In doing so, it helps to ensure that FHIR is flexible and capable of being used with ever-changing technologies. The standard defines four exchange paradigms: REST, document, messaging, and services.
Let’s take REST for our example above, which is also the most adapted exchange paradigm. So, creating a patient in a given FHIR server can easily be accomplished using REST. A simple POST request of the Patient resource with the JSON constructed above in the request's body will do the magic.
The server's response includes additional data, such as how the Patient will be identified internally. However, as I have already supplied my form of identification, I can look up the Patient easily using a GET request with one of the defined search parameters, like this:
While REST is a perfect approach to updating and accessing data in real-time, there are many processes where asynchronous communication like messaging, is more suitable.
Given the principles outlined above, there is the consequence that extensibility is a key priority. It is essential to understand that data collection and data exchange are done within their context. Still, it is good to use a single set of Resources to collaborate within a given end-to-end process from patient admission to reimbursement. And while there is too much unstructured information in healthcare, the approach supports structured information that can be validated and analyzed.
In FHIR, this approach is called "Profiling". This is the tailoring of a resource type for a specific need or process. It supports, e.g., the following:
I think it helps to understand the capabilities of profiling when you consider some examples:
The result of such profiling is often an implementation guide or a FHIR Package, which can be found in a public or private package registry.
To conclude this overview, it is essential to mention the importance of the healthcare IT and FHIR community. Standardization requires participation and collaboration from the ecosystem that wants to utilize these standards. This open-source development principle is imbued in the FHIR approach itself. At the same time, FHIR is the core of some prominent open-source offerings and toolings.
There is also a vivid exchange on https://chat.fhir.org/ regarding all matters on the specification or beyond. If needed, we can also get development-related questions answered on StackOverflow.
To round it up, the most prominent healthcare IT-related conferences, such as HIMSS or DMEA, usually feature FHIR or interoperability-related networking events. And if more is needed, there are also FHIR-centered conferences to learn more about the standard and upcoming developments. From June 6-9, 2023, I will attend the FHIR DevDays, one of the most significant FHIR-centric events. So, if you are there too, please let's connect.
Please tell us what you think. We are interested in your feedback: Are there other benefits you feel that are missing? Do you want to learn or share some disadvantages as well? Please add a comment! Thank you!
HL7, FHIR, and the Flame Design mark are registered trademarks of Health Level Seven International.
The not-for-profit, ANSI-accredited standards-developing organization HL7® is well-known for establishing industry standards for multiple decades in the healthcare IT ecosystem. Healthcare applications use these standards to facilitate the exchange of patient-related information between different systems. The predominant approach for this has been the messaging standard HL7v2. Fast Healthcare Interoperability Resources (HL7® FHIR®) is the modern standard that replaces and improves previous interoperability approaches. It has gained significant traction in recent years thanks to its simplicity, ease of implementation, and flexibility.
The FHIR Manifesto or the Fundamental Principles
While the often quoted "FHIR Manifesto" did not exist at the inception of FHIR, some important efforts resulted in an official document called the Fundamental Principles of FHIR.
- FHIR prioritizes implementation
- FHIR provides a flexible framework for interoperability
- FHIR keeps complexity where it belongs
- FHIR supports but does not mandate tight specifications
- FHIR leverages open source development principles
- FHIR is free to use
- FHIR supports multiple exchange paradigms/architectures
- FHIR leverages common web technologies
- FHIR is forward and backward compatible
- Tooling requirements are mainstream and minimal
These principles are well understood in the community and nicely explained in the above link. There are a few focus points that you can derive from these principles:
There is an evident focus on implementers. Only standards that are implemented and adopted by others are beneficial. As various environments and use cases use FHIR, it must be able to adapt to these. And there is also the notion of following the 80% principle, e.g., "the core specification only includes those elements used by approximately 80% of implementers - other elements are handled using extensions". Finally, many other principles focus on the community and ensure scalability throughout a potential FHIR-based ecosystem.
Benefits of FHIR
In my last blog post, I outlined some advantages of using FHIR. Now, I want to drill down into each of these and explain them in more detail. Naturally, these benefits also mirror the principles outlined above.
Easy to Understand and Implement
Implementability is one of the main priorities of the FHIR specification. Hence, many aspects listed below help to facilitate this goal precisely. To start with, the FHIR specification is also well structured. The FHIR R4 specification is layered in five levels and contains detailed content about the various sections. By the way, the name R4, which you can often see, refers to the version of the specification.
Layering of the FHIR Specification (source)
In addition to the core definition, various summaries, introductions, and examples are available to help implementors get started immediately.
Modern Concepts
FHIR uses web standards, such as RESTful APIs, JSON, and XML, which are widely used and familiar to developers. This familiarity makes it easier to understand and implement than legacy standards like HL7v2 or CDA. Ultimately, any FHIR-compliant app can communicate with FHIR-enabled systems, building the foundation for interoperability.
Modular and Build on Resources
FHIR is based on modular components called "resources," representing different aspects of healthcare information (e.g., Patient, Condition, Procedure, Consent). It is the format to provide the content and build the domain model. The 80% principle also guides the specification regarding what is defined and needs to be delivered to implement the standard. Hence, these resources can be combined and extended, providing high flexibility and customization.
Let’s have a detailed look what this could look like. Imagine we want to exchange patient information between two applications. The standard Patient resource of FHIR R4 already provides an excellent starting point. It also renders the model as a UML Diagram - see the screenshot below.
FHIR Patient Resource - UML Diagram (source)
Based on this domain model and some sample data set of a given patient, we can represent a patient using the JSON format like this:
{
"resourceType": "Patient",
"identifier": [
{
"use": "official",
"system": "http://example.org/fhir/Patient",
"value": "t-1"
}
],
"active": true,
"name": [
{
"use": "official",
"text": "John Putz",
"family": "Putz",
"given": [
"John"
]
}
],
"gender": "male",
"birthDate": "1970-07-30"
}As many properties are optional, this very lean data structure is sufficient to let me create a patient in a system. By directly supplying my known identifier to the system, I also ensure I can use this identifier to search for the data later. This approach is already an excellent cutover to the topic of interoperability.
Fosters Interoperability
Overall, health information sharing is becoming increasingly important. As data is collected in multiple places, physicians, nurses, but also patients require this data to be available at any point. Without standardization, the necessary point-to-point integration is becoming too complex and costly.
Following the data representation above, let's consider how best to publish this into a given FHIR server. The FHIR standard is open to security, transport, and persistence approaches. In doing so, it helps to ensure that FHIR is flexible and capable of being used with ever-changing technologies. The standard defines four exchange paradigms: REST, document, messaging, and services.
Let’s take REST for our example above, which is also the most adapted exchange paradigm. So, creating a patient in a given FHIR server can easily be accomplished using REST. A simple POST request of the Patient resource with the JSON constructed above in the request's body will do the magic.
POST https://fhir-core-service.ondemand.com/myinstance/fhir/PatientThe server's response includes additional data, such as how the Patient will be identified internally. However, as I have already supplied my form of identification, I can look up the Patient easily using a GET request with one of the defined search parameters, like this:
GET https://fhir-core-service.ondemand.com/myinstance/fhir/Patient?identifier=t-1While REST is a perfect approach to updating and accessing data in real-time, there are many processes where asynchronous communication like messaging, is more suitable.
Inbuilt Extensibility Methodology
Given the principles outlined above, there is the consequence that extensibility is a key priority. It is essential to understand that data collection and data exchange are done within their context. Still, it is good to use a single set of Resources to collaborate within a given end-to-end process from patient admission to reimbursement. And while there is too much unstructured information in healthcare, the approach supports structured information that can be validated and analyzed.
In FHIR, this approach is called "Profiling". This is the tailoring of a resource type for a specific need or process. It supports, e.g., the following:
- Changing cardinality: define what is required, what is optional, and where we would support multiple values.
- Change binding: there is a whole concept of how to work with "Terminologies," which is about selecting a value out of a predefined set of options, like, e.g., the "gender" used in the example above. Without going into much detail, it is vital for some of the attributes to be flexible bound against a specific source.
- Introduce new elements: Extensions are the way to add new elements to resources. While this creates a high level of flexibility, it is essential to reflect that there is also the need to consider reuse for extensions.
I think it helps to understand the capabilities of profiling when you consider some examples:
- International Patient Summary (IPS) defines an electronic health record extract containing essential healthcare information to support the use case scenario for 'unplanned, cross border care.' The IPS data set is minimal but still clinically relevant. The corresponding FHIR implementation guide now clearly defines which attributes must be supported, e.g., see the profile of the Patient
- There are various profiles for national implementation guides, such as, e.g., the US Core Profile, the DE profiles by gematik, or the HL7 Deutschland
- One level deeper, there are also project-specific, vendor-specific, and even institution-specific agreements.
The result of such profiling is often an implementation guide or a FHIR Package, which can be found in a public or private package registry.
Part of an Active Community
To conclude this overview, it is essential to mention the importance of the healthcare IT and FHIR community. Standardization requires participation and collaboration from the ecosystem that wants to utilize these standards. This open-source development principle is imbued in the FHIR approach itself. At the same time, FHIR is the core of some prominent open-source offerings and toolings.
There is also a vivid exchange on https://chat.fhir.org/ regarding all matters on the specification or beyond. If needed, we can also get development-related questions answered on StackOverflow.
To round it up, the most prominent healthcare IT-related conferences, such as HIMSS or DMEA, usually feature FHIR or interoperability-related networking events. And if more is needed, there are also FHIR-centered conferences to learn more about the standard and upcoming developments. From June 6-9, 2023, I will attend the FHIR DevDays, one of the most significant FHIR-centric events. So, if you are there too, please let's connect.
Please tell us what you think. We are interested in your feedback: Are there other benefits you feel that are missing? Do you want to learn or share some disadvantages as well? Please add a comment! Thank you!
HL7, FHIR, and the Flame Design mark are registered trademarks of Health Level Seven International.
- SAP Managed Tags:
