EmrApiVisitAssignmentHandler should check for null visitId

Hello people,

While debugging the EMRApiVisitAssignmentHandler we found out that the method beforeEncounterCreate will sometime returns from the first check assuming a visit is already associated with the encounter.

Below piece of code, line 83:

 if (encounter.getVisit() != null)
    return;

should be changed to something like below

if (encounter.getVisit() != null && encounter.getVisit().getVisitId() == null) {
   return;
}

Something similar done in encounterSevice line 230.

Reason for this is, when we POST a JSON, the encounter.visit is populated to an object which is not yet saved. So encounter.getVisit is not null but encounter.getVisit().getVisitId() will be null.

Let us know your thoughts. We will raise a quick PR.

CC: @mksd @dkayiwa @mogoodrich @rrameshbtech @premnisha

Thanks for tracking this down @mddubey.

Please open a ticket in the EA project and open a PR.

2 Likes

Thanks @mksd

Created an issue here:

PR for the same is here:

1 Like

Maybe I’m confused, but this seems wrong… if a visit is passed in with an encounter in a POST we want persist that visit and keep it associated with the encounter, not drop it and assign another visit to it, correct?

@mogoodrich,

Thanks for the reply. The idea We had in mind, when we post an encounter in OpenMRS with encounterLocation and encounterDatetime it automatically figures out if there is already a visit with the same location and the same start/stop datetime. While debugging we found out this is the piece which is forcing to create the new visit always.

We will put our use case as well in the post. We have a system from where we are migrating to OpenMRS. All the data we have created as individual encounter json payload including visit information(StartDate, StopDate, Location and Type). We want to not have one visit per encounter in case multiple encounters were done on the same day. We thought the API will associate with an existing visit if it finds a matching Visit with same StartData, StopDate, Type and Location.

Let us know if that is not the case and if there is another possible way to achieve the same.

When doing a comparison, the visit assignment handler will not look at the start date and stop date of any existing visit… it only looks at the encounter location and encounter datetime.

If you provide a visit as part of the encounter json POST, it should just use that visit (creating it if necessary)… it shouldn’t override it behind the scenes.

For your use case, if you don’t need any of the information created in the visit, you could just strip the visit out of the encounter post and have Encounter Visit Assignment handler set to create a visit if necessary.

If you need some of the information in the visit, you could parse all the visit information first, deduplicate, create the visits, and then create the encounters.

Alternatively, I believe you could just create a custom EncounterVisitHandler that handles your specific use case for your implementation… I forget exactly how you wire that in, but I’m hoping it would be straightforward.

fyi @mksd

Take care, Mark

@mogoodrich

Thanks for the detailed reply. I just checked and looks like the custom EncounterVisitHandler is configured using a global_property called visits.assignmentHandler. We will look into that.

Right, that GP sounds like the right place to check!

Thanks @mogoodrich. I will close this PR, since it is not applicable.