Thanks Bjorn, That explanation was helpful in refining the issue.
I think we all agree that there is real requirement to allow clinicians to work (visually, data-entry and querying) on their unit of choice. We can try to manage / constrain the units available, more appropriate at national level, as Sijje has suggested, but we are still left wit the body weight example where g/kg are required at point of care. OTOH I understand Bjorn's point that having to deal with multiple units at query / interface time seems needlessly complex and one option would be to force the use of kg and make it the responsibility of the app developer to do appropriate conversion / display. However part of the purpose of building archetypes is to document this kind of sort of real-world variation so that local developers do not need to discover this for themselves. As such I am reluctant to force archetypes to single units where conversion is possible. I think Pablo is on the right track. I think we should take advantage of the conversion rules where they exist which might allow units to be aliased e.g. body_weight/magnitude.asunit['kg'] which would force the conversion of any kg units to g. This could be used in queries, data retrieval or storage. FHIR has the idea of 'canonical units' http://www.hl7.org/implement/standards/fhir/search.html#quantity "If the units are able to be coded in UCUM and a code is provided, it SHOULD be a UCUM code. If a UCUM unit is provided in the codethen a canonical value can be generated for purposes of comparison between quantities. Note that the units element will often contain text that is actually a valid UCUM unit, but it cannot be assumed that the units element actually contains a valid UCUM unit". Ian 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 06:06, Bj?rn N?ss <bna at dips.no> 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. > > > > Vennlig hilsen > Bj?rn N?ss > Product owner > DIPS ASA > > Mobil +47 93 43 29 10 > > -----Original Message----- > From: openEHR-technical [mailto:openehr-technical-bounces at > lists.openehr.org] 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 > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
