Terminology services

Technical (archive)
1

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

2

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

3

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

4

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

5

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

6

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

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

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

+31 252 544896
+31 654 792800

7

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

8

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

9

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

10

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

11

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

12

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

13

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

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

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

+31 252 544896
+31 654 792800

14

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

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

15

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

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

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

+31 252 544896
+31 654 792800

16

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