Difference between revisions of "BingBong"

From mn/ifi/inf5750
Jump to: navigation, search
m
m (Programs we will use)
 
(21 intermediate revisions by 3 users not shown)
Line 24: Line 24:
 
To present the results we have discussed and planned on setting up a single page front-end UI consisting of multiple react components, and depending on the complexity and reusability of the data at hand we might introduce a flux structure to the project as well.
 
To present the results we have discussed and planned on setting up a single page front-end UI consisting of multiple react components, and depending on the complexity and reusability of the data at hand we might introduce a flux structure to the project as well.
  
== Architecture ==
+
== Programs used ==
 +
'''React''' is a javascript library using components that make it easy to render HTML code and combine it with javascript. By using react we will naturally also be using HTML, CSS and Javascript.
  
=== Programs we will use ===
+
'''React-Bootstrap''' is basically the Bootstrap framework built with react in mind, making it easy to work with front end with simple, readable code and a grid system for responsiveness.
- react
 
  
- flux (redux/alt.js)
+
'''Node.js''' (under the hood)  
  
- html, css, and javascript (ofc)
+
== Planning ==
 
 
- React-Bootstrap
 
 
 
=== Planning ===
 
 
* '''Time schedule'''  Group session: Thursday 10-12  Work time: planned hours that fit all three participants
 
* '''Time schedule'''  Group session: Thursday 10-12  Work time: planned hours that fit all three participants
 
* '''Tasks'''  Wiki start: Åvald
 
 
* '''Screenshots and screen flows'''  TBA
 
 
* '''Documented learning during project'''  TBA
 
 
* '''Suggested improvements to APIs etc'''  TBA
 
 
* '''Sample web app'''  TBA
 
  
 
=== Kanban board ===
 
=== Kanban board ===
 
{| class="wikitable"
 
{| class="wikitable"
 
!Tasks
 
!Tasks
 +
!Difficulty
 +
(1, 2, 3)
 
!In progress
 
!In progress
 
!Testing
 
!Testing
Line 57: Line 45:
 
|-
 
|-
 
|UI design
 
|UI design
 +
|3
 
|M
 
|M
 
|
 
|
|
+
|M A
 
|
 
|
 
|-
 
|-
 
|Grid skeleton for app
 
|Grid skeleton for app
 +
|
 
|
 
|
 
|
 
|
Line 70: Line 60:
 
|Add basic navbar(tabs to split TEIS and
 
|Add basic navbar(tabs to split TEIS and
 
singletons)
 
singletons)
|A
+
|2
 +
|
 +
|M
 
|M
 
|M
 +
A
  
 
Å
 
Å
|M
 
 
|
 
|
 
|-
 
|-
 
|Add content to TEI tab
 
|Add content to TEI tab
|
+
|3
|
+
|M
|
+
A
|
+
|M
 +
 
 +
A
 +
|M
 +
 
 +
A
 +
|Grid structure might need some changes, but its working!
 
|-
 
|-
 
|Add content to Singleton tab
 
|Add content to Singleton tab
 +
|3
 +
|A
 +
Å
 
|
 
|
|
+
|A
|
+
Å
|
+
|Parts of the singleton content was the same as TEIs, but did not have things like an advanced option, and the backend was of course different.
 
|-
 
|-
 
|Split TEI and Single events in app
 
|Split TEI and Single events in app
|
+
|1
|
+
|A
|
+
|A
|
+
|A
 +
|Became a sub result of adding the TabBar
 
|-
 
|-
 
|OrgUnit dropdown
 
|OrgUnit dropdown
 +
|2
 
|A
 
|A
 
M
 
M
 
|
 
|
|
+
|A
|
+
M
 +
|[RESOLVED]for all dropdowns add a search element so user won't have to scroll too much
 
|-
 
|-
 
|Program dropdown
 
|Program dropdown
 +
|2
 
|A
 
|A
 
M
 
M
 
|
 
|
 +
|A
 
|
 
|
 +
|-
 +
|Time period select
 +
|1
 +
|A
 +
|M
 +
|A
 +
Å
 
|
 
|
 
|-
 
|-
|Date dropdown
+
|Implement favourite button
 +
|2
 +
|M
 +
|M
 +
|M
 +
|[RESOLVED] Still requires functionality though!
 +
|-
 +
|Implement functionality for the favourite button
 +
|
 +
|A
 +
M
 
|
 
|
 +
|A
 +
M
 
|
 
|
 +
|-
 +
|Favourites area
 
|
 
|
 +
|M
 
|
 
|
 +
|M
 +
A
 +
|for users to add a combination to favourites so they don't have to select everything anew.
 
|-
 
|-
|Results area
+
|Functional "Find results" button
|
+
|1
 +
|M
 +
A
 +
|M
 +
 
 +
A
 +
|A
 +
Å
 
|
 
|
 +
|-
 +
|Implement functionality for finding duplicates
 +
|3
 +
 +
A
 
|
 
|
 +
 +
A
 
|
 
|
 +
|-
 +
|Results area
 +
|2
 +
|A
 +
|A
 +
|A
 +
|Results area has been implemented, but could use some updated frontend design for consistency
 
|-
 
|-
 
|Update Wiki
 
|Update Wiki
 +
|N/A
 
|A M Å
 
|A M Å
 
|N/A
 
|N/A
 +
|A M Å
 
|
 
|
 +
|-
 +
|Save things in data store
 +
|2 1/2
 +
|M
 
|
 
|
 +
|M
 +
A
 +
 +
Å
 +
|an all-purpose component that can be used by other components to save teis/singletons/favs/recents in a simple way based on namespace keys.
 
|-
 
|-
 
|Find API url(s) for trackedEntityInstances
 
|Find API url(s) for trackedEntityInstances
 +
|3
 
|A
 
|A
 
Å
 
Å
Line 133: Line 197:
  
 
Å
 
Å
 +
 +
A
 +
|Still missing urls for dealing with spesific set of time periods
 +
|-
 +
|Find API url(s) for updating trackedEntityInstances
 +
(Needed to merge TEIs together)
 +
|3
 +
|A
 
|
 
|
|
+
|A
 +
|Finished, but not implemented due to the fact that the urls that was found could not be used to update the spesific property "trackedEntityInstance".
 +
 
 +
An alternative was to add a field instead but we decided to add our results to our own dataStore instead to show that we can handle PUT requests.
 +
 
 +
Ideally we would like to update the property though, and then DELETE the TEIs that are no longer used.
 +
|-
 +
|Find and implement actions for finding data elements
 +
|2
 +
|A
 +
|A
 +
|A
 +
|Two functions has been implemented, 1 for finding all and 1 for finding a specific set of elements
 +
|-
 +
|Find and implement actions for finding singleton
 +
events
 +
|2
 +
|A
 +
|A
 +
|A
 +
Å
 +
|A few functional functions has been added, but still need to figure out how to use filter in the url
 +
to ONLY fetch singleton events (currently it finds all events, including events linked to TEIs)
 +
|-
 +
|Improve query area (Includes setting up area for advanced,
 +
area for previous queries (while reusing a lot of pre-existing code))
 +
|3
 +
|A
 +
|A
 +
|A
 +
|This can always be improved, I added some simple advanced options for TEIs that can be upgraded,
 +
and advanced can easily be added to singletons as well should we find some relatively easy things
 +
 
 +
to include here.
 
|}
 
|}
 +
 +
== Screenshots and screen flows  ==
 +
Singletons tab (without results well):
 +
<br />
 +
[[File:Singletons.png]]
 +
<br />
 +
<br />
 +
TEIs tab (with results well):
 +
<br />
 +
[[File:TEIS.png]]
 +
<br />
 +
<br />
 +
Duplicates found:
 +
<br />
 +
[[File:Duplicates.png]]
 +
 +
== Suggested improvements to DHIS API & our client  ==
 +
'''API Improvements'''
 +
 +
We have used several parts of the API where it has served our needs well, but there has been a lot of hiccups regarding PUT & POST requests where we have simply received the error message "Method not allowed". This made us implement somewhat crude functionality in regard to our data store initialization functions and also limited our ability to actually perform required updates to events (e.g update the trackedEntityInstance value of an event). Instead we offer the user a save option when finding duplicates where the duplicates will be saved in our data store. In the future it would of course be more ideal to actually correct the duplicates straight away.
 +
 +
'''Flux'''
 +
 +
Earlier in the project we had discussed wether or not to implement a flux like structure, and ended up with a structure close to flux, but we are not using flux. Instead we have an "actions" folder which contains all of the actions that deal with requests towards the DHIS 2 API and a regular "components" folder which contains all of our components. In addition to this we have added a lot of functionality under a "utils" folder.
 +
 +
In retrospect we could probably have implemented flux to avoid having to load some data more than once (e.g all organizational units) and also to keep track of other data that could be useful across components. Data like this is something we could have stored in flux stores.
 +
 +
'''Improvements to our client'''
 +
 +
We have diverted most of our focus in delivering a product where the content is understandable and not too big and yet have the functionality required. Other than possible bug fixes we would've liked to implement a way to update duplicates on the API itself with PUT & DELETE requests, in addition to providing more advanced options for TEIs and also give some advanced options for singletons.
  
 
== Link to repository ==
 
== Link to repository ==
 
https://github.com/lax1n/INF5750-Project
 
https://github.com/lax1n/INF5750-Project

Latest revision as of 11:14, 7 December 2016

Group members

  • August Haug Hem
  • Åvald Åslaugson Sommervoll
  • Mahasty Assi

Summary of requirements

A Cleaning and Deduplication of Events

The DHIS2 Tracker module allows people to collect individual level data. These come in two forms:

1) “Singelton” cases that are recorded only once without registration or follow-up (e.g. Outpatient data). DHIS2 calls this a single event.

2) Events linked to a person (the DHIS2 term is a Tracked Entity Instance - TEI) where you first look up a person (or register a new) who is enrolled in a health program and then follow the patient over a period, with each visit to the doctor recorded as an event, linked to the program (e.g. a TB patient). However, patients often go to different clinics for the same thing, and a lot of data is collected offline, without the possibility to check if the patient is already in the system. Therefore, there is a need to A) identify duplicate people and B) reconcile the data belonging to the same person.

The task is to make a webapp which helps administrators to easily identify clear and potential duplicates (e.g. slight misspellings) and mark them for reconciliation (which the app could also assist in). A combination of automated and manual filtering/navigation. You can initially assume the number of persons and events is small enough to be handled in the client. For more advanced functionality, it is also interesting to link to server side procedures.

Understanding

We are to clean the DHIS2 Tracker module. This will be done by finding possible duplicate entries of a patient, and presenting these findings to an admin, who can then choose to mark them for reconciliation or dismiss the finding. We see that we can also assist in the reconciliation.

This app will basically be a 2-in-1, with one functionality to find duplicate TEIs, and one functionality for finding duplicate single events. The Tracked Entity Instances have identificators like name, birth date, village and so on in order to be identified, so using those parameters we should be able to find duplicates for that instance type. Single events however, do not have these identificators, and are mainly used for statistics and follow-up on a more general basis for the database. These are noted down from paper and due to basic human errors a single event may be documented multiple times. Our job in this case is to find such single events and list them up. For both functionalities a list of results will be shown in order for the admin to mark them for reconciliation.

To present the results we have discussed and planned on setting up a single page front-end UI consisting of multiple react components, and depending on the complexity and reusability of the data at hand we might introduce a flux structure to the project as well.

Programs used

React is a javascript library using components that make it easy to render HTML code and combine it with javascript. By using react we will naturally also be using HTML, CSS and Javascript.

React-Bootstrap is basically the Bootstrap framework built with react in mind, making it easy to work with front end with simple, readable code and a grid system for responsiveness.

Node.js (under the hood)

Planning

  • Time schedule Group session: Thursday 10-12 Work time: planned hours that fit all three participants

Kanban board

Tasks Difficulty

(1, 2, 3)

In progress Testing Finished Comments
UI design 3 M M A
Grid skeleton for app App is already responsive, grid structure does not need to be implemented manually.
Add basic navbar(tabs to split TEIS and

singletons)

2 M M

A

Å

Add content to TEI tab 3 M

A

M

A

M

A

Grid structure might need some changes, but its working!
Add content to Singleton tab 3 A

Å

A

Å

Parts of the singleton content was the same as TEIs, but did not have things like an advanced option, and the backend was of course different.
Split TEI and Single events in app 1 A A A Became a sub result of adding the TabBar
OrgUnit dropdown 2 A

M

A

M

[RESOLVED]for all dropdowns add a search element so user won't have to scroll too much
Program dropdown 2 A

M

A
Time period select 1 A M A

Å

Implement favourite button 2 M M M [RESOLVED] Still requires functionality though!
Implement functionality for the favourite button A

M

A

M

Favourites area M M

A

for users to add a combination to favourites so they don't have to select everything anew.
Functional "Find results" button 1 M

A

M

A

A

Å

Implement functionality for finding duplicates 3 Å

A

Å

A

Results area 2 A A A Results area has been implemented, but could use some updated frontend design for consistency
Update Wiki N/A A M Å N/A A M Å
Save things in data store 2 1/2 M M

A

Å

an all-purpose component that can be used by other components to save teis/singletons/favs/recents in a simple way based on namespace keys.
Find API url(s) for trackedEntityInstances 3 A

Å

A

Å

Å

A

Still missing urls for dealing with spesific set of time periods
Find API url(s) for updating trackedEntityInstances

(Needed to merge TEIs together)

3 A A Finished, but not implemented due to the fact that the urls that was found could not be used to update the spesific property "trackedEntityInstance".

An alternative was to add a field instead but we decided to add our results to our own dataStore instead to show that we can handle PUT requests.

Ideally we would like to update the property though, and then DELETE the TEIs that are no longer used.

Find and implement actions for finding data elements 2 A A A Two functions has been implemented, 1 for finding all and 1 for finding a specific set of elements
Find and implement actions for finding singleton

events

2 A A A

Å

A few functional functions has been added, but still need to figure out how to use filter in the url

to ONLY fetch singleton events (currently it finds all events, including events linked to TEIs)

Improve query area (Includes setting up area for advanced,

area for previous queries (while reusing a lot of pre-existing code))

3 A A A This can always be improved, I added some simple advanced options for TEIs that can be upgraded,

and advanced can easily be added to singletons as well should we find some relatively easy things

to include here.

Screenshots and screen flows

Singletons tab (without results well):
Singletons.png

TEIs tab (with results well):
TEIS.png

Duplicates found:
Duplicates.png

Suggested improvements to DHIS API & our client

API Improvements

We have used several parts of the API where it has served our needs well, but there has been a lot of hiccups regarding PUT & POST requests where we have simply received the error message "Method not allowed". This made us implement somewhat crude functionality in regard to our data store initialization functions and also limited our ability to actually perform required updates to events (e.g update the trackedEntityInstance value of an event). Instead we offer the user a save option when finding duplicates where the duplicates will be saved in our data store. In the future it would of course be more ideal to actually correct the duplicates straight away.

Flux

Earlier in the project we had discussed wether or not to implement a flux like structure, and ended up with a structure close to flux, but we are not using flux. Instead we have an "actions" folder which contains all of the actions that deal with requests towards the DHIS 2 API and a regular "components" folder which contains all of our components. In addition to this we have added a lot of functionality under a "utils" folder.

In retrospect we could probably have implemented flux to avoid having to load some data more than once (e.g all organizational units) and also to keep track of other data that could be useful across components. Data like this is something we could have stored in flux stores.

Improvements to our client

We have diverted most of our focus in delivering a product where the content is understandable and not too big and yet have the functionality required. Other than possible bug fixes we would've liked to implement a way to update duplicates on the API itself with PUT & DELETE requests, in addition to providing more advanced options for TEIs and also give some advanced options for singletons.

Link to repository

https://github.com/lax1n/INF5750-Project