Revamping the OpenMRS Roadmap

Implementing
1

Hello Everyone:

The OpenMRS team is currently working on Revamping the Technical roadmap. The process began in August with information gathering from different implementing partners and during these next few weeks, we are kicking off the process of conducting a landscape assessment, gathering feature proposals/ improvements. We kindly welcome interested members to submit features proposals/improvements for review and inclusion on the upcoming OpenMRS roadmap.

The OpenMRS Roadmap process will consist of the following steps. As our goal is to involve

Phase 1:

Landscape assessment of all implementing partner activities. The object of this activity is to ascertain the following

  • Objectives of the implementation
  • Which theme does the implementation fall under
  • Key components (modules) of the implementation
  • Future growth ambitions of the implementation
  • Harmonisation of reference and platform activities with implementer ecosystem activities.
  • Better position technical activities to meet the needs of the community.

Phase 2 :

  • Proposal of product enhancements
  • Initial review and prioritization of proposals into a proposed roadmap by the OpenMRS Product architecture team
  • Final review and approval of proposed roadmap.

In 2018, we are looking to have a draft roadmap process defined and features agreed by the time the Implementers conference happens.

A draft roadmap process will be shared with the community after the completion of the landscape assessment which should end by October 30.

To submit a proposal, kindly use the attached template and share it with me via one of following methods:

The idea behind this template is to have a standard way of proposing new features/improvements for the OpenMRS product. The template has guiding statements/questions to ensure that adequate and essential information is provided on a feature.

All submitted proposal are tracked using a Trello Board to be created shortly.

This process is open until October 30.

We would prefer if those who wish to make a submission do so as soon as possible as we may decide to close the submission date earlier than scheduled.

We look forward to hearing from you.

2 Likes
2

Dear All

The results are in!

First off I would like to thank all those that participated in initial discussions on how to define this roadmap to make it more collaborative and inclusive (including those I kept nagging :slight_smile: :smile:)

Given the nature of our ecosystem we have drafted an initial roadmap for your feedback. You will notice that it is not your normal product roadmap, but rather an attempt to have a structure that would allow for collaboration and driven more by implementer activities and priority areas. We envisage that this approach will allow for the platform to be better aligned with implementer activities and resourcing.

Please also note that we have created this approach to be very iterative, so this is not cast in stone.

We encourage feedback to this approach. Please do not hesitate to post your thoughts here, or reach out to me directly on email or my talk id (@c.antwi)

Technical Roadmap Approach Draft

Statement of Intent:

The aim of this roadmap is to be a mechanism that allows for collaboration and agreement on a shared vision of where the community would like to go; leveraging on activities that are already being conducted within the community. We would like to have an an interactive, iterative and collaborative approach.

Strategic Objective of this Roadmap:

  • Reducing duplicate efforts and waste.
  • Better align core development activities with the implementer ecosystem; once achieved, a more rigorous and structured roadmap approach could be adopted.
  • To better engage implementers in developing a mechanism to bring back into the reference and platform applications
  • Leveraging on implementer activities to drive growth and enrichment of the reference and platform applications
  • To deliver a better experience for both new and current implementer of OpenMRS

Through initial discussions with implementer and different stakeholders of the platform we have identified the following areas for potential areas of collaboration:

Functional Needs and Priorities:

Short to Medium term:

  • A library of UI/UX interfaces… in a consistent way and for different interface configurations
  • Smooth transition / migration from one upgrade to another ( a full upgrade path)
  • Point of care tool/ framework to cater for other conditions such as NCD, mental health, PHC

Medium to Long term

  • Standard reporting module or an easier way to get data out
  • Data Warehousing
  • A way to automate testing of code (testing framework for code)

What process are we going to follow?

mpnBVrlTl5XpFfBnHpLYDP5lor-a283kvx9XT97C-DNKv7dOJK4NK6Re5TRGgvbvgaDw1Q2RWcD2_HfAJ2VNNh3A9SbIQiPdS7EcFimsrtvuYTc17cPH8Jebn5qWdoVf6zwPNd4m1414Ă—779

As an example, assuming it is agreed that we select UX/UI interface revamp activity, the approach to initiating activities to complete this functional feature would be:

Phase 1: Agree on shared vision for OpenMRS 3.0 (more strategy than tactics) – agreement of initial partners to use OpenMRS 3.0 assuming we are successful in making it

Phase 2: Agree on quickest (biggest pragmatic low hanging fruit) initial steps (short-term wins)

Phase 3: Divide and conquer on initial steps

Phase 4: Defining MVP for a shared web application (tactics for getting there) – we all feel we can see we got something that at least initial partners can use

@burke @janflowers @darius @paul @terry

1 Like
3

Thanks for pulling this together Cynthia!

I really like the idea to approach this with a Project mindset rather than a Product mindset, and to focus on enabling collaboration more than building features.

I still have to look at the phase diagram more closely but one thing I think it’s missing is a clear depiction that there are multiple entities involved in working on any feature. (At a minimum there is OpenMRS and a specific implementation.) And if we are counting on having implementations do the bulk of the dev work on features they care about then we need to reflect this more.

Also I am a bit concerned about the specific short/medium term items because it sounds like we are saying “build a completely new OpenMRS application with a completely new UI/UX.” While I’m sure that some people want this, it feels exceptionally risky to make these be our initial roadmap focus. The Data Warehousing bullet that your mention in long seems like a safer bet, in that it can be done as an incremental addition. Are there really no exams where anyone has said that the OpenMRS platform or refapp basically work but they just want one additional thing?

Also, about structure, since we are focused on enabling collaboration, I would expect that the road map items are listed along with the people or organizations that are proposing to design and work on them.

1 Like
4

Cynthia:

Great job getting this going.

Further to our F2F conversation a few minutes ago, let us explore how we can use the upcoming OpenMRS meeting in Nairobi to move some of the action items along. For example, we can have a exercise to actualise the collaboration by taking advantage of presence of most implementers to identify who will take lead on certain task items in the road map. We at IntelliSOFT for example are very interested in the work around use of OpenMRS in NCDs…ref: Point of care tool/ framework to cater for other conditions such as NCD, mental health, PHC.

1 Like
5

Attaching an original discussion here: