Select Page

Triage

Overview

Going to an emergency room can be a frustrating and stressful experience. This is made more difficult by the fact that many patients feel uninformed about their treatment process and have no way to determine what to expect next or how long they are expected to wait for a particular procedure or decision. Our team worked with Cliexa Inc. to add a timing algorithm feature to their new navigatER app — an app designed to help patients stay informed in their treatment process by providing them real time updates. Our program utilizes hospital data records to estimate how long a patient can expect to wait until the next step in their treatment. This information is passed through the navigatER app to the hospital patients to keep them better informed of their treatment process and reduce the uncertainty and stress that they experience during their visit to the emergency room.

Live Zoom Chat

Use the link below to join us live from 8:00 – 10:30 a.m. on April 29.

Join from PC, Mac, Linux, iOS or Android: 

Link: https://mines.zoom.us/j/99224978782?pwd=L0VBWlFNd2cybm1uTXZ6ZzFVSjd1Zz09

Password: 608940

Meeting ID: 992 2497 8782

 

Team Members

  • Frederick Coleman
  • Collin Kreutz
  • Matthew Rathmann

The Client

  • Cliexa

Acknowledgements

Client Person of Contact: Evan Wentland

Project Advisor: Leslie Light

Technical Advisors: Burak Cetin, Şadi Elaskar, Dr. Christopher Painter-Wakefield

Video

Elevator Pitch

Our program generates predicted times for various steps in the emergency department process including estimations for the time it will take a patient to be triaged, assigned a first provider and physician, assigned a room, and admitted into the hospital, as well as the times for labs and CT scans. Our program utilizes historic hospital data and takes into account factors such as patient age, patient triage level and critical care status, time of the day, and day of the week, to generate the most tailored time estimations for a particular patient. Our program is very versatile so that additional metrics and parameters can be easily added during the lifetime of the program based on the changing needs of the navigatER app. Our program includes biasing and rounding of times estimations to make the predicted times easily digestible and realistic for the average patient.

 

Design Approach

The project was broken up into two phases. During the first phase of the project the team was given historic hospital data in an Excel spreadsheet. This data included 19 metrics, or segments of a patient’s treatment, such as the time between a patient’s arrival at the Emergency Department (ED) and their first provider being assigned. For each metric, the hospital provided averages from a year’s worth of data that included the median times and first and third quartile times that a patient with a certain set of parameters experienced each metric. These parameters included patient age, ESI (triage level), critical care, week or weekday, and day or evening. 

The goal of the first phase was to find and display the correct average metric time from the spreadsheet based on a set of input parameters. The team came up with two solutions. The first solution was using a data tree to store and find the correct time. The tree method would populate the branches based on what was read from the data sheet and place times that were missing information on multiple branches. The tree method was very quick at returning values, but made it difficult and unintuitive to store certain data points, and was not well suited for future adjustments and changes to the data.

The second solution was finding the time directly from the spreadsheet, by simply iterating through the spreadsheet and looking for matches. This solution was much more straightforward and viable with future changes to the data, and the team concluded that the direct access method was the best solution for phase 1 of the project. After selecting the direct access search method the team noticed that some of the data in the spreadsheet was missing or corrupted, and that some specific sets of parameters had no match in the historic data. The team designed functions to estimate missing or corrupted data based on similar existing data, or return a default time. 

 

 

The team also conducted stakeholder feedback to determine which metrics a potential hospital patient would find useful, and how best to display the time estimations. The team decided to range and bias the average times based on this feedback.

The goal of the second phase of the project was to read real time data and update the algorithm’s prediction. It was determined by the client that this real time data would come in the format of periodically updated average hospital data, similar to the initial historic data. The team was also asked to store and read the data from a SQL database and run the program on a web browser using an API rather than a local machine. The team researched and designed an API and used a test SQL database to practice the program during development. Modifications were also made to the security of the API based on the client’s recommendations, to ensure that patient data was not accessed improperly. Lastly, the team made adjustments to the algorithm to ensure greater robustness, adaptability, and clarity of the program to handle future updates to hospital data.

 

Design Solution

The final design for the predictive timing algorithm is capable of providing time estimations to users of the navigatER application at various different steps throughout the emergency department process. The algorithm is accessible through a web API and will output a biased time interval from the historic database based on the inputs that were requested.

The emergency department historic data is stored in an SQL database which can be stored on Cliexa’s online environment. The algorithm receives input parameters including the metric number, the patient’s age category, the patient’s ESI level and critical care status, and whether the estimation is being requested during a weekend or an evening. Using the provided parameters, the algorithm searches through the historic data until it finds a matching median time for those inputs and returns using an API get or post method call.

The algorithm also accounts for the possibility of missing input characteristics and any observed irregularities in the historic data. If the app wishes to fetch a median time but does not have information on one of the inputs that the algorithm uses, an “n/a” parameter can be passed in and the algorithm will ignore that input and find the most accurate time with the other provided inputs. Any missing data points in the historic data is accounted for as well, as the algorithm is capable of changing its inputs until it finds a valid match, modifying the least impactful inputs first to ensure the most accurate estimation is still being provided. If no match is found after changing every input to every possible combination, which would generally only happen with an invalid metric number, then a default minute value is returned.

Once a median time has been fetched by the algorithm, an upper-biased range will be calculated to be shown to the user of the app. For example, if a median time of 30 minutes is fetched from the historic data, the final display to the user will be shown as 30-45 minutes. As the time estimations reach the range of times that are an hour or larger, they will begin to be shown in quarter hour, half hour, or full hour intervals, based on how large they are. An example of user outputs for specific minute value estimations and the program output for the 30 minute example are shown in the images below.

The algorithm is accessible by the client through a web API that is hosted natively on their Microsoft Azure environment. In order to establish security of the algorithm and hospital data, a randomly generated security key is necessary on the back end to receive an output from the program. Our algorithm’s app settings file can be edited real time to account for this random security key and ensure that no outside parties have access to the algorithm.

 

 

 

Next Steps

 

The next steps for the predictive timing algorithm involve integration into Cliexa’s environment so that the navigatER application can become capable of delivering the time estimations to its users. The algorithm can be further altered by the client if needed to include any additional functionality, any changes to input or output format, and any additional security protections. Specific integrations that could be included in future development include use of the Entity framework to integrate building the SQL database in the code, and incorporating the Microsoft Azure key vault for stronger algorithm security. Once the algorithm is integrated into the navigatER app, patients should immediately begin to have an improved and more informed emergency department experience.

 

Meet the Team

Frederick Coleman

Role: Technical Lead

Major: Mechanical Engineering

Hobbies: Game making, Playing the ukulele, Basketball

Collin Kreutz

  Role: Communication Lead

  Major: Electrical Engineering

  Minor: Computer Science

  Hobbies: Taekwondo Instructor, Watching Sports, Traveling

Matthew Rathmann

 Role: Scrum Master

 Major: Mechanical Engineering

 Career interests: Air Force (currently in the AFROTC program), interested in Space Operations

 Hobbies: Reading, Tennis, Hiking