This page presents real world integration experiences that the team has collated. This information serves as background to help others understand some of the values and workflows created by this TWG.

Bidirectional OpenMRS ↔ CommCare Integration

Dimagi built a point-to-point connection between CommCare and OpenMRS using the existing APIs. OpenMRS is the source of truth for this integration. The workflow focuses on exporting a list of people for community follow-up and entering them in to CommCare. Information collected in CommCare gets sent to OpenMRS as encounters and observations. CommCare is not responsible for creating new patients as part of this workflow.

Setup:

• Map CommCare form to the appropriate OpenMRS entity (Patient, Encounter, Visit, Observation, Person)
• Build orchestration workflow
• Activate atom feed

Generic Steps for CommCare Central System → OpenMRS:

• User collects a form in the mobile app
• Mobile app syncs to the central system
• Central system identifies that there is a form that needs to go to the third party system
  • Each different type of CommCare form has a different action.
  • Additionally, the state of the case.xml vs the OpenMRS patient is considered at each integration point
• Central system queries OpenMRS to verify state
  • Does the patient exist
  • What's the latest record
• Central system compares the OpenMRS state against the current state
  • If no difference, then they stop the workflow here
• Central system orchestrates the multistep process of creating entities in OpenMRS
  • Create a patient if it doesn't exist (this also creates a person)
  • Start a visit
  • Create an encounter
  • Create observations
  • End the visit (within a 24 hour period)
  • Store appropriate duplicate information in CommCare case.xml for that patient
• Central system closes out the connection and marks it as done.

Generic Steps for OpenMRS → CommCare Central System:

• CommCare queries the OpenMRS atom feed for each entity type (patient, encounter, observation) on a regular schedule
• CommCare loops through each item in the atom feed and queries the OpenMRS system
• CommCare identifies the changes, runs through logic and applies the changes locally
  • Create cases for new patients
  • Create form submissions for new encounters
  • Update case properties in the event OpenMRS has the latest information
• CommCare marks the atom feed item as processed and saves state on each entry

Additional Notes:

• These transactions need to be rolled back if there's a failure partially through
• We need to identify which system should win in the event that there's a conflict
• We replay the event submissions across both systems in the order they were received because the state of a single variable or observation may have changed multiple times and the last one in generally wins.
• Users often duplicate properties so they can see everything in one place instead of overriding properties generated in their system. So, they would add "openmrs_" properties to each case so it's clear the latest version of a field from OpenMRS

Referral Workflow

Referrals are when a patient is referred from a community to a central health facility or visa versa so that they can receive care that that team can provide. Referrals are a package of information sent from the CHIS to the EMR in this instance.

Generic Steps:

• 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

CommCare is responsible for collecting and sending individual transactions to DHIS2 tracker. There is also a general pattern used to send regular reports from a central system to DHIS2.

Unidirectional OpenSRP → OpenMRS Integration

OpenSRP is responsible for sending data to OpenMRS in a number of implementations. The primary use case is to exchange health worker information from the local OpenSRP facility based app to a central instance of OpenMRS. This workflow is the same as identified in the Bidirectional OpenMRS → CommCare Integration above.

Bidirectional OpenSRP/CHT ↔ RapidPro Integration

Bidirectional Referrals OpenSRP CHW App ↔ OpenSRP Facility Based App

Link: https://smartregister.atlassian.net/wiki/spaces/Documentation/pages/1156251738/FHIR+Task+Based+Referrals+Software+Requirements+Specification

Generic Steps:

• 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 Trace Reports for Lost to Follow-up and Contact Tracing