DEV Community: Labish Bardiya

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.