Stream: implementers
Topic: DataAbsentReason extension or ValueSet with UNK/OTH?
Alexander Henket (Mar 29 2017 at 09:59):
Back in V3 we used to have NullFlavor at virtually any point in a message to why indicate stuff was not present. In FHIR there is a core extension for DataAbsentReason (http://hl7.org/fhir/extension-data-absent-reason.html) that seems to mimic NullFlavor. But can also still add "unknown", "other" etc. to a ValueSet if the target element is coded in some way.
.
That leaves you with two options. Depending on a (core) extension for this is only possible in a controlled setting where this explicitly required in implementation guides. It is also the only option as far as I can tell when the context element is not coded. If you use the ValueSet-with-null-included then a regular receiver is not likely to miss the dataabsentreason.
.
How do people handle or avoid DataAbsentReason?
Lloyd McKenzie (Mar 29 2017 at 14:11):
Design guidelines for FHIR are that "unknown", "other", etc. should always be part of the value set for coded elements if they're considered to fall within the scope of core. And, for that matter, a companion element allowing capture of the reason for missing data should be provided for non-coded elements if this falls within the 80% (e.g. Observation.dataAbsentReason). The data-absent-reason extension is for use when such information is not supported by most systems.
Alexander Henket (Mar 29 2017 at 15:01):
Thanks Lloyd. That sounds like a fair decision tree in designing specs.
Last updated: Apr 12 2022 at 19:14 UTC
