CQuantityItem.units not empty

Technical (archive)
1

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).
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

2

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

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

  • thomas beale

Tony França wrote:

(attachments)

OceanCsmall.png

3

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

4

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:

5

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
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

6

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

7

In a message dated 10-2-2009 15:56:17 W. Europe Standard Time, 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
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

8

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
9

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

Cheers
Tony

(attachments)

OceanCsmall.png

10

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)?

11

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

Karsten

12

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.

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

13

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

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

14

In a message dated 10-2-2009 20:10:16 W. Europe Standard Time, 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
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

15

Thomas wrote:

In a message dated 10-2-2009 18:21:06 W. Europe Standard Time, 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, Hauan MJ. 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
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

16

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

17

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

18

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