Click here to learn more about the Master Data Management Service, and configure it.

Sync

1. Server should be responsible to handle or offer a mechanism to handle errors once data reaches it. (Error handling mechanism being designed by Platform).

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

3. Sync down of data is not required to supported (good to have) for first roll out.

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 2 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. 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 create operations.

   2. Any subsequent operations (like update, delete) will be on server gen id, so client has to get server gen id by searching using client generated id. Client will call search API with clientReferenceId and will get 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 default limit

2. Service details and endpoints

Frontend

1. Service details and endpoints

2. Number of entities sent to 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 in order for the data captured against such configuration to continue being usable.

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

7. Timeout for API calls

Access Control

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

Data

1. All deletes are soft deletes

2. 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. 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 span of time, 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 cache or database.

6. For v1, we can maintain 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 last caller's updates going through.

7. In order to maintain 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 uniqueness of registry entities.

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 a variety of 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 smart 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 big 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 micro-services. 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 independent of each other.

Note: Check the master promotion guide for more details.

The articles in this section include:

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

Here are the articles in this section:

API Spec

Sequence Diagrams

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 categorized 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 modeled 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.

API Spec

Sequence Diagrams

API Spec

Sequence Diagrams