Provider Registry Track 2

This page contains notes for the Provider Registry and iHRIS interfacing with the data warehouse and other systems under Track 2 for Rwanda.

Under the proposed Track 2 wor kplan there were a few main areas identified for further work on the provider registry. Further specification is needed, but based on what is known to date,

Track 2 Workplan

Data Warehouse

Quoting from the workplan:

The objective of this work package is to develop towards a data warehouse that receives and stores nationally representative data for evaluating the performance of the health services. The data warehouse will pull data from OpenMRS, iHRIS, TracNet, the HMIS (and other DHIS-2 instances), the Lab Information Systems, and other aggregate reporting and transactional systems (eg LMIS, Blood bank) by employing defined standards and interoperability interfaces.  It will also store historical data (since 2008) from the old HMIS.
*Develop interoperability profiles to pull data (or receive monthly batches) from the target systems (OpenMRS, iHRIS, TracNet, HMIS during phase 1).
*Define interfaces and communication standards for reporting profiles
*Create DW data interface that connects to the HIM
*Create new HIM channel that supports new interfaces

It is not clear to the PR team what the role of the DR

Status

Details to be filled in by Jembi/Rhonywn

OpenMRS Provider Module

The OpenMRS Provider Module is intended to allow a verification of providers in OpenMRS before HL7 messages are sent up to the HIM. Any providers which are not found in the PR can then me added to the PR.

Outstanding issues include:

• What is the work-flow for adding new providers to the PR? For example, suppose a new provider is working in a clinic and gets added to OpenMRS. If this person has not been processed by the MOH's HR unit, they will not appear in the PR. This is largely a policy question, rather than a technical question.
• Related to the above question, should we add the ability to add "unverified" providers? Should we enable this to be done automatically?
• There are two main architectural solutions under consideration, each with benefits and disadvantages:
  • The OpenMRS Provider Module access all provider information via PR web-services passed through the HIM
  • The PR uses an LDAP data store that can readily be replicated at the POC level at which OpenMRS could access the PR directly.

Status

Required data-fields for OpenMRS provider to be provided by the Jembi team.

iHRIS

To date only paid-public sector health care providers from the Rwamagana MCH use case have been entered into the system. The following (non-disjoint) data sets need to be added during the course of Track 2:

• All paid-public sector care providers
• Other districts

Much of the initial work here is determining the correct workflow and architecture for updating the PR from iHRIS. There are two main options here:

1. All updates for the PR happen via the HIM. Currently the PWP and HPD profiles are for querying the PR, not for updating the PR, so appropriate web-services would need to be defined.
2. All updates for the PR from iHRIS happen "outside" of the HIM. This is what was done for the initial population of the PR from iHRIS source data. It would not be an as robust solution as a web-services solution.

Note that the architecture adopted here should be the same/similar to what is adopted for the CHWs coming from RapidSMS (See below).

Status

Need to assess relative merits and development resources needed to define iHRIS and PR linkage and evaluate this within the RHEA architecture.

RapidSMS

RapidSMS provides source data for CHWs and all CHWs from Rwamagana district have been added to the PR under Track 1. This was done through a time-consuming process of merging the Excel spreadsheets before an import was done to the PR. It is not likely that this is a sustainable process.

A few questions we should answer are:

• How can we import the CHWs from the other districts? (Excel spreadsheets may be too time consuming)
• How can we update information on existing CHWs or add new CHWs?
• Are there any processes that the RapidSMS team follows when adding/registering a new CHW with RapidSMS that would make it easy to add them to the PR?
• Are there any use the RapidSMS team would have for information coming from the Provider Registry?
• The PR has a web-interface allowing for adding/updating provider information.
  • Should we expose this (with appropriate security restrictions) to RapidSMS?
  • If so, what would be the implications? Does this change the intended nature of the PR, as until now, it has been essentially just a queryable database and was not exposing write functionality publically.

Status

Reached out to in-country RapidSMS team to determine their needs and processes for updating CHWs.

PWP Profile Data Elements

Data elements from:

• [HIE's PWP]
• [HPD] [HPD]

should be queryable using LDAP.

PWP Required attributes are: PWP

• Cn: common name (Barbara Jensen)
• displayName: display name (Babs Jensen)
• sn: surname

HPDProvider Attributes

• hpdProviderStatus
• memberOf (professional organization...)
• hpdCredential
• hcIdentifier (National ID...)
• hcProfession
• createTimestamp
• modifyTimestamp