Care Plans & the Care Task List

Part of the Anaya Care Handbook — the source of truth for how the product must behave. When the product needs to change, change this document first, then make the system match it.

What this covers

This page governs how a client's plan of care is written and how that care is carried out shift by shift. There are two distinct documents: the care plan — the narrative describing how the client should be cared for — and the Care Task List — the concrete, recurring to-do list attached to each of the client's schedules. Care providers see the Care Task List expanded into their shifts on mobile, record each task as a task submission, and families review those submissions and can raise concerns that the agency must address.

For the step-by-step instructions a care provider reads before performing each task, see AI-Generated Task Instruction Steps. This page sits at the centre of the care lifecycle: the care plan is built from the care assessments, and it must change whenever the client does — see When the plan must change.

Key terms

• Care plan — the narrative plan describing how the client should be cared for: daily-living approaches, goals, safety adaptations, memory care, health monitoring, and escalation protocol. Versioned as Draft → Published → Archived; the newest Published version is current. A reassessment draft is private until final human approval. In this handbook, "care plan" always means this narrative document — never the operational list below.
• Daily Routine section — the structured section of the care plan that proposes the client's routine time anchors; the only place in the care plan where clock times belong.
• Routine anchor — one named, time-typed point in the client's day (wake, sleep, or a meal): a client-local time plus care guidance.
• Care Task List — the operational list of recurring tasks attached to one client schedule, which care providers perform during shifts. Moves through Draft → Published → Archived. (Formerly called the "task plan"; renamed to end the constant confusion with "care plan." The in-code entity is CareProviderTasks.)
• Task template — a platform-wide form definition for one kind of task (e.g. "Vital Signs"): the fields to fill in, which answers are required, and which values trigger warnings.
• Scheduled task — a task that occurs at set times and is completed once per occurrence per shift.
• Tracking task — a task that can be recorded any number of times during a shift (e.g. fluid intake), each entry numbered.
• Task submission — a care provider's record of performing one task on one shift, including form answers, files, location, and any warnings. An attachment field can hold several files (see PLAN-44).
• Threshold warning — an automatic flag when a submitted health value (e.g. blood pressure) falls outside the safe range for that client. Warns, never blocks.
• Concern — a comment on a submission flagged for agency follow-up; it moves Open → Acknowledged → Resolved.
• Excused occurrence — a single task occurrence waived because it collides with a doctor appointment.
• Daily task view — the single, ordered list of everything a care provider is expected to do on one shift, consolidating every source (the Care Task List, approved engagement programs, approved meal-plan prep and grocery pickup, calendar events, and confirmed ARMI Marketplace bookings).
• Completion state — how a task was finished: Completed, Partially Completed, or Skipped. Partially Completed needs a brief note; Skipped needs a reason chosen from a configurable list plus a note. Every state change records a completion timestamp.
• Time-anchored task — a task tied to a set time, which appears in the daily task view in its scheduled position. A non-time-anchored task has no fixed time and can be completed in any order, following a recommended sequence the care manager configures.
• Time Performed — the time a care provider records for a time-sensitive task (for example repositioning); the next cycle of a recurring time-sensitive task is scheduled from this entered time, not the originally scheduled time.
• Care domain category — the area of care a task belongs to (Life's Milestone or the agency's configured equivalent), used for reporting and pattern analysis.
• Reference media — optional photos, short video, or audio the agency can attach to a task to guide the care provider.

How it works

The care plan

A care plan is written manually by agency staff or generated by the platform's AI, which draws on the client's profile, medications, and completed assessments. The plan is never edited in place: every save creates a new version. Normal authoring publishes a version through its existing human gate; reassessment preparation creates a private Draft. Publishing that draft archives the previous Published version. Staff can compare versions, revert to an earlier one, and export the current published plan as a PDF. Families and care providers can read published care; only authorized agency staff can change it.

For initial Care Operations setup, a plan can be created only after the current shift-generation batch succeeds. The plan records that batch and the exact schedule revisions it used. This does not make shifts care-plan content; it makes the plan's operational grounding auditable and lets the product explain when a later schedule edit has made setup stale.

The plan carries a structured Daily Routine section: the client's routine time anchors (wake, sleep, and meal times — each a client-local time plus care guidance). The AI drafts it from the care assessments — the Montessori Profile's Daily routine area and the Meal Assessment's meal timing preferences (CA-17) — a human reviews it, and it is versioned with the rest of the plan. It is the only home for clock times in the care plan; every other section references anchors by name (PLAN-37). This section proposes the client's routine times: publishing the plan seeds any routine-time field the care manager has not yet set on the client's routine-times record (fill-if-empty, never overwriting a set value), where those times feed schedule defaults and AI task timing (PLAN-38, SCH-47, SCH-48).

When the plan must change

A care plan is born from the care assessments, but the client keeps changing, so the plan has to keep up. Four upstream events open a care-plan review, and they all converge on the same review action and update the same care plan document (PLAN-35):

• a significant change of condition (COC-8);
• a discharge after a hospital stay (TOC-2);
• a routine or event reassessment falling due (RAC-7); and
• a repeatedly-flagged instruction step caught by pattern analysis (STEP-16).

When the review produces a new care plan version, that change must ripple outward — because a Care Task List built from an old plan version is now stale. Publishing a new care plan version flags the dependent Care Task Lists stale and records which plan version each was built from (PLAN-34), so staff know exactly what to refresh; the affected instruction steps are flagged for regeneration (STEP-17). When the review's suggested assessment changes were applied (RAC-17), the new plan version also records the assessment generation that grounded it (PLAN-36) — completing the trace from "this picture of the client" through "this plan version" to "these published tasks" (PLAN-34). The full loop is mapped on the Care Lifecycle page.

The Care Task List and its lifecycle

Each client schedule has at most one Care Task List. It is created either as an empty draft (staff add tasks by hand) or generated by AI from the client's current care plan. Tasks are added, edited, and removed only while the plan is a draft. Publishing makes the plan live for shifts and archives the previously published version; staff can later start a new draft from the published plan, or revert to an earlier published version.

The first time any Care Task List is published for a client, the client automatically becomes active and care delivery begins (see Clients). Publication is blocked until at least one accountable care manager is assigned.

How tasks reach a shift

Tasks are stored once per schedule with a recurrence pattern, then expanded into each shift's time window when a care provider opens the shift. Three things are blended in live, so they are always current without republishing the plan:

• Medication reminders are computed from the client's current medication list every time — medication changes reach care providers immediately.
• Meal and engagement details assigned to that specific shift are attached to the matching tasks.
• Excused occurrences (doctor-appointment collisions) are removed from what the care provider is expected to do.

If a schedule has no published Care Task List, its shifts simply show no tasks.

The consolidated daily task view

A care provider should see one ordered list per shift, not several separate lists. The daily task view pulls together everything expected on that shift from every source: the published Care Task List, approved engagement programs, approved meal-plan prep and grocery pickup, calendar events (additions, changes, and cancellations flow through automatically), and confirmed ARMI Marketplace bookings. A pending ARMI booking does not generate a task — only confirmed bookings do. Each item carries its source so staff and care providers can see where a task came from.

Each task in the view carries a title, instructions, an estimated duration, a care domain category (Life's Milestone or the agency's equivalent), and its source. The agency can attach optional reference media — photos, short video, or audio — and link the step-by-step task instruction steps a care provider reads before the shift.

When a care provider completes the task, its attachment fields accept more than one photo each, up to a cap the template sets (PLAN-44). This matches how the work actually gets documented: a meal is photographed before and after, a wound from more than one angle, an incident as both the injury and the scene.

Task order on the shift

Time-anchored tasks appear in their scheduled position in the list. Non-time-anchored tasks can be completed in any order; they appear in a recommended sequence the care manager configures, but the care provider is free to do them out of order.

Task times come from the client's routine anchors: the AI generator resolves each task's time against the wake, sleep, and meal times rather than hardcoded windows (PLAN-39). A task scheduled before the client's wake time is preparation, so it sits at the top of the shift, before the client is up (SCH-47) — this is inferred from the wake time and the shift start, with no stored phase on the task.

Completion states and time-sensitive tasks

Every task is finished in one of three states: Completed, Partially Completed (requires a brief note), or Skipped (requires a reason from a configurable list plus a note). Each state change records a completion timestamp.

Time-sensitive tasks — repositioning, scheduled vital-sign checks, and similar — capture a care-provider-entered Time Performed. The next cycle of a recurring time-sensitive task is scheduled from the entered time, not the originally scheduled time, so intervals reflect when care actually happened (see Scheduling & Shifts on recurring time-anchored tasks).

The care manager dashboard shows real-time completion status for each shift. Skipped and partially completed tasks are flagged for care manager review, and repeated skips of the same task across shifts raise a pattern alert so the care manager can look into it.

The data captured for each task conforms to the Task Templates Reference companion document, which defines the field structure, required fields, validation rules, and observation thresholds for each of its 59 templates.

Completing tasks

A scheduled task is a two-step flow: the care provider starts it, fills in the template's form, and completes it. A tracking task is submitted in one step, as many times as needed. On completion the answers are validated against the template, health values are checked against the client's personal safe ranges (falling back to the template's defaults), and the care provider's location is compared to the client's address. Warnings and an out-of-range location are recorded and reported but never stop the submission. When the care provider clocks out, any tasks still in progress are automatically completed and clearly marked as auto-completed. A shift cannot be completed while required tasks in its window are missing submissions — a required tracking task needs at least one entry, however many it ends up receiving. Only required scheduled tasks hold up clock-out itself; a missing required tracking entry warns the care provider and is recorded against the shift, but lets them clock out (see Scheduling & Shifts).

Review, comments, and concerns

There is no approve/reject step on submissions. Instead, staff and family review submissions after the fact and comment on them. A comment flagged as a concern opens a follow-up that notifies the agency's owners and admins; they acknowledge it and then resolve it, optionally with a resolution note, and the person who raised it is notified at each step. Ordinary comments notify the submitting care provider and the client's representatives.

What the family sees

Representatives linked to a client see the client's task list for each day, each task's submission status, submission details with comments, and summary statistics. They can comment and raise concerns but cannot change plans or tasks.

Rules

• PLAN-1 — A care plan is never edited in place. Every save, AI generation, or revert creates a new version, and the highest version is always the client's current plan.
• PLAN-2 — A care plan can be created manually by agency staff or generated by AI. AI generation must use the client's profile, current medications, and completed assessments.
• PLAN-3 — Only one AI generation (care plan or Care Task List) can run per client at a time. The requester is notified when it finishes, and a running generation can be cancelled.
• PLAN-4 — Reverting a care plan or a Care Task List must restore the chosen version as the current one while keeping a record of the versions it supersedes.
• PLAN-5 — Each client schedule has at most one Care Task List. Creating a draft for a schedule that already has one must be refused.
• PLAN-6 — Tasks can only be added, edited, or removed while the Care Task List is a draft. Only a draft can be published.
• PLAN-7 — Publishing a Care Task List archives the previously published version of the same plan, so exactly one published version is live per schedule at any time.
• PLAN-8 — AI task generation requires the client to have a current care plan linked to schedules; without one it must be refused.
• PLAN-9 — Every task must be based on a template from the platform task library, which defines its form fields, required answers, and warning thresholds.
• PLAN-10 — The first publish of any Care Task List for a client automatically activates that client.
• PLAN-11 — Removing a recurring task can apply to all occurrences, to a single date, or to a date and everything after it.
• PLAN-12 — Medication reminder tasks are always derived live from the client's current medications and are never stored in the Care Task List. Completing one updates medication stock and triggers the related notifications.
• PLAN-13 — A task occurrence that collides with a doctor appointment can be excused; an excused occurrence is not expected on that shift.
• PLAN-14 — A scheduled task accepts exactly one submission per task, per care provider, per shift. A tracking task accepts unlimited submissions, each numbered in order.
• PLAN-15 — A submission always belongs to one shift, and the care provider submitting must be the one assigned to that shift for that client.
• PLAN-16 — Care providers can only complete, change, or remove their own submissions.
• PLAN-17 — Submitted answers must be validated against the task's template. Health values are checked against the client's personal safe ranges first, then the template defaults; breaches at high or critical level must alert the agency immediately.
• PLAN-18 — Threshold warnings and a failed location check never block a submission; both are recorded on the submission for review.
• PLAN-19 — At clock-out, every in-progress submission on that shift is automatically completed and permanently marked as auto-completed; abandoned in-progress submissions are also swept up periodically.
• PLAN-20 — Anyone permitted to comment can flag a comment as a concern. A concern starts Open, must be acknowledged before or as part of resolution, and ends Resolved with an optional note. Owners and admins are notified when a concern opens; the author is notified at each status change.
• PLAN-21 — Representatives can only see clients they are actively linked to.
• PLAN-22 — All care plans, Care Task Lists, and submissions belong to one agency, and people from another agency must never be able to see or change them.
• PLAN-23 — Deleting a schedule removes its Care Task Lists. A care plan that also covers other schedules must survive the deletion of just one of them.
• PLAN-24 — Each shift must present a single, ordered daily task view that consolidates every source: the published Care Task List, approved engagement programs, approved meal-plan prep and grocery pickup, calendar events, and confirmed ARMI Marketplace bookings. (🚧 Spec only)
• PLAN-25 — A pending ARMI Marketplace booking must not generate any task; only a confirmed booking generates tasks. (🚧 Spec only)
• PLAN-26 — Calendar changes (additions, modifications, and cancellations) must flow into the daily task view automatically, without republishing the Care Task List. (🚧 Spec only)
• PLAN-27 — Each task must carry a title, instructions, an estimated duration, a care domain category (Life's Milestone or the agency's configured equivalent), and its source; the agency may also attach optional reference media. (🚧 Spec only)
• PLAN-28 — Every task must be finished in one of three completion states — Completed, Partially Completed, or Skipped — and each state change must record a completion timestamp. (🚧 Spec only)
• PLAN-29 — Marking a task Partially Completed must require a brief note; marking a task Skipped must require both a reason chosen from a configurable list and a note. (🚧 Spec only)
• PLAN-30 — Time-anchored tasks must appear in their scheduled position; non-time-anchored tasks must be completable in any order and shown in a care-manager-configurable recommended sequence. (🚧 Spec only)
• PLAN-31 — Time-sensitive tasks must capture a care-provider-entered Time Performed, and the next cycle of a recurring time-sensitive task must be scheduled from that entered time rather than the originally scheduled time. (🚧 Spec only)
• PLAN-32 — The care manager dashboard must show real-time task completion status per shift, flag skipped and partially completed tasks for review, and raise a pattern alert when the same task is skipped repeatedly across shifts. (🚧 Spec only)
• PLAN-33 — Task data capture must conform to the Task Templates Reference companion document (59 templates), which defines field structure, required fields, validation rules, and observation thresholds per template. (🚧 Spec only)
• PLAN-34 — Publishing a new care plan version must flag every published Care Task List built from a prior care plan version as stale, notify the care manager to review and republish, and record which care plan version each Care Task List was generated from. The flag is surfaced for the care manager to act on; whether the platform also auto-creates updated drafts is an open decision below. (🚧 Spec only)
• PLAN-35 — A care-plan review triggered by a significant change of condition (COC-8), a discharge (TOC-2), or a reassessment (RAC-7) must converge on the same care-plan-review action and update the same care plan document. The entry reason is recorded on the review, but the three paths must not create separate, divergent review tracks. (🚧 Spec only)
• PLAN-36 — A care plan drafted from a reassessment outcome must record the assessment generation that grounded it (the emitting stamp is CA-16). Together with PLAN-34 — each Care Task List records its source care plan version — this closes the provenance chain assessment generation → care plan version → Care Task List, so for any published task the exact assessment picture behind it can be traced. (🚧 Spec only)
• PLAN-37 — The care plan carries a structured Daily Routine section: the client's routine time anchors (wake, sleep, and meal times — each a client-local time plus care guidance) — AI-drafted from the care assessments, human-reviewed, and versioned with the plan. This section is the only place in the care plan where clock times belong; every other section references anchors by name. (🚧 Spec only)
• PLAN-38 — The client's routine times (wake, sleep, and meal times) are the operational source scheduling and task generation read; they are set directly on the client schedule page (see Scheduling & Shifts SCH-48). The care plan's Daily Routine section proposes these times: publishing a version seeds any routine-time field the care manager has not yet set on the client's routine-times record (fill-if-empty, never overwriting a set value). (🚧 Spec only)
• PLAN-39 — Care Task List task times are derived from the client's routine anchors rather than generic hardcoded meal-window constants, and a task scheduled before the client's wake time is preparation. Preparation is inferred from the wake time and the shift start — there is no stored task phase or anchor-reference field. (🚧 Spec only)
• PLAN-41 — The first care plan in Care Operations setup requires a successful, current shift-generation batch covering every active client schedule revision. (✅ In code)
• PLAN-42 — Every care plan records the generation batch and schedule revisions that grounded it, in addition to its assessment provenance. (✅ In code)
• PLAN-43 — Editing a grounded schedule marks the dependent setup plan Stale; staff must regenerate shifts and review or create a current plan before new downstream staffing can be committed. Existing live shift work is preserved. (✅ In code — currency is derived from batch and schedule provenance)
• PLAN-44 — A task template's attachment field may accept several attachments rather than one, up to a per-field cap defined on the template. The care provider adds and removes attachments freely until the submission is recorded, and the cap is enforced when the submission is saved — not only in the app — so it holds regardless of which app version was used. Every photo field in the current task library accepts up to five attachments. (✅ In code)
• PLAN-45 — The task library is non-clinical by default. Templates covering work that sits outside an unlicensed care provider's scope in most places — wound dressing, catheter and stoma care, applying medication, eye drops, and seizure response — are marked as requiring delegation. The AI task generator never selects a delegated template, so this work reaches a shift only when a care manager assigns it deliberately, knowing who is rostered. (✅ In code)
• PLAN-46 — Every health-monitoring task must let the care provider record that the reading did not happen — the client declined, the reading could not be obtained, or the equipment was unavailable — and must not require a number in that case. A reading that was never taken is never counted as a reading, so a client whose checks are consistently declined reads as unmonitored rather than healthy. (✅ In code)

Who can do what

Access in this area is granted through the agency's permission settings; the roles above are the intended defaults.

Decisions needed

1. How should a care plan change reach the Care Task Lists? PLAN-34 now resolves the core link: publishing a new care plan version flags the affected Care Task Lists stale and records their source version. The open sub-question is the degree of help: should the platform also auto-create updated drafts for staff to review, or only flag-and-notify (the default) and leave staff to draft? Keeping it fully manual is no longer an option.
2. (Resolved) Does a reviewed change of condition trigger a care plan review? Yes — a significant change now opens a reassessment and care-plan review via COC-8, and all review entry points converge through PLAN-35. What remains is the threshold for "significant," owned by Change of Conditions.
3. Should submissions get a formal supervisor review step? Today review is informal, via comments and concerns. Options: add an approve/return-for-correction status, or keep comment-based review as the model.
4. Should care providers be able to delete their own submissions? Care records are compliance-sensitive. Options: forbid deletion entirely, allow it only within a short window, or allow it with a permanent audit record.
5. (Resolved) What do we call the two "care plans"? The narrative document is the care plan; the operational recurring list is the Care Task List (formerly "task plan"). In this handbook, "care plan" always means the narrative document. The in-code entity for the Care Task List remains CareProviderTasks. See the glossary.
6. May a pre-wake preparation task ever resolve before shift start? It must not — a shift positioned to begin before the client's wake time keeps pre-wake preparation inside the shift window; confirm this invariant holds for manually retimed schedules.