Order Entry UI Sprint 4 Announcement

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

Order Entry UI Sprint 4 Wiki

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 :sweat_smile: 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…

1 Like

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.

1 Like

@larrystone

Awesome job :+1:

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.

1 Like

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