Case 2 - Data entry forms

In the last ten years, Whotopia has digitized much of its routine health information reporting systems. In the process, the reporting of health data is moved from paper forms to digital forms entered and submitted using DHIS2 on desktop computers or tablets. A persistent challenge experienced by the Ministry of Health is that end-users are struggling with digital data entry. Currently, the Ministry of Health is planning to transition yet another paper-based data entry form to DHIS2. They want to use the opportunity to explore how a new web-based DHIS2 application can provide better support to the end-users. In this case, you will be provided with the data entry form, and are to build a web-based app for digital data entry.

End-user profile

Concretely, there are two types of end-users that fill in and submit the digital data entry forms in DHIS2 in Whotopia. First, the medical staff are medical experts such as doctors and nurses who primarily work with patients, while submitting reports from their health facilities on a regular basis. The reporting is thus not their primary work, but something that they do as part of their administrative tasks in addition to attending to patients. Typically, they spend a few hours every month entering 4 - 5 different forms on aspects such as vaccination, maternal health services, and the prevalence of various diseases. Second, dedicated data entry clerks are hired at some health facilities, often district or regional offices. They are responsible for entering data into the digital form in DHIS2 on behalf of health facilities where there are no computers. In essence, their work comprise of looking at forms filled with pen and paper by health workers at various facilities and then entering the submitted numbers into the corresponding form in DHIS2. 
 

Key Challenges

A team from HISP Whotopia and the Ministry of Health have conducted visits to several health facilities to understand the challenges end-users experience with digital data entry. They have identified 4 key issues. 

1. Internet connectivity
The medical staff doing the monthly reporting rely on the digital form being available when they are to enter the data. However, unstable internet connectivity makes it difficult to access the data during longer periods of the day. Accordingly, they prefer to keep their data entry forms on paper, which is available regardless of internet connectivity.
    
“Access to the data entry form in DHIS2 may fluctuate throughout the week. Often, it is not available when we need to enter the data, or we need to go back and check if we entered the data, and what we entered”

2. Submission status
The medical staff finds it difficult to know whether the data entered in the digital form is actually submitted or not. 

“I click on ‘Complete’ but I have no idea if the form is submitted or not. Sometimes, I think I have submitted the form, but then later find out that I have not. If I sometime after completing the data entry go back to the data entry app, it is difficult to see if the form is submitted”

3. Familiarity with paper 
In general, the medical staff finds the paper forms easier to use and more familiar than the digital data entry forms.

“We have been using paper forms for ages - paper is easy to use, easy to learn, and reliable. The switch to the computer system is difficult for many of the staff that have been working here for a long time”

4. The size of forms
Both medical staff and data entry clerks find it difficult to enter data into the forms due to their size.

“You know, in some forms, we have to scroll both in vertical and horizontal direction - especially with big forms on smaller screens. It is very difficult to know which row and column I’m entering data into when entering data far down and to the right of the form”

The issue of large forms may also negatively affect data quality as indicated by a data manager. 
“We often see a lot of data entry errors where we suspect that the person entering the data has missed the right row or column. This may seem like a simple mistake, but we may end up doing our health planning based on the totally wrong data” 

While both the medical staff and the data entry clerks find it difficult to navigate the large forms, the data entry clerks find the work very mundane and tiresome, particularly as the forms are very large.

“You know, my work involves filling these forms the whole day. The work is important, but it is very mundane and tiresome, especially since the forms are so large”
 

Infrastructural conditions at the hospitals

All hospitals that are to use the data entry application have desktop computers or tablets, and electricity available. Internet connectivity may, however, fluctuate throughout the day, sometimes being lost for several hours. 

Fundamental requirements

In this case, your group is to design and develop a web-based DHIS2 app that supports data entry for the form (?Data set? in DHIS2 terminology) “Morbidity”. Figure 4 shows the paper version of this form, which is what is used by health workers in facilities that do not use DHIS2. You should use the challenges identified by HISP Whotopia as a basis for the way you design your solution, attempting to address some or several of the challenges they face with the current digital data entry solution. As a bare minimum, your solution should address the following fundamental requirements:

  • Users should be able to open the Morbidity data entry form and enter data
  • The app should retrieve the data elements from the Morbidity data set in DHIS2
  • Users should be able to submit data

With regards to the form (data set), you can assume that the type of disaggregation of diseases remains the same (by age group, and new/follow-up). However, the solution should be able to dynamically cater to additional diseases/diagnosis.

Beyond these, it is up to your group to ideate, prototype, and decide how you will design and develop a solution that addresses the challenges faced by the end-users. 

 

Figure 1: Morbidity monthly summary form

Technical starting point

Background

Data values, such as those collected through the input fields of a data collection form (data set), are in DHIS2 linked to three key dimensions: periods (“when?”), organisation units (“where?”) and data elements (“what?”). For periods, the ISO format is used, so that October 2021 becomes “202110”. For organisation units, the name, uid or code can be used (though name is seldom used by applications such as those you are developing here, and not all organisation units have code - so in practice you should use the uid).

Data elements are a bit more complicated, as they can be disaggregated (i.e. broken down into smaller entities) by categories with options. Categories can be combined in category combinations, where the combination of the options of all included categories becomes category option combinations (or catoptioncombo). For the data element dimensions, data values are thus associated with both a data element (name, code, uid) and catoptioncombo (name, code, uid).

Object

Description

Example

Data element

The main definition of the data value, the “what?” of the data.

Children given BCG vaccine

Category

Defines a breakdown/disaggregation of the data.

Age

Category options

The different breakdowns (options) of a category

0-11 months; 1+ year

Category Combination

The combination of one or more categories.

Age and sex

Category option combination

The combined options of the categories in the category combination.

0-11 months, female; 0-11 months, male; 1+ year, female; 1+ year, male

 

Data elements in the “Morbidity” data set you’ll be working on in this case are disaggregated by two different category combinations: The new and follow-up cases are disaggregated with the “Morbidity cases” category combination (t3aNCvHsoSn), whilst the referrals are disaggregated with the “Morbidity referral” category combination (ck7mRNwGDjP). Each of these category combinations only consist of one category each, and the category option combinations thus have the same name and definition as the category options! However, they are different metadata objects with different identifiers, and it is the category option combinations that must be used when reading and submitting data. One could think that the split of each disease into “new” and “follow-up” cases is also a category, but in this case they are different data elements. The configuration is illustrated in the figure below (for the “Morbidity cases” category combination):

 

(Whole data sets can also be disaggregated, meaning that data values can have yet another dimension (referred to as attributeOptionCombination), but this can be ignored for the purpose of this assignment.)

 

Key API docs

 

Example API endpoints with relevance for the case

Identifying relevant organisation units

Fetch organisation unit(s) to which current user is assigned. End users involved in data entry will typically be “assigned” to a district or health facility, depending on their role. If assigned to a district, data entry is still generally done for individual health facilities, thus the “children” of the organisation unit district users are assigned to.
/api/me.json?fields=id,name,organisationUnits

To list forms (data sets) associated with an organisation unit:
/api/organisationUnits/[orgunit uid].json?fields=name,id,dataSets

To include “children” or the orgunit and their assigned data sets, nested field filters can be used:
/api/organisationUnits/[orguinit_uid].json?fields=name,id,dataSets[name,id],children[name,id,dataSets[name,id]]
 

Identifying forms/data sets and its content

List all data sets:
/api/dataSets.json

Access all properties of one particular data set (excluding the list of organisation units which can be very long and not necessarily relevant if orgunit is already identified)
/api/dataSets/[dataset_uid].json=fields=*,!organisationUnits

dataSetElements is an array is a list of all data elements in the data set. The field filter can be used to include their name etc in the listing: 
/api/dataSets/[data set uid].json=fields=*,!organisationUnits

It’s also possible to include categorycombo and catoptioncombos for the data elements in dataSetElements:
/api/dataSets/eZDhcZi6FLP.json?fields=name,id,dataSetElements[dataElement[name,id,categoryCombo[name,id,categoryOptionCombos[name,id]]]
 

Reading data values

To fetch the current values for all fields in a data set, the dataValueSets endpoint can be used. For example, to get the data values for the “Morbidity” data set (eZDhcZi6FLP), for the period October 2021 (202110) for the organisation unit “Faabu CHP” (ZpE2POxvl9P):
/api/dataValueSets.json?dataSet=eZDhcZi6FLP&period=202110&orgUnit=ZpE2POxvl9P

To get the data values for a single data element (commodity), we can use the dataValues endpoint. To get the data values for “Worm infestation new” (Usk9Asj5DED) data element and “12-59m” (wHBMVthqIX4) catoptioncombo, for the same period and organisation unit:
/api/dataValues.json?de=Usk9Asj5DED&pe=202110&ou=ZpE2POxvl9P&co=wHBMVthqIX4
 

Sending data values

Multiple data values for a data set (e.g. “Morbidity”) can be submitted by POSTing a json-file to /api/dataValueSets. This object/file should be in the below format (described further here), using the same orgunit, period and dataset as above as an example:

{

   "dataSet": "ULowA8V3ucd",

   "resource":"dataValueSets",

   "completeDate": "2021-11-04",

   "type": "create",

   "data": {

      "orgUnit": "ImspTQPwCqd",

      "period": "202106",

      "dataValues": [

          {

          "dataElement": "dY4OCwl0Y7Y",

          "categoryOptionCombo":

          "J2Qf1jtZuj8",

          "value": "12"

           }

   ]}

}

To update a single data value, the dataValues endpoint is used. Here, the value is included as a parameter in the POST request, rather than as a separate json file/object:
/api/dataValues.json?de=Usk9Asj5DED&pe=202110&ou=ZpE2POxvl9P&co=wHBMVthqIX4&value=9