This page captures proposed architectures and workflows for supporting the CHW Interoperability Workflows.

Architectural Components

• Mobile App - This is the primary data entry point for the CHIS users.
• Central System - This central system is used to manage the mobile deployment, house all information collected, and ensure that the right information is synced with for the right users devices. Examples include CommCareHQ, OpenSRP Server, and CHT Core.
• Web Ui - This is the web interface with which users interact with the system. This Web Ui can be used for management of the system, health worker performance, basic reporting, and primary data collection.
• (Optional) Extract Transform Load (ETL) Tool - This is a tool that's responsible for extracting transactional information from the central system, normalizing it and loading it into the Data Warehouse.
• (Optional) Data Warehouse - This is a normalized data repository that is focused on providing performant analytics and reporting
• (Optional) Data Visualization Tools - These are tools that help end users make sense of information in the system with minimal programming involved. Tools in this category include Power BI, Tableau, and Superset
• Facility Based Electronic Medical Record System - A facility based electronic medical record system

Core Thoughts

• CHWs are often linked to working out of a centralized physical brick and mortar location where their management sits. This could be a district hospital, primary health facility, or other
• We often need to sync information with a facility based EMR to provide medical record continuity between the CHIS and facility based care

Assumptions

• Every system needs to have a full representation of a person or patient locally within their system.
• There's business logic that needs to be executed on both sides of an integration for each system. Each system is responsible for receiving the content, parsing it and storing it appropriately within the system.

Notes on Architecture:

• We need to consider the process of patient de-duplication in both systems.
  • We probably assume that the receiving system will handle this. In a point to point integration, we would need to return a response in the case there's a high likelihood that they are the same patient.
  • How much data do I want to store in my system about the patient's state in another system? ← This is a big question.
• Considerations:
  • Only sync what you know you need to sync.
    • You could send a bundle, which would be great for the sending system.
    • Being able to create a bundle is hugely important for the sending system. The receiving system will need to break down that bundle, loop through each item and then
• General points:
  • Sending side support
    • Needs to package a bundle
  • Receiving side support
    • Break down a bundle
    • Return a response of failed in the event there's a parsing error in the bundle
  • Most of our integration requests are for sending DHIS2 aggregate information
  • We need to determine if we want to send a standardized document or just particular transaction
    • We send the limited things that we know will be used by the receiving end.
• Big problems to solve:
  • What does the sending system care about in the case of duplicates in the receiving system?
  • What information do you want to store in the sending system to make it easier in the receiving system?
  • From a project perspective, who takes on the responsibility of implementing the requirements in the receiving system?
    • For OpenMRS there's a multiple stage process
    • For DHIS2 there's a two stage process

Point to Point FHIR Interoperability

HIE Mediated FHIR Interoperability