Clinical scales - ordinal or coded text?

Actually such response options are textual values.

Those are classified as an ordinal type in LOINC, and they equal to 1+, 2+, 3+…

I agree but I can see that conceptually there really is no difference between the Clinical Frailty 1-9 and NYHA Grade 1 to Grade 4.

Both are actually arbitrary grades - CFS could easly have been developed as Grade 1 to Grade 9, and NYHA as 1 to 4.

This is why I have suggested that no scales should be published without an informatics expert review!!

Agree. Creating a scale or a questionnaire is not just a casual thing.

Related LOINC Codes:

LOINC 93124-6 New York Heart Association Functional Classification panel

Its MemberLOINC Codes:

LOINC 88020-3 Functional capacity NYHA
LOINC Scale Type: Ordinal

Normative Answer List LL4734-1
Source: American Heart Association
Answer________Code________Answer ID
Class I________I________ LA28404-4
Class II________II________ LA28405-1
Class III________ III________LA28406-9
Class IV________IV________ LA28407-7

LOINC 88021-1 Objective assessment of cardiovascular disease NYHA
LOINC Scale Type: Ordinal

Normative Answer List LL4735-8

Source: American Heart Association
Answer________Code________Answer ID
No objective evidence of cardiovascular disease________A________LA28408-5
Objective evidence of minimal cardiovascular disease________B________LA28409-3
Objective evidence of moderately severe cardiovascular disease________C________LA28410-1
Objective evidence of severe cardiovascular disease________D________LA28411-9

Interesting. the LOINC definition of ordinal therefore goes beyond a coded_text ‘symbol’ plus related numeric ‘value’ in openEHR to allow other string-based ‘values’ . I am not sure I trust that approach or see the particular added value.

Thanks @siljelb. Timley conversation.

Our problem comes exactly because we are forced to squeeze the scores and scales into Text and Ordinal data types. While it is possible to use either data type for most scores/scales, there are always outliers.

Ordinal is not truly intended to support scoring, but rather ordering.

So when we get scoring that is sequential or unique whole numbers it works fine. But if we get duplicates we had trouble, at least until recently. And if we have scores that have 2, 2.5 and 3 we have no possible solution except to try to represent the numerical scores associated with each value/selection.

Ultimately we need a technical datatype solution that separates out the score from the ordering, so that developers know when the score is applicable for the archetype - at the moment it can be derived from the hierarchy of a DV_ORDINAL or in the name or description of a CODED_TEXT.

There is no consistency because it is not possible to be consistent when we are often forced to adapt data types for purposes they are not intended for.

We need a data type that allows:

  • data element names for all
  • descriptions for some, but not all
  • ordering for some, but not all and not always sequential or unique
  • scores associated with some, but not all
    It is not just about modelling patterns…

Advice from our @Specifications experts?

Thanks everyone for your responses!

Before attempting to conclude on this, I’d like to hear from more people with UI implementation experience, for example @bna, @vanessap.

You need to implement this, as closely as practical to what it looks like on paper:

What makes this easier?


…or this?

…or something else?

And why? :sweat_smile:

That is coming - new datatype called DV_SCALE basically identical to DV_ORDINAL but allows real numbers as well as integers . There was no simple way of extending/adapting DV_ORDINAL without causing breaking changes, so the decision was that very largely, DV_SCALE would be used for new archetypes, leaving DV_ORDINAL as deprecated unless tere is some IMO very weird) requirement that the numeric be an integer.

Do you mean within a specific scale? some coded_texts have numbers , some don’t?

I don’t think there is anything in the RM/AOM which forces us to have descriptions - just custom and practice/ tooling behaviour.

From an UI perspective it doesn’t really matter if we use DV_CODED_TEXT or DV_ORDINAL. It matters though if we have to share the data with some obscure messaging format. They typically tend to use the number shown on screen. It saves a few keystrokes if we use an ordinal then.

If the score is a continum or not integers it still doesn’t matter (IMHO) - but the preferred solution would be to wait for the new DV_SCALE. We’ve implemented it in our software (backend/libraries), but I assume it takes some time before the tooling chain is ready for it.

It is coming? How advanced is this discussion? As clinical modellers it would be good to know, so that we can confirm it meets all our modelling requirement before it becomes part of specifications…

1 Like

That’s useful feedback, thanks!

The original trigger for this discussion was a question about whether we should use DV_ORDINAL or DV_CODED_TEXT for the Clinical Frailty Scale archetype, which is about to be published. This was originally modelled using DV_ORDINAL, but feedback from reviewers that the combination of the numeral and the description text string was confusing (see image below), led us to change it into a DV_CODED_TEXT. In retrospect, this is really a problem with the visualisation in the CKM and not really with the model as such.

I think this visualisation would be more useful if it was modified so that it’s clearer that the numeral (the bit before the colon) and the text description are two separate things.

If we got that fixed, a good modelling guidance could be something like “If a scale is displayed as a numbered list, use DV_ORDINAL”?

I think we need to understand what DV_SCALE offers before we can proceed any further. I didn’t know this was in development…

DV_SCALE is identical to DV_ORDINAL other than allowing real numbers rather than just integers. The only reason it exists is that it would have been too disruptive to try to change DV_ORDINAL whicj would have been a breaking change in the RM.

As for current DV_ORDINAL the unique number rules is relaxed. Are there any other changes needed? I think I’d be pretty reluctant to relax the requirement for the numeric value to be mandatory or allow things like ‘infinity’ (one of the Berg scales).

“If a scale is displayed as a numbered list, use DV_ORDINAL”? would still work but I’d be saying in future “If a scale is displayed as a numbered list, use DV_SCALE”? which is just that little bit more flexible.

The SPEC CR is at if you want to comment there

Agree. It should be DV_SCALE as soon as this is available in tools.

But would changing the visualisation fix the original problem?

[1] 1. Very fit
1:: 1. Very fit

Although TBH I 'm not too bothered by the visualisation. It is really an artefact of the original score author putting the numeric in the text and requiring people to stick to the text but here is an example where that is not the case an NHS sponsored app). So I think there is an argument that where the numeric is carried in the text, and we also carry it in the ordinal value, that we can relax the requirement to also carry it in the text - I don;t think we are subverting the spirit of what wa intended or the clinical safety.

We have had to make many other ‘tweaks’ to be published scales, because quite simply they cannot be implemented otherwise.

So on balance I think we should be more relaxed about rigidly including the numeric in the text idf this is (in our world) quite reasonably split into a separate field which can be easily reconstituted in a UI, if that seems appropriate. If needs be offer guidance in the metadata.

[1] 1. Very fit
1:: 1. Very fit

The way it is displayed in the CKM is confusing. Modellers will know, but a lot of our reviewers doesn’t understand why the numbers are displayed twice. Any help here in the CKM will help. I prefer [1] 1. Very fit… Or something brilliant that @sebastian.garde can come up with? :smiley:

1 Like

I’m arguing that there is no need for us to include the numerics in the text (as it is in the original) as we are faithfully capturing that, albeit in a slightly modified way. This is the price of turning a paper artefact into something computable. Of course, we should not mangle meaning or compromise safety but, I would defend dropping the numeric from the text, in that regard.

I’ve reread the terms of use, and I can’t find the phrase about faithful reproduction of the text that I thought I’d seen before. So maybe this is okay, from a representation POV. Would removing the numbers from the description impact ease of implementation for you, @bna?

The numbers doesn’t really matter from a technical viewpoint. We have features to add the number from the code to the user if that’s needed/wanted. Depends on the use case.

My personal view is to remove the number in description since it is a duplicate and possible error cause if the number/ordinal where to be changed.