Wiki Spaces
Documentation
Projects
Resources
Get Help from Others
Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack
We're building a new frontend for OpenMRS via a collaborative process that leverages modern frontend technologies. These technologies will enable OpenMRS users and developers around the world to share more frontend functionality, reduce duplicated effort, and have a better user experience.
Quick Links
Here are the most important links for this project, aside from the actual code. High-level project documentation and information about how to join us can be found below.
Note: If you are new to this page, please review this page's contents before clicking on these buttons. These are convenient links to team resources but should only be utilized after completing basic onboarding. |
---|
u: admin p: Admin123 DEMO SITE
Project documentation
Developer Documentation Implementer Documentation
Where to find work
Live Tickets Dashboard Team Jira Board Key GitHub Repos
Designs
Public: Patient Chart Designs Public: Offline Designs Public: OHRI Designs Detailed: Designs Ready for Development Detailed: Styleguide
How to Work with the Designs
Zeplin how-to for devs Styleguide (Re-useable Styled Components)
Current Status VERY ACTIVE
We are working on 3 main goals that will unlock better frontend collaboration across OpenMRS:
Watch this 15 minute video that will give you a better understanding of our vision.
Strategic Fit for OpenMRS
Why Microfrontends? High-Level Strategy SPA Proposal Explained Detailed Technical Vision
Decision Making Process
We use an RFC (Request For Comments). Major decisions are made through GitHub pull requests where anyone can comment.
When: Thursdays at 4pm UTC / 9:30pm IST/ 7pm EAT / 5pm CET / 11am ET / 8am PT
Where: Zoom link for computer or mobile
What Happens On These Calls:
Notes: Notes for meetings
Talk: Hyperlink
Slack channel: #microfrontends
GitHub: Link to Git page
Website Board/Additional Forum: Additional site link
Goal: Frontend architecture designed for extensible and configurable apps and widgets.
What are Microfrontends? Microfrontends are in-browser javascript modules (ESMs) that provide application UI. They make it possible to have extensible, configurable and independently deployable frontend features. It means you can get your frontend live and updated fast.
Our MF Framework is Single-SPA: We chose to use single-spa, the most popular microfrontends framework, as the basis upon which to build this new frontend architecture.
Our MF Tech Stack: Primarily React, HTML and CSS, but it's not unfeasible that one could choose to develop in a JavaScript framework of their choosing - that's the whole premise behind microfrontends after all.
Frontend 3.0 uses a framework called esm-framework
, which is housed in openmrs-esm-core, along with the app shell and tooling. Distributions will use these core modules and package a number of Microfrontends which are built on them. The reference application is made up of all the microfrontends found in the following repositories:
Special mention for openmrs-rfc-frontend which is a git repo that facilitates a democratic process where folks can propose changes to the frontend implementation via RFCs (Request For Comments). Please read, for example, the Contributing Guidelines for Microfrontends, which were established with RFC #20.
GitHub: esm-core Dev Guide Tutorial
Goal: Enable both developers and non-developers to easily configure their distribution, and re-use that configuration rapidly.
Implementer Tool App on GitHub openmrs-esm-implementer-tools-app is an in-browser javascript module provides a UI for viewing and editing configurations, and viewing other administrative information about the frontend application. It is part of the Extension System.
This is the configuration library for OpenMRS Microfrontends. It makes configurability easier for developers and configuring easier for implementers. Implementer Config Library on GitHub
Goal: Create a better means for building out a shared UI. Modernizing the entire RefApp frontend, using Carbon Design System for UI consistency and faster dev value. Our OpenMRS Reference Application needs to become a Point of Care application, that’s modern, friendly, and works well on tablets.
We're currently in the process of implementing new designs that leverage the carbon design system for our reference application. (More on why we chose carbon here).
We're not starting from scratch though. Rather, we're migrating from an old set of designs (and an old style guide) to the new designs (and now migrating to use Carbon Design System as well - not all the Carbonizing work is done). As such, it should not be unexpected that gaps will be found in documentation, incomplete implementations, broken functionality and so on as we move to get everything back in order.
Designs:
Designs in Progress Designs Ready for Development
Our Design System:
Carbon Design System Rationale for Carbon
Our Simple Style Guide for reference:
Styleguide (Re-useable Styled Components) How to Use Zeplin in Dev Work
Finally, member information. This will include the project’s leaders, or any other noteworthy members, sorted by their role and given contact information. It is important to maintain a distinction between teams and squads. All contact tables should be conveyed using the same format. Currently being used is this table below. The left column indicates the different positions, and the corresponding right columns will list the tags of all active members holding those positions.
Project Owners | AMPATH | |
OpenMRS | ||
Mekom Solutions | ||
Regenstrief Institute | ||
UX Design | Ciarán Duffy, Paul Adams | Sonder Design & AMPATH |
Software Architecture | Smapiot & Mekom Solutions | |
PIH | ||
Developers, DevOps, QA, BA | Dennis Kigen Donald Kibet | AMPATH |
OpenMRS | ||
Romain Buisson | Mekom Solutions | |
Nikita Malyschkin | Smapiot & Mekom Solutions | |
UCSF | ||
PIH | ||
BA/Clinical Feedback | ||
Brown, Backend & FHIR Support | ||
Bett Kipchumba | AMPATH, Backend & FHIR Support |