Designed as part of an AI healthcare innovation initiative focused on continuity of care, accessibility, and post-discharge recovery.

System Context 

The Problem: 

Discharge is often treated as the end of treatment rather than the beginning of recovery. Many cardiac patients return home without accessible guidance, symptom monitoring, or reliable follow-up support, increasing the risk of deterioration and preventable readmission.

The Solution: 

Aura AI was designed as a continuity-of-care support system helping patients navigate recovery beyond the hospital. The platform supports symptom monitoring, medication adherence, daily recovery guidance, and risk escalation while prioritizing accessibility for elderly and visually impaired users.

Understanding Patient Experience 

Empathy Map

User Journey Map

Care Journey Analysis 

Empathy & User Journey Mapping 

Before defining any features, I needed to ground our AI in human reality. I developed the primary persona, Tago (a 60-year-old, visually impaired cardiac patient), and mapped his post-discharge journey.

• The Empathy Map: Revealed that Tago feels overwhelmed by complex medical apps and fears missing important medications or symptom changes.

• The User Journey: Highlighted a critical "drop" in the experience curve when Tago struggles to read vital sign monitors or navigate traditional UI interfaces.

• The Design Decision: These artifacts dictated our core constraint: Aura AI could not be a standard app with dense menus. It had to be an accessible, text-based, screen-reader-friendly conversational agent.

I didn't design the agent's features in a vacuum. To ensure Aura AI was both technically viable and clinically impactful, I mapped proposed features against a Feasibility vs. Patient Value grid. 

• Prioritized (The No-Brainers): Secondary Vitals Checks to objectively validate severe pain and prevent false alarms. 

• Discarded (The Unwise): Open-ended symptom text inputs. These require complex NLP, slow down critical alerts, and are difficult for visually impaired users. 

By filtering features strategically, we focused Watsonx's processing power on structured, high-value, and safe interactions.

This user flow served as the blueprint for the Watsonx.ai engine. The snapshot here highlights the Caregiver Confirmation & Mode Selection, where the AI dynamically adapts its support level based on whether the patient is recovering independently.

In the full logic architecture, I designed the daily adherence loops to balance routine monitoring with strict safety protocols:

• Structured Validation: The agent specifically prompts and validates exact formats (e.g., parsing "120/80" for BP) to ensure clean EHR data logging.

• Risk Escalation Protocol: If a patient rates their chest pain ≥ 9, the logic triggers a mandatory secondary vitals check. If instability is confirmed, the system initiates a critical alert to the hospital and caregiver

Design Constraints and Adaptation

During development, we faced a major technical roadblock: our environment lost access to Watson Orchestrate, the tool meant to handle our automated scheduling and triggers.

The Solution: I re-engineered the logic flow so Watsonx.ai handled both the conversational interface and the orchestration.

The Result: Relying purely on intelligent prompts, reasoning, and memory, the LLM successfully managed the morning/evening check-ins, data validation, and risk-flagging all on its own.

Prototype Overview

Prototype interface demonstrating patient guidance, symptom logging, and continuity-of-care interactions.