Reference Application 3.0 - Where do we go from here?

Now that Reference Application 2.10 is going to get released, I want to kickstart this discussion on the future of the Reference Application … This is a mid-term goal for the An amazing future for OpenMRS that we can use today

  1. As an example of what OpenMRS can do - I think it is starting to fall short of illustrating the key salient features of the EMR and supporting features

  2. Do we need all the existing modules - is it time to look them over and see how to merge, combine and eliminate some to reduce the startup times and points of change (this we learnt as we moved the UI to Bootstrap)

  3. Alot of the focus and energy is on adding features, probably now is the time to start focusing on patient flows and field useages

  4. Is it prime time for the Front End squad to come to light and play front and center for the next release

  5. Can Iniz become the future for configuration

  6. What is the underlying foundation for data imports - this need is becoming more necessary for us in UgandaEMR as the focus is on integration, interoperability with other systems

  7. Does Sync2 have a future, will FHIR ever work? Where do we go from here?

  8. How do we do reporting, and data driven decision analysis? Patient Flags, Dashboard Widgets, etc are the start how to expand this for larger data volumes


  1. Simplify the process of creating custom web service end-points within custom modules

Now , thats very key. We seem to be now having issues with start up time ,and building time for some modules like core apps and the core its self.

  • We need to see how we can optimise start-up/loading time for reff app.
  • We also need to optimise build time for some modules ,specifically ,core apps seems to be getting several issues with building as its too bulky …some issues include this and this.
1 Like

Do you mind giving some details in regards to what could be simplified about this process?

@dkayiwa if I have to create a custom end point, what classes and configurations do I have to make, currently they are not clear, I have tried to do this 4-5 times and gave up

I think we can address this with the documentation team. GSoD 2019: Improved REST API Documentation

If it can be updated this week, I am happy to take it for a test run as we have a burning need

1 Like

@ssmusoke wouldnt that be as easy as writing your own controller without using the openmrs Rest Framework ??

That has disadvantages of not showing up in our swagger docs, and a few others.

1 Like

sure :grinning: , However the primary need would be solved. a custom end point :grinning:

1 Like

Hi @dkayiwa , @ssmusoke

Guys currently we are not focusing on this area.But if it’s something we have to focus we do it.I will talk with Stphe :slightly_smiling_face:

1 Like

@mozzy nope it will not, one thing you will learn about me is that I tend to write code that can later be migrated into OpenMRS core or Ref App from Day 1… So I have to follow the best practices approach recommended, takes a while to get up and running, but after that its a sprint


sure , thats a better practice @ssmusoke

@mozzy, @ssmusoke is not a man who goes for hacky solutions. :blush:


Which modules within the Ref App are no longer relevant? Which ones have potential to have additional features but need rework? which modules need to be redesigned all together to meet new needs of its users?

@ssmusoke @dkayiwa @mksd @k.joseph @ball @burke @mseaton @mogoodrich @aojwang @angshuonline @ggomez @@valvijo @ruhanga @jdick @janflowers @wanyee

Totally agree. RefApp should both demonstrate what’s possible and be the same thing people can start with, IMHO – i.e., I’m not interested in a RefApp that cannot (at least optionally) be used by implementations as a starting point.

I believe some of the modules are being carried forward unnecessarily or, despite removing them in the past, they’ve shown up again in the list and just won’t die (e.g., logic module). :wink:

It’s also worth noting the list of persons responsible for modules may not still be actively maintaining them (e.g., Ben, Darius, Wyclif, etc.).

Agreed. This will require thinking about how we package both content and behavior – i.e., what I’ve previously referred to as vertical packaging.


Frequently this is done with bespoke scripting. Embracing standards (e.g., FHIR) would help.

What we need to “sync” is development and the implementation need. We surveyed implementations for their needs and sync was near the top of the list. When SolDevelo took on sync (as Sync2), we struggled to find an implementation to be product owner for SolDevelo’s efforts.

FYI – microfrontends, like Sync2 did, is pushing to try to use FHIR over bespoke REST endpoints.

We need 2-3 or more implementations to agree to use a shared approach to ETL with a clean line between standard and implementation-specific features (i.e., a clear extension-point). A community-supported approach to ETL could not only serve reporting/analytics needs, but allow us to feed these types of data back into the clinical system (e.g., advanced cohort management, providing decision support based on aggregate data, shaping choice lists based on analytics, etc.).

One of the goals of the REST Web Services module was to provide an extension mechanism. Given the world is migrating toward the FHIR standard, we might do well to consider this as a strategy (i.e., add new FHIR resources in the same way that we’d expect the next custom web service to add its own resources).


@burke Could you share your thought on how can we better manage modules moving forward? How will one know which module needs rework/optimisation or archiving? Product Owners may not necessarily know well/frequently their module is being used .Is there any analytics on usage of the modules?