Sync

1. A server should be responsible to handle or offer a mechanism to handle errors once data reaches it. (Error handling mechanism is being designed by the platform).

2. Sync will be manually triggered by the user (except for automatically syncing configuration down on the first login).

3. Sync down of data is not required to support (good to have) the first rollout.

4. Sync will be done through bulk APIs.

5. Sync will send each save action performed by the field user while offline to the server to preserve an audit of actions performed by the field user.

   1. Eg: If a field user registers an individual and saves the record and then goes back to update the individual, this will result in two API calls to the server (one create and one update).

6. API response compression Gzip will be turned on for all the endpoints.

7. Unique identifier to be used between client and server:

   1. A Client will create a unique (client-generated) identifier per entity (clientReferenceId) to relate entities while operations are being performed offline and send this id to the server for creating operations.

   2. Any subsequent operations (like update, delete) will be on the server gen id, so the client has to get the server gen id by searching using the client generated id. The client will call search API with clientReferenceId and will get the server generated id.

   3. Client will update the server-generated id into the records on the client and use the server-generated id for subsequent updates for those entities.

8. Processing on the backend will continue to be asynchronous and not changed for the health use case.

Configurability

Backend

1. Search API max limit and the default limit.

2. Service details and endpoints.

Frontend

1. Service details and endpoints.

2. Number of entities sent to the server in bulk API calls

3. Additional fields per entity in the app.

4. The drop-down values or select options to be presented in the app for field users.

5. Configuration changes are expected to be additive for the data captured against such configuration to continue being usable.

6. Number of retries on API call failure after which the app should stop retrying.

7. Timeout for the API calls.

Access Control

1. Access to data will be defined by the linkages of staff to the project and the corresponding boundary while respecting role-action mappings instead of the tenant-based approach.

Data

1. All deletes are soft deletes.

2. The server is responsible to delete nested/child entities if applicable when the parent entity is deleted.

3. Undeletion is not permitted.

4. Duplicate updates do not need to be detected or filtered out. The client is responsible to send duplicate updates on entity as separate requests to server.

5. Since persistence in DIGIT is asynchronous but the sync process from the field worker app is likely to send dependent data in a short period, a cache is to be introduced against which dependent data can be validated if required while it is in the process of being persisted to the DB. This cache is exposed via the search API of the corresponding service and the caller is agnostic to whether the result was returned from the cache or database.

6. For v1, we can maintain the sequence of updates only for requests on a single entity by a single user. i.e. Updates on the same entity by multiple users will result in the last caller's updates going through.

7. To maintain the sequence of updates, a rowVersion field is introduced in every entity. Callers pass the rowVersion as received from the server. The server can detect if any out-of-sequence updates have come in and reject it / pass it to the error handling mechanism.

8. Search APIs will not return (soft) deleted data by default. If deleted data is required the includeDeleted param can be passed to the search APIs.

Limitations

1. From the Product requirement perspective, there is no unique identification identifier, so Platform is unable to check the uniqueness of registry entities.

Health Campaign - High Level Design

The high level design is divided into:

1. Master data

2. Registries/entities

3. Reusable DIGIT services

4. Form engine support

5. Multi-tenancy

6. Android offline first app

7. Web app - Campaign planning + dashboard

8. External integration - DHIS2

Base Health Campaign on DIGIT Core 2.8.

Master Data

Master data categorised on the complexity required to maintain them from the technical perspective.

1. Simple Masters

   1. Roles

   2. Additional field schemas for different entities

   3. Project task configurations

   4. Project type

   5. Role-actions

   6. Actions

2. Hierarchical Masters

   1. Administrative boundary and hierarchy

3. Inter-Linking Masters

   1. Field app config

   2. Service registry

Services/Registries

Individual Registry

• New service.

• As users are registered to campaigns, populate the individual registry with basic information about them.

• This registry is the first step towards the long term plans in DIGIT to move non users of the system away from the User service. However, due to the current dependency on User service for authN and authZ among other things, this registry will be a wrapper over the User service.

Household Registry

• New service.

• Collection of Individuals living together (potentially receiving shared campaign intervention).

Facility Registry

• New service.

• Needed to model storage Warehouses through which stock moves.

Product Registry

• New service.

• Needed to model the resources that are distributed as part of projects both as part of stock movement and actual distribution to beneficiaries.

Project Service

• New service.

• Models how services and benefits are typically distributed to citizens by governments.

• Contains multiple endpoints within the service to map other entities such as beneficiaries, staff, facilities, resources to the projects.

Stock Service

• New service.

• Track inflow and outflow of stock resources.

Reusable DIGIT Services

Many of the DIGIT-Core services can be reused without any changes. Some of them could be extended and enhanced to support the required features.

DIGIT Services reused as-is

• digit-mdms-service

• Digit-location / boundary service

• digit-access-control

• Zuul API Gateway

• digit-idgen

• digit-persister

• digit-indexer

• digit-localization

• DSS

• Signed Audit

DIGIT Services reused with enhancements

No existing services being enhanced.

Workflow

The Health Campaign system does not make heavy use of workflows. Most flows in v1 are single actor and end after a single step (i.e. submitting collected data).

High-Level Design Diagram

ER Diagram

Form Engine Support

Form engine support was pushing out timelines and has been dropped from v1 scope.

Multi-Tenancy

The proposal is to have a single installation to support multiple countries and multiple health campaigns within these countries. Different campaigns will need to share registries.

Leveraging multi tenancy support in DIGIT for this.

Android App

Offline First

Android app is proposed to be modelled on mGramSeva app and will be built in Flutter.

This app will be used in areas with limited or no internet connectivity and hence will need to work while offline. Users will sync the data collected offline when they are in an area with network connectivity.

SQLite will be used to model structured data and ISAR will be used for unstructured data.

Form Renderer

Out of scope for v1.

Offline Dashboards

The field workers will need to see dashboards based on the data stored in the offline database. Library - TBD

Web App

Campaign Planning App

Out-of-scope for v1.

Dashboards App

The app will have some custom screens to capture information around the campaign plan.

DSS dashboards are planned to be leveraged for reporting dashboards.

External Integration

DHIS2

This will be added to implementation scope.

DIGIT is India’s largest open-source platform for digital governance. The health services are built on top of DIGIT. It is built on OpenAPI (OAS 2.0) and provides API-based access to various services, enabling governments to provide health campaign services with relevant new ones. It also facilitates integration with the existing system into the platform and runs seamlessly on any commercial/on-prem cloud infrastructure with scale and speed.

Key Architecture Highlights

• Health DIGIT is a micro-services-based platform that is built to scale. Micro-services are small, autonomous, and developer-friendly services that work together.

• It facilitates decentralised control between teams so that its developers strive to produce useful tools that can then be used by others to solve the same problems.

• Micro-services have intelligent endpoints that process information and apply logic. They receive requests, process them, and generate a response accordingly.

• Parallelism in development: Micro-services architectures are mainly business-centric.

• A large software or system can be broken down into multiple small components or services. These components can be designed, developed, and deployed independently without compromising the integrity of the application.

Multi-Layer Architecture

DIGIT Health follows a multi-layer or n-tiered distributed architecture pattern. As seen in the illustration above, there are different horizontal layers with some set of components such as Services, Registries, and DIGIT Core Services. Every layer consists of a set of microservices. Each layer of the layered architecture pattern has a specific role and responsibility within the application. The following are the advantages:

• Layered architecture increases flexibility, maintainability, and scalability.

• Multiple applications can reuse the components.

• Parallelism.

• Different components of the application can be independently deployed, maintained, and updated, on different time schedules.

• Layered architecture also makes it possible to configure different levels of security to different components.

• Layered architecture also helps users test the components independently of each other.

The articles in this section include:

API Spec

Sequence Diagrams

API Spec

Sequence Diagrams

Here are the articles in this section:

The articles in this section include:

API Spec

Sequence Diagrams

API Spec

Sequence Diagrams

API Spec

Sequence Diagrams

Overview

Attendance service allows users to maintain attendance registers, enrol individuals, create, update or search attendance logs and manage staff permissions.

API Specifications

Base Path: /health-attendance/

API Contract Link

Data Model

DB Schema Diagram

Web Sequence Diagrams

Attendance Register

Staff

Attendee

Attendance Log

API Spec

Sequence Diagrams

To learn more about Referral Reconciliation, click here. Link to the Pub Package:

The referral reconciliation feature enables the user to track referrals made by on-field health workers to different health facilities digitally via the Digit HCM app capturing all the cases of:

• Beneficiary being referred

• Referral details of the beneficiary

• Reason for referrals and their diagnosis

• Based on the diagnosis, further details, if applicable

Role

• HEALTH_FACILITY_WORKER

Getting Started

To use this package, add the following dependency to your pubspec.yaml file:

dependencies:
  referral_reconciliation: ^latest
  digit_scanner: ^latest

Integrating with the HCM Application

1. To integrate this package with the HCM Application, run the main function located in health-campaign-field-worker-app/tools/referral_reconciliation_imports.dart.

   • This will automatically add the necessary imports, mapper initializers, route config, setting initial data, and repository initialization to the required files.

2. Make sure you are on the path apps/health_campaign_field_worker_app and run the command:

dart run build_runner build --delete-conflicting-outputs

This adds a package route to the main router.gr.dart

1. Install the application and you should have referral reconciliation integrated into your base app.

By following these steps, you can successfully integrate and use the Referral Reconciliation module within your application.

Sequence Diagram

Here are the articles in this section:

To learn more about Attendance Management,

Link to the Pub Package:

Role

• SUPERVISOR

Features

• Attendance Pages: The package includes several pages like mark_attendance.dart, manage_attendance.dart, and session_select.dart that provides the user interface for managing attendance.

Getting Started

To use this package, add the following dependency to your pubspec.yaml file:

Integrating with the HCM Application:

1. To integrate this package with the HCM application, run the main function located in health-campaign-field-worker-app/tools/attendance_management_imports.dart.

   • This will automatically add the necessary imports, mapper initializers, route config, setting initial data, and repository initialization to the required files.

2. Now make sure you are on the path apps/health_campaign_field_worker_app and run the command:

This adds a package route to the main router.gr.dart

1. Navigate to the project bloc since we need to fetch registers and attendee data after login:

1. Next, navigate to the line where the project staff search is written, and add the below code in the try-catch where we check the role and fetch attendance data:

1. Make sure you are on the path apps/health_campaign_field_worker_app and run the command:

This adds a package route to the main router.gr.dart

By following these steps, you'll successfully integrate and can use attendance module within your application.

Sequence Diagram

API Spec

Sequence DIagrams

As a part of the 1.4 release, we have extracted the features of the Frontline Worker's App as individual packages:

To known more about Inventory Management,

Link to the Pub Package:

Role

• DISTRIBUTOR, WAREHOUSE_MANAGER

Features

• Manage Stocks: Receipt, issued, returned, damaged, and loss of stocks.

• Stock Reconciliation: Reconcile the stock data.

• View Reports: View the reports of the stocks.

Getting Started

To use this package, add the following dependency to your pubspec.yaml file:

Integrating with the HCM Application:

1. To integrate this package with the HCM Application, run the main function located in health-campaign-field-worker-app/tools/inventory_management_imports.dart.

   • This will automatically add the necessary imports, mapper initializers, route config, setting initial data, and repository initialization to the required files.

2. Make sure you are on the path apps/health_campaign_field_worker_app and run the command:

   This adds a package route to the main router.gr.dart

3. Install the application and you should have Inventory Management integrated into your base app.

By following these steps, you can successfully integrate and use the Inventory Management module within your application.

Sequence Diagram

To learn more about Registration and Delivery, Link to the pub package:

Role

• DISTRIBUTOR

Features

• Register new households and individuals.

• Search existing households and individuals.

• Update details for existing households and individuals.

• Record service delivery of healthcare interventions to households and individuals for a single round campaign.

• Auto-calculation of resources to be delivered to a household or individuals based on the configured rule.

Getting Started

To use this package, add the following dependency to your pubspec.yaml file:

Integrating with the HCM Application:

1. To integrate this package with the HCM Application, run the main function located in health-campaign-field-worker-app/tools/registration_delivery_imports.dart.

   • This will automatically add the necessary imports, mapper initializers, route config, setting initial data, and repository initialization to the required files.

2. Make sure you are on the path apps/health_campaign_field_worker_app and run the command:

This adds a package route to the main router.gr.dart

1. Install the application and you should have Registration and Delivery integrated into your base app.

By following these steps, you can successfully integrate and use the egistration and delivery module within your application.

During boundary selection, if you need to downsync registration-delivery-related data, include the below code in the project_beneficiaries_downsync file:

Next, find this method in the same file networkManager.writeToEntityDb and the below repositories:

With the above changes, you will enable the down sync of registration and delivery data.

Link to the Pub Package:

How to Use the Scanner Package

To use the digit_scanner package, add the following dependency to your pubspec.yaml file:

Initialise DigitScannerBloc Provider

To initialise the DigitScannerBloc provider in your application, add the following code:

Clear the Scanner State

To clear the scanner state, use the following code:

Navigate to the DIGIT Scanner Page

To navigate to the Digit Scanner page, use this code snippet:

Wrap the DigitScannerListener or DigitScannerBuilder

Wrap the DigitScannerListener or DigitScannerBuilder in your widget tree wherever you need to read the scanned codes from the scanner state:

Find out about usage at the example implementation.

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

Codebase

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

Link to the Pub Package:

The showcase widget is a wrapper widget that provides a way to highlight or showcase a widget. It is useful for highlighting a widget in a list of widgets or providing functionality to provide visual help to understand the widget's functionality.

Features

• Provides a showcase or highlight of the wrapped widget:

Getting Started

To use the digit_showcase package, add the following dependency to your pubspec.yaml file:

Wrap the top layer of your widget tree with the showcase widget:

Provide localisation for the showcase widget:

Now use .buildWith to build the showcase widget:

Link to the Pub Package:

The digit_data_model package is a comprehensive data modeling library for the project. It defines various classes, enums, and functions used throughout the project. The package is written in Dart and is primarily used in Flutter applications.

Features

• Data Models: The package provides a set of predefined data models like DataModel, EntityModel, EntitySearchModel, AdditionalFields, AdditionalField, ClientAuditDetails, AuditDetails, etc. These models are used to structure the data in the project.

• Model Provider: The package includes a ModelProvider abstract class that can be implemented to provide a list of models. It also includes a ModelProviderRegistry class to register and retrieve all model providers.

• Data Model Type Enum: The package defines a DataModelType enum that represents the different types of data models in the project.

• Mapping Annotations: The package uses the dart_mappable package to generate mapping code for the classes. This helps in converting the data models to and from JSON.

• Data Repositories: The package provides abstract classes for data repositories, DataRepository, RemoteRepository, and LocalRepository, which can be extended to create repositories for different data models. It also includes error handling with InvalidApiResponseException.

• Sql Store: The package includes a SqlStore class that can be used to store data in a SQLite database.

Here are the key features it provides to other packages:

• Database Connection: It provides a connection to the SQLite database. This connection is opened when the database is first accessed.

• Table Definitions: It defines the tables in the database. These tables correspond to various entities in the project.

• Database Operations: It provides methods for querying and manipulating the data in the tables. These methods can be used to perform CRUD (Create, Read, Update, Delete) operations on the data.

• Schema Version: It provides the schema version of the database. This can be used to handle database migrations.

• Drift Integration: It uses the Drift package for interacting with the SQLite database. This provides a reactive persistence library for Flutter and Dart.

Getting Started

To use this package, add the following dependency to your pubspec.yaml file:

dependencies:
  digit_data_model: ^latest

Integrating with the HCM Application

To integrate this package with the HCM Application, run the main function located in health-campaign-field-worker-app/tools/digit_data_model_imports.dart.

This will automatically add the necessary imports, mapper initializers, and repository initializations to the required files.

Below are some examples of how you can use this package:

• Extend the EntityModel or `EntitySearchModel class and implement the required methods:

class ExampleSearchModel extends EntitySearchModel {
  ExampleSearchModel({
    required this.employeeId,
    required this.attendanceDate,
    required this.status,
  });
}

 class ExampleAdditionalFields extends AdditionalFields {
  ExampleAdditionalFields({
    required this.field1,
    required this.field2,
  });
}

• Extend the `LocalRepository` class and implement the required methods:

class ExampleLocalRepository
        extends LocalRepository<ExampleModel, ExampleSearchModel> {
    ExampleLocalRepository(super.sql, super.opLogManager);
    }

• Extend the `RemoteRepository` class and implement the required methods:

 class ExampleRemoteRepository
        extends RemoteRepository<ExampleModel, ExampleSearchModel> {
  ExampleRemoteRepository(super.apiClient, super.opLogManager);
    }