date:20180128

Re: Quantities of arbitrary units in openEHR

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

RE: Quantities of arbitrary units in openEHR

2018-01-28 Thread 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.org>
> *Emne:* Re: Quantities of arbitrary units in openEHR
>
>
>
> I think there are several potential problems with this, and IMHO we are
> stepping too much on what should be done in a terminology service (We are
> literally talking about a 'public available UCUM service'). You can also
> ask the terminology service what kind of unit code you have. Your
> implementation could answer "arbitrary" for these new units.
>
>
>
> In my opinion, saying "here comes a mass unit code" is not much different
> from "here comes a diagnosis code", and we say these in a completely
> different way (a better way, if you ask me).
>
>
>
> Also, I'm not a big fan of "arbitrary" property, as feels like a "other"
> kind of terminology code that is potentially dangerous as knowledge or
> terminology advances, thus coexisting 'arbitrary' and 'new shiny type of
> measurements' all mixed up. That's why I also expect these properties to be
> as derived from the codes and not the other way around.
>
>
>
> 2018-01-26 9:21 GMT+01:00 Sebastian Garde  oceaninformatics.com>:
>
> While I agree with the SPEC-95 rationale (once you have a unit, you should
> be able to know what its property is), it is still convenient to have the
> property for constraining.
> Otherwise you don't have a way to say in an archetype: I don't care about
> the exact unit here, but please let it be a "Mass".
>
> -Ursprüngliche Nachricht-
> Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
> Im Auftrag von Thomas Beale
> Gesendet: Freitag, 26. Januar 2018 09:13
> An: openehr-technical@lists.openehr.org
> Betreff: Re: Quantities of arbitrary units in openEHR
>
> Right - at the moment, it is a 'fake' field in archetypes, enabled by
> being in the BMM or other expression of the RM. It's convenient to do this
> occasionally, since we don't think 'property' needs to be a field of
> DV_QUANTITY - but maybe it should be, since for some of the more esoteric
> units, it's not that clear what is being measured.
>
> This trick is also not mentioned in the ADL/AOM specs, and it either
> should be, or we just don't allow it. I don't have a strong opinion either
> way.
>
> - thomas
>
>
> On 26/01/2018 07:51, Pieter Bos wrote:
> > A bit unrelated perhaps, but in the 1.0.3 and 1.0.4 RM specification,
> > there is no property attribute or function present in dv_quantity,
> > even though the text says it can be conveniently constrained. There is
> > a reference to the spec-95 jira issue, which says it has been removed.
> > So there’s no way to constrain it - unless the specification contains
> > a mistake :)
> >
> > It is present in the BMM variants of the RM though, as a mandatory field.
> >
> > Regards,
> >
> > Pieter Bos
> >
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
>
>
> --
>
> [image: VeraTech for Health SL] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> *Diego Boscá Tomás* / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> *VeraTech for Health SL*
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%20

RE: Quantities of arbitrary units in openEHR

2018-01-28 Thread 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" :

> 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"  >:
>
>> 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 > 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
>> 
>>
>> Feedback 
>>
>> 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 ] *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 u

RE: Quantities of arbitrary units in openEHR

2018-01-28 Thread 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" :

> 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.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
> 
>
> Feedback 
>
> 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 <+47%20402%2003%20298>
>
> 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 Fo

RE: Quantities of arbitrary units in openEHR

2018-01-28 Thread 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 
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  

Feedback  

Hi Silje,

 

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

 

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

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

 

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

 

Regards

Sebastian

 

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

 

Hi Silje,

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

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

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

- thomas

 

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

Hi all,

 

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

 

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

 

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

 

Kind regards,
Silje Ljosland Bakke

 

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web:   http://arketyper.no / Twitter:
 @arketyper_no

 





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

 

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

RE: Quantities of arbitrary units in openEHR

RE: Quantities of arbitrary units in openEHR

RE: Quantities of arbitrary units in openEHR

RE: Quantities of arbitrary units in openEHR

5 matches

Site Navigation

Mail list logo

Footer information