Stream: implementers
Topic: Observation - not performed - USCDI specs
Ardon Toonstra (Oct 22 2021 at 07:27):
Is it valid to return an Observation having an unknown code in .valueCodeableConcept because the observation has not been performed? At least, I would also expect something in the .dataAbsentReason. I am however doubting if this is valid/usefull.
Ardon Toonstra (Oct 22 2021 at 07:30):
Moreover, I am missing something like a status field not-done. I don't think the Observation.status have proper codes for the not performed Observation.
Or do you argue that at the moment of the request, the Observation is made that there is no known value and thus the Observation.status = final
Mareike Przysucha (Oct 22 2021 at 07:31):
Probably status =cancelled?
Ardon Toonstra (Oct 22 2021 at 07:32):
Perhaps more fitting, but I am still not completely sure it is the right match
Ardon Toonstra (Oct 22 2021 at 07:36):
But is this common practice? Or even allowed?
It looks like USCDI describes this method, having the '266927001 Unknown if ever smoked' http://hl7.org/fhir/us/core/2017Jan/ValueSet-us-core-observation-ccdasmokingstatus.html
Mareike Przysucha (Oct 22 2021 at 07:37):
Or set dataAbsentReason = not-performed.
I think that's better than saying it in value[x].
Though I am not 100% sure.
Ardon Toonstra (Oct 22 2021 at 07:38):
I agree on that, using the dataAbsentReason
Mareike Przysucha (Oct 22 2021 at 07:43):
Depends on what you want to say. If you want to say "I don't know anything about ... (anamnesis to former behavior or preexisting conditions)", you can say this in a a code or in dataAbsentReason.
If you want to say something like: "I don't know the current concentration of blood alcohol, because the observation was not performed", I think it's better to use dataAbsentReason.
Ardon Toonstra (Oct 22 2021 at 07:51):
Or you can just not generate an Observation and return an empty searhset bundle. Indicating that no Observation exists for that requested Observation code/category ect.
Ardon Toonstra (Oct 22 2021 at 11:55):
Moreover, would including an OperationOutcome not be more appropriate to explicitly indicate you don't have any results for a certain type of Observation?
Rik Smithies (Oct 22 2021 at 12:28):
hi Ardon, there is a difference between not generating an Observation and an Observation that says something was not performed. So I don't think not generating one will convey the positive knowledge that something didn't happen. If you know the question is "are there any of these done" and the answer comes back as "zero", then that works. But even then, what you are really saying is "none were found". A positive statement that is was not done, at that time, (if you know that to be true) is more information and will be useful when anyone looks at the record.
OperationOutcome is not really used outside of the actual communication channel - "OperationOutcome is not designed to be persisted or referenced from other parts of the workflow."
Ardon Toonstra (Oct 22 2021 at 12:42):
Hi Rik! So potentially, you can answer any request with a bare-bone, generated, resource to indicate that the Observation's value is unknown?
Regarding the US core smokingstatus profile: wouldn't it for example be an improvement to have a constraint like vital signs ("if there is no a value a data absent reason must be present") to indicate that the smoking status is unknown? Instead of making Observation.valueCodeableConcept mandatory?
Ardon Toonstra (Oct 22 2021 at 12:44):
Or does the '266927001 Unknown if ever smoked' actually mean that the an observation has been made/performed with the patient, but the patient does not recall if the patient has even smoked?
Yunwei Wang (Oct 22 2021 at 14:41):
According to US Core Missing Data Guidance:
For coded data elements:
example, preferred, or extensible binding strengths (CodeableConcept datatypes): if the source systems has text but no coded data, only the text element is used. if there is neither text or coded data: use the appropriate “unknown” concept code from the value set if available if the value set does not have the appropriate “unknown” concept code, use unknown from the DataAbsentReason Code System.
Lloyd McKenzie (Oct 22 2021 at 17:25):
I think it's fine - in general - to have an Observation that is in process and doesn't have either a value or a dataAbsentReason. It would be bad practice to have a value and then have an extension that says "but I don't really have one". It's just that your Observation instance wouldn't comply with US Core - because US Core doesn't typically care about "in-progress" observations.
Ardon Toonstra (Oct 25 2021 at 10:22):
Thnx Yunwei for the missing data guidance, interesting stuff.
@Lloyd McKenzie, I can follow the reasoning for Observations that are in process . I am more interested in the situation where no observation/measurements, by a health professional, have been made about someone's smoking status (or allergy intolerances etc). The observation is not in process then. Should the system, according to USCDI (or even FHIR), explicitly generate clinical related resources indicating the relevant values are unknown upon a search?
In my opinion, most resources are not particularly well modelled for that, one example would be the status values of Observation. Moreover, I don't think it is necessary to explicitly generate a clinical related resource for this.
If I am a client and retrieve the US core smoking status resource with an Unkown if every smoked value, I expect the healthcare provider at least made an observation or tried to get the smoking status from the patient or a relatedperson. It is then possible to use the final status and potentially fill performer ect.
Lloyd McKenzie (Oct 25 2021 at 14:12):
If you're 'supposed' to make an observation but get no data, then you can have an Observation with a data-absent reason of not-performed. I guess the question is whether there are legitimate reasons to say "you're supposed to observe smoking information" - if there is, then I agree that 'value' shouldn't be mandatory.
Vivian Neilley (Oct 27 2021 at 23:41):
+1 to this on Allergy - we might not know the severity of an allergy but require the severity (and unknown is not a viable option).
Peter Jordan (Oct 28 2021 at 02:00):
@Vivian Neilley - criticality is the appropriate property in the AllergyIntolerance Resource and that can be populated with 'unable-to-assess' or not completed at all. Severity is a property of an associated reaction and that is not a mandatory element either.
Last updated: Apr 12 2022 at 19:14 UTC
