Re: Quantities of arbitrary units in openEHR

Fri, 26 Jan 2018 04:12:08 -0800

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 
<[email protected] 
<mailto:[email protected]>>:


    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:[email protected]
    <mailto:[email protected]>] *On Behalf
    Of *Diego Boscá
    *Sent:* Friday, January 26, 2018 10:18 AM
    *To:* For openEHR technical discussions
    <[email protected]
    <mailto:[email protected]>>
    *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
    <[email protected]
    <mailto:[email protected]>>:

        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:[email protected]
        <mailto:[email protected]>] *På
        vegne av* Diego Boscá
        *Sendt:* fredag 26. januar 2018 09:42
        *Til:* For openEHR technical discussions
        <[email protected]
        <mailto:[email protected]>>
        *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
        <[email protected]
        <mailto:[email protected]>>:

            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:[email protected]
            <mailto:[email protected]>] Im
            Auftrag von Thomas Beale
            Gesendet: Freitag, 26. Januar 2018 09:13
            An: [email protected]
            <mailto:[email protected]>
            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
            [email protected]
            <mailto:[email protected]>
            
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
            
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
            _______________________________________________
            openEHR-technical mailing list
            [email protected]
            <mailto:[email protected]>
            
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
            
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>





        -- 


        VeraTech for Health SL <https://htmlsig.com/t/000001C268PZ>

        Twitter <https://htmlsig.com/t/000001C47QQH> LinkedIn
        <https://htmlsig.com/t/000001C4DPJG> Maps
        <https://htmlsig.com/t/000001BZTWS7>

        *Diego Boscá Tomás*/ Senior developer
        [email protected] <mailto:[email protected]>
        [email protected] <mailto:[email protected]>

        *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 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 [email protected] <mailto:[email protected]>.


        _______________________________________________
        openEHR-technical mailing list
        [email protected]
        <mailto:[email protected]>
        
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
        
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>





    -- 


    VeraTech for Health SL <https://htmlsig.com/t/000001C268PZ>

    Twitter <https://htmlsig.com/t/000001C47QQH> LinkedIn
    <https://htmlsig.com/t/000001C4DPJG> Maps
    <https://htmlsig.com/t/000001BZTWS7>

    *Diego Boscá Tomás*/ Senior developer
    [email protected] <mailto:[email protected]>
    [email protected] <mailto:[email protected]>

    *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 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
    [email protected] <mailto:[email protected]>.


    _______________________________________________
    openEHR-technical mailing list
    [email protected]
    <mailto:[email protected]>
    
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
    
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>




--

VeraTech for Health SL <https://htmlsig.com/t/000001C268PZ>


Twitter <https://htmlsig.com/t/000001C47QQH>LinkedIn 
<https://htmlsig.com/t/000001C4DPJG>Maps 
<https://htmlsig.com/t/000001BZTWS7>


Diego Boscá Tomás / Senior developer
[email protected]<mailto:[email protected]>
[email protected] <mailto:[email protected]>

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 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 [email protected] 
<mailto:[email protected]>.




_______________________________________________
openEHR-technical mailing list
[email protected]
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
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org






















					Reply via email to