...
The PSMRI/Admin-API provides: Comprehensive user and role management Geographic and service-line isolation Support for multi-village field workers and MMU operations Scalable three-tier architecture with audit trails Additive healthcare facility hierarchy without affecting existing systems
11. Proposed New Implementation – Healthcare Facility Hierarchy (To-Be)
...
11.1 Purpose of the New Implementation
The existing facility model is optimized for inventory and MMU operations using a Main Store / Sub Store structure.
However, healthcare delivery requires a clinical hierarchy aligned with public health systems.
This new implementation introduces a healthcare-focused hierarchy to support:
Referral pathways
Clinical reporting
ABDM (HFR) compliance
State-level healthcare structuring
...
...
...
11.2 Design Principle
Separation of Concerns
| Aspect | Current System | New Implementation |
|---|---|---|
| Hierarchy Type | Inventory hierarchy | Healthcare hierarchy |
| Primary Goal | Stock & MMU management | Clinical & service delivery |
| Impact on Existing Logic | — | ❌ No impact |
| Data Model | M_Facility (store-based) | New hierarchy layer |
| Backward Compatibility | — | ✅ Fully preserved |
...
11.3 Enhanced M_Facility Entity (Additive Only)
The existing M_Facility table is extended, not modified.
Newly Added Nullable Fields
stateIDdistrictIDblockIDhfrIDhealthcareLevel(DH, CHC, PHC, SC)
Why This Works
Existing records remain valid
No migration risk
Inventory logic continues using
storeTypeHealthcare logic uses
healthcareLevel
storeTypeandhealthcareLeveloperate independently
...
11.4
...
A new dedicated table is introduced to model healthcare relationships.
Purpose
Represent clinical hierarchy:
District Hospital → CHC → PHC → SubcenterEnable structured referrals and reporting
Keep healthcare logic separate from store logic
Key Characteristics
Self-referencing parent–child relationship
Healthcare-level validation rules
HFR ID mapping for ABDM
Audit fields and soft deletion
This table does not replace
mapStoreor Main/Sub Store logic.
...
Hierarchy Coexistence Model
Both hierarchies exist in parallel, serving different purposes.
| Inventory Logic (Existing) | Healthcare Logic (New) |
|---|---|
| Main Store | District Hospital (DH) |
| Sub Store | CHC / PHC / SC |
| Van & MMU focus | Referral & care delivery |
| Stock flow | Patient/service flow |
...
11.
...
5 API Enhancements (Non-Breaking)
Extended / New APIs
/createStore– accepts optional healthcare fields/editStore– updates healthcare attributes
...
/getFacilityHierarchy – returns healthcare tree
...
/validateFacilityHierarchy – validates DH→CHC→PHC→SC rules
Important Note
Existing API consumers do not need changes
Healthcare parameters are optional
Current flows remain intact
...
11.7 UI Enhancements (Proposed)
Facility Creation Screen
Current UI
Radio buttons: Main Store / Sub Store
New UI (Additive)
Dropdown: Facility Type
District Hospital (DH)
CHC / Block
PHC / UPHC
Subcenter (SC)
Inventory UI behavior remains unchanged.
...
11.8 What Is NOT Changing (Reconfirmed)
The following remain 100% untouched:
Main/Sub Store mapping
MMU, Van, and parking logic
Inventory & stock management
User creation and role assignment
Village coverage logic
File upload and bulk import processes
...
11.9 Call Explanation – How to Explain This to the Lead
Use this exact narrative 👇
“Today, our system has a store-based hierarchy mainly for inventory and MMU operations.
The new proposal introduces a separate healthcare hierarchy to model DH, CHC, PHC, and Subcenters.
We are not changing any existing logic. Instead, we add healthcare-specific fields and a new hierarchy table.
This allows both inventory and healthcare workflows to coexist without risk.”
11.10 Final Summary
✅ Current system remains stable
✅ New healthcare hierarchy is additive
✅ No breaking changes
✅ Clear separation of inventory vs healthcare concerns
✅ Future-ready for ABDM and referrals
✅ You did this correctly
...
Architecture thinking: ✔️
...
Backward compatibility: ✔️
...
Documentation clarity: ✔️
...