Workflow pattern
A resource that must be allocated
Shows the shape where a limited resource is requested and allocated, how competing demands are ordered, and how the outcome is recorded.
A limited resource draws more requests than it can hold at once, so the order in which requests are met matters. This pattern sets out the shape a resource takes as it is requested and allocated, how competing demands are ordered, and how the outcome is recorded.
The shape
A resource is a limited thing the hospital allocates, such as a bed, an imaging slot, a theatre, or a piece of equipment. A request is a claim on that resource for one patient.
The shape has one entry and one settled exit. It begins with a request and ends with a recorded outcome, after which the resource returns to the pool.
Nexus Manager holds the resource and its state, Quest schedules the use against a time, Gate requests a bed as part of a visit, and Cirith Manager decides whether the allocating person may allocate.
Where it starts
The shape starts with a request. A claim is placed for one patient, and it carries the urgency of that patient's care.
The hospital model holds one shared state for the resource: whether it is free, in use, or already scheduled. The request reads that shared state, so every claim on the resource sees the same availability.
The path
- 1
The resource is requested
A request is placed for one patient, carrying the urgency of that patient's care.
- 2
Availability is read from the model
The hospital model shows the resource's current state and what is already scheduled against it.
- 3
Competing requests are ordered
Requests for the same resource are ordered by urgency and by the resource's availability.
- 4
The resource is allocated
The resource is allocated to one request, and a named person confirms the allocation.
- 5
The outcome is recorded
The allocation, the reason, and the deferral of any competing request are recorded.
- 6
The resource returns to the pool
When the use ends, the resource returns to the pool for the next request in the queue.
What is recorded
| Recorded item | What it captures |
|---|---|
| The request | The patient, the resource, and the urgency claimed. |
| The availability | The resource's state and what was already scheduled. |
| The allocation | Which request received the resource, when, and who confirmed it. |
| The deferral | A competing request held in the queue, with its reason. |
| The release | When the use ended and the resource returned to the pool. |
Tools in the shape
| Tool | Its part in the shape |
|---|---|
| Nexus Manager | Holds the resource, its state and its schedule, and manages the allocation of assets. |
| Quest | Schedules the use against a time and shows what is due. |
| Gate | Requests a bed as part of a visit and holds it through the stay. |
| Cirith Manager | Decides whether the allocating person may make the allocation. |
What holds throughout
One shared state per resource
The hospital model holds one shared state for each resource. A request reads that shared state rather than a copy, so two requests read the same availability and one allocation settles which claim holds.
Where the shape varies
The shape holds whether the resource is a bed, an imaging slot, a theatre, or a piece of equipment. What changes is the pool the request draws on and the urgency that orders it. A resource returns to the pool as each use ends, and the next request takes its turn.
Common questions
How are two requests for the same resource ordered?
By urgency and by the resource's availability. The request with the stronger claim receives the resource, and the other stays in the queue with its reason.
What happens to a request that misses the resource?
It stays in the queue with a recorded reason, and takes its place for the next release.
Where does the outcome live?
In the patient's record and against the resource in the hospital model, so both sides read the same allocation.
Read how beds and locations sit in the hospital model in units, locations and beds.