In software development, it is well understood that product development requires knowledge of the domain in which the software will be used. People who have this knowledge are called subject matter (domain) experts or business analysts. For example, for developing a hospital system you require hospital administration understanding, or for a tax filing system tax-accounting knowledge.
But, is hospital administration in a regular metro city hospital the same as the hospital administration in a rural (i.e. rural, tier-3, tier-4 city) hospital? At a technical level, it may appear that both have patients, departments, doctors, similar processes e.g. for outpatient registration->queue->doctor->test->prescription->pharmacy->home. One may use this understanding and develop a hospital management system, but will it work in rural hospitals?
We argue that a domain expert not exposed to the rural hospitals - will bake numerous bad decisions into the product, making it an inappropriate solution eventually. This phenomenon applies to many domains.
Let's take some examples of a rural hospital and understand how it is materially different from a tier-1 hospital. Almost all patients do not take appointments before visiting the hospital. So if one develops a patient-facing appointment system, it is completely useless.
Patients are not good at keeping their older medical records. Hence usually hospitals tend to keep their record with them instead of handing it over to them.
Patient's phone number registered with the hospital changes all the time (either because their number changes or they provide different family members' numbers every time). As a result, patients take a lot of time at the registration desk - as the re-identification process takes a lot of time. The software should be sophisticated in this area.
Rural doctors see 2 to 3 times more patients. They simply do not have time to enter any data in the hospital system. Also, a token-based queue in front of the doctors' room is useless in rural setups, as many patients are not that literate to follow it. Usually, there is an usher.
You can read more about two other examples, recently in the news where this phenomenon is in play.
- COVID-19 vaccination system - The challenges of our vaccination drive’s final stretch - The system developed a pull-based system i.e. citizens will take appointments/walk-in and take vaccines. First, in a low resource setup, it works based on a push mechanism (pushed by health workers). Second, is the very basic mistake of assuming good internet connectivity.
- Nutrition system to be used by anganwadi worker - The Anganwadi angst over an unfriendly mobile app (use reader mode in Firefox). Again the assumption that internet connection is good is false. Also, the app has many complex workflows.
Examining this as a software practitioner, we see that although we have a domain expert among ourselves but the domain in itself is quite different when we switch context to a low resource setup. We cannot assume even the basic understanding of low resource setup since most domain experts (like many urban folks) have almost never set their foot in such places - for any meaningful length of time. It doesn't come very naturally to someone who is in a high-resource setup.
In essence, we are dealing with an orthogonal dimension (see the diagram below) - to the extent that each domain expertise needs to be further qualified into a high resource (being default) and low resource.
Broadly, the general low resource expertise consists of deeply understanding how the following factors impact the inner workings of the domain for which the software is built. This is not an exhaustive list.
- Internet is not present everywhere and/or is not available all the time.
- Demand massively surpasses the supply of providers.
- Local IT support is difficult to get and retain.
- Client literacy levels are low.
- Client finances are poor.
- Clients have to work hard for their livelihood hence leaving less time for availing themselves of even important services.
- Distances are high and play an important role (unlike cities).
In software teams, we should strive to have domain experts who have low resource understanding to avoid having serious design mistakes in our solution.
This article has been republished from Samanvay Foundation and the original can be viewed here