Re: Quantities of arbitrary units in openEHR

[Pablo Pazos]

But you can't specify terms in DV_COUNT while DV_ORDINAL.symbol can be used
to specify the arbitrary units but not as physical property units of
measure, but as a terminology concept / term.

On Tue, Jan 30, 2018 at 1:30 PM, Thomas Beale 
wrote:

>
> On 30/01/2018 16:24, Pablo Pazos wrote:
>
>> Hi Silje,
>>
>> My thinking is for your use case, DV_QUANTITY doesn't apply for
>> arbitrary, since those seem not related with physical properties (mass,
>> length, area, concentration, etc.)
>>
>> As I said, "level of X" makes me think of DV_ORDINAL.
>>
>
> or even DV_COUNT.
>
> I have asked some questions of knowledgeable ontology sources; will post
> any replies I get here.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
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]

On 30/01/2018 16:24, Pablo Pazos wrote:

Hi Silje,

My thinking is for your use case, DV_QUANTITY doesn't apply for 
arbitrary, since those seem not related with physical properties 
(mass, length, area, concentration, etc.)


As I said, "level of X" makes me think of DV_ORDINAL.


or even DV_COUNT.

I have asked some questions of knowledgeable ontology sources; will post 
any replies I get here.


- thomas


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

My thinking is for your use case, DV_QUANTITY doesn't apply for arbitrary,
since those seem not related with physical properties (mass, length, area,
concentration, etc.)

As I said, "level of X" makes me think of DV_ORDINAL.

DV_PROPORTION would be used for numerator / denominator modeling, but
currently doesn't support units so it's real / real. My suggestion was to
analyze the change from that to an arbitrary type for each numerator and
denominator, so you can model DV_QUANTITY / DV_QUANTITY proportions.

Also DV_ORDINAL doesn't have a unit but has a DV_CODED_TEXT, maybe your
arbitrary units are really terms from a given terminology, so this might be
good to model that.

But as I said, for this specific use case you might need to use many data
points (ELEMENTS) of different types, inside a CLUSTER to be able to comply
with all your requirements (please check my previous message where I
outlined your requirements as I understood them).


Hope that helps.



On Tue, Jan 30, 2018 at 11:55 AM, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Hi Pablo,
>
>
>
> This is our current modelling, for reference (the administration unit
> denominator isn’t modelled):
>
>
>
> I don’t see how either ordinals or proportions, the way they currently
> work, can be of any help here.
>
>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* Monday, January 29, 2018 4:34 PM
> *To:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> *Subject:* Re: Quantities of arbitrary units in openEHR
>
>
>
> 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<num_type,
> den_type>, so something like DV_PROPORTION<DV_QUANTITY, DV_QUANTITY> 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<DV_ORDERED, DV_ORDERED> might
> be a better solution but needs changes

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<num_type,
den_type>, so something like DV_PROPORTION<DV_QUANTITY, DV_QUANTITY> 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<DV_ORDERED, DV_ORDERED> 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-technical@lists.
> 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).
>

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" <thomas.be...@openehr.org 
<mailto:thomas.be...@openehr.org>> 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
<silje.ljosland.ba...@nasjonalikt.no
<mailto:silje.ljosland.ba...@nasjonalikt.no>>:

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
<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
<openehr-technical@lists.openehr.org
<mailto:openehr-technical@lists.openehr.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
<mailto: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
<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
<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-technical@lists.openehr.org
<mailto:openehr-technical@lists.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 &q

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 <openehr-technical@lists.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" 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@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 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<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-technical@lists.openehr.org<mailto:openehr-technical@lists.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 
<sebastian.ga...@oceaninformatics.com<mailto: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

Re: Quantities of arbitrary units in openEHR

[Pablo Pazos]

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" <thomas.be...@openehr.org> 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 <
> silje.ljosland.ba...@nasjonalikt.no>:
>
>> 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 <openehr-technical@lists.opene
>> 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 <openehr-technical@lists.opene
>> 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&

RE: Quantities of arbitrary units in openEHR

[Pablo Pazos]

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" <
silje.ljosland.ba...@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 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-technical@lists.
> 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 <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.open

RE: Quantities of arbitrary units in openEHR

[A Verhees]

So, to explain Diego's proposal.

Now the units field in DvQuantity in an archetype is of type string. This
enforces everyone using that archetype to use that specific unit, while,
maybe, in a country or situation that is not convenient.

Diego proposes to replace the string by a UCUM termbinding, for example
UCUM::mass, so every unit-string inside this boundary can be used, and the
reader of the dataset can ask for another unit, if desired, because UCUM
knows how to convert from one to another unit inside the same boundary.

So it is only a small redesign which is needed, and backwards compatibility
may be important.

I don't know if Diego's proposal is feasible and I hope to hear from others
what they think.

Bert




Op 28 jan. 2018 23:17 schreef "A Verhees" <bert.verh...@rosa.nl>:

> Sam, for me the point was not having an OpenEhr property but an UCUM
> property which has also conversion routines for units within that property
> boundary available, so that it does not matter if the dataset contains
> Fahrenheit or Celsius when property "temperature" was constrained, because
> UCUM can tell the data validating/interpretating software how to understand
> the value and how to convert to another unit if desired.
>
> This needs a redesign of the DvQuantity, see the example Diego described a
> few days ago.
>
> Best regards
> Bert
>
>
> Op 28 jan. 2018 22:32 schreef "Sam Heard" <sam.he...@oceaninformatics.com
> >:
>
>> Hi All
>>
>> The ‘property’ editor is available with the archetype editor. Has anyone
>> had a look at adding the required type and then the whatever bit can be in
>> all the tools.
>>
>> Cheers, Sam
>>
>>
>>
>> *From:* openEHR-technical [mailto:openehr-technical-boun
>> c...@lists.openehr.org] *On Behalf Of *Sebastian Garde
>> *Sent:* Thursday, 25 January 2018 7:33 PM
>> *To:* For openEHR technical discussions <openehr-technical@lists.opene
>> hr.org>
>> *Subject:* AW: Quantities of arbitrary units in openEHR
>>
>>
>>
>> This sender failed our fraud detection checks and may not be
>>  who they appear to be. Learn about spoofing
>> <http://aka.ms/LearnAboutSpoofing>
>>
>> Feedback <http://aka.ms/SafetyTipsFeedback>
>>
>> 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
>> c...@lists.openehr.org <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 di

RE: Quantities of arbitrary units in openEHR

[A Verhees]

Sam, for me the point was not having an OpenEhr property but an UCUM
property which has also conversion routines for units within that property
boundary available, so that it does not matter if the dataset contains
Fahrenheit or Celsius when property "temperature" was constrained, because
UCUM can tell the data validating/interpretating software how to understand
the value and how to convert to another unit if desired.

This needs a redesign of the DvQuantity, see the example Diego described a
few days ago.

Best regards
Bert


Op 28 jan. 2018 22:32 schreef "Sam Heard" <sam.he...@oceaninformatics.com>:

> Hi All
>
> The ‘property’ editor is available with the archetype editor. Has anyone
> had a look at adding the required type and then the whatever bit can be in
> all the tools.
>
> Cheers, Sam
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Sebastian Garde
> *Sent:* Thursday, 25 January 2018 7:33 PM
> *To:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> *Subject:* AW: Quantities of arbitrary units in openEHR
>
>
>
> This sender failed our fraud detection checks and may not
> be who they appear to be. Learn about spoofing
> <http://aka.ms/LearnAboutSpoofing>
>
> Feedback <http://aka.ms/SafetyTipsFeedback>
>
> 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 <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 <+47%20402%200

RE: Quantities of arbitrary units in openEHR

[Sam Heard]

Hi All

The 'property' editor is available with the archetype editor. Has anyone had
a look at adding the required type and then the whatever bit can be in all
the tools.

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Sebastian Garde
Sent: Thursday, 25 January 2018 7:33 PM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: AW: Quantities of arbitrary units in openEHR

 


This sender failed our fraud detection checks and may not be who they appear
to be. Learn about spoofing <http://aka.ms/LearnAboutSpoofing> 

Feedback <http://aka.ms/SafetyTipsFeedback> 

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
<mailto: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/> http://arketyper.no / Twitter:
<https://twitter.com/arketyper_no> @arketyper_no

 





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

 

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

[Bert Verhees]

On 27-01-18 11:16, Thomas Beale wrote:


Bert,

I don't disagree philosophically, but practically speaking, no SNOMED 
service is going to be able to answer requests to do with unit 
properties, unit conversions, or different forms of rendering, which 
are all things we need to take care of properly.


I actually think units is one of the things we should just do 
properly, and in only one way for openEHR. I can't imagine why anyone 
would use SNOMED for units instead of a proper units service that 
supported the above, even if they use SNOMED for everything else. 
There is of course nothing preventing anyone adding bindings from 
SNOMED to the units paths in archetypes.




I personally think that UCUM does a outstanding good job. One thing that 
is missing is translations, this is important in countries which have 
another script, like Arabs or Chinese or many many other. The majority 
of the world population does not use the Latin alphabet.


And this is where SNOMED comes in, it is getting translated by the 
people who use it. And I found somewhere on the internet a mapping from 
UCUM to SNOMED, and when I looked again, I coudn't find it anymore. 
SNOMED has infrastructure to take care of translations (done by the 
national standard bodies). That is one of its important strengths. HL7 
is quite America bounded, and UCUM is (as far as I know) a typical HL7 
product, from this point of view.

Please correct me if I am wrong.

Most people of the world cannot read/write English and they also need to 
use medical software/devices, and it is a good thing that translations 
are delivered by an authority like a national standard body, instead of 
vendors more or less educated


I think that is obvious that the mapping between SNOMED and UCUM will 
come if it isn't there yet. So restricting the termbindings regarding 
DvQuantity-property to UCUM may become a problem, although, promoting 
the use is not wrong, like tooling promoted also the use of the OpenEhr 
units-terminology


But it may be alright to define in the RM that the DvQuantity-property 
is like the UCUM-property, but then without mentioning the word UCUM ;-)
And of course, that the unit-string must be restricted by the general 
higher hierarchy of the property domain (like Mass, energy, etc)


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

[Bert Verhees]

On 27-01-18 11:10, Bert Verhees wrote:
If one wants an UCUM term in the DvQuantity and another wants a SNOMED 
term, it is both legal and possible.


What is preferable, that is not to us to decide while thinking about 
OpenEhr. 


But having said this

Until now, in practice, people use the OpenEhr terminology for units 
because that is what the tooling offers. This is not enforced by the RM, 
but it is common practice.


Now UCUM emerge, and then it is also good to accept termbindings for 
defining the property to restrict the units which may be used in the 
DvQuantity.


But does this mean that it is not anymore allowed to use another 
terminology to define a property, that UCUM would be part of the RM, 
does this mean that OpenEhr will be inseparable connected to UCUM?


I don't think that is wise. It breaks with the standard philosophy of 
OpenEhr to offer as much freedom as is possible to the archetype designer.


SNOMED offers also higher hierarchy concepts for properties, for 
example, 118538004: Mass


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

[Thomas Beale]

Bert,

I don't disagree philosophically, but practically speaking, no SNOMED 
service is going to be able to answer requests to do with unit 
properties, unit conversions, or different forms of rendering, which are 
all things we need to take care of properly.


I actually think units is one of the things we should just do properly, 
and in only one way for openEHR. I can't imagine why anyone would use 
SNOMED for units instead of a proper units service that supported the 
above, even if they use SNOMED for everything else. There is of course 
nothing preventing anyone adding bindings from SNOMED to the units paths 
in archetypes.


- thomas


On 27/01/2018 10:10, Bert Verhees wrote:

On 26-01-18 10:00, Thomas Beale wrote:


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 OpenEhr is a registering system, so if archetypes will be written 
to define datasets which use a SNOMED-term, then OpenEhr supports 
that, because OpenEhr supports archetypes.


You cannot negate termbindings on AOM/ADL-level in expressing (for 
example), we do not accept SNOMED (only UCUM) at this point, it is the 
archetype-designer who decides that. I think that is one of the best 
features of OpenEhr, the semantic standards are by the user to define. 
OpenEhr facilitates. There is the success factor of OpenEhr.


The solution Diego described yesterday works perfect for many point of 
views and fits in the OpenEhr paradigms.
If one wants an UCUM term in the DvQuantity and another wants a SNOMED 
term, it is both legal and possible.


What is preferable, that is not to us to decide while thinking about 
OpenEhr.


Best regards
Bert

___
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

Re: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 26-01-18 10:00, Thomas Beale wrote:


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 OpenEhr is a registering system, so if archetypes will be written to 
define datasets which use a SNOMED-term, then OpenEhr supports that, 
because OpenEhr supports archetypes.


You cannot negate termbindings on AOM/ADL-level in expressing (for 
example), we do not accept SNOMED (only UCUM) at this point, it is the 
archetype-designer who decides that. I think that is one of the best 
features of OpenEhr, the semantic standards are by the user to define. 
OpenEhr facilitates. There is the success factor of OpenEhr.


The solution Diego described yesterday works perfect for many point of 
views and fits in the OpenEhr paradigms.
If one wants an UCUM term in the DvQuantity and another wants a SNOMED 
term, it is both legal and possible.


What is preferable, that is not to us to decide while thinking about 
OpenEhr.


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

[GF]

Semantic Interoperability is possible only when each. distinct domain:
has its own model
has its own rules
and always orthogonal to other models.

A terminology can be equated to a Dictionary.
A terminology is never an Encyclopedia of everything.

We need a terminology of concepts related to the Patient System.
And we need a terminology for things not related, such as Units of Measurement.
There will be more terminologies we need: basic archetype patterns for 
documentation, time-related concepts, medical devices, continuity of care, 
business modelling, etc.

So I agree with Thomas.
SNOMED must have bounderies.
I fear that the SNOMED world is without a well defined scope.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 26 Jan 2018, at 10:00, Thomas Beale  wrote:
> 
> 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

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

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 
<silje.ljosland.ba...@nasjonalikt.no 
<mailto:silje.ljosland.ba...@nasjonalikt.no>>:


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
<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
<openehr-technical@lists.openehr.org
<mailto:openehr-technical@lists.openehr.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
<mailto: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
<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
<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-technical@lists.openehr.org
    <mailto:openehr-technical@lists.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
<sebastian.ga...@oceaninformatics.com
<mailto: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 

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 <silje.ljosland.bakke@
nasjonalikt.no>:

> 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 <openehr-technical@lists.opene
> 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 <openehr-technical@lists.opene
> 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 <sebastian.garde@oceaninformat
> 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 so

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 <openehr-technical@lists.openehr.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<mailto: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<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-technical@lists.openehr.org<mailto:openehr-technical@lists.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 
<sebastian.ga...@oceaninformatics.com<mailto: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<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<mailto: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<mailto: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<mailt

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-technical@lists.
> 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 <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] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/0

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 <openehr-technical@lists.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 
<sebastian.ga...@oceaninformatics.com<mailto: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<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<mailto: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<mailto: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<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--

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

[Twitter] <https://htmlsig.com/t/01C47QQH>  [LinkedIn]  
<https://htmlsig.com/t/01C4DPJG>  [Maps]  
<https://htmlsig.com/t/01BZTWS7>
[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

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

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

Su dirección de correo electrónico junto a sus datos personales forman parte de 
un fichero titularidad 

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] <https://htmlsig.com/t/01C268PZ>

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

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

VeraTech for Health SL
+34 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

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

[Pieter Bos]

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

Op 26 jan. 2018 om 08:19 heeft Bakke, Silje Ljosland 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>
 het volgende geschreven:

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

Regards,
Silje

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Sebastian Garde
Sendt: torsdag 25. januar 2018 11:03
Til: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Emne: AW: Quantities of arbitrary units in openEHR

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<mailto: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<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>

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

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

RE: Quantities of arbitrary units in openEHR

[Bakke, Silje Ljosland]

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

Regards,
Silje

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Sebastian Garde
Sendt: torsdag 25. januar 2018 11:03
Til: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Emne: AW: Quantities of arbitrary units in openEHR

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<mailto: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<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>

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

--
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<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>





___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>

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

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

[Thomas Beale]

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

Re: Quantities of arbitrary units in openEHR

[Bert Verhees]

It would be good if OpenEhr RM would support the UCUM-properties fully 
in the DvQuantity, then all problems regarding units would be over for 
the next 20 years, and no maintenance on customer or OpenEHR-foundation 
side is needed. UCUM is, I think, widely regarded as the most important 
unit-registration system.


I haven't thought about which changes are needed to do this, sorry for 
that, but I am sure the community is very well able to handle this.


By the way, if someone needs a UCUM-library for Golang, I have written 
one in open source, find it here:

https://github.com/BertVerhees/ucum
Grahame Grieve and some FHIRT enthousiasts have written one for Java:
https://github.com/FHIR/Ucum-java

Best regards
Bert


On 24-01-18 10: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



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

Quantities of arbitrary units in openEHR

[Bakke, Silje Ljosland]

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