ArkCloud Care

Care coordination

Follow-up work assigned and tracked as a queue rather than held in an individual's inbox, and the teams that work it. Operational coordination, not clinical content.

Written for: Care coordinators · Care management leadership · Operations · Evaluators

The coordination queue

Launcher → ArkCloud Care → Coordination

The care coordination task queue, where follow-up work is assigned and tracked rather than held in an individual inbox

Coordination tasks as a shared queue. A follow-up that nobody has started is visible to the team rather than sitting unseen in one person's list.

/care/coordination

Task queues

Launcher → ArkCloud Care → Queues

Task queues in ArkCloud Care: named queues with open, unclaimed and overdue counts, and the selected queue's tasks with Claim and Release controls

Named queues with their open, unclaimed and overdue counts, and the selected queue's tasks with Claim and Release controls.

/care/queues

A queue is a named pile of coordination work and the staff who work it. Tasks are routed into a queue and claimed by one person at a time, so two coordinators do not ring the same patient. The queues and the Coordination list are two views of the same tasks, so they cannot disagree about a task's state.

Field or controlWhat it means
Creating and changing queuesAdministrators only.
Claiming a taskA member of the task's queue, or an administrator.
Releasing a taskThe person who claimed it, or an administrator.

Patient follow-up

Launcher → ArkCloud Care → Follow-ups

Patient follow-ups in ArkCloud Care, earliest first, with overdue items flagged and repeating follow-ups shown with their interval

Patient follow-ups, earliest first, with overdue items flagged and repeating follow-ups shown with their interval.

/care/follow-ups

A follow-up is a commitment to contact one patient by a date. It stays due until someone records what happened: completed, missed (attempted, or its date passed without it) or cancelled (no longer needed). Overdue is worked out from the date when it is read, never stored. A repeating follow-up schedules the next one from the day it was completed or missed - not when it is cancelled, because cancelling means stop. The reason and the outcome note are encrypted at rest.

Multidisciplinary care teams

Multidisciplinary care teams, which record team composition from staff records and therefore hold no patient data

Care teams record team composition from staff records. Because members are staff rather than patients, this surface holds no patient data at all.

/care/teams

Teams answer "who is involved in this person's care" as a structure rather than as knowledge held by whoever has been there longest.

Transitions and outreach

Two more operational logs sit alongside coordination, and both are deliberately narrow.

Field or controlWhat it means
Transitions of careA setting change and the follow-up it requires. An event-and-follow-up log - it does not carry clinical handoff content.
OutreachA contact-attempt log: who was contacted, by what channel, and what happened. Patient fields encrypted at rest.
Transitions of care, logging a change of setting and the follow-up it requires

Transitions of care record that a setting changed and what follow-up it triggered. Clinical handoff content is not held here, deliberately - that would be governed clinical content.

/care/transitions

The outreach log, recording each contact attempt with its channel and outcome

The outreach log makes contact attempts countable. Three unanswered calls is a different situation from one, and only a log can tell you which you are in.

/care/outreach

Care gaps and risk tiers are governed

Care gaps, risk stratification and population cohorts produce clinicalconclusions about a patient - that a gap in their care exists, that they are high risk. So each runs only on a definition your organisation authored and published.

Field or controlWhat it means
Care gapsRaised by a published care-gap rule, each with the reason it fired. Resolved automatically when the record shows what the rule asks for; dismissed by a person with a reason.
Risk stratificationTiers from a published risk model: a points table over recorded events. Every tier shows its points; a person may override it with a reason.
Population health workflowsSaved cohorts over programme enrollment, published risk tiers and open gaps, turned into a task-queue worklist in one step.
Care gaps in ArkCloud Care: open gaps raised by a published rule, each with the reason it fired, above the rule review pipeline

Open care gaps, each with the reason the published rule gave, above the rule pipeline. The rule shown is a labelled demonstration rule on test data.

/care/gaps

Risk stratification in ArkCloud Care: current tiers from a published risk model, each explainable signal by signal and overridable with a reason

Current risk tiers from a published model; every tier can show the points behind it and be overridden with a reason. The model shown is a labelled demonstration.

/care/risk

Launcher → ArkCloud Care → Population

Population health in ArkCloud Care: counts of patients in care, programmes, open gaps and overdue contact, above saved cohorts that generate task-queue worklists

Population health: counts of patients in care, programmes, open gaps and overdue contact, above saved cohorts that generate task-queue worklists.

/care/population

A cohort is a saved filter - programme enrollment, active plans, tiers from published risk models and gaps from published rules - and its members update as the record changes. Generating a worklist creates one task in a queue for each member who has no open task from that cohort already, so running it twice does not double anyone's work. Only patients Care holds a linked record for are counted.

Care pathways, governed on the same authored, reviewed and legally cleared pipeline as clinical guidance, with nothing yet published

Care pathways are governed on the same authored, reviewed and legally cleared pipeline as clinical guidance. Nothing has been published through it yet.

Not yet usable. This capability is implemented and cannot be used until something outside the software exists - published clinical content, or a live payer or payment connection. The screen states the reason rather than offering a control that would fail.

/care/plans

Related documentation