Difference between revisions of "BingBong"

From mn/ifi/inf5750
Jump to: navigation, search
Line 1: Line 1:
'''List of group members'''
 
  
August Haug Hem,  
+
== Group members ==
 +
* August Haug Hem
 +
* Åvald Åslaugson Sommervoll 
 +
* Mahasty Assi  
  
Åvald Åslaugson Sommervoll, 
+
== Summary of requirements ==
  
Mahasty Assi 
+
=== A Cleaning and Deduplication of Events ===
 +
The DHIS2 Tracker module allows people to collect individual level data. These come in two forms:
  
'''Summary of requirements'''
+
1) “Singelton” cases that are recorded only once without registration or follow-up (e.g. Outpatient data). DHIS2 calls this a single event.
  
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).
 
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.
+
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.  
 
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.  
  
'''Time schedule'''
+
=== '''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.
Thursday 10-12
 
 
 
'''How you are dividing tasks within the group'''
 
 
 
Wiki start: Åvald
 
 
 
'''Screenshots and screen flows'''
 
 
 
'''Documented learning during project'''
 
 
 
'''Suggested improvements to APIs etc'''
 
 
 
'''Link to repository'''
 
 
 
https://github.com/lax1n/INF5750-Project
 
 
 
'''Download link to sample web app'''
 
  
'''Architecture'''
+
An algorithm will be needed to find duplicates, also taking into account that there might be typos and misspellings. The current challenge is finding out how to know which singleton events can be connected to tracked entities, as the information in singleton events are sparse. 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 ==
 
- react
 
- react
  
Line 48: Line 33:
 
(-http://www.material-ui.com/#/)
 
(-http://www.material-ui.com/#/)
  
'''Understanding'''
+
== Planning ==
 +
* '''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
  
We are to clean the DHIS2 Tracker module. This will be done by finding possible duplicate entries of the same patient, and presenting these findings to an admin. Who can choose to mark them for reconciliation or dismiss the finding. We see that we can also assist in the reconciliation.
+
* '''Sample web app'''  TBA
  
To find duplicate entries we have planned to make an algorithm which will find duplicates, also taking into account that there might be typos and such. Then,  to present the results we have discussed and planned on setting up a single page frontend 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.
+
== Link to repository ==
 +
https://github.com/lax1n/INF5750-Project

Revision as of 14:18, 28 October 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.

An algorithm will be needed to find duplicates, also taking into account that there might be typos and misspellings. The current challenge is finding out how to know which singleton events can be connected to tracked entities, as the information in singleton events are sparse. 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

- react

- flux (redux/alt.js)

- html, css, and javascript (ofc)

(-Bootstrap)

(-http://www.material-ui.com/#/)

Planning

  • 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

Link to repository

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