Scores or scales with mixed data types or explicit NULL values

[damoca (David Moner)]

@bna

The question is:
Are there any known use of the NULL_FLAVOUR today? If yes - what’s your experiences using the different flavours? Is the current list of flavours good enough? Do you miss any flavours

Null flavours is a tough topic that has been discussed for a long time. @thomas.beale presents some excellent arguments in his blog:

The HL7 Null Flavor Debate – part 1

The HL7 Null Flavor Debate – part 2

We also have some infomation in the wiki:
https://openehr.atlassian.net/wiki/spaces/spec/pages/4915211/Null+Flavours+and+Boolean+data+in+openEHR

And also in Discourse:

Uncertain, unknown and no information

Clinical data is hard to get right. One problem is to handle the unknown and/or uncertain semantic. I assume you all have met the challenge to model a value list of yes no uncertain unknown not applicable Norway is currently implementing a screening program for colorectal cancer. There will be #fhir messages with the data and extensively use of #snomed-ct. DIPS is developing #openehr models (templates and archetypes) to be used within our systems. We need to map these value sets into openehr …

I’m not sure which is the best way to discuss this and to try to reach an agreement in the community, but it will require some effort and dedication for sure.

Meanwhile, these are my two cents.

Maybe we should rethink which is the real meaning and value of having null flavours. I have been thinking on how the HTTP response codes work (4XX codes for client errors and 5XX for server errors) and that could be a good inspiration.

• There are null flavors that will come from the server, during data recovery. For example, the no information and the masked nulls, meaning that the server is not able to serve that information due to a technical or logical reason. These should be generated automatically just to inform of the situation to the receiver of the data (being a human or another system) so it can react accordingly: show an error, retry later, retry with different credentials…
• There are null flavors that will come from the user, from the person or system that is generating the data. This is the case of not applicable/evaluable, not asked… The difference here is that these null are provided during the data capture process, they are in some way also clinical data, that should be stored, processed and maybe be modified in the future. They could be also useful in the situation when an archetype defines a data point as mandatory but maybe that information cannot be recorded or it doesn’t exist. The user could select a null reason so he/she is able to, at least, store the composition without errors with all the other data. And that means that they could be archetyped.

At the end, we will probably end with more or less the same values of null, but I think that this approach of thinking helps in clarifying that the null flavour should not be understood just as a miscellaneous mess of codes.