CQuantityItem.units not empty
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
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Tuesday, 10 February 2009 1:43 AM
To: For openEHR technical discussions
Subject: Re: CQuantityItem.units not empty
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:
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
_
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Thomas Beale
Chief Technology Officer, Ocean http://www.oceaninformatics.com/
Informatics
Chair Architectural Review Board, http://www.openehr.org/ openEHR
Foundation
Honorary Research Fellow, University College http://www.chime.ucl.ac.uk/
London
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090210/0f4eabfc/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4972 bytes
Desc: not available
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090210/0f4eabfc/attachment.png
CQuantityItem.units not empty
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 at cs.com phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090210/0c326c2f/attachment.html
CQuantityItem.units not empty
Williamtfgoossen at 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 *
CQuantityItem.units not empty
In a message dated 10-2-2009 15:56:17 W. Europe Standard Time, thomas.beale at 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 at cs.com phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090210/ffa52223/attachment.html
CQuantityItem.units not empty
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090210/746042cc/attachment.html
CQuantityItem.units not empty
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)? On Tue, February 10, 2009 12:19 pm, Thomas Beale wrote: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head meta content=text/html;charset=ISO-8859-1 http-equiv=Content-Type /head body bgcolor=#ff text=#00 a class=moz-txt-link-abbreviated href=mailto:Williamtfgoossen at cs.comWilliamtfgoossen at cs.com/a wrote: blockquote cite=mid:d08.4cff1767.36c30534 at cs.com type=citefont face=arial,helveticafont ptsize=10 family=SANSSERIF face=Arial lang=0 size=2br br Thomas,br br Thank you for your reply, however it does not satisfy the request. br br I think that the pain score is indeed not a physical measurable instrument. br 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. br Hence reliability studies have determined that it is useful in practice. br /font/font/blockquote br I certainly didn't mean to imply that things like the pain score were not useful!br br blockquote cite=mid:d08.4cff1767.36c30534 at cs.com type=citefont face=arial,helveticafont ptsize=10 family=SANSSERIF face=Arial lang=0 size=2br However, I would like to have the followingbr br DV_PhysicalQuantity meeting the PQ requirements from ISO 21090br and thebr DV_CodedOrdinal, or DV_Ordinal meeting the requirements for the CO (Coded Ordinal) from ISO 21090. br The CO does allow the order as we need, and allows the mathematical operations such as summations, calculations like BMI style, among others. br br /font/font/blockquote br As far as I can see, the current openEHR data types satisfy your needs (with one exception - see below):br ul liDvQuantity - handles all PQ, including with no units/li liDvOrdinal - handles all ordinals, with any kind of symbols, including from coding systems/li /ul 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?br br 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.br br Would you agree with my understanding of the problem as stated here?br br - thomasbr br /body /html ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CQuantityItem.units not empty
On Tue, Feb 10, 2009 at 02:01:59PM -0500, Greg Harris wrote: 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)? 7 centimeters of pain ? No, that's just a device, a metaphor, basically. It does add a bit of comparability, though. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
CQuantityItem.units not empty
On Tue, February 10, 2009 2:22 pm, Karsten Hilbert wrote: On Tue, Feb 10, 2009 at 02:01:59PM -0500, Greg Harris wrote: 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)? 7 centimeters of pain ? No, that's just a device, a metaphor, basically. It does add a bit of comparability, though. Karsten -- 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.
CQuantityItem.units not empty
In a message dated 10-2-2009 20:10:16 W. Europe Standard Time, glharris at 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 at cs.com phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090210/770afc4c/attachment.html
CQuantityItem.units not empty
Thomas wrote: In a message dated 10-2-2009 18:21:06 W. Europe Standard Time, thomas.beale at 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 at cs.com phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090210/7027d9fd/attachment.html
CQuantityItem.units not empty
Question: Isn't the pain score a COUNT data type? Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at 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 On Feb 10, 2009, at 5:28 PM, Williamtfgoossen at cs.com wrote: 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. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090210/750b8134/attachment.html
