I think @damoca is not claiming that it is being used wrongly as such, just that the type is described wrongly in the RM if it is to be used for scores. Let’s imagine it were called ‘DV_SCORE’ and the documentation improved, then it would be OK.
So what is missing is a type whose purpose is for scales, like pain scales - a DV_SCALE type, and in an archetype using this type, more than one item could have the same numeric value (or equivalently, they could have overlapping ranges), whereas in a DV_SCORE archetype, the values all have to be unique, and also can’t be ranges.
Exactly, of course I have nothing to say about the clinical use case
My initial comment was just about coherence around the data type name and definition in the RM.
By definition, an ordinal is:
In set theory, an ordinal number, or ordinal, is a generalization of ordinal numerals (first, second, nth, etc.) aimed to extend enumeration (a complete, ordered listing of all the items in a collection) to infinite sets.
That’s why I insist in the order as a innate property of something called DV_ORDINAL. I think that anyone new to openEHR would expect that, and could be confused seeing how it is used in archetypes.
Do we really need two data types for this? Or change anything at all, now that we do have the DV_SCALE data type which allows decimal numbers?
As far as I know, and which I suspect was @bna 's point above, there is no clinical use case for a data type where there’s an explicitly declared order of values, but where the numerical values can’t be used for calculations and/or graphing.
The DV_ORDINAL data type is structurally a great match for the actual use case (apart from the edge case with decimal numbers which is fixed by DV_SCALE), and has been used extensively in implementations and archetypes.
