The main problem is that ucum units are not human readable units, and trying to force them to be will generate substantial pushback from end users. In USA, this is an open problem for CDA adoption. In Australia, I solved it by declaring that we would never retire valid ucum units in CDA.
A secondary problem is discrete units like tablet, capsule etc which have no computable form in ucum Grahame > On 18 May 2016, at 9:17 PM, Thomas Beale <[email protected]> wrote: > > Hi Ian > As far as I know, 'dose units' are not scientific units as such; they're > measures of discrete objects (including 'puffs' etc), which don't fit into a > clean grammar of scientific units, and trying to do so will just ruin the > former. > > We do of course need dose units, but we need a better way of modelling them - > my view is that they should not be treated as if they were 'units' in the > usual sense. > > The relevant SNOMED codes seem to be these 'unit of product usage' codes, > which is the correct kind of description. > > What is the current problem/issue with modelling 'dose units' in archetypes > in fact? It looks to me like the current modelling approach (similar to FHIR) > represents these elements in a reasonable way. > - thomas > >> On 18/05/2016 10:22, Ian McNicoll wrote: >> Hi Grahame, >> >> For the use case raised, I agree, but there other considerations e.g. Dose >> units and other non-UCUM code use - in the UK there is a desire to use >> SNOMED terms for dose units. >> >> FHIR has human + code + system for quantity units, I think? >> >> Ian > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
