Stream: genomics
Topic: Pertinent negatives & no-call regions
Jamie Jones (Jul 20 2020 at 16:14):
Hi all, wanted to follow up today's discussion with http://build.fhir.org/observation.html#resource which provides the rule:
"dataAbsentReason SHALL only be present if Observation.value[x] is not present". Since we set value[x] to 0..0 on region-studied, dataAbsentReason could theoretically be used, but using this along with no call or indeterminate as a value on other Observations is improper.
Further description of the field:
Null or exceptional values can be represented two ways in FHIR Observations. One way is to simply include them in the value set and represent the exceptions in the value. For example, measurement values for a serology test could be "detected", "not detected", "inconclusive", or "specimen unsatisfactory".
The alternate way is to use the value element for actual observations and use the explicit dataAbsentReason element to record exceptional values. For example, the dataAbsentReason code "error" could be used when the measurement was not completed. Note that an observation may only be reported if there are values to report. For example differential cell counts values may be reported only when > 0. Because of these options, use-case agreements are required to interpret general observations for null or exceptional values."
Kevin Power (Jul 20 2020 at 16:17):
Thanks @Jamie Jones -- That actually makes me wonder if our way of not allowing Observation.value[x] is even appropriate?
Jamie Jones (Jul 20 2020 at 16:26):
I agree we need to re-think value[x] on region-studied, since we are viewing it as its own observation and not a panel like Grouper (where we also removed value[x], which is valid as long as one of the .hasMember Findings have a value).
Also the Implications, I recall seeing that as long as components have a value you don't need one on the Observation itself, will have to track that down...
Jamie Jones (Jul 20 2020 at 16:39):
Interestingly, the FHIRpath expression of constraint/rule 6,
obs-6 - dataAbsentReason SHALL only be present if Observation.value[x] is not present - dataAbsentReason.empty() or value.empty()
Seems to suggest any panel Observation matching their described pattern:
"For grouping related observations such as for a "panel" or "battery". In this case the Observation.code represents the "panel" code, typically Observation.value[x] is not present, and the set of member Observations are listed in Observation.hasMember. This structure permits nested grouping when used with DiagnosticReport (e.g. complex micro isolate and sensitivities report)."
would also have to supply a dataAbsentReason... not sure this is intended. I've never seen an error from that rule on HAPI/etc.
not-permitted may be appropriate.
Bob Dolin (Jul 20 2020 at 17:12):
@Jamie Jones Hi Jamie. I was thinking that the intent wouldn't be to use dataAbsentReason on region-studied, but rather, on Variant. (Observation.value for variant profile includes various data absent reasons, such as 'no call', which we'd have to think through).
Bob Dolin (Jul 20 2020 at 17:22):
In other words, region-studied is making explicit assertions about noncallable regions, whereas you may also want to make an explicit assertion about a variant in a noncallable region, in which case you'd use the variant profile, with an observation.value of not callable or perhaps a data absent reason.
Kevin Power (Jul 21 2020 at 13:14):
Thanks for the explanation @Bob Dolin - I think that makes sense to me. Variant(Observation).valueCodeableConcept is currently bound to a LOINC answer list with Present, Absent, No Call, Indeterminate. I concur with Bob D that we need to think through a value of "No Call" and if it is really the same thing we are talking about here.
Joel Schneider (Jul 22 2020 at 19:31):
The "recommendation is to include notions of other, unknown, etc. into value sets if the element is coded, NOT to use [DAR]".
(per Lloyd's comment here: https://chat.fhir.org/#narrow/stream/179202-terminology/topic/Extensible)
Bret H (Jul 27 2020 at 12:58):
data absent reason seems both appropriate and useful to me. Use what all ready exists in FHIR
Joel Schneider (Jul 27 2020 at 20:59):
My comment above refers to a general recommendation for value set bindings.
FHIR defines generic data absent reason and null flavor extensions, but those extensions are limited in their ability to describe nuanced reasons for missing data.
Last updated: Apr 12 2022 at 19:14 UTC
