# CQuantityItem.units not empty

**URL:** <https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880>\
**Category:** Technical (archive)\
**Created:** [9 February 2009 14:27 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880 "2009-02-09T14:27:15Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tony\_Franca](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/bcef8e/32.png) [@Tony\_Franca](https://discourse.openehr.org/u/Tony_Franca)\
**Post date:** [9 February 2009 14:27 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/1 "2009-02-09T14:27:15Z")

</div>

Hi all.

I´m working in the archetype validation alghoritm of the zilics models (more on this thread → [http://www.openehr.org/mailarchives/ref\_impl\_java/msg00975.html](http://www.openehr.org/mailarchives/ref_impl_java/msg00975.html)).  
I ran into a little problem, and I´d like to hear your thoughts.

The specification for the C\_QUANTITY\_ITEM class states that the “units” field is valid when:  
units\_valid: units /= Void and not units.is\_empty, in other (java) words: units != null && units.size() \> 0

Ocean´s Archetype editor lets you create a Quantity Item as a Qualified real, without any units.  
The ADL it generates for such an item is like:

ELEMENT[at0005] occurrences matches {0..1} matches { – INR  
value matches {  
C\_DV\_QUANTITY \<  
property = \<[openehr::380]\>  
list = \<  
[“1”] = \<  
units = \<“”\>  
magnitude = \<|\>=0.0|\>  
precision = \<|0|\>

> 

}  
}

For such an archetype, validation fails because the parsed Archetype object will have a CQuantityItem object having units = [empty list]

So, which one is wrong? The archetype or the validation alghorithm?  
Should I just avoid creating archetypes with Quantity items with no units?  
If so, should Archetype editor prevent the user from creating such an item?

Cheers!  
Tony Lâmpada

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 February 2009 16:12 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/2 "2009-02-09T16:12:53Z")

</div>

Hi Tony,

I just tested this in the latest ADL workbench, and it passes there as well, because we erroneously don’t check the length of the string, even though we do have the invariant set correctly (but of course it isn’t being executed in production copies of the system) - see [http://www.openehr.org/svn/ref\_impl\_eiffel/BRANCHES/specialisation/libraries/openehr/src/am/openehr\_profile/data\_types/quantity/c\_quantity\_item.e](http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/specialisation/libraries/openehr/src/am/openehr_profile/data_types/quantity/c_quantity_item.e)

I will correct this in the parser. Which archetype did you find this on?

- thomas beale

Tony França wrote:

> **(attachments)**
>
> ![OceanCsmall.png](https://discourse.openehr.org/images/transparent.png)

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [10 February 2009 11:41 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/3 "2009-02-10T11:41:57Z")

</div>

Hi All

We do have some strange history to deal with here that includes reals in HL7 with no units PQ. So we need the ability to have a blank unit. This is a reality and I don’t think the solution is to make that impossible unless there is a clear way forward to deal with labs that do not have units.

Cheers, Sam

> **(attachments)**
>
> ![OceanCsmall.png](https://discourse.openehr.org/images/transparent.png)

---

<div class="post-metadata">

**Author:** ![grahamegrieve](https://discourse.openehr.org/user_avatar/discourse.openehr.org/grahamegrieve/32/3602_2.png) [@grahamegrieve](https://discourse.openehr.org/u/grahamegrieve)\
**Post date:** [10 February 2009 12:06 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/4 "2009-02-10T12:06:26Z")

</div>

hi

Technically, it's not empty, it just has a default unit of unity (i.e.  
a unitless amount). At least this is how it is in HL7. I would've thought  
the same arrangement is appropriate for openEHR

Grahame

Sam Heard wrote:

---

<div class="post-metadata">

**Author:** ![williamtfgoossen](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/w/aca169/32.png) [@williamtfgoossen](https://discourse.openehr.org/u/williamtfgoossen)\
**Post date:** [10 February 2009 12:26 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/5 "2009-02-10T12:26:50Z")

</div>

It should be in OpenEHR in order to handle for instance pain scores that do get a number quantity but has no unit

of course then the question is still if CQuantityItem can hold decimals as well for the VAS score which can be pain = 7.5, or 3.4

Sincerely yours,

dr. William TF Goossen  
director  
Results 4 Care b.v.  
De Stinse 15  
3823 VM Amersfoort  
the Netherlands  
email: [Results4Care@cs.com](mailto:Results4Care@cs.com)  
phone + 31654614458  
fax +3133 2570169  
www.results4care.nl  
Dutch Chamber of Commerce number: 32133713

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [10 February 2009 14:54 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/6 "2009-02-10T14:54:37Z")

</div>

Williamtfgoossen@cs.com wrote:

> It should be in OpenEHR in order to handle for instance pain scores  
> that do get a number quantity but has no unit
> 
> of course then the question is still if CQuantityItem can hold  
> decimals as well for the VAS score which can be pain = 7.5, or 3.4

\*theoretically speaking, such 'quantities' are not true quantities - a  
true quantity is one that states the amount of some physical substance  
or flow, and by definition has units to measure that. Pain and other  
scores are not true quantities, they are just numbers. True quantities  
have the operations +and - defined on them. I doubt that pain scores  
could be meaningfully added for a single individual, let alone across  
individuals.

However ... the current specification allows DV\_QUANTITYs to have an  
empty unit string, which allows for these pseudo quantities that are not  
modelled as Ordinals. We really should not do this. Instead we should  
have an equivalent of DV\_ORDINAL that allows fractional values -  
Ordinals only have ordered, but math operations are not defined on them.  
DV\_SCORE might be an appropriate addition to openEHR.

- thomas beale

---

<div class="post-metadata">

**Author:** ![williamtfgoossen](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/w/aca169/32.png) [@williamtfgoossen](https://discourse.openehr.org/u/williamtfgoossen)\
**Post date:** [10 February 2009 16:28 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/7 "2009-02-10T16:28:36Z")

</div>

In a message dated 10-2-2009 15:56:17 W. Europe Standard Time, [thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com) writes:

> \*theoretically speaking, such ‘quantities’ are not true quantities - a  
> true quantity is one that states the amount of some physical substance  
> or flow, and by definition has units to measure that. Pain and other  
> scores are not true quantities, they are just numbers. True quantities  
> have the operations +and - defined on them. I doubt that pain scores  
> could be meaningfully added for a single individual, let alone across  
> individuals.
> 
> However … the current specification allows DV\_QUANTITYs to have an  
> empty unit string, which allows for these pseudo quantities that are not  
> modelled as Ordinals. We really should not do this. Instead we should  
> have an equivalent of DV\_ORDINAL that allows fractional values -  
> Ordinals only have ordered, but math operations are not defined on them.  
> DV\_SCORE might be an appropriate addition to openEHR.
> 
> - thomas beale
> 
> -

Thomas,

Thank you for your reply, however it does not satisfy the request.

I think that the pain score is indeed not a physical measurable instrument.  
But it is not an Ordinal, in statistical terms it is an Interval if the numeric score is used (0, 1, 2, 3 etc up to 10) and a ratio when the VAS scale is used.  
Hence reliability studies have determined that it is useful in practice.

However, I would like to have the following

DV\_PhysicalQuantity meeting the PQ requirements from ISO 21090  
and the  
DV\_CodedOrdinal, or DV\_Ordinal meeting the requirements for the CO (Coded Ordinal) from ISO 21090.  
The CO does allow the order as we need, and allows the mathematical operations such as summations, calculations like BMI style, among others.

Sincerely yours,

dr. William TF Goossen  
director  
Results 4 Care b.v.  
De Stinse 15  
3823 VM Amersfoort  
the Netherlands  
email: [Results4Care@cs.com](mailto:Results4Care@cs.com)  
phone + 31654614458  
fax +3133 2570169  
www.results4care.nl  
Dutch Chamber of Commerce number: 32133713

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [10 February 2009 17:19 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/8 "2009-02-10T17:19:43Z")

</div>

> Thomas,
> 
> Thank you for your reply, however it does not satisfy the request.
> 
> I think that the pain score is indeed not a physical measurable instrument.  
> But it is not an Ordinal, in statistical terms it is an Interval if the numeric score is used (0, 1, 2, 3 etc up to 10) and a ratio when the VAS scale is used.  
> Hence reliability studies have determined that it is useful in practice.

I certainly didn’t mean to imply that things like the pain score were not useful!

> However, I would like to have the following
> 
> DV\_PhysicalQuantity meeting the PQ requirements from ISO 21090  
> and the  
> DV\_CodedOrdinal, or DV\_Ordinal meeting the requirements for the CO (Coded Ordinal) from ISO 21090.  
> The CO does allow the order as we need, and allows the mathematical operations such as summations, calculations like BMI style, among others.

As far as I can see, the current openEHR data types satisfy your needs (with one exception - see below):

- DvQuantity - handles all PQ, including with no units
- DvOrdinal - handles all ordinals, with any kind of symbols, including from coding systems  
I don’t understand the need for summations etc for ordinals, because the general nature of ordinal values is that that symbolically identify arbitrary ranges in a value space (e.g. amount of pain, amount of protein in urine etc). Mathematically they don’t satisfy the requirements to be summable. Can you explain further the intended semantics here?

The exception is that neither of the above types handles a non-integral ‘ordinal’ idea. Hence my proposal of DV\_SCORE. There are probably better solutions, I have not thought much about it. I do think however, that any solution needs to be mathematically sound, because downstream data computing relies on that.

Would you agree with my understanding of the problem as stated here?

- thomas

---

<div class="post-metadata">

**Author:** ![Tony\_Franca](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/bcef8e/32.png) [@Tony\_Franca](https://discourse.openehr.org/u/Tony_Franca)\
**Post date:** [10 February 2009 17:20 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/9 "2009-02-10T17:20:06Z")

</div>

Wow, never thought this could be a polemic issue.

Anyway, Thomas, the archetype I found this was this one:  
[https://svn.connectingforhealth.nhs.uk/svn/public/nhscontentmodels/TESTING/TestRelease03/archetypes/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.Coagulation\_studies.v1.adl](https://svn.connectingforhealth.nhs.uk/svn/public/nhscontentmodels/TESTING/TestRelease03/archetypes/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.Coagulation_studies.v1.adl)

Cheers  
Tony

> **(attachments)**
>
> ![OceanCsmall.png](https://discourse.openehr.org/images/transparent.png)

---

<div class="post-metadata">

**Author:** ![Greg\_Harris](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/g/5fc32e/32.png) [@Greg\_Harris](https://discourse.openehr.org/u/Greg_Harris)\
**Post date:** [10 February 2009 19:01 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/10 "2009-02-10T19:01:59Z")

</div>

Not that it's dispositive of any larger issue, but doesn't VAS  
actually record a physical quantity (specifically, the centimeter  
position on the horizontal line where the patient indicates the level  
of pain)?

---

<div class="post-metadata">

**Author:** ![Karsten\_Hilbert](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/k/e56c9b/32.png) [@Karsten\_Hilbert](https://discourse.openehr.org/u/Karsten_Hilbert)\
**Post date:** [10 February 2009 19:22 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/11 "2009-02-10T19:22:03Z")

</div>

7 centimeters of pain ? No, that's just a device, a  
metaphor, basically. It does add a bit of comparability,  
though.

Karsten

---

<div class="post-metadata">

**Author:** ![Greg\_Harris](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/g/5fc32e/32.png) [@Greg\_Harris](https://discourse.openehr.org/u/Greg_Harris)\
**Post date:** [10 February 2009 19:56 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/12 "2009-02-10T19:56:07Z")

</div>

The VAS is not a direct measurement of "pain." It is a direct  
measurement of where, on a 10 cm. line, the patient records her  
impression of her pain severity. So a reported VAS of 6.5 is a record  
that the mark the patient drew was located at 6.5 cm from the left  
endpoint of the pre-printed form.

There are other assessments of pain that attempt a more direct  
numerical measure of the pain itself. See, e.g.,  
[http://www.ispub.com/ostia/index.php?xmlFilePath=journals/ija/vol8n1/vrs.xml](http://www.ispub.com/ostia/index.php?xmlFilePath=journals/ija/vol8n1/vrs.xml).

But this is only a trivial point that doesn't really affect the  
discussion. Sorry for the distraction.

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [10 February 2009 20:16 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/13 "2009-02-10T20:16:33Z")

</div>

Question:

Isn’t the pain score a COUNT data type?

Gerard

– –  
Gerard Freriks, MD  
Huigsloterdijk 378  
2158 LR Buitenkaag  
The Netherlands

T: +31 252544896  
M: +31 620347088  
E: [gfrer@luna.nl](mailto:gfrer@luna.nl)

Those who would give up essential Liberty, to purchase a little temporary  
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

<div class="post-metadata">

**Author:** ![williamtfgoossen](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/w/aca169/32.png) [@williamtfgoossen](https://discourse.openehr.org/u/williamtfgoossen)\
**Post date:** [10 February 2009 21:38 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/14 "2009-02-10T21:38:30Z")

</div>

In a message dated 10-2-2009 20:10:16 W. Europe Standard Time, [glharris@panix.com](mailto:glharris@panix.com) writes:

> Not that it’s dispositive of any larger issue, but doesn’t VAS  
> actually record a physical quantity (specifically, the centimeter  
> position on the horizontal line where the patient indicates the level  
> of pain)?

Yes that is correct and Thomas’reply that it can be handled in DvQuantity as PQ without Units satisfies this need.

Sincerely yours,

dr. William TF Goossen  
director  
Results 4 Care b.v.  
De Stinse 15  
3823 VM Amersfoort  
the Netherlands  
email: [Results4Care@cs.com](mailto:Results4Care@cs.com)  
phone + 31654614458  
fax +3133 2570169  
www.results4care.nl  
Dutch Chamber of Commerce number: 32133713

---

<div class="post-metadata">

**Author:** ![williamtfgoossen](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/w/aca169/32.png) [@williamtfgoossen](https://discourse.openehr.org/u/williamtfgoossen)\
**Post date:** [10 February 2009 21:57 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/15 "2009-02-10T21:57:11Z")

</div>

Thomas wrote:

In a message dated 10-2-2009 18:21:06 W. Europe Standard Time, [thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com) writes:

> As far as I can see, the current openEHR data types satisfy your needs (with one exception - see below):
> 
> DvQuantity - handles all PQ, including with no units  
> DvOrdinal - handles all ordinals, with any kind of symbols, including from coding systems I don’t understand the need for summations etc for ordinals, because the general nature of ordinal values is that that symbolically identify arbitrary ranges in a value space (e.g. amount of pain, amount of protein in urine etc). Mathematically they don’t satisfy the requirements to be summable. Can you explain further the intended semantics here?

William: That is perfect and will help deal with the VAS and numeric and base ordinal.

> The exception is that neither of the above types handles a non-integral ‘ordinal’ idea. Hence my proposal of DV\_SCORE. There are probably better solutions, I have not thought much about it. I do think however, that any solution needs to be mathematically sound, because downstream data computing relies on that.

The mathematical requirement of summation is a clinical necessary feature for about a 1000 to 10.000 assessment scales used in a variety of clinical domains.  
The generic feature is that an ordinal scale is used as a value for a variable, so per node the value can be e.g. 0 = no problem, 1 = some problem and 2 = severe problem  
the semantics is clear and indeed an ordinal scaling.  
However, ususally assessment instruments / scales / indexes of scores consist of more than one variable. E.g. Apgar score has 5 variables, with a minimum score (worst case) = 0 and a maximum score (best case) = 10.  
Similar scales include Barthel, Glasgow coma scale, Braden etc.

So the summation as mathematical approach is as follows (using the following explanation to the scores: 0 = no problem, 1 = some problem and 2 = severe problem).

variable 1, score = 1  
variable 2, score = 0  
variable 3, score = 2  
variable 4 score = 1  
variable 5 score = 0  
variable 6, score is 0

Total score on the instrument is score variable 1 + score variable 2 + score variable 3 + score variable 4 + score variable 5 + score variable 6 =  
1 + 0 + 2 + 1 + 0 + 0 = 4.

This is usually viewed agains scientifically derived reference ranges, e.g. 4 out of 12 (maximum for 6 variables is

So for appropriate scales / indexes etc the mathematics need to be possible on the ordinal values.

See for a discussion on these features e.g.

**[White TM](http://www.ncbi.nlm.nih.gov/sites/entrez?Db=pubmed&Cmd=Search&Term=%22White%20TM%22%5BAuthor%5D&itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_DiscoveryPanel.Pubmed_RVAbstractPlus)**, **[Hauan MJ](http://www.ncbi.nlm.nih.gov/sites/entrez?Db=pubmed&Cmd=Search&Term=%22Hauan%20MJ%22%5BAuthor%5D&itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_DiscoveryPanel.Pubmed_RVAbstractPlus)**. **Extending the LOINC conceptual schema to support standardized assessment instruments.** J Am Med Inform Assoc. 2002 Nov-Dec;9(6):586-99.

> Would you agree with my understanding of the problem as stated here?
> 
> - thomas

Sincerely yours,

dr. William TF Goossen  
director  
Results 4 Care b.v.  
De Stinse 15  
3823 VM Amersfoort  
the Netherlands  
email: [Results4Care@cs.com](mailto:Results4Care@cs.com)  
phone + 31654614458  
fax +3133 2570169  
www.results4care.nl  
Dutch Chamber of Commerce number: 32133713

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [12 February 2009 07:59 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/16 "2009-02-12T07:59:19Z")

</div>

Hi William

We can do maths on Ordinals as long as their symbols are numeric. This is set in the archetype rather than the reference model. You will know from Bathel and Apgar that we do this.

Cheers, Sam

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [12 February 2009 08:01 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/17 "2009-02-12T08:01:10Z")

</div>

Hi All

It is possible to use the proportion with the numerator of 1 to express continuous reals from 0…n

It is how we say that someone has had 5.1 lots of something, or fractions.

Cheers, Sam

---

<div class="post-metadata">

**Author:** ![Tony\_Franca](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/bcef8e/32.png) [@Tony\_Franca](https://discourse.openehr.org/u/Tony_Franca)\
**Post date:** [20 February 2009 14:29 UTC](https://discourse.openehr.org/t/cquantityitem-units-not-empty/14880/18 "2009-02-20T14:29:31Z")

</div>

Ok guys, sorry, I´m a little confused as to what is the result here.  
Thomas, could you kindly clear it out for me?

The spec says:

invariant  
units\_valid: units /= Void and not units.is\_empty

But you also said  
“However … the current specification allows DV\_QUANTITYs to have an  
empty unit string”

I just want my archetype validator to follow the specs, so I´m guessing, it should really consider [units=“”] as IN-valid, right?

Cheers  
Tony