Introduction: What is OpenMRS 3?

Welcome to the OpenMRS 3 design world! OpenMRS 3 (aka 3.0, or 3.x) is a large project that:

• Substantially modernizes OpenMRS' frontend technology;
• redesigns the UX/UI leveraging Carbon Design; and,
• brings together many organizations to use both this technology and the shared design framework to share the burden of work and benefit from collaborative processes. So that good projects can achieve more good, together. 

See the section below called "A Visual History of OpenMRS" to better understand why we arrived here. 

Contents: 

Connect With Us

OpenMRS 1.x:  (2004)

The main strategic focus of the OpenMRS project was our modular backend: the software platform, the data model, and modular add-on software that unlocked additional backend features. The frontend code provided simple role- and privileged-based control along with extension points and path-based space for modules to add their own frontend pages.

This visual shows the first reference UI that provided the very basic fundamentals for a system. Implementations needed to add or build modules to realize even basic clinical functions.

Some problems with the 1.x RefApp UI are:

• Based on Java Server Page (JSP) technology that was tricky for developers.
• Developing and debugging frontend pages is slow and cumbersome.
• Relies on server-based rendering of web pages, which is no longer best practice.

OpenMRS 2.x:  (2011)

In 2011, the OpenMRS Reference Application ("RefApp") frontend was updated, along with the UI. Newer frontend approaches (like React and Angular) had appeared, but were not yet established as best practice.

The modular backend/platform continued to be the main strategic focus of the community. The primary focus of the 2.x frontend was to address key complaints from 1.x frontend development: primarily the ease of building new frontends for modules and development cycle time. Groovy Server Page (GSP) technology was introduced, allowing frontend pages to be scripted more easily, support debugging of frontend pages, and made for quicker development cycles.

2.x was successful in achieving shareable frontend elements across different organizations. However, some problems with the 2.x RefApp UI are:

• The Groovy Server Page (GSP) approach was custom-designed for OpenMRS, providing an OpenMRS-specific approach to web application development.
• Technology is now outdated. Difficult to find devs to work on; long dev onboarding.
• Still relies on server-based rendering of web pages, which is no longer best practice.
• UI uses an in-house style guide that requires maintenance. Not originally set up to be responsive (e.g. to work on tablets, phones). 
• Some implementers found it difficult to extend the Design to handle more detailed workflows and deeper EMR chart navigation. 

A Different RefApp: Bahmni (2016)

After launching the 2.x RefApp, many in the OMRS community realized that a point-of-care EMR was needed, especially one that came out-of-the-box with an ecosystem of the critical tools needed in clinics and hospitals - Lab System, Pharmacy/Dispensing System, and RIS/PACS. A sub-faction of the community then created Bahmni, named after a very remote village in India in the middle of a tiger sanctuary. The name was a reminder of the extreme settings that the product needed to serve.

Bahmni was built on the OpenMRS platform, but added separate technical layers of abstraction and applied a different UI/UX. This means that frontend features developed for Bahmni cannot be used by 2.x RefApp users, and vice-versa. 

Turning Point: The Situation by 2020

Despite sharing the same backend, many OpenMRS systems had a radically different frontend. The world had decided that frontend development was better done with client-side technologies and frameworks like React and Angular were well-established as best practice for web application development. As a result, many implementations looking to development new features, turned to these newer technologies and built in-house frontends on top of the OpenMRS platform.

This prevented collaboration on frontend features, and substantial duplicated effort around the world. These are all patient summary views in OpenMRS systems.  (Click to zoom)

OpenMRS 3.x:  (2021)

OpenMRS now recognizes a need to offer both a solid platform and a compelling frontend offering / modern user experience. In the OpenMRS 3 project, we are now working on a new UI/UX convention: 

• Uses modern frontend technology e.g. JavaScript and client-side rendering; this has a larger and growing global dev talent pool.
• Modular frontend allows teams to plug-and-play with widgets created by others.
• Design and technology optimized for point of care, responsiveness, and patient care records that can be simple or very complex. 
• Uses a 3rd party Design System maintained by another open source community. 
• Avoiding/minimizing OpenMRS-specific approaches to development.

This time, we have put a lot of effort into the design, shareability, reusability, and extensibility of the User Interface.

Example: Before OpenMRS 3

These 2 organizations wanted to collaborate together on new feature. They couldn't, because they didn't share frontend technology, nor a common set of design principles. (Click to zoom)

Example: With OpenMRS 3

Now: With OpenMRS v3, these groups are actively pooling development and design time, since they can share frontend technology and consistent UX/UI in features. (Click to zoom)