Simon wright
Simon is an IT manager at a very large GP Surgery in the West Midlands, with 20,000 patients and 18 GPs. He has been in the IT industry for over 21 years, first as a programmer, then as a computer analyst/consultant/ specialist. His present position involves dealing with the local PCT in all matters relating to Connecting for Health, as well as the normal day-to-day operation of over 65 computers within the surgery.
The programme implemented by the government to improve computer systems was originally called the National Programme for IT (NPfIT), but the name has now been changed to Connecting for Health.
Connecting for Health
As well as setting up a central database, the government thought it would be a good idea to standardise the software used by GPs. There are currently three major suppliers of clinical software to Primary Care Trusts (PCTs), and several smaller suppliers. EMIS is the software system used by the majority of GPs in primary care, with Torex and In Practice systems also proving very popular. To achieve their aim of getting everyone onto one main system, the government split the country into five regions and awarded contracts to different local service providers (LSPs). These firms then awarded contracts to different suppliers, which does not seem like a good plan to get everyone onto the same system!
The main contender for supplying the clinical software is Isoft, formerly Torex, with its new Lorenzo system. This system is being designed to be suitable for both primary and secondary care. Three of the LSPs have agreed to supply Lorenzo as their preferred system. However, due to the enormity and complexity of this project, it now appears that the “supersystem” will take a lot longer to implement than was originally thought.
Additionally, GPs feel that they have not been consulted about their requirements for a new clinical system and wish to exercise choice, as promised in the new GMS contract. With this in mind, the government has decided to allow GPs to retain their current systems, provided that these systems are Spine-compliant. This means that they must be able to communicate with the National Spine, the name for the National Patient Database, which is currently under development and subject to very strict security measures to ensure patient confidentiality.
In order to access the Spine, and to ensure data security, clinicians will be given a “unique electronic signature” in the form of a smartcard that will be issued by their local PCT. This will need to be placed in a smartcard reader attached to the computer every time they use the computer. They will also be required to enter a unique PIN number every time they log in. For security reasons, you must ensure that every time the clinician leaves the workstation, they remove their smartcard. In addition, they should not log anyone else onto the system using their card.
The biggest advantage to the Spine is that everyone who has a requirement to access a patient’s medical record should be able to access that record. Currently, hospital staff have no direct access to a patient’s medical history. This is stored at the GP surgery. When the Spine record is set up, all the key information is passed from the GP system to the Spine record. In addition, any other intervention carried out by the hospital or outside agencies will be passed to the Spine record and will be available to the GP. It is proposed that patients will have the right not to have their medical information stored on the Spine, but I believe that the patient will have to request that the information is not stored on their Spine record each and every time that they visit the GP.
Another benefit of the Spine record will be the electronic transfer of patient records. At the moment, if you move area or change GP, even though your medical records are probably held on computer, your entire record will have to be printed out and transferred by NHS secure courier to your next GP. This process can sometimes take several days to achieve. Once the records arrive, someone will have to type in all the information onto their computer system, even if it is the same type as your previous GP’s system. Thanks to the new systems being put into place, it should soon be possible to transfer your medical record electronically, and your information will arrive in a matter of minutes rather than days, ensuring that if you need to see your new GP urgently, he or she will have your full medical history available.
LSPs are intending to provide centrally hosted systems, with the software being run from servers based at the local PCTs. GPs will link into these systems, removing the need for surgeries to have their own servers. This has several benefits for surgeries – including not having to perform their own daily backup procedures. This will require a fast network between the surgeries and the local PCT hosting the system on its server. BT is providing a fast network called N3. These hosted solutions are not favoured by everyone, as some GPs are concerned about patient confidentiality and the fact that they are responsible for the patients’ medical records, but PCTs are actually storing the data. EMIS and Vision are also planning to offer hosted solutions, and in the short term we are likely to see PCTs beginning to offer hosted options for surgeries that prefer this type of system. There is also a cost-saving consideration for PCTs, as they will not need to spend money on replacing local servers within these surgeries.
Choose and Book: the patient’s choice
Several other exciting projects and changes are due to be instigated under Connecting for Health. The first project, which is currently underway, is Choose and Book, the patient’s choice.
The aim of this project is to give the patient a choice in relation to any referral that the GP may feel is required. It also speeds up the process of making the appointment. Instead of the GP sending a referral letter to the hospital consultant, who will then send an appointment letter to the patient, the new system will expedite the entire process, as well as allowing the patient a choice in where they are seen. The GP decides to refer a patient; from his computer terminal, he/she can pull up a Directory of Services (DOS), which lists available hospitals and consultants. A list can then be printed of the available hospitals, to enable the patient to choose which they feel is most appropriate.
The choice should offer between four and five hospitals. The GP will ask the patient to choose a password, which will be required to book their appointment. An “appointment request letter” will be printed, which will include a “booking reference number”. Patients can make their choice at the surgery, and a member of staff can log onto the hospital appointment system, or they can return home and phone the hospital booking team at their convenience within the next few days.
When they have chosen their hospital, they will be offered a choice of appointment times and dates from the free appointments available. If they decide while still at the surgery, the appointment can be booked there and then. A letter will be printed off and given to the patient. They return home knowing exactly where and when their appointment is due, rather than having to wait several weeks for an appointment letter to drop in through the post. The appointment will be classified as a normal appointment, and there will be the usual waiting time for the relevant hospital and department. If the GP feels that the appointment is very urgent, it should be booked using the normal Rapid Access system. When consultants vet the letter, if they feel that the appointment should be brought forward, the patient will be contacted and offered a “cancellation” to bring their appointment forward without hopefully frightening them.
Another part of the Connecting for Heath project is electronic prescribing. This will be of benefit both to patients on long-term repeat prescriptions and to the surgery. There are two main aims for this project. The first is the electronic transfer of prescriptions from the GP surgery to the pharmacist. This will cut down on paper waste and also prevent possible errors due to misreading the prescription. The second is reducing the surgery time in dealing with long-term repeat prescriptions.
If a patient requires medication that will be required over a long-term period, the GP will be able to issue a prescription to the pharmacists for 12 months’ worth of medication in one script. The pharmacist will then release the medication to the patient in the correct monthly or weekly amounts. The surgery will not have to get involved again until the 12-month period has expired. This means less repeat prescriptions for the GPs to check, less scripts to print and less staff involvement in the whole process. To ensure that only qualified clinicians can prescribe, enhanced security features are required, as a GP will no longer “sign” the prescription. An electronic signature is required, and this will be achieved using smartcards and PIN numbers. The NHS wants this system to be operational by the end of 2007.
The new SNOMED coding system
One part of the changes that may not prove quite so popular initially is replacing Read codes with the new SNOMED coding system. All current entries on medical records require a Read code for Quality and Outcomes Framework (QOF) funding. Read codes cover a large percentage of medical conditions, as well as some unusual problems, such as being hit by a meteorite! Unfortunately, secondary care does not use Read codes, so the decision was taken to get everybody using the same system by late 2004. However, this implementation has slipped and is still under development.
There are several potential problems with the SNOMED implementation. It has been agreed that current clinical suppliers will write software to change all current Read codes to their new corresponding SNOMED code. This will apply only to official codes. Many suppliers have created their own codes to cover “gaps” in the Read code system. Again, the supplier should automatically change these codes to their new equivalent. Unfortunately, surgeries have also created their own codes to fill in gaps. These codes will be the responsibility of the surgeries to find and change. In addition, Read codes are built into templates to assist the coding of medical conditions. Again, software suppliers will amend their official templates, but any templates created by the surgery will be their responsibility to change.
SNOMED codes are very different from the existing Read codes. SNOMED codes are numeric-only and do not have a hierarchal structure similar to that of Read codes, where H3 was IHD (ischaemic heart disease) and H33 was a child code that would be included in any searches performed on a H3 condition – if required.
The final problem with SNOMED codes is that they were originally going to be switched in a “big-bang approach” – one day Read codes, the next day SNOMED codes. Due to the problems encountered, the idea is now to start to phase in SNOMED codes gradually with existing Read codes.
This is going to lead to various complications and possibly increase the risk of errors being introduced to the patient’s clinical record or funding problems due to incorrect polling of data due to code mix-ups.
