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.

Table of Contents

Product Roadmap

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

Go to the OMRS Product Roadmap

Milestones

Platform 2.7 (Q4 2023 - before 2023 ends)

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.

Implement Encounter Context and Visit Context.
Extract Immunization like we did for Allergies, Conditions, Diagnosis.
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.
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.)
Upgrade to Liquibase 4.19.0 - for patches included. Need to check if this upgrade would cause any complexity for us.
Upgrade to Hibernate 6.1.7.Final - for patches included. Need to check if this upgrade would cause any complexity for us.
Upgrade to Spring 6.0.5 - for patches included. Need to check if this upgrade would cause any complexity for us.
Upgrade other small libraries to their latest versions.
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.
Add onsetDate to Allergy and AllergyReaction. https://github.com/openmrs/openmrs-esm-patient-chart/pull/1073

Platform 2.6 (Q1 2023)

Platform 2.5 (Q4 2021)

Support for Tomcat 8.5+
Support for FormRecordable for more than just Obs and Condition
Administration via REST

Tickets for Platform 2.5

Key	Summary	T	Created	Updated	Due	Assignee	Reporter	P	Status	Resolution

Loading...

Refresh

Additional candidates for 2.5:

Patient Lists (Cohort Module changes)
User settings TRUNK-6020 - Getting issue details... STATUS
Moving OrderTest toward ServiceOrder to support Referrals

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.

Release Calendar

How to update this calendar

List View

EDIT THE CALENDAR
Customize the different types of events you'd like to manage in this calendar.
#legIndex/#totalLegs
RESTRICT THE CALENDAR
Optionally, restrict who can view or add events to the team calendar.
#legIndex/#totalLegs
SHARE WITH YOUR TEAM
Grab the calendar's URL and email it to your team, or paste it on a page to embed the calendar.
#legIndex/#totalLegs
ADD AN EVENT
The calendar is ready to go! Click any day on the calendar to add an event or use the Add event button.
#legIndex/#totalLegs
SUBSCRIBE
Subscribe to calendars using your favorite calendar client.
#legIndex/#totalLegs

Calendar View

EDIT THE CALENDAR
Customize the different types of events you'd like to manage in this calendar.
#legIndex/#totalLegs
RESTRICT THE CALENDAR
Optionally, restrict who can view or add events to the team calendar.
#legIndex/#totalLegs
SHARE WITH YOUR TEAM
Grab the calendar's URL and email it to your team, or paste it on a page to embed the calendar.
#legIndex/#totalLegs
ADD AN EVENT
The calendar is ready to go! Click any day on the calendar to add an event or use the Add event button.
#legIndex/#totalLegs
SUBSCRIBE
Subscribe to calendars using your favorite calendar client.
#legIndex/#totalLegs

Someday

Reference Application Someday

Feature	Description	Status	Point of Contact	Comments
Add Order Entry UI	Add some sort of user interface for doing order entry.		Daniel Kayiwa	We could polish up the orderentryui module, or do an OWA from scratch. Whichever we find easier.
Add Patient Flags Module		NOT DONE		Still under development
Responsive ability to the clinician facing dashboard	RA-1285 - Getting issue details... STATUS	Accepted
Core and modules to advertise capabilities that can be configured and manipulated	RA-1292 - Getting issue details... STATUS	NOT DONE		Not started
MPI enhancements to Registration App and Registration Core	Production quality integration with OpenEMPI using HL7 v3 PIX/PDQ messaging standards	IN PROGRESS	Nathaelf Hyppolite	Discussion on talk.
Pre-built Reporting Tools	This includes the ability to do several things. Run a report for a patient directly form the patient dashboard. RA-381 - Getting issue details... STATUS	IN PROGRESS	Mike Seaton	Patient summary module does not provide adequate configuration and doesn't work in Ref App. 27-March: We could include Reporting REST documentation that Darius Jazayeri and the Andela team have done.

OCL subscription module	Using KenyaEMR as a use case, create a tool for subscribing an OpenMRS instance to a dictionary (e.g. the CIEL dictionary)	BETA	Nicholas Ingosi and Rafa? Korytkowski	OCLM-24 - Getting issue details... STATUS
Retrospective data entry	Basic support for retrospective data entry within the Reference Application RA-68 - Getting issue details... STATUS	NOT STARTED		Needs a user centric story - add to existing ticket
OpenMRS Web Framework	From discussions in #MOZ15, we would like for the OpenMRS Platform to evolve toward providing a web framework that allows developers to add functionality using standard development tools (e.g., HTML5 + JavaScript against REST services, AngularJS apps, OWA , ...).	IN DESIGN	Burke Mamlin	Ranking REST tickets on 5 Aug design call. Burke Mamlin and Darius Jazayeri discussed 24-July-2015 and Darius will make a Talk topic to move this forward. Bahmni technical deep dive scheduled for 4 June Developers Forum. 17 June design forum will discuss progress (coordinating various efforts). As well as look at how to make REST services more robust. Darius still working w/ Bahmni on fundamental pieces of their web framework to pull into OpenMRS (will talk about this on future call). 25 June dev forum on REST web services: how to substantially improve them W/ Burke Mamlin & Darius Jazayeri
Vertical Packaging	OpenMRS has a lot of flexibility and extensibility with a central concept dictionary, RBAC, forms, reports, modules, and apps; however, it's not always easy to know which metadata goes with which functionality. The goal of vertical packaging is to define best practices for managing and relating all of the components (metadata & behavior) that work together to solve a particular problem within OpenMRS. Eventually, we envision a way that someone could easily add the MDRTB package to their OpenMRS implementation to begin treating MDRTB patients... or upgrade their Oncology package, etc.	IN DESIGN	Rafal Korytkowski	Need to look at the design we had and see if we can get it in 2.3 Burke Mamlin to share first draft of metadata mapping design on Talk. First step will be to add ability to map metadata, 22 June design forum Discussed on 20 May design forum.
Condition List	Manage & view patient problems (e.g., on the patient dashboard and integrated with diagnosis capture) EA-40 - Getting issue details... STATUS See also: RA-209 - Getting issue details... STATUS RA-580 - Getting issue details... STATUS	DONE see Condition List board	Daniel Kayiwa Ravinder Kumar	Daniel took a look at condition list to see what we need to do to get the API in 2.3 and believes if we do not get volunteers on admin sprint then condition list will not be ready., 13 April WIP given on design call 1 June design forum to define how encounter diagnoses should work with conditions (and condition list). Talked w/ Bahmni BA (Saranya) about use cases and requirements on 15 June design forum
Basic Order Entry for meds and tests	Basic ordering of meds and tests "out of the box" in Reference Application.	STALLED
Ad Hoc Analysis tool (v1)	Incorporate new cohort definition tool. RA-261 - Getting issue details... STATUS	STALLED
Concept Management Improvements	Allow for concept merging and easier browsing through concepts and references terms without losing frame of reference.
Improvements to Permissions (technical implementation)	Avoid giving all API privileges to users RA-341 - Getting issue details... STATUS	NOT DONE	Burke Mamlin	Needs discussion and design Would like input from implementations, PIH (Mark, Mike, David) AMPATH, Kenya EMR, BAMI/JSS Need to reach out for inputs! Kiran has started helping with this
Provider Management	Would include provider types and ability to retire the old provider management module. Will remove UI library module once provider management is in the core.	NOT DONE

Platform Someday

Feature	Description	Status
Anonymous Patients	Support for unnamed John Doe patients RA-62 - Getting issue details... STATUS	NOT DONE
Test Patients	Support for tagging & recognizing test/fake patients, so they can be ignored within reports. RA-65 - Getting issue details... STATUS	NOT DONE
Clinical Encounter	Record the entire clinical transaction piece-by-piece as part of a Session, as opposed to via a Form.	Is this still relevant?
Patient Lists	e.g. "My Patients", "Inpatients on Service XYZ", etc. (Related to RA-202.)
Program Enrollments	v1: capturing this data; v2: drive available forms/actions based on program state

Wiki Spaces

Get Help from Others

Documentation

Page tree