...

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

...

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 New M_HealthcareFacilityHierarchy Table

A new dedicated table is introduced to model healthcare relationships.

Purpose

• Represent clinical hierarchy:
  District Hospital → CHC → PHC → Subcenter

• Enable 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 mapStore or Main/Sub Store logic.

...

11.5 Hierarchy Coexistence Model

Both hierarchies exist in parallel, serving different purposes.

...

11.6 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: ✔️

• Lead communication readiness: ✔️