OpenMRS Platform Roadmap

[dkayiwa (Daniel Kayiwa)]

As we prepare for the next release of the OpenMRS platform, which we plan to happen towards the end of this year, are there any new features or bug fixes that you would like to happen in this coming release?

@Mekom @PIH @AMPATH @BandaHealth @OHRI @PalladiumKenya @ICRC @ICAPEthiopia @Intellisoft @Jembi @METS @SolDevelo @UCSF @UWash @Brown @dev3 @dev4 @dev5 @angshuonline

[slubwama (Samuel Lubwama)]

@dkayiwa thanks for this communication let us put up a list of thinks which we would love to see in platform.

[mksd (Dimitri R)]

Thanks @dkayiwa for the heads up. @ruhanga we need to start thinking about this

[aojwang (Antony Ojwang)]

Hi Daniel. Thanks for tagging me on this conversation. I don’t know how well this will sit with the rest, but I have been longing to see immunizations and chronic illnesses moved to own models. Allergies, for instance, has become very easy to collect and report on after it was moved outside of obs.

[dkayiwa (Daniel Kayiwa)]

@aojwang

I have been longing to see immunizations and chronic illnesses moved to own models

Do you mind explaining a bit more about chronic illnesses? What kind of observations are currently represented by this?

[grace (Grace Potma)]

FYI we will be discussing this on this Thursday’s TAC call:

2023-03-08 TAC call: Platform 2.7 & API Roadmap & Plan - we want your feedback!

You are all invited for this week’s Technical Action Committee call on Thursday at 2pm UTC (3pm CET / 5pm EAT / 7:30pm IST / 9am EST / 6am PST) at Launch Meeting - Zoom Main Topic: @herbertyiga and @dkayiwa will be sharing their ideas for the Platform 2.7 Roadmap. We are looking for community feedback - FYI folks like @aojwang @eudson @mogoodrich @mseaton @ibacher @pirupius @samuel34 @slubwama @binduak @angshuonline @dagimm @mksrom @ruhanga @mksd Spoiler alert, these are the cur…

[grace (Grace Potma)]

Some notes from our TAC discussion on the Platform Roadmap last week:

Our main goal: Make Platform as easy to support as possible.

1. Community Priority: Implement Encounter Context and Visit Context.
2. Community Priority: Extract Immunization like we did for Allergies, Conditions, Diagnosis.
3. Support for Tomcat 10 - many newcomers come with v10 installed, run into errors, ask for help, and then we discover the issue is their Tomcat version. Still support running with Tomcat 8.
4. Support for Java 17 - many newcomers come with Java 17 installed, run into errors, we discover the issue is Java 17. RefApp currently runs well on Java 11, but not 17. (LTS after 11 is 17.) People should be able to develop in the latest LTS of Java, but we want to be able to run on a previous LTS, e.g. still support running on Java 8 (thinking of Implementers). (As we try out 17, will depend on what we figure out; if can’t support Java 8, might decide to either cancel 17 update, or drop 8, etc. - we try not to just drop support for a previous version due to the difficulty this causes for implementers.)
5. Upgrade to Liquibase 4.19.0 - for patches included. Need to check if this upgrade would cause any complexity for us. TRUNK-6208
6. Upgrade to Hibernate 6.1.7.Final - for patches included. Need to check if this upgrade would cause any complexity for us.
7. Upgrade to Spring 6.0.5 - for patches included. Need to check if this upgrade would cause any complexity for us.
8. Upgrade other small libraries to their latest versions.
9. Replace the Standalone with something else. Very old, can’t even build in our latest releases - we disable it as the technology no longer works and is no longer supported. We now just ship the .war file and README. Suggestion to leverage Docker - something that works by double clicking and then just runs.

[ruhanga (Nathan Ruhanga)]

Hi @grace,

I’d like to add one more to the list, hopefully this is still welcome: TRUNK-6169 mentioned in the topic below,

Filters and/or Servlets cannot be added to context [/openmrs] as the context has been initialised

Hi all, For the very first time an OpenMRS instance is started and has modules adding some filters and/or servlets to it’s context during initializaton, an error along the following lines occurs. java.lang.IllegalStateException: Filters cannot be added to context [/openmrs] as the context has been initialised at org.apache.catalina.core.ApplicationContext.addFilter(ApplicationContext.java:850) at org.apache.catalina.core.ApplicationContext.addFilter(ApplicationContext.java:829) at org.apach…

cc @mksd

[grace (Grace Potma)]

Very welcome indeed @ruhanga! CC @dkayiwa

[burke (Burke Mamlin)]

From our Platform team call today, we landed on this list for the next release of the Platform:

1. Community Priority: Implement Encounter Context and Visit Context.
   • Much of encounter context work may apply to frontend; there may be some requirements for business on the backend (e.g., deciding when to use existing vs. create new encounter)
2. Community Priority: Extract Immunization (especially Immunization Schedule) like we did for Allergies, Conditions, Diagnosis.
   • Need to be able to attribute these (including Allergies, Conditions, Diagnoses) to an encounter
3. A REST endpoint to check status of platform (especially when platform is starting up) TRUNK-6198
   • Would be great to have sense of progress for long-running states
4. Upgrade other small libraries to their latest versions.
5. Upgrade to Liquibase 4.19.0 - for patches included. Need to check if this upgrade would cause any complexity for us. TRUNK-6155, TRUNK-6208
6. Support for Java 17 - many newcomers come with Java 17 installed, run into errors, we discover the issue is Java 17. RefApp currently runs well on Java 11, but not 17. (LTS after 11 is 17.) People should be able to develop in the latest LTS of Java, but we want to be able to run on a previous LTS, e.g. still support running on Java 8 (thinking of Implementers). (As we try out 17, will depend on what we figure out; if can’t support Java 8, might decide to either cancel 17 update, or drop 8, etc. - we try not to just drop support for a previous version due to the difficulty this causes for implementers.) TRUNK-6197
7. Remove all uses of the Hibernate Criteria API because it’s deprecated (replaced with JPA criteria) TRUNK-6202
8. Global properties access should be privileged, so we need an endpoint to expose those items needed (anonymously) during O3 startup. TRUNK-6203, TRUNK-6206
9. Add support for init parameters for module servlets (TRUNK-4673) and this Talk post
10. Docker as a first-class approach to deployment. RA-1990, TRUNK-6186, TRUNK-6083

These items were elected to defer for future Platform releases due to backwards-incompatibility issues:

1. Support for Tomcat 10 - many newcomers come with v10 installed, run into errors, ask for help, and then we discover the issue is their Tomcat version. Still support running with Tomcat 8.
2. Upgrade to Hibernate 6.1.7.Final - for patches included. Need to check if this upgrade would cause any complexity for us.
3. Upgrade to Spring 6.0.5 - for patches included. Need to check if this upgrade would cause any complexity for us.
4. Replace the Standalone with something else. Very old, can’t even build in our latest releases - we disable it as the technology no longer works and is no longer supported. We now just ship the .war file and README. Suggestion to leverage Docker - something that works by double clicking and then just runs.

/cc @dkayiwa

[mksd (Dimitri R)]

Thanks @Platform_Team

This looks like an excellent list of items, and I’m grateful that items #3, #6 and #9 in particular are on that list for @Mekom and the work with do with Ozone HIS.

Great stuff.

[burke (Burke Mamlin)]

@burke

8. Global properties access should be privileged, so we need an endpoint to expose those items needed (anonymously) during O3 startup

During today’s Platform Meeting, we discussed this. Trying to come up with an approach that (1) avoid exposing global properties to anonymous users by default and (2) be as backwards-compatible as possible, we came up with this approach:

1. Refactor getGlobalProperty API method implementations to throw an authentication exception if user is not authenticated and property requested is not on a list of anonymously-accessible global properties.
2. Assuming this breaks startup, by logging the global properties that are are denied, and iterating on startup process, we should be able to build the list of global properties that need to be available anonymously for startup.
3. If the list of global properties needed to expose anonymously for startup is short & comprises only core global properties, the list can be managed explicitly. If we find there are several global properties from modules that need to be exposed anonymously for startup, then we may need to create a method for modules to add global properties to the list of anonymously accessible global properties.

Extra credit: After having done the above, then we would benefit from extending this approach to allow for specific global properties to have additional privilege requirements – i.e., the few that contain particularly sensitive information like a password.

[janflowers]

@burke Are these items you listed out above in October still needed for the platform? I see the Technical Roadmap - Documentation - OpenMRS Wiki, but don’t see those types of things on it. Or maybe they go in JIRA and not the roadmap…sorry, not sure what our process is for logging and tracking these types of things for platform. But would love to better understand so we can make sure to resource them getting done!

[dkayiwa (Daniel Kayiwa)]

Yes they are still needed and are planned to be part of the next platform release. I have just updated the Technical Roadmap wiki documentation. Whenever a JIRA ticket is created for any of those items, we update the platform roadmap wiki page by adding a link to the created ticket. Some of those items are already completed, others are still in progress, and a few others are still untouched (The ones without links to JIRA tickets).