3 Questions about GRAIL3.1 What is GRAIL?
3.2 Why is GRAIL important?
3.3 Why is it so complicated?
3.4 Do you always need the full power of GRAIL? Can't there be some kind of GRAIL-lite?
3.5 What does being compositional mean?
3.6 But isn&'t SNOMED compositional?
3.7 What does being generative mean?
3.8 Isn't GRAIL just another conceptual modelling scheme like Martin-Odell?
3.9 Isn't GRAIL just another KR language?
3.10 Is GRAIL object oriented?
3.11 Is it finished?
3.12 How do you get round the absence of certain features in GRAIL?
3.13 What measures for complexity are there?
3.1 What is GRAIL?
GRAIL - the GALEN Representation And Integration Language - is the concept modelling language (or formalism) that has been developed in the GALEN Programme; it is being used to build the GALEN Common Reference Model.
GRAIL is a formal system, which we use to represent all and only sensible medical concepts in a form suitable for effective computer-based use.
GRAIL is a compositional and generative semantic network knowledge representation language, which has many similarities and many unique distinguishing features to other such languages which have developed out of the Artificial Intelligence community. GRAIL and its predecessors were developed specifically to support the problems that were encountered in trying to build effective clinical systems systems that would be able to represent and manipulate detailed clinical information about patients, at a level of detail sufficient to support routine day-to-day clinical care.
GALEN succeeds in bridging the gap between coding schemes for categorising medical information, and clinical language used in day-to-day care, because it is built on a formal language: those facts that are implicit in human communication are captured in a formal way so that the computer can reason with them. GRAIL defines the rules of classification: why pneumonia should be classified both as an infection and also as a lung disorder, or why a fracture of the neck of the femur should be classified as "something wrong with the leg".
The rules of GRAIL define the rules of classification; the implementation of GRAIL within the GALEN Terminology Server allows the GALEN Common Reference Model to be built in a declarative way. Traditionally, building a coding and classification scheme has demanded that the author(s) specify each clinical concept, and then manually assert or enumerate how they relate to each other. In contrast, GRAIL allows the GALEN Common Reference Model to be built by having the modellers (or authors) specify a number of primitive concepts, describe their properties, and create additional, complex, concepts in terms of others already present. The GRAIL implementation then automatically organises the classification (or inheritance hierarchy), according to those facts that are known. This ensures that the classification is complete, and furthermore, additional axes of classification can be defined at any point even after the model is delivered.
The use of GRAIL allows the computer to actively help in the enormously complex task of building and maintaining a clinical terminology that is detailed and complete enough to be usable to support day-to-day clinical care.
GRAIL is necessarily complex, and therefore takes time to come to terms with though people now routinely learn to use it from scratch with a few weeks training and practice. However, it is only as complicated as we have found it needs to be. The problem seems to be that the medical domain is complex and medical language, like all natural language, is slippery. Clinicians use concepts so naturally that it is hard to explain what they do. We suspect that the complexity is unavoidable and a major part of the reason that effective clinical systems have proved to be so hard to build and integrate in practice.
GALEN aims to take some of this complexity off the hands of individual system builders by providing terminological services they can access. Because we are offering a novel service, there will inevitably be an initial learning curve for applications to be able to fully exploit the GALEN Technology. Open GALEN provides training, education and consultancy services to overcome this issue.
Similarly, because GRAIL is different, modelling with it (building GRAIL knowledge bases) is also different; we have had to develop new methodologies and tools to support effective modelling. The good news is that we seem, empirically, to be getting better at explaining the features and properties of GRAIL to both modellers and application builders.
It is important that, internally, the full power of GRAIL is maintained. However, there are two pieces of good news. The first is that provision of the GALEN Common Reference Model via the GALEN Terminology Server means that the power of GRAIL is available to application developers without them having to implement GRAIL.
The second piece of good news concerns the problem of scaling up the GALEN Common Reference Model itself to cover the whole of medicine, and to map to innumerable different existing coding and classification schemes. In this regard, we now consider GRAIL to be something of an assembly language; most of the interaction that clinicians need to have (for example to define new clinical concepts, or to map them to systems like ICD-10) is done with a higher level language, or intermediate representation, which is then automatically translated into the underlying GRAIL language (which is then interpreted by the GALEN Terminology Server). The intermediate representation acts as an additional layer of abstraction: making it easy to involve clinicians in the authoring process (tools have been developed that take only a day or so to learn), whilst still allowing us to take full advantage of the underlying GRAIL formalism.
GRAIL models unlike traditional coding systems are not enumerated lists or trees of hundreds of thousands of phrases. Rather, GRAIL models consist of a limited number of around 10,000 elementary concepts, a set of attributes (or linking relationships), and a series of rules which specify how individual elements may be combined to give complex concepts. Being able to combine concepts into arbitrarily complex concepts (or descriptions) is the feature of being compositional.
Yes, it is. However, there are rather significant differences between the notion of compositionality in SNOMED and GRAIL. Firstly, SNOMED is only partially compositional in that elements from the different axes of SNOMED may be combined, but those axes themselves are built traditionally from a tree of enumerated SNOMED codes. Secondly, the semantics of combining SNOMED codes is only partially defined; what is actually meant by the juxtaposition of two codes? SNOMED does not include a set of linking relationships by which the nature of a link between two concepts can be made explicit. Collecting a number of codes together says that they are related in some way, but not how. Thirdly, any SNOMED codes can be combined, allowing the production of composite codes representing medical nonsense. Fourthly, SNOMED composite structures cannot easily be classified into hierarchies to facilitate information retrieval and use by decision support systems. GRAIL addresses all of these problems.
At present, it is unclear as to how, or to what extent, SNOMED-RT (the next version of SNOMED, currently in development) and the GALEN Technology overlap, or how they could be made to do so.
In an unconstrained compositional system, any codes or concepts can be combined - whether or not the resulting expression makes medical sense. One approach to this problem is to say that in practice clinicians will not make nonsensical combinations, so theres no need to worry. However, this means that the computer system cannot provide much help to the clinician at the user interface. It cannot anticipate what the clinician might want to do because it does not have the information on what is sensible. It cannot validate expressions because it doesnt know what is allowed.
GALEN's approach is to represent explicitly in the model what it is medically sensible to say. What is not explicitly sensible is considered nonsense and disallowed e.g. "abscess of blood" or "fractured eyebrow". No concepts in GRAIL can be combined until the knowledge known as sanctions that they are sensible has been added to the model. This has two major effects.
The first effect is the confidence and integrity that results from the knowledge that all complex concepts represented in patients medical records are medically sensible. The second effect is that the resulting model is much more powerful, in that it can now answer questions such as: "given this concept, how could it be combined with others". This is equivalent to the question "how could I sensibly describe this concept?", which has proven to be an essential one for the production of effective clinical interfaces.
GRAIL models are generative in that they can answer such questions; given a model consisting of elementary concepts and sanctions, we can in principle generate all those combinations that are sanctioned by the model i.e. those that are medically sensible. However, the total number of such sensible combinations would be several billion billion. Instead, we supply end-users with a relatively small, pre-generated set of obviously common and useful combinations and they can then add those extra ones they need, when they need them. They arent limited to a fixed list of phrases (as in a traditional scheme) but nor are they overwhelmed by the huge numbers possible in a compositional scheme.
(Name your favourite systems design or object oriented analysis methodology UML, Coad-Yourdon, IFO, NIAM, ...)
GRAIL models and the conceptual models for databases and information systems are intended for different but overlapping tasks. The high levels of a GRAIL model are related to the entity-relationship modelling parts of information system design methodologies, but the lower levels of GRAIL models provide much finer grained detail and more knowledge. Roughly speaking, GRAIL models are about the concepts that go in the boxes on database or information system conceptual models. Or conversely, conceptual modelling for databases and information systems is about how you link together GRAIL concept representations in an information system. GRAIL is also much more specialised. It is concerned only with concepts. There is nothing comparable, for example, to data flow diagrams or the other tools of overall design methodologies.
In general, the two types of models are used differently. GRAIL models are dynamic implementation tools which often form part of systems implementations. They are only useful with GALEN Terminology Servers to manipulate them. By contrast, conceptual models are largely static design tools usually presented as diagrams on paper, possibly with the aid of editing or prototyping tools.
There is an overlap, however. Some things can be done either way. With the advent of object oriented databases, this relationship of the two types of modelling is evolving rapidly. Several experiments are under way to explore the inter-relationship of the two types of methodologies and establish guidelines for which to use when.
Isn't GRAIL just another KR language?
GRAIL is a knowledge representation (KR) language; as described earlier, it has lots of features similar to KR languages (sometimes also known as description logics) such as KL-ONE, CLASSIC and BACK. However, it has been developed specifically to support the requirements of medical terminology, and has specific features to provide that support; for example, its handling of partonomies and the integration of multiple classifications for different purposes is unique, as far as we have been able to determine.
GRAIL may be useful as a general purpose KR language, and separately funded work is taking place to examine its use in other environments outside of medicine. However, within the GALEN Programme we are interested in it to support our high-level requirements for building effective clinical information systems. All we can say now is that it is proving its use in medicine.
Yes. Strongly, although to avoid confusion we use the words "entity" instead of "object", "category" instead of "class", and "individual" instead of "instance". (Some of this labelling is historical: a good deal of the prototype GALEN software was implemented in Smalltalk - almost the original object oriented language. The developers needed to know when they were talking about GRAIL, and when they were talking about the underlying implementation language.)
3.11 Is it finished?
Yes and no.
Yes, in that a specification exists and has been implemented in several different versions of GALEN Terminology Server. Implementations are now available for use, and are being used, to support clinical systems at the point of care.
No, in that there are some features that were deliberately left out of the current version of GRAIL, but which, ideally, would be present. An example is a more complete treatment of negation. Without it, there has to be some compromise in the style of modelling of the GALEN Common Reference Model.
Research is continuing into additional features for GRAIL: their specification, and determination of their impact on complexity and performance. In addition, research is continuing in new implementation techniques for the language as a whole.
As mentioned in the answer to the previous question, negation is not handled natively within the current version of GRAIL. In the meantime, there is a special construct used in the implementation of the GALEN Common Reference Model using presence and absence which provides a limited form of negation sufficient to represent most of the concepts found in existing coding systems.
This is a typical way in which we can use GRAIL, even with its known limitations: what it does have more than compensates for what it lacks!
GRAIL is a novel formalism for representing clinical concepts. Because of this, traditional measures of size and complexity how many codes do you have - do not relate effectively to its structure. For example, given a limited size of elementary concepts and sanctions, the model may sanction (or allow to exist if required) very many more complex concepts the real coverage of the model. As modelling in GRAIL develops in size and scope, we are working on developing sensible and relevant measures of complexity. It seems, for example, that the inter-connectedness, or density of the model is a more important criterion for performance than sheer number of concepts apparent in the model.
At present, a more useful indicator of current performance is that the implementation is keeping track with the scale of the GALEN Common Reference Model.
Formal measures of complexity are also invaluable; for example, complete terminological classification in some other, similar formalisms has been shown to be computationally intractable. In designing GRAIL, we have used two strategies to ensure we will end up with a usable system. The first is to be very careful what features we allow in the formalism we chose not to implement a notation for full first order logic, for example, due to its well-known computational properties.
Secondly, our criterion for success is for real-world usefulness and not necessarily for philosophical perfection. If, most of the time, the models built using GRAIL exhibit acceptable performance properties, we will be content, especially if we can spot in advance the cases which will give poor performance. This is not an abdication of academic principles, rather a pragmatic realisation that a partial solution to an inherently difficult problem may be, in itself, useful.