Platform Release Notes 1.10.0

Platform Release Notes 1.10.0

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).

Download

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.

Changelog

New Features

  •  - Create foundation of Order Entry API for 1.10+

Bug Fixes