These are formally two different vocabularies - the null_flavours is sourced from openEHR terminology, while reason text/codes are on a per archetype basis.
I’d suggest that we don’t want people being able to edit the null_flavours vocabulary in an uncontrolled way (this will wreck any computability). I can imagine however that AD and similar tools would make it easy to see the vocabulary and potentially post a change request.
Well it depends on how computable we want data marked with a null flavour to be. Not applicable is very different from Not available for example.
FYI - ‘masked’ originally was designed to be a NF that is set by a server when it hides (i.e. removes) some data item because it is ‘sensitive’, when it provides the data to some client system or application. Whether this still makes sense is an open question, since I don’t think we seriously envisage marking data as sensitive or not at the ELEMENT level.
Yes - this makes sense and I think it would be good to add this to some documentation/specification.
One use-case could be extract of openEHR data where it could make sense to mask free text (DV_TEXT). By using the masked code the server/routine could inform that some data exist or not.
As you write; data access control on ELEMENT level will be extremely hard to design and implement. If we want to follow this pattern of access controll (to filter data) we could visit the idea of a NULL_FLAVOUR on higher level structures. In some situations it could be relevant to mask an ENTRY or CLUSTER structure. Not that we have seen this in a concrete use-case yet. Still I have from a theoretical view seen this need.
What if the tooling / visualisation / from build were to allow this visually
Mild
Moderate
Severe
Not applicable
Not asked
Essentially the ability to visually add ‘null’ type terms to a normal list, or as a pesudo alternative datatype.
Under the hood these would actually be Null reasons/ null_falvour codes
Mild
Moderate
Severe
Not applicable [Reason: Not indicated Null_flavour: not_applicable]
Not asked [Reason: Not asked Null_flavour: ]
which would be represented at run-time exactly as currently intended.
i.e Mild, Moderate, Severe → value
Not applicable → null.null_flavour = not_applicable, null.reason = “Not applicable”
I think we could probably do this with current ADL but I do wonder if this can cope with both ‘technical integration’ constraints (fall back for null data in integrations) and clinical null constraints, essentially specifying allowed null terms that can be entered.
That’s probably a step too weird for me (since it makes values and non-values look like one value space), but I now get what you are suggesting and can see some attraction in it, since normal people (including docs who design healthcare forms etc) often build this kind of mixed value list.
I think to make it work properly, you’d want some way of visually distinguishing the null values, e.g. in a different colour, and to get them added in the first place, you’d have some button for ‘add exception value’ or similar.
I do think it’s necessary to be able to present this visually as if both the ordinal values and the null values belonged to the same value set. But I don’t think it needs to be difficult to visually distinguish them from each other. The paper form screenshot I included in the initial post of this topic does this beautifully: the ordinal values are presented with their respective values to the left, and the null values are presented with, well, nothing
Agree. I have no problem with making it clear somehow both in tooling and end-user apps that these are nulls but I do think this is probably how they have to be handled to make them useable in archetyping/templating and UI. Under the hood, I 'm happy for these to resolve into the current RM approach. though not sure if anything needs to change to support constraints of null_flavour codes, along with one or more ‘Reason’ codes - this is a pattern quite similar to ism_transitions, I guess and I wonder if the RM might need to change to make constraining easier.
I wouldn’t agree with that: I think it’s reasonable that they can be made to appear that way (as you have shown), but to make them literally part of the same value set, when the 0-3 are values resulting from assessment, and the other two indicate that no assessment was done (or maybe ‘not evaluable’ is actually a kind of evaluation?), would greatly confuse any subsequent inferencing.
Essentially it is mxing values with non-values, which we humans are good at because we are cognitively very sophisticated, and we are abstracting over the difference. But computers just do what they’re told…
