I don't think that is necessary, UCUM is a very small service, which can also be in software as a library or small external service in microservice architecture.
Ia gree with Diago.
UCUM basicly is a terminological system.
GF
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
maybe something like this
ELEMENT[at0004] occurrences matches {0..1} matches { – One element
value existence matches {0..1} matches {
DV_QUANTITY occurrences matches {0..1} matches { – DV_QUANTITY
units existence matches {1..1} matches {
[ac0001]
}
}
}
}
…
constraint_binding = <
[“UCUM”] = <
items = <
[“ac0001”] = <[UCUM::mass]>
‘mass’ or whatever way of identifying the valid unit set
that’s not a bad idea, but that requires a change to the reference model, since DV_QUANTITY.units is currently a String.
I sometimes wonder if we need to allow for some sort of automatic conversions in cases like this, i.e. where the ‘code’ is self-defining - as we already accept via the notion of openEHR code-sets, e.g. country codes and so on - units are like this, rather than being like SNOMED or LOINC codes.
Perhaps we define it to be legal to enable a String field can be mapped to a code-set, more or less in the way that Diego does here?
- thomas
Bert
yes I agree with this. We should do something about it.
- thomas
I am glad you think so too. Thanks to Silje for bringing it u initially. I think, there is already much possible with only few changes, the ideas expressed by Diego help a lot. On the archetype side we need to define the UCUM-property for constraint, and units mandatory. On the dataset-side only the value and the unit name is necessary. The dataset-validating software must then check against the UCUM-definitions if the used unit and value can be used in the context of the property. This would be a great improvement because worldwide, every DvQuantity value could be calculated to its appropriate value. Fahrenheit and miles for some countries, and Celcius and Kilometer for some other countries, and of course many other local used units. The best way to achieve it, in my opinion, (but I am sure I don’t see the whole picture), would be to make units in DvQuantity of type STRING OR by term-binding. We already know alternative datatypes, which are sometimes used in ELEMENT/value. So the use would then be to have to alternative values for the ELEMENT, one for the string-type DvQuantity, one for the coded type, so there would never be a problem with interpreting. In this way it would remain backwards compatible and also allow to support units to be checked against a (any) terminology. It is also that, besides UCUM, SNOMED also defines units, and there can be data, maybe from legacy systems, which use SNOMED-terms for a unit (maybe there are also translated units, if so, SNOMED takes care for that, and I also found on google there is a mapping between SNOMED and UCUM coming up or already finished). And the only thing needed to change in the RM would be an addition for the DvQuantity-unit-type, without losing backwards compatibility. I wouldn’t have come tot his idea without the discussion this morning, and I am sure there is more to it then I see. But this kind of solution, I think is the best I can think of. Bert
Semantic Interoperability is possible only when each. distinct domain:
has its own model
has its own rules
and always orthogonal to other models.
A terminology can be equated to a Dictionary.
A terminology is never an Encyclopedia of everything.
We need a terminology of concepts related to the Patient System.
And we need a terminology for things not related, such as Units of Measurement.
There will be more terminologies we need: basic archetype patterns for documentation, time-related concepts, medical devices, continuity of care, business modelling, etc.
So I agree with Thomas.
SNOMED must have bounderies.
I fear that the SNOMED world is without a well defined scope.
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
But OpenEhr is a registering system, so if archetypes will be written to define datasets which use a SNOMED-term, then OpenEhr supports that, because OpenEhr supports archetypes.
You cannot negate termbindings on AOM/ADL-level in expressing (for example), we do not accept SNOMED (only UCUM) at this point, it is the archetype-designer who decides that. I think that is one of the best features of OpenEhr, the semantic standards are by the user to define. OpenEhr facilitates. There is the success factor of OpenEhr.
The solution Diego described yesterday works perfect for many point of views and fits in the OpenEhr paradigms.
If one wants an UCUM term in the DvQuantity and another wants a SNOMED term, it is both legal and possible.
What is preferable, that is not to us to decide while thinking about OpenEhr.
Best regards
Bert
Bert,
I don’t disagree philosophically, but practically speaking, no SNOMED service is going to be able to answer requests to do with unit properties, unit conversions, or different forms of rendering, which are all things we need to take care of properly.
I actually think units is one of the things we should just do properly, and in only one way for openEHR. I can’t imagine why anyone would use SNOMED for units instead of a proper units service that supported the above, even if they use SNOMED for everything else. There is of course nothing preventing anyone adding bindings from SNOMED to the units paths in archetypes.
- thomas
But having said this....
Until now, in practice, people use the OpenEhr terminology for units because that is what the tooling offers. This is not enforced by the RM, but it is common practice.
Now UCUM emerge, and then it is also good to accept termbindings for defining the property to restrict the units which may be used in the DvQuantity.
But does this mean that it is not anymore allowed to use another terminology to define a property, that UCUM would be part of the RM, does this mean that OpenEhr will be inseparable connected to UCUM?
I don't think that is wise. It breaks with the standard philosophy of OpenEhr to offer as much freedom as is possible to the archetype designer.
SNOMED offers also higher hierarchy concepts for properties, for example, 118538004: Mass
Bert
I personally think that UCUM does a outstanding good job. One thing that is missing is translations, this is important in countries which have another script, like Arabs or Chinese or many many other. The majority of the world population does not use the Latin alphabet.
And this is where SNOMED comes in, it is getting translated by the people who use it. And I found somewhere on the internet a mapping from UCUM to SNOMED, and when I looked again, I coudn't find it anymore. SNOMED has infrastructure to take care of translations (done by the national standard bodies). That is one of its important strengths. HL7 is quite America bounded, and UCUM is (as far as I know) a typical HL7 product, from this point of view.
Please correct me if I am wrong.
Most people of the world cannot read/write English and they also need to use medical software/devices, and it is a good thing that translations are delivered by an authority like a national standard body, instead of vendors more or less educated
I think that is obvious that the mapping between SNOMED and UCUM will come if it isn't there yet. So restricting the termbindings regarding DvQuantity-property to UCUM may become a problem, although, promoting the use is not wrong, like tooling promoted also the use of the OpenEhr units-terminology
But it may be alright to define in the RM that the DvQuantity-property is like the UCUM-property, but then without mentioning the word UCUM 
And of course, that the unit-string must be restricted by the general higher hierarchy of the property domain (like Mass, energy, etc)
Bert
Hi All
The ‘property’ editor is available with the archetype editor. Has anyone had a look at adding the required type and then the whatever bit can be in all the tools.
Cheers, Sam
Sam, for me the point was not having an OpenEhr property but an UCUM property which has also conversion routines for units within that property boundary available, so that it does not matter if the dataset contains Fahrenheit or Celsius when property “temperature” was constrained, because UCUM can tell the data validating/interpretating software how to understand the value and how to convert to another unit if desired.
This needs a redesign of the DvQuantity, see the example Diego described a few days ago.
Best regards
Bert
So, to explain Diego’s proposal.
Now the units field in DvQuantity in an archetype is of type string. This enforces everyone using that archetype to use that specific unit, while, maybe, in a country or situation that is not convenient.
Diego proposes to replace the string by a UCUM termbinding, for example UCUM::mass, so every unit-string inside this boundary can be used, and the reader of the dataset can ask for another unit, if desired, because UCUM knows how to convert from one to another unit inside the same boundary.
So it is only a small redesign which is needed, and backwards compatibility may be important.
I don’t know if Diego’s proposal is feasible and I hope to hear from others what they think.
Bert
Hi Silje,
When specifying the property but not the units, any units are allowed. This is saying “any units” which is similar to “arbitrary units”. We can relax the spec to allow non-ucum as units (my interpretation of “any units” is any in ucum and compliant with the specified property, while “arbitrary” might be in or not in ucum, and compliant with the property).
What do you think?
Maybe we can analyze the need/implications of changing the string tour of units for a coded text in the SEC?
Hi,
«Any units» isn’t the same as “arbitrary units”. As I wrote below, “arbitrary units” in the context of biomedicine are units which are defined by biological activity, such as level of allergic reaction or enzymatic activity. This is done to be able to compare the concentration of different substances which have the same effects in different mass or volume amounts – birch pollen extract vs grass pollen extract (measured in SQ-U; standardized quality units), retinol vs betacarotene (measured in RE, retinol equivalents), human insulin vs insulin analogues (measured in IU, international units).
To be able to specify medication strength in a meaningful way, I need a numerator (amount active substance) and a denominator (amount helper substance). The numerator can be a mass (such as mg), a volume (such as ml) or an arbitrary unit (such as IU). The denominator can be a volume, a mass or an administration unit (such as tablet or puff). Since there can be approximately a million different variations on mass, volume and arbitrary units, I don’t want to specify them all in the archetype, but leave it up to the application, while still specifying the property (mass, volume or arbitrary). At the moment, I can’t do this for the arbitrary units element, since there’s no property in the openEHR units properties terminology set for arbitrary units.
However, I’m starting to wonder if “” really is a misnamed “arbitrary units” property. Anyone know the origin of this? IU isn’t a mass unit, so it’s misnamed in any case (see https://en.wikipedia.org/wiki/International_unit).
Also, what would be really really neat, is a Quantity data type which could be any of a couple of a set of preselected properties (such as for instance mass, volume and arbitrary), and not just one fixed property. :o)
Regards,
Silje
Hi Pablo,
It seems to me that it is better to keep it a String - which is what UCUM units are - and to consider adding a property field. Another idea is to change it to a CODE_PHRASE, with terminology_id = UCUM, but I’m not sure that buys us anything really, if we keep using UCUM, which I think we should. That is what we currently do in the RM for fields like language and country.
- thomas
Hi Silje,