That is a tough one, @siljelb !
In your preferred option 1, you MUST set the null_flavour to something anyway for the last two “values” from the score. (Only having a null_reason is not enough as per the spec)
The choice for this is:
253|unknown|, 271|no information|, 272|masked|, and 273|not applicable|
Therefore is simply using the two null_flavours as follows not an option?
- “Not assessed” ↔ 271| no information and
- “Not evaluable” ↔ 273| not applicable
I must say that I am always slightly uneasy with the openEHR null_flavour codes because these four codes seem not to be very well defined (or simply not very well understood by me) and my assignments above may not be correct. BTW, it seems I am not the only one with this problem, see e.g. this discussion: Uncertain, unknown and no information - #2 by pablo
The question of course is how to properly present this in GUIs based on templates, etc. and also if you need the exact text of “Not assessed” and “Not evaluable”, especially the more low-code it gets.
Adding the null_reason as constraint to an archetype makes this far more complex (beyond just supporting another field). This is because we then have to constrain the tuple of (null_flavour, null_reason) to two different options above (but e.g. Not assessed ↔ 273 not applicable would not be allowed).
Another reason why constraining the null_flavour and/or null_reason at design time is problematic is that the other null_flavours (and kind of free text reason) may still be required at runtime, e.g. masked, so in essence there seems to be more than one layer of null_flavours possible here. It may well be possible that people want to document e.g. “Not evaluable”, but this information subsequently gets “masked” when presenting documented data. This seems to be problematic when we start constraining null_* at design time already.
For these reasons, I find option 1 - EXPLICITLY constraining null_flavour and/or null_reason at design time, pretty hard to get right.
However, using null_flavours [+ null_reason] at runtime to document these two NULL options, should be possible in theory at least everywhere, including in this case where the score developers have explicitly thought of these possibilities and explicitly allow them.
And if the two codes aboce chosen by me are not accurate, we may need to look into adding others of making the description more explicit.
Looking at NullFlavor - HL7 Terminology (THO) v5.3.0 they support quite a lot more codes, and “Not Asked” may be a more appropriate or at least more specific null_flavour for the score’s “Not Assessed” value.
It may not be enough to put in a comment or hint in the description/comment that these two values are modelled explicitly in the score, but are typically covered by null_flavours in our case? If these two values need to be modelled more explicitly than that I am not sure Option 1 is good.
Option 2 seems very dangerous to me. At least I would consider if -1 is not a better value in these cases, although we’d need to be careful if there is a total score. Maybe 999 is a little better - that would at least come up in any reasonable check if the total score is correct.
Re Option 4: I don’t think having a NULL code here is an option, it would need to be a letter I guess. Generally a bit clunky and not conveying the modelling intention very well.
So, from my point of view, I think making sure that we make null_flavours so useful that we can use them in such situations would be very benefitial. This may require a few extra codes or better documentation of the existing codes, (re-)harmonising with FHIR. More importantly, it requires giving a hint that these two null_flavours (and potentially these two null_reasons) are preferred. And one way of doing this in the future may be by using binding strengths here?
Given all this and also the clunkiness of any alternative approach, it seems to me that using an ORDINAL for this modelling without explicitly constraining null_flavours or null_reasons at design time and providing descriptions/comments/(UI) hints of some sort as to the usage of the two preferred NULL values is the least evil solution. It also seems to me that it is the only one with a pathway to a more proper solution in the future.