As Grahame mentioned on an earlier post, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won’t work. There seem to be two reasons for this:
it doesn’t take care of the need for a displayable form of units, e.g. the computable form ‘mcg’ or ‘ug’, where as the displayable is ‘µg’ (Greek mu followed by ‘g’)
it doesn’t take care of ‘units’ like puffs, tablets, patches, vials, strips, and other discrete delivery units
it doesn’t take care of discrete delivery units per time, e.g. ‘2 puffs / hour’
Grahame and others have already done a lot of thinking on this here - there are a lot of excellent examples from Linda Bird on the Singapore programme.
The more I think about the last two above, the more I think it is not about quantities per se but about an administration directive (how the patient should take something). Trying to make Quantity do that kind of stuff doesn’t make sense to me - there is obviously a Quantity to indicate the dose in scientific form, but another data element may be needed to indicate how (in what discrete measures) to take the medication.
I would therefore expect a distinct data element in the Medication Cluster archetype rather than a re-engineered Quantity type to deal with these last two. For the first one - displayable v computable, we will need a CR to change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a second units field.
Some of my earlier thoughts are actually on the above wiki page - the concept of a DiscretisedQuantity type inheriting from Quantity, which I think is also a reasonable alternative.
Are discrete units only encountered in administrative directives? Do
you prohibit people from making observations or measurements that
include discrete units such as puffs, tablets, patches, vials, strips etc?
why?
HL7 does because we claim that you have to have UCUM codes
so the data can be computable. If people simply want to exchange
it in a structured but non-computable fashion... they can go to hell.
And as for computable: we insist on a ucum code, and then say
that for these discrete unit kind of things, well, you just put "1" for
countable units, and then put the effective unit somewhere else -
somewhere that no one can actually pull off in practice - because
this is more "computable". Huh? We do not make sense on this.
Are discrete units only encountered in administrative directives? Do
you prohibit people from making observations or measurements that
include discrete units such as puffs, tablets, patches, vials, strips etc?
I don't think so; a physician could obviously ask a patient how many ventolin puffs they take a day.
why?
HL7 does because we claim that you have to have UCUM codes
so the data can be computable. If people simply want to exchange
it in a structured but non-computable fashion... they can go to hell.
And as for computable: we insist on a ucum code, and then say
that for these discrete unit kind of things, well, you just put "1" for
countable units, and then put the effective unit somewhere else -
somewhere that no one can actually pull off in practice - because
this is more "computable". Huh? We do not make sense on this.
So much for HL7... what's openEHR's excuse?
well it's not prevented from being expressed; it's just expressed using a Quantity field (e.g. a DV_COUNT) and another field saying what you are counting (there are a reasonable number of examples of this already in the archetypes - number of cigarettes a day, number of previous pregnancies, number of steps taken in physiotherapy etc). If we made this a Quantity, we could in theory then use an instance to say '3 puffs'. But this is not an amount of substance, it's a count of 'delivery' units or 'grains' of substance. I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it. That's why it seemed to me that if we are going to try and bind this counting concept with a Quantity concept, then we need a dedicated subtype like DiscretisedQuantity that adds in the info of '3 puffs' to a Quantity that can represent '30 mcg'.
well it's not prevented from being expressed; it's just expressed using a
Quantity field (e.g. a DV_COUNT) and another field saying what you are
counting (there are a reasonable number of examples of this already in the
archetypes - number of cigarettes a day, number of previous pregnancies,
number of steps taken in physiotherapy etc). If we made this a Quantity, we
could in theory then use an instance to say '3 puffs'. But this is not an
amount of substance, it's a count of 'delivery' units or 'grains' of
substance. I still think Quantities should be computable as such - if we
don't know how many mcg of substance 3 puffs is, we can't compute with it.
ok, so you say it should be computable, but then allow a fixed unit of one,
and some other code as well. And this in a subclass of Quantity, so you
could always use it or encounter it in place of quantity. So if that's the
case, why not simply make it a property of Quantity? What's really
important is not that all Quantities are computable, but that you know
whether you can compute with it. And in fact, making it a property of
Quantity makes it easier to manage and/or constrain
I had an issue recently were I was receiving HL7 V2 Lab messages with units such as x10^6/L, the equivalent in UCUM is 10*6/l, which was used in the archetype constraint for an RBC element. I translated the HL7 unit into the archetype constrained unit as required to be valid.
However, when we displayed this in our application that was going through a conformance process for this particular Lab’s interface to allowed to retrieve messages within the enterprise, the Lab said that we must display the unit as x10^6/L as provided in the HL7 message. Therefore we had to translate it back again in our app… sigh.
This scenario demonstrates this exact conversation.
Personally I don’t like the idea of another attribute for displayable units. I am thinking that we need to have a means to lookup a particular set of “displayable” units and get the computable unit for when we need to do any conversion, which I have yet to come across any need to do so in current implementations (not that this will not be required at some point but it will certainly be in very limited set of cases).
I am thinking the units attribute should be our “displayable”, and tat in cases where we need to convert to other units we provide a similar concept to mappings in DV_TEXT. Perhaps this should be the reverse, but because the displayable unit is the 99.99% use case I think we should make this the easiest representation with minimal change to RM.
In archetypes, if the units attribute is allowed to any value, we can then specify a conversion mapping for each unit, which may allow multiple “displayable” units to be defined and mapped to the same UCUM unit. So this conversion mapping is represented as knowledge in the archetype, but we also start getting some consistent representation of “displayable” units without the weirdness of UCUM syntax.
I don't know if your solution works. I've considered putting a service
up in the cloud that
provides a service to take represented units and convert them to ucum
units. But it's a
many to many mapping unless the conversion is actually done in the context of a
specific LOINC code, in which case there's a huge amount of
duplication of mapping work.
I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it.
Although i tend to agree with you, this won't work because then you assume that we're talking about the absolute truth. The absolute truth only exist when you're talking, for instance, about astronomics. In medicine you can't say 25 ml of alcohol is lethal. You can only say something like: 25 ml of alcohol is lethal in an adult man of 80 kg. And only when he doesn't drink more than 15 unit alcohol à week. When he drinks more then The lethal dose is higher. For à roman of the same weight who drinks < 15 units à week, the lethal dose is lower.
My point is that an absolute quantity alone doesn't meander much. At The other hand, we know empirically that if someone has smoked 15 pack years he's at serious risk.
Then about puffs. I' m almost sure that you can translate à puff info a volume. If i remember it correctly 40 drops is 1 ml. So the same should go for puffs.
because it only applies in a small number of cases. Most Quantity instances will never have this because they don't represent this kind of information.
I think that might work theoretically, but it means establishing yet another terminology (or piece of SCT) that is going to take time to agree, and then has to be deployed and in every computing environment. I also don’t think we can predict how much it will be used in the future - the future is all about computing with data, unlike today, where we are still just moving it around. I could be wrong - maybe the units work in SCT is further ahead than I think. The other problem is the problem of synonyms - there is not always a 1:1 mapping between display and computable forms.
Well, that is only true if we think the data are only being used for display. But if the data need to be computed with - even if large research projects only start using openEHR data in a few years time - imagine the frustration when researchers discover non-computable units all over the place.
we could do it that way… we would need to look at some actual data examples and see if that would work.
I'm trying to make sense of this discussion around "computability" -- what
are the kinds of things that one wants to "compute" with these kinds of
countable things?
I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it.
Although i tend to agree with you, this won't work because then you assume that we're talking about the absolute truth. The absolute truth only exist when you're talking, for instance, about astronomics. In medicine you can't say 25 ml of alcohol is lethal. You can only say something like: 25 ml of alcohol is lethal in an adult man of 80 kg. And only when he doesn't drink more than 15 unit alcohol à week. When he drinks more then The lethal dose is higher. For à roman of the same weight who drinks < 15 units à week, the lethal dose is lower.
My point is that an absolute quantity alone doesn't meander much. At The other hand, we know empirically that if someone has smoked 15 pack years he's at serious risk.
Then about puffs. I' m almost sure that you can translate à puff info a volume. If i remember it correctly 40 drops is 1 ml. So the same should go for puffs.
ok but you are still talking about making it computable somehow - by assuming 1ml = 40 drops or whatever. If we want a kind of quantity that accommodates only representation in non-systematic units, we should not mix this type up with a proper Quantity that can be used with 90% (or maybe its only 75%) of all clinical data.
Doesn’t ‘computability’ depend on having clearly defined rules on how the UOMs relate to each other? Yes, UCUM provides this - however I don’t understand why (in the context of a national program), we would exclude another terminology-based knowledge source (e.g. a SNOMED CT extension) providing these computational rules.
If, for example, we referred to “2 tablets” of “Paracetamol 500 mg + Codeine Phosphate 15 mg Tablet”, and we have a knowledge base that tells us that each of these tablets has “500 mg” of Paracetamol and “15 mg” of Codeine Phosphate, then we can compute that:
“2 tablets” of “Paracetamol 500 mg + Codeine Phosphate 15mg Tablet”
is therapeutically equivalent to
“1 tablet” of “Paracetamol 1g + Codeine Phosphate 30 mg Tablet”
This is just one of many ‘computations’ which are possible with an additional knowledge base that is very useful for decision-support purposes.
Clinicians may order “500 mg” of "Amoxicillin Capsule"s, or “1 capsule” of “Amoxicllin 500 mg Capsule” … and these actually mean different things (the former could either mean 1 x 500 mg capsule, 2 x 250 mg capsules, etc; while the later specifically means 1 x 500 mg capsule). In the case of simple dosing, clinicians would expect to see only 2 fields - dose_value and dose_units, irrespective of whether the units is “mg” or “capsules” … with the knowledge base determining the ‘computability’ rules.
I think your first example demonstrates why "tablet" is not a "Unit" -- I could equally say:
"2 Mountains" of "Paracetamol 500 mg + Codeine Phosphate 15mg Mountains"
is therapeutically equivalent to
"1 Mountain" of "Paracetamol 1g + Codeine Phosphate 30 mg Mountains"
Really what I am saying here is:
2 of "Paracetamol 500 mg + Codeine Phosphate 15mg Tablet"
is therapeutically equivalent to
1 of "Paracetamol 1g + Codeine Phosphate 30 mg Tablet"
In your next example, both orders are for "500mg of Amoxicllin" in "capsule form" but the second case also says "1 capsule" and carries with it a business rule that says you cannot convert this. However, it still doesn't change the "therapeutically equivalent" relation. That is, "therapeutically equivalence" should be treated separately from "can be substituted for when dispensing".
In clinical practice, a clinician may either order a dose of ‘2 tablets’ or alternatively ‘500 mg’. I would argue that these are both equally ‘computable’, given the appropriate knowledge base.
Well I'm still stuck trying to understand what you mean by 'computable'.
And, no, a clinician cannot prescribe (just) "2 tablets" -- I cannot compare that with "500 mg" unless I know how much is in each tablet. Once you've told me how much is in each tablet, then (from a computability perspective), I may as well have just said "2 units".
‘tablet’ ‘capsule’ and ‘box’ are all quantities that only make sense when you know the context.
mcg and 10^-6/L are measurement units that do not need a context.
That’s not to say that ‘tablets’ etc. should not be recorded in the eHR, just that their usefulness depends on the context being linkable, or ambiguity will result.
well any mathematical operation working on quantities - e.g. averages, max, min, variance, standard deviation etc etc. These kind of operations are ubiquitous in research queries, and will become increasingly so in personal health records. Just consider what is needed to determine the actual amount of tobacco consumed by each of 10,000 patients in a cohort - each of whom report their usage in terms of ‘tailor-made cigarettes’, ‘hand-rolled cigarettes’, ‘cigars’, ‘chewing tobacco’ (okay not popular, but still in use in some places!), ‘grams a week (of pipe tobacco)’, etc etc. Some patients have a mixture of these.
Same argument for amounts of drugs taken by patients in a cancer study, amounts of sugar, salt, cholesterol computed from food recorded in patient diet and so on. How about a query that finds all patients with blood sugar over 7? What if they input the data (at home) in different unit systems due to different equipment?
We simply can’t do any useful computing if we can’t trust the data. We don’t do that much computing now with it because of the unreliability of the available data, but the only interesting future really is being able to do intelligent computing with the data. To get there we have to be able to compute reliably with quantities.
I have no problem with data that records only ‘puffs’, ‘patches’, ‘pessaries’, ‘pills’, ‘pellets’ or ‘powder’… but we don’t want to compromise data that record normal scientific quantities. Therefore I think we should be treating these kind of amounts as a separate type. This is distinct from the problem of Quantities that do have scientific units, but there is a conflict with the displayable form. I think we should accommodate that in the current data type - a small modification would take care of that.