DWAPI Architecture

NDWH APIs consists of the following Endpoints running as separate services for the respective Docket:

1)Care and Treatment

This API Service exposes the following REST endpoints that accepts messages transmitted by DWAPI Client;

  • Subscriber Verification Endpoint – Authenticating and validating DWAPI client.
  • facility Verification Endpoint – Verifying facility MFL Code
  • Pertinent Extracts Endpoints for each of the following extracts as defined in the data dictionary:
  • All patients extract
  • ART patient extract
  • Patient baselines
  • patient status
  • patient labs
  • patient pharmacy
  • patient visits
  • Adverse events extracts

 

2)Master Patient Index

This API Service exposes the following REST endpoints that accepts messages transmitted by DWAPI Client;

  • Subscriber Verification Endpoint – Authenticating and validating DWAPI client.
  • facility Verification Endpoint – Verifying facility MFL Code
  • Master Patient Indices Endpoint – Accepts PKV message as defined in the data dictionary

 

3)HIV Testing Services

This API Service exposes the following REST endpoints that accepts messages transmitted by DWAPI Client;

  • Subscriber Verification Endpoint – Authenticating and validating DWAPI client.
  • facility Verification Endpoint – Verifying facility MFL Code
  • HTS Client Extracts Endpoints for each of the following extracts as defined in the data dictionary:
  • HTS Clients
  • HTS Client Test
  • HTS Client Linkage
  • HTS Test Kits
  • HTS Client Tracing
  • HTS Partner testing
  • HTS Partner notification services

DWAPI API Mechanics

All the endpoints will receive messages for each of respective Docket as transmitted by DWAPI Client.

Each Message on receipt by the endpoint is forwarded to a message queue (a message broker that accepts and forwards messages)

The NDWH currently supports these two Message queueing systems

  1. RabbitMQ
  2. Microsoft Message Queuing (MSMQ)

The respective docket services will then process the Messages as received and save them to the staging databases.

During the processing of the messages the service will also post the Facility and number of records processed to SPOT to provide real time monitoring through a public portal.

Dwapi Settings configuration (Facility Level):

Dwapi is configured at the facility with the following settings:

Database connection: The Dwapi is configured to connect to a database, MSSQL and mysql

Registry configuration:  The registry refers to any database storing clinical information collected as a by product of patient care. There are various registries that offer centralized storing of data, in Dwapi there are the following dockets and registries:

  • (I) Care and Treatment
  • (II) Master Patient Index
  • HIV Testing Services
  • Migration Services

The registry information contains the Name of the registry, the URL, subscriber, and authentication token.

The following settings are configured:

  1. EMR system is selected: The EMRs currently in place are KeEMR, IQCare, AMRS, ECare and Faces.
  2. DBMS: The DBMS is selected as appropriate with the EMR in use E.g. MSSQL for IQCare and MYSQL for KeEMR
  3. Host: The server name/ host is input
  4. Keys
  5. Port: The port is configured by default
  6. Username: The super user account username is input
  7. password: The super user password is input
  8. Database name: The database name is entered as appropriate

Dockets: The Dwapi is designed to manage data in the three dockets:

  • (I) Care and treatment docket: This contain data from care and treatment extracts. These are All patients extract, ART patient extract, Patient baselines, patient status, patient labs, patient pharmacy, patient visits, and adverse events extracts. The data for each extract is mined from the EMRs where queries are written to extract the data elements. For each extract there exists a data dictionary which describe the variables, data types and description. With the data dictionary any partner that is implementing any other EMR can configure their system and send data to the NDWH.
  • (II) Master Patient Index docket: This contains records of clients that have been assigned a Patient Key Value (PKV) for the purpose of deduplicating the records.
  • HIV Testing services: This contains the data for HIV testing services extracts. These are HTS Clients, HTS Client Test, HTS Client Linkage, HTS Test Kits, HTS Client Tracing HTS Partner testing and HTS Partner notification services.

Data transmission security features

The following are the security measures in place:

  1. Firewall: This stands between internet and the assets Dwapi central, a fail over is available at data.kenyahmis.org
  2. Access control: Passwords: The central Server is secured by password
  3. Backups: The database is backed up
  4. Secure connections: Server is accessible via a secure VPN
  5. Secure transmission– SSL connection ensures secure and encrypted link between Dwapi client at facility and the Dwapi central APIs. Only the dwapi client is authorized to send to the DWH APIs.
  6. Non patient identifying information: No transmission of PIIs is allowed

Comments are closed