Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Help countries achieve Health SDGs by building digital public goods that strengthen public health.
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.
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 program.
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 programs.
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 programs. 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.
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.
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
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.
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 program-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.
The platform is designed to facilitate stakeholders with a digital system to manage and implement health campaign activities in Mozambique. Click to know more.
The articles in this section includes:
The articles in this section include:
The detailed mapping of DIGIT’s capabilities with the core requirements mentioned in the NUIS digital blueprint has been done below:
Interoperability
DIGIT is designed as an API-first platform and with open APIs and open standard interoperability is maintained.
Along with this, taxonomies are available for the key domain entities/registries on DIGIT.
Data privacy and security by design
Data privacy and security design are a critical part of the design of DIGIT.
Core service layer of DIGIT includes a signing and encryption service that provides capabilities to sign/encrypt/mask sensitive data.
Appropriate access controls can be defined in the APIs to ensure authorised access to sensitive data.
Transparency and accountability through data
DIGIT has
The capability to define registries, preferably through standard specifications like OpenAPI 3.0.
The capability to configure registry attributes for security and protection as per the configuration.
Mechanisms to verify data and its provenance through audit logs (access and change logs), preferably through APIs.
Reusability and Extensibility
The DIGIT platform is designed as a collection of over 55-plus atomic micro-services which are bundled together in a given context to provide an end solution.
DIGIT allows the extension of existing capabilities without needing architectural interventions.
Components are designed to be independently reusable without any tight coupling.
Evolvability and Scale
On DIGIT:
Capabilities can be added without needing an overall system re-architecture.
Individual components can evolve separately to enable the heterogeneous evolution of the system.
Scaling can be done horizontally to handle changes in request volumes.
Individual components can be scaled independent of each other to enable efficient resource utilisation.
Multi-channel access
DIGIT allows multiple channels of solution delivery: ULB counters, web portals, mobile app, WhatsApp Chatbot and third party applications like Paytm, tablets, etc.
DIGIT’s access control mechanism can be configured to provide different levels of access based on channels and roles.
Ecosystem-driven
DIGIT leverages open source technologies to reduce the cost of solutions.
Leverages or integrates with, or extends existing platforms/stacks such as IndiaStack, IUDX, ICTRA infrastructure, etc.
Provides the capability to gather feedback from the ecosystem in a digital manner.
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 3 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 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.
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 perimeter control at its API gateway layer to ensure that unauthorised calls are not allowed to even 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
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 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.
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, 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.
A new functionality can be added by rebundling existing building blocks in the context of new use cases and implementing only additionally-required services without requiring any architectural overhaul. Additionally, due to its loosely coupled API-driven design, DIGIT allows for new components to be implemented in the technology that is most useful for that use case. The API-driven, micro-services-based architecture of DIGIT enables its components to evolve separately. On DIGIT, individual components can evolve separately to enable the heterogeneous evolution of the system. DIGIT uses SemVer 2.0 for the versioning of its micro-services and interfaces. Semantic versioning is a formal convention for specifying compatibility using a three-part version number: major version; minor version; and patch. More details on this can be found on this link: https://semver.org/. DIGIT is designed to be horizontally scalable. The microservices-based architecture of DIGIT also enables it to scale only needed components/services, thereby providing resource efficiency. For example, the billing and collection services can be scaled separately during a financial year closing if the load pattern indicates increasing volume of bill payments during that period. DIGIT is designed to be hardwarec agnostic and can be run on any hardware. It has been tested on multiple commercial clouds and state-sponsored bare metal infrastructure. Components of DIGIT that need to use underlying hardware have been carefully chosen (in case where DIGIT is using other open source components) or designed (DIGIT’s own components) to provide a layer of abstraction that can be extended for any types of hardware.
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.
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.
DIGIT is an open-source platform licensed under the MIT license () compliant with the NUIS digital blueprint.
Click to learn more about the Master Data Management Service, and configure it.
DIGIT is India’s largest open-source platform for digital governance. The health services are built on top of DIGIT. It is built on OpenAPI (OAS 2.0) and provides API-based access to a variety of services, enabling governments to provide health campaign services with relevant new ones. It also facilitates integration with the existing system into the platform and runs seamlessly on any commercial/on-prem cloud infrastructure with scale and speed.
Health DIGIT is a micro-services-based platform that is built to scale. Micro-services are small, autonomous, and developer-friendly services that work together.
It facilitates decentralised control between teams so that its developers strive to produce useful tools that can then be used by others to solve the same problems.
Micro-services have smart endpoints that process information and apply logic. They receive requests, process them, and generate a response accordingly.
Parallelism in development: Micro-services architectures are mainly business-centric.
A big software or system can be broken down into multiple small components or services. These components can be designed, developed, and deployed independently without compromising the integrity of the application.
DIGIT Health follows a multi-layer or n-tiered distributed architecture pattern. As seen in the illustration above, there are different horizontal layers with some set of components such as Services, Registries and DIGIT Core Services. Every layer consists of a set of micro-services. Each layer of the layered architecture pattern has a specific role and responsibility within the application. The following are the advantages:
Layered architecture increases flexibility, maintainability, and scalability.
Multiple applications can reuse the components.
Parallelism.
Different components of the application can be independently deployed, maintained, and updated, on different time schedules.
Layered architecture also makes it possible to configure different levels of security to different components.
Layered architecture also helps users test the components independent of each other.
HCM 1.0 is a base version release that has functional and non-functional requirements:
Functional: Built new registries: Individual, Household, Facility and Product. The release also has services: Project and Stock
Non-functional: The services support bulk and non-bulk APIs which can be used in online and offline modes for the HCM app.
Registries & services
Individual, household, facility and product registries, as well as product, and stock services through standard specifications like OpenAPI 3.0. They have been integrated with the DIGIT platform.
HCM app
The health campaign Android mobile app built on Flutter.
Infra/ops simplification & enablement
HCM, DIGIT service monitoring.
All Java-based services with SpringBoot version 2.2.6 for better security, performance, and metrics.
Helm templates to ease deployment on Kubernetes.
UI technical documents
Backend service documents
Infra/deployment documents
Note: Check the for more details.
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 categorized on the complexity required to maintain them from the technical perspective.
Simple Masters
Roles
Additional Field schemas for different entities
Project Task configurations
Project Type
Role-Actions
Actions
Hierarchical Masters
Administrative Boundary and Hierarchy
Inter linking Masters
Field app config
Service 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.
New service
Collection of Individuals living together (potentially receiving shared campaign intervention)
New service
Needed to model storage Warehouses through which stock moves.
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.
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.
New service
Track inflow and outflow of stock resources
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-mdms-service
Digit-location / boundary service
digit-access-control
Zuul API Gateway
digit-idgen
digit-persister
digit-indexer
digit-localization
DSS
Signed Audit
No existing services being enhanced.
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).
Form engine support was pushing out timelines and has been dropped from v1 scope.
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 is proposed to be modeled on mGramSeva app and will be built in Flutter.
This app will be used in areas with limited or no internet connectivity and hence will need to work while offline. Users will sync the data collected offline when they are in an area with network connectivity.
SQLite will be used to model structured data and ISAR will be used for unstructured data.
Out of scope for v1.
The field workers will need to see dashboards based on the data stored in the offline database. Library - TBD
Out of scope for v1.
The app will have some custom screens to capture information around the campaign plan.
DSS dashboards are planned to be leveraged for reporting dashboards.
This will be added to implementation scope.
Here are the articles in this section:
Timelines
Q2 2023 (w/c May15, 2023): Field testing
TBD: Tentative - 2023-end.
Tentative Q1 24
Value bundle
Value delivered
Feature list
Feature list
Feature list
Feature list
Campaign setup
Enable system administrators and program managers to set up the platform quickly, easily configure roles and role-based permissions, update master data, and manage users.
1. Campaign manager: Create and update campaigns (single round campaigns). 2. User management with UI. 3. Out-of-the-box standard dashboards.
1. Campaign manager with support for multi-round campaigns. 2. Forms engine.
1. Campaign manager with UI. 2. UI for setting up custom dashboards. 3. Forms designer with UI.
1. Mobile Device Management
Service delivery
Mobile app with a user-friendly design and easy, intuitive navigation. This will guide the field teams to easily register eligible beneficiaries, and deliver the healthcare intervention with built-in checks that enforce data collection protocols and validations to avoid data entry errors.
1. Register new households and individuals. 2. Search registered beneficiaries from the list. 3. Update service delivery information against a beneficiary. 4. Decision support for the resource delivery of LLIN's. 5. Creation of household and individual registries. 6. Re-use beneficiary data from the registries.
1. Proximity-based search using GIS map on the mobile app. 2. Routing assistance to locate beneficiaries. 3. Support voucher generation and scanning for tracking service delivery. 4. Last-mile delivery tracking: Record stock received from the warehouse for delivery. 5. Adverse events reporting. 6. Enhance decision support logic for MDA campaigns.
1. Beneficiary eligibility checker. 2. Generation of due lists for multi-round campaigns. 3. In-app alerts and reminders to improve medication adherence.
Inventory management
Mobile app that enables the warehouse manager to capture the inflow and outflow of resources from the warehouse and monitor delivery data against consumption data to identify potential stock outs, wastage, fraud, as well as take corrective action.
1. Record stock receipts and issues. 2. Stock reconciliation to view the balance stock on hand.
Consumables management
Dashboards and reports
Enable program managers, supervisors and frontline workers to view key performance indicators for assessing campaign efficiency and effectiveness before, during, and after the campaign via near real-time dashboards and preemptive alerts for course corrections.
1. Offline mobile reports to view task completion and campaign coverage. 2. Offline mobile reports to asses the performance of frontline teams. 3. Out-of-the-box online web dashboard to view campaign coverage and efficiency indicators. 4. Export tabular reports from web dashboards.
1. Automate preemptive email/SMS notifications. 2. Automate report generation.
Configure rule-based alerts on dashboards with enhanced predictive analytics.
1. Online GIS-enabled web dashboards for real-time monitoring 2. Dashboard with basic rule-based prescriptive analytical support.
Training
Enable program managers and supervisors to track training progress, evaluate training attendees and provide on-demand refreshers to attendees. Ensure that the campaign staff is equipped and trained to perform their duties efficiently.
1. Capture PII, bank details and performance data of hired campaign staff for longitudinal tracking. 2. Creation of the staff registry.
1. UI to find and hire campaign staff from the staff registry to enable better skill-requirement match. 2. On-demand access to job-aids.
1. Training refreshers. 2. Pre and post evaluation of the training. 3. Track the status of the training sessions.
Payments
Enable program managers to decrease the time to pay frontline workers while increasing financial accountability and reducing fraud.
1. Manage attendance for the campaign staff. 2. View payment due for services delivered.
1. Automate invoice generation for incentive payments. 2. Automate payment to campaign staff 3. Track status of payment processing. 4. Send notification on payment completion.
SBCC/demand generation
Enable program managers, frontline workers and citizens to easily access and recieve SBCC messages digitally to improve disease awareness and decrease refusals.
1. On-demand access to IEC material within the mobile app.
1. Broadcast SMS for one-way messaging to beneficiaries. 2. Post service delivery surveys.
Grievances and complaints
Enable program managers and supervisors to ensure speedy and efficient resolution of complaints while providing them with an intuitive system that helps to initiate corrective actions in a timely manner.
1. Log grievances/complaints. 2. Manage complaints: View and resolve complaints. 3. Dashboards for viewing complaints and grievances.
1. Assign complaints to the appropriate actor for resolution. 2. Track the status of complaints. 3. Notification on complaint resolution.
1. Automatic prioritization of complaints from the list. 2. Auto-routing and escalation of complaints.
Planning
Enable program managers to improve the efficiency and effectiveness of the planning process by leveraging GIS systems and data from other sources to create planning templates that make it easy to generate, validate and share micro-plans.
Micro-planning: Template for capturing targets from the micro-plans.
Workflow management.
1. Macro-planning: Estimating population numbers and resource requirements. 2. Micro-planning: Input based template to generate micro-plans. 3. Micro-planning: Workflow to share micro-plans for reviews and approvals. 4. Micro-planning: Track the status of the micro-planning activity.
GIS-enabled micro-planning using digital maps.
Supervision
Enable supervisors to to track the campaign staff's adherence to campaign SOP's and protocols and record inspection details.
Submit supervision checklists.
In-app notifications to the field teams.
WhatsApp integration to enable a two-way communication.
Offline capability
Enable frontline teams to collect data in low and no internet areas.
1. Data collection in low/no internet areas. 2. Enable location services while offline to track GPS coordinates.
Peer-to-peer sync.
User experience delighters
Enable all frontline workers to do their best work by providing a feature set in the mobile application that enables the app to act as a co-pilot to help the user perform their tasks while improving technology adoption.
1. In-app walkthrough of the application. 2. Progress bar to monitor the work status. 3. Multi-language support. 4. Call help desk: SOS button.
Interoperability and integration
Enable the adoption of the HCM platform by allowing a hassle-free integration of the capabilities with widely-used applications.
Integration with DHIS2.
1. Interoperability with FHIR for data exchange. 2. Supply chain management: Integration with OpenLMIS. 3. Integration with other visualization tools like PowerBI, and Tableau. 4. Integration with Reveal.
Citizen's portal
Registration 1. Self-Registration for campaigns. 2. Appointment scheduling and booking.
Demand generation: 1. Post-service delivery surveys. 2. Help desk service for citizens.
Service delivery: 1. Download the certificates after receiving the health intervention. 2. Self-reporting of adverse events.
Grievances and complaints: 1. Log grievances/complaints regarding service delivery. 2. Feedback post issue resolution. 3. Track the status of complaints.
Server should be responsible to handle or offer a mechanism to handle errors once data reaches it. (Error handling mechanism being designed by Platform).
Sync will be manually triggered by user (except for automatically syncing configuration down on first login).
Sync down of data is not required to supported (good to have) for first roll out.
Sync will be done through bulk APIs
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.
Eg: If a field user registers an individual and saves the record and then goes back to update the individual, this will result in 2 API calls to the server (one create and one update).
API Response compression Gzip will be turned on for all the endpoints
Unique identifier to be used between client and server
Client will create a unique (client generated) identifier per entity (clientReferenceId) to relate entities while operations are being performed offline and send this id to the server for create operations.
Any subsequent operations (like update, delete) will be on server gen id, so client has to get server gen id by searching using client generated id. Client will call search API with clientReferenceId and will get server generated id.
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
Processing on the backend will continue to be asynchronous and not changed for the health use case.
Search API max limit and default limit
Service details and endpoints
Service details and endpoints
Number of entities sent to server in bulk API calls
Additional fields per entity in the app
The drop-down values or select options to be presented in the app for field users
Configuration changes are expected to be additive in order for the data captured against such configuration to continue being usable.
Number of retries on API call failure after which app should stop retrying
Timeout for API calls
Access to data will be defined by the linkages of staff to project and the corresponding boundary while respecting role-action mappings instead of the tenant based approach.
All deletes are soft deletes
Server is responsible to delete nested/child entities if applicable when the parent entity is deleted
Undeletion is not permitted
Duplicate updates do not need to be detected or filtered out. Client is responsible to send duplicate updates on entity as separate requests to server.
Since persistence in DIGIT is asynchronous but the sync process from the field worker app is likely to send dependent data in a short span of time, a cache is to be introduced against which dependent data can be validated if required while it is in the process of being persisted to the DB. This cache is exposed via the search API of the corresponding service and the caller is agnostic to whether the result was returned from cache or database.
For v1, we can maintain sequence of updates only for requests on a single entity by a single user. i.e. Updates on the same entity by multiple users will result in last caller's updates going through.
In order to maintain sequence of updates, a rowVersion field is introduced in every entity. Callers pass the rowVersion as received from the server. The server can detect if any out of sequence updates have come in and reject it / pass it to the error handling mechanism.
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.
From the Product requirement perspective, there is no unique identification identifier, so Platform is unable to check uniqueness of registry entities.
The development is complete for all the features that are part of the release.
Yes
Kalyan
Code merged to master branch on May 12th.
Test cases are documented by the QA team, reviewed by product owners, and test results are updated in the test cases sheet.
Yes
Guruprasad
Mrunal
Signed-off by Roshan/ Mrunal.
The incremental demo of the features showcased during the sprint showcase and feedback is incorporated. If possible, list out the JIRA tickets for feedback.
Yes
PGR - April 26th. HRMS & Mobile Offline Reports - May 11th.
UI/UX audit review is completed along with feedback incorporation for any changes in UI/UX.
Yes
Sai Neelakantan Bhanu
Andrew
PGR, Dashboard HRMS - UX audit complete and high priority issues fixed.
Incremental demos to the product owners are completed as part of the sprint, and feedback is incorporated.
Yes
Guruprasad
Mrunal
PGR - April 26th. HRMS & Mobile Offline Reports - May 11th.
QA sign-off is completed by the QA team and communicated to product owners. All the tickets’ QA sign-off status is updated in JIRA.
Yes
Guruprasad
PGR - Provided on April 28th. Dashboard v1.1 - Provided on May 2nd. HRMS and Mobile Offline reports - Provided on May 10th.
UI, and API technical documents are updated for the release along with the configuration documents.
Yes
Kavi
Ghanshyam
UAT promotion and regression testing from the QA team is completed. QA team has shared the UAT regression test cases with the product owners.
Yes
Guruprasad
PGR - Provided on April 28th. Dashboard v1.1 - Provided on May 2nd. HRMS and Mobile Offline reports - Provided on May 10th.
API automation scripts are updated for new APIs or changes to any existing APIs for the release. API automation regression is completed on UAT; the automation test results are analysed and the necessary actions are taken to fix the failure cases. Publish the list of failure use cases with a reason for failure and the resolution taken to fix these failures for the release.
Yes
Done for FLW App.
The API backward compatibility testing is completed.
Not applicable
Reason: This is the first version of product.
The communication is shared with product owners for the completion of UAT promotion and regression by the QA team. The product owners have to give a product sign-off within one week of this communication.
Yes
Frontline Worker's App - On March 23rd.
Complaints - On April 28th. Dashboard v1.1 - On May 2nd. HRMS and Mobile Offline reports - On May 10th.
Kalyan
The UAT product sign-off communication is received from product owners along with the release notes and user guides (if applicable).
Yes
Frontline Worker's App - On March 23rd.
User Management - On April 28th. Dashboard - On May 2nd. HRMS and Mobile Offline reports - On May 10th.
Mrunal
Kalyan
The GIT tags and releases are created for the code changes for the release.
Yes
Roopesh/ Kavi
Need to be created for the flutter component.
Verify whether the release notes are updated.
Yes
Roopesh/ Kavi
Kalyan
Tech release notes are updated.
Verify whether all the UAT builds are updated along with the GIT tag details.
Yes
Roopesh/ Kavi
Verify whether all MDMS, configurations, infra-ops configurations are updated.
Yes
Roopesh/ Kavi
All configurations are part of the master promotion document.
Yes
Mihika
Signed-off.
Verify whether all test cases are up-to-date and updated along with the necessary permissions to view the test cases sheet. The test cases sheet is verified by the test lead.
Yes
Guruprasad
Signed-off.
Verify whether the UAT credentials' sheet is updated with the details of new users and roles, if any.
Yes
This should not go into Gitbook as this is internal to eGov
Guruprasad
Signed-off.
Verify whether all the localisation data was added in UAT, and updated in the release kits.
Yes
Roopesh
This should be part of the release kit. This will be shared internally with the team.
Verify whether the product release notes and user guides are updated and published.
Yes
Mrunal
Jojo
Signed-off.
The demo of the released features is done by the product team as part of a sprint/release showcase.
Yes
Mrunal
Done.
Technical and product workshops/demos are conducted by the engineering and product teams respectively to the implementation team (implementation handover).
Yes
Kalyan
Prasanna
Architect sign-off and technical quality report.
Yes
Roopesh
Signed-off.
Product roadmap and success metrics
Yes
Mrunal
Published.
Adoption metrics
Yes
Ankit
Pradipta
Ankit has shared the draft for this. However, final discussion is pending with NMCP.
Programme roll-out plan
Yes
Ankit
Pradipta
Implementation checklist
Yes
Aparna
Elzan
Implementation roll-out plan
Yes
Aparna
Elzan
Gate 2
Ankit
ExCos
Scheduled on June 9th.
The internal release communication along with all the release artefacts are shared by the engineering/product teams.
Mrunal
To be shared post Gate 2.
Plan for upgrading the staging/demo instance with the release product within 2-4 weeks based on a period where no demos are planned from staging for the previous version of the released product.
Not applicable currently.
The release communication to partners is shared by the GTM team, and a webinar is arranged by the GTM team after the release communication, within 2-4 weeks of the release.
Not applicable currently.
This is not the final release. Hence, external communication is not required.
The articles in this section include:
Here are the articles in this section:
Verify whether all docs will be published to by the Technical Writer as part of the release.
This page lists the skillset required for anyone to build and support the HCM application
This document lists the technical skillset required for someone to build and support the Health Campaign Management 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.
The technical skill sets 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.
Open API Contract - Swagger2.0
YAML/JSON
Postman
Postgres
Java and REST APIS
Basics of Elasticsearch
Maven
Springboot
Kafka
Zuul
ReactJS
Flutter
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 & 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 Zuul gateway
Gitops, Git branching, PR review process. Rules, Hooks, etc.
Experience in Helm, packaging and deploying.
Apache, Nginx, Redis and Postgres.
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
There are the 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.
Topic
Reference
Preparedness Check
Git
Do you have a Git account? Do you know how to clone a repository, pull updates, push updates? Do you know how to give a pull request and merge the pull request?
Microservice Architecture
Do you know when to create a new service?How to access other services?
ReactJS
How to create react app?How to create a stateful and stateless component? How to use HOC as a wrapper?Validations at form level using React.js and Redux.
Postgres
How to create a database and set up privileges? How to add an index on a table? How to use aggregation functions in psql?
Postman
Call a REST API from Postman with proper payload and show the responseSetup any service locally (MDMS or user service has least dependencies) and check the API’s using postman.
REST APIs
What are the principles to be followed when making a REST API? When to use POST and GET? How to define the request and response parameters?
Kafka
How to push messages on Kafka topic? How does the consumer group work? What are partitions?
Docker and Kubernetes
How to edit deployment configuration? How to read logs? How to go inside a Kubernetes pod?How to create a docker file using a base image?How to port-forward the pod to the local port?
JSON
How to write filters to extract specific data using jsonPaths?
YAML
How to read an API contract using swagger?
Zuul
What does Zuul do?
Maven
What is POM?What is the purpose of maven clean install and how to do it?What is the difference between the version and SNAPSHOT?
Springboot
How does Autowiring work in spring? How to write a consumer/producer using spring Kafka? How to make an API call to another service using restTemplate? How to execute queries using JDBC Template?
Elastic search
How to write basic queries to fetch data from elastic search index?
DIGIT Architecture
What comes as part of core service, business service and municipal services? How to calls APIs from one service in another service?
DIGIT Core Services
Which are the core services in the DIGIT framework?
DIGIT DevOps
DIGIT MDMS
How to read a master date from MDMS? How to add new data in an existing Master? Where is the MDMS data stored?
DIGIT UI Framework
How to add a new component to the framework? How to use an existing component?
DSS
Here are the articles in this section:
Here are the articles in this section:
Install
Install
Install
Install 6
Install
s
This section discusses the supported cloud environment for DIGIT services. It provides information on where and how DIGIT is deployed. Further, it offers guidelines for estimating the infrastructural requirements for cloud support.
Click to know more about our data setup guide.
The following data is needed for DIGIT ecosystem
Boundary and Boundary Hierarchy is part of one time setup. All the fields cannot be fetched from the DHIS2 directly. Some manual intervention is needed.
Clubbing projects and boundaries because both of these can be populated from same set of master data. These are directly correlated to Organisational Units. Targets to be fetched from forms. The forms of interest are “RTIs Metas Macroplano” and “RTIs Metas Microplano”. They are available at village level only. Projects and relevant targets can be fetched from the following boundary information.
Product and Product variant are one time config
ration for a campaign. Unable to find equivalent in DHIS2. Will need to double check.
For Mozambique, the following are being tracked on DHIS2 at a team level.
Red Sticker
Green Sticker
Bednet
At the district and community warehouses only bed nets are being tracked.
OrgUnits have shapes (geometry) associated with them. Granularity is available only till district level. If we have to generate the shapefile dynamically, it will be tedious. Would be better to check with the CHAI team about how they are downloading the shapefiles from DHIS2 and replicate.
Unable to find on DHIS2. Will need to check with Mrunal and CHAI team.
Types of Data
There are two types of transactional data that we need to ingest into DIGIT from DHIS2.
Beneficiary - In the case of Moz it is Household data.
Service Delivery - In the case of Moz, this is the bed net being distributed.
Inventory management
Supervisor checklist - Forms are available in DHIS2, need to understand DIGIT models before this mapping can be done.
The following forms contain transactional data in DHIS2
This data is extracted from the form called “Ficha de Registo dos Agregados Familiares”. The only Beneficiary field available is the Head of household’s name and memberCount of the household. The rest of the required fields will be empty.
This data is extracted from the form called “Ficha de Registo dos Agregados Familiares”.
At the start of the campaign we will need to ingest data from the physical count form. Entry and Exits are tracked through the entry and exit form mentioned above. We will need to do this for District and Community warehouses. The fields remain the same only the forms are changing. Which means the appropriate IDs will also change. The following are the forms:
The spec of the survey service is being worked on at the product side. Once the design is completed, this section will be addressed.
On DHIS2 there is a single form that captures Bednet distribution as well as household registration (Both the required transactional data fields). This form is called “Ficha de Registo dos Agregados Familiares”. We will have to convert this single form data into two DIGIT payloads - Beneficiary and Benefit (or Service Delivery or Task).
All data is collected at a village level only in DHIS2. This form has the following fields.
Click to know more more.
DIGIT Field
DHIS2 Source
Comments
Boundary Code
OrgUnit.code
Boundary Name
OrgUnit.name
Parent Boundary Code
OrgUnit.parent.code
Boundary Type
OrgUnitLevel.name
Hierarchy Type Code
OrgUnitLevel
Campaign Start Date
Campaign End Date
Total Households
RTIs Metas Macroplano.Agregado familiar
Targetted Households
RTIs Metas Microplano.Agregados do Microplano
Total Individuals
RTIs Metas Macroplano.População
Targeted Individuals
RTIs Metas Microplano.População
Bednets estimated to be delivered
RTIs Metas Macroplano.Redes mosquiteiras
DIGIT Field
DHIS2 Source
Comments
Username
User.userCredentials.username
Can be kept same as DHIS2 username
Password
We will need to auto generate this, if user access needs to be provided.
Name
User.name
Mobile No
Not available
DHIS2 does not capture demographic and user information.
Gender
Not Available
DHIS2 does not capture demographic and user information.
Date of Birth
Not Available
DHIS2 does not capture demographic and user information.
Not Available
DHIS2 does not capture demographic and user information.
Correspondence Address
Not Available
DHIS2 does not capture demographic and user information.
Role
User.userRole
Multiple role assignments are possible. Role Maps need to be created between DIGIT and DHIS2 and appropriately assigned
Employment Type
Not Available
DHIS2 does not capture demographic and user information.
Date of Appointment
Not Available
DHIS2 does not capture demographic and user information.
Department*
Not Available
DHIS2 does not capture demographic and user information.
Designation
Not Available
DHIS2 does not capture demographic and user information.
Project
User.organisationalUnit
A user can be associated with multiple Organisational Units. We will need to map OU to Projects and appropriately map the project to the user
DHIS2 Form
Translation
Comments
Ficha de entrega de material - Monitor (Entrega e Devolução)
Material delivery form for monitor.
Not sure about where this can be used. This contains details for all materials used as part of campaigns. Red stickers, Green stickers, bednets etc.
Ficha de entrega de material - Provincial (Entrega e Devolução)
Material delivery form - Provincial (Delivery and Return)
Need to understand use case
Ficha de entrega de material - Logistico (Entrega e Devolução)
Material delivery form - Logistics (Delivery and Return)
Need to understand use case
Ficha de Registo dos Agregados Familiares
Household registration form
This is the form of interest. This contains the service delivery information.
Gestão De Stock - Começo de cada dia
Stock management - Start of every day
This is stock management to each distribution team. How many Red and Green stickers, bed nets etc are being given to each team at the beginning of the day. Not of interest.
Gestão De Stock - No final de cada dia
Stock management - End of each day
This is stock management to each distribution team. How many Red and Green stickers, bednets etc are returned by the team at the end of each day. Not of interest.
AD (Armazém distrital) - Entradas
District Warehouse - Entry
AD (Armazém distrital) - Saidas
District Warehouse - Exit
AD (Armazém distrital)- Contagem física
District Warehouse - Physical Count
AC (Armazem Comunitarial) - Entradas
Community Warehouse - Entry
AC (Armazem Comunitarial) - Saidas
Community Warehouse - Exit
AC (Armazem Comunitarial) - Contagem física
Community Warehouse - Physical count
DIGIT Field
DHIS2 Source
Comments
projectId
OrgUnit
This is an acquired field from DIGIT<>DHIS2 master data mapping. It will be associated with the relevant OU at the village level
tenantId
clientReferenceId
FormEntry.ID
This is to store the DHIS2 internal unique identifier of this beneficiary record from the form. This will be the ID of the form instance
memberCount
Número de membros do agregado familiar que vivem na mesma casa (incluindo o(a) chefe do agregado familiar)
address.tenantId
address.doorNo
NA
address.latitude
FormEntry.latitude
address.longitude
FormEntry.longitude
address.locationAccuracy
NA
address.type
HOUSEHOLD
address.addressLine1
NA
address.addressLine2
NA
address.landmark
NA
address.city
OrgUnit?
Can we populate from OrgUnit or can we ignore this
address.pincode
NA
address.buildingName
NA
address.street
NA
address.locality.code
OrgUnit.code
address.locality.label
OrgUnit.name
address.locality.latitude
NA
address.locality.longitude
NA
DIGIT Field
DHIS2 Source
Comments
projectId
OrgUnit
This is an acquired field from DIGIT<>DHIS2 master data mapping. It will be associated with the relevant OU at the village level
tenantId
clientReferenceId
FormEntry.ID
This is to store the DHIS2 internal unique identifier of this beneficiary record from the form. This will be the ID of the form instance
projectBeneficiaryId
DIGIT BeneficiaryID
After the beneficiary is created, we will need to fetch that ID and populate this field
resources.tenantId
resources.productVariantId
This is the product variant being distributed. Will be part of MDMS. We were told that if we configure at project level in MDMS, it will be auto populated.
resources.quantity
FormEntry.Número de redes distribuídas
resources.isDelivered
This will always be true, because entry is created in DHIS2 after service delivery
resources.deliveryComment
FormEntry.Observações
plannedStartDate
plannedEndDate
actualStartDate
actualEndDate
createdBy
FormEntry.Selecione equipe de distribuição
This is the name of the DHIS2 user who created this record. We will be importing these users as part of master data import, the equivalent DIGIT userID to be populated here.
createdDate
address.tenantId
address.doorNo
NA
address.latitude
FormEntry.latitude
address.longitude
FormEntry.longitude
address.locationAccuracy
NA
address.type
HOUSEHOLD
address.addressLine1
NA
address.addressLine2
NA
address.landmark
NA
address.city
OrgUnit?
address.pincode
NA
address.buildingName
NA
address.street
NA
address.locality.code
OrgUnit.code
address.locality.label
OrgUnit.name
address.locality.latitude
NA
address.locality.longitude
NA
AD (Armazém distrital) - Entradas
District Warehouse - Entry
AD (Armazém distrital) - Saidas
District Warehouse - Exit
AD (Armazém distrital)- Contagem física
District Warehouse - Physical Count
AC (Armazem Comunitarial) - Entradas
Community Warehouse - Entry
AC (Armazem Comunitarial) - Saidas
Community Warehouse - Exit
AC (Armazem Comunitarial) - Contagem física
Community Warehouse - Physical count
DIGIT Field
DHIS2 Source
Comments
clientReferenceId
FormInstance.ID
This is will be unique identity of the FormEntryInstance
tenantId
facilityId
Armazém distrital
This will be the district warehouse or community warehouse ID. We will need to fetch and do a mapping. This facility will be mapped to the project so we need only the facilityId.
productVariantId
This is a DIGIT field, created as part of master data creation
quantity
Nr. da guia de remessa *
referenceId
Unsure of what this is
referenceType
Entrada ou Devolucao
Entry or Exit
transactionReason
Entrada ou Devolucao
Return
transactingPartyId
User ID of the transacting party
transactingPartyType
WAREHOUSE
DHIS2 Field Name
DIGIT Field
Comments
Org Unit
Beneficiary.projectId, Beneficiary.address[].locality,
Benefit.projectId,
Benefit.address[].locality
This corresponds to the Village in which the Bed Nets are distributed. Each Org Unit has a different unique identifier. This mapping needs to be maintained in configuration.
Latitude
Beneficiary.address[].latitude,
Beneficiary.address[].locality.latitude
Benefit.address[].locality.latitude, Benefit.address[].latitude
Longitude
Beneficiary.address[].longitude,
Beneficiary.address[].locality.longitude
Benefit.address[].locality.longitude, Benefit.address[].longitude
Equipe de distribuição
Beneficiary.userId, Benefit.createdBy
This is the user who does the distribution. Typically this is the user who distributes the Bednets.
Data hoje
Beneficiary.dateOfRegistration, Benefit.plannedStartDate, Benefit.plannedEndDate, Benefit.actualStartDate, Benefit.actualEndDate, Benefit.createdDate
Date when the form was filled/service was delivered.
Nome do(a) chefe do agregado familiar
Beneficiary.name.givenName
DHIS2 captures the full name of the head of the household. There is no way to syntactically split it into Given Name, Surname and otherNames as needed for the DIGIT ecosystem. So the assumption is that only the givenName will be populated
Selecione equipe de distribuição
Beneficiary.userId, Benefit.createdBy
Número de membros do agregado familiar que vivem na mesma casa (incluindo o(a) chefe do agregado familiar)
Beneficiary.memberCount
Número de redes por atribuir
No equivalent in DIGIT payload for service delivery. This is a calculated field on the UI. No persistence. The aggregate for a village will be persisted at the equivalent project level.
Número de redes distribuídas
Benefit.resources[].quantity
Observações
Benefit.deliveryComment
Verifique se seus números estão corretos antes de finalizar este formulário
This field is to let the distributor validate the information present in the form.
DHIS2 Field Name
Translation
DIGIT Field Mapping
Comments
Entrada ou Devolucao
Incoming or Outgoing
Armazém distrital
District warehouse
Identificação do fiel armazém (nome completo)
Identification of the faithful warehouse (full name)
Proveniência
Provenance
Especficar
Specify
Nr. da guia de remessa
Delivery note number
Nr. matrícula ou tipo de transporte
Registration no. or type of transport
Quantidade de redes indicadas na guia de remessa
Quantity of nets indicated on delivery note
Quantidade de redes recebidas
Quantity of nets received
Comentário
Comment
Following are the features for HCM Product:
Register new households and individuals.
Search existing households and individuals
Update details for existing households and individuals.
Record service delivery of healthcare interventions to households and individuals for a single round campaign.
Auto-calculation of resources to be delivered to a household or individuals based on the configured rule.
Record stock movement for a warehouse-stock received, issued, returned, damaged and lost.
Stock reconciliation to automatically calculate the stock on hand available in the warehouse.
Offline reports for view all stock transactions and stock count in the mobile application.
Register complaints on the mobile app with offline support.
Search, sort, filter complaints based on configured parameters.
Web app for help desk users to view and act on logged complaints; assign, resolve or reject complaints.
Configurable checklists for supervisors for various supervision activities.
Multi-language support.
Track GPS coordinates to record locations with offline support.
In-app guided walkthrough to help onboard and train new app users.
Progress bar for monitoring the daily work status of registration and service delivery against the targets assigned.
Reuse beneficiary data from the registries for future campaigns.
Web portal for user management.
SOS: One-click call to the helpdesk.
Auto-sync capability to sync all data collected while offline.
In-app notification to prompt users to perform actions that are due.
DIGIT Field
DHIS2 Source
Comments
Code
DHIS2 has numerical short codes. DIGIT expects alphabets. We can directly use the Level codes - 1,2,3,4,5,6 as described by DHIS2
Boundary Hierarchy Type
Organizational Unit Level
Description
OrgUnit.Name
Here are the articles in this section:
Data Capture
Validation
Analysis
Presentation
SDMX-HD and ADX standards for interoperability
ADX: Aggregate Data Exchange
DHIS2 Web API
DHIS2 Core
It exposes REST API(s) over DHIS2 Core which we can utilise.
DHIS2 provides Basic Auth, Two Factor Auth, Personal Access Token(PAT) and OAuth2. Basic Auth is the least secure and Two Factor Auth is for direct DHIS2 users.
PAT
By default PAT will have all the authorizations that the user has. This can be configured or a special user can be created having only the required permissions.
The token is configurable via API and only the constraints can be modified after a token is created.
Token key is returned only once when the token is generated.
Expiry of the token can be configured via Web API along with other constraints.
OAuth2
We can go with grant_type as password. This can be configured via Web API too. Grant_type password would involve sharing username and password. However, this will be in a POST call body.
User: admin
Pass: district
List of the metadata which are required and there attributes
Note this data is extracted from the schemas endpoint of DHIS2
DHIS2 is District Health Information Software 2.
The DHIS 2 is a routine data based health information system which allows for:
data capture,
aggregation,
analysis, and
reporting of data.
The data model is generic in all dimensions in order to allow for capture of any item of data.
The model is based on the notion of a DataValue.
A DataValue can be captured for
any DataElement (which represents the captured item, occurrence or phenomena),
Period (which represents the time dimension), and
Source (which represents the space dimension, i.e. an organisational unit in a hierarchy).
Meta Data
Understanding on this
Remarks
DataSet
The DataSet is a collection of DataElements for which there is entered data presented as a list, a grid and a custom designed form.
A DataSet is associated with a PeriodType, which represents the frequency of data capture.
This is what is a campaign as per current understanding
Data Element
Basically a Form Field
The data element often represents a count of something, and its name describes what is being counted, e.g. "BCG doses given" or "Malaria cases".
Data Element Group
Group of Data Element
Indicator
Allows for data analytics and reporting. It is basically output of data capture. An Indicator is basically a mathematical formula consisting of Data Elements and numbers. The formula is split into a numerator and denominator.
IndicatorType
An Indicator is associated with an IndicatorType, which indicates the factor of which the output should be multiplied with.
A typical IndicatorType is percentage, which means the output should be multiplied by 100.
OrgUnit
Source or manageable area under which the data is captured
Category
METADATA Diagram taken from the DHIS2 technical documentation
The diagram is taken from the core technical documentation for understanding the relationships between the DHIS2:
Health Campaign Management Platform
Our mission is to build a digital infrastructure that 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.
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 Platform that offers:
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 these goals and more.
Countries require innovative solutions to ensure that campaign delivery and coverage are achieved effectively, efficiently, and rapidly. Digitisation of campaigns is a way forward.
Health campaigns are categorised based on the following characteristics:
Duration of the campaign (short-term/long-term)
Frequency of the campaign (episodic/periodic/seasonal)
Campaign design (vertical/horizontal, reactive/proactive)
Type of Intervention delivered (product/service/information)
Click on the links below to learn more about the products:
Find the mock-ups below:
A landing page must be available to the user to access all available modules.
A user must be able to search for an existing employee using search parameters (name, mobile number, username).
Users must be able to create new users by providing the following details. Refer to the section on specifications.
Allow users to reset the password. Allow users to edit existing information or add information to an existing employee. Refer to the section on specifications for validations and conditions.
Refer to the section on specifications for validations and conditions.
Here are the articles in this section:
SDMX:
SDMX-HD:.
While adding dhis2 client
All content on this page by is licensed under a .
Find the mock ups below:
After logging into the application, the user lands on this screen which displays daily performance (the number of households registered). The progress bar must reset daily at 00:00 hours and start from 0 registration. The action buttons related to the beneficiary are present, which include:
Beneficiaries
View Reports
Sync Data
Call Supervisor
File Complaint
At the bottom, there is a card that shows how many records are unsynced for the user’s convenience to sync data. If all the records are synced, then the card must say, “All records are synced”.
The help button is on every screen of the application. By clicking on this button, a user can get a walkthrough of the elements on that screen. On the top right, the administrative area assigned to the user is displayed which will be based on the level of hierarchy. The hamburger button on the top left corner covers other actions.
After clicking on the hamburger button, a list of actions appears on the user screen. On top, it displays the user name and contact number, followed by other options such as the home button, language select, edit profile, projects, and logout. The “Edit Profile” option is not in scope for V1, it needs to be taken in V1.1.
If the user clicks on the hamburger button again, it collapses the hamburger menu. The button is available on all screens of the application.
The user can edit his/her name, phone number, and select the gender. After updating the details, the user needs to click on the save button which opens a prompt stating “saved successfully”.
If the user does not want to make any changes, he/she can click on the back button which will take him/her back to the hamburger menu. This is not in scope for V1.0; it needs to be taken up in V1.1.
When a user clicks on the projects option in the hamburger menu, it navigates them to the project selection screen from where the user can select another project to work on.
Though the automatic sync is triggered by the login action, after selecting another project, the system must now sync the data for the new project, and the same flow must be followed.
For a user assigned multiple boundaries, after logging in, the boundary selection overlay must appear. This forces the user to select a boundary only after which the user can view the home screen. The user can then change the boundary whenever required from the location picker placed at the top right. It has dropdown fields to select the boundary, which depends upon the hierarchy level of the user. For an FLW, the boundary selection starts from the administrative post. The values in the dropdown are linked to the higher hierarchy and the user cannot select a boundary if the previous field is left blank.
The dropdown must only consist of the boundaries which are assigned to the user, not all the boundaries under a particular hierarchy. For example, if the user is assigned localities 1, 2, and 3, and there are a total of 5 localities under admin post 1, then the dropdown must have only 1, 2, and 3 localities. The highest boundary must at least be selected to enable the select button which navigates the user to the home screen. For multiple projects, the sync needs to download the data only for the selected project.
If the user clicks on the help button, it will give a walkthrough of the entire screen, including the role of each button placed with two buttons:
Skip: If the user wants to skip the walkthrough at any point.
Next: It will proceed to the next action aligned.
The text box appears at the bottom of the button.
When a user clicks on the ‘Beneficiaries’ button, he/she will be navigated to this screen. It displays the number of households registered along with the number of bednets delivered in that administrative area. The register button is primarily disabled to ensure that the user performs the search action.
The search bar allows the user to search by the household head’s name, and the system provides the search results. The minimum string length to show results is 2 characters and the order of the results will be the last record displayed first.
Two cases can be generated:
No results are displayed.
The search results displayed do not match.
Both cases are discussed further. The ‘Back’ button on the top will navigate to the home screen.
When the user searches for a household, there can be two outcomes:
The list of households will appear as a search result. The user can then open the household card and proceed with service delivery.
Household Card (For a household-level campaign)
After registering the household, a user can search for the household and open the card. The household name is displayed as household to avoid the risk of names that may be longer. There is an “Edit Household” button for editing the household details which navigates the user to the household location screen. Below the household’s name, the service delivery status is present followed by the administrative area and the number of members.
There are cards for each member, starting from the household head. The card consists of the member's name, gender, age, and the ‘Edit’ button for individual-level actions. Age will be denoted in years for this version. This is because, for household-level campaigns, age is not a considerable parameter to provide interventions.
For adding new members to the household, there is an “Add Member” button below the member cards, which navigates the user to the “Individual Details” screen. At the bottom, the “Deliver Intervention” button navigates the user to the update delivery screen.
If the intervention is delivered to that household, a second screen will appear. The deliver intervention button must be replaced by the ‘Update Delivery Details’ button if more interventions are needed to be delivered. The back button at the top takes the user to the list of households screen.
In the case of an individual-level campaign, the household card appears in a similar format with some changes. The “Deliver Intervention” button is present at the bottom of every member’s card. If the intervention is delivered to a member, it will display ‘delivered’ below their details on the card, and the button will be replaced with “Update Delivery Details”. If the intervention is not delivered, it will display “not delivered”.
The deliver intervention button on the individual cards navigates the user to the update delivery screen. The back button navigates the user to the search households screen.
The summary of the household is displayed for preview on this screen. At the top, the “Date of Registration” is displayed, followed by the household head’s details, and the number of members in that household.
The “Number of Resources For Delivery” must be automatically calculated by the system based on the value entered in the number of household members, including the household head. For the LLIN campaign, the auto-calculation formula to calculate the number of bednets is in the ratio 1:1.8, that is, 1 bednet for 1.8 members with a maximum cap of 3 bednets per household. For example, if the member count is 7, the calculated value must be 3. The “Resource delivered” field consists of all the possible resources that can be delivered in a particular project. If there is only one resource to be delivered, then the field must be auto-filled by the system.
In the “Quantity distributed” field, the user can decide how many bednets need to be delivered to that household against the value generated by the system. The auto-calculation of the quantity must be hard-coded and can be made configurable in later versions. The user can increase or decrease the count through the ‘+’ or ‘-’ buttons, respectively. The field is mandatory and must be defaulted to 1, but can be reduced to 0 to cater to situations where the household receives no intervention due to stock-out.
The user can add a delivery comment if the service is not delivered due to some reason or situation, in the “Delivery Comment” field, which is a dropdown field with a list of possible reasons. The reasons must be configured in the MDMS. After reviewing the details, the user can click on the submit button which will save details of the household in the system. The confirmation screen appears after the details are validated.
After submitting the details, a pop-up window appears, asking the user to review the details before submitting.
If the user clicks on the ‘Submit’ button, the data will be submitted and the next screen will appear.
If the user clicks on the ‘Cancel’ button, the popup will close and the user will be taken back to the “Deliver Intervention’ screen.
When the user clicks on submit, this screen appears, confirming to the user that his/her data has been recorded successfully. Below the message, there is a “Back to Search” button which navigates the user to the search households screen for household-level campaigns. The search bar must be blank and previous results must not be displayed. For individual-level campaigns, the user will land on the household card screen.
The front end must not have the capability to delete any delivery details to avoid any misuse of this function. The backend must be able to delete any delivery record if needed.
Before going into the field, the user needs to log into the application daily, which will initiate an automatic sync process mentioned in the user login PRD. For manual sync, there is a “Sync Data” button on the home screen which allows the user to sync data according to their convenience. At the bottom of the screen, there is a card that shows the message “Data Unsynced” along with the number of records unsynced.
When the user clicks on the ‘Sync’ button, the sync action starts along with an overlay showing “Sync in Progress” over the home page. The user cannot perform any other action until the sync is complete or there is some error.
Once the data is synced, a pop-up comes up stating “Data Synced” along with a ‘Close’ button. When the user clicks on this button, it navigates them to the home screen.
If the data did not sync, a popup comes up, stating “Sync Failed” with two buttons below it:
Retry: If the user wants to retry syncing the data.
Close: Clicking on this will navigate the user back to the home screen.
The reports dashboard provides a tabular and visualised representation of user performance. They are generated based on the offline data present in the local device, associated with the user’s login. If a user selects the ‘Data’ option, it will provide a data-wise report of the campaign.
The bar graph shows the day-to-day comparison of registered beneficiaries along with a threshold of the daily target for registration. The table, which is added below the graph, displays the households registered as well as bednets distributed.
In the ‘Leaderboard’ section, the overall number of households registered will be displayed in the form of a milestone. Below that, all the individual users’ performance will be listed separately. The leaderboard option will not be available at the registrar level (field level) but at the field supervisor level.
If the user is facing any challenge and requires immediate solutions, they can click on the “Call Supervisor” button on the home screen. It will redirect them to their phone’s dial pad with the supervisor’s number auto-filled. By clicking on the ‘Call’ button, the user can contact the supervisor for immediate assistance.
No results appear. In this case, the user needs to register the household first, so that he/she can deliver the intervention. (Note: Refer to the PRD).
ACKNOWLEDGEMENT_SUCCESS_ACTION_LABEL_TEXT
Go Back
hcm-acknowledgement
en_MZ
वापस जाओ
ACKNOWLEDGEMENT_SUCCESS_DESCRIPTION_TEXT
The data has been recorded successfully.
hcm-acknowledgement
en_MZ
डेटा को सफलतापूर्वक दर्ज किया गया है।
ACKNOWLEDGEMENT_SUCCESS_LABEL_TEXT
Data recorded successfully
hcm-acknowledgement
en_MZ
डेटा सफलतापूर्वक दर्ज किया गया
ADMINISTRATION_AREA_FORM_LABEL
Administrative Area
hcm-household
en_MZ
प्रशासनिक क्षेत्र
AGE_LABEL_TEXT
Age
hcm-common
en_MZ
आयु
ATTR1
The district warehouse and the staff comply with COVID-19 prevention measures (minimum distance of 1.5m, use of masks, use of disinfectants etc)
hcm-checklist
en_MZ
जिला गोदाम और कर्मचारी COVID-19 रोकथाम उपायों (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक का उपयोग आदि) का अनुपालन करते हैं
ATTR2
Does the warehouse have RTI stock forms?
hcm-checklist
en_MZ
क्या गोदाम में आरटीआई स्टॉक फॉर्म हैं?
ATTR3
Is the stock form completed?
hcm-checklist
en_MZ
क्या स्टॉक फॉर्म पूरा हो गया है?
ATTR4
Are all the header fields on the stock card filled in?
hcm-checklist
en_MZ
क्या स्टॉक कार्ड पर सभी हेडर फ़ील्ड भरे गए हैं?
ATTR5
Is the number of RTIS (bales) received equal to the number of planned RTIS (bales)? (See MPP)
hcm-checklist
en_MZ
क्या आरटीआई (गठरी) की संख्या नियोजित आरटीआई (गठरी) की संख्या के बराबर है? (एमपीपी देखें)
ATTR6
Are the RTI movement fields filled in?
hcm-checklist
en_MZ
क्या आरटीआई की आवाजाही क्षेत्र भरे गए हैं?
ATTR7
Are the RTI movement fields CORRECTLY filled in?
hcm-checklist
en_MZ
या आरटीआई की आवाजाही क्षेत्र सही ढंग से भरे हुए हैं?
BENEFICIARY_ADD_ACTION_LABEL
Register New Household
hcm-beneficiary
en_MZ
नया परिवार पंजीकृत करें
BENEFICIARY_INFO_DESCRIPTION
Click on Register New Household button to add details.
hcm-beneficiary
en_MZ
विवरण जोड़ने के लिए 'नया परिवार पंजीकृत करें' बटन पर क्लिक करें।
BENEFICIARY_INFO_TITLE
Match not found!
hcm-beneficiary
en_MZ
मैच नहीं मिला!
BENEFICIARY_SEARCH_HINT_TEXT
To start, enter the name of household head
hcm-beneficiary
en_MZ
शुरू करने के लिए घर के मुखिया का नाम दर्ज करें
BENEFICIARY_STATISTICS_LABEL_TEXT
Search Households
hcm-beneficiary
en_MZ
परिवार खोजें
CHECKLIST
Checklist
hcm-checklist
en_MZ
चेकलिस्ट
CHECKLIST_CREATE_ACTION_LABEL
Create Checklist
hcm-checklist
en_MZ
चेकलिस्ट बनाएं
CHECKLIST_DATE
Date
hcm-checklist
en_MZ
तारीख
CHECKLIST_DETAILS_LABEL
Checklist Details
hcm-checklist
en_MZ
चेकलिस्ट विवरण
CHECKLIST_DIALOG_DESCRITPTION
Make sure the details entered are correct.
hcm-checklist
en_MZ
सुनिश्चित करें कि दर्ज किए गए विवरण सही हैं।
CHECKLIST_DIALOG_LABEL
Ready to submit checklist?
hcm-checklist
en_MZ
चेकलिस्ट सबमिट करने के लिए तैयार हैं?
CHECKLIST_DIALOG_PRIMARY_ACTION
Submit
hcm-checklist
en_MZ
जमा करें
CHECKLIST_DIALOG_SECONDARY_ACTION
Go Back
hcm-checklist
en_MZ
वापस जाओ
CHECKLIST_LABEL
My Checklists
hcm-checklist
en_MZ
मेरे चेकलिस्ट
CHECKLIST_VIEW_ACTION_LABEL
View Submitted Checklists
hcm-checklist
en_MZ
प्रस्तुत चेकलिस्ट देखें
CORE_COMMON_AGE
Age
hcm-common
en_MZ
आयु
CORE_COMMON_BACK
Back
hcm-common
en_MZ
वापस
CORE_COMMON_CANCEL
Cancel
hcm-common
en_MZ
रद्द करें
CORE_COMMON_CLOSE
Close
hcm-common
en_MZ
बंद करें
CORE_COMMON_CONTINUE
Continue
hcm-common
en_MZ
जारी रखें
CORE_COMMON_GENDER
Gender
hcm-common
en_MZ
लिंग
CORE_COMMON_HELP
Help
hcm-common
en_MZ
मदद
CORE_COMMON_MOBILE_NUMBER
Mobile Number
hcm-common
en_MZ
मोबाइल नंबर
CORE_COMMON_REQUIRED
Required field cannot be empty
hcm-common
en_MZ
आवश्यक क्षेत्र खाली नहीं हो सकता
CORE_COMMON_SAVE
Save
hcm-common
en_MZ
सहेजें
CORE_COMMON_SUBMIT
Submit
hcm-common
en_MZ
जमा करें
DAMAGED_STOCK_DETAILS
Damaged Stock Details
hcm-stock
en_MZ
क्षतिग्रस्त स्टॉक का विवरण
DATA_SYNC_INFO_CONTENT
There are {} transactions yet to be synced
hcm-home
en_MZ
सिंक किए जाने के लिए अभी तक {} रिकॉर्ड हैं
DATA_SYNC_INFO_LABEL
Data unsynced
hcm-home
en_MZ
डेटा अनसिंक्ड
DELIVER_INTERVENTION_DATE_OF_REGISTRATION_LABEL
Date of Registration
hcm-delivery
en_MZ
पंजीकरण की तारीख
DELIVER_INTERVENTION_DELIVERY_COMMENT_LABEL
Delivery Comment
hcm-delivery
en_MZ
वितरण टिप्पणी
DELIVER_INTERVENTION_DIALOG_CONTENT
Make sure you review all details before clicking on the Submit button. Click on the Cancel button to go back to the previous page.
hcm-delivery
en_MZ
सुनिश्चित करें कि आप सबमिट बटन पर क्लिक करने से पहले सभी विवरणों की समीक्षा करें। पिछले पृष्ठ पर वापस जाने के लिए रद्द बटन पर क्लिक करें।
DELIVER_INTERVENTION_DIALOG_TITLE
Ready to Submit?
hcm-delivery
en_MZ
सबमिट करने के लिए तैयार हैं?
DELIVER_INTERVENTION_ID_NUMBER_TEXT
ID Number
hcm-delivery
en_MZ
आईडी नंबर
DELIVER_INTERVENTION_ID_TYPE_TEXT
ID Type
hcm-delivery
en_MZ
आईडी का प्रकार
DELIVER_INTERVENTION_LABEL
Deliver Intervention
hcm-delivery
en_MZ
संसाधन प्रदान करें
DELIVER_INTERVENTION_MEMBER_COUNT_TEXT
Member Count
hcm-delivery
en_MZ
सदस्यों की संख्या
DELIVER_INTERVENTION_NO_OF_RESOURCES_FOR_DELIVERY
Number Of Resources For Delivery
hcm-delivery
en_MZ
वितरण के लिए संसाधनों की संख्या
DELIVER_INTERVENTION_QUANTITY_DISTRIBUTED_LABEL
Quantity Distributed
hcm-delivery
en_MZ
वितरित मात्रा
DELIVER_INTERVENTION_RESOURCE_DELIVERED_LABEL
Resource delivered
hcm-delivery
en_MZ
वितरित संसाधन
DOB_LABEL_TEXT
Date of Birth
hcm-beneficiary
en_MZ
जन्म की तारीख
FORGOT_PASSWORD_ACTION_LABEL
Forgot Password?
hcm-forgot-password
en_MZ
पासवर्ड भूल गए?
FORGOT_PASSWORD_CONTENT_TEXT
Please contact your administrator if you have forgotten your password
hcm-forgot-password
en_MZ
यदि आप अपना पासवर्ड भूल गए हैं तो कृपया अपने व्यवस्थापक से संपर्क करें
FORGOT_PASSWORD_LABEL_TEXT
Forgot Password
hcm-forgot-password
en_MZ
पासवर्ड भूल गए
GENDER_LABEL_TEXT
Gender
hcm-common
en_MZ
लिंग
HEAD_OF_HOUSEHOLD_LABEL_TEXT
Head of household
hcm-beneficiary
en_MZ
घर के मुखिया
HOME_BENEFICIARY_LABEL
Beneficiaries
hcm-home
en_MZ
लाभार्थियां
HOME_CALL_BACK_LABEL
Call Supervisor
hcm-home
en_MZ
पर्यवेक्षक को फोन करें
HOME_FILE_COMPLAINT
File Complaint
hcm-home
en_MZ
शिकायत दर्ज करें
HOME_MANAGE_STOCK_LABEL
Manage Stock
hcm-home
en_MZ
स्टॉक प्रबंधित करें
HOME_STOCK_RECONCILIATION_LABEL
Stock Reconciliation
hcm-home
en_MZ
स्टॉक का मिलान
HOME_SYNC_DATA_LABEL
Sync Data
hcm-home
en_MZ
डेटा सिंक करें
HOME_VIEW_REPORTS_LABEL
View Reports
hcm-home
en_MZ
रिपोर्ट देखें
HOUSEHOLD_ACTION_LABEL
Next
hcm-household
en_MZ
अगला
HOUSEHOLD_ADDRESS_LINE_1_FORM_LABEL
Address Line 1
hcm-household
en_MZ
पता पंक्ति 1
HOUSEHOLD_ADDRESS_LINE_2_FORM_LABEL
Address Line 2
hcm-household
en_MZ
पता पंक्ति 2
HOUSEHOLD_DETAILS_DATE_OF_REGISTRATION_LABEL
Date of Registration
hcm-household
en_MZ
पंजीकरण की तारीख
HOUSEHOLD_DETAILS_LABEL
Household Details
hcm-household
en_MZ
घर का विवरण
HOUSEHOLD_LOCATION_ACTION_LABEL
Next
hcm-household
en_MZ
अगला
HOUSEHOLD_LOCATION_LABEL_TEXT
Household Location
hcm-household
en_MZ
घर का स्थान
HOUSEHOLD_OVER_VIEW_ACTION_CARD_TITLE
Do you want to delete this beneficiary?
hcm-household
en_MZ
क्या आप इस लाभार्थी को हटाना चाहते हैं?
HOUSEHOLD_OVER_VIEW_ACTION_TEXT
Deliver Intervention
hcm-household
en_MZ
संसाधन प्रदान करें
HOUSEHOLD_OVER_VIEW_DELETE
Delete Household
hcm-household
en_MZ
घर को हटा दें
HOUSEHOLD_OVER_VIEW_DELETE_ICON_LABEL
Delete Household
hcm-household
en_MZ
घर को हटा दें
HOUSEHOLD_OVER_VIEW_DELIVERED_ICON_LABEL
Visited
hcm-household
en_MZ
दौरा किया
HOUSEHOLD_OVER_VIEW_EDIT_ICON_LABEL
Edit Household Details
hcm-household
en_MZ
घर का विवरण संपादित करें
HOUSEHOLD_OVER_VIEW_EDIT_ICON_LABEL_TEXT
Edit Household
hcm-household
en_MZ
घर संपादित करें
HOUSEHOLD_OVER_VIEW_HOUSEHOLD_HEAD_LABEL
Household Head
hcm-household
en_MZ
घर का मुखिया
HOUSEHOLD_OVER_VIEW_HOUSEHOLD_HEAD_NAME_LABEL
Household Head Name
hcm-household
en_MZ
घर के मुखिया का नाम
HOUSEHOLD_OVER_VIEW_LABEL
Household
hcm-household
en_MZ
परिवार
HOUSEHOLD_OVER_VIEW_NOT_DELIVERED_ICON_LABEL
Not Visited
hcm-household
en_MZ
दौरा नहीं किया
HOUSEHOLD_OVER_VIEW_PRIMARY_ACTION_LABEL
Delete
hcm-household
en_MZ
मिटा दें
HOUSEHOLD_OVER_VIEW_SECONDARY_ACTION_LABEL
Cancel
hcm-household
en_MZ
रद्द करें
HOUSEHOLD_OVER_VIEW__ADD_ACTION_TEXT
Add Member
hcm-household
en_MZ
सदस्य जोड़ें
ICON_LABEL
Open
hcm-beneficiary
en_MZ
खोलें
ID_NUMBER_LABEL_TEXT
ID Number
hcm-beneficiary
en_MZ
ID नंबर
ID_NUMBER_SUGGESTION_TEXT
Enter 10 digit ID number
hcm-beneficiary
en_MZ
10 अंक ID नंबर दर्ज करें
ID_TYPE_LABEL_TEXT
ID Type
hcm-beneficiary
en_MZ
ID का प्रकार
INDIVIDUAL_DETAILS_INVALID_MOBILE_NUMBER
Enter only numbers
hcm-beneficiary
en_MZ
केवल संख्या दर्ज करें
INDIVIDUAL_LABEL_TEXT
Individual Details
hcm-beneficiary
en_MZ
व्यक्ति का विवरण
INDIVIDUAL_NAME_LABEL_TEXT
Name of the Individual
hcm-beneficiary
en_MZ
व्यक्ति का नाम
ISSUED_STOCK_DETAILS
Issued Stock Details
hcm-stock
en_MZ
जारी किए गए स्टॉक का विवरण
LANDMARK_FORM_LABEL
Landmark
hcm-household
en_MZ
सीमाचिह्न
LOGIN_ACTION_LABEL
Login
hcm-login
en_MZ
लॉग इन करें
LOGIN_LABEL_TEXT
Login
hcm-common
en_MZ
लॉग इन करें
LOST_STOCK_DETAILS
Lost Stock Details
hcm-stock
en_MZ
खोए हुए स्टॉक का विवरण
MEMBER_CARD_ASSIGN_AS_HEAD
Assign as household head
hcm-member
en_MZ
घर के मुखिया के रूप में नियुक्त करें
MEMBER_CARD_DELETE_INDIVIDUAL_ACTION_TEXT
Delete Individual
hcm-household
en_MZ
व्यक्ति को हटाएं
MEMBER_CARD_DELIVER_DETAILS_UPDATE_LABEL
Update Delivery Details
hcm-member
en_MZ
वितरण विवरण अपडेट करें
MEMBER_CARD_DELIVER_DETAILS_YEAR_TEXT
years
hcm-member
en_MZ
साल
MEMBER_CARD_DELIVER_INTERVENTION_SUBMIT_LABEL
Submit
hcm-member
en_MZ
जमा करें
MEMBER_CARD_EDIT_DETAILS
Edit
hcm-member
en_MZ
संपादित करें
MEMBER_CARD_EDIT_INDIVIDUALDETAILS
Edit
hcm-member
en_MZ
संपादित करें
MEMBER_CARD_EDIT_INDIVIDUAL_ACTION_TEXT
Edit Individual Details
hcm-member
en_MZ
व्यक्तिगत विवरण संपादित करें
MEMBER_CARD_EDIT_INDIVIDUAL_DETAILS
Edit Individual Details
hcm-member
en_MZ
व्यक्तिगत विवरण संपादित करें
MOBILE_NUMBER_LABEL_TEXT
Mobile Number
hcm-beneficiary
en_MZ
मोबाइल नंबर
MY_CHECK_LIST_LABEL
My Checklist
hcm-home
en_MZ
मेरी चेकलिस्ट
NO_OF_HOUSEHOLDS_REGISTERED
No. of Households Registered
hcm-beneficiary
en_MZ
पंजीकृत परिवारों की संख्या
NO_OF_MEMBERS_COUNT_LABEL
Number of members living in the household
hcm-household
en_MZ
घर में रहने वाले सदस्यों की संख्या
NO_OF_RESOURCES_DELIVERED
No. of Bednets Delivered
hcm-beneficiary
en_MZ
वितरित मच्छरदानी की संख्या
PASSWORD_PLACEHOLDER
Password
hcm-login
en_MZ
पासवर्ड
POSTAL_CODE_FORM_LABEL
Postal Code
hcm-household
en_MZ
पोस्टल कोड
PRIMARY_ACTION_LABEL
OK
hcm-forgot-password
en_MZ
ठीक है
PROGRESS_INDICATOR_PREFIX_LABEL
completed
hcm-home
en_MZ
पूरा हुआ
PROGRESS_INDICATOR_TITLE
more to reach target
hcm-home
en_MZ
लक्ष्य तक पहुंचने के लिए और अधिक
PROJECT_DETAILS_LABEL
Projects
hcm-common
en_MZ
परियोजनाएं
RECEIVED_STOCK_DETAILS
Received Stock Details
hcm-stock
en_MZ
प्राप्त स्टॉक का विवरण
RETURNED_STOCK_DETAILS
Returned Stock Details
hcm-stock
en_MZ
लौटाए गए स्टॉक का विवरण
SEPARATOR_LABEL_TEXT
(or)
hcm-common
en_MZ
(या)
STOCK_DETAILS_COMMENTS_LABEL
Comments
hcm-stock
en_MZ
टिप्पणियाँ
STOCK_DETAILS_DAMAGED_DURING
Damaged during
hcm-stock
en_MZ
कब खराब हुआ था
STOCK_DETAILS_DIALOG_CONTENT
Make sure you reivew all details before clicking on the Submit button. Click on the Cancel button to go back to the previous page.
hcm-stock
en_MZ
सुनिश्चित करें कि आपने सबमिट बटन पर क्लिक करने से पहले सभी विवरण पुनः प्राप्त कर लिए हैं। पिछले पृष्ठ पर वापस जाने के लिए रद्द करें बटन पर क्लिक करें।
STOCK_DETAILS_DIALOG_TITLE
Ready to submit?
hcm-stock
en_MZ
सबमिट करने के लिए तैयार हैं?
STOCK_DETAILS_ISSUED_TO
Issued to
hcm-stock
en_MZ
किसके लिए जारी किया गया
STOCK_DETAILS_LOST_DURING
Lost during
hcm-stock
en_MZ
कब खो गया
STOCK_DETAILS_QUANTITY_DAMAGED
Quantity damaged
hcm-stock
en_MZ
क्षतिग्रस्त मात्रा
STOCK_DETAILS_QUANTITY_LOST
Quantity lost
hcm-stock
en_MZ
खोई हुई मात्रा
STOCK_DETAILS_QUANTITY_RECEIVED
Quantity received
hcm-stock
en_MZ
प्राप्त मात्रा
STOCK_DETAILS_QUANTITY_RETURNED
Quantity returned
hcm-stock
en_MZ
लौटाई गई मात्रा
STOCK_DETAILS_QUANTITY_SENT
Quantity sent
hcm-stock
en_MZ
भेजी गई मात्रा
STOCK_DETAILS_RECEIVED_FROM
Received from
hcm-stock
en_MZ
कहाँ से प्राप्त किया
STOCK_DETAILS_RECEIVED_FROM_DAMAGED
Received from
hcm-stock
en_MZ
कहाँ से प्राप्त किया
STOCK_DETAILS_RECEIVED_FROM_LOST
Received from
hcm-stock
en_MZ
कहाँ से प्राप्त किया
STOCK_RECONCILIATION_COUNT_EXPECTS_NUMBER
please give number
hcm-stock
en_MZ
कृपया नंबर दें
STOCK_DETAILS_RETURNED_TO
Returned to
hcm-stock
en_MZ
किसके पास लौटाया
STOCK_DETAILS_SELECT_PRODUCT
Select product
hcm-stock
en_MZ
उत्पाद का चयन करें
STOCK_DETAILS_VEHICLE_NUMBER
Vehicle number
hcm-stock
en_MZ
गाडी नंबर
STOCK_DETAILS_WAYBILL_NUMBER
Waybill Number
hcm-stock
en_MZ
वेबिल नंबर
STOCK_DETAILS_WAYBILL_QUANTITY
Quantity indicated on waybill
hcm-stock
en_MZ
वेबिल पर इंगित मात्रा
STOCK_RECONCILIATION_COMMENTS_LABEL
Comments
hcm-stock-reconciliation
en_MZ
टिप्पणियाँ
STOCK_RECONCILIATION_DATE
Date of reconciliation
hcm-stock-reconciliation
en_MZ
सामंजस्य की तारीख
STOCK_RECONCILIATION_DIALOG_CONTENT
Make sure you reivew all details before clicking on the Submit button. Click on the Cancel button to go back to the previous page.
hcm-stock-reconciliation
en_MZ
सुनिश्चित करें कि आपने सबमिट बटन पर क्लिक करने से पहले सभी विवरण पुनः प्राप्त कर लिए हैं। पिछले पृष्ठ पर वापस जाने के लिए रद्द करें बटन पर क्लिक करें।
STOCK_RECONCILIATION_DIALOG_TITLE
Ready to submit?
hcm-stock-reconciliation
en_MZ
सबमिट करने के लिए तैयार हैं?
STOCK_RECONCILIATION_FACILITY_LABEL
Warehouse
hcm-stock-reconciliation
en_MZ
गोदाम
STOCK_RECONCILIATION_INFO_CARD_CONTENT
Stock on hand = (Stock received + stock returned) - (stock issued + stock lost + stock damaged)
hcm-stock-reconciliation
en_MZ
स्टॉक ऑन हैंड = (प्राप्त स्टॉक + स्टॉक जो वापस आ गया) - (जारी किया गया स्टॉक + खोया हुआ स्टॉक + क्षतिग्रस्त स्टॉक)
STOCK_RECONCILIATION_INFO_CARD_TITLE
Info
hcm-stock-reconciliation
en_MZ
जानकारी
STOCK_RECONCILIATION_MANUAL_STOCK_COUNT_LABEL
Manual stock count
hcm-stock-reconciliation
en_MZ
मैनुअल स्टॉक गणना
STOCK_RECONCILIATION_PAGE_TITLE
Stock Reconciliation
hcm-stock-reconciliation
en_MZ
स्टॉक का मिलान
STOCK_RECONCILIATION_PRODUCT_LABEL
Select product
hcm-stock-reconciliation
en_MZ
उत्पाद का चयन करें
STOCK_RECONCILIATION_STOCK_DAMAGED
Stock damaged
hcm-stock-reconciliation
en_MZ
क्षतिग्रस्त स्टॉक
STOCK_RECONCILIATION_STOCK_ISSUED
Stock issued
hcm-stock-reconciliation
en_MZ
जारी किया गया स्टॉक
STOCK_RECONCILIATION_STOCK_LOST
Stock lost
hcm-stock-reconciliation
en_MZ
खोया हुआ स्टॉक
STOCK_RECONCILIATION_STOCK_ON_HAND
Stock on hand
hcm-stock-reconciliation
en_MZ
स्टॉक ऑन हैंड
STOCK_RECONCILIATION_STOCK_RECEIVED
Stock received
hcm-stock-reconciliation
en_MZ
प्राप्त स्टॉक
STOCK_RECONCILIATION_STOCK_RETURNED
Stock returned
hcm-stock-reconciliation
en_MZ
स्टॉक जो वापस आ गया
SUBMIT_LABEL_TEXT
Submit
hcm-common
en_MZ
जमा करें
USER_ID_PLACEHOLDER
User ID
hcm-login
en_MZ
उपयोगकर्ता ID
WAREHOSUE_DETAILS_WAREHOUSE_NAME_ID
Warehouse name / ID
hcm-stock
en_MZ
गोदाम का नाम / ID
WAREHOUSE_DETAILS_DATE_OF_RECEIPT
Date of receipt
hcm-stock
en_MZ
प्राप्ति की तारीख
WAREHOUSE_DETAILS_LABEL
Warehouse Details
hcm-stock
en_MZ
गोदाम विवरण
project1.TEAM_FORMATION.WAREHOUSE_MANAGER
Feedback
hcm-checklist
en_MZ
प्रतिक्रिया
project1.TEAM_FORMATION.WAREHOUSE_MANAGER.ATTR1
overall co-ordination
hcm-checklist
en_MZ
समग्र समन्वय
project1.TEAM_FORMATION.WAREHOUSE_MANAGER.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
project1.TEAM_FORMATION.WAREHOUSE_MANAGER.ATTR2.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.TRAINING_SUPERVISION.WAREHOUSE_MANAGER
Supervision Feedback
hcm-checklist
en_MZ
पर्यवेक्षण प्रतिक्रिया
project1.TRAINING_SUPERVISION.WAREHOUSE_MANAGER.ATTR1
Supervision Work satisfied?
hcm-checklist
en_MZ
पर्यवेक्षण कार्य संतुष्ट?
project1.TRAINING_SUPERVISION.WAREHOUSE_MANAGER.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
project1.TRAINING_SUPERVISION.WAREHOUSE_MANAGER.ATTR2
Supervision Worked onTime?
hcm-checklist
en_MZ
पर्यवेक्षण ने समय पर काम किया?
project1.TRAINING_SUPERVISION.WAREHOUSE_MANAGER.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
project1.TRAINING_SUPERVISION.WAREHOUSE_MANAGER.ATTR3
Supervision overall co-ordination
hcm-checklist
en_MZ
पर्यवेक्षण का समग्र समन्वय
project1.WAREHOUSE.WAREHOUSE_MANAGER
Warehouses
hcm-checklist
en_MZ
गोदामों
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR1
The district warehouse and the staff comply with COVID-19 prevention measures (minimum distance of 1.5m, use of masks, use of disinfectants etc)
hcm-checklist
en_MZ
जिला गोदाम और कर्मचारी COVID-19 रोकथाम उपायों (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक का उपयोग आदि) का अनुपालन करते हैं
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR1.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR10
Does the warehouse have RTIs SHIPMENT GUIDE?
hcm-checklist
en_MZ
क्या गोदाम में RTIS शिपमेंट गाइड है?
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR10.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR11
If there was movement of RTIs (outside of the initial entry), was the Shipping Slip completed?
hcm-checklist
en_MZ
यदि आरटीआई (प्रारंभिक प्रविष्टि के बाहर) की आवाजाही थी, तो क्या शिपिंग स्लिप पूरी हो गई थी?
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR11.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR12
Does the warehouse have (Verify) the map of the flow of direct and reverse logistics?
hcm-checklist
en_MZ
क्या गोदाम में प्रत्यक्ष और रिवर्स लॉजिस्टिक्स के प्रवाह का नक्शा (सत्यापित) है?
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR12.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR13
Do you have (Check) the inventory flowchart in the warehouse?
hcm-checklist
en_MZ
या आपके पास गोदाम में इन्वेंट्री फ्लोचार्ट (चेक करें) है?
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR13.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR2
Does the warehouse have RTI stock forms?
hcm-checklist
en_MZ
क्या गोदाम में आरटीआई स्टॉक फॉर्म हैं?
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR2.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR3
Is the stock form completed?
hcm-checklist
en_MZ
क्या स्टॉक फॉर्म पूरा हो गया है?
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR3.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR4
Are all the header fields on the stock card filled in?
hcm-checklist
en_MZ
क्या स्टॉक कार्ड पर सभी हेडर फ़ील्ड भरे गए हैं?
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR4.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR5
Is the number of RTIS (bales) received equal to the number of planned RTIS (bales)? (See MPP)
hcm-checklist
en_MZ
क्या आरटीआई (गठरी) की संख्या नियोजित आरटीआई (गठरी) की संख्या के बराबर है? (एमपीपी देखें)
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR5.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR6
Are the RTI movement fields filled in?
hcm-checklist
en_MZ
क्या आरटीआई की आवाजाही क्षेत्र भरे गए हैं?
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR6.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR7
Are the RTI movement fields CORRECTLY filled in?
hcm-checklist
en_MZ
क्या आरटीआई की आवाजाही क्षेत्र सही ढंग से भरे हुए हैं?
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR7.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR8
Are the RTI movement fields filled in with the appropriate pen colors? (Red inputs, blue/black outputs)
hcm-checklist
en_MZ
क्या आरटीआई आवाजाही क्षेत्र उचित कलम के रंगों से भरे हुए हैं? (लाल इनपुट, नीला/काला आउटपुट)
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR8.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR9
Is there an INVENTORY record of the RTIs on the stock card every 15 days?
hcm-checklist
en_MZ
क्या हर 15 दिनों में स्टॉक कार्ड पर आरटीआई का एक इन्वेंट्री रिकॉर्ड है?
project1.WAREHOUSE.WAREHOUSE_MANAGER.ATTR9.ADDITIONAL_FIELD
Reason for cause
hcm-checklist
en_MZ
कारण का कारण
LLIN Angónia.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR1
The district warehouse and the warehouse workers (warehouse guards and custodians) have material and comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant)
hcm-checklist
en_MZ
जिला गोदाम और गोदाम कर्मचारियों (वेयरहाउस गार्ड और संरक्षक) के पास सामग्री है और COVID-19 के खिलाफ निवारक उपायों का अनुपालन करते हैं (न्यूनतम 1.5 मीटर की दूरी, मास्क का उपयोग, कीटाणुनाशक का उपयोग)
LLIN Angónia.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Angónia.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR2
Does the warehouse have a STOCK SHEET of RTIs?
hcm-checklist
en_MZ
क्या गोदाम में आरटीआई की स्टॉक शीट है?
LLIN Angónia.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Angónia.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR3
Is the stock sheet filled out?
hcm-checklist
en_MZ
क्या स्टॉक शीट भरी हुई है?
LLIN Angónia.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Angónia.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR4
Are all the fields in the header of the stock sheet filled in?
hcm-checklist
en_MZ
क्या स्टॉक शीट के हेडर में सभी फ़ील्ड भरे गए हैं?
LLIN Angónia.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Angónia.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR5
Is the number of RTIs (Bales) received equal to the number of RTIS (Bales) planned? (See MPP)
hcm-checklist
en_MZ
क्या आरटीआई (गठरी) की संख्या नियोजित आरटीआई (गठरी) की संख्या के बराबर है? (एमपीपी देखें)
LLIN Angónia.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR1
The district warehouse and the warehouse workers (warehouse guards and custodians) have material and comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant)
hcm-checklist
en_MZ
जिला गोदाम और गोदाम कर्मचारियों (वेयरहाउस गार्ड और संरक्षक) के पास सामग्री है और COVID-19 के खिलाफ निवारक उपायों का अनुपालन करते हैं (न्यूनतम 1.5 मीटर की दूरी, मास्क का उपयोग, कीटाणुनाशक का उपयोग)
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR2
Does the warehouse have a STOCK SHEET of RTIs?
hcm-checklist
en_MZ
क्या गोदाम में आरटीआई की स्टॉक शीट है?
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR3
Is the stock sheet filled out?
hcm-checklist
en_MZ
क्या स्टॉक शीट भरी हुई है?
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR4
Are all the fields in the header of the stock sheet filled in?
hcm-checklist
en_MZ
क्या स्टॉक शीट के हेडर में सभी फ़ील्ड भरे गए हैं?
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR5
Is the number of RTIs (Bales) received equal to the number of RTIS (Bales) planned? (See MPP)
hcm-checklist
en_MZ
क्या आरटीआई (गठरी) की संख्या नियोजित आरटीआई (गठरी) की संख्या के बराबर है? (एमपीपी देखें)
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Tete.WAREHOUSE.PROVINCIAL_SUPERVISOR.ATTR1
Does the warehouse have a STOCK SHEET of RTIs?
hcm-checklist
en_MZ
क्या गोदाम में आरटीआई की स्टॉक शीट है?
LLIN Tete.WAREHOUSE.PROVINCIAL_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Tete.WAREHOUSE.PROVINCIAL_SUPERVISOR.ATTR2
Are the fields of the RTI movement CORRECTLY filled in?
hcm-checklist
en_MZ
"क्या आरटीआई की आवाजाही क्षेत्र सही ढंग से भरे हुए हैं?"
LLIN Tete.WAREHOUSE.PROVINCIAL_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Tete.WAREHOUSE.PROVINCIAL_SUPERVISOR.ATTR3
Are the fields of the RTIs movement filled in with the appropriate pen colors? (Red entries, blue/black exits)
hcm-checklist
en_MZ
क्या आरटीआई आवाजाही क्षेत्र उचित कलम के रंगों से भरे हुए हैं? (लाल इनपुट, नीला/काला आउटपुट)
LLIN Tete.WAREHOUSE.PROVINCIAL_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Tete.WAREHOUSE.PROVINCIAL_SUPERVISOR.ATTR4
Is there a record of INVENTORY of RTIs in the stock sheet every 15 days?
hcm-checklist
en_MZ
क्या हर 15 दिनों में स्टॉक शीट में आरटीआई की इन्वेंट्री का रिकॉर्ड है?
LLIN Tete.WAREHOUSE.PROVINCIAL_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Tete.WAREHOUSE.PROVINCIAL_SUPERVISOR.ATTR5
Does the warehouse have a SHIPPING DOCUMENT for RTIs?
hcm-checklist
en_MZ
क्या गोदाम के पास आरटीआई के लिए एक शिपिंग दस्तावेज़ है?
LLIN Tete.WAREHOUSE.PROVINCIAL_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Ulongué.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR1
Do the training site and the teams comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant and/or hand washing with soap and water or ash)?
hcm-checklist
en_MZ
क्या प्रशिक्षण स्थल और टीमें COVID-19 (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक का उपयोग और/या साबुन और पानी या राख के साथ हाथ धोने) के खिलाफ निवारक उपायों का पालन करती हैं?
LLIN Ulongué.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Ulongué.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR2
Does the training have an agenda?
hcm-checklist
en_MZ
क्या प्रशिक्षण में एक एजेंडा है?
LLIN Ulongué.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Ulongué.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR3
Do the teams have an electronic device?
hcm-checklist
en_MZ
क्या टीमों के पास एक इलेक्ट्रॉनिक डिवाइस है?
LLIN Ulongué.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Ulongué.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR4
Are all electronic devices operational?
hcm-checklist
en_MZ
क्या सभी इलेक्ट्रॉनिक उपकरण चालू हैं?
LLIN Ulongué.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Ulongué.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR5
Is the District M&E Officer part of the training? (applicable if he/she was not present at the provincial microplanning)
hcm-checklist
en_MZ
क्या जिला एम एंड ई अधिकारी प्रशिक्षण का हिस्सा है? (यदि वह प्रांतीय माइक्रोप्लानिंग में उपस्थित नहीं था तो लागू)
LLIN Ulongué.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Dómuè.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR1
Do the training site and the teams comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant and/or hand washing with soap and water or ash?
hcm-checklist
en_MZ
क्या प्रशिक्षण साइट और टीमें COVID-19 (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक का उपयोग और/या साबुन और पानी या राख के साथ हाथ धोने के लिए निवारक उपायों का पालन करती हैं?
LLIN Dómuè.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Dómuè.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR2
Does the training have an agenda?
hcm-checklist
en_MZ
क्या प्रशिक्षण में एक एजेंडा है?
LLIN Dómuè.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Dómuè.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR3
Do the teams have an electronic device?
hcm-checklist
en_MZ
क्या टीमों के पास एक इलेक्ट्रॉनिक डिवाइस है?
LLIN Dómuè.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Dómuè.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR4
Are all electronic devices operational?
hcm-checklist
en_MZ
क्या सभी इलेक्ट्रॉनिक उपकरण चालू हैं?
LLIN Dómuè.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Dómuè.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR5
Is the District M&E Officer part of the training? (applicable if he/she was not present at the provincial microplanning)
hcm-checklist
en_MZ
क्या जिला एम एंड ई अधिकारी प्रशिक्षण का हिस्सा है? (यदि वह प्रांतीय माइक्रोप्लानिंग में उपस्थित नहीं था तो लागू)
LLIN Dómuè.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Chioco.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR1
Do the training site and the teams comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant and/or hand washing with soap and water or ash?
hcm-checklist
en_MZ
क्या प्रशिक्षण साइट और टीमें COVID-19 (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक का उपयोग और/या साबुन और पानी या राख के साथ हाथ धोने के लिए निवारक उपायों का पालन करती हैं?
LLIN Chioco.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Chioco.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR2
Does the training have an agenda?
hcm-checklist
en_MZ
क्या प्रशिक्षण में एक एजेंडा है?
LLIN Chioco.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Chioco.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR3
Do the teams have an electronic device?
hcm-checklist
en_MZ
क्या टीमों के पास एक इलेक्ट्रॉनिक डिवाइस है?
LLIN Chioco.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Chioco.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR4
Are all electronic devices operational?
hcm-checklist
en_MZ
क्या सभी इलेक्ट्रॉनिक उपकरण चालू हैं?
LLIN Chioco.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Chioco.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR5
Is the District M&E Officer part of the training? (applicable if he/she was not present at the provincial microplanning)
hcm-checklist
en_MZ
क्या जिला एम एंड ई अधिकारी प्रशिक्षण का हिस्सा है? (यदि वह प्रांतीय माइक्रोप्लानिंग में उपस्थित नहीं था तो लागू)
LLIN Chioco.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Kazula.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR1
Do the training site and the teams comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant and/or hand washing with soap and water or ash?
hcm-checklist
en_MZ
क्या प्रशिक्षण साइट और टीमें COVID-19 (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक का उपयोग और/या साबुन और पानी या राख के साथ हाथ धोने के लिए निवारक उपायों का पालन करती हैं?
LLIN Kazula.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Kazula.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR2
Does the training have an agenda?
hcm-checklist
en_MZ
क्या प्रशिक्षण में एक एजेंडा है?
LLIN Kazula.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Kazula.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR3
Do the teams have an electronic device?
hcm-checklist
en_MZ
क्या टीमों के पास एक इलेक्ट्रॉनिक डिवाइस है?
LLIN Kazula.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Kazula.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR4
Are all electronic devices operational?
hcm-checklist
en_MZ
क्या सभी इलेक्ट्रॉनिक उपकरण चालू हैं?
LLIN Kazula.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Kazula.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR5
Is the District M&E Officer part of the training? (applicable if he/she was not present at the provincial microplanning)
hcm-checklist
en_MZ
क्या जिला एम एंड ई अधिकारी प्रशिक्षण का हिस्सा है? (यदि वह प्रांतीय माइक्रोप्लानिंग में उपस्थित नहीं था तो लागू)
LLIN Kazula.TRAINING_SUPERVISION.FIELD_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Ulongué.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR1
The registration and distribution teams, including the assistant, have material and comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant and/or washing
hcm-checklist
en_MZ
सहायक सहित पंजीकरण और वितरण टीमों के पास सामग्री है और COVID-19 (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक और/या धोने का उपयोग करने के लिए निवारक उपायों का अनुपालन है।
LLIN Ulongué.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Ulongué.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR2
Is there a map with a calendar/route and daily distribution of the teams to the communities?
hcm-checklist
en_MZ
क्या समुदायों के लिए एक कैलेंडर/मार्ग और टीमों के दैनिक वितरण के साथ एक नक्शा है?
LLIN Ulongué.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Ulongué.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR3
Are registration and distribution teams organized as planned? Check presence of registrar, distributor and assistant.
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों को योजना के रूप में आयोजित किया जाता है? रजिस्ट्रार, वितरक और सहायक की उपस्थिति की जाँच करें।
LLIN Ulongué.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Ulongué.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR4
Do the registration and distribution teams have a functioning electronic device?
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों में एक कार्यशील इलेक्ट्रॉनिक डिवाइस है?
LLIN Ulongué.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Ulongué.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR5
Is the entry of registration and distribution data into the platform performed daily?
hcm-checklist
en_MZ
क्या मंच में पंजीकरण और वितरण डेटा का प्रवेश दैनिक किया गया है?
LLIN Ulongué.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Dómuè.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR1
The registration and distribution teams, including the assistant, have material and comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant and/or washing
hcm-checklist
en_MZ
सहायक सहित पंजीकरण और वितरण टीमों के पास सामग्री है और COVID-19 (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक और/या धोने का उपयोग करने के लिए निवारक उपायों का अनुपालन है।
LLIN Dómuè.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Dómuè.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR2
Is there a map with a calendar/route and daily distribution of the teams to the communities?
hcm-checklist
en_MZ
क्या समुदायों के लिए एक कैलेंडर/मार्ग और टीमों के दैनिक वितरण के साथ एक नक्शा है?
LLIN Dómuè.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Dómuè.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR3
Are registration and distribution teams organized as planned? Check presence of registrar, distributor and assistant.
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों को योजना के रूप में आयोजित किया जाता है? रजिस्ट्रार, वितरक और सहायक की उपस्थिति की जाँच करें।
LLIN Dómuè.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Dómuè.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR4
Do the registration and distribution teams have a functioning electronic device?
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों में एक कार्यशील इलेक्ट्रॉनिक डिवाइस है?
LLIN Dómuè.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Dómuè.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR5
Is the entry of registration and distribution data into the platform performed daily?
hcm-checklist
en_MZ
क्या मंच में पंजीकरण और वितरण डेटा का प्रवेश दैनिक किया गया है?
LLIN Dómuè.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Chioco.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR1
The registration and distribution teams, including the assistant, have material and comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant and/or washing
hcm-checklist
en_MZ
सहायक सहित पंजीकरण और वितरण टीमों के पास सामग्री है और COVID-19 (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक और/या धोने का उपयोग करने के लिए निवारक उपायों का अनुपालन है।
LLIN Chioco.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Chioco.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR2
Is there a map with a calendar/route and daily distribution of the teams to the communities?
hcm-checklist
en_MZ
क्या समुदायों के लिए एक कैलेंडर/मार्ग और टीमों के दैनिक वितरण के साथ एक नक्शा है?
LLIN Chioco.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Chioco.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR3
Are registration and distribution teams organized as planned? Check presence of registrar, distributor and assistant.
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों को योजना के रूप में आयोजित किया जाता है? रजिस्ट्रार, वितरक और सहायक की उपस्थिति की जाँच करें।
LLIN Chioco.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Chioco.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR4
Do the registration and distribution teams have a functioning electronic device?
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों में एक कार्यशील इलेक्ट्रॉनिक डिवाइस है?
LLIN Chioco.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Chioco.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR5
Is the entry of registration and distribution data into the platform performed daily?
hcm-checklist
en_MZ
क्या मंच में पंजीकरण और वितरण डेटा का प्रवेश दैनिक किया गया है?
LLIN Chioco.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Kazula.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR1
The registration and distribution teams, including the assistant, have material and comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant and/or washing
hcm-checklist
en_MZ
सहायक सहित पंजीकरण और वितरण टीमों के पास सामग्री है और COVID-19 (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक और/या धोने का उपयोग करने के लिए निवारक उपायों का अनुपालन है।
LLIN Kazula.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Kazula.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR2
Is there a map with a calendar/route and daily distribution of the teams to the communities?
hcm-checklist
en_MZ
क्या समुदायों के लिए एक कैलेंडर/मार्ग और टीमों के दैनिक वितरण के साथ एक नक्शा है?
LLIN Kazula.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Kazula.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR3
Are registration and distribution teams organized as planned? Check presence of registrar, distributor and assistant.
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों को योजना के रूप में आयोजित किया जाता है? रजिस्ट्रार, वितरक और सहायक की उपस्थिति की जाँच करें।
LLIN Kazula.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Kazula.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR4
Do the registration and distribution teams have a functioning electronic device?
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों में एक कार्यशील इलेक्ट्रॉनिक डिवाइस है?
LLIN Kazula.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Kazula.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR5
Is the entry of registration and distribution data into the platform performed daily?
hcm-checklist
en_MZ
क्या मंच में पंजीकरण और वितरण डेटा का प्रवेश दैनिक किया गया है?
LLIN Kazula.TEAM_FORMATION.FIELD_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Angónia.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR1
The registration and distribution teams, including the assistant, have material and comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant and/or washing
hcm-checklist
en_MZ
सहायक सहित पंजीकरण और वितरण टीमों के पास सामग्री है और COVID-19 (1.5 मीटर की न्यूनतम दूरी, मास्क का उपयोग, कीटाणुनाशक और/या धोने का उपयोग करने के लिए निवारक उपायों का अनुपालन है।
LLIN Angónia.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Angónia.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR2
Is there a map with a calendar/route and daily distribution of the teams to the communities?
hcm-checklist
en_MZ
क्या समुदायों के लिए एक कैलेंडर/मार्ग और टीमों के दैनिक वितरण के साथ एक नक्शा है?
LLIN Angónia.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Angónia.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR3
Are registration and distribution teams organized as planned? Check presence of registrar, distributor and assistant.
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों को योजना के रूप में आयोजित किया जाता है? रजिस्ट्रार, वितरक और सहायक की उपस्थिति की जाँच करें।
LLIN Angónia.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Angónia.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR4
Do the registration and distribution teams have a functioning electronic device?
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों में एक कार्यशील इलेक्ट्रॉनिक डिवाइस है?
LLIN Angónia.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Angónia.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR5
Is the entry of registration and distribution data into the platform performed daily?
hcm-checklist
en_MZ
क्या मंच में पंजीकरण और वितरण डेटा का प्रवेश दैनिक किया गया है?
LLIN Angónia.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR1
The registration and distribution teams, including the assistant, have material and comply with the preventive measures against COVID-19 (minimum distance of 1.5m, use of masks, use of disinfectant and/or washing
hcm-checklist
en_MZ
सहायक सहित पंजीकरण और वितरण टीमों के पास सामग्री है और COVID-19 के खिलाफ निवारक उपायों का अनुपालन करते हैं (न्यूनतम 1.5 मीटर की दूरी, मास्क का उपयोग, कीटाणुनाशक और/या धोने का उपयोग)
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR1.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR2
Is there a map with a calendar/route and daily distribution of the teams to the communities?
hcm-checklist
en_MZ
क्या समुदायों के लिए एक कैलेंडर/मार्ग और टीमों के दैनिक वितरण के साथ एक नक्शा है?
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR2.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR3
Are registration and distribution teams organized as planned? Check presence of registrar, distributor and assistant.
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों को योजना के रूप में आयोजित किया जाता है? रजिस्ट्रार, वितरक और सहायक की उपस्थिति की जाँच करें।
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR3.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR4
Do the registration and distribution teams have a functioning electronic device?
hcm-checklist
en_MZ
क्या पंजीकरण और वितरण टीमों में एक कार्यशील इलेक्ट्रॉनिक डिवाइस है?
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR4.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR5
Is the entry of registration and distribution data into the platform performed daily?
hcm-checklist
en_MZ
क्या प्लेटफॉर्म में पंजीकरण और वितरण डेटा का प्रवेश दैनिक किया गया है?
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR.ATTR5.ADDITIONAL_FIELD
Reason
hcm-checklist
en_MZ
कारण
MANAGE_STOCK_LABEL
Manage Stocks
hcm-stock
en_MZ
स्टॉक प्रबंधित करें
MANAGE_STOCK_RECORDSTOCK_RECEIPT_LABEL
Record Stock Receipt
hcm-stock
en_MZ
प्राप्त स्टॉक के लिए रिकॉर्ड
MANAGE_STOCK_RECEIPT_DESCRIPTION
Create records for stock received at the warehouse
hcm-stock
en_MZ
गोदाम में प्राप्त स्टॉक के लिए रिकॉर्ड बनाएं
MANAGE_STOCK_RECORDSTOCK_ISSUED_LABEL
Record Stock Issued
hcm-stock
en_MZ
जारी किए गए स्टॉक के लिए रिकॉर्ड
MANAGE_STOCK_RECORDSTOCK_ISSUED_DESCRIPTION
Create records for stock sent out from the warehouse
hcm-stock
en_MZ
गोदाम से बाहर भेजे गए स्टॉक के लिए रिकॉर्ड बनाएं
MANAGE_STOCK_RECORDSTOCK_RETURNED_LABEL
Stock Returned
hcm-stock
en_MZ
लौटाए गए स्टॉक के लिए रिकॉर्ड
MANAGE_STOCK_RECORDSTOCK_RETURNED_DESCRIPTION
Create records for the stock returned to the warehouse
hcm-stock
en_MZ
गोदाम में लौटाए गए स्टॉक के लिए रिकॉर्ड बनाएं
MANAGE_STOCK_RECORDSTOCK_DAMAGED_LABEL
Stock Damaged
hcm-stock
en_MZ
क्षतिग्रस्त स्टॉक
MANAGE_STOCK_RECORDSTOCK_DAMAGED_DESCRIPTION
Record the list of resources damaged during campaign operations
hcm-stock
en_MZ
अभियान संचालन के दौरान क्षतिग्रस्त संसाधनों की सूची रिकॉर्ड करें
MANAGE_STOCK_RECORDSTOCK_LOSS_LABEL
Stock Loss
hcm-stock
en_MZ
स्टॉक हानि
MANAGE_STOCK_RECORDSTOCK_LOSS_DESCRIPTION
Record the list of resources lost during campaign operations
hcm-stock
en_MZ
अभियान संचालन के दौरान खोए हुए संसाधनों की सूची रिकॉर्ड करें
NO_PROJECT_SELECTED
No Project Selected
hcm-stock
en_MZ
कोई परियोजना नहीं चुनी
STOCK_RECONCILIATION_FILED_REQUIRED
Field is required
hcm-stock-reconciliation
en_MZ
ये स्थान भरा जाना है
en_MZ
en_MZ
User ID is Required
en_MZ
Login
User ID
Password is Required
en_MZ
Login
Password
Unable to login
en_MZ
Login
Min 2 characters required
en_MZ
Additional Field
Name is required
en_MZ
Individual details
Individual Name
Required
en_MZ
Individual details
ID Type
ID Number is required
en_MZ
Individual details
ID Number
Age should be less than 150
en_MZ
Individual details
Date of birth Age
Enter only numbers
en_MZ
Individual details
Mobile number
Field is required
en_MZ
Deliver Intervention
Select Resource
Required
en_MZ
Received Stock Details
Warehouse
Number
en_MZ
Received Stock Details
Quantity Received
CORE_COMMON_REQUIRED
Required field cannot be empty
hcm-common
en_MZ
Checklist
CORE_COMMON_LANGUAGE
Language
hcm-common
en_MZ
भाषा
CORE_COMMON_HOME
Home
hcm-common
en_MZ
होम
CORE_COMMON_SYNC_PROGRESS
Sync in progress
hcm-common
en_MZ
सिंक हो रहा है
CORE_COMMON_DATA_SYNCED
Data Synced
डेटा सिंक हो गया है
CORE_COMMON_DATA_SYNC_FAILED
Sync Failed!
सिंक असफल!
CORE_COMMON_DATA_SYNC_RETRY
Retry
पुन: प्रयास करें
Members
Members
hcm-beneficiary
en_MZ
सदस्य
LLIN Changara.TEAM_FORMATION.DISTRICT_SUPERVISOR
Team Formation Checklist
hcm-checklist
टीम गठन चेकलिस्ट
LLIN Changara.WAREHOUSE.DISTRICT_SUPERVISOR
Warehouse Inspection Checklist
hcm-checklist
गोदाम निरीक्षण चेकलिस्ट
Find the mock-ups below:
HCM Homescreen
After logging into the application, the user lands on this screen which displays daily performance (number of households registered). The progress bar must reset daily at 00:00 hours and start from 0 registrations. The action buttons related to the beneficiary are present which include:
Beneficiaries
View Reports
Sync Data
Call Supervisor
File Complaint
At the bottom, there is a card that shows how many records are unsynced for the user’s convenience to sync data. If all the records are synced, then the card must say, “All records are synced.”
The help button is on every screen of the application, and by clicking on it a user can get the walkthrough of the elements on that screen.
On the top right, the administrative area assigned to the user is displayed which will be based on the level of hierarchy. The hamburger button on the top left corner covers some other actions mentioned further.
Find the mockups below:
After successful login, a user lands on the home screen of inventory management which consists of the following actions and elements:
Manage Stock
Stock Reconciliation
View Reports
Sync Data
Call Supervisor
File Complaint
There is a location picker on the top right that displays the assigned boundary for the user. The help button provides a walkthrough of the screen to the user. The hamburger button on the top left consists of a few quick actions. The location picker, help button, and hamburger buttons are available on every screen for a user’s convenience.
After clicking on the hamburger button, a list of actions appears on the user screen. On top, it displays the user name and contact number, followed by other options such as the home button, language select, edit profile, projects, and logout. The “Edit Profile” option is not in scope for V1; it needs to be taken in V1.1 If the user clicks on the hamburger button again, it collapses the hamburger menu. The button is available on all screens of the application.
This screen consists of different types of transactions that take place for the inventory. These include:
Stock Receipt
Stock Issued
Stock Returned
Stock Damaged
Stock Loss
Every transaction has a separate card with an arrow button, an icon, and a brief description below the title. Clicking on the arrow button will navigate the user to the warehouse details screen. The back button is located below the hamburger button, which takes the user to the previous screen (In this case, it is the home screen).
If the user is not assigned any warehouse, then an error popup must appear over the warehouse details screen, asking the user to contact the system administrator to assign a warehouse. The user must be able to close the popup and change the administrative area on the warehouse details screen to check if he/she is assigned any warehouse in any other boundary. This must force the screen to load again and check for the warehouse.
When the user clicks on record stock receipt, the warehouse details screen will appear. The latitude/longitude captures the Geo-location of the warehouse which can be fetched with the help of the location icon within the field. It is a mandatory field denoted by *. The warehouse name/ID is a dropdown field which contains the list of warehouses assigned to the project for a particular user. If there is only one warehouse, the field must be auto-populated by the system.
The date of receipt field captures the date of transaction which can be fetched with the help of a calendar icon placed inside the box. The field must be validated, where the date cannot be in the future. If the user puts a future value, it must show an error message stating “date cannot be in future”. The user must select the administrative unit from the dropdown of the administrative unit field. The next button navigates the user to the stock receipt details screen.
The user must provide details of the stock received. The select product field has a dropdown that consists of all the products under a campaign. The user can select from the list the desired product that he has received. The type of transaction is provided to specify whether the stock is being received, issued, or returned.
In the ‘received from’ section, the user needs to select from the dropdown the warehouse from which the stock is being received. The dropdown must contain the list of all the warehouses that are part of the campaign, that is, the list must be of the warehouse assigned to the root project. The list is taken from the facility registry and must be the same for all the transactions. The quantity received field collects the information for how much quantity of stock is being received.
For a pack of a certain number of nets, there is a packing slip attached to the packet which indicates the number of nets within that pack. The user needs to mention the value in the number of nets field.
The total number of packing slips must be mentioned in the following field. The user can add any comments/remarks in the additional comments field. The following - select product, type of transaction, received from, and quantity received fields - are mandatory for this screen. When the user has entered all the details, he must click on the submit button which leads to the confirmation screen whether the record has been created successfully or there are some errors.
When the user clicks on the submit button, he/she lands on this page with the confirmation message “Record created Successfully”. Users can go back to the home screen by clicking on the “Back To Home” button. This screen must appear for every other transaction (issued, returned, damaged, lost, reconciliation).
When the user clicks on record stock issued, the warehouse details screen will appear. The screen is similar to the stock receipt one. The only difference is that instead of the date of receipt, the field is the date of issue. The next button navigates the user to the stock issued details screen.
The user needs to provide details for the stock issued. The select product field acts the same as that for stock receipt. In the destination field, the user needs to select the warehouse where the stock is being sent. The quantity sent field collects the information on how much quantity of stock is being sent. When the user has entered all the details, he must click on the submit button which leads to the confirmation screen whether the record has been created successfully or there are some errors.
When the user clicks on stock returned, the warehouse details screen appears. The fields are similar to that for stock receipt; only the date of receipt label is changed to the date of return. The next button navigates the user to the stock returned details screen.
The user needs to provide details for the stock returned. The “Select product” field acts the same as that for stock receipt. In the “Returned from” field, the user needs to select the warehouse from where the stock has been returned. The “Quantity returned” field collects the information for how much quantity of stock has been returned. When the user has entered all the details, he/she must click on the submit button which leads to the confirmation screen that confirms whether the record has been created successfully or there are some errors.
For the damaged stock, the user must provide the details asked on the screen.
The user needs to provide the details for the damaged stock. There can be two cases for the damaged stock:
If the stock is damaged during transit, then the user must select the warehouse name from where the stock was received.
If the stock is damaged during storage, then the user must select N/A from the dropdown.
The user needs to provide the details for the lost stock.
The user must provide the details for the stock loss.
Stock Reconciliation
When the user clicks on the stock reconciliation button on the home screen, they are navigated to this screen where they need to verify whether the physical count and calculated stock values are the same or not. In the select product field, the user needs to select a product from the dropdown. There are warehouse name and administrative area fields as well, all of which are mandatory. The following details are there:
Date of Reconciliation
Received Stock
Issued Stock
Returned Stock
Damaged Stock
Stock Lost
Stock on Hand- The stock on hand is calculated as incoming stock minus outgoing stock. There is a hint icon for how the stock on hand is calculated. The received and returned stocks will be considered incoming stocks. The issued, damaged and lost stocks will be considered outgoing stocks.
The date of reconciliation is system-generated and non-editable. Other values are calculated based on the data recorded in stock receipts, stock issued, and the stock returned screens. In the manual stock count, the user needs to enter the value for manually counted inventory. If the stock on hand does not match the physical count, then the latter must take precedence, provided the user has submitted the form with a proper reason. In the comments field, the user can add remarks and comments.
When a user clicks on the view reports button on the home screen, he/she is navigated to this page where he/she has the provision to view the following reports:
Stock Received
Stock Issued
Stock Returned
Stock Reconciliation
Users can click on the arrow button placed next to every transaction to open the respective report. The back button will navigate them back to the home screen.
When the user clicks on the “Stock Received” button, the report for stock received appears which provides a tabular representation of the data. The table is scrollable, both vertically and horizontally, to cater to multiple values and columns. The date column is kept frozen and other columns are scrollable. The first column is for the date of the receipt, followed by units received in the second column, and received from (warehouse name) in the third column. The “Back To Home” button is placed at the bottom of the screen which navigates the user back to the home screen.
For the stock reconciliation report, the table consists of the date in the first column and other columns. The “Back To Home” button will navigate users to the home screen.
Find the mockups below:
After logging into the application, the user lands on this screen which displays daily performance (number of households registered). The progress bar must reset daily at 00:00 hours and start from 0 registrations. The action buttons related to the beneficiary are present, which include:
Beneficiaries
View reports
Sync data
Call supervisor
Complaints
At the bottom, there is a card that shows how many records are unsynced for the user’s convenience to sync data. The help button is on every screen of the application. By clicking on it, a user can get the walkthrough of the elements on that screen.
On the top right, the administrative area assigned to the user is displayed, which will be based on the level of hierarchy. The hamburger button on the top left corner covers some other actions mentioned further.
When the user clicks on the complaints, she is navigated to the “My Complaints” screen, which consists of two actions:
File a complaint (primary action): Clicking on this must open the complaint type screen.
View previously logged complaints.
Complaint Type
When the user clicks on file a complaint, the complaint type screen appears. The user must select the type of complaint from the list, which must be configurable (to be configured during implementation as per program requirements).
There is a ‘Next’ button at the bottom of the screen, clicking on which, the user is navigated to the complaint details screen.
Complaint Details
Once the user has selected the type of complaint and clicked on ‘Next’, this screen appears, where they need to provide the complaint details.
The date field is auto-captured by the system, which must be non-editable.
The administrative area is also auto-captured but it is editable. It is editable in case the user is creating the complaint on someone’s behalf. The dropdown displays a list of boundaries that are assigned to the user.
The user needs to select whether she is raising a complaint for herself or on behalf of another user.
If the user wants to raise a complaint for herself, then she must provide the following details:
Name (must be populated if already available in the user’s profile else must be blank).
Contact number (must be populated if already available in the user’s profile else must be blank).
Supervisor’s name and contact number.
If the complaint is raised on behalf of another user, then her details must be captured in the above fields. The user has the option to upload images describing the issue along with a text-based description. If the user wants to change the type of complaint, they can click on the ‘Back’ button and return to the previous screen.
After filling in all the details, the user needs to click on the ‘Submit’ button to file the complaint.
Confirmation Screen
When the user clicks on the submit button after providing all the complaint details, the confirmation screen appears, which provides information on whether the complaint has been submitted or not.
If the complaint has been submitted, then it must show the message to sync the data for generating the complaint number. There must be a back to home button below the message. When the user clicks on it, she must be navigated to the home screen.
If the complaint has not been submitted, then there must be two buttons available; Retry and Back to Home.
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 an appropriate action (mentioned below).
The helpdesk user must be able to do the following :
View 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
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 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.
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.
Find the mock-ups below:
After logging into the application, the user lands on this screen which displays the daily performance (number of households registered). The progress bar must reset daily at 00:00 hours and start from 0 registrations.
The action buttons related to the beneficiary are present, which include:
Beneficiaries
Sync Data
Call Supervisor
File Complaint
At the bottom, there is a card that shows how many records are unsynced for the user’s convenience to sync data. If all the records are synced, then the card must say “All records are synced”. The help button is on every screen of the application, clicking on which a user can get a walkthrough of the elements on that screen.
On the top right, the administrative area assigned to the user is displayed, which will be based on the level of hierarchy. The hamburger button on the top left corner covers some other actions mentioned further.
After clicking on the hamburger button, a list of actions appears on the user screen. The top displays the user name and contact number, followed by other options such as the home button, language select, edit profile, projects, and logout. The ‘Edit Profile’ option is not in scope for V1, it needs to be taken in V1.1
If the user clicks on the hamburger button again, it collapses the hamburger menu. The button is available on all screens of the application.
The user can edit his/her name, and phone number, and select the gender. After updating the details, the user needs to click on the save button which opens a prompt stating “saved successfully”.
If the user does not want to make any changes, he/she can click on the back button, which will take them back to the hamburger menu. Not in scope for V1.0, needs to be taken in V1.1.
When a user clicks on the projects option in the hamburger menu, it navigates them to the project selection screen, from where the user can select another project to work on.
Though the automatic sync is triggered by the login action, after selecting another project, the system must now sync the data for the new project, and the same flow must be followed.
For a user assigned multiple boundaries, after logging in, the boundary selection overlay must appear. This forces the user to select a boundary, only after which the user will be able to view the home screen. The user can then change the boundary whenever required from the location picker placed on the top right.
It has dropdown fields to select the boundary, which depends on the hierarchy level of the user. For example, in the case of an FLW, the boundary selection starts from the administrative post. The values in the dropdown are linked to the higher hierarchy and the user cannot select a boundary if the previous field is left blank.
The dropdown must only consist of the boundaries that are assigned to the user, not all the boundaries under a particular hierarchy. For example, if the user is assigned localities 1, 2, and 3, and there are 5 localities in all under admin post 1, then the dropdown must have only 1, 2, and 3 localities.
At least the highest boundary must be selected to enable the select button, which navigates the user to the home screen. For multiple projects, sync needs to download the data only for the selected project.
If the user clicks on the help button, it will give a walkthrough of the entire screen, including the role of each button placed with two buttons:
Skip: If the user wants to skip the walkthrough at any point.
Next: It will proceed to the next action aligned.
The text box appears at the bottom of the button.
When a user clicks on the ‘Beneficiaries’ button, they will be navigated to this screen. It displays the number of households registered along with the number of bednets delivered in that administrative area.
The register button is primarily disabled to ensure that the user performs the search action.
The search bar allows the user to search by the household head’s name and the system provides the search results. The minimum string length to show results is 2 characters and the order of the results will be the last record displayed first. Two cases can be generated:
No results are displayed.
The search results displayed do not match.
Both cases are discussed further. The ‘Back’ button on the top will navigate to the home screen.
If a user is searching for a household and there are no households registered by that name, it will display: “Match not found! Register New Household button to add details”. The register button is enabled to proceed with the household registration. When the user clicks on the “Register New Household” button, it takes them to the “Household Location” screen.
If the user searches for a household by the name Jose, for example, all the household cards by the name Jose will be displayed. The cards will provide details such as the household name, members in the household, service delivery status, administrative area, and a dropdown arrow at the centre.
The open button at the right corner of each card is for the user’s understanding to open the household card. The search results displayed must be 10 at a time followed by pagination for the next 10 results.
At the end of the search results, a query message is displayed stating “Match not found” and the register button is enabled. If the results do not match, the user can click on the register button for household registration. The back button will take them to the home screen.
After the user searches for a household, the search results are displayed with a dropdown arrow. The dropdown has a significant circular area of touch response for the user. When the user clicks on the dropdown, it will expand and display the tabular data of all the members in that particular household. The table is scrollable, both vertically as well as horizontally, but the card dimension of the dropdown must remain fixed to show 5 members.
The table must not display the household head icon ‘H’, as shown on the individual level screen. This will help the user to verify whether it is their household or not. In the beneficiary column, only the first 14 characters will be displayed.
Since there are no separate fields for first name and last name, the cell will count 14 characters, counting space as 1 character. If it is the same household, the user can click on the ‘Open’ button on the card, which will open the household card. The ‘Back’ button will take the user to the home screen.
In this case, a column for delivery status is added to the table. The format for the delivery status must be the same for every screen wherever the status needs to be displayed. The format is check mark+status. The household-level delivery status is omitted in this case.
Household registration begins from this screen. The user needs to provide the location details of the household. The administrative area field must be auto-captured from the boundary selected, which is mandatory, denoted by * and is non-editable. If the user wants to change the area, he/she can click on the location picker on the top, which opens the boundary selection screen.
The system must fetch the lat/long coordinates of the household. If it is unable to detect the coordinates, it will be left blank in the dashboard to avoid errors.
The back button takes the user to the “List of Households” screen. The ‘Next’ button at the bottom takes them to the “Household Details” screen.
The “Date of Registration” is auto-populated by the system, and is non-editable. The user provides the details on the total number of members in a particular household with the help of the increment/decrement buttons on both sides. The field must default to one and validation must be applied, where at least one member should be there in a household for registration.
After providing the numbers, the user clicks on the ‘Next’ button at the bottom of the screen, which will navigate them to the ‘Individual Details’ screen.
In the name field, the system fetches the name from the search action performed on the beneficiaries screen, which is editable. The first individual will be the head of the household by default, denoted by a checkbox below the field. The checkbox must be non-editable as the users are trained in such a way that the first member registered should always be the household head.
The name, ID type, and ID number fields are kept mandatory for data collection. The ID type is a dropdown field where the individual must provide the type of ID they hold if any. The ID types must be configured in the MDMS.
If the individual does not hold any ID, an option for ‘System generated ID’ must be there, which will inform the system to generate an ID for that individual. In “ID Number”, the user needs to enter the individual’s ID number. If the user selects a system-generated ID, then this field must be disabled. The system must capture the ID number when the device is online and sync can take place.
The “Date of birth” is a calendar input field, where the individual’s birth date is entered. If the individual does not know his/her date of birth, there is an option to enter the age. The system captures only the date of birth at the backend, which is described in the two cases below:
If the user enters the date of birth, the age field is disabled. The system captures the exact date entered.
If the user has entered the age, the date of birth field must remain editable (date of birth takes precedence over age).
If age has been entered, the date captured by the system must be the first day of January and the year must be the difference between the current year and age. For example, if the user has entered the age 23, then the date captured must be 01-01-2000 (as of 2023).
During the edit flow, the application user must not see the system-derived date. This means that while creating the record, the user had input age and the system calculated the date of birth as 01-01-XXXX, but during the edit flow, only the data entered by the user while creating the record must be visible to the user.
If the user has entered age (Eg. 23) in the current year, the system must derive the date as 01-01-2000. After a year, during the edit flow, the age displayed must be 24 (incremented by 1 year).
The date of birth field must be validated where the value cannot be in the future, and if a user has entered a future date, then an error message must appear stating the date cannot be in the future. Gender is a dropdown field to select the individual’s gender. The user needs to enter the mobile number of the individual if they have a mobile phone.
At the bottom, there is a ‘Submit’ button, clicking on which the user can register the beneficiary into the system. For every submit action, the system validates the information entered. If the user enters incomplete or incorrect data, clicking on the submit button will show an error message above it, along with the validated message below the field (as shown in the adjacent screen).
When the user clicks on the ‘Submit’ button, a popup appears asking for confirmation. If the user wants to edit any detail, they can click on the ‘Cancel’ button, which will take the user back to the previous screen. If the user clicks on ‘Submit’, the household is registered and the household card is opened.
Once the user clicks on the submit button, the acknowledgement screen appears providing the information that the data has been recorded successfully. When the user clicks on “Back to Search”, he/she must be navigated to the search household screen.
After registering the household, the user can search for the household and open the card. The household name is displayed as household only, to avoid the risk of names that may be longer. There is also an ‘Edit Household’ button for editing household details, which navigates the user to the household location screen.
The service delivery status is present below the household’s name followed by the administrative area and the number of members. There are cards for each member, starting from the household head. The card consists of the member's name, gender, age, and the ‘Edit’ button for individual-level actions. Age will be denoted in years for this version, as for household-level campaigns, age is not a considerable parameter for providing interventions.
For adding new members to the household, there is the ‘Add Member’ button below the member cards, which navigates the user to the ‘Individual Details’ screen. At the bottom, the ‘Deliver Intervention’ button navigates the user to the update delivery screen.
If the intervention is delivered to that household, the second screen will appear. The deliver intervention button must be replaced by the ‘Update Delivery Details’ button in case more interventions are needed to be delivered. The back button on top takes the user to the list of households screen.
If the campaign is at an individual level, the household card appears in a similar format with some changes. The ‘Deliver Intervention’ button is present at the bottom of every member’s card. If the intervention is delivered to a member, it will display ‘Delivered’ below their details on the card and the button will be replaced with ‘Update Delivery Details’. If the intervention is not delivered, it will display “Not Delivered”. The ‘Deliver Intervention’ button in this case navigates the user to the update delivery screen. The back button navigates the user to the search households screen.
Household-Level Actions When the user clicks on the “Edit Household” button, the actions appear on the screen.
Edit Household: The user is navigated to the household location screen followed by household details. In this screen, the ‘Next’ button is now replaced by the ‘Save’ button.
Delete Household: If the user wants to delete the entire household.
After a user clicks on the “Delete Household”’ button, an overlay appears with a message asking whether he/she wants to delete that beneficiary. It has two buttons: Delete: This will delete the beneficiary from the system records. Cancel: if the user does not want to delete the beneficiary, clicking on this button will collapse the overlay.
If a user selects the delete option, it will bring them to this screen, where he/she must select the reason for deleting a particular household. The screen will be the same as that of individual deletion, only the reasons will vary. The reasons may include the household having relocated, the household does not exist, etc. The reasons must be configured in the MDMS.
When a user clicks on the ‘Edit’ button on an individual’s card, an overlay screen appears with the following actions:
Assign as household head: If the user wants to change the head of household, they can select this option and that member will be assigned as household head. The option must be disabled for the household head.
Edit individual details: If the user wants to edit the member’s details. It will navigate them to the individual details screen and the same flow is to be followed.
Delete individual: This option allows the user to delete a particular member. A user must not be able to delete the household head and hence the delete individual button must be disabled if the beneficiary is marked as the head of the household. If the user wants to delete the beneficiary marked as a household head, the user must assign another member in the household as the head and then delete the beneficiary.
When a user clicks on edit individual details, he/she navigates to the individual details screen where he/she can edit the previously entered data. For edit flow, all the fields must be editable at the front end.
For the date of birth and age fields, the date of birth must always be given precedence over age. If the user has entered the date of birth while creating an individual, only that field must be editable, and the age field must be disabled. If the user has entered age, then the age entered must be visible, and the date of birth field must be blank, but editable. If the user wants to enter the exact date of birth, then he/she must be able to enter the value, in which case the age field is disabled (as in create flow).
Clicking on the delete button opens a popup that asks whether the user wants to delete that member. If the user clicks on the delete button, it will proceed further to delete the member. If the user clicks on cancel, it will take him/her back to the household card.
If the member is the household head, a popup should appear stating that deletion cannot happen unless some other member is assigned the household head. If there is only one member in a household, a popup should appear stating that there should be at least one member for creating a household. The user needs to either add another member or delete the entire household.
If the user selects the delete option, it will bring him/her to this screen, where he/she needs to select the reason for deleting a member. The reasons must be configured in the MDMS.
Before going into the field, the user needs to log into the application every day, which will initiate an automatic sync process (mentioned in the user login PRD). For manual sync, there is a ‘Sync Data’ button on the home screen, which allows the user to sync data according to his/her convenience. At the bottom of the screen, there is a card that shows the message “Data unsynced” along with the number of records unsynced.
When the user clicks on the ‘Sync’ button, the sync action starts along with an overlay showing “Sync in Progress” over the home page. The user cannot perform any other action until the sync is complete or there is some error.
Once the data is synced, it will show a popup, stating “Data Synced” along with a ‘Close’ button at the bottom. When the user clicks on close, it navigates him/her to the home screen.
If the data is not synced due to any error, it will show a popup stating “Sync Failed” with two buttons below it:
Retry: If the user wants to retry syncing the data.
Close: Clicking on this will navigate the user back to the home screen.
The reports dashboard provides a tabular and visualised representation of user performance. The reports are not in V1.0 for mobile applications, except for the stock reconciliation. They are generated based on the offline data present in the local device, associated with the user’s login.
If a user selects the ‘Data’ option, it will provide a data-wise report of the campaign. The bar graph shows the day-to-day comparison of registered beneficiaries along with a threshold of the daily target for registration. Below the graph, the table is added which displays the households registered as well as bednets distributed.
In the leaderboard section, the overall number of households registered will be displayed in the form of a milestone. Below that, all the individual users’ performance will be listed separately. The leaderboard option will not be available at the registrar level (field level) but at the field supervisor level.
If the user is facing any challenge and requires an immediate solution, he/she can click on the call supervisor button on the home screen, which will redirect them to their phone’s dial pad with the supervisor’s number auto-filled. By clicking on the ‘Call’ button, the user can contact the supervisor for immediate assistance.
The articles in this section include the following:
Find the mock-ups below:
When the user opens the application, it asks them to first select the language. The selected language is highlighted in orange color. Once the user selects a language, he/she must click on the ‘Continue’ button which opens the login page.
The user will be provided a unique system-generated ID and password manually for first-time login. After logging in, the user is taken to the password reset page where they need to enter a new password of their choice. The password reset is not in scope for V1.0. If a user enters an incorrect username, it should show an error message below the field saying “username does not match”. For an incorrect password, it should show the message “incorrect password” below the password field.
If an existing user does not remember his/her password, they must click on “Forgot Password”. This will open a popup asking the user to contact the administrator. The ‘OK’ button will collapse the popup.
After the user logs in for the first time, a screen appears where he/she needs to create a new password. There are two fields, “Enter new password” and “Confirm password”, with the eye button present in both.
After entering and reviewing the new password, the user clicks on the submit button which opens a screen with the message “New password created successfully” along with a “Back to Login” button below the text. Clicking on this button will take the user back to the login page. The password reset flow is not in scope for V1.0.
If the user is assigned to multiple projects, they need to select a particular project on this page by clicking on the arrow in front of each project name. Once the user has selected a project, it will open the application’s home page. After selecting a project, the system must download the data for the selected project only. For single-project users, the sync action takes place directly after the login action. There can be multiple cases for projects assigned to a user:
If the user is assigned 0 projects, an overlay must appear saying “Please contact the system administrator for a project” after logging in, and the user must log out of the application.
If the user is assigned multiple projects as mentioned above.
If the user has been assigned a project but later the project has been unassigned. In this case, if the user logs in and selects that project, an error message must appear stating “the project is not assigned to you, please select another project”. When the user clicks on the ‘OK’ button, he/she must be navigated to the updated project selection screen which must not display the unassigned project.
After every login action, the system will automatically sync the data with the system. Since the user will log in only at the start of the day and before going into the field, there must be stable internet connectivity for the device to perform this process. A “Sync in Progress” window will appear on the screen and the user cannot perform any other action until the process is complete.
The overlay will appear over the previous screen. For users assigned to multiple projects, the overlay appears over the project selection screen when the user selects one project from the list. For single-project users, the overlay must appear over the login page.
Once the data is synced, it will show a popup that the data is successfully synced, with a ‘Close’ button at the bottom. When the user clicks on this button, it will navigate him/her to the homepage. These overlays also appear over the previous screens.
If the data is not synced due to an error, it will show a popup stating “Sync Failed” with two buttons below it:
Retry: If the user wants to retry syncing the data. This will open the sync in progress window.
Close: Clicking on this will navigate the user back to the login page and he/she is required to log in again.
When the user opens the application, it asks them to first select the language. The selected language is highlighted in orange colour.
On this page, the following actions can be performed:
A user can switch the language.
A user can click on 'Continue' to navigate to the login screen.
File Path
Users are redirected to this screen once they click on the "Forgot Password" button in the language selection screen.
On this page, the following actions can be performed:
Clicking on the forgot password option in the login page opens a popup message “Please contact your administrator if you have forgotten your password”.
Users are redirected to this screen once they select the preferred language in the previous screen.
On this page, the following actions can be performed:
A user can login to app by giving the User ID and Password.
The "Forgot Password" button gives a user the option to contact the administrator reset if he/she has forgotten the password.
After a user logs into the HCM app, the project selection screen displays all the projects assigned to the user.
On this page, the following actions can be performed:
A user has to select one project.
After selecting a project, the system downloads the data for the selected project only.
After every login action, the system will automatically syncs the data with the system.
Since the user will log in only at the start of the day and before going into the field, there must be stable internet connectivity for the device to perform this process.
A “Sync in Progress” window appears on the screen and the user cannot perform any other action until the process is complete.
If the complaint has been assigned successfully, then the following screen must appear.
A landing page must be available to the user to access all available modules.
Confirmation Screen
If the complaint has been assigned successfully, then the following screen must appear. If the complaint could not be assigned, then the text must say, “Complaint Not Assigned.”
/project/staff/v1/_search
POST
/project/v1/_search
POST
Project Selection Screen
Beneficiary registration involves the registration of households and individuals using the HCM application. When field, and district supervisors navigate to the home screen, the beneficiaries button is visible to them.
On this page, the following actions can be performed:
A user can register a new household only after attempting a search.
A user has to click on the "Register New Household" button to register a household.
After the user clicks on "Register New Household", the page navigates to the "Household Location" page.
The "Administrative Area" is the only mandatory field. "Address Line 1", "Address Line 2", 'Landmark' and "Postal Code" are optional fields.
Clicking on the 'Next' button will take the user to the "Household Details" page where the number of members living in the household can be registered.
Clicking the 'Next' button will take the user the "Individual details" screen.
The first individual added will be the "Head of Household" by default.
The name, ID type, and ID number fields are mandatory. Users can enter the date of birth or their age. The date birth will take precedence over age.
When the user clicks on the submit button, a popup appears asking for confirmation.
If the user clicks on ‘Submit’, the household is registered and a confirmation screen is displayed.
The user can click on the "Back to Search" button for editing the household or register new household fields.
Click on the open card to navigate to the detailed page of the household.
There is an "Edit Household" button for editing household details, which navigates the user to the household location screen. The service delivery status is present below the household’s name followed by the administrative area and the number of members.
There are cards for each member, starting from the household head. The card consists of the ‘Edit’ button for individual-level actions.
For adding new members to the household, there is the "Add Member" button below the member cards, which navigates the user to the "Individual Details" screen.
At the bottom, the "Deliver Intervention" button is present which navigates the user to the update delivery screen.
/individual/v1/bulk/_create
POST
/individual/v1/bulk/_update
POST
/individual/v1/_search
POST
/household/v1/bulk/_create
POST
/household/v1/bulk/_update
POST
/household/v1/_search
POST
/household/member/v1/bulk/_create
POST
/project/beneficiary/v1/bulk/_create
POST
This gives an overview of the number of the number of resources to be delivered. It also enables a user to decide how many resources need to be delivered to a household.
On this page, the following actions can be performed:
The "Deliver Intervention" button navigates the user to the following screen:
The “Number Of Resources For Delivery” must be automatically calculated by the system based on the value entered in the number of household members registered, including the household head.
The ‘Resource Delivered’ field consists of all the possible resources that can be delivered in a particular project.
In the ‘Quantity Distributed’ field, the user can decide how many resources need to be delivered to that household against the value generated by the system. The user can increase or decrease the count through the ‘+’ or ‘-’ buttons respectively.
The user can add a delivery comment if the service is not delivered due to a specific reason or situation in the "Delivery Comment" field, which is a dropdown field with some common reasons that may take place.
After reviewing the details, the user can click on the submit button which will save the details of the household in the system. After validating the details, the confirmation screen appears.
/project/task/v1/bulk/_create
POST
/project/task/v1/_search
POST
The "My Checklist" screen allows supervisors to perform random or scheduled inspections, and record observations of the inspection activity.
On this page, the following actions can be performed:
Clicking on "My Checklist," will display the checklists assigned to the user role.
Clicking on any checklist will show a popup with
- Create Checklist
- View Submitted Checklists
The "Create Checklist" option will allow the supervisor to fill the checklist against the date and the administrative area.
The "View Submitted Checklists" will show the checklists submitted by the supervisor.
/service/v1/_create
POST
/service/v1/_search
POST
This enables a user to manage stocks, besides facilitating stock reconciliation.
On this page, the following actions can be performed:
After a successful login as a warehouse manager, a user lands on the home screen which consists of "Manage Stock", and "Stock Reconciliation".-
This screen consists of the following types of transactions that take place for the the inventory:
Stock Receipt
Stock Issued
Stock Returned
Stock Damaged
Stock Loss
When a user clicks on record stock receipt, the warehouse details screen will appear.
The latitude/longitude captures the geo-location of the warehouse which can be fetched with the help of the location icon within the field.
Clicking on the next button will navigate the user to the "Received Stock" details screen.
The "Receipt Stock Details" form has some mandatory fields: product, received from warehouse, and quantity received.
The optional fields include waybill number, quantity indicated on waybill, transport type, vehicle number, and comments.
Clicking on the submit button will take the user to the success page.
This screen captures the mandatory fields: Product, Issued to warehouse, and the quantity.
The optional fields include waybill number, quantity indicated on waybill, transport type, vehicle number and comments.
Clicking on the submit button will go to the success page.
This screen captures the mandatory fields: Product, returned to warehouse, and quantity returned.
The optional fields are waybill number, quantity indicated on waybill, transport type, vehicle number, and comments.
Clicking on the submit button will take the user to the success page.
This screen captures the mandatory fields: Product, damaged during, received from, and quantity damaged.
The optional fields include waybill number, quantity indicated on waybill, transport type, vehicle number, and comments.
Clicking on the submit button will take he user to the success page.
This screen captures the mandatory fields: Product, lost during, received from, and quantity lost.
The optional fields are wWaybill Number, quantity indicated on waybill, transport type, vehicle number, and comments.
Clicking on the submit button will take the user to the success page.
When the user clicks on the stock reconciliation button on the home screen, he/she is navigated to this screen where he/she needs to verify whether the physical count and calculated stock values are the same or not.
In the select product field, the user needs to select a product from the dropdown.
There are warehouse name and administrative area fields as well, all of which are mandatory.
/stock/v1/bulk/_create
POST
/stock/v1/bulk/_update
POST
/stock/v1/bulk/_search
POST
/stock/reconciliation/v1/bulk/_create
POST
/stock/reconciliation/v1/_search
POST
Needs to work in low/no network coverage areas
Needs to have high level of configurability
Needs to work on android
Users of the app have low tech literacy
Sync
Since the app is expected to be configurable, there is the need to receive these configurations from the server. Data already on the server might need to be retrieved by the app as well.
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 the sending of 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 in an online mode.
The backend interfaces for the app which include localization, MDMS and the 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 time taken for sync).
Values/Options that need to be displayed in various fields in the app.
Additional fields to be captured for any of the entities if any.
Supported languages
Op Log
Any action to create or update data performed by the field user while the app is configured to run in 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 only 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 i.e. 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.
Class Diagram
Sequence Diagrams
Init App
Login
Sync Down
HCM deployment guide
Access needed to the following:
Github
eGoV email Id
Jenkins: https://builds.digit.org
Click on ‘builds’.
Search for “health-campaign-services”.
Select the relevant service.
All services which are created for the health campaign are in “Health-services”.
If the service is not present, add it in the build files of the repo. The dev team should have added this already.
Select the service to build.
Click on “Build with Parameters”.
You will see a list of branches available for Github
For QA, search ‘qa’.
Select “origin/qa”.
Click on ‘Build’.
This will trigger the build. The latest build will be on the top of the list.
Click on the top of the list to check for the build logs.
You will see multiple options.
Click on “Console Output”.
If the build is successful, you will see the following message: “Finished: SUCCESS”.
Scroll up to see the image name, which has been pushed: docker.io/egovio/household:qa-efb0e0ac09-20 pushed successfully!
Copy household:qa-efb0e0ac09-20.
Visit https://builds.digit.org/.
Click on deployments.
Select the environment where you want to deploy.
For QA, click on “deploy-to-health-qa”.
Click on “Build with Parameters”.
Click on ‘Build’.
Paste the image name from the build step and paste it in the text box.
Cluster Config: If there is a change at the infra level or it is the first deployment for the service on the infra, select this check box: default keep it unchecked.
Click on ‘Build’.
You will see the latest deployment in progress on the top of the deployment list.
Click on the top to see the deployment logs.
This will show the Git data.
Click on “Console Output”.
If the deployment is successful in the logs, you will see the following message: “Finished: SUCCESS”.
Check the status of Kubernetes to verify if the new pod is running or not.
Here are the articles in this section:
Here are the articles in this section:
Role action mapping has only been completed for registrars, distributors and system administrators to support the development of registration and Delivery flows. Other roles are still in progress.
The product service helps and provides APIs to create products and product variants to the HCM. This document provides the configuration details for setting up products and product variants.
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.
Provides APIs to create, update, and search products.
Provides APIs to create, update, and search product variants.
*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.
Application.properties file information:
Kafka topics persister configs for eGov persister
Action test: URL actions adding
Access to role-based actions
Persister configuration
Indexer configuration
Postman collection
The individual registry helps and provides APIs to create citizens or users to the DIGIT platform. This document provides the configuration details for setting up individuals.
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.
Provides APIs to create, update, and delete individuals.
Provides APIs to bulk create, update, and delete individuals.
Inactivates the status of individuals post deletion.
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.
Application.properties file information:
Kafka topics persister configs for eGov persister
URLs for the external API references:
idGen Id formats :-> idgen.individual.id.format=individual.id // eg: IND-[cy:yyyy-MM-dd]-[SEQ_ADDRESS_IND]