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<tel:+47%2093%2043%2029%2010> -------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141114/5aa01478/attachment-0001.html>
