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" <[email protected]> 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 < > [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:openehr-technical-boun >> [email protected]] *On Behalf Of *Diego Boscá >> *Sent:* Friday, January 26, 2018 10:18 AM >> *To:* For openEHR technical discussions <[email protected] >> 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 < >> [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 >> >> 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 >> [email protected]] *På vegne av* Diego Boscá >> *Sendt:* fredag 26. januar 2018 09:42 >> *Til:* For openEHR technical discussions <[email protected] >> 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 >> [email protected]] Im Auftrag von Thomas Beale >> Gesendet: Freitag, 26. Januar 2018 09:13 >> An: [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] >> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >> lists.openehr.org >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >> lists.openehr.org >> >> >> >> >> -- >> >> [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ> >> >> [image: Twitter] <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn] >> <https://htmlsig.com/t/000001C4DPJG> [image: Maps] >> <https://htmlsig.com/t/000001BZTWS7> >> >> *Diego Boscá Tomás* / Senior developer >> [email protected] >> [email protected] >> >> *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 [email protected]. >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >> lists.openehr.org >> >> >> >> >> -- >> >> [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ> >> >> [image: Twitter] <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn] >> <https://htmlsig.com/t/000001C4DPJG> [image: Maps] >> <https://htmlsig.com/t/000001BZTWS7> >> >> *Diego Boscá Tomás* / Senior developer >> [email protected] >> [email protected] >> >> *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 [email protected]. >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >> lists.openehr.org >> > > > > -- > > [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ> > > [image: Twitter] <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn] > <https://htmlsig.com/t/000001C4DPJG> [image: Maps] > <https://htmlsig.com/t/000001BZTWS7> > > Diego Boscá Tomás / Senior developer > [email protected] > [email protected] > > 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 [email protected]. > > > _______________________________________________ > openEHR-technical mailing > [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 >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
