Healthcare data management is complicated, even for the most developed countries. Adopting new healthcare data standards gets put on the back burner since suggested solutions do not always correlate with strict requirements for the security and interoperability of healthcare data.
However, the explosive growth in the amount of healthcare data forces governments and non-profit organizations to cooperate at all levels to improve healthcare data interoperability and exchange its advanced accessibility by leveraging the FHIR standard data model.
According to Questex Fierce Healthcare and Google survey results from May 31, 2022, 56% of healthcare executives state interoperability as one of their top priorities, and 29% have the implementation of interoperability solutions in progress.
For that reason, the FHIR (Fast Healthcare Interoperability Resources) standard began to gain popularity and become a part of interoperability roadmaps for countries like the U.S. FHIR is a standard representing the set of rules and specifications for healthcare data exchange.
Read Also: What is FHIR Guide
In our article on the future of healthcare data management, we talked about how FHIR RESTful API is one of the main components of the standard that revolutionized the healthcare industry. Therefore, this article is a good introduction to the HL7 FHIR data model, another crucial component of the HL7 FHIR standard: FHIR Resources.
FHIR Resources: Design Choices
A resource is the FHIR information data model of a healthcare business object. Compared to other information models to healthcare data models on FHIR, for example, FHIR vs. HL7 V3, the scalable design of FHIR Resources avoids redundant data sets.
The Office of the National Coordinator for Healthcare Information Technology (ONC) highlights interoperability as the primary motivation for FHIR Resources’ design choices. The ONC defines five principles of FHIR resources.
1. Reuse
FHIR Resources allow for avoiding the overcomplicated structure of a FHIR standard data model by providing customizable Resources from the core FHIR specification. A healthcare provider can use extensions and constraints to adapt any existing FHIR Resource for a specific use case.
2. Performance
FHIR Resources are designed for speedy transmission and processing, which is handy for a niche like healthcare where every second counts. In addition, FHIR Resources are simple in their construction so that developers can implement FHIR effortlessly.
3. Usability
Even though FHIR is a developer-focused standard, both tech-savvy and non-technical people can understand the content of any FHIR Resource. Even the data represented in XML/JSON format is human-readable.
4. Fidelity
FHIR Resources have strict restrictions on intermixing values with different FHIR data types, like strings and numeric values. They can also be validated by their syntax in addition to defined sets of business rules. This design choice ensures that the data contained within FHIR Resources is accurate, consistent, and of high quality.
5. Interoperability
FHIR Resources use common data formats and established data exchange technologies. As a result, the FHIR standard provides a flexible, scalable, and interoperable information for the HL7 FHIR data model.
What are the main FHIR Resources?
FHIR Resourcelist includes 157 Resources grouped into various categories. The categories cover administrative, clinical, financial, infrastructure, and other workflows. For example, the Base category comprises the Individuals subcategory, which contains relevant resources (including Patient, Practitioner, PratctitionerRole, etc.)
Resource Metadata: Resource metadata includes essential information such as the resource ID, version ID, and the last updated date of a resource. This information helps in identifying and managing resources efficiently.
Narrative: The narrative is an HTML representation of a resource’s contents in a human-readable format. It enables displaying data in a narrative even if the system cannot process the coded standard data.
Extensions: FHIR Resources can be extended to match a specific use case. The extension element expands resource capabilities beyond the standard 80% use cases described in the core FHIR specification. Implementers can use key-value pairs as a simple way to represent data in an extension.
Structured Data: The standard data block of an FHIR resource covers the common 80% of all healthcare use cases. For instance, the structured data block of a patient resource includes the medical record number, name, gender, date of birth, and other critical attributes.
Resources are building blocks of the FHIR standard. They define the types of data that can be exchanged. The key benefit of FHIR Resources is the ability to exchange data in a structured and standardized format seamlessly.
This FHIR data model diagram is a graphical representation of FHIR data models using standard UML notation that defines the base abstract types that provide the foundation for all FHIR types. HL7 FHIR data modeling is a structured approach to representing and exchanging healthcare information electronically. The base of the FHIR Data Model is Element Type and Resource Type, which all other types are derived from.
Element Type is an abstract type that represents the common attributes and behaviors of all FHIR elements, such as DataTypes and BackboneElements. Together, they are used for creating Element Definitions that are building blocks of FHIR Resources. They describe the attributes of a resource, such as Path (name), cardinality, data type, constraints and other usage rules, FHIR terminology binding, etc. For instance, a Patient FHIR Resource includes the following elements: name, birth date, gender, and more.
Example of an Element Definition:
{
"id": "Patient.name",
"path": "Patient.name",
"short": "A name associated with the patient",
"definition": "A name associated with the individual.",
"comment": "A patient may have multiple names with different uses or applicable periods. For animals, the name is a \"HumanName\" in a sense assigned and used by humans and has the same patterns.",
"requirements": "Need to be able to track the patient by multiple names. Examples are your official name and a partner name.",
"min": 0,
"max": "*",
"base": {
"path": "Patient.name",
"min": 0,
"max": "*"
},
"type": [
{
"code": "HumanName"
}
],
"constraint": [
{
"key": "ele-1",
"severity": "error",
"human": "All FHIR elements must have a @value or children",
"expression": "hasValue() or (children().count() > id.count())",
"xpath": "@value|f:*|h:div",
"source": "http://hl7.org/fhir/StructureDefinition/Element"
}
],
"isModifier": false,
"isSummary": true,
"mapping": [
{
"identity": "v2",
"map": "PID-5, PID-9"
},
{
"identity": "rim",
"map": "name"
},
{
"identity": "cda",
"map": ".patient.name"
}
]
},The dataType class is used as a base class to define and represent data types for individual elements within resources. It describes the common properties and behaviors of all FHIR data types. There is a wide range of data types that are used to represent different kinds of values within the Resource.
These data types can be broadly categorized as either primitive data types or complex data types. Primitive data types can take a single value, like string, boolean, or decimal. Complex data types called general-purpose complex types include multiple values and are designed for specific use cases (e.g., period, quantity, reference, identifier, etc.).
For more information about FHIR data types, read our previous article about FHIR components and resources.
Example of a complex Data Type:
{
"value": 5,
"unit": "mg",
"system": "http://unitsofmeasure.org",
"code": "mg"
}If a data type is complex but not general-purposed, it can be represented using BackboneElement. For example, Contact in the Patient Resource is a BackboneElement, because it consists of multiple values but can not be applicable/reusable in other resources.
Example of FHIR backbone element:
"contact" : [{
"relationship" : [{
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0131",
"code" : "N"
}]
}],
"name" : {
"family" : "du Marché",
"_family" : {
"extension" : [{
"url" : "http://hl7.org/fhir/StructureDefinition/humanname-own-prefix",
"valueString" : "VV"
}]
},
"given" : ["Bénédicte"]
},
"telecom" : [{
"system" : "phone",
"value" : "+33 (237) 998327"
}],
"address" : {
"use" : "home",
"type" : "both",
"line" : ["534 Erewhon St"],
"city" : "PleasantVille",
"district" : "Rainbow",
"state" : "Vic",
"postalCode" : "3999",
"period" : {
"start" : "1974-12-25"
}
},
"gender" : "female",
"period" : {
"start" : "2012"
}
}],
Another type, derived from DataType, is a BackboneType, which is a base definition for the few special dataTypes that allow modifier extensions, such as Timing, Dosage, and ElementDefinition, that we mentioned before. Using modifier extensions in these FHIR data types allows overwriting the original meaning of an element.
The Resource is a generic type that serves as a base for all the FHIR Resources and does not contain any domain-specific data elements. Bundle, Parameters, and Binary extend Resources directly.
DomainResource is a base type for all domain-related resources. These resources can have a human-readable XHTML representation of the Resource’s content, contain additional related resources inside the Resource, and have additional extensions and modifier extensions as well as the defined data. For example, resources such as Patient, Observation, Claim, and Condition are derived from DomainResource.
Additionally, some of the resources are considered canonical and implement the CannonicalResource Interface. These resources have canonical, globally unique, and stable URLs, version, status, and data properties to help manage their publication and carry additional metadata about their use, including copyright information—for example, CapabilityStatement, OperationDefinition, and SearchParameter.
Some resources may also carry additional publication metadata over other canonical resources, describing their review and use in more detail. These resources implement MetadataResource Interface— for example StructureDefinition, CodeSystem, and ConceptMap.
This concept of inheritance also lay at the core of profiling. Profiling is a process of extending and constraining existing FHIR Data Types to meet project requirements. Profiles can inherit properties and behaviors from their base resource types and define additional properties and behaviors specific to the profile.
For example, US Core Patient Profile is built on top of the FHIR Patient StructureDefinition. It is achieved by referencing the corresponding StructureDefinition in the baseDefinition field:
“baseDefinition” : “http://hl7.org/fhir/StructureDefinition/Patient”,
At the same time, CARIN for Blue Button defines Patient Profile by referencing US Core Patient Profile:
“baseDefinition”: “http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient”,
Using inheritance like this allows for interoperability between systems and applications that use FHIR to exchange healthcare data. It helps ensure consistency across different resource and element types, reduces code duplication, and makes development more efficient.
Any Data Type described above can be extended in this manner. Moreover, you can use the FHIR Profiler Tool to automate and speed up profile development. Read a real FHIR Australian case.
Reasons to Use FHIR Resources
Leveraging the FHIR data model can help stakeholders support the highest accuracy and consistency of the information exchanged between systems, which streamlines the exchange process and minimizes the risk of errors or misinterpretations.
Semantic Interoperability
The highest level of interoperability means preserving a precise meaning of the data shared between systems. One of the key benefits of using FHIR resources for healthcare data exchange is that they provide a standard way for different organizations to communicate with each other.
If all parties involved in the exchange are implementing the FHIR specification, they can be confident they can understand and interpret the data being shared. For example, suppose a resource type of Patient is being exchanged. In that case, both the sending and receiving organizations will know what fields to expect and what functions are available for that Patient Resource. FHIR makes the exchange process more efficient, reducing the risk of errors or misinterpretations.
Unified Workflows
By adopting the FHIR Specification, organizations can assess the Data Model on FHIR and determine which business models and objects align with their existing processes. For example, if an organization uses Patient, Claim, and Order resources, it can match them with those in the FHIR model to ensure compliance. The organization can also complete mapping its data to FHIR resources and configure the data model using profiling if necessary.
With the help of profiling, an organization can constrain element definitions for resource parameters not used in their workflow and create unique profiles for resources. Profiling allows the organization to define which fields to use and exchange and which to omit. Additionally, the organization can create extensions for the profile if the FHIR model does not include the necessary parameters.
Read Also: How to Choose FHIR Profiling Tool?
Overall, FHIR Resources enable a streamlined approach to healthcare data exchange, ensuring all parties understand the type of Resource being exchanged and can interpret it accurately.
Tools Available to Work With The FHIR Data Model
The complexity and diversity of clinical data can challenge effective FHIR implementation. The data mapping can help integrate healthcare data that come in legacy formats into the FHIR standard data model.
THE FHIR MAPPER
Achieving seamless communication and interoperability in healthcare requires mapping healthcare data to HL7 FHIR resources. However, the complexity and diversity of clinical data make FHIR implementation challenging. The Kodjin FHIR Mapper addresses the complexities of data mapping, making FHIR implementation more efficient and less time-consuming.
With the Kodjin Data mapper, data analysts can easily customize resource templates to meet specific requirements. The mapper utilizes functions like _if, _ifnot, _foreach, and _flatten to map resources accurately and effectively. Additionally, the Kodjin FHIR Mapper serves as a FHIR facade, simplifying complex backend processes to present a user-friendly interface for data mapping. It also facilitates more straightforward hl7 data integration with third-party systems, enhancing care coordination. The mapper ensures data accuracy, consistency, and quality, improving patient care.
MAPPING HEALTHCARE DATA TO HL7 FHIR RESOURCES
By mapping healthcare data to FHIR resources, healthcare organizations can ensure that their data is standardized, structured, and ready for exchange between different systems and applications. However, mapping healthcare data to FHIR resources can be complex for FHIR beginners.
Our certified FHIR experts have extensive experience mapping healthcare data to FHIR resources using proven methodologies to ensure the highest accuracy of the mapping. By partnering with Kodjin, you can save time and resources while ensuring your data is mapped according to the HL7 FHIR data standard. We are ready to direct our extensive experience, energy, and healthcare domain expertise to your project’s best advantage.
Wrap-up
As healthcare technology advances, the popularity of the FHIR standard grows since this standard allows for addressing the challenges of healthcare data management and healthcare data interoperability.
There are several efficient ways to implement the FHIR approach to data management and exchange, even without the need to build an FHIR-first system from scratch. Edenlab’s team of FHIR engineers will help you with FHIR implementation and healthcare data exchange optimization.
Schedule a consultation with our FHIR experts to get details on the custom FHIR development services and to explore what tools from the Kodjin Interoperability Suite will cover your project’s needs.
