Redesign Emergency Requisitions
Goals/Scope
- The purpose of this requirement is to improve the following process for Emergency Requisitions by:
- Allowing the user to search for and select (facility type approved) products to add to the Emergency Requisition (as of 3.2.1 the emergency requisition includes all products that have previously reported)
- Emergency Requisition follows the same approval workflow as regular period requisition
- Emergency Requisition does not require reporting
- Allowing the user to search for and select (facility type approved) products to add to the Emergency Requisition (as of 3.2.1 the emergency requisition includes all products that have previously reported)
Background
The Emergency Requisition was originally designed to duplicate the entire period's regular requisition for the user to complete and submit. Therefore, the emergency requisition form requires the user to populate all fields and all products (that have reported) in the requisition before they can submit; regardless of whether they are requesting all of the products in the requisition. See 3.0 design here: Emergency Requisitions
Current workaround:
When a user initiates an emergency requisition, they cannot skip products that have been previously reported. Malawi, Tanzania, and Zambia have confirmed that when users are completing emergency requisitions, they are are only requesting a few products and it is not an efficient process for the users to complete reporting for all products before they can complete their emergency requisition. Malawi's current workaround has been to zero out all fields within an emergency requisition, skip products that they are not requesting, and then enter requested quantities for the products they need. This workaround may create data integrity issues for the next period's beginning balance. They must zero out the products (and not delete or erase data in the fields) because the products are required to report.
Assumptions
- Need to determine if we should limit how many emergency requisitions a user can enter per period. A problem with emergency requisitions is that the central medical stores prioritize emergency requisitions higher than regular requisitions, and this can cause a delay in processing the regular period requisitions.
- The frequent use of emergency requisitions within a period can point to an issue with the health of the supply chain, and may need to be tracked or reported.
Mockup for redesign emergency requisitions that was agreed on in Product Committee meeting:
User Stories
| # | Title | User Story | Label | Importance | Notes |
|---|---|---|---|---|---|
| 1 | Emergency requisition redesign | As Raquel I need to create an emergency requisition with only the requested products and quantities so that I can submit my request quickly. | Must Have |
| |
| 2 |
Diagrams
Dependencies
| Description | Link |
|---|---|
Open Questions
Below is a list of questions to be addressed as a result of this requirements document:
| # | Question | Outcome | Status |
|---|---|---|---|
| 1 | When a user is completing an emergency requisition, do they need to provide data to report for that product? Will they need to complete all fields in the requisition form before requesting, or is the requested quantity the only field that is required? | Yes. Option B is the preferred solution. | Closed 1/12/18 |
| 2 | Should the Emergency Requisition remember the products that were requested during a previous period? Is there a trend of products that are requested before a period ends? Do we need to track and report emergency requisitions to identify where a problem exists in the normal requisitioning process? | No, this is out of scope for this redesign. Currently emergency requisitions do not remember previously reported and requested products, and this should be the same going forward. Reporting on emergency requisitions is already being discussed separately. | Closed 1/12/18 |
| 3 | Is the available product list for emergency requisitions the same as regular requisitions? Or should there be a limit to which products can be requisitioned? Should the list of products available to requisition in an Emergency Requisition be configurable by the administrator? How should full supply vs non-full supply products appear in the available product list? For non-full supply products, the user isn't required to enter regular reporting numbers. This may be difficult to display in the emergency requisition, but a user needs to be able to request both full supply and non-full supply products. | Yes, the full product list that is used for regular requisitions should also be available for emergency requisitions (same as current state). Update mockup to show: Non-full supply tab for emergency requisitions. This should work the same as it currently does for emergency requisitions, where the user is only required to add a product and enter the requested quantity and explanation. | Open - pending updated mockup |
| 4 | How will the new design integrate with stock cards in Stock Management? OLMIS-3505 - Getting issue details... STATUS | ||
| 5 | What, if anything, needs to be configurable for this feature to support different country's implementations? This was brought up in PC: October 24 2017
| No additional configurability. | Closed 1/12/18 |
| 6 | Are there any key design issues that we need to consider?
| No, this is out of scope for this redesign. | Closed 1/12/18 |
| 7 | How should emergency requisitions be approved? Should they be allowed to approve in batches alongside regular requisitions? (How does this affect the batch approvals page?) Current proposal will not change the approval hierarchy. | There are no changes to the batch approval process for regular and emergency requisitions with this redesign. | Closed 1/12/18 |
| 8 | When a user has completed their emergency requisition, how are the regular requisition reporting numbers affected? Consumption, balances, etc.
| Sam Im (Deactivated) to confirm that opening balance is updated per comment in #8. Sam Im (Deactivated) to confirm current scenario: | Open |
| 9 | Requested quantity explanation free text entry forces the user to provide information that does not make sense. Can this be a dropdown selection? If so, what reasons would be selectable from the dropdown. In the case of emergency requisitions, most of the meaningful reasons have come from the approved quantity explanations. Check with Alfred. Nuran's experience is that the requested quantity explanation has not been useful, and the users are entering random data since the field is required. Reporting would be more helpful if there was a dropdown. | Nuran is gathering more information about the requested quantity explanation and its usefulness. This will remain as required for emergency requisitions redesign. OLMIS-3976 - Getting issue details... STATUS | Closed 1/12/18 |
Out of Scope
- Limiting the number of emergency requisitions within a period
OpenLMIS: the global initiative for powerful LMIS software