Health
PlatformDomainAcademyDesign SystemFeedback
v1.7
v1.7
  • 👋Introducing Health
    • Release Notes
      • HCM v1.7 Release Notes
        • Release Checklist
        • Eligibility Checklist
        • Service Build Updates
      • HCM v1.6 Release Notes
        • Service Build Updates
        • Release Checklist
        • Migration from v1.5 to v1.6
      • HCM v1.5 Release Notes
        • Migration from v1.4 to v1.5
        • Service Build Updates
        • Release Checklist
      • HCM v1.4 Release Notes
        • Migration from v1.3 to v1.4
        • Service Build Updates
        • Release Checklist
      • v1.3 Release Notes
      • v1.3 Tech Release Summary
        • Master Data Management Service (MDMS) & Configuration Updates
        • Test Cases
        • Service Build Updates
      • v1.2 Release Notes
      • v1.0 Release Notes
  • Product Roadmap
  • 💙HEALTH CAMPAIGN MANAGEMENT
    • Understanding Health Campaign Management (HCM)
    • Value Proposition
  • 🎯HCM PRODUCT SUITE
    • Functional Specifications
      • Campaign Type Setup
      • Campaign Setup
      • Inventory
      • Boundary Hierarchy
      • Beneficiary
      • Boundary Data Specs
      • Draft System User Setup
      • Role Action Mapping
    • Building Blocks & Services
    • Health Products
      • HCM App
        • User Manual
          • Single Round Campaigns
            • Registration & Delivery
              • Registration & Delivery: IRS
          • Multi-Round Campaigns
            • Registration & Delivery
            • Download Beneficiary Data
          • Common Functions
            • User Management
            • 2D Voucher Scanning
            • Proximity-Based Search
            • Voucher-Based Registration and Distribution
            • Tracking Beneficiary Referrals
            • Tracking Side-Effects for Beneficiaries
            • Tracking Adverse Events
            • Health Facility Referral
            • Raising Complaints
            • Resolving Complaints
            • Inventory Management
              • User Manual
                • Stock Management
                • Stock Reconciliation
                • View Reports
                • Bale Scanning
            • Attendance Management
            • Payments
              • Guide to HCM Payments
            • Community Living Facilities
              • Product Requirement Document
          • Support Functions
            • Language Selection
            • Login
            • Forgot Password
            • Project Selection
            • Hamburger Menu
            • Help
            • Sync
            • Checklist
      • Campaign Management Dashboard
        • User Manual
        • Configurations
          • MDMS Configurations and s3 assets
          • IRS Dashboard Chart Configurations
        • Kibana Dashboard Integration With DSS Module
          • Auth Proxy Setup and Configuration for Kibana
        • SMC Dashboard
      • Microplanning
      • HCM Console
      • Health Payments
        • MDMS Configurations
        • Attendance Update and Approval Process
          • Project Selection
          • Register Inbox
          • View Attendance:Edit And Approve
        • Bill Generation Process
          • Project And Bill Aggregation
          • Bill Generation
          • My Bills
  • 🚀REFERENCE IMPLEMENTATIONs
    • Mozambique
      • LLIN Overview
      • Customisation
      • Rollout
  • 🧰TECHNOLOGY
    • Architecture
      • High Level Design
        • Health Campaign System High Level Design
        • Design Decision Log
      • Low Level Design
        • Registries
          • Individual
          • Household
          • Product
          • Facility
          • Attendance
          • Expense
        • Services
          • Project
          • Stock
          • Referral
          • Muster Roll
          • Expense Calculator
      • Field App Architecture
        • UI Packages
          • Closed HouseHold package
          • Registration & Delivery Package
            • Eligibility Checklist
            • Communal Living Facilities
          • Referral Reconciliation Package
          • Inventory Management Package
          • Attendance Management Package
          • DIGIT Scanner Package
          • Digit Showcase Package
          • Digit Data Model Package
          • DIGIT DSS Package
          • Complaints Package
          • Survey Form Package
          • Sync Service Package
    • Standards
    • Security
    • Interoperability
  • 🪝SETUP
    • Planning an HCM Implementation
    • Establish Project & Team
    • Gathering Requirements
    • Installation
      • Install Using GitHub Actions in AWS
      • System Data Setup
      • Project Data Setup
      • Setup Mobile App
      • Setup Kibana Dashboard
        • Create or Edit Existing Dashboards
      • Server Cleanup
    • Configuration
      • Configuring HCM to Campaign and Country Needs
      • Service Configuration
        • Individual Registry
        • Household Registry
        • Product Registry
        • Facility Registry
        • Stock & Inventory
        • Project Services
        • Referral Management
        • Attendance
        • Complaints
          • QA Sign-Off
            • Test Cases
        • User Management
          • QA Sign-Off
        • Muster Roll
        • Expense Service
        • Expense calculator
      • UI Configuration
        • Stock Management
        • Language Selection
        • Login
        • Forgot Password
        • Project Selection
        • Dashboard Configuration
          • Dashboard UI Enhancements
          • HCM Dashboard Master Promotion Guide
        • Attendance Management
          • Attendance Package Extraction and Interaction with HCM Application
    • Quality Assurance Testing
      • Regression Test cases
        • HCM Product
        • HCM Console
        • Microplanning
      • Eligibility and CLF Test cases
      • Console v0.3.1
      • Micro planning v0.2
      • HCM Payments v0.1
  • 🔵COMMUNITY
    • Source Code
    • Committee
      • Digital Product Advisory Committee Charter
      • Idea Management Process
      • Sessions
        • November 2023 Session
        • August 2024 Session
          • Minutes of the Meeting
        • December 2024 Session
    • HCM Declarative Statements & FAQs
Powered by GitBook

https://creativecommons.org/licenses/by/4.0/

On this page
  • Sync
  • Configurability
  • Access Control
  • Data
  • Limitations

Was this helpful?

Export as PDF
  1. TECHNOLOGY
  2. Architecture
  3. High Level Design

Design Decision Log

Sync

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

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

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

  4. Sync will be done through bulk APIs.

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

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

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

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

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

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

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

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

Configurability

Backend

  1. Search API max limit and the default limit.

  2. Service details and endpoints.

Frontend

  1. Service details and endpoints.

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

  3. Additional fields per entity in the app.

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

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

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

  7. Timeout for the API calls.

Access Control

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

Data

  1. All deletes are soft deletes.

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

  3. Undeletion is not permitted.

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

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

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

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

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

Limitations

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

PreviousHealth Campaign System High Level DesignNextLow Level Design

Was this helpful?

🧰