Technology Overview

Before you “get started,” make sure to take a look at the Should You Use ChildCount+? section of the introduction. If you are duly convinced that you need some CC+ action in your life, then read on.

Technology Prerequisites


ChildCount+ should NOT be deployed on a publicly accessible network. Data between the server and clients is not encrypted the software is not hardened against attacks.


Wait! Before you read on, check out the Human Prerequisites section. Make sure that you’re not missing anything on the human side of things before you jump into the land of config files and list comprehensions.

Hopefully these documentation pages, plus some Googling, will be all the information you need to get ChildCount+ up and running. In the real world, it is unlikely that the ChildCount+ team will be able to keep this documentation up to date forever, but at least we are trying!

All Installs

Linux Server
You will need a server to host your ChildCount+ installation. We recommend using Ubuntu versions 10 and up, since that is what we use for development and deployments.
If you need to print paper reports.

Paper-Form-Based Installs

Computers for Data Entry
You will need one client machine per data entry clerk. Windows, Max, Linux, OS/2, – anything with a good web browser will do.
Local Area Network
To connect your data entry computers to the ChildCount+ server.

SMS-Based Installs

GSM Modem
If you want to interact with ChildCount+ via SMS. Any modem that works with PyGSM will work. We use Multitech MTCBA-G-F4 modems.
SMS-Enabled Mobile Phones
One per community health worker.
Mobile Phone Chargers
If you are deploying in an area without reliable power, make sure you have solar chargers or some other means of charging cell phones.
Airtime Credit Distribution System
You will need some way to distribute airtime credit to the community health workers. Millennium Villages Project has tried to negotiate with mobile operators to get toll-free SMS lines, but distributing airtime scratch cards by hand is also an option.

Understanding the Components

The ChildCount+ stack is large – it includes many components patched together in non-obvious ways. The following diagrams will hopefully give you a sense of what the components of ChildCount+ are and how they relate to each other.

ChildCount+ runs on top of RapidSMS, but since there is almost no documentation for RapidSMS, we will try to document bits of RapidSMS as we go along.

ChildCount+ Component Overview

Web. How ChildCount+ handles HTTP requests from Web browsers:

  • Cherokee Web Server handles incoming HTTP requests and passes them to...
  • – a Python script that sets some environment variables (like the local time zone) and invokes Django’s wsgi (Web Server Gateway Interface) handler.
  • Django‘s Web framework handles the request from there. The Web portion of ChildCount+ works like Django (with a few caveats). You will find Django-style and files in the apps/* directories.

SMS. How ChildCount+ handles SMS messages.

  • The GSM modem receives SMS messages from your mobile operator and queues them.
  • PyGSM provides a simple API through which Python applications (like RapidSMS) can connect to the GSM modem to send and receive SMS messages.
  • The RapidSMS Router (rapidsms route) periodically (every five seconds or so) uses PyGSM to check the modem for pending incoming messages and to send pending outgoing messages. The rapidsms program resides in the root ChildCount+ directory and is the core RapidSMS executable.
  • The router then looks for all installed RapidSMS applications. The list of installed applications is in the file local.ini in the root ChildCount+ directory. For an example of local.ini files, see the ChildCount+ Installation Repository.
  • For each installed application, RapidSMS loads the file apps/[app_name]/ and calls the App.handle() method with a rapidsms.message.Message object. (App inherits from
  • The :meth:`App.handle` method does app of the SMS processing logic, and finally returns a bool value, indicating whether RapidSMS should propagate the message to other installed apps (when App.handle() returns True) or not (when App.handle() returns False). The App.handle() method can also call the message.respond() method on the message object to send an SMS back to the sender.

Reports. How ChildCount+ schedules and runs nightly reports and SMS alerts:

  • Each RapidSMS application within a ChildCount+ installation has a file called apps/[app_name]/ Django Celery loads these files and uses them to schedule periodic tasks.
  • Celerybeat, a process invoked as /etc/init.d/celeryd -B periodically checks the current time, and the task run history located in (celerybeat-schedule) to determine if there is a periodic task that should run. When Celerybeat wants to run a task, it inserts a message into...
  • RabbitMQ, a message queue that holds pending tasks.
  • Celeryd worker processes periodically check RabbitMQ for pending tasks and they run any pending tasks they find in the queue. Celeryd workers run as /etc/init.d/celeryd and can run in the same process as Celerybeat (above). When Celeryd workers start up, they load the current RapidSMS/ChildCount+ code so they have access to the ChildCount+ database and all ChildCount+ classes.
  • The Celeryd workers can write out completed reports to the file system or they can send SMS alerts out via the RapidSMS messaging functionality.


There are a few different places where configurations happen in ChildCount+ and it’s useful to know which settings go where.

This is a Python file that holds settings for the Django environment in which RapidSMS and ChildCount+ run. If you have settings for Django plug-ins or need to set environment variables, this is where to do it.

We use it to hold timezone settings, Django cache settings, django-celery settings, and some language settings.


This is a RapidSMS-specific configuration file. It is divided up into sections, with each RapidSMS app getting a single section. RapidSMS passes the values of these settings to the configure() method of the class in the RapidSMS application apps/[app_name]/

The database login information is here, and the lists of activated ChildCount+ forms and reports are there under the [childcount] header.

I am not sure what this does but I am scared to delete it.
This is a Django model (a database table) that holds some configuration information that doesn’t fit well anywhere else. OpenMRS login information (for mgvmrs) and lists of enabled dashboard sections are there too.


We use: