Is there a recommended way that we can add to the DV_QUANTITY units list so that it can be included in updates. Personally, I’ve hacked the ADL on multiple occasions but this is clearly not ideal and it isn’t there next time I or others need it…
Triggered by @JonJones question… Medication amounts and units - #4 by JonJones
The Gray is an SI unit, defined as the absorption of one joule of radiation energy per kilogram of matter. In the Archetype Designer settings (top R corner of the logged in AD screen) can be set to UCUM or to an openEHR list that includes SI units. In the UCUM list ‘J/kg’ is present, and if you switch to the openEHR list, then ‘Gy’ is present.
Similarly, Volt (V) is another SI unit, defined as Joules per Coulomb. While Volt appears in the openEHR list, ‘J/C’ appears not to be available.
While Gy and V are presented as SI units in this UCUM document with definition units - The Unified Code for Units of Measure - centiGray and kiloVolt are not. I’ve found references to 100 cGy = 1 Gy and descriptions of a centiGray as a ‘derived metric (SI) measurement unit’. Similarly 1 kV = 1000V.
The Ocean tool used to have a local file that could be edited. Is there an equivalent one for the AD tool?
There is a local file for Archetype Designer in the same way as in Archetype Editor. In fact it’s the same file. I’ve added cGy, mGy and kV to this file, as well as made some other minor adjustments and corrections. Could you update AD with this when convenient, @borut.fabjan ?
Although for the future, it’s likely we’ll want to be able to construct UCUM units conbining the atom units with appropriate prefixes on the fly. In this case, the unit files would only contain a list of properties (length, mass, energy dose, etc), a list of atom units (m, kg, Gy, etc), and a list of prefixes (m, M, c, etc). This would be much more flexible, and wouldn’t require us to add new stuff to the units file anywhere near as often.
I like this future option, and thanks for the information on the property units. To work around this for now I’ve just removed the units constraint so any unit value is now allowed- lets the user specify cgy or gy but weakens the model slightly. It has limited exposure at the moment but pressing timescales. Would be interested to know where that file lives in AD directories- not seen that before!
Since a UCUM annotation (anything between curly braces) is dropped by a parser, almost all of these could be represented as a “qualified real/volume” concentration:
The exception is {copies}/ug which is a “qualified real/mass” concentration. We don’t have a unit setup for this in the currently used PropertyUnitData.xml, but I see no reason why we couldn’t add it.
If we need the units persisted with the {copies} etc annotations, we could add those also to the PropertyUnitData.xml.
Sure. In that case, I’d like to see {copies}, 1 {Log_copies} and 10*3{copies} added to the .XML file and we now have a use case for {Qualified Real/Mass}.
As the apparent custodial of the file, can you update it, please?
I can update the copy I have, but as far as I know there isn’t any centralised governance of this file. Is this something we can get going, @thomas.beale ?
Yes indeed - is the link you made below of a definitive copy, or do you want to make changes?
EDIT: also, I would have expected you want to retain the {copies} in those additions - the idea is for the parser to get rid of those, otherwise the remaining units text won’t be computable / comparable.
I’ve already made the changes I outlined, but I don’t know whether this is the definite file, because we don’t have a centralised governance of the file
I’m not sure what you mean here. These units are functionally equivalent to 1/ml, 1/ug, 1/ml and 10*3/ml, respectively. Any interpretation would need to be done by a human. This should be okay for most of them, but I’m struggling a bit with the {log_copies}/ml. Ideally we should have a machine readable symbol for a decimal logarithmic (and natural logarithmic) scale in UCUM, but I can’t find one.
Otherwise you can get there via the Jira PRs project. Use ‘View all filters’ on the bottom left menu to get to a filter ‘TERM-PRs’, otherwise you will see everything.
Heather, I guess you see some (technological) obstacles in managing future evolution this PropertyUnit.xml file. We actually apply same principles as for all other openEHR specifications artefacts, so it is nothing special for this file.
