Enhancing Clinical Module to include Consultation button on the patient dashboard, irrespective to visit type mapped to login location.

Hi @all,

Current functionality of Bahmni does not show the Consultation button on the patient dashboard of the Clinical module for the patient whose login location is different from the location where his visit started.

The requirement is that the patient shall be visible in the patient queue, according to the selection of his visit type during registration, and he shall be able to see the “Consultation” button in the patient dashboard of the Clinical module.

The patient is visible in the patient queue of the Clinical module according to the selected visit type. But the “Consultation” button is not visible on the Patient Dashboard.

As per Bahmni Standard flow we are Registering and starting patient visit through location “Registration Desk” and with the same login if we capture the clinical details, then it works fine.

But when we are registering and starting the patient visit through location “Registration Desk”, and then login with another Location suppose “OPD”, the patient is not listing out in Clinical module patient search queue.

Please refer to this flow for clarity:

  • Login with the location Registration Desk and register the patient from the Registration Module.
  • Select the visit type as “OPD Visit” and start the visit.
  • The patient is visible in the patient queue of the location “Registration Desk” in the Clinical module.
  • Select the patient, the patient dashboard opens and in the dashboard a “Consultation” button is present.
  • Logout from the location Registration Desk.
  • Login with the location OPD.
  • The patient is visible in the patient queue of the location OPD in Clinical Module.
  • Select the patient, the patient dashboard opens.
  • In the patient dashboard, the “Consultation” button is missing.

Moved to the bahmni category.

@prashantsable1991 the usecase you describe is how it works at most places. if you have the login locations (e.g. Registration, OPD) mapped to a common parent (e.g. Hospital) tagged as visit location, this should work just fine.

Yes to what Arjun said. I also have a feeling that you have gotten your location hierarchy and location tags wrong.

Check the following example

@arjun and @angshuonline We tried the above-suggested solution but it is not working in our scenario.
Currently, we have the following location hierarchy:

Hi, I think the hierarchy is messed up and as a result the existing data might be reflecting wrong or working towards wrong detection of visit & encounter location.

Generally speaking:

  • Have only 1 root (Visit Location) in a hierarchy, model it just like the hospital is.
    • Under the root location, you can have multiple “login locations”. Encounters are associated with “login locations”.
    • for example: If in your example, “LOCATION_CARDIOLOGY”, “LOCATION_DELIVERY” are under the same hospital, then simplify by bringing them under one “Visit Location” (the hospital), and remove tag “Visit Location” from these individual locations. If you want Providers to login to such locaiton, keep them as “Login Location”.
  • Bahmni allows multiple “Visits” to be open in different visit locations
    • unless absolutely required, don’t create “Visit Locations” under “Visit Locations”. so unless you want department wise visit requirements (e.g. If a patient visits the hospital in Cardio or Dentistry departments, are they considered 2 different visits or a single visit, with 2 different encounters at different locations?)
    • you can have 2 different visit locations if they are setup as different. Mimic how the hospital views the structure. Remember the visit will get attached to the location, which is in the hierarchy of the login location.

(Setting up the location hierarchy is one of the first steps you should have take)

Also check the “Visit Location” documentation on WIKI

Sorry for bumping up old thread.

If I am about to create new visit type(so that it’ll show up at visit option in registration module), and new location (so that it’ll show up as login location), where’s that two tied each other? e.g the admin staff login with location registration desk, and from registration module sent the patient one to visit type one, and patient two to visit type two. The two different doctor will then login with two different location, where they should only see patient queue based on their login location that will map to visit type that the registration staff sent the patient to.

I saw theres location map with encounter type in the location_encouter_type_map table. I also saw in the openmrs advance settings theres option visits.encounterTypeToVisitTypeMapping. But theres no option to map visit type to location.

There’s another table called entity_mapping_type that has entry of loginlocation_visittype, but based on this page, it’s for make visit type option in registration module default based on login location.

1 Like

It seems this issue still persists. Registration clerk have to go back to home screen every time to change location then register patients just to put the client in the correct queue. About 200 patient always in same queue so we have to split them somehow in our case.

Currently, we split it by pediatric, adult, cardio, gyno, echo. If someone can map the start visit button to correct location …