Clinical scales - ordinal or coded text?

Starting with some definitions. These are not universal, but I’m using the words this way in this post:

  • Clinical score: A multi-component clinical assessment tool that involves summing up the numerical values of a set of more than one component. Example: NEWS2
  • Clinical scale: A clinical assessment tool consisting of one or more components with a value set, which are not summed into a total score. The component value set items may or may not have numerical values associated with them. Example: New York Heart Association (NYHA) functional classification

This terminology is made even more confusing by the fact that some clinical scores are called “something something scale” (like Braden scale).

Clinical scores are usually represented in archetypes using a set of Ordinal type elements, whose values are summed up in a Count type element. The Ordinal data type makes it easy to associate a computable number with a text string in the value set items, and as such is perfect for this use case.

Clinical scales however, have no use of summing up the values, and as the number of each value set item often needs to be displayed to the clinician as part of the text, there may be value in putting the number in the text string of each value set item. However, if a scale needs to be displayed as a graph on a time scale, that would be an argument for representing it as an ordinal in order to get the computable numerical value.

We have several of published clinical scale archetypes, some of which are using Coded text and some of which are using the Ordinal data type. We’d like to be able to set down a pattern for this kind of archetype in the modelling style guide, but we’re getting mixed response from reviewers and other parts of the openEHR community.

Therefore we’d like to gather all the arguments, clinical, modelling and technical,

Convince us. :wink:

1 Like

It’ s not necessarily a proper scale although it’s called as SOMETHING Scale.

A useful link:
15 Common Rating Scales Explained
by Jeff Sauro, PhD | August 14, 2018

MeasuringU: 15 Common Rating Scales Explained

LOINC would be a professional reference for your question:

Example Scale:
LOINC 75243-6 Norton scale panel

Example Question:
LOINC 75244-4 Physical condition [Norton scale]
LOINC Scale Type: Ordinal

Maybe you can use the online tool Search LOINC to find similar scales or surveys:

1 Like

That’s a great reference, thanks. And you are right - this is a real mess!!

So my view FWIW

  1. Agree use DV_ORDINAL where it is need for computation e.g in a total score or grade. (easy!!) BTW a new ‘DV_SCALE’ datatype is coming that allows us to handle real number such as 0.5 in these annoying scales.

  2. Where a numeric is normally associated with the scale (as in Clinical frailty) use a DV_ORDINAL as that number may often be used by UI developers - much easier for them to handle than coded-text. Same applies oto something like +,++, +++ in urinalysis - pseudo numeric but close enough.

  3. Where there is no natural number associated with a valueset , use dv_Coded_TEXT , even though you could assign some sort of weighting to things like mild, moderate , severe. We used to do that in early archetypes but I think it was mistake as the allocation of the number to the code is really very arbitrary.

  4. The tricky ones are something like the NYHA functional classification which has Grade 1 to Grade 4. That might qualify as a pseudo-numeric but I would be worried about somebody adding Grade 4a and Grade 4b.

So I think I would stick closely to using DV_ORDINAL where there are clear associations of a number (not a Grade or Class) to a particular term, with perhaps urinalysis being a bit of an anomoly.

1 Like

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.