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 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
<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
<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
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 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 <mailto:verat...@veratech.es>.
_______________________________________________
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
<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
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 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
<mailto:verat...@veratech.es>.
_______________________________________________
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
<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
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 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 <mailto:verat...@veratech.es>.
_______________________________________________
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
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
