# OpenMRS Platform Roadmap **URL:** \ **Category:** Development\ **Created:** [February 21, 2023, 3:31pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652 "2023-02-21T15:31:27Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\ **Post date:** [February 21, 2023, 3:31pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/1 "2023-02-21T15:31:27Z")
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](https://talk.openmrs.org/groups/mekom) [@PIH](https://talk.openmrs.org/groups/pih) [@AMPATH](https://talk.openmrs.org/groups/ampath) [@BandaHealth](https://talk.openmrs.org/groups/bandahealth) [@OHRI](https://talk.openmrs.org/groups/ohri) [@PalladiumKenya](https://talk.openmrs.org/groups/palladiumkenya) [@ICRC](https://talk.openmrs.org/groups/icrc) [@ICAPEthiopia](https://talk.openmrs.org/groups/icapethiopia) [@Intellisoft](https://talk.openmrs.org/groups/intellisoft) [@Jembi](https://talk.openmrs.org/groups/jembi) [@METS](https://talk.openmrs.org/groups/mets) [@SolDevelo](https://talk.openmrs.org/groups/soldevelo) [@UCSF](https://talk.openmrs.org/groups/ucsf) [@UWash](https://talk.openmrs.org/groups/uwash) [@Brown](https://talk.openmrs.org/groups/brown) [@dev3](https://talk.openmrs.org/groups/dev3) [@dev4](https://talk.openmrs.org/groups/dev4) [@dev5](https://talk.openmrs.org/groups/dev5) @angshuonline ---
**Author:** ![slubwama](https://talk.openmrs.org/user_avatar/talk.openmrs.org/slubwama/32/8366_2.png) [@slubwama](https://talk.openmrs.org/u/slubwama)\ **Post date:** [February 21, 2023, 3:37pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/2 "2023-02-21T15:37:39Z")
@dkayiwa thanks for this communication let us put up a list of thinks which we would love to see in platform. ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [February 22, 2023, 3:20pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/3 "2023-02-22T15:20:40Z")
Thanks @dkayiwa for the heads up. @ruhanga we need to start thinking about this 🤔 ---
**Author:** ![aojwang](https://talk.openmrs.org/letter_avatar/aojwang/32/5_5575768a8748004e209b776fc1b2916d.png) [@aojwang](https://talk.openmrs.org/u/aojwang)\ **Post date:** [February 22, 2023, 9:26pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/4 "2023-02-22T21:26:19Z")
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. ---
**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\ **Post date:** [March 1, 2023, 6:05pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/5 "2023-03-01T18:05:10Z")
> [@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? ---
**Author:** ![grace](https://talk.openmrs.org/user_avatar/talk.openmrs.org/grace/32/16942_2.png) [@grace](https://talk.openmrs.org/u/grace)\ **Post date:** [March 8, 2023, 7:52pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/6 "2023-03-08T19:52:10Z")
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!](https://talk.openmrs.org/t/2023-03-08-tac-call-platform-2-7-api-roadmap-plan-we-want-your-feedback/38931): > > 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 video_camera [Launch Meeting - Zoom](https://om.rs/zoomtac) 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… ---
**Author:** ![grace](https://talk.openmrs.org/user_avatar/talk.openmrs.org/grace/32/16942_2.png) [@grace](https://talk.openmrs.org/u/grace)\ **Post date:** [March 15, 2023, 12:55pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/7 "2023-03-15T12:55:12Z")
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.](https://talk.openmrs.org/t/associating-data-with-the-correct-encounter/38062) 2. **Community Priority:** [Extract Immunization](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/4) like we did for Allergies, Conditions, Diagnosis. 3. [Support for Tomcat 10](https://talk.openmrs.org/t/openmrs-update-to-latest-java-tomcat-and-mysql-versions/36505) - 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](https://en.wikipedia.org/wiki/Java_version_history) - 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](https://issues.openmrs.org/browse/TRUNK-6155) - for patches included. Need to check if this upgrade would cause any complexity for us. [TRUNK-6208](https://issues.openmrs.org/browse/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](https://issues.openmrs.org/browse/TRUNK-5767) 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. ---
**Author:** ![ruhanga](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ruhanga/32/8318_2.png) [@ruhanga](https://talk.openmrs.org/u/ruhanga)\ **Post date:** [March 27, 2023, 11:30am UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/8 "2023-03-27T11:30:31Z")
Hi @grace, I’d like to add one more to the list, hopefully this is still welcome: [TRUNK-6169](https://issues.openmrs.org/browse/TRUNK-6169) mentioned in the topic below, > [@Filters and/or Servlets cannot be added to context \[/openmrs\] as the context has been initialised](https://talk.openmrs.org/t/filters-and-or-servlets-cannot-be-added-to-context-openmrs-as-the-context-has-been-initialised/39187): > > 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 ---
**Author:** ![grace](https://talk.openmrs.org/user_avatar/talk.openmrs.org/grace/32/16942_2.png) [@grace](https://talk.openmrs.org/u/grace)\ **Post date:** [March 28, 2023, 5:45am UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/9 "2023-03-28T05:45:15Z")
Very welcome indeed @ruhanga! CC @dkayiwa ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [October 4, 2023, 4:05pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/10 "2023-10-04T16:05:24Z")
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](https://issues.openmrs.org/browse/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](https://issues.openmrs.org/browse/TRUNK-6155), [TRUNK-6208](https://issues.openmrs.org/browse/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](https://openmrs.atlassian.net/browse/TRUNK-6197) 7. Remove all uses of the Hibernate Criteria API because it’s deprecated (replaced with JPA criteria) [TRUNK-6202](https://issues.openmrs.org/browse/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](https://issues.openmrs.org/browse/TRUNK-6203), [TRUNK-6206](https://issues.openmrs.org/browse/TRUNK-6206) 9. Add support for init parameters for module servlets ([TRUNK-4673](https://issues.openmrs.org/browse/TRUNK-4673)) and [this Talk post](https://talk.openmrs.org/t/filters-and-or-servlets-cannot-be-added-to-context-openmrs-as-the-context-has-been-initialised/39187/16) 10. Docker as a first-class approach to deployment. [RA-1990](https://issues.openmrs.org/browse/RA-1990), [TRUNK-6186](https://issues.openmrs.org/browse/TRUNK-6186), [TRUNK-6083](https://issues.openmrs.org/browse/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 ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [October 4, 2023, 5:03pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/11 "2023-10-04T17:03:42Z")
Thanks [@Platform\_Team](https://talk.openmrs.org/groups/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](https://talk.openmrs.org/groups/mekom) and the work with do with #Ozone HIS. Great stuff. ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [October 18, 2023, 3:52pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/12 "2023-10-18T15:52:10Z")
> [@burke](#): > > 1. 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](https://github.com/openmrs/openmrs-core/blob/master/api/src/main/java/org/openmrs/api/AdministrationService.java#L93) 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. ---
**Author:** ![janflowers](https://talk.openmrs.org/user_avatar/talk.openmrs.org/janflowers/32/208_2.png) [@janflowers](https://talk.openmrs.org/u/janflowers)\ **Post date:** [February 16, 2024, 4:47pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/13 "2024-02-16T16:47:50Z")
@burke Are these items you listed out above in October still needed for the platform? I see the [Technical Roadmap - Documentation - OpenMRS Wiki](https://wiki.openmrs.org/display/docs/Technical+Roadmap), 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! 🙂 ---
**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\ **Post date:** [February 19, 2024, 2:50pm UTC](https://talk.openmrs.org/t/openmrs-platform-roadmap/38652/14 "2024-02-19T14:50:07Z")
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).