Swasthya AI

Swasthya AI: A multilingual health memory platform that connects symptoms, medicines, and family history to deliver explainable insights and help patients and doctors make better-informed decisions.

Comment

Swasthya AI — Healthcare That Remembers

Tagline: Healthcare that remembers, so patients never have to start from zero.

1. Inspiration

Healthcare information is often fragmented across paper prescriptions, laboratory reports, different clinics, and disconnected digital applications. Patients may repeatedly explain their medical history, forget previous symptoms, or overlook recurring patterns between consultations. Doctors, meanwhile, have limited time to reconstruct a patient's health story.

We wanted to build a system that does more than answer isolated health questions. Swasthya AI creates a connected, evolving health memory that links symptoms, medicines, family history, lifestyle information, and health measurements over time.

Inspired by the need for accessible healthcare in India, we designed it to support Hindi, Marathi, and English through voice-first interactions. Our goal is to help patients maintain better health records and give doctors clearer, explainable context without replacing professional medical judgment.

2. What We Built

Swasthya AI is a multilingual health memory and clinical decision-support platform consisting of two interfaces.

Patient Application

  • Conversational onboarding to collect medical history, allergies, medicines, surgeries, and family history.
  • Voice and text interactions in Hindi, Marathi, and English.
  • Adaptive daily check-ins based on previous symptoms.
  • A health timeline and 3D body heatmap showing symptom frequency and recency.
  • Family health groups with individual record privacy.
  • Medicine tracking, reminders, and drug-interaction checks.
  • Jan Aushadhi generic medicine price comparisons and store discovery.
  • Cardiovascular risk estimation with contributing factors.
  • Appointment booking and simulated smartwatch measurements for demonstrations.

Doctor Dashboard

  • QR-code or patient-ID-based record lookup.
  • Summarised medical history, recurring symptoms, and active medications.
  • Explainable cardiovascular risk results.
  • Medicine conflict review and patient-specific AI assistance.
  • A trace panel showing how information was retrieved and processed.
  • Appointment management and concise patient summaries.

3. How We Built It

Technology Stack

Component Technology Purpose
Patient application React Native, Expo, TypeScript Cross-platform patient experience
Doctor dashboard React, Vite, TypeScript Clinician-facing interface
Backend FastAPI, Python APIs and orchestration
Health memory Neo4j AuraDB Connected health relationships
Structured storage Supabase, PostgreSQL Accounts, medicines, appointments, and structured records
Voice Sarvam AI Speech-to-text and text-to-speech
Language model Groq-hosted Llama model Context extraction and natural-language responses
Drug information OpenFDA API Medication safety information
Machine learning scikit-learn, XGBoost, SHAP Cardiovascular risk estimation and explanation
Deployment Render Backend and workflow hosting

System Architecture

Every patient interaction passes through a central orchestrator that coordinates 11 specialised agents.

  1. Perceive: Receive typed messages, voice transcripts, or health events.
  2. Understand: Extract symptoms, duration, severity, and recurrence indicators into structured data.
  3. Retrieve Memory: Fetch relevant historical relationships from Neo4j and structured records from Supabase.
  4. Route Agent: Select the appropriate specialised agent.
  5. Validate and Apply Safety Rules: Check relevant data and deterministic escalation conditions.
  6. Execute Action: Perform supported actions, such as creating reminders or queuing clinician questions.
  7. Update Memory: Save confirmed information and an auditable event.
  8. Respond: Return a contextual response with explanations and available source information.

Why a Graph Database?

Health information is relational. For example:

Patient → Symptom → Previous Episode

Patient → Takes → Medicine

Patient → Family Member → Medical Condition

Neo4j represents these relationships as nodes and edges, allowing the system to retrieve relevant context across multiple records rather than relying only on isolated chat messages.

Supabase complements the graph by managing structured, transactional application data.

4. Cardiovascular Risk Prediction: ML Pipeline and Formulas

Swasthya AI includes one machine-learning model for estimating cardiovascular risk. It is a decision-support feature, not a diagnostic system.

Dataset and Features

The training pipeline uses a public cardiovascular disease dataset containing approximately 70,000 records. The target indicates whether cardiovascular disease is present.

Input features include:

  • Age and gender
  • Height and weight
  • Systolic and diastolic blood pressure
  • Cholesterol and glucose categories
  • Smoking and alcohol indicators
  • Physical activity

Feature Engineering

1. Age Conversion

The source dataset stores age in days:

$$ \text{Age in years}=\frac{\text{Age in days}}{365.25} $$

2. Body Mass Index (BMI)

$$ \text{BMI}=\frac{\text{Weight (kg)}}{[\text{Height (m)}]^2} $$

For a person weighing 70 kg and measuring 1.75 m:

$$ \text{BMI}=\frac{70}{1.75^2}\approx22.86 $$

3. Pulse Pressure

$$ \text{Pulse Pressure}=\text{SBP}-\text{DBP} $$

For a blood pressure reading of 120/80 mmHg:

$$ \text{Pulse Pressure}=120-80=40\text{ mmHg} $$

These engineered features supplement the original inputs. They are not, by themselves, diagnoses or definitive measures of individual cardiovascular health.

Data Preparation and Training

The proposed pipeline follows these steps:

  1. Remove duplicate records and implausible measurements.
  2. Split the dataset into stratified 80% training and 20% test sets.
  3. Apply missing-value imputation, numerical scaling, and categorical encoding within a scikit-learn pipeline.
  4. Compare Logistic Regression, a regularised Random Forest, and regularised XGBoost.
  5. Use stratified five-fold cross-validation on the training set.
  6. Select a candidate based on ROC-AUC, recall, precision, F1, accuracy, and calibration.
  7. Calibrate predicted probabilities using sigmoid or isotonic calibration.
  8. Evaluate the selected model on the held-out test set.
  9. Save the trained pipeline as a .joblib artifact for serving through FastAPI.

Logistic Regression Formula

Logistic Regression estimates the probability of the positive class using a linear combination of input features:

$$ z=b+\sum_{i=1}^{n}w_ix_i $$

The sigmoid function converts this value into a probability:

$$ P(y=1\mid x)=\sigma(z)=\frac{1}{1+e^{-z}} $$

Where:

  • (x_i) represents an input feature.
  • (w_i) represents its learned coefficient.
  • (b) is the intercept.
  • (P(y=1\mid x)) is the predicted probability of the positive class.

The final model is selected according to the defined validation process. Logistic Regression serves as a baseline rather than a predetermined winner.

Probability Calibration and Risk Bands

Calibration aims to make predicted probabilities better match observed outcome frequencies across comparable groups.

The initial proposed risk bands are:

  • LOW: Probability below 0.35.
  • MEDIUM: Probability from 0.35 through 0.65.
  • HIGH: Probability above 0.65.

These are starting thresholds, not clinically validated cut-offs. Final thresholds should be selected using validation data and assessed for clinical suitability before real-world use.

Explainability Using SHAP

SHAP helps explain which input features contributed to a particular model prediction.

A simplified additive explanation is:

$$ f(x)=\phi_0+\sum_{i=1}^{n}\phi_i $$

Where:

  • (f(x)) is the model output being explained.
  • (\phi_0) is the baseline output.
  • (\phi_i) represents the contribution of feature (i).

Depending on the explanation configuration, the output may be expressed in probability space or another model-output space. SHAP contributions explain model behaviour; they do not establish medical causation.

Missing Data and Confidence

The pipeline uses median imputation for numerical inputs and most-frequent-value imputation for categorical inputs. Missingness indicators can help distinguish actual observations from imputed values.

Age, gender, blood pressure, height, and weight are designated as minimum required inputs. If these are missing, the system requests them rather than producing a risk estimate.

The interface distinguishes measured or user-provided values from estimated values. Confidence labels must be supported by a defined validation method and should not be interpreted as guarantees of medical accuracy.

Serving the Model

The trained pipeline is exposed through a FastAPI /predict-risk endpoint. It returns the predicted probability, risk band, contributing factors, and relevant missing-input information.

The Cardiac Risk Agent passes this output to the orchestrator, which presents it in the patient application and doctor dashboard.

The what-if interface can recompute predictions when inputs change. These scenarios illustrate model sensitivity and do not predict the clinical effect of changing a person's blood pressure or weight.

5. Safety, Reliability, and Explainability

We deliberately separate language understanding from safety-critical decisions.

Deterministic Escalation Rules

The language model extracts information, while explicit Python rules determine whether a defined escalation condition has been met.

For example, a configured rule may flag breathing difficulty when it occurs alongside recurrence, an age-related risk condition, or relevant cardiac history. The system records the rule ID and contributing factors so that the decision can be reviewed.

This is an illustrative rule, not a complete clinical triage protocol. Real deployments require clinically reviewed rules, appropriate emergency guidance, and validation.

Medication Conflict Checks

Before a newly entered medicine is saved, the system checks available OpenFDA information against the patient's existing medication list. Potential conflicts are surfaced for review.

External drug databases may have incomplete coverage, and an API check cannot guarantee that a medication combination is safe. Patients should consult a qualified clinician or pharmacist before changing medicines.

Grounded Doctor Q&A

The doctor assistant retrieves relevant patient-specific graph data before answering. If required information is missing, it identifies the gap and can queue a question for the patient's next check-in rather than inventing an answer.

Important facts require confirmation before saving, structured outputs are validated, and processing steps are logged for traceability.

Privacy

Family relationships help contextualise health risks, but each person's individual records remain private. Only permitted, non-sensitive contextual information should be shared. Access controls and consent are essential to any production deployment.

6. Challenges We Faced

  • Connecting fragmented records: Representing symptoms, medication history, and family relationships required a consistent graph structure.
  • Coordinating multiple agents: A central orchestrator was needed to route requests and keep specialist responsibilities separate.
  • Reducing unsupported AI output: Structured extraction, source-grounded answers, validation, and deterministic safety rules help reduce unsupported conclusions.
  • Handling missing health measurements: The risk pipeline required explicit input requirements, imputation, and visible distinctions between actual and estimated values.
  • Making predictions understandable: SHAP explanations and a trace panel help users inspect model factors and processing steps.
  • Integrating multiple technologies: Connecting React Native, FastAPI, Neo4j, Supabase, voice services, and the ML endpoint required clear API boundaries.
  • Designing for Indian users: Multilingual voice interactions and generic medicine price comparisons address accessibility and affordability challenges.

7. What We Learned

We learned that meaningful healthcare AI requires more than a powerful language model. Persistent memory, reliable data relationships, transparent explanations, privacy controls, and clearly defined safety boundaries are equally important.

We also gained practical experience with graph databases, multi-agent orchestration, API integration, machine-learning pipelines, probability calibration, SHAP explanations, and multilingual voice interfaces.

Most importantly, we learned to distinguish a model's prediction from a medical conclusion and to design the system around that distinction.

8. Impact and Future Vision

Swasthya AI aims to reduce repetitive history-taking, help patients notice recurring symptoms, and give clinicians a more structured view of relevant medical context.

Its longer-term potential includes integration with validated wearable devices, locally validated risk models, clinically reviewed escalation protocols, and healthcare-provider systems with appropriate consent and security.

The current smartwatch experience is a simulator, and the cardiovascular model is based on a general public dataset rather than validation for the Indian population. These limitations must be addressed before clinical deployment.

9. Conclusion

Swasthya AI turns disconnected health records into a connected health story. By combining multilingual voice, graph-based memory, specialised agents, deterministic safety rules, and explainable machine learning, it aims to help patients and clinicians make better-informed decisions.

Our core belief is simple: healthcare should remember relevant context, explain what it knows, acknowledge what it does not know, and keep qualified medical professionals at the centre of care.

Disclaimer: Swasthya AI is a prototype for health awareness and decision support. It does not diagnose diseases, prescribe treatment, or replace professional medical evaluation. Its model estimates and safety rules require appropriate validation before real-world clinical use.

Built With

Share this project:

Updates

Submission history