FHIR Chat · Data Absent Reason · argonaut

Stream: argonaut

Topic: Data Absent Reason

Jason Walonoski (Nov 19 2019 at 22:31):

<deleted>

Jason Walonoski (Nov 22 2019 at 15:00):

OK, I'm having trouble with data absent reason. I'm hoping some people can help out.

Jason Walonoski (Nov 22 2019 at 15:00):

The instructions for US Core are here: http://hl7.org/fhir/us/core/general-guidance.html#missing-data

Jason Walonoski (Nov 22 2019 at 15:01):

The Patient.name example in the documentation does not validate, because of the us-core-8 invariant: "Patient.name.given or Patient.name.family or both SHALL be present [family.exists() or given.exists()]"

Jason Walonoski (Nov 22 2019 at 15:04):

I've also set Condition.category to data absent reason unknown, and that works fine, because it has an extensible binding without a preexisting concept for "unknown".

Jason Walonoski (Nov 22 2019 at 15:06):

But for that other category of missing data, where there is a required binding, putting in a data absent reason creates validation errors. For example, on Condition.clinicalStatus. So in the instructions, when it says "it must be populated" I should interpret that as: it is not allowed to have a data absent reason?

Jason Walonoski (Nov 22 2019 at 15:08):

I'm having trouble coming up with other good examples that use data absent reasons. E.g. SNOMED seems to have a blanket unknown code that would exclude you using data absent reason anywhere with a SNOMED binding.

Jason Walonoski (Nov 22 2019 at 15:09):

Any other ideas?

Brett Marquard (Nov 22 2019 at 15:46):

Correct, there are few elements that MUST be (mandatory) popluated. See guidance on missing data

Jason Walonoski (Nov 22 2019 at 15:51):

What about the name example?

Jason Walonoski (Nov 22 2019 at 15:52):

And do you have ideas for any other examples? I'm trying to create some useful example instances that cover the ground.

Brett Marquard (Nov 22 2019 at 16:45):

on name, ugh, the invariant must be trumping the data absent

Jason Walonoski (Nov 22 2019 at 16:48):

Agreed.

Eric Haas (Nov 22 2019 at 18:45):

To me that is a validation issue since element is not empty

Eric Haas (Nov 22 2019 at 18:45):

@gg?

Eric Haas (Nov 22 2019 at 18:50):

The DAR needs to go on name. family and or name.given. If on name it will fail validation due to the invariant.

Lloyd McKenzie (Nov 22 2019 at 19:46):

You could satisfy the invariant if you sent given or family with a DAR inside, but a DAR directly on name won't satisfy the invariant

Brett Marquard (Nov 22 2019 at 20:18):

Understood, but I am fairly certain we didn't meant to write the invariant that way....

Eric Haas (Nov 22 2019 at 20:35):

I think that is only way to write it. We wanted at least one or the other

Lloyd McKenzie (Nov 22 2019 at 21:07):

You could have explicitly allowed for DAR if you wanted to allow for that as an option.

Grahame Grieve (Nov 23 2019 at 09:19):

What’s the actual question?

Jason Walonoski (Nov 25 2019 at 13:47):

They are asking if the behavior of the validator is correct. This example fails validation because of the us-core-8 invariant.

us-core-8

Patient.name.given or Patient.name.family or both SHALL be present [family.exists() or given.exists()]`

Data Absent Reason Example:

{
  "resourceType" : "Patient",
       ...
       "name":[
         "extension" : [
         "url" : "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
         "valueCode" : "unknown"
          }]
          ]
        "telecom" :
        ...
     }

Jason Walonoski (Nov 25 2019 at 13:48):

Ignoring the fact that example isn't complete, that is just the copy & paste from the US Core documentation.

Grahame Grieve (Nov 25 2019 at 16:08):

well, the example fails the invariant

Grahame Grieve (Nov 25 2019 at 16:09):

so I think it should fail validation

Jason Walonoski (Nov 25 2019 at 16:13):

So either the invariant needs to change, or the example needs to reflect the requirements of the invariant (e.g. DAR extension on Patient.name.given or Patient.name.family).

Grahame Grieve (Nov 25 2019 at 16:19):

agree. @Eric Haas @Brett Marquard

Brett Marquard (Nov 25 2019 at 16:19):

agree.

Brett Marquard (Nov 25 2019 at 16:19):

please log a tracker if you haven't already

Jason Walonoski (Nov 25 2019 at 16:45):

please log a tracker if you haven't already

https://jira.hl7.org/browse/FHIR-25249

Eric Haas (Nov 25 2019 at 18:03):

thanks for catching that....

Jason Walonoski (Feb 20 2020 at 22:18):

Another Data Absent Reason Question... this time on http://hl7.org/fhir/us/core/StructureDefinition-pediatric-bmi-for-age.html

In this case, Observation.dataAbsentReason is "must support", but Observation.valueQuantity is required.

obs-6: dataAbsentReason SHALL only be present if Observation.value[x] is not present [dataAbsentReason.empty() or value.empty()]

So, if I want to use data absent reason on a pediatric BMI, is the approach to use the data absent reason extension on Observation.valueQuantity.value?

Grahame Grieve (Feb 20 2020 at 23:58):

doesn't look like a very intelligent profile to me

Eric Haas (Feb 21 2020 at 00:21):

Jason you found and issue with the profiles, we inadvertently propagated an uncaught error in the FHIR BMI profile since the pediatric profiles were drafted from it. ideally would be 0..1 like and use the inline DAR element.

Eric Haas (Feb 21 2020 at 00:25):

So yes right now stuck DARing either the value or valueQuantity and optionally using the inline DAR element too.

Eric Haas (Feb 21 2020 at 00:27):

sigh.. I made a tracker to correct it, and pediatric wt and BMI.

Jason Walonoski (Feb 21 2020 at 13:56):

This issue also effects the http://hl7.org/fhir/us/core/StructureDefinition-pediatric-weight-for-height.html profile.

Robert Scanlon (Feb 21 2020 at 17:22):

@Eric Haas -- I'm not sure you can "optionally use the inline DAR element too" due to the obs-6 invariant "dataAbsentReason SHALL only be present if Observation.value[x] is not present" http://hl7.org/fhir/R4/vitalsigns-definitions.html#Observation.dataAbsentReason

Eric Haas (Feb 22 2020 at 18:24):

indeed, I forgot about the invarient

Brett Marquard (Feb 24 2020 at 10:25):

Fun times. Which rule do we want to propose breaking until a new technical release is available? (nothing planned/scheduled yet)

Eric Haas (Feb 24 2020 at 18:26):

I think we follow the spec DAR it using the extension don't use the inline DAR. no rules broken it just doesn't follow the general observation pattern. This is an edge case which is why we discovered only now.

Last updated: Apr 12 2022 at 19:14 UTC