Wiki Spaces
Documentation
Projects
Resources
Get Help from Others
Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack
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:
See the section below called "A Visual History of OpenMRS" to better understand why we arrived here.
Contents:
3.x Reference Application Demos:
Introduction to 3.x Design Patterns and Carbon Design
Example: Applying UX Research & Carbon Design with 3.x
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:
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:
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.
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 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:
This time, we have put a lot of effort into the design, shareability, reusability, and extensibility of the User Interface.
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)
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)