 |
 |
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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%