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,
That’s a great reference, thanks. And you are right - this is a real mess!!
So my view FWIW
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.
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.
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.
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.
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
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.
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…
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…
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”?
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.
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.
