Preventing unnecessary hospital readmissions


Sulos is a startup that prevents palliative care patients from returning to the hospital and improves the quality of care. They do this with remote patient monitoring solutions for palliative care organizations. These solutions track patient health and provide timely support, reducing hospital readmissions and improving care.


Product Design, Product Strategy, User Research, Design QA, Prototyping, Visual Design


Natasha August - Head of Product | Paul Brown - Delivery Lead | Josh Radecki - Dev Leader | Natalie Frecka - Sr. Developer


Healthcare | Remote Patient Monitoring | iOS & Android | Web App

The narrative

Readmissions to the hospital in palliative care can be either preventable or unpreventable. While the natural decline of a seriously ill patient is often inevitable, many patients return to the hospital due to preventable causes such as failure to take medication, incorrect medication use, high co-payments, and a lack of knowledge about the patient’s condition by healthcare providers after discharge. By addressing these issues, we can reduce the number of preventable readmissions and improve the quality of care for palliative care patients.

Problem & Solution Space

  • Palliative care organizations often lack knowledge of patients’ conditions after they are discharged from the hospital.

  • There are few tools available to intervene when a patient’s condition is deteriorating.

  • Patients may face difficulty accessing pharmacies to obtain their medication.

  • Care teams lack effective tools to respond to patients’ requests.

  • There are few intuitive tools that can help engage patients and allow them to report their symptoms.

Project goals

  • Develop a prioritization system to identify which patients require immediate assistance.

  • Create a patient questionnaire experience that captures daily symptom reports.

  • Develop an improved admin toolbox to help palliative care organizations manage their patients.

  • Overall goal: Prepare all three apps for pilot testing and onboard the first client.



  • The problem is complex and time is limited.
  • It is necessary to provide context and value to users without relying on electronic health records (EHRs) for the minimum viable product (MVP).
  • There are limited design resources available.
  • Solving complex problems requires careful planning and analysis.


  • Use the double diamond model in the design process and devote 70-80% of effort to user research to identify and validate the right problem. The remaining time will be used to evaluate the solution we build to ensure it is effective.
  • Use real customer data from the pilot phase to define Phase 2 of the project.

Measuring the success of the user experience

    • Conduct qualitative one-on-one conversations with clients to gather feedback.
    • Use surveys to gather additional feedback and data.

Prior experience

Here’s the site and mobile experience prior this work

The home screen’s list of patients did not provide meaning or context and did not represent priority patients, making it hard for the team to prioritize.

The patient profile was not responsive or accessible, and did not present the patient information in a meaningful way. It also lacked the ability to edit patient information or set rules for prioritizing patients. These issues made it difficult for the user to effectively manage and track patient information.

The patient questionnaire had an uninviting design that was not user-friendly. It did not provide clear information about what would happen after a patient reports symptoms or what to do if they feel a symptom that is not on the list.

The patient profile in the care team app was very busy and cluttered, and it was missing important patient information. These issues may make it difficult for the care team to effectively manage and track patient information and provide the necessary care

Design and research


Step 1: Patient prioritization 

The first step in our project was to plan a patient prioritization feature that would help care teams get a bird’s-eye view of their patient population and determine who needs help first using a data-driven approach. The priority patients would be a list of patients displayed using hard-coded logic, and would be visible to both care team members such as nurses, as well as palliative care organization admins.

This feature is not intended to provide clinical advice to care teams. It is not a substitute for the advice of clinicians. Instead, it is a tool designed to help care teams do their job better by connecting them with patients and providing real-time notifications when a patient becomes a priority.

To achieve maximum alignment within the team, I started off by mapping out and defining the key terms and concepts that were brought up in our earlier discussions.

What are ‘patient flags’?’
Patient flags are a set of tools and algorithms that enable admins and nurses to prioritize patients and determine who needs help first in a data-driven way.

Who are they for?

  • Admins who want to get a bird’s eye view of their patient population and track their health status

  • Nurses who want to see how their patients are doing and be notified when their condition improves or worsens, or when they haven’t reported any symptoms.

What are ‘patient thresholds’?
Patient thresholds are clinical parameters that are created and edited by the admin to determine a patient’s baseline condition. Setting thresholds is like creating ‘rules’ for when a patient will have a flag and when they will not.

Priority patient values
I created this pyramid to reflect the core values and hierarchies of patient flagging. In a nutshell, self-reported symptoms such as severe or extreme, or app inactivity, determine whether a patient is at high risk and therefore becomes a priority patient. This pyramid helps to visualize the importance of these factors and how they contribute to the overall prioritization of patients.

Hard-coded scoring configuration
Scores are calculated based on self-reported symptoms and biometric data. We worked closely with clinical advisors such as physicians and nurse practitioners to ensure the design of this feature accurately reflects clinical expertise.

Patient and admin apps
The patient app and admin portal were designed to integrate seamlessly with the Patient Flagging System, providing a smooth and intuitive experience for users. This integration allows admins and nurses to easily access and review patient data, as well as prioritize patients based on their needs.

Priority patient table
I designed the priority patient table to include patient flags pills that would surface whenever a patient was reporting severe or extreme symptoms. This would allow admins to quickly identify and prioritize patients who were in need of urgent care.

Filter & Sort
In addition, I designed filtering and sorting tools that would enable admins to sort and filter the priority patients by other parameters. This would give them more control over how they view and prioritize patients, allowing them to focus on the most urgent cases first.

The journey of a flag
To test the design of self-reported and biometric flags, I used journey mapping to understand how the flags would travel through multiple endpoints. This helped me to identify gaps, opportunities, and prioritize certain functionalities for later phases of the project. By using journey mapping, I was able to gain a deep understanding of the journey of the flags and ensure that the design would be effective and user-friendly.

Step 2: Design of the patient threshold UI

This feature will help palliative care organizations prioritize patients and determine who needs help first using a data-driven approach. The admin portal and patient app were designed to integrate seamlessly with the Patient Flagging System and care team app. Whenever a patient reports a symptom, both the admin and the nurse will be notified.

The Patient Flagging System is a set of tools and algorithms that enables admins and nurses to prioritize patients based on their needs.

Step 3:  Intuitive patient questionnaire experience

  • Old questionnaire experience:
    The previous patient questionnaire experience had several UX problems that needed to be addressed. These included an outdated design, the inability to report multiple symptoms at once, and a lack of engagement for patients. We wanted to improve the experience by creating a more modern, intuitive, and engaging design.

  • Exploring high-level designs:
    After aligning with the team on the issues, we began exploring high-level designs for a more engaging questionnaire experience. We came up with a design that was modern and appealing to older audiences, but we still needed to validate our assumptions through research.

  • Conducting exploratory research:
    To test our assumptions and ensure that the new design was better than the old one, we conducted an exploratory research study with real patients. This allowed us to gather feedback and make any necessary adjustments to the design before implementing it.

Exploratory Research

  • I planned a user research study with 12 participants and interviewed them over the course of 2 weeks.

  • Each participant was initially presented with design option 1 and we showed them multiple screens, asking questions along the way. Then they were presented with option 2, and finally we asked them questions comparing the two options.

Key Insights

  • Based on the feedback from participants, the majority preferred Option B because the design was more intuitive and user-friendly.

  • All participants liked the pain level icons.

  • The majority of participants said that they liked Option A because it provided all the symptoms on one page, which they found more efficient.

  • Most participants expected that when they clicked the “get started” button, it would show a list of symptoms or take them through a questionnaire.

  • Almost all participants believed that the illustration image was clickable and would allow them to point to the specific location of their pain.

  • The majority of participants expected that when they clicked the “next” button, it would show the next symptoms on the list or the next step in the questionnaire.

  • Most participants wanted to know what would happen after they answered the questions and why they were being asked to answer them.


Patient questionnaire

We decided to create a third option for patients to select multiple symptoms and generate relevant questions. We also wanted to provide the option for patients to report current and non-current symptoms to their healthcare team.

Admin portal

The new admin portal experience includes several deliverables, such as improved screens for requests and the home screen, but the most important feature is the ability for admin users to set rules and prioritize patients.

Step 4: Onboard and pilot with first customer

Pilot Plan

We developed a 9-week pilot plan to onboard our first customer to use the admin portal. The main goals of the pilot were to validate the value of the features we had built for the customer and to identify any issues or gaps in the user experience. We held weekly one-on-one sessions with the customer to gather their feedback, learn about their experience, and test various features.


Learnings and results

Learnings from pilot

  • Onboarding was smooth: Customers provided positive feedback about the guiding documents and training materials we provided.
  • Customers requested the ability to upload medical documents, such as medication lists.
  • They also requested a calendar feature to set appointments for patients with physicians.
  • Customers also mentioned the need for a notes feature to add additional details to patient profiles.

Results and metrics

  • Positive insights emerged from the interviews, with customers indicating that they are satisfied with the set of features in the admin portal used to manage patients. Additionally, they reported feeling ready to start creating patient profiles in the system and inviting their patients to use it.