Visit data lifecycle | CAIRE Platform

🏛

Municipality care decision (assistance decision)

Starting point — approved services, counts and frequency per client

The municipality decides which services a client is entitled to and how often. This is the legal basis for all planning. CAIRE translates the decision into services and templates in Layer 1.

Example

Anna Svensson — Approved for: Shower 3×/week, Lunch on weekdays, Cleaning 1×/month.
The client view in CAIRE shows decision (hours), planned (from templates) and used (completed visits) — so the planner sees gaps between law, plan and reality.

1

Master data — care decision, services, groups and visit templates

Time-independent data: what the client needs, under which conditions, and how services connect

1A. Services (service types)

A service is a type of care or service clients may be approved for. Each service has organisation-wide default values:

Priority

How urgent the service is (default per type).

Time windows

Which part of the day, e.g. Morning 07:00–10:30.

Skill requirements

Gender, language, specific certification, etc.

Time flexibility

How much the visit can move, e.g. ±30 min.

Overlap rule

Can two visits happen in parallel at the client?

Note: Length/duration is set per client in the visit template — not on the service. The service defines what; the template defines how long for that client.

1B. Service groups and dependencies

A service group bundles services that belong together in one day, in a fixed order with timing between steps. Each member has a sequence position and specifies minimum (and optional max) delay from the previous service.

Example: Service group "Meals" — time windows are enough

[1] Breakfast
Morning 07–10:30

|

[2] Lunch
Lunch 11–13:30

|

[3] Dinner
Evening 16–19

The windows do not overlap → order follows automatically without dependencies. Breakfast only in the morning, lunch at lunchtime, dinner in the evening. No min/max dependency is needed.

Design principle — time windows before dependencies: If each meal has its own non-overlapping window (morning, lunch, evening), no 3h/4h dependencies are needed for order. Dependencies (min/max time between services) should only be used when there is a clinical requirement for an exact span — e.g. "at least 3 hours between meal and medication". Always use the simplest tool.

Example: Service group "Shower + Lunch" — dependency required

[1] Shower
11:30–12:00, double staffing

→ immediately after (0 min) →

[2] Lunch
12:00–12:30

Visits must run back-to-back in the same window. Here the dependency (0 min) is required — time windows alone cannot guarantee lunch immediately after shower.

Design principle: Always ask first: can order be solved with non-overlapping time windows instead of a dependency? In the example above the windows overlap, so the dependency is needed. But if shower and lunch had separate slots (e.g. shower 07–09, lunch 11–13) order would follow automatically — without dependency. Always choose the simplest tool.

Across days — frequency and spacing (pre-computed):

Shower Mon+Wed+Fri → automatic 48h spacing via day selection.
Cleaning 1×/month → spread evenly across the period.
Every other day → CAIRE picks the right days when the schedule is created.

Cross-day spacing is never modelled as heavy dependencies for the optimiser — the right days are computed when the schedule is created in Layer 2.

Per-client override: The service group timing is the default. In the visit template the planner can change for one client, e.g. "at least 3 hours" → "at least 2 hours".

1C. Time windows

Time windows divide the day into named periods. They are the main lever for when services should occur. When windows do not overlap, no special dependencies are needed.

Morning
07:00–10:30

|

AM/Lunch
11:00–13:30

|

Evening
16:00–19:00

1D. Shifts

Shifts define staff working periods. They are used both as frames for visit templates and as the basis for workforce planning in Layer 3.

Day
07:00–16:00

|

Evening
15:00–22:00

|

Weekend
08:00–17:00

1E. Visit templates (per client)

The visit template links the care decision to the operational schedule. One template per service per client. The template holds pattern rules, not calendar dates.

Service

Which service, e.g. shower.

Duration

How long, e.g. 25 minutes.

Days

E.g. Mon, Wed, Fri.

Frequency

Every week, every other week, 1×/month.

Time windows

Shift, slot or exact interval (07:00–09:00).

Skill requirements

Additive on top of the service defaults.

Double staffing

Visits that require two carers at once.

Preferred carers

Which staff the client prefers. The optimiser weights continuity toward these.

Priority

How important the service is in conflicts (normal, high, critical). Can override the service default.

Locked / pinned

The visit must not be changed by the optimiser — staff and/or time fixed. Use sparingly.

Dependency override

When the service group timing does not fit the client.

Example: Anna Svensson’s visit templates

Template 1 — Shower: Mon+Wed+Fri, 25 min, 07:00–09:00, double staffing (2 carers)
Template 2 — Lunch: Weekdays, 20 min, immediately after shower (from service group)

Dependencies can be inherited from the service group when the template is created. The planner can accept or adjust.

1F. Smart recommendations (new clients)

When a new client is onboarded, CAIRE can automatically recommend visit templates based on three factors:

Client needs

Care decision, service types, preferences.

Organisation rules

Work patterns, routines, preferences.

Area status

Existing visits and shifts — where is capacity?

The planner can accept, adjust or reject the suggestions.

How CAIRE handles constraints — simplest tool first

The fewer unnecessary dependencies, the faster and better the optimisation. Over-specifying makes the schedule rigid and increases the risk that visits cannot be placed.

1

Pre-computed (when the schedule is built)

Day selection, frequency, cross-day spacing. Mon+Wed+Fri → 48h automatically. Every other day, 1×/month — correct days chosen in Layer 2. Nothing is sent to the optimiser.

2

Time windows (~85% of all constraints)

Non-overlapping slots and shift boundaries give implicit order. Maximum freedom for the optimiser to find the best routes.

3

Dependencies (sparingly — only when needed)

Min/max delay between services same day. 0 min: shower + lunch in same slot. 3 h: clinical requirement. Stored in care planning, read at optimisation.

Hybrid modelling (best practice): Recurring rules live in templates; they materialise to dated visits per period. Instance overrides exist for exceptions. Preferences should be soft goals; reserve hard constraints for law, skills and clinical must-haves.

Fixed routes are manual planning’s answer to an optimisation problem

In traditional home-care planning, routes (fixed rounds with fixed visits in fixed order) are copied from period to period. The route implicitly bundles continuity, priorities, dependencies and time logic — baked into one sequence. CAIRE models each requirement explicitly and separately, so it does not need routes at all.

Aspect	Fixed route (manual)	CAIRE
Continuity	Implicit — same staff, same round. Breaks on sickness or change.	Explicit optimisation: preferred carers, continuity score as soft goal.
Visit order	Fixed sequence in the route. Change means replanning the whole route.	Time windows and dependencies drive order automatically. Optimiser finds best route.
Efficiency / travel	Depends on the route being good from the start. Often suboptimal — hard to review all rounds manually.	Route optimisation computes travel and finds the most efficient order given all requirements.
Priorities	Implicit in route order. No systematic way to prioritise in conflicts.	Explicit priority per service/template. Hard requirements always met; soft ones optimised.
Dependencies	Baked into the route — visible only to whoever built it.	Explicit in service groups and templates. Visible, editable, inheritable.
Changes	The weakest point. New client, sick staff, changed decision → route must be rebuilt manually. Often patches that accumulate problems.	Run optimisation again. CAIRE computes a new best solution given current requirements and changes.
Quality at start	Highly variable. Often wrong from the start — hard to manually optimise hundreds of visits.	Optimal from the start. Each period is optimised mathematically under all constraints.

Summary: Fixed routes are a shortcut that bundles requirements (continuity, order, travel) into an opaque package. It works until something changes — but home care changes constantly. CAIRE splits each requirement into an explicit attribute (time window, preferred carers, priority, dependency, lock) and optimises the whole. Changes are handled quickly and correctly without tearing up an entire route.

Service group → Visit template → Visit — how properties inherit

The planner rarely needs to edit individual visits. Most changes are made at service group or template level and inherit on the next materialisation.

Property	Service group (default)	Visit template (client level)
Duration	—	25 min
Priority	Normal	High (override)
Time window	Morning 07–10:30	07:00–09:00 (tighter)
Skill requirements	Gender: female	+ double staffing (additive)
Preferred carers	—	Anna P., Erik S. (soft goal in optimisation)
Min delay	3 h (group default)	2 h (client override)
Double staffing	No (default)	Yes — two carers required
Locked / pinned	—	No (default) — can be set per instance

2

Schedule — concrete visits with dates

Planning window (e.g. 4 weeks) with dated visits ready for review and optimisation

2A. Area and time period

The schedule is created for one or more service areas and a time period (2 weeks, 4 weeks, quarter). The period should cover the longest frequency — if cleaning is 1×/month the window must be at least one month.

By selecting multiple areas the planner can run what-if scenarios and see how KPIs such as continuity and efficiency change if areas are merged.

2B. Day pre-computation

Templates expand to specific dates. Every other day, 3×/week, every 4th week — correct days are computed here. Cross-day spacing is handled via day selection, not as dependencies for the optimiser.

2C. Rules projected to visit level

Organisation and client rules (dependencies, preferences, skills, groups) are stored once at client/care-plan level. When the schedule is built CAIRE projects them onto each new visit. The next period automatically reflects updated care plans — without copying the previous schedule as source.

2D. Editable

The planner can add, remove or adjust individual visits before optimisation runs. Changes are tracked so the planner knows what changed since the last run.

Example: Anna Svensson’s shower template → dated visits

Template: Mon+Wed+Fri, 07:00–09:00 → Generated visits for 14–25 April:

Date	Time window	Service	Double
Mon 14 Apr	07:00–09:00	Shower	Yes
Wed 16 Apr	07:00–09:00	Shower	Yes
Fri 18 Apr	07:00–09:00	Shower	Yes
Mon 21 Apr	07:00–09:00	Shower	Yes
Wed 23 Apr	07:00–09:00	Shower	Yes
Fri 25 Apr	07:00–09:00	Shower	Yes

For each shower visit a lunch visit is also created immediately after (from the service group dependency). 48h spacing is guaranteed by Mon+Wed+Fri day selection.

✓

Checkpoint 1: Do the visits look correct?
Right clients, right services, right days and time windows. If not — adjust directly in CAIRE.

3

Optimisation — assigned staff and exact times

The solver matches visits to staff and optimises for continuity, efficiency and legal requirements

3A. Supply: shifts and availability

Shift generation and contract rules (working time law, agreements, preferences) define supply. The planner can review supply before or after an optimisation run depending on workflow.

3B. Optimisation and assignment

Demand

All visits with time windows, skill requirements and dependencies.

Supply

Staff, skills, shifts, working times, travel times.

Result

Each visit → assigned staff + exact start time.

3C. Hard and soft constraints

Type	Meaning	Examples
Hard (must hold)	Requirements that must never be broken.	Working time law, skill requirements, staff cannot be in two places at once.
Soft (desirable)	Optimised but may be relaxed. CAIRE finds the next-best solution.	Preferred day, continuity, minimised travel.

Principle: Use soft constraints where possible. That adds flexibility, reduces the risk that visits cannot be scheduled, and improves overall outcomes.

3D. Staff and client views

The planner reviews the same schedule in two perspectives (same data, same filters — only grouping and colouring change):

👤

Staff view (row = carer)

Classic route view. Travel between visits. Workload per carer.

🏠

Client view (row = client)

All visits per client. Staff colours show continuity. Overlap is obvious.

3E. After optimisation — actions

Action	Description
Save (this visit)	Adjust a single visit in the solution without a full re-run.
Validate	Quick score/feasibility check (sync) before a large change.
Re-optimise	Run the solver again (e.g. after pinning, closure, weight changes). May be async.
This instance vs all future	Change can apply to this visit only, or edit the template and propagate to future visits.

✓

Checkpoint 2: Does the optimised assignment look reasonable?
Assigned staff, exact times, routes, shifts. Compare scenarios if you like. Re-run when needed.

▶

Publish — the schedule becomes the active plan. Staff follow this schedule.

Draft

Visits are edited. Optimisation can run one or more times. The planner iterates until satisfied.

Published

The active plan. The chosen solution is locked for execution. One-off changes can still be made.

Archived

The period is closed or replaced by a newer rolling period. Historical reference.

Rolling planning

Each service area can be configured with a planning horizon (weeks per window) and lead time to create the next period before the current one ends.

First period: Created explicitly (wizard or equivalent) when templates and master data are ready.
Later periods: Auto-chaining creates the next period automatically. It lands as draft until the team publishes.
Continuity: The next period’s optimisation can favour continuity with the previous published solution (preferred staff in solver input).
Automatic optimisation: Optional — a new draft period can be optimised automatically in the background.

Ready to run is reflected by the solution status (optimisation done, routes ready), not extra ceremony like “accepted” or “planned” on the schedule. Visit changes are tracked so the planner knows what changed relative to an older solution.

Data can enter in several ways. The source of truth is always what is stored in CAIRE after import or registration — messy external files are mapped as well as possible; the planner corrects in the UI when needed.

📄

CSV import

Existing planning files are imported automatically. The adapter parses the format and maps to the CAIRE model: services, templates, dependencies and time windows are created.

Note: The CSV is not permanent truth. If it is wrong, data in CAIRE after import wins.

✏️

Manual entry

The planner creates visit templates and client data directly in CAIRE. When a service that belongs to a group is chosen, dependencies can be created from the group defaults. For new clients CAIRE can recommend templates.

⚡

Schedule wizard

When a new schedule is created, CAIRE loads templates and generates visits for the window. Day selection is computed; organisation rules are projected so dependencies, preferences and skills appear on visits.

CSV / manual / wizard

→

Data in CAIRE (source of truth)

→

Verify visits

→

Optimise

→

Verify assignment

→

Publish

🏛

Care decision — Client X approved for service Y, Z visits/week

▼

1

Layer 1: Services + service groups + time windows + shifts → Visit templates per client (with recommendations for new clients)

▼

2

Layer 2: Templates materialise → dated visits with pre-computed days + projected rules → Checkpoint: do visits look right?

▼

3

Layer 3: Demand + supply → optimisation → assigned staff + exact times → Checkpoint: reasonable assignment?

▼

▶

Publish → Draft → Published (live plan) → Archived | Rolling: next period is created automatically as draft