Liberia-mHero-eIDSR-Documentation: Difference between revisions
(2 intermediate revisions by the same user not shown) | |||
Line 121: | Line 121: | ||
===Sample Pickup & Delivery by Riders=== | ===Sample Pickup & Delivery by Riders=== | ||
If a case alert by a health worker is associated with a sample for testing,then an alert goes to riders telling them to quickly go at the facility for sample collection to the Lab. Immediately after riders have delivered a sample to the lab,they are also needed to send an alert that they have delivered a sample to a lab. More about these two usecase can be found on this video tutorial here - https://youtu.be/-2K3qkmi6gU | If a case alert by a health worker is associated with a sample for testing,then an alert goes to riders telling them to quickly go at the facility for sample collection to the Lab. Immediately after riders have delivered a sample to the lab,they are also needed to send an alert that they have delivered a sample to a lab. More about these two usecase can be found on this video tutorial here - https://youtu.be/-2K3qkmi6gU | ||
===Weekly Report=== | |||
All facilities are required to send an aggregate number of all cases in a week,even if they had zero cases in a week. This video tutorial - https://youtu.be/PijcxiFmIYY has extra details about this usecase and the rapidpro workflow that handles this usecase. Below is a sequence diagram of this usecase | |||
[[File:Weekly_Report.png | 1000px]] | |||
===Weekly Report Reminders=== | |||
openHIM also has a mediator that searches for health facilities which didn't send their weekly reports and then sends them a reminder. This video tutorial - https://youtu.be/PijcxiFmIYY has extra details about this usecase and the rapidpro workflow that handles this usecase. below is a usecase diagram that explains the whole process. | |||
[[File:Weekly_Report_Reminder.png | 1000px]] | |||
== eIDSR Troubleshooting tips == | |||
This video tutorial https://youtu.be/2tzwjoKAHAw has summarized the procedures to follow to troubleshoot some issues that may happen to eIDSR. |
Latest revision as of 13:21, 15 January 2018
Introduction and Overview
mHero is a free SMS mobile phone based communications system between MOH staff,Health Workers and Community Health Workers. This is achieved by the interoperability between Intrahealth's iHRIS (or any HRIS with CSD compliant) and UNICEF's Rapidpro and utilizing the OpenHIE architecture. The platform uses health workforce data to target specific communications based on cadre,location and other information. Communications, which can be triggered both centrally and locally, go far beyond traditional “message blasts” offered by many technology vendors. Real-time monitoring, complex multi-path surveys, monitoring and detailed analysis can be conducted with ease. This tutorial will use iHRIS as a HRIS. Addition of disease surveillance component into mHero is what creates eIDSR.
This documentation will concentrate on the connection of iHRIS, openInfoMan, Rapidpro to make mHero and then the connection of Sync Server (Disease surveillance system) into mHero to extend it to eIDSR.
Below is a sequence diagram of what the documentation will cover.
Brief overview of Components
- iHRIS-it is an integrated Human Resource Information System which is used to track and manage health workforce data.
- Rapidpro-is a free and open source framework designed to send and receive data using basic mobile phones, manage complex workflows, automate analysis and present data in real-time.
- Health Worker Registry/openInfoman - It is an OpenHIE component used to bring health workforce information together from variety of sources and represent that information in a common format against a common standard in order to facilitate the use of health workforce information across the health information system. Health Worker Registry is implemented by Openinfoman,this documentation will be using the two terminologies interchangeably.
- OpenHIM - a component that provides security and access control mechanisms for mHero
About the OpenHIM
OpenHIM stands for the Open Health Information Mediator. The OpenHIM is an interoperability layer: a software component that eases integration between disparate information systems by connecting client and infrastructure components together. Its role is to provide a facade to client systems - providing a single point-of-control for defining web service APIs and adapting and orchestrating requests between infrastructure services. While doing this the OpenHIM also provides extensive security and access control mechanisms that enables the user to protect personal information within an HIE. It also enables monitoring and alerting services to ensure that the HIE is always running optimally.
OpenHIM security and privacy
Privacy and security are vital components of a coherently designed HIE. The OpenHIM is a cornerstone on which HIEs are built and it specialises in managing the interfaces on which systems interact with the HIE and on which components of the HIE communicate with each other. Therefore, the OpenHIM employs a number of mechanisms to ensure that traffic to and from an HIE is kept private and secure.
The OpenHIM provides the following features to ensure that personal information is protected:
- It makes it easy to ensure that traffic coming to the HIE or within it is encrypted. It does this by providing a certificate management facilities.
- It provides authentication mechanisms to ensure that only systems that are known and trusted can access the HIE services.
- It provides access control mechanisms to ensure that only systems that actually need access to certain services are allowed to access them.
How the OpenHIM fits into the mHero architecture
Within the context of mHero, the OpenHIM performs a few vital functions.
- It triggers the synchronization between iHRIS, OpenInfoMan and Rapidpro.
- It provides visibility into the messages being exchanged. This allows the user to ensure that the data exchange is occurring correctly.
- It ensures that the communication between components occurs securely and it logs the transactions for historical and audit purposes.
- It provides authentication and authorisation mechanisms to control access to the OpenInfoMan documents
The OpenHIM provides polling channels to trigger the synchronization between iHRIS and the OpenInfoMan. These polling channels execute periodically and trigger an mHero mediator which in turn pulls data out of the OpenInfoMan and pushes it into RapidPro. To learn more about polling channels please see the OpenHIM docs here.
The OpenHIM provides a web console that enables the user to view these synchronization message. This enables any problems to be debugged effectively and provides confidence that the synchronization is working effectively.
The OpenHIM was designed to protect an HIE by providing mechanisms to secure transactions between various components of the HIE. It can ensure that requests that access certain OpenInfoMan documents come from known and authorised sources.
Within mHero, the OpenInfoMan contains a number of documents which contain health worker and facility information. The OpenHIM prevents unauthorised access to these documents by implementing a role-based access control mechanism. This allows documents with sensitive information to be secured and documents with non-sensitive information to be as open and accessible as necessary.
Installation
openHIM Installation
Configuring the OpenHIM to work with mHero is fairly straightforward. A debian package has been created that will automatically configure the OpenHIM for the mHero context. This takes care of most of the configuration that is require. You can find this package here: https://github.com/jembi/openhim-config-mhero.
To install it simply execute the following on server to host the OpenHIM:
<source lang="bash"> sudo add-apt-repository -y ppa:openhie/release sudo apt-get update sudo apt-get install openhim-console openhim-core-js </source>
After that the OpenHIM console will be accessible on http://localhost. For more information about how to use the OpenHIM console and edit the base configuration, see http://openhim.readthedocs.org/en/latest/user-guide/index.html.
iHRIS Installation
iHRIS can be installed by referring to its installation page which is http://wiki.ihris.org/wiki/Installing_iHRIS_4.2
openInfoman Installation
openInfoman can be installed by referring to OpenInfoMan installation page which is https://github.com/openhie/openinfoman
After openinfoman is installed,Additional libraries will also need to be installed to extend the functionality of openInfoMan. Below are the extra libraries
- openinfoman-dhis available in here https://github.com/openhie/openinfoman-dhis
- openinfoman-hwr available in here https://github.com/openhie/openinfoman-hwr
- openinnfoman-rapidpro available in here https://github.com/openhie/openinfoman-rapidpro
- openinfoman-liberia available in here https://github.com/openhie/openinfoman-liberia
Rapidpro Installation
If you want to run your own instance of Rapidpro,you may refer to http://rapidpro.github.io/rapidpro/docs/development/ for the guide on how rapidpro can be installed.
Linking iHRIS,Rapidpro and OpenInfoman.
To setup mHero, iHRIS,Rapidpro and OpenInfoman needs to be connected together. There are two connections in here:
- Connecting iHRIS and OpenInfoman
- Connecting OpenInfoman and Rapidpro
- Push all Health workers to Rapidpro.
- Pull all created Rapidpro contacts back to OpenInfoman.
Connecting iHRIS and OpenInfoman.
Publishing iHRIS Data For Use In eIDSR and mHero
The OpenInfoman is built on an international standard called Care Services Discovery (CSD). So to connect iHRIS and OpenInfoman,it will need to make iHRIS data to conform to CSD and then this data can be loaded to OpenInfoman. This video tutorial - https://youtu.be/8RRhPAF5kVI explains the role of iHRIS in eIDSR like
- What does it need for a health worker to send an alert
- What does it need for DSO,CSO and CDO to receive alerts coming from their respective facilities
- How iHRIS data can be published in CSD standard for being shared to openInfoMan for eIDSR to work
- How openHIM can trigger iHRIS to generate a cache of its records in CSD format
More details about CSD caches in iHRIS can also be found in here https://www.youtube.com/watch?v=oxmRhW4Q2T4&t=21s.
Fetching iHRIS Data with openInfoMan
iHRIS Generated and published CSD documents can then be pulled by OpenInfoman, and this video tutorial - https://youtu.be/yVk-bHX_X-U shows how openInfoman can be triggered to fetch data from iHRIS for use in eIDSR and mHero. This youtube video - https://www.youtube.com/watch?v=ev-my7-ZQ0I explains how to configure OpenInfoman to pull iHRIS published CSD data.
The simplest way of saying all of the above is that,iHRIS publishes health worker data in CSD format and OpenInfoman subscribes to the iHRIS CSD data.
Connecting OpenInfoman and Rapidpro.
After iHRIS data being fetched by openInfoMan,then health worker data that has phone numbers will need to be created as contacts in rapidpro,this will enable health workers to send SMS to eIDSR and mHero. An openHim Mediator called openhim-mediator-mhero-liberia have been developed to perform a task of fetching all health workers from openInfoman,create them as a contact in rapidpro and then take back all rapidpro created contacts to openInfoMan.
Installation and configuration of this meadiator have been documented on this video tutorial - https://youtu.be/R-jyJakPFQo
This mediator can be run using steps on this video tutorial (explained starting from 9:28 minute) - https://youtu.be/yVk-bHX_X-U
The whole process above of publishing iHRIS data,fetching iHRIS data by openinfoman and creating health workers as a contact into rapidpro,is summarised in this video tutorial here https://youtu.be/Cv-hRuffM_U
Role of Rapidpro in eIDSR
Rapidpro is the first entry point of all case alerts from heath workers. This video tutorial - https://youtu.be/EatIILEs6_E explains the role of rapidpro in eIDSR and what does it need for a health worker to communicate with rapidpro.
eIDSR Usecases and Rapidpro Workflows
Case Alerts
This is the main usecase of eIDSR in which a case alert is submitted by a health worker and then other people like DSO,CSO,CDO,DPC and HMER are alerted. below is a web sequence diagram that explains about this usecase.
In the usecase above,District Surveillance Officer stands on behalf of every one else like County Surveillance Officer,County Diagnostic Officer and others.
This video tutorial - https://youtu.be/3lBjaKIyhds has in depth explanations about this usecase.
Sample Pickup & Delivery by Riders
If a case alert by a health worker is associated with a sample for testing,then an alert goes to riders telling them to quickly go at the facility for sample collection to the Lab. Immediately after riders have delivered a sample to the lab,they are also needed to send an alert that they have delivered a sample to a lab. More about these two usecase can be found on this video tutorial here - https://youtu.be/-2K3qkmi6gU
Weekly Report
All facilities are required to send an aggregate number of all cases in a week,even if they had zero cases in a week. This video tutorial - https://youtu.be/PijcxiFmIYY has extra details about this usecase and the rapidpro workflow that handles this usecase. Below is a sequence diagram of this usecase
Weekly Report Reminders
openHIM also has a mediator that searches for health facilities which didn't send their weekly reports and then sends them a reminder. This video tutorial - https://youtu.be/PijcxiFmIYY has extra details about this usecase and the rapidpro workflow that handles this usecase. below is a usecase diagram that explains the whole process.
eIDSR Troubleshooting tips
This video tutorial https://youtu.be/2tzwjoKAHAw has summarized the procedures to follow to troubleshoot some issues that may happen to eIDSR.