Re: AW: AW: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 26-01-18 14:27, Thomas Beale wrote:



yes I agree with this. We should do something about it.



I am glad you think so too. Thanks to Silje for bringing it u initially.

I think, there is already much possible with only few changes, the ideas 
expressed by Diego help a lot.


On the archetype side we need to define the UCUM-property for 
constraint, and units mandatory.

On the dataset-side only the value and the unit name is necessary.

The dataset-validating software must then check against the 
UCUM-definitions if the used unit and value can be used in the context 
of the property.


This would be a great improvement because worldwide, every DvQuantity 
value could be calculated to its appropriate value.
Fahrenheit and miles for some countries, and Celcius and Kilometer for 
some other countries, and of course many other local used units.


The best way to achieve it, in my opinion, (but I am sure I don't see 
the whole picture), would be to make units in DvQuantity of type STRING 
*OR* by term-binding.


We already know alternative datatypes, which are sometimes used in 
ELEMENT/value. So the use would then be to have to alternative values 
for the ELEMENT, one for the string-type DvQuantity, one for the coded 
type, so there would never be a problem with interpreting.


In this way it would remain backwards compatible and also allow to 
support units to be checked against a (any) terminology.
It is also that, besides UCUM, SNOMED also defines units, and there can 
be data, maybe from legacy systems, which use SNOMED-terms for a unit 
(maybe there are also translated units, if so, SNOMED takes care for 
that, and I also found on google there is a mapping between SNOMED and 
UCUM coming up or already finished).


And the only thing needed to change in the RM would be an addition for 
the DvQuantity-unit-type, without losing backwards compatibility.


I wouldn't have come tot his idea without the discussion this morning, 
and I am sure there is more to it then I see.

But this kind of solution, I think is the best I can think of.

Bert




- thomas


On 26/01/2018 13:23, Bert Verhees wrote:

On 26-01-18 08:53, Sebastian Garde wrote:
This is where I think that not only it is stated that openEHR uses 
UCUM (and not some part or “inspiration” of it), but also implies 
that the case sensitive version of it is used (which in my view is 
important to know at least for some of the units). I still think it 
would be good to explicitly say that the case-sensitive version is used?


Just for the record, my point I wanted to make was that OpenEhr does 
not define use of the facilities of UCUM (like properties and 
conversions), as we see now in the discussion, which I think is very 
useful and making use of UCUM facilities possible.


Quoting myself from a reply this morning:

> If it would, not only use the stringified units of UCUM, but also 
would incorporate UCUM-defined functionality, it would also have, for 
example, conversion routines from UCUM, which are usable for software 
defined in the UCUM essence-file."





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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 




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



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

Re: AW: AW: Quantities of arbitrary units in openEHR

[Thomas Beale]

yes I agree with this. We should do something about it.

- thomas


On 26/01/2018 13:23, Bert Verhees wrote:

On 26-01-18 08:53, Sebastian Garde wrote:
This is where I think that not only it is stated that openEHR uses 
UCUM (and not some part or “inspiration” of it), but also implies 
that the case sensitive version of it is used (which in my view is 
important to know at least for some of the units). I still think it 
would be good to explicitly say that the case-sensitive version is used?


Just for the record, my point I wanted to make was that OpenEhr does 
not define use of the facilities of UCUM (like properties and 
conversions), as we see now in the discussion, which I think is very 
useful and making use of UCUM facilities possible.


Quoting myself from a reply this morning:

> If it would, not only use the stringified units of UCUM, but also 
would incorporate UCUM-defined functionality, it would also have, for 
example, conversion routines from UCUM, which are usable for software 
defined in the UCUM essence-file."





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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

Re: AW: AW: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 26-01-18 08:53, Sebastian Garde wrote:
This is where I think that not only it is stated that openEHR uses 
UCUM (and not some part or “inspiration” of it), but also implies that 
the case sensitive version of it is used (which in my view is 
important to know at least for some of the units). I still think it 
would be good to explicitly say that the case-sensitive version is used?


Just for the record, my point I wanted to make was that OpenEhr does not 
define use of the facilities of UCUM (like properties and conversions), 
as we see now in the discussion, which I think is very useful and making 
use of UCUM facilities possible.


Quoting myself from a reply this morning:

> If it would, not only use the stringified units of UCUM, but also 
would incorporate UCUM-defined functionality, it would also have, for 
example, conversion routines from UCUM, which are usable for software 
defined in the UCUM essence-file."


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

AW: Quantities of arbitrary units in openEHR

[Sebastian Garde]

While I agree with the SPEC-95 rationale (once you have a unit, you should be 
able to know what its property is), it is still convenient to have the property 
for constraining.
Otherwise you don't have a way to say in an archetype: I don't care about the 
exact unit here, but please let it be a "Mass".

-Ursprüngliche Nachricht-
Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Thomas Beale
Gesendet: Freitag, 26. Januar 2018 09:13
An: openehr-technical@lists.openehr.org
Betreff: Re: Quantities of arbitrary units in openEHR

Right - at the moment, it is a 'fake' field in archetypes, enabled by being in 
the BMM or other expression of the RM. It's convenient to do this occasionally, 
since we don't think 'property' needs to be a field of DV_QUANTITY - but maybe 
it should be, since for some of the more esoteric units, it's not that clear 
what is being measured.

This trick is also not mentioned in the ADL/AOM specs, and it either should be, 
or we just don't allow it. I don't have a strong opinion either way.

- thomas


On 26/01/2018 07:51, Pieter Bos wrote:
> A bit unrelated perhaps, but in the 1.0.3 and 1.0.4 RM specification, 
> there is no property attribute or function present in dv_quantity, 
> even though the text says it can be conveniently constrained. There is 
> a reference to the spec-95 jira issue, which says it has been removed. 
> So there’s no way to constrain it - unless the specification contains 
> a mistake :)
>
> It is present in the BMM variants of the RM though, as a mandatory field.
>
> Regards,
>
> Pieter Bos
>


___
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: AW: AW: Quantities of arbitrary units in openEHR

[Thomas Beale]

We should fix this documentation - can you create a PR for this?

thanks

- thomas


On 26/01/2018 07:53, Sebastian Garde wrote:



it certainly specifies it 
. 
If there are tools and implementations that don't respect this, they 
are non-compliant and will get found out ;)


*/[SG] /*The first reference 
https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_quantity_class 
is more an “inspiration”: “Units were inspired by the Unified Code for 
Units of Measure (UCUM) , 
developed by Gunther Schadow and Clement J. McDonald of The 
Regenstrief Institute.”


The 2^nd reference is clearer: “Stringified units, expressed in UCUM 
unit syntax, e.g. "kg/m2", “mm[Hg]", "ms-1", "km/h".”
This is where I think that not only it is stated that openEHR uses 
UCUM (and not some part or “inspiration” of it), but also implies that 
the case sensitive version of it is used (which in my view is 
important to know at least for some of the units). I still think it 
would be good to explicitly say that the case-sensitive version is used?


The unit strings in the terminology are to help archetype tooling, but 
I would say that all tools and systems in the future should be using a 
'UCUM service' that does not yet exist, but knows about all unit 
strings, properties and so on. This is something we could easily 
specify and implement, if there is not already one in existence.


*/[SG] Agree – such a  UCUM service may also be able to give a print 
version, e.g. /**°C instead of CEL or °F instead of **[degF]**//*


*/Sebastian/*

*//*




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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

AW: AW: Quantities of arbitrary units in openEHR

[Sebastian Garde]

Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 17:34
An: openehr-technical@lists.openehr.org
Betreff: Re: AW: Quantities of arbitrary units in openEHR




On 25/01/2018 16:28, Bert Verhees wrote:
On 25-01-18 11:03, Sebastian Garde wrote:
Hi Silje,

I think this may 'just' be a modelling tooling issue, openEHR itself supports 
this ok.

Speaking for CKM, if you upload an archetype with this to CKM, it should 
validate the UCUM unit correctly for [arb'U]{whatever}.
However, [arb'u]{whatever} or similar is (very slightly) incorrect in my 
understanding:


  1.  Use the completely vertical ' not ' or similar (at least that is my 
understanding).
  2.  openEHR uses (implicitly I think, but it may be hidden somewhere in the 
spec), the case-sensitive version of UCUM - therefore the U needs to be upper 
case, see e.g. http://unitsofmeasure.org/ucum.html#para-45

As far as I know, Sebastian, OpenEhr does not use UCUM

it certainly specifies 
it<https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_quantity_class>.
 If there are tools and implementations that don't respect this, they are 
non-compliant and will get found out ;)

[SG]  The first reference 
https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_quantity_class
 is more an "inspiration": "Units were inspired by the Unified Code for Units 
of Measure (UCUM)<http://unitsofmeasure.org/ucum.html>, developed by Gunther 
Schadow and Clement J. McDonald of The Regenstrief Institute."
The 2nd reference is clearer: "Stringified units, expressed in UCUM unit 
syntax, e.g. "kg/m2", "mm[Hg]", "ms-1", "km/h"."
This is where I think that not only it is stated that openEHR uses UCUM (and 
not some part or "inspiration" of it), but also implies that the case sensitive 
version of it is used (which in my view is important to know at least for some 
of the units). I still think it would be good to explicitly say that the 
case-sensitive version is used?

The unit strings in the terminology are to help archetype tooling, but I would 
say that all tools and systems in the future should be using a 'UCUM service' 
that does not yet exist, but knows about all unit strings, properties and so 
on. This is something we could easily specify and implement, if there is not 
already one in existence.
[SG] Agree - such a  UCUM service may also be able to give a print version, 
e.g. °C instead of CEL or °F instead of [degF]
Sebastian


The unit strings in the terminology are to help archetype tooling, but I would 
say that all tools and systems in the future should be using a 'UCUM service' 
that does not yet exist, but knows about all unit strings, properties and so 
on. This is something we could easily specify and implement, if there is not 
already one in existence.


but it uses many unit-strings which also are defined in UCUM, but has these 
strings for OpenEhr-use listed in an own terminology-list. This list needs to 
be maintained separately by the OpenEHR community. There is no validation 
defined directly to the UCUM-services. If it would, not only use the 
stringified units of UCUM, but also would incorporate UCUM-defined 
functionality, it would also have, for example, conversion routines from UCUM, 
which are usable for software defined in the UCUM essence-file.

right, that's the sort of thing we need. I have not researched this for a few 
years, so if anyone knows of a service and/or service definition / API we can 
use and standardise on, please post some information.

- thomas
--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Team, Intermountain 
Healthcare<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR 
Foundation<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer 
Society<http://www.bcs.org/category/6044>
Health IT blog<http://wolandscat.net/> | Culture 
blog<http://wolandsothercat.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AW: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 25-01-18 17:48, Bert Verhees wrote:
A UCUM-service is quite simple, it has a simple API. You can extract 
it from this testfile which you find here:

https://github.com/BertVerhees/ucum/blob/master/convey/ucum/UcumEssenceService_test.go
I must add a few small remarks, this github-repository is not a service 
(as I on one place indicated), but it is a library, so that is why the 
API is not visible in a simple way, and that is why I point to this 
testfile to learn about the API.


The API, as said, is simple, it consist in about 10 or 15 API-calls. 
Refactoring the library to a service is (in Golang) also very simple, 
just put one file before it with service-calls ( in REST-calls, or if 
used as microservice maybe gRPC calls are possible (which are much 
faster)) and then use the library to feed the service.


https://www.slideshare.net/borisovalex/grpc-vs-rest-let-the-battle-begin-81800634

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

Re: AW: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 25-01-18 17:34, Thomas Beale wrote:




On 25/01/2018 16:28, Bert Verhees wrote:

On 25-01-18 11:03, Sebastian Garde wrote:


Hi Silje,

I think this may ‘just’ be a modelling tooling issue, openEHR itself 
supports this ok.


Speaking for CKM, if you upload an archetype with this to CKM, it 
should validate the UCUM unit correctly for [arb'U]{whatever}.


However, [arb‘*u*]{whatever} or similar is (very slightly) incorrect 
in my understanding:


 1. Use the completely vertical ' not ‘ or similar (at least that is
my understanding).
 2. openEHR uses (implicitly I think, but it may be hidden somewhere
in the spec), the case-sensitive version of UCUM – therefore the
U needs to be upper case, see e.g.
http://unitsofmeasure.org/ucum.html#para-45



As far as I know, Sebastian, OpenEhr does not use UCUM 


it certainly specifies it 
. 
If there are tools and implementations that don't respect this, they 
are non-compliant and will get found out ;)


The unit strings in the terminology are to help archetype tooling, but 
I would say that all tools and systems in the future should be using a 
'UCUM service' that does not yet exist, but knows about all unit 
strings, properties and so on. This is something we could easily 
specify and implement, if there is not already one in existence.
I wrote a UCUM-service for Golang in a two weeks, and had some debugging 
afterwards, I needed it for a project. But I was lucky, the hard 
thinking had already been done by some FHIR developers. I had the URL's 
in my reply to this subject this morning.


A UCUM-service is quite simple, it has a simple API. You can extract it 
from this testfile which you find here:

https://github.com/BertVerhees/ucum/blob/master/convey/ucum/UcumEssenceService_test.go

Bert

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

Re: AW: Quantities of arbitrary units in openEHR

[Thomas Beale]

On 25/01/2018 16:28, Bert Verhees wrote:

On 25-01-18 11:03, Sebastian Garde wrote:


Hi Silje,

I think this may ‘just’ be a modelling tooling issue, openEHR itself 
supports this ok.


Speaking for CKM, if you upload an archetype with this to CKM, it 
should validate the UCUM unit correctly for [arb'U]{whatever}.


However, [arb‘*u*]{whatever} or similar is (very slightly) incorrect 
in my understanding:


 1. Use the completely vertical ' not ‘ or similar (at least that is
my understanding).
 2. openEHR uses (implicitly I think, but it may be hidden somewhere
in the spec), the case-sensitive version of UCUM – therefore the
U needs to be upper case, see e.g.
http://unitsofmeasure.org/ucum.html#para-45



As far as I know, Sebastian, OpenEhr does not use UCUM 


it certainly specifies it 
. 
If there are tools and implementations that don't respect this, they are 
non-compliant and will get found out ;)


The unit strings in the terminology are to help archetype tooling, but I 
would say that all tools and systems in the future should be using a 
'UCUM service' that does not yet exist, but knows about all unit 
strings, properties and so on. This is something we could easily specify 
and implement, if there is not already one in existence.


but it uses many unit-strings which also are defined in UCUM, but has 
these strings for OpenEhr-use listed in an own terminology-list. This 
list needs to be maintained separately by the OpenEHR community. There 
is no validation defined directly to the UCUM-services. If it would, 
not only use the stringified units of UCUM, but also would incorporate 
UCUM-defined functionality, it would also have, for example, 
conversion routines from UCUM, which are usable for software defined 
in the UCUM essence-file.


right, that's the sort of thing we need. I have not researched this for 
a few years, so if anyone knows of a service and/or service definition / 
API we can use and standardise on, please post some information.


- thomas

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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

Re: AW: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 25-01-18 11:03, Sebastian Garde wrote:


Hi Silje,

I think this may ‘just’ be a modelling tooling issue, openEHR itself 
supports this ok.


Speaking for CKM, if you upload an archetype with this to CKM, it 
should validate the UCUM unit correctly for [arb'U]{whatever}.


However, [arb‘*u*]{whatever} or similar is (very slightly) incorrect 
in my understanding:


 1. Use the completely vertical ' not ‘ or similar (at least that is
my understanding).
 2. openEHR uses (implicitly I think, but it may be hidden somewhere
in the spec), the case-sensitive version of UCUM – therefore the U
needs to be upper case, see e.g.
http://unitsofmeasure.org/ucum.html#para-45



As far as I know, Sebastian, OpenEhr does not use UCUM but it uses many 
unit-strings which also are defined in UCUM, but has these strings for 
OpenEhr-use listed in an own terminology-list. This list needs to be 
maintained separately by the OpenEHR community. There is no validation 
defined directly to the UCUM-services. If it would, not only use the 
stringified units of UCUM, but also would incorporate UCUM-defined 
functionality, it would also have, for example, conversion routines from 
UCUM, which are usable for software defined in the UCUM essence-file.


There could be some RM redesign, as Thomas also hinted (on this subject 
today) by using the UCUM-ordering of unit-strings to properties like 
"pressure", "energy", etc and define DvQuantity so that archetypes could 
constrain these properties instead of constraining the stringified units.


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

AW: Quantities of arbitrary units in openEHR

[Sebastian Garde]

Hi Silje,

I think this may 'just' be a modelling tooling issue, openEHR itself supports 
this ok.

Speaking for CKM, if you upload an archetype with this to CKM, it should 
validate the UCUM unit correctly for [arb'U]{whatever}.
However, [arb'u]{whatever} or similar is (very slightly) incorrect in my 
understanding:


  1.  Use the completely vertical ' not ' or similar (at least that is my 
understanding).
  2.  openEHR uses (implicitly I think, but it may be hidden somewhere in the 
spec), the case-sensitive version of UCUM - therefore the U needs to be upper 
case, see e.g. http://unitsofmeasure.org/ucum.html#para-45

Regards
Sebastian

Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 10:25
An: openehr-technical@lists.openehr.org
Betreff: Re: Quantities of arbitrary units in openEHR


Hi Silje,

I don't understand how adding an 'Arbitrary' term to the openEHR terminology 
helps things. DV_QUANTITY.units is a UCUM String field. Won't the strange units 
just turn up in the String form you quoted for UCUM arbitrary units in that 
field?

(BTW, to ask for a new terminology term, just create a new issue on the PR 
tracker with component=New Term Request - choose this from the dropdown).

Setting property and not units makes sense - and if we had a proper, 
standardised units service, a runtime archetype evaluator would use it to limit 
the actual units for property = pressure (say) to only pressure units. I think 
we need to define such a service properly

- thomas

On 24/01/2018 09:52, Bakke, Silje Ljosland wrote:
Hi all,

I'm working on representing medication strengths in archetypes at the moment. 
Most medications are thankfully measured in SI units such as mg/ml or mg/{dose 
unit}, but others use arbitrary units that are not derived from any other 
physical dimensional units. Examples of these are standardized quality units 
(SQ-U), focus forming units (FFU), European and American pharmacopoeia units, 
anti factor Xa units, or international units (IU). There are seemingly an 
unlimited number of these units, and they apparently make up new ones as they 
go along (ref: SQ-T and SQ-HDM). See 
http://unitsofmeasure.org/ucum.html#para-45 for more.

UCUM has a generic way of representing these, as "[arb'u]{whatever}" (arbitrary 
unit, name of the unit), but openEHR doesn't seem to have a property in its 
Quantity data type for them. Could it be a possibility to add an "Arbitrary" 
property to the openEHR support terminology for unit properties?

Also, is it ok to model Quantity elements with a property set but the units 
left unconstrained? I've just started trying to add these units to an archetype 
(as a concentration, so got around the property issue), and it's just a never 
ending task.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no





___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org