FHIR Chat · FhirInstanceValidator - code in a slice · hapi

Stream: hapi

Topic: FhirInstanceValidator - code in a slice

Lars Rückert (May 21 2019 at 13:13):

Hello,

TL/DR: I have an Issue with the FhirInstanceValidator on a code in a required slice. Can I work around it without removing the profile from the validator?

To be precise: I want to create an Organization which is supposed to have a work address. The Profile states that it should have a slice of address with the use defined as work using this valueset. Without the Validator using my Profile enabled I can create the organization just fine, sending in something like:

{
  "resourceType": "Organization",
  "name": "org",
  "address": [{
    "use": "work",
    "city": "Atown",
    "postalCode": "12345",
    "country": "Bland",
    "line": [
      "CStreet 1"
    ]
  }]
}

When I activate the validator though, I get the following response:

"response": {
    "statusCode": 422,
    "body": {
      "resourceType": "OperationOutcome",
      "issue": [
        {
          "severity": "error",
          "code": "processing",
          "diagnostics": "Problem evaluating slicing expression for element in profile <Profile> path Organization.address (fhirPath = true and (use memberOf 'http://hl7.o
rg/fhir/ValueSet/address-use')): null",
          "location": [
            "Organization.address"
          ]
        },
        {
          "severity": "information",
          "code": "processing",
          "diagnostics": "Profile <Profile>, Element 'Organization.address[workAddress]'': Unable to check minimum required (1) due to lack of slicing validation",
          "location": [
            "Organization"
          ]
        }
      ]
    }

I debugged through lots of the code and noticed that it gets to the point where the rule: use memberOf 'http://hl7.o rg/fhir/ValueSet/address-use' is evaluated.
The given value of use (which is work) is being converted to a Codeing.
To do this the given valueset is trying to be expanded which ends up in this code:

@Override
public ValueSetExpander.ValueSetExpansionOutcome expandVS(org.hl7.fhir.r4.model.ElementDefinition.ElementDefinitionBindingComponent binding, boolean cacheOk, boolean heiarchical) {
  throw new UnsupportedOperationException();
}

What I think to be weird, is that when the same kind of attribute (a code given as string value with an implicit valueset) is outside of a slice, it works. For example posting an observation which has a status that is part of a valueset as well, works.
I did notice though that posting an observation with an invalid status does not fail in validation but in processing.

Now to my question:
Is there any way for me to make the validator not fail on my adress slice other than removing the profile altogether?
Can I overwrite the expandVS function in my validator to make it work somehow?
Is there maybe a way to express the same thing in the profile in a different way? (Multiple adresses are okay, but one has to be a work address.)

Thanks and best regards,
Lars

James Agnew (May 21 2019 at 19:43):

Hi Lars,

Before any other checking, it would be worth testing your system against the latest snapshot builds of HAPI FHIR (3.8.0-SNAPSHOT). The validator is very actively developed, so many things have been fixed since 3.7.0 was released.

Lars Rückert (May 22 2019 at 07:35):

Hi James,

thanks for the answer, unfortunately we have a setup where we have to get the dependencies from maven, which seems not to be available yet.
I think we can work around it for now by changing the profile a bit.
Do you have an estimation as to when 3.8.0 will be released?

James Agnew (May 22 2019 at 12:46):

We'll be releasing on this coming Tuesday. If you want to use snapshot builds before then, there are instructions on how to do this here: http://hapifhir.io/download.html#_toc_using_snapshot_builds

Lars Rückert (May 22 2019 at 13:46):

That's great! Thank you a lot for the information.

Lars Rückert (May 23 2019 at 07:55):

Version 3.8.0 fixes the described Problem with codes in slices. Thanks.

Last updated: Apr 12 2022 at 19:14 UTC