Care plans

care-plans keeps one plan per client: the problems found, the goals that answer them and the actions that reach those goals. You draft a plan, publish it as the client's active plan, evaluate its goals over time and draft the next version when the care changes. The client is any registered subject, such as a contact, a patient table of your own or a household, so the block serves home care, youth care, clinics, social work and coaching alike.

better-supabase add care-plans

import { createCarePlans } from "better-supabase/blocks/care-plans";

The module requires memberships, permissions and subjects. It works with these blocks when they are installed:

TablesCopy Anchor Link

A plan is a subject of type care_plan, so comments, attachments, tags and the other subject blocks work on it. Members with care_plans.read read a plan only when they can also read its client, so a record team that limits who sees a client limits who sees the client's plans. Writes go through the functions below.

Drafting a planCopy Anchor Link

Server code calls the carePlans instance on db, in the caller's organization:

const plan = await db.carePlans
  .create({
    subjectType: "contact",
    subjectId: clientId,
    title: "Living at home safely",
    reviewOn: Temporal.PlainDate.from("2027-05-01"),
    ownerId,
  })
  .orThrow();

const problem = await db.carePlans
  .addProblem(plan.id, {
    codeSystem: "omaha",
    code: "25",
    title: "Risk of falls",
  })
  .orThrow();

const goal = await db.carePlans
  .addGoal(problem.id, {
    title: "No falls at night",
    targetOn: Temporal.PlainDate.from("2027-01-01"),
    measure: { observation: "falls", target: 0 },
  })
  .orThrow();

await db.carePlans
  .addAction(goal.id, {
    kind: "intervention",
    title: "Night round",
    frequency: { frequency: 1, period: 1, periodUnit: "d" },
    teamRole: "nurse",
  })
  .orThrow();

A plan's version is one more than the client's last plan. Pass copyFromPlanId to start from an earlier plan of the same client: its problems, goals and the actions that haven't ended are copied into the draft.

A problem's codeSystem must be one of options.codeSystems (default custom). Codes are never bundled: add the systems you use, such as omaha, icf, nanda, snomed or icd-10, and keep their codes in your app.

blocks: {
  "care-plans": {
    options: {
      codeSystems: ["omaha", "custom"],
      measureKinds: ["seclusion", "supervision", "bed_rail"],
      guestRead: true,
    },
  },
},

Problems, goals and actions take a rank key for their order; without one they go after the last. frequency and measure are objects your app shapes, such as a FHIR Timing repeat and a goal target.

PublishingCopy Anchor Link

publish needs care_plans.publish and a plan with at least one problem. It makes the draft the client's active plan, archives the active plan before it and ends that plan's actions with the reason superseded. With versions installed it freezes the published plan as a version. Then it starts the plan's actions: an action without an approval starts at once, and a measure asks for its approval.

const active = await db.carePlans.publish(plan.id).orThrow();

A client has at most one active plan. On an active plan only the status of a problem or goal changes, and an action changes only how it runs (bookingSeriesId, endsOn, frequency, instructions, reviewEvery and teamRole). Anything else goes into the next version: create a draft with copyFromPlanId and publish it. archive ends the plan's actions with the reason plan archived.

Evaluations and reviewsCopy Anchor Link

evaluate records what a goal reached and sets the goal's status. It needs care_plans.evaluate and an active plan. Pass submissionId when a forms submission recorded the evaluation.

await db.carePlans
  .evaluate(goal.id, {
    status: "achieved",
    outcome: "No falls in three months",
  })
  .orThrow();

reviewAction records a review of an active action, and reviewEvery (a Temporal.Duration) says how often one is due. Run dueReviews daily with the service role; the block's reviews schedule does that at 06:00. It records care_plan.review_date_reached when a plan's reviewOn has passed and care_plan_action.review_date_reached when an action's review is overdue, once each, and notifies the plan's owner. For reminders ahead of the date, point reminders at the column:

reminders: {
  on: { care_plan: { table: "better_supabase.care_plans", at: "review_on" } },
},

Restrictive measuresCopy Anchor Link

An action of kind measure, or one with requiresApproval, starts only once approved. With approvals installed, publishing asks for an approval of subject type care_plan_action and action start, by default from a member with care_plans.manage. The final approval starts the action. Tenants tighten that policy with conditions and a second approver through approval policies. Without approvals, only a member with care_plans.manage starts a measure with startAction.

const measures = await db.carePlans.measures().orThrow();
// The measures in force: [{ title, measureKind, planTitle, subjectId, approvalId, ... }]

measures is the organization's register of restrictive measures, the ones in force unless you pass activeOnly: false. measureKind must be one of options.measureKinds when you set it. Give a measure a reviewEvery so its review comes due.

AgreementCopy Anchor Link

With signatures installed, requestAgreement asks the members who speak for the client (the client, a representative) to agree to an active plan. It needs care_plans.publish and the signatures request permission. The signature request has meaning agreed and points at the published version; when every signer has signed, the plan records agreedAt and care_plan.agreed.

await db.carePlans
  .requestAgreement(active.id, [clientUserId, representativeId])
  .orThrow();

list leaves out archived plans unless you pass includeArchived: true.

ErrorsCopy Anchor Link

EventsCopy Anchor Link

care_plan.created, care_plan.updated, care_plan.published, care_plan.archived, care_plan.agreed, care_plan.review_date_reached, care_plan_goal.status_changed, care_plan_evaluation.created, care_plan_action.started, care_plan_action.ended, care_plan_action.review_date_reached and care_plan_action.reviewed. The events page lists their payloads.

The care plan editor and care plan evaluations recipes render the tree and the evaluation history.

Without the clientCopy Anchor Link

db.carePlans is this client. Code that does not go through bsb.db() builds it with a transport and an organization id:

const carePlans = createCarePlans({ transport, tenant: organizationId });

const plans = await carePlans.list("contact", clientId).orThrow();