Despite the July 2018 announcement of a large cash injection, the NHS is merely returning to historical levels of 3 to 4% per annum increases. The pressure to optimise all aspects of the service is as high as ever. In a report for the IPPR Lord Darzi, said: "The proposed increase in NHS funding is very welcome but must be accompanied by a serious plan for reform. NHS staff are trapped working in a fractured system that is in desperate need of radical simplification."
Aside from issues related to de-centralised purchasing, resulting in some trusts paying up to 47 times more for items such as rubber gloves or plasters, workflow optimisation is high on the agenda. Chief Executive Nigel Edwards said: "Cuts to the NHS have caused havoc and clinicians find themselves in a ‘busyness trap’ where they would like to make things more efficient, but simply don’t have the time.
I talked to a neurologist in a southern NHS trust who gave an example of a patient imaging workflow in his hospital that may act as a microcosm for a large institution such as the NHS (not exclusively, however).
Step 1: Request for imaging
- App 1: Administrative personnel entering data rather than Doctors, so often the wrong team associated with the request as the admin was not observing the clinical decisions.
- This is then passed to a second app to generate the request (app 2), but there are issues arising because the user interface is poor and data must be input multiple times if there are multiple requests.
- The request is then passed to the radiology information system (app 3) and there the request is authorised and the parameters of the scan are set (which device, body part etc.). Once this has been confirmed the relevant parties are contacted regarding the appointment.
Step 2: Performing and reporting the scan
- This is also performed in app 3, but then passed to app 4 for image viewing
- All Clinicians have access to app 4, and once the images have been reported on these reports can be accessed in app1 and app 4.
Step 3: Notification of report completion
- For inpatients, there is no immediate notification of report availability. The ward teams will be expecting images/reports to become available and the system works by them intermittently looking to see if they have been done/issued.
- For inpatients, there is no notification that amendments have been applied to reports. This leads to clinical errors when a significant amendment is made to a report that has already been seen, acted upon and considered ‘finished’ by the ward team.
- Once per week, App 3 exports a spreadsheet of all tests reported or amended during the preceding week and stores it is a shared location on the hospital network.
- Clinical teams/departments access this list and filter it for results that are relevant to them. Each line contains the lead clinician and their department – these are the columns used to filter the list by most users.
- As tests performed in the Emergency Department always default to a single lead clinician and department, requests made in this way but intended for a specific clinician or department are therefore not filterable in this way.
- The Emergency Department team do not review results reported on this spreadsheet as the number of tests is unmanageable and most tests are expected to be acted upon immediately for Emergency Department patients.
Step 4: Acting upon requests
- Processes likely vary from department to department.
- In the department in question, each consultant has a secretary who once per week will access the central spreadsheet, filter on the lead clinician and copy/paste the resulting records into their own spreadsheet (incidents have occurred when lines are accidentally not copied across). This has additional columns so they can record when they have passed the result to a Doctor / when they have received it back etc.
- For each line on the spreadsheet (average 10 per consultant per week), the secretary accesses App 4, finds the relevant scan (searching by hospital number and selecting from a list by scan name and date) and prints a hard copy of the report. They also print the last clinical letter in our departmental folder for the patient (whether it contains useful information or not – they don’t look) and staples the two together.
- Each report is passed to the consultant in a pile.
- At some point during the following week (supposedly, it can take months for some) the consultant reviews the report. They may need to look up the patient’s letter themselves if the attached letter isn’t sufficient. If necessary, they may return the report to the secretary with a note to request the patient’s medical records if that too is insufficient.
- The consultant dictates their interpretation of the scan result and any consequent actions into the dictation system. This is typed by a typist and returned to the consultant for verification. When verified the dictation system sends an electronic copy to the GP surgery and the typists print a copy to send to the patient in the post. A further copy is printed for filing in the medical records, but that is a system that is months and months behind.
- If the scan was requested by a junior doctor, the consultant returns the paper copy with a note to the secretary to pass it on to the junior, who goes through a similar process as above, other than their dictation must be approved by a consultant before printing/sending
Workflow analysis: too many cooks, or not enough chiefs?
Initial analysis suggests that ‘acting upon requests’ is the most inefficient stage here. A decent workflow should not require the intervention by the secretary to sort and print the reports, or even the use of a spreadsheet at all. The doctor should be able to access the appropriate report, patient records and images directly, and then input his analysis without further interaction with the secretary (possibly through the application of dropdown options, with additional textarea for observations outside of dropdown scope). It seems that the secretary is acting as a sorting algorithm that has not been formally codified in the workflow, but that could easily be automated. It may be that the software is supposed to do this sorting, but that it is not sufficiently flexible to cater for some/most of the use cases and so has been circumvented for the sake of accuracy.
There are a number of other issues with the workflow: mostly with the input of data, sorting of data and the notification of important parties in the chain. Most of these are common to large institutions with sprawling software systems that have not been effectively managed or optimised to integrate properly. Most of these software systems may have been developed by different companies who have no financial interest in integrating with other software, or worse still: the businesses may no longer exist.
There may be no quick fixes in this situation, in fact, the situation may be absolutely unavoidable once institutions become a certain size. This may be because hospital workflows are more akin to complex adaptive systems than the linear systems as employed in manufacturing and other more commercial institutions. Trying to optimise discrete parts of the workflow without taking into account the resulting knock-on effects will only lead to more inefficiencies that are unaccounted for. These workflow issues present rather like a Lernaean Hydra: except that the two heads regenerate out of sight and possibly days later when the swordsman has long departed.
Some research has demonstrated that nurse (and arguably most hospital) workflows are complex adaptive systems susceptible to the Pareto principle: 80% of the disruptive effects come from 20% of the causes. Having flexibility in these causative areas, so that individuals can adapt how they respond on a case-by-case basis, is vitally important and naively targeting these areas for optimisation alone will only cause more disruption elsewhere. If you were to employ a discrete software solution, that solution would have to incorporate user-led configurability to be any use at all. Simply prescribing a rigid, linear workflow of an idealised use case would only lead to its circumvention in most of the real-world use cases.
One of the chief benefits of having an NHS is supposedly the ability to implement policy across or within trusts, without the atomisation that would occur in private health care. Unfortunately, there is also a history of government mishandling of large IT projects: with over £10 billion wasted on a Lorenzo patients record project that resulted in 14,000 patients being discharged without medical notes and will cost £7 million to fix. A consequence of this incident is a fear of failure; keeping the software small and discreet within the trust is a way to localize responsibility to managers and committees rather than politicians.
A GP practice in Brighton has engaged with a workflow management administrator and optimised their letter processing workflow to reduce the time spent on non-clinically important documents by 80%. This approach may be productive in the imaging workflow, as administrators lack awareness about the data resulted in the obfuscation of important patient or doctor information. However, the role of the secretary is arguably that of a workflow management administrator, and it may just be a case of upskilling the existing employees to factor in optimization approaches rather than act as a replacement for an algorithm.
Whatever the solution may be, it is important to acknowledge that:
- Hospital workflows are complex adaptive systems that cannot be rigidly formalised
- Any changes to the workflow are not discrete and separate, there will be upstream/downstream consequences
- Technology is only a solution if it is non-linear and itself adaptable/configurable by the user
- Employees opting out of an automated system is an indictment of the system and not the employees – there needs to be forward accountability
SwiftCase helps thriving businesses, swamped by growing demand, automate and organise, to focus on what matters — loved by 1000s of users across Insurance, Finance, Legal, Service & Contractor sectors.