Raxa JSS EMR Application Architecture

Proposed application architecture
OpenMRS being a medical records platform is a widely used data model and API. Building upon this data model provides a very standard base of services that are required for any EMR in general. Although, the limitation is that the reference OpenMRS application's UI is meant to be used by data entry operators and not clinician directly. Thus, we would like to build upon the OpenMRS API, yet have a beautiful user experience for clinicians
We have seen other projects that used only the OpenMRS data model and not the API services. This has resulted in those projects over-time getting forked and hard to upgrade to newer changes in the OpenMRS model. Thus, we would not like to be in a similar position, yet maintain flexibility on how we do the user experience.

The OpenMRS modular structure allows us to extend the data model, extend the API as well as expose these as RESTful webservices. RaXa-JSS uses the extensibility of OpenMRS platform in the following ways:

1. New tables are created inside OpenMRS schema (https://wiki.openmrs.org/x/sw8z)
2. New API to CRUD data from these tables (Registering Module services to OpenMRS Context)
3. Controllers (GET/POST) that access the API (https://wiki.openmrs.org/x/ZhAz) - skip View/JSP
4. Expose Controllers as webservice endpoints (https://wiki.openmrs.org/x/CpEaAQ)

Technology Stack (side-by-side to the above diagram):

1. Database Layer - MySQL
2. API Layer - Hibernate, Spring 3.0
3. Web Layer - Spring MVC, webservices.rest (https://wiki.openmrs.org/x/xoAaAQ)
4. App Layer - Using ExtJS 4.1 for mouse-keyboard interface modules and Sencha Touch 2.0 for touch-screen interface modules

HTML5 Feature set:

1. Form features (Placeholder, autofocus, email, spinbox, searchbox, form validators, required)
2. Web Workers
3. Web Storage (Since, we will primary deal with one patient in one tab only)