Stream: netherlands
Topic: nullFlavor vs data-absent-reason
Marc de Graauw (Mar 29 2017 at 07:31):
FHIR has 2 codelists to transfer why data is not available: FHIR's data-absent-reason and v3 nullFlavor. Values like 'unknown' and 'other' appear everywhere in the Nictiz/VZVZ valuesets. Using both in the Netherlands won't help interoperability, so is this something where we should have a best practice? What do MedMij en Zorgdomein do? Of course, data-absent-reason is 'real' FHIR, on the other hand we have loads of valuesets in ART-DECOR which use v3. Translation won't work, since data-absent-reason misses OTH, which is widely used in our valuesets.
Alexander Henket (Mar 29 2017 at 07:40):
There is a mapping NullFlavor <> DataAbsentReason: http://hl7.org/fhir/cm-data-absent-reason-v3.html
.
The DataAbsentReason valueset is linked to a core extension that has context datatype. This allows you to say
<address>
<city>
<extension url="http://hl7.org/fhir/StructureDefinition/data-absent-reason">
<valueCode value="unknown"/>
</extension>
</city>
We have not talked about using that core extension just yet. I'm not enthusiastic about it. Almost always we'll be able to say "unknown" or "other" using codes in the element itself. Only for non-coded elements you need this extension is my initial assessment.
.
You could argue differently and say that we need the same mechanism for Data Absence anywhere, even if we have codes available in the ValueSet for a given context, beit in SNOMED-CT, NullFlavor or whatever system.
Alexander Henket (Mar 29 2017 at 07:45):
So yes a best practice would be good, but I don't have a clear vision of what that best practice could look like. You could bring this up in Implementer stream. I'm sure best practices already exist
Marc de Graauw (Mar 29 2017 at 08:24):
I don't think the implementer stream is a good idea. I think a best practice for the Netherlands is what we should aim for, global consensus seems to high a target.. Our situation is different since we have a lot of valuesets available in ART DECOR, with usually v3 codes for unknown, other etc.
And neither do I have a clear vision on this, and yes, it's valuesets with coded 'unknown' and 'other' that's the use case. Let's discuss tomorrow.
Alexander Henket (Mar 29 2017 at 09:44):
The implementer stream could give you a hunch whether or not other people thought about this and what they came up with. That's just to stream line our thought process. It doesn't have to mean world consensus although if achievable you can hardly argue against that 
Alexander Henket (Mar 29 2017 at 09:51):
This touches the topic stream:implementers topic:Required+bindings+and+data+absent+reason and this
stream:implementers topic:dataAbsentReason+extensions
I don't see a truly related topic though.
Alexander Henket (Mar 29 2017 at 10:00):
Asked anyway here: https://chat.fhir.org/#narrow/stream/implementers/subject/DataAbsentReason.20extension.20or.20ValueSet.20with.20UNK.2FOTH.3F
Alexander Henket (Mar 29 2017 at 20:06):
Answer from lloyd which seems reasonable:
.
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.
Grahame Grieve (Mar 29 2017 at 21:36):
what's 'misusing other' about?
Marc de Graauw (Mar 30 2017 at 07:32):
@Grahame Grieve who says "misusing other"? If you refer to "missing OTH", which I wrote, the codesystem data-absent-reason looks somewhat like v3 nullFlavor, but an obvious match for 'OTH' is missing. There's 'astext', but that would apply only if there is text. So if I want to make a valueset {A, B. other}, I can code 'other' as v3 nullFlavor, but I see no clear FHIR alternative.
Grahame Grieve (Mar 30 2017 at 19:48):
sorry. misread you. But the omission of OTH is deliberate; the only cases it is the correct thing to use is internal to the data type definitions, and those cases do not need OTH in FHIR
Last updated: Apr 12 2022 at 19:14 UTC
