# O3: What should be the UX of a non-provider user?

**URL:** <https://talk.openmrs.org/t/o3-what-should-be-the-ux-of-a-non-provider-user/38049>\
**Category:** Development\
**Tags:** ux, developers-forum, design-forum, o3\
**Created:** [November 29, 2022, 11:02am UTC](https://talk.openmrs.org/t/o3-what-should-be-the-ux-of-a-non-provider-user/38049 "2022-11-29T11:02:23Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\
**Post date:** [November 29, 2022, 11:44pm UTC](https://talk.openmrs.org/t/o3-what-should-be-the-ux-of-a-non-provider-user/38049/10 "2022-11-29T23:44:09Z")

</div>

So, from a quick look at the code, I think the order basket is still kind of broken in key ways.

The error you’re reporting is because when a user opens the order basket we call a function called `getCurrentOrderBasketEncounter()`. If this function doesn’t find an encounter (more on that below), it attempts to create an encounter, but the [code to create an encounter](https://github.com/openmrs/openmrs-esm-patient-chart/blob/05a390c549974a98f20aba408b8fa0b33810e752/packages/esm-patient-medications-app/src/api/api.ts#L80) is setup in such a way that it can return a JSON document that has this fragment:

```json
"encounterProviders": [{
  "provider": null,
  "encounterRole": "<UUID from config>"
}]

```

This isn’t a valid `encounterProvider` entry, though the error message could be better. Ideally, if there’s no provider, we just skip the `encounterProviders` entry altogether (but more considerations further on).

It seems wrong for the app to try and create an encounter _when the user opens the workspace_. That should, ideally, happen once the user performs an action. In my mind, the ideal moment would be when someone goes to submit the order, but even delaying it until a user actually creates a draft order would be better than the current implementation. (Right now, if Dr. X clicks on the order basket icon, an encounter is created, even if nothing is done inside that encounter).

Now, when we create the encounter, its not associated with a visit. This also seems wrong… I think the idea was to have a single “Order Entry” encounter for each visit. If we’re going to model things that way, then there’s really no sensible encounter provider to associate with the “Order Entry” and we just shouldn’t be trying to provide one. This is because two different providers might both place orders for the same patient on the same visit, but with the current implementation, one of them will be marked as the encounter provider and the other will not, which means we’re creating bad data.

Finally, before we get into all of this, the `getCurrentOrderBasketEncounter()`. I’d expect it to look for an “Order Encounter” for the currently active visit and return that if it exists. Instead, it’s implementation looks like this:

```auto
export function getCurrentOrderBasketEncounter(patientUuid: string, abortController?: AbortController) {
  const [nowDateString] = new Date().toISOString().split('T');
  return openmrsFetch(`/ws/rest/v1/encounter?patient=${patientUuid}&fromdate=${nowDateString}&limit=1`, {
    signal: abortController?.signal,
  });
}

```

Which is asking for the backend for the first encounter it decides to return from the current day. There’s no guarantee what encounter this will be. It could be the “Order Entry” encounter we created or it could be… any other encounter that was entered for the patient. In other words, we will end up attaching orders created via the order basket to a basically random encounter the patient had.

From [the documentation](https://rest.openmrs.org/#list-encounters), I can see we can already support having the `encounterType`, at least, used to filter down this list and it should be pretty easy to add the filtering for the current visit to that too.

---

_[View the full topic](https://talk.openmrs.org/t/o3-what-should-be-the-ux-of-a-non-provider-user/38049)._