Uganda has implemented DHIS2 to support health commodity consumption reporting throughout the public health system. Every month, personnel at each hospital’s- or health clinic’s pharmacy department fill in data on consumption, end-balance, etc. (you can see an example of the forms used for this here, by selecting Sierra Leone as the organization unit, "Life-Saving Commodities" as data set, and any time period). The reports are used by warehouses to determine how many medicines and other medical equipment to be shipped to hospitals and clinics for the next month.
As an increasing number of health facilities have access to computers or smartphones, the Ministry now wants an application where health workers can register information on the dispensing of commodities. That is, each time someone comes to collect a certain amount of a commodity, the personnel at the pharmacy storage should be able to register the transaction in the application. The application should keep track of these transactions by using the DHIS2 API to store the number of commodities left. It would also be useful for the users to see previous transactions and the current stock-balance for the commodities.
Figure 1 - Current dispensing and reporting system
Figure 2 - Envisioned, new dispensing system
When dispensing a commodity, the pharmacy storage worker should register:
- Name of commodity (from a predefined list in the system).
- Amount dispensed.
- Name and department of the person collecting the commodity.
Form/data set to use in DHIS2
A data set is already configured to be used for storing consumption and stock data. The set is named "Life-Saving Commodities" and can be found in the Data Entry app.
All elements in the data set can be accessed, modified and updated using the API. See the example API calls below.
Fundamental requirements
(NB! it is important to note that the user is the person registering and dispensing commodities, not the person picking up the commodities).
- The user should be easily able to register the dispense of commodities, including the name of the commodity (from a predefined list in the system, in this case, from the Life-Saving commodities data set), the amount dispensed, and the name and department of the person collecting the commodity. How the commodities are dispensed varies, and the solution should be easy to use for all the given cases:
- Sometimes low amounts of one type of commodity are dispensed, eg. someone picks up only one or two of a certain commodity.
- Sometimes large amounts of one type of commodity are dispensed at once, eg. someone picks up 50+ of a certain commodity.
- Sometimes many types of commodities are dispensed at once, eg. someone picks up one to many of commodity 1, one to many of commodity 2, etc.
- When commodities are dispensed, the stock balance in the data set (Life-saving commodities) on the server should be updated.
- When commodities are dispensed, it should be recorded in a transaction history (you can use ‘Datastore’ in DHIS2 for this, see example below). The transaction history should consist of: type of commodity dispensed, amount, date and who it was dispensed to.
- The user should be able to see the transaction history and search in it.
- The user should be able to dispense a given commodity, despite the current stock being less than the amount being dispensed (in cases of mismatch in the database and the actual stock). In these cases, the user should be given a warning message, and the application should suggest that the user does a stock count.
Other than these basic requirements, you are free to design the application in any way you want.
Potential additional features
(suggestions)
- It should be possible for the user to dispense commodities even if the application goes offline (but you can assume that initial loading of the app has to be done online). When the application goes back online, the database should be updated with the new stock.
- You can assume that there’s only one user (person registering) for each commodity dispensing facility.
- It should be possible for the user to edit the stock, for example if there is a mismatch in the database and the actual stock.
- The commodity dispenser should be “smart”, and somehow know what amount the user usually dispenses to the person picking up. It should provide warnings for unusual or unlikely transactions (for example if someone dispenses 100 000 of a commodity, and usually the person picking up the commodity picks up around 10 at the time).
- Create an overview screen with useful information such as warnings about which commodities are low on stock.
- Make sure the user interface of the app works well on smaller screens such as tablets and/or mobile phones.
Example API calls:
Get all life saving commodity (dataset ULowA8V3ucd) names and ids:
Get stock for life saving commodities (dataset ULowA8V3ucd) in a given period (201909), for a given organization (DiszpKrYNg8):
- The response gives you each commodity listed three times, these are to indicate consumption (J2Qf1jtZuj8), endBalance (rQLFnNXXIL0) and toBeOrdered (KPP63zJPkOu).
Get the current users organization units:
https://play.dhis2.org/2.31/api/me.json?fields=teiSearchOrganisationUnits
Data store (docs)