FHIR Chat · USCOBH-11 - should DAR be required?

Stream: inferno

Topic: USCOBH-11 - should DAR be required?

Cooper Thompson (Aug 06 2021 at 14:59):

Should USCOBH-11 be requiring support for dataAbsentReason? It currently is, but it doesn't seem like it should. I don't see a DAR requirement in the general server capability statement. There are several Observation profiles have this requirement:

An Observation without a value, SHALL include a reason why
the data is absent unless there are component observations,
or references to other Observations that are grouped within it.

However, this is a conditional SHALL, and if the system is always returning Observations with a value or component observations, then DAR isn't required.

Stephen MacVicar (Aug 06 2021 at 15:57):

That language is from US Core 3.2.0, right? Inferno is testing against US Core 3.1.1 until ONC approves a newer version. Currently, US Core 4.0.0 is under consideration for approval, which contains clearer language:

Systems that never provide an observation without a value are not required to support Observation.dataAbsentReason

Cooper Thompson (Aug 06 2021 at 17:16):

I see that language in 3.1.1:

Cooper Thompson (Aug 06 2021 at 17:17):

I think I looked through all the possible 3.1.1 Observation profiles (the ones I didn't list didn't have any mention of DAR). Maybe there is a DAR requirement that isn't conditional buried in one of them, but I can't see it.

Cooper Thompson (Aug 06 2021 at 17:19):

I called out USCOBH-11 specifically, which references http://hl7.org/fhir/R4/bodyheight.html. But same deal there:

Either one Observation.valueQuantity or, if there is no value,
one code in Observation.DataAbsentReason

Robert Scanlon (Aug 06 2021 at 18:09):

If you click on the 'Full View' for one of the STU3.1.1 resources, you'll see that Observation.dataAbsentReason is flagged as 'must support'. This comes from the base FHIR vital signs profile that the STU3.1.1 vital signs profiles derive from. Since the profile doesn't change this element, it doesn't show up in the differential, but it is still in the profile.

Robert Scanlon (Aug 06 2021 at 18:13):

Inferno's us core must support tests are very simple: it looks at elements flagged as must support in the profile, and checks off which of those elements it has seen across all resources that meet that profile (containing a value -- DARs are allowed but don't count as evidence of support).

Cooper Thompson (Aug 06 2021 at 19:04):

Though in this case, DARs do count as evidence of must support, since you are checking for support of DAR.

Robert Scanlon (Aug 06 2021 at 19:06):

if there is language in the "must support" narrative within the profile clarifying what it means in this context, we loosen the must support check. This happens, for example, in the Implantable Device profile where is says in the must support section that they can support either HRF or AIDC. And in US Core R4, they add in an exception as Steve pointed out above. It just isn't in US Core v3.1.1.

Robert Scanlon (Aug 06 2021 at 19:08):

Yeah, this is a very confusing example, because the element itself is a DAR. I was referring to times when you leave the value of an element empty and add a DAR extension.

Cooper Thompson (Aug 06 2021 at 19:08):

I suppose this needs to be a request to ONC for clarification in the CCG then? Since we always support sending Observation value data, we'd have to info block in order to pass the DAR check :grinning_face_with_smiling_eyes: .

Cooper Thompson (Aug 06 2021 at 19:19):

(deleted)

Yunwei Wang (Aug 06 2021 at 19:26):

Added to what Steve mentioned about, the ticket on US Core vital sign profiles is: https://jira.hl7.org/browse/FHIR-30699

Robert Scanlon (Aug 06 2021 at 19:48):

Since we always support sending Observation value data, we'd have to info block in order to pass the DAR check

I think the idea is that you would have to explicitly be able to support the case of communicating that an observation occurred, but for some exceptional reason a value didn't get recorded. Right now that information is simply not recorded in those exceptional cases, or perhaps stored somewhere else and not considered to be an 'Observation'?

Robert Scanlon (Aug 06 2021 at 19:50):

But since US Core v4 adds an exception here, it seems that this is an oversight vs something intended to be required...

Cooper Thompson (Aug 06 2021 at 20:17):

Normally recording something like an Observation has some sort of transaction around it, so you either get an Observation with a value, or you don't. Getting an Observation without a value is normally going to mean database corruption of some sort.

Cooper Thompson (Aug 06 2021 at 20:18):

Hans was making the same point in FHIR#30699, so I expect Cerner behaves similarly.

Cooper Thompson (Aug 06 2021 at 20:19):

Anyway - do you think this is "Inferno-change" or "ONC-clarification" territory?

Yunwei Wang (Aug 09 2021 at 15:58):

The clarification in US Core 4.0 makes sense but we also don't want to deviate from US Core 3.1.1 too much.

Yunwei Wang (Aug 09 2021 at 19:25):

I think it is better to provide feedback to ONC to address this either over CCG or SVAP @Cooper Thompson

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · USCOBH-11 - should DAR be required? · inferno