HWC - Removing Van Chain & Implementing Facility Hierarchy

1. EXISTING SYSTEM - How It Works Today

Admin Setup (One-time, for each HWC)

To set up one HWC like "Gunjalli HWC", admin must go through 6 pages in sequence:

...

Problem: HWC is a fixed building, not a moving vehicle. But the system forces admin to create fake Zone, Parking Place, and Van just to make login and worklist work. This creates unnecessary complexity and 7 database records across 6 tables for one HWC.

...

User Login (Every time a user opens the app)

When Dr. Ravi opens HWC app:

...

3 API calls, 7+ table reads just to log in.

...

Daily Patient Flow

1. Search Patient - Nurse searches "Lakshmi" by name/phone. System finds benRegID=50001. (No vanID used here)

2. Submit to Nurse - System writes a record in i_ben_flow_outreach table with vanID=5 and parkingPlaceID=3 (from session). This is how system knows "this patient is at this HWC."

3. Nurse Worklist - Query runs: WHERE vanID = 5 AND nurseFlag = 1. Shows "Lakshmi" waiting for nurse. There are 16 such queries in the codebase for nurse, doctor, lab, pharmacist, radiologist, TC specialist worklists.

4. Nurse completes → Doctor worklist → Doctor completes → Lab → Pharmacist - Same pattern. Every worklist query filters by vanID. Every visit record stores vanID and parkingPlaceID.

vanID is being used as a location identifier, not as a vehicle identifier.

...

2. NEW SYSTEM - How It Will Work After Facility Hierarchy

Admin Setup (One-time, for each HWC)

To set up "Gunjalli HWC", admin goes through 2 pages only:

...

2 pages, 2 tables. Location info is already inside the facility record.

...

User Login (Every time a user opens the app)

When Dr. Ravi opens HWC app:

...

For old users like Dr. Ravi who were already mapped to a Van: The new API has a fallback. It reads m_uservanmapping → m_van → FacilityID. So Dr. Ravi logs in without any admin re-mapping.

...

Daily Patient Flow

1. Search Patient - Same as before, no change.

2. Submit to Nurse - System writes facilityID=4 in i_ben_flow_outreach instead of vanID. vanID and parkingPlaceID will be NULL for new records.

3. Nurse Worklist - Query runs: WHERE facilityID = 4 AND nurseFlag = 1. Same 16 queries, just vanID replaced with facilityID. Same result for the nurse - no visible difference.

4. Rest of the flow - Same as before. Doctor, Lab, Pharmacist all see their worklists filtered by facilityID instead of vanID. Patient data (vitals, diagnosis, prescription) is saved exactly the same way.

Nurse and Doctor experience does not change at all. Only the internal identifier changes from vanID to facilityID.

...

3. IMPACT ON OTHER SERVICE LINES

Each service line has its own API codebase, its own repository, and its own deployment. They share the same database but do not share code.

...

Key point: We are NOT deleting any Van tables (m_van, m_parkingplace, m_zone, m_uservanmapping, m_userparkingplacemap). All these tables stay in the database. MMU and TM continue reading them. We are only stopping HWC from using them.

...

4. DATABASE CHANGES

What we ADD (before deploying new code)

Change 1: Add facilityID column to worklist table

...

For new users, admin maps them directly to a facility. Old users still work through the existing Van mapping tables (fallback).

What we DO NOT change

• m_van - NOT deleted, NOT modified (MMU/TM reads it)
• m_parkingplace - NOT deleted, NOT modified
• m_parkingplacesubdistrictmap - NOT deleted, NOT modified
• m_userparkingplacemap - NOT deleted, NOT modified (old user fallback)
• m_uservanmapping - NOT deleted, NOT modified (old user fallback)
• m_zone - NOT deleted, NOT modified
• m_itemfacilitymapping - NOT changed (already uses facilityID)
• t_itemstockentry - NOT changed (already uses facilityID)

Zero tables deleted. Zero columns deleted. Only 1 column added, 1 table created.

Pre-deployment verification

-- Must return 0 rows. If any Van has NULL FacilityID, fix it first.
SELECT VanID, VanName FROM db_iemr.m_van
WHERE FacilityID IS NULL AND Deleted = false;

Post-deployment verification

-- Must return 0. All old records should have facilityID filled.
SELECT COUNT(*) FROM db_iemr.i_ben_flow_outreach
WHERE facilityID IS NULL AND vanID IS NOT NULL;

Rollback

If anything goes wrong after deployment:

...

          Fully reversible with zero data loss

TWO OPTIONS FOR INVENTORY MAP

Option A: Remove Van Chain from HWC (Full Change)

What: Stop using vanID in HWC completely. Login, worklist, visit save - everything uses facilityID directly.

Work involved:

• DB: Add facilityID column to i_ben_flow_outreach, backfill old records, new table m_userfacilitymapping
• HWC-API: ~25 files (new login API, 16 worklist queries, visit save, entity change)
• HWC-UI: ~25 files (login flow, session, worklist calls, visit save)
• Inventory-API: ~3 files (hierarchy walk)
• Total: ~57 files

Benefit:

• Admin setup goes from 6 pages to 2 pages
• No more fake Van, Zone, Parking Place for HWC
• Clean architecture - HWC uses facility directly
• Login: 2 API calls instead of 3
• Hierarchy built-in (DH→CHC→PHC→SC)

Risk:

• Old data needs backfill
• Old user login needs fallback logic

...

Option B: Keep Van, Use Existing FacilityID for Hierarchy (Minimal Change)

What: Van flow stays exactly as it is. Login still uses vanID, worklist still filters by vanID, visit save still stores vanID. BUT - every Van already has FacilityID in m_van table. And m_facility now has ParentFacilityID (hierarchy is already done). So hierarchy is already connected through the existing link:

Van (VanID=5) → m_van.FacilityID=4 → m_facility (FacilityID=4, ParentFacilityID=3)
                                        → Kavital PHC (3, Parent=2)
                                          → Manvi CHC (2, Parent=1)
                                            → Raichur DH (1)

The chain already exists. No need to change login, worklist, or visit save.

Work involved:

• DB: ZERO changes to i_ben_flow_outreach (no new column, no backfill)
• HWC-API: ZERO changes to login, worklist, visit save
• HWC-UI: ZERO changes to login, worklist, visit save
• Inventory-API: ~3 files (hierarchy walk using Van → FacilityID → ParentFacilityID)
• Total: ~3-5 files only

Benefit:

• Almost no code changes
• No risk to existing flow - everything stays as is
• No old data migration needed
• Hierarchy is available whenever needed through Van → FacilityID → m_facility
• Inventory hierarchy walk works (Van → FacilityID → walk up parents)
• Can be done very quickly

Limitation:

• Admin still needs 6 pages to set up a new HWC (fake Van, Zone, Parking Place still required)
• vanID is still the main identifier everywhere in HWC code
• For every new HWC facility in hierarchy, admin must still create a corresponding Van

...

Side by Side

...