Skip to end of metadata
Go to start of metadata

Introduction

This document aims to fully specify the transactions used by OpenHIE. In this document the transaction specifications will be laid out for each planned transaction type. In this document we will specify transactions on two fronts. We will describe both the external API and internal APIs that the interoperability layer will support. These are explained below:

  • External API - This is the publicly exposed API that the interoperability layer supports. This API contains all the transactions that the interoperability layer exposes to end-user applications (mostly point of service application).
  • Internal APIs - These are the APIs of the national service that the interoperability layer can call to fulfill the API calls in the external API. There can be 0..* calls to these internal APIs for each external API call.

This document is aimed at developers and implementers of the systems involved. It should cover enough detail to allow a developer to fully implement transaction endpoints in the required system.

External API

API exposed by HIM (interoperability layer) to PoS systems. This part of the API can be used by systems like OpenMRS and RapidSMS to interact with the HIE. This API will be available publically (for system with the the correct privileges). 

Patient Encounters
Patient
HC Facilities
Alerts

Internal API

This API is used by the HIM (interoperability layer) to orchestrate the API calls it receives on the external API. This API is only accessible from within the HIM and is not designed to be accessed by any system other than the HIM.

Shared Health Record - OpenMRS
Client Registry - OpenEMPI
HC Facility Registry - Resource Map
HC Professional Registry - OpenLDAP
RapidSMS
Terminology Service

Security

All RESTful endpoint of the External API will be secured using HTTPS and basic auth.

Error Messages

In the cases in which a transaction fails the standard HTTP response codes will be used to convey these error. In some cases a more detailed error is needed. These endpoint will return a XML document representing the error in the HTTP body. The document will have the following structure:

<?xml version="1.0" encoding="UTF-8" ?>
<error>
   <error_code>...</error_code>
   <error_msg>...</error_msg>
</error>
  • No labels