Jon Rogers writes:

> Some views of
> Read are soured by experience of poorly maintained, and sometimes poor
> software implementations, yet despite this, the earlier versions of Read
> are used very widely.

I've seen this argument many times now: that the reason people dislike
READ is because of poor software implementation.  Certainly I have seen
some truly DREADFUL pieces of GP software - in which a poor
implementation of a READ browser was just one awful part of an awful
package.  However, I do not get the impression that the vast majority
of users of the market leading systems are especially happy with
coding.  Are we really to believe that the developers of Meditel, VAMP,
Emis et al are all so incompetent ? Or that GPs are just misguided as
users ?

I do not follow the logic in concluding that the problem lies entirely
with the system suppliers.  Perhaps nobody *can* build a usable and
acceptable implementation.  The origins of GALEN stem from a DHSS
funded research project (PEN&PAD) in which we tried to do just that: to
build a usable clinical data entry system on the back of READ version 1
or 2 (I forget which).  We concluded that it couldn't be done, and thus
GRAIL and, ultimately, GALEN were born.

The current status seems to be that READ blames the software suppliers
and the software suppliers blame READ.  The bemused user sits in
between.  Who exactly is qualified to decide who is right?

Rob Hampton writes:

> Is a clinical coding scheme a 'product' , a process, (and now for the jargon), a
> semantic framework, interlingua etc.. I would contend that Read is actually a
> 'Product' and that it's evaluation should take place in the market. Many people
> have problems with Read but the good news is that people are using it. Feedback
> mechanisms exist.

If READ really is a 'product' and its success is to be measured by its
acceptance in the market, then what does it say about it if nobody has
so far built a usable implementation?.

You might argue that the GP software supplier market is small, and
hasn't put the money into building 'proper' implementations.  This
would still mean that (as a product) READ's design is unrealistic for
its true market.

Finally, some questions about the whole premise that READ is just a
product.  I was not aware that the Government, or the NHS, was in the
business of funding highly experimental and unproven product
development, especially without any clear definition of what would
constitute success.  Further, I would love to be able to 'test' the
acceptance and success of any product I might ever build in a market
which was obliged to buy and use it.  Are you really saying that we can
ignore all the RFA requirments that GP systems have to use READ? That
we can take it or leave it?

> The GRAIL engine and Pen&Pad was an impressive display of removing complexity
> from the user where it worked. Clinical concepts based on site, pathology and
> manifestation lend themselves to the pure compositional approach. The trouble
> with compositional schemes is the need to record common but difficult to define
> or complex concepts e.g. - Anxiety, Menopause, Stress. Here the enumerative
> approach works well. Maybe things have moved on since HC96 but I'm still to be
> convinced that it is even worth the effort to build these into the compositional
> framework that is theoretically possible.  Non medical analogy: 'A good time'  -
> I can't define it but I know what it is when I see it

All compositional schemes contain a large number of basic things which are NOT defined -
these are the building blocks from which you build the things which ARE defined.
I'm not going to define 'Leg' or 'Pain', but I'll use them to define (Pain LOCATION Leg).
It is true, however, that many detailed things can not be defined. For example, it is very
hard to come up with a definition of 'Rheumatoid Arthritis', especially one which
can be agreed on by clinicians internationally.

A GALEN model is considerably more compositional than a READ model, because it can
be - because there is an automatic classifier whirring away in the middle keeping
it coherent. However, it is not an absolute requirement in GALEN that everything
should be modelled compositionally. It is perfectly legal to model some broader concept,
and then create more detailed concepts under it as primitives:

(Device which <
	hasFunction Cutting
	hasContextOfUse Surgery>) name SurgicalCuttingDevice.

SurgicalCuttingDevice newSub [Scissors Scalpel Saw LaserCutter].

In this example, the more general concept of a surgical cutting device IS defined
compositionally, but I don't really think I can (or would want to) define further
compositionally what the difference is between this and a pair of scissors, as opposed
to a scalpel. So I don't: I declare these detailed concepts as new primitives, with
a complex parent. However, having gone as far as I have, I would still find
that if I later ask for:

(Device which hasContextOfUseSurgery)

I would find classified below it scissors, scalpel, saw and laser cutter. Automatically,
dynamically. The advantage of this approach (as a modeller) is that I don't have to
worry so much about what the classification should be - all I have to do is say what
something IS, and let the engine do the work for me.

GALEN is not a religiously compositional enterprise. We just use it as much as we can,
because it's easier and gives greater power in the long term.

> Experience tells us that the more expressive the terminology, the more
> complicated is it's implementation.  This applies to GALEN and Read
> V3.  It is this complexity that the CCC is currently looking into
> removing for future GP systems.

We have already eliminated the technical complexity of implementing
GALEN for the end user by making the whole thing available via a
server running a well defined formalism via a well documented set
of API calls.

I'd be interested to know what technical options the CCC is considering.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr Jeremy Rogers MRCGP DRCOG DFFP MBChB
Clinical Research Fellow
Medical Informatics Group
Department of Computer Science
Manchester University, Oxford Road
Manchester, United Kingdom
M13 9PL

(+44) 161 275 6145 voice
(+44) 161 275 6932 fax
[log in to unmask]
URL http://www.cs.man.ac.uk/mig/people/jeremy.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%