Hi Silje, On Mon, Jan 29, 2018 at 11:15 AM, Bakke, Silje Ljosland < [email protected]> 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 “<Property id="57" Text="Mass (IU)" > 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- > [email protected]] *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.bakke@ > 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- > [email protected]] *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:[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 > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -- Ing. Pablo Pazos Gutiérrez [email protected] +598 99 043 145 skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
