Skip to main content

Technical Development Summary – Final Month of Notice Period

This document outlines the features and enhancements developed during the final month of the notice period. Each section below details specific functionality, technical implementations, and database-related changes that were introduced to improve system efficiency, data integrity, and feature coverage in the ZM mobile and backend systems.

1. Mobile Immunization Van Feature Enhancement​

Objective:​

To enhance data tracking for mobile immunization vans by including geographic coordinates (latitude and longitude) for each vaccination event and optimize data reporting via the data warehouse.

Changes Implemented:​

  • Stored Procedure Migration:

    • The existing stored procedure ImmunizationVanRegistry was previously located in the active transactional database unfepi.

    • It has now been migrated to the data warehouse database unfepi_dwh for improved performance and analytical processing without impacting live transactions.

  • Functional Modification:

    • The stored procedure was enhanced to include new fields: latitude and longitude for each vaccination record, enabling geolocation-based reporting and analytics for mobile van operations and included in the downloadable CSV report.

2. Rota3 Vaccine Feature Implementation​

Objective:​

To introduce a new vaccine (Rota3) that is selectively administered in specific geographic regions, starting with the South district of Karachi.

Key Enhancements:​

  • Vaccine Master Table Update:

    • A new vaccine entry for Rota3 was added with vaccine_id = 35.

    • A new flag isLocationBased was introduced in the vaccine table to distinguish vaccines that are location-specific.

  • Location-Based Filtering:

    • A new mapping table vaccine_location was created to control vaccine visibility by geographic location.

    • The table structure includes:

      • vaccine_id: References the specific vaccine (e.g., 35 for Rota3).

      • location_id: Refers to the location where the vaccine is applicable (e.g., 34324 for South district, Karachi).

  • Vaccination Schedule & Dependency Configuration:

    • Vaccine Gap Table (vaccine_gap): Entries added for Rota3 to define the time intervals such as birthdate gap, previous vaccine gap, etc.

    • Vaccine Prerequisite Table (vaccine_prerequisite): Rota2 is set as a mandatory prerequisite for Rota3.

    • Settings Table: Relevant configurations for Rota3 were registered to enable system-wide support.

  • End-User Impact:

    • Only vaccinators operating in the South district of Karachi will see the Rota3 vaccine option on the ZM mobile application.

3. Offline Sync Data API Optimization​

Objective:​

To improve the performance of child and women data synchronization APIs used in offline scenarios by decoupling large procedures and optimizing nested logic.

Improvements Made:​

  • Stored Procedure Refactoring:

    • The existing procedure SyncDataChildren was split into two separate procedures:

      • getChildBiography: Retrieves demographic and basic profile information.

      • getChildVaccination: Retrieves immunization history and events.

    • Similarly, SyncDataWomen was split into:

      • getWomenBiography

      • getWomenVaccination

  • Codebase Optimization:

    • Java class DataServiceHelper.java was refactored:

      • Functions getAllUpdatedNewChildUpdated and getAllUpdatedNewWomenUpdated were optimized to reduce nested loops and enhance runtime efficiency.

  • Benefits:

    • Improved data retrieval speed.

    • Reduced server load during synchronization.

    • Better modularity and maintainability of backend logic.

4. Tracking Feature Modification (On Hold)​

Objective:​

To shift the granularity of tracking records from visit-based to vaccine-based to enhance monitoring and auditing accuracy.

Implementation Details:​

  • Database Schema Update:

    • A new column vaccinationRecordNum was added to the tracking table.

    • This allows linkage of tracking entries to individual vaccination records rather than aggregated per visit.

  • Behavioral Change:

    • Previous Behavior: A single tracking record per visit, regardless of how many vaccines were administered.

    • New Behavior: A separate tracking entry will be created for each vaccine administered during a visit.

  • Status:

    • Currently on hold due to the need for backfilling historical data.

    • Task pending: Populate vaccinationRecordNum for historical entries in the tracking table.

5. Vaccination-MCCT Visit Linking Feature​

Objective:​

To resolve inconsistencies in visit and vaccination record mapping, especially in scenarios involving multiple visits by a child on the same day.

Technical Solution:​

  • New Bridge Table: vaccination_mcctvisit

    • Purpose: Establish a direct one-to-one mapping between a vaccination event and a corresponding visit record.

    • Columns:

      • vaccinationRecordNum: Unique identifier for the administered vaccine.

      • visitRecordNum: Identifier for the child’s visit on a particular date.

  • Problem Addressed:

    • In the prior implementation, multiple visits on the same day by the same child could lead to incorrect linkage due to missing granularity in the mapping.

    • This new table ensures accurate correlation between individual vaccination records and their associated visits.

  • Benefits:

    • Resolves data integrity issues for reporting and audit.

    • Improves traceability of vaccination data across multiple visit scenarios.