# ??? DV_CODEDQUANTITY
**Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153)
**Created:** 2010-04-20 11:35 UTC
**Views:** 2
**Replies:** 15
**URL:** https://discourse.openehr.org/t/dv-codedquantity/14979
---
## Post #1 by @ian.mcnicoll
Assessment scales provide a rich seam of frustration for developers, with their seemingly limitless capacity for arbitrary scales and quantities.
Here is a current example about which I have been asked for advice - the Borgscale ([http://www.ac6v.com/karlaz2.htm](http://www.ac6v.com/karlaz2.htm)).
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.
>
**SCALE**
|
**SEVERITY**
|
> - | - |
>
0
|
No Breathlessness* At All
|
>
0.5
|
Very Very Slight (Just Noticeable)
|
>
1
|
Very Slight
|
>
2
|
Slight Breathlessness
|
>
3
|
Moderate
|
>
4
|
Some What Severe
|
>
5
|
Severe Breathlessness
|
>
6
|
|
>
7
|
Very Severe Breathlessness
|
>
8
|
|
>
9
|
Very Very Severe (Almost Maximum)
|
>
10
|
Maximum
|
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
[ian.mcnicoll@oceaninformatics.com](mailto:ian.mcnicoll@oceaninformatics.com)
[ian@mcmi.co.uk](mailto:ian@mcmi.co.uk)
Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group [www.phcsg.org](http://www.phcsg.org) / BCS Health Scotland
---
## Post #2 by @thomas.beale
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.
- thomas beale
---
## Post #3 by @Mark_Leaning
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.
Cheers
Mark
Mark S Leaning PhD
---
## Post #4 by @thomas.beale
Hi Mark,
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):
1. 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
1. to model scales whose values are primarily expressed as numerics and whose 'symbols' are just words
1. 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.
- thomas
---
## Post #5 by @system
Thanks Mark
Any seminal papers you can point to?
Cheers, Sam
---
## Post #6 by @Mark_Leaning
This has an overview and pointers to other work:
ftp://ftp.sas.com/pub/neural/measurement.html
Some of the core measurement theory is rather mathematical – names to look out for are RD Luce, P Suppes.
This Wikipedia article is not bad: [http://en.wikipedia.org/wiki/Level_of_measurement](http://en.wikipedia.org/wiki/Level_of_measurement)
Mark
Mark S Leaning PhD
Mob: +44 7552 747389
---
## Post #7 by @thomas.beale
The wiki one is interesting. Correspondences with openEHR (see information model at [http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109599337877_94556_1510Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109599337877_94556_1510Report.html)):
- 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...
- thomas
---
## Post #8 by @Daniel_Karlsson
Dear Everyone,
here is a nice 1946 paper on this:
http://web.duke.edu/philosophy/bio/Papers/Stevens_Measurement.pdf
/Daniel
Thomas Beale skrev:
---
## Post #9 by @grahamegrieve
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
Grahame
---
## Post #10 by @Mark_Leaning
Tom:
The suggestion of making the numeric attribute real as opposed to integer seems to me a pragmatic approach.
Cheers
Mark
Mark S Leaning PhD
---
## Post #11 by @thomas.beale
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 am interested in any arguments against it...
- thomas
[details="(attachments)"]
[/details]
---
## Post #12 by @system
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.
Cheers, Sam
---
## Post #13 by @system
Hi all,
I like Sam's proposal\. It is exactly how DV\_QUANTITY works today\.
Cheers,
Rong
---
## Post #14 by @thomas.beale
Sam,
can you please add a PR to the issue tracker at
http://www.openehr.org/issues/browse/SPECPR
thanks
\- thomas
---
## Post #15 by @system
Will do when I get home, Sam
Sam Heard via Blackberry
CEO
Ocean Informatics
\+61417838808
---
## Post #16 by @Koray_Atalag
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\.
Cheers from beautiful New Zeland,
\-koray
---
**Canonical:** https://discourse.openehr.org/t/dv-codedquantity/14979
**Original content:** https://discourse.openehr.org/t/dv-codedquantity/14979