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