On 18/03/2012 21:51, Heath Frankel 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 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. > 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. > 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. > 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. > we could do it that way.... we would need to look at some actual data examples and see if that would work. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/887557f7/attachment-0001.html>
