Intern Project

PatientSight

Our six interns, Dhylan, Emma, Sreedda, Zoe, Elise and William, and two fellows, Noo and Fred, spent 8 weeks this summer working on solutions aimed at improving patient flow in hospitals.  

What was the journey to Patientsight? 

During the first few weeks the interns focused on one aspect of patient flow: capturing bed occupancy from hospital wards and finding solutions to improve the current system. This incorporated research into RFID Tagging and Infrared sensors, QR codes, Wifi and Bluetooth tracking. 

On the third week of their internship, the interns visited Addenbrooke’s hospital. They talked to nurses, doctors, porters and bed managers about their ideas and solutions on how to optimise patient flow and bed occupancy. They observed that many hospital beds were occupied by patients who were clinically fit to leave the hospital but were waiting on administrative tasks and/or prescriptions to be completed, keeping patients who needed a bed waiting. They also learned about the dissatisfaction and frustration felt by patients and visitors by the lack of updates on their care. One factor that causes this is the lack of communication and information ranging from the waiting time for surgery to that of being discharged from hospital. The interns decided to focus on the discharge process, making the information regarding the different stages of it available to patients. This is how Patientsight was conceived and developed. 

What is Patientsight? 

Patientsight makes information on the discharge process transparent to patients and hospital staff. It relies on information stored in a hospital’s electronic health record (EHR). Once a patient has been deemed clinically fit to leave, the process for discharge commences. A series of items need to be sorted and checked before a patient is able to leave the hospital. This might include categories such as: medication, transport arrangements, medical device given, discharge paper work etc. Patientsight aims to expose the status of each of these categories from the moment a patient is deemed clinically fit to leave until they are discharged. This results in the patient being better informed about their care, allows staff to be aware of pending items and hospital management to be informed of the duration of the discharge process. To achieve this, Patientsight is made up of 3 displays: a large display screen deployed on the wall of hospital ward, a nurses station desktop app and a portable personalised bedside device.  

What did the interns work on? 

The interns split up into smaller teams to work on different aspects of the PatientSight prototype: 

• Creating dummy patient data  
• Receiving data from Electronic Health Records and sending it to the different displays 
• Creating the desktop and display screen views 
• Creating the personalised bedside device view 
• Creating a business value proposition 

Creating dummy patient data 

Elise and Zoe created a dummy discharge patient dataset.  

Given that the interns did not have access to an Electronic Health Record (EHR) with real-world patient data, this simulated EHR allowed for testing and demonstration of the prototype. Many EHRs across the NHS use a standardised FHIR (Fast Healthcare Interoperability Resources) protocol for passing information between systems. As a result, they decided to base their product on this standard.  

Elise and Zoe wrote a python script to create patient records and then update them over time to simulate patient’s journeys. Much effort was made to ensure that these hypothetical patient journeys were realistic and progressed in logical steps.  

This data then got added to the HAPI FHIR server – an open sourced FHIR API for Java.  The API calls developed by Fred and Sreedda (described below) can therefore be applied to both the dummy patient data on the HAPI FHIR and to a real EHR as they both have the same structure. 

Receiving data from Electronic Health Records and sending it to the different displays 

Fred and Sreedda worked on making API calls to the EHR database, processing this data, and returning it in a form which was compatible with the website and personalised bedside display.  

For this segment, they employed cloud computing to allow the solution to be deployed over multiple regions and to limit the physical need for additional servers in hospitals. The platform used was Amazon Web Services (AWS), more specifically, AWS Lambda Function, API Gateway, and AWS Internet of Things (IoT) Core.  

The AWS Lambda was accessed via an HTTP API (configured using AWS API Gateway). When invoked, the lambda function would then make multiple API calls to the EHR server to extract relevant patient information and store it in a dictionary which could then be returned to the website. Additionally, a second lambda function was built to publish messages to the personalised bedside device using AWS IoT and MQTT messaging. 

Creating the desktop and display screen views 

Dhylan and William developed a website to view the data on the desktop and display screen. This initially used a static Json file to create an HTML table. They then further developed the website by adding an option to view five rows at a time in both an automatic and manual configuration for the user. The table was further developed by colour coding entries and filtering out patients who were fit to discharge.  

The aesthetics of the website were really enhanced through the addition of bootstrap files in CSS and JS which enabled them to make a landing page. The landing page facilitated navigation to the different ward tables as well as important information about the project and its mission.  

The final step in the website process was making calls to an API in order to receive a live data feed from the dummy data created. This was achieved using an AJAX post to obtain the patient data at regular intervals whilst displaying it in the ward tables. This data feed was recorded to display the project’s huge potential in the final presentation.  

Creating the personalised bedside device view 

William and Emma worked on the personalised bedside display, a piece of E-Paper (technology used by the Kindle or electronic price tags in supermarkets). The E-Paper is driven by an ESP32 microcontroller, which uses the Arduino framework. 

For the AWS implementation, the ESP32 is subscribed to the MQTT topic created in AWS IoT Core service. When a new message (in JSON format) is posted to the topic via AWS Lambda Function, the message handler in the program is called, which parses (deserialises) the MQTT message, prints icons framework, and updates the patient information to the bedside display. 

There was also a local network implementation, which used a Raspberry Pi as the message broker, and used Node-RED for handling MQTT messages. 

Creating a business value proposition 

Emma created a business model canvas to contextualise PatientSight within the marketplace. She identified the different customers that this product can target, highlighted gains from displaying the discharge information and strategised the key activities required to reach these customers.  

What’s next for Patientsight?

Once again, a group of multi-disciplinary interns came together to produce a remarkable prototype. 

Making the status of the discharge process transparent to anyone in a hospital ward or waiting area gives power to patients and exposes delays. Our desire is to expand this product to display all processes during a patient’s journey within the hospital. Moreover it could automatically create reports for hospital management with time taken to complete each process to better understand pressure points. 

Final Presentation of Patientsight: