Jon Rogers writes:

> Whooa!  I don't see how you read this into my message!

Forgive me if I have put words into your mouth. Apologies if this was not what you intended.

The substantive point remains, I think, that (particularly when considering READ 3.1) the official
CCC line was/is that the details of how to actually implement it were for the suppliers to work out,
and that the reason there wasn't an existing commercial 3.1 browser was the suppliers' fault.
At suppliers' meetings with CCC which took place some 2 years ago, it became clear that the
suppliers blamed CCC for the fact that the codes were virtually unimplementable. This was
because the effort to develop a working system was, as you've said, so technically complex.
Many suppliers did not have the resources to commit to doing it. Further, many felt that
important technical information about how the codes were supposed to behave was
missing, such that there was no guarantee that individual suppliers (if left to their own devices)
would actually end up implementing the same thing. Indeed, how could they actually be
sure that they *had* implemented it? What does it mean to 'implement' READ 3.1?
There would not, actually, be any standard version of the codes in use, and if a post-hoc
standard were subsequently declared, individual suppliers could find themselves out in the cold.

There is no doubt that to implement READ 3.1 as a fully compositional system would involve
considerable commercial investment, with no guarantee that it would actually work (no one has
ever built anything like this before, at least not on anything remotely like this scale). Doing it,
therefore, becomes a significant commercial risk. If other suppliers do NOT implement 3.1, then
you have all the problems of cross-compatability: GPs are increasingly prepared to swap suppliers
completely, and are rightly wary of having their previous data locked into a particular suppliers'
choice of data storage. Individual suppliers have become  very secretive about their plans
for  3.1. Many of them are sticking with READ 2 whilst keeping a wary eye on what everybody else
is doing.

The situation remains something of a mexican standoff with both sides blaming the
other, with the users caught in the middle not knowing who to believe. It is good to see that
the CCC has now begun a more considered dialogue with the suppliers in order to work out
how to actually help them to implement something. One technical option which was considered
was to start with only a very limited degree of compositionality - this might be viewed as a very
cut-down version of 3.1, or a slightly enhanced version of READ 2. Either way, whilst it may
be a step in the right direction, it won't deliver the kind of added functionality (advanced decision
support etc) which we all seem to be after. It would also represent a significant climb-down from
the original promise and timetable of 3.1.

(If step-wise implementation in collaboration with real implementors does become the chosen route,
I strongly suspect that much of the existing technical details of READ 3.1 will need to be changed
in the light of experience - would this not have been a more realistic project methodology from the
beginning?)

> I personally think that the Read Codes meet most of my GP requirements.  I am disappointed that they
> don't meet more, but I know that the reason they don't is that the NHSCCC has quite rightly widened
> the scope and focus to concentrate on Read V3 to meet the needs of clinicians in general.  That will
> benefit me when electronic communication takes off, as it is already starting to do.

Which aspects of the Read Codes do you feel meet your requirements? I would agree that, all along,
the various versions of READ were streets ahead of any other published terminology when it comes
to wanting to describe GP medicine - provided, of course, you could find the right code. But GP
requirements and aspirations for their IT systems have moved beyond requirements for scope alone.
Like all doctors, they want to be able to do clever things with the information stored: they want this
mysterious thing called a 'Clinical Workstation'. Whilst nobody yet can agree what, exactly, a Clinical
Workstation might look like or do, they are all agreed that it needs a standard and controlled
terminology at its centre.

This aspect of READ 3.1 remains, as far as I can tell, vapourware. It is *said* that it will support
sophisticated data use, but I have yet to see a real program using 3.1 as the terminology that does
any more than was possible with version 2.0. The NHS's own Integrated Clinical Workstation Project
was hardly an unqualified success. There is much READ hype, but I have seen no reality.

As a paper exercise, READ and the Clinical Terms Project represent the most sophisticated attempt
yet to derive and scope a medical terminology for real, practicing clinicians. I've always said that this
was a valuable piece of work. However, READ was always intended to be more than a paper exercise
- it was supposed to be designed specifically to allow computers to do whizzy things. Version 1 and 2
represented the best that there was at the time. However, the significant expansion in the scope of the
terms brought about by the Clinical Terms Projects means that we could confidently predict that the
underlying technology used in version 2 would no longer be adequate. The move to a compositional
scheme seems to offer hope, but *nobody has ever done it before*. The important question is not
whether the set of terms in READ includes lots which are useful for a GP, but whether or not the
underlying technology will allow the codes to drive applications. Otherwise, you might still be
typing data in - albeit rather more detailed - for minimal reward.

Jeremy Rogers