Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata

Friday September 19th 2014 

This version of the OpenMRS Platform is not intended for use for implementations running the reference application(OpenMRS 2.0) because it has several backwards incompatible changes that will break some modules.


What's New

Introducing: OpenMRS Platform

When OpenMRS reached 2.0, we decided to allow the platform – application programmer interface (API) and web services – to develop and grow separately from the web application.  As a result, we have named the API and web services "OpenMRS Platform" and will continue to call our web-based medical record system "OpenMRS".

  • OpenMRS – this continues to refer to our web-based medical record system.
  • OpenMRS Platform – going forward, this refers to the API and web services used under the hood.  When the OpenMRS application has sufficiently replaced the legacy user interface components, the user interface components will be removed from the platform.

For the time being, we are in an awkward phase, where the legacy UI remains within the OpenMRS Platform and the new OpenMRS UI has not fully replaced the legacy UI. As a result, many implementations will continue to use the platform without the new web application and people will continue to be confused by the naming of "OpenMRS Platform". We are working hard to resolve this by OpenMRS 2.2 (or, worse case, OpenMRS 2.3), when implementations will be able to upgrade into the new application and the legacy UI can be retired from the platform.

This release is "OpenMRS Platform 1.10" – it is the release version of the under-the-hood OpenMRS API that follows the OpenMRS 1.9.x line.

New Features

The order entry API in prior versions was not well designed and not as useful in handling the relatively complex ordering workflows in a typical clinical setting. Therefore, the main focus for this version was to refactor the order entry API. The release has 2 major changes.

  • Re-designed Order Entry API in a backwards incompatible way, there isn't yet a user interface for managing orders and order types, see below for user interface changes
  • Conditional resource loading to support multiple OpenMRS versions in a module
  • The exit patient from care feature has been removed from the legacy patient dashboard and will be provided in a module.

You will certainly need to read Prepare for Upgrading From a Pre-1.10 to 1.10 or Later Version

Who is this release meant for?

Implementations that are not running the reference application and would like to use the new order entry API i.e. if you are running a module or modules that consumes the new order entry API.

Community Input

A huge thanks to the 25+ people that contributed code to this release: Ak, Alexis Cartier, Andras Szell, Bharti Nagpal, Damian Szafranek, Daniel Kayiwa, Darius Jazayeri, Deepak N, Harsha Kumara, Gitahi Ng'ang'a, Jakub Kondrat, Kaweesi Joseph, Krzysztof Kaczmarczyk, Lech Rozanski, Mark Goodrich, Mhawila Ahmed Mihir Khatwani, Mujir Shaikh, Nicholas Ingosi Magaja, Rafal Korytkowski, Rohan Poddar, Shruthi Dipali, Vinay Venu, Vinkesh Banka, Wyclif Luyima.

Not to mention all the people that contributed in countless other ways to support this release and be a great part of the shaping it: Burke Mamlin, Paul Biondich, Ryan Yates, Michael Downey, Elliot Williams, Anushya Prasad, Mike Seaton, Andy Kanter, Shasha Lui, Chris Power, Jonathan Teich, Roger Friedman.


We welcome any user to download OpenMRS 1.10.0 and try it out, give us feedback, and potentially bug reports on this release.

If you happen to run into any sort of obscure bugs, send an email to one of the mailing lists or create a new JIRA ticket (click upper right icon).


OpenMRS Platform 1.10.0 represents revision: d8b5d007c91e64eb1e82d9d5db10076863570fcd

Download OpenMRS Platform 1.10.0

Bundled Modules

  • Rest Web Services 2.6

User Interface Changes

  • All UI components for managing order and order types have been removed.
  • The regimens tab on the patient dashboard has been removed.
  • You can no longer merge patient where any of the losing patients has active orders

Non-Backwards-Compatible Changes for Developers

Developers take note: unfortunately 1.10 includes several non-backwards-compatible changes from prior versions for the following classes.

  • OrderService
  • Order
  • DrugOrder
  • OrderUtil

But as mentioned earlier, with the introduction of conditional resource loading, you should be able to work with different versions in your modules.

Required configurations for the new order entry API

In order for the new order entry API to work as expected, the following configurations need to be made:

  • Set the values for following global properties:

order.drugRoutesConceptUuid: Specifies the uuid of the concept set where its members represent the possible drug routes

order.drugDosingUnitsConceptUuid: Specifies the uuid of the concept set where its members represent the possible drug dosing units

order.drugDispensingUnitsConceptUuid: Specifies the uuid of the concept set where its members represent the possible drug dispensing units

order.durationUnitsConceptUuid - Specifies the uuid of the concept set where its members represent the possible duration units

order.testSpecimenSourcesConceptUuid - Specifies the uuid of the concept set where its members represent the possible test specimen sources

  • Add concept mappings to SNOMED CT concept source to durations concepts, these are the concepts that constitute the set members of the concept that has a uuid that matches the value of the order.durationUnitsConceptUuid global property.
  • Concept classes for orderable concepts must be mapped to order types. As of the 1.10.0 release, this has to be do manually by the admin by adding entries to the order_type_class_map table in the database, the columns values should be the order type and concept class ids.


New Features

  • TRUNK-4121 - Getting issue details... STATUS  - Create foundation of Order Entry API for 1.10+

Bug Fixes

Changes since 1.10.0 Beta

TRUNK-4373 - Getting issue details... STATUS

TRUNK-287 - Getting issue details... STATUS

TRUNK-4436 - Getting issue details... STATUS

TRUNK-4437 - Getting issue details... STATUS

TRUNK-4438 - Getting issue details... STATUS

TRUNK-4443 - Getting issue details... STATUS

TRUNK-4442 - Getting issue details... STATUS

TRUNK-4444 - Getting issue details... STATUS

TRUNK-3586 - Getting issue details... STATUS

TRUNK-4445 - Getting issue details... STATUS

TRUNK-4280 - Getting issue details... STATUS

TRUNK-4430 - Getting issue details... STATUS

TRUNK-4472 - Getting issue details... STATUS

TRUNK-4440 - Getting issue details... STATUS

TRUNK-4446 - Getting issue details... STATUS

TRUNK-4484 - Getting issue details... STATUS

TRUNK-4238 - Getting issue details... STATUS

TRUNK-4488 - Getting issue details... STATUS

TRUNK-2671 - Getting issue details... STATUS


Platform 1.10.0 focused on introducing a flexible Order Service. There were significant changes made to orders, drug_order, and test_order tables and some new tables were added: care_setting, drug_reference_map, order_frequency, order_type, order_type_class_map.

- Adding unique key constraint to column
- Adding java_class_name column to order_type table
- Adding parent column to order_type table
- Setting java_class_name column for drug order type row
- Add not-null constraint on order_type.java_class_name column
- Insert order type for test orders
- Making orders.start_date not nullable
- Making order.encounter required
- Make orders.orderer not NULLable
- Renaming drug_order.prn column to drug_order.as_needed
- Adding as_needed_condition column to drug_order table
- Adding order_number column to orders table
- Setting order numbers for existing orders
- Making orders.order_number not nullable
- Adding previous_order_id to orders
- Adding order_action to orders and setting order_actions as NEW for existing orders
- Renaming drug_order.complex to dosing_type
- Making drug_order.dosing_type nullable
- Converting values in drug_order.dosing_type column
- Adding num_refills column to drug_order table
- Create the order_frequency table
- Adding dosing_instructions column to drug_order table
- Adding comment_to_fulfiller column to orders table
- Adding duration column to drug_order table
- Adding duration_units column to drug_order table
- Adding quantity_units column to drug_order table
- Changing quantity column of drug_order to double
- Adding route column to drug_order table
- Dropping equivalent_daily_dose column from drug_order table
- Adding dose_units column to drug_order table
- Adding foreignKey constraint on dose_units
- Migrating old text units to coded dose_units in drug_order
- Deleting units column
- Adding frequency column to test_order table
- Adding number_of_repeats column to test_order table
- Rename orders.discontinued_date to date_stopped
- Creating Discontinue Order for discontinued orders
- Setting order.discontinued_reason to null for stopped orders
- Setting orders.discontinued_reason_non_coded to null for stopped orders
- Removing discontinued from orders
- Dropping fk constraint on orders.discontinued_by column to users.user_id column
- Removing discontinued_by from orders
- Temporarily renaming drug_order.frequency column to frequency_text
- Adding the frequency column to the drug_order table
- Creating coded order frequencies for drug order frequencies
- Migrating drug order frequencies to coded order frequencies
- Dropping temporary column drug_order.frequency_text
- Adding care_setting table
- Adding OUTPATIENT care setting
- Adding INPATIENT care setting
- Add care_setting column to orders table
- Set default value for orders.care_setting column for existing rows
- Make care_setting column non-nullable
- Add foreign key constraint
- Add drug_reference_map table
- Temporary dropping foreign key on orders.discontinued_reason column
- Renaming orders.discontinued_reason column to order_reason
- Adding back foreign key on orders.discontinued_reason column
- Renaming orders.discontinued_reason_non_coded column to order_reason_non_coded
- Creating provider accounts for all users who have placed orders for patients and have no associated provider accounts
- Temporarily removing foreign key constraint from orders.orderer column
- Converting orders.orderer to reference provider.provider_id
- Adding foreign key constraint to orders.orderer column
- Inserting Frequency concept class
- Adding scheduled_date column to orders table
- Add order_type_class_map table
- Concatenate dose_strength and units to form the value for the new strength field
- Add changed_by column to order_type table
- Add date_changed column to order_type table
- Adding foreign key constraint from order_type.parent column to orders.order_id column
- Add brand_name column to drug_order table
- Add dispense_as_written column to drug_order table
- Dropping default value for drug_order.drug_inventory_id
- Renaming the start_date in order table to date_activated
- Increase size of dosing type column to 255 characters
- Changing duration column of drug_order to int

Upcoming End of Release Notice

OpenMRS 1.7 is no longer supported

As described in Unsupported Releases (EOL), OpenMRS can only support up to three released versions at a time (the current release and then two versions back). With the release of OpenMRS 1.10.0, support is no longer provided by the core Development Team for OpenMRS 1.7.x and earlier. This announcement also serves as advance notice that support will end for OpenMRS 1.8.x, concurrent with the release of OpenMRS 1.11.0



  • No labels

1 Comment

  1. I like the introduction of OpenMRS platform here Wyclif Luyima (smile) and so i adopt it also to 1.11 platform release