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?
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)
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 AdmissionLocation
s, and of Bed
s 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:
AdmissionLocationResource
).AdmissionLocationResource
).
Location
instance, it just says that an existing location has become an IPD ward.
BedResource
and possible other REST resources.)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
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:
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
Add a Ward(on clicking an empty block) or Edit a Ward(on clicking an existing Ward). Delete option will be provided on hover.
After creation of Ward(empty), admin will have 2 options: Either add a room or add beds directly.
Adding beds directly to a Ward:
a. Set bad layout(inside a ward/room) :
b. Add/edit Bed in the layout so set(Upon saving bed layout, it will auto-forward to Bed management page) :
Add a Room (upon clicking empty block)/ edit a Room(upon clicking existing room):
Add/edit a 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
insert into bed_type values(1, 'deluxe', 'deluxe bed', 'DLX');
)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);
)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.
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:
@sudipkoirala @mjsanish does that make sense, can we move forward with 2 & 3?
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?