Recently in a training course a students asked if it was possible to define a range constraint for the DV_ORDINAL.value in an archetype.
Currently in the archetype editor and archetype designer it’s only possible to select a single integer value but not a range constraint.
Also based on the current ADL syntax I think it’s only possible to pick a single value, because we have a specific syntax for the ordinal instead of using the normal complex object syntax.
Another student proposed to use many values with the same coded text.
That seems very odd to me - can you tell us what was the use case? The whole point of the ordinal type is that there is a specific value associated with a code.
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?
I think David is correct in terms of use/abuse of the DV_ORDINAL.
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.
DV_SCALE is essentially the same as DV_ORDINAL but allows real numbers. Over time it should probably be used for new scores but there is no need to do any kind of bulk update of DV_ORDINAL.
Let’s keep DV_ORDINAL as is, to allow the representation of comparable values. For that, the integer value is the right option.
And now let’s use DV_SCALE (instead what I proposed of a new DV_SCORE), and use it for everything else, with just two modification:
It should not inherit from DV_ORDERED
Remove the mention to its “implied ordering” from its class description
Then we have two data types for two diferent scopes. And if, as you said, ordered values are not a thing in real life, then the DV_ORDINAL will at some point disappear.
So the only change I would suggest is the following:
Change…
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.
…to…
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…
Hi
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.
It’s specifically not marking the order, it’s marking the numerical value of the associated symbol.