...

• User collects a form in the mobile app
• Mobile app syncs to the central system
• Central system identifies that there is a referral that needs to go to the third party system
• Central system creates the referral package by mapping incoming form submission fields to the output(s)
• Central system sends the package(s) to the third party system
  • Note: This may require creating multiple entities in the third party system and the Central data repository is responsible for orchestrating that. For example, you first need to create the patient, then the encounter, then the observations with the ability to roll back changes.
• Third party system receives the package and confirms that it was received
• Third party system parses each package and stores them in the system
• Third party system may trigger internal events based on this changing information

...

CommCare and DHIS2 Anonymous Events

CommCare ---> DHIS2
CommCare Form -> DHIS2 Anonymous Event

...

1. A mobile worker submits a form to the central server
2. Data is mapped from CommCare form question values to DHIS2 data elements, event date, org unit (location) and program. (30 kinds of forms, half a dozen indicators per form.)
3. A single payload is pushed to DHIS2

Project summary

In Mozambique, the upSCALE An application integrates the entire Ministry of Health’s agentes polivalentes elementares curriculum (elementary multipurpose agents curriculum) into one platform. The platform collects real time data entered by CHWs who deliver health services in the remote areas where they live. Dimagi, with the collaboration of Malaria Consortiumthe partner, developed a live integration of every form submissions using the anonymous events functionality into the Ministry of Health (MISAU) “Community Involvement for Health Information System” DHIS2 instance.

...

CommCare and DHIS2 DataSets 

CommCare ---> DHIS2
CommCare Report -> DHIS2 DataSet

...

1. Mobile workers submit many forms over a period of a month
2. After the start of the next month, CommCare retrieves a report for the month just completed. (The report has one column per category option per data element. e.g if the "Live Births" data element is broken down by two gender category options and three attendee category options, the report will have 2 x 3 = 6 columns for live births.)
3. Report data is mapped to data elements and category options, and submitted for the period of the month just completed.

Project Summary

In 2017 Dimagi has collaborated with MSH the partner and the Ministry of Public Health of Madagascar to develop the integration between the CommCare application used at the community level and the DHIS2 instance setup by the Ministry. Using Motech MOTECH and the aggregated integration feature, monthly aggregated reporting data coming from community health workers is sent to the DHIS2 instance of the Ministry of Health. The scope of the application includes all indicators on the monthly activity report covering data for IMCI, Surveillance and also stock management.

Infomovel: Mozambique

CommCare and OpenMRS (with Reports)

CommCare CommCare <--> OpenMRS
CommCare Case <- OpenMRS Report
CommCare Case + Form -> OpenMRS Patient + Observations

...

In order to automate workflows, Dimagi has supported the Center of Disease Control partner to develop a two-way integration between OpenMRS and the Infomovel (a CommCare ) application in Mozambique.  This integration pulls data once a week from multiple OpenMRS instances into a single CommCare instance and has successfully allowed health facilities to replace what was previously a manual effort conducted by the team.  As part of this collaboration, Dimagi has also trained the local project team in how to configure and maintain this integration so that they can independently and sustain this beyond Dimagi’s involvement in the project.

Fully automated 2-way integration between Infomovel (the CommCare app ) and OpenMRS, removing any manual work involved, in at least one health facility of each one of the partners of the Infomovel consortium.

Multi-instance setup where one CommCare instance exchanges data with several OpenMRS instances. This was dictated by the implementation model adopted in which each health facility has its own OpenMRS instance.  

...

Upon submission of a visit form a Visit, an Encounter and several Observations are created in OpenMRS, according to the location of the user, ensuring that the information collected is reflected in OpenMRS. Patient demographics are also updated in OpenMRs OpenMRS if they change.

...

CommCare and OpenMRS (with Atom feed)

CommCare <--> OpenMRS
CommCare Case + Form <--> OpenMRS Patient + Observations
CommCare Case <- OpenMRS Atom feed

...

Dimagi supported the single and bi-directional integration between the Possible Health CommCare app and their OpenMRS / Bahmni system.  This integration allowed for data tracked in the hospital management system to stay in-step with data collected by clinicians in the facilities.  Dimagi also built capacity within the local project team to maintain and extend the CommCare application as well as the integration component of their system.

...

CommCare beneficiaries are created/updated when a clinician at a facility updates a corresponding patient, so that a CHW can follow up. Updates from the CHW are sent back to the clinic/OpenMRS.

...

CommCare and OpenClinica

CommCare <--> OpenClinica

...

• CHW decides that they need to refer a patient to a health facility
• The CHW opens the referral form for that patient, completes it and clicks save
• Post Save Action
  • We generate a task in the CHW application
  • The task is added to the referrals task list in the CHW app
• The CHW app automatically synchronizes 15 minutes
• The task and referral form are sent to the server and added to the queue of forms to download at that health facility
• The Facility app synchronizes and downloads the referral and task
• The task is added to the task list in the facility app
• A visual indicator also shows up next to patient in the appropriate register
• The user taps the task from the task list to open it
• The referral information is displayed and the user can navigate away or they can mark the referral as done
• Post Save Action
  • The task status changes to Complete if the referral is marked as done
• Navigate Back Action
  • The task has now been read, so we need to update the task status to "In Progress"
• The Facility app synchronizes after 15 minutes and updates the task in the server
• The CHW app synchronizes, identifies there is an updated task and updates the task locally to show the status as complete

CHT ↔ EMR (Mali)

...

CHT↔OpenMRS: Lost to Follow-Up (bidirectional)

Summary

For patients who missed important appointments at the health facility, CHWs need to proactively find them to encourage them to visit the health facility. Technically speaking, a report is generated in OpenMRS that contains a list of all the patients who need to be followed-up with. This report is sent to the CHT and for each patient on that list, a task is sent to CHWs requesting the CHW to find and refer the patient to the health facility. 

Patient Process

1. One time sync of all patients between the CHT server and OpenMRS
2. When creating new patients in the CHT mobile app, CHWs have the opportunity to enter an EMR ID.
   CHW syncs.
3. If the patient has an EMR ID, nothing is sent to OpenMRS*
4. If the patient does not have an EMR ID, patient details are sent to OpenMRS and a person + patient is created.  A unique identifier generated by the CHT is also stored in OpenMRS. NOTE: When patients are created in OpenMRS, they are not sent to the CHT

LTFU Process

1. Report is run in OpenMRS which includes all the patients who need to be followed-up
2. IL grabs report from OpenMRS and pushes to CHT server
3. For each patient in the report, IL checks to see if they exist in the CHT.  If not, create the patient in the CHT and allocate to a supervisor who will review and assign to the appropriate CHW.
4. CHW syncs mobile app.
5. CHW receives tasks for patients that need to be followed-up.

CHT↔KenyaEMR: COVID-19 Contact Tracing (bidirectional)

Summary

Suspected cases registered in the CHT are sent to OpenMRS. In OpenMRS, testing/lab results are obtained/recorded, as are additional contacts of cases. Confirmed cases and additional contacts are sent back to the CHT. Confirmed cases are advised and their contacts are followed-up for 10 days. If a contact becomes a suspected case, the cycle starts over.  

Process

1. Suspected COVID patient registered in CHT
2. Sync mobile app, central server sends to OpenMRS
3. CHT sends one payload, OpenMRS splits to person, patient, and case
4. Patient visits clinic for testing, labs, etc..
5. When labs are complete, if case is confirmed COVID, this confirmation and a list of additional contacts to trace are sent to the CHT central server
6. CHT central server splits and allocates to appropriate tracers
7. Tracers receive a task to follow-up with confirmed cases
8. Tracers receive a task to follow-up with contacts of confirmed cases for 10 days or until the contact becomes a suspected case
9. If a contact becomes a suspected case, start back at #1

CHT↔Bespoke EMR: Referrals (bidirectional)

Summary

CHWs do assessments for sick children using the CHT mobile app. If the CHT mobile app determines that the child should be referred to the health facility, the CHT server (once the CHW syncs) will send information about the patient and the referral to the facility based server. When patients arrive at the health facility, they will have access to information from the community. If the patient does not arrive at the health facility by the end of the next day, the facility based system will send a notification to the CHT central server indicating a ‘no show’. This generates a task for the CHW to follow-up with the patient and encourage them to visit the health facility.  If the patient does visit the health facility, various results from the visit are sent back to the CHW to be delivered to the patient. 

Process

1. Patient registered in CHT mobile app
2. Assessment done on patient
3. If assessment results in a referral, once the CHW syncs to the central server, this referral gets sent to the facility based system
4. Facility based system looks to see if the patient exists already (using an ID generated by the CHT), if not, creates this patient in the facility based system.
5.  Referral is added to patient
6. When patient arrives, check-in clerk looks up patient in facility based system and has access to referral information from the CHW
7. If after 24h the patient does not arrive, the facility based system sends a notification to the CHT central server and a task is created for the CHW to follow-up with the patient again
8. Once the patient arrives in the health facility, various activities initiated by doctor or pharmacist can be sent back to the CHW

CHT→DHIS2: Aggregate dataSet reporting (unidirectional)

Summary

Monthly DHIS2 Aggregate reporting, one way (CHT to DHIS2). CHWs perform their normal duties throughout the month and can see their aggregate totals for each indicator on the DHIS2 dataSet. At the end of the month, they must sync to the central server. Supervisors sync to receive these aggregate totals from each CHW and the Supervisor’s app also aggregates across the entire DHIS2 orgUnit. Supervisors can all see each CHW’s contribution towards a given indicator.  Once confirmed, a Health Records Information Officer can download a file from the CHT which is in the format required by DHIS2 and upload this file as a DHIS2 dataSet in their DHIS2 instance.  More details and documentation here. 

Process

1. CHWs perform their normal duties throughout the month, viewing their aggregate data while offline in their app
2. CHWs sync to central server
3. Supervisor syncs to receive each CHWs aggregate totals
4. Supervisor reviews totals across their catchment area
5. HRIO downloads file from CHT central server and uploads to DHIS2

CHT↔RapidPro: Multiple use cases (bidirectional)

Summary

Multiple integrations with RapidPro have been developed and are live in several countries. Details of several RapidPro integration use cases can be found here.

Use Cases

1. Client Initiated Health Assessments
2. Contact Tracing
3. Self quarantine
4. Remote training
5. CHW Symptom and Mental Health checks