Silje has just pinged me again on the question of whether we should have an ELEMENT.null-reason or similar attribute to accommodate specific reasons for null_flavour being set. There are 3 PRs on this as follows:
SPECPR-41 - Enable content specific flavours of null to be specified per archetype
SPECPR-62 - Add a ‘reason for null’ text attribute in the Reference model
SPECPR-151 - Add an attribute to ELEMENT to record ‘null reason’
These are all reporting the same problem. (The last one can probably be closed as a direct duplicate of SPECPR-62). Having re-read the comments on all, my inclination is to propose the simple addition of an attribute null_reason: DV_TEXT[0..1] to the ELEMENT class. This would be optional and will not invalidate any existing data, but on the downside it will be a data field that will often be emtpy (i.e. Void, or ‘null’ in the Java/C sense).
What would the general reaction to proposing this change be?
I agree that we should go ahead with this ASAP. However it might be worth a slight pause to think about the wider problem in handling ‘clinical nulls’.
To summarise, ‘null flavours’ have limited value in a great deal of clinical models because the standard set of null flavours, although expressing the ‘reason for null’ from a technical perspective ‘not appropriate’, ‘unavailable’ etc is not clinician/context friendly enough for actual use-cases.
I think there is strong parallel here with the need to overlay the technical state machine current_state attribute with archetype_specific careflow_steps as per SPECPR-41 .
Now we will probably always need extra free text as per SPECPR-62/151 but if we are thinking about this, I suggest putting a little effort into progressing ( or ditching) those other PRs.
If null_flavour is a DV_CODED_TEXT, what stops anyone to create an
specialized archetype (directly from an rm class) that has the texts
(+ codes) needed in a given country/use case?
This probably should work even if set of null_flavour codes is fixed.
I don't know if this would be enough, but in theory it provides a
workaround for all issues (except the cluster one)
That’s a pretty good suggestion, although in that case we are really abandoning the idea of the current fixed base set of ‘technical’ null-flavours and allowing them to be replaced by local terms, while I was suggesting something more like the ISM_TRANSITION setup where archetype-specific ‘clinical overlays’ can be provided via the archetyped careflow_steps but are always associated with the underlying state_machine and current_status attribute.
extending the current openEHR null_flavour code set, and making it hierarchical OR
allowing other local code-sets to be used in that slot.
if these codes were understood as proper local extensions of the openEHR code-set, i.e. any new code asserted an IS-A relationship to one of the 4 existing openEHR null codes, then it would work properly. But we have no way to do that.
The first I think gets into the place HL7 is with this field - you can never design a terminology for ‘null flavour reason’ that works for everyone.
The second has the problem that the field becomes non-interoperable - today, applications can assume one of 4 known values; if any code set can be used, this assumption will break. Unless the ‘extension’ idea could be achieved somehow, which would be kind of nice.
Whenever I think through this problem I come back to the idea of a second field, which is more or less the design concept, as Ian says, or the state machine state + careflow step in ACTIONs.
So, if I understand well, the idea is to add an attribute for representing clinical reasons for a null flavor, maintaining the current null_flavor for technical reasons only. Is that right?
That seems to be my understanding of Thomas’ suggestion – and I think that is the way to go. Then we will have a small set of “classes of null flavours” , and the detailed and local description can be added to the second field . The second field may then be of type DV_TEXT to allow both unstructured and coded values.
Yes, this is also my understanding and I agree this is the way to go.
Best regards,
Bostjan
That seems to be my understanding of Thomas’ suggestion – and I think that is the way to go. Then we will have a small set of “classes of null flavours” , and the detailed and local description can be added to the second field . The second field may then be of type DV_TEXT to allow both unstructured and coded values.