Re: UCUM/SNOMED/custom units

[Pablo Pazos]

REF https://openehr.atlassian.net/browse/SPECPR-96

On Mon, Jul 23, 2018 at 9:15 AM, Bert Verhees  wrote:

> 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 alternatives are being explored in order to not break current
>> units definitions. Maybe adding an optional codephrase or terminology
>> mapping could do the trick, as then you can tell where the unit comes from
>> and allows you to provide a "code" which could either contain a Snomed code
>> or a UCUM expression. Inputs are appreciated as always :)
>>
>
> I think your suggested solution is just right ;-)
> But possible I do not oversee all consequences
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM/SNOMED/custom units

[Bert Verhees]

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 alternatives are being explored in order to not break current 
units definitions. Maybe adding an optional codephrase or terminology 
mapping could do the trick, as then you can tell where the unit comes 
from and allows you to provide a "code" which could either contain a 
Snomed code or a UCUM expression. Inputs are appreciated as always :)


I think your suggested solution is just right ;-)
But possible I do not oversee all consequences

Bert

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

Re: UCUM/SNOMED/custom units

[Diego Boscá]

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 to not break current units
definitions. Maybe adding an optional codephrase or terminology mapping
could do the trick, as then you can tell where the unit comes from and
allows you to provide a "code" which could either contain a Snomed code or
a UCUM expression. Inputs are appreciated as always :)

Regards

2018-07-23 13:14 GMT+02:00 Bert Verhees :

> 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 the DV_QUANTITY-definition,
> because it has a units-attribute, it says it must be expressed in UCUM
> syntax. It does not say anything about the unit itself, only about the
> notation.
>
> Must we understand UCUM so, that it has not only a syntax for its own
> units, but also for custom units?
>
> That is strange, because custom-units (non-UCUM) can carry custom
> (non-UCUM) syntax-descriptions. So if we are writing a custom unit, and
> using a syntax to specify it, then we need two references, don't we?
>
> One reference for where the unit comes from, and one reference for the
> syntax?
>
>
> A custom unit can also occur in another standard, for example SNOMED, also
> a UCUM-unit can occur in SNOMED, but is it sure it means the same? Normally
> we are very prudent about things like this.
> I found a HL7 wiki about this. Someone did some thinking about this. I
> think that also applies to OpenEhr.
>
> http://wiki.hl7.org/index.php?title=Representation_of_Units
>
> Best regards
> Bert Verhees
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

UCUM/SNOMED/custom units

[Bert Verhees]

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 the 
DV_QUANTITY-definition, because it has a units-attribute, it says it 
must be expressed in UCUM syntax. It does not say anything about the 
unit itself, only about the notation.


Must we understand UCUM so, that it has not only a syntax for its own 
units, but also for custom units?


That is strange, because custom-units (non-UCUM) can carry custom 
(non-UCUM) syntax-descriptions. So if we are writing a custom unit, and 
using a syntax to specify it, then we need two references, don't we?


One reference for where the unit comes from, and one reference for the 
syntax?



A custom unit can also occur in another standard, for example SNOMED, 
also a UCUM-unit can occur in SNOMED, but is it sure it means the same? 
Normally we are very prudent about things like this.
I found a HL7 wiki about this. Someone did some thinking about this. I 
think that also applies to OpenEhr.


http://wiki.hl7.org/index.php?title=Representation_of_Units

Best regards
Bert Verhees

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

Re: UCUM

[Bert Verhees]

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 that an improved version of the UCUM standard website will be 
transferred soon to the infrastructure that hosts the LOINC website too.


So the bell ringing worked out ;-)

Bert

On 21-11-17 09:04, Bert Verhees wrote:


I wrote a message to the chief Nictiz terminology specialist to ring 
some bells. I don know if she will do that, but that is as far as my 
influence goes.


Bert


Didn't work out. That was all I can do. Now it is for real influencers 
and ambassadors of the good cause to do their best to get a solid 
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

[Bert Verhees]

On 20-11-17 12:02, Bert Verhees wrote:

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 terminology specialist to ring 
some bells. I don know if she will do that, but that is as far as my 
influence goes.


Bert


Didn't work out. That was all I can do. Now it is for real influencers 
and ambassadors of the good cause to do their best to get a solid 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

[Bert Verhees]

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 terminology specialist to ring 
some bells. I don know if she will do that, but that is as far as my 
influence goes.


Bert

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

Re: UCUM

[Bert Verhees]

On 20-11-17 11:21, Grahame Grieve wrote:

I’m sure Gunther would enjoy it if you helped out with some funding :-)


I wouldn't mind to spend a small amount, if it is necessary, but I think 
there are other more wealthier institutions which also profit from this 
work.

Nictiz for example. (Dutch 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:
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 thought this was maintained by private persons.
I think we must be thankful to Gunther for doing this.

Bert



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

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




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

Re: UCUM

[Thomas Beale]

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

Grahame



--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

Re: UCUM

[Grahame Grieve]

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 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 thought this was maintained by private persons.
> I think we must be thankful to Gunther for doing this.
> 
> Bert
> 
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: UCUM

[Grahame Grieve]

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 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 thought this was maintained by private persons. 
>> I think we must be thankful to Gunther for doing this. 
>> 
> 
> -- 
> Thomas Beale
> Principal, Ars Semantica
> Consultant, ABD Team, Intermountain Healthcare
> Management Board, Specifications Program Lead, openEHR Foundation
> Chartered IT Professional Fellow, BCS, British Computer Society
> Health IT blog | Culture blog
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM

[Thomas Beale]

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 
responding


Thanks, I wonder, should such a server get funding to run in a 
professional hosting-environment. I never thought this was maintained 
by private persons.

I think we must be thankful to Gunther for doing this.



--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

Re: UCUM

[Bert Verhees]

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 thought this was maintained by 
private persons.

I think we must be thankful to Gunther for doing this.

Bert



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

Re: UCUM

[Grahame Grieve]

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 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
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM

[Bert Verhees]

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/terminology_data/ucum-essence.xml

It is just that that one site is authoritative, and that is what 
customers want (and need).


Bert

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

Re: UCUM

[GF]

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 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
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: UCUM

[Bert Verhees]

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

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

Re: UCUM

[Ian McNicoll]

Does not work here either, Bert. The whole site is offline. Probably just a
tech snafu.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 19 November 2017 at 08:24, Bert Verhees <bert.verh...@rosa.nl> wrote:

> 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
>
> But it doesn't work anymore, not from my computer or phone (which is on
> another network)
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

UCUM

[Bert Verhees]

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

But it doesn't work anymore, not from my computer or phone (which is on 
another network)


Bert


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

Re: UCUM code in body temperature archetype

[Colin Sutton]

I agree with Thomas. Speaking as someone who has had to help with quality 
control of large amounts of user entered concomitant medication data for 
clinical trials, ‘tablet’ , ‘capsule’, and similar are not ‘units’ unless they 
are associated with other reference data.
 ‘Tablet' is a description of the appearance of the medication, which is not 
useful in the context of dose units.
 ’Tablet’ may be useful as a discriminant between different proprietary 
products, if you have more details (e.g. the product name) and a database which 
has the dose units of the product variations.

Colin Sutton
I.T. Systems Development Manager
NHMRC Clinical Trials Centre

On 19 May 2016, at 5:24 PM, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:


Hi Gerard,

they actually could be, but whenever this discussion comes up, no-one proposes 
it. I'm not sure if I would either, because these arbitrary units are still not 
computable in general, but 'dose units' can be made computable but only with 
some extra data fields, i.e. you need both 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) in a 
terminology, which is reasonable, but doesn't fit so well with UCUM.

- thomas

On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
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 of Arbitrary Units?
3.2

ARBITRARY UNITS


§24 arbitrary units   ■1 Arbitrary or procedure defined units are units 
whose meaning entirely depends on the measurement procedure (assay). These 
units have no general meaning in relation with any other unit in the SI. 
Therefore those arbitrary semantic entities are called arbitrary units, as 
opposed to proper units. The set of arbitrary units is denoted A, where A∩ U = 
{}.   ■2 An arbitrary unit has no further definition in the semantic framework 
of The Unified Code for Units of Measure  ■3 Arbitrary units are not “of any 
specific dimension” and are not “commensurable with” any other unit.

Until version 1.6 The Unified Code for Units of Measure has dealt with 
arbitrary units as dimensionless, but as an effect the semantics of The Unified 
Code for Units of Measure made all arbitrary units commensurable. Since version 
1.7 of The Unified Code for Units of Measure it is no longer possible to 
convert or compare arbitrary units with any other arbitrary unit.

§25 operations on arbitrary units   ■1 Any term involving arbitrary units, 
is itself an arbitrary unit and is not comparable with any other arbitrary unit 
or term.

§26 definition of arbitrary units   ■1 Arbitrary units are marked in the 
definition tables for unit atoms by a bullet (‘•’) in the column titled “value” 
and a bullet in the column titled “definition”.


Gerard Freriks
+31 620347088
<mailto:gf...@luna.nl>gf...@luna.nl<mailto:gf...@luna.nl>

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
http://scanmail.trustwave.com/?c=1688=nuq91wXdsw3fdrcy_RKYOroV-0psr7BFxYHw4b5Mdg=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-technical%5flists%2eopenehr%2eorg


#
Scanned by MailMarshal - M86 Security's comprehensive email content security 
solution. 
#


IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be 
read or used by the named addressee. It is confidential and may contain legally 
privileged information. No confidentiality or privilege is waived or lost by 
any mistaken transmission to you. The CTC is not responsible for any 
unauthorised alterations to this e-mail or attachment to it. Views expressed in 
this message are those of the individual sender, and are not necessarily the 
views of the CTC. If you receive this e-mail in error, please immediately 
delete it and notify the sender. You must not disclose, copy or use any part of 
this e-mail if you are not the intended recipient.

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

Re: UCUM code in body temperature archetype

[Thomas Beale]

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 clinically, but it always is in terms of quantities - 
that's the whole point of the system of physical quantities. It's not up 
to the DvQuantity (or any similar) type to know the clinical semantics 
at hand; the way it has to work is that a higher level clinical context 
in an application knows what Quantities are clinically comparable, when 
it does, it's a /guarantee /that two DvQuantity instances of the same 
unit (say 'g') are addable, subtractable and can be multiplied by a scalar.


This is the point of having a simple Quantity type in the system - just 
to do this job.


Nor does the fact that a unit is non-scientific invalidate the use of 
those operators in many cases e.g 1 tab + 1 tab = 2 tabs. Of course 
there are situations where to do so would be unsafe and not sensible 
but that also applies to cases where SI units are being used.


in this case you simply can't know, not even if you know that both 
'tablet' quantities are for Aspirin. You have to at least know what the 
tablet size is. This can be known, and the semantics can be known, but 
not from a basic Quantity type; we need something more.


A very basic rule in IT and modelling is to build things additively, 
using a new abstraction for each new complication. The alternative of 
trying to jam all possible use cases into a single type or abstraction 
always leads to something unwieldy, unclear and guaranteed to create 
bugs in processing and data. That's the reason we don't try to make the 
type 'Integer' do more than a simple integer can do.


Similarly, I would argue that the basic 'Quantity' type in a set of data 
types for science / biomedical computing should just do its basic job - 
representing quantities with units, accuracy, and precision. (We already 
violate this somewhat in openEHR by including reference ranges, but at 
least that remains perfectly computable.)


When we get to the scenario of quantities of drugs delivered in 
quantised dose objects such as tablets etc, we are at another level of 
sophistication. It doesn't make sense to change the Quantity data type 
to do a more complicated job; if we do that, we have no Quantity type 
that just implements standard scientific quantities.


Adding a new smart type, say DoseQuantity, is easy enough. Or else we 
relegate the more complex information needed for drug information to 
archetype data points as we do now. Trying to hack an existing type to 
do a job it is not designed to do is a bad idea.


- thomas

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

Re: UCUM code in body temperature archetype

[Diego Boscá]

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, such as snomed or even the national
ones

2016-05-19 10:19 GMT+02:00 "Gerard Freriks (privé)" <gf...@luna.nl>:

> An alternative for dealing with semantic in archetypes is dealing with
> semantics in coding systems like SNOMED.
>
> The consequence is that SNOMED must be a complete Medicinal Product
> Formulary.
> I have doubts whether this is a good idea.
>
> Many countries have different specific formularies.
> I like to reserve SNOMED-CT to use as any dictionary with universal
> lemma’s, concepts.
> Each country will have its own maintained Formulary.
> A formulary that changes because of the marketing whims of pharmaceutical
> companies.
>
>
> Gerard Freriks
> +31 620347088
> gf...@luna.nl
>
> 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-based dm+d (or AMT) drug dictionary to
> compute actual doses/amounts where possible.
>
> e.g.
>
> 318421004 | Atenolol 100mg tablets |
>
> via dm+d allows us to infer that 1 tab (in this case) = 100mg
>
> http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004=nofloat
>
> and allows us to do maximum daily dose calculation, at least against a
> defined subset of such 'dose units'.
>
> in other cases the dose unit strength will be defined as part of the
> medication order - we have a 'Strength' element in the medication order
> archetype for just such a purpose.
>
> I don't think we need to be able to define the unit strength as part of
> the quantity datatype.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 19 May 2016 at 08:24, Thomas Beale <thomas.be...@openehr.org> wrote:
>
>> Hi Gerard,
>>
>> they actually could be, but whenever this discussion comes up, no-one
>> proposes it. I'm not sure if I would either, because these arbitrary units
>> are still not computable in general, but 'dose units' can be made
>> computable but only with some extra data fields, i.e. you need both 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) in a terminology, which is reasonable, but doesn't fit so well with
>> UCUM.
>>
>> - thomas
>>
>> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>>
>> 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 of Arbitrary Units?
>> 3.2  ARBITRARY UNITS
>>
>> *§24 arbitrary units*  * ■1* Arbitrary or procedure defined units
>> are units whose meaning entirely depends on the measurement procedure
>> (assay). These units have no general meaning in relation with any other
>> unit in the SI. Therefore those arbitrary semantic entities are called 
>> *arbitrary
>> units*, as opposed to *proper units*. The set of arbitrary units is
>> denoted *A*, where *A*∩ *U* = {}.  * ■2* An arbitrary unit has no
>> further definition in the semantic framework of *The Unified Code for
>> Units of Measure* * ■3* Arbitrary units are not “of any specific
>> dimension” and are not “commensurable with” any other unit.
>>
>> Until version 1.6 *The Unified Code for Units of Measure* has dealt with
>> arbitrary units as dimensionless, but as an effect the semantics of *The
>> Unified Code for Units of Measure* made all arbitrary units
>> commensurable. Since version 1.7 of *The Unified Code for Units of
>> Measure* it is no longer possible to convert or compare a

Re: UCUM code in body temperature archetype

[Ian McNicoll]

Hi Gerard,

"The consequence is that SNOMED must be a complete Medicinal Product
Formulary.
I have doubts whether this is a good idea.'

dm+d is a UK health-service managed dictionary based on SNOMED CT and using
the UK national namespace i.e. it is not managed internationally.
It is a complete Product formulary/dictionary but only for UK. I understand
that Aus and New Zealand have very similar approaches.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 19 May 2016 at 09:19, "Gerard Freriks (privé)" <gf...@luna.nl> wrote:

> An alternative for dealing with semantic in archetypes is dealing with
> semantics in coding systems like SNOMED.
>
> The consequence is that SNOMED must be a complete Medicinal Product
> Formulary.
> I have doubts whether this is a good idea.
>
> Many countries have different specific formularies.
> I like to reserve SNOMED-CT to use as any dictionary with universal
> lemma’s, concepts.
> Each country will have its own maintained Formulary.
> A formulary that changes because of the marketing whims of pharmaceutical
> companies.
>
>
> Gerard Freriks
> +31 620347088
> gf...@luna.nl
>
> 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-based dm+d (or AMT) drug dictionary to
> compute actual doses/amounts where possible.
>
> e.g.
>
> 318421004 | Atenolol 100mg tablets |
>
> via dm+d allows us to infer that 1 tab (in this case) = 100mg
>
> http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004=nofloat
>
> and allows us to do maximum daily dose calculation, at least against a
> defined subset of such 'dose units'.
>
> in other cases the dose unit strength will be defined as part of the
> medication order - we have a 'Strength' element in the medication order
> archetype for just such a purpose.
>
> I don't think we need to be able to define the unit strength as part of
> the quantity datatype.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 19 May 2016 at 08:24, Thomas Beale <thomas.be...@openehr.org> wrote:
>
>> Hi Gerard,
>>
>> they actually could be, but whenever this discussion comes up, no-one
>> proposes it. I'm not sure if I would either, because these arbitrary units
>> are still not computable in general, but 'dose units' can be made
>> computable but only with some extra data fields, i.e. you need both 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) in a terminology, which is reasonable, but doesn't fit so well with
>> UCUM.
>>
>> - thomas
>>
>> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>>
>> 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 of Arbitrary Units?
>> 3.2  ARBITRARY UNITS
>>
>> *§24 arbitrary units*  * ■1* Arbitrary or procedure defined units
>> are units whose meaning entirely depends on the measurement procedure
>> (assay). These units have no general meaning in relation with any other
>> unit in the SI. Therefore those arbitrary semantic entities are called 
>> *arbitrary
>> units*, as opposed to *proper units*. The set of arbitrary units is
>> denoted *A*, where *A*∩ *U* = {}.  * ■2* An arbitrary unit has no
>> further definition in the semantic framework of *The Unified Code for
>> Units of Measure* * ■3* Arbitrary units are not “of any specific
>> dimension” and are not “commensurable

Re: UCUM code in body temperature archetype

[jantal...@home.nl]

In 2012 a number of ISO standards were published on the “Identification of 
medicinal products” When I recall correctly there is one that deals with the 
representation of dose forms, units of presentation and route of 
administration. 

Jan Talmon

> On 19 mei 2016, at 10:19, Gerard Freriks (privé) <gf...@luna.nl> wrote:
> 
> An alternative for dealing with semantic in archetypes is dealing with 
> semantics in coding systems like SNOMED.
> 
> The consequence is that SNOMED must be a complete Medicinal Product Formulary.
> I have doubts whether this is a good idea.
> 
> Many countries have different specific formularies.
> I like to reserve SNOMED-CT to use as any dictionary with universal lemma’s, 
> concepts.
> Each country will have its own maintained Formulary.
> A formulary that changes because of the marketing whims of pharmaceutical 
> 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 (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 | Atenolol 100mg tablets |
>> 
>> via dm+d allows us to infer that 1 tab (in this case) = 100mg
>> 
>> http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004=nofloat 
>> <http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004=nofloat>
>> 
>> and allows us to do maximum daily dose calculation, at least against a 
>> defined subset of such 'dose units'.
>> 
>> in other cases the dose unit strength will be defined as part of the 
>> medication order - we have a 'Strength' element in the medication order 
>> archetype for just such a purpose.
>> 
>> I don't think we need to be able to define the unit strength as part of the 
>> quantity datatype.
>> 
>> Ian  
>> 
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com <mailto:i...@freshehr.com>
>> twitter: @ianmcnicoll
>> 
>> 
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
>> <mailto:ian.mcnic...@openehr.org>
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>> 
>> On 19 May 2016 at 08:24, Thomas Beale <thomas.be...@openehr.org 
>> <mailto:thomas.be...@openehr.org>> wrote:
>> Hi Gerard,
>> they actually could be, but whenever this discussion comes up, no-one 
>> proposes it. I'm not sure if I would either, because these arbitrary units 
>> are still not computable in general, but 'dose units' can be made computable 
>> but only with some extra data fields, i.e. you need both 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) 
>> in a terminology, which is reasonable, but doesn't fit so well with UCUM.
>> 
>> - thomas
>> 
>> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>>> 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 of Arbitrary Units?
>>>  <>3.2 
>>> ARBITRARY UNITS
>>>  <>§24 arbitrary units   ■1 Arbitrary or procedure defined units are 
>>> units whose meaning entirely depends on the measurement procedure (assay). 
>>> These units have no general meaning in relation with any other unit in the 
>>> SI. Therefore those arbitrary semantic entities are called arbitrary units, 
>>> as opposed to proper units. The set of arbitrary units is denoted A, where 
>>> A∩ U = {}.   ■2 An arbitrary unit has no further definition in the semantic 
>>> framework of The Unified Code for Units of Measure  ■3 Arbitrary units are 
>&

Re: UCUM code in body temperature archetype

[Gerard Freriks (privé)]

An alternative for dealing with semantic in archetypes is dealing with 
semantics in coding systems like SNOMED.

The consequence is that SNOMED must be a complete Medicinal Product Formulary.
I have doubts whether this is a good idea.

Many countries have different specific formularies.
I like to reserve SNOMED-CT to use as any dictionary with universal lemma’s, 
concepts.
Each country will have its own maintained Formulary.
A formulary that changes because of the marketing whims of pharmaceutical 
companies.


Gerard Freriks
+31 620347088
gf...@luna.nl <mailto:gf...@luna.nl>
> 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-based dm+d (or AMT) drug dictionary to compute 
> actual doses/amounts where possible.
> 
> e.g.
> 
> 318421004 | Atenolol 100mg tablets |
> 
> via dm+d allows us to infer that 1 tab (in this case) = 100mg
> 
> http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004=nofloat 
> <http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004=nofloat>
> 
> and allows us to do maximum daily dose calculation, at least against a 
> defined subset of such 'dose units'.
> 
> in other cases the dose unit strength will be defined as part of the 
> medication order - we have a 'Strength' element in the medication order 
> archetype for just such a purpose.
> 
> I don't think we need to be able to define the unit strength as part of the 
> quantity datatype.
> 
> Ian  
> 
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com <mailto:i...@freshehr.com>
> twitter: @ianmcnicoll
> 
> 
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
> <mailto:ian.mcnic...@openehr.org>
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> 
> On 19 May 2016 at 08:24, Thomas Beale <thomas.be...@openehr.org 
> <mailto:thomas.be...@openehr.org>> wrote:
> Hi Gerard,
> they actually could be, but whenever this discussion comes up, no-one 
> proposes it. I'm not sure if I would either, because these arbitrary units 
> are still not computable in general, but 'dose units' can be made computable 
> but only with some extra data fields, i.e. you need both 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) 
> in a terminology, which is reasonable, but doesn't fit so well with UCUM.
> 
> - thomas
> 
> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>> 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 of Arbitrary Units?
>>  <>3.2 
>> ARBITRARY UNITS
>>  <>§24 arbitrary units   ■1 Arbitrary or procedure defined units are 
>> units whose meaning entirely depends on the measurement procedure (assay). 
>> These units have no general meaning in relation with any other unit in the 
>> SI. Therefore those arbitrary semantic entities are called arbitrary units, 
>> as opposed to proper units. The set of arbitrary units is denoted A, where 
>> A∩ U = {}.   ■2 An arbitrary unit has no further definition in the semantic 
>> framework of The Unified Code for Units of Measure  ■3 Arbitrary units are 
>> not “of any specific dimension” and are not “commensurable with” any other 
>> unit.
>> 
>> Until version 1.6 The Unified Code for Units of Measure has dealt with 
>> arbitrary units as dimensionless, but as an effect the semantics of The 
>> Unified Code for Units of Measure made all arbitrary units commensurable. 
>> Since version 1.7 of The Unified Code for Units of Measure it is no longer 
>> possible to convert or compare arbitrary units with any other arbitrary unit.
>> 
>>  <>§25 operations on arbitrary units   ■1 Any term involving arbitrary 
>> units, is itself an arbitrary unit and is not comparable with any other 
>> arbitrary unit or term.
>> 
>>  <>§26 definition of arbitrary units   

Re: UCUM code in body temperature archetype

[Ian McNicoll]

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 | Atenolol 100mg tablets |

via dm+d allows us to infer that 1 tab (in this case) = 100mg

http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004=nofloat

and allows us to do maximum daily dose calculation, at least against a
defined subset of such 'dose units'.

in other cases the dose unit strength will be defined as part of the
medication order - we have a 'Strength' element in the medication order
archetype for just such a purpose.

I don't think we need to be able to define the unit strength as part of the
quantity datatype.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 19 May 2016 at 08:24, Thomas Beale <thomas.be...@openehr.org> wrote:

> Hi Gerard,
>
> they actually could be, but whenever this discussion comes up, no-one
> proposes it. I'm not sure if I would either, because these arbitrary units
> are still not computable in general, but 'dose units' can be made
> computable but only with some extra data fields, i.e. you need both 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) in a terminology, which is reasonable, but doesn't fit so well with
> UCUM.
>
> - thomas
>
> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>
> 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 of Arbitrary Units?
> 3.2  ARBITRARY UNITS
>
> *§24 arbitrary units*  * ■1* Arbitrary or procedure defined units are
> units whose meaning entirely depends on the measurement procedure (assay).
> These units have no general meaning in relation with any other unit in the
> SI. Therefore those arbitrary semantic entities are called *arbitrary
> units*, as opposed to *proper units*. The set of arbitrary units is
> denoted *A*, where *A*∩ *U* = {}.  * ■2* An arbitrary unit has no further
> definition in the semantic framework of *The Unified Code for Units of
> Measure* * ■3* Arbitrary units are not “of any specific dimension” and
> are not “commensurable with” any other unit.
>
> Until version 1.6 *The Unified Code for Units of Measure* has dealt with
> arbitrary units as dimensionless, but as an effect the semantics of *The
> Unified Code for Units of Measure* made all arbitrary units
> commensurable. Since version 1.7 of *The Unified Code for Units of
> Measure* it is no longer possible to convert or compare arbitrary units
> with any other arbitrary unit.
>
> *§25 operations on arbitrary units*  * ■1* Any term involving
> arbitrary units, is itself an arbitrary unit and is not comparable with any
> other arbitrary unit or term.
>
> *§26 definition of arbitrary units*  * ■1* Arbitrary units are marked
> in the definition tables for unit atoms by a bullet (‘•’) in the column
> titled “value” and a bullet in the column titled “definition”.
>
>
> Gerard Freriks
> +31 620347088
> <gf...@luna.nl>gf...@luna.nl
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Gerard Freriks (privé)]

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 misinterpretation.
In the real world users want to have data presented in many shapes and forms.
Accommodating the end-users is the task of the industry.
It is the task of health informaticians to reduce misinterpretations.

At the Template/Interface level we need facilities to annotate as much as 
possible that what is expressed/modelled.
And why not have in the annotations, the printable, the human readable, the 
personal choice, the local choice.

2- When it comes to the Arbitrary UCUM Units.
The question is how much semantic we carry in data types.
And how much semantics we carry in archetypes.
I opt for the latter.
Data types should be as primitive as possible.

I use the UCUM Arbitrary ‘Unit’ and use the structure in the Archetype to 
provide the semantics that describe the Unit.


Gerard Freriks
+31 620347088
gf...@luna.nl <mailto:gf...@luna.nl>
> On 19 mei 2016, at 09:24, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> Hi Gerard,
> 
> they actually could be, but whenever this discussion comes up, no-one 
> proposes it. I'm not sure if I would either, because these arbitrary units 
> are still not computable in general, but 'dose units' can be made computable 
> but only with some extra data fields, i.e. you need both 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) 
> in a terminology, which is reasonable, but doesn't fit so well with UCUM.
> 
> - thomas
> 
> 

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

Re: UCUM code in body temperature archetype

[Ian McNicoll]

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. Nor does the fact that a unit is non-scientific invalidate the use of
those operators in many cases e.g 1 tab + 1 tab = 2 tabs. Of course there
are situations where to do so would be unsafe and not sensible but that
also applies to cases where SI units are being used.

In other words the safe and sensible use of the operators is always going
to be constrained 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 solves that problem in a way
which prevents avoids change, avoids introducing another flavour of
quantity (more stuff for people to learn), and makes modelling of the key
area of medication much cleaner.

I would be really keen to hear from other openEHR implementers on this. If
operators are being heavily used and the suggested change would compromise
computability or ease of implementation, I could be otherwise persuaded.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 18 May 2016 at 20:45, Thomas Beale <thomas.be...@openehr.org> wrote:

> Grahame,
>
> I think you are saying that you can implement the *semantics *of dose
> units with just a DvQantity / FHIR Quantity. If 'dose units' includes the
> knowledge of the discrete unit of delivery, i.e. table, drop etc, as well
> as total amount, you can't. You need at least the elements here, or their
> equivalent.
>
> class DoseQuantity
> unitForm: DvCodedText // type of physical dose entity tablet,
> capsule, puff etc
> unitAmount: DvQuantity// how much is in a `doseForm` unit e.g.
> 5mg
> doseCount: Integer// how many items of `doseForm` to
> deliver
>
> doseAmount: DvQuantity {  // total amount of substance delivered
> to patient
> Result := doseCount * unitAmount
> }
> end
>
> If on the other hand you are saying we just go the pseudo-units route,
> where 'tablet' is a kind of unit, we can, but the Quantity library won't
> work properly anymore, because you no longer know if you can add two
> quantities even if they have the same unit, because 'tablet' as a unit
> doesn't mean anything. Where I am coming from is: Quantity is not just
> data, it is operations and computing
> <http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_quantity_package>;
> it includes operators like:
>
>- DV_AMOUNT: =, +, -, *, etc
>- DV_ABSOLUTE_QUANTITY: diff, add, subtract
>
> (there are many ways to model this kind of thing, that's just the openEHR
> way).
>
> If you are saying: use a code + code-system approach, and check the code
> 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 style of Quantity
>
> So, in terms of what we do in openEHR, I don't think it makes sense. In
> terms of FHIR, it makes sense; but I have to check a FHIR Quantity and
> instantiate different kinds of RM structures depending on the units code
> system.
>
> - thomas
> On 18/05/2016 17:58, Grahame Grieve wrote:
>
> 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 used will
> achieve that. A processor will know when it can use ucum based logic - not
> that I've ever seen that in the real world - and it will know when it can't
>
> Eric's part of this thread notes the issues with doing with this
> implicitly, so I'm not advocating for that, which brings you back to the
> FHIR model: human units, and system + code for computable units.
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Thomas Beale]

Hi Gerard,

they actually could be, but whenever this discussion comes up, no-one 
proposes it. I'm not sure if I would either, because these arbitrary 
units are still not computable in general, but 'dose units' can be made 
computable but only with some extra data fields, i.e. you need both 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) in a terminology, which is reasonable, but doesn't fit so 
well with UCUM.


- thomas


On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:

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 of Arbitrary Units?


  3.2




  ARBITRARY UNITS

*§24 arbitrary units* *^ ■1 * Arbitrary or procedure defined units are 
units whose meaning entirely depends on the measurement procedure 
(assay). These units have no general meaning in relation with any 
other unit in the SI. Therefore those arbitrary semantic entities are 
called /arbitrary units/, as opposed to /proper units/. The set of 
arbitrary units is denoted /A/, where /A/∩ /U/ = {}. *^ ■2 * An 
arbitrary unit has no further definition in the semantic framework of 
/The Unified Code for Units of Measure/ *^ ■3 * Arbitrary units are 
not “of any specific dimension” and are not “commensurable with” any 
other unit.


Until version 1.6 /The Unified Code for Units of Measure/ has dealt 
with arbitrary units as dimensionless, but as an effect the semantics 
of /The Unified Code for Units of Measure/ made all arbitrary units 
commensurable. Since version 1.7 of /The Unified Code for Units of 
Measure/ it is no longer possible to convert or compare arbitrary 
units with any other arbitrary unit.


*§25 operations on arbitrary units* *^ ■1 * Any term involving 
arbitrary units, is itself an arbitrary unit and is not comparable 
with any other arbitrary unit or term.


*§26 definition of arbitrary units* *^ ■1 * Arbitrary units are marked 
in the definition tables for unit atoms by a bullet (‘•’) in the 
column titled “value” and a bullet in the column titled “definition”.




Gerard Freriks
+31 620347088
gf...@luna.nl <mailto:gf...@luna.nl>


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

Re: UCUM code in body temperature archetype

[Gerard Freriks (privé)]

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 of Arbitrary Units?
 <>3.2 
ARBITRARY UNITS
 <>§24 arbitrary units   ■1 Arbitrary or procedure defined units are units 
whose meaning entirely depends on the measurement procedure (assay). These 
units have no general meaning in relation with any other unit in the SI. 
Therefore those arbitrary semantic entities are called arbitrary units, as 
opposed to proper units. The set of arbitrary units is denoted A, where A∩ U = 
{}.   ■2 An arbitrary unit has no further definition in the semantic framework 
of The Unified Code for Units of Measure  ■3 Arbitrary units are not “of any 
specific dimension” and are not “commensurable with” any other unit.

Until version 1.6 The Unified Code for Units of Measure has dealt with 
arbitrary units as dimensionless, but as an effect the semantics of The Unified 
Code for Units of Measure made all arbitrary units commensurable. Since version 
1.7 of The Unified Code for Units of Measure it is no longer possible to 
convert or compare arbitrary units with any other arbitrary unit.

 <>§25 operations on arbitrary units   ■1 Any term involving arbitrary 
units, is itself an arbitrary unit and is not comparable with any other 
arbitrary unit or term.

 <>§26 definition of arbitrary units   ■1 Arbitrary units are marked in the 
definition tables for unit atoms by a bullet (‘•’) in the column titled “value” 
and a bullet in the column titled “definition”.



Gerard Freriks
+31 620347088
gf...@luna.nl <mailto:gf...@luna.nl>
> On 18 mei 2016, at 13:41, 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 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 that we need to embed not just the formal 
> form, but the human-readable form as well. So that's a fairly anodyne design 
> problem for the Quantity type in everyone's type system. I think we can solve 
> that in a reasonable way in openEHR.
> 
>> 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.
>> 
>> A secondary problem is discrete units like tablet, capsule etc which have no 
>> computable form in ucum
> 
> I suspect this is the main problem for some people at least these days. 
> Scientifically speaking, anything like 'tablet', 'capsule', 'drop' etc isn't 
> a 'unit' in the science/physics sense; but in English (and most other 
> languages I suspect) we use the same word in a non-science sense to mean 
> 'discrete amount of anything', e.g. unit shares, 5mg tablet is the unit of 
> dosing, and so on. This makes people think the problem can be solved within 
> the model / language of scientific units. It can't in any clean way.
> 
> So dose 'units' need to be understood as something different from scientific 
> units, and modelled in a different way. They are units of discretisation or 
> quantisation of material, not units of physical properties.
> 
> - thomas
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: UCUM code in body temperature archetype

[Grahame Grieve]

well, it's a question of where you keep your complexity and uncertainty.
Sure, you can exclude the uncertainty from the data type, and retain clear
and simple operations associated with the type. But that doesn't mean that
uncertainty goes away. You've just pushed it somewhere else. I agree that
the value proposition of putting in the data type is less clear for openEHR
than it is for FHIR, but I don't think you've accounted for the operational
costs of where you propose to put the complexity. I argue that you should
just eat the complexity into DV_QUANTITY because:
- that's where the real 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 that outcome of trying
them might be undefined - but it might be already if the ucum units don't
have matching dimensions. So - least cost is to put it into the data type

Grahame


On Thu, May 19, 2016 at 5:45 AM, Thomas Beale <thomas.be...@openehr.org>
wrote:

> Grahame,
>
> I think you are saying that you can implement the *semantics *of dose
> units with just a DvQantity / FHIR Quantity. If 'dose units' includes the
> knowledge of the discrete unit of delivery, i.e. table, drop etc, as well
> as total amount, you can't. You need at least the elements here, or their
> equivalent.
>
> class DoseQuantity
> unitForm: DvCodedText // type of physical dose entity tablet,
> capsule, puff etc
> unitAmount: DvQuantity// how much is in a `doseForm` unit e.g.
> 5mg
> doseCount: Integer// how many items of `doseForm` to
> deliver
>
> doseAmount: DvQuantity {  // total amount of substance delivered
> to patient
> Result := doseCount * unitAmount
> }
> end
>
> If on the other hand you are saying we just go the pseudo-units route,
> where 'tablet' is a kind of unit, we can, but the Quantity library won't
> work properly anymore, because you no longer know if you can add two
> quantities even if they have the same unit, because 'tablet' as a unit
> doesn't mean anything. Where I am coming from is: Quantity is not just
> data, it is operations and computing
> <http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_quantity_package>;
> it includes operators like:
>
>- DV_AMOUNT: =, +, -, *, etc
>- DV_ABSOLUTE_QUANTITY: diff, add, subtract
>
> (there are many ways to model this kind of thing, that's just the openEHR
> way).
>
> If you are saying: use a code + code-system approach, and check the code
> 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 style of Quantity
>
> So, in terms of what we do in openEHR, I don't think it makes sense. In
> terms of FHIR, it makes sense; but I have to check a FHIR Quantity and
> instantiate different kinds of RM structures depending on the units code
> system.
>
> - thomas
> On 18/05/2016 17:58, Grahame Grieve wrote:
>
> 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 used will
> achieve that. A processor will know when it can use ucum based logic - not
> that I've ever seen that in the real world - and it will know when it can't
>
> Eric's part of this thread notes the issues with doing with this
> implicitly, so I'm not advocating for that, which brings you back to the
> FHIR model: human units, and system + code for computable units.
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>



-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Thomas Beale]

Grahame,

I think you are saying that you can implement the /semantics /of dose 
units with just a DvQantity / FHIR Quantity. If 'dose units' includes 
the knowledge of the discrete unit of delivery, i.e. table, drop etc, as 
well as total amount, you can't. You need at least the elements here, or 
their equivalent.


class DoseQuantity
unitForm: DvCodedText // type of physical dose entity 
tablet, capsule, puff etc
unitAmount: DvQuantity// how much is in a `doseForm` unit 
e.g. 5mg
doseCount: Integer// how many items of `doseForm` to 
deliver


doseAmount: DvQuantity {  // total amount of substance 
delivered to patient

Result := doseCount * unitAmount
}
end

If on the other hand you are saying we just go the pseudo-units route, 
where 'tablet' is a kind of unit, we can, but the Quantity library won't 
work properly anymore, because you no longer know if you can add two 
quantities even if they have the same unit, because 'tablet' as a unit 
doesn't mean anything. Where I am coming from is: Quantity is not just 
data, it is operations and computing 
<http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_quantity_package>; 
it includes operators like:


 * DV_AMOUNT: =, +, -, *, etc
 * DV_ABSOLUTE_QUANTITY: diff, add, subtract

(there are many ways to model this kind of thing, that's just the 
openEHR way).


If you are saying: use a code + code-system approach, and check the code 
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 style of Quantity

So, in terms of what we do in openEHR, I don't think it makes sense. In 
terms of FHIR, it makes sense; but I have to check a FHIR Quantity and 
instantiate different kinds of RM structures depending on the units code 
system.


- thomas

On 18/05/2016 17:58, Grahame Grieve wrote:

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 
used will achieve that. A processor will know when it can use ucum 
based logic - not that I've ever seen that in the real world - and it 
will know when it can't


Eric's part of this thread notes the issues with doing with this 
implicitly, so I'm not advocating for that, which brings you back to 
the FHIR model: human units, and system + code for computable units.


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

Re: UCUM code in body temperature archetype

[Grahame Grieve]

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 used will achieve that. A 
processor will know when it can use ucum based logic - not that I've ever seen 
that in the real world - and it will know when it can't 

Eric's part of this thread notes the issues with doing with this implicitly, so 
I'm not advocating for that, which brings you back to the FHIR model: human 
units, and system + code for computable units.

Grahame

> On 18 May 2016, at 10:06 PM, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> 
> 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 
> basic principles in science e.g.
> 
> there are only 9 primitive physical properties;
> all other physical properties can be obtained by combining the 9 primitive 
> ones, e.g. pressure = mass/area; area = length^2;
> various mathematical properties hold for true amounts (these can be described 
> formally)
> etc
> These things don't hold for 'dose units', because they are not the same kind 
> of thing. They can't be modelled or computed in the same way.
> 
> So there are two choices:
> 
> hack a clean model / library of scientific units to force it to deal with 
> non-units; these creates dirty code and bugs, and lots of if/then exception 
> conditions
> write a new clean model of the new kind of units, and integrate it with the 
> basic scientific units model.
> I am only interested in one thing here: clarity for coders and data, which 
> translates to error-reduction, better quality data and more maintainable code 
> in the long run.
> 
> The final result may not be particularly differentiated on the screen, or 
> even consciously understood by end users, but they are miles away from the 
> models and code inside the systems we build.
> - thomas
> 
>> On 18/05/2016 12:54, Grahame Grieve wrote:
>> The arbitrary units are something different, but why does that matter at the 
>> data type level? If you understand the unit, you can work with it, if you 
>> don't you can't. Separating them because of ... Ontological ... Purity: just 
>> creates make -work for all the users who otherwise don't differentiate them
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Ian McNicoll]

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.

https://openehr.atlassian.net/browse/AEPR-44?focusedCommentId=14127=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14127

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 18 May 2016 at 14:03, Peter Gummer  wrote:

> 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 you
> provided but even after that it was still complaining. I never got to the
> bottom of what was causing it.
>
> Looking at GitHub, nothing resembling your corrections appears to have
> made it there yet:
>
>
> https://github.com/openEHR/arch_ed-dotnet/commits/master/ArchetypeEditor/PropertyUnits
>
> I would suggest that the best way to proceed would be to add the fixes
> again, but proceed slowly, testing your file in AE after every few changes.
> Keep a backup copy after each successful test. Then, if AE complains about
> a small set of changes, it will be easy to identify what has caused it.
>
> Peter
>
>
> > On 18 May 2016, at 22:37, Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no> wrote:
> >
> > They usually are, though the units file in the Archetype Editor has had
> (still has?) a lot of errors in it, which means the correct units had to be
> edited into the ADL by hand. I made a better version of the units file for
> the AE a while ago, but there were some issues with it that I'm not sure if
> have been solved or if it's made its way into a release.
> >
> > Regards,
> > Silje
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: UCUM code in body temperature archetype

[Bakke, Silje Ljosland]

Ah yes, that's definitely not right. There are actually two blood glucose 
archetypes, and the other one has 'IU' (which should be [iU]).

Probably all of the current OBSERVATION.lab_test* and 
OBSERVATION.pathology_test* archetypes should be deprecated and (some of them) 
redone as either cluster extensions or specialisations of the newer 
OBSERVATION.laboratory_test archetype.

I think it would be very useful if you would be willing to proof read my 
Archetype Editor units file if we can ever get it into a form that the AE will 
accept. :)

Regards,
Silje


-Original Message-
From: 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' 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:-

10*3/L  =  /mL
10*6/L  =  /uL
10*9/L  =  /nL

with all 6 codes being valid.

regards,
eric

> On 18 May 2016, at 11:43 pm, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> Hah, thanks for that correction, I completely missed the '0' instead 
> of 'O' and the 'mho'. J
>  
> 'U' is certainly wrong if used for international units, as you say, but for 
> the liver tests ALP, ALT, AST, GGT and LD the test is actually measuring 
> catalytic activity, so U/L should be correct. Not sure where 'U' by itself is 
> used.
>  
> Regards,
> Silje
>  
> -Original Message-
> From: openEHR-technical 
> [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Eric 
> Browne
> Sent: Wednesday, May 18, 2016 3:49 PM
> To: For openEHR technical discussions 
> <openehr-technical@lists.openehr.org>
> Subject: 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 in 
> Appendix D Example Unit Terms at http://unitsofmeasure.org/ucum.html.
>  
> The same is likely to occur in the case of Litre, with 'l' (lowercase 
> L) vs '1' (numeral one) vs 'I' (capital letter eye), depending on 
> typefaces used. That's why many health safety organisations favour 'L'  
> for Litre over the lowercase variant. UCUM unfortunately allows either 
> as case sensitive variants ( which strictly means that this particular 
> unit is not case sensitive in the case sensitive case)  :-(
>  
> Also, despite 'U'  being a valid UCUM unit, it is probably incorrectly used 
> in the CKM archetypes. The correct UCUM unit code for international unit 
> should be "[iU]" or "[IU]" - another case of case variants for supposedly 
> case-sensitive units. 'U' is the UCUM code for catalytic activity. Same 
> applies for 'U/l', which may be valid UCUM syntactically, but unlikely to be 
> correct semantically in the liver function test archetype.
>  
> Also mmho is correct UCUM. A mho is a unit of electrical conductance ( 
> It comes from Ohm, the unit for resistance, spelt backwards. Ohm 
> starts with a capital letter since named after a human, whereas mho 
> does not). mho as been deprecated as an SI unit and renamed to 
> siemens, but is retained and valid in UCUM. mmho was found in 
> openEHR-EHR-OBSERVATION.tympanogram_hf.v1.adl
>  
>  
>  
>  
> regards,
> eric
>  
>  
>  
> > On 18 May 2016, at 10:05 pm, Bakke, Silje Ljosland 
> > <silje.ljosland.ba...@nasjonalikt.no> wrote:
> > 
> > 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, pg, pmol/l, s,
> > 
> > Non-UCUM:
> > /d, /h, /min, /mo, /wk, Ashman units, 10*12/l, 10*6/l, 10*6/mm3, 
> > 10*9/l, , IU, cc, dB, fl, , fl oz, ft, in, in2, lb, lb/in2, mIU/l, 
> > millisec, oz(avdp), °, °C, °F, µmol/
> > 
> > Just plain wrong:
> > gm, gm/d, gm/l, gm/wk (gm == "gram meter", not "gram") mmho 
> > (supposed to be mm/h or mm.h? Does anyone know which archetype this 
> > comes from?)
> > 
> > Not 100% s

Re: UCUM code in body temperature archetype

[Eric Browne]

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:-

10*3/L  =  /mL
10*6/L  =  /uL
10*9/L  =  /nL

with all 6 codes being valid.

regards,
eric

> On 18 May 2016, at 11:43 pm, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> Hah, thanks for that correction, I completely missed the '0' instead of 'O' 
> and the ‘mho’. J
>  
> ‘U’ is certainly wrong if used for international units, as you say, but for 
> the liver tests ALP, ALT, AST, GGT and LD the test is actually measuring 
> catalytic activity, so U/L should be correct. Not sure where ‘U’ by itself is 
> used.
>  
> Regards,
> Silje
>  
> -Original Message-
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
> On Behalf Of Eric Browne
> Sent: Wednesday, May 18, 2016 3:49 PM
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
> Subject: 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 in 
> Appendix D Example Unit Terms at http://unitsofmeasure.org/ucum.html.
>  
> The same is likely to occur in the case of Litre, with ‘l’ (lowercase L) vs 
> ‘1’ (numeral one) vs ‘I’ (capital letter eye), depending on typefaces used. 
> That’s why many health safety organisations favour ‘L’  for Litre over the 
> lowercase variant. UCUM unfortunately allows either as case sensitive 
> variants ( which strictly means that this particular unit is not case 
> sensitive in the case sensitive case)  :-(
>  
> Also, despite ‘U’  being a valid UCUM unit, it is probably incorrectly used 
> in the CKM archetypes. The correct UCUM unit code for international unit 
> should be “[iU]” or “[IU]” - another case of case variants for supposedly 
> case-sensitive units. ‘U’ is the UCUM code for catalytic activity. Same 
> applies for ‘U/l’, which may be valid UCUM syntactically, but unlikely to be 
> correct semantically in the liver function test archetype.
>  
> Also mmho is correct UCUM. A mho is a unit of electrical conductance ( It 
> comes from Ohm, the unit for resistance, spelt backwards. Ohm starts with a 
> capital letter since named after a human, whereas mho does not). mho as been 
> deprecated as an SI unit and renamed to siemens, but is retained and valid in 
> UCUM. mmho was found in openEHR-EHR-OBSERVATION.tympanogram_hf.v1.adl
>  
>  
>  
>  
> regards,
> eric
>  
>  
>  
> > On 18 May 2016, at 10:05 pm, Bakke, Silje Ljosland 
> > <silje.ljosland.ba...@nasjonalikt.no> wrote:
> > 
> > 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, pg, pmol/l, s,
> > 
> > Non-UCUM:
> > /d, /h, /min, /mo, /wk, Ashman units, 10*12/l, 10*6/l, 10*6/mm3, 
> > 10*9/l, , IU, cc, dB, fl, , fl oz, ft, in, in2, lb, lb/in2, mIU/l, 
> > millisec, oz(avdp), °, °C, °F, µmol/
> > 
> > Just plain wrong:
> > gm, gm/d, gm/l, gm/wk (gm == "gram meter", not "gram") mmho (supposed 
> > to be mm/h or mm.h? Does anyone know which archetype this comes from?)
> > 
> > Not 100% sure:
> > {Volume/Volume}
> > 
> > So quite a few units in archetypes are actually UCUM-compatible, but there 
> > are plenty which aren't, and some which are wrong and can be badly 
> > misinterpreted.
> > 
> > Oh, and UCUM does allow non-units to be represented using curly braces, 
> > like {puff} or {tablet} as symbols for the default unit '1'.
> > 
> > Regards,
> > Silje
>  
>  
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


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

Re: UCUM code in body temperature archetype

[Eric Browne]

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 in 
Appendix D Example Unit Terms at http://unitsofmeasure.org/ucum.html.

The same is likely to occur in the case of Litre, with ‘l’ (lowercase L) vs ‘1’ 
(numeral one) vs ‘I’ (capital letter eye), depending on typefaces used. That’s 
why many health safety organisations favour ‘L’  for Litre over the lowercase 
variant. UCUM unfortunately allows either as case sensitive variants ( which 
strictly means that this particular unit is not case sensitive in the case 
sensitive case)  :-(

Also, despite ‘U’  being a valid UCUM unit, it is probably incorrectly used in 
the CKM archetypes. The correct UCUM unit code for international unit should be 
“[iU]” or “[IU]” - another case of case variants for supposedly case-sensitive 
units. ‘U’ is the UCUM code for catalytic activity. Same applies for ‘U/l’, 
which may be valid UCUM syntactically, but unlikely to be correct semantically 
in the liver function test archetype.

Also mmho is correct UCUM. A mho is a unit of electrical conductance ( It comes 
from Ohm, the unit for resistance, spelt backwards. Ohm starts with a capital 
letter since named after a human, whereas mho does not). mho as been deprecated 
as an SI unit and renamed to siemens, but is retained and valid in UCUM. mmho 
was found in openEHR-EHR-OBSERVATION.tympanogram_hf.v1.adl




regards,
eric



> On 18 May 2016, at 10:05 pm, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> 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, pg, pmol/l, s, 
> 
> Non-UCUM:
> /d, /h, /min, /mo, /wk, Ashman units, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, , 
> IU, cc, dB, fl, , fl oz, ft, in, in2, lb, lb/in2, mIU/l, millisec, oz(avdp), 
> °, °C, °F, µmol/
> 
> Just plain wrong:
> gm, gm/d, gm/l, gm/wk (gm == "gram meter", not "gram")
> mmho (supposed to be mm/h or mm.h? Does anyone know which archetype this 
> comes from?)
> 
> Not 100% sure:
> {Volume/Volume}
> 
> So quite a few units in archetypes are actually UCUM-compatible, but there 
> are plenty which aren't, and some which are wrong and can be badly 
> misinterpreted.
> 
> Oh, and UCUM does allow non-units to be represented using curly braces, like 
> {puff} or {tablet} as symbols for the default unit '1'.
> 
> Regards,
> Silje


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

Re: UCUM code in body temperature archetype

[Peter Gummer]

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 you provided but even 
after that it was still complaining. I never got to the bottom of what was 
causing it.

Looking at GitHub, nothing resembling your corrections appears to have made it 
there yet:


https://github.com/openEHR/arch_ed-dotnet/commits/master/ArchetypeEditor/PropertyUnits

I would suggest that the best way to proceed would be to add the fixes again, 
but proceed slowly, testing your file in AE after every few changes. Keep a 
backup copy after each successful test. Then, if AE complains about a small set 
of changes, it will be easy to identify what has caused it.

Peter


> On 18 May 2016, at 22:37, Bakke, Silje Ljosland 
>  wrote:
> 
> They usually are, though the units file in the Archetype Editor has had 
> (still has?) a lot of errors in it, which means the correct units had to be 
> edited into the ADL by hand. I made a better version of the units file for 
> the AE a while ago, but there were some issues with it that I'm not sure if 
> have been solved or if it's made its way into a release.
> 
> Regards,
> Silje


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

Re: UCUM code in body temperature archetype

[Thomas Beale]

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 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 to explain the reason for, and ramifications arising 
from this issue in a previous post. That post arose from Heather Leslie’s 
concerns about potential major changes to the coveted blood pressure archetype 
- see 
https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg09185.html.

In that post I stated "Even basic archetypes like Body Temperature define units 
which are not UCUM-conformant. I consider this to be a more serious issue than the tilt 
angle of a person whose blood pressure is being recorded."

At that time Thomas suggested I raise a Problem Report, but  so far  I have 
failed to do so.

There are also the related PRs:

https://openehr.atlassian.net/browse/SPECPR-13
https://openehr.atlassian.net/browse/SPECPR-96




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

Re: UCUM code in body temperature archetype

[Diego Boscá]

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, 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, pg, pmol/l, s,
>
> Non-UCUM:
> /d, /h, /min, /mo, /wk, Ashman units, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, , 
> IU, cc, dB, fl, , fl oz, ft, in, in2, lb, lb/in2, mIU/l, millisec, oz(avdp), 
> °, °C, °F, µmol/
>
> Just plain wrong:
> gm, gm/d, gm/l, gm/wk (gm == "gram meter", not "gram")
> mmho (supposed to be mm/h or mm.h? Does anyone know which archetype this 
> comes from?)
>
> Not 100% sure:
> {Volume/Volume}
>
> So quite a few units in archetypes are actually UCUM-compatible, but there 
> are plenty which aren't, and some which are wrong and can be badly 
> misinterpreted.
>
> Oh, and UCUM does allow non-units to be represented using curly braces, like 
> {puff} or {tablet} as symbols for the default unit '1'.
>
> Regards,
> Silje
>
>
> -Original Message-
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
> On Behalf Of Eric Browne
> Sent: Wednesday, May 18, 2016 2:03 PM
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
> Subject: Re: UCUM code in body temperature archetype
>
> I just did a bulk download of 133 Observation archetypes from ckm.openehr.org 
> and extracted the following list of units:-
>
> /d, /h, /min, /mo, /wk, 1/min, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, Ashman 
> units, Hz, Hz/s, IU, U, U/l, [pH], cc, cm, cm2, cm[H20], d, dB, daPa, daPa/s, 
> deg, fl, fl oz, ft, gm, gm/d, gm/l, gm/wk, h, in, in2, kHz, kPa, kg, kg/m2, 
> l, l/min, l/s, lb, lb/in2, m, m2, mIU/l, mV, mg, mg/dl, mg/l, millisec, min, 
> ml, ml/d, ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], 
> mmho, mmol/l, oz(avdp), pg, pmol/l, s, {Volume/Volume}, °, °C, °F, µmol/
>
> I did this with a script and have not manually validated this list visually 
> in the 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 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 
>> parseable and so on).
>> - thomas
>> On 18/05/2016 10:05, Daniel Karlsson wrote:
>>> So, right now the DV_QUANTITY.units is a String, perhaps it should be 
>>> DV_CODED_TEXT?
>>>
>>> /Daniel
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
>> ehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

RE: UCUM code in body temperature archetype

[Bakke, Silje Ljosland]

They usually are, though the units file in the Archetype Editor has had (still 
has?) a lot of errors in it, which means the correct units had to be edited 
into the ADL by hand. I made a better version of the units file for the AE a 
while ago, but there were some issues with it that I'm not sure if have been 
solved or if it's made its way into a release.

Regards,
Silje


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Sebastian Garde
Sent: Wednesday, May 18, 2016 2:26 PM
To: For openEHR technical discussions <openehr-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 check is available for each archetype (or for all archetypes from 
Reports/Validation Report when logged in).
I think the validation errors are usually fixed when the archetype is updated 
the next time.

Regards
Sebastian


-Ursprüngliche Nachricht-
Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Eric Browne
Gesendet: Mittwoch, 18. 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 units in various 
DV_QUANTITY elements. I would guess up to 30% of Observation archetypes have 
some ‘invalid' UCUM unit.

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

RE: UCUM code in body temperature archetype

[Bakke, Silje Ljosland]

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, pg, pmol/l, s, 

Non-UCUM:
/d, /h, /min, /mo, /wk, Ashman units, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, , IU, 
cc, dB, fl, , fl oz, ft, in, in2, lb, lb/in2, mIU/l, millisec, oz(avdp), °, °C, 
°F, µmol/

Just plain wrong:
gm, gm/d, gm/l, gm/wk (gm == "gram meter", not "gram")
mmho (supposed to be mm/h or mm.h? Does anyone know which archetype this comes 
from?)

Not 100% sure:
{Volume/Volume}

So quite a few units in archetypes are actually UCUM-compatible, but there are 
plenty which aren't, and some which are wrong and can be badly misinterpreted.

Oh, and UCUM does allow non-units to be represented using curly braces, like 
{puff} or {tablet} as symbols for the default unit '1'.

Regards,
Silje


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Eric Browne
Sent: Wednesday, May 18, 2016 2:03 PM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: UCUM code in body temperature archetype

I just did a bulk download of 133 Observation archetypes from ckm.openehr.org 
and extracted the following list of units:-

/d, /h, /min, /mo, /wk, 1/min, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, Ashman units, 
Hz, Hz/s, IU, U, U/l, [pH], cc, cm, cm2, cm[H20], d, dB, daPa, daPa/s, deg, fl, 
fl oz, ft, gm, gm/d, gm/l, gm/wk, h, in, in2, kHz, kPa, kg, kg/m2, l, l/min, 
l/s, lb, lb/in2, m, m2, mIU/l, mV, mg, mg/dl, mg/l, millisec, min, ml, ml/d, 
ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], mmho, mmol/l, 
oz(avdp), pg, pmol/l, s, {Volume/Volume}, °, °C, °F, µmol/ 

I did this with a script and have not manually validated this list visually in 
the 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 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 
> parseable and so on).
> - thomas
> On 18/05/2016 10:05, Daniel Karlsson wrote:
>> So, right now the DV_QUANTITY.units is a String, perhaps it should be 
>> DV_CODED_TEXT?
>> 
>> /Daniel
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.org


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

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

Re: UCUM code in body temperature archetype

[Karsten Hilbert]

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

-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

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

AW: UCUM code in body temperature archetype

[Sebastian Garde]

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 check is available for each archetype (or for all archetypes from 
Reports/Validation Report when logged in).
I think the validation errors are usually fixed when the archetype is updated 
the next time.

Regards
Sebastian


-Ursprüngliche Nachricht-
Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Eric Browne
Gesendet: Mittwoch, 18. 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 units in various 
DV_QUANTITY elements. I would guess up to 30% of Observation archetypes have 
some ‘invalid' UCUM unit.

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

Re: UCUM code in body temperature archetype

[David Moner]

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. We should not store the readable form of the unit everywhere.


Apart from that, I think that trying to avoid unscientific units should be,
as far as possible, a requirement the modeling activities. FYI:

Spoons lead to inaccurate medicine doses for kids (
http://www.nhs.uk/news/2014/07July/Pages/Spoons-lead-to-inaccurate-medicine-doses-for-kids.aspx
)

-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Diego Boscá]

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 °).
>
> https://en.wikipedia.org/wiki/Numero_sign
>
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: UCUM code in body temperature archetype

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

https://en.wikipedia.org/wiki/Numero_sign

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

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

Re: UCUM code in body temperature archetype

[Eric Browne]

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 to explain the reason for, and ramifications arising 
from this issue in a previous post. That post arose from Heather Leslie’s 
concerns about potential major changes to the coveted blood pressure archetype 
- see 
https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg09185.html.

In that post I stated "Even basic archetypes like Body Temperature define units 
which are not UCUM-conformant. I consider this to be a more serious issue than 
the tilt angle of a person whose blood pressure is being recorded."

At that time Thomas suggested I raise a Problem Report, but  so far  I have 
failed to do so.

There are also the related PRs:

https://openehr.atlassian.net/browse/SPECPR-13
https://openehr.atlassian.net/browse/SPECPR-96

regards,
eric

Eric Browne
eric.bro...@montagesystems.com.au
ph 0414 925 845
skype: eric_browne


> On 18 May 2016, at 5:55 pm, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> 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 (which 
> is to my mind the only way to go), is that there’s as far as I know no way to 
> include both the code and the print symbol in the archetype. 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.
>  
> Kind regards,
> Silje Ljosland Bakke
>  
> Information Architect, RN
> Coordinator, National Editorial Board for Archetypes
> National ICT Norway
> 
> Tel. +47 40203298
> Web: http://arketyper.no / Twitter: @arketyper_no
>  
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
> On Behalf Of Daniel Karlsson
> Sent: Wednesday, May 18, 2016 10:09 AM
> To: openehr-technical@lists.openehr.org
> Subject: 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 Karlsson, PhD, sr lecturer
> Department of Biomedical Engineering/Health informatics
> Linköping university
> SE-58185 Linköping
> Sweden
> Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


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

Re: UCUM code in body temperature archetype

[Diego Boscá]

very interesting, seems like a few archetypes need to be changed

2016-05-18 14:03 GMT+02:00 Eric Browne <eric.bro...@montagesystems.com.au>:
> I just did a bulk download of 133 Observation archetypes from ckm.openehr.org 
> and extracted the following list of units:-
>
> /d, /h, /min, /mo, /wk, 1/min, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, Ashman 
> units, Hz, Hz/s, IU, U, U/l,
> [pH], cc, cm, cm2, cm[H20], d, dB, daPa, daPa/s, deg, fl, fl oz, ft, gm, 
> gm/d, gm/l, gm/wk, h, in,
> in2, kHz, kPa, kg, kg/m2, l, l/min, l/s, lb, lb/in2, m, m2, mIU/l, mV, mg, 
> mg/dl, mg/l, millisec, min,
> ml, ml/d, ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], 
> mmho, mmol/l, oz(avdp), pg,
> pmol/l, s, {Volume/Volume}, °, °C, °F, µmol/
>
> I did this with a script and have not manually validated this list visually 
> in the 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 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 
>> parseable and so on).
>> - thomas
>> On 18/05/2016 10:05, Daniel Karlsson wrote:
>>> So, right now the DV_QUANTITY.units is a String, perhaps it should be 
>>> DV_CODED_TEXT?
>>>
>>> /Daniel
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: UCUM code in body temperature archetype

[Thomas Beale]

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 basic principles in science e.g.


1. there are only 9 primitive physical properties;
2. all other physical properties can be obtained by combining the 9
   primitive ones, e.g. pressure = mass/area; area = length^2;
3. various mathematical properties hold for true amounts (these can be
   described formally)
4. etc

These things don't hold for 'dose units', because they are not the same 
kind of thing. They can't be modelled or computed in the same way.


So there are two choices:

 * hack a clean model / library of scientific units to force it to deal
   with non-units; these creates dirty code and bugs, and lots of
   if/then exception conditions
 * write a new clean model of the new kind of units, and integrate it
   with the basic scientific units model.

I am only interested in one thing here: clarity for coders and data, 
which translates to error-reduction, better quality data and more 
maintainable code in the long run.


The final result may not be particularly differentiated on the screen, 
or even consciously understood by end users, but they are miles away 
from the models and code inside the systems we build.


- thomas


On 18/05/2016 12:54, Grahame Grieve wrote:
The arbitrary units are something different, but why does that matter 
at the data type level? If you understand the unit, you can work with 
it, if you don't you can't. Separating them because of ... Ontological 
... Purity: just creates make -work for all the users who otherwise 
don't differentiate them


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

Re: UCUM code in body temperature archetype

[Eric Browne]

I just did a bulk download of 133 Observation archetypes from ckm.openehr.org 
and extracted the following list of units:-

/d, /h, /min, /mo, /wk, 1/min, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, Ashman units, 
Hz, Hz/s, IU, U, U/l, 
[pH], cc, cm, cm2, cm[H20], d, dB, daPa, daPa/s, deg, fl, fl oz, ft, gm, gm/d, 
gm/l, gm/wk, h, in, 
in2, kHz, kPa, kg, kg/m2, l, l/min, l/s, lb, lb/in2, m, m2, mIU/l, mV, mg, 
mg/dl, mg/l, millisec, min, 
ml, ml/d, ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], mmho, 
mmol/l, oz(avdp), pg, 
pmol/l, s, {Volume/Volume}, °, °C, °F, µmol/ 

I did this with a script and have not manually validated this list visually in 
the 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 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 
> parseable and so on).
> - thomas
> On 18/05/2016 10:05, Daniel Karlsson wrote:
>> So, right now the DV_QUANTITY.units is a String, perhaps it should be 
>> DV_CODED_TEXT?
>> 
>> /Daniel
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


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

Re: UCUM code in body temperature archetype

[Diego Boscá]

If you have a human-readable form for 'º' as "degree" you probably
want that non-english speaking countries can put "grado"

2016-05-18 13:52 GMT+02:00 Grahame Grieve <graha...@gmail.com>:
> Really? No one has ever brought that to us as an requirement
>
> Grahame
>
>> 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>:
>>>
>>> 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 that we need to embed not just the
>>> formal form, but the human-readable form as well. So that's a fairly anodyne
>>> design problem for the Quantity type in everyone's type system. I think we
>>> can solve that in a reasonable way in openEHR.
>>>
>>> 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.
>>>
>>> A secondary problem is discrete units like tablet, capsule etc which have no
>>> computable form in ucum
>>>
>>>
>>> I suspect this is the main problem for some people at least these days.
>>> Scientifically speaking, anything like 'tablet', 'capsule', 'drop' etc isn't
>>> a 'unit' in the science/physics sense; but in English (and most other
>>> languages I suspect) we use the same word in a non-science sense to mean
>>> 'discrete amount of anything', e.g. unit shares, 5mg tablet is the unit of
>>> dosing, and so on. This makes people think the problem can be solved within
>>> the model / language of scientific units. It can't in any clean way.
>>>
>>> So dose 'units' need to be understood as something different from scientific
>>> units, and modelled in a different way. They are units of discretisation or
>>> quantisation of material, not units of physical properties.
>>>
>>> - thomas
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: UCUM code in body temperature archetype

[Thomas Beale]

On 18/05/2016 12:24, Ian McNicoll wrote:

Hi thomas,

See https://openehr.atlassian.net/browse/SPECPR-96 for discussion on 
this. Medication dose and quantities need both SI units and otherwise. 
The current restrictions make the modelling much clunkier than is 
necessary IMO. I'm not clear why strict adherence to SI is helpful in 
this context. Surely part of the point of a health orientated ref 
model is to make life easier and medication dose units are a critical 
type of quantity in this domain.


I was reviewing that (good statement of needs). The issue isn't SI units 
- 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 that we have not really done so.


The more I think about this issue over the years, I mostly come to the 
same conclusion: we need a special Quantity type that models exactly 
what is needed. E.g. something like


class DoseQuantity
unitForm: DvCodedText  // type of physical dose entity 
tablet, capsule, puff etc
unitAmount: DvQuantity// how much is in a `doseForm` unit 
e.g. 5mg
doseCount: Integer // how many items of `doseForm` 
to deliver


doseAmount: DvQuantity { // total amount of substance delivered 
to patient

Result := doseCount * unitAmount
}
end

Note that this does not include the actual substance, e.g. morphine or 
whatever.


- thomas


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

Re: UCUM code in body temperature archetype

[Grahame Grieve]

The arbitrary units are something different, but why does that matter at the 
data type level? If you understand the unit, you can work with it, if you don't 
you can't. Separating them because of ... Ontological ... Purity: just creates 
make -work for all the users who otherwise don't 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 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 that we need to embed not just the formal 
> form, but the human-readable form as well. So that's a fairly anodyne design 
> problem for the Quantity type in everyone's type system. I think we can solve 
> that in a reasonable way in openEHR.
> 
>> 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.
>> 
>> A secondary problem is discrete units like tablet, capsule etc which have no 
>> computable form in ucum
> 
> I suspect this is the main problem for some people at least these days. 
> Scientifically speaking, anything like 'tablet', 'capsule', 'drop' etc isn't 
> a 'unit' in the science/physics sense; but in English (and most other 
> languages I suspect) we use the same word in a non-science sense to mean 
> 'discrete amount of anything', e.g. unit shares, 5mg tablet is the unit of 
> dosing, and so on. This makes people think the problem can be solved within 
> the model / language of scientific units. It can't in any clean way.
> 
> So dose 'units' need to be understood as something different from scientific 
> units, and modelled in a different way. They are units of discretisation or 
> quantisation of material, not units of physical properties.
> 
> - thomas
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Grahame Grieve]

Really? No one has ever brought that to us as an requirement 

Grahame

> 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>:
>> 
>> 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 that we need to embed not just the
>> formal form, but the human-readable form as well. So that's a fairly anodyne
>> design problem for the Quantity type in everyone's type system. I think we
>> can solve that in a reasonable way in openEHR.
>> 
>> 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.
>> 
>> A secondary problem is discrete units like tablet, capsule etc which have no
>> computable form in ucum
>> 
>> 
>> I suspect this is the main problem for some people at least these days.
>> Scientifically speaking, anything like 'tablet', 'capsule', 'drop' etc isn't
>> a 'unit' in the science/physics sense; but in English (and most other
>> languages I suspect) we use the same word in a non-science sense to mean
>> 'discrete amount of anything', e.g. unit shares, 5mg tablet is the unit of
>> dosing, and so on. This makes people think the problem can be solved within
>> the model / language of scientific units. It can't in any clean way.
>> 
>> So dose 'units' need to be understood as something different from scientific
>> units, and modelled in a different way. They are units of discretisation or
>> quantisation of material, not units of physical properties.
>> 
>> - thomas
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: UCUM code in body temperature archetype

[Diego Boscá]

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,
>
>
> 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 that we need to embed not just the
> formal form, but the human-readable form as well. So that's a fairly anodyne
> design problem for the Quantity type in everyone's type system. I think we
> can solve that in a reasonable way in openEHR.
>
> 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.
>
> A secondary problem is discrete units like tablet, capsule etc which have no
> computable form in ucum
>
>
> I suspect this is the main problem for some people at least these days.
> Scientifically speaking, anything like 'tablet', 'capsule', 'drop' etc isn't
> a 'unit' in the science/physics sense; but in English (and most other
> languages I suspect) we use the same word in a non-science sense to mean
> 'discrete amount of anything', e.g. unit shares, 5mg tablet is the unit of
> dosing, and so on. This makes people think the problem can be solved within
> the model / language of scientific units. It can't in any clean way.
>
> So dose 'units' need to be understood as something different from scientific
> units, and modelled in a different way. They are units of discretisation or
> quantisation of material, not units of physical properties.
>
> - thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: UCUM code in body temperature archetype

[Thomas Beale]

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 that we need to embed not just the 
formal form, but the human-readable form as well. So that's a fairly 
anodyne design problem for the Quantity type in everyone's type system. 
I think we can solve that in a reasonable way in openEHR.


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.


A secondary problem is discrete units like tablet, capsule etc which 
have no computable form in ucum


I suspect this is the /main /problem for some people at least these 
days. Scientifically speaking, anything like 'tablet', 'capsule', 'drop' 
etc isn't a 'unit' in the science/physics sense; but in English (and 
most other languages I suspect) we use the same word in a non-science 
sense to mean 'discrete amount of anything', e.g. unit shares, 5mg 
tablet is the unit of dosing, and so on. This makes people think the 
problem can be solved within the model / language of scientific units. 
It can't in any clean way.


So dose 'units' need to be understood as something different from 
scientific units, and modelled in a different way. They are units of 
discretisation or quantisation of material, not units of physical 
properties.


- thomas
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Ian McNicoll]

Hi thomas,

See https://openehr.atlassian.net/browse/SPECPR-96 for discussion on this.
Medication dose and quantities need both SI units and otherwise. The
current restrictions make the modelling much clunkier than is necessary
IMO. I'm not clear why strict adherence to SI is helpful in this context.
Surely part of the point of a health orientated ref model is to make life
easier and medication dose units are a critical type of quantity in this
domain.

Ian
On Wed, 18 May 2016 at 12:17, Thomas Beale <thomas.be...@openehr.org> wrote:

> Hi Ian
>
> As far as I know, 'dose units' are not scientific units as such; they're
> measures of discrete objects (including 'puffs' etc), which don't fit into
> a clean grammar of scientific units, and trying to do so will just ruin the
> former.
>
> We do of course need dose units, but we need a better way of modelling
> them - my view is that they should not be treated as if they were 'units'
> in the usual sense.
>
> The relevant SNOMED codes
> <http://browser.ihtsdotools.org/?perspective=full=408102007=en-edition=v20160131=http://browser.ihtsdotools.org/api/snomed=9000509007>
> seem to be these 'unit of product usage' codes, which is the correct kind
> of description.
>
> What is the current problem/issue with modelling 'dose units' in
> archetypes in fact? It looks to me like the current modelling approach
> (similar to FHIR) represents these elements in a reasonable 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
> SNOMED terms for dose units.
>
> FHIR has human + code + system for quantity units, I think?
>
> Ian
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Grahame Grieve]

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.

A secondary problem is discrete units like tablet, capsule etc which have no 
computable form in ucum

Grahame

> On 18 May 2016, at 9:17 PM, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> Hi Ian
> As far as I know, 'dose units' are not scientific units as such; they're 
> measures of discrete objects (including 'puffs' etc), which don't fit into a 
> clean grammar of scientific units, and trying to do so will just ruin the 
> former.
> 
> We do of course need dose units, but we need a better way of modelling them - 
> my view is that they should not be treated as if they were 'units' in the 
> usual sense.
> 
> The relevant SNOMED codes seem to be these 'unit of product usage' codes, 
> which is the correct kind of description.
> 
> What is the current problem/issue with modelling 'dose units' in archetypes 
> in fact? It looks to me like the current modelling approach (similar to FHIR) 
> represents these elements in a reasonable 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 
>> SNOMED terms for dose units.
>> 
>> FHIR has human + code + system for quantity units, I think?
>> 
>> Ian
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Thomas Beale]

Hi Ian

As far as I know, 'dose units' are not scientific units as such; they're 
measures of discrete objects (including 'puffs' etc), which don't fit 
into a clean grammar of scientific units, and trying to do so will just 
ruin the former.


We do of course need dose units, but we need a better way of modelling 
them - my view is that they should not be treated as if they were 
'units' in the usual sense.


The relevant SNOMED codes 
<http://browser.ihtsdotools.org/?perspective=full=408102007=en-edition=v20160131=http://browser.ihtsdotools.org/api/snomed=9000509007> 
seem to be these 'unit of product usage' codes, which is the correct 
kind of description.


What is the current problem/issue with modelling 'dose units' in 
archetypes in fact? It looks to me like the current modelling approach 
(similar to FHIR) represents these elements in a reasonable 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 SNOMED terms for dose units.


FHIR has human + code + system for quantity units, I think?

Ian



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

Re: UCUM code in body temperature archetype

[Thomas Beale]

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 another field to carry the rendered form.


- thomas

On 18/05/2016 10:11, Grahame Grieve wrote:

That's overkill - just have two fields, human and computable units.

Grahame

On 18 May 2016, at 7:05 PM, Daniel Karlsson <daniel.karls...@liu.se 
<mailto:daniel.karls...@liu.se>> wrote:




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

Re: UCUM code in body temperature archetype

[Thomas Beale]

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 can also be equated to e.g. 
'kPa' (which is itself parseable and so on).


- thomas

On 18/05/2016 10:05, Daniel Karlsson wrote:
So, right now the DV_QUANTITY.units is a String, perhaps it should be 
DV_CODED_TEXT?


/Daniel


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

Re: UCUM code in body temperature archetype

[Grahame Grieve]

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:
> 
> 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
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
> 
> 
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> 
>> On 18 May 2016 at 10:11, Grahame Grieve <graha...@gmail.com> wrote:
>> That's overkill - just have two fields, human and computable units.
>> 
>> Grahame
>> 
>>> On 18 May 2016, at 7:05 PM, Daniel Karlsson <daniel.karls...@liu.se> wrote:
>>> 
>>> 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 of 
>>>> the code, which in many cases is not readable to clinicians.
>>> 
>>> -- 
>>> Daniel Karlsson, PhD, sr lecturer
>>> Department of Biomedical Engineering/Health informatics
>>> Linköping university
>>> SE-58185 Linköping
>>> Sweden
>>> Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com
>>> 
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Ian McNicoll]

One option might be simply to do a per FHIR and 'hardwire' code + code
system, alongside units. This would retain backward compatibility. It would
prevent us using DV_TEXT features like mapping but in many respects that
might not be a bad thing.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 18 May 2016 at 10:22, Ian McNicoll <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 quantity units, I think?
>
> Ian
>
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 18 May 2016 at 10:11, Grahame Grieve <graha...@gmail.com> wrote:
>
>> That's overkill - just have two fields, human and computable units.
>>
>> Grahame
>>
>> On 18 May 2016, at 7:05 PM, Daniel Karlsson <daniel.karls...@liu.se>
>> wrote:
>>
>> 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 of
>> the code, which in many cases is not readable to clinicians.
>>
>>
>> --
>> Daniel Karlsson, PhD, sr lecturer
>> Department of Biomedical Engineering/Health informatics
>> Linköping university
>> SE-58185 Linköping
>> Sweden
>> Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com
>>
>> 
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Ian McNicoll]

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
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 18 May 2016 at 10:11, Grahame Grieve <graha...@gmail.com> wrote:

> That's overkill - just have two fields, human and computable units.
>
> Grahame
>
> On 18 May 2016, at 7:05 PM, Daniel Karlsson <daniel.karls...@liu.se>
> wrote:
>
> 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 of
> the code, which in many cases is not readable to clinicians.
>
>
> --
> Daniel Karlsson, PhD, sr lecturer
> Department of Biomedical Engineering/Health informatics
> Linköping university
> SE-58185 Linköping
> Sweden
> Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com
>
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Ian McNicoll]

Hi Daniel,

This is being discussed by the Specs group as part of a different CR around
use of 'dose units' but would mean a breaking change, so is tricky.

https://openehr.atlassian.net/browse/SPECPR-96

Ian



Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 18 May 2016 at 10:05, Daniel Karlsson <daniel.karls...@liu.se> wrote:

> 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 of
> the code, which in many cases is not readable to clinicians.
>
>
> --
> Daniel Karlsson, PhD, sr lecturer
> Department of Biomedical Engineering/Health informatics
> Linköping university
> SE-58185 Linköping
> Sweden
> Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Grahame Grieve]

That's overkill - just have two fields, human and computable units.

Grahame

> On 18 May 2016, at 7:05 PM, Daniel Karlsson <daniel.karls...@liu.se> wrote:
> 
> 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 of the 
>> code, which in many cases is not readable to clinicians.
> 
> -- 
> Daniel Karlsson, PhD, sr lecturer
> Department of Biomedical Engineering/Health informatics
> Linköping university
> SE-58185 Linköping
> Sweden
> Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Daniel Karlsson]

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 of the code, which in many cases is not readable to clinicians.


--
Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com

<>___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: UCUM code in body temperature archetype

[Bakke, Silje Ljosland]

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 (which is 
to my mind the only way to go), is that there’s as far as I know no way to 
include both the code and the print symbol in the archetype. 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.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Daniel Karlsson
Sent: Wednesday, May 18, 2016 10:09 AM
To: openehr-technical@lists.openehr.org
Subject: 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 Karlsson, PhD, sr lecturer

Department of Biomedical Engineering/Health informatics

Linköping university

SE-58185 Linköping

Sweden

Ph. +46 708350109, Skype: imt_danka, Hangout: 
daniel.e.karls...@gmail.com<mailto:daniel.e.karls...@gmail.com>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

UCUM code in body temperature archetype

[Daniel Karlsson]

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 Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com

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

UCUM

[Michael Osborne]

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 could use the same approach as an openEHR DV_PARSABLE, where the name
of the syntax is stored as well, but this is IMO inviting a different
kind of pain...

My answer would be: let's get UCUM doing everything we need (for the
formal units field I mean, not the informal one); if we can't, we need a
new UCUM.

- thomas


Hi Thomas,
   '^' is a special character in HL7 V2.x messages - so by changing '*'
back to '^' you would break implementations of HL7 ORU messages. We already
see this in some lab messages - if you try to parse the units field you get
x10 instead of x10^9/L, because OBX-6 is a coded element (CE) data type.
UCUM also uses annotations which are a bit unsightly e.g. mmol/mol creat is
expressed as mmol/mol {creat}. I'm all in favour of a display component
for units of measure - in the end you are still getting coded data.

Cheers,
Michael Osborne
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/99c0d0db/attachment.html

UCUM

[Grahame Grieve]

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 be except for annoying problems like the one Heath
 mentioned - UCUM uses '*' for exponent instead of '^' which almost
 everyone else uses

 We could use the same approach as an openEHR DV_PARSABLE, where the name
 of the syntax is stored as well, but this is IMO inviting a different
 kind of pain...

 My answer would be: let's get UCUM doing everything we need (for the
 formal units field I mean, not the informal one); if we can't, we need a
 new UCUM.

 - thomas


 Hi Thomas,
 ? ?'^' is a special character in HL7 V2.x messages - so by changing '*' back
 to '^' you would break implementations of HL7 ORU messages. We already
 see this in some lab messages - if you try to parse the units field you get
 x10 instead of x10^9/L, because OBX-6 is a coded element (CE) data type.
 UCUM also uses annotations which are a bit unsightly e.g. mmol/mol creat is
 expressed as mmol/mol {creat}. I'm all in favour of a display component
 for units of measure - in the end you are still getting coded data.

 Cheers,
 Michael Osborne

 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

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


On Fri, May 27, 2011 at 10:26 PM, Leonardo Moretti
lmoretti at noemalife.com wrote:

 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:

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

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



 --
 View this message in context: 
 http://old.nabble.com/Unable-to-express-an-unit-of-measurements-in-UCUM-syntax-tp31494533p31715342.html
 Sent from the openehr-technical mailing list archive at Nabble.com.


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Thomas Beale]

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

- thomas*
*
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110530/d28eea2f/attachment.html

Unable to express an unit of measurements in UCUM syntax

[Leonardo Moretti]

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:
 
 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 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
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 

-- 
View this message in context: 
http://old.nabble.com/Unable-to-express-an-unit-of-measurements-in-UCUM-syntax-tp31494533p31715342.html
Sent from the openehr-technical mailing list archive at Nabble.com.

Unable to express an unit of measurements in UCUM syntax

[Leonardo Moretti]

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:
 
 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
 
 1. Use the pseudo-unit in the unit attribute, as a qualified real
 2. 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 at 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
 
 
 
 On 29 April 2011 12:27, Thomas Beale
 thomas.beale at oceaninformatics.comwrote:
 

 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?

 - thomas


 On 29/04/2011 10:25, Grahame Grieve wrote:

 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.


  *
 *

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 

-- 
View this message in context: 
http://old.nabble.com/Unable-to-express-an-unit-of-measurements-in-UCUM-syntax-tp31494533p31709299.html
Sent from the openehr-technical mailing list archive at Nabble.com.

Unable to express an unit of measurements in UCUM syntax

[Thomas Beale]

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

Unable to express an unit of measurements in UCUM syntax

[Koray Atalag]

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


-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@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-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

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Unable to express an unit of measurements in UCUM syntax

[Colin Sutton]

'...twopointseven', or ask the cardiologists to give the unit a name. heartz?

Regards,
Colin

On 29/04/2011, at 9:44 PM, Ian McNicoll Ian.McNicoll at 
oceaninformatics.com wrote:

 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?
 
[...]
#
This e-mail message has been scanned for Viruses and Content and cleared 
by MailMarshal
#



IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be 
read or used by the named addressee. 
It is confidential and may contain legally privileged information. No 
confidentiality or privilege is waived or lost 
by any mistaken transmission to you. The CTC is not responsible for any 
unauthorised alterations to this e-mail or 
attachment to it. Views expressed in this message are those of the individual 
sender, and are not necessarily the 
views of the CTC. If you receive this e-mail in error, please immediately 
delete it and notify the sender. You must 
not disclose, copy or use any part of this e-mail if you are not the intended 
recipient.

#

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

Hi Leo

Can you please provide some references to show the use of height^2.7?

Grahame


On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo
lmoretti at noemalife.com wrote:
 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
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical





-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

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


On Fri, Apr 29, 2011 at 12:50 AM, Leonardo Moretti
lmoretti at noemalife.com wrote:

 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:

 Hi Leo

 Can you please provide some references to show the use of height^2.7?

 Grahame


 On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo
 lmoretti at noemalife.com wrote:
 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
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical





 --
 -
 http://www.healthintersections.com.au /
 grahame at healthintersections.com.au / +61 411 867 065
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



 --
 View this message in context: 
 http://old.nabble.com/Unable-to-express-an-unit-of-measurements-in-UCUM-syntax-tp31494533p31497302.html
 Sent from the openehr-technical mailing list archive at Nabble.com.

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

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



On Fri, Apr 29, 2011 at 9:20 AM, Grahame Grieve
grahame at healthintersections.com.au 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


 On Fri, Apr 29, 2011 at 12:50 AM, Leonardo Moretti
 lmoretti at noemalife.com wrote:

 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:

 Hi Leo

 Can you please provide some references to show the use of height^2.7?

 Grahame


 On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo
 lmoretti at noemalife.com wrote:
 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
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical





 --
 -
 http://www.healthintersections.com.au /
 grahame at healthintersections.com.au / +61 411 867 065
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



 --
 View this message in context: 
 http://old.nabble.com/Unable-to-express-an-unit-of-measurements-in-UCUM-syntax-tp31494533p31497302.html
 Sent from the openehr-technical mailing list archive at Nabble.com.

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




 --
 -
 http://www.healthintersections.com.au /
 grahame at healthintersections.com.au / +61 411 867 065




-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Thomas Beale]

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

- thomas

On 29/04/2011 01:48, Grahame Grieve wrote:
 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


*
*
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/9213f009/attachment.html

Unable to express an unit of measurements in UCUM syntax

[Thomas Beale]

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?

- thomas

On 29/04/2011 10:25, Grahame Grieve wrote:
 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.

*
*
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/987d608b/attachment.html

Unable to express an unit of measurements in UCUM syntax

[Ian McNicoll]

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

1. Use the pseudo-unit in the unit attribute, as a qualified real
2. 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 at 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



On 29 April 2011 12:27, Thomas Beale thomas.beale at 
oceaninformatics.comwrote:


 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?

 - thomas


 On 29/04/2011 10:25, Grahame Grieve wrote:

 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.


  *
 *

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/4a45cf66/attachment.html

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

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 at noemalife.com wrote:
 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
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical





-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Leonardo Moretti]

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:
 
 Hi Leo
 
 Can you please provide some references to show the use of height^2.7?
 
 Grahame
 
 
 On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo
 lmoretti at noemalife.com wrote:
 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
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


 
 
 
 -- 
 -
 http://www.healthintersections.com.au /
 grahame at healthintersections.com.au / +61 411 867 065
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 

-- 
View this message in context: 
http://old.nabble.com/Unable-to-express-an-unit-of-measurements-in-UCUM-syntax-tp31494533p31497302.html
Sent from the openehr-technical mailing list archive at Nabble.com.