I think we could add something at reference model level to say give me this quantity in 'x' units, performing the conversion at server level where possible or return null. This could also be supported in AQL since it would just be another RM attribute/function?
Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 14 November 2014 12:12, Bj?rn N?ss <bna at dips.no> wrote: > I guess smart querying services would do the work. But should it also be > possible for the client to say when unit conversion should be used and when > not? > > Use case is when user only want the units stored as grams, and not kilos. > > Maybe a pattern from HTTP could be used. The accept pattern. > > Accept: profile (metrics, british imperial) > Accept: gram, kilos > > Of course all this add complexity and we must be sure that we really need > it. > > > Vennlig hilsen > Bj?rn N?ss > Produktansvarlig > DIPS ASA > > Mobil +47 93 43 29 10 > > > -------- Original message -------- > From: Thomas Beale > Date:14/11/2014 10:14 (GMT+01:00) > To: openehr-technical at lists.openehr.org > Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible > units > > > Should we have a way of marking the 'normative' units for computation / > conversion? So that then you only create AQL queries in the units you > want, and let the query service do the rest (e.g. by looking up the UCUM > DB)? In fact, you don't even need to mark anything as normative, if the > query service is smart, if would know how to do units comparisons. If it > hits weight data in other units, it does an on-the-fly conversion. > > - thomas > > On 14/11/2014 06:06, Bj?rn N?ss wrote: >> Thanks for your feedback on this small topic. I agree with your opinions, >> and this may not be a huge problem. My point of view is not from an >> Archetype or Template modelling point. I am more into Guideline modelling >> and population queries. >> >> Take for instance the guide for Body Mass Index: >> https://github.com/openEHR/gdl-tools/blob/master/cm/guidelines/BMI.Calculation.v.1.gdl >> . This rule will be more complex if we add more units. Then the guideline >> editor must consider all possible units and conversion between them. That is >> of course doable and MUST be done if the clinical model say this is needed. >> >> Another use-case is population queries. If I want to find all entries of >> body-weight that is between 0,3 and 3 kg. I must create a query that >> consider all possible units; both grams and kilos from the metrics and lb >> from the imperial. This is of course doable, but add more complexity when >> querying. >> >> I agree with you that this could be handled by templating. For a given >> system we should use Templates that secure data quality, i.e. always use the >> same unit for given use-cases. >> >> When I use the term system I do not mean one application. I am thinking >> about the system of all health care applications in a large health >> enterprise or a nation. If we only talk about applications this will not be >> a problem, because you may/should have control on templates. >> >> @ian e.g very young children where some clinicians use grams and others >> use kg for exactly the same patients in exactly the same circumstances. >> Yes - some clinicians want to use grams and other kgs. And I think the >> application used to display data and/or create data should handle this. >> >> If I am, as a clinician, used to think of a given quantity in grams, then >> I want the application to give me data in grams. As clinician should not >> have to use brain-capacity to convert between different units. Working in >> neonatal I want all weights to be grams. But the question is if we then MUST >> add grams to the Archetype? >> >> @ian Creating 2 different archetypes for each unit only moves the querying >> complexity elsewhere (arguably worse). >> I agree when you put it like this :-). This would be a nightmare if we >> have one archtype for each unit. >> >> And to bring back the postulate: "DV_QUANTITY should be modelled with >> fewest possible units". This only means that we should be restrictive when >> adding more units because it may add complexity when using the archetype. > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
