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/20120318/ead04269/attachment.html>
