1 of 100

v1.4

Introducing DIGIT Health

Mission

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

What are public health campaigns?

Health risks such as infectious diseases generally cannot be addressed at the individual and health worker levels alone. They require intervention at the policy level. This is where public health campaigns come into the picture.

Public health campaigns are specific, time-bound health services that respond to particular challenges and are provided to a target population by dedicated campaign workers. Such campaigns can influence perceptions, attitudes, and behaviors to achieve the desired goal. They can prevent or respond to disease outbreaks, control or eliminate targeted diseases, or achieve other health objectives. According to the World Health Organisation (WHO), two strains of wild poliovirus have “officially been certified as globally eradicated,” and immunisation campaigns have played a key role in this. Over the years campaigns to fight malaria, AIDS and other diseases have not only improved the lives of millions of people in poor and developing countries and disadvantaged communities, but it has also enabled them to lead more productive lives.

In 2019, 534 campaigns were tracked globally, providing vaccines, drugs, vitamins, and preventative tools for malaria, malnutrition, measles, meningitis, NTDs, polio, tetanus, typhoid, and yellow fever. However, by the end of 2020, an estimated 50% of the public health campaigns were postponed, suspended, or canceled due to the COVID-19 pandemic. This left millions of people and children at risk of vaccine-preventable diseases and malnutrition.

How can DIGIT HCM help?

As health campaigns catch up on missed vaccinations, drugs, and other preventative measures globally, there is an opportunity to reimagine the way countries can plan and implement campaigns through open-source digital platforms.

Today, digital tools are either free but not fit for purpose, or they do the job but cost a fortune due to repetitive work adding to the costs. Data is locked in silos and there is no operability between systems. These tools are also difficult to sustain and scale. These realities made it clear that isolated approaches cannot do the job.

Health campaigns require a holistic digital transformation. That's why DIGIT Health Campaign Management or DIGIT HCM was developed to address these challenges effectively.

DIGIT HCM is a free, fit-for-purpose, open-source, end-to-end health campaign digitisation product. It covers campaign setup, planning, registration, service delivery, inventory management, and real-time data dashboards, enabling faster and cost-effective health campaigns. DIGIT HCM is designed to evolve rapidly and adapt to local needs while addressing systemic challenges.

With DIGIT HCM, all programmes — whether for polio, malaria, or measles — are unified under a single, streamlined interface. This ensures that data flows seamlessly across different modules, improving data quality and accessibility.

The shared data repository within DIGIT HCM guarantees a “single source of truth,” maintaining high data quality. It offers easy integrations, seamlessly operating with open-source products, providing a unified system for health campaign management.

DIGIT HCM is designed with highly configurable, reusable modular building blocks, enabling rapid reconfiguration of the same product for different health campaigns. These modules can also be repurposed to develop new solutions for routine health, primary healthcare, and other areas.

More than just a product, DIGIT HCM is a comprehensive solution designed to streamline health campaigns, enhance coordination, and improve outcomes at every level of the health campaign management system.

Useful Links

Contact Us

Release Notes

Here are the articles in this section:

HCM v1.4 Release Notes

Release Summary

HCM v1.4 is a tech release with only server upgrade to DIGIT 2.9 LTS with some additional cleanup.

Features:

Digit core LTS integration
- MDMS v2 integration
- Boundary V2 integration
HCM Admin Console
DIGIT HCM app modules as package extractions

Functional Changes

Missing unique validation on client reference ID added in all offline supported services.
Project types have been moved to project additional details from MDMS.

Non-Functional Changes

UI modules extracted as packages
- Registration and delivery
- Referral reconciliation
- Inventory management
- Attendance management
- DIGIT scanner
- DIGIT showcase
All core services have been upgraded to core 2.9 LTS barring the services modified for offline use cases.
All data models have been restructured with an "is a relationship" from base eGov model and the base eGov search model.
All data models have been moved to the health common library and duplicates removed.
Removed reflection until code in the health common library that is Incompatible with Java 9 and above.

Breaking Changes

All the master data for the DIGIT HCM app are separated by functionality from one single master.
Flyway version upgrade to 9.22.3 for LTS upgrade.
Boundary v2 Integration

Migration from v1.3 to v1.4

The HCM v1.4 release required migration of the boundary and MDMS data if the server is not a fresh deployment but an existing v1.3 deployment

Boundary v2 migration

If the current environment has boundary data in MDMS v1 please follow the steps mention in the document below to migrate to boundary v2. Boundary migration from v1 to v2 LTS

MDMS v2 migration

If the environment is new the one click installer and data loader will by default load the data required.

If the Environment has pre existing data then the MDMS v2 migration tool should be run using the below document:

MDMS migration from v1 to V2 LTS

Following is the code link:

Code link for the above-mentioned migration utilities

Service Build Updates

Find the service build updates below:

HCM v1.4 Release chart

Release Checklist

v1.3 Release Notes

Release Summary

Health Campaign Management v1.3: The Frontline Worker’s App includes two new features that enable frontline teams to perform their tasks efficiently even when offline.

To learn more about the DIGIT Health Platform and the Health Campaign Management (HCM) product, click .

New Feature Additions

Localisation Keys

v1.3 Tech Release Summary

Impacted Services

Project:

Implemented validation for updating the project start date and the end date. Implementing this ensures that any changes made to these critical campaigns adhere to the predefined criteria.
Added the number of sessions field in additional details for the attendance registry, which enhances the system's ability to manage attendance tracking within projects. This field specifically denotes the frequency of attendance-taking sessions for a given project. Each session represents an instance where attendance is recorded, typically within a single day. For instance, if a project requires attendance twice daily (for example, morning and afternoon sessions), the number of sessions field would indicate ‘2’ to reflect this frequency. This information provides crucial context for understanding the attendance requirements and scheduling patterns within the project.

Individual:

Added the ability to search by user UUID (Universally Unique Identifier) for individual search. This addition expands the search capabilities within the DIGIT-HCM platform, providing users with a more versatile and efficient means of locating specific individuals. A UUID is a unique identifier assigned to each user within the system. This new feature allows users to quickly retrieve information about a particular individual by entering their UUID into the search functionality. By leveraging UUIDs, which ensure each user has a distinct identifier, the search process becomes highly precise and reliable, minimising the risk of ambiguity or confusion, particularly in large datasets.

Referral Management:

Health Facility Referral Feature Update

New Feature: HF Referral

DIGIT-HCM now includes a Health Facility Referral (HF Referral) functionality that enhances the platform’s capability to efficiently manage referrals across health facilities. This addition is aimed at improving coordination and communication, ensuring a smoother referral process.

Stock Registry:

Enhance the inventory flow with the sender ID and the receiver ID added. Including sender and receiver IDs offers flexibility in handling inventory transactions within the DIGIT-HCM platform. Transactions can involve movement between warehouses, from warehouse to staff, from staff to staff, or any combination thereof. This accommodates various scenarios, such as inter-departmental transfers, internal requisitions, or supplier deliveries.

Sender Identification: The sender ID specifies the entity initiating the inventory transaction. This could be a warehouse, indicating that inventory items are being dispatched from a specific storage location. Alternatively, it could represent an individual staff member responsible for authorising the transfer of inventory items.
Receiver Identification: The receiver ID denotes the entity or individual receiving the inventory items. Similar to the sender ID, this could represent either a warehouse where the items are being delivered or an individual staff member who is the designated recipient.

Attendance:

Implemented offline-enabled functionality in the Attendance Module. Implementing this functionality in the attendance module significantly enhances the usability and reliability of the DIGIT-HCM platform, especially in environments where internet connectivity may be intermittent or unavailable.

Master Data Management Service (MDMS) & Configuration Updates

MDMS

Config

Test Cases

HCM Test Cases v1.3

Service Build Updates

Category (Tag)

Services

Docker Artifact ID

Remarks

v1.2 Release Notes

Release Summary

Health Campaign Management v1.2: The frontline worker’s App includes 8 new features that allow the frontline teams to perform their tasks efficiently even when offline.

New Feature Additions

v1.0 Release Notes

Release Summary

The Health Campaign Management V1.0 frontline worker’s app includes four new modules with several features that allow frontline teams to perform their tasks efficiently even when offline. To learn more about the DIGIT Health Platform and the Health Campaign Management (HCM) product, please follow the

Release Highlights

Feature

Description

Bug Fixes (Feedback from the bug bash)

Click to access the Jira dashboard.

Known Issues

Field 'type' does not exist or this field cannot be viewed by anonymous users.
The field 'assignee' does not exist or this field cannot be viewed by anonymous users.
A value with ID '10141' does not exist for the field 'project'.
Field 'labels' do not exist or this field cannot be viewed by anonymous users.
The field 'priority' does not exist or this field cannot be viewed by anonymous users.
Not able to sort using field 'priority'.

Product Roadmap

Find the Product Capability Roadmap below:

To see a detailed version of this roadmap, click here.

HEALTH CAMPAIGN MANAGEMENT

Understanding DIGIT Health Campaign Management (HCM)

The DIGIT Health Campaign Management (HCM) aims to expand capabilities in public health. It covers campaign setup, planning, registration and delivery, inventory management, and real-time data dashboards enabling the establishment of digital public health infrastructure for faster and cost-effective health campaigns. DIGIT HCM is designed to evolve rapidly and adapt to local needs while addressing systematic challenges. It enables decision-makers and programme managers to streamline campaign planning, manage workflows and monitor service delivery in real-time to aid data-driven decision-making.

Why do we need DIGIT HCM?

Health campaigns are a commonly used strategy that helps the routine health system prevent or control diseases by delivering essential healthcare interventions in a time-bound manner.

Health campaign management faces several challenges, which include the inability to fetch accurate population targets or monitor the campaigns in real-time and tune the campaign to the defined population needs. Lack of timely and actionable data is often the primary cause of operational inefficiency. Additional concerns relate to siloed, redundant datasets adding to the implementation costs.

There is a need for a campaign management product that offers:

Single interface for managing all components in a campaign lifecycle
Allows reuse of assets across campaigns
Reduces fragmentation by supporting multiple diseases
Supports data interoperability with other health intervention areas (Eg. disease surveillance systems)
Improves sustainability by providing ownership and control to the government
Uses a modular and standards-based architecture

The goals include:

Increased campaign effectiveness (coverage)
Reduced time to respond to outbreaks
Improved efficiency (lower costs)
Increased transparency and accountability

Watch the video below to find out how DIGIT Health Campaign Management meets the above goals and more:

Reimagine Health Campaigns with DIGIT HCM

Setup campaigns in 3 days
Run hundreds of campaigns simultaneously
Record bednet delivery in 1 minute
Real-time campaign data dashboards
Interoperability with any system
Reusable campaign setup
Data privacy by maintaining control over data from day one

Value Proposition

A digital partner for the frontline workers:

Better user experience for frontline workers leads to better quality data captured in less time, thus facilitating improved efficiency
The ability for frontline workers to access on-demand training, and in-app guided walkthroughs, enabling improved efficiency
Ability to use geospatial tools to analyse and identify missed households. This leads to increased coverage and identification of fraud by frontline workers

Co-pilot for managers and supervisors:

Ability to reuse campaign data for planning and executing other campaigns leading to lower costs and lower turnaround time, leading to better estimation and planning
Provide visibility into stock availability and consumption data to enable supervisors to identify leakages/ wastages and avoid potential stock-outs
Track attendance based on task completion – this provides visibility into incentives due based on attendance, reducing ambiguity in payment amounts
Ability to leverage staff registry and attendance tracking to request and release digital payments to campaign staff

Digital headquarters for national health agencies:

Quick setup and launch
The dashboard provides the ability to view better quality data in near real-time that provides actionable insights
Quick and easy integration with existing platforms and systems such as supply chain, HRMS, LMIS, and DHIS2, facilitating interoperability and coordination at scale

Free & open-source software:

Countries own and evolve digit

HCM PRODUCT SUITE

Functional Specifications

Here are the articles in this section:

Draft System User Setup

Role Action Mapping

Inventory

Name of the field

Description

Mandatory

Input

Data type

Minimum length

Maximum length

Validation

Comments

Need data from program/state

Multi-Round Campaigns

Multi-round campaigns for health initiatives entail registering beneficiaries once, followed by interventions delivered in successive rounds at predefined intervals. Click on the link below to learn more:

Voucher-Based Registration and Distribution

An illustrative guide to using the Multi-Round Campaign Module

With the help of Voucher-Based Registration and Distribution, the registrar can use a QR code-based voucher provided by the program to link beneficiaries to the QR code voucher at the time of registration. This will enable distributors to search for beneficiaries at the time of delivery by scanning the QR code vouchers linked to a specific beneficiary.

Key Features

Allows a registrar to link a QR code voucher provided by the program to the beneficiary by scanning the QR code at the time of registration.
Allows a distributor to search for a beneficiary in the system by scanning the QR code voucher shown by the beneficiary when the Distributor has to deliver the drug.

User Roles

User Role

Scope of Action

Role Description

Steps to Register Using Voucher Based Registration and Distribution

User Role: Registrar

Step 1

Once the all the mandatory details for an individual are added on the Individual Details screen, you can link the QR code voucher by clicking on the "Link Voucher To Individual" button.

Step 2

The QR code scanner is launched and you can scan the unique QR code linked to the beneficiary. The "1 Resource Scanned" message will appear below the QR scanning panel.

If the QR code voucher scanning shows an error, you can link the voucher manually by clicking on the "Enter Beneficiary Code". The following screen appears, which lets you add the voucher code manually. Next, click on 'Submit' to link the code successfully to the beneficiary.

Step 3

The voucher will appear on the Individual Details page. If click on the 'Edit' button next to the voucher code, you redo step 2 and link the correct QR code voucher to the beneficiary. Click on 'Submit' after adding the correct voucher code for the beneficiary to link the Voucher to the Beneficiary in the database.

Step 4

You will be directed to the "Data Record Successfully" screen.

User Role: Distributor

After the registrations have been done and the respective QR code vouchers are linked to all beneficiaries, the distributors at the time of delivering the drug can search for beneficiaries using the QR code voucher associated to that beneficiary.

Step 1

Come to the "Search Individual" screen, and click on the "Scan QR Code" button.

Step 2

The QR code scanner will open up. Scan the voucher shown by the beneficiary and click on submit.

Step 3

If there is a user linked to the voucher scanned by the distributor, the details of the beneficiaries will appear on the "Individual Details" page. If not, a message will be shown saying "Match Not Found".

Step 4

If the beneficiary is found after scanning, you can open the record of the beneficiary and add the drug administration as per the regular flow.

REFERENCE IMPLEMENTATIONs

TECHNOLOGY

Health Facility Referral

An illustrative guide to using the Health Facility Referral Module

This will enable the health facility supervisors to track referrals made by on-field health workers to different health facilities digitally via the Digit HCM app

Key Features

It captures all the cases of:

Beneficiary being referred.
Referral details of the beneficiary.
Reason for referrals and its diagnosis.
Based on the diagnosis chosen further details if applicable.

User Roles

User Role

Scope of Action

Role Description

Using the Health Facility Referral Management Module

User Persona: This feature will be used by workers working at a given Health Facility (HF) who will be responsible for giving the diagnosis based on the type of symptoms they observe and then do a diagnosis and provide the appropriate drugs.

Steps for Referral Flows:

Step 1:

Login for a HF worker who will see the home screen options based on the role-action mapping and will see the option which says “Beneficiary Referral“. The options available on the home screen for HF workers apart from the Beneficiary Referral option will be defined based on the role-action mapping provided for them.

Step 2:

When the user clicks on the “Beneficiary Referral” button in the previous screen, the user will be taken to the “Search Beneficiary” screen where he/she can search for a given beneficiary by their name or a QR code voucher provided to the beneficiary.

Search Produces Result: If the user searches for a given beneficiary name and finds a match, he/she can click on the 'Open' button in the card for that beneficiary and view their details.

Search Does Not Produce Result: If the search does not provide any results, the user can click on the “Create New Referral" button to add a new entry under the Referral module.

Step 3:

Once the user creates a new referral or opens an existing one in the previous step, he/she is taken to the Facility Details screen first where he/she needs to enter the details of the health facility they are in to attend the beneficiary. This screen will have the following fields:

Administrative Unit: This field will be auto-filled from the value available from the role-action mapping, and will be non-editable.
Date of Evaluation: This field will be auto-filled with system value and will be non-editable.
Evaluation Facility: This will be a mandatory field for the health facility worker to search and add. It is the ID used for a given health facility.
Name of Health Facility Coordinator: This is a non-mandatory field that will capture the name of the health facility coordinator who is attending the referred beneficiary.
Referred By (CDD Team Code): This is a non-mandatory field that will capture the CDD team code of the field worker who referred the beneficiary.

Once the user has filled all the fields with the relevant information, he/she must click on the 'Next' button.

Step 4:

After the user has clicked on submit, he/she will come to the screen called “Referral Details”. On this screen, the user is supposed to enter details into sections, that is, “Referral Details” and “What is the reason for referral”.

Section 1: Referral Details

In this section, the user must add the details to the following fields:

Select Cycle: This will be a dropdown selector which will have the cycle numbers. This is a mandatory field and cannot be left empty.
Name of the child: The user needs to add the name of the referred beneficiary. This field is mandatory.
Beneficiary ID: This will be added by the user with the beneficiary ID of the referred Beneficiary. This is a mandatory field.
Age in Months: This will be a mandatory field that will capture the age of the beneficiary being referred in months.
Gender: This is a mandatory field with a dropdown having values: Male, Female, Other.

Section 2: Reason for Referral

In this section, the user must capture the data as to why the beneficiary was referred. The field will capture data with the help of the radio button option selector. The options are:

Sick
Fever
Drug side effect in current cycle
Drug side effect in previous cycle

After selecting one of the reasons for referral, the user needs to press 'Next' which will navigate the user to 3 different screens based on what they select in the “Reason for Referral” section.

Step 5:

Based on what the user selects in the previous step in the “Reason for Referral” section, the following 3 flows could be shown to the user:

If “Sick” was chosen as a reason: If the user selects 'Sick' as the reason for eeferral in Step 4, he/she will be taken to “Referral Due to Illness” screen, where he/she will see the following list of questions:
- “Child evaluated to determine cause of illness”: This will be a mandatory question to be answered with 2 options in the form of a radio button: Yes or No.
- Enter Comment for Diagnosis: The answer to this question should be entered by the user in a free text form which will be a mandatory field.
- “Was the Child Treated?”: This question will be answered by the user using a radio button option of 'Yes' or 'No', and it will be a mandatory question
- Name and Dose of the Drug: Provide an open text field that will be mandatory.
- “Was the child admitted / transferred to the hospital due to serious illness?”: This question will have a Yes/No radio button selection for it. This is a mandatory field.

If “Fever” was chosen as a reason: If the user selects 'Fever' as the reason for referral in Step 4, the user will be taken to the “Referral Due to Fever” screen, where he/she will see the following list of questions:
- “Was the child tested for malaria?”: This question will have a Yes/No radio button option. This will be a mandatory field.
- “Result of Malaria Diagnostic Test? “: This will be a mandatory field and based on what the user answers to this question the next set of questions for the user will open up as a nested form.
  - If the user chooses 'Positive' as the answer for “Result of Malaria Diagnostic Test? then he/shewill see the following questions:
    Was the child admitted/transferred to the hospital due to serious illness?: This will be answered with a simple Yes/No radio button and will be a mandatory field.
    Child with positive malaria test treated with anti-malarial?: This will be answered with a simple Yes/No radio button and will be a mandatory field.
    Name and Dose of Anti Malarial: This will be answered with an open text form and will be a mandatory field.
  - If the user chooses “Negative” for “Result of Malaria Diagnostic Test?, then he/she will see the following questions as a nested fForm:
    “Child with negative malaria test received SPAQ in this cycle“: This will be a Yes/No Radio button question, and is a non-mandatory field.
If “Drug side effect in current/previous cycle” was chosen as a reason: If the user selects “Drug side effect in current/previous cycle” as the reason for referral in Step 4, he/she will be taken to the“Referral due to adverse drug reaction” screen, where he/she will see the following list of questions:
- Child evaluated for adverse reaction for SP and AQ?: This will be a simple Yes/No radio button in the form and it will not be a mandatory field.
- The National Pharmacovigilance has been filled out?: This will be a simple Yes/No radio button in the form, and it will not be a mandatory field.
- Was the child admitted/transferred to the hospital due to serious illness?: This will be a simple Yes/No radio button in the form, and it will not be a mandatory field.

Once all the questions in one of these flows are answered, a pop-up frame asking for confirmation will be shown for submission as shown below:

Once the user clicks on submit, he/she will see the ”Data Recorded Successfully” screen, and the option to navigate to the home screen.

Resolving Complaints

An illustrative guide to using the Complaints Module (Mobile and Web)

There is a support helpdesk set up by the program which will receive all complaints raised by system users. The support helpdesk is responsible for reviewing all the complaints in the inbox. Depending on the complaint, the helpdesk can either resolve, reject, or assign the complaint to the respective actor Helpdesk users may create complaints on the user’s behalf, which are received over call/WhatsApp messages.

User Roles

User Role

Scope of Action

Role Description

Resolving Complaints

Resolving a complaint (Mobile App View)

Helpdesk

The L1 support helpdesk must be the first point in the complaint management workflow. All complaints created must be first routed to the helpdesk, after which the helpdesk may take appropriate action (mentioned below).

The helpdesk user must be able to do the following :

View the list of complaints in the inbox
File a new complaint
Open a complaint from the inbox and

View complaints status

Resolve a complaint

Reject a complaint

Assign to other roles

The inbox view for other workflow states must be similar and must be able to view complaints assigned to their respective inbox. The user must also have the option to assign the complaint back to the L1 support helpdesk by selecting the value in the “Assign To” field. The users must be able to view complaints that have been assigned to their role. For example, the L1 helpdesk user must not be able to view complaints assigned to the L2 helpdesk and vice versa.

Filters The user can apply filters in multiple parameters as follows:

Complaint Type: The user can select the complaint type from the dropdown
Administrative Area: The area of complaint.
Status: Refer to the list of statuses detailed above.

A button to clean all filters must be available at the bottom of the page. An “Apply Filter” button must be available to set the filters and route the user to the inbox and display the filtered complaints.

Search By

A user must be able to search for one or more complaints by using the following search parameters (must support passing multiple search parameters):

Complaint Number
Mobile Number
Administrative Area

After providing the appropriate search parameters, the user must click on the “Search” button located at the bottom of the screen and must be routed to the inbox which displays the search-appropriate search results.

Complaint Summary

A summary screen must be displayed when the user clicks on the ‘Open’ button located on the complaints card.

Actions

The “Take Action” button at the bottom of the screen must open a pop-up displaying all possible actions that the user can take. The actions available to address the complaint are as follows:

Resolve Complaint
Assign to P2
Reject Complaint
Close

The close button collapses the overlay and takes the user back to the complaints summary screen.

Assign Complaint

If the user wants to assign any project to P2, she must click on the assign button which opens this screen. The date of assigning the complaint is user input which can be filled in with the help of the calendar icon within the field.

In the "assigned to" field, the user needs to select the person to whom she wants to assign that complaint. There is an additional comments field in which the user can provide any remarks if she wants. The user can attach any supporting documents such as photos, documents, etc.

At the bottom, there is a cancel button which takes the user back to the complaint summary screen, and an assign button which assigns the complaint to the selected person.

Confirmation Screen

Landing Page (Common page)

Helpdesk (Desktop View)

When the user clicks on complaints on the home screen, then this screen must appear. On the top left, there is an option to file a new complaint, view reports. Besides, there are search fields for different parameters, such as complaint number and mobile number, and the search button to execute the search action. There is a clear search button below the search one if the user wants to clear the search parameters.

Below the new complaint and reports buttons, there are filters available to apply over the results. The filter parameters are the same as that for the mobile view.

The complaints are displayed in a horizontal format with the same values for mobile view. The user can click on the entire area of a particular complaint.

At the bottom, there are forward, backward, first page, and last page arrow buttons along with the page number information as displayed on the screen.

Complaint Details

When the user clicks on a complaint, the details screen appears which provides the entire information of that complaint. The summary includes the same information mentioned in the card along with the additional comments/remarks, and photos provided by the complainant.

There is a "Take Action" button at the bottom. When the user clicks on it, the actions appear above the button as displayed on the screen. The actions include resolve complaint, assign to P2, and reject complaint. If the user clicks on any blank area on the screen, the actions collapse.

Resolve Complaint

If the complaint has been resolved, then the user must click on the "Resolve Complaint" button which opens this screen. There is an "Additional Comments" field in which the user can provide any remarks if he wants. At the bottom, there is a submit button that updates the complaint status as resolved.

Reject Complaint

If the user has rejected any complaint, then she needs to select the reason for rejection from the dropdown. There is an additional comments field in which the user can provide any remarks if he wants. At the bottom, there is a submit button that updates the complaint status as rejected.

Assign to P2

In the assigned to field, the user needs to select the person to whom she wants to assign that complaint.

There is an additional comments field in which the user can provide any remarks if he wants. The user can attach any supporting documents such as photos, documents, etc.

At the bottom, there is a cancel button which takes the user back to the complaints screen, and an assign button which assigns the complaint to the selected person.

Confirmation Screen

New Complaint

When the user clicks on the “New Complaint” button on the complaints screen, then this screen appears. The details captured are the same as that entered by the complainant. When the details are entered, the user needs to click on the submit button which opens the confirmation window over the same screen. If the user clicks on the cancel button, then she is navigated back to the complaints screen

Confirmation Screen

When the user clicks on the submit button, the system confirms whether the complaint has been submitted successfully or not. There is a back to home button placed on both screens, clicking on which will navigate the user to the home screen of the helpdesk.

LLIN Overview

Overview

The National Malaria Control Program (NMCP) transitioned to a digital system for their bed net distribution campaign in 2022/2023, moving away from their previous paper-based method. However, the team faced numerous issues with the new tool, such as synchronisation errors, data quality issues, inadequate visualization and analysis of geolocation data, and ineffective bednet tracking during the campaign.

To address these challenges, NMCP partnered with eGov to develop DIGIT HCM, a Digital public infrastructure. This collaborative effort resulted in the creation of an open-source digital public infrastructure (DPI) with interoperability and scalability. Customised as Salama (implying health in Swahili), the aim was to mitigate the above challenges and support multiple campaigns efficiently.

Salama and LLIN

Salama was rolled out as part of the Long Lasting Insecticidal Nets (LLIN) campaign for the periodic distribution of bednets in the Tete and Gaza provinces.

The main players involved in the campaigns in Tete and Gaza are listed below:

National Malaria Control Program, Mozambique: Provided overall strategic direction for the campaign, part of the Ministry of Health (MISAU).
DIS (Information System Directorate): Provided support during the requirements discussion and the implementation of the campaigns, part of MISAU.
DTIC (Information Technology and Communication Directorate): Technical team that was trained and helped manage technical training and issues during the campaign, part of MISAU.
World Vision: Implementation Partner for the BedNet campaign in Tete and Gaza.
Bill and Melinda Gates Foundation: Funder of the DIGIT HCM platform.
The Global Fund: Funds campaign implementation across Africa.

The other partners include PNCM, World Vision, the Foundation for Community Development (FDC), Food for The Hungry Association (FHA), Aid for Develop.

Besides the different players mentioned above, a core group called Nucleo Duro, consisting of members from all groups was formed to lead all decision-making aspects of campaign implementation and digitisation.

Lessons learned from the Tete implementation spurred enhancements in Gaza, and underscored the flexibility of Salama. NMCP successfully conducted campaigns with reduced eGov assistance and effectively addressed many campaign-related issues. During the campaign, NMCP noted that the platform was user-friendly for registrars, and the dashboard's clear presentation negated the need to work on different formats in M&E meetings. Notable improvements in the Gaza campaign encompassed enhanced real-time syncing efficiency, prompt access to team performance reports, and a significant decrease in incomplete records.

Key Takeaways from Salama Implementation

The NMCP highlighted the points listed below as things that went well while implementing DIGIT HCM (SALAMA):

Automatic synchronisation in areas with internet connectivity: The Salama application has enabled automatic synchronisation in intervals of 5 minutes, which resulted in near real-time data synchronisation in areas with internet connectivity. This was observed during the campaign in Gaza.
Ability to check teams' progress against daily targets: In the application, there is a progress bar that each team can use to verify their progress when compared to the target. This feature was appreciated by NMCP as it gave the local monitors the ability to check the targets and motivate the teams to achieve at least the daily target.
Automatic collection of GPS data on each Household registered: The collection of GPS coordinates for a household is done in the background of the application. Whenever a household is registered, the registrar does not have to click any button to initiate the capture of geo coordinates. This made the user experience for registrators better and was in turn well received by NMCP.
Dashboard was flexible, interactive, and user-friendly: The dashboard was used in the daily review meetings as the main monitoring and evaluation tool and saved time as it was not necessary to develop a PowerPoint presentation for those meetings.
Automatic calculation of the bednets to be delivered: The application was able to recommend the number of bednets to be delivered to a household based on the number of members, which removed the cognitive effort of the registrar to calculate these numbers by themselves.
Indication of duplications at the end of the day: The custom reports generated at the end of the day indicated duplications of registration and delivery, It further provided details of duplicate households created by the same registrar and the ones duplicated by different registrars.
Application easy to learn: During the training, it was noticed that it took less time for the trainees to understand the application and flows. Thus, the training was more practical and focused on simulation-based learning rather than on training the users on how to use the applications.

Throughout the campaign, numerous training sessions were conducted to enhance the capacity of NMCP in managing and utilising Salama, with additional capacity-building activities scheduled for post-campaign implementation. Key recommendations include linking credentials to performance, enhancing microplan estimates, improving warehouse manager training, addressing bed net scanning issues, and shifting the focus to monitoring and correcting supervision results.

In summary, the successful digitalization of Tete and Gaza using Salama facilitated accomplishing essential campaign objectives. While recognising areas for improvement, the standardised data format enabled thorough analysis across campaigns, ensuring ongoing enhancement in effectiveness and efficiency.

Health Campaign System High Level Design

Health Campaign - High Level Design

The high level design is divided into:

Master data
Registries/entities
Reusable DIGIT services
Form engine support
Multi-tenancy
Android offline first app
Web app - Campaign planning + dashboard
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.

Simple Masters
1. Roles
2. Additional field schemas for different entities
3. Project task configurations
4. Project type
5. Role-actions
6. Actions
Hierarchical Masters
1. Administrative boundary and hierarchy
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.

Standards

Overview

Global standards vary from stakeholder natures, functioning, and deliverables. The core agenda of this exercise was to find a few globally certified standards in the DPP space that fit each of these roles:

Product owner: A product owner is an entity that owns, governs, or controls the product's codebase. They are responsible for its architecture design, roadmap, and versions.
Implementing agencies: An agency that deploys and configures a product for the program owner is an implementing agency (IA).
Programme owners: A “programme owner” is an entity responsible for delivering specific public goods, services, or social welfare. A Program owner is usually a government entity.

Global Standards For All

Product Owner

Depending on the nature of the work, the product owner undertakes the NIST Privacy Framework as a direction for standardisation.

What is it?

The privacy framework comprises three parts: Core, profiles, and implementation tiers.
Each component reinforces privacy risk management by connecting business and mission drivers, organisational roles and responsibilities, and privacy protection activities.
The core enables a dialogue — from the executive level to the implementation/operations level — about important privacy protection activities and desired outcomes.
Profiles enable the prioritisation of the outcomes and activities that best meet organisational privacy values, mission or business needs, and risks.
Implementation tiers support decision-making and communication about the sufficiency of organisational processes and resources to manage privacy risk.

The advantages of NIST are:

It pushes for privacy engineering functions to be embedded in the design of the software.
It promotes transparency as the guidelines are communicated to implementing agencies (IAs) and programme owners.
It enhances trust as it encourages proactive privacy measures to be taken from the design stage itself.
It streamlines operations by embedding privacy into the functional and design practices, avoiding costly retroactive changes.

Implementing Agencies/Programme Owners

An IA’s core responsibility is to deploy the product. Its functions require hands-on functions of customisation, configuration, training, and support. The IA ideally has complete access to the data of citizens. For an IA getting certified under ISO 27701 is recommended. This certification requires a certification to ISO 27001 as a first step.

Why ISO 27701?

The upcoming Digital Personal Data Protection Bill will require companies that are eligible to be an IA to undergo steps similar to those in ISO 27701.

The steps/key components of ISO 27701's Privacy Information Management System (PIMS) are:

Privacy risk management: ISO 27701 will require an IA to identify and assess privacy risks associated with the processing of Personally Identifiable Information (PII) and implement appropriate controls to mitigate these risks.
Privacy policy and procedures: ISO 27701 requires an IA to develop and implement privacy policies and procedures that are aligned with the administering authority’s overall information security policies and procedures.
Data subject rights: ISO 27701 requires the IA to establish procedures for handling data subject requests, such as access, rectification, and erasure of personal data. With such a feature embedded, the citizens would be allowed to exercise their right to privacy.
Privacy training and awareness: ISO 27701 requires an IA to provide privacy training and awareness programs to employees and other stakeholders to ensure that they understand their roles and responsibilities in protecting PII.
Incident management: ISO 27701 requires an IA to establish procedures for managing privacy incidents, including breach notification, investigation, and remediation.
Third-party management: ISO 27701 requires an IA to establish procedures for managing third-party relationships that involve the processing of PII, including due diligence, contract management, and monitoring.
Assurance: ISO 27701 assures senior members of administrative authorities, and other stakeholders, such as citizens and partners that the organisation is committed to protecting Personally Identifiable Information (PII) and has implemented international best practices for privacy management.
Trust: ISO 27701 can help organizations build trust with stakeholders by providing tangible evidence of their commitment to protecting PII.
Compliance: ISO 27701 supports compliance with globally recognised data protection and privacy regulations such as GDPR, CCPA, and others.
Risk management: ISO 27701 helps the IA identify and mitigate privacy risks, reducing the likelihood of data breaches, reputational damage, and financial losses.
Global standard: ISO 27701 is a respected global standard for privacy information management and can be used by agencies of all sizes and from all sectors.
Integration: ISO 27701 is an extension of ISO 27001, meaning it can be integrated with an existing Information Security Management System (ISMS) to enhance privacy management and compliance efforts.

In conclusion, by getting certified under ISO 27701, implementing agencies can demonstrate their commitment to protecting PII, build trust with stakeholders, comply with data protection and privacy regulations, and improve their privacy risk management efforts.

Field App Architecture

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

Needs to work in low/no network coverage areas.
Needs to have a high level of configurability.
Needs to work on Android.
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:

If the app has to run in an offline first mode or an online mode.
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.
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).
Values/options that need to be displayed in various fields in the app.
Additional fields are to be captured for any of the entities, if any.
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

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.

Beneficiary Refused: Indicates that the beneficiary refused to accept the delivery in the current cycle.
Beneficiary Referred: Indicates that the beneficiary was referred to a health facility during the current cycle.
Visited: Indicates that a delivery was successfully made for the beneficiary in the current cycle.
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

Security

Data Protection & Privacy Definitions

1. Data

Data is any information shared by citizens or received from existing databases to enable government service delivery and government operations. It could be name, address, mobile number, age, etc.

Under the Indian law, the current Digital Personal Data Act of 2023 defines data as:

Sec 2(h) - ‘Data’ means a representation of information, facts, concepts, opinions, or instructions in a manner suitable for communication, interpretation, or processing by human beings or by automated means.

It is similar to what is defined as ‘data’ in the Information Technology Act of 2000:

a representation of information, knowledge, facts, concepts or instructions which are being prepared or have been prepared in a formalized manner and are intended to be processed, is being processed or has been processed in a computer system or computer network, and may be in any form (including computer printouts magnetic or optical storage media, punched cards, punched tapes) or stored internally in the memory of the computer.

1a) Personal Data or Personally Identifiable Information (PII)

For this document, PII and personal data are to mean the same.

Personal data is defined under the Digital Personal Data Act,2023 as:

Sec 2 (t) - “Personal data” means any data about an individual who is identifiable by or about such data;

To add, a breach of personal data is also defined in Section 2 (u) as -:

“Personal data breach” means any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data;

is “any data that allows one to be recognised either directly or indirectly. It is defined as any information that relates to a natural person, which, either directly or indirectly, in combination with other information available or likely to be available with a body corporate, is capable of identifying such a person.”

Both the above definitions of personal data are to be read together until the government fixates on maintaining one.

1b) Sensitive Personal Data (SPD)

Sensitive Personal data of a person means “...such personal information which consists of information relating to:

password;
financial information such as Bank account, credit card, debit card or any other payment instrument details;
physical, physiological and mental health conditions;
sexual orientation;
medical records and history;
biometric information;
any detail relating to the above clauses as provided to the body corporate for providing service;
and any of the information received under the above clauses by the body corporate for processing, stored or processed under lawful contract or otherwise

Provided that, any information that is freely available or accessible in the public domain or furnished under the Right to Information Act, 2005 or any other law for the time being in force shall not be regarded as sensitive personal data or information[...].”

2. Product Implementation Cycle

2a) Product

For this document, ‘product’ refers to any software system that can be used by a government entity, or by a contractor performing any tasks on behalf of that government entity. The term ‘product’ refers to the software (code) itself, and NOT to any implementation of that code. Therefore, a product does not collect, store, process, use, or share data.

2b) Product Implementation

For this document, “product Implementation” refers to each instance of a product/software system that has been implemented.

During the implementation of a product, the implementing agency may collect, store, process, use, and share such data as is necessary for implementing the product. This will normally be specified in the contract or agreement between the implementing agency and the administrative authority responsible for that implementation.

After the implementation of a product is complete, the implementing agency should cease to have access to data from the product implementation, except to such extent as may be agreed between the implementing agency and the administrative authority responsible for that implementation.

In cases where the implementing agency performs the role of a support agency concerning any product implementation, the implementing agency may have access to data as specified for that role. The activity of product implementation involves roles having access to datasets flowing through the product.

For example, Salama (in Mozambique) is the product implementation – It is an implementation of the DIGIT-HCM product.

2c) Programme

Any ongoing or to-be-executed delivery of government service or defined government operation is a programme.

During the operation of a programme, the programme owner (and its staff and contractors) will collect, store, process, use, and share such data as is necessary for performing their tasks, and/or which they are required to do under prevailing law.

For example, a programme is one in which ULBs in Punjab use the MSeva product to collect revenues, deliver ULB services, and redress grievances.

2d) Summary & Comparison of Product, Product Implementation, & Programme

2e) Product Implementation Stages

We describe a product implementation as progressing across 7 stages:

3. Roles

3a) Product Owner (PO)

For this document, a product owner is an entity that owns, governs, or controls the product's codebase. They are responsible for its architecture design, roadmap, and versions.

As a product is a code that has NOT been implemented, a product owner has no access to data.

When a product is implemented, becoming a product implementation, the product owner may have access to such data as is being collected, stored, processed, used, or shared by that product implementation as may be agreed upon by the product owner and the administrative authority responsible for that implementation.

In cases where a product owner performs the roles of an implementing agency or support agency concerning any product implementation, the product owner may have access to data as specified for those roles (see below).

For example, eGovernments Foundation is a product owner.

3b) Implementing Agency (IA)

An agency that deploys and configures a product for the administrative authority or program owner (see below) is an implementing agency (IA). An IA may:

set up the hardware necessary for the programme;
customise, extend, configure, and install/set up the software (product) as per the needs of the programme owner;
train staff or contractors of the program owner on how to use the product;
Perform other such functions to ensure program readiness as may be agreed upon between the implementing agency and the program owner and/or administrative authority responsible for such product implementation.

During the implementation of a product, the implementing agency may collect, store, process, use, and share such data as is necessary for implementing the product. This will normally be specified in the contract or agreement between the implementing agency and the administrative authority responsible for that implementation.

In cases where the implementing agency performs the role of a support agency concerning any product implementation, the implementing agency may have access to data as specified for that role (see below).

For example, if a given state government signs a contract with “Company L” to implement the DIGIT-HCM product in that state, Company L is an IA.

3c) Programme Owner (Prog)

For this document, a “programme owner” is the entity responsible for delivering specific public goods, services, or social welfare. A program owner is usually a government entity (though they may contract private entities to perform some or all of these tasks on their behalf).

In the context of a product implementation, the program owner is the primary client of the implementing agency, as they will use the product implementation to perform their tasks.

A programme owner (and its staff and contractors) will collect, store, process, use, and share such data as is necessary for performing their tasks, and/or which they are required to do under prevailing law.

A programme owner has primary responsibility for ensuring that all relevant legal provisions and good practices concerning data security, data protection, and privacy are being followed in its programs.

A programme owner may perform the roles of implementing agency and/or support agency or may contract those roles out to third-party implementing agencies and support agencies respectively. If they are performing these roles, they will have access to such data as is specified for these roles.

A programme owner is typically subordinate to the administrative authority in the official/administrative hierarchy. It is also possible that the administrative authority and program owner are the same entity.

For example, if a government has initiated a program to use the DIGIT-HCM product to reform Health Campaign Management, the respective department that is running the programme will be the programme owner.

3d) Support Agency (SA)

For this document, a “Support Agency” provides support in any functional aspect required by the program owner concerning that product implementation (for example, assistance in the maintenance of the product, technical or operational problem-solving, bug/error resolution).

A support agency would normally be engaged once the product has gone live, that is, during stages 5 and/or 6 of product implementation (see above).

A support agency will have access to such data as is necessary to perform their functions, and this shall normally be specified in the agreement/contract between the supporting agency and the programme owner/administrative authority responsible for that product implementation / the implementing agency responsible for that product implementation (in cases where the implementing agency sub-contracts support functions to the supporting agency).

In cases where a product owner, implementing agency, or program owner performs the role of a support agency, they may have access to such data as is specified for that role.

For example, suppose a given state government signs a contract with “Company L” to implement the DIGIT-HCM product in that state. In that case, and Company L sub-contracts support/maintenance/helpdesk activities to “Company M”, Company M is an IA.

3e) Administrative Authority (AA)

For this document, an administrative authority (AA) is a government entity that has the authority to enter into contracts/agreements with the product owner, implementing agency, and supporting agency.

Under prevailing law, an administrative authority has the power to permit other entities to access (collect, store, process, use, and/or share) data, including the PII of individuals within the territorial jurisdiction of that AA.

For this document, a product owner, implementing agency, or supporting agency cannot access data unless authorised to do so by the administrative authority. Such authorisation may be specified in an agreement/contract between the administrative authority and these entities. Such authorisation must be in keeping with prevailing laws and shall include such provisions and safeguards as are required under prevailing law.

An administrative authority may be a programme owner or maybe a superior agency of a program owner in the administrative hierarchy.

For example, when a given state government decides to implement the DIGIT-HCM product in that state, the specific department of that state government which signs MOUs and/or contracts with eGov Foundation (as product owner), and with an IA to implement the DIGIT-HCM product, is an AA.