You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

Work in progress

This is page is a work in progress. This info bubble will be removed once the TWG feels it is complete.


This page captures interoperability workflows that add value to Community Health Worker organizations.

User Personas

PersonaDescription
CHWCHWs are the central users of CHIS. CHWs conduct household visits and are responsible for the health of their community. CHWs are known and trusted locally and typically live in and are chosen by their community. Their degree of health training, responsibilities, and support depends upon their country and program. The majority of CHWs are women, ranging from 25-60 years old.
CHW SupervisorThe CHW supervisor is the person who trains and supports CHWs and helps them meet their monthly goals. Supervisors usually split their time between administrative duties at the local health facility and accompanying CHWs on their community visits.
Regional ManagerRegional managers provide overall oversight of activities in the region they are assign. They are employed by technical and implementing partners to oversee and provide general guidance for two or more branches in a region. They troubleshoot and provide support to branch managers to optimise operations. They have limited interactions with end users but provide the link between field operations and the head office.
NurseNurses are stationed at the health facility and spend their days seeing patients. They are typically very busy and may see 50 or more patients a day. At the clinic, they sometimes deal with staff shortages, stock-outs, and poor internet connectivity. They help train and manage CHWs, particularly during monthly meetings at the facility. They are interested in seeing improvements in health metrics for the areas their facility serves.
Data ManagerData Managers are often based at a regional health facility or a program or administrative unit and serve many local facilities. They are responsible for collating and reporting on community and health system data. Their work often involves following up with supervisors and nurses to verify data and retrieve missing information.
App BuildersApp builders and technical organizations develop, deliver, and maintain software contextualized to meet their needs.

Interoperability Patterns from Experience

Anonymous Events from CHIS to DHIS2

  • Goal: Track individual events from the CHIS so that it can be tracked against a programme in DHIS2.
  • Steps:
    • Each form from the CHIS gets anonymized
    • Each anonymized form pushes to DHIS2 Tracker

Monthly Reports from CHIS to DHIS2

  • Goal: Ensure monthly trends in the CHIS are captured and reported in the central reporting system by programme
  • Each DHIS2 data element is broken down to category options
  • Steps:
    • On a regular schedule the CHIS compiles a large report based on the data in the system
    • The large report gets converted to the DHIS2 format
    • The report gets sent over to DHIS2 which populates the aggregate information in the system

Pull data to CHIS from EMR for follow-up

  • Goal: Get a list of people who need to be followed-up in the community and follow up in the CHIS. Any changes in the CHIS go back to the EMR
  • One CHIS to many EMRs that are specific to a region
  • Steps:
    • EMR generates a report on a regular schedule
    • CHIS queries the report and creates the "cases" for follow-up in the CHIS
    • CHWs work through the list
    • Updates for each "case" is pushed to the EMR

Bidirectional duplication of programmatic patient data between CHIS and EMR

  • Goal: Ensure that both systems have a copy of the appropriate information so it is locally available for the defined interoperability workflows
  • Steps CHIS to EMR:
    • User collects a form in the mobile app
    • Mobile app syncs to the central system
    • CHIS Central system identifies that there is a form that needs to go to the EMR
      • Each different type of CHIS form has a different action.
      • Additionally, the state of the case vs the EMR patient is considered at each integration point
    • CHIS Central system queries EMR to verify state
      • Does the patient exist
      • What's the latest record
    • CHIS Central system compares the EMR state against the current state
      • If no difference, then they stop the workflow here
    • CHIS Central system orchestrates the multistep process of creating entities in EMR
      • 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 CHIS case for that patient
    • CHIS Central system closes out the connection and marks it as done.
  • Steps EMR to CHIS:
    • CHIS queries the OpenMRS atom feed for each entity type (patient, encounter, observation) on a regular schedule
    • CHIS loops through each item in the atom feed and queries the EMR system
    • CHIS 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 EMR has the latest information
    • CHIS marks the atom feed item as processed and saves state on each entry

CHIS to EMR Referral Workflow

  • Goal: 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.
  • Steps:
    • User collects a form in the mobile app
    • Mobile app syncs to the CHIS central system
    • CHIS Central system identifies that there is a referral that needs to go to the EMR
    • CHIS Central system creates the referral package by mapping incoming form submission fields to the output(s)
    • Central system sends the package(s) to the EMR
      • Note: This may require creating multiple entities in the EMR and the CHIS 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.
    • EMR receives the package and confirms that it was received
    • EMR parses each package and stores them in the system
    • EMR may trigger internal events based on this changing information

CHW Supervision Workflow

  • Goal: Provide the appropriate information for supervisors so they can understand the inputs and outputs of the CHWs. Interoperability in this case supports identifying the original source of truth.
  • Mapping between these systems is critical to ensure that each patient or case is assigned to the right team in the CHIS. There needs to be a clear path to the community health worker.
  • Steps:
    • The case is created in the CHIS based on whatever input
    • Mapping is done so that we appropriately map the case to the right health worker in the CHIS
      • This mapping is often done by geographic information or identifier patterns. For example, we know that ids from this EMR need to go to this CHW team in the CHIS
    • We duplicate case properties in the CHIS to be able to represent

Integration Setup and Maintenance

  • Every integration requires setting up the system the first time and then maintaining the metadata over time.
  • Setup requires the following:
    • Map metadata:
      • Administrative Locations
      • Catchment Area Locations
      • Points of Interest (Facilities)
      • Programmes
      • Forms
      • Form fields
      • Large lists
      • Identifiers
    • Establish connections
    • Test the connection in a staging environment
  • Maintenance requires the following:
  • No labels

This work is licensed under a Creative Commons Attribution 4.0 International License.