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

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

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 control | What it means |
|---|---|
| Creating and changing queues | Administrators only. |
| Claiming a task | A member of the task's queue, or an administrator. |
| Releasing a task | The person who claimed it, or an administrator. |
Patient follow-up
Launcher → ArkCloud Care → Follow-ups

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

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 control | What it means |
|---|---|
| Transitions of care | A setting change and the follow-up it requires. An event-and-follow-up log - it does not carry clinical handoff content. |
| Outreach | A contact-attempt log: who was contacted, by what channel, and what happened. Patient fields encrypted at rest. |

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 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 control | What it means |
|---|---|
| Care gaps | Raised 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 stratification | Tiers 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 workflows | Saved cohorts over programme enrollment, published risk tiers and open gaps, turned into a task-queue worklist in one step. |

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

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: 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 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
