The purpose of the Shared Health Record (SHR) 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, which this is a part, the SHR 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 SHR. Please refer to this document for the SHR 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 on which to build a solution. The review process that we went through to make this decision is described in the tool recommendation document. This design document will describe the modifications needed to allow OpenMRS to be used as an 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 an 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 detail and give a design of how these functions can be implemented within OpenMRS.
The following diagram describes the overall architecture of the components that would enable OpenMRS to act as an SHR.
In the initial version of the SHR we would like to be able to receive data in 2 different message formats:
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 functions 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 basic architecture for allowing OpenMRS to become an SHR is to provide a number of modules that expose the interfaces that we need for the SHR and to allow us to process the data received and store this in the OpenMRS data model. Also, these modules must allow data to be retrieved from OpenMRS and formatted in standardized message formats in the case where data need to be queried by clients.
In order to do this we require 3 different types of modules:
We also consider monitoring as a first-class citizen and a module to monitor SHR performance is required. All other modules are expected to report monitoring data to this module.
Interface modules provide service interfaces for an external application to call in order to get access to information in the SHR. These modules MUST make use of the content handler module's getContentHandler(String contentType) method (see here) to handle any request to save data or to query data from the SHR.
As part of the default implementation of the SHR, we will implement some specific interface modules. These are described below.
This module provides an XBS.b interface into OpenMRS. It is expected to receive any type of document payloads over the XDS.b interface and pass those on to the content handler with the content type of the payload.
For the more detailed design of this component see: XDS.b interface module
This module is expected to provide a RESTful interface for receiving and querying CDA documents. In the future, it will conform to a subset of the RESTful FHIR specification which is planned to be used for the future IHE MHD profile once it is stable. It will pass the received data on to the content handler with the content type of the payload. However, for now, these specifications have not been completed and are not releases. As such we will produce a simple REST module in order to test the rest of the SHR architecture until such time as we have proper profiled specifications to develop against.
The design for this basic REST module can be found here: Simple SHR REST interface module
For the more detailed design of the MHD/FHIR module see: FHIR Document interface module (This will be updated as new specifications emerge)
This module receives data from the interface handler along with the content type of that data. Using this information it is expected to forward data to the appropriate processing module that can handle that data. It is also required to have the functionality to allow processing modules to be able to dynamically register and de-register their interest to data of particular content types.
For the more detailed design of this component see: Content Handler Module
Processing modules are able to process data in a particular format to save into OpenMRS and to query OpenMRS for data and convert this to the supported format. Processing modules MUST implement the ContentHandler interface of the content handler module MUST register their content handler with the content handler module to make it available to other modules. See here for more details about the content handler module.
The CDA processing module is expected to process CDA documents and store these within OpenMRS's data model. It should also provide functions to retrieve information from OpenMRS and construct this as a CDA document as required.
The HL7 v2 processing module is expected to process HL7 v2 messages and store these within OpenMRS's discrete data model. It should also provide functions to retrieve information from OpenMRS and construct this as HL7 v2 messages as required. OpenMRS's relational database tables will be used to store this information and this can be stored and queried using the normal OpenMRS services.
Alternatives for HL7 V2 message processing
Currently, the RHEA implementation uses the RHEASHRAdapter module for hl7 message generation. Another alternative is the HL7Query module, which was built by OpenMRS developers in response to the use cases and requirements highlighted by the development of the RHEASHRAdapter module. Therefore, the hl7 generation component of the HL7Query module may be used for the second phase of this effort.
More information about HL7 processing concerns is at SHR HL7 processing issues.
The unstructured data storage module is expected to be able to store unstructured data as a Complex Observation or a Complex Note. For a more detailed design see the Unstructured Data Processing Module.
This module provides services to other modules that allow them to store specific metrics about the functions that they perform.
In addition to the creation of these modules, there are some changes that we would like to make to OpenMRS itself: