Postulate: DV_QUANTITY should be modelled with fewest possible units
Hi Thomas, RM function to retrieve a magnitude expressed as a particular unit. from my previous email ... I think we could add something at reference model level to say give me this quantity in 'x' units, performing the conversion at server level where possible or return null. This could also be supported in AQL since it would just be another RM attribute/function? magnitude.inUnit['mg'] I think this is, roughly speaking, what FHIR is doing 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 17 November 2014 12:13, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 17/11/2014 07:42, Ian McNicoll wrote: Hi Karsten, I agree, this will not always be possible but where the conversion can be safely done, I would still argue that this should be done at RM level and not per-archetype. Hi Ian, I'm not sure what you mean by doing this at the RM level. Can you elaborate? - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Postulate: DV_QUANTITY should be modelled with fewest possible units
On 17/11/2014 12:47, Ian McNicoll wrote: Hi Thomas, RM function to retrieve a magnitude expressed as a particular unit. from my previous email ... I think we could add something at reference model level to say give me this quantity in 'x' units, performing the conversion at server level where possible or return null. This could also be supported in AQL since it would just be another RM attribute/function? magnitude.inUnit['mg'] I think this is, roughly speaking, what FHIR is doing well, it's not a reference model thing inasmuch as it's not an information model concept at all, but a knowledge service concept, relying on some database of units that knows about canonical forms, conversions etc. This is what things like the UCUM service do, via an API. I wouldn't want to make the RM dependent on specific functions of such an API; I think the most that the RM should assume (as it does right now in fact) is that the units are in UCUM syntax. - thomas
Postulate: DV_QUANTITY should be modelled with fewest possible units
Dear all, Magnitude is not the same as Units of Measurement. Units of Measurement are not the same as Magnitude. Gerard Gerard Freriks +31 620347088 gfrer at luna.nl mailto:gfrer at luna.nl On 17 nov. 2014, at 13:47, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: Hi Thomas, RM function to retrieve a magnitude expressed as a particular unit. from my previous email ... I think we could add something at reference model level to say give me this quantity in 'x' units, performing the conversion at server level where possible or return null. This could also be supported in AQL since it would just be another RM attribute/function? magnitude.inUnit['mg'] I think this is, roughly speaking, what FHIR is doing Ian -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141117/c1c28e6e/attachment.html
Postulate: DV_QUANTITY should be modelled with fewest possible units
Hi Gerard, Agreed - the dummy function call says give me the magnitude in ?xx? Units of measure, performing any conversions necessary?. 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 17 November 2014 16:00, Gerard Freriks gfrer at luna.nl wrote: Dear all, Magnitude is not the same as Units of Measurement. Units of Measurement are not the same as Magnitude. Gerard Gerard Freriks +31 620347088 gfrer at luna.nl On 17 nov. 2014, at 13:47, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: Hi Thomas, RM function to retrieve a magnitude expressed as a particular unit. from my previous email ... I think we could add something at reference model level to say give me this quantity in 'x' units, performing the conversion at server level where possible or return null. This could also be supported in AQL since it would just be another RM attribute/function? magnitude.inUnit['mg'] I think this is, roughly speaking, what FHIR is doing Ian ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Postulate: DV_QUANTITY should be modelled with fewest possible units
On Fri, Nov 14, 2014 at 01:55:56PM +, Ian McNicoll wrote: 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. Uhm, yeah, well, no. There are units in use which only apply in context -- their conversion would require knowing, say, the substance measured. And that's only those that actually _make_ any computational sense. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Postulate: DV_QUANTITY should be modelled with fewest possible units
On Sun, Nov 16, 2014 at 12:02:00PM +0100, Karsten Hilbert wrote: There are units in use which only apply in context -- their conversion would require knowing, say, the substance measured. think mg/dl - mmol/l Karsten Hilbert -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Postulate: DV_QUANTITY should be modelled with fewest possible units
Bj?rn, Thomas
You could potentially create a template for each archetype with this unit
issue, if you like, and govern it in the Norwegian CKM. That artefact can then
be published as the 'approved' Norwegian version of the international archetype.
Templates of a single archetype are effectively a profile. We use this in
Ocean's implementations where we want consistent archetype constraints used
across multiple document templates.
Templates can then be used in other templates and these Norwegian-specific
constraints could be used consistently across templates within a single
clinical system and also across multiple clinical systems.
The only remaining issue would be to indicate that the template is the
preferred modelling artefact - not sure how we do that other than notification
in CKM. It would not be apparent to modellers deep in the tools, and
predominantly working with archetypes. Not sure how we could do that... :(
Regards
Heater
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On
Behalf Of Thomas Beale
Sent: Friday, 14 November 2014 8:04 PM
To: openehr-technical at lists.openehr.org
Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible
units
On 14/11/2014 08:42, Bj?rn N?ss wrote:
I have been thinking about profiling. I am not sure if this fix the problem
regarding complexity.
This may be an governance thing. If we define a metric and british imperial
profile we may define that in Norway every application MUST use the metric
profile and other countries may select british imperial. This could make it
easier to set up validation on entries.
Is this a usage you were thinking about?
exactly. It requires defining the profiles in the archetypes as per my last
post. I can see that it could work for units, not sure about other things. If
such profiles were defined, it would then be possible to make a template tool
remove elements you don't want when creating templates. This would be done by
the normal means e.g.
path/to/imperial/quantity occurrences matches {0}
but it would be done for you, and noone would have to go looking for them.
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141115/f79f18ab/attachment.html
Postulate: DV_QUANTITY should be modelled with fewest possible units
Hi Heather,
I agree with that approach. I would actually regard this as a kind
specialised archetype, just using template technology.
One of the advantages of moving to ADL1.5/2.0 is that it is is
possible to do this kind of profiling as a specialised archetype not
just within a template. In fact templates and archetypes are
technically identical.
You do raise an interesting point about how/if we flag that the parent
archetype itself should not normally be used.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian at freshehr.com
twitter: @ianmcnicoll
Director, freshEHR Clinical Informatics
Director, openEHR Foundation
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
On 15 November 2014 05:03, Heather Leslie
heather.leslie at oceaninformatics.com wrote:
Bj?rn, Thomas
You could potentially create a template for each archetype with this unit
issue, if you like, and govern it in the Norwegian CKM. That artefact can
then be published as the ?approved? Norwegian version of the international
archetype.
Templates of a single archetype are effectively a profile. We use this in
Ocean?s implementations where we want consistent archetype constraints used
across multiple document templates.
Templates can then be used in other templates and these Norwegian-specific
constraints could be used consistently across templates within a single
clinical system and also across multiple clinical systems.
The only remaining issue would be to indicate that the template is the
preferred modelling artefact ? not sure how we do that other than
notification in CKM. It would not be apparent to modellers deep in the
tools, and predominantly working with archetypes. Not sure how we could do
that? L
Regards
Heater
From: openEHR-technical [mailto:openehr-technical-bounces at
lists.openehr.org]
On Behalf Of Thomas Beale
Sent: Friday, 14 November 2014 8:04 PM
To: openehr-technical at lists.openehr.org
Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible
units
On 14/11/2014 08:42, Bj?rn N?ss wrote:
I have been thinking about profiling. I am not sure if this fix the problem
regarding complexity.
This may be an governance thing. If we define a metric and british imperial
profile we may define that in Norway every application MUST use the metric
profile and other countries may select ?british imperial?. This could make
it easier to set up validation on entries.
Is this a usage you were thinking about?
exactly. It requires defining the profiles in the archetypes as per my last
post. I can see that it could work for units, not sure about other things.
If such profiles were defined, it would then be possible to make a template
tool remove elements you don't want when creating templates. This would be
done by the normal means e.g.
path/to/imperial/quantity occurrences matches {0}
but it would be done for you, and noone would have to go looking for them.
- thomas
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Postulate: DV_QUANTITY should be modelled with fewest possible units
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 10tel:+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.comhttp://cabolabs.com/es/homehttp://twitter.com/ppazos From: b...@dips.no 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 + 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
Postulate: DV_QUANTITY should be modelled with fewest possible units
I have been thinking about profiling. I am not sure if this fix the problem regarding complexity. This may be an governance thing. If we define a metric and british imperial profile we may define that in Norway every application MUST use the metric profile and other countries may select ?british imperial?. This could make it easier to set up validation on entries. Is this a usage you were thinking about? Vennlig hilsen Bj?rn N?ss Produktansvarlig DIPS ASA Mobil +47 93 43 29 10tel:+47%2093%2043%2029%2010 From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Thomas Beale Sent: 13. november 2014 22:04 To: openehr-technical at lists.openehr.org; For openEHR clinical discussions Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible units On 13/11/2014 20:34, Bakke, Silje Ljosland wrote: The original context for this discussion was this archetype: http://arketyper.no/ckm/#showArchetype_1078.36.25 (default archetype language for this CKM is Norwegian, but it can be changed manually) Being an all-metric country since the 1800s, we've removed lbs as a possible unit, but added g (gram) for weighing infants. There is something I have been thinking about for a while, which is whether we need some kind of 'profiles' in archetypes, that can be used select or deselect alternative constraints. An 'alternative' in an archetype is technically 1. an alternative object constraint under a single-valued attribute; example: a DV_QUANTITY and a DV_COUNT as siblings under ELEMENT.value representing 'amount of tobacco' 2. any optional object under a container attribute, typically with other siblings 3. any branch of a tuple (ADL 2 speak) or branch of C_DV_QUANTITY - this is the units example So I have been thinking whether we need something like a profile section, with named profiles, pointing to the paths of things in (or not in) that profile. We could imagine profiles like: profiles = [metric] = path1, path2, [system international] = path1, path2, [british imperial] = ... [us imperial] = ... Now the question is whether this just applies to units, or whether it's more global. For example, could there be an argument to create profiles for 'general practice', 'icu', 'aged care'? Consider the example of the BP archetype. It contains 'systolic pressure', 'diastolic pressure', 'pulse pressure' and 'mean arterial pressure'. Now the last two are only used in anaesthesiology and specific instruments (from memory); one could imagine some profiles that would select out pulse pressure for just 'anaesthesiology'. Right now, this selection occurs by people specialising archetypes, and ultimately making templates, and along they way, getting rid of things they don't want, and keeping what they do. But there's no way you can run a query over an archetype library and filter it on some specialty, or even 'metric'. But there are many other reasons for specialising and removing / keeping elements as well - geographical, legislative, anything... So for now this remains just an idea - we would need some input from clinical modellers to know whether it's a useful one or not. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141114/05c3a926/attachment.html
Postulate: DV_QUANTITY should be modelled with fewest possible units
On 14/11/2014 08:42, Bj?rn N?ss wrote:
I have been thinking about profiling. I am not sure if this fix the
problem regarding complexity.
This may be an governance thing. If we define a metric and british
imperial profile we may define that in Norway every application MUST
use the metric profile and other countries may select ?british
imperial?. This could make it easier to set up validation on entries.
Is this a usage you were thinking about?
exactly. It requires defining the profiles in the archetypes as per my
last post. I can see that it could work for units, not sure about other
things. If such profiles were defined, it would then be possible to make
a template tool remove elements you don't want when creating templates.
This would be done by the normal means e.g.
path/to/imperial/quantity occurrences matches {0}
but it would be done for you, and noone would have to go looking for them.
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141114/d4d5b67a/attachment-0001.html
Postulate: DV_QUANTITY should be modelled with fewest possible units
On 14/11/2014 00:57, Ian McNicoll wrote: Hi Pablo, I would agree, this information is also carried in the Archetype Editor property files, although I suspect not as well maintained as the UCUM file. @Thomas - the profile suggestion is interesting but it feels to me that it adds level of categorisation that is likely to be imprecise e.g map is certainly not just only used in anaesthesia, and even the use of imperial vs metric is likely to e somewhat blended in places e.g the UK where although metric is used officially, it is quite common for patients themselves to use imperial. yes, exactly. That's why this thought it just a thought, and I have never proposed it seriously in the formalism - as soon as you start digging, everything gets muddy. Units may be one of the few things where profiles could even be stated. The question is then what do tools do with the profiles. - thomas
Postulate: DV_QUANTITY should be modelled with fewest possible units
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 10tel:+47%2093%2043%2029%2010 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141114/5aa01478/attachment-0001.html
Postulate: DV_QUANTITY should be modelled with fewest possible units
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 at 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
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 From: b...@dips.no 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 + 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/20141113/8ab4298a/attachment.html
