Postulate: DV_QUANTITY should be modelled with fewest possible units

[Gerard Freriks]

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  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: 

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Ian McNicoll]

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  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 
> 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

[Thomas Beale]

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

[Ian McNicoll]

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
 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

[Thomas Beale]

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

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Ian McNicoll]

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.

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 16 November 2014 11:12, Karsten Hilbert  wrote:
> 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
>
> ___
> 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

[Karsten Hilbert]

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

[Karsten Hilbert]

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

[Ian McNicoll]

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
 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

[Heather Leslie]

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

[Diego Boscá]

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 :
> 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?  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 :
>>> 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 

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Diego Boscá]

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 :
> 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

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Ian McNicoll]

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?  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 :
>> 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 

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Thomas Beale]

On 14/11/2014 13:32, Diego Bosc? 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.
>
  we could do this; it would be replicating the applicable rules from 
the UCUM conversion engine. Writing such rules is certainly doable - it 
could even be done by an authoring tool that talks to the UCUM service 
and gets the info it needs to construct the rule.

I don't know if this is a good idea or not at this stage.

- thomas

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Ian McNicoll]

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?

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 14 November 2014 12:12, Bj?rn N?ss  wrote:
> 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

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bjørn Næss]

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
-- 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

[Ian McNicoll]

Thanks Bjorn,

That explanation was helpful in refining the issue.

I think we all agree that there is real requirement to allow
clinicians to work (visually, data-entry and querying) on their unit
of choice. We can try to manage / constrain the units available, more
appropriate at national level, as Sijje has suggested, but we are
still left wit the body weight example where g/kg are required at
point of care.

OTOH I understand Bjorn's point that having to deal with multiple
units at query / interface time seems needlessly complex and one
option would be to force the use of kg and make it the responsibility
of the app developer to do appropriate conversion / display. However
part of the purpose of building archetypes is to document this kind of
sort of real-world variation so that local developers do not need to
discover this for themselves. As such I am reluctant to force
archetypes to single units where conversion is possible.

I think Pablo is on the right track. I think we should take advantage
of the conversion rules where they exist which might allow units to be
aliased
e.g. body_weight/magnitude.asunit['kg'] which would force the
conversion of any kg units to g.

This could be used in queries, data retrieval or storage.

FHIR has the idea of 'canonical units'
http://www.hl7.org/implement/standards/fhir/search.html#quantity

"If the units are able to be coded in UCUM and a code is provided, it
SHOULD be a UCUM code. If a UCUM unit is provided in the codethen a
canonical value can be generated for purposes of comparison between
quantities. Note that the units element will often contain text that
is actually a valid UCUM unit, but it cannot be assumed that the units
element actually contains a valid UCUM unit".


Ian




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 14 November 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.
>
>
>
> Vennlig hilsen
> Bj?rn N?ss
> Product owner
> DIPS ASA
>
> Mobil +47 93 43 29 10
>
> -Original Message-
> From: openEHR-technical [mailto:openehr-technical-b

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Thomas Beale]

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.

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Thomas Beale]

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

[Thomas Beale]

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: 

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bjørn Næss]

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 10

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"] = 
["system international"] = 
["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

[Bjørn Næss]

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

 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: 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

[Bjørn Næss]

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.



Vennlig hilsen
Bj?rn N?ss
Product owner 
DIPS ASA

Mobil?+47 93 43 29 10

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Heather Leslie
Sent: 14. november 2014 06:09
To: For openEHR technical discussions; For openEHR clinical discussions
Subject: RE: Postulate: DV_QUANTITY should be modelled with fewest possible 
units

I echo Ian's opinion.

The value of having an archetype with metric and imperial units inside the one 
asset is that if you use one unit, you can still compute if you receive data 
using the other units as you have a common model and clear relationship between 
units. Templates is where you select what you want for your use case. If you 
take one set of units out of your archetype then when you receive data using 
alternative units you are relying on application based assumptions of semantic 
equivalence, rather than the 'no-brainer' of using the same archetype, 
different units.

And the notion of managing/governing/maintaining profiles, on top of 
archetypes, templates, terminology subsets, GDL rules and AQL queries makes my 
modelling/governing head hurt. I don't think this is sustainable, even if it is 
desirable. IMO this is what templates are for.

Regards

Heather

> -Original Message-
> From: openEHR-technical [mailto:openehr-technical- 
> bounces at lists.openehr.org] On Behalf Of Ian McNicoll
> Sent: Friday, 14 November 2014 11:57 AM
> To: For openEHR clinical discussions
> Cc: openeh technical
> Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest 
> possible units
> 
> 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.
> 
> @Bjorn - I am not really sure why this is such a problem.
> 
> As a modeller I would expect to remove any unwanted/unneeded units at 
> template level. You would there fore only be having to deal with 
> situations such as body weight where in your context both grams or kg might 
> be specified.
> Again as a modeller I would want to reduce this complexity where 
> possible but there must be clinical situation e.g very young children 
> where some clinicians use grams and others use kg for exactly the same 
> patients in exactly the same circumstances.
> Creating 2 different archetypes for each unit only moves the querying 
> complexity

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Heather Leslie]

I echo Ian's opinion.

The value of having an archetype with metric and imperial units inside the one 
asset is that if you use one unit, you can still compute if you receive data 
using the other units as you have a common model and clear relationship between 
units. Templates is where you select what you want for your use case. If you 
take one set of units out of your archetype then when you receive data using 
alternative units you are relying on application based assumptions of semantic 
equivalence, rather than the 'no-brainer' of using the same archetype, 
different units.

And the notion of managing/governing/maintaining profiles, on top of 
archetypes, templates, terminology subsets, GDL rules and AQL queries makes my 
modelling/governing head hurt. I don't think this is sustainable, even if it is 
desirable. IMO this is what templates are for.

Regards

Heather

> -Original Message-
> From: openEHR-technical [mailto:openehr-technical-
> bounces at lists.openehr.org] On Behalf Of Ian McNicoll
> Sent: Friday, 14 November 2014 11:57 AM
> To: For openEHR clinical discussions
> Cc: openeh technical
> Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible
> units
> 
> 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.
> 
> @Bjorn - I am not really sure why this is such a problem.
> 
> As a modeller I would expect to remove any unwanted/unneeded units at
> template level. You would there fore only be having to deal with situations 
> such
> as body weight where in your context both grams or kg might be specified.
> Again as a modeller I would want to reduce this complexity where possible but
> there must be clinical situation e.g very young children where some clinicians
> use grams and others use kg for exactly the same patients in exactly the same
> circumstances.
> Creating 2 different archetypes for each unit only moves the querying
> complexity elsewhere (arguably worse).
> 
> @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.
> 
> Perhaps I am missing something?
> 
> 
> 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 14 November 2014 00:07, pablo pazos  wrote:
> > 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: bna at 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
> >
> >
> >
> >
> &g

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bjørn Næss]

Se below: 

Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil?+47 93 43 29 10

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Diego Bosc?
Sent: 13. november 2014 21:23
To: For openEHR technical discussions
Cc: openehr-clinical at lists.openehr.org
Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible 
units

As mentioned on twitter, I agree with that postulate for templates, but not 
general archetypes :)

[Bj?rn N?ss] I partly agree. I agree that the Templates would adapt archetypes 
to a given use-case and as part of that constraint units. 

But my concern in bringing this up is the query part. I have been very lucky 
with archetypes that makes it possible to model and save the maximum dataset 
for every phenomena we meet. But then - when we are using queries, CDS, process 
support and reporting over archetyped data we need to reduce complexity where 
we can. Healthcare is a complex domain. The maximum dataset for simple 
observations like body temperature, body weight, etc. shows this. This is why I 
want to introduce this postulate to remember to keep complexity down as often 
as possible. 

Of course it is not hard to query over grams and kilos, compare them and do 
whatever we want. But the real question is why do we need to do that? 

For general archetypes that will be reused in different use-cases and different 
modules it is best to define the datastructure in a consistent way. And then 
leave it up to the user-interface to display the data in a way that fits the 
current user or user-group. 




2014-11-13 21:07 GMT+01:00 Bj?rn N?ss :
> 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.open
> ehr.org

___
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

[Ian McNicoll]

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.

@Bjorn - I am not really sure why this is such a problem.

As a modeller I would expect to remove any unwanted/unneeded units at
template level. You would there fore only be having to deal with
situations such as body weight where in your context both grams or kg
might be specified. Again as a modeller I would want to reduce this
complexity where possible but there must be clinical situation e.g
very young children where some clinicians use grams and others use kg
for exactly the same patients in exactly the same circumstances.
Creating 2 different archetypes for each unit only moves the querying
complexity elsewhere (arguably worse).

@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.

Perhaps I am missing something?


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 14 November 2014 00:07, pablo pazos  wrote:
> 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: bna at 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
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Diego Boscá]

Could assertions/rules be used for this kind of profiles?

2014-11-13 22:03 GMT+01:00 Thomas Beale :
> 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
>
> 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'
> any optional object under a container attribute, typically with other
> siblings
> 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"] = 
> ["system international"] = 
> ["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
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bakke, Silje Ljosland]

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.

Regards,
Silje 

> -Original Message-
> From: openEHR-technical [mailto:openehr-technical-
> bounces at lists.openehr.org] On Behalf Of Diego Bosc?
> Sent: Thursday, November 13, 2014 9:23 PM
> To: For openEHR technical discussions
> Cc: openehr-clinical at lists.openehr.org
> Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest
> possible units
> 
> As mentioned on twitter, I agree with that postulate for templates, but not
> general archetypes :)
> 
> 2014-11-13 21:07 GMT+01:00 Bj?rn N?ss :
> > 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.open
> > ehr.org
> 
> ___
> 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

[Diego Boscá]

As mentioned on twitter, I agree with that postulate for templates,
but not general archetypes :)

2014-11-13 21:07 GMT+01:00 Bj?rn N?ss :
> 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

Postulate: DV_QUANTITY should be modelled with fewest possible units

[pablo pazos]

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>

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Thomas Beale]

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"] = 
 ["system international"] = 
 ["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: 

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bjørn Næss]

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

-- next part --
An HTML attachment was scrubbed...
URL: