HCM Console Configuration

Set Up Boundary Master Data (Mandatory)

Boundaries are the foundation of every campaign. You must configure a boundary hierarchy before creating campaigns or microplans.

1.1 Create a Boundary Hierarchy

If a hierarchy does not already exist, create one from the Boundary Management screens.

Example (Hierarchy Type: ADMIN)

Country → Province → District → AdministrativePost → Locality → Village

You can define hierarchies at any depth based on campaign needs.

1.2 Configure Hierarchy in MDMS

Navigate to MDMS and configure the hierarchy:

• Module Name: HCM-ADMIN-CONSOLE

• Master Name: HierarchySchema

Use the same hierarchy for:

• Console

• Campaign

• Microplan

Keep these values consistent:

• Hierarchy name

• Lowest hierarchy level

• Split boundary level

Example

• Hierarchy: AdministrativePost

• Lowest Level: Locality

1.3 Upload Boundary Data

1. Go to Boundary Data Management

2. Click Create New Boundary Data

3. Select the hierarchy

4. Download the Excel template

5. Fill in boundary data

6. Upload the file

Important

• Headers change automatically if hierarchy levels change

• Data must match the template exactly

1.4 Boundary Localisation

Boundary names are automatically localised during upload.

Localisation Module Format

hcm-boundary-${BOUNDARY_HIERARCHY_TYPE}

• Must be lowercase

• Must match the hierarchy type

Configure Hierarchy Behaviour (MDMS)

The hierarchy schema controls how boundaries are used during campaign flows.

MDMS Location

• Module: HCM-ADMIN-CONSOLE

• Master: HierarchySchema

Key Fields

[
    {
        "type": "microplan",
        "group": [
            "MALARIA"
        ],
        "hierarchy": "MICROPLAN",
        "department": [],
        "lowestHierarchy": "VILLAGE",
        "highestHierarchy": "COUNTRY",
        "splitBoundariesOn": "DISTRICT",
        "consolidateUsersAt": "LOCALITY"
    },
    {
        "type": "boundary",
        "group": [
            "MALARIA"
        ],
        "hierarchy": "MICROPLAN",
        "department": [],
        "lowestHierarchy": "VILLAGE",
        "highestHierarchy": "COUNTRY",
        "splitBoundariesOn": "DISTRICT",
        "consolidateUsersAt": "LOCALITY"
    },
    {
        "type": "campaign",
        "group": [
            "MALARIA"
        ],
        "hierarchy": "NEWTEST0002",
        "department": [],
        "lowestHierarchy": "ADMINISTRATIVEPOST",
        "splitBoundariesOn": "DISTRICT",
        "consolidateUsersAt": "LOCALITY",
        "highestHierarchy": "COUNTRY"
    },
    {
        "type": "default",
        "group": [
            "MALARIA"
        ],
        "hierarchy": "DEFAULTBOUNDARYNEWONE",
        "department": [],
        "lowestlevel": "ADMINISTRATIVEPOST",
        "splitBasedOn": "DISTRICT",
        "consolidateUsersAt": "LOCALITY",
        "highestHierarchy": "COUNTRY"
        
    },
    {
        "type": "console",
        "group": [
            "MALARIA"
        ],
        "hierarchy": "ADMIN",
        "department": [],
        "lowestHierarchy": "Posto Administrativo",
        "splitBoundariesOn": "Distrito",
        "consolidateUsersAt": "LOCALITY",
        "highestHierarchy": "COUNTRY"
    }
]

Supported Hierarchy Types

In the HierarchySchema configuration, different type values are used to define the purpose of each hierarchy. These types determine how the hierarchy will be applied during different stages of the campaign.

Here, we have 4 types used in the campaign flow:

• "type": "console": Used for the Campaign creation flow. Defines the boundary hierarchy structure that will be visible when creating a new campaign

• "type": "microplan": Used for the Microplan creation flow. Ensures that microplans are aligned to the configured boundary hierarchy.

• "type": "campaign": Used for the Boundary Management creation flow. Specifies the hierarchy for managing campaign boundaries once a campaign is set up.

• "type": "default": Serves as the default hierarchy for Boundary Management creation flow and holds default settings.

Configure Excel Upload Validations

All Excel uploads (users, facilities, targets) are validated using schemas.

MDMS Location

• Module: HCM-ADMIN-CONSOLE

• Master: schemas

Validations apply at:

• UI level

• Backend level

What You Can Control

Common Schema Properties

Validation Types

• User Validations

• Roles → Add or remove roles to be validated.

• Employment Type → Update the enum list to add or remove types.

• Headers → All headers are mandatory by default, but you can toggle this by setting isRequired = true/false.

• Facility Validations

• Facility Type → Add or delete facility categories.

• Facility Status → Add or delete status options.

• Facility Usage → Add or delete usage options.

• Capacity → Adjust minimum and maximum values.

• Facility Name → Update constraints for minLength and maxLength.

• Headers → All headers are mandatory by default; adjust using isRequired.

• Target Validations

• Target → Adjust minimum and maximum validations.

• Boundary Code → Mandatory field.

• Target Header → Mandatory field.

• Campaign Type → Based on the selected campaign type, boundary targets are updated.

• Custom Columns → New target columns can be introduced if required.

Configure Attributes (Beneficiary Data)

The schema includes a list of attribute configurations, where each attribute is:

• Identified by a unique key,

• Defined with a code, and

• Linked to an internationalisation key (i18nKey) for multi-language support.

Example AttributesThe following attributes are available for use in campaigns to capture beneficiary information:

• Age

• Height

• Weight

• Gender

These attributes ensure that consistent, standardised data points are collected across campaigns.

The attribute dropdown in the system is dynamically populated from the attributeConfig schema. This schema defines the set of attributes available for selection during campaign setup or data entry.

• Module Name: HCM-ADMIN-CONSOLE

• Master Name: attributeConfig

Configure Upload Processing Timings

Controls how often the system checks the upload status. The schema defines the rules for how frequently the system should call the search API after a file upload. The purpose of these calls is to check the validation status of the uploaded file.

• Module Name: HCM-ADMIN-CONSOLE

• Master Name: baseTimeOut

• baseTimeOut.json

How It Works

• Base Time

  • Defines the minimum interval after which the search API is triggered.

• Dynamic Interval Calculation

  • The actual interval = baseTime × number of fields in the uploaded sheet.

  • This interval is constrained by:

    • Minimum base time (lower limit), and

    • maxTime (upper limit).

• Search API Calls

  • The search API is called repeatedly at the calculated interval.

  • Calls stop only when a successful or failed response is received.

• TimelineRefetch

  • Configured to call the getProcessAPI of the timeline periodically.

  • Ensures the process status is kept up to date after a certain interval.

Configure Campaign & Delivery Behaviour

The delivery configuration schema is used to define how deliveries are displayed in the system. It distinguishes between:

• Direct Deliveries → Items or services provided directly to the beneficiary.

• Indirect Deliveries → Items or services provided through an intermediary (e.g., via a facility, distributor, or supervisor).

• Module Name: HCM-ADMIN-CONSOLE

• Master Name: deliveryTypeConfig

[
    {
        "key": 1,
        "code": "DIRECT"
    },
    {
        "key": 2,
        "code": "INDIRECT"
    }
]

Mail Configurations

The mailConfig schema is used to define the default email ID for contacting the L1 support team or the implementation team. This comes into play when a user requests a hierarchy that is not currently available in the system.

• Module Name: HCM-ADMIN-CONSOLE

• Master Name: mailConfig

[
    {
        "mailId": "[email protected]"
    }
]

Operator Configuration

The operatorConfig schema defines all the operator options that can be applied to attributes. These operators are used in the system for filtering, validation, and logical conditions during campaign configuration and execution.

• Module Name: HCM-ADMIN-CONSOLE

• Master Name: operatorConfig

Product Type Configuration

The productType schema defines the list of resource types that can be selected in the system. If a required resource type is not already available, it can be added through this schema. Once added, the new resource type will automatically appear in the resources dropdown.

• Module Name: HCM-ADMIN-CONSOLE

• Master Name: productType

ReadMe Configuration

The ReadMeConfig schema defines the information messages that are displayed both in the UI and in the ReadMe sheet of the downloaded Excel templates. These messages act as instructions for users, guiding them on how to correctly fill in the upload templates.

• Module Name: HCM-ADMIN-CONSOLE

• Master Name: ReadMeConfig

Schema Fields

• type: Defines the upload type (e.g., User, Facility, Target).

• header: The text identifier for the header (localised using the localisation module).

• isHeaderBold: Boolean → whether the header should be displayed in bold.

• inSheet: Boolean → whether the header should appear in the downloaded Excel sheet.

• inUiInfo: Boolean → whether the header should appear in the UI information panel.

• text: The text identifier for the description (localised).

• isStepRequired: Boolean → whether the description is a mandatory step for users.

Localisation

• All header and text values are stored as codes, which are then mapped through the localisation module.

• This ensures multi-language support for instructions across the platform.

hcm-admin-schemas

Below is an example of how data is entered into the read-me schema for the headers and their description:

Login & Privacy Configuration

To display the Privacy Policy component on the login page, you need to add the required configurations in MDMS.

• Module Name: LoginConfig

• Master Name: commonUiConfig

In version v0.4, the login page was revamped, and the configuration was updated accordingly.

Steps

1. Navigate to the MDMS configuration for the login page.

2. Locate the module: LoginConfig.

3. In the commonUiConfig master, add or update the fields as required.

4. You can customise the fields (add or delete) depending on your implementation needs.

For detailed configuration examples and usage, refer here.

[
{
                "texts": {
                    "header": "CORE_COMMON_LOGIN",
                    "submitButtonLabel": "CORE_COMMON_CONTINUE",
                    "secondaryButtonLabel": "CORE_COMMON_FORGOT_PASSWORD"
                },
                "title": "login",
                "inputs": [
                    {
                        "key": "username",
                        "type": "text",
                        "label": "CORE_LOGIN_USERNAME",
                        "populators": {
                            "name": "username",
                            "error": "ERR_USERNAME_REQUIRED",
                            "validation": {
                                "required": true
                            }
                        },
                        "isMandatory": true
                    },
                    {
                        "key": "password",
                        "type": "password",
                        "label": "CORE_LOGIN_PASSWORD",
                        "populators": {
                            "name": "password",
                            "error": "ERR_PASSWORD_REQUIRED",
                            "validation": {
                                "required": true
                            }
                        },
                        "isMandatory": true
                    },
                    {
                        "key": "city",
                        "type": "dropdown",
                        "label": "CORE_COMMON_CITY",
                        "disable": false,
                        "populators": {
                            "name": "city",
                            "error": "ERR_HRMS_INVALID_CITY",
                            "mdmsConfig": {
                                "select": "(data)=>{ return Array.isArray(data['tenant'].tenants) && Digit.Utils.getUnique(data['tenant'].tenants).map(ele=>({code:ele.code,name:Digit.Utils.locale.getTransformedLocale('TENANT_TENANTS_'+ele.code)}))}",
                                "masterName": "tenants",
                                "moduleName": "tenant",
                                "localePrefix": "TENANT_TENANTS"
                            },
                            "optionsKey": "name"
                        },
                        "isMandatory": true
                    },
                    {
                        "key": "check",
                        "type": "component",
                        "disable": false,
                        "component": "PrivacyComponent",
                        "populators": {
                            "name": "check"
                        },
                        "customProps": {
                            "module": "HCM"
                        },
                        "isMandatory": false,
                        "withoutLabel": true
                    }
                ]
            }
]

Policy Configurations

This configuration displays the data in the privacy pop-up. An example of the configuration is shown below:

{
      "header": "PRIVACY_HEADER",
      "module": "HCM",
      "contents": [
        {
          "header": "PRIVACY_HEADER_1_SUB_1",
          "descriptions": [
            {
              "text": "PRIVACY_HEADER_1_SUB_1_DESC_1",
              "type": null,
              "isBold": false
            },
            {
              "text": "PRIVACY_HEADER_1_SUB_1_DESC_2",
              "type": null,
              "isBold": false
            },
            {
              "text": "PRIVACY_HEADER_1_SUB_1_DESC_3",
              "type": null,
              "isBold": false
            },
]
},
 {
              "text": "PRIVACY_HEADER_9_SUB_9_DESC_5",
              "type": null,
              "isBold": false,
              "subDescriptions":[
                {
                  "text": "PRIVACY_HEADER_9_SUB_9_DESC_5_SUBDESC_1",
                  "type": null,
                  "isBold": false,
                  "isSpaceRequired": true
                },
                {
                  "text": "PRIVACY_HEADER_9_SUB_9_DESC_5_SUBDESC_2",
                  "type": null,
                  "isBold": false,
                  "isSpaceRequired": true
                }
              ]
            }
          ]
        },

In the schema:

Type can be the following:

• null:

  • When type is null, it indicates that the description is just plain text.

• point:

  • When type is set to point, it likely means that the description should be displayed as a bullet point or list item.

• step:

  • When type is set to step, it suggests that the description is part of a sequence of steps.

• subdescriptions: to show the sub-descriptions at the point.

Date with Boundary Configurations

This configuration is used when you want to update the dates with or without the selected boundaries. If the flag is false, it updates the dates at the country level by default. If you want to update the dates at the lower boundary levels, then make the flag true.

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: dateWithBoundary

"dateWithBoundary": [
    {
      "dateWithBoundary": true
    }
  ]

Project Type Configurations

This configuration is now used in place of the delivery configuration.

This is used to store all the pre-required conditions for the delivery conditions screens.

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: projectTypes

 {
      "id": "ea1bb2e7-06d8-4fe4-ba1e-f4a6363a21be",
      "name": "configuration for Multi Round Campaigns",
      "code": "MR-DN",
      "group": "MALARIA",
      "type": "multiround",
      "beneficiaryType": "INDIVIDUAL",
      "eligibilityCriteria": [
        "All households having members under the age of 18 are eligible.",
        "Prison inmates are eligible."
      ],
      "taskProcedure": [
        "1 bednet is to be distributed per 2 household members.",
        "If there are 4 household members, 2 bednets should be distributed.",
        "If there are 5 household members, 3 bednets should be distributed."
      ],
      "resources": [
        {
          "productVariantId": "PVAR-2024-05-09-000331",
          "isBaseUnitVariant": false,
          "name": "SP 500mg"
        },
        {
          "productVariantId": "PVAR-2024-05-09-000332",
          "isBaseUnitVariant": true,
          "name": "SP 250mg"
        }
      ],
      "observationStrategy": "DOT1",
      "validMinAge": 3,
      "validMaxAge": 64,
      "cycles": [
        {
          "mandatoryWaitSinceLastCycleInDays": null,
          "startDate": 1714329000000,
          "endDate": 1715279400000,
          "id": 1,
          "deliveries": [
            {
              "id": 1,
              "deliveryStrategy": "DIRECT",
              "mandatoryWaitSinceLastDeliveryInDays": null,
              "doseCriteria": [
                {
                  "condition": "3<=age<11",
                  "ProductVariants": [
                    {
                      "productVariantId": "PVAR-2024-05-09-000331", // should be set according to the environment
                      "quantity": 1,
                       "name": "SP 500mg"
                    },
                  ]
                },
              ]
            },
          ]
        },
      ]
    },

This is the sample data for the project type - MR-DN

Explanation for the MDMS Data -

1. Project Types: Three main project types (LLIN-mz, MR-DN, and IRS-mz) with unique configurations.

2. Cycles and Deliveries:

   • Each project type contains cycles, and each cycle contains multiple deliveries.

   • Deliveries include details such as deliveryStrategy, doseCriteria, and ProductVariants.

3. Resources: A list of resources specific to each project type.

4. Eligibility Criteria: Contains a list of conditions for each project type.

5. Other Configurations:

   • attrAddDisable, deliveryAddDisable, and similar attributes determine UI behaviour.

Requirements:

"ProductVariants": [
                    {
                      "productVariantId": "PVAR-2024-05-09-000331", // should be set according to the environment
                      "quantity": 1,
                       "name": "SP 500mg"
                    },
                  ]

Roles For Checklist

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: rolesForChecklist

This master data is used to show the dropdown of roles in the checklist screens -

{
    "tenantId": "mz",
    "schemaCode": "HCM-ADMIN-CONSOLE.rolesForChecklist",
    "uniqueIdentifier": null,
    "data": {
        "key": 1,
        "code": "DISTRIBUTOR"
    },
    "isActive": true
}

Checklist Templates

This master data is used to create a default template of the checklist for the selected campaign + role + checklist type -

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: ChecklistTemplates

{
    "code": "SingleValueList",
    "type": [
        "checklist"
    ]
}

App Field Types

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: appFieldTypes

This is used to describe the type of questions available in the dropdown while configuring the checklist.

{
    "code": "SingleValueList",
    "type": [
        "checklist"
    ]
}

Microplan Integration

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: microplanIntegration

This master is utilised for the microplan data fetching. Here, 'type' refers to the data template that needs to be filled. 'To' and 'from' pertain to the microplan data, and while populating campaign data, various filter conditions, such as 'includes', or 'equals', can be applied.

IdGen Configuration

To enable the generation of unique identifiers via the idGen service, the following data must be added to the MDMS under moduleName=common-masters and masterName=IdFormat.

• Master Name: common-masters

• ModuleName: IdFormat

Ensure both configurations are added to MDMS before proceeding with ID generation.

Target Configuration

This configuration is used to define the mapping of target-related data from the target sheet to different beneficiary types. Each beneficiary type can be associated with one or more columns from the target sheet, which hold the respective target values.

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: targetConfigs

Key Details:

• campaignType: Specifies the campaign type this configuration applies to (e.g., "LLIN-mz").

• beneficiaries: A list of beneficiary types, each having:

  • columns: The columns in the target sheet that map to this beneficiary type.

  • beneficiaryType: The type of beneficiary (e.g., "INDIVIDUAL", "HOUSEHOLD", "PRODUCT").

Help Tutorial

This configuration is used to define help tutorial content for the users during the flow. It provides contextual help videos, guided tours, and documentation links based on the current screen.

• Master Name: commonUiConfig

• ModuleName: HelpTutorial

tours (Guided Tour Steps)

For interactive page walkthroughs, each tour step contains:

How It Works

module

The application module this help content belongs to (e.g., campaign).

helpContent

Array of help items to display. Each item contains:

Allowed Modules Configurations

This configuration is used to restrict the App Config from deselecting certain modules. It defines the mandatory modules that must be selected for each project type during campaign setup. Users cannot proceed without selecting all the allowed (required) modules.

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: AllowedModules

How It Works

projectType

The project type code for which this configuration applies (e.g., Bednets, IRS-mz, MR-DN).

allowedModule

Array of module codes that are mandatory for this project type. These modules cannot be unselected by users.

Example Data

App Link Configurations

This configuration is used to provide the Downloadable APK link after the campaign is created. So APK needs to be manually generated here and update the link in this master

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: AppLink

App Module Schema Configurations

This configuration is used to define the modules and their features in the App Config flow. It specifies which features are available for each module and controls their visibility and behaviour.

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: AppModuleSchema

How It Works

code

Unique identifier for the module (e.g., REGISTRATIONFLOW, DELIVERYFLOW, COMPLAINTS, INVENTORY).

description

Localisation key for the module description (e.g., REGISTRATION_DESC, DELIVERY_DESC).

features

Array of feature configurations is available for this module. Each feature contains:

Available Modules

Available Features

Example Data

App Screen Localisation Configurations

This configuration is used to define the properties for which localisation should be enabled in the App Config flow. It determines which properties in the app configuration screens should show the localisation input fields (multi-language support).

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: AppScreenLocalisationConfig

How It Works

screenName

Unique identifier for the configuration (e.g., appScreenConfig).

LocalisationModule

The localisation module name used for storing translations (e.g., configure-app).

moduleVersion

Current version of the module configuration.

minModuleVersion

Minimum supported module version for backward compatibility.

fields

Array of field type configurations. Each entry defines which properties can be localized for that field type.

Common Localisable Properties

Example Data

Form Config Template

This master serves as the base template for mobile app form configuration screens. When a new campaign is created, the system copies the relevant template configuration for the selected project type and uses it as the starting point for app configuration.

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: FormConfigTemplate

How It Works

name

Module name identifier (e.g., REGISTRATION, DELIVERY, COMPLAINTS, ATTENDANCE, MANAGESTOCK).

project

Project type code this template belongs to (e.g., IRS-mz, MR-DN, LLIN-mz, DEFAULT).

flows

Array of flow configurations within the module. Each flow contains:

pages

Each page within a flow contains:

properties (Fields)

Each field within a page contains properties.

Example Data

Campaign Naming Convention

This master defines the naming convention rules displayed to users when creating a campaign name. The rules are shown as a checklist with real-time validation feedback.

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: CampaignNamingConvention

How It Works

id

Unique identifier for the naming convention configuration.

data

Array of localisation keys (translation codes) for the naming rules.

isActive

Whether this configuration is active.

Field Properties Panel Config

This master defines the configuration for the properties panel (right-side drawer) that appears when editing a field in the mobile app configuration screens. It controls which properties and validations are available for each field type.

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: FieldPropertiesPanelConfig

How It Works

Label

Unique identifier for the panel configuration (e.g., NewPanelConfig).

Content

Array of property fields shown in the panel. Each field can have:

Validation

Array of validation rules is available in the panel:

Available Content Properties

Field Type Mapping Configurations

This master defines the available field types for configuring mobile app screens. It maps each field type to its UI component, metadata, and configurable properties.

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: FieldTypeMappingConfig

How It Works

Type

Unique identifier for the field type (e.g., text, dropdown, card, button).

Category

Groups field types for display in the UI:

• basic - Simple inputs like text, number, date, dropdown

• advanced - Complex components like template components, scanner component etc

Order

Display order in the field type selection dropdown.

Metadata

Schema information for the field:

• type - Data type (string, integer, boolean, template)

• format - Format identifier for rendering

Field Type

Base field type used for rendering.

Component

(Optional) React component name for advanced field types.

Properties

(Optional) Configurable options for the field type.

Editable

(Optional) Whether the field can be modified after creation.

Details Renderer Configurations

Master details

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: DETAILS_RENDERER_CONFIG

Campaign Type Templates

This configuration is used to define pre-built campaign templates that users can select when creating a new campaign. Templates provide a quick-start option with predefined settings based on previous successful campaigns.

Master details

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: campaignTypeTemplates

How It Works

id

Unique identifier for the template (e.g., MalariaSMC2024, PolioNID2025).

name

Display name of the campaign template.

description

Detailed description of the template explaining its purpose and use case.

projectTypeCode

Code linking to the project type in HCM-PROJECT-TYPES.projectTypes (e.g., MR-DN, Bednets, POLIO).

disease

Associated disease type (e.g., MALARIA, POLIO, VITAMINADEFICIENCY).

usedIn

Location or geography where this template was previously used (e.g., Kano - Nigeria, Maputo, Mozambique).

partnerName

Name of the organization or partner that created/used this template.

modules

Array of modules included in the campaign:

• Registration

• Delivery

• Inventory

• Attendance

duration

Campaign duration configuration

deliveryCycles

Array of delivery cycle/round configuration

imageDetails

Image configuration for the template card

Campaign Rules & Controls

Includes:

• Date updates by boundary (dateWithBoundary)

• Campaign naming rules (CampaignNamingConvention)

• Mandatory modules (AllowedModules)

• Target-to-beneficiary mapping (targetConfigs)

• Checklist roles & templates

• Microplan integration rules

• ID generation (common-masters.IdFormat)

Dieseases List

This configuration is used to define the list of supported diseases for campaign templates and project types. It provides disease options for filtering and categorising campaigns.

Master details

• Master Name: HCM-ADMIN-CONSOLE

• ModuleName: diseasesList

How It Works

code

Unique identifier for the disease (e.g., MALARIA, POLIO, COVID19).

name

Human-readable display name of the disease.

active

Flag to indicate if the disease is currently active and should be shown in dropdowns.

description

(Optional) Detailed description of the disease for informational purposes.