Jembi Architecture
Purpose of this documentation
This documentation aims to provide a guide to how we at Jembi generally architect software projects. This is a collection of best practices and thoughts that we have distilled and generalised from our project work over the years. Not all (or any) of this may apply to new projects, however, it is a good base on which to build and to try keep software architecure aligned within Jembi.
Architecture
The largest influencing factor to work that we do at Jembi is the OpenHIE architecture. Jembi helped formulate the general architectural patterns of OpenHIE along with a number of other partners based on experience with health information exchange worldwide.
The guiding principals for OpenHIE are:
- A number of registry components should exist in the architecture that are responsible for storing information about different domains:
- Health Worker Registry (AKA: Provider registry) - for storing information about all health workers and practitioners in the health information exchange
- Client Registry (AKA: Mater Patient Index) - for storing patient details and matching patients that may be duplicates
- Facility Registry - for storing clinical facility information and admin structures
- Shared Health Record - for storing clinical information
- Terminology Service - for storing codes systems that are used to identify concepts in the clinical information or other information sets
- Health Management Information System - for receiving, calculating and storing aggregate data for reporting purposes
- These registries are exposed to client systems through an interoperability layer which handles request routing, security and auditing of requests. This layer also provides visibility into the health of the information exchange.
- Client system use the services exposed by the registries to perform their business function and enable data to be shared amongst systems.
- OpenHIE mandates the use of Health interoperability standards for communication between system. This is so that each system communicates in the same way so that we don't have to write integration code for every new client sysetm that is added.
Jembi's instantiation of OpenHIE
OpenHIE doesn't define what software applications to use within the architecture as it should be agnostic of particular software. However, Jembi has a set of tools that we often use for particular components of OpenHIE. These are only guidelines and may differ project to project.
The software that we commonly use is as follows (many other system may be included depending on the project specifics):
- OpenHIM - this is a software product built and maintained by Jembi to play the role of an Interoperability Layer within a health information exchange. It is, in simple terms, a reverse proxy that is capable of storing and displaying requests that are made through it. It is intended that API call made from client systems to registries are routed through the OpenHIM. It can provide some security and authentication mechansims and has a web interface to configure the application and visualise the requests that are routed through it.
- Hearth - this is a software product built and maintained by Jembi to play the role of an Shared Health Record within a health information exchange. This is an implementation of a FHIR server with a few additions to support particular standard message exchange profiles for OpenHIE particular transaction. Given that FHIR support resources for Patients, Practitioners, Locations, ValueSets and CodeSystems, it may also be used to act as most of the OpenHIE registries in a single application. This greatly reduces complexity of managing multiple registries until it becomes necessary. A few other open-source FHIR servers exist so Hearth is not the only option for new projects.
- DHIS2 - this is a software product built and maintained by the Health Information Systems Program (HISP) at the University of Oslo. It stores and processes aggregate data and may act as an Health Management Information System in the OpenHIE context. It is common for Jembi project to report information into DHIS via it's rest API for reporting puposes, however, this depends on the project. Some project choose to implement their own reporting mechanisms.
Typically, we will commonly use micro-services know as mediators to intercept requests and performs any additional business logic or orchestration that needs to happen that is implementation specific. This can include message transformation or calling out to one or more external systems to performs a variety of functions. We often use the mediator API of the OpenHIM to make these operations more visible to the maintainer of the information exchange. Learn more about mediators here and here.
Jembi's uptake of FHIR
FHIR (Fast Healthcare Interoperability Resources) is a standard for health data exchange. It describes a number of 'resources' for many different concepts within the health context. Such as Patient
, Encounter
, Observation
, Practitioner
etc. Each of these resources describes a particular data model for representing data and the FHIR specification describes mechanisms to create, update, delete, search and more on these resources. It is a moderns standard that uses a HTTP RESTful API and either JSON or XML as the format in which data is exchanged. This makes it very easy to pickup and use. It is also extensible in cases where the base specification does not suit the project needs. Find out more here.
FHIR has become the go to standard messaging format for Jembi projects as it is easy to use, modern and fits well with our current technologies. All new projects are encouraged to use FHIR where possible and appropriate.