Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: a couple small typos

...

ModuleDescription
Reference Application

Glue that ties together and configures some of these other modules.

Defines the login and home screens.

Reference Metadata

Includes the "content" for our Reference Distribution. E.g. Roles, Encounter Types, Concepts.

Eventually this will include sample clinical forms as well.

UI Commons

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 Apps

Core set of apps including Find Patient and Patient Dashboard.

Also includes common HTML Form Entry tags, e.g. <encounterDiagnoses/>

Registration AppApp and UI for "Register a Patient". (Much of the business logic for this lives in the Registratino Registration Core module.)
DispensingApp 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 APICommon OpenMRS APIs for EMR workflows. (Generally these APIs are higher level than the ones in core.)
Registration CoreCommon OpenMRS APIs for registering new patients (progressively searching for duplicates, etc). We do not use any UI from this module.
Id GenCommon OpenMRS API for generating patient identifiers. You may use this directly, or use the "primary identifier type" defined by the EMR API module
Reporting ModuleCommon OpenMRS API for querying for cohorts and datasets. We use its calculations, but not its UI.
Provider Management ModuleUsed for "Provider Types". (This module contains quite a bit more functionality, but we are not interested in that for the reference application.)
App Framework ModuleFramework for building the full application out of smaller self-contained pieces
UI FrameworkFramework for building server-side pages and fragments, using Java ang and Groovy
Calculation Module

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 ModuleWe use this to import/export the packages of "content" in the reference application. (See the Reference Metadata module.)
HTML Form Entry ModuleFramework 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 extensionsAdds a few necessary HTML Form Entry tags (e.g. <encounterProviderAndRole/>) needed for working with OpenMRS 1.9+
APP UI

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

EventFramework 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.)
Webservices.REST

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 MappingRequired by the Metadata Sharing module.
Serialization.xstreamRequired by the Reporting module
HTML WidgetsRequired by the Reporting module
Logic ModuleRequired by OpenMRS core. We do not use this module, but prefer the Calculation module
UI Library

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

...