It is a scale from 0-10, so would be ideal to express as a DV_ORDINAL but includes 0.5 which makes this impossible.
There are a number of workarounds but is there a case for adding some form of Coded Quantity datatype to openEHR? The primary problem is in representing such constraints in archetypes but there might be some value in simplifying integration from Snomed coded findings.
this has clearly happened because the designers of the scale did not have the term ‘very very slight’ in the beginning, but unfortunately they had already chosen contiguous integers. I have to say, this scale looks quite subjective. I would be amazed to discover that a) the middle terms were being used in the same way across all users or that b) the outcomes would be any worse if a 3 or 5 item scale was used instead. But I am not a doctor, so ignore that comment
Practically speaking, I guess we are in the realm of having to create an ordinal kind of concept to deal with scales with retro-fitted non-integer items. A pragmatic approach might be to add a DV_ORDINAL variant called something like DV_SCALE_VALUE which is the same model as DV_ORDINAL but with the value of Real rather than Integer type.
I am hesitant to enter this discussion, but here goes.
An assessment scale which assigns a numeric score as well as a symbol/term is not an ordinal scale. The symbols do in fact comprise an ordinal scale (“very low” < “low” etc). However the numerics provide something else – usually to be added up with other scores. The designers of such scales are bound to validate the composite numeric scores (cf SF36).
What you then have is ordinal symbol + real number. If the scale designer needs to use decimals, that is their choice.
It might be worth looking at the measurement theory literature.
the openEHR model of ‘ordinals’ (right or not) is that each ordinal value is an association of an integer with a symbol (which could be words, but also anything else like ‘++’). The numbers are used to make the ordering computable - in fact this is the definition of the ‘ordinal’ concept in openEHR - that there is order without otherwise any proper scaled notion of magnitude.
This data type (DV_ORDINAL) is used in at least two ways (wrongly or rightly):
to model scales of symbols, such as ‘none’, ‘+’, ‘++’, ‘+++’ and so on (maybe pain, reaction, urinalysis analytes), where there are otherwise no numerics built into the published scale - i.e. someone had to invent them when creating archetypes or other openEHR artefacts
to model scales whose values are primarily expressed as numerics and whose ‘symbols’ are just words
to model scales of numbers like Apgar and Barthel, where the primary expression of ‘value’ is numeric, and the numbers are meant to be added up, and the ‘symbol’ is in fact a term, i.e. explanatory phrase
doing this has the desired effect in all cases of establishing computable ordering between adjacent members (since computers don’t understand that ‘++’ is somehow ‘less than’ ‘+++’). But it is clear that there are downsides:
in the first case above, it is us (i.e. archetype modellers) adding arbitrary numbers to make the scale of values computable
in the second and third cases, there is no obvious reason why real numbers should not be chosen, especially in the last case above, since the values might be carefully chosen to make the subsequent additions have a certain effect.
At the very least it seems that we need is the ability to use real numbers as well as just integers. Maybe there is more to it - I certainly don’t have a good enough feel for the use of these kinds of scales in medicine, nor their implied semantics. With respect to literature, I have to admit we did not find anything much on ordinal scales, although we tried to stick to well-known notions of accuracy, precision, units etc in the design of the main quantitative data types in openEHR (also proper mathematical notions which lead to meaningful operations, e.g. + and - being defined on true ‘amounts’ but not on dates). If you know of any literature on this topic of scale design, I am sure it would be helpful here.
nominal ‘scale’ - this is not really a scale, but a classification concept, expressed using DV_CODED_TEXT
ordinal scale - DV_ORDINAL
interval scale - this is formalised by the abstract type DV_ABSOLUTE_QUANTITY, whose only current subtypes are DV_DATE, DV_DATE_TIME and DV_TIME. These types don’t have + or - defined in the normal way, although add and subtract operations (different semantics do apply).
ratio scale - this is formalised in the type DV_AMOUNT, which models exactly the concept of quantities with a meaningful 0 point and for which + and - operations are defined. Concrete subtypes are DV_QUANTITY, DV_COUNT, DV_DURATION and DV_PROPORTION.
this article doesn’t seem to mention non integer ‘ordinals’ though…
Ordinals are not just about order. That's certainly a primary use, but for some
specific ordinal scales, specific operations are defined that give
(quasi) meaningful
results when performed upon the numbers. There's no general case, and
additionally,
I think that many of the specific defined operations fail any sort of
rigor test at all.
But never-the-less, they are defined and used in clinical contexts.
That's an additional
reason why the ordinal equivalent in ISO 21090 has a real number for
value, not an
integer. And for this reason, openEHR should probably have a real too.
But I don't
see a path from here to there, as it were
Based on the discussion so far, I would agree. The question probably needs some more analysis, since this is the first scale I have seen at least that breaks the Integer model. If we make it a new change request, we need to think carefully about how to deal with it, since it is possibly a breaking change. I say ‘possibly’ because in mathematical terms it is not; Reals are a more general kind of number than Integers. However, IT systems don’t necessarily know that, so the question of exactly how existing data are represented and whether they will either a) seamlessly keep working if we change DV_ORDINAL to have a Real value or b) only require minor modificaitons to software. For example, if data are physically stored as XML, changing the relevant XSD field should enable the data to remain perfectly valid.
Clearly as more systems are built using openEHR, this kind of change would need to be very rare, but I think if a good impact analysis + implementation guidance is worked out, it could certainly be done now.
I agree – could we make DV_ORDINAL have a real value and allow constraint to integer through precision which would default to 0. This would maintain compatibility and not get too complicated. It is just the reality that things get a little abused.
Hi, sorry was not able to follow discussions on this thread but do you think it would also be a good time to discuss the cases where some custom defined/non included units need to be added for some properties in DV_QUANTITY. You may remember our discussions around 'French' as Gauge unit - which is not allowed currently. Although this may safely be added to terminology I think many more will follow when people really get into niche highly structured clinical modelling.
