Work

About

Reducing financial toxicity in the healthcare industry

Reducing financial toxicity in the healthcare industry

Reducing financial toxicity in the healthcare industry

Quiddity Solutions

Quiddity Solutions

UX Design

User Flows

User Research

User Testing

Prototyping

Team

3 UX Designers, 1 Product Manager

Year

2016

Challenge

Quiddity Solutions is an early-stage startup platform concerned with reducing the financial toxicity that is prevalent in the healthcare industry. It seeks to address the problem that patients and physicians are concerned with the costs of care, but doctors do not have access to accurate cost data when they’re interacting face-to-face with their patients. The platform seeks to give doctors a way to compare treatment options across several criteria such as effectiveness and cost; while also involving the patient more with the decision-making process, which will in turn increase patient satisfaction with the treatment.

Quiddity Solutions is an early-stage startup platform concerned with reducing the financial toxicity that is prevalent in the healthcare industry. It seeks to address the problem that patients and physicians are concerned with the costs of care, but doctors do not have access to accurate cost data when they’re interacting face-to-face with their patients. The platform seeks to give doctors a way to compare treatment options across several criteria such as effectiveness and cost; while also involving the patient more with the decision-making process, which will in turn increase patient satisfaction with the treatment.

Goal

As part of a three week design sprint, our team was tasked with:

  • Examining physician needs and constraints to determine the viability of the product

  • Making the platform engaging and efficient

  • Finding a better way to present the information contained in the product

As part of a three week design sprint, our team was tasked with:

  • Examining physician needs and constraints to determine the viability of the product

  • Making the platform engaging and efficient

  • Finding a better way to present the information contained in the product

Research

Our initial research methodology was concerned with first analyzing the domain, which proved to be quite tricky due to the complexity of the American healthcare system, and the opaque nature of other healthcare startups concerned with cost reduction. From there, we pivoted to focus our efforts on our second method of research, interviewing doctors themselves on their day-to-day routines, as well as having them perform initial usability testing with the initial prototype we were given from the client.

Initial prototype screens provided by client

Our initial evaluation of the MVP was this was a bare-bones product structured to mimic a retail platform. The user would input a patient’s insurance info and diagnosis code, and then be able to build and compare courses of treatment containing options pertaining to the specific diagnosis. Our initial assumptions in evaluating the prototype led us to a number of research questions we were interested in that we would use to focus our efforts and research:

• What systems/tools do physicians currently interact with during a patient visit?

• How do physicians determine and decide between potential procedures or courses of treatment?

• How do physicians respond to cost inquiries from patients?

• What cost information, if any, do physicians have (or want) access to?

• What frustrations do physicians encounter during a patient visit?

• What information/features do doctors need to improve their workflow?

• How useful does the general concept of the platform sound?

We then conducted 60-120 minute interviews with six doctors across a variety of disciplines, first learning about how they interact with patients on a daily basis, then having them evaluate the initial prototype.

Our initial evaluation of the MVP was this was a bare-bones product structured to mimic a retail platform. The user would input a patient’s insurance info and diagnosis code, and then be able to build and compare courses of treatment containing options pertaining to the specific diagnosis. Our initial assumptions in evaluating the prototype led us to a number of research questions we were interested in that we would use to focus our efforts and research:

• What systems/tools do physicians currently interact with during a patient visit?

• How do physicians determine and decide between potential procedures or courses of treatment?

• How do physicians respond to cost inquiries from patients?

• What cost information, if any, do physicians have (or want) access to?

• What frustrations do physicians encounter during a patient visit?

• What information/features do doctors need to improve their workflow?

• How useful does the general concept of the platform sound?

We then conducted 60-120 minute interviews with six doctors across a variety of disciplines, first learning about how they interact with patients on a daily basis, then having them evaluate the initial prototype.

What we discovered in our research is that doctors currently experience several pain points in the exam process that we had not anticipated. Most large medical facilities as well as small private practices have moved from traditional paper notation to Electronic Health Records (EHR) and Electronic Medical Records (EMR),  which can be cumbersome and difficult to use, due to their interfaces being more akin to accounting software than exam software. Having to use these platforms takes valuable time away from patient interactions, which are already too brief by their standards. Further, the doctors noted that they have reservations that when cost is concerned in treatment, as they want patients to view them as allies, rather than “businessmen trying to make a buck.”

These interviews provided the team with valuable insight into the treatment doctors routinely provide, and gave us several key takeaways to consider in our next steps:

  • Excessive screen time is a huge constraint and source of frustration for both physicians and patients. 

  • Costs of procedures and medications are very important to patients; doctors don’t usually have access to this information, but they want it to have better informed discussions with their patients. 

  • Diagnosis and treatment selection processes are largely done mentally in the context of the specific patient in question; it is rare to consult additional studies to formulate a course of treatment.

These interviews provided the team with valuable insight into the treatment doctors routinely provide, and gave us several key takeaways to consider in our next steps:

  • Excessive screen time is a huge constraint and source of frustration for both physicians and patients. 

  • Costs of procedures and medications are very important to patients; doctors don’t usually have access to this information, but they want it to have better informed discussions with their patients. 

  • Diagnosis and treatment selection processes are largely done mentally in the context of the specific patient in question; it is rare to consult additional studies to formulate a course of treatment.

After synthesizing our research, we formulated our problem statement and design principles for our iteration moving forward

Problem Statement

Problem Statement

Time-strapped physicians need access to accurate procedure and drug costs to better navigate an increasingly cost-conscious healthcare landscape in a way that: 

  • Forefronts improved patient care 

  • Fits efficiently into the physician workflow 

  • Enhances, as opposed to erodes, trust and transparency with the patient

Design Principles

Design Principles

Credibility

Credibility

We will help doctors build trust with their patients by providing reliable, contextualized information

Transparency

Transparency

We will facilitate an open and honest conversation between patients and doctors, taking into account the realities of the health insurance landscape

Efficiency

Efficiency

We will provide a simple platform with minimal data entry to help doctors make the most of the limited time they have with patients

Quality

Quality

We will set ourselves apart from other healthcare software by emphasizing quality and context of data over quantity

Humanity

Humanity

Physicians resent the idea that patients and medicine can be reduced to an algorithm; we will help doctors keep patient care at the center of their work

Formulating the statement and establishing our design principles helped us move forward into the iteration process by giving us a clear goal of what we were trying to solve, as well as giving us a framework for what we absolutely needed to consider in achieving that goal.

Synthesizing research and using the crazy 8's design exercise to ideate

Ideate

Each member of the team then took our respective quick ideas, and translated them into a series of wireframes as possible solutions. We experimented with several different approaches: a node based layout, a layout including all of the information into accordions for quick access and glanceability, and using a single page with hover states and more organized statistics. Due to the time limitations of the design sprint, and the very limited scheduling availability in which to test these designs with the doctors, we were constrained to only being able to utilize wall voting and client feedback to determine what features we would bring forward into our final prototype for further user testing.

Different approaches the team took for the next round of testing - node based layout, a single page with hover states and more organized statistics, and an accordion layout for quick access and glanceability

Iteration

For our final prototype, we merged the most functional ideas from our initial ideations into one, to address features doctors wanted:

  • A visual running tally of the total cost to the patient 

  • Hover states to quickly access additional helpful information

  • Quickly accessible information regarding patient out-of-range vitals, and diagnosis

  • More in-depth explanations as to what “effectiveness” measured

  • Faster method of comparing selected options

  • A “shopping” model of displaying information, in order to maximize screen real estate, as well as provide a system doctors would be familiar with

For our final prototype, we merged the most functional ideas from our initial ideations into one, to address features doctors wanted:

  • A visual running tally of the total cost to the patient 

  • Hover states to quickly access additional helpful information

  • Quickly accessible information regarding patient out-of-range vitals, and diagnosis

  • More in-depth explanations as to what “effectiveness” measured

  • Faster method of comparing selected options

  • A “shopping” model of displaying information, in order to maximize screen real estate, as well as provide a system doctors would be familiar with

This round of testing provided us with several key takeaways: 

  • There is not enough time in the hospital setting to review detailed cost info

    The platform may be useful for the patient to review after their visit (possibly through a patient portal), as well doctors expressed concerns about “bartering” with their patients. 

  • Content and organization must be tailored to the specific discipline

    Different types of doctors can have very different needs and approaches to treatment, the platform must address these differences.

This round of testing provided us with several key takeaways: 

  • There is not enough time in the hospital setting to review detailed cost info

    The platform may be useful for the patient to review after their visit (possibly through a patient portal), as well doctors expressed concerns about “bartering” with their patients. 

  • Content and organization must be tailored to the specific discipline

    Different types of doctors can have very different needs and approaches to treatment, the platform must address these differences.

  • Level of Evidence rather than effectiveness

    A generic effectiveness scale can prove to be problematic, a more useful tool would be to have direct links to medical guidelines that are published and regularly updated by medical societies. This information can also be tied to contraindications, which is a component of major concern to doctors. 

  • All options must be shown, even if they are not covered by the patient’s insurance

    Doctors may need to provide a specific medication or procedure, a color-coding system or emoticons can be a method of quickly demonstrating what is in or out of policy. 

  • Emailing the information is problematic due to HIPPA regulations

    An easily accessible print screen, that can be tailored to patient-facing or doctor-facing would be the most useful in the decision making process.

  • Level of Evidence rather than effectiveness

    A generic effectiveness scale can prove to be problematic, a more useful tool would be to have direct links to medical guidelines that are published and regularly updated by medical societies. This information can also be tied to contraindications, which is a component of major concern to doctors. 

  • All options must be shown, even if they are not covered by the patient’s insurance

    Doctors may need to provide a specific medication or procedure, a color-coding system or emoticons can be a method of quickly demonstrating what is in or out of policy. 

  • Emailing the information is problematic due to HIPPA regulations

    An easily accessible print screen, that can be tailored to patient-facing or doctor-facing would be the most useful in the decision making process.

After analyzing this feedback, we made certain updates to the wireframes such as removing the email feature, and annotated them for our final client deliverable.

Final annotated mid-fidelity screens

Takeaway

After testing, we conceptualized a number of suggestions for next steps in the process:

  • Further testing

    Further iteration and usability testing needs to be performed, and it is key that it is performed in its domain as part of a contextual inquiry. The platform should also be tested further with doctors working as private practitioners, rather than part of a complex medical system.

  • Build a database of diagnosis codes, treatments, level of evidence 

  • Establish a relationship with insurance companies and collect cost data 

  • Establish an add-on module structure 

    For the platform to truly succeed, it needs to integrate fully into already existing EMR and EHR platforms, so doctors do not have to have even more windows and platforms to deal with during their limited time.

One of the major things I learned from this project was that many key assumptions that we made as a team starting the project were quickly found to be incorrect, demonstrating the absolute importance of using design thinking as a methodology. What we initially thought was a platform that could be used to reduce costs had unintended consequences of both secondary user perception, as well as integrating into it’s primary user’s workflow. Though the platform itself has verifiable merit and could be a useful tool to both doctors and patients; in such a complicated and esoteric domain, being able to test, iterate, and pivot is crucial to the development of a successful product.

After testing, we conceptualized a number of suggestions for next steps in the process:

  • Further testing

    Further iteration and usability testing needs to be performed, and it is key that it is performed in its domain as part of a contextual inquiry. The platform should also be tested further with doctors working as private practitioners, rather than part of a complex medical system.

  • Build a database of diagnosis codes, treatments, level of evidence 


  • Establish a relationship with insurance companies and collect cost data 


  • Establish an add-on module structure 

    For the platform to truly succeed, it needs to integrate fully into already existing EMR and EHR platforms, so doctors do not have to have even more windows and platforms to deal with during their limited time.

One of the major things I learned from this project was that many key assumptions that we made as a team starting the project were quickly found to be incorrect, demonstrating the absolute importance of using design thinking as a methodology. What we initially thought was a platform that could be used to reduce costs had unintended consequences of both secondary user perception, as well as integrating into it’s primary user’s workflow. Though the platform itself has verifiable merit and could be a useful tool to both doctors and patients; in such a complicated and esoteric domain, being able to test, iterate, and pivot is crucial to the development of a successful product.

SpotOn: Mobile Terminal

Giving small merchants the ease of on-the-go payments

SpotOn: Mobile Terminal

Giving small merchants the ease of on-the-go payments

SpotOn: Mobile Terminal

Giving small merchants the ease of on-the-go payments

Power E*Trade Desktop: Platform

Turning a best-in-class trading experience on the web into a multi-window native desktop solution

Power E*Trade Desktop: Platform

Turning a best-in-class trading experience on the web into a multi-window native desktop solution

Power E*Trade Desktop: Platform

Turning a best-in-class trading experience on the web into a multi-window native desktop solution

© 2023 YLSCLLC

© 2023 YLSCLLC

© 2023 YLSCLLC