RE: openEHR-technical Digest, Vol 51, Issue 26

[William Goossen]

It does include VERY much more than mg or number of tablets. I.a units like in 
insulin, drops like in a piper, percentage of working substances in herbs and 
MANY more.

Unfortunately you have to study it yourself 😩 

Met vriendelijke groet / With kind regards, 

 
dr. William T.F. Goossen


directeur Results 4 Care B.V.
De Stinse 15
3823 VM Amersfoort
the Netherlands

telefoon +31654614458

e-mail: wgoos...@results4care.nl
dcmhelpd...@results4care.eu
skype: williamgoossenmobiel
kamer van koophandel 32133713
http://www.results4care.nl 
http://www.results4care.eu 
http://results4care.wikispaces.com/
http://www.linkedin.com/company/711047
http://results4care.wikispaces.com/3.+Cursussen+Nederlands

-Oorspronkelijk bericht-
Van: "openehr-technical-requ...@lists.openehr.org" 

Verzonden: ‎19-‎5-‎2016 18:00
Aan: "openehr-technical@lists.openehr.org" 
Onderwerp: openEHR-technical Digest, Vol 51, Issue 26

Send openEHR-technical mailing list submissions to
openehr-technical@lists.openehr.org

To subscribe or unsubscribe via the World Wide Web, visit

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

or, via email, send a message with subject or body 'help' to
openehr-technical-requ...@lists.openehr.org

You can reach the person managing the list at
openehr-technical-ow...@lists.openehr.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openEHR-technical digest..."


Today's Topics:

   1. Re: openEHR-technical Digest, Vol 51, Issue 24 (Thomas Beale)
   2. Re: openEHR draft Expression spec (Pieter Bos)


--

Message: 1
Date: Thu, 19 May 2016 14:25:22 +0100
From: Thomas Beale 
To: openehr-technical@lists.openehr.org
Subject: Re: openEHR-technical Digest, Vol 51, Issue 24
Message-ID: <79d309d2-5aae-57c0-41fa-e66ecb466...@openehr.org>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

William,

I think the question is /how/ they use UCUM. If it's just a question of 
expressing '5 mg', that works out of the box. I would imagine that here 
you are talking about the manufactured dose of one tablet / capsule / 
etc, i.e. the manufacturer's point of view (what's printed on the box).

But do they say how to use UCUM for things like '3 x 5mg tablets' as a 
dose? I imagine not, since that's the clinician/physician point of view 
- where 'dose' means what's given to the patient, not the amount of a 
drug in a given units of the product ...

- thomas


On 19/05/2016 14:07, William Goossen wrote:
> Dear All,
>
> The international pharmacy stakeholers, in particular EMA, FDA, 
> Canada, Japan, Australia have decided that All medicines units shall 
> be expressed in UCUM according ISO IDMP, in particular
> EN ISO 11240, Health informatics ? Identification of medicinal 
> products ? Data elements and structures for the unique identification 
> and exchange of units of measurement.
>
> Even if you would use some Snomed for this internal in a system you 
> will need to map e.g. for decision support that are defined based on 
> IDMP standards, medicinal product dictionaries that provide the 
> medicinal products and details, ICSR reporting, cross border 
> exchanges, logistics, insurance reimbursements and many more.
>
> Recommendations can only be to adjust to the UCUM, or if you find 
> something awkward to adjust UCUM via the open community.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20160519/096d77d0/attachment-0001.html>

--

Message: 2
Date: Thu, 19 May 2016 15:20:24 +
From: Pieter Bos 
To: "openehr-technical@lists.openehr.org"

Subject: Re: openEHR draft Expression spec
Message-ID: <04c839e9-2867-453d-8212-f18d9664d...@nedap.com>
Content-Type: text/plain; charset="utf-8"

Hello Thomas,

I had already noticed the expressions part and based my experimental 
implementation on that. This email got quite long, so let?s start with a 
summary:

Summary:
- The current spec is quite similar to XPath. We can keep this even closer by 
referencing to the XPath specification in our specification in more places. It 
allows for tool reuse and resolves ambiguities in the specification.
- Some other problems/questions where found regarding to the spec, including 
grammar ambiguities and how to handle them and a question about node-ids that 
exist in the AOM, but not alway in the RM.

I have not implemented the full expression language yet, so I might find more, 
for example when I implement functions.

XPath and the relation to the expressions language:

Before i note my issues, I wo

Re: openEHR draft Expression spec

[Pieter Bos]

Hello Thomas,

I had already noticed the expressions part and based my experimental 
implementation on that. This email got quite long, so let’s start with a 
summary:

Summary:
- The current spec is quite similar to XPath. We can keep this even closer by 
referencing to the XPath specification in our specification in more places. It 
allows for tool reuse and resolves ambiguities in the specification.
- Some other problems/questions where found regarding to the spec, including 
grammar ambiguities and how to handle them and a question about node-ids that 
exist in the AOM, but not alway in the RM.

I have not implemented the full expression language yet, so I might find more, 
for example when I implement functions.

XPath and the relation to the expressions language:

Before i note my issues, I would like to point out I noticed the language is 
very similar to XPath. In fact, you can convert almost all of the expressions 
language to valid XPath 2.0-expressions with some simple steps:

  1.  Split into separate statements. For every statement:
  2.  Replace Apath shorthand notation with xpath: [id1] to [@archetype_node_id 
= ‘id1’], etc.
  3.  Replace symbolic form of operators with the textual form
  4.  Replace for_all … In … … with ‘every $var in /path satisfies …’
  5.  Replaces implies with ‘if … then …’
  6.  Replace exists(expression) with  count(expression) > 0

Then, get an Xpath implementation that works on your reference model, or just 
convert to XML first. Then for every assertion, evaluate the expression to a 
boolean. For every variable declaration, evaluate the expression to the type 
given in the variable declaration and store it under the given name.
Then implement the standard functions and variables. Functions and variables 
are part of standard Xpath, and so is defining your own.

If you do this, you just implemented full assertion support with very little 
effort and code, and very little chance of mistakes!

(If all you have is xpath 1, the for all and implies require manual handling. 
You might need to do a bit of extra work for some datatypes, especially 
terminology codes)

Having noticed this, i’m strongly in favour of keeping the syntax as close to 
Xpath as possible. This means we can reuse tools. Or, if you have reasons to 
write your own (I do, unfortunately), at least you can validate your 
implementations easily by testing against a known implementation.

So I would argue strongly in favour of keeping the $var syntax, because it is 
the same as the xpath-standard.

Some constructions in the expressions have a valid reason why they are 
different than Xpath, for example, the shorthand notation for archetype node 
ids really helps. I would say this could include the exists operator, because 
it expresses something that is often needed and expressing it explicitly allows 
for some really nice features in user interfaces.

However, I think this does not apply to the for_all and implies statements. If 
they could be replaced with the corresponding Xpath-syntax, I would think that 
is a good idea.

Problems in the specification

Here the problems I found in the spec so far:

Multiple-valued paths and type conversion:

  *   The spec does not say how to handle multiple-valued expressions, outside 
for_all statements. We could just follow the xpath-standard
  *   The spec says nothing about type conversion. We could just follow the 
xpath-standard.

Whitespace aware grammar

The current definition of the language needs a whitespace aware grammar. If 
not, the following is ambiguous:

$var:Integer ::= /path/to/value
/path/to/another/value > 3

Because there is no way to see which part of 
/path/to/value/path/to/another/value belongs to the first or second statement 
without considering whitespace in your parser. And that’s fine in a lexer, but 
harder to do in a parser – although still possible. Alternatively, it’s easily 
solved by demarcating your assertions, for example by requiring a ‘;’ after 
every assertion

The same problem happens in a second place:

for_all $var in /path /some/other/path > $var/subpath

This is actually even a bit hard to read for a human, because the space after 
/path is easily overlooked. Both the whitespace-awareness and the human 
readability could be easily solved by replacing for_all with the every .. In … 
satisfies syntax of xpath.

Node ids in archetype/reference model objects

In archetypes, some nodes have node ids, that have no node id in the 
corresponding reference model object. This is tricky, because a valid path to 
an archetype node, converted to Xpath, is NOT a valid path to the corresponding 
reference model objects. For example, the context attribute of a Composition is 
an EVENT_CONTEXT. This does not have an archetype node id. But it always has 
one in the ADL/AOM. So if you write the path /context[id2], you can convert it 
to Xpath as /composition/context[@archetype_node_id = ‘id2’]. But this will 
result in an empty node set, be

Re: openEHR-technical Digest, Vol 51, Issue 24

[Thomas Beale]

William,

I think the question is /how/ they use UCUM. If it's just a question of 
expressing '5 mg', that works out of the box. I would imagine that here 
you are talking about the manufactured dose of one tablet / capsule / 
etc, i.e. the manufacturer's point of view (what's printed on the box).


But do they say how to use UCUM for things like '3 x 5mg tablets' as a 
dose? I imagine not, since that's the clinician/physician point of view 
- where 'dose' means what's given to the patient, not the amount of a 
drug in a given units of the product ...


- thomas


On 19/05/2016 14:07, William Goossen wrote:

Dear All,

The international pharmacy stakeholers, in particular EMA, FDA, 
Canada, Japan, Australia have decided that All medicines units shall 
be expressed in UCUM according ISO IDMP, in particular
EN ISO 11240, Health informatics — Identification of medicinal 
products — Data elements and structures for the unique identification 
and exchange of units of measurement.


Even if you would use some Snomed for this internal in a system you 
will need to map e.g. for decision support that are defined based on 
IDMP standards, medicinal product dictionaries that provide the 
medicinal products and details, ICSR reporting, cross border 
exchanges, logistics, insurance reimbursements and many more.


Recommendations can only be to adjust to the UCUM, or if you find 
something awkward to adjust UCUM via the open community.


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: openEHR-technical Digest, Vol 51, Issue 24

[William Goossen]

load]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 19 May 2016 at 08:24, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

Hi Gerard,

they actually could be, but whenever this discussion comes up, no-one proposes 
it. I'm not sure if I would either, because these arbitrary units are still not 
computable in general, but 'dose units' can be made computable but only with 
some extra data fields, i.e. you need both the quantity of dose in 1 
tablet/capsule etc, and also number of tablet/capsule etc. So the structural 
model is different anyway.

I think the other problem with using UCUM arbitrary units is that people / orgs 
want to control the names of medicinal delivery products ('tablet' etc) in a 
terminology, which is reasonable, but doesn't fit so well with UCUM.

- thomas

On 19/05/2016 08:11, "Gerard Freriks (priv?)" wrote:
Thomas,

All are Units of a different kind.

SI defines: Units of Measure, and Units of Quantity in the scientific domain.

There are also Units of Time: minute, hour, etc.

When I think of tablets, capsule, etc. we will call these Units of Medicinal 
Product Dose.
Isn?t in UCUM this an example of Arbitrary Units?
3.2

ARBITRARY UNITS


?24 arbitrary units   ?1 Arbitrary or procedure defined units are units 
whose meaning entirely depends on the measurement procedure (assay). These 
units have no general meaning in relation with any other unit in the SI. 
Therefore those arbitrary semantic entities are called arbitrary units, as 
opposed to proper units. The set of arbitrary units is denoted A, where A? U = 
{}.   ?2 An arbitrary unit has no further definition in the semantic framework 
of The Unified Code for Units of Measure  ?3 Arbitrary units are not ?of any 
specific dimension? and are not ?commensurable with? any other unit.

Until version 1.6 The Unified Code for Units of Measure has dealt with 
arbitrary units as dimensionless, but as an effect the semantics of The Unified 
Code for Units of Measure made all arbitrary units commensurable. Since version 
1.7 of The Unified Code for Units of Measure it is no longer possible to 
convert or compare arbitrary units with any other arbitrary unit.

?25 operations on arbitrary units   ?1 Any term involving arbitrary units, 
is itself an arbitrary unit and is not comparable with any other arbitrary unit 
or term.

?26 definition of arbitrary units   ?1 Arbitrary units are marked in the 
definition tables for unit atoms by a bullet (???) in the column titled ?value? 
and a bullet in the column titled ?definition?.


Gerard Freriks
+31 620347088
gf...@luna.nl<mailto:gf...@luna.nl>


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@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/20160519/3fb8a8ab/attachment.html>

--

Subject: Digest Footer

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--

End of openEHR-technical Digest, Vol 51, Issue 24
*
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR draft Expression spec

[Thomas Beale]

Pieter,

With respect to the 'rules' bit of ADL, and also GDL, there is a new 
draft 'Expressions' spec in the BASE component 
. This is a 
working draft, and partly lifted from ADL/AOMs specs (those now just 
include this one), plus some extensions to show how rule extensions are 
done properly.


This spec proposes an improved syntax, but it's definitely not finished 
(e.g. I am thinking of getting rid of the $var style syntax), and it 
would be great to have some other collaborators on it who have a lot of 
experience with expressions / rules systems. So please have a look and 
feel free to comment - comments here probably make sense since others 
may be interested.


The draft of this spec will be released soon in a new release of the 
BASE component. All that means is that changes from then need to be 
documented by PRs and CRs in the normal fashion.


- thomas

On 19/05/2016 13:01, Pieter Bos wrote:

It certainly does validate specs. In fact, it already has caused some 
corrections to both the specs and the ANTLR-grammar.

And we already found a few more issues in the specs. I’ll soon file an issue 
report about the rules section, to specify how to handle operators on 
multiple-valued path expressions without a for_all :)

Pieter

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Sebastian Garde 
mailto:sebastian.ga...@oceaninformatics.com>>
Reply-To: "openehr-technical@lists.openehr.org" 
mailto:openehr-technical@lists.openehr.org>>
Date: Wednesday 18 May 2016 at 18:31
To: "openehr-technical@lists.openehr.org" 
mailto:openehr-technical@lists.openehr.org>>
Subject: AW: Archie version 0.1.0 released



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AW: Archie version 0.1.0 released

[Pieter Bos]

It certainly does validate specs. In fact, it already has caused some 
corrections to both the specs and the ANTLR-grammar.

And we already found a few more issues in the specs. I’ll soon file an issue 
report about the rules section, to specify how to handle operators on 
multiple-valued path expressions without a for_all :)

Pieter

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Sebastian Garde 
mailto:sebastian.ga...@oceaninformatics.com>>
Reply-To: 
"openehr-technical@lists.openehr.org"
 
mailto:openehr-technical@lists.openehr.org>>
Date: Wednesday 18 May 2016 at 18:31
To: 
"openehr-technical@lists.openehr.org"
 
mailto:openehr-technical@lists.openehr.org>>
Subject: AW: Archie version 0.1.0 released

My congratulations too, Pieter!

To add to Thomas, a perfectly redundant wheel-reinvention based on the specs 
also validates the specs nicely and highlights potential 
problems/inaccuracies/underspecified things in the underlying specs as we have 
seen previously with the various 1.4 implementations.
(Yes, even with the nearly perfect openEHR specs ;-) )

Sebastian

Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Thomas Beale
Gesendet: Mittwoch, 18. Mai 2016 17:24
An: 
openehr-technical@lists.openehr.org
Betreff: Re: Archie version 0.1.0 released


I'm sure something can be worked out. Not my call personally of course.

But just a thought for everyone who instantly thinks 'oh no, not another wheel 
re-invention'... the work described here probably is slightly re-inventing 
something, but as Pieter has said, there are overlaps and also unique elements 
to each library.
Anyway, my thought is this: even a perfectly redundant wheel-reinvention 
exercise does achieve one very useful thing: it creates a new dev team that 
understands the specification and model intimately, and knows how to code with 
it - in other words we are growing the developer community. This is very 
valuable.

- thomas
On 18/05/2016 10:49, Pieter Bos wrote:

Hello Diego,



That is possibly, but has some complications:



To make a dual licensing approach work in this case it would requires us to 
release Archie under the AGPL, combine it with adl2-core and get a license from 
Marand to use their contributions to the resulting library in our products 
combined with a license from us to them to use our contributions in their 
products. Also all future contributors will have to sign a document allowing to 
use their contribution to be released under a different license by Marand and 
Nedap.



That would leave the resulting combined library still unusable for other 
non-GPL projects by others.



I would prefer another way forward :)



Regards,



Pieter Bos







On 18/05/16 11:10, "openEHR-technical on behalf of Diego Boscá" 

 wrote:



Nice wok Piter!



I've seen quite a lot of open source projects with dual licensing.

Maybe this is the way to go so we can please everyone



Regards



2016-05-18 11:06 GMT+02:00 Pieter Bos 
:

Hi Ian,



Good to hear this work is being appreciated.



It could certainly be possible to merge Archie with the existing adl2-core 
library. I think the adl2-core library looks like it has good quality code and 
decent API. It could be interesting because although there is quite a bit of 
overlap in functionality, Archie has functionality that adl2-core does not 
have, and adl2-core has functionality Archie does not yet have. If the owners 
of that library are willing to relicense their code or at least parts of their 
code under a different license, it could be interesting. We’re open to 
releasing this code under a different license, but only if the resulting work 
can be used in non-GPL software.



Regards,



Pieter Bos

Nedap Healthcare



From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Ian McNicoll 
mailto:i...@freshehr.com>>

Reply-To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>

Date: Wednesday 18 May 2016 at 10:42

To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>

Cc: 
"openehr-implement...@lists.openehr.org"
 
mailto:openehr-implement...@lists.openehr.org>

RE: UCUM code in body temperature archetype

[Koray Atalag]

Hi Ian,

In NZ we use the NZMT which is based on AMT (which is 
based on dm+d) – the tricky bit is neither of these are part of the SNOMED CT 
proper in terms of content but they do use SCTIDs and have formal IHTSDO 
namespace as national extensions. Based on the NZMT we have a 
Formulary which are all provided through 
the NZULM service. I really think is this the right way 
to go with medicines although there’s quite a bit of discomfort (among health 
informaticians / developer community) with the constraints the SNOMED CT way of 
representation brings (the 7-Boxes) and the fact that content is not harmonised 
with international edition so comparative studies can be done across different 
jurisdictions. There is also belief an SPARQL based access (at least as an 
alternative) to medicines terminology would be a better way. My 2 cents

I’d support adding the means to manage medicinal units (called units of use) at 
RM level (e.g. as a separate data type).

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Thursday, 19 May 2016 8:09 p.m.
To: For openEHR technical discussions
Subject: Re: UCUM code in body temperature archetype

Hi Thomas,

In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for dose 
units because the latter are expressed as SNOMED terms, and are used in 
conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to compute 
actual doses/amounts where possible.

e.g.

318421004 | Atenolol 100mg tablets |

via dm+d allows us to infer that 1 tab (in this case) = 100mg

http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004&toc=nofloat


and allows us to do maximum daily dose calculation, at least against a defined 
subset of such 'dose units'.

in other cases the dose unit strength will be defined as part of the medication 
order - we have a 'Strength' element in the medication order archetype for just 
such a purpose.

I don't think we need to be able to define the unit strength as part of the 
quantity datatype.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 19 May 2016 at 08:24, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

Hi Gerard,

they actually could be, but whenever this discussion comes up, no-one proposes 
it. I'm not sure if I would either, because these arbitrary units are still not 
computable in general, but 'dose units' can be made computable but only with 
some extra data fields, i.e. you need both the quantity of dose in 1 
tablet/capsule etc, and also number of tablet/capsule etc. So the structural 
model is different anyway.

I think the other problem with using UCUM arbitrary units is that people / orgs 
want to control the names of medicinal delivery products ('tablet' etc) in a 
terminology, which is reasonable, but doesn't fit so well with UCUM.

- thomas

On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
Thomas,

All are Units of a different kind.

SI defines: Units of Measure, and Units of Quantity in the scientific domain.

There are also Units of Time: minute, hour, etc.

When I think of tablets, capsule, etc. we will call these Units of Medicinal 
Product Dose.
Isn’t in UCUM this an example of Arbitrary Units?
3.2

ARBITRARY UNITS


§24 arbitrary units   ■1 Arbitrary or procedure defined units are units 
whose meaning entirely depends on the measurement procedure (assay). These 
units have no general meaning in relation with any other unit in the SI. 
Therefore those arbitrary semantic entities are called arbitrary units, as 
opposed to proper units. The set of arbitrary units is denoted A, where A∩ U = 
{}.   ■2 An arbitrary unit has no further definition in the semantic framework 
of The Unified Code for Units of Measure  ■3 Arbitrary units are not “of any 
specific dimension” and are not “commensurable with” any other unit.

Until version 1.6 The Unified Code for Units of Measure has dealt with 
arbitrary units as dimensionless, but as an effect the semantics of The Unified 
Code for Units of Measure made all arbitrary units commensurable. Since version 
1.7 of The Unified Code for Units of Measure it is no longer possible to 
convert or compare arbitrary units with any other arbitrary unit.

§25 operations on arbitrary units   ■1 Any term involving arbitrary units, 
is itself an arbitrary unit and is not comparable with any other arbitrary unit 
or term.

§26 definition of arbitrary units   ■1 Arbitrary units are marked in the 
definition tables for unit

Re: UCUM code in body temperature archetype

[Colin Sutton]

I agree with Thomas. Speaking as someone who has had to help with quality 
control of large amounts of user entered concomitant medication data for 
clinical trials, ‘tablet’ , ‘capsule’, and similar are not ‘units’ unless they 
are associated with other reference data.
 ‘Tablet' is a description of the appearance of the medication, which is not 
useful in the context of dose units.
 ’Tablet’ may be useful as a discriminant between different proprietary 
products, if you have more details (e.g. the product name) and a database which 
has the dose units of the product variations.

Colin Sutton
I.T. Systems Development Manager
NHMRC Clinical Trials Centre

On 19 May 2016, at 5:24 PM, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:


Hi Gerard,

they actually could be, but whenever this discussion comes up, no-one proposes 
it. I'm not sure if I would either, because these arbitrary units are still not 
computable in general, but 'dose units' can be made computable but only with 
some extra data fields, i.e. you need both the quantity of dose in 1 
tablet/capsule etc, and also number of tablet/capsule etc. So the structural 
model is different anyway.

I think the other problem with using UCUM arbitrary units is that people / orgs 
want to control the names of medicinal delivery products ('tablet' etc) in a 
terminology, which is reasonable, but doesn't fit so well with UCUM.

- thomas

On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
Thomas,

All are Units of a different kind.

SI defines: Units of Measure, and Units of Quantity in the scientific domain.

There are also Units of Time: minute, hour, etc.

When I think of tablets, capsule, etc. we will call these Units of Medicinal 
Product Dose.
Isn’t in UCUM this an example of Arbitrary Units?
3.2

ARBITRARY UNITS


§24 arbitrary units   ■1 Arbitrary or procedure defined units are units 
whose meaning entirely depends on the measurement procedure (assay). These 
units have no general meaning in relation with any other unit in the SI. 
Therefore those arbitrary semantic entities are called arbitrary units, as 
opposed to proper units. The set of arbitrary units is denoted A, where A∩ U = 
{}.   ■2 An arbitrary unit has no further definition in the semantic framework 
of The Unified Code for Units of Measure  ■3 Arbitrary units are not “of any 
specific dimension” and are not “commensurable with” any other unit.

Until version 1.6 The Unified Code for Units of Measure has dealt with 
arbitrary units as dimensionless, but as an effect the semantics of The Unified 
Code for Units of Measure made all arbitrary units commensurable. Since version 
1.7 of The Unified Code for Units of Measure it is no longer possible to 
convert or compare arbitrary units with any other arbitrary unit.

§25 operations on arbitrary units   ■1 Any term involving arbitrary units, 
is itself an arbitrary unit and is not comparable with any other arbitrary unit 
or term.

§26 definition of arbitrary units   ■1 Arbitrary units are marked in the 
definition tables for unit atoms by a bullet (‘•’) in the column titled “value” 
and a bullet in the column titled “definition”.


Gerard Freriks
+31 620347088
gf...@luna.nl

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://scanmail.trustwave.com/?c=1688&d=nuq91wXdsw3fdrcy_RKYOroV-0psr7BFxYHw4b5Mdg&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-technical%5flists%2eopenehr%2eorg


#
Scanned by MailMarshal - M86 Security's comprehensive email content security 
solution. 
#


IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be 
read or used by the named addressee. It is confidential and may contain legally 
privileged information. No confidentiality or privilege is waived or lost by 
any mistaken transmission to you. The CTC is not responsible for any 
unauthorised alterations to this e-mail or attachment to it. Views expressed in 
this message are those of the individual sender, and are not necessarily the 
views of the CTC. If you receive this e-mail in error, please immediately 
delete it and notify the sender. You must not disclose, copy or use any part of 
this e-mail if you are not the intended recipient.

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Thomas Beale]

On 19/05/2016 08:26, Ian McNicoll wrote:

Hi Thomas,

I appreciate that the Quantity classes add computability such as the 
+,-,=, diff operators etc but computability (or at least safe/sensible 
computability) is not a given even when the two operands share the 
same unit.


it might not be clinically, but it always is in terms of quantities - 
that's the whole point of the system of physical quantities. It's not up 
to the DvQuantity (or any similar) type to know the clinical semantics 
at hand; the way it has to work is that a higher level clinical context 
in an application knows what Quantities are clinically comparable, when 
it does, it's a /guarantee /that two DvQuantity instances of the same 
unit (say 'g') are addable, subtractable and can be multiplied by a scalar.


This is the point of having a simple Quantity type in the system - just 
to do this job.


Nor does the fact that a unit is non-scientific invalidate the use of 
those operators in many cases e.g 1 tab + 1 tab = 2 tabs. Of course 
there are situations where to do so would be unsafe and not sensible 
but that also applies to cases where SI units are being used.


in this case you simply can't know, not even if you know that both 
'tablet' quantities are for Aspirin. You have to at least know what the 
tablet size is. This can be known, and the semantics can be known, but 
not from a basic Quantity type; we need something more.


A very basic rule in IT and modelling is to build things additively, 
using a new abstraction for each new complication. The alternative of 
trying to jam all possible use cases into a single type or abstraction 
always leads to something unwieldy, unclear and guaranteed to create 
bugs in processing and data. That's the reason we don't try to make the 
type 'Integer' do more than a simple integer can do.


Similarly, I would argue that the basic 'Quantity' type in a set of data 
types for science / biomedical computing should just do its basic job - 
representing quantities with units, accuracy, and precision. (We already 
violate this somewhat in openEHR by including reference ranges, but at 
least that remains perfectly computable.)


When we get to the scenario of quantities of drugs delivered in 
quantised dose objects such as tablets etc, we are at another level of 
sophistication. It doesn't make sense to change the Quantity data type 
to do a more complicated job; if we do that, we have no Quantity type 
that just implements standard scientific quantities.


Adding a new smart type, say DoseQuantity, is easy enough. Or else we 
relegate the more complex information needed for drug information to 
archetype data points as we do now. Trying to hack an existing type to 
do a job it is not designed to do is a bad idea.


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Diego Boscá]

Here in Spain there is an official terminology for medication dispensation.
It is partially mapped to snomed (and the remaining ones will be part of
snomed national extension)
In my opinion, it makes perfect sense to allow the specification of 'units'
from other (non-ucum) terminologies, such as snomed or even the national
ones

2016-05-19 10:19 GMT+02:00 "Gerard Freriks (privé)" :

> An alternative for dealing with semantic in archetypes is dealing with
> semantics in coding systems like SNOMED.
>
> The consequence is that SNOMED must be a complete Medicinal Product
> Formulary.
> I have doubts whether this is a good idea.
>
> Many countries have different specific formularies.
> I like to reserve SNOMED-CT to use as any dictionary with universal
> lemma’s, concepts.
> Each country will have its own maintained Formulary.
> A formulary that changes because of the marketing whims of pharmaceutical
> companies.
>
>
> Gerard Freriks
> +31 620347088
> gf...@luna.nl
>
> On 19 mei 2016, at 10:09, Ian McNicoll  wrote:
>
> Hi Thomas,
>
> In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for
> dose units because the latter are expressed as SNOMED terms, and are used
> in conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to
> compute actual doses/amounts where possible.
>
> e.g.
>
> 318421004 | Atenolol 100mg tablets |
>
> via dm+d allows us to infer that 1 tab (in this case) = 100mg
>
> http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004&toc=nofloat
>
> and allows us to do maximum daily dose calculation, at least against a
> defined subset of such 'dose units'.
>
> in other cases the dose unit strength will be defined as part of the
> medication order - we have a 'Strength' element in the medication order
> archetype for just such a purpose.
>
> I don't think we need to be able to define the unit strength as part of
> the quantity datatype.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 19 May 2016 at 08:24, Thomas Beale  wrote:
>
>> Hi Gerard,
>>
>> they actually could be, but whenever this discussion comes up, no-one
>> proposes it. I'm not sure if I would either, because these arbitrary units
>> are still not computable in general, but 'dose units' can be made
>> computable but only with some extra data fields, i.e. you need both the
>> quantity of dose in 1 tablet/capsule etc, and also number of tablet/capsule
>> etc. So the structural model is different anyway.
>>
>> I think the other problem with using UCUM arbitrary units is that people
>> / orgs want to control the names of medicinal delivery products ('tablet'
>> etc) in a terminology, which is reasonable, but doesn't fit so well with
>> UCUM.
>>
>> - thomas
>>
>> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>>
>> Thomas,
>>
>> All are Units of a different kind.
>>
>> SI defines: Units of Measure, and Units of Quantity in the scientific
>> domain.
>>
>> There are also Units of Time: minute, hour, etc.
>>
>> When I think of tablets, capsule, etc. we will call these Units of
>> Medicinal Product Dose.
>> Isn’t in UCUM this an example of Arbitrary Units?
>> 3.2  ARBITRARY UNITS
>>
>> *§24 arbitrary units*  * ■1* Arbitrary or procedure defined units
>> are units whose meaning entirely depends on the measurement procedure
>> (assay). These units have no general meaning in relation with any other
>> unit in the SI. Therefore those arbitrary semantic entities are called 
>> *arbitrary
>> units*, as opposed to *proper units*. The set of arbitrary units is
>> denoted *A*, where *A*∩ *U* = {}.  * ■2* An arbitrary unit has no
>> further definition in the semantic framework of *The Unified Code for
>> Units of Measure* * ■3* Arbitrary units are not “of any specific
>> dimension” and are not “commensurable with” any other unit.
>>
>> Until version 1.6 *The Unified Code for Units of Measure* has dealt with
>> arbitrary units as dimensionless, but as an effect the semantics of *The
>> Unified Code for Units of Measure* made all arbitrary units
>> commensurable. Since version 1.7 of *The Unified Code for Units of
>> Measure* it is no longer possible to convert or compare arbitrary units
>> with any other arbitrary unit.
>>
>> *§25 operations on arbitrary units*  * ■1* Any term involving
>> arbitrary units, is itself an arbitrary unit and is not comparable with any
>> other arbitrary unit or term.
>>
>> *§26 definition of arbitrary units*  * ■1* Arbitrary units are
>> marked in the definition tables for unit atoms by a bullet (‘•’) in the
>> column titled “value” and a bullet in the column titled “definition”.
>>
>>
>> Gerard Freriks
>> +31 620347088
>> gf...@luna.nl
>>
>>
>>
>> _

Re: UCUM code in body temperature archetype

[Ian McNicoll]

Hi Gerard,

"The consequence is that SNOMED must be a complete Medicinal Product
Formulary.
I have doubts whether this is a good idea.'

dm+d is a UK health-service managed dictionary based on SNOMED CT and using
the UK national namespace i.e. it is not managed internationally.
It is a complete Product formulary/dictionary but only for UK. I understand
that Aus and New Zealand have very similar approaches.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 19 May 2016 at 09:19, "Gerard Freriks (privé)"  wrote:

> An alternative for dealing with semantic in archetypes is dealing with
> semantics in coding systems like SNOMED.
>
> The consequence is that SNOMED must be a complete Medicinal Product
> Formulary.
> I have doubts whether this is a good idea.
>
> Many countries have different specific formularies.
> I like to reserve SNOMED-CT to use as any dictionary with universal
> lemma’s, concepts.
> Each country will have its own maintained Formulary.
> A formulary that changes because of the marketing whims of pharmaceutical
> companies.
>
>
> Gerard Freriks
> +31 620347088
> gf...@luna.nl
>
> On 19 mei 2016, at 10:09, Ian McNicoll  wrote:
>
> Hi Thomas,
>
> In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for
> dose units because the latter are expressed as SNOMED terms, and are used
> in conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to
> compute actual doses/amounts where possible.
>
> e.g.
>
> 318421004 | Atenolol 100mg tablets |
>
> via dm+d allows us to infer that 1 tab (in this case) = 100mg
>
> http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004&toc=nofloat
>
> and allows us to do maximum daily dose calculation, at least against a
> defined subset of such 'dose units'.
>
> in other cases the dose unit strength will be defined as part of the
> medication order - we have a 'Strength' element in the medication order
> archetype for just such a purpose.
>
> I don't think we need to be able to define the unit strength as part of
> the quantity datatype.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 19 May 2016 at 08:24, Thomas Beale  wrote:
>
>> Hi Gerard,
>>
>> they actually could be, but whenever this discussion comes up, no-one
>> proposes it. I'm not sure if I would either, because these arbitrary units
>> are still not computable in general, but 'dose units' can be made
>> computable but only with some extra data fields, i.e. you need both the
>> quantity of dose in 1 tablet/capsule etc, and also number of tablet/capsule
>> etc. So the structural model is different anyway.
>>
>> I think the other problem with using UCUM arbitrary units is that people
>> / orgs want to control the names of medicinal delivery products ('tablet'
>> etc) in a terminology, which is reasonable, but doesn't fit so well with
>> UCUM.
>>
>> - thomas
>>
>> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>>
>> Thomas,
>>
>> All are Units of a different kind.
>>
>> SI defines: Units of Measure, and Units of Quantity in the scientific
>> domain.
>>
>> There are also Units of Time: minute, hour, etc.
>>
>> When I think of tablets, capsule, etc. we will call these Units of
>> Medicinal Product Dose.
>> Isn’t in UCUM this an example of Arbitrary Units?
>> 3.2  ARBITRARY UNITS
>>
>> *§24 arbitrary units*  * ■1* Arbitrary or procedure defined units
>> are units whose meaning entirely depends on the measurement procedure
>> (assay). These units have no general meaning in relation with any other
>> unit in the SI. Therefore those arbitrary semantic entities are called 
>> *arbitrary
>> units*, as opposed to *proper units*. The set of arbitrary units is
>> denoted *A*, where *A*∩ *U* = {}.  * ■2* An arbitrary unit has no
>> further definition in the semantic framework of *The Unified Code for
>> Units of Measure* * ■3* Arbitrary units are not “of any specific
>> dimension” and are not “commensurable with” any other unit.
>>
>> Until version 1.6 *The Unified Code for Units of Measure* has dealt with
>> arbitrary units as dimensionless, but as an effect the semantics of *The
>> Unified Code for Units of Measure* made all arbitrary units
>> commensurable. Since version 1.7 of *The Unified Code for Units of
>> Measure* it is no longer possible to convert or compare arbitrary units
>> with any other arbitrary unit.
>>
>> *§25 operations on arbitrary units*  * ■1* Any term involving
>> arbitrary units, is itself an arbitrary unit and is

Re: UCUM code in body temperature archetype

[jantal...@home.nl]

In 2012 a number of ISO standards were published on the “Identification of 
medicinal products” When I recall correctly there is one that deals with the 
representation of dose forms, units of presentation and route of 
administration. 

Jan Talmon

> On 19 mei 2016, at 10:19, Gerard Freriks (privé)  wrote:
> 
> An alternative for dealing with semantic in archetypes is dealing with 
> semantics in coding systems like SNOMED.
> 
> The consequence is that SNOMED must be a complete Medicinal Product Formulary.
> I have doubts whether this is a good idea.
> 
> Many countries have different specific formularies.
> I like to reserve SNOMED-CT to use as any dictionary with universal lemma’s, 
> concepts.
> Each country will have its own maintained Formulary.
> A formulary that changes because of the marketing whims of pharmaceutical 
> companies.
> 
> 
> Gerard Freriks
> +31 620347088
> gf...@luna.nl 
>> On 19 mei 2016, at 10:09, Ian McNicoll > > wrote:
>> 
>> Hi Thomas,
>> 
>> In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for dose 
>> units because the latter are expressed as SNOMED terms, and are used in 
>> conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to compute 
>> actual doses/amounts where possible.
>> 
>> e.g.
>> 
>> 318421004 | Atenolol 100mg tablets |
>> 
>> via dm+d allows us to infer that 1 tab (in this case) = 100mg
>> 
>> http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004&toc=nofloat 
>> 
>> 
>> and allows us to do maximum daily dose calculation, at least against a 
>> defined subset of such 'dose units'.
>> 
>> in other cases the dose unit strength will be defined as part of the 
>> medication order - we have a 'Strength' element in the medication order 
>> archetype for just such a purpose.
>> 
>> I don't think we need to be able to define the unit strength as part of the 
>> quantity datatype.
>> 
>> Ian  
>> 
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com 
>> twitter: @ianmcnicoll
>> 
>> 
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
>> 
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>> 
>> On 19 May 2016 at 08:24, Thomas Beale > > wrote:
>> Hi Gerard,
>> they actually could be, but whenever this discussion comes up, no-one 
>> proposes it. I'm not sure if I would either, because these arbitrary units 
>> are still not computable in general, but 'dose units' can be made computable 
>> but only with some extra data fields, i.e. you need both the quantity of 
>> dose in 1 tablet/capsule etc, and also number of tablet/capsule etc. So the 
>> structural model is different anyway.
>> 
>> I think the other problem with using UCUM arbitrary units is that people / 
>> orgs want to control the names of medicinal delivery products ('tablet' etc) 
>> in a terminology, which is reasonable, but doesn't fit so well with UCUM.
>> 
>> - thomas
>> 
>> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>>> Thomas,
>>> 
>>> All are Units of a different kind.
>>> 
>>> SI defines: Units of Measure, and Units of Quantity in the scientific 
>>> domain.
>>> 
>>> There are also Units of Time: minute, hour, etc.
>>> 
>>> When I think of tablets, capsule, etc. we will call these Units of 
>>> Medicinal Product Dose.
>>> Isn’t in UCUM this an example of Arbitrary Units?
>>>  <>3.2 
>>> ARBITRARY UNITS
>>>  <>§24 arbitrary units   ■1 Arbitrary or procedure defined units are 
>>> units whose meaning entirely depends on the measurement procedure (assay). 
>>> These units have no general meaning in relation with any other unit in the 
>>> SI. Therefore those arbitrary semantic entities are called arbitrary units, 
>>> as opposed to proper units. The set of arbitrary units is denoted A, where 
>>> A∩ U = {}.   ■2 An arbitrary unit has no further definition in the semantic 
>>> framework of The Unified Code for Units of Measure  ■3 Arbitrary units are 
>>> not “of any specific dimension” and are not “commensurable with” any other 
>>> unit.
>>> 
>>> Until version 1.6 The Unified Code for Units of Measure has dealt with 
>>> arbitrary units as dimensionless, but as an effect the semantics of The 
>>> Unified Code for Units of Measure made all arbitrary units commensurable. 
>>> Since version 1.7 of The Unified Code for Units of Measure it is no longer 
>>> possible to convert or compare arbitrary units with any other arbitrary 
>>> unit.
>>> 
>>>  <>§25 operations on arbitrary units   ■1 Any term involving arbitrary 
>>> units, is itself an arbitrary unit and is not comparable with any other 
>>> arbitrary unit or term.
>>> 
>>>  <>§26 definition of arbitrary units   ■1 Arbitrary units are 

Re: UCUM code in body temperature archetype

[Gerard Freriks (privé)]

An alternative for dealing with semantic in archetypes is dealing with 
semantics in coding systems like SNOMED.

The consequence is that SNOMED must be a complete Medicinal Product Formulary.
I have doubts whether this is a good idea.

Many countries have different specific formularies.
I like to reserve SNOMED-CT to use as any dictionary with universal lemma’s, 
concepts.
Each country will have its own maintained Formulary.
A formulary that changes because of the marketing whims of pharmaceutical 
companies.


Gerard Freriks
+31 620347088
gf...@luna.nl 
> On 19 mei 2016, at 10:09, Ian McNicoll  wrote:
> 
> Hi Thomas,
> 
> In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for dose 
> units because the latter are expressed as SNOMED terms, and are used in 
> conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to compute 
> actual doses/amounts where possible.
> 
> e.g.
> 
> 318421004 | Atenolol 100mg tablets |
> 
> via dm+d allows us to infer that 1 tab (in this case) = 100mg
> 
> http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004&toc=nofloat 
> 
> 
> and allows us to do maximum daily dose calculation, at least against a 
> defined subset of such 'dose units'.
> 
> in other cases the dose unit strength will be defined as part of the 
> medication order - we have a 'Strength' element in the medication order 
> archetype for just such a purpose.
> 
> I don't think we need to be able to define the unit strength as part of the 
> quantity datatype.
> 
> Ian  
> 
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com 
> twitter: @ianmcnicoll
> 
> 
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
> 
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> 
> On 19 May 2016 at 08:24, Thomas Beale  > wrote:
> Hi Gerard,
> they actually could be, but whenever this discussion comes up, no-one 
> proposes it. I'm not sure if I would either, because these arbitrary units 
> are still not computable in general, but 'dose units' can be made computable 
> but only with some extra data fields, i.e. you need both the quantity of dose 
> in 1 tablet/capsule etc, and also number of tablet/capsule etc. So the 
> structural model is different anyway.
> 
> I think the other problem with using UCUM arbitrary units is that people / 
> orgs want to control the names of medicinal delivery products ('tablet' etc) 
> in a terminology, which is reasonable, but doesn't fit so well with UCUM.
> 
> - thomas
> 
> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>> Thomas,
>> 
>> All are Units of a different kind.
>> 
>> SI defines: Units of Measure, and Units of Quantity in the scientific domain.
>> 
>> There are also Units of Time: minute, hour, etc.
>> 
>> When I think of tablets, capsule, etc. we will call these Units of Medicinal 
>> Product Dose.
>> Isn’t in UCUM this an example of Arbitrary Units?
>>  <>3.2 
>> ARBITRARY UNITS
>>  <>§24 arbitrary units   ■1 Arbitrary or procedure defined units are 
>> units whose meaning entirely depends on the measurement procedure (assay). 
>> These units have no general meaning in relation with any other unit in the 
>> SI. Therefore those arbitrary semantic entities are called arbitrary units, 
>> as opposed to proper units. The set of arbitrary units is denoted A, where 
>> A∩ U = {}.   ■2 An arbitrary unit has no further definition in the semantic 
>> framework of The Unified Code for Units of Measure  ■3 Arbitrary units are 
>> not “of any specific dimension” and are not “commensurable with” any other 
>> unit.
>> 
>> Until version 1.6 The Unified Code for Units of Measure has dealt with 
>> arbitrary units as dimensionless, but as an effect the semantics of The 
>> Unified Code for Units of Measure made all arbitrary units commensurable. 
>> Since version 1.7 of The Unified Code for Units of Measure it is no longer 
>> possible to convert or compare arbitrary units with any other arbitrary unit.
>> 
>>  <>§25 operations on arbitrary units   ■1 Any term involving arbitrary 
>> units, is itself an arbitrary unit and is not comparable with any other 
>> arbitrary unit or term.
>> 
>>  <>§26 definition of arbitrary units   ■1 Arbitrary units are marked in 
>> the definition tables for unit atoms by a bullet (‘•’) in the column titled 
>> “value” and a bullet in the column titled “definition”.
>> 
>> 
>> 
>> Gerard Freriks
>> +31 620347088 
>>  gf...@luna.nl 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> 
> http://lists.openehr.org/mailman/listinfo/ope

Re: UCUM code in body temperature archetype

[Ian McNicoll]

Hi Thomas,

In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for dose
units because the latter are expressed as SNOMED terms, and are used in
conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to compute
actual doses/amounts where possible.

e.g.

318421004 | Atenolol 100mg tablets |

via dm+d allows us to infer that 1 tab (in this case) = 100mg

http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004&toc=nofloat

and allows us to do maximum daily dose calculation, at least against a
defined subset of such 'dose units'.

in other cases the dose unit strength will be defined as part of the
medication order - we have a 'Strength' element in the medication order
archetype for just such a purpose.

I don't think we need to be able to define the unit strength as part of the
quantity datatype.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 19 May 2016 at 08:24, Thomas Beale  wrote:

> Hi Gerard,
>
> they actually could be, but whenever this discussion comes up, no-one
> proposes it. I'm not sure if I would either, because these arbitrary units
> are still not computable in general, but 'dose units' can be made
> computable but only with some extra data fields, i.e. you need both the
> quantity of dose in 1 tablet/capsule etc, and also number of tablet/capsule
> etc. So the structural model is different anyway.
>
> I think the other problem with using UCUM arbitrary units is that people /
> orgs want to control the names of medicinal delivery products ('tablet'
> etc) in a terminology, which is reasonable, but doesn't fit so well with
> UCUM.
>
> - thomas
>
> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>
> Thomas,
>
> All are Units of a different kind.
>
> SI defines: Units of Measure, and Units of Quantity in the scientific
> domain.
>
> There are also Units of Time: minute, hour, etc.
>
> When I think of tablets, capsule, etc. we will call these Units of
> Medicinal Product Dose.
> Isn’t in UCUM this an example of Arbitrary Units?
> 3.2  ARBITRARY UNITS
>
> *§24 arbitrary units*  * ■1* Arbitrary or procedure defined units are
> units whose meaning entirely depends on the measurement procedure (assay).
> These units have no general meaning in relation with any other unit in the
> SI. Therefore those arbitrary semantic entities are called *arbitrary
> units*, as opposed to *proper units*. The set of arbitrary units is
> denoted *A*, where *A*∩ *U* = {}.  * ■2* An arbitrary unit has no further
> definition in the semantic framework of *The Unified Code for Units of
> Measure* * ■3* Arbitrary units are not “of any specific dimension” and
> are not “commensurable with” any other unit.
>
> Until version 1.6 *The Unified Code for Units of Measure* has dealt with
> arbitrary units as dimensionless, but as an effect the semantics of *The
> Unified Code for Units of Measure* made all arbitrary units
> commensurable. Since version 1.7 of *The Unified Code for Units of
> Measure* it is no longer possible to convert or compare arbitrary units
> with any other arbitrary unit.
>
> *§25 operations on arbitrary units*  * ■1* Any term involving
> arbitrary units, is itself an arbitrary unit and is not comparable with any
> other arbitrary unit or term.
>
> *§26 definition of arbitrary units*  * ■1* Arbitrary units are marked
> in the definition tables for unit atoms by a bullet (‘•’) in the column
> titled “value” and a bullet in the column titled “definition”.
>
>
> Gerard Freriks
> +31 620347088
> gf...@luna.nl
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Gerard Freriks (privé)]

Two reactions:

1- There is a difference between the world of semantic interpretability in 
system interfaces and the real word of users looking at screens, and typing on 
keyboards
In one world we can/must use as much as possible SI units via UCUM and strife 
for as detailed as possible reducing misinterpretation.
In the real world users want to have data presented in many shapes and forms.
Accommodating the end-users is the task of the industry.
It is the task of health informaticians to reduce misinterpretations.

At the Template/Interface level we need facilities to annotate as much as 
possible that what is expressed/modelled.
And why not have in the annotations, the printable, the human readable, the 
personal choice, the local choice.

2- When it comes to the Arbitrary UCUM Units.
The question is how much semantic we carry in data types.
And how much semantics we carry in archetypes.
I opt for the latter.
Data types should be as primitive as possible.

I use the UCUM Arbitrary ‘Unit’ and use the structure in the Archetype to 
provide the semantics that describe the Unit.


Gerard Freriks
+31 620347088
gf...@luna.nl 
> On 19 mei 2016, at 09:24, Thomas Beale  wrote:
> 
> Hi Gerard,
> 
> they actually could be, but whenever this discussion comes up, no-one 
> proposes it. I'm not sure if I would either, because these arbitrary units 
> are still not computable in general, but 'dose units' can be made computable 
> but only with some extra data fields, i.e. you need both the quantity of dose 
> in 1 tablet/capsule etc, and also number of tablet/capsule etc. So the 
> structural model is different anyway.
> 
> I think the other problem with using UCUM arbitrary units is that people / 
> orgs want to control the names of medicinal delivery products ('tablet' etc) 
> in a terminology, which is reasonable, but doesn't fit so well with UCUM.
> 
> - thomas
> 
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Ian McNicoll]

Hi Thomas,

I appreciate that the Quantity classes add computability such as the +,-,=,
diff operators etc but computability (or at least safe/sensible
computability) is not a given even when the two operands share the same
unit. Nor does the fact that a unit is non-scientific invalidate the use of
those operators in many cases e.g 1 tab + 1 tab = 2 tabs. Of course there
are situations where to do so would be unsafe and not sensible but that
also applies to cases where SI units are being used.

In other words the safe and sensible use of the operators is always going
to be constrained by the circumstances of use, of which the use of SI units
or not, is only one factor that needs to be considered.

We need to solve the UCUM displayname/code issue anyway. We need to allow
different code systems e.g. SNOMED CT, we need to support dose units/ pack
units etc. Adding termcode and terminology solves that problem in a way
which prevents avoids change, avoids introducing another flavour of
quantity (more stuff for people to learn), and makes modelling of the key
area of medication much cleaner.

I would be really keen to hear from other openEHR implementers on this. If
operators are being heavily used and the suggested change would compromise
computability or ease of implementation, I could be otherwise persuaded.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 18 May 2016 at 20:45, Thomas Beale  wrote:

> Grahame,
>
> I think you are saying that you can implement the *semantics *of dose
> units with just a DvQantity / FHIR Quantity. If 'dose units' includes the
> knowledge of the discrete unit of delivery, i.e. table, drop etc, as well
> as total amount, you can't. You need at least the elements here, or their
> equivalent.
>
> class DoseQuantity
> unitForm: DvCodedText // type of physical dose entity tablet,
> capsule, puff etc
> unitAmount: DvQuantity// how much is in a `doseForm` unit e.g.
> 5mg
> doseCount: Integer// how many items of `doseForm` to
> deliver
>
> doseAmount: DvQuantity {  // total amount of substance delivered
> to patient
> Result := doseCount * unitAmount
> }
> end
>
> If on the other hand you are saying we just go the pseudo-units route,
> where 'tablet' is a kind of unit, we can, but the Quantity library won't
> work properly anymore, because you no longer know if you can add two
> quantities even if they have the same unit, because 'tablet' as a unit
> doesn't mean anything. Where I am coming from is: Quantity is not just
> data, it is operations and computing
> ;
> it includes operators like:
>
>- DV_AMOUNT: =, +, -, *, etc
>- DV_ABSOLUTE_QUANTITY: diff, add, subtract
>
> (there are many ways to model this kind of thing, that's just the openEHR
> way).
>
> If you are saying: use a code + code-system approach, and check the code
> system, and do something if UCUM, and something else if not, I've now:
>
>- got just a data-oriented Quantity type
>- a bunch of if/else code to treat different Quantity 'types'
>differently
>- I have to move the operators out to another level, because they no
>longer make sense for this new style of Quantity
>
> So, in terms of what we do in openEHR, I don't think it makes sense. In
> terms of FHIR, it makes sense; but I have to check a FHIR Quantity and
> instantiate different kinds of RM structures depending on the units code
> system.
>
> - thomas
> On 18/05/2016 17:58, Grahame Grieve wrote:
>
> Hi
>
> You missed my point. I assume that the content model will differentiate
> between ucum code and some other code, so as to enable all the behaviour
> you describe.
> But you don't need to force the use of a different element in a different
> place of the model. Merely differentiating the terminology used will
> achieve that. A processor will know when it can use ucum based logic - not
> that I've ever seen that in the real world - and it will know when it can't
>
> Eric's part of this thread notes the issues with doing with this
> implicitly, so I'm not advocating for that, which brings you back to the
> FHIR model: human units, and system + code for computable units.
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Thomas Beale]

Hi Gerard,

they actually could be, but whenever this discussion comes up, no-one 
proposes it. I'm not sure if I would either, because these arbitrary 
units are still not computable in general, but 'dose units' can be made 
computable but only with some extra data fields, i.e. you need both the 
quantity of dose in 1 tablet/capsule etc, and also number of 
tablet/capsule etc. So the structural model is different anyway.


I think the other problem with using UCUM arbitrary units is that people 
/ orgs want to control the names of medicinal delivery products 
('tablet' etc) in a terminology, which is reasonable, but doesn't fit so 
well with UCUM.


- thomas


On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:

Thomas,

All are Units of a different kind.

SI defines: Units of Measure, and Units of Quantity in the scientific 
domain.


There are also Units of Time: minute, hour, etc.

When I think of tablets, capsule, etc. we will call these Units of 
Medicinal Product Dose.

Isn’t in UCUM this an example of Arbitrary Units?


  3.2




  ARBITRARY UNITS

*§24 arbitrary units* *^ ■1 * Arbitrary or procedure defined units are 
units whose meaning entirely depends on the measurement procedure 
(assay). These units have no general meaning in relation with any 
other unit in the SI. Therefore those arbitrary semantic entities are 
called /arbitrary units/, as opposed to /proper units/. The set of 
arbitrary units is denoted /A/, where /A/∩ /U/ = {}. *^ ■2 * An 
arbitrary unit has no further definition in the semantic framework of 
/The Unified Code for Units of Measure/ *^ ■3 * Arbitrary units are 
not “of any specific dimension” and are not “commensurable with” any 
other unit.


Until version 1.6 /The Unified Code for Units of Measure/ has dealt 
with arbitrary units as dimensionless, but as an effect the semantics 
of /The Unified Code for Units of Measure/ made all arbitrary units 
commensurable. Since version 1.7 of /The Unified Code for Units of 
Measure/ it is no longer possible to convert or compare arbitrary 
units with any other arbitrary unit.


*§25 operations on arbitrary units* *^ ■1 * Any term involving 
arbitrary units, is itself an arbitrary unit and is not comparable 
with any other arbitrary unit or term.


*§26 definition of arbitrary units* *^ ■1 * Arbitrary units are marked 
in the definition tables for unit atoms by a bullet (‘•’) in the 
column titled “value” and a bullet in the column titled “definition”.




Gerard Freriks
+31 620347088
gf...@luna.nl 


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Gerard Freriks (privé)]

Thomas,

All are Units of a different kind.

SI defines: Units of Measure, and Units of Quantity in the scientific domain.

There are also Units of Time: minute, hour, etc.

When I think of tablets, capsule, etc. we will call these Units of Medicinal 
Product Dose.
Isn’t in UCUM this an example of Arbitrary Units?
 <>3.2 
ARBITRARY UNITS
 <>§24 arbitrary units   ■1 Arbitrary or procedure defined units are units 
whose meaning entirely depends on the measurement procedure (assay). These 
units have no general meaning in relation with any other unit in the SI. 
Therefore those arbitrary semantic entities are called arbitrary units, as 
opposed to proper units. The set of arbitrary units is denoted A, where A∩ U = 
{}.   ■2 An arbitrary unit has no further definition in the semantic framework 
of The Unified Code for Units of Measure  ■3 Arbitrary units are not “of any 
specific dimension” and are not “commensurable with” any other unit.

Until version 1.6 The Unified Code for Units of Measure has dealt with 
arbitrary units as dimensionless, but as an effect the semantics of The Unified 
Code for Units of Measure made all arbitrary units commensurable. Since version 
1.7 of The Unified Code for Units of Measure it is no longer possible to 
convert or compare arbitrary units with any other arbitrary unit.

 <>§25 operations on arbitrary units   ■1 Any term involving arbitrary 
units, is itself an arbitrary unit and is not comparable with any other 
arbitrary unit or term.

 <>§26 definition of arbitrary units   ■1 Arbitrary units are marked in the 
definition tables for unit atoms by a bullet (‘•’) in the column titled “value” 
and a bullet in the column titled “definition”.



Gerard Freriks
+31 620347088
gf...@luna.nl 
> On 18 mei 2016, at 13:41, Thomas Beale  wrote:
> 
> 
> On 18/05/2016 12:21, Grahame Grieve wrote:
>> The main problem is that ucum units are not human readable units,
> 
> right - my idea 13 years ago was to use the UCUM string as a key into 
> something that generated a human-readable form. For reasons that became 
> clearer since, I think we all agree that we need to embed not just the formal 
> form, but the human-readable form as well. So that's a fairly anodyne design 
> problem for the Quantity type in everyone's type system. I think we can solve 
> that in a reasonable way in openEHR.
> 
>> and trying to force them to be will generate substantial pushback from end 
>> users. In USA, this is an open problem for CDA adoption. In Australia, I 
>> solved it by declaring that we would never retire valid ucum units in CDA.
>> 
>> A secondary problem is discrete units like tablet, capsule etc which have no 
>> computable form in ucum
> 
> I suspect this is the main problem for some people at least these days. 
> Scientifically speaking, anything like 'tablet', 'capsule', 'drop' etc isn't 
> a 'unit' in the science/physics sense; but in English (and most other 
> languages I suspect) we use the same word in a non-science sense to mean 
> 'discrete amount of anything', e.g. unit shares, 5mg tablet is the unit of 
> dosing, and so on. This makes people think the problem can be solved within 
> the model / language of scientific units. It can't in any clean way.
> 
> So dose 'units' need to be understood as something different from scientific 
> units, and modelled in a different way. They are units of discretisation or 
> quantisation of material, not units of physical properties.
> 
> - thomas
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org