Again, I strongly believe we can achieve this with Assertions/pseudo-OCL that currently can be defined in archetypes. For example: "if 'units' from atNNNN are 'kg' then 'value'='value'*1000 and 'units'=g"
I think Thomas told me there were some improvements in the archetype assertions section/syntax. 2014-11-14 13:12 GMT+01:00 Bj?rn N?ss <bna at dips.no>: > 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
