ELSEVIER
SCIENCE
IRELAND
International Journal of Bio-Medical Computing
34 (1994) 85-94
Computing
Clinical workstations: identifying clinical
requirements and understanding clinical information
W. Anthony Nowlan
Medical Informatics Group, Department of Computer Science and Department of Public Health and
Epidemiology. University of Manchester, Manchester Ml3 9PL, UK
Abstract
A preliminary exploration
draws the bulk of its content
of the problem of defining and meeting users’ needs, this paper
from experiences in the PEN&PAD project in the UK. This pro-
gram has been researching and developing prototype clinical workstations for direct use in
patient care by health care professionals, chiefly doctors. Focusing more on general issues
rather than the specific functional requirements embodied in the PEN&PAD prototypes, the
paper begins with a brief summary of the goals of PEN&PAD and then outlines the three
main axes of the work: user-centred design, medical concept and medical record models, and
user interfaces and architectures. The remainder of the paper then concentrates on the first
of these topics - working with users to define functional requirements.
Key words: Workstations; Functional requirements; Clinical information;
ment; User-centred design; Computer-based patient records
1. Goals of the PEN&PAD
System develop-
programme of work
The PEN&PAD
programme
has been developing
workstations
for doctors,
nurses, and other health care professionals which they should find useful and usable
for the direct care of patients [l-3]. The aim is that users should find the system simple and intuitive to use, while at the same time it should be capable of coping with
the diversity and complexity
of clinical practice and clinical information.
The
PEN&PAD programme began in late 1988 in general medical practice in the UK,
and last year was extended to the hospital setting, beginning with the shared care
of the elderly. Several aspects of the work that started within PEN&PAD have now
developed into separate but related projects. Most notable of these is the work on
compositional
systems for representing
medical concepts within the GALEN* project on advanced medical terminologies.
*GALEN - Generalized Architecture for Languages Encyclopaedias and Nomenclatures in Medicine,
is part of the European Community’s Advanced Informatics in Medicine (AIM) initiative.
OC20-7101/94/$07.00 0 1994 Elsevier Science Ireland Ltd. All rights reserved.
SSDI 0020-7 10 I (94)00900-3
W.A. Now/an /ht.
86
J. Biomed. Comput. 34 (1994) M-94
The prime requirement is for systems that support the use of detailed clinical information for the care of individual patients by medical professionals. Such systems
are qualitatively different from more general information systems used for health
care administration or epidemiological studies on populations of patients. A clinical
system must cope with the scale, detail, and complexity of information required for
clinical medicine. However at the same time it needs to be simple and intuitive to
use on a routine basis across a range of clinical settings. These requirements are complex and frequently conflict, as exemplified by the following three mutually contradictory statements that arose during discussions, with clinicians, of requirements
on clinical systems:
‘obviously the patient having leukaemia is a big problem, so I want to know all
about it’
‘it shouldn’t trouble me with all the silly sore throats’
‘it should flag if the patient has had a lot of nasty sore throats recently because
that could indicate an underlying problem such as an immune disorder or
leukaemia’
The premise within PEN&PAD is that such requirements can only be addressed if
in some way an information system’s behaviour is guided by the meaning of the information it is manipulating. It is this relationship between behaviour and meaning
which characterises the intelligent interface.
In order to work towards intuitive or intelligent clinical systems it is necessary to
have both ways for understanding what health professionals need and techniques
that can meet those needs. Both of these have proved hard to establish. In the
PEN&PAD programme the result of struggling with these challenges has been three
broad areas of work covering:
0
??
0
user-centred development and supportive evaluation - ways of working with
clinicians to define functional requirements and test solutions;
medical terminologies, medical records and the representation of medical concepts in formal systems that can capture and interpret much more of the clinical detail in a structured form; and
user interfaces and user interface management systems - architectures that try
to integrate the behaviour of the system with the medical meaning of the information to produce more intuitive systems.
This paper will concentrate on the first stream of the work. The other two will be
discussed in as far as they illustrate our perceptions of the technical problems faced
in meeting user needs, and in particular the requirements on the medical record.
2. Working with users to define and test functional requirements through supportive
evaluation
This section discuss the technique of supportive evaluation that was adopted and
developed by the PEN&PAD programme. The aim of supportive evaluation is to
W.A. Nowlan /ht.
J. Biomed. Comput. 34 (1994) 85-94
81
help designers identify key functional requirements and then test their design solutions through the use of rapid prototyping. The section begins by discussing the apparent problem with doctors, and their reluctance to use information technology.
This is then followed by an account of supportive evaluation and some of the lessons
learnt by working with doctors within PEN&PAD.
2.1. Where are the systems and why is it all so dijjkult - are doctors technophobic?
Doctors have often been described as resistant to using computers, and numerous
surveys (e.g., Ref. 4) have purported to show doctors’ negative attitudes towards
computers. Indeed, the difficulty of producing information systems which doctors
are willing to use has frequently been cited as the major barrier to the wider use of
computers in medical care [5]. However, doctors are enthusiastic users of other new
technology such as computer-based diagnostic imaging systems. Furthermore, a recent survey in the UK reported that although relatively few doctors use computers
in the course of the medical practice, more than half of all doctors use computers
at home [6].
How can this discrepancy be explained? It is all to easy to blame the doctors for
these difficulties, adopting an attitude which might be caricatured as ‘pearls before
swine’. The alternative explanation for this lack of success is that our systems have
rarely actually met medical requirements or been usable in clinical conditions - an
attitude which might be caricatured as ‘the emperors’ new clothes’. The second attitude is far more constructive for members of the informatics community, because it
leads to important consequences for the development process. Doctors find existing
systems neither sufficiently useful nor easily usable to justify the effort required to
use them, whatever their feelings towards computers in general. One possible solution to these inadequacies is to involve doctors more extensively in the development
process. However, mere involvement is not enough, since most projects claim to have
involved users, yet the problems persist. User-centred development and supportive
evaluation is an attempt to take the ‘emperor’s new clothes’ attitude seriously.
2.2. User-centred development and supportive evaluation
User-centred development aims to involve doctors in the development process
from its earliest stages. The methods are adapted from work by many others including Monk [7], Mumford [8] and Norman and Draper [9]. These methods have
led to an iterative process of rapid prototyping and formative evaluation in which
user participation is an integral part. We refer to this as supportive evaluation. The
supportive evaluation methodology makes a distinction between formative and summative evaluation [lo]. Formative evaluation is undertaken for the development
team and aims to support them in refining the functional requirements and thus improving the design. Summative evaluation is carried out either for the development
team or for external agencies to determine whether or not the project has reached
pre-defined criteria. Formative evaluation is an integral part of the development
cycle and is also used to refine the methods employed in the summative evaluation.
The whole process involves several cycles of development and evaluation. Each
cycle consists of: (i) functional requirements analysis and design workshops; (ii)
development of prototypes; (iii) formative evaluation workshops evaluating the
prototypes.
88
2.3. The participants
W.A. Nowlan/Int.
J. Biomed. Compui. 34 (1994) M-94
in the workshops: users, designers, and evaluators
The workshops involve three groups: (i) the users who are doctors; (ii) the development team who produce the prototypes; (iii) the evaluation team consisting of
psychologists and associated observers.
The user-centred development strategy employed by the PEN&PAD project relies
on the long-term involvement of doctors. These are described in terms of four
categories of doctors: (i) one doctor is employed full time as a member of the development team; (ii) an ‘inner circle’ of five doctors provides the primary input to
the design process. They are paid a small amount to participate in workshops and
consultation sessions; (iii) an ‘outer circle’ of twelve doctors participates in major
formative evaluation workshops which are held at roughly six-month intervals; (iv)
a group of initially eight and later 32 ‘naive users’, doctors with no prior connection
with the project, participates in the occasional ‘quasi-summative’ evaluations which
mark the end of major stages in the project.
The evaluation team is separate from the development team, but participates in
many of the project planning activities. They are, in general, viewed by the development team as colleagues and allies, although they also have a separate responsibility
to prepare a final evaluation report for the funding bodies.
2.4. The requirements
-
analysis and design workshops
Each requirements-analysis workshop consists of a discussion led by the clinical
member of the design team, in which usually the ‘inner circle’ of doctors discuss specific issues with the occasional participation of other members of the development
and evaluation teams. Each workshop is dedicated to a specific topic based on
materials prepared by the doctors, and aims to provide first-cut functional requirements for the design team.
2.5. The formative evaluation workshops
The formative evaluation workshops make use of prototype systems. They follow
a much more standardised format and are led by the evaluation team. The doctors
work in pairs, together with a member of the development team and an observer
from the evaluation team assigned to each pair. Following a demonstration and a
series of training tasks, each pair of doctors is given specific ‘evaluation tasks’ to perform in which one user takes the role of ‘patient’ and the other the role of ‘doctor’
in a simulated consultation using scenarios prepared and negotiated by the design
and evaluation teams. Following the evaluation tasks, the doctors complete a short
questionnaire and structured interview schedule. Throughout the training and evaluation tasks, the members of the development team are restricted to providing only
‘on-line help’ in order to let the doctors complete their tasks. Members of the development team are not allowed to discuss the reasons for different features of the
design and are not, above all, to argue about whether or not particular features are
sensible, easy to use, consistent, or convenient.
A group discussion follows the evaluation exercise, first with the clinical users
only, and then with the full participation of members of the development team. Time
permitting, there is a final, brief, brain-storming session to capture any new ideas
which might have been stimulated by the day’s activities. Following the workshop,
there is a debriefing session for the development and evaluation teams to gather the
W.A. Nowlan /ht.
.I. Biomed. Compur. 34 (1994) 85-94
89
immediate responses and impressions followed by more formal analysis and feedback from the evaluation team.
3. Results, problems and limitations of the user-centred development process
3.1. Education of the development team: formative evaluation as process not product
The most important result of the user-centred development process was that the
development team came to understand the doctors’ problems. This effect is difficult
to quantify, but there is unanimous agreement amongst members of the development
team that the workshop process has been instrumental in overcoming their
misconceptions concerning medical practice and doctors’ needs. The workshops are
dramatically more effective in achieving this than mere demonstrations, in which the
same team frequently takes part. Watching users attempt to achieve realistic tasks
with the system is a very powerful motivator to remove problems.
The most dramatic example of the development team learning about the users’
needs has been the acceptance of the extent of user variability. Developers inevitably
look for the ‘best’ way to complete a task and become attached to their pet notions.
Invariably we have found that some situations, or some users, require an alternative.
The workshops are also effective in keeping the development team focused on the
doctors’ priorities - ‘keeping their feet on the ground’. All development projects
have a natural tendency to create their own agendas. Each workshop provides a
valuable corrective.
3.2. Specific results
The evaluation workshop produces three types of output: (i) ‘micro-level’ diagnostic comments on particular ergonomic details; (ii) ‘midi-level’ comments which tend
to be comparative and relate the current implementation of some large subsystem
(such as data entry or chart handling) to its previous implementation; (iii) ‘macrolevel’ comments which assess the impact of the system on the wider clinical
environment.
The workshop tasks are designed primarily to elicit midi- and macro-level comments, but most workshops uncover a number of micro-level problems. The microand midi-level comments are system specific. There are, however, two important
general macro-level results:
0
a
There is no one best way. Medical practice is enormously complicated, and
users are highly variable. Problems cannot be solved by imposing uniformity.
It is necessary to cope with diversity.
Simple clear presentations are often more effective than sophisticated attempts
to provide intelligent summaries. Doctors are remarkably good at recognising
patterns if the information is clearly presented.
For the development team, the most important outcome of the user-centred process is the first of these macro-level results: the realisation of the range of variability
of users and of medical situations. The most obvious example is that without the
user-centred process, the project would almost certainly have followed its original
remit and produced a system which could only be used with a mouse. The approach
90
W.A. Nowlan /ht.
J. Biomed. Comput. 34 (1994) 85-94
is now far more eclectic with a goal that functions should also be accessible from
a keyboard.
The variability goes beyond ergonomics and styles of interaction to include medical diversity. Health professionals believe they have a wide range of opinions, objectives, and ways of working. In contrast, most of the design team came to the job with
the idea that medicine is a clear-cut deterministic activity, and that health professionals all share the same functional requirements. The experience within PEN&PAD is
that neither of these extreme views is correct. Health professionals have more in
common than they will often admit to, but they are far more diverse than the
stereotypical pictures painted by naive system designers. Above all else, it is this diversity that has driven much of the technical agenda within PEN&PAD. The system
must be able to cope with the major differences in clinical approach and content required by different users and clinical problems. Clinicians need to be able to extend
and adapt the system smoothly without compromising its integrity. For example, it
is essential that the system be able to maintain different protocols for different doctors, patients, and practices, or for research groups to integrate the collection of
information for clinical trials with routine patient care.
3.3. Problem space versus solution space: or ‘users are always right . . . except when
they’re wrong’
The most serious problem with involving users actively is how to treat the
multitude of requests and ideas which emerge. Users’ groups are notorious for
generating endless lists of requests, or ‘wish-lists’, which suppliers cannot hope to
meet. The PEN&PAD approach to at least mitigating this problem is to divide the
conceptual space into two parts: (i) The problem space which is the province of the
user. The problem space is concerned with the needs of the users in terms of their
functional requirements, the variability that exists in those requirements, and the
usability or acceptability of the system, which can be discovered only by evaluating
the use of the system. (ii) The solution or design space which is the province of the
development team. The solution space is concerned with the creative design ideas
generated by the developers and the constraints of practicality and feasibility implicit
in the technology in which those ideas are implemented.
Users are always right about the problem space. If users say they cannot understand something or that they need to do something - for example that they do not
understand the meaning of command buttons or if they say that they need a scratch
pad - then they must be believed. As obvious as it seems, there is no point in arguing with somebody about whether or not they understand something or find it easy.
We have frequently observed developers doing precisely that when users failed to
appreciate one of their pet features. Despite the rules that developers were only to
act as on-line help during the exercises, there were times when they could hardly restrain themselves. Observations of other groups and demonstrations suggest that our
group is far from unique.
However, users are usually wrong in their suggestions as to how best to meet their
needs or remedy a problem. Users’ comments are usually concrete and framed in
terms of the problem space, whereas a good design solution is likely to be abstract
and must be framed in terms of the design space. Repeatedly, users’ requests which
were superficially simple, turned out to hide a multiplicity of functional require-
W.A. Nowlan /ht.
J. Biomed. Comput. 34 (1994) 85-94
91
ments. A good example is the tool for writing prescriptions for medication. The formative evaluation workshops produced numerous criticisms about the time taken to
prescribe a drug because of the number of ‘mouse-clicks’ needed. Design modilications were suggested by the users. Several of these were tried with no benefit, and
often the situation worsened, even though fewer mouse-clicks were needed. Unfortunately the basic structure of the task had been formulated incorrectly. The doctors
had suggested using a standard therapeutic classification to organise the drugs for
presentation on the screen. However, this meant that doctors were frequently being
forced to think about therapeutics when all they wanted to do was record what they
had already decided. Hence, the whole process felt slow and unnatural. An alternative tool based on an alpha-sorted index was tested but this brought complaints
about the lack of medical structure. The tool is now a hybrid of navigation via therapeutic groupings, keyboard lookup, and picking from lists, all controlled by a
dialogue manager, that is based on a detailed structured model of drug concepts. The
tool is technically complex but users have found it the most simple and ‘quickest’
to use.
3.4. Difficulties with the prototyping process
The use of prototypes gives rise to a number of intrinsic difficulties. Users and outside observers have difficulty determining which parts of a prototype are real and
which are simply well-crafted mock-ups. More significantly, users find it difficult to
distinguish between those features of a prototype which the development team expects to carry through to later versions and those which are merely accidents of the
prototype. The result can be that the users spend much time discussing things of no
relevance to the further design of the system.
In a similar way, the medical content of the scenarios and the prototypes may
cause controversies which obscure the issues that the evaluation and development
teams wish to explore. For example, a workshop intended to explore various alternative presentations of clinical protocols can easily be side-tracked by discussion of the
controversy concerning how moderate high blood pressure should be managed.
Having a doctor as a member of the design team is essential to recognising and
handling such situations.
The biggest defect in the user-centred strategy is that none of the users ever
becomes really expert in using the system. There is an enormous difference between
using the system for a few hours during a formative evaluation workshop and using
it routinely, several hours per day, five days per week. Aware of this, the project has
embarked upon a series of practice-based formative evaluations where systems are
installed in friendly practices and used by the doctor in sessions with real patients.
An overall limitation is the ability of the development team to respond to change
as the scale of the development increases. At the start of the project the prototyping
cycle took about two months. Now as the prototypes have grown the cycle time is
closer to one year. There is a tension between the innovative flexibility that is a
characteristic of a rapid prototyping approach on the one hand, and the need for
proof of concept and real systems on the other hand. There are large areas of uncertainty in the development of medical workstations and flexibility during the design
phase is essential. However, there are growing pressures on medical informatics to
‘deliver’ the systems. In any programme of work in this area a balance is required.
92
W.A. Nowlan/Int.
J. Biomed. Comput. 34 (1994) 85-94
4. Fundamental requirements on the medical record
The user-centred design process has emphasised the many different functions performed by clinical records in patient care and underlined the limited focus of many
existing electronic medical record systems. This has required a re-examination of the
fundamental principles and assumptions underlying the medical record. The details
of these requirements and the design within PEN&PAD are given elsewhere [ 111.
The following considers briefly those we feel are essential for meeting clinicians’
functional requirements.
4.1. The medical record: a faithful and structured record of patient care
The design of many existing electronic medical records derives, implicitly or explicitly, from support for the use of aggregated data for research, audit, finance, or
planning. Such designs are inappropriate for a record for clinical use and, ultimately,
inadequate. While the use of aggregated data presents important requirements to
any medical record system, clinical information, as it is generated and used during
patient care, is the only sound basis for a model of the medical record. Also, this
information must be structured if the system is to be active in organising information
for the clinician. Hence, within PEN&PAD the requirements on the medical record
are based on two fundamental assumptions: (i) the principle purpose of the medical
record is to support individual patient care; (ii) all clinical information will be held
in a structured representation which can be manipulated by the information system.
Faithfulness to the clinical history and care of the patient is the fundamental
criterion for the record. The goal of developing analyses and models for the medical
record is, therefore, to create an architecture for structured information which is
both faithful to the process of clinical care and adequate for the other uses of the
information collected. This view of faithfulness has two major consequences: (i) The
information in the medical record itself is not about what was ‘true’ of the patient,
but about what was observed and believed by clinicians. We can make inferences
about what was ‘true’ on the basis of these observations with greater or lesser contidence depending on the circumstances, but these are only inferences. (ii) The model
of the medical record should be descriptive rather than prescriptive. The function
of the record is to record what was observed; the description of what was actually
observed cannot be constrained to tit within a predefined view of what ought to have
happened.
As a result of this view of faithfulness we now distinguish amongst three types of
model in PEN&PAD: (i) the information model of the medical record - what can
be said; (ii) the process model of clinical care -what ought to be said; (iii) the inferred model of the state of the patient - the clinician’s view of the true state of the
patient.
The first model is concerned with medical terminologies and what it is sensible to
say. The second is more pragmatic knowledge about what it is usual or required to
say, based on for example a protocol for the management of a particular disease.
The third model rests with the clinician. In order to meet functional requirements
it is essential to distinguish between these models. For example, it is perfectly possible to have many different process models reflecting different requirements, but all
based on a common information model.
There are several more specific requirements that result from the need for
W.A. Nowlan / Int. J. Biomed. Comput. 34 (1994) 85-94
93
faithfulness. These are detailed elsewhere [l l] but some of the key ones are:
Attributability - every observation must be made by an agent at a particular
place and time.
Permanence - the fact that an observation was made at a particular time and
place is not affected by the fact that it was later found to be incorrect.
Accept uncertain and negative statements - observations can be negative or
uncertain as well as positive. Pertinent negatives and uncertain observations
can be critical to clinical decisions and can have important legal consequences.
Allow expression at clinician’s natural level of abstraction - the clinician’s
observations must be recorded in the form in which they are made, if the record
is to be faithful to the process of care. Clinicians freely mix statements about
symptoms, signs and diagnoses at various levels of abstraction and detail. Our
experience is that a clinician finds it natural to find terms of different levels of
diagnostic precision occurring within the same list of choices, for example
cough and acute bronchitis.
Allow descriptions to an arbitrary level of detail - for clinical care, the medical record should record information at the level of detail at which it was
observed. The basic concepts must be capable of being described to the
required level, for example, that the diabetes has been poorly controlled during
the past three weeks or that the fracture was severe, painful, and cornminuted.
4.2. Technical approach
The technical approach to meeting users’ requirements has not been discussed in
this paper. The key premise is that systems can only hope to match clinical requirements if they are in some sense ‘intelligent’. The behaviour of such an information
system must be guided by the meaning of the clinical information being manipulated.
Within PEN&PAD such behaviour rests on a faithful model of the medical record
implemented using a novel representational formalism that tries to integrate the
medical information with the behaviour of the system [12-141. The overall result is
technically complex but we believe this is a prerequisite to building systems that have
some of the characteristics that make their use by clinicians intuitive.
5. Conclusion
The PEN&PAD project has tried to take a fresh look at the task of defining functional requirements and developing clinical systems. Work with users has emphasised the great diversity of needs whilst reinforcing the requirement for an integrated
framework. However, the single most important outcome of the user-centred development process is the mutual understanding between the clinicians and the design
team. This has allowed the designers and users to discuss requirements in terms of
what the user is trying to do rather than how it should be done, and has helped overcome misconceptions on both sides. We believe such a development environment is
essential to avoiding some of the repeated design failures of the past and present.
Supportive evaluation has proved very fruitful in PEN&PAD and we hope it can
contribute to establishing that environment in other projects. The medical informatics community is well placed to understand both sides of the divide between users
and designers, and between problem and solution. It thus has a responsibility to lead
94
W.A. Nowlan / Int. J. Biomed. Comput. 34 (1994) 85-94
the development of mutual understanding and an environment that is capable of
producing the clinical systems needed for clinical care.
Work on PEN&PAD is continuing in primary and secondary care, and a series
of field evaluations have just been completed. The work will shortly be feeding into
the development of commercial systems.
6. Acknowledgements
This research supported in part by grants in the UK from the Medical Research
Council, No. SPG8800091, from the Department of Health, and from the European
Community initiative on Advanced Informatics in Medicine (AIM) as part of the
EURODIABETA and PRECISE projects.
7. References
1 Howkins TJ, Kay S, Rector AL, Gable CA, Horan B, Nowlan WA and Wilson A: An overview of
the PEN&PAD project. In Medical Notes in Medical Informatics no. 40 MIE 90 (Eds: R O’Moore,
S Bengtsson, JR Bryant and JS Bryden), Springer-Verlag, Berlin, 1990, pp. 73-78.
2 Rector AL, Goble CA, Horan B, Howkins TJ, Kay S, Nowlan WA, and Wilson A: Shedding light
on patient’s problems: integrating knowledge based systems into medical practice. In Proceedings
of the Ninth European Conference on Artificial Intelhgence, ECAI 90, (Ed: L Aiello), Pitman
Publishing, 1990, pp. 531-534.
3 Nowlan WA, Rector AL, Kay S, Goble CA, Horan B, Howkins TJ and Wilson A: PEN&PAD: a
doctors’ workstation with intelligent data entry and summaries. In Proceedings of SCAMC-96, (Ed:
R Miller), 1990, pp. 941-942.
4 Teach RL and Shortliffe EH: An analysis of physician attitudes regarding computer based clinical
consultation systems, Comp Biomed Res, 14 (1981) 542-558.
5 Shortliffe EH: Computer programs to support clinical decision making, J Am Med Assoc, 258 (1987)
63-68.
6
Young D, Chapman T and Poile C: Physician, reveal thyself, Br J Healthcare Comput, 7 (1990)
7
Monk A: Fundamentals of Human Computer Interaction, Academic Press, London, 1984.
Mumford E: Designing Human Systems for New Technology: The ETHICS Method, Manchester
Business School Press, Manchester, 1983.
Norman DA and Draper SW: User Centred System Design: New Perspectives on Human Computer
Interaction, Lawrence Erlbaum Associates, Hillsdale, NJ, 1986.
Hewett IT: The role of iterative evaluation in designing systems for usability. In People and Computers II: Designing for Usability, (Eds: MD Harrison and AF Monk), Cambridge University Press,
Cambridge, 1986, pp. 196-214.
Rector AL, Nowlan WA and Kay S: Foundations for an electronic medical record, Methods Inform
16-21.
8
9
IO
11
Med, 30 (1991) 179-186.
12
Rector AL, Nowlan WA and Kay S: Unifying medical information using an architecture based on
descriptions. In: Proceedings of the Symposium on Computer Applications in Medical Care, SCAMC
90 (Ed: RA Miller), Washington, 1990, pp. 190-194.
13 Nowlan WA and Rector AL: Predictive data entry: a new paradigm for medical knowledge representation. Lecture Notes in Medical Informatics 44, AIME-91, (Eds: M Stefanelli, A Hasman, M Fieschi
and J Talmon), Springer-Verlag, Berlin, 1990, pp. 105-I I6
I4 The GRAIL Kernel (GALEN Project Deliverable 6). Details of availability from the project coordinator, Medical Infonnatics Group, Department of Computer Science, University of Manchester,
Manchester Ml3 9PL, UK.