Hello,
After haveing read some of the topics here, I noticed that everytime there is a new unit not supported by AD, there seems to be CR to update the xml file that AD uses. This seems a long process and I don’t know where and how to start it.
I am in need to use an arbitrary unit mesured in “points” of any kind. The closest representation in UCUM would be this Finto: UCUM: point which is not present under AD. How can this this unit be included in AD?
Also, what are the implications to switch from the code systems “UCUM” and “openEHR/units” in AD in the design time for different archetypes?
The problem rised when using as a proxy “Category:Arbitrary” and “Unit:abitrary unit” shortened as “[arb’U]” and a parser crushing misunderstanding that apostrophe. Alternatively, the cody system openEHR/units has the same unit shortened as “arb. unit” which may serve as a workaround, but sitll not sure about the implications of changing the code system.
That’s an issue in openEHR, not only in the archetype designer. Recently I have expressed my concern on having our own copies of terminology subsets, because it requires us to manage them, which is exactly what you express here. I would prefer just to use what other organizations are managing and maintaining and avoid that task at all costs, specially because it requires duplicated effort on our side.
I know UCUM has it’s complexities, it’s not a list of codes, it’s a unit system, but we use subsets of it as lists of codes for simplicity, though I think we should be using the unit system itself, not just sublists of codes, via an integration that allows to search, combine and validate units, then enabling the use of the whole UCUM system in all modeling tools, not just in AD. Maybe in the long term that kind of integration is less work than doing the maintenance work ourselves.
That’s true @Pablo but it’s not the origin of the openEHR unit list - this was a list which was in the original Archetype Editor tool and was supposed to be wholly based on UCUM but had some issues and errors, in particular mixing up some text UCUM representations with the coded equivalents.
The current UCUM list is wholly based on UCUM and I would definitely suggest using that and not the older openEHR list though in most cases the codes will be identical.
The only downside is that some UCUM unit descriptors are not very human friendly e.g degC but our approach is to embed the human text at application level, and not try to constrain in archetypes or templates
Agree. I’ve written something about my vision for the future about this here, but I don’t know whether there’s any work being done to move in this direction.
The [pnt] (point) unit is not an arbitrary unit, but a length unit used in typography. If you need an arbitrary unit called “point”, you should probably represent that using something like “[arb’U]{point}”. The curly braces are disregarded by UCUM parsers, and is often used to annotate UCUM units. We have examples in the current PropertyUnitData.xml file of units represented in this way.
The process to get a unit into the file is a bit involved, but if you could post a link to some documentation about the unit(s) in question I can do it this time.
The problem with the parser misunderstanding the apostrophe should probably be fixed in the parser, alternatively by escaping the text?