Title: Provider Registry Architecture
Course: RHEA Provider Registry > Section: Provider Registry Architecture

Architecture Overview

Provider Registry is made up of several components:

- Data Store (LDAP and MySQL)
- Restricted Access to Data Store (Web Services and User Interface)

Data Storage -- LDAP

LDAP Data Storage is used to hold information about the provider and their postings

It is the only thing used by web services to query information on providers

The user interface reads provider and posting data from LDAP

Data Storage -- MySQL

Database storage is used by the provider registry user interface.

Database used to hold standardized lists:

- Facilities
- Administrative Units
- Jobs

Database used to store information in reports

Database is not used by web services.

Web Services

Web Services are written in PHP -- very simple and have an self-generated API.

Web Services are used only by the Health Interoperability Layer.

The Health Interoperability Layer (HIL) validates the National ID (NID) of an incoming HL7 message against the provider registry

Once validated, the HIL transforms the HL7 message to use the Entrerprise Provider ID (EPID)

Web services returns data in mutiple formats for client applications.

Two currently supported web services:

- Lookup the NID from the EPID
- Lookup the EPID from the NID

Planned services:

- Query a list of providers by facility
- Query a list of providers by cadre (e.g. a list of all doctors)
- Query a list of providers by specialization
- Query a list of providers by district
- Query a list of providers by qualification (HRHIS)
- Query a list of providers by type (e.g. CHWs or Paid Public Sector)
- Query a list of providers by name (which names?)
- Query a list of providers by nationality

User Interface

User Interface access both the database and the LDAP service

Provides a convienient method to search for and modify the provider data.

Based on the same I2CE framework that HRHIS and iHRIS uses

The I2CE framework was written in PHP,  JavaScript, XML, SQL,HTML and CSS

Framework handles much of the logic and page structure of the user interface

The provider registry user interface is composed of configuration, data structure defition, and HTML specific to the provider registry

LDAP versus MySQL

One of the main requirements for the provider registry is high throughput -- we need to handle 5,000,000 lookups per year.

Read speed is very important

Write speed is not so important -- the providers list does not change.

LDAP is optimized for very fast read.  Writing data can be slow.

MySQL is optimized for decent read and write -- neither is slow, neither is fast.

LDAP versus MySQL - secondary requirements

Seconday requirements of providing reports and search capabilities for provider registry.

As LDAP has limited query languange and slow write, we use the MySQL database for these things.

LDAP and Future Directions

LDAP was also chose for potential future applications.

OpenLDAP is a free and open source LDAP server.

OpenLDAP suports easy replication of the data stored in a "Master-Slave" relationship

We can make the LDAP webservices avaiable to the point of care applications:

- When a User is added their details can be pulled from LDAP if present
- We can store user roles in OpenMRS in LDAP to make centralized management of users easier

OpenMRS (or other point of care applications) need to be modified to support his.