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

___
openEHR-technical mailing list
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é)" :

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

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é)"  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  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  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 

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

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 
> On 19 mei 2016, at 10:09, Ian McNicoll  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  > 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 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> 

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  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
>
>
>
> ___
> 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 
> On 19 mei 2016, at 09:24, Thomas Beale  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  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
> ;
> 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 


___
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 
> On 18 mei 2016, at 13:41, Thomas Beale  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 
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
> ;
> 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 
; 
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  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 
>  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 :
> 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  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  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 :
> Really? No one has ever brought that to us as an requirement
>
> Grahame
>
>> On 18 May 2016, at 9:48 PM, Diego Boscá  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 :
>>>
>>> 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  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á  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 :
>> 
>> 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 :
>
> 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  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

[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  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 
 
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 > 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 
 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  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  wrote:
>> That's overkill - just have two fields, human and computable units.
>> 
>> Grahame
>> 
>>> On 18 May 2016, at 7:05 PM, Daniel Karlsson  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  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  wrote:
>
>> That's overkill - just have two fields, human and computable units.
>>
>> Grahame
>>
>> On 18 May 2016, at 7:05 PM, Daniel Karlsson 
>> 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  wrote:

> That's overkill - just have two fields, human and computable units.
>
> Grahame
>
> On 18 May 2016, at 7:05 PM, Daniel Karlsson 
> 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  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  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