surely the obvious approach is that the stored field contains the UCUM
case-sensitive code, and that applications / services use UCUM tables to
render whatever display form is asked for in a client call? (I realise
openEHR archetypes are not doing this; they should be...)
there's another
Eric,
nice summary of issues. If I can take the liberty of pulling out what I
think are your key issues to worry about + recommendations. I bolded my
own subset of those ...
On 10/10/2015 10:07, Eric Browne wrote:
*Notes on UCUM*
* UCUM does not supply normative names of units.
* Some
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
Hi Heather et al,
Whilst I have followed this thread and agree with many of the observations and
conclusions reached so far, I would like to make the following observations,
which are restricted to the aspect of the “non-UCUM" unit described in
Heather’s original posting. They have more
4 matches
Mail list logo
