FHIR Validation Examples: Slicing vs. FHIRPath vs. Binding

The FHIR specification offers many resource validation options, such as slicing, FHIRPath, and binding. In order to know when to apply which validation method, you first need to understand the difference between them. This quick reference guide will explain when it's best to use one validation method over the other and provide practical examples of using various methods in different scenarios.

In our previous articles on FHIR validations, we highlighted how slicing, FHIRPath, and binding could be used to verify resources on an FHIR server. However, with so many FHIR validation examples available, how do you know when to use one over the other, or what is the difference between Slicing vs. FHIRPath vs. Binding? 

To answer that question, our business analyst, Sveta Medved, put together a table with FHIR validation examples demonstrating the difference between FHIR slicing vs. FHIRPath vs. binding that you can use as a quick reference. The options are rated based on how easy it is to perform or maintain and the outcome of the FHIR validation operation.

Note: All FHIR validation types are viable; our ratings and recommendations are based on personal experience.

Comparison: Slicing vs. FHIRPath vs. Binding

Slicing

Purpose:

Slicing is a mechanism used to specify constraints on repeating elements in FHIR resources. It allows you to differentiate between the multiple instances of an element based on some set of criteria like value or cardinality.

Use Cases:
  • Constrain repeating elements to have unique values for a particular sub-element.
  • Specify cardinality constraints on subsets of repeating elements.
Strengths:
  • Flexibility: Allows multiple instances of the same element but with different constraints.
  • High expressivity: You can define slices based on a wide variety of conditions.
Limitations:
  • Complexity: Handling slicing can add complexity to FHIR implementation.
  • May require custom logic for interpretation.

FHIRPath

Purpose:

FHIRPath is a domain-specific language for traversing and querying FHIR data models. It is employed for expressing constraints, queries, and calculations on FHIR data.

Use Cases:
  • Navigate FHIR resources.
  • Make conditional statements in FHIR resource definitions.
  • Validate resource attributes.
Strengths:
  • Precision: Can articulate very specific conditions and constraints.
  • Readability: Easier to read and understand than XPath or other similar languages.
Limitations:
  • Learning curve: Requires understanding of FHIRPath syntax and semantics.
  • May not handle all complex logic without additional programming.

Binding

Purpose:

Binding is used to attach a specific set of allowed values to an element. It enforces that the values of elements conform to predefined value sets or code systems.

Use Cases:
  • Ensuring that an element’s value is one of a specific set of allowable options.
  • Setting mandatory or optional code systems for elements.
Strengths:
  • Simplicity: Easier to implement compared to slicing or FHIRPath.
  • Standardization: Promotes use of standardized terminologies.
Limitations:
  • Rigidity: Doesn’t provide the expressive flexibility that slicing or FHIRPath can offer.
  • Limited to predefined value sets or code systems.

Each of these approaches has its own merits and limitations, and the optimal choice depends on the specific requirements of your FHIR implementation.

Below we will delve into how the different methods of validations compare based on universal two common scenarios.

Scenario 1. Validate code can use only one value from the list

FHIR Validation Example: We want to validate that a Patient resource has a name with the use set only to official.

Slicing

In this case, we slice Patient.name by value with closed rules:

 "slicing": {
                    "discriminator": [
                        {
                            "type": "value",
                            "path": "use"
                        }
                    ],
                    "ordered": false,
                    "rules": "closed"
                }

And then add slicing to the Patient.name.use:

{
    "id": "Patient.name:official.use",
    "path": "Patient.name.use",
    "short": "usual | official | temp | nickname | anonymous | old | maiden",
    "definition": "Identifies the purpose for this name.",
    "comment": "Applications can assume that a name is current unless it explicitly says that it is temporary or old.",
    "requirements": "Allows the appropriate name for a particular context of use to be selected from among a set of names.",
    "min": 1,
    "max": "1",
    "base": {
        "path": "Patient.name.use",
        "min": 0,
        "max": "1"
    },
    "type": [
        {
            "code": "code"
        }
    ],
    "fixedCode": "official",
    "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"
        }
    ]
}

If we post the use for the name as any other than `official`, we’ll receive an error message.

FHIRPath

If we use FHIRPath for this validation, we’d need to add a constraint to Patient.name.use:

{
    "key": "official",
    "severity": "error",
    "human": "Only official could be used for `use`",
    "expression": "$this = official",
    "source": "http://hl7.org/fhir/StructureDefinition/Element"
}

Then we’d also receive an error if we post a patient resource with Patient.name.use other than official.

Binding

We could also use binding to validate the same thing. In this case, we’ll need to create a ValueSet with only one value and change valueSet for `binding` in the profile:

{
    "id": "Patient.name.use",
    "path": "Patient.name.use",
    "short": "usual | official | temp | nickname | anonymous | old | maiden",
    "definition": "Identifies the purpose for this name.",
    "comment": "Applications can assume that a name is current unless it explicitly says that it is temporary or old.",
    "requirements": "Allows the appropriate name for a particular context of use to be selected from among a set of names.",
    "min": 1,
    "max": "1",
    "base": {
        "path": "Patient.name.use",
        "min": 0,
        "max": "1"
    },
    "type": [
        {
            "code": "code"
        }
    ],
    "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"
        }
    ]
    "binding": {
        "strength": "required",
        "valueSet": "http://example.com/fhir/ValueSet/only-official"
    }
}

As a result, we have the same validation done in three different ways. Each method is viable. In the end, it comes down to personal preferences and goals. For this case, we recommend FHIRPath. It does the same job but is more convenient to maintain for profile authoring. It has fewer JSON lines, meaning it’s easier to read, make changes, and find errors.

Scenario 2. Validate extension in a profile should be at least one with a concrete profile

FHIR Validation Example: We want to check that among all extensions in the resource, there is the one we expect.

Slicing

If we want to check that at least one extension is what we expect, we could use slicing. For example, such FHIR slicing is used in FHIR’s CH EMED Medication Card profiles.

FHIRPath

To perform the same validation with FHIRPath, we add a constraint to the extension:

{
    "key": "ehealth-00036",
    "severity": "error",
    "human": "Language extension is mandatory",
    "expression": "extension.exists(url = 'http://ehealth.com/fhir/StructureDefinition/ehealth-humanname-language')",
    "source": "http://hl7.org/fhir/StructureDefinition/Element"
}

In this case, both options are decent and simple to maintain. But if you are creating an Implementation Guide, slicing will give you a more human-readable format because you will be able to see in the tree structure which pieces of slicing are used. This also helps with future FHIR integrations.

Conclusion

We hope this quick reference guide and FHIR validation examples will help you validate your profiles more conveniently and apply the right FHIR validation type for your business case. Refer to our article on how to perform FHIR validations for more detailed information. 

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.

FAQ

  • How can FHIRPath be used to validate specific data elements within FHIR resources?
  • Data Type Validation: FHIRPath can be used to confirm that a specific element within a resource conforms to the required data type. For example, you could validate that an age field is a numerical value and not a string.
  • Constraint Checks: It allows for defining invariants or conditional constraints that elements in a resource must meet. For instance, you could specify that a Patient resource must have either an email or phone number.
  • Logical Operations: FHIRPath can validate logical relationships between different elements. For instance, you might want to validate that the end date of an appointment is later than the start date.
  • Are there tools or libraries available for implementing FHIR validation using slicing, FHIRPath, and binding?

You can use a FHIR Server like Kodjin that supports all types of validation methods, including slicing, binding and FHIRPath. 

More article about FHIR

no-image
FHIR Implementation in Germany

February 15, 2024

  • FHIR
no-image
How Australian Digital Health Is Embracing FHIR Standards

February 8, 2024

  • FHIR
no-image
What Is ONC (b)(10) Certification?

December 19, 2023

  • FHIR
no-image
Understanding the US Core Implementation Guide and USCDI

December 12, 2023

  • FHIR
no-image
Comprehensive Testing for FHIR Servers: Best Practices

October 19, 2023

  • 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