is there any module that can manage Bed in hospital instead of adding script simple UI

In think @mjsanish is assuming a 3-level system:

Bed ⊂ Room ⊂ Ward (Location)

Hence the reason why you would only be offered to add rooms to a ward (and then beds to a room), do you think it is overkill?

Well, the hierarchy is not exactly true, as wards often can have only beds. In bigger hospitals, yes a ward can have rooms as well (depends on how hospitals organize)

  • if its just for reporting purpose then both ward and rooms can be under a “department” location.
  • Also you will need a drill down inside the rooms within the ward if rooms are within a ward only.

I think visually as well, it will help to have only 2 levels, unless we build a drill down feature from the “bed-management” assignment. I would suggest keeping this simple and compatible with existing Bahmni and then building the nested hierarchy.

Ok @mjsanish this obviously has implications to the work you were doing.

I think you need to rewind and look at the existing. The key ‘location’ class that currently exists is AdmissionLocation, and according to what Angshu just said that’s enough. That’s the ward, so a location that contains beds.
For the sake of this post you can assume that admission location = ward (even though in fact from the data model an admission location is a ward + beds information.)

There also exists an AdmissionLocationResource, so from a REST standpoint everything was already organised in accordance to this model.

The new UI must enable the management of AdmissionLocations, and of Beds within those bed-containing locations. Starting from there you need to wonder what changes must be made to the current REST interface (all the *Resource classes) to enable everything that is being UX designed.


Let’s pedal back to the analysis phase and do things in order:

  • What would the UI look like.
    • It should list existing admission locations (using AdmissionLocationResource).
    • It should enable addition/edition/deletion of admission locations (using AdmissionLocationResource).
      • Creating an admission is essentially about selecting the location that becomes an admission location. So it does not create a Location instance, it just says that an existing location has become an IPD ward.
        Interestingly you can see that it is not possible to persist anything related to this resource (see here and here).
    • Clicking on an admission location should brings the user to its inside, so the beds layout. That’s the visual layout that @darius mentioned above in its post (using BedResource and possible other REST resources.)
    • It should allow addition/edition/deletion of beds.
      • I would imagine that occupied beds could not be deleted. So certain rules will apply.
  • Based on what the UI experience should be, start extending the REST API to allow this.
  • Provide unit tests validating the REST API.
  • Implement the REST API accordingly and start anticipating what changes may bed needed to the Java API.
  • Provide unit tests validating the Java API, if any.
  • Implement the Java API accordingly.

The above describes one cycle of an iterative process. The list of steps will be revisited multiple times until the desired outcome is obtained.

@mksd & @angshuonline Ward can have many room and room can have many beds. So I am planning to build in 3-level. First, add ward and add rooms inside ward and add beds to the ward’s rooms.

I think the simple design would be better for bed management UI with listing and add forms.

@mksd We cannot use AdmissionLocationResource for addition/edition/deletion/listing of wards since it is dependent on BedLocationMapping. So I have created WardResource for it.

@mjsanish, maybe I was not clear enough

  1. Ward can have beds without rooms
  2. Wards can have rooms and rooms can have beds. (this is currently not there, new feature)

There are many hospitals (especially in rural), where they don’t have rooms within a ward. like a General ward, Paediatrics ward etc. They are grouped under “General Medicine” or “Paediatrics” locations, tagged as “departments”. Sometimes, they do want further classification like “general ward male”, “general ward female” etc. But they just create a new ward with the right name.

In city hospitals, its common to see rooms within wards, in addition to a “dorm” like ward. So for this, you may have the 3rd level hierarchy. Although, in the implementations we have made in the past, we just named it “Room 1” and put them under “Paediatrics” location, tagged as a “department”.

We must support 1 in any case. If you are forcing the 3 levels, then it will break or force many to change they operate and also in migration.

Here I am pasting pre-existing implementation (not written by me). Maybe it will clear.

@Override
public List<AdmissionLocation> getAdmissionLocationsByLocationTagName(String locationTagName) {
    Session session = sessionFactory.getCurrentSession();

    List<Location> physicalLocations = getPhysicalLocationsByLocationTag(locationTagName, session);

    String hql = "select  blm.location.parentLocation as ward ,count(blm.bed) as totalBeds ," +
            " sum(CASE WHEN blm.bed.status = :occupied THEN 1 ELSE 0 END) as occupiedBeds" +
            " from BedLocationMapping blm where blm.location in (:physicalLocationList) " +
            " group by blm.location.parentLocation";

    List<AdmissionLocation> admissionLocations = session.createQuery(hql)
            .setParameterList("physicalLocationList", physicalLocations)
            .setParameter("occupied", BedStatus.OCCUPIED.toString())
            .setResultTransformer(Transformers.aliasToBean(AdmissionLocation.class))
            .list();

    return admissionLocations;
}

private List<Location> getPhysicalLocationsByLocationTag(String locationTagName, Session session) {
    return session.createQuery("select ward.childLocations from Location ward where exists (from ward.tags tag where tag.name = :locationTag)")
            .setParameter("locationTag", locationTagName).list();
}

@mjsanish what I am suggesting is this:

  1. An admission location is a location that can contain beds.
  2. Any location can be set to be an admission location.

The consequence of the latter is that any system of nested admission locations can be imagined. In particular your 3-level system.

Can you explain in more details what exactly prevents 1 and/or 2? If you want to point me to a place in the code, please point me to an exact line or set of lines on GitHub (using a permalink for further reference).

I am afraid, I don’t get it from the code above.

Can you please explain how you will satisfy the 2 requirements I posted above, without breaking an existing implementation during upgrade (v0.89 or lesser or for upcoming 0.90)?

Above REST API to get all admission location (Wards) which is used to list wards at Bahmni app at InPatient.

Here getPhysicalLocationsByLocationTag(String locationTagName, Session session) return locations’s (ie ward) childlocation (ie rooms) that have location_tag.name=“Admission Location”

Here in getAdmissionLocationsBy(String locationTagName) query select ward (ie room’s paentlocation) form bed_location_mapping that have location with rooms (return form getPhysicalLocationsByLocationTag(String locationTagName, Session session))

So ward can not have beds with out room.

I am not forcing to add rooms (3 levels), It not new feature. I have just name as ward’s child location as room and room’s parent location as ward.

We have not worried about it will breaks or force many to changes.

This must be supported. The use cases are also for “wards with just beds”.

Well, I am not sure if thats acceptable. It must work for someone who upgrades.

I have not touched previous existing REST API. I have worked only on add/edit/delete REST API for admin functionalities. So will work for someone who upgrades.

Ok. Can you also bring the solution(s) up for discussion in the next PAT call?

Also this bit on the product feature analysis might help.

Uploading the new UI mockups as proposed by @mjsanish

  1. Ward Management

01 ward management

  1. Add a Ward(on clicking an empty block) or Edit a Ward(on clicking an existing Ward). Delete option will be provided on hover. 02 add-edit ward

  2. After creation of Ward(empty), admin will have 2 options: Either add a room or add beds directly. 03 empty ward4

  3. Adding beds directly to a Ward:

a. Set bad layout(inside a ward/room) :

04 set layout

b. Add/edit Bed in the layout so set(Upon saving bed layout, it will auto-forward to Bed management page) :

05 add bed

  1. If admin opts for setting a 3-layer hierarchy(Ward->Room->Beds) in Step 3(above), i.e. Add a Room:

06 manage room

  1. Add a Room (upon clicking empty block)/ edit a Room(upon clicking existing room): 08 add-edit room - Copy

  2. Add/edit a Bed:

05 add bed

07 add-edit bed

We shall explain the mockups in today’s PAT call. (Note: Updated with description and proper ordering of wireframes on 2nd Nov 2017.)

Based on what we discussed in the call, if we are going to anyways build incrementally, so to begin with why not just build the UI to do the things for which no UI exists as of now and user has to use SQL?

Referring this sample bed management SQL on this page.

So we let the users define wards or whatever they want to call them (like the SQL allows) through the existing openmrs UI for defining locations. We document that 2 level of locations have to be defined tagged with ‘Admission Location’

In the new admin UI we are building as of now, we only provide the following abilities

  1. ability to add/update/delete bed types (Basically a UI for something like this insert into bed_type values(1, 'deluxe', 'deluxe bed', 'DLX'); )
  2. ability to add/update/delete beds (Basically a UI for something like this insert into bed (bed_id, bed_number, status, bed_type_id, uuid, creator, date_created, voided) values(1, '304-a', 'AVAILABLE', 1, UUID(), 1, NOW(), false); )
  3. ability to assign bed to one of the locations tagged Admission Location at a specific row/column. (Basically a UI for something like this insert into bed_location_map(bed_location_map_id, location_id, row_number, column_number, bed_id) values(1, @location_id, 1, 1, 1); )

I think the screen for 2 and 3 could be same as same bed cannot be assigned to multiple locations/wards. The bed screen can have the dropdown for location and position (row and column). So may be we are just looking at just 2 new screens - Bed type and Bed, and additionally ability to search bed type or bed to update/delete(retire).

Thanks @arjun for this additional input.

There will be a new place to manage admission locations specifically.

The data model doesn’t impose any limitations here, any location can become an admission location. On the principle that’s very convenient because it allows to define any possible structure.
So do we want to impose any limitations? If yes, could you clarify why?

Wouldn’t the existing openmrs admin UI for managing location suffice for what we need? I am imagining creating new location and tagging it with ‘Admission Location’.

Oh ok, i had done bed management setup a while ago and vaguely remember that it needed two locations (parent and child) and wasn’t working without that. Even the sample SQL on the Bahmni wiki shows that. So i assumed it’s needed. I haven’t looked at the code personally, but if its verified and we are confident that there is no such requirement by data model then that’s all the better. In that case, my comment about 2 levels can be ignored.

Thanks @arjun.

Point 1. Yes correct, but we thought this would be a chance to start developing an admin UI using non-legacy technology.

Point 2. We will go in the direction of allowing to tag any location as admission location, and we will see if this breaks anything on the clinical side.

  1. If not, we keep it like that.
  2. If yes, we will introduce a validation layer that ensures that what’s done on the admin side complies with what the clinical side can handle.

Cc @pramidat @mjsanish @sudipkoirala

Thanks to @pramidat and @santhubairam for presenting the custom IPD features that they have developed for one of their implementation sites.

They use the same version of the Bed Management module, nothing specific has been done on the back-end side. So the bottom line is that changes in the module should not break anything on the vanilla Bahmni IPD app or on their custom IPD app.

Both the vanilla IPD app and their custom IPD app need to know which one is the first layer of admission locations. When this first layer is known, then the whole UI assumes that there is a two-layer system to display.
Otherwise fundamentally there is no limitation as to how many nested layers of admission locations can be. From the admin screens standpoint this is not relevant. It is just that the IPD apps will only handle a two-layer setup, and hence should know where to start. I will create a ticket for this.

In its barest form BAH-313 should bring admin screens that:

  1. Allow to tag/untag locations as ‘admission locations’.
    DONE This can be done through the existing ‘Manage Locations’ admin screen.
  2. Allow to navigate the admission locations only to manage their content (beds basically).
    This needs to be done.
  3. Once inside an admission location: allow to add/edit/delete bed for a given admission location.
    This needs to be done.

@sudipkoirala @mjsanish does that make sense, can we move forward with 2 & 3?

Cc @angshuonline @darius

Based on our understanding, we have prepared an explanation of our mockups:

This supports both single layered hierarchy for adding beds or multiple layered.

Can we finalize with for further development?

@mksd @darius @angshuonline @pramidat @sudipkoirala