| | 1 | = Ebola Response = |
| | 2 | [[TOC]] |
| | 3 | |
| | 4 | Sahana is starting to respond to the Ebola outbreak in West Africa as we have a usecase from MSF nurses in the field: |
| | 5 | |
| | 6 | == Use case: Contact Tracing/Monitoring == |
| | 7 | As you probably know, a key element of the fight is to monitor all people that an infected person has come into contact with. |
| | 8 | |
| | 9 | This consists of: |
| | 10 | * Take temperature 2/day |
| | 11 | * Asked about symptoms |
| | 12 | * Continue for 3 weeks |
| | 13 | |
| | 14 | As soon as a person is in this monitoring state, then their contacts are also recorded. |
| | 15 | In the event that they show symptoms, or are tested positive, then their contacts are put into the enhanced monitoring state, and so on. |
| | 16 | |
| | 17 | Right now this is a paper-based system which causes long delays (days) before people are put into the enhanced monitoring state, which |
| | 18 | obviously means they're likely to have more contacts & hence more deaths will occur. |
| | 19 | There is an old study about a similar system, related to sexually transmitted diseases, which shows that such a system can reduce the delay to get people into monitoring to less than 6-8 hours (provided |
| | 20 | you have enough resources for the monitoring itself). |
| | 21 | |
| | 22 | Constraints are that the system would need to work offline and on 5-8 year old hardware...so we're talking Windows laptops with IE7/8 and pre-Android phones. |
| | 23 | |
| | 24 | My solution would be to bundle Firefox into the install and use SMS for mobile parts. |
| | 25 | This needs validating before we can action. |
| | 26 | |
| | 27 | == Solution == |
| | 28 | * Template ('Disease'? I see this as more widely applicable than Ebola, although Ebola is clearly the most pressing) |
| | 29 | - enable only relevant modules |
| | 30 | - customise menus |
| | 31 | - customise homepage (although this can be minimal - doesn't need to look pretty! Just be functional) |
| | 32 | - customise modules |
| | 33 | |
| | 34 | * Data Model |
| | 35 | - a link table between pr_person <> pr_person: pr_person_contact |
| | 36 | - hms_person_status (lowest degree of separation from an infected person, tested (None, Positive, Negative), last-monitored datetime, last-monitored result, in-treatment-centre (hospital_id?)) |
| | 37 | - hms_person_monitor: component of pr_person to record the monitoring results (if we need to keep historical) |
| | 38 | |
| | 39 | * Simplification of PR to minimum required for the usecase |
| | 40 | - pr_contact |
| | 41 | - pr_address |
| | 42 | |
| | 43 | * Simplification of HMS to minimum required for the usecase (which could start as zero with all referrals happening off-system) |
| | 44 | |
| | 45 | * onaccept routine (run async where possible, even if unlikely on the older hardware we're talking) to flag record of contacts that need to go into enhanced monitoring...and provide a summarised list to the relevant person (email?) Do we notify the contact themselves via SMS? |
| | 46 | |
| | 47 | * Simple reporting to see a list (& totals) of contacts that we should be monitoring and their status |
| | 48 | |
| | 49 | * Build Installer |
| | 50 | |
| | 51 | * Do we need Sync with a central server? |
| | 52 | |
| | 53 | |
