Anganwadi Child Growth Monitoring & Immunisation Due-List App for ICDS Field Work (Java, Room, MVVM)

Anganwadi Growth Monitor (AGM) is an offline-first Android app, written in Java with Room and MVVM, that helps an anganwadi worker do two jobs properly: monthly growth monitoring of children under six, and follow-up of the immunisation due list. In an Integrated Child Development Services (ICDS) project area, the worker weighs dozens of children every month, plots growth by hand in the MCP card, and must spot children slipping into moderate or severe underweight. Readings that live in a paper register mean a child who missed three weighings is noticed late, and the supervisor's monthly report is compiled from memory.

AGM registers each child (name, date of birth, gender, mother's name, centre code — no government ID numbers), records monthly weight, height and optional MUAC, and grades every reading against the WHO Child Growth Standards: it computes the weight-for-age z-score and classifies the child as normal, moderately underweight (−3 to −2 SD) or severely underweight (below −3 SD), with a referral flag. A colour-coded growth chart per child, a catch-up list of children due for measurement and an immunisation due list from the standard schedule complete the picture.

Everything is stored locally in Room (SQLite), so the app works through power cuts and patchy networks; the supervisor can export or import the centre's data as CSV. The z-score engine, Room schema, MVVM flow and WorkManager reminders are each explainable in the viva — exactly what a strong Madras CBCS mini project needs.

An anganwadi worker monitors the growth of 25–40 children under six every month, plus their immunisation status, using a paper register and hand-plotted growth cards. Because each weight must be compared against WHO age-and-gender tables to classify underweight, classification is slow and inconsistent, and a child drifting into severe underweight can be noticed weeks late. Children who miss a weighing are not systematically followed up, immunisation due dates are tracked from memory or wall calendars, and the monthly summary for the ICDS supervisor is compiled by hand from the register.

The problem is to build an offline-first Android app that makes the monthly measurement entry fast and validated, computes the WHO weight-for-age z-score and grade automatically, keeps a growth chart and catch-up list per centre, generates the immunisation due list from the standard schedule, and exports clean CSV summaries for the supervisor — while storing only the minimum personal data and never a government ID number.

Abstract

Growth monitoring is ICDS's core preventive service: a weight trend caught early lets supplementary nutrition and referral act before malnutrition turns severe. In practice the worker records weights in a paper register and a hand-plotted card, classification against WHO standards is mental or lookup-based, and the monthly underweight list for the supervisor is slow and error-prone. This project delivers Anganwadi Growth Monitor (AGM), an offline-first Android app in Java that stores monthly measurements, computes WHO weight-for-age z-scores with the LMS formula, classifies and colour-codes every reading, plots the growth chart and maintains an immunisation due list. It is built with Room on SQLite, MVVM with ViewModel and LiveData, Material Components and WorkManager reminders.

Introduction

I visited an anganwadi centre in an ICDS project area near Chennai (name changed) on a weighing day. She measured 34 children in two hours, wrote each weight in a register and later transcribed it into the MCP card. The classification lines (−2 SD, −3 SD) come from the WHO standards, but applying them means comparing each weight with an age-and-gender table; a tired worker at 4 pm guesses. Children who miss a weighing are found only when the register is reviewed. The Centre's Poshan Tracker is the official platform, but field reality still involves paper first, connectivity gaps and a worker who needs her own simple tool.

Existing system and its limitations

• Paper register and MCP card — transcription errors, lost cards, no backup.
• Manual z-score lookup — slow and wrong under time pressure.
• No automatic catch-up list for children who missed a monthly weighing.
• Immunisation follow-up kept separately, often from a wall calendar.
• Monthly reporting to the supervisor is compiled by hand.

Proposed system

• Child enrolment (name, DOB, gender, mother's name, centre code; no Aadhaar or ID numbers).
• Monthly measurement entry with range validation and a database-enforced one-reading-per-month rule.
• A z-score engine implementing z = ((value ÷ M)^L − 1) ÷ (L × S) from WHO LMS tables bundled as JSON, normal (≥ −2 SD), moderate (−3 to −2) and severe (< −3) underweight, with a referral flag.
• Colour-coded growth chart per child and a centre dashboard (grade counts, missed-weighing list).
• Immunisation due list from the standard schedule (BCG at birth, Pentavalent at 6/10/14 weeks, MR at 9–12 months, boosters at 16–24 months) with WorkManager reminders.
• CSV export/import so the supervisor can consolidate centre data offline.

Feasibility study

• Technical: Java (220C4A) is the programming core of the Madras CBCS BCA syllabus; Room, MVVM and WorkManager are the standard offline-capable Android stack. The LMS computation is a few lines of arithmetic per reading.
• Economic: runs on the worker's existing mid-range Android phone; no server or data plan needed.
• Operational: screens follow the weighing-day sequence — pick child, enter weight, see the grade — so training takes minutes.
• Schedule: six weeks — one study, one design, two build increments, two for testing and the report.

In scope

• One anganwadi centre per installation (25–40 children aged 0–72 months), used by one anganwadi worker on her phone.
• Child enrolment and exit (transfer/out-migration) with history retained.
• Monthly weight, height and optional MUAC entry; automatic WHO weight-for-age grading and referral flags.
• Growth chart, centre dashboard, missed-weighing catch-up list and immunisation due list with local notifications.
• CSV export/import and a correction log for audited edits.

Out of scope (v1)

• Server or cloud sync; the app is deliberately offline-first, with CSV as the interchange format (a sync layer is future scope).
• Height-for-age, weight-for-height and BMI-for-age engines beyond the one table bundled (the engine is written so new tables can be dropped in).
• Clinical diagnosis — the app flags grades; medical confirmation (for example SAM by weight-for-height and MUAC per WHO protocol) stays with the health staff.
• Aadhaar, Ration card or any government ID numbers; also out of scope are photo storage and location tracking.

The project follows an incremental model compressed into six weeks, with a paper prototype of the entry screen validated with a real anganwadi worker before coding. Each increment ends in a runnable build shown to the guide.

Member-wise work split (team of 2). Member 1: requirements study, Room schema and DAOs, enrolment and measurement screens, validation and the correction log. Member 2: LMS table format and z-score engine, grading logic, growth chart, dashboard, immunisation schedule engine and WorkManager reminders. Both wrote the report; the DFD and ER diagram were drawn jointly.

Z-score rule. For a weight W of a child of completed months m and gender g: look up (L, M, S) in the WHO weight-for-age table; z = ((W ÷ M)^L − 1) ÷ (L × S), or z = ln(W ÷ M) ÷ S when L = 0. Grade: normal if z ≥ −2, moderate underweight if −3 ≤ z < −2, severe if z < −3; a missing measurement for the current month puts the child on the catch-up list. Z-scores are rounded to two decimals and stored with the reading so charts and reports never recompute from changed tables.

AGM is a single-process, offline-first Android app arranged in MVVM layers: Activities/Fragments → ViewModels (LiveData) → Repository → Room DAO → SQLite, with two pure-Java services — the z-score engine and the immunisation schedule engine — sitting beside the repository so they can be unit-tested without Android.

Layer diagram

flowchart TD
  UI["Entry screens, chart, dashboard (Fragments)"] --> VM["ViewModels + LiveData"]
  VM --> REP["Repository"]
  REP --> DAO["Room DAOs"]
  DAO --> DB[("SQLite database")]
  REP --> ZS["Z-score engine (WHO LMS tables)"]
  REP --> IMM["Immunisation schedule engine"]
  IMM --> WM["WorkManager reminders"]
  REP --> CSV["CSV exporter / importer"]

ER diagram

erDiagram
  CENTRE ||--|{ CHILD : enrols
  CHILD ||--o{ MEASUREMENT : "is measured"
  CHILD ||--o{ IMMUNISATION_RECORD : "receives"
  APP_USER ||--o{ CORRECTION_LOG : writes

  CENTRE {
    int id PK
    string centre_code UK
    string project_area
    string worker_name
  }
  CHILD {
    int id PK
    int centre_id FK
    string child_code UK
    string full_name
    date dob
    string gender
    string mother_name
    date enrolled_on
    date exited_on
  }
  MEASUREMENT {
    int id PK
    int child_id FK
    string period_month
    decimal weight_kg
    decimal height_cm
    decimal muac_cm
    decimal z_score
    string grade
    boolean flagged
  }
  IMMUNISATION_RECORD {
    int id PK
    int child_id FK
    string vaccine
    string dose_label
    date given_on
    string source
  }
  APP_USER {
    int id PK
    string role
    string pin_hash
  }
  CORRECTION_LOG {
    int id PK
    int user_id FK
    string entity
    string old_value
    string new_value
    datetime created_at
  }

Design decisions worth defending in the viva. MEASUREMENT is separate from CHILD because one child accrues up to 72 monthly readings, and the chart is a query over that history. The unique index on (child_id, period_month) enforces the one-reading-per-month rule in the database. The z-score and grade are stored on the measurement row — computed once with the bundled WHO tables — so later table updates cannot silently rewrite history, mirroring how immunisation records freeze what was actually given. The immunisation due list is computed, not stored: doses are derived from DOB against a schedule JSON, so only what was administered is inserted (IMMUNISATION_RECORD). WorkManager requests are persisted in SQLite by the library itself, so reminders survive reboots. Passwords (worker PIN) are hashed with PBKDF2 via Android Keystore-backed salt, and all screens behind the PIN enforce a query scope limited to the installed centre.

• Sync layer to a district server (or an export-compatible integration with the government's Poshan Tracker workflow) with conflict-free merge by child and month.
• Height-for-age and weight-for-height engines plus BMI-for-age by bundling the remaining WHO tables — the engine already takes any LMS table.
• MUAC grading (colour bands per WHO cutoffs) with the referral protocol printed on screen.
• Multi-centre mode for supervisors with consolidated dashboards across centres.
• Tamil/Malayalam localisation and voice prompts for low-literacy use.
• Growth-alert analytics: children crossing two grade lines in three months, flagged automatically for the supervisor's visit.