DEV Community: Labish Bardiya

I Built India's Missing Health App: Here's How I Finished It.

Labish Bardiya — Thu, 04 Jun 2026 10:52:14 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

CureNet — a mobile app that gives every Indian citizen real ownership of their medical records through the government's ABDM (Ayushman Bharat Digital Mission) infrastructure.

The pitch is simple: scan any prescription with your phone camera, and CureNet converts it into a structured, FHIR R4-compliant digital health record — linked to your ABHA (Ayushman Bharat Health Account). No manual data entry. No hospital portals. Just point, scan, own.

It started as a semester project at university. We had 3 weeks. I built the ABDM authentication flow, a basic AI chat, and a records list — then ran out of time. The UI was rough, the scanner didn't work on half the documents, and the "AI assistant" hallucinated medical advice. I submitted what I had, got my grade, and moved on.

Five months later, I opened the repo again.

The code was a graveyard of // TODO comments and hardcoded demo data. But the idea was still good — 1.4 billion people in India have no portable health records. The government built the rails (ABDM), but nobody built a train that regular people would actually ride. So I decided to finish what I started.

What CureNet Does Today

🔐 ABDM-Compliant Auth — Login with Aadhaar, mobile, ABHA number, or ABHA address. Real RSA-OAEP encryption. Real ABDM sandbox integration.
📸 AI Document Scanner — Point your camera at any prescription, lab report, or discharge summary. NVIDIA NIM Vision classifies the document, extracts medications, dosages, lab values, and diagnosis — and packages it all into FHIR R4 bundles.
🤖 ABHAy AI — A medical AI assistant that knows your health context. It reads your scanned records, understands your medications and conditions, and answers questions in your language (all 22 scheduled Indian languages via Bhashini ULCA).
🔒 Health Locker — Biometric-protected vault for your most sensitive records. Fingerprint or Face ID to access.
📊 Health Trends — Biomarker tracking with interactive charts. Watch your HbA1c, blood pressure, or cholesterol trend over time.
🚨 Emergency Digital Pass — One-tap emergency card with your allergies, medications, blood group, and emergency contact. Saveable as an image for your lock screen.
🔑 Consent-Based Sharing — Grant doctors time-limited, scope-limited access to your records via QR code. Revoke anytime.
🌐 Multilingual — Full UI and AI translation across all 22 scheduled Indian languages via Bhashini ULCA.

Tech Stack: Flutter/Dart · Node.js/Express · MongoDB · NVIDIA NIM (Llama 3.2 90B Vision) · FHIR R4 · ABDM Sandbox · Bhashini ULCA · Render

Demo

🔗 GitHub: github.com/labishbardiya/CureNet

🔗 GitHub Release: https://github.com/labishbardiya/CureNet/releases/tag/v2.0.0

📱 APK Download: Download CureNet APK

🖥️ Live Demo: https://youtu.be/QU5zbPB3XJw

🌐 Live Backend: curenet.onrender.com

The Comeback Story

Where It Was (January 2026)

When I paused CureNet in February, here's what "existed":

Feature	Status
ABDM Login	✅ Working (barely) — single auth method, no encryption
AI Chat	⚠️ Basic Groq integration — hallucinated freely, no medical context
Document Scanner	❌ Camera opened but OCR was broken on 60%+ of documents
Health Records	⚠️ Hardcoded demo list — no real persistence
Health Locker	❌ Didn't exist
Emergency Pass	❌ Didn't exist
Multilingual	❌ English only
Consent Sharing	❌ Didn't exist
Health Trends	❌ Didn't exist
Backend	⚠️ Local only — no cloud deployment

The UI looked like a college prototype because it was a college prototype. Text arrows (←) instead of proper icons. Hardcoded names leaking everywhere. print() statements in production code. Deprecated API calls. Unused imports stacked 10-deep in every file.

What Changed (May–June 2026)

I rebuilt CureNet from the ground up — same codebase, completely different app. Here's the arc:

🧠 AI Architecture Overhaul

Migrated from basic Groq completion to a Gold Standard Architecture: NVIDIA NIM for vision OCR → Server-Sent Events for real-time streaming → smart routing across 3 API keys for rate-limit resilience.
ABHAy AI now has full medical context — it reads your uploaded records, knows your medications, and grounds its responses in your actual health data. No more hallucinations about medications you don't take.
Added Bhashini ULCA pipeline real-time translation across all 22 scheduled Indian languages. The AI responds in whatever language you ask in.

📸 Document Scanner Rebuilt

Replaced the broken OCR pipeline with NVIDIA NIM Llama 3.2 90B Vision.
Added intelligent document classification: prescriptions, lab reports, discharge summaries — each parsed differently.
Every scan produces a FHIR R4 Bundle — the international healthcare data standard. Not just text extraction, but structured clinical data.

🏗️ 6 New Features

Health Locker with biometric authentication
Interactive biomarker trends with fl_chart
Emergency Digital Pass (screenshot-saveable)
QR-based consent sharing with time-limited access grants
Access request monitoring with real-time notifications
Profile with editable medical information

💅 Enterprise-Grade Polish

Extracted shared bottom navigation into a reusable CureNetBottomNav widget (eliminated ~210 lines of duplication across 7 screens)
Replaced every print() with debugPrint()
Migrated all deprecated withOpacity() calls to withValues(alpha:)
Removed every unused import, dead method, and orphaned variable
flutter analyze: 0 errors, 0 warnings (only 2 structural infos remain)
Zero hardcoded demo data leaking to live users — all demo content gated behind identity checks
Proper Material icons everywhere (no more text arrow "←" buttons)

☁️ Cloud Deployment

Backend deployed to Render with Nginx SSE buffering fixes
MongoDB Atlas for persistent storage
ABDM Sandbox integration with live RSA-OAEP encryption

By The Numbers

Metric	Before	After
Dart files	~15	57
Lines of code	~3,000	13,654
Screens	5	28
Commits	~20	64
`flutter analyze` warnings	40+	2 (structural only)
Supported languages	1	all 22
Auth methods	1	4
AI models used	1 (Groq)	3 (NIM Vision + Llama 3.3 + Gemma)

My Experience with GitHub Copilot

GitHub Copilot was my constant pair programmer throughout this finish-up. Here's specifically how it helped:

1. Boilerplate Acceleration

Flutter is verbose. Every new screen needs a StatefulWidget, State class, initState, dispose, build method, Scaffold, SafeArea... Copilot autocompleted these structural patterns instantly. For CureNet's 28 screens, that's hours saved on scaffolding alone.

2. FHIR R4 Bundle Generation

Writing FHIR-compliant JSON structures by hand is painful — deeply nested resources with strict field requirements. I'd type createPrescriptionBundle( and Copilot would suggest the entire Bundle structure with proper resourceType, entry arrays, Patient, Practitioner, and MedicationRequest resources. I still had to verify compliance, but the starting point was 90% correct.

3. Dart API Migrations

Flutter's API evolves fast. Copilot caught deprecated patterns I didn't even know about — suggesting withValues(alpha: 0.5) when I typed withOpacity(, flagging activeColor → activeThumbColor on Switch widgets, and recommending mounted guards on async BuildContext usage. It acted like a real-time migration guide.

4. SharedPreferences Patterns

CureNet's offline-first architecture relies heavily on SharedPreferences for record persistence. Copilot learned the project's DataMode.storageKey() namespacing pattern and consistently suggested properly-namespaced keys. When I wrote save logic, it suggested the corresponding load logic with the correct JSON encoding patterns.

5. Copilot Chat for Debugging

When my SSE (Server-Sent Events) streaming broke after deploying to Render, I pasted the Nginx config into Copilot Chat and asked "why is my SSE connection dropping after 30 seconds?" It identified the missing proxy_buffering off directive immediately — a fix that would have taken me hours of Stack Overflow archaeology.

The Honest Take

Copilot didn't write CureNet. But it removed the friction that makes finishing a project so hard. The boring parts — boilerplate, type annotations, JSON parsing, import management — got handled in the background while I focused on the actual hard problems: ABDM cryptography, FHIR compliance, and making an AI assistant that doesn't hallucinate your medication list.

That's exactly what "finishing" needs. Not a magic wand, but a tireless partner that handles the tedium so you can focus on the craft.

CureNet is open for feedback. If you're building in Indian healthtech or working with ABDM, I'd love to connect.

📦 github.com/labishbardiya/CureNet

I built an AI SRE agent that joins GitHub + Sentry + Slack + PagerDuty in one SQL query

Labish Bardiya — Mon, 01 Jun 2026 09:16:10 +0000

The Problem Every Engineer Knows

It's 3am. PagerDuty fires. You're half-asleep, scrambling between tabs:

GitHub: "Which PR went out last?"
Sentry: "What's the stack trace?"
Slack: "Did anyone else notice this?"
PagerDuty: "How long has this been firing?"

You spend 60+ minutes context-switching between tools before you find root cause. The fix itself? 5 minutes.

What if you could find root cause in one query?

Introducing NexusOps

NexusOps is an AI-powered SRE investigator that diagnoses production incidents in seconds. It joins data across GitHub, Sentry, Slack, and PagerDuty in a single SQL query — powered by Coral.

🔗 Live Demo: nexus-ops-seven.vercel.app
📂 Source Code: github.com/labishbardiya/nexus-ops

What is Coral?

Coral is an open-source data retrieval layer that turns any API into a SQL table. Instead of writing custom integrations for each tool, you just write SQL:

SELECT s.title, s.level, g.title as pr_title, g.user__login as author
FROM sentry.issues s
JOIN github.pulls g
  ON g.merged_at >= datetime(s.first_seen, '-24 hours')
  AND g.merged_at <= s.first_seen
WHERE s.level = 'fatal'
ORDER BY s.first_seen DESC

That single query:

Hits GitHub's API for recent PRs
Hits Sentry's API for fatal errors
Correlates them by timestamp
Returns the PR that likely caused each error

No ETL. No data warehouse. No glue code. Coral handles auth, pagination, rate limits, and caching transparently.

Architecture

┌─────────────────────────────────────────────┐
│                  NexusOps                     │
├─────────────────────────────────────────────┤
│  Next.js 15 + TypeScript + Tailwind CSS      │
├─────────────────────────────────────────────┤
│  Groq AI (Natural Language → SQL)             │
├─────────────────────────────────────────────┤
│  Coral CLI (SQL execution layer)             │
├──────────┬──────────┬──────────┬────────────┤
│  GitHub  │  Sentry  │  Slack   │ PagerDuty  │
└──────────┴──────────┴──────────┴────────────┘

How it works:

User asks: "What caused last night's fatal error?"
Groq AI converts the question to a Coral SQL query
Coral executes the query across multiple sources simultaneously
NexusOps renders the results + a Root Cause Timeline + AI explanation

The Root Cause Timeline

This is the feature I'm most proud of. It's an SVG visualization that shows the causal chain across sources:

GitHub:    ●──── PR #342 merged ────────────────────────────
Sentry:         ●── TypeError ──── ●── Redis pool exhausted
PagerDuty:              ●── High urgency alert ─────────────
Slack:                       ●── "seeing errors" ── ●── "rolled back"
           ────────────────────────────────────────────────→ time

The gap between the PR merge and the first error is the blast radius window. You can see causality at a glance instead of mentally correlating timestamps across four different tools.

Key Coral Features Used

1. Cross-Source JOINs

SELECT 'github' as source, g.title as event, g.merged_at as timestamp
FROM github.pulls g
WHERE g.merged_at >= datetime('now', '-48 hours')
UNION ALL
SELECT 'sentry' as source, s.title as event, s.first_seen as timestamp
FROM sentry.issues s
WHERE s.first_seen >= datetime('now', '-48 hours')
UNION ALL
SELECT 'pagerduty' as source, p.title as event, p.created_at as timestamp
FROM pagerduty.incidents p
WHERE p.created_at >= datetime('now', '-48 hours')
ORDER BY timestamp DESC

One query. Four sources. Correlated by time.

2. Schema Learning

Coral automatically discovers the schema of each source. I didn't have to manually map GitHub's API response fields — Coral figured out that github.pulls has columns like number, title, state, user__login, merged_at, etc.

3. 100% Local

All credentials stay on my machine. Data never leaves my laptop. This is huge for enterprise use cases where you can't send production incident data to third-party services.

4. CLI Integration

NexusOps calls coral sql "..." via Node.js child_process. Simple, reliable, no SDK lock-in.

The NL-to-SQL Pipeline

I used Groq with Llama 3.3 70B for the natural language to SQL conversion — it's free, fast (500+ tokens/sec), and excellent at structured SQL generation. The system prompt includes the full Coral schema, and the model generates valid SQL with the right table names, column names, and JOIN conditions.

Example:

Input: "What PRs were merged in the last 24 hours?"
Output: SELECT number, title, user__login, merged_at FROM github.pulls WHERE owner = 'withcoral' AND repo = 'coral' AND merged_at >= datetime('now', '-24 hours') ORDER BY merged_at DESC LIMIT 20

The key insight: SQL is a much better intermediate representation than JSON or function calls for multi-source queries. It's composable, debuggable, and Coral handles the execution.

Tech Stack

Layer	Choice	Why
Frontend	Next.js 15 + Tailwind CSS	Fast, TypeScript-native
AI	Groq (Llama 3.3 70B)	Free, 500+ tokens/sec, great at structured SQL
Data	Coral CLI	Cross-source SQL, local-first
Deploy	Vercel	One-command deployment

What I Learned

SQL is an underrated agent interface. Most AI agent frameworks use function calling or tool chains. SQL is more powerful for data correlation because you get JOINs, aggregations, and filtering for free.
Cross-source correlation is the hard problem. Getting data from one API is easy. Correlating events across four APIs by timestamp, with different time zones and formats, is where the real engineering happens. Coral abstracts this entirely.
Local-first is a feature. For SRE tools that handle production data, sending everything to a cloud service is a non-starter. Coral's local-first architecture isn't a limitation — it's a selling point.
Demo mode is essential. Not everyone has Sentry + PagerDuty + Slack configured. Having realistic mock data lets people experience the product without setup.

Try It Yourself

# Install Coral
brew install withcoral/tap/coral

# Add GitHub source
coral source add github --interactive

# Query live data
coral sql "SELECT number, title, state FROM github.pulls WHERE owner = 'withcoral' AND repo = 'coral' LIMIT 5"

Star Coral on GitHub: github.com/withcoral/coral

[Boost]

Labish Bardiya — Tue, 26 May 2026 08:19:49 +0000

Gemma 4 Challenge: Build With Gemma 4 Submission

Labish Bardiya

May 24

CureNet AI: Decentralized Health Intelligence for India, Powered by Gemma 4 and ABHA Standardization

#devchallenge #gemmachallenge #gemma

4 min read

[Boost]

Labish Bardiya — Mon, 25 May 2026 07:17:10 +0000

Gemma 4 Challenge: Write about Gemma 4 Submission

Labish Bardiya

May 24

When Open-Weights AI Meets a Broken Healthcare System: Deploying Gemma 4 in Rural India

#devchallenge #gemmachallenge #gemma

6 min read

CureNet AI: Decentralized Health Intelligence for India, Powered by Gemma 4 and ABHA Standardization

Labish Bardiya — Sun, 24 May 2026 18:16:51 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

CureNet AI is an ABDM-native, offline-first Health Intelligence platform built to unify fragmented medical records securely under the Ayushman Bharat Digital Mission (ABDM) and FHIR R4 standards.

In rural India, reliable internet is a luxury. Prescriptions are handwritten. Lab reports fade on thermal paper. Patient histories exist as loose sheets in plastic folders. The consequences are measurable:

₹26,037 crore in health insurance claims denied in a single year — ₹15,100 crore disallowed and ₹10,937 crore repudiated — largely due to incomplete documentation (IRDAI Annual Report, FY24)
32% of patients transferred between facilities with incompatible records undergo duplicate diagnostic testing within 12 hours (NIH peer-reviewed study)
47% of India's total health expenditure is paid out-of-pocket by patients — among the highest globally — inflated by repeated tests and fragmented care
~2 minute consultations — overloaded OPDs force doctors to see 100+ patients in hours, leaving no time to reconstruct history from paper records (BMJ Open)
Less than 15% of Indian hospitals have fully digitized medical record systems

CureNet AI solves this by deploying Gemma 4 edge intelligence directly into the local clinic ecosystem — no internet required.

Core Features Shipped

Intelligent Local Ingestion: Camera-based document scanning powered by Gemma 4 31B Dense vision. Prescriptions and lab reports are analyzed directly by Gemma 4's multimodal capabilities — extracting medications, dosages, lab values, vitals, and diagnosis without any cloud dependency.

Structured Medical Parsing: A custom FHIR R4 bundle builder generates ABDM-compliant Document Bundles containing Patient, Practitioner, MedicationRequest, Observation, and DiagnosticReport resources — with SNOMED CT medication codes and LOINC lab test codes. Doctors can instantly verify whether a test was already performed — directly eliminating redundant diagnostics.

Privacy-First Architecture: AES-256-GCM encrypted local database with keys stored in the device's hardware keystore. Custom ABDM crypto module for RSA-OAEP, ECDH X25519, and AES-GCM encrypted data exchange. Full DPDP Act 2023 compliance — when Gemma 4 runs locally, zero patient data leaves the device.

Complete ABDM Integration: Full M1 + M2 + M3 milestone compliance — ABHA creation via Aadhaar and Mobile OTP, care context linking, consent management, and encrypted health data exchange using V3 sandbox APIs.

Offline-First Architecture: Three-tier connectivity probing (Ollama → Backend → Cloud) with automatic fallback. When fully offline, the AI serves responses from locally stored encrypted records. When online, cloud models act purely as fallback.

ABHAy AI Assistant: RAG-augmented health chat running intent classification, web search, clinical atom retrieval, and semantic search all simultaneously — cutting response latency from ~12s to ~4s.

Accessible by Design: High-contrast UI with large tap targets designed for senior citizens and low-literacy users. Full multilingual support across all 22 scheduled languages of India via the Bhashini API, with built-in Text-to-Speech so patients who cannot read can hear their medical information in their own language.

Download App

📱 Download APK (Android) — Install on any Android device. All API keys pre-configured. No setup required.

Demo Video

demo.mov - Google Drive

drive.google.com

Code

👉 GitHub Repository: https://github.com/labishbardiya/CureNet

📦 Download Release APK (v1.0.0) — Ready-to-install Android build with all features enabled.

How I Used Gemma 4

Medical records demand zero leakages and low latency. Gemma 4 acts as the core, private intelligence engine — running entirely locally via Ollama with no patient data ever leaving the device.

We split reasoning between edge and workstation environments using two models:

Gemma 4 E4B (Effective 4B) — On-Device Edge Intelligence

We run Gemma 4 E4B (gemma4:e4b) via Ollama for low-latency tasks on the local machine.

🤔 Why E4B? With its Per-Layer Embeddings (PLE), E4B packs frontier-level logic into a ~3 GB memory footprint. Its 128K context window handles large clinical data logs while running natively offline.

🤔 How it's used? It acts as our first-tier intent classifier — categorizing every user query into MEDICAL_QUERY, GENERAL_CHAT, or APP_HELP in under 2 seconds. This determines whether the full RAG pipeline activates. It also handles chat title generation and serves as an automatic failover when the 31B model is overloaded — ensuring the experience never breaks.

Gemma 4 31B Dense — Medical Extraction & FHIR R4 Conversion

On the clinic workstation backend, we deploy Gemma 4 31B Dense (gemma4:31b) via Ollama for complex clinical intelligence.

🤔 Why 31B Dense? Medical records cannot tolerate routing gaps or hallucination. The Dense architecture processes every token through all 31 billion parameters with a 256K context window — unlike MoE variants that risk dropping clinical context. When a missed medication has patient safety implications, Dense is the correct choice.

🤔 How it's used? Two critical paths. First, it processes prescription and lab report images directly using multimodal vision via a zero-shot structure prompt — extracting patient info, medications with dosage/frequency/duration/route, lab results with values/units/reference ranges, vitals, diagnosis, and follow-up instructions. Indian patterns like 1+0+1 (morning/afternoon/night) are parsed correctly. Brand names like "Crocin" map to their SNOMED CT active ingredient codes. Second, it powers the ABHAy RAG assistant for medical reasoning with full clinical context from the patient's encrypted local records. All outputs feed into our FHIR R4 builder, generating strict ABDM-compliant bundles with SNOMED CT and LOINC coding.

When Open-Weights AI Meets a Broken Healthcare System: Deploying Gemma 4 in Rural India

Labish Bardiya — Sun, 24 May 2026 18:16:28 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

India's healthcare system is hemorrhaging money, time, and trust at an industrial scale.

₹26,037 crore in health insurance claims denied in FY 2023-24 alone — ₹15,100 crore disallowed and ₹10,937 crore repudiated — largely because of incomplete documentation and missing medical history (IRDAI Annual Report)
32% of patients transferred between facilities with incompatible record systems undergo duplicate diagnostic testing within 12 hours, with 20% of those duplicates being clinically unnecessary (NIH peer-reviewed study)
47% of India's total health expenditure is paid out-of-pocket by patients — among the highest rates globally — inflated by repeated tests and fragmented care
~2 minute consultations — overloaded OPDs force doctors to see 100+ patients in hours, leaving no time to reconstruct a patient's history from paper records (BMJ Open)
Less than 15% of Indian hospitals have fully digitized medical record systems
8,600+ cyberattacks per week targeting Indian healthcare institutions — significantly above the global average

These numbers describe a system where the absence of structured, portable, digital health records is not an inconvenience — it is a systemic failure with measurable financial and human cost.

This article documents what happened when we deployed Gemma 4 as the AI backbone of CureNet AI — an offline-first, ABDM-native health intelligence platform built to operate in exactly these conditions.

Why Local Inference Is Not Optional

The conventional approach to AI-powered healthcare is straightforward: send patient data to a cloud API, receive structured output. This fails in India for three reasons.

No internet. Thousands of rural clinics lack reliable connectivity. A cloud-dependent system is a non-functional system in the settings where digitization is needed most.

No legal basis. The Digital Personal Data Protection (DPDP) Act, 2023 mandates free, specific, informed, unconditional, and unambiguous consent before processing personal data. Transmitting sensitive medical records to third-party cloud APIs introduces consent complexities that most health-tech platforms have not addressed.

No security guarantee. The AIIMS Delhi ransomware attack (2022) affected 30-40 million patient records. The Star Health Insurance breach (2024) compromised 31 million records. Centralized medical data is a high-value target.

Gemma 4's open-weights release under Apache 2.0 eliminates all three problems. The model runs locally. The data never leaves the device. There is no third-party processor to consent to.

Demo Video

demo.mov - Google Drive

drive.google.com

Code

👉 GitHub Repository: https://github.com/labishbardiya/CureNet

Choosing Between E4B and 31B Dense

Gemma 4 ships in multiple variants. Selecting the right one for each task was a critical architectural decision in CureNet.

Gemma 4 E4B: The Edge Workhorse

The E4B model (gemma4:e4b) occupies approximately 3 GB in memory. Its Per-Layer Embeddings (PLE) architecture packs frontier-level reasoning into a footprint that can run alongside a Flutter mobile UI without starving the rendering thread.

We use E4B for three tasks:

Task	Latency	Why E4B Works
Intent classification	< 2 seconds	High-frequency — every message triggers this
Chat title generation	< 1 second	Lightweight — no clinical reasoning needed
Rate-limit failover	Automatic	When 31B is overloaded, E4B takes over

The 128K context window is more than sufficient for these tasks. E4B classifies every inbound user message into one of three channels — MEDICAL_QUERY, GENERAL_CHAT, or APP_HELP — which determines whether the full RAG pipeline is activated.

The key insight: E4B is not a compromise model. For classification and short-generation tasks, its accuracy is indistinguishable from the 31B variant at a fraction of the latency and memory cost.

Gemma 4 31B Dense: The Clinical Backbone

The 31B Dense model (gemma4:31b) handles the heavy clinical work. We chose Dense over the 26B MoE variant for a specific reason: medical records cannot tolerate routing gaps.

In a Mixture-of-Experts architecture, each token is routed to a subset of the parameter space. For general-purpose text, this is efficient. For medical entity extraction — where a missed medication name, a misread dosage, or a dropped lab value has direct patient safety implications — we need every token processed through the full parameter grid.

The 31B Dense model serves two critical functions:

Function 1: Multimodal Medical Extraction

The model processes prescription and lab report images directly using a zero-shot structure prompt. No OCR preprocessing is required — Gemma 4's vision capabilities handle the image natively.

The extraction prompt instructs the model to identify the document type and extract every clinical entity into a strict JSON schema:

{
  "medications": [
    {
      "name": "Amoxicillin",
      "dosage": "500mg",
      "frequency": "1+0+1",
      "duration": "5 days",
      "route": "oral"
    }
  ],
  "lab_results": [
    {
      "test_name": "HbA1c",
      "value": "6.8",
      "unit": "%",
      "reference_range": "4.0-5.6"
    }
  ]
}

This output feeds into a FHIR R4 bundle builder that maps each entity to the correct FHIR resource with SNOMED CT and LOINC coding. Indian prescription patterns like 1+0+1 (morning + afternoon + night) are parsed correctly. Brand names like "Crocin" map to active ingredient SNOMED codes (Paracetamol → 387517004).

When a doctor opens a patient's profile, they see a structured timeline of every previous lab test and medication — instantly verifiable before ordering a new test. This is how you address the 32% duplicate testing problem documented in peer-reviewed literature.

Function 2: RAG-Augmented Medical Reasoning

The ABHAy AI assistant uses 31B for complex medical queries. The system runs a parallel pipeline — intent classification via E4B, web search via Tavily, clinical atom retrieval from the encrypted local database, and semantic search via vector embeddings — all execute concurrently.

This parallel architecture cuts end-to-end latency from approximately 12 seconds (sequential) to under 4 seconds. The 256K context window accommodates the full aggregated context without truncation.

The Routing Architecture

The system does not assume Ollama is always available. A connectivity service probes three tiers in parallel on startup:

Tier	Target	Timeout	Purpose
Edge	Ollama (localhost)	2s	Local Gemma 4 inference
LAN	Backend (localhost)	2s	FHIR pipeline
Cloud	Groq API	3s	Fallback AI

Results are cached for 30 seconds. Based on availability, the app operates in one of four modes:

Mode	What Works	Cloud Dependency
Full Edge	All features via Ollama + Backend	None
Edge + Cloud	AI local; ABDM and Bhashini via cloud	Partial
Cloud Only	Groq fallback handles AI	Full
Fully Offline	Serves local encrypted records	None

When Groq is used as fallback, the model mapping is:

Local Model	Cloud Fallback
`gemma4:e4b`	`llama-3.1-8b-instant`
`gemma4:31b`	`llama-3.3-70b-versatile`

The app never crashes due to network state. Every code path handles the offline case gracefully.

Accessibility: Designing for 1.4 Billion People

Healthcare AI that only works in English on modern smartphones is not healthcare AI for India.

CureNet was designed for the patients who need it most — senior citizens, low-literacy users, and non-English speakers in rural settings.

Multilingual support across all 22 scheduled languages of India. Every screen, every label, and every AI response is translated in real-time via the Bhashini Translation API — the government's own language infrastructure covering Hindi, Bengali, Tamil, Telugu, Marathi, Gujarati, Kannada, Malayalam, Odia, Punjabi, Assamese, and all other constitutionally recognized languages.

Built-in Text-to-Speech. For patients who cannot read — or whose eyesight makes reading a phone screen difficult — the Bhashini TTS engine reads medical information aloud in the patient's own language.

High-contrast, large-target UI. The interface uses oversized tap targets, high-contrast color pairs, and clear typographic hierarchy. No small text, no dense layouts, no gestures requiring fine motor control. This is not an aesthetic choice — it is a clinical requirement for a user base where the median patient may be a 60-year-old with presbyopia.

Language persistence. Once a patient selects their language, it persists across sessions. They never need to reconfigure.

DPDP Act 2023: Why This Architecture Is Legally Required

The Digital Personal Data Protection Act, 2023 fundamentally changes the legal landscape for health-tech in India:

Purpose-specific consent — no bundled authorization forms
Data minimization — collect only what is clinically necessary
Right to withdraw — patients can revoke consent at any time
Breach notification — mandatory reporting to the Data Protection Board

CureNet's architecture is inherently compliant because data processing happens locally. When Gemma 4 runs via Ollama, there is no third-party data processor. The patient physically controls their data on their device. Encryption keys live in the hardware keystore. Clinical data is encrypted with AES-256-GCM before touching disk.

Under the DPDP Act, local-first processing is not a feature — it is a legal requirement that most cloud-first health platforms will struggle to meet.

What Open-Weights Models at This Level Mean for Healthcare

Before Gemma 4, deploying a model capable of reliable medical entity extraction required either a cloud API subscription with data governance concerns, or fine-tuning a smaller open model that could not match the quality needed for clinical safety.

Gemma 4 31B Dense changes this equation. A single clinic workstation with 32 GB of RAM can run a model that processes multimodal inputs natively, maintains a 256K context window, produces output reliable enough for FHIR R4 compliance, and runs entirely offline under Apache 2.0.

For healthcare in India — where over 100 crore health records are now linked to ABHA IDs, but the vast majority of clinical encounters still produce paper — this is the infrastructure that makes digitization possible without cloud dependency.

Every handwritten prescription becomes a structured, searchable, ABDM-compliant record. Every duplicate test prevented. Every claim denial avoided. Every patient's data stays on their device, spoken back to them in their own language.

That is what open-weights AI at frontier capability makes possible.

DEV Community: Labish Bardiya

I Built India's Missing Health App: Here's How I Finished It.

What I Built

What CureNet Does Today

Demo

The Comeback Story

Where It Was (January 2026)

What Changed (May–June 2026)

By The Numbers

My Experience with GitHub Copilot

1. Boilerplate Acceleration

2. FHIR R4 Bundle Generation

3. Dart API Migrations

4. SharedPreferences Patterns

5. Copilot Chat for Debugging

The Honest Take

I built an AI SRE agent that joins GitHub + Sentry + Slack + PagerDuty in one SQL query

The Problem Every Engineer Knows

Introducing NexusOps

What is Coral?

Architecture

The Root Cause Timeline

Key Coral Features Used

1. Cross-Source JOINs

2. Schema Learning

3. 100% Local

4. CLI Integration

The NL-to-SQL Pipeline

Tech Stack

What I Learned

Try It Yourself

Links

[Boost]

CureNet AI: Decentralized Health Intelligence for India, Powered by Gemma 4 and ABHA Standardization

[Boost]

When Open-Weights AI Meets a Broken Healthcare System: Deploying Gemma 4 in Rural India

CureNet AI: Decentralized Health Intelligence for India, Powered by Gemma 4 and ABHA Standardization

What I Built

Core Features Shipped

Download App

Demo Video

demo.mov - Google Drive

Code

How I Used Gemma 4

Gemma 4 E4B (Effective 4B) — On-Device Edge Intelligence

Gemma 4 31B Dense — Medical Extraction & FHIR R4 Conversion

When Open-Weights AI Meets a Broken Healthcare System: Deploying Gemma 4 in Rural India

Why Local Inference Is Not Optional

Demo Video

demo.mov - Google Drive

Code

Choosing Between E4B and 31B Dense

Gemma 4 E4B: The Edge Workhorse

Gemma 4 31B Dense: The Clinical Backbone

Function 1: Multimodal Medical Extraction

Function 2: RAG-Augmented Medical Reasoning

The Routing Architecture

Accessibility: Designing for 1.4 Billion People

DPDP Act 2023: Why This Architecture Is Legally Required

What Open-Weights Models at This Level Mean for Healthcare