Send aggregate, patient, and event data to DHIS2
The CHT Core Framework includes functionality that allows sharing data with any API-based system. Developers have configured CHT integrations with OpenMRS, KenyaEMR, Bahmni, DHIS2, RapidPro, Apache NiFi, OpenHIM, custom electronic medical records (EMR), and several other systems.
Integrating a CHT App into your digital health ecosystem starts with identifying an integration use case. It’s important to first understand all the components present in the ecosystem (EMR, laboratory system, community health information system, etc) and then plan out what the workflow will look like operationally. It is important to consider what information is needed at each point, will it be available to them, what happens if it is not, is this workflow even useful for them.
One of the biggest challenges in developing integrations between systems is patient matching and/or deduplication. Sometimes this can be controlled operationally, other times it requires complicated algorithms or human intervention.
Below are a few example integration use cases:
- Lost to Follow-up: EMR generates a list of patients that require follow-up in the community, that list is sent to the CHT and healthworkers receive a task in the CHT to find those patients and refer them to the health facility.
- Referrals from the community: When a CHW does an assessment and determines the patient should be referred to a health facility, send the referral information to the EMR.
- Contact Tracing: Similar to Lost to Follow-Up, the EMR generates a list of contacts to be followed up with and this is sent to the CHT so that a tracer can call those contacts to see if they have symptoms.
- Interactive Messaging: Integrate with a messaging platform (such as RapidPro) to allow community members to initiate self-screening assessments, which can then be sent to the CHT for follow-up by a healthworker.
Integration Design Patterns
There are a number of different interactions that may occur between digital health systems. Below are some common use cases:
- Creating a patient in the CHT creates that patient in another system
- Creating a patient in another system creates that patient in the CHT
- Submitting a form in the CHT triggers an event in another system
- Submitting a form in the CHT sends data to another system
- Activity in another system triggers an event in the CHT
- Activity in another system stores the results in the CHT
- Another system needs to look up data in the CHT
Sending data to other systems
Using the outbound push feature, you can configure the CHT to send data to another system. Before starting, you’ll want to make sure you understand the APIs of the destination system and have login credentials with adequate privileges.
To send data to other systems from the CHT, you will need to do the following:
- Specify when data is sent
- Specify where data is sent
- Specify what data is sent
- Set up credentials for the destination system
mark_for_outbound transition in
When data is sent
Whenever a document is changed (such as submitting a form, creating a new contact, or editing an existing one) you can configure outbound to send data to another system. The
relevant_to property in the outbound configuration is used to identify which activities will trigger the sending of data.
ExampleSend data to the EMR whenever a CHW submits an
referral = true.
Where data is sent
destination property in the outbound configuration is used to specify where to send data. This will normally be the API endpoint of the destination system or interoperabiliy layer.
ExampleSend data to the
/api/v1/referralendpoint in the destination system.
What data is sent
You configure what data is sent using the
mapping property. You will map data from the CHT to the format required by the destination API endpoint.
contact.namefield in the CHT to the
patient.namefield in the EMR.
Credentials for the destination system are stored in CouchdDB. You will need to set this up before you can test your configuration.
Requests from other systems
The CHT has a complete RESTful API that other systems can utilize to interact with data in the CHT.
The most common uses are:
- Looking up data in the CHT from another system
- POSTing data to the CHT from another system
Look up data in the CHT
The CHT has a number of different API endpoints that can be used to look up data.
Example 1You have a patient’s phone number and you want to look up more information about that patient, such as who their CHW is or what Catchment Area they live in.
You can use the
contacts_by_phone endpoint will return the fully hydrated contact information for those patients.
Example 2You just have the internal UUID of a particular contact but want to get the complete information available for that contact.
You can use the
hydrate endpoint to obtain this information. to look up the complete information for that contact.
POST data to the CHT
The CHT API also allows you to POST data. Using these endpoints, you can create new records in your CHT API. You can store activities that took place in another system on that contact’s profile in the CHT, and even create tasks for CHWs in the CHT based on activities that took place in the other system.
Example 1You use RapidPro to send daily quarantine follow-up messages to a patient. You want to store the patient’s responses to those messages on their profile in the CHT.
You can do this by submitting a JSON Form to the records endpoint.
Example 2Continuing from Example 1, create a task for a CHW in the CHT whenever a patient responds that they have developed symptoms.
You would do this by simply configuring a task to be generated based on criteria available in the report that was created in Example 1.
Integrate interactive messaging conversations into your workflows
Exchange patient-level data with systems based on the OpenMRS platform
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.