Health
PlatformDomainAcademyDesign SystemFeedback
v1.7
v1.7
  • 👋Introducing Health
    • Release Notes
      • HCM v1.7 Release Notes
        • Release Checklist
        • Eligibility Checklist
        • Service Build Updates
      • HCM v1.6 Release Notes
        • Service Build Updates
        • Release Checklist
        • Migration from v1.5 to v1.6
      • HCM v1.5 Release Notes
        • Migration from v1.4 to v1.5
        • Service Build Updates
        • Release Checklist
      • HCM v1.4 Release Notes
        • Migration from v1.3 to v1.4
        • Service Build Updates
        • Release Checklist
      • v1.3 Release Notes
      • v1.3 Tech Release Summary
        • Master Data Management Service (MDMS) & Configuration Updates
        • Test Cases
        • Service Build Updates
      • v1.2 Release Notes
      • v1.0 Release Notes
  • Product Roadmap
  • 💙HEALTH CAMPAIGN MANAGEMENT
    • Understanding Health Campaign Management (HCM)
    • Value Proposition
  • 🎯HCM PRODUCT SUITE
    • Functional Specifications
      • Campaign Type Setup
      • Campaign Setup
      • Inventory
      • Boundary Hierarchy
      • Beneficiary
      • Boundary Data Specs
      • Draft System User Setup
      • Role Action Mapping
    • Building Blocks & Services
    • Health Products
      • HCM App
        • User Manual
          • Single Round Campaigns
            • Registration & Delivery
              • Registration & Delivery: IRS
          • Multi-Round Campaigns
            • Registration & Delivery
            • Download Beneficiary Data
          • Common Functions
            • User Management
            • 2D Voucher Scanning
            • Proximity-Based Search
            • Voucher-Based Registration and Distribution
            • Tracking Beneficiary Referrals
            • Tracking Side-Effects for Beneficiaries
            • Tracking Adverse Events
            • Health Facility Referral
            • Raising Complaints
            • Resolving Complaints
            • Inventory Management
              • User Manual
                • Stock Management
                • Stock Reconciliation
                • View Reports
                • Bale Scanning
            • Attendance Management
            • Payments
              • Guide to HCM Payments
            • Community Living Facilities
              • Product Requirement Document
          • Support Functions
            • Language Selection
            • Login
            • Forgot Password
            • Project Selection
            • Hamburger Menu
            • Help
            • Sync
            • Checklist
      • Campaign Management Dashboard
        • User Manual
        • Configurations
          • MDMS Configurations and s3 assets
          • IRS Dashboard Chart Configurations
        • Kibana Dashboard Integration With DSS Module
          • Auth Proxy Setup and Configuration for Kibana
        • SMC Dashboard
      • Microplanning
      • HCM Console
      • Health Payments
        • MDMS Configurations
        • Attendance Update and Approval Process
          • Project Selection
          • Register Inbox
          • View Attendance:Edit And Approve
        • Bill Generation Process
          • Project And Bill Aggregation
          • Bill Generation
          • My Bills
  • 🚀REFERENCE IMPLEMENTATIONs
    • Mozambique
      • LLIN Overview
      • Customisation
      • Rollout
  • 🧰TECHNOLOGY
    • Architecture
      • High Level Design
        • Health Campaign System High Level Design
        • Design Decision Log
      • Low Level Design
        • Registries
          • Individual
          • Household
          • Product
          • Facility
          • Attendance
          • Expense
        • Services
          • Project
          • Stock
          • Referral
          • Muster Roll
          • Expense Calculator
      • Field App Architecture
        • UI Packages
          • Closed HouseHold package
          • Registration & Delivery Package
            • Eligibility Checklist
            • Communal Living Facilities
          • Referral Reconciliation Package
          • Inventory Management Package
          • Attendance Management Package
          • DIGIT Scanner Package
          • Digit Showcase Package
          • Digit Data Model Package
          • DIGIT DSS Package
          • Complaints Package
          • Survey Form Package
          • Sync Service Package
    • Standards
    • Security
    • Interoperability
  • 🪝SETUP
    • Planning an HCM Implementation
    • Establish Project & Team
    • Gathering Requirements
    • Installation
      • Install Using GitHub Actions in AWS
      • System Data Setup
      • Project Data Setup
      • Setup Mobile App
      • Setup Kibana Dashboard
        • Create or Edit Existing Dashboards
      • Server Cleanup
    • Configuration
      • Configuring HCM to Campaign and Country Needs
      • Service Configuration
        • Individual Registry
        • Household Registry
        • Product Registry
        • Facility Registry
        • Stock & Inventory
        • Project Services
        • Referral Management
        • Attendance
        • Complaints
          • QA Sign-Off
            • Test Cases
        • User Management
          • QA Sign-Off
        • Muster Roll
        • Expense Service
        • Expense calculator
      • UI Configuration
        • Stock Management
        • Language Selection
        • Login
        • Forgot Password
        • Project Selection
        • Dashboard Configuration
          • Dashboard UI Enhancements
          • HCM Dashboard Master Promotion Guide
        • Attendance Management
          • Attendance Package Extraction and Interaction with HCM Application
    • Quality Assurance Testing
      • Regression Test cases
        • HCM Product
        • HCM Console
        • Microplanning
      • Eligibility and CLF Test cases
      • Console v0.3.1
      • Micro planning v0.2
      • HCM Payments v0.1
  • 🔵COMMUNITY
    • Source Code
    • Committee
      • Digital Product Advisory Committee Charter
      • Idea Management Process
      • Sessions
        • November 2023 Session
        • August 2024 Session
          • Minutes of the Meeting
        • December 2024 Session
    • HCM Declarative Statements & FAQs
Powered by GitBook
On this page
  • Tech Stack/Core Dependencies
  • Codebase
  • Design
  • Design Features
  • Diagrams
  • Class Diagram
  • Sequence Diagrams
  • Delivery Resource
  • Proximity Based Search
  • Beneficiary Data Down Sync
  • Multi-Round Support
  • Downsync of Beneficiaries

Was this helpful?

Export as PDF
  1. 🧰TECHNOLOGY
  2. Architecture

Field App Architecture

PreviousExpense CalculatorNextUI Packages

Was this helpful?

https://creativecommons.org/licenses/by/4.0/

The high-level design of the HCM Framework is divided into three main parts, the details of which are available below.

Tech Stack/Core Dependencies

Flutter: Framework to build multi-platform apps

SQLite: SQL offline db

ISAR: NoSQL offline db

Dio: HTTP Client

Codebase

https://github.com/egovernments/health-campaign-field-worker-app

Design

Design Considerations for Field App

  1. Needs to work in low/no network coverage areas.

  2. Needs to have a high level of configurability.

  3. Needs to work on Android.

  4. Users of the app have low-tech literacy.

Design Features

Sync

Since the app is expected to be configurable, there is a need to receive these configurations from the server. Data already on the server might also need to be retrieved by the app.

Since the app is expected to work while users are offline, there is the need to send data that has been collected while the user has been offline to the server.

These functionalities are collectively called sync. The retrieval of configuration and data is referred to as sync down while sending data collected using the app is called sync up. Login and sync can only be done while the user is online.

When a user logs in, a sync down is performed to fetch the required configuration and data for the field app to run. After collecting data using the app, the user can perform a sync which will perform a sync-up (to send all data collected) followed by a sync-down (to retrieve any fresh configuration). Syncing of data down is not required for the initial implementation and can be turned off.

Configurability

Configurations for the field app are managed as master data in the MDMS service. These configurations are used to manage various aspects of how the app functions. The important ones are:

  1. If the app has to run in an offline first mode or an online mode.

  2. The backend interfaces for the app include localisation, MDMS, and various services. This also includes the URLs for the various services and endpoints so that a fresh app build is not required if there is a new version of an API.

  3. How long the client can use each configuration that has been previously fetched before requesting data from the server (to optimise the time taken for sync).

  4. Values/options that need to be displayed in various fields in the app.

  5. Additional fields are to be captured for any of the entities, if any.

  6. Supported languages.

Op Log

Any action to create or update the data performed by the field user while the app is configured to run in the offline first mode is written to an op log. When the user performs a sync, the sync-up action reads from this op log to send the data to the server.

Permission (role-action)-Based Access and Sync

Sync is optimised to fetch configuration relevant to the logged-in user so that only the configuration/data for the actions, permissible to the user within the projects that they are assigned to, are fetched.

Network Manager

The network manager component in the app acts as an interface between the rest of the app and the backend. As a result, the other components in the app do not have to change their behaviour based on whether the app is online or offline and rely on the network manager to handle this complexity. This implies that the network manager makes an API call directly if the app is offline or saves to the local database and the op log if the device is offline, whereas the other components just make a call to the network manager to read/write data.

Down Sync of Beneficiaries

The down sync of beneficiaries feature is designed to optimise data synchronisation between the local device and the server, specifically focusing on the beneficiary records. This process helps prevent duplicate record creation by different users within the same boundary.

The down sync initiates by sending a request to the server, providing the boundary code along with offset and limit parameters. The server validates the provided parameters and responds with the total count of beneficiary records within the specified boundary.

Based on the total count received, the down sync retrieves beneficiary records from the server in batches. The batch size is dynamically adjusted according to the device's internet speed to optimise the data transfer.

The response from the server, containing beneficiary records, is written to the local entities tables on the device. This ensures that the local database stays updated with the most recent beneficiary information.

Key Features

  • Utilises offset and limit parameters for efficient pagination of data retrieval from the server.

  • Adapts the batch size based on the internet speed to enhance the overall synchronisation performance.

  • Essential for avoiding the creation of duplicate beneficiary records by different users within the same boundary.

Use Case

The down-sync of beneficiaries is particularly crucial in scenarios where multiple users operate within the same geographical boundary. It ensures that each user has access to the latest beneficiary data while minimising redundant record creation.

Multi-Round Campaign

The multi-round campaign streamlines beneficiary registration and delivery processes, ensuring efficient tracking of eligibility and delivery statuses across multiple cycles.

The system fetches the projectType configuration from MDMS for the selected project.

Eligibility checks are dynamically performed based on the retrieved projectType configuration.

  • The minimum and maximum age criteria are evaluated to determine the beneficiary's eligibility for the current cycle.

  • Recorded side-effects for the beneficiary in the current cycle.

  • There is no cycle defined in the MDMS configuration for the selected project on the current date.

Status Tracking

  1. Not Eligible:

  • The minimum and maximum age criteria are evaluated to determine the beneficiary's eligibility for the current cycle.

  • Recorded side effects for the beneficiary in the current cycle.

  • There is no cycle defined in the MDMS configuration for the selected project on the current date.

  1. Beneficiary Refused: Indicates that the beneficiary refused to accept the delivery in the current cycle.

  2. Beneficiary Referred: Indicates that the beneficiary was referred to a health facility during the current cycle.

  3. Visited: Indicates that a delivery was successfully made for the beneficiary in the current cycle.

  4. Not Visited: Indicates that no delivery was made for the beneficiary in the current cycle.

Beneficiary Refused, Beneficiary Referred, and Not Eligible status, except the age eligibility, will target reset every new cycle.

Diagrams

Class Diagram

Sequence Diagrams

Init App

Login

Sync Down

Delivery Resource

Proximity Based Search

Beneficiary Data Down Sync

Multi-Round Support

Downsync of Beneficiaries