Point of work and reporting systems is one way to classify the low resource systems (LRS). It classifies the LRS based on the objective of such systems. LRS when considered from a technical implementation perspective, can be classified differently. In this article, we shall try to understand the key features of LRS - when considered technically.
Technical architectures of LRS make them different because of two main constraints - availability of Internet and technical complexity of deployment. These constraints restrict what we can offer to the users and where.
a) The user dimension can be split into single-user or multiple users applications.
b) Further, these users can use the system in the facility or in the field (on the move).
Let's cross these two dimensions and see an example of each type of LRS.
1. Single user in a facility - Classic data entry application
2. Multiple users in a facility collaborating with each other - Rural hospital system
3. Single user in the field - Community health worker application
4. Multiple users in the field collaborating with each other - Large health camps or refuge camps
1. Single user in a facility
From an engineering standpoint, there aren't many interesting things about such systems. So let's jump to the rest three.
2. Multiple users in a facility collaborating with each other
Engineers who are used to developing software systems in high-resource environments have a very high probability of making mistakes here - based on our numerous discussions. The biggest illusion is that a progressive web app can be used because they provide higher availability of the application to the user despite poor internet. But the users need to collaborate with each other in real-time e.g. if the doctor orders a lab test, the pathologist should be able to view the order when the patient turns up in their department. Each of these two users having a PWA is not sufficient.
There are two options here.
a) Deploy the server on the premises of the hospital available to the users from LAN. This provides a great user experience but requires local technical support to deal with issues of network, server, power. At scale, with a lot of hospitals, this becomes quite an expensive proposition.
b) Use the service from the cloud, but each facility has two independent Internet connections. The higher the independence of these connections, the higher is the likelihood of Internet availability. We have not seen this tried out anywhere but seems like a good idea - and less resource-poor context can benefit from it.
3. Single user in the field
Offline mobile applications are now widely used in low-resource settings. In simple terms, each mobile device needs to keep ALL the data, for their work area, that the field user will require. Important again to highlight that offline applications are not typical PWAs - which can hold user-created data on the device and save when the internet is available. The issue with PWAs is that they do not hold all the data that the user needs - hence the application becomes useless in many use cases.
But there are certain issues with offline applications too.
a) At some point the volume of data even for a single work area becomes very large. This causes the first-time download of data to take a long time.
b) Management of data for clients moving from one work area to another is a tricky problem.
These are not insurmountable problems but they do require better engineering and user experience design to make it work. Even we in Avni have not fully tackled these.
4. Multiple users in the field collaborating with each other
Since this is the same as 2 but in the field. In 2, while technical operations are a challenge, in 4, deployment is also difficult. This requires multiple computing devices, having the applications and connected to each other. Given the technical complexity and place of technology in the hierarchy of requirements - such systems are not seen in the real world. Perhaps they may remain so.
Author: Vivek Singh
Published on: 07-Dec-2021