...

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: 




Image Added

...

2. Core Entity Relationships

...

• storeType used for inventory logic

• healthcareLevel used for healthcare logic

• Note: Existing /mapStore logic unchanged

...

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

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
  
  Image Added
  
  
  

...

11.2 Design Principle

Separation of Concerns

...

11.3 Enhanced M_Facility Entity (Additive Only)

The existing M_Facility table is extended, not modified.

Newly Added Nullable Fields

• stateID

• districtID

• blockID

• hfrID

• healthcareLevel (DH, CHC, PHC, SC)

Why This Works

• Existing records remain valid

• No migration risk

• Inventory logic continues using storeType

• Healthcare logic uses healthcareLevel

storeType and healthcareLevel operate independently

...

11.4 Hierarchy Coexistence Model

Both hierarchies exist in parallel, serving different purposes.

...

11.5 API Enhancements (Non-Breaking)

Extended / New APIs

• /createStore – accepts optional healthcare fields

• /editStore – updates healthcare attributes

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