How to Slice an FHIR Resource

07.12.2022

An important part of creating FHIR profiles is slicing, but if it’s something you’ve never worked with before, it can seem very complicated. 

The FHIR specification doesn’t go too in-depth about slicing, either. As such, we wanted to create a clear and concise guide that could serve as a point of reference for those just starting with FHIR, as well as those who want to polish their skills. 

What is FHIR slicing?

Essentially, slicing in FHIR is the “if . . . then” validation based on profile. You “slice” an element by splitting it into multiple instances. We use slicing to create different validations on the same group of fields that depend on the value of one of the fields in the group. 

So when you need to use a specific element of a resource more than once, you just copy the element in the process of slicing.

For example, we want to create different rules for different patient contacts. 

  • If contact = Insurance Company, then Patient.contact.organization is mandatory, 
  • if contact = Emergency Contact, then telecom is mandatory, 
  • if contact = Contact Person, then relationship is mandatory and address.use should be home, etc.

So, we create different validations to the same field, based only on the value of Patient.contact.

There are four steps you should follow if you want to slice an element.

1. Define the type of the FHIR slicing discriminator (a pair of values that tell slices apart).

2. Find the path of the field by which slicing rules would be defined.

3. Establish if the order of the fields is important.

4. Define if a user can send more information than mentioned in the slicing rules.

How FHIR slicing works

In order to slice an element, we first should understand what steps an FHIR server performs when validating a slicing operation. To distinguish how a server processes different slices, we define a “discriminator.” There are multiple ways of doing it, but we commonly use two types of slicing in FHIR: value and pattern. (Both types are supported by our Kodjin FHIR Server)

If the slicing discriminator is value (discriminator value implies fixed[x] value in the profile), then the FHIR server tries to find the same fields in the same order that are in the fixed[x] value. 

For example, if fixed is “fixedString”=”123,” then the FHIR server will try to find the path slicing.discriminator.path string with the value “123.

If fixed is:

CodeableConcept: {
“system”:”example.com”, 
“code”=”123”
},

then the FHIR server will try to find exactly the same CodeableConcept

And 

CodeableConcept: {
“code”=”123”, 
“system”:”example.com”
}

is not exactly the same.

After the FHIR server finds the value, it will validate the received data against the data snippet that contains the given value. After, it will validate the order of the data if slicing.ordered=true. If not found, it will check if slicing.rule=open and will validate against the All slices snippet. In case slicing.rule=close, it will return an error.

If the slicing discriminator is a pattern (discriminator value implies pattern[x] value in the profile), logically, the validation is similar to “value,” but data that is searched by the FHIR server doesn’t need to be exactly the same with the same order; it should only have the same values. 

In pattern slicing 

CodeableConcept: {
“system”:”example.com”, 
“code”=”123”
},

and request

CodeableConcept: {
“code”=”123”, 
“system”:”example.com”
}

will trigger slicing validation.

FHIR Slicing Practical Case Example

We will use one of the Carin Blue Button profiles (Payer Data Exchange profiles), which have powerful slicing to explain slicing rules better. The profile we will look at is the ExplanationOfBenefit-Inpatient profile. In this example, we have slicing in the “supporting info” element. Supporting info is a BackboneElement with a group of fields.

Source: FHIR.org

Those fields could be validated by common rules (supportingInfo: All Slices) or by slicing rules. 

For easier understanding, we defined different types of rules depending on sliceName and slice path in the table below.

All mandatory fields and their differences are defined with All slice rules. For example, sliceName “billingnetworkcontractingstatus” says that ExplanationOfBenefit.supportingInfo.code is mandatory, while it is optional for sliceNameclmrecvddate.” Or Timing is mandatory for sliceNameclmrecvddate” and should be “date,” but for “admissionperiod,” it should be period only, etc.


In the Carin Blue Button profile, FHIR slices are created on the field “category”—the full path is “ExplanationOfBenefit.supportingInfo.category.

"slicing" : {
          "discriminator" : [
            {
              "type" : "pattern",
              "path" : "category"
            }
          ],
          "description" : "Slice based on $this pattern",
          "ordered" : false,
          "rules" : "open"
        }

Category is a CodeableConcept. So with the type “pattern,” we can send system, value, and other fields of CodeableConcept in any order and any fields. The slicing will be triggered if all fields defined in the structure definition will be present in the resource separately.

In the example, “ordered” is false, showing that the order of FHIR slices in a resource is not important. We can create resources with supporting info with code “​​clmrecvddate” before “admissionperiod.

"supportingInfo" :
    {
      "sequence" : 2,
      "category" : {
        "coding" : [
          {
            "system" : "http://hl7.org/fhir/us/carin-bb/CodeSystem/C4BBSupportingInfoType",
            "code" : "clmrecvddate",
            "display" : "Claim Received Date"
          }
        ],
        "text" : "Date the claim was received by the payer."
      },
      "timingDate" : "2017-06-01"
    },
    {
      "sequence" : 3,
      "category" : {
        "coding" : [
          {
            "system" : "http://hl7.org/fhir/us/carin-bb/CodeSystem/C4BBSupportingInfoType",
            "code" : "admissionperiod",
            "display" : "Admission Period"
          }
        ],
        "text" : "Dates corresponding with the admission and discharge of the beneficiary to a facility"
      },
      "timingPeriod" : {
        "start" : "2017-05-23"
      }
    }
  ]

In case the order is true, then we should put in the resource supporting info with category.coding.code=admissionperiod before the supporting info with category.coding.code=clmrecvddate like in the FHIR slicing rules.

Takeaway

We hope you will find this article useful, and it has helped you get a better grasp of what FHIR slicing is and how to do it. Authoring FHIR profiles is a time-consuming process that requires a high skill set. If you are looking to create custom FHIR profiles or need help with FHIR implementation, our team of FHIR  Business Analysts can help you fill in that skill gap. Contact us to discuss your project and how we can help.

Let’s chat

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








    Schedule demo

    We will share all details about our enterprise-level solutions and other cases based on the FHIR standard








      Thank you!

      KODJIN WHITEPAPER

      Please leave your email to get Kodjin White Paper.
      By downloading files from this site you agree to the Policy





        Thank you!

        Thank you!