Hi Silje, My thinking is for your use case, DV_QUANTITY doesn't apply for arbitrary, since those seem not related with physical properties (mass, length, area, concentration, etc.)
As I said, "level of X" makes me think of DV_ORDINAL. DV_PROPORTION would be used for numerator / denominator modeling, but currently doesn't support units so it's real / real. My suggestion was to analyze the change from that to an arbitrary type for each numerator and denominator, so you can model DV_QUANTITY / DV_QUANTITY proportions. Also DV_ORDINAL doesn't have a unit but has a DV_CODED_TEXT, maybe your arbitrary units are really terms from a given terminology, so this might be good to model that. But as I said, for this specific use case you might need to use many data points (ELEMENTS) of different types, inside a CLUSTER to be able to comply with all your requirements (please check my previous message where I outlined your requirements as I understood them). Hope that helps. On Tue, Jan 30, 2018 at 11:55 AM, Bakke, Silje Ljosland < silje.ljosland.ba...@nasjonalikt.no> wrote: > Hi Pablo, > > > > This is our current modelling, for reference (the administration unit > denominator isn’t modelled): > > > > I don’t see how either ordinals or proportions, the way they currently > work, can be of any help here. > > > > Regards, > *Silje* > > > > *From:* openEHR-technical [mailto:openehr-technical- > boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos > *Sent:* Monday, January 29, 2018 4:34 PM > *To:* For openEHR technical discussions <openehr-technical@lists. > openehr.org> > *Subject:* Re: Quantities of arbitrary units in openEHR > > > > Hi Silje, > > > > On Mon, Jan 29, 2018 at 11:15 AM, Bakke, Silje Ljosland < > silje.ljosland.ba...@nasjonalikt.no> 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- > boun...@lists.openehr.org] *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- > 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> > *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: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] <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 > diebo...@veratech.es > yamp...@gmail.com > > *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 verat...@veratech.es. > > > _______________________________________________ > 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 > > > > > -- > > Ing. Pablo Pazos Gutiérrez > pablo.pa...@cabolabs.com > +598 99 043 145 <099%20043%20145> > 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 > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -- Ing. Pablo Pazos Gutiérrez pablo.pa...@cabolabs.com +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 openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
