Admin: Automated edit (via update-page on MediaWiki MCP Server)

2026-07-06T04:16:58Z

Automated edit (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:46, 6 July 2026
Line 89:		Line 89:

	Roles are granted through a user's membership in a facility or organization, and permissions cascade down the organization tree — so a role held higher up applies to the facilities beneath it.		Roles are granted through a user's membership in a facility or organization, and permissions cascade down the organization tree — so a role held higher up applies to the facilities beneath it.

			{{Navbox supply}}

	{{Related}}		{{Related}}

Admin: OHC identity seed

2026-07-04T22:43:45Z

OHC identity seed

New page

{{Doc header
|type=concept
|domain=supply
|title=Supply Request
|order=4
|introduced=3.0
|concept=Concepts/Location
|reference=References/Supply Request
}}

A '''supply request''' is a line item asking for a specific quantity of a catalogue product to be moved into a facility location. It is how a ward, pharmacy, or store says "we need this much of this item here" — the demand signal that drives stock movement across your facility.

== What it represents ==

In Care's FHIR-aligned model, a supply request maps to the '''SupplyRequest''' resource. A single request captures just three things: the catalogue item wanted (a [[Concepts/Product Knowledge|product knowledge]] entry), the quantity, and where it sits in its workflow.

The key distinction to hold is that a supply request is not the handover of goods. It expresses demand only; the matching movement of physical stock is recorded separately as a [[Concepts/Supply Delivery|supply delivery]]. A request can be raised, fulfilled, or cancelled without anything having physically moved — which is why the request and the delivery are kept as separate records.

== How it connects ==

Supply requests rarely travel alone. Care groups them under a '''request order''', which is the unit people actually act on:

* A '''request order''' describes a movement of items into a '''destination''' facility location — for example, "restock the ICU pharmacy."
* One order fans out to '''many supply requests''', one per catalogue item being asked for ("50 of these gloves, 20 of that saline").
* An order can name a '''supplier''' organization it is sourcing from and an '''origin''' location it is drawing from, but only the destination is required.

This is the mental model to hold: the '''order''' answers "where is this going and roughly why," while each '''supply request''' inside it answers "which item, how much." Because origin and destination are tracked separately, the same physical location can appear as the origin on orders it sends out and the destination on orders it receives.

== Order classification ==

A request order carries a few coded attributes that help staff triage and route it — guidance values that shape how an order is read and prioritised, not actions that move stock by themselves:

{| class="wikitable"
|-
! Attribute
! Plain meaning
! Example values
|-
| Priority
| How urgently it is needed
| <code>routine</code>, <code>urgent</code>, <code>asap</code>, <code>stat</code>
|-
| Intent
| How firm the request is
| <code>proposal</code>, <code>plan</code>, <code>order</code>
|-
| Reason
| Why the stock is needed
| <code>patient_care</code>, <code>ward_stock</code>
|-
| Category
| Where it is sourced from
| <code>central</code> (central store), <code>nonstock</code> (special order)
|}

== Lifecycle ==

A supply request moves through its own status as it is worked, from preparation to fulfilment:

<syntaxhighlight lang="text">draft → active → processed → completed</syntaxhighlight>
* '''draft''' — being prepared, not yet acted on
* '''active''' — submitted and open for fulfilment
* '''suspended''' — temporarily paused
* '''processed''' — picked up and being acted on
* '''completed''' — fully fulfilled
* '''cancelled''' — withdrawn before fulfilment
* '''entered_in_error''' — recorded by mistake and voided

The parent request order tracks a parallel status of its own — <code>draft</code>, <code>pending</code>, <code>in_progress</code>, <code>completed</code>, <code>abandoned</code>, or <code>entered_in_error</code> — so you can read the state of the whole order independently of any single line item, with the last three treated as closed. Note that status is a workflow label, not an enforced state machine: Care does not block a transition, so the lifecycle reflects how teams agree to work rather than a hard rule.

== Permissions ==

Access to supply requests is controlled by two role-based permissions scoped to a facility.

{| class="wikitable"
|-
! Permission
! Description
! System Roles
|-
| <code>can_write_supply_request</code>
| Create and update supply requests within a facility
| Facility Admin, Admin, Staff, Doctor, Nurse
|-
| <code>can_read_supply_request</code>
| View and list supply requests within a facility
| Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer, Pharmacist
|}

Roles are granted through a user's membership in a facility or organization, and permissions cascade down the organization tree — so a role held higher up applies to the facilities beneath it.

{{Related}}

Concepts/Supply Request - Revision history

Admin: Automated edit (via update-page on MediaWiki MCP Server)

Admin: OHC identity seed