Inspiration

This project is personal. A few years ago, someone in my family was diagnosed with early-stage cognitive decline. Overnight, our household transformed, daily routines became unpredictable, familiar behaviors shifted, and every family member suddenly became an untrained caregiver. The hardest part wasn't the medical side. It was the pattern recognition. We'd discover(usually by accident) that a particular song calmed him down, or that asking him to "help" with a simple chore redirected agitation better than any direct instruction. But those discoveries lived in scattered WhatsApp messages, sticky notes on the fridge, and the heads of whoever happened to be home that day. When a new home aide started, all of that institutional knowledge was lost.

I looked for apps that could help. What I found were rigid clinical tools - dropdown menus, structured forms, medication trackers. None of them captured the human nuance of caregiving. None of them could answer the question a panicking family member actually asks: "He's getting agitated right now, what worked last time?"

That's the gap OmniCare fills. It's not a medical app. It's a memory for the family - an AI companion that remembers what works for this specific person so that every caregiver, whether it's a family member or a new nurse on their first shift, has access to the collective wisdom of everyone who came before them.

What it does

OmniCare is a context-aware AI companion built around two simple workflows that mirror exactly how caregiving works in practice:

1. 📝 Log a Moment : When something happens(good or bad) the caregiver opens the app and describes it in their own words, either by typing or using the built-in voice recorder. There are no forms, no dropdowns, no rigid categories. Just natural language.

Behind the scenes, Google Gemini analyzes the raw input with structured output enforcement (Pydantic schema). It classifies the event type (behavioral_observation, medication_log, dietary_note, environmental_note), extracts triggers, identifies what interventions succeeded or failed, and captures the emotional sentiment. The structured document is then stored in MongoDB Atlas, where Atlas Auto-Embeddings automatically vectorize the content in the background, no manual embedding pipeline, no separate vector database, no batch jobs. The data is instantly searchable by meaning.

2. 🆘 Ask for Help : When a caregiver is in a crisis (the patient is agitated, refusing to eat, trying to leave the house) they tap "Ask for help" and describe what's happening.

The backend uses the MongoDB MCP Server (via STDIO) to execute a $vectorSearch aggregation pipeline against Atlas. This retrieves past observations that are semantically similar to the current situation, filtered to that specific patient. A reasoning-only Gemini agent then reviews the caregiver's current crisis alongside the patient's actual history, specifically what has worked and what has failed for this person before.

The response is always structured as:

  • ACTION : One clear, specific sentence telling the caregiver exactly what to do right now.
  • CONTEXT : A warm, supportive explanation of why this should work, drawing on past logs.

If the agent detects a medical emergency (difficulty breathing, unresponsiveness, a fall with injury), it immediately responds: "This sounds urgent, please call emergency services (112/911) right now." Nothing else.

The virtuous loop: The more moments you log, the smarter OmniCare gets. Every observation enriches the patient's history, making future advice more specific, more personal, and more effective.

How we built it

Backend (Python + FastAPI + Google ADK - The Code-First Approach): Instead of using the Google Cloud Agent Builder, I took a "Code-First" / Enterprise approach. I utilized the Google Agent Development Kit (ADK) in Python to programmatically orchestrate my Gemini 3.5 Flash agents. This allowed me to natively spawn the MongoDB MCP server as a subprocess and securely expose the agent to the custom Flutter frontend via a FastAPI layer.

The core architectural decision was to split the system into two distinct AI paths:

  • Ingestion path: Uses Gemini with response_schema (Pydantic) for deterministic structured extraction. Documents are inserted directly via PyMongo, no LLM involved in the write path.
  • Query path: Uses the MongoDB MCP Server. The MCP aggregate tool executes $vectorSearch pipelines natively, and the results are fed into a reasoning-only Gemini agent that generates the intervention response.

Frontend (Flutter + Dart - Deployed to Web for Judges!): OmniCare is designed as a mobile app, but I know judges don't have time to download .apk files or set up iOS simulators. Because I used Flutter, I had a massive advantage: Flutter compiles perfectly to the Web. I compiled the mobile app into a progressive web app (PWA) and deployed it to Firebase Hosting so you can test it instantly in your browser with zero friction.

The design follows a "High-Clarity" aesthetic: crisp white surfaces, high-energy Emerald and Sapphire accents, and deep Slate text for maximum contrast. I intentionally avoided the murky, low-contrast palettes of typical medical apps. This app uses extreme scale jumps and dramatic spatial boundaries to reduce cognitive load and ensure actions are unmissable for a stressed caregiver.

Database (MongoDB Atlas): MongoDB Atlas serves as both the document store and the vector database. I enabled Auto-Embeddings on the content field of the collection, which means every document inserted via PyMongo is automatically vectorized by Atlas using Voyage AI, with zero additional infrastructure. A vector search index with a patient_id filter field enables per-patient RAG retrieval, ensuring one patient's history never leaks into another's results.

Deployment: The backend is containerized in a custom Dockerfile that installs both Python 3.11 and Node.js 20 (required for the MongoDB MCP Server binary). It's deployed to Google Cloud Run with secrets managed via Google Cloud Secret Manager. The frontend web build is deployed to Firebase Hosting with SPA routing.

Challenges we ran into

  • Communicating urgency without overwhelming: The hardest design problem wasn't technical, it was figuring out how to present AI-generated advice to a caregiver who might be in the middle of a crisis. Early prototypes returned long, paragraph-style responses. In testing, it became clear that a panicking person will only read the first line. That's why I landed on the rigid ACTION + CONTEXT format: the ACTION line is always a single, direct instruction they can act on immediately ("Try asking him to help you fold laundry to redirect his attention"), and the CONTEXT below explains why. The ACTION is what saves the moment; the CONTEXT is what builds trust over time.

  • Keeping the UI minimal without making it feel empty: I went through several iterations of the home screen. The first version had four buttons, a navigation drawer, and a patient info card. It felt clinical. I stripped it down to just two primary actions: "Log a moment" and "Ask for help." Everything else (history, patient switching) is secondary. The challenge was making a two-button screen feel intentional rather than incomplete. The solution was generous spacing, warm typography, and subtle iconography that signals "this is all you need."

  • Structured output reliability: Getting Gemini to consistently produce valid JSON with the exact field names I needed required combining careful prompt engineering with Pydantic schema enforcement via Gemini's response_schema parameter. Without the schema constraint, the model would occasionally invent new categories or rename fields.

  • Balancing empathy with accuracy: The intervention agent needed to sound like a warm, experienced caregiver not a robotic medical chatbot. But it also couldn't hallucinate advice or present generic guidance as if it came from the patient's history. I solved this by making it a reasoning-only agent that receives RAG context directly in the prompt. When no history exists for a patient, the agent is explicitly instructed to say so: "There are no past care notes for this patient yet, so this is general guidance only."

Accomplishments that we're proud of

  • Zero-infrastructure RAG pipeline. The entire embedding → indexing → vector search flow happens inside MongoDB Atlas with Auto-Embeddings. I didn't deploy a single embedding model, build a batch pipeline, or manage a separate vector database. Insert a document, and it's semantically searchable within seconds. This is the kind of architectural elegance that MongoDB's document model makes possible and it's hard to achieve with traditional SQL.

  • The virtuous feedback loop actually works. In testing, I logged an observation about agitation being calmed by jazz music. Minutes later, I asked for help with a different but semantically related crisis, and the agent referenced that exact observation and recommended jazz music. The RAG loop isn't theoretical, it demonstrably improves advice with each logged moment.

  • The "High-Clarity" design language. I'm proud that OmniCare doesn't look like an AI demo or a sterile clinical tool. It looks like a highly polished, modern utility. The bold Emerald accents, crisp Slate typography, and extreme contrast were deliberate choices to reduce cognitive load and differentiate it from the sea of dark-mode, neon-gradient AI projects.

What we learned

  • MongoDB's Auto-Embeddings change the RAG game. Before this project, I assumed building a RAG pipeline meant choosing an embedding model, hosting it somewhere, building an ingestion pipeline, and maintaining a separate vector index. Atlas Auto-Embeddings collapse all of that into a single checkbox. It's the most underrated feature in the MongoDB ecosystem, and it made OmniCare's architecture dramatically simpler than I expected.

  • The MCP protocol is powerful but operationally tricky in containers. The STDIO transport works beautifully locally, but in a containerized Cloud Run environment, the Node.js MCP subprocess faces cold-start challenges when the container is frozen. Pre-warming the session at startup via FastAPI's lifespan was the key insight that made everything work reliably.

  • Designing for crisis means designing for the worst moment of someone's day. Every UX decision(font size, button placement, response format, loading animation) was filtered through one question: "Would this work for someone whose hands are shaking?" That constraint eliminated a lot of feature creep and kept the app focused.

  • Pydantic + Gemini's response_schema is the antidote to "prompt and pray." Instead of hoping the LLM returns valid JSON and writing regex parsers as fallbacks, I let the model's native structured output mode enforce the exact shape I needed. This was a massive reliability win.

What's next for OmniCare - AI Companion for Dementia Caregivers

  • Multi-patient dashboards for professional caregivers. Nurses and home aides often manage multiple patients. A dashboard view showing recent observations, mood trends, and flagged incidents across all patients would make OmniCare useful in care facilities, not just family homes.

  • Photo and video input. The architecture already supports multimodal input, Gemini can process images. A future version would let caregivers photograph a pill bottle, a meal, or a skin condition, and the agent would extract and log relevant information automatically.

  • Proactive alerts and pattern detection. Instead of waiting for a caregiver to ask for help, OmniCare could analyze the stream of logged observations and proactively flag emerging patterns: "Agitation episodes have increased 40% this week, all occurring between 4-6 PM. This may be sundowning. Consider discussing with the patient's physician."

  • Family sharing and role-based access. Multiple family members and professional caregivers should be able to contribute to and access the same patient's history, with appropriate role-based permissions (e.g., nurses can view medication logs, family members can log behavioral observations).

  • HIPAA-compliant production deployment. The current demo uses fully synthetic patient data. A production deployment would require signed Business Associate Agreements (BAAs) with Google Cloud and MongoDB Atlas, end-to-end encryption, and Firebase Authentication for access control. Both platforms support HIPAA-compliant configurations.

  • Offline-first mobile experience. Caregiving doesn't stop when the internet goes out. A future version would cache recent observations locally and sync when connectivity returns, ensuring the app works even in areas with poor coverage.

Built With

  • dart
  • docker
  • fastapi
  • firebase-hosting
  • flutter
  • google-adk
  • google-cloud-run
  • google-cloud-secret-manager
  • google-gemini
  • mcp
  • model-context-protocol-(mcp)
  • mongodb-atlas
  • mongodb-mcp-server
  • python
Share this project:

Updates