Hubris

The Need for Speed

Index
Home

Committees drawing up requirements for GP Clinical Record Systems, and in due course for the general unifiable Electronic Patient Record face temptations they have so far failed to overcome to load systems with requirements which cripple their actual use.


The problem is familiar throughout the computer or informatics industry, where creaping featurism is recognised as a problem (particularly by people who made the move from Word 6 to Word 97[1]). Sophisticated users recognise small programs with the correct feature sets as having "quality". The Unix-like approach of using a series of small programs each of which does one thing well and which can pipe information to each other has much to commend it but appears complex to the uninitiated and does not offer system integrators as much grip as they wish to acquire over their GP customers[2].

The two largest demands revolve respectively around reporting and influencing prescribing.

Reporting

SQL is a marvellous tool for complex reporting. However the temptation to use it for the actual input of patient notes during the consultation can easily lead to slow programs. Slow programs lead to notes being incomplete, or worse - on paper - and to the snazziest SQL reporting tool in the world being unable to acess them.

Speed of making a note and speed of reading the last and previous notes is paramount. A sub-second performance is acceptable but the aim should be for less than 0.1 seconds for the first page over a WAN.

Influencing Prescribing

Again the temptation is to trawl the whole of the patient record, in real time, at the moment when a prescription is being made. The reuslt of such activity is straightforward. The feature is switched off. If an RFA requires it to be unswitchable then out comes the pen, and with it the massive, old and dangerous errors we are familiar with.

A simple change in the presentation of information - for instance showing the Allergies and Avoids records in a box on the prescribing screen so that they are there before a prescription item is selected helps with this.

This class of activities may be considerably helped by the features of Unix, OS/2 and the later versions of Windows which allow programs to execute separate threads.

Testing

What looks good to a committee in its room is often unusably or stressfully frustratingly slow in the consulting room. If the answer is hardware then the central funding authorities should provide for the hardware upgrades _before_ the newly bloated (RFA5...) programs are thrust upon users. Where the answer is clever programming there are several contributions which could be made. Better funding would allow more programmers to work on a given program, but Open Source code would allow arbitrarily large numbers to do so, and allow users to focus upon a single routine which interested them and even fund an improvement to it which was more important to them than others - a last kick of an internal market perhaps.

The use of background programs - daemons in the Unix usage - has been underplayed. If the cleverness can go on at night and weekends then the front end of the system can be freed to be lightning fast. Anticipation is commonly better than trying to react quickly[3]. The processes in use at the Reigenstrief Institute years ago should have been extended to all of us by now, perhaps they will appear as part of Clinical Governance.

In the long run the move from relational databases holding the records of all practices to a record based on one or a few documents per patient is liable to help with rapid access and making of notes. Roll on XML.


Footnotes

[1] Word 6 was a very good compromise, it improved on Word 2 by exposing its objects for the programmers, but ran well on modest hardware. Word 97 is overblown, and vastly beyond any sensible needs in most of the Health Service. Up

[2] One must have some sympathy for this, suppliers trapped in the NHS GP market with its massive and incompetent regulation and uncertainty need some assurance that they will be able to develop an income from their customers next year or else they would have to change business. If a different model could be found for the market then their needs might be catered for as well as those of GPs, patients and the Executive. Up

[3] I wish the NHS would take this on board in its usual activities. Up



Service problems -SWIS | Remarks on content or suggestions | Version date 7 July 1999 | top of page | Looks best with Opera browser