Abstract not found

The European GALEN project is developing terminology services based on a large, re-usable medical ontology. The ontology is being built using GRAIL, a description logic with transitivity and general concept inclusions.

Despite years of work, no re-usable clinical terminology has yet been demonstrated in widespread use. This paper puts forward ten reasons why developing such terminologies is hard. All stem from underestimating the change entailed in using terminology in software for ‘patient centred ’ systems rather than for its traditional functions of statistical and financial reporting. Firstly, the increase in scale and complexity are enormous. Secondly, the resulting scale exceeds what can be managed manually with the rigour required by software, but building appropriate rigorous representations on the necessary scale is, in itself, a hard problem. Thirdly, ‘clinical pragmatics ’ – practical data entry, presentation and retrieval for clinical tasks – must be taken into account, so that the intrinsic differences between the needs of users and the needs of software are addressed. This implies that validation of clinical terminologies must include validation in use as implemented in software. Why-is-terminology-hard-single-r2.doc 14/01/00 15:21 2 1.

A common language, or terminology, for representing what clinicians have said and done is an important requirement for individual clinical systems, and it is a prerequisite for integrating disparate applications in a distributed telematic healthcare environment. Formal representations based on description logics or closely related formalisms are increasingly used for representing medical terminologies. GALEN's experience in using one such formalism raises two major issues: . How to make ontologies based on description logics easy to use and understand for both clinicians and applications developers; . What features are required of the ontology and description logic if they are to achieve their aims. Based on our experience we put forward four contentions: two relating to each of these two issues: . That natural language generation is essential to make a description logic based ontology accessible to users; . That the description logic based ontology should be treated as an `assembl...

The GALEN prALogramme has been developing medical ontologies collaboratively for nearly a decade. The ontologies are large and formulated in a specialised description logic, GRAIL. The programme is a broad collaboration of over a dozen groups, most with no prior experience of developing formal ontologies. The programme has developed a methodology for loosely coupled development using layers of intermediate representations, guidelines and tools which minimises training requirements for domain experts and effort by central knowledge engineers. Issues arise both from problems in formal representations and from the idiosyncrasies of the medical domain. Issues dealt with include ‘tangled ’ taxonomies, part-whole and locative relationships, defaults and exceptions, semantic normalisation, and the difference between medical convention and strict logical criteria for correctness. Keywords: Cooperative development; ontology development; ontology design; very large ontologies, medical

GALEN seeks to provide re-usable terminology resources for clinical systems. The heart of GALEN is the Common Reference Model (CRM) formulated in a specialised description logic. The CRM is based on a set of principles that have evolved over the period of the project and illustrate key issues to be addressed by any large medical ontology. The principles on which the CRM is based are discussed followed by a more detailed look at the actual mechanisms employed. Finally the structure is compared with other biomedical ontologies in use or proposed.

Our goal is to provide trusted re-usable knowledge resources for users in specialized domains such as biomedicine. Such users ’ requirements go beyond ‘ontologies ’ in the narrow sense of the word – and certainly what can be expressed simply in OWL-DL or even OWL-Full. They include defaults and exceptions that can only be met by taking the notion of ‘prototype ’ seriously, and both metaknowledge about the representation and higher order knowledge about the concepts represented. Such users also need information more naturally queried under closed world semantics than under OWL’s open world semantics. 1