THE PROBLEM

Why do these patients get (re)hospitalized often?

Self-care plays a major role in complex diseases like CHF yet studies show many patients with CHF fail to detect symptoms or changes in status, misinterpret or misevaluate symptoms, do not take responsive action, or choose the wrong response.

Currently ...

To prevent hospitalization and deaths, many patients with CHF have a cardiovascular implantable electronic device (CIED). These surgically implanted devices deliver therapy and collect physiological data, some of which can be helpful to patients with CHF in self-managing their condition.

The data that is extracted is not patient-friendly, though. For the purpose of self-care management, it is a black box of powerful, untapped data

THE SOLUTION

Power to the Patient (P2P)

A patient-centric, consumer health system, which leverages CIED data to inform and support CHF self-care management. P2P puts patients in the CIED data loop and empowers them to act on their health. The system would include (but not restricted to) several access channels from smartphones, tablets, wearables to IoT devices in the patients' environment.

Stakeholders

P2P is an NIH-funded study supposered by the Agency for Health Care Research and Quality and the system is developed with the help of Dr. Mirro and his team from Parkview Health (Fort Wayne, IN), a renowned hospital for heart care and health research, together with researchers and designers from the School of Informatics and Computing, Indiana Univeristy (Indianapolis, IN) led by Dr. Richard Holden and Dr. Davide Bolchini.

STUDY HYPOTHESIS

A CIED data delivery technology, P2P, designed on an evidence-based understanding of CHF patients’ decision-making, will be usable and acceptable for older adult patients with CHF.

AIMS

AIM 1 

Learn how patients with CHF make self-management decisions when presented with data from CIED and other sources

AIM 2

Design novel, interactive prototypes of Power to the Patient (P2P) to inform and support CHF self-care management

AIM 3

Assess the usability and acceptability of P2P prototypes for older adults with CHF

RESEARCH OVERVIEW

RESEARCH

DATA COLLECTION

INTERVIEWS

DEMOGRAPHICS

- 24 participants were interviewed with an equal gender distribution (12 F, 12 M)
- Their support person/caregiver (friend/family) were also allowed to be part of the interview
- The participants were all 65+ years of age and English-speaking
- Participants were categorized as New York Heart Association functional Class II - IV (moderate to extreme condition of HF)
- Half of the participants were implanted with a CIED and the rest weren't

Participants were selected from Parkview Physicians Group (PPG) Cardiology patient list. Those who received hospice care were excluded from the study.

LOCATION

The interviews were all conducted at Parkview Health, Fort Wayne, IN

INTERVIEW STRUCTURE

PART 1 Critical Incident Technique

- Semi-structured interviews
- Approximately 30 minutes
- Involves questions about specific experiences with decision making from real-life examples

PART 2 Fictitious Scenario

- Decision-making scenarios
- Approximately 30 minutes
- Involves a scenario around a fictitious device (Tron 17, see picture) with scripted and ad-hoc probes to learn how people make decisions.

SURVEYS

PRE-INTERVIEW

   Demographics Survey
   Atlanta Heart Failure Knowledge Test (AHFKT)

TAKE HOME

   Multidimensional Health Locus of Control (MHLC)
   Self-Care of Heart Failure Index (SCHFI)
   Kansas City Cardiomyopathy Questionnaire  (KCCQ)

DATA ANALYSIS

PARTICIPANT PROFILES

Two researchers synthesized demographic information, interview observation notes, and survey results into a profile summary for each participant (see Figure 2). Each participant was assigned a pseudonym. To generate a profile summary for each participant, researchers read through the observation notes, examined and summarized the critical incident topic and described the emerging behavioral and attitudinal characteristics of the participant as they emerged during the interview. Profiles were supplemented by participant characteristics, self - reported technology use, and scores on the standardized surveys. The narrative summary in each profile also included personal information, for example, their likes and dislikes or their occupation.

This helped the research team familiarize ourselves with the data and the design space without being inundated with too much new information. This also aided in a quick high-level analysis without wasting time waiting for the transcripts. The participant profiles provided a good base to start modelling our personas also.

PERSONA MODELLING

Fourteen participant profiles were created initially which were used for creating our personas. We first created buckets for information that we needed the personas to encompass. These buckets were filled with the data from the profiles:

- Demographics
- Information needs
- Information sources (Books, Internet, What device?)
- Dominating concern in life
- Relationship with healthcare professional (HCP)
- Role of support person
- Degree of control over self-care managemennt / Desire to control
- Knowledge of chronic heart failure

The information from all the profiles were filled into buckets using a Google spreadsheet, this allowed us to easily observe the patterns and themes that helped us model our three main personas. these personas differ mainly in their attitudes and behaviors regarding self-management behaviors, including: understanding, monitoring and acting on their symptoms, daily decision-making, information gathering, dealing with lifestyle and dietary choice affecting their chronic condition, willingness to experiment, and relationship with their care providers.

TRANSCRIPT ANALYSIS

Once the transcripts were ready, after conducting one joint coding session on Nivivo, we realized that the two parts of the interviews (CIT and TRON) need different codebooks because the first part focussed more on the cycle of decision-making, "Monitor - Interpret - Act", and the second part focussed more on the information needs of the patients. Most of the nuances would be lost if both the parts were coded using the same schemes.

We kept refining the nodes and adding several subnodes as and when we discovered more sub-themes under each node. The first 5 transcripts were analyzed in a group so that every researcher gets to the same page about what each node means. The remaining transcripts were divided amongst 3 researchers to complete. The coding of CIT was completed first followed by TRON.

The analysis phase lasted around 8 months because transcribing long interviews took a lot of time and we parallely commenced our early requirement gathering and ideation activities with all the information in the "Design Thoughts" node in Nvivo. 

MATERIALIZING RESEARCH FINDINGS

EARLY IDEATION

SCENARIOS - PAINS TO GOALS

As mentioned earlier, early ideation started in parallel to analysis and so once we were done analysing the participant profiles we conducted visioning activities with scenarios to understand the paint points and information needs of the patients.

We explored the criticial incidents of two participants Sally and Betty (names changed,) how they made their decisions when faced with a new situation or what information did they need to successfully manage their health.

In the first scenario, Sally talks about her struggles with managing her diet with heart failure and diabetes (many heart failure patients have two or three comorbidities along with HF,) both being conditions that restrict the intake of several types of food.

Betty's incident is different from Sally's as it isn't something she has to manage daily, one day she notices that her legs have swollen (due to fluid retention) and she tries to manage it on her own before going to the hospital.

These scenarios helped us envision where our system could help these patients while making decisions, either by providing them education and awareness, by closing the gaps in their information needs or by giving them actionable guidelines to follow when faced with situations that are common to patients dealing with heart failure.

REQUIREMENT GATHERING

We started working on an early requirements document once we were halfway through the CIT section of the transcipt analysis. One major perspective that was missing in these interviews was that of the clinicians. Since the team was comprised of researchers and designers we needed to ensure that we were grounded to what is clinically possible and also understand the capabilities of CIED better.

FLY-ON-THE-WALL OBSERVATION

We scheduled a visit to Parkview Health where we spent a day to observe the clinicians and gather information from them. Two researchers (including myself) observed two (different) ADCs, patients first visit the ADC who then prepares the report that the cardiologist can refer to, to recommend next steps for the patient. Below is a visual summary of my observation of the process, with a patient who recently got her device implanted.

The reports generated by these softwares are generally 30 pages long and the ADCs can convert it into something more easily consumable, it will still be around 3 pages long and filled with medical jargon so the patient would still find it impossible to comprehend.

An interesting observation was that way in which the ADCs conveyed information to their patients, they simplified all the terms and had a very assuring tone so that they did not alarm the patient in any manner. Translating this voice and tone into the system we design could make it a more familiar and pleasant experience for our users.

REQUIREMENT ELICITATION SCENARIOS

The transcripts helped us understand how patients made decisions through situations they face in their daily lives regarding their health. Similarly, to understand how clinicians make recommendations to patients we drafted three scenarios of common situations that patients often find themselves in which prompts them to contact their clinicians, based on the transcripts. These scenarios were validated by a doctor at Parkview before they were presented to Dr. Mirro and his team.

Our principal investigator presented each scenario and asked scripted, follow-up questions to start a discussion amongst the clinicians, we observed and took notes of their discussion. Below is an example of one such scenario.

LEARNINGS FROM VISIT TO PARKVIEW

1. Key CIED parameters to display to patients: Transthoracic impedance (indicates water level in the body), Mean Nocturnal Heart Rate, Activity Level (from accelerometer)
   
   
2. The physiology of the individual is so complex, things may happen suddenly, without any warning, even if the patient does everything s/he is supposed to do. It is impossible for a system to be able to predict or recommend anything without having the context of the patients' history and details of their recent activities and the ability to connect the dots between all these details.
   
   
3. The key is to extract the “individuality” of the patient; understanding everybody’s heart failure baseline which is dynamic; trends over time are important for this.
   
   
4. Education: patient may be earnest in their intention of eating healthier, but they do not know what food has low sodium and what are the alternatives to their current eating habit.
   
   
5. An ideal patient situation would be:
   See “volume information” (OptiVol), as a lead indicator of weight going up.
   Patients should be in a position to interpret those and take “rescue medication” (Metolazone) accordingly BEFORE weight goes up.
   

   Ideally the patient should be able to say: “I looked at my parameters and I took the proper medication, and I managed it properly”.

EARLY DESIGN CONCEPT

To make sure that all the information that we gathered up until this point was not lost, I made some early design concepts for the designers to refer to, to understand what the system needs to support.

REQUIREMENT DOCUMENT

To compile this first draft of requirements, the design team analyzed the following sources of information to help guide the design reasoning process:

1. Original P2P project proposal
2. Background literature (15 papers)
3. Existing models of self-management cycle and code books from related CHF projects
4. Summary of participant profile
5. Persona Models
6. Transcripts of P1-P24
7. Nvivio files generated from the analysis of the transcripts
8. Designing User Interfaces for an Aging Population - Towards Universal Design (Jeff Johnson and Kate Finn)
   

WRAPPING UP

The designers were onboarded into the process towards the fair end of the analysis phase when ideation started taking the front seat. After participating in few of our ideation sessions and going through previous documentation and the requirements documentation, they were able to start churning out different design concepts [unfortunately, I am not allowed to share them.]

INSIGHTS AND CHALLENGES

Interviews

1. The design of TRON 17 resembled current algorithms used by Boston Scientific for Heart Logic (which we learnt from our visit to Parkview Health), their single (combined) index that indicates the health of your heart. This helped make the design direction more concrete as participants' information need from such a system was already captured in our interviews.
   
   
2. Living with heart failure is Herculean task and the participants may feel emotional talking about it, it is important to lend them a listening ear and give them their time instead of trying to stick to schedule
   
   
3. It is hard for the elderly to remember a lot of details and there also isn't any way to know if what they say they do during a particular situation is different from what they would actually do/did, participants tend to idealize their decision-making process.

Participant Profiles and Personas

Having these profiles helped kick-start the analysis phase early but since the entire team was not present during interviews, and because the information was abstracted we missed out on the nuances while creating our personas. This had to be corrected later while going through the transcripts because it is then that we understood that

"The three persona types are not buckets - a "Researcher" could sometimes be a "Direction Follower" based on context - they are dynamic and do not follow a one-to-one relationship"

This is an important insight because this gives us an opportunity to trigger the "Investigator" in a patient to make them more informed about their condition and proactively take the right actions to manage their health. 

Domain Knowledge

Lacking domain knowledge about Chronic Heart Failure, the research and design team had to read myriad background works and familiarize ourselves with the field and the various jargons used by the clinicians. It was still difficult for us to truly understand the medical and technical constraints for what can be designed and also the extent to which technology can intervene in the process.

We also lacked the perspective of technical people working on the backend of remote monitoring with CIEDs since most of the feedback the clinicians gave were based on what is currently feasible but our design was for a system that would exist probably 10 years from now when technology could be exponentioally more advanced.    

THE TEAM AND MY ROLE