I’m increasing not sure that null flavours should ever be part of clinical modelling at the archetype level. No information, masked, unknown (in information context, as opposed to a clinical determination of unknown) and not applicable should be available on all data points at all times, including a reason for each null.
The current tooling only supports removal of the remaining null flavour options in order make one explicit or emphasised, when in fact all null flavours should be available all the time. Making ‘unknown’ an option in the archetype for a value set, should not remove the ability for ‘not applicable’ or ‘masked’ to be available in a template or implementation scenario.
Agree about another thread being a better option at this point.
So, the solution is … what?
a) Use Ordinal and value ‘99’ for now or;
b) Wait for changes in spec’s as described by Sebastian, then change to DV_SCALE or;
c) Change to DV_SCALE now, and fudge it to something in line of ‘99’ as alternative a)
The problem will be that if you do anything right now, it will require a breaking change to the archetype later, other than using the ELEMNT.null feature. or adding a temporary DV_CODED_TEXT alternative.
I suggest @sebastian.garde and I take it to the SEC and see if we can get a quick Spec update agreed. It would also need a change in tooling and ultimately in the CDR validation.
If this can go through the SEC quickly it would be appreciated. This archetype is going through review ready for near future implementation. And there is another archetype with this same modelling issue that will likely follow through review in the next few months.
Agree, it would be great if this could be fast tracked. However, if I understand correctly it’ll have to be changed in tooling and implementations too?
So it will take months to be able to use the proposed design. Which means we’ll make NANO archetype as alternative a) in my post above, and leave it in v0.
I wonder if there has been any progression on this? Not to stress people, but if this change is fairly minor and solves the problem, it would be nice to proceed with it.
Thanks to all who contributed for this thread, deserves (and requires) a few readings.
My inadequate brain failed to grasp how @sebastian.garde 's suggestion is solving the example @siljelb gave though
As discussed in this thread, there is a requirement to indicate the semantics of lack/unavailability of data and won’t we just lose the capability to express that semantics by using a null value ?
Clinical modellers seem to be happy with the suggestion, so I must be missing something here. Care to help me catch up with the rest of you?
Ps: There is so much to unpack here, worth commenting on, but I’d like to stay on track to be of some use in the SEC
For these PROMS-type scores the real ‘value’ is arguably the symbol (DV_CODED_TEXT) not the numeric ‘value’. And in some Scores that value really needs to be null, for at least some of the responses.
I had suggested making ‘value’ optional but on further thinking, I can see that this would allow all sorts of crappy data to be collected.
what I think we need is to allow an ‘allow null value’ option to be associated with a specific Code value constraint which in ADL2 could be done with a tuple, rather than ‘allow null value’ on the whole Element.
Thanks to everyone for the insightful input so far — this topic has had my head spinning for a while, too!
In the example shared by Silje, the “null” answers are explicitly embedded within the question’s ordinal options, which makes the handling of missing data more transparent.
However, when it comes to PROMs and the subsequent analysis of PROMs data, properly addressing patterns of missing data and the use of null flavours becomes especially important. In fact, this might be relevant not just for questions where such options are explicitly listed, but potentially for all PROM questions.
Consider this example:
A male patient completes a PROM questionnaire, and several pregnancy-related questions are automatically hidden by the application logic. These hidden questions don’t display options like “Not applicable” or “Not assessed.”
A female patient sees the same pregnancy-related questions but chooses not to answer one of them, while submitting the rest of her responses.
Later, when analyzing the data, it becomes critical to distinguish whether a question was not shown (i.e., not applicable due to system logic), or whether it was shown but not answered by the patient.
Some clinics in our hospital use REDCap for Surveys, we’ve seen some rather “hacky” solutions to this — such as using codes like 999 or 777 to indicate different types of missing responses. While practical, these workarounds highlight the need for more robust, semantically meaningful approaches. Is there a good way to handle these “Reasons for Missing Data” scenarios?
This is under discussion by SEC right now and there is an outstanding action to get clinical and tech together so that SEC can better understand the challenge and e,g why null_flavours (IMO) are not a good answer.
Re-reading you post, I actually think that null_flavours probably are a good place to document e.g partial completion for various reasons, especially for those that can be anticipated e.g not answerable by a male. I’m not sure I 'd try to catch and justify every partial-response, as that really complicates the UX
Somebody from our Quality-Management Department performing analysis of the datasets of PROMS-data brought this up which was very interesting to view this topic from his perspective: When seeing PROMs-data in a table view it would be very useful to see why some answers were not provided. I was not sure if this is possible with our current modeling:
As for the questions where explicit missing data ordinals are present, it would be great if we could render these null flavours as part of the frontend only in these special cases. The user would be unaware that altough he gets 5 possible answer-options 2 of them are semantically different things. Like this the archetype would not have additional fields because we would be using already existing ones.
