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 each one of these in more details and give a design of how these can be accomplished within OpenMRS.

Overview

TODO

Support unstructured data

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 include XDS compliant databases such as OpenXDS and HIEOS.

Separate UI from service layer

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.

Add standards-based interfaces

TODO

Initial ideas:

These could be added as modules, one per standard interface supported.

Process and store standards-based data

TODO

Initial ideas:

This logic could be stored in the module alongside the standard-based interface code.

Data lifecycle hooks

TODO

Initial ideas:

We could use hibernate interceptors or AOP to accomplish this.

Make sure everything is encounter based