House of Commons - Health - Written Evidence

Select Committee on Health Written Evidence

Evidence submitted by Dr Gerard Bulger (EPR 28)

I am lead for Practice Based Commissioning in Dacorum[75] and a GP in Bovingdon, Hertfordshire, at Archway Surgery,[76] I am a member of CfH GPSoC Committee[77] and recently joined the Royal College of General Practitioners Doctors Working in Secure Environments Group[78]

I worked in East London, as a GP, and in hospitals, for 20 years. For nine years I was Medical Officer for Redbridge and Waltham Forest's Unit for Physically Disabled People where I organised an interface for the severely disabled[79]. In the 1990s I established the Fundholders' Support Agency[80] which was partly a data warehouse, carrying data for 350,000 patients. I also developed the Consultant Provider Agency[81], an outpatient and minor surgery service. These were heavily dependent on IT systems. I have been involved in the design of a clinical system since 1990. I have installed an IT system within a prison and have been working part-time in prisons for five years.

SUMMARY

1. The UK medical IT industry was effectively nationalised at the inception of Connecting for Health by using the Government's monopoly purchasing powers for the NHS, denying current suppliers of a market.

2. HM Prison Service may have a clinical IT system imposed on it without any tender or user review process.

3. Access to previous records is designed to prejudice the care in order to reduce investigation and duplication, but that can literally prejudice care. We are changing and dying organic beings, so a previous record or diagnosis can be rendered wrong or irrelevant the very next day.

4. Deleting an incorrect entry seems to be impossible when there is a single record collected from different sources. The only correction possible is for a new correcting entry to be posted, but negation codes do not exist on most GP systems. The validity of a record depends on its provenance, but the very nature of data depends on what it was collected for. To get round this CfH spine date will be in sections, (GP data, hospital data) so not really a single record at all[82].

5. Agreeing how we record drug allergies, becomes a complex process once we accept that it is a core component of a central record. To unite us with absolute definitions would bind us down in such complex data entry coding systems that the system would become unworkable.

6. Keep data local to where it is collected, and where its purpose and meaning is understood. A Google type internal NHS net search engine could find it. There is no need for a single record. Indeed it is probable that Google Health, which exists already, could render the core plank of the NHS IT programme redundant.

7. CfH's need to centralise data extends to GP surgeries. CfH seeks to ban GPs from holding their patients' clinical data on a server in the practice. ALL GP practice data is to be held on central servers. GPs could be cut off from their own patient's records.

8. Few patients know that, under CfH plans, as soon as a key is pressed in a GP surgery, the data is outside the surgery building. Indeed all patient data, not just that held on the spine, is held outside the surgery on a central working server. Nothing remains in the surgery.

9. A safer approach for doctors and patients would be for GPs to retain their servers and governance of the data, and for CfH to run an offsite encrypted backup service. This would also alleviate the problem of narrow broadband connections which cannot support off-site serving of clinical systems on a large scale. Indeed BT has told us that no clinical system should be dependent on N3/internet connections to function. CfH demands just that.

UK MEDICAL IT INDUSTRY

10. The UK had a vibrant primary care IT industry, with small innovative competing suppliers developing systems that had to be able to use common communication and coding standards for NHS use. These companies had every GP practice as a potential customer and they needed to sell their product directly to clinicians. When NPfIT, later CfH, was established in October 2002, that market was taken away. The Primary Care IT companies were stripped of their customer base and their potential customers. There was only one customer, the Government. Since then PCTs, in order to save their costs, have encouraged and bullied GPs to move to CfH LSP solutions, as the costs of LSP solutions were "free" to PCTs. Few GPs obliged, but new surgeries have had to use the LSP "solutions". It is difficult for existing companies to invest or innovate in this single purchaser environment.

PRISON SERVICE AND CLINICAL IT

11. The Committee may like to look at the prison service and IT. Here it makes sense to have a central record because of the high rate of recidivism; the prison service also moves prisoners around the prison estate. The size of the system required is quite small, compared to NHS standards, looking after 80,000 prisoners at a time, with a turnover of about 150,000 prisoners a year.

12. Quantum EDS, [83]which has the prison service contract, would not allow clinical systems to use their cables, let alone computers. PCTs have installed some GP systems with limited NHS connectivity. Many PCTs held off as it was assumed that the prison service was to have its own Clinical system, which was in the pipeline. The draft specifications did state that the system should be based on standard Primary Care GP systems. It was assumed that CfH would handle it though the LSPs. But that would have meant that a prisoner in London would not be able to have the same record when he moved prisons, say, out of London to Hertfordshire, which is covered by a different LSP.

13. CfH is on the brink of awarding the Prison Service Healthcare contract to one system supplier without any tender process, simply on the grounds that it is at three out of the five LSPs. Once again smaller fish have not had any opportunity to contract for a part of NHS CFH programme.

14. LSPs do not need to house the system at all. Under GP Systems of Choice all the major clinical suppliers are developing their own data centres. Any of the GP clinical suppliers could tender for the Prison Contract but they are not being allowed to do so.

SYSTEM DESIGN

15. Why have a single medical record? The assumption is that a single record is a good thing. All medicines and procedures have their side-effects, some of which can be dangerous. The balance of risk over benefit is never discussed by CfH. A single record is held to be a good thing.

16. At a CfH conference "Your Care Your Record", on 23 November 2006[84] professional actors, at NHS cost, demonstrated the advantages of having a single record. Little did they know that their little play, unchanged, demonstrated the risk of having a single medical record.

17. The scene was of a patient at a bus stop becoming ill. The ambulance arrives and attaches the new technology to the patient, such that the details are sent to the hospital in the town. The habit of crews in writing down essential readings on the back of their gloves was ridiculed at the CfH conference, implying IT systems would automatically be as reliable and as useable in an emergency.

18. At the hospital the main advantage of a single care record was described by the acted scene in which the patient holding his chest and breathless was assured "we have your full record here and see that you have chest problems". All further discussion was stopped. The implication was that the single record would represent a huge saving to the NHS and save lives.

19. The trouble is with this scenario that the patient could still have a new condition and could well be having his first heart attack. The doctors would be biased by instant access to his records, and the data will allow the staff to be lazy.

20. To be safe you need to take a history and examine the patient from scratch. Humans are changing biological beings and a fresh look is needed in an emergency presentation. The information in the record may be neither accurate nor relevant as the patient's condition has changed. Digging out the records or asking the GP a few days later is reasonable. You do not need it at midnight. Instant access to records may deny patients that valuable second opinion.

EXAMPLE OF ACCESS TO RECORDS PREJUDICING CARE

21. My relative was admitted to hospital last year. He could not swallow. Why not? The hospital staff replied that it was because of his dementia. That was a surprise to us.

22. It seems that the GP team or coder had accepted his wife's statement "he is demented" and placed the read code "F110" (Alzheimer's Disease) on the computer. In fact it was the wife who was fragile of mind and intolerant of her husband's Charles Bonnet syndrome (visual hallucinations). The condition was caused by blindness from glaucoma. He was not demented and could name the time, date, and place, the name of the PM—and the entire cabinet.

23. Instant access to the GP's full record got in the way of managing that man's condition. He was not investigated on arrival because the access to the GP's record distorted the management during those vital first few days of his admission. After that it was too late. He died 12 days later with no diagnosis.

DELETING INCORRECT DATA

24. It will be a complex process to delete data. Say a hospital assumes that a patient has penicillin allergy, but as GPs we know that the patient has not (as we have given it many times before). It seems that the GP would have to add another entry countermanding the first. Our current Read coding system does not allow for negating codes. We would not be able to delete the incorrect entry, just add another. A search would still find the "allergic to penicillin" line and would deny the patient the most potent range of antibiotics, most of which are still based on that molecule. Similarly it is not clear how my relative's incorrect diagnosis of dementia would be corrected, once it was on the spine. Someone's impression that he was demented could be seen forever and continue to prejudice care.

25. On current GP systems incorrect data like that can be deleted; we often do just that. There is an audit trail to say what was done and by whom but it is seldom referred to. Sharing data on a single platform amongst different organisations, whilst making sure it is correct, is too complex to contemplate. CfH seems to have backtracked and the record would be subdivided such that a GP will have to ask a hospital trust to correct the hospital's incorrect entry. The single care record is going to be divided up into sections according to who put it there, in which case I ask why does the data have to be centralised in the first place?

THE NATURE OF MEDICAL DATA

26. Definitions of disease vary and can be arbitrary. For example the diagnosis of diabetes is not as absolute as one might think. Each piece of data, if drilled down onto it, opens up like a fractual. The complications increase the closer you get—just as the UK coastline is not 7,760 miles, if you were to count the edge of every rock and inlet at low tide. Medical data is similar.

27. The central recording of Allergy has been heralded as a major safety advance of the single record. But allergy recording becomes complex once it is to be shared. The nature of data depends on the provenance of the record and what you originally collected it for. CfH attempts to bring together information collected for different purposes (and their different meanings) into a single place for a new purpose.

28. GP clinical systems allow one to mark a patient as being allergic to a particular drug. The computer gives warnings if you attempt to give that drug, or any drug of the same family, if known to give similar reactions. The GP, for his purposes, will mark a patient record should the patient complain about a drug. The reaction could be a true dangerous allergy and collapse, or it could simply be intolerance to the drug, or a mild rash. It requires a pocketful of coding to describe exactly the patient's reaction, from a code for a profound dislike of anything coloured blue, through to intolerance (cough with ramipril or stomach pains with an antibiotic). The GP wants to remind himself not to give that again, and upset his patient, so codes the allergy. His clinical system reminds him henceforth. That entry collected for one purpose at a GP's surgery, would now be assumed by a hospital to mean that the patient was at great danger and would collapse if given that drug again. To get the NHS to agree on allergy coding we have to agree a new set of coding and subdivisions, complicating data entry.

29. Coding data in this way becomes so complex that frustrated clinicians end up putting in junk codes. One of the most common codes used in many practices is £8CB: "had a chat to patient". If the NHS is too pedantic on coding, it will develop cumbersome systems and meaningless data.

A GOOGLE WITHIN THE NHS?

30. A clinician at a hospital could, under CfH, be able to search for records wherever they were held within the secure NHS Net, and to leave an audit trail and a notice to the patient that he had done so. That way a record and provenance of each piece of information could be built up, so that the hospital clinician could make a new judgment and make up his own record on the day. He would not be relying on ONE record or any one system. It would require standards for searching on different systems. There are already programmes running that can undertake searches on any GP clinical system; Miquest[85] and Apollo. [86]

31. Google, or similar, may well render the whole of CfH redundant by inventing just such a system on an international scale. Google already has a department working on medical data run by Google's Vice President Adam Bosworth. [87]

CENTRAL DATA CENTRES AND GP SERVERS

32. CfH insists that GP data is stored in data centres. This is still the case—despite the Buncefield explosion affecting NHS trusts using who were using off-site services.

33. Under CfH's plans GPs are not to have any clinical servers in their surgery and GPs will be clients of external servers. [88]That means all data is external. My patients have worries enough about having just a fraction of their data going onto the spine. They are horrified to hear that one day, under CfH, as soon as their doctor presses a key on the desktop computer, their data will be on a working server outside the surgery (in our case in Derby). No matter that it is encrypted—all their clinical data will no longer sit in their doctor's surgery, nor would a copy of the data, as there is no local server.

34. Those patients who refuse to have their data outside the surgery will force us to use paper records again, or to create a new surgery-only clinical computer system.

35. Patients can cope with the idea of an encrypted dumb back-up file sitting off-site, and indeed even expect such a thing, as they do not want their records lost. But in my discussions patients assumed that only their surgery team had the key to restore the data.

36. Under CfH plans, if anyone accidentally digs up the cable outside the surgery, there will be NO data whatsoever for GPs to treat their patients. No patient records would be available at all—a nightmare scenario in a busy surgery.

37. A BT/CfH N3 (broadband) team, made up of Stuart Hill, Len Chard N3 Project, and Garry Jupp N3 Head of Service attended my surgery in January 207 after they had read my blogs about the N3 bandwidth. [89]The team stated that BT had have pointed out to CFH that no clinical systems should be dependent on N3 connections to function, because no communication system could guarantee being up 100%.

N3 CONNECTION BANDWIDTH

38. CfH lacks of bandwidth on N3, [90]the NHS Intranet. To run systems remotely requires fast upload speeds. Many practices have only 256k upload speeds and this pipe is simply not wide enough to transfer the level of data up to a data centre. It can lead to jerky cursors and fix the GP's eye on the screen far more than occurs already. The way around this is to have "store and forward". The data is kept locally and transferred up when the lines are quieter. Indeed BT protests that its N3 lines are quiet and that GPs are not using their current lines at anything like capacity. That underestimates the bursts of activity of any IT system. A Monday surgery with busy clinics, and data being scanned in, will be followed by pauses and a quiet night.

39. There are other pressures on bandwidth. Each machine in a GP's surgery requires windows updates and virus software updates and NHS Net email.

40. Data should be kept locally. An NHS Net secure data engine could search for data with a patient's consent (or in an emergency without it). Both the data holder and patient are informed of the search and by whom it was made. There would be no need for a central record.

SINGLE INTERFACE: FREEZING NHS IT IN THE PAST

41. The NHS is spending £40 million with Microsoft[91] to develop a common interface for the NHS. Fixing a common interface may simply set the NHS systems in aspic. The interface with programmes is the most complex part of software. We are less likely to have innovative approaches to interfaces if we are to have one interface imposed upon us. Out there on the internet, new non-windows interfaces may be developed but will be denied to NHS users.

MESSAGES

42. Keep Data local... under the control and protection of GPs, and search for it if needed, notifying the GP and the patient that the data have been gathered.

43. Provide reliable offsite live backup systems rather than demanding the use of hosted systems.

44. Setting standards of medical IT communication and searching, and applying and developing international standards.

45. Develop and keep a live market in Medical IT and encourage the smaller firms... one of them could be the next Google.

Dr Gerard Bulger

March 2007