Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
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 Registratino 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 ang 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.)|