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).
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.
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.).
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 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.
XML representations of the FHIR resource definitions can be validated using the XML schema provided by the FHIR specification.
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
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).
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.