Requisition Groups

Requisition Group

is a container for defining and managing a logical collection of facilities that (1) manage Programs on the same Schedules, (2) make use of the same review/approval hierarchy, and (3) rely on the same warehouse/stocking depots for fulfillment of their Orders. A Requisition Group has very specific structural scope: a Requisition Group has one or more member Facilities, and one Supervisory Node.

Supervisory Nodes are logical points of information aggregation and processing: Requisitions from member Facilities in Requisition Groups – or from subordinate Supervisory Nodes – flow upwards for reviews, approvals, rationing and eventual conversion into Orders… the root or top node in a hierarchy of Supervisory Nodes is the point of final review, where Requisitions become Orders, and then sent to the designated warehouse / stocking depot to be filled and shipped.

Requisition Groups themselves are not part of any parent/child or peer relationship, and are not arranged in any sort of hierarchy. However Supervisory Nodes are arranged in hierarchical trees (cycles are not allowed), with each tree having depth >= 1. A hierarchy of Supervisory Nodes codifies the chain of reviews and approvals for Requisitions from member Facilities, up to the point where the Requisitions are converted to Orders and sent to a designated warehouse for fulfillment.

Requisition Groups are also specific in terms of their operational scope: a Requisition Group manages the requisitioning process for a specific set of Programs, with each Program on a specific Schedule. The set of Programs managed by a Requisition Group need not all be on the same Schedule; individual Programs managed by the Group can be on different Schedules. However, any Facility in the Group that supports a Program which is managed by the Requisition Group will (by virtue of being a member of the Group) run its requisitioning process on the Requisition Group’s schedule for that specific Program. A Facility cannot belong to more than one Requisition Group that each mange the same Program(s) supported by that Facility – membership in multiple Groups that manage the same Program could make it impossible for the system to determine which schedule the Facility should operate on for the duplicated Program, and impossible to determine where to route its Requisitions for review, approval and fulfillment.

Individual Facilities in a Requisition Group need not support every Program that is managed by the Group. Instead, the Facility relies on the Requisition Group to manage the replenishment process for the Programs which are in common with those that the Facility itself supports.

Note, we use the verb “support” to refer to Programs that are in operation at a Facility, providing service to patients for the particular Program (e.g., the facility supports Malaria care). We use the verb “manage” to refer to Programs where a Requisition Group coordinates the requisitioning/replenishment process for Facilities that are members of the group. As noted previously, the Requisition Group runs the requisition process for some specific set of Programs, each on a specific Schedule.

A Facility can belong to more than one Requisition Group, provided there is no overlap in the Programs managed by Requisition Groups to which a Facility belongs. For example, a Facility might belong to one Requisition Group which manages Essential Medicine and Malaria Programs for the member Facilities; the Facility could also belong to a different Requisition Group that manages TB and Vaccination Programs for its member Facilities. (Reasons for having this delineation into two separate Requisition Groups would be that they have different approval hierarchies and/or the Orders are filled by different warehouses for the two sets of Programs.) Relatedly, a Facility must belong to one or more Requisition Groups that, taken together, manage all the Programs supported by the Facility, otherwise the facility has no one to manage the requisition process on its behalf, for all its Programs. For example, if a Facility does not belong to any Requisition Group that manages Vaccination Programs, then that Facility has no supervisory service or warehouse to handle its Requisitions, and thus cannot get resupplied.

Note also, the member Facilities in a Requisition Group are assumed to be service delivery points, where normally one or more programs are actively supported. (We say “normally” to allow for the case where a facility’s support for a particular program may be temporarily suspended, e.g. in the case where the medical specialist in charge of the program left the facility, and the facility is not properly staffed to run that program until they hire a replacement specialist.)