How to Validate FHIR Resources Like a Pro

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 resource validation types and various options for validating FHIR resources (including how to do it in the Kodjin Interoperability Suite).

Main Types of FHIR Validation

A critical aspect of implementing FHIR successfully involves rigorous validation processes to ensure that data conform to the defined standards and profiles. This section delves into the main types of FHIR validation, which are pivotal for developers, analysts, and healthcare IT professionals to understand and implement effectively.

1. Structure

A FHIR server or FHIR 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.

2. 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.).

3. 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.”

FHIR slicing is used to create different FHIR resource 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.

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

5. 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 FHIR 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 resource validation

The diverse nature of healthcare data and the stringent requirements for accuracy and data quality necessitate effective FHIR resource validation tools. Here are some things to consider when selecting the appropriate validation tool for your needs:

Efficiency and Productivity

The right tool can significantly impact the development lifecycle. Tools that offer real-time feedback and highlight errors promptly allow developers to correct issues on the fly, speeding up the development process. 

Adaptability and Future-proofing

 Healthcare standards evolve, and tools that quickly adapt to changes are invaluable. The FHIR standard is still under development, with new versions coming out. It’s important that the tool you choose can work with multiple versions of FHIR.

3. Flexibility and Versatility: Different scenarios may require different types of validations (e.g., XML vs. JSON). Tools that support multiple formats and offer functionalities like XML-to-JSON conversion, as seen in the Kodjin Interoperability Suite, provide developers with the flexibility to work across various projects and requirements without the need for multiple tools.

Integration and Connectivity

The choice of a validation tool also hinges on how well it integrates with existing workflows and systems. Tools that can be seamlessly incorporated into development environments, like the VS Code plugin version of the Kodjin Profiler, streamline processes and enhance collaboration among development teams.

In conclusion, selecting the right FHIR resource validation tool is crucial for ensuring the integrity, compliance, and interoperability of healthcare data. A well-chosen tool enhances efficiency, future-proofs against evolving standards, provides necessary flexibility for handling diverse data types, and integrates seamlessly with development workflows.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. 

With the Kodjin Profiler you can easily validate FHIR resources online without having to install or connect any other software.

Using the FHIR Validator Tool

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. 

Below is an example of a response on a FHIR resouce validation operation from a FHIR 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 Use Cases and Real-world Applications

Below we’ll take a look at some FHIR resource validation examples, showcasing how various functions are applied to ensure that healthcare data conforms to the required rules.

  1. This is an example of the CARIN for Blue Button Profiles validation. The highlighted line checks whether profile exists and starts with the profile version and subversion (major and minor). 

"key": "EOB-institutional-inpatient-meta-profile-version", "severity": "error",

"human": "Institutional Inpatient EOB: meta. profile with canonical and major.minor. version required.",

"expression": "meta.profile.exists($this.startsWith('

StructureDefinition/C4BB-ExplanationOfBenefit-Inpatient-Institutional |2.0.'))",

"source": " Institutional"


  1. Below is an example of email validation using the $matches function. The validation resulted in an error as the email must be valid.

"key": "custom-error-00004",

"severity": "error",

"human": "Email must be valid",

"expression": "system != 'email' or value.matches("^[a-zA-Z0-9. !#$%&' *+/=?^_` {|}~~]+@[a-zA-Z0-9]+(?:\\. [a-zA-Z0-9-]+)*$')"


  1. This example demonstrates the use of an immediate if function, which comprises three parts: an initial condition, a true branch, and a false branch. The function first evaluates whether both an onset dateTime is provided and exists. If this condition is true, it then checks whether the provided date is less than or equal to today’s date. If the initial condition is false, meaning the onset dateTime does not exist or is not provided, it evaluates accordingly.

"key": "custom-error-00119",

"severity": "error",

"human": "If onset [x] is provided in dateTime, it should be less or equal to the current date", "expression": "iif (onset is dateTime and onset.exists(), onset.toDate() <= today (), onset is dateTime.not() or onset.exists().not())",



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

Post author

Sveta Vedmed

Business Analyst at Edenlab

More article about Featured

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