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.
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.
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?
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.
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.