Two reactions: 1- There is a difference between the world of semantic interpretability in system interfaces and the real word of users looking at screens, and typing on keyboards In one world we can/must use as much as possible SI units via UCUM and strife for as detailed as possible reducing misinterpretation. In the real world users want to have data presented in many shapes and forms. Accommodating the end-users is the task of the industry. It is the task of health informaticians to reduce misinterpretations.
At the Template/Interface level we need facilities to annotate as much as possible that what is expressed/modelled. And why not have in the annotations, the printable, the human readable, the personal choice, the local choice. 2- When it comes to the Arbitrary UCUM Units. The question is how much semantic we carry in data types. And how much semantics we carry in archetypes. I opt for the latter. Data types should be as primitive as possible. I use the UCUM Arbitrary ‘Unit’ and use the structure in the Archetype to provide the semantics that describe the Unit. Gerard Freriks +31 620347088 [email protected] <mailto:[email protected]> > On 19 mei 2016, at 09:24, Thomas Beale <[email protected]> wrote: > > Hi Gerard, > > they actually could be, but whenever this discussion comes up, no-one > proposes it. I'm not sure if I would either, because these arbitrary units > are still not computable in general, but 'dose units' can be made computable > but only with some extra data fields, i.e. you need both the quantity of dose > in 1 tablet/capsule etc, and also number of tablet/capsule etc. So the > structural model is different anyway. > > I think the other problem with using UCUM arbitrary units is that people / > orgs want to control the names of medicinal delivery products ('tablet' etc) > in a terminology, which is reasonable, but doesn't fit so well with UCUM. > > - thomas > >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
