/
Detailed Technical Roadmap

Detailed Technical Roadmap

What is the OpenMRS Technical Roadmap?

The Technical OpenMRS Roadmap is a set of milestones for our Platform, Reference Application, community-sponsored modules, and related tasks that help us meet the needs of our implementations.

For information about how the roadmap milestones are chosen and prioritized, see the Technical Roadmap Planning page.

For details of recent releases and release notes, see Releases.

Product Roadmap

To see the full OpenMRS Product Roadmap, see our Product Dashboard at om.rs/productdashboard

Table of Contents

Milestones

Platform 2.8.0 (around July 2025)

  1. Cloud/Scaling Support: Create a new storage service. https://openmrs.atlassian.net/browse/TRUNK-6300

  2. Cloud/Scaling Support: Add ElasticSearch backend for full text search. https://openmrs.atlassian.net/browse/TRUNK-6301

  3. Cloud/Scaling Support: Setup Infinispan backend for Hibernate/Spring caching. https://openmrs.atlassian.net/browse/TRUNK-6302

  4. Hibernate Upgrade: Upgrade Hibernate Search to 6.2.4 https://openmrs.atlassian.net/browse/TRUNK-6316

  5. Java Upgrade: Add support for Java 21, 24 https://openmrs.atlassian.net/browse/TRUNK-6311

  6. ProviderRole in Core: Migrate Provider role functionality from the Provider Management Module. https://openmrs.atlassian.net/browse/TRUNK-6354

  7. Install Wizard UI: Modernize OpenMRS installation wizard UI to match the current OpenMRS branding. https://openmrs.atlassian.net/browse/TRUNK-6329

  8. Security Fixes from Library Upgrades: Upgrade a number of underlying library dependencies to take advantage of security vulnerability fixes.

  9. Hibernate Annotations: Migrate more domain objects from Hibernate xml mappings to annotations. https://openmrs.atlassian.net/browse/TRUNK-5748

  10. Support Postgres in Setup: Add Simple Installation Method for PosgreSQL. https://openmrs.atlassian.net/browse/TRUNK-6343

Platform & Backend Improvement Ideas from 2024

Platform 2.7 (Q1 2024 - before mid 2024)

Have feedback about this list? We want to hear from you! Please share in the forum thread here: https://talk.openmrs.org/t/openmrs-platform-roadmap/38652 

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

  1. DONE on core, IN PROGRESS with modules (but not a Platform 2.7 release blocker - modules run in 2.7, but don't compile) - 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. As part of this work, the reference application modules need to be updated to also support Java 17, but without dropping support for Java 8.

  2. DONE: Upgrade to Liquibase 4.28.0 - for patches included. Need to check if this upgrade would cause any complexity for us. TRUNK-6155, TRUNK-6208

  3. Upgrade other small libraries to their latest versions. Dependabot seems to be doing a good job for us here.

  4. DONE: 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.

  5. DONE for core, TODO for Modules: Remove all uses of the Hibernate Criteria API because it’s deprecated (replaced with JPA criteria) TRUNK-6202

  6. DONE:Global properties access should be privileged, so we need an endpoint to expose those items needed (anonymously) during O3 startup. TRUNK-6203, TRUNK-6206

  7. DONE: Add support for init parameters for module servlets (TRUNK-4673) and this Talk post

  8. DONE: Docker as a first-class approach to deployment. RA-1990, TRUNK-6186, TRUNK-6083

  9. DONE: Auto deactivation of user accounts after a given number of days without logging in. TRUNK-6235

  10. ON HOLD - 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).

    1. (Pending FE guidance): an approach that lets applications discover/add to "open encounters" for a patient rather than collecting notes, orders, observations, etc. and then trying to infer which or how to group them properly into clinical encounters. This is a need for OPD and adding enough Java dev support to that effort to propose (e.g., to community & TAC) how to better organize data into clinical encounters.. A /dev/4 or /dev/5 with Java (backend) experience & familiarity w/ the model. Probably needs input from clinical SMEs too.

      • E.g. if I directly add an allergy or add a new condition, which encounter is it supposed to be logged in? 

      • E.g. I need to enter lab results that came in after the patient left the clinic - or results from weeks ago that the patient has just handed me, while  they also have an active visit.

  11. ON HOLD - Extract Immunization like we did for Allergies, Conditions, Diagnosis (Was not done). Need to be able to attribute these (including Allergies, Conditions, Diagnoses) to an encounter. (On hold - lack of consensus)

Platform 2.6 (Q1 2023)

Platform 2.5 (Q4 2021)

Tickets for Platform 2.5

key summary type created updated due assignee reporter priority status resolution

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Additional candidates for 2.5:

2021 Goal Brainstorming

Actual Tech Priorities (Ideas):

  • Platform QA: Some regressions - need more automation to catch in advance, esp. build into PR pipeline

    • Automation +++: Get platform to point where enough is automated so have confidence in quality and release more frequently

  • Simplifying Deployment

  • Support for timezones across the Platform (and beyond, see also about HFE here.)

  • FHIR

    • Support for FHIR Group through maybe a new Core Group entity replacing Cohort (see Slack discussion here.)

  • Metadata Sharing: a solution that meets majority of needs (if Iniz, maybe expand and handle a few additional use cases; come up with something that's better than our old tech for metadata sharing)

  • Integration: Clarify actionable things we can do to better integrate into other Digital Health tools that are typically found around an EMR like OpenMRS.

  • i18n: Fully internationalizing metadata concepts (but is this really a priority, pain point?)

    • Support for i18n of metadata in Core (see for example this thread.)

  • Download & Run: Easier to use without getting bogged down in details - something non-tech end user can work with. Standalone hasn't advanced in a while - needs love for feature updates or different approach or make useable again (e.g. some Mac versions no longer running). People using Standalone in production b/c simple to manage, came up with backups automation approach. → So easy to download, click and it runs. Using tech that's already available on users' computers. 

  • Sync: Most implementations not connected to single server; most combine, do analysis later. Is this a priority for implementers now?

  • Patient Lists: FHIR-based patient lists proposal from Ampath

  • Library dependencies between modules (not high priority because so time consuming, and there are (ugly) workarounds)

  • Decision Support: Some meaningful step (e.g. with simpler ETL solution: flattened data, generates table, SQL, extrapolate from that). Feels we are waiting for AES to eventually address.