UCUM code in body temperature archetype

Technical (archive)
41

Grahame,

I think you are saying that you can implement the semantics of dose units with just a DvQantity / FHIR Quantity. If ‘dose units’ includes the knowledge of the discrete unit of delivery, i.e. table, drop etc, as well as total amount, you can’t. You need at least the elements here, or their equivalent.

class DoseQuantity
unitForm: DvCodedText // type of physical dose entity tablet, capsule, puff etc
unitAmount: DvQuantity // how much is in a doseForm unit e.g. 5mg
doseCount: Integer // how many items of doseForm to deliver

doseAmount: DvQuantity { // total amount of substance delivered to patient
Result := doseCount * unitAmount
}
end

If on the other hand you are saying we just go the pseudo-units route, where ‘tablet’ is a kind of unit, we can, but the Quantity library won’t work properly anymore, because you no longer know if you can add two quantities even if they have the same unit, because ‘tablet’ as a unit doesn’t mean anything. Where I am coming from is: Quantity is not just data, it is operations and computing; it includes operators like:

  • DV_AMOUNT: =, +, -, *, etc
  • DV_ABSOLUTE_QUANTITY: diff, add, subtract

(there are many ways to model this kind of thing, that’s just the openEHR way).

If you are saying: use a code + code-system approach, and check the code system, and do something if UCUM, and something else if not, I’ve now:

  • got just a data-oriented Quantity type
  • a bunch of if/else code to treat different Quantity ‘types’ differently
  • I have to move the operators out to another level, because they no longer make sense for this new style of Quantity

So, in terms of what we do in openEHR, I don’t think it makes sense. In terms of FHIR, it makes sense; but I have to check a FHIR Quantity and instantiate different kinds of RM structures depending on the units code system.

  • thomas
42

well, it’s a question of where you keep your complexity and uncertainty. Sure, you can exclude the uncertainty from the data type, and retain clear and simple operations associated with the type. But that doesn’t mean that uncertainty goes away. You’ve just pushed it somewhere else. I agree that the value proposition of putting in the data type is less clear for openEHR than it is for FHIR, but I don’t think you’ve accounted for the operational costs of where you propose to put the complexity. I argue that you should just eat the complexity into DV_QUANTITY because:

  • that’s where the real world users expect it to be
  • and so that’s where it goes in any other syntax you’ll ever encounter (well, at least FHIR and v2, and some CDA documents, but not all .e.g USA enforces valid UCUM, so I don’t know what happens to customary units)
  • it doesn’t change the operations, it just means that outcome of trying them might be undefined - but it might be already if the ucum units don’t have matching dimensions. So - least cost is to put it into the data type

Grahame

43

Thomas,

All are Units of a different kind.

SI defines: Units of Measure, and Units of Quantity in the scientific domain.

There are also Units of Time: minute, hour, etc.

When I think of tablets, capsule, etc. we will call these Units of Medicinal Product Dose.
Isn’t in UCUM this an example of Arbitrary Units?

3.2 | ### ARBITRARY UNITS |

  • | - |

§24 arbitrary units ■1 Arbitrary or procedure defined units are units whose meaning entirely depends on the measurement procedure (assay). These units have no general meaning in relation with any other unit in the SI. Therefore those arbitrary semantic entities are called arbitrary units, as opposed to proper units. The set of arbitrary units is denoted A, where A∩ U = {}. ■2 An arbitrary unit has no further definition in the semantic framework of The Unified Code for Units of Measure ■3 Arbitrary units are not “of any specific dimension” and are not “commensurable with” any other unit.

Until version 1.6 The Unified Code for Units of Measure has dealt with arbitrary units as dimensionless, but as an effect the semantics of The Unified Code for Units of Measure made all arbitrary units commensurable. Since version 1.7 of The Unified Code for Units of Measure it is no longer possible to convert or compare arbitrary units with any other arbitrary unit.

§25 operations on arbitrary units ■1 Any term involving arbitrary units, is itself an arbitrary unit and is not comparable with any other arbitrary unit or term.

§26 definition of arbitrary units ■1 Arbitrary units are marked in the definition tables for unit atoms by a bullet (‘•’) in the column titled “value” and a bullet in the column titled “definition”.

Gerard Freriks
+31 620347088
gfrer@luna.nl

44

Hi Gerard,

they actually could be, but whenever this discussion comes up, no-one proposes it. I’m not sure if I would either, because these arbitrary units are still not computable in general, but ‘dose units’ can be made computable but only with some extra data fields, i.e. you need both the quantity of dose in 1 tablet/capsule etc, and also number of tablet/capsule etc. So the structural model is different anyway.

I think the other problem with using UCUM arbitrary units is that people / orgs want to control the names of medicinal delivery products (‘tablet’ etc) in a terminology, which is reasonable, but doesn’t fit so well with UCUM.

  • thomas
45

Hi Thomas,

I appreciate that the Quantity classes add computability such as the +,-,=, diff operators etc but computability (or at least safe/sensible computability) is not a given even when the two operands share the same unit. Nor does the fact that a unit is non-scientific invalidate the use of those operators in many cases e.g 1 tab + 1 tab = 2 tabs. Of course there are situations where to do so would be unsafe and not sensible but that also applies to cases where SI units are being used.

In other words the safe and sensible use of the operators is always going to be constrained by the circumstances of use, of which the use of SI units or not, is only one factor that needs to be considered.

We need to solve the UCUM displayname/code issue anyway. We need to allow different code systems e.g. SNOMED CT, we need to support dose units/ pack units etc. Adding termcode and terminology solves that problem in a way which prevents avoids change, avoids introducing another flavour of quantity (more stuff for people to learn), and makes modelling of the key area of medication much cleaner.

I would be really keen to hear from other openEHR implementers on this. If operators are being heavily used and the suggested change would compromise computability or ease of implementation, I could be otherwise persuaded.

Ian

46

Two reactions:

1- There is a difference between the world of semantic interpretability in system interfaces and the real word of users looking at screens, and typing on keyboards
In one world we can/must use as much as possible SI units via UCUM and strife for as detailed as possible reducing misinterpretation.
In the real world users want to have data presented in many shapes and forms.
Accommodating the end-users is the task of the industry.
It is the task of health informaticians to reduce misinterpretations.

At the Template/Interface level we need facilities to annotate as much as possible that what is expressed/modelled.
And why not have in the annotations, the printable, the human readable, the personal choice, the local choice.

2- When it comes to the Arbitrary UCUM Units.
The question is how much semantic we carry in data types.
And how much semantics we carry in archetypes.
I opt for the latter.
Data types should be as primitive as possible.

I use the UCUM Arbitrary ‘Unit’ and use the structure in the Archetype to provide the semantics that describe the Unit.

Gerard Freriks
+31 620347088
gfrer@luna.nl

47

Hi Thomas,

In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for dose units because the latter are expressed as SNOMED terms, and are used in conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to compute actual doses/amounts where possible.

e.g.

318421004 | Atenolol 100mg tablets |

via dm+d allows us to infer that 1 tab (in this case) = 100mg

http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004&toc=nofloat |

  • |

and allows us to do maximum daily dose calculation, at least against a defined subset of such ‘dose units’.

in other cases the dose unit strength will be defined as part of the medication order - we have a ‘Strength’ element in the medication order archetype for just such a purpose.

I don’t think we need to be able to define the unit strength as part of the quantity datatype.

Ian

48

An alternative for dealing with semantic in archetypes is dealing with semantics in coding systems like SNOMED.

The consequence is that SNOMED must be a complete Medicinal Product Formulary.
I have doubts whether this is a good idea.

Many countries have different specific formularies.
I like to reserve SNOMED-CT to use as any dictionary with universal lemma’s, concepts.
Each country will have its own maintained Formulary.
A formulary that changes because of the marketing whims of pharmaceutical companies.

Gerard Freriks
+31 620347088
gfrer@luna.nl

49

In 2012 a number of ISO standards were published on the “Identification of medicinal products” When I recall correctly there is one that deals with the representation of dose forms, units of presentation and route of administration.

Jan Talmon

50

Hi Gerard,

"The consequence is that SNOMED must be a complete Medicinal Product Formulary.
I have doubts whether this is a good idea.’

dm+d is a UK health-service managed dictionary based on SNOMED CT and using the UK national namespace i.e. it is not managed internationally.
It is a complete Product formulary/dictionary but only for UK. I understand that Aus and New Zealand have very similar approaches.

Ian

51

Here in Spain there is an official terminology for medication dispensation. It is partially mapped to snomed (and the remaining ones will be part of snomed national extension)

In my opinion, it makes perfect sense to allow the specification of ‘units’ from other (non-ucum) terminologies, such as snomed or even the national ones

52

Hi Thomas,

I appreciate that the Quantity classes add computability such as the +,-,=, diff operators etc but computability (or at least safe/sensible computability) is not a given even when the two operands share the same unit.

it might not be clinically, but it always is in terms of quantities - that’s the whole point of the system of physical quantities. It’s not up to the DvQuantity (or any similar) type to know the clinical semantics at hand; the way it has to work is that a higher level clinical context in an application knows what Quantities are clinically comparable, when it does, it’s a guarantee that two DvQuantity instances of the same unit (say ‘g’) are addable, subtractable and can be multiplied by a scalar.

This is the point of having a simple Quantity type in the system - just to do this job.

Nor does the fact that a unit is non-scientific invalidate the use of those operators in many cases e.g 1 tab + 1 tab = 2 tabs. Of course there are situations where to do so would be unsafe and not sensible but that also applies to cases where SI units are being used.

in this case you simply can’t know, not even if you know that both ‘tablet’ quantities are for Aspirin. You have to at least know what the tablet size is. This can be known, and the semantics can be known, but not from a basic Quantity type; we need something more.

A very basic rule in IT and modelling is to build things additively, using a new abstraction for each new complication. The alternative of trying to jam all possible use cases into a single type or abstraction always leads to something unwieldy, unclear and guaranteed to create bugs in processing and data. That’s the reason we don’t try to make the type ‘Integer’ do more than a simple integer can do.

Similarly, I would argue that the basic ‘Quantity’ type in a set of data types for science / biomedical computing should just do its basic job - representing quantities with units, accuracy, and precision. (We already violate this somewhat in openEHR by including reference ranges, but at least that remains perfectly computable.)

When we get to the scenario of quantities of drugs delivered in quantised dose objects such as tablets etc, we are at another level of sophistication. It doesn’t make sense to change the Quantity data type to do a more complicated job; if we do that, we have no Quantity type that just implements standard scientific quantities.

Adding a new smart type, say DoseQuantity, is easy enough. Or else we relegate the more complex information needed for drug information to archetype data points as we do now. Trying to hack an existing type to do a job it is not designed to do is a bad idea.

  • thomas
53

I agree with Thomas. Speaking as someone who has had to help with quality control of large amounts of user entered concomitant medication data for clinical trials, ‘tablet’ , ‘capsule’, and similar are not ‘units’ unless they are associated with other reference data.
‘Tablet’ is a description of the appearance of the medication, which is not useful in the context of dose units.
’Tablet’ may be useful as a discriminant between different proprietary products, if you have more details (e.g. the product name) and a database which has the dose units of the product variations.

Colin Sutton
I.T. Systems Development Manager
NHMRC Clinical Trials Centre

54

Hi Ian,

In NZ we use the NZMT which is based on AMT (which is based on dm+d) – the tricky bit is neither of these are part of the SNOMED CT proper in terms of content but they do use SCTIDs and have formal IHTSDO namespace as national extensions. Based on the NZMT we have a Formulary which are all provided through the NZULM service. I really think is this the right way to go with medicines although there’s quite a bit of discomfort (among health informaticians / developer community) with the constraints the SNOMED CT way of representation brings (the 7-Boxes) and the fact that content is not harmonised with international edition so comparative studies can be done across different jurisdictions. There is also belief an SPARQL based access (at least as an alternative) to medicines terminology would be a better way. My 2 cents

I’d support adding the means to manage medicinal units (called units of use) at RM level (e.g. as a separate data type).

Cheers,

-koray