Units, Quantities, etc

Technical (archive)
21

Dear all,

Are discrete units only encountered in administrative directives? Do
you prohibit people from making observations or measurements that
include discrete units such as puffs, tablets, patches, vials, strips etc?

There are examples of counting observables in both the laboratory and
clinical domains like "number of erythrocytes in urine", "number of
complement C3b receptors on thrombocytes", "number of petechiae of skin
per cm^2".

If for example assuming the SI system base quantities, the kind of
quantity is "number" with "N" as symbol and "1" or "one" as the unit.

Comparing to another commonly known kind of quantity, length, and the
unit "meter", "1.83 m" means 1.83 times the length of the Paris meter.
Further, my body height quantity inheres in my body and the unit "meter"
may be used to represent the length on a ratio scale, i.e. my body
height = 1.83 m or 1.83 times the Paris meter. However, this quantity
may be represented using other units such as the International foot.

Going back to tablets, in "2 tablets 500 mg paracetamol" the part
"tablets 500 mg paracetamol" is not just a point of reference for
representing the number quantity but part if of the quantity being
observed (or stated). This part cannot be exchanged and thus cannot be a
unit.

The DV_QUANTITY class has no attribute for specifying the kind of
quantity of which the magnitude field is a result of observation (or
decision). Previously, this has been managed within archetypes, e.g. the
systolic blood pressure quantity is referred to by binding the at0004
code to the term "Systolic" and through this node's context within the
archetype. In instances, there is no reference to any kind of quantity
apart from units, which do not fully describe the kind of quantity, and
any reference to the archetype on which the instance is based.

Thus, my 2-cent suggestion is to stay on the path, keep DV_QUANTITY
clean, and manage any issues around representation of doses in
archetypes.

Finally, there is the whole science of metrology backing this up. Please
refrain from giving this solid ground up.

Regards,
Daniel

22

Hi Daniel

No one is talking about abandoning what we have. The only question is about the way that the casual measurements of countable discrete things where the ucum unit is "1" are handled. I think that we're agreed that openEHR and, for that matter, HL7 v2 and v3 haven't go this right yet. In the openEHR context, the question is, how should this be done?

tablets 500 mg paracetamol" is not just a point of reference for
representing the number quantity but part if of the quantity being
observed (or stated).

I don't think this is true. Mostly, we look for codes for what is measured, and the codes don't include that part. So if you, as v3/CDA do, say that that is part of the thing that is measured, you are asking people to do an impossible feat of post-coordination.

Grahame

23

But the question around can you trust the data is, can you recognize properly when the units are ucum or not? For some reason I haven’t put my finger on, you are linking the knowing of this with the boundary of the type. It’s not clear to me why you’re making that link.

Grahame

24

well... good question. So in other words: if there is a units field specifically for 'formal' units, is it UCUM only or not? I would have said it should be except for annoying problems like the one Heath mentioned - UCUM uses '*' for exponent instead of '^' which almost everyone else uses....

We could use the same approach as an openEHR DV_PARSABLE, where the name of the syntax is stored as well, but this is IMO inviting a different kind of pain...

My answer would be: let's get UCUM doing everything we need (for the formal units field I mean, not the informal one); if we can't, we need a new UCUM.

- thomas

25

Hi All,

I think the units database that we have as part of openEHR tooling allows
for the addition of equivalent and language dependent expressions, as well
as conversion where that is possible.

How about we make that available somewhere to get this going. It does mean
we are not beholden to others and can know when we have UCUM compatible
expressions (convert if necessary).

Cheers, Sam

26

Hi Grahame,

Wed 2012-03-21 klockan 10:26 +0100 skrev Grahame Grieve:

Hi Daniel

No one is talking about abandoning what we have. The only question is about the way that the casual measurements of countable discrete things where the ucum unit is "1" are handled. I think that we're agreed that openEHR and, for that matter, HL7 v2 and v3 haven't go this right yet. In the openEHR context, the question is, how should this be done?

Why not just treat numbers (or counts) as any other quantity? There might be a case for providing a field for specifying the kind of quantity in the DV_QUANTITY class, but as in the example below, this is often includes more complex terminology-information model constructs than a single field.


> tablets 500 mg paracetamol" is not just a point of reference for
> representing the number quantity but part if of the quantity being
> observed (or stated).

I don't think this is true. Mostly, we look for codes for what is measured, and the codes don't include that part. So if you, as v3/CDA do, say that that is part of the thing that is measured, you are asking people to do an impossible feat of post-coordination.

Well, I still think it’s true! What’s in a code and what’s not is a matter of the terminology binding assumptions made in the specific situation. This kind of “post-coordination” (depending on what is meant by this term) is happening constantly with e.g. laboratory medicine where the kind of property observed is stated using a code from a terminology like LOINC or, even better, NPU ;). This code does however in most cases not specify the procedure to a sufficient degree so this information is added in the message thereby adding to the meaning of the code. The same is done for sample material and sample location. I would prefer this solution to overloading the unit with things that break the assumptions of metrology.

/Daniel