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 is setup in such a way that it can return a JSON document that has this fragment:
"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:
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, 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.
