A Simple Web Application for Computing Rotator Cuff Retear Likehood
Summary
The rotator cuff is a group of four muscles and their associated tendons that surround the shoulder joint. They act primarily as stabilizers, seating the humeral head in the shoulder socket. Rotator cuff tears remain a therapeutic challenge for orthopedic surgeons. Among other concerns, the fundamental question of whether a rotator cuff tear should be repaired or not still remains unanswered. Various criteria can enter into the decision-making process, such as the patient's age, gender, activity level, tear severity, outlook on surgery, etc. In this project, I created a simple web application that predicts rotator cuff retear likelihood - assuming that a rotator cuff tear is surgically repaired - based on patient and tear characteristics.
Code and Demos
| Retear Prediction | Demo: Prediction | Demo: Map | Python |
| The code in this repository creates a web application that predicts the likelihood of a rotator cuff retear after corrective surgery, given patient and cuff tear characteristics. Feel free to try out the live demo of the code (hosted in a separate environment than the web application utilized by the surgeons). The Google Map feature (based on IP addresses) plots recorded retear likehood predictions on a map. Predictions with a likehood of <30% are marked as green, between 30 and 70% as yellow, and >70% as red. | |||
Current Status
- Complete
Background
This project began when I was approached by the surgeons in our research group to create an easily accessible web application for predicting the likelihood that a rotator cuff would retear after being surgically repaired. They had combined results from several studies, and their own datasets, to create an algorithm for predicting rotator cuff retear likelihood rate based on patient/tear characteristics. They wanted the ability to easily share this tool with their colleagues who were spread around the world. There was 2 additional requirements: 1) store all data input into the calculator (and associated predictions) in a database for later analysis, 2) provide the ability to easily export the stored data to a spreadsheet.
The additional requirement to store the input (and predictions) in a database dictated that this application needed both a front and backend. I had done very little Python programming up until that point, so I decided that this would be a great way to familiarize myself with Python. My previous experience working as an automation engineer had taught me valuable skills for approaching a problem like this (although my projects tended to be larger in scale, the same principles apply). I knew enough HTML, CSS, and JavaScript to tackle the user interface - that would be easy. What I needed to find in the Python ecosystem were these components: a web framework that could accommodate RESTful web services, an Object Relational Mapper (ORM) for the database and one for JavaScript Object Notation (JSON). I also needed to settle on a database technology and to find a web hosting company. However, given how small this application was, it seemed like a waste to pay money for a hosting service. After some research, I discovered that by utilizing Amazon Web Services (AWS) serverless computing, I could host the web application for free. This meant that I would utilize AWS Lambda to "host" the Python application and AWS DynamoDB as the database.
In the end, these are the components that I chose:
- Flask - web application framework for creating RESTful web services.
- PynamoDB - ORM for DynamoDB.
- Marshmallow - ORM for JSON.
- Flask-GoogleMaps - Flask plugin for creating the Google map functionality. The surgeons didn't ask for this functionality but I thought it would be fun to implement.
- Zappa - utility for deploying server-less Python applications to AWS Lambda.
The entire application ended up being 208 lines of HTML/JavaScript, 256 lines of CSS, and 256 lines of Python code. In the end, I was able to quickly create a web application that met all of the surgeons' requirements (and beyond, they didn't ask for a map) and host it for free indefinitely (or until Amazon decides otherwise). This was a fun project for me because it allowed me to use previously acquired skills in a new setting. It was also fun to familiarize myself more with Python and learn how to deploy serverless applications.