Offline Child Growth Monitoring App for Lady Health Workers with WHO Z-Scores

The problem: growth faltering missed between visits

Child stunting and wasting remain serious problems in Pakistan and much of South Asia. Community health workers, such as Pakistan's Lady Health Workers, visit households and are well placed to spot a child whose growth is faltering. In practice, growth monitoring is often done on paper cards that get lost or are incomplete, plotting points on a chart is slow and error-prone, and a gradual decline across several visits is easy to miss when each visit is looked at on its own. A child is often only referred once they are visibly unwell.

Calculating growth z-scores correctly is not trivial. It needs the WHO reference tables, the right method for each indicator and age, and careful handling of length versus height.

Health workers are also short of time. A worker may visit many households in a day, often in heat, and every extra step in plotting a chart or looking up a table is a step that gets skipped. A tool that does the calculation instantly, remembers previous visits and tells the worker which children need follow-up turns growth monitoring from paperwork into something that changes what happens next for a child.

What already exists and the gap

• WHO Anthro is Windows software for individual assessment and surveys, and the WHO Anthro Survey Analyser analyses survey datasets. Both are for desks, not doorsteps.
• The anthro R package, published by WHO, computes z-scores for the WHO Child Growth Standards and is the reference implementation for analysts.
• General mobile data collection platforms such as CommCare and ODK can be configured for health worker visits, but growth logic has to be built and validated by each programme.

The gap is a focused, offline app that does growth monitoring well: correct z-scores on the phone, faltering detection across visits and a follow-up list, validated against the WHO reference.

Inspiration

The WHO Child Growth Standards and the WHO anthro R package (open source on GitHub) define and implement the z-score calculations for each indicator using the LMS method, including WHO's rules for extreme values. This project ports that logic to a phone, tests it against the reference package and builds a health worker workflow around it.

What you build

• Health workers register households and children, record measurements at each visit and immediately see whether a child is in the normal range, at risk or severely affected for each indicator.
• The app compares the visit with earlier ones and flags faltering, such as a drop of more than a set amount in weight-for-age z-score, or no weight gain across two visits.
• Flagged children get a referral slip and appear on a follow-up list until they are seen.
• Supervisors see coverage, overdue visits and flagged children for their area once phones sync.

The technically interesting part

• Correct z-scores. Implement the LMS formula with the WHO tables by sex and age in days, switch correctly between length and height at two years, adjust if a child under two is measured standing, and apply WHO's restricted calculation beyond three standard deviations for some indicators.
• Validation against the reference. Generate thousands of measurements across ages and sexes, run them through both your engine and the WHO R package, and require agreement to a stated precision.
• Plausibility checks. Catch typing errors (a weight of 85 kg for a toddler, a length that shrinks) before they create false alarms.
• Offline-first sync. Workers may be offline for days. Design record identifiers, sync and conflict rules so no visit is lost or duplicated.

How to evaluate it

• Engine accuracy: maximum and mean difference from the WHO reference package across all test cases.
• Data entry errors: in a simulated session with seeded mistakes, how many your checks catch.
• Field test: with permission, a small trial with health workers or nursing students; time per visit and their feedback compared with paper cards.
• Sync robustness: tests that simulate weeks offline, conflicting edits and interrupted uploads.

Suggested plan

• Weeks 1 to 3: study the WHO standards and the R package; extract the tables; write the engine.
• Weeks 4 to 6: validation harness and plausibility checks.
• Weeks 7 to 10: app screens, faltering rules and referrals.
• Weeks 11 to 12: sync and supervisor view.
• Weeks 13 to 15: field test, report and demo.

Path to a product

Health programmes and NGOs need tools that work offline and are trustworthy. The z-score engine alone, published as a tested open source Kotlin library, would be useful to other developers. The full app could be offered to NGOs with setup and support, or contributed to a programme's existing platform. It is also a strong mobile portfolio project with real correctness requirements.

Scope warning

This app supports health workers; it does not diagnose. Clinical thresholds for referral must come from programme guidelines, not from the team's judgement. Use made-up data in development and get formal approval before any field use with real children.

Learn what you need on Sefism

• Mobile development roadmap: offline storage, background work and Android basics.
• Android Developers Documentation: Room, WorkManager and Compose.
• Guide to Android App Architecture: structuring an offline-first app.
• Kotlin Documentation: the language for the app and the engine.
• Mobile development cheat sheet: sync, local databases and testing.

Get help with this idea

The hard parts are matching the WHO reference exactly and designing sync that never loses a visit. Tauseef can help you plan the validation and scope a respectful field test. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session