About SwasthSathi

Early screening for the people the health system

A free diabetes and hypertension screening tool built by four Computer Engineering students at LDRP-ITR, Gandhinagar. It scores risk against published clinical thresholds, works without an internet connection, and speaks four Indian languages.

The principle: deterministic rules for anything clinical, models only where the output can be checked afterwards.
Our mission

Close the gap between risk and awareness

In India, most people meet their diabetes or hypertension for the first time in a hospital, years after it began. By then the inexpensive interventions — diet, movement, an early prescription — have been overtaken by the expensive ones.

The gap is not medical knowledge. The thresholds that define risk have been published for decades. The gap is that a person in a village has no free, private, five-minute way to check themselves against those thresholds in a language they read. That gap is what SwasthSathi fills, and nothing more.

Send people to doctors sooner. Never stand in for one.
The problem

Why screening doesn't happen

Found too late

Both conditions are painless for years. They are usually detected once an organ has already been affected.

Nothing feels wrong

Without a reason to suspect anything, nobody spends a day's wage and a bus fare on a test.

The clinic is far

Distance, transport, lost wages and staff shortages sit between a rural household and a check-up. So do patchy networks.

It is all in English

Reliable material online is written in clinical English, for readers who already know what HbA1c means.

How it was built

Three decisions we had to defend

01

The risk score is not generated by a language model

It is a rule engine over published cut-offs — ADA glycaemic thresholds, WHO and JNC-8 blood pressure stages, Asian-specific BMI and waist limits. Identical answers always produce an identical score, and every point traces to a named threshold. A model producing a plausible-sounding number would have been easier to build and impossible to check.

02

No clinical sentence here was written by an AI

The passages behind the guideline assistant come from WHO material, and every numeric threshold in them is taken directly from the same rule engine the screening uses — so the assistant and the calculator can never disagree.

03

The server does not trust the model's output

Citations the model claims are re-checked against the passages actually retrieved, and anything unverified is dropped. If a response cannot be parsed, the request fails closed rather than degrading into a guess. Medication and dosing questions are refused, and anything reading as an emergency is routed to emergency guidance first.

System at a glance
  • LanguagesEN / HI / GU / MR
  • Risk engineRule-based, on-device
  • Guideline passages31
  • Embedding dimensions768, normalised
  • Edge functions4
  • DB migrations8, idempotent
  • Offline screeningYes
  • Account requiredNo
ES6 modules Bootstrap 5.3 PWA TypeScript · Deno Supabase PostgreSQL · RLS pgvector Cloud Vision

Built under an ImpactThon 2025–26 student grant of ₹10,000, which covered every API and hosting cost of the deployed system.

The team

Team COGNITEX

Computer Engineering students at LDRP-ITR, Kadi Sarva Vishwavidyalaya, Gandhinagar.

Shlok Thakkar

Shlok Thakkar

Tech Lead - Architecture & AI Systems

Risk engine · retrieval pipeline · database & backend · OCR · localisation

  • Owned the end-to-end architecture — client, database schema and all four serverless functions — and set the technical direction the team worked to.
  • Wrote the offline-capable risk engine with tiered assessment and a per-factor breakdown separating modifiable from non-modifiable risk.
  • Designed and shipped the guideline assistant: vector retrieval over a curated corpus, a relevance gate that declines before any model is called, and server-side re-derivation of every citation.
  • Modelled the PostgreSQL schema with row-level security at the database layer and eight sequential idempotent migrations.
  • Built the API cost-control layer — auth before any billable call, per-API rate limits, timeouts and usage logging — keeping the project inside a ₹10,000 grant.
GitHub LinkedIn Email
Dhrupalsinh Solanki

Dhrupalsinh Solanki

App Delivery & Offline Support

Email result delivery · offline install layer

  • Shipped the email result-delivery flow into the production codebase, including the contact form’s spam and rate-limit protections.
  • Shipped the progressive web app layer — service worker registration, offline caching and install manifest — so a screening completes without a network connection.
  • Verified install and offline behaviour on Android and reported the failures fixed before launch.
GitHub LinkedIn Email
Aryan Thakkar

Aryan Thakkar

Product & Requirements Lead

Product Requirements · user walkthroughs

  • Defined requirements for post-screening doctor discovery, including the rule that the platform must never rank or endorse a listed doctor.
  • Reviewed the screening questionnaire for length and comprehension, driving the cut to a five-minute flow.
  • Ran walkthroughs with first-time users and reported the confusion points that changed the result page wording.
GitHub LinkedIn Email
Akshay Somani

Akshay Somani

Localisation & QA

Language review · device testing

  • Reviewed Hindi and Gujarati interface copy for readability and flagged translations that read as clinical rather than plain language.
  • Tested the screening flow on low-end Android devices and reported layout and input problems.
  • Gathered feedback on the lifestyle guidance so food and activity examples matched what people locally recognise.
GitHub LinkedIn Email
Where we draw the line

What we promise

Four commitments we hold the product to, including where it falls short.

Screening, never diagnosis A result tells you whether to get tested. It never tells you what you have.

No AI-written medical text Every clinical statement traces to published guidance. A language model never authored one.

Not clinically validated The engine applies published thresholds correctly, but has not been trialled against patient outcomes. We say so rather than implying otherwise.

A doctor decides Diagnosis and treatment belong to a qualified clinician. This tool exists to get you to one sooner.

If something here is inaccurate, we want to hear it. Write to us.

Find out where you stand

Free, five minutes, no account needed — and it works without a signal.

Start free screening