ALWAYS

Palliative Care App for patients and their loves

Palliative care improves the quality of life

of patients and that of their families who

are facing challenges associated with life-

threatening illness, whether physical, psycholo

-gical, social, or spiritual. However, Palliative Care

is not only about medical. The problem of fostering communication between patients who suffer life-threatening illnesses and others is equally important because it could greatly improve the quality of life of patients and their families.

Our Design Goal:

A communication app centering the patients, empowering them with control over their communications with family, friends, and healthcare professionals.

Demo Video

Design Process

Research

Identify Stakeholders:

palliative care patient
patient’s loved ones (aka family or friends)
Healthcare Professionals and caregivers

Interview Plans:

Unfortunately, in the limited research time, we didn't find a palliative patient to interview. However, other stackholders have provided us a lot of useful information.

1. Nurse

2. Family member of the patient

3. Medical professional (student in rotation)

4. Expert in palliative care

Interview Summary:

Medical student Emily, during her rotation at a Colorado Springs hospital, shared her insights about the communication needs of palliative care patients.

Key Points:

Palliative care patients often feel unheard and desire a patient-centric approach.
Many patients lack family members; an app could help connect them with friends, akin to the Bumble app.
The app should also support family members dealing with the situation.
The app needs to be easy to use, accessible to all, and use clear, direct language
A digital diary with a forum feature could help patients feel heard and build a community.
Providing resources about end-of-life symptoms could make the process less traumatic.
The app could facilitate family members to send cards or reminders to patients.
Respecting patients' religious beliefs is crucial; a survey during app setup could set preferences and priorities.
The app should facilitate communication of these preferences to the care team.

Erik is a seasoned palliative care expert with over two decades of experience at Dana-Farber's Outpatient Palliative Care Clinic. He also leads as the Director of the Serious Illness Care Program at Ariadne Labs.

Key Points:

Repetitive Narration: Patients are emotionally taxed by the necessity to recount their medical history repeatedly.
Unwarranted Advice: Well-meaning advice can inadvertently lead to patient frustration.
Sharing Updates: The struggle is real for patients when it comes to communicating their health updates to loved ones and caregivers.
AI agents have shown promise in facilitating emotionally intelligent conversations, sometimes outperforming human interactions.
There’s not an integrated platform that allows patients to effectively update their health status or document advanced care directives and wishes.
Physical challenges such as impaired vision are common among the seriously ill, posing difficulties in the use of digital tools.

We talk with the 24-year-old girl Cici, who reflected on her father's passing when she was 21. Many details remain sharp and revealing. Her recollections of those "unreal" days underscore a common struggle for families in palliative care, where the dread of loss disrupts the normal rhythms of communication.

Key Points:

The interviewee's parents shielded her from the harsh reality of their impending loss, which limited her conversation with her dad: Both societal and familial cultural norms that typically exclude the youth from the death conversations.
A general discomfort and avoidance around the topic of death in the family restrict the conversation.
The interviewee’s dad (the patient) was found to be more comfortable talking about his situation with someone who is not directly related, such as the nurse.
The lack of a safe and comforting way for the dying to express themselves creates an overarching fear of the unknown within their whole families. The interviewee believed that finding a way for her father to share his thoughts more comfortably could have benefited everyone involved.
“Do something for the patient to express” to help better the whole family “to understand and to respond.”

This interview was conducted with Riley, a current senior at Simmons University within their nursing program. Riley has a lot of experience working within an intensive care unit (ICU) from her curriculum and outside of school.

Key Points:

easy to become desensitized to the environments within healthcare clinics
palliative care is a super important aspect of health care, yet overlooked at times
candidly admitted that palliative care is not a main focus within their curriculum
palliative care is generally stigmatized by patients’ loved ones
patients generally see it in a more positive light in that “it is a door to end the suffering.”
digital forms of communication have both pros and cons
communication within the healthcare system has extensive restrictions and protocols
narrow focus to communication between patients and family

General Research over the field:

Palliative Care Guidelines Plus (PCG Plus)
- Provides healthcare professionals with guidelines for palliative care.
- Gap: May not be directly accessible to patients and their families, limiting their understanding and involvement in care planning.
Serious Illness Care at Ariandne Labs
- Aims to ensure every seriously ill patient has conversations about their goals and priorities.
- Gap: While the program seeks to improve communication, it is not widely accessible to patients and caregivers and hard to track their wishes outside of clinical settings.
CaringBridge
- A free social networking platform for patients to communicate with family and friends.
- Gap: Focuses on communication and updates but may not offer tools for advanced care planning or decision-making support.
Cake
- End-of-life planning platform.
- Gap: I encountered some difficulties in accessing detailed reviews and specific features of Cake to fully understand potential gaps.

Conclusion:

Potential lack of access or awareness of these tools among patients and families.
Limited resources for comprehensive end-of-life planning that address legal, emotional, and physical care aspects.
Insufficient tools for patients to initiate and document their care preferences outside of healthcare settings.
Lack of integrated patient engagement in care planning and documentation.

VSD Analysis based on research:

(1)We face challenges engaging multiple stakeholders like family members and other networks. Some indirect stakeholders may choose not to use our app, which hinders patient connections and thought sharing.

(2)The accessibility is mentioned by our interviewees, as some of the patients under Palliative care may need help or special assistance in using our app.

(3)Hand-changing problem upon a patient's passing. We must safeguard their privacy while considering any potential benefits arise from the transfer case.

(4) Our app's lifespan differs since some stakeholders will use it temporarily. For sustainability, the app's enduring value and features could transition to supporting family members post-usage.

(1)Design dditional messaging pathways, such as email to allow patients to reach out to non-app users, respecting their choice not to engage with our system while ensuring they don’t miss important messages.

(2)A more inclusive user interface and experience design should be accounted for. For example, large text mode, voice input, clear and easy-to-learn modularity.

(3)A robust yet user-friendly authorization process and data cleaning service is essential. However, leave messages for in the app may be a design opportunity.

(4) Design a time capsule functionality that can help deliver messages after the patient passes. This can help the patients communicate and help the family members in their transition to being without the patient.

Concepts

*what's a concept?

Concepts are the building blocks of software. On the one hand, a “concept” means you’d expect it to mean: a mental construct that you need to understand to be able to use an app effectively. On the other hand, a concept is a coherent unit of functionality. In this sense, concepts belong to the long line of modularity mechanisms in software that include procedures, classes, abstract data types, processes, and so on.

— Daniel Jackson ’The Essence of Software’

In this project development, we use Daniel Jackson’s Concept theory to design and build the module of the software which aims to serve the user in a more modular and learnable way.

Based on a brainstorming of possible features of our app, we specilized a few concepts that could serve as the minimized module of the software. Here are some of the concepts structure docs.

Concepts:

User/ Websession/ Contact/ Preference/ Delay/ Diary/ Letter/ Wish/ Forum/ Topic/ Mood/ Email....

Concept: Delay [ T ]

- Purpose: perform operation on content after a specified amount of time

- Operating Principle: after a specified time ***t**,* execute a behavior ***b*** on a piece of content of type ***T***

- State

owner: one User;

content: one Content;

type: str -> "Diary" | "Letter" | "Wish";

behavior: str -> "send" | "delete";

activation: one Date;

- Operations

create(owner, content, type, behavior, activation)

getDelayById(_id)

getDelayByContent(content)

getDelaysByOwner(owner)

delete(_id)

updateDelay(_id, update)

isExpired(_id)

isTimeCapsule(_id)

checkExpiredDelays(owner)

Concept: Mood

- Purpose: provide a way to track to update users' mood

- Operating Principle: A mood is a string that is associated with a user that can be update and revealed to other users

- State

owner: one User;

mood: one str;

notify: one bool;

previousMoods: Mood array;

updates: Date Array;

- Operations

create(owner, mood, notify, viewers)

update(_id, update)

getMoods(query)

getPreviousMoods(owner)

getByOwner(owner)

getByOwnerId(owner)

delete(_id)

addViewer(owner, viewer)

removeViewer(owner, viewer)

...

Concept: Contact

- Purpose: provide a way to bound multiple user in a patient centric way

- Operating Principle: A contact is a user or non-user that is associated with a user and bounded by a pass code verification

- State

owner: one User;

contact: one User | one EmailContact;

type: str -> "User" | "NonUser";

// passcode doc

patient: ObjectId;

passcode: string;

- Operations

create(owner, contact, type)

getContacts(query)

getContactsbyOwner(owner)

getInAppContactsbyOwner(owner)

getEmailContactsbyOwner(owner)

checkContactType(owner, contact)

delete(_id)

createpatientpasscode(patient, passcode)

verifypatientpasscode(patient, passcode)

...

Concept: Letter

- Purpose: share content with others

- Operating Principle: a content t written by sender f will be sent to a list of receiver r within the given attributes

- State

from: one User;

to: many User;

content: str;

responseEnabled: bool;

type: str -> "letters" | "responses";

response: many Letter;

send: bool;

- Operations

createLetter(from, to, content, responseEnabled, type, response, send, show)

getLetterById(_id)

getLetterBySender(sender)

receiveLetter(receiver)

updateLetterContent(_id, content)

removeLetterReceiver(_id, receiver)

addLetterReceiver(_id, receiver)

addLetterResponsetoLetter(_id,response)

sendLetter(_id)

...

Concept: Contact

- Purpose: provide a way for patient to create wish and let other users to fulfill it

- Operating Principle: A wish is a string that is associated with a user and can be fulfilled by the users' contact

- State

owner: one User;

wish: str;

notify: bool;

previousWishes: str[];

updates: Date[];

- Operations

create(owner, wish, notify, viewers)

update(_id, update)

getWishes(query)

getPreviousWishes(owner)

getByOwner(owner)

getByOwnerId(owner)

delete(_id)

addViewer(owner, viewer)

removeViewer(owner, viewer)

...

User Flow & Wireframe

Since our app centers the patient users by enable them to control the communication process, in our app, patient and non-patient users may go through different user flow with similar but different interfaces.

User Flow

Some examples of the low-fi wireframes

Wireframes

Design Revision

A few design trade-off and revision are made during the implementation.

Concept revision during implementation:

1. Defining Non-Patient and Patient User Relationships

Our approach to connecting non-patient and patient users has evolved through several stages to better align with our design principles:

Initial Approach

Friend Request System: Initially, we implemented a standard friend request system. This allowed non-patient users to send requests to connect with patient users.

First Revision

Registration with Passcode: We modified the connection process to adhere to our 'patient-centered' design principle from P1: Impact Case. During registration, non-patient users require a passcode from the patient user. This establishes an initial connection and allows them to sign into our app.

Second Revision

Connection via Forum Posts: We introduced a new connection method in response to our post forum's 'public social circle' feature. Non-patient users can now view patient profiles through forum posts and request to join their contact list, enabling connections with multiple patient users.

2. Delay for Time Machine

Our concept of 'Delay' has undergone a significant transformation:

Initial Concept

Generic Delay Functionality: We initially planned for the Delay feature to be a generic concept applicable to various elements like Letters, Diaries, and Wishes.

Revised Implementation

Specific to Time Machine: After careful consideration and during the implementation process, we decided to make the Delay feature exclusive to the TimeCapsule. This decision was based on the realization that the concept of Delay is most coherent and meaningful when applied specifically to the Time Machine in our app.
Extend Time Machine as an option for users in “diary,” “letter,” and “wishboard.” To make Time Capsule functionality more useful in our app, we make accessible options for users when they create new diary, letter, and wish.

3. Preference Setting

The design of our Preference Setting also underwent modifications driven by practical considerations and project constraints.

Initial Concept

Periodically check users’ using habits and refresh their default settings

Revised Implementation

Specify the “preference”: Due to the time limitation of this project, we specified the preference into two main functionalities: Vision Assistance and Time Capsule activation date. The first function is designed to serve the special visual needs of our users, and the second preference function addresses and assists our main innovative concept, “delay.”

.....

Based on the concept trade-off, some of the wireframes also change corresponding to the new features, ex: Time Machine.

Refine wireframe

Design Hi-fi interface

Full-Stack Prototype

The full-stack development is built on a basic architecture given by MIT which using typescript, vite, MongoDb, Vue3....

Git-hub Repo:

https://github.com/mfchao/PallCare_Frontend

Online Demo (better viewed on mobile devices):

https://pall-care-frontend-v5-git-main-maggie-chaos-projects.vercel.app/

Here is two test accounts for you to experience

Patient account:

username: Liam_J pc: 1999

Other User account:

username: Benson_D pc:1999

or Try this flow:

1. register

2. select a user type as patient

3. fill the information and set up a passcode

4. create a diary and set its preferences

5. create a wish

6. create a email contact in the contact page

7. send an anonymous letter to the contact

8. add a diary into the Time Machine

and

1. register another account

2. select a user type as other user

3. bound this new account to your previous patient account

4. view its diary (the one you just create)

5. go back to the patient account and send a letter to the "other user account"...

User Tests

Aiming a comprehensive user test, we've created a list of tasks that cover the key concepts of your app, focusing on the concepts that are particularly unique and important to our app. Each task typically involve executing a sequence of user interaction actions. From simple one-action tasks to more complex multi-action tasks, it will test how easily the user can cross the gulfs of execution and evaluation.

Task Lists

Patient view

Non-Patient view

( Each user will be assigned with both task lists of patient and non-patient user perspective to gain a coherent view of the app. )

User Test Report

Report on Patient Version:

The patient user's experience with our app was a mix of positive and negative reactions. The user found the registration process easy and intuitive but questioned the limited user settings, suggesting the inclusion of more personalized options such as religion or after-death preferences. The mood-setting feature was appreciated, but the user desired a more comprehensive pattern-tracking functionality to see mood trends more clearly while incorporating AI suggestions for negative mood trends.

The forum feature was straightforward for creating posts, but the reply functionality needed to be clearer. The user also suggested the addition of a feature to display the number of likes and who liked their post. Also, the bottom navigation menu icons could have been more intuitive, with the world and time capsule icons needing clarification about what they would lead to.

The diary feature was easy to use, but creating a topic was unnecessary. The user also questioned the option to add diary entries to the time capsule, as diaries are typically private. On some pages, the user needed to realize the home icon was a button and also expected to be able to click on their profile image on the home page.

The time machine feature was well received, but the user suggested it looked too much like an exciting present, which was conceptually odd for a concept of releasing content after death. The user also wished to add other media types to the time machine. But in general, the settings were intuitive and familiar.

Report on Non-Patient Version:

The user found the non-patient registration process easy and familiar but raised the issue of access for healthcare professionals without a patient passcode. The user found the home page icons in the mood block easy to miss but could figure out all basic functionality.

The user suggested that non-patients should also be able to add their memories of the person to the time capsule. This suggests that the app could benefit from more inclusive features that allow all users, regardless of their relationship to the patient, to contribute to the patient's time capsule.

In conclusion, the user found the app's features generally easy to use but suggested improvements for more personalization, intuitive icons, and inclusive features.

Report on Patient Version:

Throughout the whole test, the user experience was smooth and pleasant. An extra explanation was put in to help her understand the TimeMachine concept. With this understanding, she thought having such a feature was super cool and useful. Although she liked the feature, she wished there could be more notifications for clarity. “It would be much clearer if it said ‘add to the time machine, and it will be deleted after 100 days since your account stayed inactive,” she pointed out when trying to add the newly created wish to the time machine.

For our other three core concepts, Diary, Wish, and Letter. Starting with the diary, she successfully created a new diary and made it public. As in the above user test, she also thinks adding a public diary to the forum is unnecessary. “People can just read the patients' public diaries in the diary section,” she said. Some functionalities, such as adding a picture or a location, were mentioned while creating the wish to help better identify the information. She appreciated allowing the user to create a wishlist and involve their loved ones in fulfilling it. A major problem with creating a letter appeared to be the place for adding the desired contacts located on the home page. She thought finding this on the home page next to the settings was very unintuitive. Another confusion was about adding the delay behavior to the letter. She understood the scheduling idea but was unsure about the difference between delaying the sending here versus in the TimeMachie.

The user went smoothly with all the tasks for the forum and mood feature. She likes how we can navigate to a user’s profile through their topic. Overall, she thinks the app’s interface is clean and pleasant. She also likes the layout of different contents in each module.

Report on Non-Patient Version:

For creating a non-patient user and connecting to the patient-user she created before, she applauded the 4-digit verification idea. However, she mentioned that it is highly possible that she won’t know the patient’s username in advance, so a dynamic verification system generating temporary passcodes would be better in practice. A tiny problem here, though, was she pointed out that having to jump to the next code slot manually was a bit inconvenient.

After connecting with the patient-user and logging in to the home page, she likes that all the connected patients are displayed on the front. Moreover, “I would also love to be able to access the forum as the patient’s family or friends. The forum was meant to be a public space, right?” she asked. It is an interesting question and also worth careful consideration. Should we open the forum to everyone or keep it only to the patients?

With all that, she naturally navigates to the patient’s Wish, Letter, and Diary section. And this is due to the same icon she has seen as a patient user already. Ultimately, she expressed her affection for this app’s idea and catering to the palliative care and life-death process. She thinks it is a very meaningful and useful trial.

Report on Patient Version:

Overall, the user had a nice experience with the Patient Views. As this was the majority of our focus during implementation, they all were very polished. Across the board, there were small UI bugs that gave the user a bit of friction. For instance, the user must provide a 4-digit passcode on registration. Once a digit was entered, the cursor did not automatically move to the next digit input. Furthermore, the user had a few conceptual qualms. First and foremost, there needed to be more explanation of the various features across the app. For instance, upon registration, the user has to specify if they need “Visual Aid.” Although he did not select yes, he was unsure what features this would specifically modify. Another initial paint point was that the nav bar only utilizes visuals for the various pages. He worked around this by hovering and deciphering the path of the next page; however, for someone who is not tech-savvy, this would not have been feasible. In real practice, this should not be an issue in that I would expect the users to naturally explore the various pages and gain an understanding of the app's structure.

Once on the forum page, the user had no qualms with the interface. He easily navigated through various topics and saw the posts of others. One small note was that he did not naturally click on any usernames within the topics (which routes to a profile page of the associated username). If this app were to be used in a real-world setting, we would want to clarify this functionality to the users.

Next, the user went through the Diary and Wish functionalities. They are very similar so that I will discuss his points with both now. He really liked the layout and UX of the page, specifically noting that the various pages for creating / editing were nice (rather than pop-ups). He did have a few negative observations, though. Once again, he thought that our app could have done a better way of explaining a feature. He did not know what “private” specifically represented within our app. Going off of his mental model of Instagram, he thought that “Private” meant that “linked family/friends” were the only ones who could see it. However, in our app, “Private” means only the user can view it. This alludes to the fact that we should either make this a more intuitive name (i.e., “Hidden”) or have an explanation on the diary page.

Lastly, the user navigated to the Time Machine views. He thought this page's concept was awesome and loved the Time Machine layout. He easily navigated through the pages and could add and delete things to his Time Machine. A highlight of the entire User Testing Session was when he tried to edit the content of a diary within the capsule. He hesitantly clicked on the component within the capsule, and it routed him directly to the “Edit Diary” page. He thought it was a subtle feature yet extremely convenient.

Report on Non-Patient Version:

The user easily created and linked their Family/Friends’ account to the Patient account they had just created. He liked the concept of being able to link the two. The user was super impressed when his Home Page loaded and showed the content he had just created in his Patient Account. Conceptually, one qualm he had was that the Diary / Wish pages were blank when the Patient had no public entries. He validly pointed out that this needed to be clarified in that he was not sure if the page was still loading or if there was no content.

Overall, the user had difficulty navigating through our Family/Friends view. The fulfilling Wishes functionality needed to be incorporated, but the nav bar needed to be present to do things such as navigate to the forum, and there were other minor UX bugs that he pointed out. This highlights our focus on the patient version of the app. We had all of the backend to incorporate the missing features on the Non-Patient views; however, we couldn’t complete it due to time constraints. Nonetheless, I am super pleased with our app, as implementing it all was extremely ambitious.

Design Flaws/Opportunities

Based on our user tests report, we detected a few design flaws and some opportunities in the future development.

Enhanced Personalization (Moderate)
- Current Issue: Limited personalization options in patient and non-patient versions, particularly regarding religious or after-death preferences and non-patients adding memories to the time capsule.
- Opportunity: Introduce more user-specific settings and preferences to cater to each individual's unique needs and desires, enhancing the user experience and emotional connection to the app.
Intuitive Iconography (Major)
- Current Issue: Confusion caused by non-intuitive icons, such as the world and time capsule symbols.
- Opportunity: Employ universally recognized icons or integrate tooltips to clearly convey each icon's function, thereby reducing confusion and enhancing user navigation.
Advanced Mood Tracking (Moderate)
- Current Issue: The existing mood tracking system lacks depth in recognizing patterns and providing AI-driven suggestions for negative mood trends.
- Opportunity: Implement an AI-powered mood analysis feature to offer personalized suggestions and alerts and an expanded tracking calendar for a more insightful view of mood patterns over time.
User Onboarding and Feature Explanation (Moderate)
- Current Issue: Some of the app's features are not immediately intuitive or well-explained to new users.
- Opportunity: Develop comprehensive tutorials or “Help” sections throughout the app to facilitate a smoother onboarding experience and reduce the learning curve for new users.
Healthcare Professional Access ( Critical)
- Current Issue: Healthcare professionals require a patient passcode to access the app, limiting its utility for professional monitoring and support.
- Opportunity: Create a dedicated registration pathway for healthcare professionals, allowing them secure and appropriate access without patient passcodes. This would enhance the app's utility in a clinical setting and improve patient care coordination.
Open Forum (Major)
- Current Issue: The current design of the forum is unclear regarding its accessibility - whether it's exclusive to patients and their immediate circles or open to a broader audience.
- Opportunity: Clarify the forum's purpose and access policies. Consider creating separate sections within the forum for patient-exclusive and open discussions where a wider community can participate, including interested parties, healthcare professionals, and the general public. This approach would not only respect patients' privacy and specific needs but also foster a broader community engagement and support network.