# dictionary **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2006-02-07 22:32 UTC **Views:** 4 **Replies:** 11 **URL:** https://discourse.openehr.org/t/dictionary/14507 --- ## Post #1 by @system Hi, I have a question, maybe a stupid question, don't hesitate to tell me \(I can handle that\), as long as you give the answer with it\. Today I had the opportunity to have a good look at HealthOne, a GEHR system, many on this list will know it\. One thing looked smart to me\. They have a kind of Dictionary with 6000 words, \(also these words are possibly related to each other, that makes it an extra strong feature\)\. The relationship between the words is not hard coded and is not stored in medical\-records, so if the relationship changes, nothing breaks, even if a word from the dictionary will be deleted \(which will not easily happen\), nothing breaks\. The advantage is that always the same word is used when storing something, f\.e\. "Weight" Maybe OpenEhr has such a feature also\. or does it depend on archetypes to force the same semantics\. This seems dangerous to me, because when exchanging medical information, in an other Archetype weight can be defined as another word, a synonym, f\.e\. "Bodyweight" If one has an archetype which calculates the BMI \(body mass index\), it could not work on another OpenEhr system that has used \(some time\) another archetype to store the "Weight"\. Or am I completetely misunderstanding the issue, and is it in fact a non\-issue\. Please explain to me\. Thanks in advance Kind regards Bert Verhees --- ## Post #2 by @Mattias_Forss Hi Bert, I don't think this is a big issue\. The important thing in openEHR archetypes is the structure of them\. As long as there is a structure that is equal for both "Weight" and "Bodyweight", it shouldn't be a problem\. The allowed information model structures in archetypes is what really matters and the terms can always be bound to external terminologies to create a mutual understanding\. Regards, Mattias Forss --- ## Post #3 by @ognian.pishev You can plug in any "dictionary" or terminology set into openEHR\. It is terminology independent\. O\. Pishev --- ## Post #4 by @Philippe_AMELINE Hi Mattias, The more I work on medical information systems, and the less I believe that the structure is more important than the terminology\. To be a little bit more accurate, my opinion is that any health information system is there to "tell stories"\. I started in the domain 20 years ago with endoscopy reports : the story to tell was a 10 to 20 minutes medical act\. Now, for many reasons \(but it would be too long to explain it there\), the "big thing" is continuity of care, and the challenge is to be able to tell someone's whole medical journey\. So, how can we tell these stories \(from a 10 minutes encounter to the whole life and the fighting strategies to remain as healthy as possible\) ? The answer is rather simple \(at least to express\) : we need to make "sentences"\. And to make sentences requires a grammar \(the discourse structure\) and a vocabulary \(to populate the discourse structure\)\. Is it possible to have a discourse structure that can "host" any terminology ? My personal answer is 'no', but maybe I try to tell more complex stories than you intend, or maybe you have a more powerful technological solution\. At large, I can ask you a question : do you think that you could communicate using the english grammar and let people choose any other language's vocabulary to populate it ? You can answer that natural language is more complex that formal language, but I can say that the more complex the story you intend to tell and the closer they need to be\. Regards, Philippe --- ## Post #5 by @Mattias_Forss Hi Philippe, Well I started in the domain 20 weeks ago and I didn't know anything back then \(in the old days\)\. I'm currently on my way of finishing my master's thesis, so I cannot say I have the experience to answer your questions ;\-\) PS\. Your questions are sensible though, no offense Cheers, Mattias --- ## Post #6 by @mikael Hi Philippe, > From my point of view is the lack of communicable structure between different EHR systems the main problem openEHR’s archetypes tries to solve\. I think this is what Mattias tries to say with his letter\. In general medical informatics is it of cause also a large need for medical terminology systems of good quality, but openEHR’s archetypes don’t try to solve this problem by themselves\. Instead you are able to link your archetypes to the medical terminology systems of the flavor you prefer, like SNOMED CT, ICD\-10, ICF, ICPC, NCSP or something built by yourself\. \(At least in Sweden there exist maybe too many “home built” medical terminology systems\.\)   Regards,   Mikael Nyström   Mattias’ and Johan’s master thesis supervisor --- ## Post #7 by @Ed_Dodds Agenda: Professor Dr\. Asuman Dogac, from the Middle East Technical University \(METU\) in Turkey presents her talk is entitled: "Exploiting ebXML Registry Semantics in the eHealth Domain" http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2006_03_02 Your dialogue at this event would prove extremely helpful\. Just give Peter Yim a heads up beforehand if you plan attend \-\- info at the wiki link\. If you'd be interested but cannot attend live these events are usually digitized and downloadable \(mp3 audio and any presentations\) \-\- just check back at the wiki link one to two days after the event\. Thanks\. Ed Dodds --- ## Post #8 by @Philippe_AMELINE Hi Mikael, I would be very sorry to have this conversation become too formal or appear as some criticism\. I am much willing to learn, and I think that, as a master thesis supervisor, you teach Mattias not just to be happy with "established concepts" but to have a push on it and check if it is a stone basement or just a theater set\. My questions : "are you certain that a structure can host any terminology", "what is the discourse complexity level you can address" are of the "have a push on it" kind\. My feeling is that the good order to ask questions \(and answer it\) is : Why do you want to communicate ? What discourse complexity level can allow to address these needs ? What discourse representation technology fits these "required language" ? So, you may already have answered questions 1 and 2, and that it is possible to answer Q3 with a discourse structure that can host any existing terminology\. But at large, I don't agree that such a concept can address any answer to questions 1 and 2\. My personal opinion is even that, as a bottom\-up strategy, it constraints the system to a very specific range of environments\. By the way, the term "terminology" itself would demand to be made more accurate\. It is often used to describe coding systems, classifications, dictionaries, standardized vocabularies, ontologies\.\.\. All these components can actually appear somewhere in a discourse structure, but at a specific place \! One can say, for example : "The patient complains from a terrible abdominal pain 2 hours after meal\. We can classify it as D01 in ICPC" But not : "The patient complains from a terrible \(D01 in ICPC\) 2 hours after meal\." This is certainly a multi\-axial discussion\. I hope I make my point of view understandable\. Cheers, Philippe Mikael Nyström a écrit : --- ## Post #9 by @sebastian.garde Hi, Very true Mikael\. Linking archetypes to terminology is important \- especially for standardised querying I believe\. But in my opinion linking archetypes to terminology is not sufficient for semantic interoperability between systems\. For semantic interoperability you need to have either the systems using the same \(or more specialised/general\) archetypes or conversion rules between these archetypes\. Obviously it is best to have a set of archetypes available that can be used and specialised as needed in various systems, rather than every implementation starting from scratch with new archetypes\. Also not every item in an archetype will relate 1:1 to terminology\. This needs some governance processes to ensure that these archetypes: \- do not have significant concept overlaps \(e\.g\. different archetypes for   nursing and for medicine for essentially the same concept \-   just from a different viewpoint\)\. \- are easily accessible \(e\.g\. on an internet server\) and easily locatable,   i\.e\. organised in a way that a certain archetype can be retrieved with   high recall and precision from all archetypes\. \- are evidence\-based whenever possible and agreed to by   domain experts \(doctors, nurses\.\.\.\) \- need to be maintained and systematically updated when knowledge changes\. 2\-level\-modelling/archetypes ensure that data are \_syntactically\_ interoperable \(i\.e\. structure and provenance can be understood \- this is ensured by the reference model\) and semantically \_interpretable\_ \(i\.e\. the semantics is explicit and can be understood and analysed by domain experts \- this is ensured by archetypes themselves\)\. However, archetypes on their own do not ensure semantically interoperable systems \(i\.e\. archetypes alone do not guarantee that different EHR systems and vendors will construct equivalent EHR extracts, and use the record hierarchy and terminology in consistent ways, etc\.\)\. In Australia for example a set of archetypes to support shared care of patients with chronic disease has been developed for Australia's General Practice Computing Group influenced by intensive discussion of a broad variety of domain experts \(GPs, specialists, nurses, etc\.\) \- see http://www.gpcg.org.au/index.php?option=com_content&task=view&id=42&Itemid=54. To support these discussions and make archetypes available, a protoype archetype repository \(Archetypefinder, http://www.dualitysystems.com.au/archetypefinder) has been developed and is being expanded\. Regards Sebastian Dr Sebastian Garde Faculty of Business and Informatics Central Queensland University Rockhampton Qld 4702, Australia s\.garde@cqu\.edu\.au Ph: \+61 \(0\)7 4930 6542 Fax: \+61 \(0\)7 4930 9729 Skype: gardeseb http://healthinformatics.cqu.edu.au --- ## Post #10 by @thomas.beale Bert Verhees wrote: > Hi, > > I have a question, maybe a stupid question, don't hesitate to tell me (I can handle that), as long as you give the answer with it. > > Today I had the opportunity to have a good look at HealthOne, a GEHR system, many on this list will know it. > > One thing looked smart to me. > They have a kind of Dictionary with 6000 words, (also these words are possibly related to each other, that makes it an extra strong feature). The relationship between the words is not hard coded and is not stored in medical-records, so if the relationship changes, nothing breaks, even if a word from the dictionary will be deleted (which will not easily happen), nothing breaks. this is a small lexicon, or terminology. openEHR does not have its own clinical terminology; it is designed to work with what is available. We need three elements to make a health information platform function, all of which can be (and must be) understood from an ontological viewpoint (see [http://www.deepthought.com.au/health/tb_ontologies.ppt](http://www.deepthought.com.au/health/tb_ontologies.ppt) for a short presentation on this): - an ontology of information, which defines the structure and semantics of information; consists of two elements: - the software, built from models that embody a "foundation level" ontology; in openEHR this is Composition, Section, Entry, Observation, Evaluation, Instruction, Action, History, Item_tree, ....down to the data types - models of domain content, workflow etc: archetypes, workflow definitions, computerised clinical guidelines - an ontology of reality, which defines meaning of and relationships among real things, including anatomy, biochemistry, diseases, drug descriptions, other aspects of medicine; this provides an "expression" of what exists, rather than of information. This where clinical terminologies come in. So what is in Health.one (btw, designed based on our oriignal GEHR work from 1994/5) is a small version of the third item - a simple medical lexicon. But you still need parts 1 & 2 - i.e. well-designed software based on a foundation model, and models of clinical content / workflow etc - the archetype level. openEHR provides parts 1 2, but not (itself) part 3. Ideally, we would do what Philippe Ameline did - use a single, well-designed, coherent lexicon which acts as a terminology. However, in the world in which we live, we will have Snomed-ct forced upon us, by people with power but little understanding. And there are other specialist vocabularies around as well. So - we have designed archetypes to be able to connect to multiple terminologies, not to require only one. To be specific, if you see a term "skin colour" in an archetype, coded as at0004, it could mean: - that "skin colour" is defined only locally in that archetype, and has its own meaning, even if the same lexical string occurs in snomed or other archetypes. Then the term-code as you would normally think of it is: the archetype-id::at0004 - that "skin colour" is defined locally in the archetype but has a match of some kind (=, broader, narrower, ...) with some term in an external terminology; in this case it will have an entry in the binding section e.g. that binds it to snomed-ct::30002938 - that "skin colour" in the archetype was taken from an external, commonly used terminology. In this case, in the definition of at0004 in the archetype, it will have a line like : provenance = <[snomed-ct::30002938]>. The meaning of this is that at0004 is just a copy of the term already defined external to the archetype. "Weight" might be a reasonable candidate for the 3rd case. However... you would be surprised how often basic terms like "weight", while lexically matching in various terminologies, don't mean the same thing; it can mean: body weight, infant body weight, mean/max/min/change of weight, weight of a body part or tumour...and so on. Another thing I should point out: openEHR does have a terminology ([http://svn.openehr.org/specification/TRUNK/publishing/architecture/terminology.pdf](http://svn.openehr.org/specification/TRUNK/publishing/architecture/terminology.pdf)), however this is not a terminology in the same sense as Snomed-ct etc; it is just a set of vocabularies to complete the semantics of the reference model (avoids using enumerated types). > The advantage is that always the same word is used when storing something, f.e. "Weight" > > Maybe OpenEhr has such a feature also. or does it depend on archetypes to force the same semantics. This seems dangerous to me, because when exchanging medical information, in an other Archetype weight can be defined as another word, a synonym, f.e. "Bodyweight" > > If one has an archetype which calculates the BMI (body mass index), it could not work on another OpenEhr system that has used (some time) another archetype to store the "Weight". It depends on what the archetypes look like. If you have two archetypes that both record weight, and they take their "weight" terms (let's say at0002 in one archetype and at0015 in the other) as both corresponding to a snomed-ct weight term 20039394 (I just made that up - someone who has snomed needs to look it up), then in both archetypes, it will have the "provenance = <>" line in the definitions of both 'at' terms. It may also have a binding entry for both terms; additionally, in the actual data, the software can write the snomed-ct terms in as mappings wherever the at0002 / at0015 terms appear. This means that querying can easily determine by looking at data, or at least by looking at archetypes, that the same idea of "weight" is intended. > Or am I completetely misunderstanding the issue, and is it in fact a non-issue. It's not a big issue design-wise - but it does need some external terminology available. I would like to have Philippe's excellent lexicon from Nautilus (50,000+ terms plus fils guides coordination rules) in openEHR, but it is in french;-) - thomas --- ## Post #11 by @thomas.beale Philippe AMELINE wrote: > Hi Mikael, > > I would be very sorry to have this conversation become too formal or appear as some criticism\. I am much willing to learn, and I think that, as a master thesis supervisor, you teach Mattias not just to be happy with "established concepts" but to have a push on it and check if it is a stone basement or just a theater set\. > > My questions : "are you certain that a structure can host any terminology", "what is the discourse complexity level you can address" are of the "have a push on it" kind\. > > My feeling is that the good order to ask questions \(and answer it\) is : > Why do you want to communicate ? > What discourse complexity level can allow to address these needs ? > What discourse representation technology fits these "required language" ? I think it is problematic to think only in terms of linguistic discourse; we need to think in terms of conceptual truths as well\. Infection with plasmodium parasite leads to malaria, no matter what language it is written in; certain kinds of polyps in the colon increase the risk of bowel cancer, no matter what language\. "Ontologies of reaility" as I call them should be \(more or less\) linguistically independent\. The problem is to agree on one or more good quality ones\. Then archetypes have something to work with\. Unfortunately, I fear that the Snomed\-ct developers are losing sight of what a good terminology is and trying to jam many incorrect concepts into it\. > > So, you may already have answered questions 1 and 2, and that it is possible to answer Q3 with a discourse structure that can host any existing terminology\. > But at large, I don't agree that such a concept can address any answer to questions 1 and 2\. My personal opinion is even that, as a bottom\-up strategy, it constraints the system to a very specific range of environments\. > > By the way, the term "terminology" itself would demand to be made more accurate\. It is often used to describe coding systems, classifications, dictionaries, standardized vocabularies, ontologies\.\.\. > All these components can actually appear somewhere in a discourse structure, but at a specific place \! exactly > One can say, for example : "The patient complains from a terrible abdominal pain 2 hours after meal\. We can classify it as D01 in ICPC" > But not : "The patient complains from a terrible \(D01 in ICPC\) 2 hours after meal\." this is a problem of to much pre\-coordination\.\.\.\. \- thomas --- ## Post #12 by @Philippe_AMELINE Thomas Beale a écrit : >> My feeling is that the good order to ask questions \(and answer it\) is : >> Why do you want to communicate ? >> What discourse complexity level can allow to address these needs ? >> What discourse representation technology fits these "required language" ? > > I think it is problematic to think only in terms of linguistic discourse; we need to think in terms of conceptual truths as well\. Infection with plasmodium parasite leads to malaria, no matter what language it is written in; certain kinds of polyps in the colon increase the risk of bowel cancer, no matter what language\. "Ontologies of reaility" as I call them should be \(more or less\) linguistically independent\. The problem is to agree on one or more good quality ones\. Then archetypes have something to work with\. Unfortunately, I fear that the Snomed\-ct developers are losing sight of what a good terminology is and trying to jam many incorrect concepts into it\. Hi Tom, Aren't we talking on orthogonal axis ? What I meant with "discourse structure" is, for example, the formal way you can describe a colonoscopy report\. It is a huge Archetype, or rather a set of linked Archetypes\. The reason why I call it "discourse structure" is because I really think it is important to see any medical information as a "story part", in some kind of fractal way : the polyp \(and its description, maybe its ablation\) is a very small story inside the "colonoscopy" larger story, inside the "patient history" journey\. So, thinking in term of "discourse structure" just means you envision all this, and take care to be homogeneous at any level\. Of course, this terminology is close from the natural language one\. My vision is that a good natural language translation system must have two levels : an "analysis layer" that transform the input discourse into a formal language independent representation \(FLIR\), than a "synthesis layer" that transform this FLIR into an output natural language\. In my opinion, our goal really is to see the medical information we store as a FLIR\. The FLIR is made from a discourse structure populated with terms from an ontology\. This ontology can be: a concept list \(level 0 : no predicate\) a semantic network \(level 1 : level 2 predicates : isA\(colitis, inflammatory disease\)\) or more complex relationships ; I think that your "Ontology of reality" is of the kind\. Currently, I must confess that my ideas are just clear enough concerning the semantic network\. Because it is a genuine "root component" you can use everywhere\. a given decision support system \(DSS\) technology\. To be more accurate, for the examples you gave, you could want to address the follow up of this "bad polyp" by instantiating a Bayesian network or just a decision tree\. The formal representation is much different\. My idea has been to build a "formal description", like the FLIR of a medical encyclopedia entry for this polyp\. It is \(quite\) easy and useful for drugs, because you can get standard chapters such as "indications, contra\-indications, bad interactions"\. But for symptoms or diseases, it is much harder\. Currently I decided no longer to work on that, and use a "band" of smart agents, each one with its specific knowledge and its specific DSS technology, rather than building a more general expert system using a level X ontology\. Well, quite a long post\. Sorry to take your time when you release V 1\.0\. And felicitations to the openEHR team for this\. Cheers, Philippe --- **Canonical:** https://discourse.openehr.org/t/dictionary/14507 **Original content:** https://discourse.openehr.org/t/dictionary/14507