Error in terminology.xml?

Technical (archive)
1

This line is in it:
  <Concept Language="en" ConceptID="32" Rubric="Subject of data" />

when you go to grouper:
<Grouper id="1" ConceptID="32" />

and then to groupedconcept:
<GroupedConcept GrouperID="1" ChildID="0" />
  <GroupedConcept GrouperID="1" ChildID="3" />
  <GroupedConcept GrouperID="1" ChildID="6" />
  <GroupedConcept GrouperID="1" ChildID="7" />

etc....

which points to:
<Concept Language="en" ConceptID="0" Rubric="self" />
  <Concept Language="en" ConceptID="3" Rubric="foetus" />
  <Concept Language="en" ConceptID="6" Rubric="donor" />
  <Concept Language="en" ConceptID="7" Rubric="maternal grandmother" />
etc...

2

Hi Bert,

Yes, I believe it should be changed. I actually made a heading change for the subject setting in the GUI of the archetype editor when I saw that the subject attribute of the ENTRY classes should be a PARTY_RELATED (which represents the relation to the subject of data) and not a PARTY_SELF (which represents the subject of data).

For some reason I never realized that the terminology.xml was wrong.

Regards,

Mattias

2007/3/16, Bert Verhees <bert.verhees@rosa.nl>:

3

Mattias Forss schreef:

Hi Bert,

Yes, I believe it should be changed. I actually made a heading change
for the subject setting in the GUI of the archetype editor when I saw
that the subject attribute of the ENTRY classes should be a
PARTY_RELATED (which represents the relation to the subject of data) and
not a PARTY_SELF (which represents the subject of data).

For some reason I never realized that the terminology.xml was wrong.

I also have doubts on "Instruction state", shouldn't it be "ISM state"?

Bert

4

Thanks for this Bert; we have raised a CR -
http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/246

- thomas

Bert Verhees wrote:

5

Thanks for this Bert; we have raised a CR -

Thanks, Thomas, I found out, there is also a Instruction transition,
which, maybe, I think, must be "ISM Transitions"

I worked a lot last week writh this file (terminology.xml)

I also found group "Participation function" is missing, I added it myself
for private code-use, with one item: "unknown", else my code gives an
error in the class Participation, Also the same for "Participation mode"
(which does exist), which has no childs/members at all. I added also
"unknown" as child. Because the class Participation is not allowed to have
Void on function and mode.

For this moment, I did a good scan, these are the issues I found.

I really am glad when these issues will be handled, because I use the
xml-file.

There are also Codesets (countries, languages) in the terminology.xml,
which is OK for me. For the Openehr-codesets which are not in
terminology.xml, I created my own XML-files, for the time being. I don't
know what the plans are with terminology.xml, to add the codesets? Which
(as I said) would be fine to me.

It is no problem when it gets a bit large (500K-1M won't hurt), as I
process it only once using SAX, and keep the data in internal memory
structures in Hashtables, like in the Java Archetype-editor, very quick.

I am very glad the terminology.xml is maintained officially by the
community. I could add a Dutch translation, but it would be a temporary
translation, as because I believe there are people who can do this better.
But for the time being, and "father" = "vader" (often it is simple :wink:

So if you like me to do that and add, I can do that after the changes are
done.

Bert

6

Hi All

The XML is used for the archetype editor and so has a real GUI use as well. This is probably not ideal in the long term so we probably need to separate out the GUI information from the hard openEHR terminology that is used for processing.

I can understand why you want to change the wording to fit with the technical notions - but the clinicians need to use the editor so the names are really those that can be understood at the interface level.

There are a number of translations already in the editor xml file - the dutch translation needs to be coordinated with Gerard Freriks who has made a start I believe.

Sam

Bert Verhees wrote:

7

Sam Heard schreef:

Hi All

The XML is used for the archetype editor and so has a real GUI use as
well. This is probably not ideal in the long term so we probably need
to separate out the GUI information from the hard openEHR terminology
that is used for processing.

For me, the XML has a clear structure, easy to use, and technically well
documented.
As I understand from these words, this structure can be replaced, and
another structure can appear.

As I understand, this means, that terminology.xml in this fashion will
not be maintained for sure.

Because the OpenEhr terminology is only a very small part of the
terminology used in the OpenEhr kernel, it can have its own approach.
That was my consideration when choosing to use the XML-file.

(Other larger terminologies need possibly another approach depending on
how it is available, and how large it is, internal structure, etc.
(web-services, imported csv in database).)

I am happy, that in my code, I seperated the data-access-methods from
the terminology-interface. So if the xml-structure changes, I can
switch, or because it is a small file, maintain it myself for my
customers, or freeze it.

I can understand why you want to change the wording to fit with the
technical notions - but the clinicians need to use the editor so the
names are really those that can be understood at the interface level.

I now can understand that. I hope, however, the codings belonging tot
the rubrics will not change, that is the most important. Because the
codes are also documented in the specs and this part of the specs is
declared stable in the release candidate 1.0.1, I trust it is safe to
use them (mean to say, only very few changes will occur).

There are a number of translations already in the editor xml file -
the dutch translation needs to be coordinated with Gerard Freriks who
has made a start I believe.

I wait for Gerard to deliver the translation. Any idea when this will
be? I would like to know because on this depends if I make a temporarily
translation for myself, or wait for the one from Gerard. Which, I guess
will be much better than the one I would make because of his experience
in standardization-processes and his medical education.

Thanks for explaining
Bert

8

error in the class Participation, Also the same for "Participation mode"
(which does exist), which has no childs/members at all. I added also
"unknown" as child. Because the class Participation is not allowed to have
Void on function and mode.

I am sorry, this is a mistake, there are no children for "Participation
function" and for "Term mapping purpose", but there are for
"Participation mode".

Bert

9

Yes.
I’ve ‘translated’ almost all of the terms.
translating it is not easy.
Several times the English term is good enough and the only reasonable one.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

10

Gerard Freriks schreef:

Yes.
I've 'translated' almost all of the terms.
translating it is not easy.
Several times the English term is good enough and the only reasonable one.

We use a many English words in Dutch. As long as Dutch, without
knowledge of English can understand the it (as long as it looks like Dutch)
Maybe you can throw in some words with give you a headache. Others may
have a good idea.

Bert

11

Gerard Freriks schreef:

Yes.
I've 'translated' almost all of the terms.
translating it is not easy.
Several times the English term is good enough and the only reasonable one.

When are you planning to publish what you have already translated?
Is it in your plans to publish it?

Bert

12

Dear bert,

It was not.
Now it is.

(i’ll contact you)

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

13

Gerard Freriks schreef:

Dear bert,

It was not.
Now it is.

(i'll contact you)

OK, thanks, in advance
Bert

Gerard

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

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl <mailto:gfrer@luna.nl>

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

Let me remind you of the pilgrim who asked for an audience with the
Dalai Lama. He was told he must first spend five years in contemplation.
After the five years, he was ushered into the Dalai Lama's presence, who
said, 'Well, my son, what do you wish to know?' So the pilgrim said, 'I
wish to know the meaning of life, father.' And the Dalai Lama smiled and
said, 'Well my son, life is like a beanstalk, isn't it?'

14

Dear all,

in response to the anomalies in the openEHR Support Terminology found by
Bert Verhess and Mattias Forss, we have updated both the paper
specification and the XML file.

The CR describes the changes in detail -
http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/246
The XML file & PDF doc are available from here:
http://svn.openehr.org/specification/BRANCHES/Release-1.0.1-candidate/publishing/architecture/computable/terminology/terminology.html

Note that small changes were also made to the Support, Common, openEHR
archetype profile and EHR IM docs as well, due to the terminology group
name changes. Annoying I know, but I guess better to have it over and
done with than leave to annoy everyone continually...

The translations of the terminology still have to be updated, but this
will have to wait, since translations usually take time to complete.

- thomas beale

15

in response to the anomalies in the openEHR Support Terminology found by
Bert Verhess and Mattias Forss, we have updated both the paper
specification and the XML file.

[...]

The XML file & PDF doc are available from here:
http://svn.openehr.org/specification/BRANCHES/Release-1.0.1-candidate/publishing/architecture/computable/terminology/terminology.html

Hi!

Regarding SNOMED CT, the file...
http://svn.openehr.org/specification/BRANCHES/Release-1.0.1-candidate/architecture/computable/terminology/terminology.xml
...only mentions it on the line...
  <TerminologyIdentifiers VSAB="SNOMED-CT" SourceName="SNOMED
International Clinical Terms, 2002" Authority="openEHR 2003" />

How should this be interpreted?
- the identifier "SNOMED-CT" is reserved for a 2002 version of SNOMED
CT (by openEHR)
- the identifier "SNOMED-CT" is reserved for any SNOMED CT version after 2002
- anything else?

Since identifiers within SNOMED CT are not supposed to be reused, I
guess the second alternative might be somewhat safe. Still it might be
interesting to know what version of SNOMED CT the clinician used when
coding the information - since the available code choices might have
been different - where would that information be stored within the
openEHR framework?

Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/

16

Hi Erik
We have used an identifier for stable terminologies that are not removing codes - thus LOINC and SNOMED-CT have the date from which they are considered stable.
Sam

Erik Sundvall wrote:

17

Hi!

We have used an identifier for stable terminologies that are not removing
codes - thus LOINC and SNOMED-CT have the date from which they are
considered stable.

OK, great, thanks for the explanation. That answers my first question.

May I suggest that the terminology file be changed to something like...
<TerminologyIdentifiers VSAB="SNOMED-CT" SourceName="SNOMED
  International Clinical Terms, 2002 or later" Authority="openEHR 2003" />
...for pedagogical reasons. Take this as a CR/PR if you wish.

The second question remains:
It might be interesting to know what version of SNOMED CT the
clinician used when
coding the information - since the available code choices might have
been different - where would that information be stored within the
openEHR framework?
Should such info go into "EHR status" of the EHR system, some kind of
version history in the yet-to-be-specified terminology server/service
if such a service is used, or be part of compositions or be somewhere
else? Somehow in a feeder audit from the terminology server? Any other
wild speculations? Will it be available in EHR extracts or possible
for external systems to retrieve in some other way?

Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/

18

Hi Erik

SNOMED will be released every 3 months - and will retain the codes. It is possible for us to issue a new ID for all releases - the TERMINOLOGY_ID does have a release attribute) - or we go with the flow and accept that there will be some variation over time. I believe keeping track of minor releases is not useful or feasible - major releases need to have a different ID.

The only reason for this is to have semantic continuity and so needs to change when there is a change in meaning.

Cheers, Sam

Erik Sundvall wrote: