This document summarizes Bahmni Connect, an offline mobile app that allows health workers to record patient data in remote areas without internet access. Key points: - Health workers can enter patient observations, registrations, visits, treatments and more using the offline Bahmni Connect app and sync the data when internet is available. This avoids errors from paper records and saves time versus entering all data at the end of the day. - The app works offline on Android and as a Chrome extension using indexedDB for storage. It syncs data to the server in the background using web workers or on manual trigger when network is available. - Initial and background syncs transfer metadata and transactional data based on the login

1. Bahmni Connect
+
- Bahmni Team
Thoughtworks

2. No Network connectivity:
● Without Bahmni Connect: A health worker, usually active on the field and does not have access to
the internet. They would record patient details/observations for patients on paper and enter it in
Bahmni once they are back in the hospital at the end of the day.
● With Bahmni Connect: A health worker can directly enter the observations in the offline app and sync
it to the server at the end of the day when there is network.

3. How does it help?
● Data entry is a time taking process. Entering a day’s worth data at the end of the day is a huge task.
● The more the number of hops before data is entered in the system the more error prone it is.
● Avoids loss of paper records - during the transition of paper records from hospital to remote area,
many times they get lost.
● With paper records, a lot of times duplicate records get created as it is difficult to search. An offline
app helps in search and prevents creation of duplicate records.
● Doctors usually start a treatment in hospital but do follow ups in a sub centre. If the paper record is
not available, doctor at the subcenter will not know the details of the treatment going on.
● Entering the data in Connect app (offline) will help them identify the missing (mandatory) information/
erroneous information at the field itself.
● Syncing the Connect app to server ensures that the latest information is present in the Connect app
as well as at the main hospital.

4. Current Features:
●Works Offline.
●Patient Registration
●View the following information on patient dashboard
○Observations
○Visits
○Treatments
○Lab orders
○Diagnosis
●Record observations
●Push to/ pull from (sync) server

6. Offline Support through Apps
● Chrome Extension (Bahmni.tar.gz) : Web worker, Indexed DB, Lovefield

7. With discontinuity of Chrome’s support for
Chrome Apps
Evaluating options:
● Electron
● Progressive Web apps (Service workers)

8. Offline Support through Apps
● Android App (Bahmni.apk)
Ionic provides all the functionality that can be found in native mobile development SDKs.
Crosswalk

9. Home Page With Sync button:

10. Sync Mechanisms
●Initial Sync : App is unusable.
●Background Sync : Uses Web workers. Scheduled at
periodic intervals. App is usable.
●Manually trigger sync.

11. Initial Sync:

12. Background Sync/ Manual Trigger

13. App Pull

14. App Pull
●Meta data: Synced to all devices
○Configs
○Global properties
○Reference data
○Concepts
●Transactional Data: Synced based on login location
○Patient Profiles
○Encounters( observations, orders ….)

15. App Push
Hustle : A javascript queuing and messaging library built on top of IndexedDB.

16. Sync Strategy
● As the number of patients, their encounters, observations would be usually very high, the storage space
on the tab would be a constraint.
● Data is usually pulled based on the login location used during login.
● For example if a person has logged in for login location 1, data relevant for location 1 is only pulled.
● The way data is mapped to a login location is based on a strategy. The strategy is a java class which just
evaluate the filter for each event.
● Strategy is customizable and pluggable.
● Out of the box there are 2 strategies
○ LocationBasedOfflineSyncStrategy: Based on the patient address filled in registration form the
filter is evaluated.
■ Eg: If a community health worker logs in from “Kampala” , all patient whose address is
Kampala would be synced. It uses address hierarchy to map patients to login location
○ IDBasedOfflineSyncStrategy : Based on the patient identifier a patient is mapped to a login
location.
■ For eg: Primary identifier has a prefix which represents the village they belong to.
Strategy can be customised and can be plugged in as a global property in OpenMRS

17. Sync Strategy:
Note: Metadata (configs/global properties/concepts) would be synced to all locations irrespective of login location.

18. Data Flow:

19. Components on server side
●Event log Service
○Polls Events Records table for new events
○Creates events in event_log with filter for each event
●Bahmni Offline Sync OMOD
○Loads the strategy configured in global properties
○For every event in event records it evaluates the filter
based on the strategy and gives it to Event log service

20. Demo...