Representing a Real value in openEHR

Clinical (archive)
1

Hello,

It might seem a very basic question, but I couldn’t find an appropriate answer anywhere. Which is the best way to model a single Real number in openEHR? For example, a result of a score.

I have found two possible options:

In both cases, it seems we are forcing to use a data type that does not really fit for purpose. Why don’t we have something similar as the DV_COUNT, but representing a real number and not an integer? Something equivalent to the REAL data type in ISO 21090

David

2

Hi David,

Qualified Real is the current preferred option (for me anyway). I think we have flagged up in the spec CRs that proper support for Real would be helpful as Qualified real is somewhat obscure.

So - agree with your request.

Ian

3

Hi David,

until we discovered that a few scores use non Integral values, there was no need for a 'real' type with no units. There is a CR to enable DV_ORDINAL to have real values. Until then, I would suggest using the DV_QUANTITY approach, that's the most frequently used one in the past. Other than these scores, I have never heard of a real value that doesn't have units in medicine. Does anyone know of any? If there is one, we would need a new data type as well, but it still wouldn't be the one to use for scores.

- thomas

4

Well, as the openEHR data types specification document says, think of an archetype representing some statistical values such a covariance.

It is clear that the DV_QUANTITY is the most appropriate solution right now, but does not seem safe to rely on setting an empty unit to represent just a Real number

5

Qualified Real is a property from the domain type, not the type
itself, I thought the idea was to get rid of domain types in the
future.

6

yes, I agree. Release 1.0.3 is coming soon :wink: - thomas

7

Hi,
what about the unit 1 (uno) for dimensionless quantities?
http://goldbook.iupac.org/D01742.html

/Daniel

8

is interesting - what they consider to be the dimensionless quantities. - thomas

9

So it would be stored as {1}? (as they are supposed to be UCUM). Empty
units doesn't feel like valid UCUM units either.

10

That’s true Daniel, to be completely compliant with UCUM it seems the unit should be defined as 1 and not as an empty string.

http://unitsofmeasure.org/ucum.html#section-Examples-for-some-Non-Units.

11

True, UCUM is an obscure standard :smiley:

12

I'm not an UCUM expert, but that's what I believe it should be. Anything
with curlies seems to be equivalent to 1, so {1}=1.

There is some more information under §29:
http://unitsofmeasure.org/ucum.html#section-Derived-Unit-Atoms
and there is a UCUM tracker issue:
http://unitsofmeasure.org/trac/ticket/2

/Daniel