These units come from the database, therefore the validation checks if this unit is in the database.
i meant which table to be specific and what data type
Order Entry UI Sprint 4 Demo Poll
Hi everyone,
We are gradually coming to the end of the current sprint (sprint 4) for the Order Entry UI, and we are excited to show the community how far we have gone with the project.
We would appreciate your feedback in helping us pick a convenient time for the demo.
Please feel free to vote for a convenient time for the demo using the doodle link - here
For more context and to understand better the issues we have worked on, Kindly visit the links below:
Order Entry UI Sprint 4 Announcement
cc @dkayiwa @flavia @zeze @larrystone @geofrocker @betty @darius @mogoodrich @kodero
The units are concepts, therefore objects but we only display its display name
. You should be able to see the available units once you click on the drop down in the input field.
Hi @harisu I have been looking into your code. I have been able to make a few adjustment to it and get it to work on the orderEntry OWA, which also required adjusting our url param from ...&t=drugorder
to ...&type=drugorder
@Override
protected PageableResult doSearch(RequestContext context) {
String patientUuid = context.getRequest().getParameter("patient");
if (patientUuid != null) {
Patient patient = ((PatientResource1_8) Context.getService(RestService.class).getResourceBySupportedClass(
Patient.class)).getByUniqueId(patientUuid);
if (patient == null) {
return new EmptySearchResult();
}
// if the user indicated a specific type, try to delegate to the appropriate subclass handler
if (context.getType() != null) {
PageableResult ret = (PageableResult) findAndInvokeSubclassHandlerMethod(context.getType(),
"getActiveOrders", patient, context);
if (ret != null) {
return ret;
}
}
String careSettingUuid = context.getRequest().getParameter("careSetting");
String asOfDateString = context.getRequest().getParameter("asOfDate");
String sortParam = context.getRequest().getParameter("sort");
CareSetting careSetting = null;
Date asOfDate = null;
if (StringUtils.isNotBlank(asOfDateString)) {
asOfDate = (Date) ConversionUtil.convert(asOfDateString, Date.class);
}
if (StringUtils.isNotBlank(careSettingUuid)) {
careSetting = ((CareSettingResource1_10) Context.getService(RestService.class).getResourceBySupportedClass(
CareSetting.class)).getByUniqueId(careSettingUuid);
}
String status = context.getRequest().getParameter("status");
List<Order> orders = OrderUtil.getOrders(patient, careSetting, null, status, asOfDate, context.getIncludeAll());
// if the user indicated a specific type, and we couldn't delegate to a subclass handler above, filter here
if (context.getType() != null) {
filterByType(orders, context.getType());
}
if (StringUtils.isNotBlank(sortParam)) {
sortOrdersBasedOnDateActivated(orders, sortParam);
}
return new NeedsPaging<Order>(orders, context);
}
return new EmptySearchResult();
}
private static void sortOrdersBasedOnDateActivated(List<Order> orders, String sortOrder) {
//sort in descending order
if (sortOrder.compareToIgnoreCase("DESC") == 0) {
Collections.sort(orders, new Comparator<Order>() {
@Override
public int compare(Order o1, Order o2) {
return o2.getDateStopped().compareTo(o1.getDateStopped());
}
});
}
//sort in ascending order
else {
Collections.sort(orders, new Comparator<Order>() {
@Override
public int compare(Order o1, Order o2) {
return o1.getDateStopped().compareTo(o2.getDateStopped());
}
});
}
}
This worked for pastOrders which thus bring me to my question of how sorting should really work here. If the user is searching for inactive orders then it makes sense to sort by the date such orders were deactivated and if searching by active orders then the date they were activated should be used. What do you think? cc @darius @dkayiwa @kodero @fred @flavia @betty @zeze @geofrocker @wyclif
@larrystone Greate I now see what i was missing to understand. guess compareWithNullAsEarliest() was not doing what i thought it should do. Happy to know it worked.
Thanks @larrystone!
@harisu, I saw you took yourself off the ticket (RESTWS-706)… are you planning on updating based on @larrystone’s advice?
If so, could you pick the ticket back up, and when you have a pull request ready to review, can you add a link to it as a comment on that ticket and flag me and I will review?
Thanks! Mark
Yeah i would love to reclaim it. didn’t have the intention of abandoning the ticket except for the fact that it was taking longer and seems to delay the entire sprint. @larrystone just raised a pertinent design point in his post i dont know if that will also be taken care of or just going with the normal description of the ticket and updating based on his advice will be ok.
@harisu I would recommend just picked the ticket back up and updating based on his advice and then issuing a pull request…
Ok polishing it up with his modifications while waiting for update on any adjustments
I would also suggest a cleaner logic to avoid code duplication.
private static void sortOrdersBasedOnDateActivated(List<Order> orders, String sortOrder) {
Collections.sort(orders, new Comparator<Order>() {
@Override
public int compare(Order o1, Order o2) {
return sortOrder.compareToIgnoreCase("DESC") == 0 ? o2.getDateStopped().compareTo(o1.getDateStopped()) : o1.getDateStopped().compareTo(o2.getDateStopped());
}
});
}
}
@harisu But you still havent responded to this
@larrystone For me i think It suffices and optimal to do it that way . As such we make sure recents result are always on the top by default. ie decending order.
Awesome job
Did you mean to say sorting
instead of searching
?
cc @darius @dkayiwa @kodero @flavia @betty @zeze @geofrocker @wyclif
I actually meant searching or better still fetching. A typical url would look something like .../orders?sort=desc&status=inactive...
. The status parameter would help the backend decide the criteria for sorting (createdDate/stoppedDate for activeOrders/pastOrders respectively)
I think it’s fine, for consistency, to just sort on “dateActivated” for both active and inactive orders.
Take care, Mark
Your first sentence is not really clear. Seems there is a bit of typo.
For more context, could you paste the new endpoint.
I think We use sort based on status as you rightfully said but the url will remain thesame when no sort parameter is specified we default to decending order for either active or inactive orders.
FYI, I’ve been doing some testing and things are looking good! I’ve entered some tickets based on what I’ve seen. They are currently in the backlog but some of these I think we should take in the current sprint:
OEUI-116 Units for duration are duplicated
OEUI-124 “Sign and Save” and “Discard” confusing options when removing drug
OEUI-118 Widen drug prescription field boxes to accommodate available options
OEUI-117 Drop downs options should only be filtered by first letter
I also entered a ticket which would probably be good for an upcoming sprint:
OEUI-119 Remove dispensing requirement from Med prescribing
Feedback on these tickets is welcome!
Dave
Also:
OEUI-125 Inconsistent date format on Order Entry display page
OEUI-126 Switching between Inpatient and Outpatient tabs
Thanks! Dave
Thanks for your feedback and suggestions.
We would look into them together as a team and give feedback.
cc @darius @dkayiwa @kodero @flavia @betty @zeze @geofrocker @larrystone @wyclif