Let me rephrase you @ian.mcnicoll : The whole point of the ordinal type is to allow ordering coded texts by assigning to them a specific comparable value.
This is a very common misunderstanding of this data type. What it represents are coded texts, the integer value is just a helper for ordering, without any meaning. Thus, the value should be unique for each symbol. Using a range for them should not be an accepted modeling practice (although in pure and canonical ADL it is technically possible).
An now just some thoughts…
My feeling is that the DV_ORDINAL is often incorrectly used as a score (let me use that word, although maybe is not the exact one), as it is the only one that correlates a value and a symbol. Probably what we really need is one of these:
Add a “meaning” DV_CODED_TEXT attribute to the DV_COUNT data type, so we can represent pairs of <value,meaning> without implied ordering.
Create a new DV_SCORE data type, which would be very similar to the DV_ORDINAL in its structure, but with different semantics.
Rethink the modeling pattern for scores. If we look at the CKM most scores are in fact falling in this abuse of the DV_ORDINAL:
It is an abuse not because we cannot assign a score of 2 to a 92-93 range, but because that 2 is used as a score to sum a total result, while it just should have ordering purposes.
I recall that this has been discussed in the past, how to represent a wide range, for example from 1 to 10, if that value was to be used as the score to be added to the total? Should I have an ordinal for 1, another for 2, etc.? And what if it were real numbers instead of integers?
I’m not a modeler, so I prefer to stop here and ask. Am I in the right track? Or am I creating a problem where it doesn’t exist?
Note this question came in a training course, so there is no use case behind, just a discussion about the possibilities of the data type. IIRC this question came after I modeled the severity of a health problem as a DV_ORDINAL after realizing the codes had an underlying order and originally modeling the severity just as a DV_CODED_TEXT.
By current patterns it seems we are modeling the range of values inside the symbol: DV_CODED_TEXT instead of the value: Integer of the DV_ORDINAL, like @damoca mentions.
I also like the idea of having a specific data type that can carry numeric meaning and coded meaning at the same time, and that we can define C_INTEGER constraints over the numeric meaning. What do you think @ian.mcnicoll@siljelb@bna ?
It’s all well and good to say that the current use of DV_ORDINAL is “abusing” its original intended use. But the facts of clinical modelling is that associating a number with a symbol is a very common use case, and an explicitly ordered list of coded texts is not. In fact, I can’t recall a single instance where we’ve needed that way of using a DV_ORDINAL.
There’s already a DV_SCALE data type which was created as an alternative to DV_ORDINAL mainly to allow real numbers and not just integers.
Perhaps the original intent and the reality of use are somewhat different, but I certainly cannot see anything in the spec which says that the integer values have no meaning other than to order the list of codes.
That is exactly the use of DV_ORDINAL right now. Like Silje I am not aware of any use to ‘order’ Coded texts, other than in very early archetypes. I would actually not ‘order’ codes like severity using an ordinal - that just leaves you with a problem if you have to add intermediate codes, and it also implies a ‘strength’ of severity that is not really the case.
Thanks @siljelb considering what you said, DV_SCALE is actually explicitly ordering a list of coded texts, as DV_ORDINAL, it just allows the value to be Real. So it seems a DV_SCORE type like David proposed might be a better fit for clinical modeling than DV_ORDINAL and DV_SCALE.
So the only change I would suggest is the following:
a) implied ordering, b) no implication that the distance between each value is constant, and c) the total number of values is finite; d) integer values only.
a) implied ordering, b) no implication that the order is the same as the natural order of the numerical values, c) no implication that the distance between each numerical value is constant, d) the total number of values is finite, and e) integer values only.
Excellent analysis - you have just sorted out something that has been bugging me for a long time, but I never worked out why.
To summarise (including later comments further down), you think that:
DV_ORDINAL should only be used for purely ordered things, like pain levels, that are never summed. For that, the ordinals in a scale have to be unique (otherwise you can 't order them…)
DV_SCORE should be created to represent summable values, like Apgar and so on, where the numeric values have meaning, not just as a pure ordering mechanism. Ordering as such is not required. Theoretically, more than one alternative could have the same numeric value.
DV_ORDINAL would inherit (as now) from DV_ORDERED but I think DV_SCORE would still inherit from DV_ORDERED as well, since anything with numbers as part of the value is ‘partially orderable’ i.e. things with the same numeric values could occur in different orders in the total list of possibilities.
DV_ORDINAL could be theoretically renamed to DV_SCALE (or maybe DV_RANK), if we agree that
a ‘scale’ (or ‘ranking’) is an ordered set of values for recording things like level of pain, scale of infection, …? So this is a kind of observation value, similar to a coded term, but with an added numeric value
a ‘score’ is a tool for generating a summed total that is (usually) used as a triage mechanism to classify patients.
I’m not saying we would really do this, since there are numerous archetypes with DV_ORDINAL in them.
According to such logic, @siljelb 's examples (and most current DV_ORDINALs) would actually be DV_SCOREs not DV_ORDINALs…
This has been a “mind blowing thread” on DV_ORDINAL in clinical models.
I have to this day been completely safe on the assumption that DV_ORDINAL is the perfect match for integer components in a summarized score.
The specification states that DV_ORDINAL is “a data type that represents integral score values, e.g. pain, Apgar values, etc”. The Apgar archetype is currently in v2 and we see an extensive use of DV_ORDINAL to define labeled integers for each element/component. Do you, @damoca and @thomas.beale , saying that this is an example where DV_ORDINAL is misued?
If yes: I would like to see a few real life examples which illustrates the correct usage of DV_ORDINAL.
A side note:
Based on the thread and a re-visit of the specification I have been thinking about the NEWS2 archetype. Here we have a DV_ORDINAL where multiple items have the same ordinal but with different labels. This use of DV_ORDINAL can be discussed since there are no implied ordering of the items when more than one item have the same ordered value/integer.
Maybe NEWS2 is an example which push the limits on how to use DV_ORDINAL? And if so: What would be the best/correct way to model it?
Just to be clear: I think NEWS2 is modelled the best possible way as it is. The notes above is just to open a discussion to learn and perhaps make even better models in the future and maybe even add more DATA_VALUEs to the RM.