Postulate: DV_QUANTITY should be modelled with fewest possible units

Clinical (archive)
1

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

2

As mentioned on twitter, I agree with that postulate for templates,
but not general archetypes :slight_smile:

3

The original context for this discussion was this archetype: http://arketyper.no/ckm/#showArchetype_1078.36.25 (default archetype language for this CKM is Norwegian, but it can be changed manually)

Being an all-metric country since the 1800s, we've removed lbs as a possible unit, but added g (gram) for weighing infants.

Regards,
Silje

4

There is something I have been thinking about for a while, which is whether we need some kind of ‘profiles’ in archetypes, that can be used select or deselect alternative constraints. An ‘alternative’ in an archetype is technically

5

Could assertions/rules be used for this kind of profiles?

6

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?

7

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@freshehr.com
twitter: @ianmcnicoll

Director, freshEHR Clinical Informatics
Director, openEHR Foundation
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

8

Se below:

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

9

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

10

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

11

An application need that kind of service. But this is actually not the problem. See my latest mail regarding guildelines and population queries.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

12

I have been thinking about profiling. I am not sure if this fix the problem regarding complexity.

This may be an governance thing. If we define a metric and british imperial profile we may define that in Norway every application MUST use the metric profile and other countries may select “british imperial”. This could make it easier to set up validation on entries.

Is this a usage you were thinking about?

13

exactly. It requires defining the profiles in the archetypes as per my last post. I can see that it could work for units, not sure about other things. If such profiles were defined, it would then be possible to make a template tool remove elements you don’t want when creating templates. This would be done by the normal means e.g. path/to/imperial/quantity occurrences matches {0} but it would be done for you, and noone would have to go looking for them. - thomas

14

yes, exactly. That's why this thought it just a thought, and I have never proposed it seriously in the formalism - as soon as you start digging, everything gets muddy. Units may be one of the few things where profiles could even be stated. The question is then what do tools do with the profiles.

- thomas

15

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

16

I agree with both Ian and Heather.

We should keep the archetypes as "pure" as possible, to deviate as little as possible from the versions in the international CKM. It gives us a bit more workload in the templates, but from a administrative perspective we gain a lot by not having a bunch of local/regional/national archetypes.

When it comes to profiles, I fear we would soon have partly overlaping areas, where there would be disbute of which profile should be used. E.g ICU vs OR. And one day we would have "Dr Mabuse's profile"...

Cheers, Vebjørn

Denne meldingen inneholder ikke sensitiv informasjon som bryter med Oslo universitetssykehus HFs krav til informasjonssikkerhet.
(In compliance with the Security Policy of Oslo University Hospital, the content of this message (including any attachments) is of a non-sensitive nature)

-----Opprinnelig melding-----

17

Currently known as 'Dr Mabuse's template' :wink:

- thomas

18

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@freshehr.com
twitter: @ianmcnicoll

Director, freshEHR Clinical Informatics
Director, openEHR Foundation
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

19

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.

Vebjørn

(ikke sensitiv / non-sensitiv information)

-----Opprinnelig melding-----

20

I echo Vebjørn's comments!

Einar

-----Opprinnelig melding-----