Digitisation and Automation of the Gloucestershire Hospitals NHS Foundation Trust Lung Cancer Pathway

15% of patients referred locally with a suspicion of lung cancer do not start treatment within the current national target of 62 days from referral. These 15% are also the patients most at risk from long delays, often becoming too unwell for treatment during this time, with subsequent impact on their survival. There are several research studies that have shown worse prognosis for a range of cancers with prolonged referral to treatment times.1-3 Any reduction in the time from referral to treatment is expected to improve outcomes and in 2020 the National Optimal Lung Cancer Pathway (NOLCP) stated that the maximum waiting time should be reduced from 62 days down to 49.4 The national target will likely move to this reduced time-frame.

In order to optimise the local lung cancer pathway, there are many steps that need to align perfectly. Referrals need to be processed, clinics booked, investigations need to be ordered, results need to be acted upon, the patient needs to be discussed in MDT and clinical teams need to liaise with the patient and other staff members (see figure 1 and 2). Alongside this, the patient needs to be calmly led through this very stressful time. By speeding up the pathway, the time the patient is in limbo regarding their potential diagnosis can also be reduced.

One of the issues with current cancer pathways is the increasing complexity within the pathway itself. In order to ensure patients are selected for the most appropriate treatment and to increase opportunities for radical treatment there is a need for more diagnostic, staging and fitness investigations, with some results requiring clinical review before the next step of the pathway can be actioned. Historically this occurred in an MDT meeting, but this means defaulting to a weekly decision-making forum, which delays pathways and overloads MDT meetings. NOLCP states that all tests are requested as a bundle at the outset (triage or first clinic appointment), with further clinical decisions relating to diagnostic pathways taking place outside MDT. MDT discussion then occurs once all necessary results are back and treatment decisions can be made. However accelerated management of pathways outside a weekly MDT requires a process which is able to chase investigations and flag results for action on a rolling basis to the appropriate clinician. It is clear there are many steps that need to be undertaken to timely progress a patient down the cancer pathway. New strategies need to be implemented to help optimise the pathway. One option is to digitise and automate as many processes in the pathway as possible. This is a route our department wishes to take and is discussed in the following sections.

Figure 1. The current 2017 National Optimal Lung Cancer Pathway, with a 62-day referral to treatment target

Figure 2. The new 2020 NOLCP, applied to the local processes, with a 49-day referral to treatment target

Potential Benefits of a digitally supported pathway

The digitally enhanced pathway will automate commonly undertaken tasks, facilitating requests at the earliest opportunity. This will also speed up clinician’s workflow, so they have more patient facing time. The faster pathway will also help improve a patient’s prognosis
The aim of this body of work is to also improve patient safety by reducing near misses and by speeding up the patient pathway so to improve their prognosis.
Improvement of patient experience is also important in this new pathway. By speeding up the pathway, and so reducing the period that a patient is awaiting final treatment, and with sending patients links to patient information videos, it is hoped to greatly improve the patient experience
The new pathway will use digital solutions to communicate investigations to the appropriate clinician as soon as the information is available. Requesting information and appointments etc will be made visible within the system. Digitising and automating the lung cancer pathway will alleviate the need to manually chase scan dates, look up results and liaise with different teams. This way, the coordinator can be more patient facing
Digital enhancements provide an opportunity to improve the patient experience by timely targeting of patient information videos (PIVs). These PIVs will introduce the patient to the members of the cancer team and explain to the patient, in lay terms, the investigations that have been organised for them as they progress through the pathway
The work from the lung cancer pathway is planned to be open source and modular. This will allow other cancer/disease sites and trusts to utilise, benefit and collaborate on this work

Time saved

Potential reduction to delays in the pathway with digitisation and simple automation could range from 4-12 days. More complex automation (including machine learning) could further improve these time savings:

Process	Current time to undertake	Potential time to undertake with new system	Delay reductions
Automatically get new referrals from e-RS	1-5 days (booking personnel download and add to PAS)	2 hours (if run retrieval every 2 hours)	1-5 days
Informing clinician and then clinician to act on investigation results	1-2 days (coordinator chases results)	2 hours (if results checked every 2 hours)	1-2 days
Booking patient into next available lung cancer clinic	1-3 days (done by booking office)	Instantaneous	1-3 days
Ordering investigations during MDT discussions	1-2 days (clinician normally does this outside of MDT)	5-10 mins	1-2 days

Table 1. Potential time savings with digitisation and automation

What the pathway currently looks like

Booking office has to manually download a referral from the eRS referral system
Booking office has to add patient to the local PAS system ready for vetting. The referral is also sent to a lung cancer specific email inbox
Clinician needs to read and vet referral
Clinician may request CT chest at this point if not already booked
Once CT date is known then an outpatient appointment needs to be booked after CT if cancer likely, or if cancer unlikely then clinician triages again after CT and decides if 2 week wait appointment is required
Clinician needs to see patient in clinic, explain likely diagnosis, order investigations and make referrals
Lung cancer coordinator needs to check for results (at several points in the lung cancer pathway) and then inform clinician that these need to be acted on
Clinician needs to act on above, potentially booking other investigations, biopsies or add to MDT
COVID swabs need to be confirmed as negative for patient to have aerosol generating procedures (AGPs), eg bronchoscopies, EBUS
A lot of coordination needs to happen for EBUS as PET-CT and COVID result needs to be reviewed before proceeding to EBUS
Clinician needs to decide when to add patient to MDT once enough information is available
Coordinator to organise and run MDT
MDT decides on next steps (but more of a formality now as a lot of work is done outside of this meeting):
- Further investigations organised if needed
- Referral to oncology, surgery, palliation or discharge once diagnosis determined
Coordinator records outcomes of MDT

Overview of new pathway

We will be calling this new digitised and automated lung cancer pathway ‘Spiritum Duo’ (Latin for ‘breath two’). It will be abbreviated as ‘SD’. The aim of this new digitised and automated lung cancer pathway is to:

Takeover or simplify, as much as possible, simple, time consuming and repetitive tasks
Retrieve data, and retrieve it early, interpret it (via clinician, hard code or machine learning) and progress patients down their cancer pathway as quickly and safely as possible
Use patient information videos to enhance the information given to and the experience received by patients regarding their condition and what they should expect next from the pathway. These patient information videos will be created and curated by the relevant disease bodies and housed on standard online video servers (eg YouTube)

The pathway, digitised and automated

Each step of the current pathway will be reviewed, discussed and assessed for if it can be digitised and/or automated. Of course, we will not digitise for digitisations sake, and if a task is better undertaken in paper form, we will not force a digital solution on said task. Where a step cannot be automated, then we would need to discuss how a clinician or admin person could direct the pathway manually. The latter should be designed so a clinician or admin person is giving information quickly and with as much detail as needed so that the patient can be quickly progressed down the pathway again. We will liaise with the cyber security and information governance teams to make sure all digital tasks are secure from external attack and data security. Looking at the pathway in a step-by-step manner, areas that can be digitised and/or automated are:

Downloading referrals directly from e-RS using RESTful API and importing directly into SD
Automatically book a patient into clinic before (on passing set criteria) or after vetting
Inform clinician that a new referral has been received and needs acting on. This can be done via email, SMS message or via a purpose-built mobile app
Integrate existing clinician rota within the digital pathway so that information can flow to the appropriate clinician
Send patients, either via SMS, email or letter, links to PIVs (patient information videos). This can be done via GOV.uk Notify or AccuRx. Currently GOV.uk Notify allows a 25,000 SMS message to be sent free of charge, with a small fee per SMS thereafter. Accurx is currently free for sending SMS messages (but has no API for secondary care)
Retrieve future dates of requests, so that other subsequent-dependent request can be booked in at the earliest opportunity
Retrieve reports of investigations and inform the correct clinician that these need to be acted on. API or SQL can be used to obtain this information from the corresponding investigations and radiology databases. Other methods include web scraping and using the trust’s TIE (trust integration engine) to capture new results. The web scraping method is likely to be less stable
Build a secure mobile pathway app, that alerts a clinician that there are results that need to be acted on, and allows decisions to be made directly on the app to progress the patient on their pathway
Have bespoke triage, clinic and MDT noting functions which are integrated with relevant results, observations and appropriate requesting systems including PIVs ordering/prescription
There is time to be saved by making requests during MDT, when it has been decided to make these requests, rather than afterwards. This is due to the large number of patients to be discussed in MDTs and the lack of time to organise requests in the MDT itself. This means that urgent PET-CTs, MRI-heads, etc are left until the next day to be sent off. If you had a clinical details box that you filled in either at triage or clinic, which could be automatically copied across to the request form, then this could very quickly be sent during MDT with just the click of 2-3 buttons
The patients on the MDT list could be automatically spread across the list so that each clinician has the maximum amount of time between their patients to document outcomes and make requests
Automated moving of presented patient in MDT view when an MDT navigator moves to next patient. Helpful if clinicians have the MDT view open on their own devices (laptop, smart phone, etc). Clinicians will be able to move back to previous patient / other patients, so that they can request investigations and then re-join the MDT
MDTs could be further transformed by the use of “async MDTs”. This is where most, if not all, decisions are made outside of the MDT, where people act on results, clinical history and requests from colleagues when these become available rather than discussion in weekly meetings. In the actual timed MDT slot itself, this would just be a formality to voice the agreed plan from the multi-disciplinary team
Allow access to oncologists, surgeons and palliative care to the digital pathway. Perhaps have flags for these specialities so that they are made aware of patients that are likely to be referred. The oncologist could add a communication note to the respiratory physician managing the investigation pathway
GPs could have access to the above so that they can see where the patent is on the pathway and can discuss this with the patient if required. Helpful for when a patient does not fully understand or retain information given to them in a cancer clinic and then they ask their GP for clarification
When a referral to oncology, surgery or palliative care is made, an automatically written summary of the patient’s pathway can be forwarded
Graphical presentation of all patients on the pathway, showing where they are on the pathway and how far they are from breaching. This would help capture early, intervene early and progress a patient who is close to breaching in a visual format
In-built audit functionality for both local and national audits
Automated sending/uploading of data to national audits sites
Electronic consent with associated patient information video to offer quick, consistent and well-informed consent

What digital solution to use?

There are 3 possible solutions for the housing of this new digitised solution:

Building of the cancer pathway within the trust’s EPR system Sunrise from Allscripts. However, from reviewing what Sunrise is currently capable of, it is not clear if this is possible
Building of a modular and open-source program that other cancer / disease sites, NHS trusts and even hospitals in other countries could contribute to and benefit from
Although no “off the shelf” digital solution has been found from online searches, an alterative commercial product could potentially be used to house the new cancer pathway

For communication between clinical systems, there are potential 3 solutions:

Robust and tested backend communication with API, which is now a digital technology standard and the only means of true interoperability (eg HL7 FHIR)
Open-source RPA
Commerical RPA

We feel that an open-source solution would benefit both the local service and other disease sites and trusts. Open-source is generally accepted and applies to open code and not open data. Hence no patient confidential information is ever placed in the public domain. Open-source programming code is normally stored online in repositories for anyone to access, work on, comment and share. Many large companies are using open-source code, including Microsoft, Facebook and Google. By using open-source software, the code can be reviewed by many different people and hence improved. It also allows greater collaboration and sharing of code and knowledge. The rest of this document discusses our reasonings for this.

Digital infrastructure – aerial view

An aerial view of the new digital infrastructure required for the new lung cancer pathway contains:

A purpose build backend database to store information pertaining to the lung cancer pathway that does not fit within Sunrise EPR or general trust’s databases
A front-end graphical user interface
Programmatic access to the trust’s database to retrieve patient information such as demographics and investigation results
Means to inform the appropriate clinician that there are alerts that need to be acted on
Web hosting to hold patient information videos
Button in Sunrise EPR to open SD

Digital infrastructure – granular view

Planned functionality on a granular view:

Full stack web app (see “Technical design section”)
Open source PostgreSQL database backend
A modular build of the pathway. This way other specialities and trusts can use SD, using the modules as needed, with minor alterations, to fit their local needs
Use SNOWMED CT for diagnosis classification
Use HL7 FHIR communication protocol between clinical digital systems
Several (human) languages will be supported so that the digital solution can be used internationally
A button in Sunrise EPR to open the lung cancer digitised pathway. This could be limited to only certain clinicians or only available if the patient is on a cancer pathway
Graphical building interface of digital pathways. This would be similar to flow charts in Microsoft Visio. This would make it much easier for people with less coding experience to build their own version of a disease specific digital pathway

The exact elements that would be needed to bring SD to fruition, and within an acceptable time frame, are:

Programmatic access to trust databases
Admin rights to install programs that are needed
GitHub website access (currently blocked to all users)
Server space for new SD PostgreSQL database and web app
Docker container program installer
Backup capabilities of above database
SSH access to database and web server (port 22)
Internal / external URL address for web app
Virtual desktop to undertake RPA
Access to trust’s backend and development environments of EPR system
Quick access to IT staff with in-depth knowledge of trust’s IT systems, interlinks and databases
GNHSFT YouTube account (or similar) to host patient information videos
Training of current and new staff on how to use, manage and maintain the new digital system
Clinical safety certification, through MHRA, DCB 0129, DCB 0160 and ISO 27001
Funding for all of above

Collaboration

This digital solution cannot be built in isolation. We will need to build links and collaboration with several different teams. Below are interested parties who would want to collaborate on this project:

We are currently creating links with Gloucestershire University. We currently have 2 computer science placement students working on this project and we intend to fund two more next year. This will help towards the trust’s 5-year strategies including digital transformation and research capabilities. This will also potentially help the trust gain University Hospital status
We will also liaise with Gloucestershire University’s media department to build patient information videos
The trust’s QI team is interested in a QI Bronze, Silver and Gold Award equivalence in clinical informatics at GHNHSFT. This could run alongside the standard QI courses for those doing quality improvement but with a digital transformation angle
Oxford University Hospital (Grant Vallance, Information Manager)
SWAG cancer alliance
When the work on SD is in a stable phase, funding could be made available to allow SD to be used in developing countries

Phased implementation

The Spiritum Duo work is envisioned to be implemented in 3 phases. This work (and any subsequent spin off works) could be carried out within the trust’s new “Clinical Informatics Workstream” (a clinical informatics innovation hub).

Phase 1

Building of web app
Automation of retrieving of eRS referrals
Automatically checking for results and investigation times
Automatically sending results to clinicians to act upon (email based or downloadable web app)
Use of SMS messages to send patient links to patient information videos
Connection to trust’s databases
Benefit realisation

Phase 2

Charts of numbers of referrals, RTTs etc for internal audit functionality
Connectivity to national audit processes (to automatically upload data for national audit)

Phase 3

Graphical interface to help other departments and trusts with less IT training build their own pathways
Research of anonymised data to gain better understanding of the clinical pathway and patient disease.

Research

This new digitised and automated cancer pathway will be built as a research and development project. However, the primary goal is to create a digital product that is fit for purpose and can be used in real life clinical settings. Initial work will of course be on a proof-of-concept. Hence, the new pathway has to undergo extensive testing, show benefit, safe for patients and has passed clinical governance standards.

Primary outcomes

Speed up pathway (referral to treatment time)
Improved average patient prognosis

Secondary outcome

Reduction in breeches
Improved patient experience
Reduce clinician administrative time
Reduce admin staff administrative time

Balancing measures

Stress to patient as pathway is now too quick and little time for patient to process their new diagnosis
Loss of lung cancer coordinator position as potentially no longer needed
Loss of booking office positions as potentially no longer needed

Potential risks

As with any new digital implementation or change in clinical pathways, there are potential risks that should be mitigated as much as possible. Potential risks are:

Patient lost from pathway
Wrong data collected for patient
Wrong data sent to patient (ie clinic letter, patient information video link)
Investigations not ordered
Wrong investigation ordered
Investigation ordered for wrong patient
Breech of patient confidential information
Actual mental or physical harm to patient

Each individual risk will have to be analysed, discussed and methods put in place to minimise the likelihood of any of them happening. Formal clinical governance practices will have to be applied. All works will be taken through clinical safety group channels / Clinical Informatics Workstream.

Why open source?

There are many benefits with using open source rather than commercial / closed source products. These benefits include:

Build once, share several times. This leads to savings in both time and money to the NHS as a whole
Ownership of a local version of a program by a department or trust. This allows bespoke systems that are much more flexible and that can be tailored to work efficiently in the local environment
The main code can be used and changed by anyone (after review of the changes by a moderator). This accessibility allows for constant development and improvements to the code
Much like in the practice of medicine, open source runs on the philosophy of universally shared knowledge. New ideas and solutions are combined and promoted for the community’s benefit
The licensing of open source software is significantly reduced compared to its proprietary counterpart
No lock in or long-term commitments to a supplier should local situations change
Not prone to changes by a vendor that can break or even stop the program from working (the loss of Microsoft Access in Office 365 is one example that did affect our department and the management of the sleep, bronchiectasis and tuberculosis services)
Cannot be pulled by vendor if they no longer wish to support the program
Open source will always be available as long as there are people interested in using the system

Initiatives and support for open source in the NHS are seen from:

NHS (https://service-manual.nhs.uk/service-standard/12-make-new-source-code-open)
NHSx (https://www.nhsx.nhs.uk/about-us/what-we-do/), their open source repository on GitHub (https://github.com/nhsx/) and the COIVD-19 app (https://www.nhsx.nhs.uk/blogs/code-behind-nhs-covid-19-app/). See also (https://healthtech.blog.gov.uk/2019/04/23/what-does-it-mean-for-nhsx-to-be-an-open-source-organisation/)
NHS England (https://www.england.nhs.uk/digitaltechnology/open-source/)
Code4Health (https://code4health.org)
Public money, public code (https://publicmoneypubliccode.org.uk/)
Royal Colleague of Paediatrics and Child Health Digital Growth Charts (https://github.com/rcpch)

Initiatives and support for open source outside of the NHS are seen from:

Government (https://gds.blog.gov.uk/2017/09/04/the-benefits-of-coding-in-the-open/)
Government Communications Headquarters, GCHQ (https://github.com/GCHQ)
The National Cyber Security Centre, NSCS (https://github.com/ukncsc)
National Crime Agency (https://github.com/NationalCrimeAgency)
Microsoft – GitHub and VS code

Who uses python?

YouTube
NASA
Dropbox
Instagram
Spotify
Pinterest
Mozilla

Who uses PostgreSQL?

Apple
International space station
Skype
Instagram
Spotify

Who uses open source web app frontends:

Facebook (creator of React library)
Google (creator of Angular framework)

Funding

Of course, all of these works will require a workforce and money to realise the full benefits of the digitalised and automated pathway. Funding will be gained from research grants and NHS bursaries. It may also be possible to create capital by providing services to help set up SD in other trusts and also by providing “software as a service” and hosted solutions on a sustainable commercial basis. Also paid for training for trusts to setup and maintain their own local SD installation could be run.

Technical design

Initial plans were to keep the software design of Spiritum Duo as simple as possible. After much research, this is still the thought process, but the design has expanded somewhat as learnings showed that to make a modular and open-source digital pathway, some new core digital architectures were required. These architectures include building a full stack web app with separate front and backends and utilising containers. We will be using a graphQL API and using a JavaScript frontend. The backend is written in python.

The design of Spiritum Duo, starting from the frontend web app, is as below. Several of these components have already been built:

A full web stack development with separated front and backends. This will allow other systems to access the data on the SD / trust’s database via its API
The source code will be openly available on GitHub (https://github.com/spiritumduo/spiritumDuo). This is under an MIT licence
The web app design will be a single page application (SPA) with a progressive web application (PWA) architecture. This will be written in TypeScript, using the React and the Apollo graphQL frameworks. Bootstrap will be used for styling.
The use of PWA will allow the web app to be installable on both computers and smart phones and permit the usage of push notifications. This latter technology will allow the clinician to quickly be alerted to new investigation results and to then outcome and quickly progress the patient’s pathway
The use of SPA and bootstrap will allow for a much more streamlined and modern end-user experience
HTTPS will be used for encrypted data transfer between front and backend
GraphQL will be used as the API to the backend. This will help to reduce the amount of patient identifiable information that is sent over the web compared to REST API
Spiritum Duo will run on Docker containers. Kerbenetes or nomads could be used for advanced, cross server orchestration should the usage of Spiritum Duo expand across several trusts or sites. These containers will need to be run as non-root to improve security
A configured Nginx reverse proxy will offer up secure https communication
Nginx will also separately offer up static and media files
The frontend will be served up as a static transcribed javaScript file
The https security certificate will be provided by “Let’s encrypt” and be automatically updated
The backend graphQL API endpoint will be delivered by a python backend through
A dedicated PostgreSQL database will house data pertaining specifically to the Spiritum Duo digital pathway
A python library or virtual machine will be used to check for new investigation results every 2 hours during normal working hours. New results can be interpreted with natural language processing to determine the urgency and based on this alert a clinician for their input to progress the patient’s pathway. Alternatively the trust’s TIE could forward any new results to SD.
Automatic retrieval of new referrals from the NHS eRS (electronic referrals system) via their new eRS API. This will soon have automated authentication rather than smart card usage
A trust (specific) integration engine to connect Spiritum Duo to a trust’s patient demographics, CRIS radiology bookings, radiology reports and lab results databases.
If there is no availability to official backend means to communicate with a clinical digital system, then a dedicated desktop program can be built to interact with legacy systems through robotic process automation, COM and APIs
During development, or as an alternative communication method, the NHS mail exchange service can be used to send results and pathway updates to clinicians
Links to GOV.uk Notify or AccurX will be needed to send patient information videos and general updates via SMS messages, emails or letter. Currently GOV.uk Notify has its own REST API, but AccurX can only be connected from secondary care via web scraping
Patient information videos will most likely be housed on a dedicated YouTube channel. “On the fly” YouTube playlists can be used to send a patient several videos to watch with the use of just one link for them to press on within a SMS message or email

During development:

Initial development stages will use pseudo-patient data and not have actual connectivity to real trust patient data until the development stage has been fully tested and shown to be secure
A dedicated webserver at the URL https://www.spiritumduo.com. DigitalOcean has been used as the webserver. The domain name has been bought on a 2-year contract from goDaddy.com with nameserver forwarding to a DigitalOcean Droplet.
There will be a landing page written in WordPress (and a MySQL database) for presenting information about the project to the public and to potentially house discussions between developers.
During development, interested parties can trial the online web app and give feedback

Figure 4. Software design of new digital pathway. Colour coding is used to show which areas are universal for different disease sites and trusts (‘Spiritum Duo specific’) and which areas are trust specific.

References

1. Mortality due to cancer treatment delay: systematic review and meta-analysis, Hanna, BMJ 2020, https://doi.org/10.1136/bmj.m4087

2. Chen Z, King W, Pearcey R, Kerba M, Mackillop WJ. The relationship between waiting time for radiotherapy and clinical outcomes: a systematic review of the literature. Radiother Oncol. 2008 Apr;87(1):3-16. doi: 10.1016/j.radonc.2007.11.016. Epub 2007 Dec 21. PMID: 18160158.

3. Biagi JJ, Raphael MJ, Mackillop WJ, Kong W, King WD, Booth CM. Association between time to initiation of adjuvant chemotherapy and survival in colorectal cancer: a systematic review and meta-analysis. JAMA. 2011 Jun 8;305(22):2335-42. doi: 10.1001/jama.2011.749. PMID: 21642686.

4. National Optimal lung cancer pathway , https://www.cancerresearchuk.org/sites/default/files/national_optimal_lung_pathway_aug_2017.pdf, accessed 24/05/2020

Table of contents

Glossary

Introduction