# Range containers in ordinals **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2023-12-03 16:24 UTC **Views:** 567 **Replies:** 22 **URL:** https://discourse.openehr.org/t/range-containers-in-ordinals/4732 --- ## Post #1 by @pablo 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. What do modelers think about this? Thanks! --- ## Post #2 by @ian.mcnicoll 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. --- ## Post #3 by @bna I am very curious about the use-case to think more about the modelling approach. There are many ways to achieve such things: - Let the ELEMENT have as many occurences as there are ordinals and let the user choose the one that fit - Model as an `DV_INTERVAL` - Archetype the lower and upper ordinal for the range (one element for each) --- ## Post #4 by @damoca 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: 1. Add a "meaning" DV_CODED_TEXT attribute to the DV_COUNT data type, so we can represent pairs of without implied ordering. 2. Create a new DV_SCORE data type, which would be very similar to the DV_ORDINAL in its structure, but with different semantics. 3. 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: ![image|690x139](upload://d5oK6c9dbRkufUTonv765hdhf4T.png) 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? --- ## Post #5 by @pablo 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 ? --- ## Post #6 by @siljelb 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. --- ## Post #7 by @ian.mcnicoll Completely agree Silje. 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. [quote="pablo, post:5, topic:4732"] 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 [/quote] 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. --- ## Post #8 by @pablo 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. Did I interpret you correctly? --- ## Post #9 by @pablo [quote="ian.mcnicoll, post:7, topic:4732"] 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. [/quote] Maybe @damoca can expand on that? --- ## Post #10 by @ian.mcnicoll 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. --- ## Post #11 by @damoca [quote="ian.mcnicoll, post:7, topic:4732"] 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. [/quote] That's true, the specification does not explicitly say what the value IS NOT, but at least it says what IT IS ![image|690x32](upload://pGAhtu4tVZQv690sV2KGdfzDxx1.png) Maybe the problem is about the name of the class itself, DV_ORDINAL implies an order. --- ## Post #12 by @damoca DV_SCALE could be the answer to this discussion. 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. --- ## Post #13 by @siljelb I'd rather suggest to update the description of DV_ORDINAL to reflect the actual use case and use in published archetypes. --- ## Post #14 by @pablo @siljelb would you suggest an improved description? We can use that to raise a ticket to be able to modify the spec :) --- ## Post #15 by @siljelb I had a look at the specs, and I think the current definition covers the use case pretty well: [https://specifications.openehr.org/releases/RM/latest/data_types.html#_dv_ordinal_class](https://specifications.openehr.org/releases/RM/latest/data_types.html#_dv_ordinal_class) The ordering part is fine (there usually is an implied order), but the order isn't implied by the numerical values. Example from the [NEWS2 archetype](https://ckm.openehr.org/ckm/archetypes/1013.1.3342): ![image|690x215](upload://d2weBFIXfBtBGbIcyDavgtd4d9z.png) 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. --- ## Post #16 by @pablo That's curious, is that correct to have two "3" values with different code meanings? It seems the "3" is implying some meaning too instead of just marking an order of the associated codes. --- ## Post #17 by @siljelb [quote="pablo, post:16, topic:4732"] It seems the “3” is implying some meaning too instead of just marking an order of the associated codes. [/quote] 🎯 It's specifically *not* marking the order, it's marking the numerical value of the associated symbol. --- ## Post #18 by @thomas.beale [quote="damoca, post:4, topic:4732"] 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: [/quote] 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.... Do I have this right? --- ## Post #19 by @bna 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](https://ckm.openehr.org/ckm/archetypes/1013.1.4866) 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](https://ckm.openehr.org/ckm/archetypes/1013.1.3342). 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. --- ## Post #20 by @siljelb [quote="bna, post:19, topic:4732"] If yes: I would like to see a few real life examples which illustrates the correct usage of `DV_ORDINAL`. [/quote] I second this ☝️ --- ## Post #21 by @thomas.beale 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. At least that's what I understood from the above. --- ## Post #22 by @damoca Exactly, of course I have nothing to say about the clinical use case :sweat_smile: 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. --- ## Post #23 by @siljelb [quote="thomas.beale, post:21, topic:4732"] 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. [/quote] 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. --- **Canonical:** https://discourse.openehr.org/t/range-containers-in-ordinals/4732 **Original content:** https://discourse.openehr.org/t/range-containers-in-ordinals/4732