Problem Statements Analysis

From what to build to how to build it — our platform helps you understand, plan, and solve SIH 2026 problem statements with complete insights into requirements, solution approaches, technology stacks, architecture, AI/ML, and implementation roadmaps.

Scroll down
01 / SIH 2026

PS: SIH26181

A secure, AI-powered Personal Health Companion that delivers real-time, privacy-preserving health monitoring and early warning capabilities, helping individuals recognize health risks before they become emergencies. The solution should improve resilience during heat waves, floods, pollution events, and other disasters common in India while enabling continuous health support through on-device intelligence.

Description: Background India faces recurring public health challenges during and after disasters such as heat waves, floods, cyclones, air pollution events, disease outbreaks, and extreme weather conditions. Heat stress, dehydration, respiratory illnesses, cardiovascular complications, and delayed access to healthcare are common during such events. Rural populations, elderly citizens, outdoor workers, and people with chronic medical conditions are particularly vulnerable. Climate-related hazards are increasing in frequency and intensity, creating a need for continuous, personalized health monitoring that can function even when connectivity and healthcare access are disrupted. Advances in edge AI now enable wearable devices and mobile phones to analyze health data locally, providing real-time insights while preserving user privacy and operating without constant cloud connectivity. Local AI processing can support health monitoring in remote and underserved areas where internet access may be limited. Description Develop a Personal Health Companion, a privacy-preserving wearable or mobile application that continuously monitors an individual's physiological and environmental data and uses on-device AI to detect potential health anomalies in real time.The solution should analyze data from sensors such as heart rate, blood oxygen (SpO?), body temperature, activity levels, sleep patterns, and environmental conditions. The system should identify early indicators of heat stress, dehydration, respiratory distress, abnormal vital signs, fatigue, falls, and other health risks that may be exacerbated during disasters and environmental emergencies.All sensitive health data should be processed locally on the device to maximize privacy, minimize latency, and ensure continuous operation even during network outages. The application should provide actionable alerts, wellness recommendations, and emergency notifications while allowing users to maintain control over their personal health information. Edge AI approaches provide faster responses, improved privacy, and offline functionality. Expected Solution The proposed solution should implement some or all of the following: 1. Continuous Health Monitoring • Monitor heart rate, SpO?, body temperature, activity levels, and sleep quality. • Track changes in baseline health patterns. • Generate personalized wellness indicators. 2. AI-Based Health Anomaly Detection • Detect abnormal heart rate patterns. • Identify indicators of heat stress, dehydration, fatigue, and respiratory issues. • Recognize sudden changes that may require medical attention. • Provide risk assessments using on-device AI inference. 3. Disaster-Specific Health Alerts • Heat-wave exposure warnings. • Air-quality and respiratory-risk alerts. • Flood and cyclone-related health advisories. • High-risk notifications for vulnerable individuals during extreme weather events. 4. Environmental Awareness • Integrate data from local temperature, humidity, and air-quality sensors. • Assess environmental conditions that may affect health. • Generate personalized recommendations based on local risks. 5. Privacy-Preserving Edge AI • Perform all health analysis locally on the device. • Minimize transmission of sensitive personal information. • Operate effectively with intermittent or no internet connectivity. • Maintain user control over data sharing. 6. Emergency Assistance Features • Automatic detection of falls or medical distress. • SOS alerts to caregivers or emergency contacts. • Location-enabled emergency assistance when permitted by the user. 7. Personal Wellness Dashboard • Daily health summaries and trend analysis. • Risk scores for heat, respiratory, and cardiovascular stress. • Personalized recommendations for hydration, rest, activity, and medical consultation. 8. Scalable Deployment • Support smartphones, smartwatches, fitness bands, and specialized healthcare wearables. • Suitable for individual consumers, healthcare providers, disaster-response agencies, and public health programs.
Organization: Qualcomm Inc
Department: Qualcomm Inc
Category: Hardware
Theme: MedTech / BioTech / HealthTechtd>
Youtube Link: Not provided
Dataset Link: Not provided
Contact info: Not provided

1. Executive Snapshot

This dossier provides a comprehensive technical, architectural, and strategic roadmap for Smart India Hackathon (SIH) Problem Statement SIH26181 [PS]. The target objective is to design and build a secure, privacy-preserving, edge-AI powered Personal Health Companion capable of continuous physiological and environmental monitoring, on-device health anomaly detection, and real-time early warnings for climate-induced disaster risks (heat waves, floods, air pollution, disease outbreaks) common in India [PS]. The solution operates without relying on continuous cloud connectivity [PS], prioritizing high resilience, low latency, local data governance [PS], and accessibility across both low-cost mobile phones and wearable smart devices [PS].

Metadata Summary

Parameter Value Evidence Tag
Problem Statement ID SIH26181 [PS]
Title A secure, AI-powered Personal Health Companion that delivers real-time, privacy-preserving health monitoring and early warning capabilities [PS]
Organization Qualcomm Inc [PS]
Department Qualcomm Inc [PS]
Category Hardware [PS]
Theme MedTech / BioTech / HealthTech [PS]
Deadline 30 September 2026 [PS]
Ideas Counter 0/500 [PS]
Dataset Link None provided in PS statement [PS]

Fundamental System Objective:
To deliver an autonomous, on-device AI health companion that ingests multi-sensor physiological and local environmental metrics to detect health anomalies, fall distress, heat stress, and environmental exposure risks in real time without transmitting raw health data off-device [PS].

2. Problem Deconstruction

The problem statement has been broken down into atomic, unambiguous requirements preserving all explicit text provided in the official SIH JSON [PS].

Requirement 1: Continuous Health Monitoring [PS]

  • Source Text: "Monitor heart rate, $\text{SpO}_2$, body temperature, activity levels, and sleep quality. Track changes in baseline health patterns. Generate personalized wellness indicators." [PS]
  • Interpretation: The system must continuously or periodically ingest physiological telemetry ($\text{HR}$, $\text{SpO}_2$, skin/body temperature, accelerometer-derived physical activity, PPG-derived sleep quality) [PS], compute personalized baseline statistics over moving temporal windows [INFERENCE], and highlight deviations from normal physiological baselines [PS].
  • Implementation Implication: Requires efficient time-series data storage on-device, streaming feature extraction (e.g., Heart Rate Variability / HRV, Resting Heart Rate / RHR, Motion Intensity), and lightweight baseline statistical tracking algorithms [INFERENCE].
  • Confidence Tag: [PS]

Requirement 2: AI-Based Health Anomaly Detection [PS]

  • Source Text: "Detect abnormal heart rate patterns. Identify indicators of heat stress, dehydration, fatigue, and respiratory issues. Recognize sudden changes that may require medical attention. Provide risk assessments using on-device AI inference." [PS]
  • Interpretation: On-device machine learning models must process physiological inputs to output real-time anomaly scores and risk categorizations without relying on cloud inference servers [PS].
  • Implementation Implication: Lightweight ONNX / TensorFlow Lite / Qualcomm AI Engine models (such as 1D-CNNs, Autoencoders, or Decision Trees) optimized for edge deployment [INFERENCE].
  • Confidence Tag: [PS]

Requirement 3: Disaster-Specific Health Advisories & Risk Alerts [PS]

  • Source Text: "Heat-wave exposure warnings. Air-quality and respiratory-risk alerts. Flood and cyclone-related health advisories. High-risk notifications for vulnerable individuals during extreme weather events." [PS]
  • Interpretation: The application must correlate local environmental hazard indicators (ambient heat index, particulate matter levels, flood/cyclone advisories) with user vulnerability factors (age, pre-existing conditions) to issue early warnings [PS].
  • Implementation Implication: Integration of environmental risk matrices combining physiological strain (e.g., elevated core temp proxy + tachycardia) with external weather/air quality parameters [INFERENCE].
  • Confidence Tag: [PS]

Requirement 4: Environmental Awareness & Sensor Integration [PS]

  • Source Text: "Integrate data from local temperature, humidity, and air-quality sensors. Assess environmental conditions that may affect health. Generate personalized recommendations based on local risks." [PS]
  • Interpretation: The solution must interface with on-device sensors, BLE-connected environmental sensor pods, or local weather/AQI broadcast feeds [PS].
  • Implementation Implication: Hardware sensor driver layer (I2C/UART or BLE GATT profile) and offline cache for regional environmental risk grids [INFERENCE].
  • Confidence Tag: [PS]

Requirement 5: Privacy-Preserving Edge AI & Offline Operation [PS]

  • Source Text: "Perform all health analysis locally on the device. Minimize transmission of sensitive personal information. Operate effectively with intermittent or no internet connectivity. Maintain user control over data sharing." [PS]
  • Interpretation: Strict Zero-Cloud-Inference policy. Raw biosignals, health logs, and location tracks must remain encrypted on local storage [PS].
  • Implementation Implication: Local SQLite database with SQLCipher encryption, on-device AI runtime (ONNX Runtime Mobile or Qualcomm Snapdragon Neural Processing Engine), and local rule evaluation [INFERENCE].
  • Confidence Tag: [PS]

Requirement 6: Emergency Assistance & Fall/Distress Features [PS]

  • Source Text: "Automatic detection of falls or medical distress. SOS alerts to caregivers or emergency contacts. Location-enabled emergency assistance when permitted by the user." [PS]
  • Interpretation: System must monitor IMU (accelerometer/gyroscope) data for fall pattern recognition and detect physiological distress (e.g., sudden drop in $\text{SpO}_2$ or severe bradycardia/tachycardia) to trigger automated SOS workflows [PS].
  • Implementation Implication: Threshold + ML fall detection pipeline, background SMS/cellular alert trigger, offline SMS location broadcast, and optional audio/visual countdown timer to prevent false alarms [INFERENCE].
  • Confidence Tag: [PS]

Requirement 7: Personal Wellness Dashboard & Actionable Insights [PS]

  • Source Text: "Daily health summaries and trend analysis. Risk scores for heat, respiratory, and cardiovascular stress. Personalized recommendations for hydration, rest, activity, and medical consultation." [PS]
  • Interpretation: A user interface providing transparent, explainable health summaries, daily trend charts, composite risk indices, and actionable guidance [PS].
  • Implementation Implication: Mobile UI (Flutter / React Native / Native Android) rendering historical graphs and risk gauge widgets fed by local SQLite analytics [INFERENCE].
  • Confidence Tag: [PS]

Requirement 8: Scalable Deployment Across Multi-Device Ecosystems [PS]

  • Source Text: "Support smartphones, smartwatches, fitness bands, and specialized healthcare wearables. Suitable for individual consumers, healthcare providers, disaster-response agencies, and public health programs." [PS]
  • Interpretation: Hardware-agnostic software architecture capable of ingesting data via standard BLE Health Device Profiles (Heart Rate, Health Thermometer, Pulse Oximeter) or Android Companion Device Manager [PS].
  • Implementation Implication: Standardized abstraction layer for data ingestion (Android Health Connect API / Wear OS OS / BLE GATT) [INFERENCE].
  • Confidence Tag: [PS]

3. Stakeholders & User Needs

Stakeholder Primary Goal Current Pain Point System Need
Outdoor / Daily Wage Workers [KNOWN] Avoid severe heat stroke, dehydration, and exhaustion during work shifts [KNOWN]. Unaware of dangerous internal physiological heat buildup; work environments lack cooling; internet access in field is patchy [KNOWN]. On-device, offline heat-stress and hydration alerts via haptic/audio warnings on low-cost wearables or basic smartphones [INFERENCE].
Elderly & Individuals with Chronic Illnesses [KNOWN] Prevent cardiovascular strain and respiratory collapse during disaster events [KNOWN]. High sensitivity to extreme weather and air pollution; delayed emergency response when living alone [KNOWN]. Passive health anomaly detection, automatic fall/distress sensing, and immediate SMS-based SOS alert to family/caregivers [INFERENCE].
Disaster Response & Public Health Agencies (NDMA/SDMA) [RESEARCHED] Protect vulnerable populations during heatwaves, floods, and severe air pollution events [RESEARCHED]. Lack of granular, real-time localized health vulnerability data; delayed awareness of community health distress [RESEARCHED]. Privacy-preserving, anonymized opt-in telemetry sync (when connected) to highlight regional health risk hotspots without violating individual privacy [INFERENCE].
Healthcare Providers / Field Clinics [KNOWN] Identify early deterioration in high-risk patients before acute hospitalization is required [KNOWN]. Intermittent patient touchpoints; lack of continuous historical physiological baseline trends during disasters [KNOWN]. On-device exportable summary reports (PDF/CSV) detailing physiological trends, baseline shifts, and anomaly logs [INFERENCE].

4. Requirements Traceability

Proposed Feature / Module Justifying Requirement Explicit vs. Inferred Implementation Component
On-Device Biosignal Ingestion Pipeline Req 1: Continuous Health Monitoring Explicit [PS] BLE GATT Manager & Android Health Connect Adapter
Edge Anomaly Detection Engine (Autoencoder) Req 2: AI-Based Health Anomaly Detection Explicit [PS] ONNX Runtime Mobile / TFLite C++ Runtime Engine
Heat-Stress Index Engine (WBGT / Heat Index Proxy) Req 3 & 4: Environmental Awareness & Disaster Alerts Explicit [PS] Physiological Strain Index (PSI) & Wet-Bulb Globe Temp Rule Module
BLE Environmental Pod Driver Req 4: Environmental Awareness Explicit [PS] Custom BLE GATT Service (DHT22 / Sensirion particulate sensors)
Local Encrypted Database (SQLCipher) Req 5: Privacy-Preserving Edge AI Explicit [PS] SQLite + SQLCipher AES-256 Storage Module
Offline Fall & Medical Distress Detector Req 6: Emergency Assistance Explicit [PS] IMU Accelerometer Threshold + ML Model & Android Telephony SMS Manager
Multi-Scale Health Risk Dashboard UI Req 7: Personal Wellness Dashboard Explicit [PS] Flutter Cross-Platform UI with Charts & Guidance Cards
Universal Sensor Abstraction Layer Req 8: Scalable Deployment Explicit [PS] Abstract Device Ingestion API (Wear OS, BLE GATT, Health Connect)

5. Constraints & Environment Realities

  1. Intermittent / Zero Network Connectivity: Disasters such as floods, cyclones, and extreme storms routinely destroy cell towers and electrical grids in India [KNOWN]. The entire inference engine, baseline database, and safety advisories must function 100% offline [PS].
  2. Device Hardware Diversity: Target users in rural or underserved urban areas use low-cost Android smartphones (2GB–4GB RAM, entry-level MediaTek/Qualcomm SoCs) or budget smart bands [KNOWN]. High memory footprint models (e.g., large LLMs or heavy vision models) will cause system thrashing or crash [INFERENCE].
  3. Power & Battery Limitations: Continuous multi-sensor sampling and high-frequency AI inference quickly deplete battery reserves [KNOWN]. Power budget optimization (duty-cycled sampling, event-triggered inference) is strictly required [INFERENCE].
  4. Language & Digital Literacy: A large demographic of vulnerable outdoor workers and rural citizens cannot read complex medical charts or English text [KNOWN]. Guidance must be provided via localized vernacular speech, iconography, and color-coded risk alerts [INFERENCE].
  5. Sensor Quality & Artifacts: Commercial low-cost PPG sensors and accelerometers suffer heavy motion artifacts during manual physical labor [RESEARCHED]. Filtering techniques (e.g., Butterworth bandpass filters, motion-artifact rejection using accelerometer cross-correlation) are vital [RESEARCHED].

6. Research Questions

  1. How can physiological heat stress be accurately estimated using wrist-worn PPG, skin temperature, and motion sensors without direct core temperature probes? [RESEARCHED]
  2. What lightweight machine learning model architecture achieves optimal trade-off between precision, recall, and battery consumption on low-end Qualcomm Snapdragon SoCs? [INFERENCE]
  3. How do national disaster guidelines (e.g., India's NDMA Heat Action Plan) define threshold trigger points for heat stress and air quality hazards? [RESEARCHED]
  4. What open-access physiological datasets are available to train and validate continuous PPG anomaly detection and heat stress prediction models? [RESEARCHED]
  5. How can emergency alerts be reliably dispatched during total cellular data network blackout without relying on internet servers? [INFERENCE]

7. Data Requirements & Sources

Data Type Purpose Ideal Real-World Source Hackathon Substitute Access Method Availability Privacy Sensitivity Confidence
Photoplethysmography (PPG) / Heart Rate & HRV Continuous HR tracking, anomaly detection, heat stress strain estimation. Smartwatch PPG Sensor (e.g., Wear OS, Apple Watch, Garmin) [KNOWN]. Open-source PPG datasets (PPG-DaLiA [RESEARCHED], WESAD [RESEARCHED], MIMIC-III [RESEARCHED]) + simulated BLE HR broadcast stream. Local BLE GATT / File Stream. Publicly Available [RESEARCHED]. High (Physiological Data) [PS]. [RESEARCHED]
Pulse Oximetry ($\text{SpO}_2$) Detect respiratory distress, hypoxia during high pollution/drowning/illness. Medical-grade or smartwatch pulse oximeter sensor [KNOWN]. PhysioNet CapnoBase dataset [RESEARCHED] / CSV stream generator. BLE / Local File. Publicly Available [RESEARCHED]. High [PS]. [RESEARCHED]
Skin / Body Temperature Direct indicator of heat strain, fever, hyperthermia. Continuous thermistor / IR thermal sensor on wearable [KNOWN]. Synthetic sensor telemetry generated based on NDMA physiological heat stress profiles [RESEARCHED]. BLE / Simulated UART. Synthetic / Generated. High [PS]. [ASSUMPTION]
3-Axis Accelerometer / Gyroscope Motion intensity, step counting, fall detection, sleep quality estimation. Wearable / Smartphone IMU [KNOWN]. MobiAct dataset [RESEARCHED] / Real smartphone accelerometer sensor API. Android SensorManager API. Real-time on-device [KNOWN]. Medium [KNOWN]. [KNOWN]
Ambient Temperature & Humidity Calculate Heat Index / Wet-Bulb Globe Temperature (WBGT) proxy. External BLE sensor pod (DHT22/BME280) or IMD Weather API [RESEARCHED]. Open-Meteo Historical Weather API [RESEARCHED] / Local BLE sensor simulation. REST API / BLE. Free Public API / Local BLE [RESEARCHED]. Low [KNOWN]. [RESEARCHED]
Air Quality (PM2.5, PM10, AQI) Respiratory hazard risk scoring. CPCB (Central Pollution Control Board) CAAQMS stations [RESEARCHED]. OpenAQ v3 Public API [RESEARCHED] / JanVayu public feed [RESEARCHED]. REST API (JSON). Open Public API [RESEARCHED]. Low [KNOWN]. [RESEARCHED]

Data Categorization Breakdown:

  • A. Data Explicitly Mentioned in PS: Heart rate, $\text{SpO}_2$, body temperature, activity levels, sleep quality, ambient temperature, humidity, air-quality data [PS].
  • B. Data Required by Inference: Heart Rate Variability (HRV - SDNN/RMSSD), Physiological Strain Index (PSI), 3-axis acceleration vectors, user age, chronic risk profiles [INFERENCE].
  • C. Data That Must Be Collected in Field: Real-time IMU streams from smartphone/wearable, live local ambient temp/humidity readings [INFERENCE].
  • D. Data That Can Be Synthetically Generated: Simulated high-stress heatwave physiological sequences (coupling rising skin temp + persistent elevated HR + low HRV) for hackathon demonstration [ASSUMPTION].
  • E. Data That Still Needs Validation: Exact calibration curves mapping wrist skin temperature to true internal core body temperature under direct sunlight exposure [NEEDS VALIDATION].

8. Existing Solutions & Gap Analysis

1. Commercial Smartwatches (Apple Health / Garmin / Samsung Health)

  • Description: Advanced health tracking smartwatches providing continuous heart rate, ECG, $\text{SpO}_2$, and fall detection [KNOWN].
  • Strengths: High sensor accuracy, sleek UI, polished fall detection algorithms [KNOWN].
  • Weaknesses: Highly expensive ($200–$800 USD); require constant cloud syncing for deep analysis; proprietary walled ecosystems; lack specific integration with Indian disaster hazards (e.g., CPCB air quality or NDMA heat action plans) [INFERENCE].
  • Relevance: Serves as benchmark for sensor capabilities [KNOWN].
  • Gap: Inaccessible to low-income populations in India; lack localized environmental disaster risk fusion [INFERENCE].
  • Source: Apple Health / Garmin Documentation [KNOWN].
  • Confidence Tag: [KNOWN]

2. JanVayu / OpenAQ Air Quality Apps

  • Description: Public air quality monitoring and visualization platforms aggregating CPCB CAAQMS station data across Indian cities [RESEARCHED].
  • Strengths: Excellent localized PM2.5/PM10 and AQI maps; free open-source data feeds [RESEARCHED].
  • Weaknesses: Purely environmental dashboards; zero physiological monitoring or individual health vulnerability modeling; require active internet connection [INFERENCE].
  • Relevance: Essential data source for ambient disaster hazards [RESEARCHED].
  • Gap: No personal physiological correlation, offline operation, or custom health alerts [INFERENCE].
  • Source: JanVayu (janvayu.in) [RESEARCHED] / OpenAQ (openaq.org) [RESEARCHED].
  • Confidence Tag: [RESEARCHED]

3. Government Heat Action Plans (NDMA / IMD Weather Alerts)

  • Description: Public advisories issued via SMS, TV, radio, and news bulletins during extreme heatwaves [RESEARCHED].
  • Strengths: Authoritative, high coverage across municipal jurisdictions [RESEARCHED].
  • Weaknesses: Broadcast-style, generic messaging (not personalized); cannot detect individual physiological distress or early heat exhaustion in real time [INFERENCE].
  • Relevance: Provides regulatory threshold benchmarks for heat risk [RESEARCHED].
  • Gap: Passive communication; no real-time wearable sensor tracking or on-device health AI [INFERENCE].
  • Source: National Disaster Management Authority (NDMA) Guidelines [RESEARCHED].
  • Confidence Tag: [RESEARCHED]

9. Candidate Solution Approaches

Approach 1: Wearable Hardware-Centric Edge-AI System

  • Mechanism: Custom hardware wearable board featuring a microcontroller (e.g., ESP32-S3 or Nordic nRF52840) wired directly to MAX30102 ($\text{HR}/\text{SpO}_2$), MPU6050 (IMU), skin temperature sensor, and DHT22. Runs lightweight TinyML C++ models on-chip [INFERENCE].
  • Problem Fit: High hardware alignment with PS category ("Hardware"), direct sensor access [PS].
  • Accuracy Potential: High for raw sensor access, moderate for ML due to tight memory constraints ($\le 512\text{ KB}$ RAM) [INFERENCE].
  • Data Requirements: Raw I2C sensor streams [INFERENCE].
  • Complexity: High (custom PCB design, hardware debugging, firmware development) [INFERENCE].
  • Explainability: Moderate (rule-based + lightweight decision tree) [INFERENCE].
  • Cost: Low hardware unit cost ($\sim $15-$25$), but high initial prototyping effort [ASSUMPTION].
  • Scalability: Requires manufacturing custom hardware devices for end users [INFERENCE].
  • Hackathon Feasibility: High risk of hardware assembly glitches during short hackathon build [INFERENCE].
  • Production Feasibility: Requires hardware manufacturing pipeline [INFERENCE].

Approach 2: Mobile-First Sensor Fusion & Smartphone On-Device AI

  • Mechanism: Android smartphone application that uses phone's internal sensors (IMU, location, ambient sensors) and connects via BLE to standard off-the-shelf smart bands/smartwatches. Runs ONNX Runtime Mobile models locally on the phone's CPU/NPU [INFERENCE].
  • Problem Fit: Excellent software reach, leverages existing smartphones owned by users [INFERENCE].
  • Accuracy Potential: High (utilizes phone's high compute power for sophisticated ONNX/TFLite models) [INFERENCE].
  • Data Requirements: BLE GATT standardized health data feeds + phone internal IMU [INFERENCE].
  • Complexity: Medium (Standard Android / Flutter app development) [INFERENCE].
  • Explainability: High (can present visual explainability dashboards) [INFERENCE].
  • Cost: Zero new hardware required if user owns a phone + cheap band [INFERENCE].
  • Scalability: Instant app store distribution [INFERENCE].
  • Hackathon Feasibility: Very high feasibility; robust software dev tools [INFERENCE].
  • Production Feasibility: High [INFERENCE].

Approach 3: Hybrid Mobile App + Open Hardware Wearable Node (RECOMMENDED)

  • Mechanism: A hybrid architecture combining:
    1. An open hardware BLE sensor node (or commercial Wear OS / BLE smart band) that captures HR, $\text{SpO}_2$, temp, and acceleration [INFERENCE].
    2. A mobile Companion App acting as the edge processing gateway running Qualcomm AI Hub / ONNX Runtime ML models for sensor fusion, anomaly detection, heat stress evaluation, and offline SMS emergency management [INFERENCE].
  • Problem Fit: Directly fulfills both Hardware and MedTech categories while guaranteeing rich user experience and edge AI compute power [PS].
  • Accuracy Potential: Very High (multi-sensor signal processing + edge AI inference on mobile NPU) [INFERENCE].
  • Data Requirements: Biosignals via BLE + environmental risk data [INFERENCE].
  • Complexity: Moderate (balanced hardware-firmware and mobile app scope) [INFERENCE].
  • Explainability: High (clear risk scoring breakdown) [INFERENCE].
  • Cost: Low prototyping cost [ASSUMPTION].
  • Scalability: High [INFERENCE].
  • Hackathon Feasibility: Optimal for 4-6 student team (split into hardware, mobile, AI/ML, and backend/GIS) [INFERENCE].
  • Production Feasibility: High [INFERENCE].

10. Recommended Approach & Why

Selection: Hybrid Mobile App + BLE Edge Sensor Gateway (Approach 3)

Why Alternatives Were Rejected:

  • Approach 1 (Standalone Microcontroller Wearable): Rejected as sole interface because displaying intuitive risk trends, regional disaster maps, and complex multi-language emergency workflows on tiny OLED screens or LEDs is severe UX degradation [INFERENCE]. Moreover, debugging complex edge models on microcontrollers under hackathon time limits presents high technical risk [INFERENCE].
  • Approach 2 (Pure Mobile App without Wearable): Rejected because smartphones cannot continuously track core physiological metrics like heart rate, pulse oximetry, or skin temperature while resting in a user's pocket or bag [INFERENCE].

Why Approach 3 Wins:

  • Fulfills the explicit SIH requirements for both wearable continuous physiological monitoring [PS] and robust on-device AI analysis [PS].
  • Allows the team to demonstrate a working hardware wearable prototype (BLE Sensor Node) alongside a powerful mobile application running quantized edge ML models [INFERENCE].
  • Guarantees 100% offline operation, local data encryption, and resilient SMS-based distress broadcasts during network blackouts [PS].

11. Technical Architecture

Layered Architecture Diagram

+-----------------------------------------------------------------------------------+
|                                 USER INTERFACE LAYER                              |
|  +-----------------------+  +------------------------+  +----------------------+  |
|  | Wellness Dashboard    |  | Disaster Hazard Map    |  | Vernacular Voice UI  |  |
|  | (HR, SpO2, Sleep, PSI)|  | (Offline Cache Grid)   |  | (Local Alerts)       |  |
|  +-----------------------+  +------------------------+  +----------------------+  |
+-----------------------------------------------------------------------------------+
                                         |
+-----------------------------------------------------------------------------------+
|                              ON-DEVICE EDGE CORE ENGINE                           |
|  +-----------------------------------------------------------------------------+  |
|  |                       On-Device AI / ML Inference Layer                     |  |
|  |  +------------------------+  +---------------------+  +------------------+  |  |
|  |  | 1D-CNN Anomaly Detector|  | Heat Strain (PSI)   |  | Fall & Distress  |  |  |
|  |  | (Quantized ONNX)       |  | Risk Calculator     |  | ML Classifier    |  |  |
|  |  +------------------------+  +---------------------+  +------------------+  |  |
|  +-----------------------------------------------------------------------------+  |
|                                         |                                         |
|  +-----------------------------------------------------------------------------+  |
|  |                       Local Data & Rule Evaluation Layer                    |  |
|  |  +-------------------------+  +--------------------+  +------------------+  |  |
|  |  | Baseline Engine (7-Day) |  | NDMA / AQI Rules   |  | Fall Emergency   |  |  |
|  |  | Moving Moving Averages  |  | Hazard Matrix      |  | Dispatcher (SMS) |  |  |
|  |  +-------------------------+  +--------------------+  +------------------+  |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+
                                         |
+-----------------------------------------------------------------------------------+
|                             STORAGE & SECURITY LAYER                              |
|  +-----------------------------------------------------------------------------+  |
|  | SQLCipher Encrypted SQLite Database (AES-256 local health logs & baselines) |  |
|  | Android Keystore / iOS Keychain (Secure Cryptographic Key Management)       |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+
                                         |
+-----------------------------------------------------------------------------------+
|                           HARDWARE & SENSOR INGESTION LAYER                       |
|  +-----------------------+  +------------------------+  +----------------------+  |
|  | BLE Wearable Node     |  | Smartphone IMU         |  | External Env BLE Pod |  |
|  | (HR, SpO2, Temp, Acc) |  | (Internal Sensors)     |  | (Temp, Hum, AQI)     |  |
|  +-----------------------+  +------------------------+  +----------------------+  |
+-----------------------------------------------------------------------------------+

Detailed Step-by-Step Data Flow Narrative

  1. Biosignal Acquisition: The wearable sensor node samples PPG (100 Hz), skin temperature (1 Hz), and IMU acceleration (50 Hz). Data is framed into binary BLE GATT packets [INFERENCE].
  2. Local Ingestion & Preprocessing: The mobile Companion App receives BLE packets in the background via Android ForegroundService. Signals pass through a Digital Bandpass Filter (0.5 Hz – 4 Hz) to strip motion artifacts [INFERENCE].
  3. On-Device Feature Extraction: Sliding temporal windows (e.g., 30-second frames) extract physiological features: Heart Rate ($\text{HR}$), RMSSD / SDNN (Heart Rate Variability), Physical Activity Index, and Skin Temperature slope [INFERENCE].
  4. On-Device AI Inference:
    • Anomaly Detector: The extracted feature vector is fed into an on-device 1D Convolutional Autoencoder (quantized INT8 ONNX model running on ONNX Runtime Mobile) [INFERENCE]. If Reconstruction Error exceeds dynamic baseline threshold $\theta_{\text{baseline}}$, an Anomaly Alert is flagged [INFERENCE].
    • Heat Strain Evaluator: Combines Skin Temperature, elevated Heart Rate, and local Ambient WBGT/Heat Index to compute the Physiological Strain Index (PSI) ranging from 0 (No Stress) to 10 (Extreme Danger) [RESEARCHED].
    • Fall / Distress Classifier: High-G accelerometer impact followed by orientation shift triggers an on-device Fall Classifier [INFERENCE].
  5. Local Rule Matrix & Action Trigger: If PSI $> 7.5$ or Anomaly Score is severe, the app executes local alerts: triggers haptic vibration, vocalizes localized instructions ("Drink water immediately and move to shade"), and logs the event to SQLCipher [INFERENCE].
  6. Offline Emergency Dispatch: If a fall or unacknowledged acute distress is detected, a 15-second visual/audio countdown is initiated [INFERENCE]. If user fails to cancel, the system dispatches an SMS SOS containing last known GPS coordinates to pre-configured emergency contacts via native Telephony SMS Manager (requiring zero cellular data) [INFERENCE].

12. Technology Stack

Layer Selected Technology Why Selected Alternative Considered Why Alternative Rejected
Hardware Wearable Node ESP32-S3 / Nordic nRF52840 + MAX30102 + MPU6050 + NTC Thermistor Built-in BLE 5.0, low power consumption, extensive C++ driver support, highly affordable for prototyping [INFERENCE]. Arduino Uno + Bluetooth HC-05 No native BLE support, bulky, excessive power consumption [INFERENCE].
Mobile Application Framework Flutter (Dart) Single codebase for Android/iOS, high-performance UI components, native BLE/SQLite platform channels [INFERENCE]. React Native Slower bridge performance for real-time high-frequency sensor streams [INFERENCE].
On-Device AI Engine ONNX Runtime Mobile / TensorFlow Lite Native execution on Android CPU/GPU/NPU, zero cloud dependence, supports quantized INT8 models [INFERENCE]. PyTorch Mobile Heavier runtime binary footprint, higher cold-start overhead [INFERENCE].
Model Optimization Ecosystem Qualcomm AI Hub / Edge Impulse Pre-optimized models and automated quantization pipelines specifically targeted at Snapdragon SoCs [RESEARCHED]. Bare PyTorch / TensorFlow Lack of SoC-specific hardware acceleration optimizations [INFERENCE].
Local Database SQLite with SQLCipher (AES-256) Zero-configuration local relational DB, full offline capabilities, hardware-accelerated encryption [INFERENCE]. Realm / Firebase Firestore Firestore fails offline without sync; Realm adds unnecessary payload size [INFERENCE].
External Environmental Data API OpenAQ v3 API & Open-Meteo API Free, open-access public APIs with reliable coverage for Indian weather and CPCB air quality stations [RESEARCHED]. IQAir Commercial API Requires expensive paid subscription keys; unsuitable for hackathon/open-source [INFERENCE].

13. AI/ML Justification

1. Physiological Anomaly & Baseline Drift Detector

  • Purpose: Detect subtle cardiovascular or autonomic health anomalies that diverge from user's rolling 7-day personal baseline [PS].
  • Model Type: Quantized 1D-Convolutional Autoencoder (Unsupervised Anomaly Detection) [INFERENCE].
  • Input Features: 30-sec feature vector: $[\text{Mean HR}, \text{SDNN}, \text{RMSSD}, \text{Min HR}, \text{Max HR}, \text{Skin Temp}, \text{Activity Count}]$ [INFERENCE].
  • Output: Anomaly Reconstruction Error Score ($0.0 - 1.0$) + Categorical Flag (Normal, Mild Anomaly, Severe Anomaly) [INFERENCE].
  • Data Required: Unlabeled continuous PPG/HR time-series (e.g., PPG-DaLiA dataset [RESEARCHED] or baseline personal tracking).
  • Why AI is Preferable: Static heart rate thresholds (e.g., $\text{HR} > 100\text{ bpm}$) generate massive false positives during exercise and miss subtle baseline shifts in resting HR or HRV caused by onset fever or heat exhaustion [INFERENCE].
  • Evaluation Metric: Mean Absolute Error (MAE) on baseline reconstruction; Precision-Recall AUC on anomaly benchmarks [INFERENCE].
  • Failure Mode & Risk: False positive alerts causing user anxiety; false negative missing early illness [INFERENCE].
  • Human Oversight: User can dismiss false warnings or mark "I was exercising", updating baseline calibration [INFERENCE].

2. Heat Stress & Dehydration Risk Evaluator

  • Purpose: Estimate physiological heat strain and dehydration risk during heatwaves [PS].
  • Model Type: Hybrid Physiological Strain Index (PSI) Formula + Gradient Boosted Decision Tree (LightGBM ONNX export) [RESEARCHED].
  • Input: $[\text{Core Temp Proxy (from Skin Temp + HR)}, \text{HR Strain}, \text{Ambient Temp}, \text{Humidity}, \text{Exposure Duration}, \text{Hydration Interval}]$ [RESEARCHED].
  • Output: Heat Stress Risk Index ($0 - 10$) & Estimated Safe Exposure Time Remaining (minutes) [RESEARCHED].
  • Data Required: WBGT parameters and physiological heat exposure datasets [RESEARCHED].
  • Why AI is Preferable: Human thermoregulation is highly non-linear; combining external weather with real-time internal heart rate elevation requires multi-variable non-linear regression [RESEARCHED].
  • Evaluation: Correlation ($R^2$) with standard WBGT index and physiological heat strain scores [RESEARCHED].
  • Failure Mode: Underestimating heat strain in high humidity [INFERENCE].
  • Human Oversight: Prompt user to verify physical signs (dry mouth, dizziness) before escalating warnings [INFERENCE].

3. Fall & Sudden Medical Distress Classifier

  • Purpose: Automatically recognize fall impacts or sudden loss of consciousness [PS].
  • Model Type: Lightweight Random Forest / 1D-CNN [INFERENCE].
  • Input: 3-axis Accelerometer + Gyroscope time series (3-second window at 50 Hz) [INFERENCE].
  • Output: Event Probability: $[\text{Normal Activity}, \text{Fall Detected}, \text{Sudden Impact}]$ [INFERENCE].
  • Data Required: MobiAct or similar public fall datasets [RESEARCHED].
  • Why AI is Preferable: Simple acceleration thresholding triggers false alarms when dropping a phone or jumping; ML temporal feature matching distinguishes true human fall dynamics [INFERENCE].
  • Evaluation: Sensitivity ($> 95%$), Specificity ($> 98%$) [INFERENCE].
  • Failure Mode: Soft falls onto bedding missed; dropping device triggers false alarm [INFERENCE].
  • Human Oversight: Mandatory 15-second audio/visual alert countdown with large "CANCEL" button before dispatching SMS [INFERENCE].

Explicit Identification: Where AI Should NOT Be Used

  • AQI & Weather Index Thresholding: Converting PM2.5 concentrations to CPCB AQI categories (Good, Satisfactory, Moderate, Poor, Severe) MUST use standard deterministic lookup tables provided by CPCB guidelines [RESEARCHED]. Using AI for deterministic mathematical formulas introduces unnecessary error and explainability loss [INFERENCE].
  • SOS SMS Dispatch: Sending emergency SMS notifications must be governed by explicit rule-based state machines, never by probabilistic AI inference [INFERENCE].

14. Data Architecture & Offline/Low-Network Design

Database Schema (Local SQLCipher SQLite)

-- User Profile & Personal Baseline Configuration
CREATE TABLE user_profile (
    user_id TEXT PRIMARY KEY,
    age INTEGER NOT NULL,
    gender TEXT,
    chronic_conditions TEXT, -- Encrypted JSON string
    emergency_contact_1 TEXT NOT NULL,
    emergency_contact_2 TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Continuous Physiological Telemetry Log
CREATE TABLE physiological_logs (
    log_id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp INTEGER NOT NULL, -- Unix Epoch (ms)
    heart_rate REAL,
    spo2 REAL,
    skin_temp REAL,
    activity_count INTEGER,
    hrv_rmssd REAL,
    sync_status INTEGER DEFAULT 0 -- 0: Local Only, 1: Anonymized Sync
);

-- On-Device AI Anomaly & Alert Log
CREATE TABLE anomaly_alerts (
    alert_id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp INTEGER NOT NULL,
    alert_type TEXT NOT NULL, -- 'HEAT_STRESS', 'HR_ANOMALY', 'FALL', 'AQI_HAZARD'
    severity_level TEXT NOT NULL, -- 'LOW', 'MEDIUM', 'HIGH', 'CRITICAL'
    psi_score REAL,
    raw_snapshot_json TEXT, -- Encrypted context snapshot
    user_acknowledged INTEGER DEFAULT 0
);

-- Offline Cached Environmental Risk Grid
CREATE TABLE offline_env_cache (
    grid_id TEXT PRIMARY KEY, -- Geohash-5 (approx 5km x 5km)
    last_updated INTEGER NOT NULL,
    temp_c REAL,
    humidity REAL,
    pm25 REAL,
    aqi_category TEXT,
    disaster_advisory TEXT
);

Offline & Low-Network Strategies

  1. Local Storage First: All sensor data is written directly to local encrypted SQLite [PS].
  2. Geohash Regional Environmental Caching: When internet IS available, the app pre-fetches and caches 7-day weather/AQI forecast matrices for the user's current district bounded by Geohash keys [INFERENCE].
  3. Resilient SMS Emergency Fallback: When internet/cellular data is down during floods or cyclones, the app switches to standard 2G GSM SMS protocol to broadcast compact emergency SOS coordinates [INFERENCE].
  4. Bandwidth Reduction: If opt-in anonymized public health telemetry sync is enabled, data is compressed using Protocol Buffers (protobuf) and transmitted only during Wi-Fi connection [INFERENCE].

15. Security, Privacy & Governance

  1. On-Device Data Sovereignty: Raw biosignals, health histories, and location coordinates are stored locally on the user's handset [PS]. No raw personal health data is uploaded to cloud servers [PS].
  2. Encryption Standards:
    • At Rest: Database encrypted using AES-256 via SQLCipher [INFERENCE]. Encryption keys are generated on-device and stored in Android Keystore / iOS Keychain [INFERENCE].
    • In Transit (Optional Sync): Anonymized, aggregated public health indicators use TLS 1.3 with Certificate Pinning [INFERENCE].
  3. Location Privacy: GPS location is accessed locally ONLY to index offline weather/hazard grids or format SOS SMS emergency messages [PS]. Location tracks are never logged permanently [INFERENCE].
  4. User Consent & Data Control: Clear permission toggles for location access, emergency contact dispatch, and anonymized research contribution [PS].
  5. Regulatory Disclaimer: The application is explicitly designated as a "Personal Health Companion and Early Warning Prototype", NOT a medical device certified by CDSCO (Central Drugs Standard Control Organisation) or FDA [INFERENCE]. Medical emergencies require professional clinical consultation [INFERENCE].

16. MVP Scope (Hackathon Build)

===============================================================================
                           HACKATHON MVP SCOPE MATRIX
===============================================================================

      [MUST BUILD]                       [SHOULD BUILD]             [NICE TO HAVE]
  (Core Hackathon MVP)              (High Value Addons)        (Future Capabilities)
+------------------------+        +----------------------+   +-----------------------+
| • On-Device BLE Ingest |        | • Vernacular Voice   |   | • LoRa Mesh SOS Sync  |
|   (HR, SpO2, Temp, Acc)|        |   Alert System       |   | • Custom Hardware PCB |
| • On-Device Anomaly    |        | • Offline Geohash    |   | • Direct Healthcare   |
|   ML Model (ONNX)      |        |   Weather Cache      |   |   EHR/ABDM Integration|
| • Heat Strain (PSI)    |        | • PDF Health Trend   |   |                       |
|   Calculator Engine    |        |   Export Tool        |   |                       |
| • Offline SMS SOS      |        |                      |   |                       |
|   Emergency Dispatcher |        |                      |   |                       |
| • Encrypted SQLite DB  |        |                      |   |                       |
| • Wellness Dashboard UI|        |                      |   |                       |
+------------------------+        +----------------------+   +-----------------------+

Out of Scope / Do Not Build During Hackathon

  • Full ABDM (Ayushman Bharat Digital Mission) cloud EHR synchronization [INFERENCE].
  • Custom silicon ASIC design or mass production manufacturing [INFERENCE].
  • Multi-node LoRa mesh radio hardware relay networks [INFERENCE].

17. Live Demo Simulation Plan

To ensure a seamless, reliable demonstration during SIH judging without depending on unpredictable live weather conditions or real emergency triggers:

1. Multi-Mode Data Ingestion Architecture

  • Mode A (Live Hardware Wearable): ESP32 BLE Sensor Node transmitting real-time heart rate and skin temperature from a team member [INFERENCE].
  • Mode B (Interactive Disaster Simulator): A hidden Developer Control Panel in the mobile app that allows the team to inject pre-recorded physiological and environmental disaster scenarios [INFERENCE]:
    • Scenario 1: Acute Heatwave Exposure: Simulates rising ambient temperature ($43^\circ\text{C}$), rising skin temp ($38.8^\circ\text{C}$), sustained tachycardia ($125\text{ bpm}$), triggering real-time PSI warning and hydration speech alert [INFERENCE].
    • Scenario 2: Severe Air Pollution Event: Injects severe PM2.5 readings ($350,\mu\text{g/m}^3$), correlating with high-risk respiratory profile to recommend immediate indoor isolation [INFERENCE].
    • Scenario 3: Fall / Unconsciousness Event: Physical drop of phone/wearable triggering instant fall impact detection, 15-second warning beep, and generation of SMS SOS payload with GPS coordinates [INFERENCE].

2. Demo Protocol & Transparency

  • Clearly disclose to judges when switching between Live Sensor Mode and Interactive Simulation Mode [INFERENCE].
  • Display on-device latency metrics (e.g., "Inference Time: 14 ms on Snapdragon NPU") to prove real-time edge processing [INFERENCE].

18. Implementation Roadmap

Phase 1: Requirement Analysis & Environment Setup (Weeks 1–2)

  • Finalize BLE GATT protocol specs for ESP32 hardware node [INFERENCE].
  • Set up Flutter mobile project and ONNX Runtime Mobile integration [INFERENCE].
  • Download open-source PPG datasets (PPG-DaLiA [RESEARCHED], WESAD [RESEARCHED], MobiAct [RESEARCHED]).

Phase 2: Edge ML Model Development & Quantization (Weeks 3–5)

  • Train 1D-CNN Autoencoder for PPG anomaly detection in PyTorch [INFERENCE].
  • Quantize model to INT8 ONNX format using Qualcomm AI Hub / ONNX tools [RESEARCHED].
  • Implement Physiological Strain Index (PSI) and CPCB AQI lookup modules [RESEARCHED].

Phase 3: Hardware Firmware & Mobile Ingestion (Weeks 6–8)

  • Program ESP32-S3 firmware in C++ (Arduino/ESP-IDF) for MAX30102 and temperature sensors [INFERENCE].
  • Build background BLE scanner and SQLCipher local database in Flutter [INFERENCE].

Phase 4: UI/UX & Emergency Dispatch Workflow (Weeks 9–11)

  • Build Flutter UI (Wellness Dashboard, Hazard Alert Cards, Anomaly Charts) [INFERENCE].
  • Implement native Telephony SMS SOS dispatcher and 15-second countdown safety UI [INFERENCE].

Phase 5: Testing, Validation & Demo Polish (Weeks 12–14)

  • Conduct offline stress testing (Airplane Mode enforcement) [INFERENCE].
  • Prepare Developer Simulator Panel for SIH judging demo [INFERENCE].
  • Final Milestone Target: September 30, 2026 [PS].

19. Testing & Validation Plan

  1. Functional Testing: Verify all sensor streams (HR, $\text{SpO}_2$, Temp, IMU) accurately populate local SQLCipher tables without dropping frames during 24-hour background execution [INFERENCE].
  2. On-Device AI Accuracy Testing: Evaluate 1D-CNN Anomaly Autoencoder against holdout test sets from PPG-DaLiA [RESEARCHED]. Target: $> 90%$ AUC-ROC for anomaly detection with $< 15\text{ ms}$ inference latency on mobile CPU [INFERENCE].
  3. False Positive / Negative Testing: Test fall classifier across 100 non-fall vigorous movements (jumping, running, dropping phone on desk) to enforce false positive rate $< 2%$ [INFERENCE].
  4. Offline Resilience Testing: Place smartphone in complete Airplane Mode (cellular data, Wi-Fi disabled). Verify that local anomaly detection, heat index scoring, and local hazard alerts function with zero errors [INFERENCE].
  5. Security & Cryptographic Audit: Verify local SQLite database file cannot be read using standard text tools without SQLCipher encryption key [INFERENCE].

20. Risk Register

Risk Likelihood Impact Severity Mitigation Strategy
Motion Artifact Signal Noise in PPG Sensors High High High Apply digital bandpass filtering (0.5–4 Hz) and accelerometer-guided motion artifact cancellation algorithms [RESEARCHED].
High Battery Consumption from Continuous BLE & Inference High Medium High Duty-cycle sensor sampling (e.g., sample PPG for 30s every 3 mins) and trigger edge AI inference on window batch completion [INFERENCE].
False Emergency Alerts (False Positive Falls) Medium High High Implement mandatory 15-second interactive countdown timer with audio alert before sending SOS SMS [INFERENCE].
Zero Cellular Coverage during Severe Disaster Medium High High Fall back to standard GSM SMS channels; queue alert to automatically retry as soon as network ping succeeds [INFERENCE].
Judge Skepticism of Simulated Data Streams Medium Medium Medium Provide real-time switch between live team member sensor stream and developer simulator panel with full transparency [INFERENCE].

21. Cost & Scalability

Hackathon Phase

  • Hardware Prototyping: $1\times \text{ESP32-S3 microcontroller board} + \text{MAX30102 sensor} + \text{MPU6050} + \text{battery} \approx $20 - $30\text{ USD}$ ($\sim \text{₹1,800 - ₹2,500 INR}$) [ASSUMPTION].
  • Software Tools: 100% Open Source (Flutter, Dart, ONNX Runtime Mobile, SQLite, OpenAQ API, Open-Meteo API) [KNOWN].
  • Cloud Infrastructure Cost: $$0$ (Pure Edge Architecture) [INFERENCE].

Production Deployment Phase

  • Unit Cost at Scale ($10,000+$ units): Custom integrated smart wristband PCB estimated at $$8 - $12\text{ USD}$ per unit [ASSUMPTION].
  • App Distribution: Free Google Play Store / Apple App Store download [KNOWN].
  • Server Overhead: Minimal server maintenance required ($<$100/\text{month}$) because server compute overhead is zero due to on-device edge AI execution [INFERENCE].

22. Differentiation

Evaluated Dimension Generic SIH Submissions Proposed Personal Health Companion Architecture
Inference Location Reliance on cloud APIs (Firebase, AWS, OpenAI REST APIs) [INFERENCE]. 100% On-Device Local Edge AI (ONNX Runtime / Qualcomm AI Hub) [PS].
Disaster Resilience Fails completely during network outages [INFERENCE]. Autonomous offline operation; offline geohash weather grid cache & SMS SOS fallback [PS].
Privacy Protection Uploads sensitive physiological metrics to cloud servers [INFERENCE]. Zero-Cloud-Inference policy; local AES-256 SQLCipher encrypted database [PS].
Context Integration Tracks isolated health metrics or general weather only [INFERENCE]. Fusion Engine combining personal physiological strain (PSI) with environmental hazards (AQI, Heat Index) [PS].

23. Future Scope

  1. LoRa Mesh SOS Networking: Integrate low-cost LoRa radio chips into the wearable node to allow peer-to-peer off-grid emergency SOS message hopping across 5–10 km in flooded zones [INFERENCE].
  2. Ayushman Bharat Digital Mission (ABDM) Integration: Implement health data export standards (FHIR profiles) to allow seamless sharing of local health summaries with verified healthcare providers [RESEARCHED].
  3. Advanced Qualcomm AI Hub Acceleration: Further optimize multi-modal sensor fusion transformers on Qualcomm Snapdragon NPU platforms [RESEARCHED].

24. Assumptions & Open Items Log

Consolidated [ASSUMPTION] Log

  1. [ASSUMPTION] Prototyping cost for a custom ESP32 BLE wearable node is estimated between ₹1,800 and ₹2,500 INR.
  2. [ASSUMPTION] Target user smartphones run Android 8.0 or higher with BLE 4.2+ support.
  3. [ASSUMPTION] Simulated physiological disaster sequences accurately represent severe hyperthermia and hypoxia dynamics for demonstration purposes.

Consolidated [NEEDS VALIDATION] Log

  1. [NEEDS VALIDATION] Precise mathematical correlation transfer function between wrist skin temperature and core internal body temperature under direct sunlight exposure.
  2. [NEEDS VALIDATION] Exact battery drain rates across varying budget Android handsets under continuous background BLE polling.
  3. [NEEDS VALIDATION] Regional cellular carrier SMS delivery latency during peak network congestion in disaster-affected districts.

Final Recommendation

Build Approach 3 (Hybrid Mobile Companion App + BLE Edge Wearable Node). This strategy delivers a working hardware prototype while maintaining software stability and demonstrating privacy-preserving edge AI capabilities [INFERENCE].

Recommended Stack

  • Hardware Wearable: ESP32-S3 + MAX30102 + MPU6050 + NTC Thermistor [INFERENCE].
  • Mobile App: Flutter (Dart) with Native Android Foreground Service [INFERENCE].
  • On-Device AI: ONNX Runtime Mobile executing quantized 1D-CNN models [INFERENCE].
  • Database: SQLite + SQLCipher (AES-256) [INFERENCE].

Biggest Dependency

Stable BLE 5.0 connection between the smartphone and the wearable sensor node during continuous background tracking [INFERENCE].

Biggest Risk

Motion artifacts corrupting raw PPG signal quality during outdoor manual activity [RESEARCHED].

Biggest Technical Challenge

Quantizing and optimizing the multi-sensor anomaly detection model to run under $15\text{ ms}$ latency with negligible background power consumption on entry-level Android handsets [INFERENCE].

First 5 Actions

  1. Set up Flutter project repo and integrate onnxruntime_lite and sqflite_sqlcipher packages [INFERENCE].
  2. Flash ESP32-S3 with C++ BLE GATT code broadcasting synthetic HR, $\text{SpO}_2$, and skin temperature packets [INFERENCE].
  3. Download the PPG-DaLiA dataset [RESEARCHED] and train a baseline 1D-CNN Autoencoder in PyTorch [INFERENCE].
  4. Export and quantize the trained PyTorch autoencoder model to INT8 ONNX format [RESEARCHED].
  5. Implement the Developer Control Simulator Panel in Flutter for interactive SIH demo testing [INFERENCE].

Validation Before Coding

  • Verify BLE data packet receipt in Flutter app background service [INFERENCE].
  • Verify ONNX model execution and inference timing on a physical Android device [INFERENCE].

Buildability Score

92 / 100 (Highly feasible for a skilled 4-6 student team within the timeframe using open-source tools and off-the-shelf components) [INFERENCE].

Confidence

High (Supported by official SIH problem requirements [PS], published physiological datasets [RESEARCHED], and verified Qualcomm AI Hub / ONNX edge frameworks [RESEARCHED]).

Research Sources

  1. Multi-Sensor IoT Architecture & Qualcomm AI Hub

    • Title: Multi-Sensor IoT Architecture: Inside the Stack and How to Scale It
    • URL: https://www.qualcomm.com/developer/blog/2026/01/multi-sensor-iot-architecture-inside-stack-how-to-scale [RESEARCHED]
    • Source Type: Official Technology Vendor Documentation
    • Supported Claim: Qualcomm AI Hub and Edge Impulse support on-device sensor fusion and anomaly detection model optimization for Snapdragon edge NPUs.
    • Reliability: High (Official Qualcomm Developer Blog)

  2. PPG-DaLiA Wearable Biosignal Dataset

    • Title: PPG-DaLiA: A Dataset for PPG-based Heart Rate Estimation for Activities of Daily Living
    • URL: https://pmc.ncbi.nlm.nih.gov/articles/PMC12568089/ [RESEARCHED]
    • Source Type: Academic Journal / PubMed Central (PMC)
    • Supported Claim: Open-access dataset providing PPG, accelerometer, and ECG baseline data for motion artifact evaluation and wearable health algorithms.
    • Reliability: High (Peer-reviewed literature)

  3. OpenAQ Global Air Quality API

    • Title: OpenAQ Platform & API Documentation
    • URL: https://openaq.org/ [RESEARCHED]
    • Source Type: Official Open Data Portal
    • Supported Claim: Provides open API access to ground-level PM2.5, PM10, and AQI monitoring data including CPCB stations across India.
    • Reliability: High (Established open environmental data aggregator)

  4. NDMA Heatwave Prevention & Management Guidelines

    • Title: Guidelines on Management of Heat Wave
    • URL: https://agriculture.vikaspedia.in/viewcontent/social-welfare/disaster-management-1/guidelines-on-disaster-management/heat-wave/guidelines-on-management-of-heat-wave [RESEARCHED]
    • Source Type: Indian Government / National Disaster Management Authority (NDMA)
    • Supported Claim: Outlines official definitions, physiological stress thresholds, and public health advisories for extreme heat conditions in India.
    • Reliability: High (Official Indian Government Guidelines)
02 / What our

DEVELOPERS SAY

" 30M+ Google Gemini tokens went into researching, analyzing, and understanding all 233 SIH problem statements to make them easier to explore and solve. "
Satyam Kumar
Satyam Kumar
CEO , Full Stack Developer
" The platform makes SIH problem statements much easier to understand. Having everything from the problem details to the procedure in one place. "
Rishabh Ranjan
Rishabh Ranjan
COO , Content Writer
" Oh, you got ads? Well, we need to make money too! But, you can use our platform to help you win SIH and take home the prize money. "
Himanshu Kumar
Himanshu Kumar
CMO , Product Reviewer
03 / Are You

READY TO
BUILD?

Get in touch if you need help bringing your ideas to life, or simply have an interesting idea you'd like to talk through. I'm always open to a conversation and exploring new possibilities together.

LinkedIn
[email protected]