Momkhulu Hospital Resource Allocation Tool
In maternity hospitals, the time between a patient being scheduled for a caesarian section and the operation itself is of utmost importance. Known as Decision to Delivery Interval (DDI), it is one of the biggest influences on the outcome of the operation. It influences the health of the baby and the mother after delivery. A shorter DDI minimises the risk of permanent harm from intrauterine hypoxia thus improving neonatal morbidity and mortality.
Guidelines propose recommended DDI limits for caesarean sections depending on the urgency of the indication for the operation. When mothers or babies are at risk of imminent harm, delivery should occur faster, and it is important for decisions to be done transparently, fairly and efficiently.
This blog centres mostly around a technology solution that can help improve efficiency. I believe that any technology solution should be centred around the users and in order to build a way for clinicians to communicate efficiently with each other on this decision. we designed the tool in a collaborative user-centred process with the University of Cape Town Department of Anaesthesia and Perioperative Medicine. I want to describe the design process of a hospital resource allocation tool to help the clinicians reduce the time taken for organising operations in the hopes others can learn from the importance of putting patients at the centre of designing medical solutions.
Design Specifications and Requirements
Clinicians running maternity operating theatre services frequently use a whiteboard to coordinate patient flow. Patient records are written manually. The entries on the whiteboard provide the clinicians with a list of the operations pending for that day and the most critical information about the patients including:
- Patient ID
- Name
- Age
- Urgency
- Indication
- Urgency
- Comorbidities
- Gravidity and Parity
- Time of booking
- Location in Hospital
The whiteboard system has drawbacks:
- One has to physically walk to the whiteboard to see the information on it, so it is not readily available to clinicians across the hospital.
- The whiteboard is updated manually and thus not in real-time.
- The whiteboard cannot store information about other details of the ongoing and finished operations.
- Once the whiteboard has been cleared, the information is no longer available.
- This whiteboard is erased every day in the morning when staff coming in for their morning shift.
We want to create a tool that addresses these challenges. The designed application must have a terminal or web page where all the relevant clinicians can view the patient information shown on the whiteboard. In addition, the display needs to be in a tabular form, allowing clinicians to have a quick view of the patient entries. Further, the designed page needs ease of functionality to erase and delete some of the patient entries entered. Most of all, it needs to be optimized for universal ease of use so that all the different clinicians can quickly learn the application and take advantage of its abilities.
The Design
WhatsApp and RapidPro
Since the clinicians desired a faster way of sharing information, we thought WhatsApp would be an effective way to enter patient data. To connect the web application to WhatsApp, I used RapidPro. RapidPro is an application built to interface with messaging platforms, including SMS and WhatsApp. It allows messages to be sent and received from its flows and also integrates to other apps using webhook functionality. RapidPro’s webhooks can make API calls to other web applications and transfer the information in the messaging flow.
I used RapidPro flows to design user interaction with the app. Each flow has several predefined question and routes which one can take up depending on what information they want to pass to the application or changes they would like to make. An example is a Patient Entry flow, in which a user is successively asked patient details until it saves the patient entry. I designed a few flows, including a Change Information flow, a Patient Delivered flow and an Operation Completed flow. A screenshot of the RapidPro flow design interface is shown below.
Django and the Django REST Framework
Django was the default choice for the development of the web application. Django is one of the most popular and stable Python-based web frameworks. Django has many inbuilt features, but I felt it was also necessary to use Django REST Framework, which is an extension to Django for use specifically for RESTful APIs. I designed specific API endpoints for RapidPro’s Webhooks. These API endpoints became the bridge of information between the RapidPro and the application.
Django Channels
The app required the instantaneous update of the website and browser screens showing the patient information. Instantaneous updates were important because they allowed the clinicians around the hospital to be up to date with what was going on in the hospital in real-time. With the relevant clinicians always up to date, organizing operations would become more efficient.
To achieve this, I used Django Channels, which is another extension for Django. Django Channels uses the WebSocket protocol for connection instead of HTTP. HTTP, which is the most common web protocol, works by a client sending a request to the server, and the server responding after processing the request. This means that the client can only receive new data if they have requested it. Now if the client desired to get almost instantaneous updates, they would have to keep polling the server for data through a loop, which is very wasteful of resources. WebSocket, on the other hand, opens a connection between the client and the server and keeps this connection open. This allows the server to push data to the client asynchronously without the client requesting it, which is far more elegant and resource efficient! It allowed me to design the app in such a way that if there is any change in the patient’s information, the pages showing the patient’s information are updated almost instantaneously.
Channels is a project that takes Django and extends its abilities beyond HTTP — to handle WebSockets, chat protocols, IoT protocols, and more. — Channels Documentation.
Because Channels uses WebSockets and is asynchronous, it is more complex and so more difficult to use than Django. While Django uses Views, Channels uses Consumers. The Channels Consumers are the applications which are linked to each of the WebSocket endpoints and connect to the client. The WebSocket connections are initiated by Javascript in the client’s browser. The client-side Javascript requests the WebSocket connection to a particular Consumer and keeps this connection open. While the connection is open, the WebSocket on the client-side listens for any asynchronous messages from the Consumer application.
To ensure that the page is up to date at all times, every update to the patient entries triggers the application to send an update of the table to all connected browsers via the WebSocket. On receiving the updated table, the script on the client-side updates the view page.
What is most interesting about Channels is its implementation of WebSockets. The use of WebSockets means that the deployment of a Channels based application is in a few ways different from that of a regular Django application. Because it is asynchronous, Channels is run through ASGI (Asynchronous Server Gateway Interface) instead of the regular WSGI (Web Server Gateway Interface). Since Channels needs ASGI, it is deployed using the Daphne server. Daphne is a web server designed for Django Channels since the WebSockets do not work with synchronous servers like Gunicorn.
Javascript and JQuery
The implementation of Channels required a client-side script capable of setting up the WebSocket connection with the Consumer on Channels. Apart from using JavaScript just for the WebSockets implementation, JQuery came in handy again in the design of responsive web pages.
Bootstrap 4
I used Bootstrap 4 for the design of all the pages of the web application. Bootstrap is a front-end framework for rapid development of responsive web pages across all device sizes. I felt it was important that clinicians should be able to view the page on all kinds of devices, from a large screen terminal to a small mobile phone, allowing them flexibility in the way they work and share the data. Bootstrap along with some custom CSS allowed for the rapid development of a standardized and attractive page which could be used across all browsers and devices.
Final Implementation and Deployment
Using the above-chosen technologies, I managed to create a Minimal Viable Product (MVP) ready for testing and deployment.
The MVP was a success, with all the features working as expected. Changes in patient entries triggered an instantaneous update of the all the open web browser pages. The minimal delay meant that all connected browsers were always up to date with the patient entries.
Additionally, a page to view more detailed information about patients was implemented. A user could be directed to in the information about a particular patient by clicking on any of the patient entry rows. This would allow the clinicians to view more detailed information about the patients which could not fit on the patient entry tables.
Recommendations
As the application is an MVP, there are still a lot of features that can be implemented which might better its use in a practical environment.
Since the clinicians at the hospital had already been sharing images of the board, it might be useful to have an API endpoint which will produce an image or screenshot of the current state of the application.
Adding buttons to the user interface can allow the users to better navigate the system. With the introduction of buttons to the UI, it will be easier for the clinicians to navigate the around the application and easily get to their desired pages.
A screen can be erected for display by the hospital to replace the existing whiteboard to provide a central place for them to see the patient entries. The screen can be the display of a computer or even a small Raspberry Pi, with the computer or Raspberry Pi open on the View page.
I believe rolling out the application to clinicians and capturing their feedback is critical for further development. Through an iterative process, feedback from the clinicians can be utilised to develop and refine the application’s features.
