01 · What breaks
Design for the failure modes, not only the happy path.
A community health programme stands or falls on whether a referred person actually reaches care. Systems that only count visits miss that, and systems that over-share or over-alert create harms of their own.
Workers seeing unassigned patients
If every worker can search the whole patient list, neighbours' health conditions become visible to people who live next door. Limit each worker to their assigned households, give supervisors their team's caseload, and log any access outside it. When a worker leaves, move the caseload to the successor rather than sharing the old login.
Alerts without an escalation service
A red flag for high blood pressure or a newborn danger sign helps only if someone can act on it today. Before switching an alert on, name who receives it, the expected response time and the fallback when they are unavailable. Alerts with nobody behind them teach workers to ignore the screen.
Clinical interpretation embedded in code
Cut-offs for blood pressure, haemoglobin or blood sugar written into form logic get forgotten when guidelines change. Keep thresholds in a reference table owned by a clinical lead, version them, and store the version used with each screening. An audit can then show which rule applied on the day.
Unsafe contact after a sensitive screening
A positive TB, HIV or mental health screening sent by SMS to a household phone, or discussed during a visit with relatives present, can lead to stigma or worse. Record the contact method and time the person chose, and suppress automated messages for sensitive results.
02 · Minimum viable model
Follow each care episode from home visit to confirmed service.
Health programmes tend to collect visit data well and lose track at the facility door. These six records close that gap: the episode stays open from screening to confirmed service, and every step carries an owner and a due date.
| Birth type | HBNC home visits | What the case system does |
|---|---|---|
| Institutional birth | Days 3, 7, 14, 21, 28 and 42 | Creates six due visits from the birth date and flags any missed beyond the grace period your programme sets |
| Home birth | Day 1 (within 24 hours) plus days 3, 7, 14, 21, 28 and 42 | Adds the day-1 visit and alerts the supervisor if it is not recorded in time |
| Newborn discharged from an SNCU | The discharge day counts as day 1 | Starts the schedule from discharge, not from birth |
| After day 42 | Home Based Young Child care continues with quarterly visits | Moves the child to the HBYC follow-up schedule |
Under the National Health Mission, an ASHA (Accredited Social Health Activist) makes these Home Based Newborn Care visits, as of October 2026. Keep the visit days in a table the programme can edit when guidance changes. Open-source platforms such as Avni, stewarded by Project Tech4Dev, follow the same idea of scheduling visits per protocol and flagging overdue ones offline.
03 · Implementation sequence
Move through reviewable gates.
Start with the worker's daily list and work outwards to supervisors and facilities. Many workers use low-end phones with patchy signal, so the offline field data collection design matters as much as the forms.
Map worker decisions and clinical boundaries
List what a worker decides on a visit (whom to see, what to counsel, when to refer) and what they must never decide (diagnosis, changing medicines). A clinical lead signs this list. It sets the boundary for every form, alert and message, and it is reviewed whenever protocols change.
Define minimum patient identity
Agree the few fields that identify a person reliably in your area: name, age or year of birth, household, a relative's name and village. Add a government health ID only where a linked service needs it. Run a duplicate check at registration, because the same person often appears under two spellings.
Build visit and referral workflow
Each visit records what was due, what was done and the next due date. A referral creates an open item with the facility, urgency and a target date, visible on the worker's list until it closes. Build the whom-to-visit-today screen first and test it in the field before anything else.
Test privacy on shared devices
Many workers share a phone with family members. Test what a child or spouse could see if they opened the app: lock screen, automatic logout, no sensitive results in notifications and no photos saved to the gallery. Fix every leak before go-live and recheck after each app update.
Connect facility confirmation where possible
Agree with facilities how they will confirm that a referred person was seen: a callback, a slip the person brings back, a shared register or a data link. Record the confirmation method with each closure. A referral closed on the worker's word alone shows as unconfirmed in reports.
Review overdue and unresolved cases
Supervisors meet workers every fortnight with a list of overdue visits, open referrals past their target date and people lost to follow-up. They agree an action for each and record it. Closing an unresolved referral needs the supervisor's written reason, never a timeout in the software.
04 · Evidence
Measure whether the work became clearer.
The figure that matters most is how many referred people actually received care. These measures set it beside caseload and follow-up so a programme can see where people drop out. Sector context sits in our health and wellbeing playbook.
05 · Responsible automation
Let systems prepare. Keep consequence with people.
Systems can support
- Daily visit lists for each worker
- Open referrals tracked to confirmation
- Versioned screening thresholds
- Overdue and lost-to-follow-up views
People should decide
- Clinical diagnosis and treatment
- Urgent escalation
- Closing an unresolved referral
- Contact where privacy is uncertain
06 · Common questions
Practical questions teams ask.
Questions health programme managers and supervisors ask before giving workers a new app.
What is a community health worker case management system?
It gives each community health worker their assigned households, the visits and screenings due and the referrals still open, and records what happens at each step. Supervisors see their team's caseload and overdue items. The core aim is that nobody who was screened and referred gets forgotten somewhere between the home and the facility.
How do you track whether a referral was completed?
Treat each referral as an open item with a facility, an urgency level and a target date. Close it only with a confirmation: a facility callback, a returned referral slip, a shared register entry or a data link. Record which method was used, and report confirmed and unconfirmed completions separately so the programme knows how reliable the figure is.
Can a community health worker app work offline?
It should. Workers often visit areas with poor signal, so forms, the visit list and reference tables need to work without a connection and sync later. Plan how conflicts are handled when two people update the same record, keep sync status visible on the phone, and test on the cheapest handset your workers actually carry.
Should the app tell workers what is wrong with a patient?
No. It can show danger signs to look for, apply agreed screening thresholds and prompt a referral, but diagnosis and treatment belong to trained clinicians. Keep thresholds in a versioned table owned by a clinical lead, and word prompts as actions, such as refer today or recheck in a week, rather than as conclusions.
How do you protect patient privacy when workers share phones?
Limit each worker to their own caseload, use a PIN or app lock, log out automatically, keep sensitive results out of notifications and avoid saving photos to the phone gallery. Ask each person how and when they are happy to be contacted. Test all of this on a real shared phone before go-live, not only on staff devices.