Technology architecture for public health service delivery

…and why designing system for primary health centre is hard.

Health services are delivered in four kind of setups, illustrated by the following matrix — between resource availability and service team size (number of people working together to provide the service to their clients aka patients). It will become clear why I have chosen to highlight the number of people as a factor, because it is an important aspect of designing such systems, but not because of scale.

With this diagram, I am also trying to highlight that, resource availability takes a significant jump from secondary hospitals (running at district head-quarters) to tertiary hospitals in cities. As far as workload per staff is concerned, it is roughly the same throughout (or in the same order of magnitude).

What characterises a low resource setup though, from technology rollout perspective?

• Poor quality Internet (speed, latency, uptime, intermittency)
• Low proficiency levels of (presumed) users
• Low absolutely of IT support and administration personnel
• Lack of funds for tech

Since many systems have been designed for large organisations in abundant resource setups, I will not delve into the architectural characteristics of such systems— there is more than sufficient material on this. Also, to highlight a architectural blind spot, I will get into Primary Health Centre last.

Why do we need software systems in health service delivery setups?

• Management of the facilities' operations (hospital/clinic/centre)
• Storage and retrieval of health records of the clients
• Standardising the work
• Improving availability of data within the organisation
• Work-schedule management (applicable to primary and frontline healthcare which is proactive in nature — e.g. screening, followup)

Given this background of needs, context — lets try to examine the technical architecture constraints and options at each level.

Rural hospitals — District Hospital (DH) and Community Health Centres (CHC)

All hospital systems need to be highly available (one cannot afford to make the patients wait, or have long queues because “system is down or slow”). Rural hospitals of this type are at district headquarters or places like it. Most district headquarters in India are not so well connected to have a highly available Internet connection — essentially ruling out possibility of running such systems off the Internet*. One needs to run the server in a local area network (LAN), so that the connectivity is good and response time is small.

Running server in hospital requires local IT team to support the server, application, network and the user devices/machines. If this has to be done in hundreds of hospitals (for state government, missionary hospital chains), it becomes expensive and dependent on human capacity.

This not to suggest that it is technically not possible, some motivated organisations have been able to do this (running local IT setup) and as we get richer as a country, more hospitals will be doing the same, but at scale it is hard. One important thing to note, is that, the health data of patients, is available only from the internal network of the hospital and is not available to someone who is outside the hospital (for example doctors who consult remotely or want to provide opinion in certain cases). There are few options:

• Buy public IP and setup VPN (but poor Internet bandwidth and knowledge of how to connect via VPN acts as a barrier)
• Publishing data centralised server is an option (the cost of the software and operating further increases the economic burden on non-profit or public hospital)

* One can definitely run systems off-Internet that do not make patients wait if the Internet is down. e.g. Inventory management, periodic reporting system, etc.

Front line health workers

On other extreme end of service delivery hierarchy are Frontline Health Workers (FHWs), who usually work by themselves in villages or in outposts alone, covering few villages. So, when one thinks of bringing digital technology to these workers, helping them in their work, the first thought is — well there is no Internet. But thankfully there are android devices — robust full fledged computers with few GBs of storage.

First let’s step back and understand the context of FHWs and their work. They are responsible for small areas. At sub-centre an ANM works alone. A sub-centre area is roughly five villages, i.e. around 5 thousand population — let’s call this their service area. Similarly a village level worker, e.g. ASHA, is responsible for one village. ANM, ASHA and similar FHWs’ work requires them to have historical primary health data of all the people in their service area, with them (i.e. without requiring Internet connection).

If we calculate how much data this really is, we would see that it is not all that much. At the rate of 25 KB per citizen, we are looking in the ballpark of 125 MB. Modern Android devices can handle this much data in databases like Sqlite or Realm — in hands of good developers, providing great performance. Once this seems feasible, we have found away out of Internet quality problems.

Each FHW can carry these android devices with work-app and complete database of their service area. Usually this data is required by people in other parts of their organisation like medical officers, program designers, ministry. But this access though is not needed in real-time. In most scenarios a delay of even a day is fine, in some scenarios even more. This allows for FHWs application to perform incremental sync (sync = send and receive data; incremental = any data not known to the other end) of the data with a central server, whenever Internet becomes available.

Few challenges still remain (but largely this is viable and useful solution)

• Sometimes users want to keep a copy of data on paper, in case their device is not working then they cannot access the records to provide the service — even though this feels wasteful. But even in this scenario the fact that the FHW doesn’t have to travel miles to file monthly reports is a big plus — to name one.

Primary Health Centres (PHCs)

There is one primary health centre, per 5–6 sub-centres, so we are talking about roughly 30 villages now in a PHC area. Typical rural primary health centre has (rather is supposed to have) a doctor, a nurse, small laboratory, small pharmacy and a registration person.

When designing software systems for PHCs, usually it is approached from two ends i.e. either thinking of it as a smaller hospital or a collection of front line workers in a facility. But both of these are fallacious approach. Lets see why.

When PHC is considered a smaller hospital, one tries to put a server (even if smaller in specs or running in one user’s desktop) in each PHC — running an application server and a database. But, there way too many PHCs than District/Community Hospitals — multiplying all the operational challenges listed above for the district hospital. The operational expense for supporting is too high for it to be acceptable. Just the user by themselves, cannot support this server and network to connect to it.

The other approach is, to think of PHC as collection of field health workers. Hence instead of hosting the server locally, it is put in the cloud, and each user has an app like FLW has, fully capable in offline mode. But this design is flawed technically, as it misses an important difference, i.e. in PHC, unlike field worker’s scenario, “continuous sharing of data captured by one user with other users” (in other words users collaborate among themselves to provide service to the patient). For example, the data captured at registration desk should be sent to the server and be pulled onto the doctor’s (or any other department’s) device before the patient physically moves from registration to the doctor. This is not guaranteed to happen, if Internet is unstable. Soon there will be a lot of real-user downtimes. For the first few occasions, people may tolerate such downtimes, but over time, users are bound to get frustrated and junk such a system because they cannot depend on it.

Then there are ideas like, peer to peer data synchronisation between the devices in PHC. As far as I know there isn’t a mature general-purpose-database that run on android or web-browser that can do peer-to-peer-multi-node-data-replication**.

(Many a times, progressive web apps is thrown in as a solution, and ordinary consultants like me need to explain why PWA is no magic to solve no Internet problem, at the risk of coming across as someone who is not latest with one’s tech)

Overall, designing system for PHC is tricky and requires making more tradeoffs. We do not have standard technical architectures to solve this because there are not many use cases like this. While FLW and Hospital use cases are standard, PHC sort of falls in the weird and interesting middle.

More on this in, other options that don’t work and how we can think of solving it, in another post.

UPDATE (31/08/18): ** My colleagues at Samanvay pointed me to few databases that promise to be handy in solving this problem because they provide peer to peer replication—gundb, rxdb, orbitdb, couchbase lite. These indeed look promising, especially gundb.