---

# IN5320 - Case 1: Commodity dispensing
Group 3

## About the application

The application provides and easy way for personell at hospital's or health clinic's pharmacy department to register dispenced medicines and medical equipment in DHIS2. The application also helps personel keep track of inventory and which medicines and medical equipement have been dispensed.
Every transactions is being kept track of by using the DHIS2 API to store the number of commodities left and automatically update the “Consumption” and “End balance” in the data set.

## Functionality and implementation

### 1. Core functionality

> Users should be able to register when a commodity is dispensed

* To dispense commodities through in the application, go to the `Dispense`-tab in the side navigation bar. To add commodities here, simply search for the commodity in the search bar and press the `Add`-button. The selected commodity gets added to the list, where users can view balance and add amount to dispense. A commodity with a balance of 0 cannot be dispensed.
* When every commodity is added to the list, and quantities have been selected, the user need to add the name of the person requesting the commodities, as well as their department. When all is selected, users are free to press `Submit form`, which updates the balance of commodities in the data set and adds the dispense to the log

> The data set “Life-Saving Commodities” in the DHIS2 instance should be updated accordingly (adding to the consumption, and subtracting from the end-balance of the current month)

* The data set “Life-Saving Commodities” is updated through an API-call each time a user submits a dispense of commodities.

> The application should retrieve the listed commodities from the “Life-Saving Commodities” data set. If new commodities are added to the data set, these should be available in your application.

* Navigating to the `Balance`-tab in the side navigation bar shows every commodity in the "Life Saving Commodities"-data set. The data in the table is retrieved from the data set, which ensures updated balance and commodities if the data set is updated.
* There is also an additional feature in the `Balance`-table, where users can view the balance of a commodity in nearby hospitals, in case they want to request some additional stock from each other.

#### Technical implementation

- We used `useDataQuery` to receive data from the DHIS2 dataValueSet endpoint and received data from the organization units selected. We are using a table to display the data.
- After dispensing we used useDataMutation to mutate the `dataValueSet`. This was done after validating that all input fields were valid and after the user pressed the submit button in the form.
- The period updates automatically to be in the current period. We assume that a month is from the 14. in each year and that January is month 0. This means that today (19.11) is the period *202110* and that the next period will start 14.12. This takes away the hassle for the HSM to update stock-balances by hand each month. There is yet no functionality to handle a potential difference between expected delivery and actual delivery, but we our understanding from the case that there already exist an application that takes care of this problem in DHIS2.

### 2. Additional features

#### Log dispensing
- Every time the HSM (hospital store manager) dispenses a commodity, the application logs th commodity dispensed, the amount dispensed, the user who dispensed it, who it was dispensed to, which department it was dispensed to and the time and date it was dispensed.
- This is done by using DataStore in DHIS2. We created a namespace for our application; `IN5320-G3` and have one document for each month. Each organisationUnit is a key-value in the document. This works well as a MVP and is not meant for more extensive use in production. The dataStore API is not async-safe and therefore data would be lost if two facilities use the endpoint at the same time. If this application were to be rolled out in production, they would have to create a new endpoint that can be used by several sources at the same time.
- The log is useful because you can keep a history and document the dispensing. This was also done manually on paper before. Now they would save time because the log is generated automatically.

#### Full offline functionality
- Internet connectivity may vary in the hospitals where this application is used. Therefore, we have made this application 100% usable without internet. We think that this would make the application a lot more valuable for the HSM because they will not need to use paper as a supplement to this application when internet is down. This would remove double work and creates a seamless experience for the users.
- Offline functionality is done by making the application a PWA. In this way, all required network requests are cached and are used if the network is not available. We store all outgoing network post-requests (dispense-mutations and logging) in local storage. When the network is available once again we send all these network requests. We also store the dispensed amounts of the different commodities to show the correct available amount to the user. If say we had 20 of one commodity when we were connected to the internet last, and then we dispensed 3 of that commodity, we show that it is 17 commodities left.
- **We assume** that each hospital only runs one instance of this application at the same time.

#### Look up nearby facilities
- When the HSM are dealing with stockouts they may have to call the nearby hospitals to receive an amount of a commodity from another hospital. We want to help the managers so they can make a better decision on who to call. Therefor we have added functionality for looking up the stock balance of a commodity for close hospitals in the same district(organisationUnit parent).
- This is implemented by receiving data from all the organisationUnits in a district. The district is the parent organisationUnit to the hospital, so we therefore use this district to get all its children, which are the hospitals. We show the nearby district data in our balance overview.

#### Select facility
- A HSM, we assume, can have access and work at several hospitals. Therefore, we want to let the user decide which of these he or she wants to select. Then we dynamically show the data for this selected hospital.
- But for test purposes we have decided to only use the organization unit Wonda. This because the test user has too many organization-units that it would not be efficient for testing and developing purposes. Wonda is a district in Sierra Leone that has 4 organization units in that area. We assume that the test-user in our app has access to all these organization units, and can choose between them.
- To make the application ready for production we would get the users organization units and find all the units the user works in. If this is more than one, the user should be able to select the unit he or she wants.

## Missing functionality
The application is working just as it should and fulfills our MVP, but if we had time, we would like to add some extra functionality:

* We would have liked to add a sorting function to the table in dispense logs, as it would have been practical to sort by either descending or ascending, person dispensed to, commodity or department. Another small issue in logging is that the time saved in the logs is retrieved from a local data function in the code, which results in sometimes being saved in 24-hour format, while other in 12-hour formats based on configuration in local operating system for each user.

* Even though you can look up stock on commodities in nearby hospitals in the `Balance`-table, it would be interesting to do even more with this information, such as being able to order stock from nearby hospitals through the application.

* While we feel like the UI is looking good and is functional now, we believe we could have done even more work to make it as user-friendly and clean looking as possible. The best way to do this would be to work closer with the end-user and see what is intuitive and what is not.

* We would also make the DataStore-logging functionality async-safe. We could at least have done it safer and more efficient by having one document for each organization unit for each year. This would work assuming each hospital only uses one system each.