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