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 ↔ RapidPro Integration

OpenSRP has a deep point-to-point integration with RapdiPro in a couple implementations so that users can submit data via SMS to create patients and collect health information in OpenSRP, OpenMRS and the dashboard.

The system consists of 4 main parts:

• The end user: The end user sends a message via a mobile device to an SMS short code. The short code is then received by RapidPro for processing.
• RapidPro: This is the system that received the SMS messages from the CHW and validates the information against the expected syntax. It also manages the SMS flow and performs relevant validation checks before forwarding to the Canopy system.
• Canopy: This system converts and translates the coded messages based on the code card. The code card is a set of SMS syntax that the VHW references in order to send the required messages.It also forwards the data between the other connected systems. Canopy also contains the data warehouse, which the Analysis component depends on, and the Superset Dashboard, used to create and develop indicators that can be easily viewed and filtered. This set of systems consists of data tools that include RapidPro, NiFi, and Superset and PostgreSQL. 
• OpenSRP (Health Data Store): This is where all the client and health related data is stored. This is a centralized server that will integrate the mobile app.

The diagram shows 2 categorizations of the system components, namely Canopy and OpenSRP (Health Data Store). 

• Canopy is a set of solutions that provide robust data analytics for the data set. It is comprised of the below open systems 
• RapidPro: A messaging agent that caters for communication via various social channels and SMS. RapidPro is the system that handles all SMS and chat API communications with the relevant logic to validate the content of the messages. It also handles contact information and minimal access control. 
• NiFi: A mediation system that enables ETL functionality and workflow logic.
• Superset: A business intelligence and analytical tool that allows dynamic dashboards through an easy to use interface.
• Health Data Store is a set of systems that stores the health records.
• Web Dashboard: This is a web application that enables the data to be viewed by the end user. It has the logface, compartments, and analysis tab.
• OpenSRP CHW Application: This is a mobile app that can be used by the Village and Commune health workers.
• OpenSRP: A web server and lightweight EMR that stores and synchronizes data for the mobile app.
• OpenMRS: An heavyweight EMR solution, with a full user interface, that enables the use of data in a traditional EMR environment.

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