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:
In the sections that follow we will explain these in more details and give a design of how these can be accomplished within OpenMRS.
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:
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:
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
Due to the need to manage document based (unstructured) data, we are interested in considering alternative methods other than just traditional RBDMS databases for the SHR.
Initial ideas:
We could make use of OpenMRS' Complex Obs functionality: https://wiki.openmrs.org/display/docs/Complex+Obs+Support
The possibility of enabling polyglot persistence (manage multiple databases which are specialized to manage/deal with specific types of data). Potential options for managing document based data also include XDS compliant alternatives such as OpenXDS and HIEOS.
TODO
Initial ideas:
OpenMRS already exists as two separate maven projects, one containing the view layer and one containing the service layer. Can OpenMRS already be deployed with just the service layer? We will need to check this with the OpenMRS devs.
TODO
Initial ideas:
These could be added as modules, one per standard interface supported.
TODO
Initial ideas:
This logic could be stored in the module alongside the standard-based interface code.
TODO
Initial ideas:
We could use hibernate interceptors or AOP to accomplish this.
TODO
Initial ideas:
TODO
TODO
Initial ideas:
TODO
TODO
Initial ideas:
TODO
NOTE :
If you're an OpenMRS developer who is new to OpenHIE, and want a quick refresher, or if if you're interested in reading up on these topics in depth, please refer to OpenMRS as the SHR design document : A quick introduction for OpenMRS developers