Ok we showed orderentryui to our client and we have some feedback!
What you will find below is a wish list, that is pretty much settled as our requirements with them.
So @darius (and others), please step in now if you find that the requirements are getting out of line as per what should happen in your opinion. Your comments/critics will be most welcome.
The workflow should plug to the visits workflow and encounters of various types should thus be generated:
- Prescription encounters
- Dispense encounters
- Administration encounters
This means that nothing could be done if there is no active visit, even for an outpatient.
It also means that the current page should be provided both
visitId parameters. When loading the medication orders for an ended visit, then the page would become read-only.
1.1 Several, grouped, order lines make a prescription order
Each prescription order is made of several order lines (one per drug basically), that is what we are seeing right now when lines are added to the prescription.
In OpenMRS terms it seems that each order line is in fact a 'drug order'. Therefore each prescription order (which is a concept/object yet to come or to be pinpointed) is a group of drug orders.
Additionally there should be a way to create several prescription orders during one visit.
1.2 (Oupatient) The dispense occurs later, and is made by someone else
This has been noted by @arbaughj already and we have the same requirement. The basic idea if the following:
- A physician creates a prescription order at some point.
- A pharmacist dispenses it at a later point.
Two users with different privileges will thus access the page to perform a different set of actions.
1.3 (Oupatient) The order info may stick after the visit has ended
Even though the visit during which the order was made has ended, order lines that are still active should remain visible until the dispense period is over.
Example: A visit happens on a Monday and paracetamol is ordered during the visit to be taken until the next Friday, so for 5 days. Well even though the outpatient visit is ended on the day (Monday), and the paracetamol was dispensed before that, the order line should remain active, and visible where applicable, until Friday.
1.4 (Inpatient) Administration screen
We are not yet settled at all about how to put together the administration table/page/screen/fragment/... But what we know already is that each administration event is in fact a double event since it has to be double checked.
Example: Say that an inpatient prescription order states that 2ml of some drug should be administrated every 30 min for 6 hours. A nurse administers it through an 'administration encounter' each time, but then another double check event must take place: a physician will sign that the administration occurred as expected.
So those (yet to come) administration lines will have several states, at least 3:
- Nothing done yet.
- Administration done.
- Final signature given.
2. Visual & user interface
2.1 'Active' vs 'Past' --> 'Active' vs 'Discontinued'
Active order lines should be clearly visible at the top, as they currently are already. However the below section should only show discontinued order lines: those that have been hit with the cross (x) button.
2.2 Order line revisions should be accessible from the order line, but hidden by default
Rather than having past revisions always visible at the bottom, they should not be visible at first. However an order line with revisions should provide some sort of link or mechanism to see the stream of past revisions. Maybe a popup?
So Angular wise, we would need to design an 'order line widget', that carries its current data as well as its revisions's data. This widget would be added either to the top area when the order line is active, or to the bottom area when the line has been discontinued.
2.3 The page is made of prescription orders
There would be the need for a 'prescription order widget', with a top section for active order lines, and a bottom section for discontinued order lines, as said in the previous point.
The page would then be made of a list of prescription order widgets.
2.4 'Reason' not visible, and other messages
At the moment, when discontinuing an order line, a reason must be provided. However that reason is not visible anywhere after that. This should be corrected and links us back to the need of an order line widget that should know when some additional message would have to be displayed. It could be a discontinuation reason, or any reason that led to a revision (when looking at the revision of an order line).
2.5 Concept Drugs's defaults should be filled in
'Dosage Form', 'Strength' and 'Route' should be picked up from the Concept Drug's definition and filled in upon loading the drug.