Rebooting Care Coordination for AI
An architecture document for what care coordination could look like if we started from AI as a precondition, not a feature bolted onto existing workflows.
The problem with the current state
Care managers manually track 150+ members and decide who to reach out to, in what order, for what reason. The work is structured the same way it was a decade ago: lists, tasks, queues. The volume has grown. The structure has not.
This doesn't scale, and it burns out the people doing the work. More importantly, it forces a zero-sum trade-off between three things every modern care platform claims to want: collaborative operations for high-touch cases, coherent clinical and social data, and holistic product design that brings it all together. When organizational capacity is finite, these three goals compete with each other. Whichever loses, the system fragments.
The vision
An AI-first care platform, while preserving high-touch capacity for complex, high-need populations.
The model is closer to AI-powered air traffic control than self-service kiosks:
- An AI layer continuously monitors signals, prioritizes work, and generates outreach drafts
- The human layer focuses on complex, relationship-dependent work that can't be automated
- The AI doesn't replace relationships. It protects them by handling the volume that would otherwise crowd them out
The product becomes the intelligence layer that says: "These twelve members need your attention today. Here's why. Here's what to say. Here are the updated care plans ready for you to review."
The framework: a three-tier work architecture
The principle: default to lightweight, escalate to structured only when needed. Most care coordination work doesn't need a project plan. Some of it does. The product should match the structure to the work, not the other way around.
AI detects a single, clear action for one person.
- No dependencies
- One owner
- Can be completed in a single interaction
- Disposable. Once done, it's gone.
- "Call Maria about missed diabetes appointment"
- "Review John's recent ER visit notes"
- "Send medication refill reminder to 5 members"
Swipeable cards, quick actions, mark complete. AI reasoning visible but not overwhelming. Human override always available.
An Action Feed item reveals complexity, or a human initiates one.
- Multiple steps over time
- Still primarily one owner
- Sequential, not parallel dependencies
- Time-bound
- "Get Sarah enrolled in diabetes management program" — requires education call, consent form, schedule first visit, confirm attendance.
Expandable checklist within the member profile. Tracks progress. One-click promotion to Tier 3 when needed.
An explicit human decision that multiple people need visibility and coordination.
- Multiple owners with parallel work
- Dependencies between team members
- Unclear timeline or high complexity
- Needs shared context and documentation
- Housing placement for an unstable member
- Post-hospitalization transition coordination
- Complex behavioral health and medical co-management
Full task board with assignments, status, notes, and explicit handoffs.
How tiers transition
The user experience:
- Care manager starts the day with the Action Feed
- While working an action, realizes "this is bigger" → one-click promotes to an Episode
- While working an Episode, realizes "I need the social worker" → escalates to a Project, assigns collaborators
Design principles
Low friction for high-volume work
Most actions should be one to two clicks. Default to simple views. Progressive disclosure of complexity only when the situation demands it.
Clear mental model
Care managers should immediately understand "what type of work is this?" Visual distinction between tiers. Obvious escalation paths.
Preserve context
All work tied to the member profile. History visible across tiers. Handoffs between team members are explicit, not implicit.
AI transparency
Show why AI flagged something. Allow human override. Make AI reasoning visible, but not overwhelming. The goal is calibrated trust, not blind trust.
Open questions worth investigating
This architecture is field-thinking, not field-tested. A few questions remain open:
- How much AI reasoning should show on action cards before it becomes noise?
- What triggers a "promote to Episode" automatically versus prompting the human?
- How do team members get notified when added to a Project mid-flight?
- What happens to incomplete actions and episodes when a member's situation changes underneath them?
- How does this integrate with existing care plans without forcing a full migration?
Why publish this
This document was the architecture behind a working prototype I built to test the approach. The prototype is not yet public. The thinking is.
I'm publishing it because the strongest evidence of an AI-forward designer is not the polished case study. It's the working document that shows how the problem was framed before any tool was reached for. Most "AI design" content focuses on the tools. The harder, less-discussed part is the architecture.
If you're working on something similar, or you think this is wrong somewhere, I'd genuinely like to hear it.
This document accompanies an interactive prototype currently in iteration.
More at stuartkim.design