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

Code

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

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:

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:

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

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

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.