Thailand: Reveal-Biophics Data Synchronisation
Status
# | Step | Status |
---|---|---|
1 | Responsible prepares rough business analysis/reqs doc | |
2 | Get CHAI review | |
3 | Get Akros Review | |
4 | Get Ona feedback | |
5 | Responsible - 1 iteration for feedback | |
6 | Ona sign off | |
7 | Ona tech spec scoping | |
8 | Ona LOE | |
9 | Ona scheduling |
Requirements
- The Thailand BVBD requires that all data captured in Reveal be available for ETL into their Malaria Informations System (Biophics)
- These data include all form fields and as much metadata as possible
- The requirement is for the following forms to be available in the Biophics holding database (db_mhealth)
- Household Registration with Head of Household (HoH) details and HoH created as a Household Member as well, as per Reveal
- Household Members (including HoH as mentioned above)
- Blood screening (linked to household member)
- Index Case Confirmation (linked to household member)
- Bednet distribution (linked to household)
- Indoor Residual Spraying (linked to household)
- Mosquito Collection (linked to focus area/operational area)
- Larval Dip (linked to focus area)
- (Near future) Potential Area of Transmission (linked to focus area/operational area)
- Field testing is planned for 21st August
- Pilot in 3 provinces is scheduled for September, dependant on successful field testing
- It is more important to be able to see that a form has saved to the holding tables that to have every data exactly mirrored.
- The main priority is for CHAI and the BVBD to be able to see some data from each form saved on the mobile device showing up in Biophics within a few minutes.
- Each record should be correctly linked to other relevant records (e.g. a household member should always have a household record, a blood screening should always have a household member).
- The process can be improved going forward to ensure that all fields are captured correctly for each form
- Ideally, the holding tables should enforce referential integrity, but this can be relaxed if it will cause race conditions and insert failures
- Every record should have a timestamp for when it was created in the Reveal client, the OpenSRP server and the Biophics db_mhealth tables.
- Every record should include the name of the Reveal user who captured the data
- Every record should be linked to a focus area
- There may be focus areas in Reveal that do not exist in Biophics - this is expected and should be dealt with (holding tables should include both the Reveal location id (not null), as well as the Biophics focus area id (nullable)
- A formal test script is being developed and will be shared iteratively over the next 2 weeks
- Historical data can be ignored and the team is only interested in seeing data going back 2 days, until the process is finalized. This needs to be done at least 2 days before field testing starts.
To Discuss
- It would be useful to link each record to the plan and activity in Reveal. If so a plan column would need to be added, or if activity_id is populated this could be linked to a plan table. Ideally, the plan selected in mobile client hamburger menuwill be shown in each record (or linked to the plan in a plan table), as well as the name of operational area selected
Testing
- Currently, CHAI and VItal Wave are testing by completing forms for a structure, logging into the Biophics database and checking to see if records appear in the relevant tables
- A view called sync_check can be used to see if household members, households, blood screening and bednet distribution have been received by biophics for a particular household member. At the moment many household members are not linked to a household e.g.
- Suggest another view is created showing the 5 most recently created records for each holding table (Pierre will do this)
Links
Questions for the Biophics Team
System Architecture Diagram (suggested)
This site is no longer maintained. Please visit docs.opensrp.io for current documentation.