An application need that kind of service. But this is actually not the problem. See my latest mail regarding guildelines and population queries.
Vennlig hilsen Bj?rn N?ss Produktansvarlig DIPS ASA Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010> -------- Original message -------- From: pablo pazos Date:14/11/2014 01:07 (GMT+01:00) To: openeh technical ,openEHR Clinical Subject: RE: Postulate: DV_QUANTITY should be modelled with fewest possible units Hi Bj?rn, IMO when you have complex unit processing, a lookup service for UCUM might be needed. UCUM contains multipliers and correspondences between different unit systems, check this: http://unitsofmeasure.org/ucum-essence.xml Using this, a constraint on archetypes might not be needed. What do you think? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos> ________________________________ From: [email protected] To: openehr-technical at lists.openehr.org; openehr-clinical at lists.openehr.org Subject: Postulate: DV_QUANTITY should be modelled with fewest possible units Date: Thu, 13 Nov 2014 20:07:00 +0000 I want to try out a postulate regarding modelling of datavalues, and more specific DV_QUANTITY. The postulate is: Postulate 1: A data type of DV_QUANTITY should be modelled with fewest possible units! Reason behind this is to make queries and reasoning over the values easy. This makes it both faster and safer building sustainable software and systems using these values. I also think that converting between i.e. grams and kilos should be done in the client (user interface / integration engine/ etc.). What do you think? Vennlig hilsen Bj?rn N?ss Product Owner DIPS ASA Mobil +47 93 43 29 10 _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141114/31f9962d/attachment.html>
