This may be of interest. In the current press release there's some talk of SNOMED (Systematised Nomenclature of Medicine)
http://www.nehta.gov.au/component/option,com_docman/task,doc_download/gid,66 /Itemid,139/ Quoting from the article: --------------------------- SNOMED has been used to date in over 40 countries, and the US, UK and Danish governments have also decided to use SNOMED as their national clinical language. The use of SNOMED means that Australia is not reinventing the wheel by developing a clinical language from scratch; Australia will be in line with what equivalent nations are doing around the world. Since then, NEHTA has been working closely with international groups to ensure that SNOMED is openly governed and maintained, and can be made widely available within Australia at no cost to users. --------------------------- Not fully understanding the discussion so far, I'm still wondering whether or not this may be the dictionary you talk of? Cheers Tom ________________________________ From: Thomas Beale [mailto:thomas.be...@oceaninformatics.biz] Sent: Saturday, 11 February 2006 1:03 AM To: openehr-technical at openehr.org Subject: Re: dictionary 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 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/terminol ogy.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
