Doctors' Voice System for Rural India


Randolph Wang    and    Sunayna Jain




Our organization works in the northern rural Indian state of Uttar Pradesh, one of the poorest states in India. A clinic is often at least tens of miles away. Transportation is difficult to arrange. Residents and front-line health workers lack access to even the most basic health care information. People tend to overlook questions or minor illnesses until symptoms worsen seriously; they often seek advice from local quacks. One of the common "prescriptions" from quacks is large doses of steroids. One of the local traditions is to smear cow dung on a recently cut umbilical cord. Many of these customs and misconceptions are not necessarily widely known or practiced elsewhere so one-size-fits-all "expert" broadcasts or pamphlets rarely adequately address such misconceptions. Easy and regular access to small morsels of relevant information would help in preventing and identifying small problems and bad practices before they develop into something far worse.


We have built a doctors' voice system; the voice system and its associated voice database allow under-served villagers to post health-related questions that are asynchronously answered by panels of volunteer doctors and other healthcare workers. One of the key innovations is the use of low-cost de-centralized voice servers, built on open hardware and software standards, easily maintained and administered by individual grassroots health-related organizations (such as hospitals and NGOs), that are extremely easy to customize for highly tailored local purposes. We have been running a pilot deployment in the past four months. Using simple ("dumb") voice phones, villagers (who are seldom literate in our work area) leave their personal voice queries, receive timely and relevant personal voice responses, or receive broadcast messages (that are of general interest to larger groups). (In our experience, while voice signal coverage is almost ubiquitous even in the remotest areas, 3G or 2G wireless data coverage is rarely available.) Staff of our partner NGOs and volunteer nurses administer the voice system via a web interface. They filter, categorize incoming questions and assign them to volunteer doctors of particular expertise and interests. Depending on their preferences, volunteer doctors receive their "assignments" via a phone interface, or a web interface, or VOIP, or in email; and they may respond via any of these means. For example, some doctors prefer to listen to incoming villager questions that are sent to their email addresses, but they prefer to reply via a phone interface by calling back the voice system. Once the voice system receives the doctors' replies, it schedules outgoing reply calls to the villagers who have asked the questions. The cycle may repeat several times as clarifications are sought. 


Doctors tend to be very busy people. The fact that the voice system allows them to contribute small bits of wisdom asynchronously in an extremely flexible and convenient way is critical to our success--doctor could instruct the system to call her once a week at a time of her choosing and she answers just a couple questions read to her by the system. If she happens to be busy, she may choose to skip it, and her assignment gets re-assigned to someone else. This is a far cry from the "heavy-duty" commitment of a call-center type arrangement. Many being socially progressive people, given the any-time (the system is available 24/7), any-place (home, office, or even when they are traveling), any-device (computer, phone, or a mixture) convenience, the doctors that we have approached have almost universally agree to participate. The power of the system lies in its ability to harvest such small bits of contribution from many contributors and pool them together into a well-organized and cohesive whole.


In addition to "demand-driven" one-to-one exchanges, the doctors' voice forum allows a variety of other modes of interaction. We collect phone numbers of villagers who opt in to receive calls originated by the voice system at times and intervals of their choosing. (Receiving calls is free here.) (1) If a forum administrator (a staff of an NGO) feels that certain exchanges may be of interest to a larger group, such as wives of HIV-positive husbands, with appropriate anonymizing, the administrator may "narrow-cast" an edited version of the exchange to the group. (2) We create interest groups that receive regular periodic reminders or carefully designed voice programs that consist of, for example, weekly "twitter-like" voice messages targeting pregnant women or women with new-born infants, who receive regular updates on child nutrition and vaccination reminders. (3) The forum advertises the availability of services. For example, there are retired doctors, hospitals and NGOs in the area that volunteer their time to perform reconstruction and correction surgeries at a low cost for villagers who have been afflicted with polio or cerebral palsy. Some NGOs also provide free walking aids. But the villagers are not necessarily aware of these services. Our voice forum makes this "supply-side" information available so polio cases (common in the area) can be connected to those who can help. (4) The voice system serves the role of a constant, long-term, and systematic link between local health organizations and the communities that they serve; as such, this link can be used for data collection purposes. We can collect incidence of various diseases (especially infectious diseases), mortality (and its cause), birth, vaccination, contraception, and other events. In addition to input from villagers, we appoint representatives or ask community leaders to act as an additional human "interface" and some of the statistics are gathered from them via the system. Data-collection is a "side-effect" of other activities, making it less burdensome to those who are involved so it's more easily sustained in the long run. (5) The voice system acts as integral parts of other activities. Mobile (van) outreach programs run by partner organizations can conduct more pin-point specific activities, such as dropping off medicines, picking up villagers for follow-up tests at clinics. This is more efficient and effective compared to some existing medical "camps" that end up emptying out whole villages where most come to get nothing more than vitamin pills. In some cases, we have also sent prescriptions via SMS that are filled by small local pharmacies, accompanied by verbal instructions left by doctors on the voice forum. This has turned out to be an effective way of countering quacks. (6) While most of the questions are left by villagers, front-line health workers of our partner organizations also frequently leave questions of their own, which, when resolved by experts, aid the health workers' field work. (7) Re-use of earlier voice data stored in the well-organized voice database can amplify the utility of expert "bandwidth."


Compared to traditional voice systems, there are three key technical aspects of our system that are interesting: (1) de-centralized development, customization, and deployment based on open telephony standards; (2) that we have built a "kit" that drastically simplifies the construction and customization of similar specialized voice servers in the future; (3) a large number of specific interface features of our current doctors' system that we have developed in the past months that are derived from extensive field trials and are uniquely adapted to the kind of audience and environment that we target. We elaborate below on these technical aspects.


Traditionally, voice systems that may be deemed similar to ours are typically developed with proprietary PBX hardware and software, often with the blessing of telcos. This approach, confined within a closed eco-system, is costly, difficult to customize, difficult to justify for small groups of targeted users. To see how limiting this is, if we may draw the analogy between a voice server and a web server, imagine how limiting the web would have been if the web server hardware, the Apache server, the site-specific code (like cgi-bin scripts), the process of building a site and later modifying it are all tightly controlled by a few big phone companies so individuals and organizations can't easily and cheaply set up and customize their own web sites--there simply would not have been a web if this were true.


In contrast, our system is built on top of cheap ISDN line cards plugged into conventional PCs and the Asterisk open-telephony framework. The voice servers simply sit in our regional offices. We tinker with the voice server logic almost on a daily basis based on field feedback. (Presently, our software consists of about 22,000 lines of Python code.) The decentralized and open approach is low-cost, provides extreme ease of local customization, and makes it feasible for us to experiment with tailor-made solutions for small local populations and organizations. We don't need phone company blessing. The solution can be easily and cheaply replicated at many locations, and because these distributed systems are networked, the information can be easily shared across the entire network of voice servers.


The existing low-level frameworks (such as Asterisk), however, are not for the faint-hearted. There have been many efforts of simplifying Asterisk but, unfortunately, these efforts almost uniformly end up sacrificing power so they could deliver something that's akin to a corporate voice mail system or a corporate PBX system, none of which is suitable for our needs. (Instead of handling only one-to-one phone calls, our system behaves more like a "forum.") Part of our contribution is having built additional database-driven software components so that the task of building a certain class of similar doctors' voice applications in the future is drastically simplified. Our experience has been that voice applications for different contexts are very different and one-size-fits-all attempts cannot work well. What our system allows one to do is to quickly and easily build these tailored voice systems, just like the way the Apache web server allows users to quickly and easily build web sites, without worrying about the low-level details.


In addition to providing this low-level support, we have also been working on many high-level interface issues, issues that may not have been a problem in a developed world setting but caught our attention as we work with our target audience. Here we merely give two examples: villagers having difficulty grasping the concept of navigating a voice menu by pressing keys, and the fact that even the cost of a single cell phone call could be seen as a nontrivial expense. To solve these two problems, our system provides village users a "menu-less" interface that's driven by history stored on the voice server, and it lets users pick ways and times at which they prefer to be automatically called by the system (which uses additional heuristics to decide calling schedules) so the calls are free to them. There are many other interface features that collectively contribute to a comfort level that's critical for the system's adoption.


The deployment of our doctors' voice system started in late January of 2010. Since mid-February, we have been steadily adding participating villages at the rate of roughly one or two villages per week, and volunteer doctors at the rate of roughly one or two per week. We handle about ten calls per village per week. The calls encompass a very wide variety of questions and topics, almost all of which are issues that have been plaguing the afflicted for quite some time and/or issues that they would not or could not seek competent advice about prior to the availability of the system. Addressing such issues has the potential of preventing conditions from worsening and, possibly, lowering the cost of intervention. Overwhelming majority of the participants in the voice system so far have been women. There have been questions concerning issues such as HIV/AIDS, certain sexual dysfunctions, contraception, questions that might be considered "taboo" in a conservative religious society, questions that would unlikely have been asked without the questioners feeling a degree of anonymity.


We plan to look at a variety of indicators in gauging the effectiveness of the system. The more simplistic metrics include pre- and post-tests on certain public health knowledge that's "pushed" out from the voice system as broadcasts to interest groups. We will analyze the voice database statistics to see, for example, the fraction of voice messages that result in successful real-world interventions and behavior changes. In integrating the voice system with our partner organizations' existing outreach programs (such as vaccine programs and polio programs), we will study to what extent these existing programs benefit from the aid of the voice system. Ultimately, the system must answer to "bottom-line" metrics. Examples include infant mortality rates, maternal mortality rates, the incidence of polio, etc. We plan to work with additional public health experts and organizations to develop a long-term census program that's run on the voice system. This will not only track the effectiveness of the existing activities on the system, but also potentially open up new horizons of future public health programs that can take advantage of the voice platform.


If our initial experiments are successful, we will seek gradual but much larger scaling. We believe the system, in its many facets, including its modest equipment needs, its de-centralized architecture, its customizability to suit local applications and local audience needs, its philosophy of harvesting grassroots volunteerism and channeling small contributions from many into a cohesive force, its approach of empowering and strengthening grassroots organizations' existing programs, are well-positioned for replication. In the next phase, we will partner with more organizations, deploy voice servers at more locations, share data among them, and reach a larger rural population.

project home                               © 2010    The Digital StudyHall