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.