The purpose of the Shared Health Record software implementation is to provide a centralized repository for storing health data; with the goal of facilitating health information exchange among client systems. In line with the direction of the OpenHIE project, of which it is a part of, the OpenSHR does not aim to be a project specific implementation of a Shared Health Record, but rather it aims to provide a framework and several core software components that can be used to implement a specific SHR.
This document will focus on the high level architectural design for the OpenSHR. Please refer to this document for the OpenSHR requirements. The requirements themselves will be considered concluded within the scope of this document. For the Shared health Record component we have decided to make use of OpenMRS as the core technology to built off. The review process that we went through is described in in the tool recommendation document. This design document will describe the modifications needed to allow OpenMRS to be used as a SHR for OpenHIE.
To design a Shared health Record (SHR) around the OpenMRS platform, we will need to modify OpenMRS to be able to perform the functions of a SHR. Some of the key changes that we will need to make are as follows:
- Support the storage of unstructured data eg, documents such as CDA level 1 - 3
- Remove the user interface so the SHR can run as a headless service (separate the service layer from the UI layer)
- Add standards based interfaces to interact with the SHR eg, add endpoints for XDS.b + CDA or profiled HL7v2
- Add mechanisms for processing, storing and querying structured and unstructured data within OpenMRS
- Add hooks at various stages of data lifecycle for things like CDS clinical decision support or data validation.
- Make sure everything can be mapped to as encounter-based domain model
- Allow the OpenMRS SHR to scale horizontally
- Modify the database for performance based on the SHR use case
- Modify required fields to suit a SHR
In the sections that follow we will explain each one of these in more details and give a design of how these can be accomplished within OpenMRS.
Overview
The following diagram describes the overall architecture of the components that enable OpenMRS to act as a SHR.
In the initial version of the SHR we would like to be able to recive data in 2 dfferent message formats:
- CDA document
- HL7 messages
We acknowledge that we would like to support CDA as the primary exchange format however we would also like to support a minimal set of HL7 v2 processing to allow legacy applications to send data in this format until such time as they are able to make use of CDA.
In this initial version we would also like to support 2 different interfaces on which the data can be received:
- The XDS.b IHE profile - this would be the entry point for CDA documents and the primary standards based interface to receive clinical information.
- A simple REST interface - this would be a simple entry point to receive HL7v2 or CDA documents on.
Basic architecture
TODO
Interface Modules
TODO
XDS.b interface module
TODO
REST interface module
TODO
Content Handler Module
TODO
Processing Modules
TODO
CDA Processing module
TODO
HL7 v2 Processing module
TODO
Unstructured data processing module
TODO
Metric and Monitoring Module
TODO
...
Older notes:
Support unstructured data
...