Sharing Data to Improve Health Outcomes with the OpenHIM

The Challenge

Clinicians need accurate, timely and complete information for decision-making.

​

The Reality

Healthcare information solutions are often siloed, making it difficult to share information across different systems, different facilities and different locations.

OpenHIE Interoperability Layer

• Single point of entry in a health information exchange (HIE).
• Manages security of the HIE.
• Routing of messages.
• Central logging mechanism.
• Rerunning of failed transactions at a central level.

OpenHIE Workflows

Overview

​

• Functions as the Interoperability Layer in the OpenHIE architecture.
• Open-source application that acts as an interface into the HIE reference architecture.
• Allows other components to interoperate more easily:
• Handles common functions (security, auditing, logging).
• Single point of communication.
• Message transformation and orchestration via mediators.

Classification

​

​

Geographic Coverage

Map shows known implementations of the OpenHIM.

• New and emerging implementations in 2019/2020.
• Also used in PEPFAR’s Data for Accountability, Transparency and Impact (DATIM) global and country node data exchange architectures.

Use Case - MomConnect

National initiative of the South African National Department of Health (NDoH) that sends free mobile phone text messages in all eleven official languages to pregnant women who voluntarily register at any public healthcare facility in South Africa.

​

Allows for health service planning and health informative targeted messaging to expectant and new mothers.

Use Case - OpenCRVS

A response to the need for an accessible and available Civil Registration and Vital Statistics (CRVS) system.

​

Designed to be fully interoperable with other government systems, and data enabled for fast decision-making.

Recent Developments

Performance

Routing engine refactoring for improved message streaming and support for large payloads.

Extensibility

New set of generic bootstrap and mapping mediators to make it easier to reuse/adapt/develop custom mediators.

Community

Revised roadmap, updated end-user documentation and tutorials (narrative and video) published.

​

Key Features

Security

• Ensures transmission of data comes from valid sources, control over which health system data can be exchanged between entities.

Communication

• Transformation - Supports transformation of messages to broker communication between systems.
• Orchestration - Allows data to move between components of a health architecture.

Support

• Notification and resolution of issues - Configurable reports, email/SMS notifications.

Basic Architecture

​

OpenHIM core

OpenHIM console user interface

REST API

Requests from PoS systems

(EMRs, Pharmacy systems etc.)

Infrastructure services (Client Registry etc.)

Configure the OpenHIM to manage the HIE infrastructure

Deployment Architecture

​

Key Components

Clients

A client is a system that wants to connect to the HIE (e.g. an EMR system).

Adding a client enables them to access the HIE.

Channels

A channel matches a message type and forwards that message to one or more routes.

Describes which clients are authorized to access the channel.

Routes

A route describes an endpoint to another system where a message should be forwarded to (e.g. a shared health record or a client registry).

​

​

Clients, Channels, Routes

​

A Lock for your HIE

The OpenHIM acts as a lock by supporting the IHE ATNA profile:

Audit Trail (AT)

Includes an Audit Repository which allows systems to audit their actions.

Node Authentication (NA)

Includes easy TLS certificate management capabilities to keep your HIE secure and even allows you to generate your own self-signed certificates.

​

Audit Repository

​

Certificates

​

Built in capability to manage TLS certificates and keys through its keystore.

​

Functionality to trust particular certificates.

​

This allows you to specify exactly which client or external hosts you trust, and ties it in with the OpenHIM’s authentication mechanism for clients.

​

Transaction Log

​

View technical details about the transactions (messages) flowing through your HIE.

​

Filter transactions by a number of different fields.

​

Dashboard

​

Provides a view into what’s happening in your Health Information Exchange.

Visualizing Transactions

​

Extending the OpenHIM

​

Mediators allow additional functionality and business logic to be added to the OpenHIM.

​

Mediators allow you to:

• Adapt and transform messages to a different format.
• Orchestrate messages.
• Anything else you want.

Mediators

​

OpenHIM mediators are micro services that run independently from the OpenHIM to perform additional tasks for a particular use case.

​

Mediators may be developed in any language and only talk to the OpenHIM via its RESTful API.

​

The common tasks within a mediator are:

• Message format adaptation - transformation of messages received in a certain format into another format (e.g. HL7 v2 to HL7 FHIR or MHD to XDS.b).
• Message orchestration - execution of a business function that may need to call out to other service endpoints on other systems. (e.g. Enriching a message with a client’s unique identifier retrieved from a client registry).

​

​

Common Mediator Types

Passthrough

Accepts a request and passes it on unchanged.

Adaptor

Accepts a request and transforms/adapts it into another format before sending the request on to its final destination.

Orchestrator

Accepts a request and uses that to execute some business process. This could involve making calls to one or more other services to gather additional information about the request or to process it further. Finally a response is collated and returned to the OpenHIM.

​

​

Mediator Starting Points

Bootstrap Mediators

https://github.com/jembi/openhim-mediator-tutorial

Set of scaffolding mediators providing basic structure and support for production-ready mediators.

Generic Mapping Mediator

https://github.com/jembi/openhim-mediator-mapping/

Adaptable to support custom validation and mapping schemas for specific use cases.

​

Thank You

www.jembi.org

www.openhim.org