...
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 a 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 a an SHR. Some of the key changes that we will need to make made are as follows:
- Support the storage of unstructured data eg, e.g. documents such as CDA level 1 - 3
- Remove the user interface so that 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, e.g. 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 the data life cycle for clinical decision support or data validation.
- Make sure everything can be mapped to as an encounter-based domain model
- Allow Investigate solutions for allowing the OpenMRS SHR to scale horizontally
- Modify the database for in order to optimize performance based on the SHR use case
- Modify OpenMRS required fields and data model constraints in order to suit a an SHR.
In the sections that follow we will explain these in more details 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 a SHR.
...
The basic architecture for allowing OpenMRS to become a 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 module modules must allow data to be retrieved from OpenMRS and formatted in standardised message formats in the case where data need to be queried by clients.
...
We also consider monitoring as a first class citizen and a module to monitor how the SHR is performing performance is required. All other module are expected to report monitoring data to this module.
...
The HL7 v2 processing module is expected to process HL7 v2 message messages 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.
...
- Remove the requirement to have to store patient names and dob date of birth as we would only want to store a patient identifier for a an SHR
- Performs database modifications to improve performance for SHR functionality
- Add data lifecycle hooks for certain processes to hook into (for example clinical decision support functionality)
- Enable OpenMRS to be able to scale horizontally
...