Quantities of arbitrary units in openEHR

Yes, I understand the decision, but IO regard it as a quick decision which can cause problems on the longer term.

For the record, I object against this decision for the last time. (or else it will get boring ) :wink:

UCUM does not have an infrastructure for translations, so translations will be done "in the wild", this may be good or may be bad.

SNOMED has an infrastructure for professional translations, SNOMED also supports units and hierarchies, like UCUM-properties.

It is of course a matter of taste, and what a customer wants. But I think, OpenEHR should offer a customer optional facilities for professional translations of the units. Pinning the DvQuantity to UCUM in the RM makes it impossible for the customer to chose for a professional translation on archetype-level.

There is another disadvantage of this unnecessary inseparability of the RM and UCUM, it is against the OpenEHR philosophy to offer as much freedom in modeling as possible.

So take your decisions wisely :wink:

Best regards

Bert

Hi Pablo,

This is our current modelling, for reference (the administration unit denominator isn’t modelled):

I don’t see how either ordinals or proportions, the way they currently work, can be of any help here.

Regards,
Silje

Hi Silje,

My thinking is for your use case, DV_QUANTITY doesn’t apply for arbitrary, since those seem not related with physical properties (mass, length, area, concentration, etc.)

As I said, “level of X” makes me think of DV_ORDINAL.

DV_PROPORTION would be used for numerator / denominator modeling, but currently doesn’t support units so it’s real / real. My suggestion was to analyze the change from that to an arbitrary type for each numerator and denominator, so you can model DV_QUANTITY / DV_QUANTITY proportions.

Also DV_ORDINAL doesn’t have a unit but has a DV_CODED_TEXT, maybe your arbitrary units are really terms from a given terminology, so this might be good to model that.

But as I said, for this specific use case you might need to use many data points (ELEMENTS) of different types, inside a CLUSTER to be able to comply with all your requirements (please check my previous message where I outlined your requirements as I understood them).

Hope that helps.

(attachments)

image001.png

or even DV_COUNT.

I have asked some questions of knowledgeable ontology sources; will post any replies I get here.

- thomas

But you can’t specify terms in DV_COUNT while DV_ORDINAL.symbol can be used to specify the arbitrary units but not as physical property units of measure, but as a terminology concept / term.