Reflections of Reference Application Lead - January 2017 to July 2018

Development
,
1

At the OpenMRS Global Conference in 2016, in Kampala Uganda, I was requested to take over as Reference Application Lead from January 2017. Thank you @paul @burke @darius for the vote of confidence in giving me the opportunity to serve, now 18 months later, 3 releases 2.6.0, 2.7.0 and 2.8.0, I would like to take a look at the journey we have travelled together and a peek into what the future holds.

Background: The reference application (RefApp) is a demonstration of the capabilities of the OpenMRS platform, with sample forms, patient flows, and usually a starting point for those looking to use OpenMRS for their electronic medical records needs. The RefApp is released twice a year, April and October

What went well

  1. Planning cycles and discussions - this was a mix of talk posts, design calls and email exchanges to drive the direction. The approach I leveraged was to have both large and small features with a focus on implementors needs
  2. Releases actually happened - some albeit late by a month or so but they happened
  3. Release managers were new to the OpenMRS community, and were supported
  4. GSOC - the Google summer of code projects continue to be a source of needed features for the reference application
  5. Support from organizations - special mention to @SolDevelo and @Andela , for the development resources allocated to OpenMRS and Reference Application
  6. OpenMRS SDK 3.x - special mention to @raff as this makes development and support of OpenMRS implementations a labor of love
  7. Stabilized infrastructure - CI, WIKI, JIRA again special callout to @cintiadr for your tireless efforts

What did not go as well

  1. Actual development of the planned features - the resources available for actual development efforts for core reference application features were not available as they were not needed by implementors
  2. Release process - the documentation for the process still needs work to make it more visible and streamlined
  3. Planning - what should be included in the Reference Application. This may be a challenge with the maturity of the platform, however there is a need to take time to review and determine whether the Reference Application still meets its orginal intended goals
  4. Harvesting and sharing of code from downstream distributions - there is a gap between the downstream implementations code what is available in the Reference application, again this would need dedicated resources and time to bring back to the core what is used downstream
  5. Time challenges - this was truly evident in the 2.8.0 release, where I personally was unable to provide the necessary support and follow through due to demands of the implementation I am involved in ~700 sites and growing.

Where do we go from here?

  1. Leverage new Technical PM and Director Community to help coordinate engagement across the distributions to find
  2. Look to implementations in Uganda, Cameroon, Nigeria, Malawi which are in the early stages to understand which features would provide maximum impact while addressing their challenges and needs
  3. Find resources for core development to speed up the solidification of the Reference Application in the following high level areas:
    • Migration to Boostrap for UI layout
    • Setup Standards for OWAs
    • Form Building Technology - HTML Form Entry is starting to show its age especially in the run-up to point of care with customizable flows for the same forms
    • Review of the modules (do we still need all of them?), can some be merged, can some be simplified
    • Harvest of features from downstream implementations so that there can be fewer variations of the same modules
    • Reporting - how can it be improved and simplified
    • Deployment without writing code and how to improve the coding experience
    • Update documentation from here is a list of features - to here are sampel patient flows, use cases and scenarios, here is how you can customize them for your needs
    • Overall approach to simplify customization and usage for both single installations and multiple facility/national rollouts

I would love to hear your thoughts on what you have seen on the journey and how we can chart a strong way forward.

7 Likes
2

This is awesome. Such an important process to have this sort of evaluation. Well done, Steve! not sure what this means, though:

“Actual development of the planned features - the resources available for actual development efforts for core reference application features were not available as they were not needed by implementors.”

Could you elaborate?

3

@akanter There are two sets of features for Ref App (just like platform), those that are core under the hood, and those directly used by implementors. The core features under the hood plumbing do not have any dedicated development efforts, yet are needed to keep moving the Ref App forward.

Things like migration to Boostrap, patient flows (now that there is a push to point of care) etc