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, of which it is a part of, the OpenSHR 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 OpenSHRSHR. Please refer to this document for the OpenSHR 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 to built offon which to build a solution. The review process that we went through to make this decision 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.
...
- 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 life cycle for things like 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 OpenMRS required fields to suit a SHR
In the sections that follow we will explain these in more details and give a design of how these functions can be accomplished implemented within OpenMRS.
Overview
The following diagram describes the overall architecture of the components that enable OpenMRS to act as a SHR.
...
- 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 functions to allow legacy applications to send data in this format until such time as they are able to make use of CDA.
...
The basic architecture for allowing OpenMRS to become a SHR is to provide a number of modules that expose the interfaces that we need of for the SHR and to allow us to process the message formats data received and store these this in the OpenMRS data model. Also, these module must allow data to be retrieved from OpenMRS and formatted in these standardised message formats in the case where data need to be queried by clients.
In order to do this we have require 3 different types of modules:
- Interface modules - these modules provide the service interfaces to send a and receive information using a particular standardised interface.
- Content handler module - this module forwards received data to the appropriate processing module so that it can be stored.
- Processing modules - these modules provide functionality to interpret data in particular a particular format and store and /retrieve this to/from OpenMRS's data model.
...
This module provides an XBS.b interface into OpenMRS. It is expected to receive an 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.
...
This module is expected to provide a RESTful interface for receiving and querying HL7 v2 messages as well as CDA documents. It will pass the received data on tot he to the content handler with the content type of the payload.
...
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 functionality to allow processing module modules to be able to register dynamically register and de-register their interest to data of particular content types dynamically.
Processing Modules
CDA Processing module
The CDA processing module is expected to be able 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 be able to process HL7 v2 message and store these within OpenMRS's data model. It should also provide functions to retrieve information from OpenMRS and construct this as a HL7 v2 messages as required.
...
The unstructured data processing module is expected to be able to process an any other data that cannot be interpreted by any of the other processing modules. It is expected to be able to strore store and retrieve data as-is in blob form. This module is useful for handling unstructured information such as images or pdf's but may be able to store any information that cannot be stored in another mannerprocessed by another processing module.
Metric and Monitoring Module
...