HL7 FHIR Data Model Explained: Resources and Tools

As technology continues to revolutionize healthcare, interoperability remains a priority. The HL7 FHIR standard is becoming a game-changer in this arena. Our article discusses crucial aspects of the FHIR data model, including the FHIR Resources, their design choices, the role of FHIR data types and element definitions, and the concept of profiling.

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.

Interoperability is at the top of the C-suite agenda
resource: https://fh-resources.fiercehealthcare.com/free/w_defa3487/

FHIR (Fast Healthcare Interoperability Resources) is the standard developed by the Health Level 7 (HL7) standard-developing organization to enable electronic healthcare data exchange between different systems.

The FHIR 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 data model, another crucial component of the HL7 FHIR standard: FHIR Resources.

Key Takeaways

  • Core Principles Behind FHIR Resource Design: FHIR Resources are designed to be flexible, efficient, user-friendly, and accurate, making them an effective tool for seamless healthcare data exchange.
  • Resources for Accurate Data Exchange: FHIR Resources help maintain clear and consistent data meaning across systems, minimizing errors and ensuring accurate understanding and use of exchanged data.

FHIR Resources are versatile and customizable. By using profiling and mapping, Resources can be adjusted to support a variety of use cases, ensuring precision, uniformity, and enhanced interoperability in healthcare management.

FHIR Resources: Design Choices

HL7 FHIR Standard Explanation

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) defines five principles of FHIR resources.

1. Reuse

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

Resources are designed for speedy transmission and processing, which is handy for a niche like healthcare where every second counts.

3. Usability

Even though FHIR is a developer-focused standard, both tech-savvy and non-technical people can understand the content of any Resource. Even the data represented in XML/JSON format is human-readable.

4. Fidelity

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.

5. Interoperability

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. 

Examples of Core FHIR Resources

FHIR Resourcelist includes 157 Resources grouped into various categories where you can find a needed resource example. 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.)

FHIR Resource Patient xml
resource: https://www.healthit.gov/sites/default/files/page/2021-04/Intro%20to%20FHIR%20Resources%20Fact%20Sheet.pdf

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 and a human-readable FHIR format example. It enables displaying data in a narrative even if the system cannot process the coded standard data.

Extensions: 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 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.

FHIR Type Framework
Resource: https://www.hl7.org/fhir/types.html

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 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 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

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

Leveraging FHIR can help achieve the highest level of interoperability, which allows for preserving the meaning of the data shared between systems. By using resources for healthcare data exchange, different organizations can achieve a standardized way of communicating so all data exchange actors can be sure of the clear and correct interpretation of the shared information.

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

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.

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 and configure the data model using profiling if necessary.

Read Also: How to Choose FHIR Profiling Tool?

Real-World Applications of FHIR Data Model

FHIR for Data Analytics

FHIR enables comprehensive aggregation and analysis of healthcare data by standardizing its exchange across diverse systems, fostering seamless interoperability among EHRs, clinical data repositories, and other healthcare systems. This approach enhances data accessibility, reliability, and supports advanced analytics like patient cohort analysis, treatment optimization, and predictive modeling.

For the Zoadigm Analytics Platform, FHIR helps integrate diverse EHR data into a semantic layer analysis framework, ensuring compliance with HIPAA requirements. By leveraging FHIR, the platform maintains data consistency and interoperability across the network, facilitating real-time access to comprehensive patient insights.

Read also: EHR interoperability: Importance, Issues, and Solutions

FHIR for Optimizing Workflows

By leveraging the FHIR format, organizations can integrate clinical and administrative data from various sources into a single repository. This approach enhances data accessibility, consistency, and interoperability.

FHIR was used to address the challenges of automating appointment scheduling and insurance claims processing of Hong Kong’s largest third-party administrators (TPA). A custom FHIR facade was deployed for appointment management, enabling real-time data exchange to book appointments and manage patient check-ins. Simultaneously, a centralized Clinical Data Repository (CDA) was established to aggregate clinical data from multiple Electronic Health Record (EHR) systems, ensuring comprehensive data availability for decision-making.

How 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.

Achieving seamless communication and interoperability in healthcare requires mapping healthcare data to HL7 FHIR. 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. This tool employs different functionalities to map one resource into another.

The process of transforming a custom resource into a FHIR structure

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 FHIR data mapping in healthcare. 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.

By mapping healthcare data to FHIR, healthcare organizations can ensure that their data is standardized, structured, and ready for exchange between different systems and applications. 

Our certified FHIR experts have extensive experience mapping healthcare data to  to resources in the FHIR format 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.

FAQ

What are the advantages of the FHIR Data Model in Healthcare?

The FHIR data model allows for applying a standardized data exchange mechanism, facilitating seamless communication among various healthcare systems.

How does FHIR impact decision-making in healthcare?

Resources allow for consistent data representation, which supports semantic interoperability, where exchanged data retains its meaning across diverse systems, ensuring accurate data-driven decision-making.

How to Implement FHIR?

Health organizations can ensure effective FHIR implementation by assessing current workflows, selecting appropriate resources, and using tools like the Kodjin FHIR Mapper for seamless data integration.

Post author

Iryna Biiovska

System Analyst at Edenlab

More article about Blog about FHIR

Understanding FHIR Bundles

November 11, 2024

  • FHIR

November 1, 2024

  • FHIR

August 8, 2024

  • FHIR

Let`s chat

We would be glad to share more details about our enterprise-level FHIR software solutions and other cases based on the HL7 FHIR standard.

    Your form has been submitted successfully

    We will contact your shortly

    Kodjin White Paper

    Please leave your email to get Kodjin White Paper

      By downloading files from this site you agree to the Policy

      The Kodjin White Paper has been successfully sent to your email

      We have sent a copy to your email

      Back to website content