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.