...

In the initial version of the SHR we would like to be able to recive revive data in 2 dfferent different message formats:

1. CDA document
2. HL7 messages
   

...

1. The XDS.b IHE profile - this would be the entry point for CDA documents and the primary standards based interface to receive clinical information.
2. A simple REST interface - this would be a simple entry point to receive HL7v2 or CDA documents on.

Basic architecture

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 the SHR and allow us to process the message formats received and store these 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 3 different types of modules:

1. Interface modules - these modules provide the service interfaces to send a receive information using a particular standardised interface.
2. Content handler module - this module forwards received data to the appropriate processing module so that it can be stored.
3. Processing modules - these modules provide functionality to interpret data in  particular format and store and retrieve this from OpenMRS's data model.

We also consider monitoring as a first class citizen and a module to monitor how the SHR is performing is required. All other module are expected to report monitoring data to this module.TODO

Interface Modules

TODO

XDS.b interface module

TODOThis module provides an XBS.b interface into OpenMRS. It is expected to receive an type of document payloads over the XDS.b interface and pass those on to the content handler with the content type of the payload.

REST interface module

TODOThis 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 content handler with the content type of the payload.

Content Handler Module

TODOThis 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 to be able to register and de-register their interest to data of particular content types dynamically.

Processing Modules

TODO

CDA Processing module

TODOThe 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.

HL7 v2 Processing module

TODOThe 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.

Unstructured data processing module

TODOThe unstructured data processing module is expected to be able to process an other data that cannot be interpreted by any of the other processing modules. It is expected to be able to strore 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 manner.

Metric and Monitoring Module

TODO

...

This module provides services to other modules that allow them to store specific metrics about the functions that they perform.

Additional OpenMRS Modifications

In addition to the creation of these modules there are some changes that we would like to make to OpenMRS itself:

• Remove the requirement to have to store patient names and dob as we would only want to store a patient identifier for a 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

...

Older notes:

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+SupportThe 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.

Separate UI from service layer

...