PuskesmasAI: Finishing an Offline AI Triage App for Rural Indonesia

⚠️ Local-first by design. PuskesmasAI runs entirely on-device — the Next.js frontend (port 3000) and Python Flask backend (port 5000) are started separately on a local machine, with Gemma 4 E4B served via Ollama. There is no hosted demo because the whole point is offline operation: no cloud, no data leaving the device.

To run locally:

# Terminal 1 — Backend

cd backend && pip install -r requirements.txt

ollama run gemma4:e4b

python app.py  # runs on :5000



# Terminal 2 — Frontend

cd frontend && npm install

npm run dev  # runs on :3000

Demo scenario:

Phone in airplane mode → open PuskesmasAI → fill triage: 32-year-old female, symptoms: "fever for 3 days, red spots on skin, nausea" → tap Analyze → result: 🟠 ORANGE with action list and referral note → turn WiFi on → patient record auto-syncs to dashboard.

The Comeback Story

This project originally started as my submission for the Kaggle × Google DeepMind Gemma 4 Good Hackathon (Health & Sciences track, deadline: May 18, 2026). I had the full concept, the README, the architecture diagram, and the backend security layers ready — but I ran out of time before finishing the core data files and frontend components that would make the app actually work.

Before (what existed at the original deadline):

• ✅ Full README with architecture and problem statement


• ✅ Backend Flask app with 6 security layers (JWT, HMAC, rate limiting, CORS, prompt injection guard, privacy-safe logging)


• ✅ Frontend structure with Next.js PWA config


• ✅ TriageResult.tsx, OfflineBanner.tsx, VoiceInput.tsx components


• ❌ No medical_kb.json — the AI had no medical knowledge base


• ❌ No symptom_map.json — no symptom-to-condition mapping


• ❌ No drug_reference.json — no drug dosage reference for kaders


• ❌ No SymptomForm.tsx — the main input form was missing


• ❌ No db.ts / sync.ts — offline storage and sync not implemented

After (what was added during the Finish-Up-A-Thon):

• ✅ backend/data/medical_kb.json — offline medical knowledge base covering the 10 most prevalent diseases in rural Indonesia (Dengue/DBD, Typhoid, Malaria, ARI/ISPA, Diarrhea, Hypertension, Tuberculosis, Malnutrition, Cholera, Pre-eclampsia) with symptoms, red flags, triage levels, and actions — all in Bahasa Indonesia


• ✅ backend/data/symptom_map.json — 32 symptom groups with Indonesian colloquial keywords, probability weights, and automatic triage escalation rules


• ✅ backend/data/drug_reference.json — 10 essential Puskesmas drugs with pediatric dosing per kg body weight, contraindications, and kader-safe drug classification based on Indonesia's National Formulary (Formularium Nasional)


• ✅ frontend/src/components/SymptomForm.tsx — mobile-first patient intake form with symptom shortcut buttons, automatic pregnancy detection, temperature indicator, and form validation


• ✅ frontend/src/lib/db.ts — IndexedDB wrapper using Dexie.js for offline patient record storage


• ✅ frontend/src/lib/sync.ts — auto-sync module that uploads pending records to Turso cloud when connectivity returns

The transformation: from a well-documented skeleton to a genuinely functional offline AI triage tool.

My Experience with GitHub Copilot

GitHub Copilot was central to finishing this project — especially for the data-heavy and boilerplate-heavy files that would have taken hours to write manually.

symptom_map.json and drug_reference.json were generated entirely using GitHub Copilot in the github.dev editor — no local setup needed. I simply pressed . on the repository page to open github.dev, then used Ctrl+I to invoke inline prompts. I provided the full file path, the data structure requirements, and domain-specific context (Indonesian rural health context, Formularium Nasional constraints). The results were accurate, well-structured, and included details I hadn't explicitly specified — like colloquial Bahasa Indonesia symptom terms ("step" for kejang/seizure, "ngos-ngosan" for rapid breathing) and the appropriate kader-safe drug classification tiers.

db.ts and sync.ts were scaffolded by Copilot with idiomatic TypeScript and Dexie.js patterns that matched the existing codebase — including the synced boolean field for tracking upload status and the navigator.onLine check in the sync logic. What would have been an hour of boilerplate became a focused 10-minute review and refinement session.

What I learned: Copilot works best when you give it full context — the exact file path in the repo, the purpose of the file, the related files it should be aware of, and the domain-specific constraints. A well-crafted prompt saved me hours on each file.

"The best AI is not the most complex one. It's the one that works for the people who need it most — even when the internet doesn't."