Hi everyone!
So we started sprint 7 with tickets to implement this mockup(Consolidated Order Entry - Documentation - OpenMRS Wiki) provided by @ddesimone. However, we identified some design/implementation problems with the mockup and we were able to come up with a tweaked version of the mockup that fixes the identified issues.
The Issue
Having the history of the different type of Orders in the same list won’t be a good implementation and this is because:
The format of the history of each Order might differ, presenting them on the same list might not be a good design
A user that wants to see only the Lab Orders for a patient won’t be able to do this, he/she would have to fetch all the Orders(that would be mixed up).
The source of these histories are not the same, the availability of the history of one Order type should not be affecting the other.
What We Came Up With
We were able to tweak the UI flow to fix these issues and this is the flow we came up with:
The administrator visits the page
He/she chooses from a list of Order types
The entry form for that Order type and its History appears.
This is a mockup representing the tweaked UI flow: new-order-wireframe.pdf (389.3 KB)
With This Flow
We can have different kinds of lists to represent the Order history for each order type
A user can focus on a particular type of order at a time performing operations on it(adding, discarding etc) and also be viewing its history(without distraction)
It would be easier for us to add other types of Orders as the project expands.
I agree that we wouldn’t want to mix different types of orders in the same table/list, but it seems like in the original mockup it would be possible to a “Drug Orders” table and a “Lab Orders” table under “Active Orders”?
I haven’t been deeply involved in the layout discussions… @ddesimone is out on vacation, but will be back on Monday. Also flagging @mseaton.
As I responded to @ddesimone in the other thread Consolidated Order Entry Design, it definitely makes sense to be able to see only orders of one type, and for order types where “active orders” is a useful concept, it makes sense to use that list to show active orders that can be edited or discontinued. I also agree that it is good to show the prior orders of a given type together with an easy way to initiate a new order of that type – although screen real estate may demand that you make the new order just a link or a button; then, if the user selects an existing order and choose “Edit”, or if the user chooses the new-order button, you can show the full order-type-specific ordering template.
However, it is also important to have a view that shows all the orders of all types in the order they were entered. Very often orders of various types are ordered together; for example, for a patient with pneumonia I will order an x-ray, some lab tests and an antibiotic all in quick succession. Later on I will want to see that I did all those things together. Similarly to the above, the user could select one of the orders in the consolidated list and click “Edit” and bring up the appropriate form for that order type.
It is true that orders of different types have different forms. What most systems have done is to have a text representation of each order that is entered, and that’s what you see on the consolidated view (you can use it on the separate order-type views as well). Thus, a medication order would be formatted as “Amoxicillin Oral Capsule 500mg once daily for 10 days [starting now]” and a lab order would be formatted as “CBC, electrolytes, urinalysis starting tomorrow morning”. This also has the advantage of being more readable to the clinicians.
If you go this path, I can help supply text formats that incorporate the structured fields of most order types.
@tunmi, does the feedback above (and in the thread consolidated order entry design), makes sense? Will someone on your team produce updated mockups or prototypes, or if it is helpful, I can do that.
The pieces of feedback from the two Talk posts definitely makes a lot of sense.
However, my team already started work on implementing what was discussed earlier and we have been able to get some tickets done. You can take a look at our JIRA BOARD here.
In order to avoid more back and forth with the UI flow/design, I would set up a design call(as suggested by @mogoodrichhere) where we can present what we have been able to achieve so far and how we can integrate the feedback into what is already existing.