How to validate FHIR resources

FHIR validation is essential for ensuring the accuracy and consistency of healthcare data. In this article, we will discuss the different types of FHIR validation and how to perform them using various methods such as schemas, the FHIR Validator, and asking a FHIR server.

Validation in FHIR is instrumental in ensuring smooth healthcare data management and providing an accurate picture for healthcare diagnostics and reporting. FHIR validation can be performed without having to code anything, which saves significant time and effort for business analysts.

Validation is most commonly needed to check whether resources are compliant with a specific implementation guide. This requires that resources are validated against profiles. But what exactly does it mean to validate a FHIR resource?

In this article, we’ll take a look at different FHIR validation types and various options for validating FHIR resources (including how to do it in the Kodjin Interoperability Suite).

Validation types

Structure

A FHIR server or validator tool checks whether a profile describes which fields can be transferred to another resource and that everything described in the profile can be transferred, as well as whether a profile is in accordance with the registered FHIR profiles on the server.

Cardinality

FHIR attributes contain cardinality values that define the minimum and maximum number of times an attribute can be present in a resource instance. Cardinalities in FHIR look like the following: 0..1, 0..*, 1..1, and 1..*.

Profiles designated for specific use cases can use other cardinality values within the range of the cardinality specified by the base resource.

In order to validate cardinality, the FHIR server checks that all properties are correct (min. & max.).

Slicing

A common operation in the profiling process is to take an element that may appear more than once and create multiple instances of it. Each instance defines a different restriction on the elements in a group of fields. In FHIR, this operation is called “slicing.”

Slicing is used to create different validations on the same group of fields that depend on the value of one of the fields in the group. 

In essence, when validating slicing, a FHIR server checks whether the “if…then” parameters are correct and conform to the profile.

Binding or Value Set

A list of allowed coded values in an element is referred to as a “value set.” FHIR “binds” a value set to the elements. The specification describes a different binding strength attribute, which defines how the value set should be understood by the server. 

There are currently four binding strengths: Required, Extensible, Preferred, and Example. However, only Required matters when validating profiles, as in the case of all other types a FHIR server will return a warning instead of an error, and the resource will be saved into the database even if the code is not in the value set.

Thus, binding validation checks that the values of all properties conform to the rules for the specified types. 

FHIRPath

FHIRPath is a language used to navigate a FHIR resource to evaluate and extract data from its fields using a simple syntax that includes paths, functions, and operations. Operations are expressed in terms of the logical content of hierarchical data models, along with support traversal, selection, and filtering of data. 

FHIRPath allows you to create resource validations through different functions. It makes writing validations significantly easier for business analysts, as they don’t have to be hard-coded. FHIRPath is commonly used when you need to perform only one single validation on different fields.

Different ways to perform FHIR validation

Once you’ve created your profile, there are various ways in which you can perform FHIR validations depending on your needs. We’ll outline the three most common and explain them.

Using schemas

XML representations of the FHIR resource definitions can be validated using the XML schema provided by the FHIR specification.

To validate JSON files, you can use the JSON Schema with JSON validation software.

For example, the profiler tool in our Kodjin Interoperability Suite has a built-in JSON Schema, which is updated in real time from the HL7 GitHub repository. The tool checks whether the coded representation of the profile conforms to the JSON Schema and highlights the errors. 

The Kodjin Profiler Tool also has a built-in JSON Schema, which is updated in real time from the HL7 GitHub repository. The profiler checks whether the coded representation of the profile conforms to the JSON Schema and highlights the errors. 

Using the FHIR Validator

The FHIR Validator is a Java jar provided as part of the specification and used during the publication process to validate all the published examples. One downside to using the FHIR Validator is that it only supports XML files. 

Asking a FHIR server

The operation $validate can be used to check whether a resource conforms to a profile.  

A FHIR server validates a profile when publishing, but it’s also possible to perform a $validate operation if you want to check whether the resource conforms to a profile without publishing. It’s convenient when you need to validate a profile without having to actually upload it to the server. 

Typically, servers may choose to support either XML, JSON, or both. For the Kodjin Interoperability Suite, we implemented an XML-to-JSON conversion in our FHIR Server. While Kodjin performs the validation for JSON files, if you have a profile written in XML, it can convert it to run the validation. 

The command can be performed in the Kodjin Profiler Tool, which validates the profile through the Kodjin FHIR Server or any other chosen server (only available in the VS Code plugin version).

Takeaway

Validation in FHIR is a crucial part of the profiling process that helps ensure data quality and integrity. While nothing will beat the human inspection of the profiles for errors, various FHIR validation methods make that drastically easier. 

Check out the other articles in our FHIR profiling series where we cover different aspects of working with FHIR.

If you are just getting acquainted with the FHIR standard for your project and lack the proper FHIR expertise, our engineers and analysts are ready to fulfill your needs. Contact us via the website form.

More article about Featured

no-image
Introduction to FHIR Data Model: Diagram & Examples

April 21, 2023

  • Featured
  • FHIR
no-image
FHIR vs. HL7: Key Differences and Which Is a Better Choice?

February 1, 2023

  • Featured
  • FHIR
no-image
FHIR Data Mapping in Healthcare for Improved Interoperability

December 8, 2022

  • Featured
  • FHIR
no-image
SMART on FHIR: Benefits, App Development, and Future of SMART on FHIR

November 21, 2022

  • Featured
  • FHIR
no-image
How to Configure Notifications for an FHIR Server (Subscriptions)

October 25, 2022

  • Featured
  • FHIR
  • Kodjin Updates

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