SV: Postulate: DV_QUANTITY should be modelled with fewest possible units
varntzen at ous-hf.no
Fri Nov 14 06:54:23 EST 2014
What happened to "maximum data set"? To leave that idea by restricting units of choice on a national level in the definition of the archetype itself, will lead us into a dangerous path. To constrain in practical use through templates, is something else and in line with the concept, as I've understood it.
(ikke sensitiv / non-sensitiv information)
Fra: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] På vegne av Ian McNicoll
Sendt: 14. november 2014 10:54
Til: For openEHR technical discussions
Kopi: For openEHR clinical discussions
Emne: Re: Postulate: DV_QUANTITY should be modelled with fewest possible units
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'
"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".
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
email: ian at freshehr.com
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
> 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.
>> -----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?
>> 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.o
>> > pen
>> > ehr.org
>> > _______________________________________________
>> > openEHR-clinical mailing list
>> > openEHR-clinical at lists.openehr.org
>> > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.op
>> > ene
>> > hr.org
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> ehr.org _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org
More information about the openEHR-clinical