Architecture Type: Three-tier (Controller → Service → Repository)
Multi-Tenant Isolation: providerServiceMapID scoping ensures data separation between providers and states
Session Management: Redis with JWT authentication
Soft Deletion Pattern: deleted flags used across entities for safe deletion
Current System ER Diagram: 
Primary User Entity: M_User1
| Attribute | Description |
|---|---|
| Basic profile | firstName, lastName, username, etc. |
| Designation | Single designation per user |
| Demographics & Languages | Linked via one-to-one relationships |
| Supervisor/Admin flags | Supports role-specific behavior |
User-Service-Role Mapping: M_UserServiceRoleMapping2
| Feature | Description |
|---|---|
| Multi-role support | Assign multiple roles to a single user |
| Facility assignment | Uses workingLocationID |
| Multi-village coverage | Stored as comma-separated villageidDb |
| Multi-tenant scope | Scoped by providerServiceMapID |
Provider Service Mapping: M_ProviderServiceMapping
Maps healthcare providers to states and services
Creates unique providerServiceMapID per provider-state-service
Supports geographic and service-line isolation
Geographic Hierarchy
State → District → Block → Village
Users assigned to blocks/villages via role mapping
Facilities linked to geographic addresses
Creation Hierarchy:
Provider Creation – Setup healthcare organization
Provider-Service-State Mapping – Define operational scope
User Creation – Basic profile in M_User1
Role Assignment – Map users to services and facilities
Step-by-Step Process:
| Step | Description |
|---|---|
| Step 1: Basic Profile | Personal details, credentials, designation. Endpoint: /m/AddEmployee |
| Step 2: Demographics & Address | Family info, present/permanent addresses, geographic mapping |
| Step 3: Language Capabilities | Multiple languages with read/write/speak proficiency |
| Step 4: Role & Service Assignments | Multi-role assignments, facility via workingLocationID, village coverage |
Entity: M_Facility
| Feature | Description |
|---|---|
| Hierarchy | Two levels: Main Store / Sub Store |
| Type | Inventory-focused via M_facilitytype |
| Location | Basic address info |
| Facility Type | Purpose | Parent Facility | Mapping |
|---|---|---|---|
| Main Store | Central inventory hub, MMU parking | None (mainFacilityID = null) | Parking place assignment |
| Sub Store | Distribution point, MMU unit | Points to Main Store | Van assignment |
UI Implications:
Radio buttons for Main vs Sub Store
Conditional dropdown for parent store (only Sub Store)
Mapping via /mapStore endpoint
Existing Main/Sub Store logic remains
New healthcare hierarchy: District Hospital → CHC → PHC → Subcenter
Both hierarchies coexist:
| Current Logic | Healthcare Logic |
|---|---|
| Main Store / Sub Store | DH → CHC → PHC → SC |
| Inventory focus | Healthcare service focus |
| MMU operations | Clinical service delivery |
storeType used for inventory logic
healthcareLevel used for healthcare logic
Note: Existing /mapStore logic unchanged
Multi-village assignments stored in villageidDb
Supports field workers (ASHA/ANM) covering multiple villages
Subcenter assignment via workingLocationID
Organized at block level
Flat role model: M_Role
Screen-level permissions: RoleScreenMapping
Multi-role assignments supported
Role updates/deletions supported
Optional CTI integration for call centers
7.1 MMU/Van Services:
Van-facility mapping: M_VanSpokeMapping
Van service point mapping: M_VanServicePointMap
Parking place & van master repositories unaffected
7.2 Inventory Management:
Main/Sub Store hierarchy maintained
Item-facility mapping (M_itemfacilitymapping) unchanged
Stock entry/allocation unaffected
7.3 User Management:
/m/AddEmployee and role assignments unchanged
ASHA worker village assignments preserved
7.4 Facility Types:
M_facilitytype remains
Store controller endpoints unchanged
7.5 File Upload Systems:
Facility upload (/saveFacility) continues
Existing file processing maintained
Note: Healthcare fields are additive and nullable; zero disruption to current system.
Central Junction Table: M_UserServiceRoleMapping2
| Column | Purpose |
|---|---|
userID | Links to M_User1 profile |
providerServiceMapID | Provider-Service-State mapping |
workingLocationID | Facility assignment |
roleID | User role |
blockID | Geographic block |
villageidDb | Comma-separated villages |
Connection Examples:
ASHA Worker “Sunita”: providerServiceMapID=123, workingLocationID=456, blockID=78, villages=101–105, roleID=5
MMU Driver “Ramesh”: parkingPlaceID=789, vanID=45, multiple districts, roleID=12
Data Flow Summary:
Hub-and-spoke model: Provider → State → District → Block → Villages
Supports static facility and mobile unit assignments
Scoped by providerServiceMapID for multi-tenancy
| Role Type | Context |
|---|---|
| Clinical (Doctor/Nurse) | Facilities via workingLocationID, multiple roles, screen access via RoleScreenMapping |
| Field (ASHA/ANM) | Subcenters, multi-village coverage (villageidDb) |
| Administrative (Supervisor) | Multiple service lines, optional CTI integration |
Key Features:
Flexible multi-role assignment
Geographic context for field roles
Service line isolation via providerServiceMapID
Screen-based access control
Note: Junction table pattern enables complex multi-role assignments; audit trails and soft deletion supported
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