Quantities of arbitrary units in openEHR

Technical (archive)
1

Hi all,

I’m working on representing medication strengths in archetypes at the moment. Most medications are thankfully measured in SI units such as mg/ml or mg/{dose unit}, but others use arbitrary units that are not derived from any other physical dimensional units. Examples of these are standardized quality units (SQ-U), focus forming units (FFU), European and American pharmacopoeia units, anti factor Xa units, or international units (IU). There are seemingly an unlimited number of these units, and they apparently make up new ones as they go along (ref: SQ-T and SQ-HDM). See http://unitsofmeasure.org/ucum.html#para-45 for more.

UCUM has a generic way of representing these, as “[arb’u]{whatever}” (arbitrary unit, name of the unit), but openEHR doesn’t seem to have a property in its Quantity data type for them. Could it be a possibility to add an “Arbitrary” property to the openEHR support terminology for unit properties?

Also, is it ok to model Quantity elements with a property set but the units left unconstrained? I’ve just started trying to add these units to an archetype (as a concentration, so got around the property issue), and it’s just a never ending task.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web: http://arketyper.no / Twitter: @arketyper_no

2

It would be good if OpenEhr RM would support the UCUM-properties fully in the DvQuantity, then all problems regarding units would be over for the next 20 years, and no maintenance on customer or OpenEHR-foundation side is needed. UCUM is, I think, widely regarded as the most important unit-registration system.

I haven't thought about which changes are needed to do this, sorry for that, but I am sure the community is very well able to handle this.

By the way, if someone needs a UCUM-library for Golang, I have written one in open source, find it here:
https://github.com/BertVerhees/ucum
Grahame Grieve and some FHIRT enthousiasts have written one for Java:
https://github.com/FHIR/Ucum-java

Best regards
Bert

3

Hi Silje,

I don’t understand how adding an ‘Arbitrary’ term to the openEHR terminology helps things. DV_QUANTITY.units is a UCUM String field. Won’t the strange units just turn up in the String form you quoted for UCUM arbitrary units in that field?

(BTW, to ask for a new terminology term, just create a new issue on the PR tracker with component=New Term Request - choose this from the dropdown).

Setting property and not units makes sense - and if we had a proper, standardised units service, a runtime archetype evaluator would use it to limit the actual units for property = pressure (say) to only pressure units. I think we need to define such a service properly…

  • thomas
4

Hi Silje,

I think this may ‘just’ be a modelling tooling issue, openEHR itself supports this ok.

Speaking for CKM, if you upload an archetype with this to CKM, it should validate the UCUM unit correctly for [arb’U]{whatever}.

However, [arb‘u]{whatever} or similar is (very slightly) incorrect in my understanding:

5

As far as I know, Sebastian, OpenEhr does not use UCUM but it uses many unit-strings which also are defined in UCUM, but has these strings for OpenEhr-use listed in an own terminology-list. This list needs to be maintained separately by the OpenEHR community. There is no validation defined directly to the UCUM-services. If it would, not only use the stringified units of UCUM, but also would incorporate UCUM-defined functionality, it would also have, for example, conversion routines from UCUM, which are usable for software defined in the UCUM essence-file. There could be some RM redesign, as Thomas also hinted (on this subject today) by using the UCUM-ordering of unit-strings to properties like “pressure”, “energy”, etc and define DvQuantity so that archetypes could constrain these properties instead of constraining the stringified units. Best regards Bert Verhees

6

it certainly . If there are tools and implementations that don’t respect this, they are non-compliant and will get found out :wink: The unit strings in the terminology are to help archetype tooling, but I would say that all tools and systems in the future should be using a ‘UCUM service’ that does not yet exist, but knows about all unit strings, properties and so on. This is something we could easily specify and implement, if there is not already one in existence. right, that’s the sort of thing we need. I have not researched this for a few years, so if anyone knows of a service and/or service definition / API we can use and standardise on, please post some information. - thomas

7

I wrote a UCUM-service for Golang in a two weeks, and had some debugging afterwards, I needed it for a project. But I was lucky, the hard thinking had already been done by some FHIR developers. I had the URL’s in my reply to this subject this morning. A UCUM-service is quite simple, it has a simple API. You can extract it from this testfile which you find here: Bert

8

I must add a few small remarks, this github-repository is not a service (as I on one place indicated), but it is a library, so that is why the API is not visible in a simple way, and that is why I point to this testfile to learn about the API.

The API, as said, is simple, it consist in about 10 or 15 API-calls. Refactoring the library to a service is (in Golang) also very simple, just put one file before it with service-calls ( in REST-calls, or if used as microservice maybe gRPC calls are possible (which are much faster)) and then use the library to feed the service.

https://www.slideshare.net/borisovalex/grpc-vs-rest-let-the-battle-begin-81800634

9

Hi all, thanks for your replies!

I’m sure the CKM would accept the unit string, but which property would the Quantity have? Eg property = <[openehr::124]> for weight or property = <[openehr::127]> for temperature? I don’t think we have one of those codes for “Arbitrary”?

I’m sure you’re correct about the syntax, btw. J

10

A bit unrelated perhaps, but in the 1.0.3 and 1.0.4 RM specification, there is no property attribute or function present in dv_quantity, even though the text says it can be conveniently constrained. There is a reference to the spec-95 jira issue, which says it has been removed. So there’s no way to constrain it - unless the specification contains a mistake :slight_smile:

It is present in the BMM variants of the RM though, as a mandatory field.

Regards,

Pieter Bos

11

Hi Silje,

I think this may 'just' be a modelling tooling issue, openEHR itself supports this ok.

Speaking for CKM, if you upload an archetype with this to CKM, it should validate the UCUM unit correctly for [arb'U]{whatever}.
However, [arb'u]{whatever} or similar is (very slightly) incorrect in my understanding:

  1. Use the completely vertical ' not ' or similar (at least that is my understanding).
  2. openEHR uses (implicitly I think, but it may be hidden somewhere in the spec), the case-sensitive version of UCUM - therefore the U needs to be upper case, see e.g. http://unitsofmeasure.org/ucum.html#para-45

As far as I know, Sebastian, OpenEhr does not use UCUM

it certainly specifies it<https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_quantity_class&gt;\. If there are tools and implementations that don't respect this, they are non-compliant and will get found out :wink:

[SG] The first reference https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_quantity_class is more an "inspiration": "Units were inspired by the Unified Code for Units of Measure (UCUM)<http://unitsofmeasure.org/ucum.html&gt;, developed by Gunther Schadow and Clement J. McDonald of The Regenstrief Institute."
The 2nd reference is clearer: "Stringified units, expressed in UCUM unit syntax, e.g. "kg/m2", "mm[Hg]", "ms-1", "km/h"."
This is where I think that not only it is stated that openEHR uses UCUM (and not some part or "inspiration" of it), but also implies that the case sensitive version of it is used (which in my view is important to know at least for some of the units). I still think it would be good to explicitly say that the case-sensitive version is used?

The unit strings in the terminology are to help archetype tooling, but I would say that all tools and systems in the future should be using a 'UCUM service' that does not yet exist, but knows about all unit strings, properties and so on. This is something we could easily specify and implement, if there is not already one in existence.
[SG] Agree - such a UCUM service may also be able to give a print version, e.g. °C instead of CEL or °F instead of [degF]
Sebastian

The unit strings in the terminology are to help archetype tooling, but I would say that all tools and systems in the future should be using a 'UCUM service' that does not yet exist, but knows about all unit strings, properties and so on. This is something we could easily specify and implement, if there is not already one in existence.

but it uses many unit-strings which also are defined in UCUM, but has these strings for OpenEhr-use listed in an own terminology-list. This list needs to be maintained separately by the OpenEHR community. There is no validation defined directly to the UCUM-services. If it would, not only use the stringified units of UCUM, but also would incorporate UCUM-defined functionality, it would also have, for example, conversion routines from UCUM, which are usable for software defined in the UCUM essence-file.

right, that's the sort of thing we need. I have not researched this for a few years, so if anyone knows of a service and/or service definition / API we can use and standardise on, please post some information.

- thomas

12

Ah I was being dense, I thought you were talking about the units field, not the property field. In that case, what would it mean if property were set to ‘Arbitrary’ - does that mean the units has to be from the current list of arbitrary units, which is not-length, not-pressure, not-everything else? If that’s the intended effect then … maybe we add a new term. But the existing property terms are well defined, and in some sense exhaustive (at the physics level). It is clear what ‘mass’ means for example; what does ‘arbitrary’ mean? Probably it would need to be at least ‘arbitrary property’?

anyway, I think this is now a terminology discussion… :slight_smile:

  • thomas
13

Right - at the moment, it is a 'fake' field in archetypes, enabled by being in the BMM or other expression of the RM. It's convenient to do this occasionally, since we don't think 'property' needs to be a field of DV_QUANTITY - but maybe it should be, since for some of the more esoteric units, it's not that clear what is being measured.

This trick is also not mentioned in the ADL/AOM specs, and it either should be, or we just don't allow it. I don't have a strong opinion either way.

- thomas

14

We should fix this documentation - can you create a PR for this?

thanks

  • thomas
15

While I agree with the SPEC-95 rationale (once you have a unit, you should be able to know what its property is), it is still convenient to have the property for constraining.
Otherwise you don't have a way to say in an archetype: I don't care about the exact unit here, but please let it be a "Mass".

16

I think there are several potential problems with this, and IMHO we are stepping too much on what should be done in a terminology service (We are literally talking about a ‘public available UCUM service’). You can also ask the terminology service what kind of unit code you have. Your implementation could answer “arbitrary” for these new units.

In my opinion, saying “here comes a mass unit code” is not much different from “here comes a diagnosis code”, and we say these in a completely different way (a better way, if you ask me).

Also, I’m not a big fan of “arbitrary” property, as feels like a “other” kind of terminology code that is potentially dangerous as knowledge or terminology advances, thus coexisting ‘arbitrary’ and ‘new shiny type of measurements’ all mixed up. That’s why I also expect these properties to be as derived from the codes and not the other way around.

17

The thing I am not a fan of is that units themselves become part of terminology. This is a SNOMED direction but I think a wrong one. The reason is that the ontology of units isn’t the same as the ontology of findings, medications and so on. In fact they all have different ontologies, and trying to jam them all into SNOMED CT under a single meta- model is problematic at best.

But units are so clearly different that they deserve their own service - for a start, UCUM unit strings are post-coorindatable according to the UCUM grammar, and then you have the classification of units under properties, synthetic properties under basic properties, strange stuff currently called ‘arbitrary’ (which is still real, and must have a place inside the ontology); units conversion rules and algorithms and so on.

So while a mass unit code like ‘kg’ might not see much different for a code for pneumonia, even this simple example is already a pre-coordination of ‘k’ and ‘g’ according to a units ontology, something that clearly doesn’t apply to ‘pneumonia’, at least not in the same way (i.e. ‘viral pneumonia’ is a particular that is described by a disease ontology).

Thinking a bit more about ‘arbitrary’, I think I agree with Diego - to sort it out properly needs a proper ontology.

  • thomas
18

Deriving the properties from the codes makes sense when you actually specify the codes, but what do you do when you want to specify “this is a concentration, but I don’t care about the exact units”?

“Arbitrary unit” has a quite specific meaning, it’s not just a catch-all for “new units for which we haven’t got the property defined in the terminology yet”: https://en.wikipedia.org/wiki/Arbitrary_unit

I see that IUPAC and IFCC has decided to use the term “procedure defined unit” instead of “arbitrary unit”.

Also, does leaving the “property” field out mean that we can have one Quantity element with the units Cel, m, kg, ml and [arb’U]?

Regards,

Silje

19

In my mind, this should be done not by fixing a property but by defining a constraint reference pointing to the service/set of codes that can provide you with all mass units

20

This sounds good in theory, but I don’t think it’ll help me with my modelling in the next couple of weeks? J

Regards,

Silje