What is the OpenMRS Technical Road Map?The Technical OpenMRS Road Map 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 road map milestones are chosen and prioritized, see the Technical Road Map Planning page.
Platform 1.12 (TBD)
Release Manager: Bharat Akkinepalli
|Point of Contact
|Support for Free Text Drug Order Names
Allow users to order drugs that are not yet codified in the system as DRUG OTHER with a user-specified name.
|Vinay Venu & user-f2092
|Basic Order Set Implementation
|Vinay Venu & user-f2092
14-Mar: ThoughtWorks team working on release of 1.12 beta. Final work requires forward-porting to 2.0.x and master. Mayank Sharma to reach out to Vinay Venu & Bharat Akkinepalli (cc Darius Jazayeri) to formally request forward porting of Order Sets to master so they can be backported to 2.0.x
7-Mar: Order Sets merged into 1.12.x.
29-Feb: Finalized design on design forum. Expect merge this week.
22-Feb: (Lengthy) discussion has been taking place on this pull request.
8-Feb: Work on order sets is nearly complete. Some small changes needed based on code review and then pull requests merged before 1.12.x can be released. Most of work on related web services has been done and is waiting for 1.12.x to be released.
Akhil Malhotra will be creating JIRA tickets this week
|Retrospectively Editing Orders
|Bharat Akkinepalli & Prabhu Awasthi
|(Will this happen for sure during Platform 1.12?)
Platform 2.0 (Q1 2016)
Release Manager: Mayank Sharma
|Point of Contact
|Java 8 support
Starting with OpenMRS 2.3, OpenMRS will be built against Java 8 and begin using Java 8 language features, which means that OpenMRS 2.3+ will require Java 8+ to run.
|Upgrade Underlying Technologies
Upgrade to the latest version of underlying technologies in the Platform:
We need to start ensuring modules in the Reference Application are refactored so they can run against Platform 2.0 with new Spring & Hibernate
|Update REST web services
REST web services must be updated to support Platform 2.0 changes.
18-Apr – Beginning testing of REST API on Platform 2.0-beta
FHIR web services should be added to the platform to run alongside the OpenMRS REST web services.
Version 0.9.1 released.
As of 11-Jan, need to toggle off diagnostic reports if not already ready for release.
|Open Web App Support
Include OWA Module
|Remove Legacy UI
The legacy UI should be moved to a module. A key goal for Platform 2.0 is that the platform is not a web application.
|Tharunya Pati and Wyclif Luyima
18-Apr – Installing Legacy UI module on Platform 2.0–beta on UAT
As of 11-Jan, released v0.1. Plan to release v1.0 with Platform 2.0.
|Allergies in core
Allergies were introduced with Reference Application 2.2. We will bring them into the core platform with 2.0 (and remove the old, largely unused allergy support).
Also, the REST module needs to be updated to support this new API:
18-Apr – Testing completed
As of 4-Jan, we decided on the REST resource approach, and will work on this after the alpha.
|Remove deprecated methods
Moving to Platform 2.0 is an opportunity to clean house and remove deprecated methods.
The testing is waiting upon the reference application modules to run on Platform 2.0
|Outstanding Platform 2.0 tickets
18-Apr – Beta being released this week
28-Mar – 1.12 changes have been forward-ported to master. Most of work needed for beta release is done.
14-Mar – we talked through 10 remaining tickets and most should be resolved over the next week
7-Mar – Only a handful of tickets remaining. Currently aiming for beta release in the next week or so.
1 Feb – Platform 2.0-beta sprint was to be completed, but still have ~4 tickets ready for work and ~5 in progress, so plan to extend Sprint for an additional week.
11 Jan - Mayank planning on sprint on these issues once Alpha is released
13 Nov - Mayank and Daniel cutting down outstanding trunk tickets to have the must haves for 2.0 on 17 Nov
As of 23 Nov, down to 10 tickets. Platform 2.0-alpha sprint is ongoing.
Reference Application 2.4 (
March 2016, April or May 2016)
Release Manager: James deGraft-Johnson
|Point of Contact
|General Improvements to Reference Application
Latest versions of included modules
26-Apr: Releasing ref app to UAT with the CIEL manual work around but will be using the final CIEL release in the final ref app release. James is currently blocked on getting changes to referencemetadata, necessary to the release of CIEL in ref app, merged so the release to UAT can proceed.
28–Mar: most modules have been released. There are a couple blockers (e.g., RESTWS) and James deGraft-Johnson needs some help with creating release notes for all the changes across the 38 modules. Will work on setting up uat-refapp.openmrs.org.
7-Mar: working on creating CIEL data for release this week and will be getting module releases done over the next week.
Reference Application 2.5+ (September 2016)
Release Manager: TBD
|Point of Contact
|Include more translations
Start automatically importing community-sourced translations from Transifex into all the Reference Application modules
|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)
|Nicholas Ingosi and Rafał Korytkowski
Basic support for retrospective data entry within the Reference Application- RA-68Getting issue details... STATUS
|Needs a user centric story - add to existing ticket
|OpenMRS Web Framework
Ranking REST tickets on 5 Aug design call.
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).
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.
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.
Manage & view patient problems (e.g., on the patient dashboard and integrated with diagnosis capture)
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.,
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.
Incorporate new cohort definition tool.
|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
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
|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.
|Multiple concept classes per concept
|- TRUNK-4540Getting issue details... STATUS
Support for unnamed John Doe patients
|Clinician Facing Patient Dashboard (v2)
Patient summary and dashboard designed for doctors and nurses
Merge duplicate patient records into one.- RA-63Getting issue details... STATUS
Support for tagging & recognizing test/fake patients, so they can be ignored within reports.- RA-65Getting issue details... STATUS
|Patient Lookup (v2)
Search for a patient by name or ID
A form to record medication dispensing events within the patient record
|Decision Support (v1)
|The first trivial example of providing decision-support feedback (includes significant design and back-end discussions)
|Record the entire clinical transaction piece-by-piece as part of a Session, as opposed to via a Form.
|e.g. "My Patients", "Inpatients on Service XYZ", etc. (Related to RA-202.)
|v1: capturing this data; v2: drive available forms/actions based on program state
|Easy Chart Review / Flowsheets
|Reviewing the patient's whole electronic record for data points of interest (also has been called "Chart Search")
|Update REST web service module
|Some changes that were made to openmrs-core are not yet reflected in the REST web services module. - RESTWS-538Getting issue details... STATUS