Mission

Help countries achieve Health SDGs by building digital public goods that strengthen public health.

Overview

The DIGIT Health platform is being built as an open source Digital Public Good to expand capabilities in public health. It is being designed to work across countries at varying levels of capacity and complexity.

The focus is to help countries reduce “diseases of poverty.” The World Health Organisation (WHO) estimates that such diseases “account for 45% of the disease burden in the poorest countries” and stem from poor nutrition and sanitation, absence of health education, and indoor air pollution. We want to help countries reduce this by building digital tools on top of eGov’s open-source platform - the Digital Infrastructure for Governance, Impact & Transformation (DIGIT) - to enable and manage health campaigns, and disease surveillance.

As platform adoption increases over time, it will continue to generate more real-time and authoritative data in the public health space, besides ingesting data from other sources. The platform will become a “shared source of truth” that all stakeholders can use to align resources and decisions to achieve operational and financial efficiency. The platform will therefore progressively and greatly improve the ability of low-and-middle-income countries (LMICs) to better manage the delivery of public health priorities.

Need for DIGIT Health Platform

Public health challenges are massive and complex. While many countries have limited capacity and resources to address such issues, the current approach to these challenges tends to strictly focus on delivering one specific outcome, driven by specific nodal agencies. Each programme ends up replicating the same set of efforts and outputs. For example, health campaigns are typically categorised as per the diseases they aim to address - malaria, polio, etc. Each programme involves a similar set of activities: planning, delivery and logistics, human resource management, monitoring and reporting. They suffer from low effectiveness due to the siloed and uncoordinated way in which they are funded, planned, executed, and monitored.

Current digital efforts do not take a “whole of system view” and do not solve the cost of coordination and duplication issues. Each program also develops its own systems (MIS, apps, dashboards). Such siloed, solution-centric approaches and tools create a new set of problems and inefficiencies for countries:

• Higher costs and time: This is incurred on creating or procuring and maintaining these systems, including the onboarding cost of the same actors in each programme.

• Data exists in multiple systems: They are not interoperable, leading to duplication, inconsistencies, poor adoption by on-ground workers, and sub-optimal decision-making.

• Limited reusability and innovation: Data and capabilities are intertwined and ‘locked,’ making it extremely hard for the wider ecosystem to innovate and build upon.

• Sub-scale: The tools are not able to scale for the national population and across programmes.

The DIGIT Health platform reimagines the public health space as a set of horizontal building blocks, such as shared registries, and services, accessible through well-defined open APIs, which can be leveraged by multiple countries and disease programmes. It will eliminate the above inefficiencies. Further, it will facilitate the independent evolution of each building block and participation by the health ecosystem, leading to faster innovation.

Platform scope

The DIGIT Health platform is being designed to enable delivery at scale, across various aspects of public health, and multiple country contexts. Using the platform approach, we will create an end-to-end flexible, open, configurable, and reusable platform to plan, manage and run any public health program such as health campaigns so there is detailed and timely monitoring and evaluation to review coverage, target achievement and identification of gaps for their distribution.

Benefits

• Re-usable: Shared data registries and infrastructure

• Interoperable: Open API specifications

• Secure and scalable

• Multi-country support: Support for infrastructure isolation, as well as data isolation

• Multi-lingual: Support for multiple languages

Objectives

DIGIT Health platform will:

• Allow ecosystem actors to use, contribute and evolve the platform collaboratively and sustainably.

• Give the option to ecosystems to either host it on their own infrastructure or use it from a hosted environment (hosted by a trusted party) for which a sustainable costing and financial model will be evolved.

Approach

The common services and shared data registries can be reused to assemble products that provide a unified and consistent experience for each set of actors. The programme-specific context such as roles, workflows, and notifications can be configured by the respective programs, enabling faster rollout and execution.

The APIs will allow data and functionality to be reused across multiple departments, effectively breaking silos across programs. Through APIs, meaningful data and services can also be made available to the various ecosystem stakeholders for innovation and interoperate with other systems like MOSIP, DHIS2, Sunbird RC, DIVOC, etc. that are focused on other parts of the public health delivery value chain, such as disease surveillance, supply chain, verifiable certificates, and health insurance.

Products

Programme

Useful links

Contact Us

MDMS

Config

Devops

Find the Product Capability Roadmap below:

Roadmap Ahead

The articles in this section includes:

Overview

The detailed mapping of DIGIT’s capabilities with the core requirements mentioned in the NUIS digital blueprint is mentioned below:

Interoperability

Data specifications/models are available for domain entities. DIGIT is designed as an API-first platform wherein data specs/models are created for all key entities, thus ensuring interoperability through open APIs and open standards. Taxonomies are available for the key domain entities/registries. These can later be harmonised with standard taxonomies in the domain as and when they are made available. DIGIT data models and APIs are published as open APIs freely available to everyone in the ecosystem. Currently, DIGIT provides at least three key distinct APIs for all domain entities: Create, update and search. Deactivation/cancellation of key entities in DIGIT is achieved through updating their status to inactive as per their defined specification/API contracts. Given the API-first and micro-services-driven nature of DIGIT, current APIs and models can be quickly harmonised with national standards as and when they are made available. DIGIT strives to leverage established domain standards (national/international), wherever available.

Data Privacy And Security By Design

Data Privacy

Data privacy capabilities are available to mark and protect sensitive data. The core service layer of DIGIT includes signing and encryption service as one of the core services that provide capabilities to sign/encrypt/mask sensitive data. It is designed such that it can work against software key stores and can be extended to integrate with any kind of hardware key store to store and protect signing and encryption keys. Encryption requirements can be defined and adhered to for the storage of sensitive data. DIGIT requires the user PII data to be stored in its user service, which is, by default, enabled for encryption of sensitive data as user data vault. All other services in DIGIT are required to access PII data by explicitly calling the user service, which, in turn, audits all access to PII. In addition, individual services in DIGIT can leverage DIGIT’s signing and encryption service (this is what the user service leverages to create user data vault) to further protect additional sensitive data available with the services. DIGIT provides the capability to define workflows for data modification that can be configured to have approval steps to get the needed consent for any data modification activities. DIGIT currently provides RBAC (Role-Based Access Control)-based access control for access (search) to data.

Security

Appropriate access controls can be defined in the APIs to ensure authorised access to sensitive data. DIGIT is designed to handle authentication and authorisation as a perimeter control at its API gateway layer to ensure that unauthorised calls are not allowed to contact the respective micro-services. DIGIT provides an RBAC mechanism where users are explicitly provided access to relevant resources by assigning them appropriate roles. By default, DIGIT supports OAUTH-based authentication for individual users and APIs. However, the authentication and authorisation filter in DIGIT is designed to be easily extendable to support any further authorisation and authentication needs. The perimeter security mechanism in DIGIT also helps developers in focusing on the functional developments for further services and offloading the access control requirements for new resources and their APIs to the API gateway using simple configurations. DIGIT also ensures that risks like the following are taken care of:

• Privilege escalation – form field manipulation

• Failure to restrict URL access

• Insecure direct object references (IDOR)

• Malicious file upload leads to cross-site scripting

• Improper authentication

• Missing account lockout

• Request throttling attack

• Weak encoding mechanism

• Sensitive information in URL

• Lack of automatic session expiration

• Insecure banner implementation

• Concurrent session

• Clickjacking

• Improper error handling

Transparency and Accountability Through Data

DIGIT has the capability to define key registries in OpenAPI 3.0 specs formats. It can easily achieve key APIs like create/update/search using its building blocks in core services, mainly through configurations and using lightweight extensions on a needs basis. DIGIT has the capability to protect person-specific sensitive data by encrypting them in the user data vault (user registry), which allows configuration-based protection of sensitive PII. DIGIT requires additional registries to reference PII using this mechanism. In addition, registries in DIGIT can leverage its data protection (signing and encryption) core service to provide additional protection to registry-specific attributes. The registry data in DIGIT can be signed for tamper-proofing, using its signing and encryption core service. A proof-of-concept for this has already been done on the ePass module that was built on the DIGT platform. All key data modifications in DIGIT are access logged to provide an audit trail, which can be accessed through the APIs. The upcoming version of DIGIT is planning to bring in the concept of immutable event logs to further strengthen this capability. DIGIT leverages open-source telemetry to provide the ability to gather telemetry data and extends it for the DIGIT-specific processing pipeline. This framework allows for additional event definitions and contextual extension of the telemetry processing pipeline thereby future-proofing this capability in DIGIT.

Reusability and Extensibility

The DIGIT platform is designed as a collection of more than 50-plus atomic micro-services which are bundled together in a given context to provide end solutions. The micro-services in DIGIT can be divided into three main categories: data services (registries, reference master data management, etc.), tech infrastructure services (authentication, authorisation, notification engine, etc.) and domain services (assessment, NOC, etc.). Citizen, employee and administrative interfaces in DIGIT use these micro-services to achieve the needed functionality. Data models and APIs in DIGIT are defined as OpenAPI 3.0 specifications and can be extended by using a combination of configuration and extension techniques. For example, if the additional attributes are only needed to be stored with format validation, it can be a simple schema extension, while if the additional business checks/functionality need to be implemented using the extended attributes, then it can be achieved using pre/post request filters or extending underlying micro-services. DIGIT allows the extension of existing capabilities without needing architectural interventions. As described above, the extension of existing functionality on DIGIT can be achieved using additional configurations, additional extension services, or request/response filters. Several partners have extended DIGIT modules to cater to new use cases. For instance, the DIGIT mCollect module caters to the collection of fees for over 50 services on the counter, but it does not have a citizen interface for the payment of these services online. The Directorate General Defence Estates (DGDE) wanted to introduce this interface for the citizen’s of cantonment boards in India, and were able to easily enhance the mCollect module to include this capability. DIGIT supports single-instance multi-tenancy to enable sharing of the underlying infrastructure. All DIGIT data models and services are designed to be multi-tenanted. DIGIT uses an API-first approach in its design and development to ensure loose coupling between its various components. These APIs are clearly defined using OpenAPI 3.0 specifications to ensure clear documentation.

Evolvability and Scale

Multi-Channel Access

DIGIT is designed using an API-first approach, therefore enabling any user interface channel to leverage it. DIGIT’s own user interfaces (web/mobile app, WhatsApp, Chatbot) are implemented using its APIs to ensure that the offered platform capabilities and data are accessible to any delivery channel based on configured policies. DIGIT’s access control mechanism can be configured to provide different levels of access based on channels and roles.

Ecosystem-Driven

The DIGIT platform and its user interfaces are completely open source. All external components used in DIGIT are also open source. Due to its API-based and event-driven architecture, DIGIT can be integrated with any existing stack. Wherever appropriate, DIGIT also provides out-of-the-box integrations with crucial stacks/platforms. The most common integrations are to payment gateways, SMS providers and SMTP email servers for a typical implementation. More than 14 organisations have already partnered with us to implement DIGIT across multiple implementations in India, and have built over 20 new solutions on top of the platform. DIGIT also provides the capability to gather feedback from the ecosystem in a digital manner. The feedback capability in DIGIT can be looked at the following levels:

• Service delivery feedback on services offered through DIGIT: DIGIT provides a highly configurable and extensible public grievance module to enable this kind of feedback/redressal for functional users (such as citizens, and employees).

• Service usage feedback: The DIGIT user interfaces include a telemetry SDK which is backed by telemetry infrastructure in DIGIT platform. Coupled with API access logs, this enables DIGIT to gather usage feedback through live action and can be used for fine tuning interfaces and APIs

• Design/feature feedback: As an open source project on Github, DIGIT provides a mechanism to provide comments/feedback on its various components using Github. This feedback can be leveraged to create a point of view on the future roadmap for the platform.

Introduction

This document lists the technical skillsets required for someone to build and support the Health Campaign Management (HCM) platform. There are distinct skills required to customise the application, and set up and run the infrastructure for this. The basic hardware configuration required for the developer machine is part of this document.

Technical Skillset

The technical skillsets that are required to work on the DIGIT HCM stack are listed below. It is expected the team has satisfactory knowledge of the below technologies before they take up DIGIT training.

Development Team Skillset

• Open API Contract - Swagger2.0

• YAML/JSON

• Postman

• Postgres

• Java and REST APIS

• Basics of Elasticsearch

• Maven

• Springboot

• Kafka

• Zuul

• ReactJS

• Flutter

DevOps Team Skillset

• Understanding of the micro-service architecture.

• Experience with AWS, Azure, GCP, and NIC Cloud.

• Strong working knowledge of Linux, command, VM Instances, networking, and storage.

• To create Kubernetes cluster on AWS, Azure, and GCP on NIC Cloud.

• Kubectl installation and commands (Apply, get, edit, describe k8s objects).

• Terraform for infra-as-code for cluster or VM provisioning.

• Understanding of VM types, Linux OS types, LoadBalancer, VPC, Subnets, Security Groups, Firewall, Routing, DNS).

• Experience setting up CI like Jenkins and creating pipelines.

• Deployment strategies - Rolling updates, Canary, Blue/Green.

• Artifactory - Nexus, Verdaccio, DockerHub, etc.

• Experience with Kubernetes ingress, setting up SSL certificates, and renewal.

• Understanding of the Zuul gateway.

• Gitops, Git branching, PR review process. Rules, Hooks, etc.

• Experience in Helm, packaging, and deploying.

• Apache, Nginx, Redis, and Postgres.

Hardware Pre-requisites

Teams are expected to have laptops/desktops configured as mentioned below with all the software required to run the DIGIT application:

• Laptop for hands-on training with 16GB RAM and OS preferably Ubuntu

• All developers need to have Git IDs

• Install VSCode/IntelliJ/Eclipse

• Postman

Software Assets

There are knowledge assets available on the net for general items and eGov assets for DIGIT services. Here you can find references to each of the topics of importance. It is mandated the trainees do a self-study of all the software mentioned in the pre-requisites using the reference materials shared.

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.

Release Summary

The release offers new platform features and functions, the details of which are provided below.

Functional Changes

• Added proximity-based search on household and individual.

• Multi-round campaign enabled in the mobile app.

  - Ability to configure cycles and deliveries.

  - Formula to calculate the dosage based on criteria added in MDMS.

• Referral management and side-effects.

• Total count added in the household search.

• Adding voucher tag (QR code) during beneficiary registration.

• Last-mile delivery with QR code (only BE - exchange of inventory between any users using user uuid scanned from logged in user profile code).

• Down sync API (v1.0).

Non-Functional Changes

NA

New ‌Feature Additions

Known Issues

• Down sync does not support incremental download (that is, downloading only new data created in the server since the last download).

Migration for new mandatory field (clientreferenceid) in Household_Member table, This migration has to be done before the deployment the Household build.

ALTER TABLE HOUSEHOLD_MEMBER ADD COLUMN IF NOT EXISTS clientreferenceid character varying(256);

UPDATE HOUSEHOLD_MEMBER SET clientreferenceid = id;

Migration for null client Audit details Since previous versions did not have the information.

UPDATE HOUSEHOLD SET clientCreatedBy = createdBy,
                     clientCreatedTime = createdTime,
                     clientLastModifiedBy = clientLastModifiedBy,
                     clientLastModifiedTime = lastModifiedTime where clientcreatedby is null;

UPDATE HOUSEHOLD_MEMBER SET clientCreatedBy = createdBy,
                     clientCreatedTime = createdTime,
                     clientLastModifiedBy = clientLastModifiedBy,
                     clientLastModifiedTime = lastModifiedTime where clientcreatedby is null;

UPDATE INDIVIDUAL SET clientCreatedBy = createdBy,
                     clientCreatedTime = createdTime,
                     clientLastModifiedBy = clientLastModifiedBy,
                     clientLastModifiedTime = lastModifiedTime where clientcreatedby is null;

UPDATE PROJECT_BENEFICIARY SET clientCreatedBy = createdBy,
                     clientCreatedTime = createdTime,
                     clientLastModifiedBy = clientLastModifiedBy,
                     clientLastModifiedTime = lastModifiedTime where clientcreatedby is null;

UPDATE PROJECT_TASK SET clientCreatedBy = createdBy,
                     clientCreatedTime = createdTime,
                     clientLastModifiedBy = clientLastModifiedBy,
                     clientLastModifiedTime = lastModifiedTime where clientcreatedby is null;

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.

Here are the articles in this section:

The articles in this section include:

API Spec

Sequence Diagrams

The articles in this section include:

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.

API Spec

Sequence DIagrams

API Spec

Sequence Diagrams

Here are the articles in this section:

API Spec

Sequence Diagrams

API Spec

Sequence Diagrams

API Spec

Sequence Diagrams

Here are the articles in this section:

Here are the articles in this section:

Here are the articles in this section:

API Spec

Sequence Diagrams

Overview

The individual registry provides APIs to create citizens or users to the DIGIT platform. This document provides the configuration details for setting up individuals.

Pre-requisites

• Knowledge of Java/J2EE(preferably Java 8 version).

• Knowledge of Spring Boot and spring-boot microservices.

• Knowledge of Git or any version control system.

• Knowledge of RESTful web services.

• Knowledge of the Lombok library is helpful.

• Knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-indexer, and eGov-user will be helpful.

Functionalities

1. Provides APIs to create, update, and delete individuals.

2. Provides APIs to bulk create, update, and delete individuals.

3. Inactivates the status of individuals post deletion.

4. Provides search API for individuals on name, individual ID, unique ID, and date of birth.

Setup Details

*In the case of IntelliJ, the plugin can be installed directly. For eclipse, the Lombok jar location has to be added in the eclipse.ini file in this format javaagent:lombok.jar.

API Details

Application.properties file information:

Kafka topics persister configs for eGov persister

individual.consumer.bulk.create.topic=individual-consumer-bulk-create-topic
individual.consumer.bulk.update.topic=individual-consumer-bulk-update-topic
individual.consumer.bulk.delete.topic=individual-consumer-bulk-delete-topic
individual.producer.save.topic=save-individual-topic
individual.producer.update.topic=update-individual-topic
individual.producer.delete.topic=delete-individual-topic

URLs for the external API references:

• idGen Id formats :-> idgen.individual.id.format=individual.id // eg: IND-[cy:yyyy-MM-dd]-[SEQ_ADDRESS_IND]

Configuration Details

Access MDMS Configurations

Action test: URL actions adding

{
      "id": 1549,
      "name": "Individual Create",
      "url": "/individual/v1/_create",
      "displayName": "Individual Create",
      "orderNumber": 0,
      "parentModule": "",
      "enabled": false,
      "serviceCode": "individual",
      "code": "null",
      "path": ""
    },
    {
      "id": 1550,
      "name": "Individual Update",
      "url": "/individual/v1/_update",
      "displayName": "Individual Update",
      "orderNumber": 0,
      "parentModule": "",
      "enabled": false,
      "serviceCode": "individual",
      "code": "null",
      "path": ""
    },
    {
      "id": 1551,
      "name": "Individual Search",
      "url": "/individual/v1/_search",
      "displayName": "Individual Search",
      "orderNumber": 0,
      "parentModule": "",
      "enabled": false,
      "serviceCode": "individual",
      "code": "null",
      "path": ""
    },
    {
      "id": 1561,
      "name": "Individual Bulk Create",
      "url": "/individual/v1/bulk/_create",
      "displayName": "Individual Bulk Create",
      "orderNumber": 0,
      "parentModule": "",
      "enabled": false,
      "serviceCode": "individual",
      "code": "null",
      "path": ""
    },
    {
      "id": 1562,
      "name": "Individual Bulk Update",
      "url": "/individual/v1/bulk/_update",
      "displayName": "Individual Bulk Update",
      "orderNumber": 0,
      "parentModule": "",
      "enabled": false,
      "serviceCode": "individual",
      "code": "null",
      "path": ""
    },
    {
      "id": 1563,
      "name": "Individual Delete",
      "url": "/individual/v1/_delete",
      "displayName": "Individual Delete",
      "orderNumber": 0,
      "parentModule": "",
      "enabled": false,
      "serviceCode": "individual",
      "code": "null",
      "path": ""
    },
    {
      "id": 1564,
      "name": "Individual Bulk Delete",
      "url": "/individual/v1/bulk/_delete",
      "displayName": "Individual Bulk Delete",
      "orderNumber": 0,
      "parentModule": "",
      "enabled": false,
      "serviceCode": "individual",
      "code": "null",
      "path": ""
    }

Access to role-based actions

{
    "rolecode": "SYSTEM_ADMINISTRATOR",
    "actionid": 1549,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "REGISTRAR",
    "actionid": 1549,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "DISTRIBUTOR",
    "actionid": 1549,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "SYSTEM_ADMINISTRATOR",
    "actionid": 1550,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "REGISTRAR",
    "actionid": 1550,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "DISTRIBUTOR",
    "actionid": 1550,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "SYSTEM_ADMINISTRATOR",
    "actionid": 1551,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "REGISTRAR",
    "actionid": 1551,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "DISTRIBUTOR",
    "actionid": 1551,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "SYSTEM_ADMINISTRATOR",
    "actionid": 1561,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "REGISTRAR",
    "actionid": 1561,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "DISTRIBUTOR",
    "actionid": 1561,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "SYSTEM_ADMINISTRATOR",
    "actionid": 1562,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "REGISTRAR",
    "actionid": 1562,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "DISTRIBUTOR",
    "actionid": 1562,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "SYSTEM_ADMINISTRATOR",
    "actionid": 1563,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "REGISTRAR",
    "actionid": 1563,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "DISTRIBUTOR",
    "actionid": 1563,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "SYSTEM_ADMINISTRATOR",
    "actionid": 1564,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "REGISTRAR",
    "actionid": 1564,
    "actioncode": "",
    "tenantId": "default"
},
{
    "rolecode": "DISTRIBUTOR",
    "actionid": 1564,
    "actioncode": "",
    "tenantId": "default"
},

Persister configuration

Indexer configuration

Database schema

Postman collection

Overview

The household service provides APIs to create households and household members for the HCM. This document provides the configuration details for setting up the household registry.

Pre-requisites

• Knowledge of Java/J2EE (preferably Java 8 version).

• Knowledge of spring boot and spring-boot micro-services.

• Knowledge of Git or any version control system.

• Knowledge of RESTful web services.

• Knowledge of the Lombok library is helpful.

• Knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-indexer, and eGov-user will be helpful.

Functionalities

1. Provides APIs to create, update, delete, and search households.

2. Provides APIs to bulk create, bulk update, and bulk delete households.

3. Provides APIs to create, update, delete, and search household members.

4. Provides APIs to bulk create, bulk update, and bulk delete household members.

Setup details

*In the case of IntelliJ, the plugin can be installed directly. For eclipse, the Lombok jar location has to be added in the eclipse.ini file in this format javaagent:lombok.jar.

API Details

Application.properties file information:

Kafka topics persister configs for eGov persister

URLs for the external API references:

Configuration details

Access MDMS configurations

Action test: URL actions adding

Access to role-based actions

Persister configuration

Indexer configuration

Database schema

Postman collection