Stream: implementers
Topic: DataAbsentReason | NullFlavor | ValueSets
Alexander Henket (Jun 18 2019 at 12:05):
Most of what we do has a V3 background. Most ValueSets for that reason contain exceptional values i.c. NullFlavors. Almost always these are UNK and OTH, but MSK/ASKU/NASK could happen. If no specific NullFlavor is specified, any NullFlavor can happen.
When I take a ValueSet like that to FHIR, I get into questions I cannot answer in STU3 and R4 makes it worse. I hope someone can shed some light.
Consider this V3 fragment:
<value xsi:type="CD" nullFlavor="UNK"/>
In FHIR this could lead to:
<valueCodeableConcept>
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-nullFlavor">
<valueCode value="UNK"/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/data-absent-reason">
<valueCode value="unknown"/>
</extension>
<coding>
<system value="http://hl7.org/fhir/v3/NullFlavor"/>
<code value="UNK"/>
<display value="unknown"/>
</coding>
</valueCodeableConcept>
Suppose the ValueSet behind this element would specify the exceptional value UNK, then any validator would require UNK to be in coding. Suppose the ValueSet did not list UNK, then any validator would forbid UNK in coding (likely pointing the implementer towards the extension).
This is really inconvenient, and it does not answer how UNK relates to DataAbsentReason which sort of duplicates what UNK is trying to say.
Matters get worse in R4 where the NullFlavor extension in FHIR has been updated to say that I should not use OTH, PINF, NINF and TRC anymore.
Is there any guidance in when to use what?
Lloyd McKenzie (Jun 18 2019 at 16:57):
Best practice is that where the notion of "unknown" is relevant for a coded element, it should be part of the value set. If it's not part of the bound value set, but the binding strength is example, preferred or extensible, you can still use the UNK as a code value. If the binding is required, you're out of luck. It's not permissible to have the element included in the instance unless a code is chosen from the value set. There must either be a coding from the bound value set or the element must be omitted. (And if it's a min=1 element, you may be in a situation where you can't send an instance at all.)
Lloyd McKenzie (Jun 18 2019 at 16:58):
For non-coded elements, best practice is probably to use DataAbsentReason as it's more FHIR-specific. However, sending NullFlavor instead for ease of conversion isn't necessarily wrong. Sending both is sort of redundant, but may also ease reverse conversion/preserve source information better.
Grahame Grieve (Jun 18 2019 at 17:56):
OTH, PINF, NINF and TRC
there a specific reasons for each of these, and if it's a problem, then there's an underlying problem, I think
Alexander Henket (Jun 18 2019 at 22:23):
OTH, PINF, NINF, TRC
I can see how OTH + originalText from V3 would end up being just CodeableConcept.text (potentially with coding.userSelected=true) but I fail to see why having NullFlavor OTH would be advised against.
Same for PINF/NINF/TRC. I must say I've never seen those in practice, but suppose they are true in V3, what would you do in FHIR?
It's a pity that the discussion that must have led to the updated wording in the extension was not captured with the extension so I could understand. I've looked for the tracker item, but could not find it. Would you happen to know?
Alexander Henket (Jun 18 2019 at 22:39):
@Lloyd McKenzie Thanks I think that could work for us. After inspection of our profiles, I believe there's only 1 occasion where we might run into trouble because of an element 1..1, binding required, no NullFlavors in set, and reason to believe there should have been. But that would be our thing to look into. Thanks again.
Grahame Grieve (Jun 18 2019 at 23:02):
OTH, TRC, PINF and NINF all have only valid uses in V3 that have no equivalent in FHIR - they're methodology things
Alexander Henket (Jun 18 2019 at 23:14):
If the extension NullFlavor is about bringing that functionality to FHIR, why leave them out? Isn't the extension about the same thing which is to state your reason for not having a value? Suppose I truly have:
<value xsi:type="PQ" nullFlavor="TRC" unit="mmol"/>
What would I do?
Grahame Grieve (Jun 18 2019 at 23:19):
how can you truly have that?
Grahame Grieve (Jun 18 2019 at 23:20):
I assert that the value of this is positive infinity (with no units...). That is not a meaningful statement. The only place that PINF (and NINF) are meaningful statements are where they are assigned an arbitrary meaning of "not, actually, when it comes to it, [X}INF" in IVL
Alexander Henket (Jun 19 2019 at 12:41):
Like I said: I've not seen NINF/PINF/TRC in practice, but R4 deemed it necessary to say "do not use here". So what would I do when I see them? If there is no real life use case for ever using those NullFlavors in V3, then I should just assume they occur.
Lloyd McKenzie (Jun 19 2019 at 14:05):
When you see them, you need to figure out what they're trying to represent and then decide what the appropriate way to represent that in FHIR is - which could be context-specific.
Last updated: Apr 12 2022 at 19:14 UTC
