...
- Framework (existing)
- Core OpenMRS API (effectively our low-level data API)
- APIs from key existing modules (Reporting, HTML Form Entry, XForms, IDGen, etc)
- Framework (new)
- App Framework module: a thin module to support the pluggable app paradigm, but without defining a UI
- EMR API module: a thick module that provides high-level APIs relevant to a clinical EMR, to complement the low-level data API of OpenMRS core. Makes opinionated decisions about how to represent common medical concepts in the underlying data model. No UI.
- UI-layer libraries and utilities
- UI Library: reusable components and widgets (CSS, HTML templates, JS). Assumes that you will use the OpenMRS Reference Application Style Guide, but does not assume you're using any particular server-side or client-side UI Framework. (Not necessarily
- UI Framework module: helps you develop traditional server-side code, facilitating rapid application development in line with the OpenMRS module framework.
- Offline Library: common tooling to support apps that want to cache metadata and data so they can be used offline
- Apps
- To support reusability and sharing of building blocks, most user-facing functionality should be build as "Apps". An OpenMRS module may provide 0 or more apps.
- Implementation projects will create apps for their own purposes.
- Sometimes we will be able to "harvest" these for inclusion in the OpenMRS Reference Application, or for use by other implementations.
- Often these will be custom apps of little interest outside the implementation. This is not a problem.
- For the Reference Application we'll allocate some work into finding/improving/bundling/building apps for common use cases (registration/check-in, triage/vitals station, patient search, chart review, reports, etc)
- Distributions
- Apps are intended to be reusable and pluggable building blocks. A "Distribution" is a particular combination of OpenMRS modules, plus configuration to wire together those building blocks.
- Typically contains: CSS, XML configuration, Metadata Sharing packages
- PIH is building the Mirebalais module to represent the Mirebalais Hospital distribution
- Thoughtworks will build a JSS distribution
- OpenMRS's core team will build a "Reference EMR" distribution
Current State
PIH's work on Mirebalais Hospital has built out a significant amount of this architecture. But some specific changes need to be made to PIH's work to build the proper general architecture:
- The module at https://github.com/PIH/openmrs-module-emrhas too much in it, and it needs to be split up:
- (soon) Its API needs to move to an "EMR API" module (which should be in OpenMRS's github space)
- (later) its API should be exposed RESTfully
- (soon) Common UI elements need to be pulled into a UI Library module. (Not the same as the current UI Library module)
- the Mirebalais Style Guide and CSS needs to be refactored to have an OpenMRS Reference Application Style Guide, of which Mirebalais is just a minor change.
- (soon) UIs for specific features need to be split out into their own modules (e.g. Archives Room, Patient Search + Dashboard)
- (ASAP) Architectural changes to the App Framework module
- Darius started putting together https://github.com/djazayeri/openmrs-module-referenceemr , which needs to be pulled into OpenMRS space and refactored a bit to be the beginning of the OpenMRS EMR Reference Application distribution
App Framework
Reference Application
Sprints
Our first sprint will address minimal functionality, but lay the foundation for future work. It should include:
...
- It will contain just two app on the homepage:
- "Register Patient". This should use the new Registration API module, and should allow you to create a patient with minimal data, and suggest possible duplicates.
- "Legacy OpenMRS". Takes you to the old OpenMRS UI.
...
- This will likely start off as: "Reference EMR", "Registration API", "Registration App", "Logic", and hopefully "EMR API" (if the Mirebalais team has finished splitting that off from its EMR module.)
- We need reliable email notifications about build failures
...
- Mock-based unit tests
- DB-backed unit tests
- Scripted-browser smoke tests (is there a framework that lets us write these in Groovy?)
...
App Framework
Reference Application
Included Modules
| Module | Description |
|---|---|
| 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 App | App and UI for "Register a Patient". (Much of the business logic for this lives in the Registratino 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 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 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+ |
| 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.) |
| 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.) |
| 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 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 |
| 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.) |
Continuous Delivery Pipeline
Below is the current state of the Deployment pipeline in Bamboo.
...