Re: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 29-01-18 15:22, Thomas Beale wrote:

Another idea is to change it to a CODE_PHRASE, with terminology_id = UCUM


Yes, I understand the decision, but IO regard it as a quick decision 
which can cause problems on the longer term.


For the record, I object against this decision for the last time. (or 
else it will get boring ) ;-)


UCUM does not have an infrastructure for translations, so translations 
will be done "in the wild", this may be good or may be bad.


SNOMED has an infrastructure for professional translations, SNOMED also 
supports units and hierarchies, like UCUM-properties.


It is of course a matter of taste, and what a customer wants. But I 
think, OpenEHR should offer a customer optional facilities for 
professional translations of the units. Pinning the DvQuantity to UCUM 
in the RM makes it impossible for the customer to chose for a 
professional translation on archetype-level.


There is another disadvantage of this unnecessary inseparability of the 
RM and UCUM, it is against the OpenEHR philosophy to offer as much 
freedom in modeling as possible.



So take your decisions wisely ;-)

Best regards

Bert



___
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

[Pablo Pazos]

Hi Silje,

On Mon, Jan 29, 2018 at 11:15 AM, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Hi,
>
>
>
> «Any units» isn’t the same as “arbitrary units”. As I wrote below,
> “arbitrary units” in the context of biomedicine are units which are defined
> by biological activity, such as level of allergic reaction or enzymatic
> activity.
>

>From the modeling point of view, I don't think using DV_QUANTITY for this
is the right direction, since DV_QUANTITY.units are defined to contain a
unit related to a physical property (mass, length volume, concentration,
etc.). When talking about "level of X", my first idea is to go for
DV_ORDINAL. If the ordinal part is not really needed, then downgrade to
DV_CODED_TEXT (that is part of DV_ORDINAL).


> This is done to be able to compare the concentration of different
> substances which have the same effects in different mass or volume amounts
> – birch pollen extract vs grass pollen extract (measured in SQ-U;
> standardized quality units), retinol vs betacarotene (measured in RE,
> retinol equivalents), human insulin vs insulin analogues (measured in IU,
> international units).
>

In this context, I think comparing levels will work with DV_ORDINAL.


>
>
> To be able to specify medication strength in a meaningful way, I need a
> numerator (amount active substance) and a denominator (amount helper
> substance). The numerator can be a mass (such as mg), a volume (such as ml)
> or an arbitrary unit (such as IU). The denominator can be a volume, a mass
> or an administration unit (such as tablet or puff).
>

This would be normally modeled with DV_PROPORTION, but the issue is that we
don't have units there, just real numerator and deonominator.

This might lead to a requirement of having DV_PROPORTION, so something like DV_PROPORTION will
work.

Also, with DV_QUANTITY alone it is not possible to express an explicit
numerator and denominator, just the final real value of num/den, but the
units are flexible enough to satisfy this. But this leads to the issue you
have again :)

So if the requirement is:

1. to have explicit numerator and denominator,
2. have units for numerator and denominator,
3. have units that are not related with physical properties or that are not
standardized,
4. be able to compare two values of this form

With the current RM, I think it is not possible to model it directly as one
datatype, so it might be a combination of datatypes and using a CLUSTER to
put all together. Then some querying power will allow you to compare those
structures.

I can't think of a better solution with the current RM.

Architecturally I think having DV_PROPORTION might
be a better solution but needs changes to the RM. We already have this for
DV_INTERVAL but a proportion is not the same as an interval.

REF:
http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_overview_4



> Since there can be approximately a million different variations on mass,
> volume and arbitrary units, I don’t want to specify them all in the
> archetype, but leave it up to the application, while still specifying the
> property (mass, volume or arbitrary). At the moment, I can’t do this for
> the arbitrary units element, since there’s no property in the openEHR units
> properties terminology set for arbitrary units.
>
>
>
> However, I’m starting to wonder if “ openEHR="385" />” really is a misnamed “arbitrary units” property. Anyone
> know the origin of this? IU isn’t a mass unit, so it’s misnamed in any case
> (see https://en.wikipedia.org/wiki/International_unit).
>
>
>
> Also, what would be really really neat, is a Quantity data type which
> could be any of a couple of a set of preselected properties (such as for
> instance mass, volume and arbitrary), and not just one fixed property. :o)
>

For the aforementioned, DV_QUANTITY might not be the right solution for
this problem IMHO.


>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* Monday, January 29, 2018 12:37 AM
> *To:* For openEHR technical discussions  openehr.org>
> *Subject:* RE: Quantities of arbitrary units in openEHR
>
>
>
> Hi Silje,
>
>
>
> When specifying the property but not the units, any units are allowed.
> This is saying "any units" which is similar to "arbitrary units". We can
> relax the spec to allow non-ucum as units (my interpretation of "any units"
> is any in ucum and compliant with the specified property, while "arbitrary"
> might be in or not in ucum, and compliant with the property).
>
>
>
> What do you think?
>
>
>
> On Jan 26, 2018 6:01 AM, "Bakke, Silje Ljosland"  nasjonalikt.no> wrote:
>
> 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 

Re: Quantities of arbitrary units in openEHR

[Thomas Beale]

Hi Pablo,

It seems to me that it is better to keep it a String - which is what 
UCUM units are - and to consider adding a property field. Another idea 
is to change it to a CODE_PHRASE, with terminology_id = UCUM, but I'm 
not sure that buys us anything really, if we keep using UCUM, which I 
think we should. That is what we currently do in the RM for fields like 
language and country.


- thomas


On 28/01/2018 23:37, Pablo Pazos wrote:
Maybe we can analyze the need/implications of changing the string tour 
of units for a coded text in the SEC?


On Jan 26, 2018 9:11 AM, "Thomas Beale" > wrote:


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 

RE: Quantities of arbitrary units in openEHR

[Bakke, Silje Ljosland]

Hi,

«Any units» isn’t the same as “arbitrary units”. As I wrote below, “arbitrary 
units” in the context of biomedicine are units which are defined by biological 
activity, such as level of allergic reaction or enzymatic activity. This is 
done to be able to compare the concentration of different substances which have 
the same effects in different mass or volume amounts – birch pollen extract vs 
grass pollen extract (measured in SQ-U; standardized quality units), retinol vs 
betacarotene (measured in RE, retinol equivalents), human insulin vs insulin 
analogues (measured in IU, international units).

To be able to specify medication strength in a meaningful way, I need a 
numerator (amount active substance) and a denominator (amount helper 
substance). The numerator can be a mass (such as mg), a volume (such as ml) or 
an arbitrary unit (such as IU). The denominator can be a volume, a mass or an 
administration unit (such as tablet or puff). Since there can be approximately 
a million different variations on mass, volume and arbitrary units, I don’t 
want to specify them all in the archetype, but leave it up to the application, 
while still specifying the property (mass, volume or arbitrary). At the moment, 
I can’t do this for the arbitrary units element, since there’s no property in 
the openEHR units properties terminology set for arbitrary units.

However, I’m starting to wonder if “” really is a misnamed “arbitrary units” property. Anyone know 
the origin of this? IU isn’t a mass unit, so it’s misnamed in any case (see 
https://en.wikipedia.org/wiki/International_unit).

Also, what would be really really neat, is a Quantity data type which could be 
any of a couple of a set of preselected properties (such as for instance mass, 
volume and arbitrary), and not just one fixed property. :o)

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Pablo Pazos
Sent: Monday, January 29, 2018 12:37 AM
To: For openEHR technical discussions 
Subject: RE: Quantities of arbitrary units in openEHR

Hi Silje,

When specifying the property but not the units, any units are allowed. This is 
saying "any units" which is similar to "arbitrary units". We can relax the spec 
to allow non-ucum as units (my interpretation of "any units" is any in ucum and 
compliant with the specified property, while "arbitrary" might be in or not in 
ucum, and compliant with the property).

What do you think?

On Jan 26, 2018 6:01 AM, "Bakke, Silje Ljosland" 
>
 wrote:
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