In cardiology, left ventricular mass (LVM) is often indexed to better identify left ventricular hypertrophy.
Possible indexations are:
- LVM/BSA (body surface area)
- LVM/height
- LVM/height^2.7
The first and the latter are often used.
The units of measurement of the latter is usually g/m2.7 [gram/(meter^2.7)].
In DV_QUANTITY, “units” attribute should be expressed in UCUM unit syntax. UCUM doesn’t allow not integer exponent (see http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules), so I have the problem that I cannot express the units as g/m2.7.
Any suggestion to solve this problem!?
Best regards
leo
hi Leo
I have forwarded this question onto the UCUM wizard (Gunther Schadow).
It's a pretty good question. Simply allowing the decimal would make the
syntax ambiguous, but there's no easy way to do it any other way.
Grahame
Hi Leo
Can you please provide some references to show the use of height^2.7?
Grahame
Hi
there are a lots of scientific publications treating the indexations of left
ventricular mass (LVM).
I can link some abstracts, but the whole PDF documents are not public:
- http://www.nature.com/jhh/journal/v23/n11/full/jhh200916a.html
- http://www.ncbi.nlm.nih.gov/pubmed/11729247
or here
https://www.stanford.edu/group/ccm_echocardio/cgi-bin/mediawiki/index.php/Left_ventricle_wall_thickness
It can be used to detect left ventricular hypertrophy.
You can google "mass/height^2.7" to find more references.
Thanks for your help.
leo
Grahame Grieve-3 wrote:
There's some question about whether such a funky unit is
a proper unit. It does look rather like a statistical imagination
to me, rather than an actual unit.
I'm not sure where the right place to discuss this is. I'll let
you know when I find out.
Grahame
Hi Leo
Gunther says that these units are not proper units.
http://www.xkaw.com/Education_Reference/Science_Mathematics.asp?id=2276318
There's a possible question of scope alignment here. It's kind of tantamount to
saying that a measure like that is not a proper measurement. I don't think
I agree with that.
To pursue the UCUM issue, you need to make at ticket at
http://www.unitsofmeasure.org/
I think that there's a tension here between the notion of purity from UCUMs
point of view, and the use of UCUM in the measurement data types (PQ in
HL7 v3 and DV_QUANTITY in openEHR - both have the same scope and the
same usage of UCUM)
Also see http://www.unitsofmeasure.org/wiki/ProcedureDefinedUnits
Grahame
it is a pretty weird unit, since it is partway between 2-d and 3-d space, and therefore partway between the concept of ‘area’ and that of ‘volume’. So whether it is acceptable depends on whether we think that such concepts are meaningful in the activity we call ‘measurement’ in the physical world. Probably there are weird units like this in quantum mechanics, or other esoteric mathematical spaces, so then it comes down to scope of UCUM - presumably not all of science, just physical measurement?
Changing openEHR or HL7 to handle it probably would not be hard, but it might open up a can of worms, and also just plain annoyances, by allowing fractional dimensions (i.e. as soon as you start using floating point numbers for values that are almost always integers, computers struggle to get it right…).
Hi Tom
It's a strange concept for sure. The real question here is whether
UCUM and PQ/DV_QUANTITY are for real measurements, or
whether they for quantitative notions.
There's general agreement that things like "tablet" etc are not
UCUM units - because they're not quantitative. Now we have a different
issue - these are quantitative, but not real.
I can see the grounds for keeping them out of UCUM. In
addition, I'd have to recode my ucum library for this, and
it's an odd challenge for such a strange notion.
On the other hand, why not let scientists how measure things
measure them how they want, as long as the units are meaningful
- to them.
Grahame
I think that we at least need to find out what the physical basis of this unit is. I could not find any definitive reference online, only papers reporting its use. Any cardiologists here?
This kind of scenario is very common and we need to establish some guidelines and governance about how to handle these sort of ‘pseudo-units’, so that vendors can get on with some kind of implementation while these sort of difficult and obscure issues are discussed.
Am I correct in thinking that since ‘units’ is a string, there is no particular barrier to the use of a non-UCUM term?
We obviously want to enforce UCUM use where-ever possible but this will not always be sensible or possible and we need to give developers alternatives (perhaps temporary) and a clear change request mechanism.
e.g. As alternatives
- Use the pseudo-unit in the unit attribute, as a qualified real
- Use a qualified real and keep the name of the unit in the element name ‘LV function factor (m2/kg3/m)’ or whatever.
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
+44 (0)2032 392 970
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org
'...twopointseven', or ask the cardiologists to give the unit a name. "heartz"?
Regards,
Colin
Hi all,
I thought a lot on your proposal.
If we want to use pseudo-units (non-UCUM terms), then we have to be able to
distinguish when a term is in UCUM syntax. For example g/m2.7 is a valid
UCUM string, but it is interpreted as (g/m^2) * 7 and not as g/(m^2.7),
because in UCUM “.” is the symbol for multiplication operator.
So “units” attribute should become a sort of code phrase, with the
information on adopted syntax. Otherwise we can have an ambiguous syntax.
As alternative, if we want to go on using only UCUM syntax, we could express
this pseudo-unit (and not standard units) with the so-called annotation,
wrapped in curly braces (see
http://aurora.regenstrief.org/~ucum/ucum.html#section-Character-Set-and-Lexical-Rules,
section 6). In this case, we can adopt {g/m2.7} safely, remaining compliant
with the UCUM syntax.
What do you think!?
Regards,
Leonardo
Ian McNicoll-3 wrote:
Hi all,
I thought a lot on your proposal.
If we want to use pseudo-units (non-UCUM terms), then we have to be able to
distinguish when a term is in UCUM syntax. For example g/m2.7 is a valid
UCUM string, but it is interpreted as (g/m^2) * 7 and not as g/(m^2.7),
because in UCUM “.” is the symbol for multiplication operator.
So “units” attribute should become a sort of code phrase, with the
information on adopted syntax. Otherwise we can have an ambiguous syntax.
I am surprised that precedence does not force the reading of the full
number following a '^', or a unit like 'm' when the '^' is inferred. I
will have to look at my own UCUM parser to see what it does!
As alternative, if we want to go on using only UCUM syntax, we could express
this pseudo-unit (and not standard units) with the so-called annotation,
wrapped in curly braces (see
http://aurora.regenstrief.org/~ucum/ucum.html#section-Character-Set-and-Lexical-Rules,
section 6). In this case, we can adopt {g/m2.7} safely, remaining compliant
with the UCUM syntax.
I actually think that is a good idea. Have you looked for a mailing list
or place in HL7 where you can make that proposal?
- thomas beale
Hmm, haven't had a chance to read the full thread but does this mean I can also represent Gauge as a Quantity unit (which is not part of openEHR terminology) similarly?
Cheers,
-koray
In UCUM, the period '.' is only used as a multiplication operator, thus “2.7”
means always 2 × 7 and is not equal to 27/10.
The use of curly brace is already part of UCUM systax, so it would be
already compliant with it.
I haven't yet found any mailing list in HL7 which deals with this aspect..
Regards,
leonardo
Thomas Beale-3 wrote:
it'd be either Orders and Observations or Modeling and Methodology.
I don't think that your proposed solution is valid. It meets the
syntactical requirements while making a mess of any semantic
meaning.
Grahame
well… ok, but {} in UCUM is for things whose syntax doesn’t make proper sense… if we can make sense of it in the non-{} part of UCUM, how do is it done? Everything unit has to either fit into the regular part of UCUM or else the {} ‘escape hatch’ doesn’t it?
I don't think that your proposed solution is valid. It meets the
syntactical requirements while making a mess of any semantic
meaning.
well... ok, but {} in UCUM is for things whose syntax doesn't make proper
sense
From UCUM:
"Annotations do not contribute to the semantics of the unit but are
meaningless by definition. Therefore, any fully conformant parser
must discard all annotations. Parsers of limited conformace should
not value annotations in comparison of unit"
so If I say that the unit really is g/m^2.7, but because of
UCUM limitations I say the unit is g/m{^2.7}, I'm actually
now making a false claim. (And only secret knowledge, along
with a non-conformant parser, will allow it to be made right
again).
As I said, the proper way to do this is to open a ticket.
There's a related one:
http://www.unitsofmeasure.org/ticket/51
But i don't think that this is expressed the way we would
want to express this one, which would be somewhere
along the lines of
* ucum is normatively used by HL7 v3 and others
for representing units
* a community are using the unit x (can't recall the original)
* in the health record, we need to record these units
* so how are we supposed to do this?
* UCUMs scope is "intended to include all units of measures
being contemporarily used in international science, engineering,
and business", and these units clearly comply with this scope
* a harmless way to extend the syntax to support this notion
would be to use "," a la european usage
Grahame