Skip to end of metadata
Go to start of metadata

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 focuses on creating a working definition of Community Health Information Systems (CHIS) and the actors who use these systems. This will be adjusted when the Delphi study results complete.

What is a CHIS?

A Community Health Information System (CHIS) is an information system that supports the routine and emergency health care of a patient population within community contexts in defined geographic areas. CHISs target supporting patient and population health where there is minimal physical health infrastructure in order to support universal health coverage.

Who uses a CHIS?

The following actors are important within a CHIS ecosystem:

  • Patient
  • Patient's relatives/family unit
  • Community Health Worker
  • Field Supervisor

These actors are defined in the User Personas section of the Interoperability workflows

Functional specifications

Notes: (Model this section off of https://ohie.org/architecture-specification/)

Community Health Information Systems focus on supporting healthcare provided in the community context and have different functional requirements than electronic medical record systems that are targeted for deployment in brick and mortar health locations. This section defines the functional specifications for a CHIS.

Craig wrote these on 21 Dec - They are unordered, just to get some thoughts out there.

#CHIS Functional RequirementRecommended/Required
CHIS-1

The system shall support synchronization and local caching of the appropriate information in order to support the full health workflows that are required for that patient's needs completely offline for long periods of time. 

Required
CHIS-2

The system should support the full lifecycle management of location-based information for key administrative areas, structures, and points of interest that aid in the full management of care coordination. This location information shall include the ability to collect GPS geometries in point, polygon, or multi-polygon format so they can be displayed on a digital map.

Examples include:

  • Administrative boundaries required for lines of reporting
  • Health facility location GPS points
  • Geometries for patient homes in point, polygon, or multi-polygon formats
  • Distribution points or local gathering places where services are centrally located
Recommended
CHIS-3The system shall support regular automated attempts to access the internet to sync.Required
CHIS-4The system should compressing information in minimal format when exchanging it between the centralized system and the point of service device in order to reduce the costRecommended
CHIS-5The system should support enterprise mobility management (EMM) solutions to support the remote deployment of updates, enforcement of business and security policies, and monitoring of internet access costs.Recommended
CHIS-6The system shall support the orchestration of activities among the workforce so that community health workers are appropriately managed by their frontline management team. This includes providing views of health worker activity, supporting feedback loops with information through reports, and orchestration of activities natively within the system.Required
CHIS-7The system shall have a clearly defined process for managing conflicts in data submissions in order to robustly handle asynchronous submissions when front line devices have been offline for long periods of time.Required
CHIS-8The system should support syncing information between devices that are both offline (Peer-to-Peer sync)Recommended
CHIS-9The system shall provide robust reports that track the time lag between data collection to submission in important views so that managers clearly see sync activities. Required
CHIS-10The system shall have functions that support the privacy and security of personally identifiable information including user management, access controls, and auditing. This includes the ability to set up and manage users, permissions for reading data, writing data (posting, validation, publishing), viewing data, and system administration.Required
CHIS-11The system should support the regular synchronization of appropriate information between the central server and a health information exchange to support the workflows required in this contextRecommended
CHIS-12The system should support the generation of "official" standardized reports from the point of service to the central system that supports stakeholder needs.Recommended
CHIS-13The system should be able to be deployed on premise within a country context to support data sovereignty laws that are applicable to the contextRecommended
CHIS-14The system should have flexible standards-based APIs, preferably RESTful.Recommended
CHIS-15The system should have the ability to pull and/or push data to other systems based on defined criteria to a standardized format such as CSV, DXF2, JSON, XML, etc.Recommended
CHIS-16The system should generate standard and customizable reports in line with the core CHIS attributes.Recommended
CHIS-17The system should support a minimum set of data attributes as defined by the CHIS CoPRecommended
CHIS-18The system's point of service interface should support the needs of low-skilled health workers, providing decision support tools that measure and ensure quality of care is provided.Recommended
CHIS-19The system should support mechanisms to longitudinally track and manage the care of a patient and population within the assigned context.Recommended
CHIS-20The system should support modeling teams so that information about a given patient can be updated by any of the actors on the team. This allows frontline health workers and managers to ensure the continuity of care even if an individual team member is not able to provide it as scheduled.Recommended
CHIS-21The system shall support operating on low cost mobile devices that can be deployed at scale.Required
CHIS-22The system should be able to collect codes that link to standardized terminologies that support interoperabilityRecommended

Additional discussion on this page

  • Metadata alignment with standardized names
    • Looking at API output and xform metadata tags across systems.
    • Looking to identify the data elements that are helpful in composing the analysis that are being defined for visualization.
      • Thinks that establish context like where, when, and by whom the work is being done.
    • There are also tags that are captured in the forms for each system.
    • Not the value of the field, but the system name for the value that's being collected.
  • No labels

1 Comment

  1. Designing CHIS applications for interoperability – It is helpful to consider CHIS apps as mini-EHRs and to design them with the consideration that CHIS apps would be part of a network of CHIS  to compose the longitudinal record of patients needed for proper and informed care of the patient.  For this reason, it would be helpful to leverage interoperability profiles for the front-end metadata definition, valid values, and taxonomies at the point of data capture to minimize the data quality and data mapping need in the backend.    See below the CHIS projects that need to be connected to a network to support the creation of 360-degree information for Community Health Workers.  A key question to consider is how suitable are these applications in a health information exchange architecture versus health information mediation architecture?