FHIR Chat · Preserving the meaning of “negative space” terms

Stream: terminology

Topic: Preserving the meaning of “negative space” terms

Rute Martins (Oct 02 2019 at 19:11):

We’ve come across an implementation scenario where a coded element at the point of data capture is drawn from a value set with extensible binding and:

Not all codes from the specified value set are presented to the user; and
An additional local code with the description of “other” is also presented, and not part of the value set (technically allowed because the value set is extensible…)

The question here is how to we preserve the meaning of that context-dependent “other” option in a corresponding FHIR resource without making any changes to the way the data is currently captured (non-negotiable from the clinical side)?
@Mark Kramer and I have been scratching our heads and the only (and clearly clumsy) solution we have found to this issue is to provide guidance to implementers to fully expand the implicit negative space as a pseudo-code in CodeableConcept.text as “NOT(A or B or C)”, where A, B and C are the codes from the value set that are surfaced in the UI.

The use of “other” options is very common in questionnaires, and it’s bound to come up again, yet I’ve been unable to find any discussions and/or guidance on this topic. Any and all ideas welcome!

Lloyd McKenzie (Oct 02 2019 at 19:15):

It's very difficult to define what set of codes a user "considered", especially if the UI requires them to type search criteria to find the code they eventually select. In theory, the system could create (and transmit) a value set of all the codes the user was exposed to (and the display terms used) at the time they made their decision. In practice, good luck getting a client application to do that... The most common practice is to maintain traceability that a particular result came from a given questionnaire. That lets you go back and see exactly what options were presented and even how the question was phrased.

Rute Martins (Oct 02 2019 at 19:22):

Agreed. I should add that this particular application is not a questionnaire, but that the options presented can (and will likely) change in the future. There's not a robust version tracking mechanism we could use to keep that traceability. But even if there was, we would still be highly dependent on knowing which questionnaire and what version (it may not be publicly available). What then?

Grahame Grieve (Oct 02 2019 at 19:23):

if you really don't have good control over the versioning of the context where the question was asked, then you can use the value set extension: http://hl7.org/fhir/r4/extension-valueset-reference.html

Grahame Grieve (Oct 02 2019 at 19:24):

but: even then the potential list of other codes doesn't really provide you with that much information. you know what the user could have chosen, but not why they didn't choose them

Rute Martins (Oct 02 2019 at 19:40):

We're on DSTU2, sadly.

Lloyd McKenzie (Oct 02 2019 at 19:41):

Nothing stops you from pre-adopting the extension in DSTU2

Grahame Grieve (Oct 02 2019 at 20:01):

that one was defined back in R2

Michael Lawley (Oct 03 2019 at 20:27):

How important is the interpretation of the "Other" case? i.e., is it really the case that you need to interpret it as "not X and not Y and not Z and ..."? Or is it more sensibly interpreted as "Unspecified"?