The OpenMRS Reference Application is a sample EMR application running atop the OpenMRS API. OpenMRS has always had a web application component; however, the web application focused primarily on basic administrative features and lacked most content, leaving it up to modules and administrators to provide EMR functionality and content. The Reference Application, on the other hand, strives to provide more of a starter set of content along with basic EMR functionality (e.g., registration, basic reports, etc.). The web application framework upon which the Reference Application is based comprises a handful of new modules that run within the existing web application and provide a new, Groovy-based framework for more agile web development.
As of May 2013, the Reference Application is a work in progress, porting the work done using the Reference Application framework at Mirebalais Hospital in Haiti to become a generic application for the OpenMRS community.
Here's the architecture diagram we drew after a meeting including representatives from PIH, Thoughtworks (Mirebalais and JSS teams, and advisors), and OpenMRS.
Glue that ties together and configures some of these other modules.
Defines the login and home screens.
Includes the "content" for our Reference Distribution. E.g. Roles, Encounter Types, Concepts.
Eventually this will include sample clinical forms as well.
Standard CSS and UI elements, that can be used across apps to build consistent APIs.
This module also contains (or should contain) a small number of highly-reusable standard messages that you can rely on living for a long time.
Core set of apps including Find Patient and Patient Dashboard.
Also includes common HTML Form Entry tags, e.g. <encounterDiagnoses/>
|Registration App||App and UI for "Register a Patient". (Much of the business logic for this lives in the Registration Core module.)|
|Dispensing||App for recording that meds were dispensed to a patient. (This will only cover a very simple workflow. We do not intend to expand this module into a "real" dispensing system, and we explicitly will not expand it to track inventories. This function should be covered by an external system, or a module built for this purpose.)|
|EMR API||Common OpenMRS APIs for EMR workflows. (Generally these APIs are higher level than the ones in core.)|
|Registration Core||Common OpenMRS APIs for registering new patients (progressively searching for duplicates, etc). We do not use any UI from this module.|
|Id Gen||Common OpenMRS API for generating patient identifiers. You may use this directly, or use the "primary identifier type" defined by the EMR API module|
|Reporting Module||Common OpenMRS API for querying for cohorts and datasets. We use its calculations, but not its UI.|
|Provider Management Module||Used for "Provider Types". (This module contains quite a bit more functionality, but we are not interested in that for the reference application.)|
|App Framework Module||Framework for building the full application out of smaller self-contained pieces|
|UI Framework||Framework for building server-side pages and fragments, using Java and Groovy|
Framework for calculating data points about patients or groups of patients.
(Any reference application code should use this, and not the Logic module.)
|Metadata Sharing Module||We use this to import/export the packages of "content" in the reference application. (See the Reference Metadata module.)|
|HTML Form Entry Module||Framework for defining data-collection forms without significant programming skills in a way that nicely integrates into the application's UI.|
|HTML Form Entry 1.9 extensions||Adds a few necessary HTML Form Entry tags (e.g. <encounterProviderAndRole/>) needed for working with OpenMRS 1.9+|
Includes our standard page decorators, header, and includes. It also gives the UI Framework access to the App Framework's SessionContext.
(This module exists to tie together the App Framework, UI Framework, and UI Commons modules, which are intentionally independent of each other.)
|Event||Framework for loosely coupled inter-module communication. (We don't use this much yet, but we'd like to base a lot of the architecture on it.)|
Framework that lets us publish our APIs RESTfully.
(We don't do this much yet, but it's a fundamental part of our intended architecture.)
|Metadata Mapping||Required by the Metadata Sharing module.|
|Serialization.xstream||Required by the Reporting module|
|HTML Widgets||Required by the Reporting module|
|Logic Module||Required by OpenMRS core. We do not use this module, but prefer the Calculation module|
(To be removed.)
It is included because it is required by the Provider Management Module (for the functionality we don't use).
|Paper Record||(To be removed.)|
Below is the current state of the Deployment pipeline in Bamboo.