TB VAN Setup & Sync

1. Current Gap 

Laptops issued but not configured. No VAN ID assigned. No beneficiary data available locally. Field tracking cannot begin. 

2.  What We Need 

Each laptop configured with its correct VAN ID, then synced with the central DB so local records are ready for offline field use. 

End-to-End Flow:

3. Planning Steps:

Phase 1 - Define VAN Structure

• Decide total no. of VANs and names 

• List all field locations and corresponding logins 

• Get the Beneficiary count per tab login 

• Finalize the Location -> Login -> VAN allocation 

Phase 2 - Central DB Setup 

• Create all VAN records in the central 

• Map each tab login to its VAN ID 

• Verify all the logins are mapped to a VAN 

Phase 3 - Beneficiary Allocation 

• Beneficiary record - look at “CreatedBy” - assign the ben to that VAN of CreatedBy login’s VAN mapping 

• Verify - VAN ID | Beneficiary Count  

Phase 4 - Laptop Configuration & Down-sync 

• In each local laptop - configured the VAN  

• Trigger the down-sync process from the application of local laptop 

• Down-sync pulls all beneficiary records for the laptop's VAN 

• Verify the count on laptop 

4. Tables Involved in VAN Setup and Sync 

5. TB Clinical Tables - Verify Sync Columns (VanId, VanSerialNo, ParkingPlaceID, Processed, SyncedBy, SyncedDate, SyncFailureReason, LastModDate, LastModBy)  

• Tb_screening 

• Tb_suspected 

• Tb_confirmed_cases 

• Tb_stoptb_visit 

6. New columns to track per-record down-sync delivery 

Central DB (Add to each table which involved in downsync):

 Local DB:

Note: Processed = 'F' + SyncFailureReason : Carries all required information

Any edits on the record resets Processed back to 'N' - same as a new record.

LastDownSyncDate provides the conflict detection reference during up-sync.

7. Down-Sync Order - FK Dependency Chain

Records must arrive on the laptop in this order:

Master / Reference Data 

• M_state / m_district / m_districtblock 

• M_providerservicemapping 

• m_van/ m_vantype / m_parkingplace 

• M_servicepoint / m_servicepointvillagemap 

• M_user / m_uservanmapping 

• Clinical masters 

 Beneficiary Root Tables 

• M_beneficiaryregidmapping 

• I_beneficiarymapping 

 Then all transactional / clinical tables

Note: The down-sync query for each transactional table is simply SELECT * FROM {table} WHERE VanID = {vanID} 

Conflict Handling Desing: 

Master Table Conflicts: 

Master / reference tables are central-authoritative.  Local never edits them, so no conflict handling is required for those tables.  

Overview:

After initial down-sync, two types of edits can happen simultaneously:

• Edits a record directly in the Central DB
• Edits the same or a different record on the local laptop while offline.

Any record edited in the central after down-synced is automatically flagged for re-down-sync.  

Any local edit always resets Processed back to 'N'.  'N' covers both new records and records edited after a previous sync.

Key Actions on Each Event: