...

• 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 ↔ OpenHIM

CommCare is importing data from a DHIS2 server through an OpenHIM mediator.

Point-to-Point ↔ DHIS2 connection for Aggregate and Tracker

...

Malaria Consortium upSCALE: Mozambique

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

Workflow

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 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 Consortium, 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.

Access (aka MSANP, Mikolo): Madagascar

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

Workflow

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 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 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 <--> OpenMRS
CommCare Case <- OpenMRS Report
CommCare Case + Form -> OpenMRS Patient + Observations

Workflow: CommCare <--- OpenMRS

1. Once a week CommCare retrieves a report from OpenMRS using its Reporting API.
2. Report columns are mapped to case properties
3. Cases are created or updated (based on whether their "external_id" property already exists) and mapped case property values are set.

Workflow: CommCare ---> OpenMRS

1. A mobile worker submits a form
2. CommCare form questions and case properties are mapped to OpenMRS Patient properties, Visit properties, Encounter properties and Observations.
3. OpenMRS patients are never created, because all CommCare cases have been imported from OpenMRS
4. A workflow of requests to the OpenMRS API is followed:
   1. Update identifiers
   2. Update "preferred name"
   3. Update "preferred address"
   4. Update other standard properties
   5. Update custom attributes
   6. Create Visit
   7. Create Encounter
   8. Create Observations
5. The original state is stored until the workflow is complete, and a failed API call will roll back the workflow by reversing the requests.
6. The OpenMRS server is selected based on the location of the mobile worker.

Project Summary

In order to automate workflows, Dimagi has supported the Center of Disease Control to develop a two-way integration between OpenMRS and the Infomovel (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 (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.  

Once a week CommCare pulls patients that meet the program participation criteria from all active OpenMRS instances.

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 if they change.

Possible Health: Nepal

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

Workflow: CommCare <--> OpenMRS

1. A mobile worker submits a form
2. CommCare form questions and case properties are mapped to OpenMRS Patient properties, Visit properties, Encounter properties and Observations.
3. OpenMRS Patients are searched and matched with CommCare cases. If no definitive match is found, a new Patient is created.
4. The Patient's system-generated ID (as opposed to national ID or facility ID) is saved to the CommCare case as unique, indexed "external ID".
5. The standard OpenMRS workflow is followed
6. The OpenMRS server is selected based on the location of the mobile worker.

Workflow: CommCare <--- OpenMRS

1. CommCare polls the OpenMRS Patient, and Encounter Atom feeds. Atom feeds list the IDs of new and modified Patients and Encounters.
2. CommCare fetches an OpenMRS Patient details, matches the Patient with a case on CommCare external ID, and creates a new case if one is not found.
3. New CommCare cases are assigned to a supervisor for the facility's location, who will allocate cases to mobile workers.
4. Case properties are set from values from Patients and the Observations of Encounters.

NOTE: CommCare form submissions can create OpenMRS Observations, but the reverse is not true: Observations set CommCare case property values; they do not submit forms of a CommCare app.)

Project Summary

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 exported to OpenMRS (and Bahmni, the hospital management system built on top of OpenMRS) based on their location. When cases are updated, their OpenMRS records are updated too.

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.

KEMRI: Kenya

CommCare <--> OpenClinica

Workflow: CommCare <--- OpenClinica

1. A CommCare app is generated from an OpenClinica Study Definition

Workflow: CommCare ---> OpenClinica

1. At the conclusion of a clinical study, a pre-defined report is exported to OpenClinica over an API in CDISC format

Unidirectional OpenSRP → OpenMRS Integration

...