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. Vennlig hilsen Bj?rn N?ss Product owner DIPS ASA Mobil?+47 93 43 29 10 -----Original Message----- From: openEHR-technical [mailto:[email protected]] On Behalf Of Heather Leslie Sent: 14. november 2014 06:09 To: For openEHR technical discussions; For openEHR clinical discussions Subject: RE: Postulate: DV_QUANTITY should be modelled with fewest possible units I echo Ian's opinion. The value of having an archetype with metric and imperial units inside the one asset is that if you use one unit, you can still compute if you receive data using the other units as you have a common model and clear relationship between units. Templates is where you select what you want for your use case. If you take one set of units out of your archetype then when you receive data using alternative units you are relying on application based assumptions of semantic equivalence, rather than the 'no-brainer' of using the same archetype, different units. And the notion of managing/governing/maintaining profiles, on top of archetypes, templates, terminology subsets, GDL rules and AQL queries makes my modelling/governing head hurt. I don't think this is sustainable, even if it is desirable. IMO this is what templates are for. Regards Heather > -----Original Message----- > From: openEHR-technical [mailto:openehr-technical- > bounces at lists.openehr.org] On Behalf Of Ian McNicoll > Sent: Friday, 14 November 2014 11:57 AM > To: For openEHR clinical discussions > Cc: openeh technical > Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest > possible units > > Hi Pablo, > > I would agree, this information is also carried in the Archetype > Editor property files, although I suspect not as well maintained as the UCUM > file. > > @Bjorn - I am not really sure why this is such a problem. > > As a modeller I would expect to remove any unwanted/unneeded units at > template level. You would there fore only be having to deal with > situations such as body weight where in your context both grams or kg might > be specified. > Again as a modeller I would want to reduce this complexity where > possible but there must be clinical situation e.g very young children > where some clinicians use grams and others use kg for exactly the same > patients in exactly the same circumstances. > Creating 2 different archetypes for each unit only moves the querying > complexity elsewhere (arguably worse). > > @Thomas - the profile suggestion is interesting but it feels to me > that it adds level of categorisation that is likely to be imprecise > e.g map is certainly not just only used in anaesthesia, and even the > use of imperial vs metric is likely to e somewhat blended in places > e.g the UK where although metric is used officially, it is quite common for > patients themselves to use imperial. > > Perhaps I am missing something? > > > 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 00:07, pablo pazos <pazospablo at hotmail.com> wrote: > > Hi Bj?rn, > > > > IMO when you have complex unit processing, a lookup service for UCUM > > might be needed. UCUM contains multipliers and correspondences between > > different unit systems, check this: > > > > http://unitsofmeasure.org/ucum-essence.xml > > > > Using this, a constraint on archetypes might not be needed. What do > > you think? > > > > -- > > Kind regards, > > Eng. Pablo Pazos Guti?rrez > > http://cabolabs.com > > > > ________________________________ > > From: bna at dips.no > > To: openehr-technical at lists.openehr.org; > > openehr-clinical at lists.openehr.org > > Subject: Postulate: DV_QUANTITY should be modelled with fewest > > possible units > > Date: Thu, 13 Nov 2014 20:07:00 +0000 > > > > > > I want to try out a postulate regarding modelling of datavalues, and > > more specific DV_QUANTITY. > > > > > > > > The postulate is: > > > > > > > > Postulate 1: A data type of DV_QUANTITY should be modelled with fewest > > possible units! > > > > > > > > Reason behind this is to make queries and reasoning over the values easy. > > This makes it both faster and safer building sustainable software and > > systems using these values. > > > > I also think that converting between i.e. grams and kilos should be > > done in the client (user interface / integration engine/ etc.). > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > > > Vennlig hilsen > > Bj?rn N?ss > > Product Owner > > DIPS ASA > > > > Mobil +47 93 43 29 10 > > > > > > > > > > _______________________________________________ openEHR-technical > > mailing list openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open > > ehr.org > > > > _______________________________________________ > > openEHR-clinical mailing list > > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.opene > > hr.org > > _______________________________________________ > 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
