OpenHIT

is a concerns-oriented way of thinking
about IT application and it's value in the healthcare industry
contacts blog

OpenHIT Architecture

HELP

This diagram describes a logical architecture of the system. Each component has its own short description.

Database

Databases are not obligatory but could be used by REST services as a part of message processing and storing.

Internal system

Internal systems are legacy systems which are used together with message processing pipelines. Normally, such systems would be isolated from the domain but inside it’s network and security perimeter and connected to the domain.

SOAP
proxy service

SOAP proxy service can be used to connect internal legacy systems with the openHIT domain. Its main purpose is to transform messages from internal systems (from an XML-based format) to a flexible JSON used in the openHIT domains for processing of the messages in pipelines.

Internal system

Internal systems are legacy systems which are used together with message processing pipelines. Normally, such systems would be isolated from the domain but inside it’s network and security perimeter and connected to the domain.

REST service

REST service is a component that implements a particular piece of work. E.g. putting a prescription into the internal database, etc.

REST service

REST service is a component that implements a particular piece of work. E.g. putting a prescription into the internal database, etc.

REST service

REST service is a component that implements a particular piece of work. E.g. putting a prescription into the internal database, etc.

Data sharing services
Data validation services

Validation services is a set of services used for any kind of technical validation for the sake of the other services inside the domain.

Message internal routing & processing engine
Message external routing engine (MERE)
Application heap

Application heap is a cache database for both internal and external applications. It helps to store and retrieve temporary data for applications, establishes communication between a service layer and applications.

For example, application has some temporary data, the service does some work and the last needs to send results to an application. In this case service writes data to the Application Heap and the application recieves access to this data immediately.

Pipelines & rules

Rules for the pipelines adoption include two main components - templates for processes and rules for pipelines adoption. The first one describes the template for process and is managed with the use of process type ID (TID). The second ones defines the way to change the sequence of nodes,to add additional nodes to the pipeline based on the contains of the message. On the whole, rules and pipelines can be described as a configurational database that with own API and operated on the fly.

Context state
Security provider
Transport subsystem

Transport subsystem provides the tools to fulfill the specific requirements for interactions between domains and external systems / applications.

Applications
Processing domain

Processing domain is an isolated entity consisting of core services and a service layer and providing a solid engine for message processing via pipelines. One of the main features of the domain is to hold a solid and mostly independent instance of the message processing context.

External Systems

External systems are the ones outside of the domain borders and not included into the other domains. Such systems can still be a part of the overall message processing pipeline.