OpenMRS To Save 50K Hours With BrightRide

Healthcare
OpenMRS
OpenMRS is the foundational, electronic medical record technology for countries that touches and helps millions of patients throughout the world.

As of March 2010, OpenMRS is in use in at least 23 developing countries (mostly in Africa) and it has been used to record over 1 million patient records.
OpenMRS helps doctors and patients in the hospital
  • ~350
    Company size
  • 16
    Sites worldwide
  • 10
    Number of timezones
Summary of success
BrightRide has identified an opportunity to remove 50,000 hours of waiting, allowing OpenMRS to be one step ahead of pandemics and bring new capabilities to patients around the world 20% faster while saving $85,260 (>500% ROI).
Challenge
OpenMRS is a truly global community spanning 10 timezones. It consists of core OpenMRS team and a number of other teams working on different distributives and modules for the platform. In addition to that, OpenMRS accepts contributions from small contracting firms, individual contributors, participates in Google Summer of Code (GSoC) program.

Coordinating such a vast community to create a robust, scalable, and user-driven medical record platform, and at the same time moving quickly, is not an easy task. Community needs central people to synchronize and ensure consistency as well as to provide necessary training to new contributors and GSoC participants. And these key people's time should be spent very efficiently to avoid cascading waiting hours.

Most time-sensitive discussions happen in Slack, Jira issues, and GitHub pull requests. This is the data we used to find constraints on the OpenMRS communication system.
Solution
BrightRide team has collected and filtered data for 2023 calendar year from OpenMRS Slack, OpenMRS Jira, and OpenMRS GitHub. We then analyzed interactions between teams, calculated waiting times and visualized to best highlight improvement opportunities.

BrightRide's data adapters automatically collect and arrange data into the BR Universal Format. Universal Format allows BrightRide to uniformly process people interactions from diverse sources and to add support for any additional collaboration tools in the future. Adapters work via REST API and OAuth, and it took 1 week to collect all the data while respecting API rate limits of the selected collaboration tools.

To visualize collaboration between teams, BrightRide needs to know the organization structure of the customer. Since OpenMRS is not a traditional organization but is highly distributed across the globe, we had to spend 2 weeks collecting and cleaning team structure and members' metadata from the organization's Discourse space and websites of organizations contributing to the platform. This step could be skipped for traditional hierarchical organizations.

In the end we obtained the following matrix with org units arranged by functions (vertically) and business lines (horizontally). Waiting times are shown as follows,

  • Left — from other org units in the org unit's business line,
  • Right - org unit's own waiting on org units in the business line,
  • Top — from other org units in the org unit's function,
  • Bottom - org unit's own waiting on org units in the function.

Some numbers look unrealistically high, like 152147 hours waiting for the OpenMRS Leadership. 152147 hours for the whole 2023 is 1.3 hours a day for each of the 323 members. Also keep in mind that these are cumulative — they include transitive waiting times from all the upstream members. This is exactly why see a huge opportunity here as a small improvement has a such a dramatic effect!

Here is the resulting diagram,
OpenMRS Communication Traffic Map
OpenMRS Communication Traffic Map
Widths of arrows represent the amount of communication along that channel.
For functions and business lines you can see the temporal diameter—it is the average duration for a message to go along the path from any one member to any other.

Four opportunities for improvement are clearly visible from the diagram:

  1. Dependency on the OpenMRS Leadership,
  2. GSoC students' training and commitment,
  3. Core development coordination,
  4. Front-end teams coordination.
Let's go through them in turn.

Dependency on the OpenMRS Leadership
OpenMRS Leadership team creates an outsized amount of waiting for the whole organization. It's input is needed to ensure the necessary quality and consistency of all components, so it couldn't be circumvented. It also can be seen that the Leadership team itself waits a lot on input from other OpenMRS platform members.

A few strategies can be helpful here,
  • Inform leaders about the impact of their response times;
  • Formulate generic principles, guidelines and policies that can be available to everyone and direct the work. Thus the leaders won't have to be consulted as often;
  • Label messages coming from leaders to have a high priority. Thus they will be answered faster and leaders won't have to wait to answer to someone else. BrightRide supports such labeling for Slack, it can be enabled for OpenMRS as we work together.

GSoC students' training and commitment
Unexpected issue identified by BrightRide is that participation in Google Summer of Code program has its downsides. On one side it allows for more project contributions and more members joining the community permanently—which is essential for an open project. On the other—it is not free. A lot of teams have to wait for those members to be trained at work and deliver what is expected.

The following actions can be implemented to mitigate the impact:
  • Don't assign critical work required by other teams as GSoC projects;
  • Provide more detailed onboarding materials to such members, so less online training time is required of other members;
  • Calculate actual cost vs. benefit for such engagement. With BrightRide team can make such decision based on numbers.

Core development coordination
OpenMRS Core is developed concurrently by multiple teams in different locations. Four of those (OpenMRS Core, Regenstrief Institute, Andela, ThoughtWorks) are most central and create outsized waiting to coordinate the development.

While colocating the teams is not an option, the following options should be explored,
  • Those four central Core teams are to be informed about the impact of their response times on other teams and the rest of the organization;
  • Clearly define Core subcomponents and assign ownership to different teams such that ownership lines don't cross the team boundaries. Ownership doesn't mean that teams cannot exchange contributions, but defines who makes the final call about the component change and is responsible for component's long-term quality. Read about the benefits of ownership assignment in our blog post and this other one on Conway's law;
  • Use those clearer boundary lines when planning the product roadmap and product releases to minimize the amount of communication needed;
  • Define clearer guidelines and principles for Core development and code quality that can be consulted offline instead of taking time to coordinate online.

Front-end teams coordination
Front-end teams coordination is necessary to ensure visual and functional consistency of the product as well as its quality. Recommendations for the front-end teams mostly resemble the ones for the Core teams with one front-end specific addition:

  • Create a well defined design system and components library for OpenMRS;
  • Inform the teams about the impact of their response times on other teams;
  • Clearly define Front-end subcomponents and assign ownership to specific teams;
  • Use ownership boundary lines for planning the product roadmap and releases;
  • Define clearer front-end development and code quality guidelines and principles.
Customer Success
BrightRide has successfully identified 4 improvement opportunities for OpenMRS community. Modest 20% reduction in waiting times will amount to 50,000 hours of reduced waiting, allowing OpenMRS to be one step ahead of pandemics and bring new capabilities to patients around the world.

Not all of the 50,000 saved hours directly convert to the cost saving because people switch to other tasks when blocked. Also waiting can happen overnight or through holidays. Assuming that people cannot switch between more than 4 different projects and work 8 hours a day for 249 business days in 2023, OpenMRS can save 2842 hours of labor. At $30/hour median rate it amounts to $85,260 of savings or over 500% ROI.
Next Steps
Steps recommended by the BrightRide team are to be implemented, automatic labeling of messages coming from most blocking areas to be turned on, and analysis done again next year to estimate the actual impact on the organization and further improvements.

  Pilot with us?

Our Mission — Unleash creative energy in
today's organizations for what truly matters.

We achieve this by equipping business leaders with tools
to forge efficient communication structures.
contact@brightride.io
© 2024 Bright Ride, Inc.​ All rights reserved.