Order Entry UI Sprint 4 Announcement

Hello everyone,

This is the official announcement for Order Entry UI sprint 4. In this sprint, we would be implementing feedback received from sprint 3 demo and completing the remaining functionalities using React/Redux.


  • Implement sprint 3 feedback
  • Checking the existence of encounter role
  • Update and optimise application tests
  • Fix Linter and prop type validation issues
  • Implement pagination for active drug orders
  • Consume Api to discontinue/delete an active order
  • Make a POST request to actually add orders.
  • Consume Api to edit an existing order

Start Date: 7th May 2018

End Date: 21st May 2018


Jira Board: https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=159

Github Repo: https://github.com/openmrs/openmrs-owa-orderentry

Wiki: https://wiki.openmrs.org/display/docs/Order+Entry+UI+Sprint+4

Sprint planning session - https://www.youtube.com/watch?v=UCcAvY47ujc

Development Team

Flavia Nshemerirwe

Fredrick Mgbeoma

Lanre Lawal

Geoffrey Asiimwe

Osaze Edo-Osagie

Betty Kebenei

cc @dkayiwa @flavia @larrystone @betty @zeze @geofrocker @kodero

1 Like

Currently working on the sprint 3 demo feedback to sort past orders according to the most recent. Need some assistance here.

  • Is there backend support for sorting orders?

  • If yes, how do I enable it?

cc: @darius @dkayiwa @mogoodrich @wyclif @kodero

@fred, could you give a bit more info? What’s the screen that you’re working on? What’s the REST call that you’re doing now?

It’s likely that the REST API does not give sorted orders yet, and you’ll need to add this. (I peeked at the code quickly and it seems like it’s also doing something inefficient if there are many inactive orders.)

It’s also the case that the “past orders” screen may need some UI rethinking, so maybe it’s worth doing that first before making the changes to the REST API… I actually don’t think that we should have “Past Prescriptions” right under the active ones, because over time there are too many of them. I think the user should actively have to click somewhere to see past orders.

In Bahmni’s these are then grouped by date, which might be a nice touch. See their proposed redesign here: https://docs.google.com/document/d/11xKT3pV9Us4-oPKYzw38C5KhZb65TNnO3gW2Gp1BEMc/edit#heading=h.z1khodomvthp

To give more context. The feedback the team received suggested that past orders should be arranged according to the most recent past orders. Below is the endpoint being used to retrieve past orders:


In order to implement the suggested feedback, we need more information about the endpoint that might not be in the API documentation, such as the following:

  • Does the order REST API endpoint support sorting?

  • If yes, do I need to pass a parameter to the endpoint to enable sorting?

Also, the Past Orders tab is always closed on page load. The tab pulls down to show the past orders only when the user clicks on it.

Page screenshot:

Thanks, this context helps.

So, I don’t think the order REST API supports sorting. You’re going to have to add support to this.

The relevant section of code is https://github.com/openmrs/openmrs-module-webservices.rest/blob/2.22.0/omod-1.10/src/main/java/org/openmrs/module/webservices/rest/web/v1_0/resource/openmrs1_10/OrderResource1_10.java#L209

Ideally this should be implemented so that it’s efficient, i.e. you let the DB take care of sorting and paging. Peeking at the underlying Java API (https://github.com/openmrs/openmrs-core/blob/2.1.3/api/src/main/java/org/openmrs/api/OrderService.java) I do not think that is supported right now.

So, the quick-fix is probably to do a sort before returning the result in the REST resource. (This is hacky but the code already there looks quite hacky.) The better fix (which you should either do or at least add a ticket for) would be to the implement the query against the DB. (This might need to be in the REST module first, but with a plan to add it to openmrs-core…)


Thanks for that information @darius.

Thanks for the detailed feedback.

Have considered the first alternative you suggested, but there is a challenge with this approach. The results returned by the endpoint for each call is restricted to the limit supplied which may affect accuracy. For instance, say the total number of past orders is 100, the first call returns 10 results, then this result is sorted on the frontend. The challenge this poses is that the newly sorted result might be incorrect because it was based on the 10 results returned by the first call. When a second API call is made, we get another set of 10 results which is sorted independent of the initial 10 results.

The better fix you suggested would be helpful in this case. However, that is outside the scope of our current Order Entry UI implementation. Could we get backend support from the community to implement this?

cc: @dkayiwa @wyclif @mogoodrich @kodero

Thahks for detailed analysis @fred!

The first step would be to add a ticket to the “Web Service REST module” for adding sorting to the Order object… the response from @darius gives a good summary of the possible options.

Feel free to tag me on the ticket and I’ll make sure it’s “ready for work” and tagged as “community-priority”. And if anyone working on the Order Entry sprint is looking to do some Java coding, feel free to pick it up, I’m available to do code reviews.

Take care, Mark

From peeking at the code I thought (because it uses the NeedsPaging helper class) that (1) it’s inefficient, but (2) you could just sort, because it’s all in memory at that point.

Noted. Would add a ticket for sorting to “Web Service REST module” as @mogoodrich has suggested.

Please could you assist me with the link for “Web Service REST module”. Thank you.

@fred you can just search for the project by name (“Web Services REST”) or slugline (“RESTWS”) when creating the issue.

Here’s the link to the project, but, strangely, it doesn’t seem to go to a relevant page:


Thanks for the link.

I have created the ticket here - RESTWS-706

Great, thanks @fred I will take a look…

Please, any update on this issue?

cc: @dkayiwa @wyclif @mogoodrich @kodero

I’ve added some design notes on the ticket and marked it “ready for work”.

We currently have a task that is dependent on this implementation.

Thank you for the update.

@fred (and others) - Is there a staging server that’s best you are using to see the latest? I will start writing up my feedback and testing this code.

I apologize if this have been answered elsewhere.


@fred for now, can you upload the latest here? modules-refapp.openmrs.org/openmrs/

@ddesimone I would upload the latest version of the app to the link posted by Daniel, and update this talk post.