Order Entry UI Sprint 5 Announcement

Hello everyone,

In this sprint, we shall be implementing the feedback received from sprint 4 demo and fixing any bugs identified along the way. The Order Entry Open Web application can so far support the following functionalities:

  1. Create new drug order(s).

  2. Edit existing drug order(s).

  3. Delete existing drug order(s).

  4. Discontinue existing drug order(s).

  5. View active and past orders.


  • Fix identified bugs.
  • Implement feedback received from the community.

Start Date: 22 May 2018

End Date: 05 Jun 2018


Sprint planning call

1. Date: 22nd May, 2018

2. Time: 5pm - 6pm (EAT)

3. Link: here

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

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

Wiki: https://wiki.openmrs.org/display/projects/Order+Entry+UI+sprint+5

Development Team

  1. Flavia Nshemerirwe
  2. Fredrick Mgbeoma
  3. Lanre Lawal
  4. Geoffrey Asiimwe
  5. Osaze Edo-Osagie
  6. Betty Kebenei

cc @dkayiwa, @fred, @betty, @zeze, @larrystone, @geofrocker, @ddesimone, @mogoodrich, @darius, @kodero

Sprint planning call can be found here.

Thanks everyone for a good sprint planning meeting today!

Following up on a discussion we had, it would be good to get the community’s (@burke, @darius, @dkayiwa and anyone else) thoughts on the following issue I raised:

Remove dispensing requirement from Med prescribing

Currently a medication order cannot be placed if dispensing data is not entered.

Many implementations will not have their ordering clinicians dispensing drugs themselves. It should be possible to configure this so dispensing information was not included on the ordering forms.

At the very least, implementations should be able to set it up so that dispensing information is not required, but ideally so that the fields only appear during order entry if desired.

Just to clarify, you mean the quantity to dispense, and number of refills fields? These are actually required by the underlying platform for any drug order with an outpatient care setting. (See this code.)

The idea is that an outpatient prescription must be filled by some pharmacy, either inside our outside the hospital (versus inpatient prescriptions which would be delivered by the hospital staff itself). The prescriber indicates how many things should be dispensed as a required part of that prescription.

One approach is to automatically calculate it based on the dose, frequency, and duration (which is what Bahmni does), though this gets a bit trickier if the dosing unit is mg, but the dispensing unit is tablets.

I’m open to the argument that we should not actually require these. (Maybe @burke and/or @jteich can comment on this.)

To be clear, the quantity and refill for outpatient medication orders are instructions for dispensing, not actual dispensing data.

A prescriber says (in an order) “give the patient 30 tablets and let them refill it once before needing a new prescription.” This information is part of the outpatient prescription and tells the person dispensing the medication (e.g., pharmacist) how much to give the patient.

In certain circumstances the quantity to dispense may be inferred. For example, if you prescribe “take one pill daily for one week” it doesn’t take a rocket scientist to infer that the patient will need 7 pills.

In many cases (especially for prescriptions that span months or chronic medications that are taken lifelong), the duration cannot be inferred. For example, if you prescribe “take 1 tab daily”, the amount to give the patient is ambiguous.

What is the use case for an outpatient prescription without a quantity or number of refills? I’m assuming the prescriber would still need to indicate how long the prescription should be taken, but maybe without doing the actual calculation of pill counts (e.g., “give the patient enough for 2 months”).

Agree with Darius and Burke — there needs to be some sort of direction for how much to dispense, whether it is frequency x amount x duration or whether it is an actual quantity to dispense (usually tablets/pills, but could be liquid, units of insulin, grams or tubes of skin cream, etc.).

@ddesimone, I also just wanted to make sure you weren’t referring to some other dispensing information (lot numbers, specific pill sizes or other pharmacy-specific information), given the context of your post. But if we have interpreted it correctly, then I would think some way of specifying amount is needed — let us know if we have missed an important point.

Thanks guys, this is helpful. I was interpreting the “Dispense” amount as the amount that HAD BEEN dispensed instead of the amount TO dispense. Since we require frequency, duration etc… I was assuming the pharmacy would calculate this - especially since there are probably many cases where they would dispense medications in different forms than what was originally intended based on what is available.

It seems this will work for us but I would definitely like to automatically calculate it where it can, as Bahmni does. Also, we should precede the dispense amount and units with “Dispensing Instructions:”. Right now it says “For outpatient orders” (it only appears for outpatient orders).

I would also like to make an improvement to the Prescribed Medications widget that displays this information on the patient clinical dashboard. In addition to just making it easier to read, cleaning up wrapping etc… we need to determine what clinicians would really like to see as a summary.

Currently the following 2 columns are displayed:

  • Name of drug, including form (e.g. Acetylsalicylic acid, 100 mg, tablet)
  • dosage instruction (e.g. 2.0 Tablet Oral Three times a day)

I would suggest changing this to:

  • drug name (without the the formulation e.g. just Acetylsalicylic acid)
  • Active dates (e.g. 23-May-2018 to 2-June-2018)

My thoughts are to keep it spare and they can navigate to the orders page if they would like to see the details.

Thoughts? @burke, @jteich, anyone else?


Another data point you can look at is the patient dashboard widget that we built for the Ebola system. (This one had more design thought go into it.)


I was thinking that in the program-based communicable disease projects I’ve seen, the model may be that the program guidelines and management decide what quantities are dispensed, not necessarily the doctor.

E.g. I’ve seen where the doctor says:

  • the patient should be on standard regimen 1a
  • they should come back for a followup visit in 28 days

… therefore you’d end up dispensing 31 tablets, per the program guidelines, but that wasn’t exactly decided at the start.

Or I’ve seen an MDR-TB project where the pulmonologist sets an individualized regimen for the patient, but someone later in the flow decides how many pills to dispense.

Actually, now that I think about it, a common thread here is Directly Observed Therapy. Maybe that should be treated a bit differently than Outpatient?

@ddesimone, Usually a meds summary display does show the dose and frequency – particularly useful for active medications, because it lets the clinician know at a glance what the patient is on and how much. In the inpatient world we would probably shorten your example to “Acetylsalicylic acid, 200mg oral 3 times per day”, because inpatient prescriptions don’t include drug strength and form (the pharmacy figures that out).

Or you can pick and choose subsets from the example Darius showed for amoxicillin.

@darius, if a patient is getting drugs on a protocol, and the prescriber essentially is writing “dose per protocol”, then all bets are off, and the protocol supervisors (who may be physicians, pharmacists, etc.) would rewrite the prescription in a way that allows the pharmacist to keep track of what they have dispensed. Whether this is an actual new prescription is probably site-dependent. Essentially, writing a “dose per protocol” prescription is tantamount to writing a prescription with free-text dosing instructions, which Ebola-EMR and OpenMRS both support, I believe.

An update on one of the tickets I am working on - OEUI-101: Drug orders arrangement - most recent drug orders first. This ticket has been in progress for a while now. The reason being that it is dependent on backend implementation that is still in progress - RESTWS-706: Add sorting by dateActivated Or dateStopped to Orders.

In order to complete OEUI-101, the backend implementation would need to be updated to add support for sorting past orders based on either dateStopped or autoExpireDate. Currently, the pull request raised by Harisu in RESTWS-706 allows sorting of past orders based on dateStopped only. The challenge this poses is that if an order was auto expired, when a request is made to return all past orders, the request would result in a 500 error because the backend does not understand sorting orders based on autoExpireDate.

I have notified @harisu on GitHub about this issue and suggested a possible solution to resolve it.

cc: @kodero @dkayiwa @darius @mogoodrich @larrystone

We are working on user guides for the administrator and end user. We already have drafts for the administrator guide and end user guide. Feedback on these documents is welcome.

cc @dkayiwa, @fred, @betty, @zeze, @larrystone, @geofrocker, @ddesimone, @mogoodrich, @darius, @kodero

Thanks so much for doing documentation, something we definitely are not always good about!


Hello everyone,

I would like to thank you all for your support during this sprint. Allow us to announce our sprint demo which will take place on Monday, 4th June, 2018.

In this sprint, we were able to fix all the identified bugs and documentation. For anymore information, please refer to the links below.

Demo details

  1. Date: 4th June 2018.
  2. Time: 5:00pm-6pm (EAT).
  3. Link: To be added on Monday

Sprint Details

  1. Jira Board: https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=1621
  2. Github Repo: https://github.com/openmrs/openmrs-owa-orderentry
  3. Wiki: https://wiki.openmrs.org/display/projects/Order+Entry+UI+sprint+5

cc @dkayiwa, @fred, @betty, @zeze, @larrystone, @geofrocker, @ddesimone, @mogoodrich, @darius, @kodero

Hi @flavia,

Would it be possible to have the demo earlier or later Monday? This is the same time as the OpenMRS Project Management call.

Thanks! Dave

PM call is 6 - 7 pm Nairobi time.

@ddesimone, before we reschedule the demo, would an hour before the OpenMRS Project Management call work?

Demo: 5:00pm - 6:00pm OpenMRS Project Management call: 6:00pm - 7:00 pm.

Right, sorry for the confusion, as Daniel pointed out, the time does NOT conflict with the project management call. No need to reschedule for that reason. Sorry!


@flavia did you add this to the OpenMRS calendar?

@dkayiwa, I sent in a request last Friday, I am still waiting for the response.