Resource Caseload

Normally a resource is a pool and any free unit serves whoever is next. Caseload changes that: a case is bound to one unit of the resource, and that same unit serves it on every later visit. This is continuity of care, the pattern behind a named nurse, a case worker, an account manager, or a mechanic who owns a job from start to finish.

The tab is one toggle until you turn caseload on, and the rest of the fields appear beneath it.

Enable caseload

Off by default. With it on, the first time an entity is served by this resource it is bound to the unit that served it, and every later request from that entity goes to the same unit, waiting for it if it is busy.

How much one worker can carry

Two independent ceilings, both optional. Leave either blank for no limit.

• Max active cases is a straight count of concurrent bound cases.
• Max workload is a ceiling on the total weight of those cases, so a worker can hold many simple cases or a few heavy ones.

The two are checked separately. Max active cases takes no notice of case weight at all, so a worker at a count ceiling is full even if every case is trivial. Set the one that matches how the real constraint works, or set both when both apply.

Both accept a number, a variable, or a distribution, and both are worked out once at the start of each replication. Entity attributes are not allowed, because the ceiling belongs to the worker rather than to any one case.

Case weight

Case weight is how much of the workload ceiling one case takes up, and it is read from the case itself, so it can be an attribute such as a_Acuity, an arithmetic expression, or a plain number. It defaults to 1, which makes workload behave the same as a case count until you change it.

The weight is re-read every time the case comes back, so a case that gets heavier as it progresses takes up more of its worker’s capacity as it goes. A weight of zero or less stops the run, since it would let a worker take on unlimited cases.

Case weight and the workload ceiling sit behind a Weighted workload disclosure, which opens on its own once any of them is set.

When no worker has room

What happens when a new case arrives and every unit is at a ceiling:

• Queue: the case waits until a worker has room. Capacity is respected, and the wait shows up in the results.
• Allow over: a worker takes it anyway and the over-cap is recorded. Use this when the real system does not turn work away, and you want the report to show how often that happened.

Always accept when

A condition that bypasses both ceilings for the cases that match it, for example a_ESI = 1 for a top-priority patient. Leave it blank and nothing bypasses them.

Two ways to get it wrong: an override on a resource with no ceilings set has nothing to bypass and does nothing, and an override that does not reference a case attribute is true for every case, which is a slower way of writing Allow over.

Handoff partners

When a worker goes off shift their bound cases have to go somewhere. Handoff partners is the list of other caseload-enabled resources that may inherit them.

At each shift change, the cases of the departing worker are redistributed heaviest first onto the least loaded partner who is on shift, and a partner coming on shift picks up cover before taking any new arrivals. If no partner is on shift, nothing moves and the cases stay bound where they are until someone is available.

The list only appears when the resource has a shift schedule, since handoff happens at shift boundaries. Give the resource its shift first.

Working with other resource settings

• Resource groups: a group’s defaults stamp its caseload settings onto every member, so a whole team can be configured once. Handoff partners are the exception and stay per resource, unless the group is set to hand off among its own members.
• Dedicated resource connections: a connection set to Dedicated requires caseload on the resource it comes from, and that resource must have a quantity of exactly 1. Without both, the model will not run. See Resource Connectors.

The live Track board

Caseload is easiest to follow while it runs. During an animated run on a caseload model, a toggle on the Simulation Bar opens the Track board, a live whiteboard of who is carrying what, in the spirit of the board on an emergency department wall.

Each caseload resource gets a section, with a row for every unit. A row shows the unit’s state (Busy, Idle, Off shift, or Over cap), its bound case count against the ceiling (for example 1 of 10), and a load bar that fills as the unit takes on weight, turning amber as it nears the ceiling and red past it. Open a row to list its bound cases with their weights.

Below the units, the Waiting list is the cases queued to be assigned, in the order the model works through them, priority first and then by how long each has waited. A green dot means the case fits a worker right now, a grey dot means it is blocked, and hovering a blocked case names the worker leg that is full and by how much.

The toggle appears only for a caseload model, and it needs animation on, since the board is drawn from the animated run. Turn animation off and the toggle is disabled with a note saying so.