Multi-round delivery of resources
Background
Target Audience
Objectives (of this release)
Assumptions and Validations
Process flow
Specifications
Design
This document describes the need and scope of adding multi-round delivery capability within V2.0, explaining the module’s features, specifications, purpose, and functionality. It also provides a descriptive view of the application along with the specification of each element.
For certain campaigns, especially at the individual levels, the doses are administered in multiple rounds which are referred to as ‘cycles’. Each cycle has multiple doses within them. In such campaigns, the doses are administered by following either of the two strategies: DOT 1 and DOT n, where DOT means Direct Observation of Treatment. In DOT 1 strategy, the distributor provides the first dose of the first cycle, and the remaining doses are given to the caretaker/mother to be given accordingly. The process is repeated for the next cycles. In DOT n, the distributor himself/herself provides each dose to the beneficiary. Thus, the application must be capable of capturing data for multi-round campaigns.
This document is intended for the engineering and platform (tech teams), product management, and implementation teams to agree on requirements for the Health Campaign Management (HCM) Platform.
Support multi-round delivery:
- Enable actors to capture delivery details for multi round campaigns.
- Able to capture details for both types of DOT strategies.
Enhance user experience:
- Auto-populate the number of cycles and doses being administered to the beneficiary for the user’s convenience.
- Provide the auto-calculated resource and quantity to be administered for each dose.
- Enable actors to deliver multiple resources based on the campaign.
Record past delivery:
- Enable actors to record past delivery details (for DOT 1-based campaigns).
Sr. No.
Theme
Assumption
1
Deliver intervention
The actors collect the data for multi-round campaigns for each cycle and each dose within the cycle.
There must be a time interval, restricting the user to record the delivery data for next dose/cycle and it must be configurable.
The user cannot change the dose and cycle to avoid collection of incorrect data.
2
Resource delivered
Auto-populate the resource and the quantity from the calculated values.
The fields are editable if the user wants to change the resource or quantity.
3
Beneficiary details
Provide the history for delivery details on the beneficiary details screen to track the resource delivery.
Field
Data type
Data validation
Required (Y/N)
Comments
Height
Integer
Height of the beneficiary:
Should not exceed 3 digits.
Y
Weight
Integer
Weight of the beneficiary:
Should not exceed 3 digits.
Y
Is the beneficiary sick?
Binary (Yes/No)
Y
Sickness description
String
Must appear if a user selects ‘Yes’.
Y
Is the beneficiary undergoing any form of treatment?
Binary (Yes/No)
Y
Treatment description
String
Must appear if a user selects ‘Yes’.
Y
Does the beneficiary have any co-morbidities?
Binary (Yes/No)
Y
Co-morbidities
Dropdown
Must appear if a user selects ‘Yes’. A user must be able to select multiple values from the dropdown list.
Y
Was the dose administered
Binary (Yes/No)
A user must select whether the dose was administered or not.
Y
Date of administration
Date
The date must be non-editable for recording current delivery and editable for past delivery records.
Y
Dose administered by
Dropdown
A user must select from the list the person who administered the dose.
Y
Resource to be administered
Read-only
This is calculated by the system based on the configurations.
NA
Resource delivered
Dropdown
The system auto-populates the resource which is editable.
Y
Quantity administered
Increment/decrement
The system auto-populates the quantity which is editable.
Y
Was the delivery successful?
Binary (Yes/No)
Y
Reason for not delivering
Dropdown
The field must be dynamic and appear when the user selects ‘No’. The list must be configured in the MDMS.
Y
Find the mock-ups below:
When the user clicks the ‘Open’ button on the beneficiary card in the search household screen or scans a voucher, the household card is opened, which contains the household details.
Based on the campaign type, the “Deliver Intervention” button is displayed either on each individual’s card or the entire household. For individual based campaigns, the button appears only on the individual’s card that was searched or scanned.
Clicking on the “Deliver Intervention” button opens this screen which has the beneficiary data as well as delivery data if he/she has received any intervention earlier. The user can record past delivery data (if DOT 1 strategy is followed) or simply click on the ‘Next’ button to record current delivery details.
For certain campaigns, the resources delivered are calculated based on the beneficiary’s height, weight, age, or other parameters. This screen captures details of the beneficiary along with a checklist that has health-related questionnaires: Whether the beneficiary is sick and undergoing any treatment, or if he/she is suffering from disease(s).
The form must be configurable to support multiple question types and add questions, if needed. For questions that require specific details, a text field appears when the user selects ‘Yes’. The dropdown list for comorbidities must allow multiple selection.
The user needs to provide the delivery details for the resources delivered to the beneficiary. The screen is configurable depending on the campaign type, and the auto-calculated resources and quantity are displayed and populated in the fields. `The user can edit the fields if he/she needs to change the resource administered.
The “Date of Administration” is non-editable if the user records current delivery details. For past delivery data, the field must be editable with a restriction on the earliest date that can be captured (cannot select the date less than that of previous dose, and if additional time interval is added).
Click here to know more.
When a user clicks on the ‘Next’ button on the “Deliver Intervention” screen, a pop-up appears to check if the user observed any adverse events in the beneficiary. Click here to know more.
The user must provide the details for whether the delivery was successful or not. If the user selects ‘No’, an additional field must appear asking for the reason of non-delivery.
The dropdown must have the reasons that are configured in the MDMS. After selecting the response, the user must click on the ‘Submit’ button, which opens the acknowledgement screen stating that the delivery was successful. The user can go back to the search household screen or record the next dose, if required.
