Sorry for delay, PR is now merged, the change is not in ‘latest’ and will be part of upcoming Release 3.1.0.
1 Like
<concept id="380" rubric="Qualified real"/>
My current translation (zh) of the rubric “Qualified real” is “带有量词限定的实数” (which means a real number with a qualifier for counting)? Is this understanding correct?
BTW, I forked the openEHR specifications-TERM repo for translating the XML file.
<concept id="375" rubric="Resistance"/>
This rubric is a bit ambiguous. “Electric resistance”?
<concept id="267" rubric="mode"/>
An ambiguous rubric. It means “the value that appears most frequently in a series of numbers”?
If example units available, it would be easier to clarify the meaning.
<concept id="758" rubric="Spectral power density"/>
I can’t find exactly the same term above but the following one:
"Power spectral density" = "功率谱密度"
Should these issues be proposed to the github repo?
It’s a good question. I’ve always understood ‘Qualified real’ to be a “trick” to be able to fit a unitless number into the DV_QUANTITY data type, but others who’ve been around for longer probably have more info about this. @thomas.beale ?
Agree, “Electrical resistance” is better!
This is from <group openehr_id="event_math_function" name="event math function">:
<group openehr_id="event_math_function" name="event math function">
<concept id="145" rubric="minimum"/>
<concept id="144" rubric="maximum"/>
<concept id="267" rubric="mode"/>
<concept id="268" rubric="median"/>
<concept id="146" rubric="mean"/>
<concept id="147" rubric="change"/>
<concept id="148" rubric="total"/>
<concept id="149" rubric="variation"/>
<concept id="521" rubric="decrease"/>
<concept id="522" rubric="increase"/>
<concept id="640" rubric="actual"/>
</group>
In the context of the other related values, my assumption is that this is the statistical mode:
The mode refers to the most frequently occurring number found in a group of numbers.
( Mode - StatPearls - NCBI Bookshelf (nih.gov))
Yes, the units for all the different unit properties are in PropertyUnitData.xml.
You’re right, it should be “Power spectral density”.
That would be great! 
That is my understanding, it signifies a unitless number, but I had thought that “1” was a valid UCUM unit, not an openEHR thing. Having said that I can’t find any notes on this this in UCUM documentation.
2 Likes
‘1’ is a valid UCUM unit. Meaningless, but valid 
2 Likes
It’s called “unity”, if i remember correctly.
Thanks, Selje and Ian. Your clarifications are very useful.
Chinese translation (zh) of the openehr_terminology.xml (Release-3.0.0) is completed.
1 Like
<Unit property_id="0" Text="cm" name="centimeter" conversion="1" coefficient="-2" primary="false" UCUM="cm"/>
How to translate this file, including the property name and especially the Unit name? I mean the official way.
As part of an ongoing project at Region Östergötland ( Cardiology templates and archetypes - #14 by davwet ) we are creating a new archetype for echocardiography including measurements set by clinicians. These include some values divided by body surface area (BSA) which are given the unit mm/(m^2), but this unit does not exist in Archetype Designer right now. Is it possible to get some help with adding this unit, or perhaps an option for {LENGTH/AREA}?
The easiest way to get a new unit added is to make the change and create a pull request for this file: specifications-TERM/computable/XML/PropertyUnitData.xml at master · openEHR/specifications-TERM
For your specific unit, UCUM mm/m2 and a new property “Length per area” would probably work, and it may be a good idea to also add the more generic {LENGTH/AREA} as you suggested.
2 Likes
Quickly dropping in to share a use case around adding non-standard units to DV_QUANTITY.
I’m working on medication templates where many dosage units are proprietary and non-SI, e.g. tube, sachet, tablet, or even piece. These are the units patients actually understand: “Apply one tube of cream X each morning” or “Dissolve one tablet in water before meals”
Obviously, these units are highly variable and non-standard (the size of a “tube” can differ wildly between products) but they still carry much more meaning for patients than something like 500 mg, and thus the main administration and prescription units.
At the moment, I handle this in Archetype Designer by manually adding units to each relevant DV_QUANTITY element in the t.json file, e.g.:
...
}, {
"@type" : "C_PRIMITIVE_TUPLE",
"members" : [ {
"@type" : "C_STRING",
"rmTypeName" : "STRING",
"constraint" : [ "Tube" ]
}, {
"@type" : "C_REAL",
"rmTypeName" : "REAL",
"constraint" : [ {
"lowerIncluded" : false,
"upperIncluded" : false,
"upperUnbounded" : true,
"lowerUnbounded" : true
} ]
}, {
"@type" : "C_STRING",
"rmTypeName" : "STRING",
"constraint" : [ "KISIM" ]
}, {
"@type" : "C_STRING",
"rmTypeName" : "STRING",
"constraint" : [ "Tube" ]
} ]
}, {
...
When the file is imported back into AD, these extra units are preserved and not overwritten, which is good.
It works, but is cumbersome and error-prone, especially with multiple dosage fields per template that should have the same units. Maintaining consistency quickly becomes difficult.
I don’t think asking for these units to be added to PropertyUnitData.xml really makes sense, given how context-specific they are, but I wanted to share the approach anyway. Maybe it’s useful for others dealing with similar topics, or as a starting point for a more elegant solution.
I would question the need to structure this kind of dosing to this level. If you need to represent the patient instruction including dosage, maybe “Dose description” would be sufficient? Otherwise, the “Alternate dose” is intended to be used for dosage representations like number of tablets, but then we’re back to your solution of hacking the template file.
Quick reply for now The quantity datatype does support non ucum terminology exactly for this purpose. In uk we would use snomed for these kinds of ‘unit’.
3 Likes
We want to be pretty careful here. The concept of Quantity is a ‘hard’ physics one, and is intended to make data computable.
Things like ‘sachet’ etc are pre-manufactured doses, and are proxies for real amounts. E.g. you could put ‘1 sachet’ of ‘Lemsip’ (a non-hospital flu product available in the UK, just using it for fun…), but you’ll never know that the patient who receives a sachet is consuming 1000mg of paracetomol. Now apply this to drugs of more serious interest like chemo / immunotherapy…
Doing this kind of data properly should be done via something like the following representation
- drug admin (CLUSTER)
- form = powder
- delivery unit = adult single sachet manufacturer/type xyz
- medication =
- paracetomol
- amount: DV_QUANTITY = 1000mg (ideally derived from some knowledge base that knows what this particular sachet xyz actually has in it)
- diphenhydramine
- amount: …
- etc
- paracetomol
That phrase ‘delivery unit’ (or it could be ‘product unit’) is not the same kind of ‘unit’ as a scientific unit of measure, at all. It should be in a different field.
I’m skipping over various details, but you know them all. The key however is to think very carefully before making a lot of data just uncomputable…
BTW the real way to do all this properly is with a ref to a drug / preparation database, and a thumbnail copy of the information found there (guaranteeing that the 1000mg / sachet / other details are in the EHR for all time, even if the knowledge base goes away).
1 Like
Disclaimer: The following discussion veers away from the original topic of Archetype Designer and goes deep into clinical modelling…
Hi Thomas,
thanks for your input. Your concern is reasonable, and we have been grappling with how to properly represent these differences between medication products, their delivered units, and amounts of individual compounds.
TL;DR: Separating delivery dosage units from actual compound amounts in dedicated elements seems reasonable, but even those are currently alwaysDV_QUANTITY, which - in current practice - does not seem to be strictly limited to computable SI units.
Your proposed representation sounds good, but from my understanding does not align with the currently published archetypes for this field. Thus, we have found no better option for now than our current approach of storing the ordered and/or administered amount in “Dose” of CLUSTER.dosage.v2 nested within the “Structured dose and timing directions” SLOT of INSTRUCTION.medication_order.v3, or “Amount” SLOT of ACTION.medication.v1.
Although not ideal, we feel that we are within the proposed usage of CLUSTER.dosage.v2. In its concept description, the comment specifically mentions delivery units as accepted: “Comment: For example: ‘2 tablets at 6pm’ or ‘20 mg three times per day’.” The description of the “Dose” element only mentions SI units, with “Alternate dose” being more appropriate: “For example, can be used to represent a unit-dose based value such as ‘tabs’, when the Dose amount is expressed as an SI unit such as ‘mg’,“. I could be convinced to use “Dose” in CLUSTER.dosage.v2solely for computable SI-unit doses. This highlights a slightly different problem we encountered, how to store the information of which active ingredient within the ordered product the “Dose” refers to, especially for compound products (Co-Amoxicillin) or complex mixtures (Smofkabiven) - which we currently persist in “Dose description“. Furthermore, “Alternate dose” is also a DV_QUANTITY, so even using “Alternate dose” for “sachet” and “Dose” for “1000 mg" would require manually injecting the delivery units into the t.json.
Similar story with a different cluster CLUSTER.medication_supply_amount.v0, whose “Amount” and “Pack size” are DV_QUANTITY and explicitly refer to delivery units: “For example: ‘30’ as magnitude and ‘tablets’ as unit; or ‘100’ as magnitude and ‘ml’ as unit.”
We do in fact include, as you suggest, a reference to an external database via CLUSTER.knowledge_base_reference.v1 where medication compounds and amounts for the ordered product are stored, just without a copy of this information within the openEHR composition (yet). We are still considering adding this, potentially under the “Medication details” SLOT via CLUSTER.medication.v2. However, its description explicitly forbids (from my understanding) using this archetype for storing delivery units: “Misuse: Not to be used to record the intended or administered dose of a medication. Use either the INSTRUCTION.medication_order or the CLUSTER.dosage archetypes for this purpose.”.
Furthermore, we store a reference to an external unit conversion database that knows how much compound is in a product and can (to some degree) convert a “500 mg” order by a doctor into an administrable “tablet” for the nurse. However, due to the problems listed above, this conversion happens outside of openEHR at the moment.
