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

openEHR REST APIs - Release 0.9.0 / invitation for comments

[Thomas Beale]

The REST API Team (Bostjan Lah, Erik Sundvall, Sebastian Iancu, Heath 
Frankel, Pablo Pazos, and others on the SEC 
 and 
elsewhere) have made a 0.9.0 Release of the ITS (Implementation 
Technology Specifications) component, in order to make a pre-1.0.0 
release of the REST APIs available for wider comment.


The key point about this current release is that it is meant to be a 
'core basics' foundation of APIs to build on, and some services like 
CDS, and more sophisticated querying (e.g. that Erik Sundvall has 
published in the past) will be added over time.


NOTE THAT IN THE 0.9.0 RELEASE, BREAKING CHANGES ARE POSSIBLE.

You can see the ITS Release 0.9.0 link here 
, while 
the links you see on the specs 'working baseline' page 
 are the 
result of 0.9.0 plus any modifications made due to feedback. The .apib 
files are here in Github 
 
(see mainly the includes directory).


We are aiming to release 1.0.0 at the end of February, at which point 
the formal process kicks in.


Since we are in Release 0.9.0, the formal PR/CR process is not needed, 
and you can comment here. However, if you want to raise a PR you can, in 
which case, please set the Component and Affects Version fields 
appropriately:


- thomas  beale

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

[Thomas Beale]

that's not a bad idea, but that requires a change to the reference 
model, since DV_QUANTITY.units is currently a String.


I sometimes wonder if we need to allow for some sort of automatic 
conversions in cases like this, i.e. where the 'code' is self-defining - 
as we already accept via the notion of openEHR code-sets, e.g. country 
codes and so on - units are like this, rather than being like SNOMED or 
LOINC codes.


Perhaps we define it to be legal to enable a String field can be mapped 
to a code-set, more or less in the way that Diego does here?


- thomas


On 26/01/2018 11:08, Diego Boscá wrote:

maybe something like this

ELEMENT[at0004] occurrences matches {0..1} matches {  -- One element
  value existence matches {0..1} matches {
  DV_QUANTITY occurrences matches {0..1} matches {  -- 
DV_QUANTITY

  units existence matches {1..1} matches {
[ac0001]
  }
  }
  }
  }

...


 constraint_binding = <
    ["UCUM"] = <
    items = <
    ["ac0001"] = <[UCUM::mass]>
    >
    >
    >


'mass' or whatever way of identifying the valid unit set



2018-01-26 10:40 GMT+01:00 Bakke, Silje Ljosland 
>:


This sounds good in theory, but I don’t think it’ll help me with
my modelling in the next couple of weeks? J

Regards,

*Silje*

*From:*openEHR-technical
[mailto:openehr-technical-boun...@lists.openehr.org
] *On Behalf
Of *Diego Boscá
*Sent:* Friday, January 26, 2018 10:18 AM
*To:* For openEHR technical discussions
>
*Subject:* Re: Quantities of arbitrary units in openEHR

In my mind, this should be done not by fixing a property but by
defining a constraint reference pointing to the service/set of
codes that can provide you with all mass units

2018-01-26 10:00 GMT+01:00 Bakke, Silje Ljosland
>:

Deriving the properties from the codes makes sense when you
actually specify the codes, but what do you do when you want
to specify “this is a concentration, but I don’t care about
the exact units”?

“Arbitrary unit” has a quite specific meaning, it’s not just a
catch-all for “new units for which we haven’t got the property
defined in the terminology yet”:
https://en.wikipedia.org/wiki/Arbitrary_unit


I see that IUPAC and IFCC has decided to use the term
“procedure defined unit” instead of “arbitrary unit”.

Also, does leaving the “property” field out mean that we can
have one Quantity element with the units Cel, m, kg, ml and
[arb'U]?

Regards,

*Silje*

*Fra:*openEHR-technical
[mailto:openehr-technical-boun...@lists.openehr.org
] *På
vegne av* Diego Boscá
*Sendt:* fredag 26. januar 2018 09:42
*Til:* For openEHR technical discussions
>
*Emne:* Re: Quantities of arbitrary units in openEHR

I think there are several potential problems with this, and
IMHO we are stepping too much on what should be done in a
terminology service (We are literally talking about a 'public
available UCUM service'). You can also ask the terminology
service what kind of unit code you have. Your implementation
could answer "arbitrary" for these new units.

In my opinion, saying "here comes a mass unit code" is not
much different from "here comes a diagnosis code", and we say
these in a completely different way (a better way, if you ask me).

Also, I'm not a big fan of "arbitrary" property, as feels like
a "other" kind of terminology code that is potentially
dangerous as knowledge or terminology advances, thus
coexisting 'arbitrary' and 'new shiny type of measurements'
all mixed up. That's why I also expect these properties to be
as derived from the codes and not the other way around.

2018-01-26 9:21 GMT+01:00 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 

Re: Quantities of arbitrary units in openEHR

[Diego Boscá]

maybe something like this

ELEMENT[at0004] occurrences matches {0..1} matches {  -- One element
value existence matches {0..1}
matches {
DV_QUANTITY occurrences matches
{0..1} matches {  -- DV_QUANTITY
units existence matches
{1..1} matches {
[ac0001]
}
}
}
}

...


 constraint_binding = <
["UCUM"] = <
items = <
["ac0001"] = <[UCUM::mass]>
>
>
>


'mass' or whatever way of identifying the valid unit set



2018-01-26 10:40 GMT+01:00 Bakke, Silje Ljosland :

> This sounds good in theory, but I don’t think it’ll help me with my
> modelling in the next couple of weeks? J
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-boun
> c...@lists.openehr.org] *On Behalf Of *Diego Boscá
> *Sent:* Friday, January 26, 2018 10:18 AM
> *To:* For openEHR technical discussions  hr.org>
> *Subject:* Re: Quantities of arbitrary units in openEHR
>
>
>
> In my mind, this should be done not by fixing a property but by defining a
> constraint reference pointing to the service/set of codes that can provide
> you with all mass units
>
>
>
> 2018-01-26 10:00 GMT+01:00 Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no>:
>
> Deriving the properties from the codes makes sense when you actually
> specify the codes, but what do you do when you want to specify “this is a
> concentration, but I don’t care about the exact units”?
>
>
>
> “Arbitrary unit” has a quite specific meaning, it’s not just a catch-all
> for “new units for which we haven’t got the property defined in the
> terminology yet”: https://en.wikipedia.org/wiki/Arbitrary_unit
>
> I see that IUPAC and IFCC has decided to use the term “procedure defined
> unit” instead of “arbitrary unit”.
>
>
>
> Also, does leaving the “property” field out mean that we can have one
> Quantity element with the units Cel, m, kg, ml and [arb'U]?
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *Fra:* openEHR-technical [mailto:openehr-technical-boun
> c...@lists.openehr.org] *På vegne av* Diego Boscá
> *Sendt:* fredag 26. januar 2018 09:42
> *Til:* For openEHR technical discussions  hr.org>
> *Emne:* Re: Quantities of arbitrary units in openEHR
>
>
>
> I think there are several potential problems with this, and IMHO we are
> stepping too much on what should be done in a terminology service (We are
> literally talking about a 'public available UCUM service'). You can also
> ask the terminology service what kind of unit code you have. Your
> implementation could answer "arbitrary" for these new units.
>
>
>
> In my opinion, saying "here comes a mass unit code" is not much different
> from "here comes a diagnosis code", and we say these in a completely
> different way (a better way, if you ask me).
>
>
>
> Also, I'm not a big fan of "arbitrary" property, as feels like a "other"
> kind of terminology code that is potentially dangerous as knowledge or
> terminology advances, thus coexisting 'arbitrary' and 'new shiny type of
> measurements' all mixed up. That's why I also expect these properties to be
> as derived from the codes and not the other way around.
>
>
>
> 2018-01-26 9:21 GMT+01:00 Sebastian Garde  ics.com>:
>
> 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 

Re: Quantities of arbitrary units in openEHR

[GF]

Ia gree with Diago.

UCUM basicly is a terminological system.

GF

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 26 Jan 2018, at 09:41, Diego Boscá  wrote:
> 
> I think there are several potential problems with this, and IMHO we are 
> stepping too much on what should be done in a terminology service (We are 
> literally talking about a 'public available UCUM service'). You can also ask 
> the terminology service what kind of unit code you have. Your implementation 
> could answer "arbitrary" for these new units.
> 
> In my opinion, saying "here comes a mass unit code" is not much different 
> from "here comes a diagnosis code", and we say these in a completely 
> different way (a better way, if you ask me).
> 
> Also, I'm not a big fan of "arbitrary" property, as feels like a "other" kind 
> of terminology code that is potentially dangerous as knowledge or terminology 
> advances, thus coexisting 'arbitrary' and 'new shiny type of measurements' 
> all mixed up. That's why I also expect these properties to be as derived from 
> the codes and not the other way around.

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

Re: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 26-01-18 10:40, Bakke, Silje Ljosland wrote:

(We are literally talking about a 'public available UCUM service')


I don't think that is necessary, UCUM is a very small service, which can 
also be in software as a library or small external service in 
microservice architecture.



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

RE: Quantities of arbitrary units in openEHR

[Bakke, Silje Ljosland]

This sounds good in theory, but I don’t think it’ll help me with my modelling 
in the next couple of weeks? ☺

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Diego Boscá
Sent: Friday, January 26, 2018 10:18 AM
To: For openEHR technical discussions 
Subject: Re: Quantities of arbitrary units in openEHR

In my mind, this should be done not by fixing a property but by defining a 
constraint reference pointing to the service/set of codes that can provide you 
with all mass units

2018-01-26 10:00 GMT+01:00 Bakke, Silje Ljosland 
>:
Deriving the properties from the codes makes sense when you actually specify 
the codes, but what do you do when you want to specify “this is a 
concentration, but I don’t care about the exact units”?

“Arbitrary unit” has a quite specific meaning, it’s not just a catch-all for 
“new units for which we haven’t got the property defined in the terminology 
yet”: https://en.wikipedia.org/wiki/Arbitrary_unit
I see that IUPAC and IFCC has decided to use the term “procedure defined unit” 
instead of “arbitrary unit”.

Also, does leaving the “property” field out mean that we can have one Quantity 
element with the units Cel, m, kg, ml and [arb'U]?

Regards,
Silje

Fra: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org]
 På vegne av Diego Boscá
Sendt: fredag 26. januar 2018 09:42
Til: For openEHR technical discussions 
>
Emne: Re: Quantities of arbitrary units in openEHR

I think there are several potential problems with this, and IMHO we are 
stepping too much on what should be done in a terminology service (We are 
literally talking about a 'public available UCUM service'). You can also ask 
the terminology service what kind of unit code you have. Your implementation 
could answer "arbitrary" for these new units.

In my opinion, saying "here comes a mass unit code" is not much different from 
"here comes a diagnosis code", and we say these in a completely different way 
(a better way, if you ask me).

Also, I'm not a big fan of "arbitrary" property, as feels like a "other" kind 
of terminology code that is potentially dangerous as knowledge or terminology 
advances, thus coexisting 'arbitrary' and 'new shiny type of measurements' all 
mixed up. That's why I also expect these properties to be as derived from the 
codes and not the other way around.

2018-01-26 9:21 GMT+01:00 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



--

[VeraTech for Health 

Re: Quantities of arbitrary units in openEHR

[Diego Boscá]

In my mind, this should be done not by fixing a property but by defining a
constraint reference pointing to the service/set of codes that can provide
you with all mass units

2018-01-26 10:00 GMT+01:00 Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no>:

> Deriving the properties from the codes makes sense when you actually
> specify the codes, but what do you do when you want to specify “this is a
> concentration, but I don’t care about the exact units”?
>
>
>
> “Arbitrary unit” has a quite specific meaning, it’s not just a catch-all
> for “new units for which we haven’t got the property defined in the
> terminology yet”: https://en.wikipedia.org/wiki/Arbitrary_unit
>
> I see that IUPAC and IFCC has decided to use the term “procedure defined
> unit” instead of “arbitrary unit”.
>
>
>
> Also, does leaving the “property” field out mean that we can have one
> Quantity element with the units Cel, m, kg, ml and [arb'U]?
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *Fra:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *På vegne av* Diego Boscá
> *Sendt:* fredag 26. januar 2018 09:42
> *Til:* For openEHR technical discussions  openehr.org>
> *Emne:* Re: Quantities of arbitrary units in openEHR
>
>
>
> I think there are several potential problems with this, and IMHO we are
> stepping too much on what should be done in a terminology service (We are
> literally talking about a 'public available UCUM service'). You can also
> ask the terminology service what kind of unit code you have. Your
> implementation could answer "arbitrary" for these new units.
>
>
>
> In my opinion, saying "here comes a mass unit code" is not much different
> from "here comes a diagnosis code", and we say these in a completely
> different way (a better way, if you ask me).
>
>
>
> Also, I'm not a big fan of "arbitrary" property, as feels like a "other"
> kind of terminology code that is potentially dangerous as knowledge or
> terminology advances, thus coexisting 'arbitrary' and 'new shiny type of
> measurements' all mixed up. That's why I also expect these properties to be
> as derived from the codes and not the other way around.
>
>
>
> 2018-01-26 9:21 GMT+01:00 Sebastian Garde  oceaninformatics.com>:
>
> 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
>
>
>
>
> --
>
> [image: VeraTech for Health SL] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> *Diego Boscá Tomás* / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> *VeraTech for Health SL*
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> 

RE: Quantities of arbitrary units in openEHR

[Bakke, Silje Ljosland]

Deriving the properties from the codes makes sense when you actually specify 
the codes, but what do you do when you want to specify “this is a 
concentration, but I don’t care about the exact units”?

“Arbitrary unit” has a quite specific meaning, it’s not just a catch-all for 
“new units for which we haven’t got the property defined in the terminology 
yet”: https://en.wikipedia.org/wiki/Arbitrary_unit
I see that IUPAC and IFCC has decided to use the term “procedure defined unit” 
instead of “arbitrary unit”.

Also, does leaving the “property” field out mean that we can have one Quantity 
element with the units Cel, m, kg, ml and [arb'U]?

Regards,
Silje

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Diego Boscá
Sendt: fredag 26. januar 2018 09:42
Til: For openEHR technical discussions 
Emne: Re: Quantities of arbitrary units in openEHR

I think there are several potential problems with this, and IMHO we are 
stepping too much on what should be done in a terminology service (We are 
literally talking about a 'public available UCUM service'). You can also ask 
the terminology service what kind of unit code you have. Your implementation 
could answer "arbitrary" for these new units.

In my opinion, saying "here comes a mass unit code" is not much different from 
"here comes a diagnosis code", and we say these in a completely different way 
(a better way, if you ask me).

Also, I'm not a big fan of "arbitrary" property, as feels like a "other" kind 
of terminology code that is potentially dangerous as knowledge or terminology 
advances, thus coexisting 'arbitrary' and 'new shiny type of measurements' all 
mixed up. That's why I also expect these properties to be as derived from the 
codes and not the other way around.

2018-01-26 9:21 GMT+01:00 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



--

[VeraTech for Health SL]

[Twitter]   [LinkedIn]  
  [Maps]  

[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

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

VeraTech for Health SL
+34 961071863 / +34 
627015023
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman parte de 
un fichero titularidad de VeraTech for Health SL (CIF B98309511) cuya finalidad 
es la de mantener el contacto con usted. Conforme a La Ley Orgánica 15/1999, 
usted puede ejercitar sus derechos de acceso, rectificación, 

Re: Quantities of arbitrary units in openEHR

[Thomas Beale]

The thing I am not a fan of is that units themselves become part of 
terminology. This is a SNOMED direction but I think a wrong one. The 
reason is that the ontology of units isn't the same as the ontology of 
findings, medications and so on. In fact they all have different 
ontologies, and trying to jam them all into SNOMED CT under a single 
meta- model is problematic at best.


But units are so clearly different that they deserve their own service - 
for a start, UCUM unit strings are post-coorindatable according to the 
UCUM grammar, and then you have the classification of units under 
properties, synthetic properties under basic properties, strange stuff 
currently called 'arbitrary' (which is still real, and must have a place 
inside the ontology); units conversion rules and algorithms and so on.


So while a mass unit code like 'kg' might not see much different for a 
code for pneumonia, even this simple example is already a 
pre-coordination of 'k' and 'g' according to a units ontology, something 
that clearly doesn't apply to 'pneumonia', at least not in the same way 
(i.e. 'viral pneumonia' is a particular that is described by a disease 
ontology).


Thinking a bit more about 'arbitrary', I think I agree with Diego - to 
sort it out properly needs a proper ontology.


- thomas


On 26/01/2018 08:41, Diego Boscá wrote:
I think there are several potential problems with this, and IMHO we 
are stepping too much on what should be done in a terminology service 
(We are literally talking about a 'public available UCUM service'). 
You can also ask the terminology service what kind of unit code you 
have. Your implementation could answer "arbitrary" for these new units.


In my opinion, saying "here comes a mass unit code" is not much 
different from "here comes a diagnosis code", and we say these in a 
completely different way (a better way, if you ask me).


Also, I'm not a big fan of "arbitrary" property, as feels like a 
"other" kind of terminology code that is potentially dangerous as 
knowledge or terminology advances, thus coexisting 'arbitrary' and 
'new shiny type of measurements' all mixed up. That's why I also 
expect these properties to be as derived from the codes and not the 
other way around.




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

[Diego Boscá]

I think there are several potential problems with this, and IMHO we are
stepping too much on what should be done in a terminology service (We are
literally talking about a 'public available UCUM service'). You can also
ask the terminology service what kind of unit code you have. Your
implementation could answer "arbitrary" for these new units.

In my opinion, saying "here comes a mass unit code" is not much different
from "here comes a diagnosis code", and we say these in a completely
different way (a better way, if you ask me).

Also, I'm not a big fan of "arbitrary" property, as feels like a "other"
kind of terminology code that is potentially dangerous as knowledge or
terminology advances, thus coexisting 'arbitrary' and 'new shiny type of
measurements' all mixed up. That's why I also expect these properties to be
as derived from the codes and not the other way around.

2018-01-26 9:21 GMT+01:00 Sebastian Garde <
sebastian.ga...@oceaninformatics.com>:

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



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


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

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

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

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

Re: Quantities of arbitrary units in openEHR

[Thomas Beale]

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

Re: Quantities of arbitrary units in openEHR

[Thomas Beale]

Ah I was being dense, I thought you were talking about the units field, 
not the property field. In that case, what would it mean if property 
were set to 'Arbitrary' - does that mean the units has to be from the 
current list of arbitrary units, which is not-length, not-pressure, 
not-everything else? If that's the intended effect then ... maybe we add 
a new term. But the existing property terms are well defined, and in 
some sense exhaustive (at the physics level). It is clear what 'mass' 
means for example; what does 'arbitrary' mean? Probably it would need to 
be at least 'arbitrary property'?


anyway, I think this is now a terminology discussion... :)

- thomas


On 26/01/2018 07:18, Bakke, Silje Ljosland wrote:


Hi all, thanks for your replies!

I’m sure the CKM would accept the unit string, but which property 
would the Quantity have? Eg property = <[openehr::124]> for weight or 
property = <[openehr::127]> for temperature? I don’t think we have one 
of those codes for “Arbitrary”?


I’m sure you’re correct about the syntax, btw. J



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