Terminology services

[Esat ERYILMAZ]

Dear all,

 

I assume, based on the ontological services deployment efforts in some fields 
within different geographical contexts (medicine, agriculture, GIS, US, Europe, 
AU, NZ etc?) coding has nothing to do with descriptions and classifications at 
the same level of frames. I suggest utilizing Kintsch?s 
Construction-Integration theory to unify the concepts and cognitive frames. 
Studies carried out in DFKI-Germany, in my opinion, could support my view in 
various contexts.

 

Coding is inherent in all natural languages in some respects; but in EHR 
contexts, coding is an approach to map classified things/concepts etc inc. 
descriptions.

 

If we can manage, independently from all natural languages, using 
ontology-based taxonomies the need to use different coding systems will fade 
away beyond my expected lifetime period.

 

The same applies to healthcare institutions within OECD?s SHA (System for 
Health Accounts) classification efforts and studies. As has been the case for 
standardization efforts, conceptual mapping and semantic nets have to converge 
around a universal ontological system through research efforts. It is, in 
essence, a matter of unified knowledge representation formalism.

 

Esat N. ERYILMAZ

Pamukkale University
 Philippe AMELINE  wrote:
>Thomas,
>
>I disagree.
>
>I disagree because in essence both are the same. It is in the richness
>versus reduced richness that there is a difference. And that difference is
>not major.
...
>A rich ontology is better than a restricted code set.
>
>Gerard

Hi,

I am not certain that we are talking about the very same things.

Lets take your comparison between very accurate free text and a vague free 
text : both are of the same kind, with the former bearing more information, 
but both use the same langage, probably with a reduced term set for the 
second. Anyway both use terms with a semantic.
Let's say, in the "structured world" that they use the same ontology, but 
one mode uses only a part of it.

If the definition of an ontology is "something that can be used to 
describe", Tom's definition of a Level 0 ontology is "a set of terms + a 
semantic network". In short, it means "in order to describe, you must 
provide a semantic".

Some coding systems may be able to be incorporated into a semantic system ; 
in that case, I agree with Gerard that using one such system or a rich 
ontology is just a choice of the right level of granularity.
However, I think I can give strong evidences that classifications cannot, 
by construction, be incorporated inside a semantic network since each of 
their codes represents an artificial domain delimited by the inclusion and 
exclusion criterions.

Lets take a comparison with geography : you can build an ontology in order 
to describe natural objects (mountains, rivers...), but if you build 
artificial frontiers, and call it countries, you cannot semantically 
include these concepts inside the geographical domain (that is the very 
reason why human beings, very frustrated, had to invent the political 
domain ;-) )

I think that there is the same difference in medicine between ontologies 
and classifications that, in the geographical domain, between geography and 
politics : you can "describe" the political frontiers using the geography 
ontologie, but the political objects belong to another domain.
Tom might answer that the word Australia is an example of a term that is 
shared between geography and politic, but I can't imagine another concept 
of the kind.

As a summary of this (too long) message, I would say that the problem comes 
from the definition of the term "coding" : does it mean "coding in order to 
describe" or "coding in order to classify" ?

Best regards,

Philippe

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org



-
With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your 
needs
-- next part --
An HTML attachment was scrubbed...
URL: 

Terminology services

[François MENNERAT]

The best way to deal with numerous coding schemes, as well as their 
versions and sub-versions seems to be:
1. hold an international register of coding scheme, with an ICSI assigned 
to each one of them
2. always provide the ICSI together with any code mentioned

Regarding the registration of coding scheme, there has been first a 
European pre-standard for the registration of coding schemes used in health 
care (ENV1068), implemented in 1995, then subsequently withdrawn when more 
generic ISO standards have been published. Since, on their turn, these ISO 
standards have never been implemented, and have been withdrawn, the 
European standard EN1068 is now about to be reinstated, and provisions are 
being taken for it to be implemented as soon as it is published (in 2003). 
Later, it may be extended if necessary to cover the neesds of the rest of 
the world.

Fran?ois Mennerat


A 2002-12-22 07:13+1000, Thomas Beale a ?crit :


>Karsten Hilbert wrote:
>
>>>we need to be specific here: what are the attributes? I think that for 
>>>example ICD10 (version = "10" or are there interim releases?) does not
>>Yes, there are. Here in Germany we took a specific (German)
>>version of ICD10 and modified it slightly for use in GP practices.
>>It is called ICD10-SGBV (the SGBV part points to a book of
>>German laws that also deal with health care ...).
>ah yes, well we all seem to do that. THere is ICD10CM (clinical 
>modifications) in the US, ICD10AM (Australian modifications) and so on. 
>What I meant was - are there interim official releases? I have been told 
>"no" so far...
>
>- thomas
>
>
>
>-
>If you have any questions about using this list,
>please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Gerard Freriks]

What I wrote was (in other words)
I see no difference (on a certain level) between natural language and an
artificial one like ENV 13606 plus ICD-x or any other classfication and
terminological system.

Gf



n 2002-12-18 17:00, "Thomas Beale"  wrote:

> 
> 
> Gerard Freriks wrote:
> 
>> Hi,
>> 
>> My thoughts.
>> 
>> If we assume that a code plus description plus coding system, etc as a unit
>> of information them the coding system and the version plus some more
>> attributes will indicate the "language".
>> 
> Hi Gerard,
> 
> we need to be specific here: what are the attributes? I think that for
> example ICD10 (version = "10" or are there interim releases?) does not
> tell you the language. As far as I know, people get ICD10 in a file in
> whatever their language is and just call it "ICD10" - I don't know of a
> formal naming scheme for it including the language.
> 
>> 
>> Equally we can assume that any piece of text (not coded using a
>> classification or terminology) is coded using a code, descriptive text,
>> grammar, a coding system and version number plus some more attributes.
>> I see no difference between the handling of raw text and coding ro
>> terminological systems.
>> 
> well I see plenty! But we are probably talking about different things
> here...
> 
> - thomas beale
> 
> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Philippe AMELINE]

>Thomas,
>
>I disagree.
>
>I disagree because in essence both are the same. It is in the richness
>versus reduced richness that there is a difference. And that difference is
>not major.
...
>A rich ontology is better than a restricted code set.
>
>Gerard

Hi,

I am not certain that we are talking about the very same things.

Lets take your comparison between very accurate free text and a vague free 
text : both are of the same kind, with the former bearing more information, 
but both use the same langage, probably with a reduced term set for the 
second. Anyway both use terms with a semantic.
Let's say, in the "structured world" that they use the same ontology, but 
one mode uses only a part of it.

If the definition of an ontology is "something that can be used to 
describe", Tom's definition of a Level 0 ontology is "a set of terms + a 
semantic network". In short, it means "in order to describe, you must 
provide a semantic".

Some coding systems may be able to be incorporated into a semantic system ; 
in that case, I agree with Gerard that using one such system or a rich 
ontology is just a choice of the right level of granularity.
However, I think I can give strong evidences that classifications cannot, 
by construction, be incorporated inside a semantic network since each of 
their codes represents an artificial domain delimited by the inclusion and 
exclusion criterions.

Lets take a comparison with geography : you can build an ontology in order 
to describe natural objects (mountains, rivers...), but if you build 
artificial frontiers, and call it countries, you cannot semantically 
include these concepts inside the geographical domain (that is the very 
reason why human beings, very frustrated, had to invent the political 
domain ;-) )

I think that there is the same difference in medicine between ontologies 
and classifications that, in the geographical domain, between geography and 
politics : you can "describe" the political frontiers using the geography 
ontologie, but the political objects belong to another domain.
Tom might answer that the word Australia is an example of a term that is 
shared between geography and politic, but I can't imagine another concept 
of the kind.

As a summary of this (too long) message, I would say that the problem comes 
from the definition of the term "coding" : does it mean "coding in order to 
describe" or "coding in order to classify" ?

Best regards,

Philippe

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Gerard Freriks]

Thomas,

I disagree.


I disagree because in essence both are the same. It is in the richness
versus reduced richness that there is a difference. And that difference is
not major.

As a physician I believe in free text and narrative. Healthcare is exchange
of information between responsible humans in the first place and secondly
between databases. And free text in a rich narrative structure is the way in
which humans can express them selves in a rich way as complete and accurate
as they can.
The richer the structure of the free text or narrative the better the
information can be expressed in a structured way. The richer the text is
structured using concepts from a source the better information can be
expressed in an analysable form.
A rich ontology is better than a restricted code set.

Gerard

On 2002-12-18 17:01, "Thomas Beale"  wrote:

> 
> 
> Philippe AMELINE wrote:
> 
>> Hi,
>> 
>> Since I missed the starting point of this thread, I may un-properly
>> answer ; however I can say from the work we are doing that there is a
>> great difference between a system based on an ontology and a system
>> based on free text annotated by a coding system.
>> 
>> The fist one allows structured description (knowledge management
>> field) while the other remains in the field of classification (data
>> management : text index keeping and epidemiology).
> 
> And I have to agree 100%.  But I doubt if Gerard really disagrees with this.
> 
> - thomas
> 
> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Thomas Beale]

Karsten Hilbert wrote:

>>we need to be specific here: what are the attributes? I think that for 
>>example ICD10 (version = "10" or are there interim releases?) does not 
>>
>Yes, there are. Here in Germany we took a specific (German)
>version of ICD10 and modified it slightly for use in GP practices.
>It is called ICD10-SGBV (the SGBV part points to a book of
>German laws that also deal with health care ...).
>
ah yes, well we all seem to do that. THere is ICD10CM (clinical 
modifications) in the US, ICD10AM (Australian modifications) and so on. 
What I meant was - are there interim official releases? I have been told 
"no" so far...

- thomas



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Karsten Hilbert]

> we need to be specific here: what are the attributes? I think that for 
> example ICD10 (version = "10" or are there interim releases?) does not 
Yes, there are. Here in Germany we took a specific (German)
version of ICD10 and modified it slightly for use in GP practices.
It is called ICD10-SGBV (the SGBV part points to a book of
German laws that also deal with health care ...).

Mind you, all this doesn't amount to an official "ICD10 iterim
release", however.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Thomas Beale]

Philippe AMELINE wrote:

> Hi,
>
> Since I missed the starting point of this thread, I may un-properly 
> answer ; however I can say from the work we are doing that there is a 
> great difference between a system based on an ontology and a system 
> based on free text annotated by a coding system.
>
> The fist one allows structured description (knowledge management 
> field) while the other remains in the field of classification (data 
> management : text index keeping and epidemiology). 

And I have to agree 100%.  But I doubt if Gerard really disagrees with this.

- thomas



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Thomas Beale]

Gerard Freriks wrote:

>Hi,
>
>My thoughts.
>
>If we assume that a code plus description plus coding system, etc as a unit
>of information them the coding system and the version plus some more
>attributes will indicate the "language".
>
Hi Gerard,

we need to be specific here: what are the attributes? I think that for 
example ICD10 (version = "10" or are there interim releases?) does not 
tell you the language. As far as I know, people get ICD10 in a file in 
whatever their language is and just call it "ICD10" - I don't know of a 
formal naming scheme for it including the language.

>
>Equally we can assume that any piece of text (not coded using a
>classification or terminology) is coded using a code, descriptive text,
>grammar, a coding system and version number plus some more attributes.
>I see no difference between the handling of raw text and coding ro
>terminological systems.
>
well I see plenty! But we are probably talking about different things 
here...

- thomas beale



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Philippe AMELINE]

Hi Francois, Hi the list (Since the message was not in french, I think 
Francois believed he sent it on the list)

To be honnest, it is a tricky field...
My point of view can be seen on the page 
http://www.nautilus-info.com/cone.htm (in french ;o) )

To summarize :

- The medical description domain can be seen as a 3D cone (a cone since 
your description can range from ill/not ill (sharp edge) to a very accurate 
pathologist description of individual lesions)

- Classifications are build in a 3 steps process :
1) choice of a plan that cut the cone at the proper granularity : you get a 
flat circle that intersect the description cone : the classification domain
2) paving of that plan with small domains delimited by inclusion and 
exclusion criterions : the classification (each domain is given a code, for 
example T08)
3) give each small domain a name (for example T08 = Loss of weight)

 From a given description (a point of the cone), the classification process 
is done through a "projection" of the description point to the 
classification domain

Then :

 From step 1) and 2) above, you can see that there is no semantic at all in 
a classification ; the tricky point is that, due to step 3, people usually 
give a natural langage name to each domain, and end up thinking the domain 
T08 "means" Loss of weight.
Indeed, it is wrong : sometimes, a genuine loss of weight will be 
"projected" on another domain, and you could even imagine coding T08 a 
patient state with no loss of weight (say just low weight).

Indeed, T08 just "means" a domain delimited by inclusion and exclusion 
criterions. There is no semantic behind it.

To give you another evidence of this fact, lets return back to ontologies 
basics : a level 0 ontology is a term list + a semantic network ; the level 
0 semantic network is just a set of "is a" links between terms of the list.

Test 1 : try to build "is a" relations between codes of a classification. 
You should not succeed ; if you succeed, it just means that the paving of 
step 2 has not been done properly, and a domain is included in another.

Test 2 : try to build "is a" relations between codes of a classification 
and terms of an ontology. I don't think you can succed, unless the domains 
in your classification are restricted to a single point of the description 
cone.

Of course, my description cone model, as any model, has just been built to 
help me understand (and explain) the differences between classification and 
description, and thus the reasons why description tools and description 
purposes are far different from classification tools and classification 
purposes.

Philippe

Fran?ois Mennerat answered my message in
>Philippe,
>
>I do not see a great difference.
>Does not a coding scheme (as applied to a classification, or to any other 
>terminological system), or even the classification itself (as any other 
>terminological system) rely on an implicit or explicit ontology?
>
>Fran?ois
>
><<<
>A 2002-12-09 10:14 +0100, vous avez ?crit :
>>Hi,
>>
>>Since I missed the starting point of this thread, I may un-properly 
>>answer ; however I can say from the work we are doing that there is a 
>>great difference between a system based on an ontology and a system based 
>>on free text annotated by a coding system.
>>
>>The fist one allows structured description (knowledge management field) 
>>while the other remains in the field of classification (data management : 
>>text index keeping and epidemiology).
>>
>>Philippe
>>
>>At 08:43 08/12/2002 +0100, Gerard Freriks wrote:
>>>Hi,
>>>
>>>My thoughts.
>>>
>>>If we assume that a code plus description plus coding system, etc as a unit
>>>of information them the coding system and the version plus some more
>>>attributes will indicate the "language".
>>>Equally we can assume that any piece of text (not coded using a
>>>classification or terminology) is coded using a code, descriptive text,
>>>grammar, a coding system and version number plus some more attributes.
>>>I see no difference between the handling of raw text and coding ro
>>>terminological systems.
>>>
>>>Handle both in the same generic way.
>>>
>>>Gerard
>>>
>>>
>>>On 2002-12-05 18:59, "Dipak Kalra"  wrote:
>>>
>>> > Dear Tom,
>>> >
>>> > Sorry for the delay in replying. My remark was describing a situation
>>> > that I believe to be realistic - that a health care session might take
>>> > place in more than one language e.g. via an advocate or a relative.
>>> >
>>> > If one stipulates that the set of coded terms within a whole
>>> > Transaction must be recorded in one language, then clearly that does
>>> > suggest a different rule needs to be offered for plain text. However, I
>>> > was not necessarily implying that it is right for a whole Transaction
>>> > to be in one language, although I could see Sam's reasons for proposing
>>> > this, merely that this clinical scenario is a complication that needs
>>> > to be considered. I note that Sam has suggested an altern

Terminology services

[Philippe AMELINE]

Hi,

Since I missed the starting point of this thread, I may un-properly answer 
; however I can say from the work we are doing that there is a great 
difference between a system based on an ontology and a system based on free 
text annotated by a coding system.

The fist one allows structured description (knowledge management field) 
while the other remains in the field of classification (data management : 
text index keeping and epidemiology).

Philippe

At 08:43 08/12/2002 +0100, Gerard Freriks wrote:
>Hi,
>
>My thoughts.
>
>If we assume that a code plus description plus coding system, etc as a unit
>of information them the coding system and the version plus some more
>attributes will indicate the "language".
>Equally we can assume that any piece of text (not coded using a
>classification or terminology) is coded using a code, descriptive text,
>grammar, a coding system and version number plus some more attributes.
>I see no difference between the handling of raw text and coding ro
>terminological systems.
>
>Handle both in the same generic way.
>
>Gerard
>
>
>On 2002-12-05 18:59, "Dipak Kalra"  wrote:
>
> > Dear Tom,
> >
> > Sorry for the delay in replying. My remark was describing a situation
> > that I believe to be realistic - that a health care session might take
> > place in more than one language e.g. via an advocate or a relative.
> >
> > If one stipulates that the set of coded terms within a whole
> > Transaction must be recorded in one language, then clearly that does
> > suggest a different rule needs to be offered for plain text. However, I
> > was not necessarily implying that it is right for a whole Transaction
> > to be in one language, although I could see Sam's reasons for proposing
> > this, merely that this clinical scenario is a complication that needs
> > to be considered. I note that Sam has suggested an alternative proposal
> > - of linking together two transactions, one in each language. I am not
> > sure how this would work for documenting a more interactive situation.
> >
> > At this stage, I would prefer us to be exploratory about the various
> > scenarios in which language issues arise and then to revisit our model.
> > I am suspicious that our present approach might not be sufficient, but
> > it may also be that I am being too fanciful in my ideas about how
> > multi-lingual consultations might work. I was not at this stage
> > intending to imply a particular information modelling approach to
> > meeting this requirement.
> >
> > With best wishes,
> >
> > Dipak
> > 
> > Dr Dipak Kalra
> > Senior Clinical Lecturer in Health Informatics
> > CHIME, University College London
> > Holborn Union Building, Highgate Hill, London N19 5LW
> > Direct Line: +44-20-7288-3362
> > Fax: +44-20-7288-3322
> > Web site: http://www.chime.ucl.ac.uk
> >
> > -
> > If you have any questions about using this list,
> > please send a message to d.lloyd at openehr.org
>
>--   --
>Gerard Freriks, arts
>Huigsloterdijk 378
>2158 LR Buitenkaag
>The Netherlands
>
>+31 252 544896
>+31 654 792800
>
>
>-
>If you have any questions about using this list,
>please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Gerard Freriks]

Hi,

My thoughts.

If we assume that a code plus description plus coding system, etc as a unit
of information them the coding system and the version plus some more
attributes will indicate the "language".
Equally we can assume that any piece of text (not coded using a
classification or terminology) is coded using a code, descriptive text,
grammar, a coding system and version number plus some more attributes.
I see no difference between the handling of raw text and coding ro
terminological systems.

Handle both in the same generic way.

Gerard


On 2002-12-05 18:59, "Dipak Kalra"  wrote:

> Dear Tom,
> 
> Sorry for the delay in replying. My remark was describing a situation
> that I believe to be realistic - that a health care session might take
> place in more than one language e.g. via an advocate or a relative.
> 
> If one stipulates that the set of coded terms within a whole
> Transaction must be recorded in one language, then clearly that does
> suggest a different rule needs to be offered for plain text. However, I
> was not necessarily implying that it is right for a whole Transaction
> to be in one language, although I could see Sam's reasons for proposing
> this, merely that this clinical scenario is a complication that needs
> to be considered. I note that Sam has suggested an alternative proposal
> - of linking together two transactions, one in each language. I am not
> sure how this would work for documenting a more interactive situation.
> 
> At this stage, I would prefer us to be exploratory about the various
> scenarios in which language issues arise and then to revisit our model.
> I am suspicious that our present approach might not be sufficient, but
> it may also be that I am being too fanciful in my ideas about how
> multi-lingual consultations might work. I was not at this stage
> intending to imply a particular information modelling approach to
> meeting this requirement.
> 
> With best wishes,
> 
> Dipak
> 
> Dr Dipak Kalra
> Senior Clinical Lecturer in Health Informatics
> CHIME, University College London
> Holborn Union Building, Highgate Hill, London N19 5LW
> Direct Line: +44-20-7288-3362
> Fax: +44-20-7288-3322
> Web site: http://www.chime.ucl.ac.uk
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Dipak Kalra]

Dear Tom,

Sorry for the delay in replying. My remark was describing a situation 
that I believe to be realistic - that a health care session might take 
place in more than one language e.g. via an advocate or a relative.

If one stipulates that the set of coded terms within a whole 
Transaction must be recorded in one language, then clearly that does 
suggest a different rule needs to be offered for plain text. However, I 
was not necessarily implying that it is right for a whole Transaction 
to be in one language, although I could see Sam's reasons for proposing 
this, merely that this clinical scenario is a complication that needs 
to be considered. I note that Sam has suggested an alternative proposal 
- of linking together two transactions, one in each language. I am not 
sure how this would work for documenting a more interactive situation.

At this stage, I would prefer us to be exploratory about the various 
scenarios in which language issues arise and then to revisit our model. 
I am suspicious that our present approach might not be sufficient, but 
it may also be that I am being too fanciful in my ideas about how 
multi-lingual consultations might work. I was not at this stage 
intending to imply a particular information modelling approach to 
meeting this requirement.

With best wishes,

Dipak

Dr Dipak Kalra
Senior Clinical Lecturer in Health Informatics
CHIME, University College London
Holborn Union Building, Highgate Hill, London N19 5LW
Direct Line: +44-20-7288-3362
Fax: +44-20-7288-3322
Web site: http://www.chime.ucl.ac.uk

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Thomas Beale]

DipakHome wrote:

> However,
> 4. There is at times the need to include remarks (e.g. made by the 
> patient or a relative) in a different language to the main clinical 
> author. This might arise, for example, if the main author is a health 
> advocate working jointly with a patient and a clinician who do not 
> speak the same language. This is not entirely conjecture, as I have 
> worked in such clinical situations (but obviously, not with such 
> wonderful systems that can do what I am proposing here). As patients 
> begin to fill in questionnaires that form part of a consultation, a 
> need for mutli-lingual Compositions may arise in that scenario too. 
> This means that the EHR representation of narrative expressions should 
> permit a specification of natural language that differs from that of 
> the overall  Transaction/Composition. 

So - you are saying that for a Transaction in a given language, all 
coded terms in the Transaction must be in the same language as the 
transaction, but plain text (instances of DV_TEXT) can be in other 
languages?

- thomas beale



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Thomas Beale]

Sam Heard wrote:

>Dear All
>
>There has been an intense discussion - mainly Tom Beale and Matthew Darlison
>going on off line. I want to share some of my views with others on the
>approach to terminologies. I will deal with them one at a time.
>
>1. Language and terminologies.
>
>It is clear that we need to know what language we are working in to ensure
>that the rubric or phrase returned by the terminology service is
>appropriate. I have proposed in our GEHR work that this is kept at the level
>of a transaction (a transaction can only be in one language). The issue is
>that some words in different languages are lexically identical but their
>meaning is different. SO - if we allow different language rubrics in the
>same transaction - we will get an error one day as someone will read
>something erroneous.
>
I don't think we can do this - 1 Tx should = 1 language.

> For this reason - safety - I propose that transactions
>are consistent in language. I am sure that it has huge pragmatic advantages
>as well. A transaction in a language different from that of the workspace
>can be displayed in a different format and possibly be translated (as
>required).
>
>If people accept this - and I will need a lot of persuading that it is not a
>sensible restriction - it follows that terminology references - called
>coordinated terms in the present model though I do not believe they have a
>rubric so it may not be the best name - do not need a language associated
>with them. This can be drawn from the present transaction, workspace or
>whatever.
>
well except that we have designed the data types to be usable in many 
circumstances - not just in the EHR or in Transactions. The equivalent 
semantic we could use instead is to allow COORDINATED_TERM to have a 
language, and to force all coordinated terms in a TRANSACTION to have 
the same language.

>2. Terminology ID and versions
>
>When sharing the EHR we will need to keep tight control over the expression
>of the terminology in use. For this reason I would favour that we work with
>HL7 & CEN to have a table of terminologies used in openEHR and that versions
>of different terminologies are given different IDs. 
>
agree


- thomas beale




-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Sam Heard]

Dipak

I would propose that such narratives be kept in a different transaction if
you want to specify the language and referenced from the main record. This
can be transparent for the user (BUT the language would of the referenced
transaction would need to be stated as it differed from the current
workspace) but maintains the principle - one transaction, one language.

Sam

> -Original Message-
> From: owner-openehr-technical at openehr.org
> [mailto:owner-openehr-technical at openehr.org]On Behalf Of DipakHome
> Sent: Friday, 29 November 2002 4:45 PM
> To: Openehr-Technical
> Subject: Re: Terminology services
>
>
> Dear All,
>
> I would like to concur with Sam on these issues. i.e.
>
> 1. The natural language used in recording a set of EHR entries should
> normally be specified at the Transaction/Composition level.
> 2. The EHR must be able to represent faithfully the use of a term from
> a terminology system by an author, by being able to represent (either
> as one or as multiple attributes)
>   a) the code value
>   b) a unique reference to the terminology system that issued
> the code
> (ISO & CEN naming schemes have been defined over the years but not
> rigorously or comprehensively adopted)
>   c) the version of that system used
>   d) the actual rubric as selected by the author (for safety, and for
> transparency in a distributed environment)
> 3. The language of the Transaction/Composition should be deemed to have
> prevailed throughout
>
> However,
> 4. There is at times the need to include remarks (e.g. made by the
> patient or a relative) in a different language to the main clinical
> author. This might arise, for example, if the main author is a health
> advocate working jointly with a patient and a clinician who do not
> speak the same language. This is not entirely conjecture, as I have
> worked in such clinical situations (but obviously, not with such
> wonderful systems that can do what I am proposing here). As patients
> begin to fill in questionnaires that form part of a consultation, a
> need for mutli-lingual Compositions may arise in that scenario too.
> This means that the EHR representation of narrative expressions should
> permit a specification of natural language that differs from that of
> the overall  Transaction/Composition.
>
> With best wishes,
>
> Dipak
> 
> Dr Dipak Kalra
> Senior Clinical Lecturer in Health Informatics
> CHIME, University College London
> Holborn Union Building, Highgate Hill, London N19 5LW
> Direct Line: +44-20-7288-3362
> Fax: +44-20-7288-3322
> Web site: http://www.chime.ucl.ac.uk
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Sam Heard]

Dear All

There has been an intense discussion - mainly Tom Beale and Matthew Darlison
going on off line. I want to share some of my views with others on the
approach to terminologies. I will deal with them one at a time.

1. Language and terminologies.

It is clear that we need to know what language we are working in to ensure
that the rubric or phrase returned by the terminology service is
appropriate. I have proposed in our GEHR work that this is kept at the level
of a transaction (a transaction can only be in one language). The issue is
that some words in different languages are lexically identical but their
meaning is different. SO - if we allow different language rubrics in the
same transaction - we will get an error one day as someone will read
something erroneous. For this reason - safety - I propose that transactions
are consistent in language. I am sure that it has huge pragmatic advantages
as well. A transaction in a language different from that of the workspace
can be displayed in a different format and possibly be translated (as
required).

If people accept this - and I will need a lot of persuading that it is not a
sensible restriction - it follows that terminology references - called
coordinated terms in the present model though I do not believe they have a
rubric so it may not be the best name - do not need a language associated
with them. This can be drawn from the present transaction, workspace or
whatever.

When querying a record via a terminology service, language will only be
relevant for the display - if you require translation (or if it is
available). So, if we have a term in ICD10 english, if there is a
translation of this then it should be the same concept - not a linguistic
translation. Stan Shepherd can help us with this as he translated ICPC into
12 languages and learned a great deal.

2. Terminology ID and versions

When sharing the EHR we will need to keep tight control over the expression
of the terminology in use. For this reason I would favour that we work with
HL7 & CEN to have a table of terminologies used in openEHR and that versions
of different terminologies are given different IDs. Every clinical system
will have a set of terminologies that it can deal with and will require
mappings to be created with termsets that it does not process. It is infact
likely that the shared parts of the record will have mappings to many
different terms sets - problem lists and medications for example.

The advantage is that we keep control over terminologies and understand when
they are different or the same - a translation might be identical - or might
involve modification. Whatever the realities - it is unlikely that much will
be gained in automatic processing until there is more convergence in the
world of terminologies than there is at the moment.

3. Domain termlists

It is very likely that some entries will require national or local domain
term lists - of the type that is in HL7. For this reason, I would propose
that we deal with this at two levels:

A. When the domain termlist is available internationally - use the authority
and the domain term list via the terminology service. For example
HL7:SpecimenType will give us the table of Specimen Types for laboratory
specimens. We may need some EHR specifics such as which terminologies are
allowed in openEHR for formal translation??

B. A term list that is very specific for a particular archetype or a
particular location. I would propose that this will be a set of
DV_PLAIN_TEXTs or DV_TERM_TEXT (if they are from a known terminology that
does not provide the means of displaying a subset).

Summary

All approaches have problems and only time will tell what is the most
appropriate response for a particular situation. For a fixed termset -
perhaps the patient position when a blood pressure is measured - an
identifier to a terminology (eg Children of Patient_Position),
HL7:PatientPosition or {sitting|lying|reclining|standing} are all
possibilities.

I am sure all need to be available from the start and standardisation needs
to unfold in the best manner for interoperability.

I look forward to hearing from you - Cheers, Sam

Dr Sam Heard
Ocean Informatics, openEHR
Co-Chair, EHR-SIG, HL7
Chair EHR IT-14-2, Standards Australia
105 Rapid Creek Rd
Rapid Creek NT 0810

Ph: +61 417 838 808

sam.heard at bigpond.com

www.openEHR.org
www.HL7.org
__





Dr Sam Heard
Ocean Informatics, openEHR
Co-Chair, EHR-SIG, HL7
Chair EHR IT-14-2, Standards Australia
105 Rapid Creek Rd
Rapid Creek NT 0810

Ph: +61 417 838 808

sam.heard at bigpond.com

www.openEHR.org
www.HL7.org
__

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[DipakHome]

Dear All,

I would like to concur with Sam on these issues. i.e.

1. The natural language used in recording a set of EHR entries should 
normally be specified at the Transaction/Composition level.
2. The EHR must be able to represent faithfully the use of a term from 
a terminology system by an author, by being able to represent (either 
as one or as multiple attributes)
a) the code value
b) a unique reference to the terminology system that issued the code 
(ISO & CEN naming schemes have been defined over the years but not 
rigorously or comprehensively adopted)
c) the version of that system used
d) the actual rubric as selected by the author (for safety, and for 
transparency in a distributed environment)
3. The language of the Transaction/Composition should be deemed to have 
prevailed throughout

However,
4. There is at times the need to include remarks (e.g. made by the 
patient or a relative) in a different language to the main clinical 
author. This might arise, for example, if the main author is a health 
advocate working jointly with a patient and a clinician who do not 
speak the same language. This is not entirely conjecture, as I have 
worked in such clinical situations (but obviously, not with such 
wonderful systems that can do what I am proposing here). As patients 
begin to fill in questionnaires that form part of a consultation, a 
need for mutli-lingual Compositions may arise in that scenario too. 
This means that the EHR representation of narrative expressions should 
permit a specification of natural language that differs from that of 
the overall  Transaction/Composition.

With best wishes,

Dipak

Dr Dipak Kalra
Senior Clinical Lecturer in Health Informatics
CHIME, University College London
Holborn Union Building, Highgate Hill, London N19 5LW
Direct Line: +44-20-7288-3362
Fax: +44-20-7288-3322
Web site: http://www.chime.ucl.ac.uk

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org