Re: UCUM/SNOMED/custom units

escriptions (which >> could be language dependent), etc. This could be very useful for better >> describing custom UCUM units too. >> Several alternatives are being explored in order to not break current >> units definitions. Maybe adding an optional codephrase or terminology >

Re: UCUM/SNOMED/custom units

On 23-07-18 13:45, Diego Boscá wrote: Units need to be (and will be) revamped, we also need other things already discussed in other posts like rubric, long descriptions (which could be language dependent), etc. This could be very useful for better describing custom UCUM units too. Several

Re: UCUM/SNOMED/custom units

Units need to be (and will be) revamped, we also need other things already discussed in other posts like rubric, long descriptions (which could be language dependent), etc. This could be very useful for better describing custom UCUM units too. Several alternatives are being explored in order

UCUM/SNOMED/custom units

I wonder if it is possible to use other units then UCUM units in DV_QUANTITY. I read from Pablo in Stackoverflow that the SEC is considering custom units. I think this is great, but I see some problems coming up. I have some questions about this, I wonder how you can do that without changing

Re: UCUM

Hi, I received a message from Nictiz, in the end they were surprised as we were, that the UCUM website was not hosted professionally. UCUM is regarded as a very important standard in the Netherlands. They are discussing the case with Daniel Freeman from Regenstrief, and seeing

Re: UCUM

ground for UCUM. Bert ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM

On 20-11-17 11:26, Thomas Beale wrote: Seriously though, why isn't it hosted at Regenstrief or HL7, or even better, NLM? It's one of the best pieces of work in the history of health informatics - it really should be kept alive for the long term. I wrote a message to the chief Nictiz

Re: UCUM

governmental institution for Health ICT). They have a lot of information about UCUM and how good it is on their website. Bert I’ll pass your thanks on Grahame On 20 Nov 2017, at 8:27 pm, Bert Verhees <bert.verh...@rosa.nl> wrote: On 20-11-17 02:58, Grahame Grieve wrote: Gunthe

Re: UCUM

Seriously though, why isn't it hosted at Regenstrief or HL7, or even better, NLM? It's one of the best pieces of work in the history of health informatics - it really should be kept alive for the long term. - thomas On 20/11/2017 10:22, Grahame Grieve wrote: I won’t pass that on ;-)

Re: UCUM

I’m sure Gunther would enjoy it if you helped out with some funding :-) I’ll pass your thanks on Grahame > On 20 Nov 2017, at 8:27 pm, Bert Verhees wrote: > >> On 20-11-17 02:58, Grahame Grieve wrote: >> Gunther says that the server had crashed, and he thinks it's memory

Re: UCUM

I won’t pass that on ;-) Grahame > On 20 Nov 2017, at 9:09 pm, Thomas Beale wrote: > > > openEHR would be happy to host it. I'm sure Gunther would lve that. > >> On 20/11/2017 09:27, Bert Verhees wrote: >>> On 20-11-17 02:58, Grahame Grieve wrote: >>> Gunther

Re: UCUM

openEHR would be happy to host it. I'm sure Gunther would lve that. On 20/11/2017 09:27, Bert Verhees wrote: On 20-11-17 02:58, Grahame Grieve wrote: Gunther says that the server had crashed, and he thinks it's memory related. He's put a process in place to email him when it stops

Re: UCUM

On 20-11-17 02:58, Grahame Grieve wrote: Gunther says that the server had crashed, and he thinks it's memory related. He's put a process in place to email him when it stops responding Thanks, I wonder, should such a server get funding to run in a professional hosting-environment. I never

Re: UCUM

Gunther says that the server had crashed, and he thinks it's memory related. He's put a process in place to email him when it stops responding Grahame On Sun, Nov 19, 2017 at 7:37 PM, Bert Verhees wrote: > On 19-11-17 09:31, Ian McNicoll wrote: > >> Does not work here

Re: UCUM

On 19-11-17 09:47, GF wrote: Lesson: - One is at risk when relying on one single source; one single point of failure. It is not really a single source, the XML file can be downloaded from many sites, also Nictiz. Even from my github-account: https://github.com/BertVerhees/ucum/blob/master

Re: UCUM

Lesson: - One is at risk when relying on one single source; one single point of failure. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 19 Nov 2017, at 09:37, Bert Verhees wrote: > > On 19-11-17 09:31, Ian McNicoll

Re: UCUM

On 19-11-17 09:31, Ian McNicoll wrote: Does not work here either, Bert. The whole site is offline. Probably just a tech snafu. Thanks Ian, it is strange, it is so since (at least) three days. I wouldn't expect that from such an important standard. Bert

Re: UCUM

ne knows how to help. > > I am trying since a few days to reach the UCUM site because I want to > download the UCUM XML file > > This would be on the URL: > > http://unitsofmeasure.org/trac > > But it doesn't work anymore, not from my computer or phone (

UCUM

Sorry for this message which has nothing to do with OpenEhr, but I have a problem and possible here someone knows how to help. I am trying since a few days to reach the UCUM site because I want to download the UCUM XML file This would be on the URL: http://unitsofmeasure.org/trac

Re: UCUM code in body temperature archetype

erent anyway. I think the other problem with using UCUM arbitrary units is that people / orgs want to control the names of medicinal delivery products ('tablet' etc) in a terminology, which is reasonable, but doesn't fit so well with UCUM. - thomas On 19/05/2016 08:11, "Gerard Freri

Re: UCUM code in body temperature archetype

On 19/05/2016 08:26, Ian McNicoll wrote: Hi Thomas, I appreciate that the Quantity classes add computability such as the +,-,=, diff operators etc but computability (or at least safe/sensible computability) is not a given even when the two operands share the same unit. it might not be

Re: UCUM code in body temperature archetype

Here in Spain there is an official terminology for medication dispensation. It is partially mapped to snomed (and the remaining ones will be part of snomed national extension) In my opinion, it makes perfect sense to allow the specification of 'units' from other (non-ucum) terminologies

Re: UCUM code in body temperature archetype

an McNicoll <i...@freshehr.com> wrote: > > Hi Thomas, > > In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for > dose units because the latter are expressed as SNOMED terms, and are used > in conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to

Re: UCUM code in body temperature archetype

al > companies. > > > Gerard Freriks > +31 620347088 > gf...@luna.nl <mailto:gf...@luna.nl> >> On 19 mei 2016, at 10:09, Ian McNicoll <i...@freshehr.com >> <mailto:i...@freshehr.com>> wrote: >> >> Hi Thomas, >> >> In the UK (

Re: UCUM code in body temperature archetype

On 19 mei 2016, at 10:09, Ian McNicoll <i...@freshehr.com> wrote: > > Hi Thomas, > > In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for dose > units because the latter are expressed as SNOMED terms, and are used in > conjunction with the SNOMED-ba

Re: UCUM code in body temperature archetype

Hi Thomas, In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for dose units because the latter are expressed as SNOMED terms, and are used in conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to compute actual doses/amounts where possible. e.g. 318421004

Re: UCUM code in body temperature archetype

Two reactions: 1- There is a difference between the world of semantic interpretability in system interfaces and the real word of users looking at screens, and typing on keyboards In one world we can/must use as much as possible SI units via UCUM and strife for as detailed as possible reducing

Re: UCUM code in body temperature archetype

by the circumstances of use, of which the use of SI units or not, is only one factor that needs to be considered. We need to solve the UCUM displayname/code issue anyway. We need to allow different code systems e.g. SNOMED CT, we need to support dose units/ pack units etc. Adding termcode and terminology

Re: UCUM code in body temperature archetype

the quantity of dose in 1 tablet/capsule etc, and also number of tablet/capsule etc. So the structural model is different anyway. I think the other problem with using UCUM arbitrary units is that people / orgs want to control the names of medicinal delivery products ('tablet' etc

Re: UCUM code in body temperature archetype

Thomas, All are Units of a different kind. SI defines: Units of Measure, and Units of Quantity in the scientific domain. There are also Units of Time: minute, hour, etc. When I think of tablets, capsule, etc. we will call these Units of Medicinal Product Dose. Isn’t in UCUM this an example

Re: UCUM code in body temperature archetype

world users expect it to be - and so that's where it goes in any other syntax you'll ever encounter (well, at least FHIR and v2, and some CDA documents, but not all .e.g USA enforces valid UCUM, so I don't know what happens to customary units) - it doesn't change the operations, it just means

Re: UCUM code in body temperature archetype

system, and do something if UCUM, and something else if not, I've now: * got just a data-oriented Quantity type * a bunch of if/else code to treat different Quantity 'types' differently * I have to move the operators out to another level, because they no longer make sense for this new

Re: UCUM code in body temperature archetype

Hi You missed my point. I assume that the content model will differentiate between ucum code and some other code, so as to enable all the behaviour you describe. But you don't need to force the use of a different element in a different place of the model. Merely differentiating the terminology

Re: UCUM code in body temperature archetype

Hi Peter, I think I did manage to identify and fix that particular problem locally but was stumped by this wider issue of whether how/if we display code / human version or both.

RE: UCUM code in body temperature archetype

: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Eric Browne Sent: Wednesday, May 18, 2016 4:30 PM To: For openEHR technical discussions <openehr-technical@lists.openehr.org> Subject: Re: UCUM code in body temperature archetype Hi Silje, 'U' i

Re: UCUM code in body temperature archetype

Hi Silje, ‘U’ is used in the lab_test-blood_glucose archetype. I also think that 10*12/l, 10*6/l, 10*6/mm3, 10*9/l are all valid UCUM codes. In fact UCUM’s table 26 Example Unit Terms by Term lists 10*6/mm3 as legal with a preferred alternative of /pL . It also lists the following alternatives

Re: UCUM code in body temperature archetype

Unfortunately Silje, not quite correct. The eye deceiveth. The construct [H20] is not valid UCUM. In none of the CKM archetypes did I find the correct UCUM code [H2O]. A zero has been substituted for the letter ‘O’. An easy mistake for a human to make. H20 even mistakenly appears 4 times

Re: UCUM code in body temperature archetype

Hi Silje, Yes, it was at the end of October that I was trying to get it to work. A DataGrid in AE was throwing exceptions, complaining about duplicates because the property_id and text fields have to form a unique key. I did manage to find and remove one pair of duplicates from the file that

Re: UCUM code in body temperature archetype

Eric, One thing I had better do is re-instate my UCUM string checker in the ADL Workbench... thanks for the timely warning. - thomas On 18/05/2016 12:59, Eric Browne wrote: Dear All, There are many, many, many archetypes in the various openEHR CKMs that DO NOT, I repeat DO NOT, I repeat

Re: UCUM code in body temperature archetype

I believe that anything between brackets can be considered a correct UCUM 2016-05-18 14:35 GMT+02:00 Bakke, Silje Ljosland <silje.ljosland.ba...@nasjonalikt.no>: > Awesome! These can be classified into UCUM, non-UCUM and just plain wrong: > > UCUM: > 1/min, Hz, Hz/s, U, U/l, cm2

RE: UCUM code in body temperature archetype

ehr-technical@lists.openehr.org> Subject: AW: UCUM code in body temperature archetype Yes, unfortunately. I have even implemented a Validation Check named VUI for this in CKM after these discussion, so that this is not forgotten, because I too think it is important to get this right... This

RE: UCUM code in body temperature archetype

Awesome! These can be classified into UCUM, non-UCUM and just plain wrong: UCUM: 1/min, Hz, Hz/s, U, U/l, cm2, cm[H20], d, daPa, daPa/s, deg, h, kHz, kPa, kg, kg/m2, l, l/min, l/s, m, m2, mV, mg, mg/dl, mg/l, min, ml, ml/d, ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], mmol/l

Re: UCUM code in body temperature archetype

On Wed, May 18, 2016 at 02:12:39PM +0200, Diego Boscá wrote: > You are right, but not my main point ;) Actually, it sort of is. It shows that the same symbol can mean different things to different people :-) Karsten > 2016-05-18 14:10 GMT+02:00 Karsten Hilbert : > > On

AW: UCUM code in body temperature archetype

. Mai 2016 14:00 An: For openEHR technical discussions <openehr-technical@lists.openehr.org> Betreff: Re: UCUM code in body temperature archetype Dear All, There are many, many, many archetypes in the various openEHR CKMs that DO NOT, I repeat DO NOT, I repeat DO NOT use valid UCUM codes for

Re: UCUM code in body temperature archetype

When we register a coded value, we store the terminology and the code. The display or rubric of it can be used for example to communicate data to a system that may not have access to the complete terminology, so that a human user can understand it. This behavior should not be different for units.

Re: UCUM code in body temperature archetype

You are right, but not my main point ;) 2016-05-18 14:10 GMT+02:00 Karsten Hilbert : > On Wed, May 18, 2016 at 01:56:00PM +0200, Diego Boscá wrote: > >> If you have a human-readable form for 'º' as "degree" > > That's the "o" in "numero", as in Nº, not degree (which is

Re: UCUM code in body temperature archetype

On Wed, May 18, 2016 at 01:56:00PM +0200, Diego Boscá wrote: > If you have a human-readable form for 'º' as "degree" That's the "o" in "numero", as in Nº, not degree (which is °). https://en.wikipedia.org/wiki/Numero_sign Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net

Re: UCUM code in body temperature archetype

Dear All, There are many, many, many archetypes in the various openEHR CKMs that DO NOT, I repeat DO NOT, I repeat DO NOT use valid UCUM codes for units in various DV_QUANTITY elements. I would guess up to 30% of Observation archetypes have some ‘invalid' UCUM unit. I spent some time trying

Re: UCUM code in body temperature archetype

ADL. > > regards, > eric > > Eric Browne > eric.bro...@montagesystems.com.au > ph 0414 925 845 > skype: eric_browne > > >> On 18 May 2016, at 8:35 pm, Thomas Beale <thomas.be...@openehr.org> wrote: >> >> Hi Daniel, >> the reason it is a Strin

Re: UCUM code in body temperature archetype

I knew someone would say that;-) But it's not for some principle of ontological purity. It's for the most basic practical reasons. Consider a quantity / units library designed based on a rigorous model of units, like UCUM (which is a very good and rigorous piece of work), and also other

Re: UCUM code in body temperature archetype

son it is a String is because we have always treated UCUM units as > parseable strings. E.g. > kg.m^-2 > > and > > kg/m^2 > are parseable according to UCUM's grammar into an expression that has a > single meaning, and can also be equated to e.g. 'kPa' (which is itself >

Re: UCUM code in body temperature archetype

ame > >> On 18 May 2016, at 9:48 PM, Diego Boscá <yamp...@gmail.com> wrote: >> >> And we probably want that the human-readable form can be multilingual as >> well. >> >> 2016-05-18 13:41 GMT+02:00 Thomas Beale <thomas.be...@openehr.org>: >>

Re: UCUM code in body temperature archetype

- there are lots of non-SI units in UCUM. The issue is that units of doses are not scientific units, and can't be represented the same way. So we shouldn't expect our models of the latter to work properly for dose units. Of course I agree that we should make life easier for developers, systems etc, and also

Re: UCUM code in body temperature archetype

differentiate them Grahame > On 18 May 2016, at 9:41 PM, Thomas Beale <thomas.be...@openehr.org> wrote: > > >> On 18/05/2016 12:21, Grahame Grieve wrote: >> The main problem is that ucum units are not human readable units, > > right - my idea 13 years ago wa

Re: UCUM code in body temperature archetype

thomas.be...@openehr.org>: >> >> On 18/05/2016 12:21, Grahame Grieve wrote: >> >> The main problem is that ucum units are not human readable units, >> >> >> right - my idea 13 years ago was to use the UCUM string as a key into >> something that g

Re: UCUM code in body temperature archetype

And we probably want that the human-readable form can be multilingual as well. 2016-05-18 13:41 GMT+02:00 Thomas Beale <thomas.be...@openehr.org>: > > On 18/05/2016 12:21, Grahame Grieve wrote: > > The main problem is that ucum units are not human readable units, > > &g

Re: UCUM code in body temperature archetype

On 18/05/2016 12:21, Grahame Grieve wrote: The main problem is that ucum units are not human readable units, right - my idea 13 years ago was to use the UCUM string as a key into something that generated a human-readable form. For reasons that became clearer since, I think we all agree

Re: UCUM code in body temperature archetype

sonable way. > - thomas > > > On 18/05/2016 10:22, Ian McNicoll wrote: > > Hi Grahame, > > For the use case raised, I agree, but there other considerations e.g. Dose > units and other non-UCUM code use - in the UK there is a desire to use > S

Re: UCUM code in body temperature archetype

The main problem is that ucum units are not human readable units, and trying to force them to be will generate substantial pushback from end users. In USA, this is an open problem for CDA adoption. In Australia, I solved it by declaring that we would never retire valid ucum units in CDA

Re: UCUM code in body temperature archetype

thomas On 18/05/2016 10:22, Ian McNicoll wrote: Hi Grahame, For the use case raised, I agree, but there other considerations e.g. Dose units and other non-UCUM code use - in the UK there is a desire to use SNOMED terms for dose units. FHIR has human + code + system for quantity units, I think

Re: UCUM code in body temperature archetype

It's not out of the question, although my view was always that the units string should be parsed and then rendered using one of the other columns of UCUM, or even something else. But this does as Silje says, put more work on to implementers, so we probably should consider a CR on the RM to add

Re: UCUM code in body temperature archetype

Hi Daniel, the reason it is a String is because we have always treated UCUM units as parseable strings. E.g. kg.m^-2 and kg/m^2 are parseable according to UCUM's grammar <http://unitsofmeasure.org/ucum.html#section-Syntax-Rules> into an expression that has a single meaning, and ca

Re: UCUM code in body temperature archetype

Yes you're right. We need to allow snomed units there etc. but we use quantity for more than openehr does, so I thought you might be able to just have ucum. So you might as well copy FHIR then Grahame > On 18 May 2016, at 7:22 PM, Ian McNicoll <i...@freshehr.com> wrote: >

Re: UCUM code in body temperature archetype

t;i...@freshehr.com> wrote: > Hi Grahame, > > For the use case raised, I agree, but there other considerations e.g. Dose > units and other non-UCUM code use - in the UK there is a desire to use > SNOMED terms for dose units. > > FHIR has human + code + system for quant

Re: UCUM code in body temperature archetype

Hi Grahame, For the use case raised, I agree, but there other considerations e.g. Dose units and other non-UCUM code use - in the UK there is a desire to use SNOMED terms for dose units. FHIR has human + code + system for quantity units, I think? Ian Dr Ian McNicoll mobile +44 (0)775 209 7859

Re: UCUM code in body temperature archetype

> So, right now the DV_QUANTITY.units is a String, perhaps it should be > DV_CODED_TEXT? > > /Daniel > > On 2016-05-18 10:25, Bakke, Silje Ljosland wrote: > > This imposes a larger implementation burden on the systems who will have > to be able to read UCUM codes and show

Re: UCUM code in body temperature archetype

t;> On 2016-05-18 10:25, Bakke, Silje Ljosland wrote: >> This imposes a larger implementation burden on the systems who will have to >> be able to read UCUM codes and show the corresponding symbol instead of the >> code, which in many cases is not readable to clinicians. >

Re: UCUM code in body temperature archetype

So, right now the DV_QUANTITY.units is a String, perhaps it should be DV_CODED_TEXT? /Daniel On 2016-05-18 10:25, Bakke, Silje Ljosland wrote: This imposes a larger implementation burden on the systems who will have to be able to read UCUM codes and show the corresponding symbol instead

RE: UCUM code in body temperature archetype

Hi Daniel, You’re 100% correct. This error is corrected in the branch I uploaded after the Norwegian body temp archetype was published, but this hasn’t been taken into the trunk yet as it contains some other major changes. As a general observation, an issue with using UCUM units in archetype

UCUM code in body temperature archetype

Dear All, it seems the UCUM code for the temperature units in the Body temperature archetype is wrong. It uses the UCUM print symbol, e.g. "°C", rather than the UCUM code "Cel". http://www.openehr.org/ckm/#showArchetype_1013.1.49 Regards, Daniel -- Daniel Karlss

UCUM

well... good question. So in other words: if there is a units field specifically for 'formal' units, is it UCUM only or not? I would have said it should be except for annoying problems like the one Heath mentioned - UCUM uses '*' for exponent instead of '^' which almost everyone else uses We

UCUM

you would just escape the ^ in the HL7 message Grahame On Thu, Mar 22, 2012 at 6:35 AM, Michael Osborne mjosborne1 at gmail.com wrote: well... good question. So in other words: if there is a units field specifically for 'formal' units, is it UCUM only or not? I would have said it should

Unable to express an unit of measurements in UCUM syntax

: 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

Unable to express an unit of measurements in UCUM syntax

On 29/05/2011 22:50, Grahame Grieve 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. well... ok, but {} in UCUM is for things

Unable to express an unit of measurements in UCUM syntax

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

Unable to express an unit of measurements in UCUM syntax

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

Unable to express an unit of measurements in UCUM syntax

On 26/05/2011 16:48, Leonardo Moretti 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

Unable to express an unit of measurements in UCUM syntax

...@openehr.org] On Behalf Of Thomas Beale Sent: Friday, 27 May 2011 4:24 a.m. To: openehr-technical at openehr.org Subject: Re: Unable to express an unit of measurements in UCUM syntax On 26/05/2011 16:48, Leonardo Moretti wrote: Hi all, I thought a lot on your proposal. If we want to use pseudo

Unable to express an unit of measurements in UCUM syntax

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

Unable to express an unit of measurements in UCUM syntax

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

Unable to express an unit of measurements in UCUM syntax

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

Unable to express an unit of measurements in UCUM syntax

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

Unable to express an unit of measurements in UCUM syntax

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

Unable to express an unit of measurements in UCUM syntax

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

Unable to express an unit of measurements in UCUM syntax

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

Unable to express an unit of measurements in UCUM syntax

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 On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo lmoretti

Unable to express an unit of measurements in UCUM syntax

(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