OncoConnect AI

A Splunk-powered AI care observability platform that transforms patient symptom check-ins into explainable risk signals, safety alerts, live insights, and coordinated next actions.

Comment

Inspiration

OncoConnect AI began from a deeply personal place.

I was diagnosed with cancer, and my treatment was still ongoing when I discovered this hackathon. During that period, I experienced how overwhelming cancer can be—not only physically, but also emotionally and practically. Symptoms change from day to day, important details can be difficult to remember, and patients and caregivers may struggle to understand when they should simply continue monitoring and when they should contact their care team.

When I saw the hackathon, I did not want to remain only a patient facing a difficult experience. I wanted to use my technical skills, creativity, and determination to build something that could create value for society and for other people fighting the same disease.

That motivation became OncoConnect AI.

The project is my attempt to transform a personal challenge into a useful, human-centered platform. It is designed not to replace healthcare professionals, but to help patients, caregivers, and support teams organize symptom information, recognize important safety signals, communicate more clearly, and understand what actions may be appropriate next.

Building this project also gave me a sense of purpose during treatment. Every feature represents a simple idea: people living with cancer should feel more informed, more supported, and less alone.

What it does

OncoConnect AI is a Splunk-powered care observability and AI-assisted support coordination platform for cancer patients, caregivers, and support teams.

Users can provide structured information about their current situation, including:

  • Fatigue or weakness
  • Pain
  • Nausea or appetite changes
  • Fear or low mood
  • Cancer type and treatment stage
  • Their main concern and support goal
  • Important warning signs such as fever, breathing difficulty, confusion, or severe vomiting

The platform then:

  1. Validates the submitted information.
  2. Calculates an explainable support-priority score.
  3. Applies deterministic red-flag safety rules.
  4. Uses an AI model to generate a non-diagnostic summary and recommended next actions.
  5. Produces doctor-ready questions and a monitoring plan.
  6. Connects the current case with public evidence and cohort context.
  7. Converts check-ins and AI workflow activity into structured Splunk telemetry.
  8. Displays trends, evidence signals, execution status, and care-support insights through an interactive dashboard.

A critical design principle is that deterministic safety rules always take precedence over generative AI.

For example, a patient may have a relatively low symptom score but select a serious warning sign such as fever during treatment. In that case, OncoConnect AI applies a rule-based safety override, marks the case as critical, and recommends promptly contacting the treating care team or following urgent-contact instructions.

OncoConnect AI is explicitly non-diagnostic. It does not provide diagnoses, choose treatments, recommend medication dosages, predict survival, or replace emergency services or professional medical advice.

How we built it

OncoConnect AI was developed as a full-stack web application with an observability-focused architecture.

Frontend

The user interface was built with React and Vite. It includes:

  • A patient and caregiver input workflow
  • Symptom sliders and context selectors
  • Red-flag safety checkboxes
  • An AI execution console
  • Support-priority scoring
  • Trend visualizations
  • Evidence and cohort-comparison cards
  • Doctor-ready next actions
  • English and Turkish interface support
  • PDF export and sharing functionality
  • Responsive layouts for desktop and smaller screens

The interface was designed as a care intelligence cockpit rather than a conventional medical form. Its purpose is to make complex information understandable without creating unnecessary fear.

Backend

The backend was built with Node.js and Express.

It handles:

  • Request validation
  • Symptom score calculation
  • Red-flag detection
  • Safety overrides
  • AI prompt orchestration
  • Structured response generation
  • Splunk event ingestion
  • Splunk Search API metrics
  • Public evidence endpoints
  • Administrative dataset operations
  • Read-only safeguards for the hosted demo

The backend was adapted for deployment as a Vercel serverless Express application while preserving the local development workflow.

AI layer

The application uses an AI model through OpenRouter to generate:

  • Non-diagnostic patient summaries
  • Recommended next actions
  • Questions to discuss with a doctor
  • Monitoring plans
  • Evidence notes
  • Safety disclaimers

The AI receives structured patient context, symptom values, the calculated support score, and available evidence context.

If the AI provider is unavailable, the system can return a deterministic rule-based fallback rather than failing completely.

Safety architecture

The safety layer is independent of the generative model.

Red flags are detected through deterministic application logic. When one is found:

  • red_flag_detected becomes true
  • The priority is overridden to Critical
  • safety_override_applied becomes true
  • The detected warning signs are shown clearly
  • The generated recommendation is replaced with a safer urgent-contact message

This protects the workflow from relying solely on probabilistic model output for important safety decisions.

Splunk integration

OncoConnect AI uses Splunk in two directions:

  • Splunk HTTP Event Collector: receives structured patient check-ins, AI summaries, risk scores, safety overrides, and workflow telemetry.
  • Splunk Search API: retrieves recent indexed events and aggregates live metrics such as average risk, event volume, and risk-level distribution.

The frontend periodically requests these metrics and uses them to present live cohort comparisons and observability signals.

For hosted environments where Splunk is not available, the application handles the missing connection gracefully without interrupting the core AI support workflow.

Evidence layer

The project also includes summarized public and research-oriented data sources covering:

  • Cancer treatment performance
  • NHS cancer waiting-time pressure
  • Chemotherapy-related patient data
  • Colorectal cancer lifestyle context
  • Structured evidence metadata and quality checks

These sources are used as contextual evidence and not as personal diagnostic or treatment recommendation engines.

Challenges we ran into

One of the greatest challenges was balancing innovation with clinical responsibility.

It is relatively easy to create an AI interface that produces confident-sounding medical text. It is much harder to design a system that clearly limits what the AI is allowed to do, detects high-risk inputs independently, and communicates uncertainty responsibly.

Another major challenge was integrating a locally hosted Splunk Enterprise instance with a publicly deployed serverless backend. The local Splunk services are not directly accessible from Vercel, so the architecture required careful planning around secure tunneling, environment variables, HTTPS access, HEC ingestion, and Search API authentication.

We also faced several deployment and engineering challenges:

  • Converting a long-running Express server into a Vercel-compatible serverless application
  • Configuring explicit API routing
  • Preventing local .env secrets from entering the public repository
  • Making administrative operations read-only in the hosted demo
  • Allowing AI results to succeed even when Splunk telemetry is temporarily unavailable
  • Preventing repeated metrics errors from filling the browser console
  • Preserving local and production workflows with a configurable API base URL
  • Maintaining a complex responsive dashboard without breaking existing components
  • Integrating multiple evidence files while keeping the public repository safe and reproducible

The user interface was also challenging because the project contains many information layers. We repeatedly refined spacing, card proportions, hierarchy, and responsiveness so that symptom input, AI reasoning, safety alerts, trends, and public evidence could coexist without overwhelming the user.

Finally, developing the project while continuing cancer treatment was personally demanding. There were moments of fatigue and uncertainty, but the meaning behind the project kept me moving forward.

Accomplishments that we're proud of

I am especially proud that OncoConnect AI is more than a visual prototype. It is a working end-to-end platform with:

  • A deployed frontend and backend
  • Live OpenRouter AI integration
  • Deterministic symptom validation
  • Explainable risk scoring
  • A working red-flag safety override
  • Structured Splunk HEC telemetry
  • Splunk Search API integration
  • Live cohort comparison logic
  • AI fallback behavior
  • A bilingual user interface
  • Responsive care-intelligence dashboards
  • Doctor-ready summaries and next actions
  • PDF export functionality
  • A public open-source repository
  • A documented architecture diagram
  • Secure environment-variable handling
  • Hosted-demo safeguards for administrative actions

The most meaningful accomplishment is the safety behavior.

During testing, the system correctly recognized fever as a warning sign even when the calculated symptom score was low. It overrode the normal recommendation, changed the priority to critical, displayed the detected warning sign, and provided urgent-contact guidance.

That result represents the central purpose of the platform: using AI and observability to support people without allowing AI convenience to take priority over safety.

I am also proud that a personal experience with cancer became the foundation for a project that may help other patients, caregivers, and support organizations.

What we learned

This project taught me that observability is not limited to servers, infrastructure, or application performance.

In a human-centered AI system, observability can also mean understanding:

  • What information entered the system
  • How a support score was calculated
  • Whether an AI model or fallback produced the result
  • Which safety rule was activated
  • What evidence influenced the interface
  • Whether telemetry was indexed successfully
  • How the current case compares with recent events
  • What action was recommended and why

I learned that responsible AI requires a combination of probabilistic and deterministic systems. A generative model is useful for explaining information and preparing supportive communication, but high-impact safety conditions should be handled by explicit rules.

I also learned how important graceful degradation is. If the AI provider or Splunk connection is unavailable, the application should not simply crash. It should preserve safe core functionality, clearly report what is unavailable, and avoid presenting misleading information.

From a technical perspective, I strengthened my skills in:

  • React interface architecture
  • Node.js and Express APIs
  • Serverless deployment
  • Splunk HEC and Search APIs
  • AI prompt and response orchestration
  • Input validation
  • Rule-based safety systems
  • Environment and secret management
  • Responsive data visualization
  • Git and public repository preparation
  • Production debugging across local and hosted environments

Most importantly, I learned that technology becomes more meaningful when it is built from empathy and lived experience.

What's next for OncoConnect AI

The next stage is to evolve OncoConnect AI from a hackathon prototype into a validated support and observability platform developed together with patients, caregivers, clinicians, hospitals, and cancer-focused NGOs.

Planned developments include:

  • Secure long-term patient symptom histories
  • Consent-based caregiver access
  • Clinician and NGO support dashboards
  • More advanced Splunk anomaly detection
  • Alerts for meaningful symptom deterioration
  • Treatment-specific symptom monitoring pathways
  • Configurable clinical safety protocols
  • Secure authentication and role-based access
  • Privacy-preserving data storage
  • Stronger multilingual support
  • Accessibility improvements

Built With

Share this project:

Updates