...

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

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.

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 can be mapped to as encounter-based domain model

TODO

Initial ideas:

TODO

Allow the OpenMRS SHR to scale horizontally

TODO

Initial ideas:

TODO

Modify the database for performance based on the SHR use case

TODO

Initial ideas:

TODO

NOTE :

If you're an OpenMRS developer who is new to OpenHIE, and want a quick refresher, or if if you're interested in reading up on these topics in depth, please refer to OpenMRS as the SHR design document : A quick introduction for OpenMRS developers