Hi Heath yes, this the problem.
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. Grahame On Mon, Mar 19, 2012 at 8:51 AM, Heath Frankel <heath.frankel at oceaninformatics.com> wrote: > 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-bounces at 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 - 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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- ----- http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
