From care decision to completed visit

From the municipality care decision to a published schedule — three layers (master data, dated visits, optimisation) and how data flows in CAIRE.

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.

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

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

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.

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

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".

• 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.

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.

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

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.

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

The planner can accept, adjust or reject the suggestions.

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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

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. Schedule lifecycle 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 ro

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.

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.

• 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.

flowchart LR %% ========= COLORS (Caire palette-inspired placeholders) ========= classDef source fill:#cce7ff,stroke:#2a7de1,color:#000; classDef storage fill:#e0ffe5,stroke:#31a353,color:#000; classDef process fill:#fff3c4,stroke:#c79b00,color:#000; classDef security fill:#ffe0e0,stroke:#d63a3a,color:#000; classDef output fill:#e4d7ff,stroke:#7a4ed8,color:#000; %% ========= DIAGRAM START ========= subgraph "Attendo Systems (eCare Welfare)" welfareAPI["Welfare API (REST / Authentication)"]:::source welfareCSV["Welfare CSV Export (optional)"]:::source welfarePDF["PDF: Care Decisions (manual upload)"]:::source end subgraph "Caire Platform (AWS Stockholm - EU/EEA)" ingest["Data Ingestion Layer (API Gateway / Import Services)"]:::process validate["Validation + Normalization (Business Rules)"]:::process encrypt["Encryption & Access Controls (Transport & At-Rest)"]:::security store["Datastore