hi Eric Some comments:
* UCUM introduces ambiguity, despite the above claim. > please demonstrate examples. > * UCUM does not provide a single code for each unit - it provides 2 > normative codes, as well as a non-normative display/print rendition and an > ad-hoc name. For each unit, UCUM defines a case-sensitive version, a > case-insensitive version, and a version intended for display or printing. > the display is not the same as the 2 codes and so your sentence is misleading. As for the 2 codes, the case-insensitive codes should be ignored. All the contexts of use I have seen require the use of case sensitive codes. > * Some units have no display/print variant defined. > you mean name, or printSymbol? examples? * Some similar units have quite dissimilar UCUM variants. e.g. > so? > * UCUM’s names don’t follow the 7-bit rule. Some names like *Ampère* and > *Ångström* use 8-bit character representation. > UCUM says that the codes do, not that the names or print symbols do * UCUM uses [qualifier]s to indicate where a base unit is changed, e.g. *mm* is > a unit for length property whereas *mm[Hg]* is a unit for pressure > property. The [] syntax is unnecessary and complicates implementations. > The [] is not unnecessary, nor should it complicate anything. It's a code, and [] is introduced to remove ambiguity. What complications do you think it introduces? * UCUM releases are clearly supported and versioned, although differences > between versions are hard to determine. > are you familiar with text diff programs? > * Further useful information: > http://motorcycleguy.blogspot.com.au/2009/11/iso-to-ucum-mapping-table.html > and here: the most commonly used UCUM codes based on extensive survey of implementers systems: http://hl7.org/fhir/valueset-ucum-common.html > > * Depending on the quantity being sent in a report, the ability to > computationally deal with the unit is fraught with implementation issues. > Some parameters such as temperatures or weights that have been modelled as > such in archetypes can be validated. In many cases there is simply too much > variability, either in the units that are allowable for a particular field, > or for the variability in quality of the actual units sent. > there's another problem: in both v2 and CDA, HL7 specified a single units field on the assumption that implementers could somehow square the circle and have a single units that satisfies human and computer readability. This is not possible. Hence the mess we are in. Grahame
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
