OpenMRS Platform Roadmap

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

7 Likes

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

1 Like

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

3 Likes

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.

1 Like

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

1 Like

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

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.
2 Likes

Hi @grace,

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

cc @mksd

4 Likes

Very welcome indeed @ruhanga! CC @dkayiwa

1 Like

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

4 Likes

Thanks @Platform_Team :pray:

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.

1 Like

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.

2 Likes

@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! :slight_smile:

1 Like

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).

1 Like