OpenMRS Terms and Definitions
Here we list some definitions in an effort to standardize the language used in our community.
- 1 Community Roles
- 1.1 Admin
- 1.2 Developer
- 1.3 Implementor
- 2 Clinical Terms
- 3 Technical Terms
- 3.1 Component
- 3.2 Distribution
- 3.3 Distro
- 3.4 End 2 End
- 3.5 Frontend Module
- 3.6 Implementation
- 3.7 Microfrontend
- 3.8 Microfrontend Based Web-App
- 3.9 Widget
- 4 Other Terms, Concepts, Definitions
Community Roles
Admin
A Developer with permissions to access administrator tools from within the site, or make changes to the backend or database of a deployed instance.
Developer
A technical member who can make changes to the code base. Typical responsibilities are to modify existing features, create new features, and review code.
Implementor
Any member when they are preforming implementation tasks.Â
Clinical Terms
Patient
Person
Technical Terms
Component
A reusable piece of frontend code used to render some visual effect (text, picture..) on an HTML page. Components should have a clear understanding of when and how they are used as defined in their docstrings.Â
Examples: Button, Accordion, Checkbox
Distribution
A fully functional set of software packages needed to run OpenMRS. This includes a Frontend, Backend, Network or Server, and Database.
Distro
See distribution
End 2 End
Typically in reference to a test that acts as a user would. Such behavior usually involves multiple technical layers (Frontend, Backend, Networking, Database), all of which must work in unison to accomplish the task and therefore pass the test.
Frontend Module
A microfrontend. Commonly one that is intended to be optional within an OpenMRS distro. This can either depend on other frontend modules to work, or be completely autonomous
Implementation
(one distribution) A specific instance of OpenMRS as tangibly deployed and being used by end users
The act of choosing modules and configuring them to become a distribution
Microfrontend
An environment agnostic and autonomous widget. This differs from a widget in that a microfrontend can contain all dependencies to use itself by itself, where a widget will rely on other packages already being present (like React or Angular).
Microfrontends should contain "good default behavior" and do not rely on direct inputs from other members of a UI to work. If they interact with other microfrontends on the page, they do so through common high level API.
Example: Patient Chart, ...
Microfrontend Based Web-App
A way to organize a web-app such that a common linking shell does not know before hand which features or functionality will be added to the app.
Typically the choice of which microfrontends / frontend modules to include will happen at implementation of a distribution. In theory these could be dynamically loaded.
An app shell will then "discover" which microfrontends exist and then place them onto the page accordingly.
Widget
A functional component made up of smaller Components that accomplishes a set of UI interactivity for a specific task or set of tasks typically of some complexity
Example: