OpenMRS 3.0: A Frontend Framework that enables collaboration and better User Experience

Owned by Joel Denning
Last updated: Oct 29, 2024 by Grace Potma
7 min read

Yes, we’ve been changing!

OpenMRS 3
Our exciting new direction

OpenMRS 3, aka O3, is our community’s next-generation of the OpenMRS EMR.

O3 uses modern technology and user interface design. This new frontend for OpenMRS leverages modern frontend technologies that enable users and developers around the world to share more frontend functionality, reduce duplicated effort, and have a better user experience. Learn more about the O3 story here. 

OpenMRS 2
Our historic application

OpenMRS 2 remains a widely-used version of the OpenMRS user interface. 

 

O3 Resources to Know 🧠

Connect With Us 📞

You have multiple options for where to seek help or have discussions on matters related to OpenMRS v3:

Online Discussions & Help

Daily "Coffee Chats" ☕️

  • What: O3 Troubleshooting for Frontend Developers

  • When: Monday-thru-Thursday. Calendar info with times and call links here: om.rs/cal 📆

Weekly 3.x Squad Call (all-hands) 👥

  • What: Our weekly 3.x initiative all-hands. Everyone (Devs, Designers, BAs/PMs) shares their updates, and a short design showcase is shared to keep everyone current on the latest design thinking and user feedback. 

  • When: Calendar info with times and call links here: om.rs/cal 📆

Bi-Weekly 3.x Product Design Call 🎨

  • What: A weekly gathering of BAs, PMs, Designers and stakeholders co-designing 3.x workflows and features. We share emerging ideas, detailed requirements, discuss concerns, and review the latest design outputs and user testing results. 

  • When: Calendar info with times and call links here: om.rs/cal 📆

Join a Squad 🤝

  • What: A squad is a group of community members, kind of like a “feature team”, working autonomously on specific, discrete solutions to a shared problem(s).

  • When: Each squad is different - some meet on a video call several times a month; some work exclusively over Slack. Check out the current Squads on our Squad Dashboard: om.rs/squads

How to Start Contributing 

  1. Dev Guide: Use our Dev Guide to get started: om.rs/o3dev

  2. Intro: Introduce yourself at our #openmrs3 Squad Slack channel (Note: You will first need to create an OpenMRS Slack account by going to slack.openmrs.org)

  3. Find Intro Tickets: Intro tickets you can use to start contributing are available here: om.rs/intro

    1. Assign tickets to yourself before starting work, but only if you are going to try to complete the ticket. This helps avoid confusion and accidental duplication of work.

    2. Please only take 1-2 tickets at a time. If you assign yourself to multiple tickets, this prevents others from working on them, so please be considerate of others and only pick up 1-2 tasks at a time. When those are done, you can assign yourself another 1-2 other tasks. If you have submitted your PR for 2 tickets and are still waiting for feedback, it is okay to pick up another ticket, so long as you promptly respond to the feedback on your original tickets so that work can be merged promptly.

    3. Note: For tickets that require using a design hosted in Zeplin: to view designs in detail, you'll need an invite to our Zeplin account. Ask @Grace Potma for help - @grace on Slack. Make sure you also review our short How to Use Zeplin video.

  4. Meet Us! Join our weekly Squad calls on Thursdays - Calendar info with times and call links here: om.rs/cal 📆

Other Information

(1) Plug & Play Architecture: The frontend stack we're building on using Micro Frontends

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.

(2) Implementer Tooling: Tooling we're building to make MFE easier for implementers to configure

Goal: Enable both developers and non-developers to easily configure their distribution, and re-use that configuration rapidly. 

  • openOpenMRS-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.

(3) Building a Friendly, Modern UX in RefApp v3.0

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 are working on a re-design of the patient chart, starting with end-to-end support for HIV Outpatient Workflows.

We're 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.

Our Design System: