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
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
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)
Alot of the focus and energy is on adding features, probably now is the time to start focusing on patient flows and field useages
Is it prime time for the Front End squad to come to light and play front and center for the next release
Can Iniz become the future for configuration
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
Does Sync2 have a future, will FHIR ever work? Where do we go from here?
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
UPDATE
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.
@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
@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
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?
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).
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?
, However the primary need would be solved. a custom end point 
