Percent as DV_PROPORTION or DV_QUANTITY

Hi all!

This is a conundrum we’ve been talking about informally for a long time, but never really concluded. openEHR has two possible ways of representing a percentage:

  1. DV_PROPORTION with type = 1
  2. DV_QUANTITY with unit = %

We haven’t been clear on which one of these should be used for which use cases. I have a hypothesis which I’d like to get some input on:

  1. When we’re talking about physical concentrations such as saline concentration or oxygen saturation we should probably use DV_QUANTITY with units of %, [ppth], [ppm] or [ppb].
  2. When we’re talking about abstract or otherwise unitless concepts such as percent weight change over a time interval, or measured/predicted FVC, it’s probably more reasonable to use DV_PROPORTION.

Thoughts?

1 Like

Sorry for the rush, but does anyone have any thoughts about my hypothesis? :smile:

1 Like

This is probably stuff for @thomas.beale but to me a percentage is more a proportion (with denominator 100) than a quantity. (Sitting waiting to learn how things really are :))
One thing I think is important is that they are easy to work with at the RM level, independent of implementer choices of DV (query, conversion etc. )

1 Like

To me a concentration is not a quantity.

“ concentration ratios, e.g. Na:K (unitary denominator)” is an example use of DV_PROPORTION Data Types Information Model

“ including percent” is what it says in de ‘type’ attribute.

1 Like

In scientific reality, I agree with you. However, the UCUM units system treats ‘%’ as a kind of unit, so that’s how it gets represented in openEHR - as a DV_QUANTITY with % units.

1 Like

Yes - this was written before UCUM had a ‘%’ unit. We should fix this…

2 Likes

My thinking is that for example lab results will come from the LIS as a number with a unit. The unit for some (for example CO-Hemoglobin) will be given as ‘%’. To me it makes more sense to put this in a DV_QUANTITY than a DV_PROPORTION :woman_shrugging:

2 Likes

Do you mean that you think all percents should be DV_QUANTITY, and not DV_PROPORTION? We have a significant number of archetypes modelled where we use DV_PROPORTION for percents. Example: Spirometry result

1 Like

I don’t know - if it makes more sense to have some as proportions, there is no reason not to use proportion. As @ian.mcnicoll always says, in a certain sense, it doesn’t matter how you model things (let’s say, at the ‘fine’ level), as long as each thing is modelled only once, and in a discoverable place.

It may be that clinical modellers want to create a simple modelling rule of thumb for this question.

2 Likes

Aaah yes, I can see why in this it makes more sense that percentage is unit. And for real world, considering integration scenarios in lab use cases and the lack of an expected conversation need (no one does Hb as a fraction), I think percentage as a unit in dv quantity makes most sense here.
(Theoretically it’s still a proportion to me).

2 Likes

@siljelb - I’m happy enough with your distinction but I might make it tighter and only use DV_PROPORTION for examples where the proportion is also commonly expressed as some sort of fraction or ratio.

The only example I can think of is the FiO2/Percent O2 in the oxygen archetype. I would keep that as a Proportion and if we were doing Pulse oximetry or even lung function now , use DV_QUANTITY? I don’t think we should change these now but in terms of future guidance, really largely use DV_QUANTITY unless there is a good reason otherwise.

Hi all

I would dare to say - and mind the boldness - that the units say it all :slightly_smiling_face: % is a proportion
In the SpO2 case, defining the result as a quantity is an understatement.
I mean, you can do it to solve a template level problem that the ckm doesn’t accommodate for.
But we should never forget the semantics, and the data needs of the future to come. What we are estimating is the percentage of oxyhemoglobin in arterial blood.
To use it otherwise - to solve practical needs in forms, scales, etc - should never compromise the need to express the semantics correctly. Or
We did it for BP, etc - so why not for SpO2?
Clinical modeling will never rely easily on rules of thumb. My question would be: how can we model to accommodate for future semantics and RM detail?