Why Constraint Management Defines Schedule Quality

Every homecare visit carries constraints: the client is only available during certain hours, the caregiver must hold the right qualification, a shower visit must precede lunch by at least 30 minutes, and weekly frequency must be respected. Multiply this by hundreds of clients and thousands of visits and you face a combinatorial explosion that no human scheduler can solve manually — and that can easily break an automated solver if the constraints are not designed carefully.

The core challenge is not adding more constraints, but managing which constraints to enforce as absolute rules (hard) versus which to treat as optimization targets (soft), and how to structure multi-day patterns so the solver retains the freedom it needs to find high-quality routes. Caire's approach, grounded in both academic research and operational results from Swedish hemtjänst, can be summarized in one principle: use the simplest possible tool at each layer.

Caire's Three-Layer Constraint Model

Layer 1 — Care decisions, services, and visit templates

All planning in Caire starts from the municipal care decision (biståndsbeslut). This is translated into services (insatser) such as shower, lunch, or cleaning, each with organization-wide defaults: a standard time slot, competency requirements, time flexibility (±30 min), and an overlap rule. Services are grouped into service groups (insatsgrupper) that define intra-day ordering and minimum time distances — for example, breakfast → minimum 3 hours → lunch → minimum 4 hours → dinner. For each client, a visit template (besöksmall) captures which days, how long, and under which rules the visits should occur. Templates contain no dates — only rules. When a template is created, Caire automatically generates dependencies from the service group; the scheduler can accept or adjust them.

Layer 2 — Schedule and dated visits

Caire automatically generates concrete dated visits from templates. Inter-day spacing (every other day, 3×/week) is resolved here by selecting the correct calendar days — not by sending complex recurrence rules to the optimizer. For example, a shower template set to Mon+Wed+Fri automatically guarantees 48-hour spacing through day selection alone. This pre-computation is critical: it removes an entire class of constraints from the optimization layer, keeping the solver fast and flexible.

Layer 3 — Shift generation, route optimization, and solution

With dated visits in place, Caire generates the shifts needed to cover demand — respecting Swedish labor law, existing employment contracts, and staff preferences — and then runs route optimization. The constraint hierarchy at this layer is: (1) pre-computed (day selection already done), (2) time windows handle ~85% of all scheduling conditions, (3) dependencies used sparingly only where time windows overlap or a clinical requirement demands it. The result is an assignment of each visit to a specific caregiver at an exact start time.

Hybrid Recurrence Model: Templates with Instance-Level Overrides

The core design tradeoff

Defining all constraints at service-template level gives a compact, manageable model — but it is brittle. A single poorly designed rule can make an entire week of visits infeasible. Defining all constraints at the individual visit instance level gives maximum flexibility, but the combinatorial search space explodes, degrading solver performance with long runtimes and propagation stalls. The pragmatic best practice is a hybrid model: general recurrence rules (frequency, allowed days, time windows) are stored at template level. Templates materialize into visit instances for the planning horizon (1–4 weeks rolling). Materialized instances inherit template defaults but can be individually overridden to handle exceptions — a one-off assessment, a discharge visit, a family-requested change — without affecting the recurring pattern.

Soft constraints at template level

Even at template level, most rules should be modeled as soft constraints with penalty weights rather than hard prohibitions. This means deviating from a preferred day costs a penalty in the objective function instead of making the schedule infeasible. The solver can then weigh day preferences against route efficiency, workload balance, and other objectives — and find the best possible compromise even under disruption.

Hard vs. Soft Constraints: Where the Line Must Be Drawn

Hard constraints — inviolable rules

Hard constraints must be satisfied for any solution to be valid. A violation makes the schedule infeasible. Examples: a caregiver cannot be in two places at once; a visit requiring a specific clinical skill must be assigned to a caregiver with that skill; a visit that is clinically prerequisite to another must precede it. Overusing hard constraints — for example, pinning every visit to a specific time or strictly enforcing every patient preference — makes the model brittle. A single disruption (a caregiver calling in sick, a client having an unexpected appointment) can cascade into complete infeasibility.

Soft constraints — optimizable preferences

Soft constraints are desirable but not mandatory. Violating one incurs a weighted penalty in the objective function. Examples: assigning a client their preferred caregiver (continuity of care); scheduling a visit on the client's requested day of the week; minimizing caregiver travel time; minimizing overtime. The optimizer finds the solution that minimizes total penalty score across all soft constraints — making intelligent tradeoffs between competing preferences.

Lessons from Swedish hemtjänst: avoiding minutstyrning

Research from Swedish homecare (hemtjänst) provides a powerful real-world cautionary tale. The practice of 'minutstyrning' — where municipalities predetermine exactly how long each task should take, and that time cannot be used for anything else regardless of the client's needs on a given day — is used by one in four Swedish municipalities (Socialstyrelsen). This extreme form of hard constraint scheduling is associated with lower satisfaction for both clients and staff. Studies show satisfaction is significantly higher where clients and staff have greater influence over timing and content. The practical lesson: reserve hard constraints for absolute, unbreakable rules. Model everything else as weighted soft constraints.

Dependency Implementation: minDelay/maxDelay vs. Hard Pinning

Relative delay constraints — the preferred approach

Relative delay constraints define the relationship between two visits temporally rather than absolutely. For example: 'Visit B must occur at least 24 hours (minDelay) and no more than 72 hours (maxDelay) after Visit A.' Modern solvers like Timefold FSR support advanced variants: delay to the next day, next week, or next specific weekday (e.g., next Monday). This preserves the solver's combinatorial freedom — it can choose the best possible day and time within the window, enabling superior route optimization and workload balancing. It effectively models clinical cadences ('a follow-up visit within 3 days') without unnecessarily restricting the schedule.

Hard pinning to specific days — use only when unavoidable

Pinning a visit to a specific calendar date collapses the solution space for that visit and all visits dependent on it. The benefit is simplicity; the cost is significant: cascading infeasibility where a single pinned visit makes it impossible to schedule related visits efficiently or at all. Reserve hard pinning only for cases with absolute, immovable constraints — a visit that must coincide with a family member's presence, or a fixed medical appointment with an external party.

How Caire resolves this at Layer 2

Caire's three-layer architecture elegantly sidesteps most inter-day dependency complexity. Patterns like 'shower every other day' or 'cleaning once per month' are resolved by selecting the correct days at schedule generation time (Layer 2). The optimization engine at Layer 3 never sees these as constraints — they are already encoded in which visits exist on which dates. This reduces the optimizer's constraint load dramatically and keeps the model lean.

The KISS Principle for Homecare Solvers

The KISS principle — Keep It Simple — is not about building less capable systems. It is about recognizing that every unnecessary constraint reduces the solver's search space, and a smaller search space produces worse solutions or no solution at all. The tradeoff is real: highly detailed, rigid constraints increase the risk of over-constraining the model (infeasibility), while simpler, flexible constraints maximize the solver's ability to find high-quality feasible solutions.

Avoid hard pinning

Instead of fixing visits to specific days, define a frequency per week, a set of allowed days, and a time window. Use soft penalties to guide the solver toward preferred days without forcing its hand.

Limit complex dependencies

Only model precedence and synchronization constraints that are clinically necessary. Unnecessary links between visits artificially shrink the solution space. Caire's data shows that time windows alone handle approximately 85% of all scheduling conditions — dependencies are the exception, not the rule.

Manage problem scope with rolling horizons

Materialize visit instances only for the immediate planning horizon (1–4 weeks on a rolling basis), not for an entire multi-month care episode. The problem size stays tractable and the model stays current with real-world changes.

Use goal programming for lower-priority rules

Employ a hierarchy of soft constraints (lexicographic objectives) to handle lower-priority rules without risking infeasibility. Care delivery always takes priority over cost optimization.

Managing Infeasibility: Diagnosis and Resolution

Proactive validation before optimization

Before running the optimizer, perform pre-flight checks: verify there is sufficient staff supply for visit demand, check that frequency and day-of-week combinations are achievable within the planning period, confirm that all required skill coverages can be met. Many infeasibility conditions can be caught deterministically before the solver even starts.

Reactive diagnosis: IIS and conflict refiners (MIP solvers)

For Mixed-Integer Programming solvers like Gurobi and IBM CPLEX, the Irreducible Infeasible Subsystem (IIS) or Conflict Refiner is a powerful diagnostic tool. It identifies the minimal subset of conflicting constraints such that: the subset is itself infeasible, but removing any single constraint from it makes the remaining system feasible. This pinpoints the exact root cause — for example: 'This visit cannot be scheduled because the client is only available on Monday, but the required nurse is on leave, and a minimum delay constraint from the preceding visit would push it past Monday.' Schedulers receive an actionable explanation and can make a targeted decision: widen a time window, allow a different caregiver, or relax a dependency.

Reactive diagnosis: constraint propagation failures (CP solvers)

Constraint Programming solvers like Google's OR-Tools CP-SAT do not provide built-in IIS. Infeasibility is discovered through constraint propagation — when the domain of a variable is wiped to empty, a contradiction exists. Practical debugging techniques: (1) Incremental modeling — add constraints in small groups until the model becomes infeasible, isolating the problematic set. (2) Assumption-based conflict search — test feasibility under specific assumptions and use the returned conflict core to diagnose. (3) Log inspection and constraint toggling — systematically disable constraints to observe propagation behavior. These techniques require more manual effort but are effective for debugging complex models.

User-facing explanations

The ultimate goal of infeasibility handling is not just a technical fix — it is to give schedulers clear, actionable explanations they can act on. 'Visit X cannot be scheduled: the client is only available Mon/Wed, but the required caregiver is on leave both days. Suggestion: widen the allowed days or assign a different caregiver.' This empowers schedulers to make informed decisions rather than facing an opaque 'no solution found' error.

References and further reading

Conclusion: Simplicity Scales, Rigidity Breaks

The most effective homecare scheduling systems are not the most constrained — they are the most intelligently constrained. Caire's three-layer model separates the concerns of care planning (templates), schedule generation (dated visits), and optimization (routing and assignment). Time windows handle ~85% of scheduling conditions at Layer 3. Dependencies are used sparingly, only where clinically required. Soft constraints give the optimizer the flexibility to find high-quality solutions even under real-world disruption. The alternative — rigid, pinned schedules with hard constraints for every preference — produces brittle models that break under the first deviation from plan.

Want to see how Caire's constraint model works with your data? Contact us for a demo or try the platform at app.caire.se.

See constraint management in action

From care decision to optimized schedule — three layers, minimal constraints, maximum efficiency.

Explore route optimization

Try the optimization now

Open app.caire.se

Effective Constraint Management in Homecare Scheduling Optimization