Hi Thomas, 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. Hope this triggers further thoughts. Heath From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Thomas Beale Sent: Sunday, 18 March 2012 10:49 PM To: Openehr-Technical Subject: Units, Quantities, etc 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 <http://www.healthintersections.com.au/wiki/index.php?title=Non-ucum_units_in_Quantity> - 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. what do others think? - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/ce91de2c/attachment.html>
