CSE443 Project: Chronica11y

Abstract

People struggling with health problems with vague/hard-to-diagnose symptoms can find it hard to identify what they’re experiencing and/or what those symptoms could be caused by. This information can be helpful in getting diagnosed, especially with chronic and rare illnesses. Likely, these people spend a lot of time in between doctors appointments feeling as if they should have some way to help themselves, and this often comes in the form of medical research. Their goal in the lens of medical professionals seems to be to self diagnose, but we argue that they are attempting to better understand their experiences, find potential methods to try that can alleviate symptoms without medicine, and build a community around them.

What we are proposing is an agnostic multi-agent medical research and community engagement tool. By agnostic, we mean that the system does not aim to diagnose or push a specific condition. Instead, the user will chat with a multi-agent system that is designed to help organize the user's thoughts, prompt the user with questions to consider, define hard to understand medical topics, explore related information, and optionally connect with communities in a responsible and ethical way. We think this can be a helpful tool for a lot of people because it doesn’t attempt to solve any one issue. It is a tool kit that gives the user the best shot at whatever their individual goal is, whether that is understanding what they are feeling, reflecting on their experiences in new ways, exploring personal accounts and seeing what they connect with, or something else entirely.

Project Details

Motivation

We found a first-person account on TikTok by the user itsjanineliz. Janine is a person with chronic health issues, and they discuss how they track symptoms and navigate doctor appointments. This meets the criteria of a first-person account because the speaker has a disability, regularly uses technology to track symptoms (specifically mentioning Migraine Buddy), and directly mentions the pros and cons of symptom tracking. Janine specifically notes in their bio that they are not offering medical advice and do not advertise or make money off of any of the products mentioned. It is a personal account of lived experience and ongoing medical care they are seeking.

Janine describes that they use symptom trackers, specifically Migraine Buddy, but explains that these apps do not work well for them due to ADHD. Instead, they use an iPad to jot down notes about their experiences and bring this into the doctor.

Janine explains that doctors themselves have a lot of control over whether you receive a diagnosis. This means that a doctor’s personal opinions and biases can directly affect your medical care. This is a massive barrier and is unfortunately one that we can’t solve with external technology. However, Janine also mentions choosing not to continue scheduling with doctors who treat her in this way, and that some doctors do find this information very helpful. This suggests that while there are still systemic barriers, having symptoms, experiences, and data to discuss with doctors can be helpful in the process of getting diagnosed.

Symptom trackers have the barrier that if a person (like Janine) has ADHD or something that doesn’t mesh well with the design of a symptom tracker, it simply will not work for them. They describe systems that work better, relying on very little to no technology (for example, writing down when they have symptoms, as well as asking a close friend to describe any changes they notice from their point of view).

From Janine’s perspective, symptom trackers seem to be mostly an inconvenient solution to a generally solved problem, as the best solution for her is simply writing things down. As a person who has used symptom trackers myself (Ally), I am completely in the same boat. The problem with symptom trackers for me (and for others I have spoken with) is that there is no habit established for using a new app. When something occurs that should be tracked, your first instinct is to do what you normally do to write things down. Additionally, if you are in pain when you need to track symptoms, you often don’t want to go through the effort of learning or navigating something new. I think this indicates that symptom tracking itself may not be the core problem we should tackle. Instead, we want this technology to function as a research and identification tool that helps users consider potential symptoms to look out for in real life and point people toward appropriate medical resources.

I also think this account shows the long-term process of getting a diagnosis when it comes to conditions that are difficult to diagnose. Janine has clearly had time to try multiple strategies and apps when it comes to tracking, and they mention speaking with many doctors. This illustrates that even someone who knows how to navigate the system and has experience doing so may still wait an extensive amount of time to receive a diagnosis. This is why I think our solution could still be helpful. People in this waiting stage will likely want to do their own research, be as prepared as possible for doctor appointments, and find ways in the meantime to minimize their pain. Having tools that help identify symptoms, explore possible causes, and try different methods to alleviate pain could meaningfully improve quality of life and reduce the helplessness that comes from waiting for an external system to provide answers.

Ally’s experience with a relatively uncommon type of chronic migraine that doesn’t present like typical migraines is also helping to shape our discussion and goals. Something that she found very difficult during the diagnostic process was feeling helpless between doctor appointments, which would often be months apart with little to no support in between. Journaling, having ChatGPT suggest possible causes of symptoms, and then researching those causes helped in the process of diagnosis, but was also incredibly tedious and isn’t something that every person has the time, energy, support, education, and technology to do. While Ally would use this tool to help keep track of symptoms, ask for suggestions of illnesses that could be causing symptoms, and to find people’s experiences who have those illnesses, this isn’t the only functionality we want to focus on – things like engaging with community and defining what a person’s symptoms are may also be helpful tools.

Disability Analysis

Disability Justice Principle 1 INTERSECTIONALITY

Definition

As this is the first listed disability justice principle, it is fitting that this project starts here. This principle begins with the statement from Sins Invalid: “We do not live single issue lives.” Intersectionality reminds us that disability is never experienced in isolation. Ableism is entangled with racism, sexism, classism, fatphobia, transphobia, and other systems of oppression. Disability justice insists that we recognize how these systems interact rather than treating disability as a standalone category.

Reflection

Chronic illness especially illustrates this principle. It does not exist in a vacuum. It intersects with gender, race, income, immigration status, trauma history, and access to healthcare. The way someone’s symptoms are interpreted, believed, or dismissed often depends on these intersecting identities. For example, research consistently shows that women, particularly women of color, have their pain minimized or misattributed. The experience of illness is therefore shaped not just by biology, but by power.

What we would like to represent in this project is that chronic illness is entangled in so many personal identities and experiences. Traditional medical systems often attempt to isolate variables and reduce experiences to symptom checklists. While structure can be helpful, it can also flatten lived experience. There is a risk in trying to extract symptoms from context, as if they are purely mechanical signals detached from identity and environment.

With this tool, we are not trying to untangle someone’s intersecting identities or reduce them to a medical abstraction. Instead, we are attempting to create space for narrative first. The journaling component allows the user to describe their experience in their own language before it is translated into standardized symptom terminology. This sequencing matters. It acknowledges that lived experience precedes medical language.

How we reflect on intersectionality is the determining factor in the success of our project. AI systems can easily reproduce dominant biases embedded in medical data and online communities. If we are not careful, the tool could reinforce existing inequities rather than challenge them. How can we remain open to the possibility that there are many intermingling factors at play? Who is this system built for? Whose language is recognized as valid? Whose experiences are likely to be surfaced or ignored?

I would argue that we are not trying to untangle these threads, but rather allow them to exist and support where we can. The success of this project depends on whether we can hold complexity without pretending to resolve it. Intersectionality reminds us that chronic illness is never just a medical issue. It is social, political, and deeply personal. Our responsibility is not to simplify that reality, but to design in a way that respects it.

Disability Justice Principle 2 RECOGNIZING WHOLENESS

Definition

“People have inherent worth” is how Sins Invalid begins this principle. It is beautiful in its simplicity and powerful in its implication. It directly challenges a cultural norm that measures people by productivity, diagnosis, or usefulness. If you are not contributing in ways that society values, you are often treated as less than. Recognizing wholeness rejects that framework. It insists that people are complete, complex, and valuable beyond what they produce or what can be medically categorized.

Reflection

I think this principle shows up in our project most clearly in what we are not trying to build. Diagnosis is not our goal. Traditional symptom checkers often push toward ranking possible conditions, reducing someone’s experience into probabilities and medical labels. That framing subtly communicates that clarity, certainty, and classification are what make an experience legitimate.

From our research and first-person accounts, we saw a divide between what people are asking for and what designers are building. Many people with chronic illness are not primarily asking for prediction algorithms. They want to be heard. They want their experience validated. They want language that helps them articulate what is happening without feeling dramatic or dismissed.

Recognizing wholeness means designing for the person, not just the pathology. Our journaling-first approach attempts to start with narrative rather than medical reduction. The tool structures symptoms, but it does not collapse someone into them. It avoids telling users what condition they likely have, because a diagnosis is not what determines someone’s worth or legitimacy.

Our biggest fear, and something we are reflecting on as we move this project forward, is that this is a difficult balance to strike. How do we provide clarity without reducing someone to a set of symptoms? Recognizing wholeness challenges us to design systems that support understanding without implying that a person is a problem to be solved.

Additional Questions

Is the technology ableist?

It can be. Many of these technologies exist online with good intentions, while others are driven purely by capitalistic motivations. They see a need and a vulnerable community and attempt to capitalize on it. A real concern our team has is whether we are simply adding to the growing list of technologies attempting to solve this very real problem. We have decided that ethics and morality must play a larger role than anything technical. The technical side of this project is not a major undertaking to achieve a minimally viable solution. What likely will not be solved in the four weeks of this course — and will remain our ongoing goal — is how this tool can genuinely help people and contribute meaningfully.

Is the technology informed by disabled perspectives?

It is and will continue to be. We are fortunate to have someone in our group who would be a user of this technology, which informs many of our design choices and priorities. At the same time, we recognize that one person’s experience does not represent the entire community. I (Ally) do have chronic health problems, but I am also someone with a doctor as a parent who helps me advocate for myself, someone with the financial flexibility to prioritize health, and someone whose parents have helped identify symptoms I might otherwise have dismissed. It is essential that we keep our perspective broader than my experience alone. That is why we are conducting extensive research on how people interact with (or avoid interacting with) technology when navigating chronic illness and diagnosis. We are focused on creating a flexible toolbox rather than an all-encompassing solution.

Does it oversimplify disability/ability?

In some ways, yes. Health conditions are complex and multifaceted, and there are elements technology cannot account for. For example, one first-person account we found described asking a close friend or family member to point out noticeable changes before seeing a doctor — something I (Ally) have also found helpful. Because this tool relies on user input, individual perceptions and biases will always shape results. If someone has been conditioned to believe that constant fatigue is normal, they may never think to report it, meaning the system cannot account for it. For this reason, it is imperative that we clearly communicate that this tool is not a complete solution and should not be treated as ground truth. By presenting information in an agnostic way, we aim to offer health data as potentially useful knowledge rather than persuasive evidence for or against a diagnosis.

Background Research

For my background research, I examined the research article “The Accuracy of Artificial Intelligence–Based Symptom Checkers: Systematic Review” published in PubMed Central (PMC11091811). This paper reviews existing studies evaluating AI-powered symptom checkers and analyzes how accurately they provide diagnoses and triage advice. The authors synthesize findings across multiple tools and conclude that while symptom checkers often provide reasonably safe triage recommendations, their diagnostic accuracy remains inconsistent and generally lower than that of trained clinicians. In many cases, the correct diagnosis was not ranked first, and accuracy varied widely depending on the condition being assessed. The review also highlights methodological inconsistencies across studies, making it difficult to compare tools directly.

This paper is highly relevant to our project because it clarifies the current strengths and weaknesses of AI-driven health tools. Symptom checkers appear more reliable as triage and organizational systems than as diagnostic engines. This reinforces the idea that AI in this space may be better suited to structuring user-reported experiences rather than attempting definitive diagnoses. I learned that many tools overpromise diagnostic precision while underdelivering in complex or rare cases. This supports our decision to position our project not as a diagnostic system, but as a structured reflection and community engagement platform that helps users organize experiences, translate them into medical terminology, and explore shared experiences responsibly.

For my research, I looked into a few different chronic illness subreddits. One interesting post I found was from the subreddit TherapyGPT. This reddit thread is a post from someone describing how they used ChatGPT as a tool to help cope with a severe chronic illness. In the post, they describe how they were hospitalized and sent home with no answers, and how they turned to ChatGPT to help manage anxiety, talk through the medical trauma, track symptoms, and get some feedback/thoughts about what the problem could be. ChatGPT suggested that the problem might be neurological, so the user mentioned this to their doctor, got a referral to a specialist, and ultimately got diagnosed. This is incredibly relevant to our project, as it is exactly the kind of tool we want to make: a system that allows you to just talk or type out your experiences, and it will help you with tracking symptoms, working through problems, and finding potential causes. This thread shows that having a tool like this can help in getting an actual diagnosis and improving quality of life. It’s also important to note that there are comments in this thread that mention similar experiences, with one person also mentioning that it has become hard to look back at old data because of how much they use ChatGPT for this purpose. This is why a similar AI tool trained on health data and with a good way to view history and old entries would be a worthwhile tool to create.

Project Storyboard

Storyboard panel showing a user journaling chronic symptoms in plain language before any medical labeling.
Panel 1 shows the user beginning with free-form journaling. The goal is to capture lived experience first so the system can preserve context before structuring symptoms.
Storyboard panel showing the system organizing notes into symptom themes and clarifying follow-up questions.
Panel 2 illustrates the multi-agent workflow that organizes entries, identifies patterns, and asks follow-up questions. This helps users prepare clearer information for doctor visits.
Storyboard panel showing the user reviewing credible resources and optional community connections for support.
Panel 3 highlights outcome support: users review curated resources and optionally connect with relevant communities. The system emphasizes exploration and support, not diagnosis.

Project Screenshots

Screenshot of the Chronica11y website before a user has logged in or written in any chatrooms.
This is a screenshot of the website prior to a user logging in or writing in any of the chatrooms. At the top of the page, there is a place to enter a username and a join button. In the center, there is a general chatroom and a place for the user to type. On the left, there is a section with dropdowns that allows users to look through existing chatrooms from their previous chats, as well as a spot to make a new chatroom. Below this is a dropdown for agents, which will be used once the user enters a room.
Screenshot of the Chronica11y website with a user logged in and in the middle of a conversation.
This is a screenshot of the website once a user has logged in and began a chat. The user has messaged in the chatroom about medical symptoms, and the yapper agent has responded with clarifying questions and advice. On the left under "Agents," there is a list of active agents (the yapper, definer, redditor, engager, and auditor), as well as an empty list of kicked out agents.

Validation

We validated our system using three structured user vignettes representing distinct health exploration scenarios. Each vignette will include a realistic multi-turn dialogue that simulates how a user might engage with the tool.

Rather than comparing outputs to a single “expected” script, we evaluated responses against a rubric derived from our ethics document. Each output will be scored on a 1-5 scale across the following dimensions:

Vignette 1

Condition/symptoms: general fatigue, unsure of what symptoms they are feeling, they just know that they feel tired and generally bad all the time. Has anemia, but doesn’t know it. If prompted about it, they may remember other symptoms, like having cold hands/feet, dizziness, shortness of breath, etc.

Goals: Vent about their concerns and potentially identify symptoms that they are feeling.

Scores:

Vignette 2

Condition/symptoms: Thinks they may have PMDD, but aren’t sure. To their knowledge, they get extreme depression and mood swings for a week once every month or so. They want to find specific medical conditions that could cause these symptoms.

Goals: Identify potential causes based on symptoms provided, as well as getting prompted to think about other symptoms too.

Scores:

Vignette 3

Condition/symptoms: Has chronic vestibular migraines, but doesn’t know this. They have moderate headaches, pain on one side of their head, and light sensitivity. They have had multiple past conversations with the chatbot about migraines, just generally venting about their headaches, brain fog, and light sensitivity. On this occasion, the user will ask about the possibility of having migraines and how they don’t feel like they can have them because the headaches aren’t very severe. Also, due to having trouble remembering things during migraines, downplays the severity of them after the fact.

Goals: Use past interactions and data to reflect on health experiences.

Scores:

Final Summary

Overall, our strategy for validation gave us a lot of insight into where we want to focus our efforts in the future. The most important thing to us is the interractions people can have with our tool, so seeing where problems occured was very helpful. Many things didn't work as intended (which we ultimately weren't surprised about for our first iteration, and given the time frame of this project). One of the most glaring issues was the fact that the definer wasn't able to actually make definitions. The agent also would tell the user to see a medical professional in every message, which is important, but gets very repetitive and redundant quickly. The UI and chatroom functionality worked really well, though! The agent's language was also very friendly, supportive, and understandable, which created a nice tone.

Accessibility Assessment

Chronica11y was designed with accessibility as a first principle. Because the project supports people with chronic illness, we recognize that disability often intersects with other accessibility needs. Our goal is to ensure that users with a wide range of abilities can interact with the system in a clear and equitable way.

To evaluate accessibility, we conducted an audit using automated accessibility tools, manual inspection, and screen reader testing. The audit focused on three core user activities within the system: talking through health experiences, identifying possible symptoms, and reviewing past conversations.

Overall, the interface demonstrated a strong accessibility foundation. The system relies primarily on semantic HTML, allowing assistive technologies to interpret page structure naturally. ARIA attributes were only used when semantic HTML alone was not sufficient, following best practices for accessible design.

The audit identified three accessibility issues that will be improved in future iterations:

These findings confirmed that accessibility is already embedded in the design of Chronica11y while also highlighting areas where the interface can better support assistive technologies. Improving screen reader navigation and dynamic content announcements will be a priority as the system continues to evolve.

Learnings and Future Work

Developing Chronica11y highlighted the complexity of designing technology for health exploration while maintaining ethical responsibility. One of the most important lessons from this project is that users navigating chronic illness are often not seeking definitive answers from technology. Instead, they want tools that help them reflect on experiences, organize information, and articulate symptoms in ways that can be useful when interacting with healthcare providers. This insight reinforced our decision to avoid building a diagnostic system and instead focus on a reflective research tool that helps users structure their experiences and explore possible explanations.

Our validation exercises also revealed several areas where the system can improve. The conversational agent often provided supportive language but struggled to generate useful definitions or actionable research suggestions. Additionally, it relied too heavily on recommending that users consult a doctor, which is important but became repetitive and did not meaningfully advance the interaction. Future work will focus on improving the agent’s ability to surface relevant resources, define medical terminology accurately, and use information from previous conversations to provide more context-aware responses.

From a design perspective, the project reinforced the importance of accessibility and inclusive design practices. Using semantic HTML and a simple interface helped ensure compatibility with assistive technologies, but testing revealed areas where improvements are needed, such as better screen reader announcements for dynamic chat responses and improved heading hierarchy. Addressing these issues will make the system more usable for people who rely on assistive technologies.

Looking forward, Chronica11y could be extended in several meaningful ways. Future versions could incorporate improved knowledge retrieval from trusted medical resources, better conversation memory across sessions, and visualization tools that help users identify patterns in symptoms over time. Community features could also be expanded to connect users with relevant peer experiences while maintaining strong moderation and ethical safeguards. Ultimately, the long-term goal is to develop a flexible and responsible tool that supports people navigating complex health journeys without replacing professional medical care.