...
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)
...
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 rulesImportant Note
Existing API consumers do not need changes
Healthcare parameters are optional
Current flows remain intact
...