Re: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 27-01-18 11:16, Thomas Beale wrote:


Bert,

I don't disagree philosophically, but practically speaking, no SNOMED 
service is going to be able to answer requests to do with unit 
properties, unit conversions, or different forms of rendering, which 
are all things we need to take care of properly.


I actually think units is one of the things we should just do 
properly, and in only one way for openEHR. I can't imagine why anyone 
would use SNOMED for units instead of a proper units service that 
supported the above, even if they use SNOMED for everything else. 
There is of course nothing preventing anyone adding bindings from 
SNOMED to the units paths in archetypes.




I personally think that UCUM does a outstanding good job. One thing that 
is missing is translations, this is important in countries which have 
another script, like Arabs or Chinese or many many other. The majority 
of the world population does not use the Latin alphabet.


And this is where SNOMED comes in, it is getting translated by the 
people who use it. And I found somewhere on the internet a mapping from 
UCUM to SNOMED, and when I looked again, I coudn't find it anymore. 
SNOMED has infrastructure to take care of translations (done by the 
national standard bodies). That is one of its important strengths. HL7 
is quite America bounded, and UCUM is (as far as I know) a typical HL7 
product, from this point of view.

Please correct me if I am wrong.

Most people of the world cannot read/write English and they also need to 
use medical software/devices, and it is a good thing that translations 
are delivered by an authority like a national standard body, instead of 
vendors more or less educated


I think that is obvious that the mapping between SNOMED and UCUM will 
come if it isn't there yet. So restricting the termbindings regarding 
DvQuantity-property to UCUM may become a problem, although, promoting 
the use is not wrong, like tooling promoted also the use of the OpenEhr 
units-terminology


But it may be alright to define in the RM that the DvQuantity-property 
is like the UCUM-property, but then without mentioning the word UCUM ;-)
And of course, that the unit-string must be restricted by the general 
higher hierarchy of the property domain (like Mass, energy, etc)


Bert

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

Re: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 27-01-18 11:10, Bert Verhees wrote:
If one wants an UCUM term in the DvQuantity and another wants a SNOMED 
term, it is both legal and possible.


What is preferable, that is not to us to decide while thinking about 
OpenEhr. 


But having said this

Until now, in practice, people use the OpenEhr terminology for units 
because that is what the tooling offers. This is not enforced by the RM, 
but it is common practice.


Now UCUM emerge, and then it is also good to accept termbindings for 
defining the property to restrict the units which may be used in the 
DvQuantity.


But does this mean that it is not anymore allowed to use another 
terminology to define a property, that UCUM would be part of the RM, 
does this mean that OpenEhr will be inseparable connected to UCUM?


I don't think that is wise. It breaks with the standard philosophy of 
OpenEhr to offer as much freedom as is possible to the archetype designer.


SNOMED offers also higher hierarchy concepts for properties, for 
example, 118538004: Mass


Bert



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

Re: Quantities of arbitrary units in openEHR

[Thomas Beale]

Bert,

I don't disagree philosophically, but practically speaking, no SNOMED 
service is going to be able to answer requests to do with unit 
properties, unit conversions, or different forms of rendering, which are 
all things we need to take care of properly.


I actually think units is one of the things we should just do properly, 
and in only one way for openEHR. I can't imagine why anyone would use 
SNOMED for units instead of a proper units service that supported the 
above, even if they use SNOMED for everything else. There is of course 
nothing preventing anyone adding bindings from SNOMED to the units paths 
in archetypes.


- thomas


On 27/01/2018 10:10, Bert Verhees wrote:

On 26-01-18 10:00, Thomas Beale wrote:


The thing I am not a fan of is that units themselves become part of 
terminology. This is a SNOMED direction but I think a wrong one. The 
reason is that the ontology of units isn't the same as the ontology 
of findings, medications and so on. In fact they all have different 
ontologies, and trying to jam them all into SNOMED CT under a single 
meta- model is problematic at best.


But OpenEhr is a registering system, so if archetypes will be written 
to define datasets which use a SNOMED-term, then OpenEhr supports 
that, because OpenEhr supports archetypes.


You cannot negate termbindings on AOM/ADL-level in expressing (for 
example), we do not accept SNOMED (only UCUM) at this point, it is the 
archetype-designer who decides that. I think that is one of the best 
features of OpenEhr, the semantic standards are by the user to define. 
OpenEhr facilitates. There is the success factor of OpenEhr.


The solution Diego described yesterday works perfect for many point of 
views and fits in the OpenEhr paradigms.
If one wants an UCUM term in the DvQuantity and another wants a SNOMED 
term, it is both legal and possible.


What is preferable, that is not to us to decide while thinking about 
OpenEhr.


Best regards
Bert

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





--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

Re: Quantities of arbitrary units in openEHR

[Bert Verhees]

On 26-01-18 10:00, Thomas Beale wrote:


The thing I am not a fan of is that units themselves become part of 
terminology. This is a SNOMED direction but I think a wrong one. The 
reason is that the ontology of units isn't the same as the ontology of 
findings, medications and so on. In fact they all have different 
ontologies, and trying to jam them all into SNOMED CT under a single 
meta- model is problematic at best.


But OpenEhr is a registering system, so if archetypes will be written to 
define datasets which use a SNOMED-term, then OpenEhr supports that, 
because OpenEhr supports archetypes.


You cannot negate termbindings on AOM/ADL-level in expressing (for 
example), we do not accept SNOMED (only UCUM) at this point, it is the 
archetype-designer who decides that. I think that is one of the best 
features of OpenEhr, the semantic standards are by the user to define. 
OpenEhr facilitates. There is the success factor of OpenEhr.


The solution Diego described yesterday works perfect for many point of 
views and fits in the OpenEhr paradigms.
If one wants an UCUM term in the DvQuantity and another wants a SNOMED 
term, it is both legal and possible.


What is preferable, that is not to us to decide while thinking about 
OpenEhr.


Best regards
Bert

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

Re: Quantities of arbitrary units in openEHR

[GF]

Semantic Interoperability is possible only when each. distinct domain:
has its own model
has its own rules
and always orthogonal to other models.

A terminology can be equated to a Dictionary.
A terminology is never an Encyclopedia of everything.

We need a terminology of concepts related to the Patient System.
And we need a terminology for things not related, such as Units of Measurement.
There will be more terminologies we need: basic archetype patterns for 
documentation, time-related concepts, medical devices, continuity of care, 
business modelling, etc.

So I agree with Thomas.
SNOMED must have bounderies.
I fear that the SNOMED world is without a well defined scope.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 26 Jan 2018, at 10:00, Thomas Beale  wrote:
> 
> The thing I am not a fan of is that units themselves become part of 
> terminology. This is a SNOMED direction but I think a wrong one. The reason 
> is that the ontology of units isn't the same as the ontology of findings, 
> medications and so on. In fact they all have different ontologies, and trying 
> to jam them all into SNOMED CT under a single meta- model is problematic at 
> best. 
> But units are so clearly different that they deserve their own service - for 
> a start, UCUM unit strings are post-coorindatable according to the UCUM 
> grammar, and then you have the classification of units under properties, 
> synthetic properties under basic properties, strange stuff currently called 
> 'arbitrary' (which is still real, and must have a place inside the ontology); 
> units conversion rules and algorithms and so on. 
> So while a mass unit code like 'kg' might not see much different for a code 
> for pneumonia, even this simple example is already a pre-coordination of 'k' 
> and 'g' according to a units ontology, something that clearly doesn't apply 
> to 'pneumonia', at least not in the same way (i.e. 'viral pneumonia' is a 
> particular that is described by a disease ontology).
> 
> Thinking a bit more about 'arbitrary', I think I agree with Diego - to sort 
> it out properly needs a proper ontology.
> 
> - thomas
> 
> On 26/01/2018 08:41, Diego Boscá wrote:
>> I think there are several potential problems with this, and IMHO we are 
>> stepping too much on what should be done in a terminology service (We are 
>> literally talking about a 'public available UCUM service'). You can also ask 
>> the terminology service what kind of unit code you have. Your implementation 
>> could answer "arbitrary" for these new units.
>> 
>> In my opinion, saying "here comes a mass unit code" is not much different 
>> from "here comes a diagnosis code", and we say these in a completely 
>> different way (a better way, if you ask me).
>> 
>> Also, I'm not a big fan of "arbitrary" property, as feels like a "other" 
>> kind of terminology code that is potentially dangerous as knowledge or 
>> terminology advances, thus coexisting 'arbitrary' and 'new shiny type of 
>> measurements' all mixed up. That's why I also expect these properties to be 
>> as derived from the codes and not the other way around.
>> 
> 
> -- 
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare 
> 
> Management Board, Specifications Program Lead, openEHR Foundation 
> 
> Chartered IT Professional Fellow, BCS, British Computer Society 
> 
> Health IT blog  | Culture blog 
> ___
> 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