On 29-01-18 15:22, Thomas Beale wrote:
Another idea is to change it to a CODE_PHRASE, with terminology_id = UCUM
Yes, I understand the decision, but IO regard it as a quick decision which can cause problems on the longer term.
For the record, I object against this decision for the last time. (or else it will get boring ) ;-)
UCUM does not have an infrastructure for translations, so translations will be done "in the wild", this may be good or may be bad.
SNOMED has an infrastructure for professional translations, SNOMED also supports units and hierarchies, like UCUM-properties.
It is of course a matter of taste, and what a customer wants. But I think, OpenEHR should offer a customer optional facilities for professional translations of the units. Pinning the DvQuantity to UCUM in the RM makes it impossible for the customer to chose for a professional translation on archetype-level.
There is another disadvantage of this unnecessary inseparability of the RM and UCUM, it is against the OpenEHR philosophy to offer as much freedom in modeling as possible.
So take your decisions wisely ;-) Best regards Bert _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
