View Source

1. Architecture Overview

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: (Attach diagram image here)

2. Core Entity Relationships

2.1 User Management Structure

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`

2.2 Multi-Tenant Provider Structure

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

3. User Creation and Management Flow

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

4. Facility Management

4.1 Facility Structure

Entity: M_Facility

Feature	Description
Hierarchy	Two levels: Main Store / Sub Store
Type	Inventory-focused via `M_facilitytype`
Location	Basic address info

4.2 Main/Sub Store Logic

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

4.3 Healthcare Facility Hierarchy Integration

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

5. Geographic & Village Management

Multi-village assignments stored in villageidDb
Supports field workers (ASHA/ANM) covering multiple villages
Subcenter assignment via workingLocationID
Organized at block level

6. Role and Permission System

Flat role model: M_Role
Screen-level permissions: RoleScreenMapping
Multi-role assignments supported
Role updates/deletions supported
Optional CTI integration for call centers

7. Services and UI Components NOT Affected

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.

8. User & Entity Mapping Architecture

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

9. Multi-Role Assignment Architecture

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

10. Summary

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