Project | Medical Diagnosis Platform

The Problem

Redivus Health (then SORA) was building their first product and needed a product design lead to improve usability, accessibility, and help define the final feature set before launch.

They hoped to tackle three major areas that were plaguing hospitals: Code Blues, Sepsis, and Stroke. Each one of these issues cost large hospitals hundreds of millions of dollars each year and threatened patient lives. Each of these conditions was also difficult to diagnose at critical moments, yet there did exist best practices and standardized flow charts to navigate these conditions - the issue was time and access.

For Code Blues, in particular, the survival rate was under 12%, but for many hospitals, the event was rare and complex enough that under the stress of the moment, it was difficult for medical staff to remember how to navigate the event. These events are extremely time-sensitive, and any hesitation puts everyone at risk.

For both stroke and sepsis, time is essential but often progressed over hours, instead of minutes.

The Redivus team hoped to use an application to track, inform, and coordinate diagnosis using established practices. By integrating with EMR systems as well, events and history would be auto-documented, saving nurses hours for each patient.

Resources/Constraints

Six months window for launch
Regulatory scrutiny (Medical device)
Direct impact on human survival

My Role in the Project

Coty Beasley (Me)

Principal Designer

For this role, I was contracted to help the founding team with their MVP. As the sole designer on the project, I worked with research teams, physicians, and medical staff to build their first mobile application over six months.

Other Notable Team Members

As a team around ten, the company was incubated at the Kansas State University's medical research extension. It comprised of medical professionals alongside business, product, and engineering members. We periodically teamed up with research hospitals and various medical organizations.

Initial Research

The research cycles were very deliberate, given the potential risk of using the app in the field. Through our partnership with the university, we had access to doctors, nurses, and paramedics as well as state-of-the-art training facilities with advanced dummies and observation rooms.

The business need was validated regularly from our conversations with hospital staff and professionals as well as empirical data published in the medical community. In one such instance, we discovered that nurses would regularly have to wear multiple watches or write information directly onto their pants in critical moments.

With every new feature we conceived, we were able to create a prototype and try it out in the lab, watching from a control room as the simulation gathered loads of event data.

No items found.

Early Explorations + Planning

After defining the initial feature set (in great detail from a massive spreadsheet), I got to work on a color guide for theming the application.

We had decided to use standard mobile devices, developing a React Native application for cross-publishing. I also determined that the application would be used in direct sunlight by paramedics. Since sunlight washes out phone screens and readability was a critical requirement, I adopted a color system based on Solarized, a GUI theme by Ethan Schoonover.

Additionally, I explored tablet and handheld layouts. Ultimately, we decided that access to an iPad was more limited than personal devices.

The main feature of the application, however, was being able to deliver a question-based decision tree quickly and efficiently. To that end, I developed a visual condition tree for sepsis and stroke that brought clarity to the scope of the UI component system and a guide for engineering logic.

No items found.

Production Designs + Interactions

The feature set coalesced into a few main categories:

Forms and input
Decision wizards
Onboarding
Active event with drug timers
Event documentation (history)
Collaboration

After all the requirements and features were defined, I built a design system for unique components, then built a set of representational screens to show context. From these screens, the engineering team was able to work in parallel while I designed other features.

As the design system grew, I took on a methodology of self-documentation, including logic and component context (like drug timers) in the main Sketch file. This documentation proved to be an essential source of truth for our engineers as the complexity of the application expanded.

No items found.

Outcomes

The MVP of the platform ended up less ambitious than many of the features I designed, due to the limited time window and the complexity of the logic system.

Despite streamlining, we focused on the stroke and sepsis diagnosis, which was immediately useful in a partnership with a local hospital and proved to be much easier and faster to navigate than their previous options.

I'll be excited to see how the product grows with time.