Back to Portfolio

SpeedER

Development
University
Description

In my 4th year at The University of Chicago, I took a course called Software Construction. It was one of the more hands-on classes, and our final project consisted of developing a functional web app. Our team chose to create SpeedER, a web application that aimed to reduce the amount of time between the time of injury and the time of care for the patient.

The app consisted of 3 primary actors:

  1. Patients

  2. Doctors

  3. Hospital Administrators (Medical Staff)

Doctors and Hospital Administrators belonged to the same database table, so a Doctor could not sign up as a Hospital Administrator, and vice versa. However, a Doctor, as well as a Hospital Administrator, could sign up as a Patient because the Patient database table was separate.

Patient Walkthrough

The app allowed Patients to sign up and create a "Health Profile," where they'd enter their health history and certain personal information — age, weight, height, gender, insurance provider, etc. This action would allow a hospital to quickly pull up and view Patient Health Profiles when Patients arrived or even when they were on their way to the hospital.

When a Patient injured themselves, they could report the injury with a few clicks on the platform and discover the optimal emergency room to visit — by comparing the estimated travel time and estimated wait time of nearby emergency rooms. Note: because we were manually seeding data (as we weren't able to get real hospital wait time data), we only supported viewing hospitals in the Chicago area.

Based on the estimated travel times and wait times, a Patient could decide which hospital they preferred to visit. Once they selected a hospital, they'd fill out a few additional details about their injury:

  1. Discomfort on a scale from 1 to 10

  2. A description of their injury (they could use the speech recognition feature to have their voice transcribed to text — for instance, if they were in severe pain and didn't want to type everything out).

The injury report would then be submitted to the hospital the patient selected and would also appear under the Patient's "Past Injuries" section under their Health Profile in the app.

Doctor Walkthrough

In the context of the SpeedER app, Doctors were the simplest actors. All they needed to do was sign themselves up for SpeedER so that they could be verified by a Hospital Administrator at the the same hospital (to make sure the Doctor actually exists and works at that hospital).

Once the Doctor was verified, Hospital Administrators could assign the Doctor to emergency Patients. Doctors would receive email notifications (we wanted to include support for text notifications but couldn't get to it in time) after they were assigned a Patient. This email would include the Patient's name and description of the injury.

Expanding upon the above, the sign-up process for Doctors was 2-fold:

  1. They'd first input their name and contact information (email, phone number). Then they'd wait for a Hospital Administrator to manually verify them.

  2. Once a Hospital Administrator verified a Doctor, the Doctor received an email notification with a verification code. Finally, the Doctor would navigate back to the website and input the verification code to complete the sign-up process.

Hospital Administrator (Medical Staff) Walkthrough

After successfully signing up, a Hospital Administrator could access their profile, where they could perform a variety of tasks:

  1. Verify Doctors — A Hospital Administrator can review doctors' names and emails and make sure these credentials align with those of real doctors at their hospital. If these credentials are valid, a hospital administrator checks the doctors' names, and then the app automatically sends all of them an email with their respective verification code.

  2. Assign Patients to Doctors — A Hospital Administrator can match an incoming Patient with a Doctor (at the specific hospital the Hospital Administrator + Doctor works at). The left column of this page refers to the different Patient discomfort levels, and automatically groups and sorts the the Patients from highest to lowest discomfort level. The right column features a list of unassigned Doctors (Doctors free to treat Patients). The middle column includes a box where the administrator can "drop" (drag and drop) a Patient from the left column and a Doctor from the right column to make an assignment. After the Hospital Administrator confirms the assignment by clicking a button, a Doctor receives an email notification with the patient's name and description of the injury. Note: only one Patient can be assigned to one Doctor.

  3. Unassign Doctors — A Hospital Administrator can unassign currently assigned Doctors once they know a Doctor is done treating a Patient. The fact that a Hospital Administrator knows that a Doctor has finished treating a Patient is external to this application. This page not only unassigns Doctors but also "discharges" Patients that were assigned to that Doctor. We update this information in our database.

The chief goal of the platform is to ensure that injured patients receive treatment quickly by eliminating the time spent waiting in line and filling out forms.

Team

Organization: The University of Chicago — CMSC 22001: Software Construction

Members: Adam Freymiller, Steven Hernandez, Neal Jochmann, Anand Kannappan, Brian Keene, Maitreyi Nabar, Forrest Sill, and Connor Soltas

The team consisted of an interesting mix of UChicago students — from 2nd - 4th year Computer Science undergrad majors to a Masters student studying Molecular Engineering.

Role

SpeedER was actually my first full-stack development project! I worked fully across the stack, writing frontend Javascript code with the Pug templating language and diving into the backend by writing Express routes and creating database models in MySQL. Some of my other teammates had prior experience with Pug, Node + Express, and MySQL, but it was my first time working with these technologies.

I learned a bunch by collaborating with my highly talented teammates, asking questions, and reading the technologies' official documentation. Halfway through the project, I took on a leading role and helped see everything through completion. On top of being a full-stack developer deeply involved in writing the code for several features, I shared the role of project manager with another teammate — we organized group meetings, work sessions, and schedules. Many of my teammates felt that I knew the most about how SpeedER operated, so I ended up demoing the final versions of our app to our TA!

Technologies
  • Pug.js — for frontend.

  • Node.js — for backend.

  • Various Javascript libraries - for testing (mocha, chai, sinon, etc.), user authentication (passport.js), encryption (bcrypt.js), database queries (sequelize.js), etc.

  • Python scripts — for automatically adding information to databases (like Hospital geospatial coordinates).

  • MySQL (MySQL server + workbench for internal visualization).

  • Google Maps API — for displaying the hospitals and estimated travel + wait times from the Patient's location.