# Bug when saving Encounter without a Visit

**URL:** <https://talk.openmrs.org/t/bug-when-saving-encounter-without-a-visit/16643>\
**Category:** Development\
**Created:** [March 8, 2018, 11:02am UTC](https://talk.openmrs.org/t/bug-when-saving-encounter-without-a-visit/16643 "2018-03-08T11:02:37Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![achachiez](https://talk.openmrs.org/user_avatar/talk.openmrs.org/achachiez/32/2049_2.png) [@achachiez](https://talk.openmrs.org/u/achachiez)\
**Post date:** [March 8, 2018, 11:02am UTC](https://talk.openmrs.org/t/bug-when-saving-encounter-without-a-visit/16643/1 "2018-03-08T11:02:37Z")

</div>

**Application Name:** Platform

**Version Number:** 2.1.2

We are already using openmrs 2.1.2 at ampath we have discovered a bug that causes encounters filled without a visit being assigned the last visit for the particular patient. If you look at [https://github.com/openmrs/openmrs-core/blob/2.1.x/api/src/main/java/org/openmrs/api/handler/ExistingVisitAssignmentHandler.java#L69-L84](https://github.com/openmrs/openmrs-core/blob/2.1.x/api/src/main/java/org/openmrs/api/handler/ExistingVisitAssignmentHandler.java#L69-L84) It does not seem to be handling cases where visit.getStopDatetime() is null. The fix I used is to skip the loop when visit.getStopDatetime() is null.

---

<div class="post-metadata">

**Author:** ![darius](https://talk.openmrs.org/user_avatar/talk.openmrs.org/darius/32/8082_2.png) [@darius](https://talk.openmrs.org/u/darius)\
**Post date:** [March 8, 2018, 8:35pm UTC](https://talk.openmrs.org/t/bug-when-saving-encounter-without-a-visit/16643/2 "2018-03-08T20:35:56Z")

</div>

@achachiez when visit.stopDatetime is null that means that the visit is still open, so it is _intended_ behavior that the handler will assign an encounter to this visit.

Or maybe I’m not understanding you right?

Perhaps you can write a failing unit test to demonstrate the bug in the core code?

---

<div class="post-metadata">

**Author:** ![achachiez](https://talk.openmrs.org/user_avatar/talk.openmrs.org/achachiez/32/2049_2.png) [@achachiez](https://talk.openmrs.org/u/achachiez)\
**Post date:** [March 9, 2018, 5:27am UTC](https://talk.openmrs.org/t/bug-when-saving-encounter-without-a-visit/16643/3 "2018-03-09T05:27:11Z")

</div>

@darius You are correct the issue is our users almost never end visits. This means an encounter may be assigned a historical visit that should have been ended.

---

<div class="post-metadata">

**Author:** ![darius](https://talk.openmrs.org/user_avatar/talk.openmrs.org/darius/32/8082_2.png) [@darius](https://talk.openmrs.org/u/darius)\
**Post date:** [March 9, 2018, 5:40am UTC](https://talk.openmrs.org/t/bug-when-saving-encounter-without-a-visit/16643/4 "2018-03-09T05:40:27Z")

</div>

@achachiez, that’s somewhat of a misuse of the data model to leave visits open. Especially if the next visit starts without ending the previous one, you’ll end up in a state that many modules (and maybe eventually openmrs-core) would consider invalid.

What we did in PIH’s Mirebalais project is to have a scheduled task that automatically closes state visit if they haven’t had any activity for a configurable amount of time (and it isn’t an inpatient visit).

These are included in the EMR API module. See [the scheduled task](https://github.com/openmrs/openmrs-module-emrapi/blob/1.23.0/api/src/main/java/org/openmrs/module/emrapi/adt/CloseStaleVisitsTask.java) and the [underlying business logic](https://github.com/openmrs/openmrs-module-emrapi/blob/1.23.0/api/src/main/java/org/openmrs/module/emrapi/adt/AdtServiceImpl.java#L124).

I would recommend taking a similar approach.

If that’s not feasible you can also turn off the visit assignment handler.

---

<div class="post-metadata">

**Author:** ![achachiez](https://talk.openmrs.org/user_avatar/talk.openmrs.org/achachiez/32/2049_2.png) [@achachiez](https://talk.openmrs.org/u/achachiez)\
**Post date:** [March 9, 2018, 5:48am UTC](https://talk.openmrs.org/t/bug-when-saving-encounter-without-a-visit/16643/5 "2018-03-09T05:48:30Z")

</div>

Thanks @darius I think the scheduled task is a better option. It should be feasible to do that. Thanks again.