Scores or scales with mixed data types or explicit NULL values

Clinical
42

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.

4 Likes
43

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)

Just a slightly confused…

44

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.

Is there a really pressing need?

45

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.

2 Likes
46

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?

47

Yes, this change would definitely not work out of the box for CKM and pretty sure also not for any other tool.

3 Likes
48

And it will also need a change in CDR validation

2 Likes
49

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.

Which, by the way, was done some days ago: Observation Archetype: Neurologic Assessment in Neuro-Oncology (NANO) scale [openEHR Clinical Knowledge Manager]

50

@ian.mcnicoll, @sebastian.garde

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. :slight_smile:

Kind regards, Vebjørn

2 Likes
51

Raised as a Specification PR and I will table specifically at the next SPEC meeting.

https://openehr.atlassian.net/jira/software/c/projects/SPECPR/issues/SPECPR-442

52

This looks like a different issue to me?

53

SPECPR-442 is the correct one.

54

Apologies - JIRA was messing me about. Fixed now.

Please add comments there, so hopefully we can get consensus on this ASAP.

55

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 :slight_smile:

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 :slight_smile:

56

A couple of comments that might help.

  • 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.

value matches {
                                                    DV_ORDINAL[id9056] matches {
                                                        [value, symbol,allow_null_value] matches {
                                                            [{0}, {[at24]}, {{false}}],
                                                            [{1}, {[at25]},{{false}}],
                                                            [{2}, {[at26]},{{false}}],
                                                            [{3}, {[at27]},{{false}}],
                                                            [{}, {[at28]},{{true}}] // Nullable 
                                                        }
                                                    }
                                                }

I’m sure that is not legal ADL but hopefully you get the idea.

This is about being able to apply ‘optional’ to a specific CodedText constraint, not to the whole Element.

2 Likes