The Retinopathy Screening Service has four sections. There is an administrative team that makes appointments for a scan and a team of healthcare assistants and screeners who go the various centres around the county and run the clinics at which the retinal images are collected. Back at the main location there is viewing equipment that enables graders to assess the images. In most cases the screeners are also graders. Finally, there are three Failsafe Officers who are responsible for tracking patients through the entire process and making sure they move from one category to another, i.e. from having been sent a request to arrange an appointment to having booked an appointment to having had images collected etc.
The OptoMize system is fundamental to the work of the Retinopathy Screening Service because it is designed to cover all aspects of the service. Firstly, it is the database of patients with diabetes they have to screen and it contains the templates for the different kinds of letters they send to patients. Secondly, it enables patients to be tracked at every stage of their journey through the retinopathy pathway by assigning them to different ‘queues’ as they are screened, images are processed etc. Thirdly, the system ‘flags up’ when patients are getting near a time when they need to be moved into another category. Fourthly, it contains the clinical details of the patients including the retinal images that are to be graded and assessed. The ability of the system to meet the needs of the Screening Service staff at every stage of the screening process is therefore vital to the success of the service. The experience of the service can be reviewed for each stage of the process as identified in figure 7.3.
a. Selecting patients for screening Following the ‘restart’ the
Diabetic Retinopathy Screening Service found that the ‘clean’ database had many errors and they were especially troubled by the fact that there were patients who needed screening they knew nothing about.
In the database we had patients who had moved out of area or were now deceased that the surgeries hadn’t told us about and close on 2,000 patients that the surgeries had never told us about. Quite often GP surgeries were not telling us when they had a patient that was diagnosed with diabetes, and some were not telling us when a patient had died or a patient had moved out of area
Member of the Restart Team When the change facilitator was ‘embedded’ with the Retinopathy Service she worked with the retinopathy staff, the GP practices, a member of the PCT Commissioners and the OptoMize team to look for improved working practices. This process led to some changes in the pathway and to some changes in the new version of OptoMize. One of the consequences of the changes made was that the Failsafe Officers developed more of an on- going dialogue with practices about patients who needed screening. For the Failsafe Officers it has meant much more manual entry to a system that was intended to be mostly automatic, as it is necessary to add and delete patients and move them between categories. At the time of the interviews the new processes of validating the database with 3-monthly uses of Quest Browser were just bedding-in but there was optimism that they were getting on top of the job
b. Booking appointments for screening The admin team are
responsible for sending letters, generated by OptoMize, to patients to ask them to contact the service to arrange a screening appointment. If they do not respond they are sent two reminders. OptoMize helps manage this by flagging when relevant time periods have passed and action is required. When the patient does not respond other measures have to be considered and consulting the GP practice may well prove to be the most effective way of approaching the patient, because the local diabetic nurse is more likely to be successful than a direct approach from Retinopathy. The Failsafe Officers were concerned to hit the kpi targets for the patients being screened and non-respondents were a particular difficulty. If patients did not respond or, when contacted, said they did not want to be screened, the Failsafe Officers needed to get proof that the service was not necessary or wanted by the patient. Once proof was obtained they could be excluded from the returns.
If they are registered blind, for example, we would go back to Ophthalmology or the GP and try and get a certificate of visual impairment... The biggest thing is getting that proof.
Failsafe Officer Another problem for the Failsafe Officers is the boundary of the county. If patients move outside of the county but are still with their GP they will be in the retinopathy screening catchment area although the patients may think otherwise. They may also wish to go for screening to a site outside
the county. Working out the best course for such patients can involve liaison with other retinopathy screening services and GPs.
Reviewing the different circumstances that have to be dealt with led in the re-design process to a need to change some of the standard letters to patients held in OptoMize. Getting them modified was not a straightforward process.
If we wanted a line deleted from a letter...we have to wait for OptoMize to remove it from the letter. They have to upload the modification to the server and then we can start using it. ...So they are the annoying bits….
Clinical Change Facilitator
c. Screening and Grading The main change for the patients in the
south of the county is that rather than attending a mobile screening session near their GP practice they now have to go to a fixed site that might be further away which can be difficult for elderly or infirm patients. The process of screening involves having drops placed in the eyes and patients are advised not to drive. In the view of the screening team these factors contribute to the difficulties of achieving high attendance levels. When patients attend, the healthcare assistant updates their record in OptoMize or starts a new record for new patients. The Retinopathy Screening Service receive very little information from GPs so they need to do their own history taking in relation to diabetes and eye problems. The healthcare assistant also puts in eye drops before the screeners take four photographs, two of each eye. These images are stored in OptoMize with the patient’s record. Subsequently, back at the headquarters of the Retinopathy Screening Service, graders review the images. Some of the clinics have ‘live’ connections with the OptoMize server and new records and images can be put on the system immediately. However, at some clinics, staff have to store the new records on laptops and upload them to OptoMize when they return to base. This can cause problems:
When we work remotely and cannot upload data directly, there is a risk factor to getting it accurately transferred when we are back. There are problems with data transfer. Also it creates a delay - when we work remotely, it will be a least a day before a grader can see an anomaly that needs urgent attention
Screener/Grader The graders are in many cases also the screeners who captured the images and the grading process has several levels. There are regular multidisciplinary meetings at the Retinopathy Screening offices which screeners, graders and ophthalmologists attend to review difficult cases and to improve their collective expertise in assessing screened images. There can be several outcomes to this process that may lead to the
Failsafe Officers having to intervene. If the patient did not attend for their appointment or the images were not of sufficient quality for the grading to be made, the patients will need to be contacted and another appointment made.
The majority of patients are found to be free of abnormalities. In some cases there are minor abnormalities that do not require referral to Ophthalmology. More serious cases go into two pathways. Those needing non-urgent treatment are referred using OptoMize to the relevant Acute Trust Ophthalmology Department and there is a 13-week target for treatment. Urgent cases, where sight-threatening abnormalities have been identified, have a 2-week target and the Failsafe Officers deal with them separately.
The urgent referrals things that are sight-threatening, come into Failsafe and I email each Acute with them. I check the next day to make sure they have been accepted. If they haven't then I get onto the Ophthalmologist and say 'you haven't done it, do it now quickly'.
Failsafe Officer
d. Treatment Most of the referrals for treatment are to the
Ophthalmology Departments of the two Acute Trusts in Kettering and Northampton. The Ophthalmologists make their own assessments of the images and decide whether to call the patient for further diagnosis and treatment. The Ophthalmologists in the county have access to OptoMize and can view the patient’s details and their images on the system. However, when they make an appointment for the patient they use their own Acute Trust System and thereafter, the Ophthalmologists use that to record subsequent treatment. Failsafe Officers are responsible for tracking patients who are referred to ensure they get appointments and receive treatment and there may be 1,000 patients in this process at any one time.
Fulfilling these responsibilities is largely a manual process because the information needed is not in OptoMize. The Ophthalmologists can enter details of appointments made with referred patients and of treatment outcomes into OptoMize but because there are few computers that can access in OptoMize in the hospital, in most cases they send Failsafe Officers a form with the details.
The Failsafe Officer summarized the job as one big on-going detective hunt – continually trying to find ways of checking whether patients were in the right place and were being progressed through the system. Sometimes they could do this directly by using OptoMize but often it was a case of checking other systems and of communicating with other healthcare agencies. They had been given access to the appointments system of one of the hospitals and this helped but much of the time was spent ringing people to see what had happened to particular patients. The process led to much manual entry into Optomize – entering details of
patients and moving them from one queue to another. The Failsafe Officer thought it might be possible to get OptoMize to do more searching and reporting for them, e.g. listing patients in various queues. The reports, at present, told them what targets they were hitting but did not help them manage the patient load more effectively.
But the Failsafe Officer concluded they were still a young service and they had made a lot of progress.
The job is developing as we go along really and so is the system. The only way we can see what we need is to be doing it and then we can ask ‘can the system help us with this?’
Failsafe Officer
7.6.6 The Design Process
In the early stages of the development of the Diabetic Retinopathy Screening Service different strands of the system were developed separately. When the North and South of the County merged there was an
organisational design exercise to merge the service into one team and
undertake the screening in a number of fixed sites. In a separate exercise
technical work was undertaken to integrate the databases from the North
and the South. When this was unsuccessful the whole service was paused. The National Programme had issued guidance and targets for the performance of the service and the pause was an opportunity to re-design
the pathway.
When the restart was begun, it was again regarded as a technical task to use Quest Browser to obtain a new and ‘clean’ database from all the GP practices in the County. The Clinical Change Facilitator commented on this stage of the design process.
The first time around when most of these changes were happening, it was IT … it wasn’t even IT internally to us - it was a company coming in to give Retinopathy a new system.
Clinical Change Facilitator This process did not yield an accurate database because of the rate of change in the diabetic population and problems of coding etc. It led the IT team in conjunction with the staff of the Retinopathy Screening Service to take a different approach. They concluded that, whilst the detailed operational practices of the delivery of the pathway were being worked out, especially the increasing role of Failsafe Officers, there was a need for IT staff to work very closely with the operational staff so that clinical involvement in the development of technical systems could be greater. A crucial part of this change of approach was the embedding of a Clinical Change Facilitator – a hybrid - with the Screening Team.
This time around we have had clinical involvement in it, and there is a lot more questioning of what they needed from the technical system to do the job
Clinical Change Facilitator But there were limitations to the changes local IT staff could make to OptoMize which has been designed to meet the requirements laid down by the National Diabetic Screening Programme. They could not change the national data set and major changes would involve a contract review with the suppliers. There were, however, quite a number of ‘tweaks’ possible to customise the existing system to local needs, such as, changing the flags so warnings came up earlier.
Although there was a belief that version 2 of OptoMize would support the operation of the Screening Programme more effectively than version 1 there was a realisation that there was more to be done, for example, to help the Failsafe Officers move all patients through the process and sharing information more effectively at the boundaries of the system.
7.7 Discussion
The diabetic retinopathy screening pathway has a dedicated technical infrastructure that provides much of what is needed for an integrated service. It is technical support to implement the guidance and kpis of the National Programme for Retinopathy Screening. However, the rapidly changing nature of the diabetic population and the many different circumstances that can arise during the screening process mean that the overall sociotechnical system delivering the pathway has to be resilient and responsive. The use of a technical solution Quest Browser to extract information from GP records has been useful but has to be backed up by an on-going dialogue between the GP Practices and the Screening Service. Similarly, OptoMize may signal how to move most patients through its various ‘queues’ in the screening process but there are many patients who fall through the cracks. In these circumstances it is up to the healthcare professionals to spot the needs and take corrective action. It is noteworthy that the role of the Failsafe Officers has become more prominent and the ability of OptoMize to support their detective work is crucial to the success of the service. Their role has strong echoes of the ‘progress chasers’ in manufacturing plants that ‘oiled the wheels’ of automated production systems.
The design process for the Screening Service has had an evolutionary character with different facets of the service in focus at different times. Initially the merger of the two PCTs in the county meant there was a focus on organisational change. Then the promulgation of the National Screening Programme meant there was a focus on designing the service to meet the targets of the programme. Separately there were technical efforts first to merge two databases and, when that was not successful, to restart the service with a clean database by using QuestBrowser to extract data from
the GP records. These rather separate ventures seem to have served to set up a basic structure for the pathway that, when put into operational practice, revealed the many areas where patients were likely to ‘slip through the net’. At this point a design approach was used that focused on the operational delivery of the service and, by using clinical change facilitators to ensure close clinical engagement with technical developments, issues of service design (to meet the requirements of the National Screening Programme), the detailing of work roles and responsibilities in the screening service and the refinement of the technical systems supporting the process were addressed in an integrated manner, albeit within the constraints of the existing policies and technical system.