# Error in terminology.xml? **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2007-03-16 12:30 UTC **Views:** 4 **Replies:** 17 **URL:** https://discourse.openehr.org/t/error-in-terminology-xml/14638 --- ## Post #1 by @system 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\.\.\. --- ## Post #2 by @Mattias_Forss1 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](mailto:bert.verhees@rosa.nl)>: --- ## Post #3 by @system 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 --- ## Post #4 by @thomas.beale 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: --- ## Post #5 by @system > > 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 ;\-\) So if you like me to do that and add, I can do that after the changes are done\. Bert --- ## Post #6 by @Sam 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: --- ## Post #7 by @system 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 --- ## Post #8 by @system > 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 --- ## Post #9 by @system 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](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 --- ## Post #10 by @system 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 --- ## Post #11 by @system 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 --- ## Post #12 by @system 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](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 --- ## Post #13 by @system 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?' --- ## Post #14 by @thomas.beale 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 --- ## Post #15 by @erik.sundvall > 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/ --- ## Post #16 by @Sam 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: --- ## Post #17 by @erik.sundvall 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/ --- ## Post #18 by @Sam 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: --- **Canonical:** https://discourse.openehr.org/t/error-in-terminology-xml/14638 **Original content:** https://discourse.openehr.org/t/error-in-terminology-xml/14638