Working with OMRS in Low-Connectivity Environments
14:00-14:40 in main room.
timer and note taker: Isaac Holeman
1) Need all the data from multiple locations in one place for reporting etc.
2) It's expensive to set up new servers and network (time and equipment costs) at each remote location.
3) If you use OMRS as a standard web app - one server, multiple remote sites using it -load times can be slow in low bandwidth
Sync module is getting better and better - would be a good topic for a later meeting. It can work over internet or USB.
Currently people also use remote form entry (with info path) for this.
Note: sync can be made to go just one way (as in, data goes to but not from the central server). You can manage this on an object by object level (example: patients are synced down but not specific observations).
Make it easier to set up OMRS in remote sites - example: Run OMRS on a single computer instead of a server, network, and work stations. Could make it easier to set up/maintain small OMRS installations.
Improve OMRS so that not as much data is sent with each page load
Host servers closer to home - less latency
Drew recommends better use of ajax a la gmail.
Discussion on comprehensive sync, partial sync, and lazy loading.
Comprehensive Sync: Sync module can currently be used to comprehensively sync OMRS databases so that multiple OMRS servers have the exact same data
Partial Sync: Sync module currently can manage synchronization on an object by object level (example: patients are synced down but not specific observations).
Lazy Loading: Evan and Isaac think it would be great, at some point in the future, if remote OMRS servers (or OMRS on mobile devices) could query a parent server for information on a specific patient, cohort ect, and download only that data.
Andrew of PIH Lesotho uses OMRS as a data repository (not point of care). Central server hosted in USA. Seven rural mountain sites connected via satellite. Usually connected, but very low bandwidth. How can we speed up data entry? Using HTML form entry module. Overview page takes ~30 seconds to load. Updating one CD4 count means entire page must reload.
Dave Thomas of PIH is now working with the sync module in OMRS 1.6. There are some bugs (legacy bugs in sync or bugs due to OMRS data model changes), but generally it's working. Started with 1 or 2 days a week managing sync (solving issues takes longer over bandwidth). Now they have one 2-3 hour issue a month.
Evan Waters of PIH Malawi was using remote form entry module in Malawi. Only works with infopath forms, data is synced upwards to parent server. They take a laptop out to the remote site, fill out data, take it back to parent server and sync up.
Wisdom in Ghana is using the Zain (a telecom) 3.5G network to send data. They have issues with the reliability of the network - it goes off all the time. Thinking about sync… it would be good to reduce the number of fields on a form/number of objects on the interface to make it simpler and reduce bandwidth needs.
Hamish Fraser was in Haiti this spring, tried loading a few pages over mobile data network. Redundancy in connectivity should be a big theme moving forward, mobile internet can be a part of that.
Maurice from MVP is entering all data locally, but they are trying to move towards remote data entry using the Edge network (Zain, in Kenya) to transmit data. It was very, very slow last week and they are considering not moving forward with the switch to GSM. Considering a tool for offline data entry that would then sync via mobile network whenever data connectivity is available.