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 as well as higher
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.
Each CHIS has to have a FHIR REST API that conforms to the specification.
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
There is a difference between the syntax of the interoperability and the content that gets sent over.
HIPAA in the back of our minds as ownership.
We can use data about the patient we need so we can match patients, but only send the data that we need to send over.
What data are you looking for? We provide that and then send it over.
What about authorization and access to information within roles?
We are all dealing with Community Health Workers and their use cases. Either CHWs are registering patients or they have a set of patients already.
If you already have a set of patients, they come from somewhere with system generated ids and primary keys, making it easy to sync.
We should explicitly call out the semantic vs syntactic interoperability so it's clear for people to understand when they see this work.
The primary use case would be to implement CHIS to facility, but we don't know if there's a difference between syncing with a facility.
Who owns the routing of information?
Push, Pull and PubSubHub architecture
If you push, you need to support retries and acknowledgement
Does OpenHIE have an opinion on this?
Our FHIR API may need to:
Support providing state at each version of the resource
We need a way of identifying all of the version changes for each resource since a point in time
We don't know if this is a hard requirement.
Our systems could
Add a Clinical Data Repository
Façade API in front of an existing API that's custom
Notes on content
Locations where people live are important
This can drive analytics in the future
Who lives at each location
Point to Point FHIR Interoperability
CHIS to 3P System
Setup a regular schedule
CHIS identifies the last time that the data was pulled or page that was pulled