Well, I assume that this also works for specialized archetypes, I don't see why it shouldn't. Declare rules in parent archetype and you don't need to declare them anywhere else.
2014-11-14 14:55 GMT+01:00 Ian McNicoll <ian.mcnicoll at oceaninformatics.com>: > Hi Diego, > > I am sure that could be done but it would mean replicating these kind > of statements in every archetype that had multiple units. This really > feels like something that should be handled computationally at RM > level- it is universal and a property of the units not of the > archetype. > > Ian > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant, Ocean Informatics, UK > Director openEHR Foundation www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > SCIMP Working Group, NHS Scotland > BCS Primary Health Care www.phcsg.org > > > On 14 November 2014 13:32, Diego Bosc? <yampeku at gmail.com> wrote: >> Again, I strongly believe we can achieve this with >> Assertions/pseudo-OCL that currently can be defined in archetypes. >> For example: "if 'units' from atNNNN are 'kg' then >> 'value'='value'*1000 and 'units'=g" >> >> I think Thomas told me there were some improvements in the archetype >> assertions section/syntax. >> >> 2014-11-14 13:12 GMT+01:00 Bj?rn N?ss <bna at dips.no>: >>> I guess smart querying services would do the work. But should it also be >>> possible for the client to say when unit conversion should be used and when >>> not? >>> >>> Use case is when user only want the units stored as grams, and not kilos. >>> >>> Maybe a pattern from HTTP could be used. The accept pattern. >>> >>> Accept: profile (metrics, british imperial) >>> Accept: gram, kilos >>> >>> Of course all this add complexity and we must be sure that we really need >>> it. >>> >>> >>> Vennlig hilsen >>> Bj?rn N?ss >>> Produktansvarlig >>> DIPS ASA >>> >>> Mobil +47 93 43 29 10 >>> >>> >>> -------- Original message -------- >>> From: Thomas Beale >>> Date:14/11/2014 10:14 (GMT+01:00) >>> To: openehr-technical at lists.openehr.org >>> Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible >>> units >>> >>> >>> Should we have a way of marking the 'normative' units for computation / >>> conversion? So that then you only create AQL queries in the units you >>> want, and let the query service do the rest (e.g. by looking up the UCUM >>> DB)? In fact, you don't even need to mark anything as normative, if the >>> query service is smart, if would know how to do units comparisons. If it >>> hits weight data in other units, it does an on-the-fly conversion. >>> >>> - thomas >>> >>> On 14/11/2014 06:06, Bj?rn N?ss wrote: >>>> Thanks for your feedback on this small topic. I agree with your opinions, >>>> and this may not be a huge problem. My point of view is not from an >>>> Archetype or Template modelling point. I am more into Guideline modelling >>>> and population queries. >>>> >>>> Take for instance the guide for Body Mass Index: >>>> https://github.com/openEHR/gdl-tools/blob/master/cm/guidelines/BMI.Calculation.v.1.gdl >>>> . This rule will be more complex if we add more units. Then the guideline >>>> editor must consider all possible units and conversion between them. That >>>> is >>>> of course doable and MUST be done if the clinical model say this is needed. >>>> >>>> Another use-case is population queries. If I want to find all entries of >>>> body-weight that is between 0,3 and 3 kg. I must create a query that >>>> consider all possible units; both grams and kilos from the metrics and lb >>>> from the imperial. This is of course doable, but add more complexity when >>>> querying. >>>> >>>> I agree with you that this could be handled by templating. For a given >>>> system we should use Templates that secure data quality, i.e. always use >>>> the >>>> same unit for given use-cases. >>>> >>>> When I use the term system I do not mean one application. I am thinking >>>> about the system of all health care applications in a large health >>>> enterprise or a nation. If we only talk about applications this will not be >>>> a problem, because you may/should have control on templates. >>>> >>>> @ian e.g very young children where some clinicians use grams and others >>>> use kg for exactly the same patients in exactly the same circumstances. >>>> Yes - some clinicians want to use grams and other kgs. And I think the >>>> application used to display data and/or create data should handle this. >>>> >>>> If I am, as a clinician, used to think of a given quantity in grams, then >>>> I want the application to give me data in grams. As clinician should not >>>> have to use brain-capacity to convert between different units. Working in >>>> neonatal I want all weights to be grams. But the question is if we then >>>> MUST >>>> add grams to the Archetype? >>>> >>>> @ian Creating 2 different archetypes for each unit only moves the querying >>>> complexity elsewhere (arguably worse). >>>> I agree when you put it like this :-). This would be a nightmare if we >>>> have one archtype for each unit. >>>> >>>> And to bring back the postulate: "DV_QUANTITY should be modelled with >>>> fewest possible units". This only means that we should be restrictive when >>>> adding more units because it may add complexity when using the archetype. >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
