OpenHIM mediators can be developed in any language and only talk to the OpenHIM via its RESTful API. They do not have to be installed on the same server as the OpenHIM. The only restriction is that a mediator must communicate with the OpenHIM Core in a particular way. In order to support centralized management of mediators in the OpenHIM Console, mediators must register themselves with the OpenHIM Core, accept requests from the OpenHIM Core, and return a specialised response to the OpenHIM Core to explain what that mediator did. The mapping mediator discussed in this paper would need to comply with the general requirements of OpenHIM mediators, and should ensure that:
The mediator is able to reach the OpenHIM-core servers RESTful API endpoint.
The OpenHIM is able to reach the mediator’s endpoint for receiving requests.
The mediator is configured with the correct credentials so that it may access the OpenHIM’s RESTful API as an admin user.
The mediator trusts the OpenHIM Core’s certificate as all API communication takes place over https.
The mapping mediator does not need to fulfil functionality offered by the OpenHIM Core and Console, such as transaction and error management, and the configuration/management of clients, channels and routes.
The mapping mediator is primarily concerned with simplifying the task and complexity of configuring message format adaptation, and then orchestration between HIE components & services and point of service applications, as well as the potential for easier management of workflows and interactions between mediators.
FYI...some of the objectives don’t need to fully implemented if there’s no time, we’re just looking for a clearer sense of whether the objectives can/can’t be met.
Document how to get it installed / getting started