Care coordination breaks down in a very particular way. Everyone is trying to help, and nobody can see the whole picture at once. One team owns a follow-up call. Another has the most recent clinical note. A patient is waiting on outreach that never got scheduled. A referral is stuck behind an authorization nobody has chased. A medication question is sitting unanswered, and the next action is buried three messages deep in a thread the right person never opened.
None of that is a failure of effort. It is a failure of visibility. When the current state of a patient lives across an EHR, a scheduling tool, a shared inbox, and somebody's memory, the team spends its energy reconstructing where things stand instead of moving the work forward. This guide is about building a care coordination workflow that shows, at a glance, who owns what, what is blocking it, and what happens next, so patients stop slipping through the gaps between people who all meant to follow up.
It is written for the person who runs this work day to day: a care-operations lead, a coordination manager, or the operations owner in a clinic, practice group, or home-health provider. The aim is a workflow your team can actually run, not a systems project that takes a year and helps nobody in the meantime.
The job is to make the next patient action clear
In healthcare, care coordination is practical operating work that sits right next to clinical work. A good coordination workflow helps the team answer five plain questions for any patient in the queue: what does this person need next, who owns it, what is blocking it, when should it happen, and what has already been communicated to them or about them.
Notice what those questions are not. They are not clinical decisions. Whether a patient needs a medication change, a different care plan, or an urgent review is a clinical judgment, and that belongs to clinicians. The coordination workflow does not make those calls. It makes sure the administrative work around them, the scheduling, the outreach, the chasing, the documentation, stays visible and owned, so the clinical decisions actually get acted on instead of getting lost in a queue.
Keeping that line clear is what makes the whole thing safe to build. Once the team agrees that the workflow organizes the coordination work and clinicians still decide the clinical work, you can move fast on the parts that are genuinely just admin.
Draw the clinical and administrative boundary first
Before you design any queue or turn on any automation, write down where the administrative work ends and clinical judgment begins. In care coordination the two are tangled together all day, so the boundary has to be explicit or it will drift.
A practical way to hold the line is to sort every task into one of three buckets. Administrative tasks can be organized, drafted, and even automated: booking a call, sending an approved appointment reminder, chasing an authorization status, flagging that a follow-up is overdue. Clinical tasks are decided by a clinician and only executed after they decide: changing a care plan, interpreting a symptom, approving a message that contains clinical advice. Mixed tasks look administrative but carry clinical weight, so a person routes them to the right clinician rather than resolving them alone, for example a patient replying to an outreach message with a new symptom.
This boundary is not bureaucracy. It is what lets you speed up the safe parts without anyone worrying that a workflow is quietly practicing medicine. When you later decide where software or AI can help, you check it against these buckets. Anything clinical stays with the clinician. Anything administrative is fair game.
Map one patient path from trigger to closed follow-up
Do not try to fix all of care coordination at once. Pick a single path and follow it from the event that starts it to the moment the next action is genuinely done. Good candidates are post-discharge follow-up, specialist referral follow-up, chronic-care outreach, a care-plan task that keeps stalling, missing documentation, or high-risk patient review.
As you trace one path, write down every handoff. In most providers the work crosses clinicians, care coordinators, schedulers, front-desk staff, billing, referral teams, outside providers, the patient, and sometimes a family contact. At each handoff, note two things: who owns the work after the handoff, and what information has to travel with it. The places where either answer is unclear are exactly where patients fall through, because the work arrives somewhere with no owner and no context.
You will usually find that the path is not really one path. Post-discharge follow-up splits into a scheduling branch, a medication-clarification branch, and a documentation branch, each with different owners and different failure points. That is fine. Mapping it honestly is what tells you what the shared view actually needs to hold.
Start with a care coordination record for one path
The first concrete build is small: a single shared record for the path you chose, holding the fields the team needs to answer those five questions without opening four other systems. It does not replace the EHR. It sits on top of the coordination work and points back to the systems where the real detail lives.
The point of this record is a shared view. Right now, knowing the state of a patient's follow-up depends on asking the right person or remembering the last call. The record turns that into something the whole team can read and sort. Here is a workable starting shape.
| Field | What it captures | Example |
|---|---|---|
| Patient and trigger | Who this is about and the event that started the follow-up | Discharged Tuesday, post-discharge follow-up due within 48 hours |
| Current status | The state this action is in right now | Waiting on medication clarification |
| Next action | The single next thing that has to happen | Confirm dose with clinical team before the patient call |
| Owner | The one person responsible now | Care coordinator, Priya |
| Due date | When the next action should happen | By end of day Thursday |
| Blocker | What is stopping progress, if anything | Pharmacy list does not match discharge summary |
| Outreach history | What has already been sent or received, and when | Left voicemail Wednesday; no call back yet |
| Escalation state | Whether this needs a clinician or a supervisor, and why | Needs clinician review of the medication mismatch |
| Resolution note | How it closed, once it does | Dose confirmed, patient reached, next check-in booked |
Every field except the resolution note should be fillable in seconds. If the record takes ten minutes to update, nobody will keep it current, and a stale shared view is worse than no shared view because people trust it and get burned. Keep it lean enough that updating it is faster than the phone call it replaces.
Name the states a patient action moves through
A shared view only helps if everyone reads status the same way. "In progress" means five different things to five people. Before you sort anything, agree on a small set of states and what each one requires.
For most coordination paths a handful of states is enough: new, in progress, waiting on the patient, waiting on someone internal, waiting on an outside party, needs clinician review, and closed. The value is in the waiting states. "Waiting on the patient" and "waiting on an authorization" look the same on a generic task list, but they need completely different follow-up and different chase timing. Splitting them is what lets the team see, without asking, where the queue is actually stuck.
Pair each waiting state with a simple aging rule so nothing sits silently. If an action has been waiting on the patient for more than two attempts, or waiting on an outside party past its expected date, it should surface on its own rather than depend on someone remembering to check.
Route by urgency, blocker, and owner
Coordination queues become unmanageable when every task looks the same. A missing document, a clinical review, an eligibility question, and a routine reminder call should not sit in one undifferentiated list, because they need different people, different urgency, and different next steps.
Route the queue by urgency first, then by blocker type, then by the role that has to act. The first version of this can be crude. It does not need scoring models. It needs enough structure that when a coordinator opens the queue in the morning, the order roughly matches what should be handled first, and each item already names its owner and its next action. Here is what that looks like in practice.
| Patient path | Urgency | Blocker | Owner | Next action |
|---|---|---|---|---|
| Post-discharge follow-up | High | Medication clarification pending | Care coordinator | Confirm with clinical team before the patient call |
| Specialist referral | Medium | Authorization status unknown | Referral coordinator | Check the payer portal and update the expected date |
| Chronic-care check-in | Medium | Patient missed the outreach window | Nurse reviewer | Review notes and choose the next contact path |
| Missing consent form | Low | Form sent, not returned | Front-desk lead | Second reminder, then flag if still open in two days |
The routing does not decide the medicine. It decides the order of the administrative work and who picks it up. When a clinician does need to weigh in, the routing makes that explicit as its own state so it lands with the right person instead of stalling in a general queue.
A worked example: home-health across three agencies
To make this concrete, here is an illustrative scenario. It is not a real client, and the details are invented to show the mechanics. Say a home-health provider is coordinating care for an elderly patient just discharged after a fall, and the work spans three parties: the hospital's discharge team, a physical-therapy agency, and the provider's own nursing staff. On paper, everyone knows what to do. In practice, three separate threads are quietly stuck.
The discharge summary lists a medication change, but the provider's medication list still shows the old dose, and nobody is sure which is current. The physical-therapy agency is waiting on an authorization before it can schedule the first visit, and it assumes the provider is chasing it, while the provider assumes the agency is. The nursing team has left one voicemail for the patient's daughter, the named contact, and is waiting for a call back that may never come. Each of these is somebody's job. None of them is visibly anybody's job right now.
Put those three threads into one shared view and the picture changes immediately. Here is what the record surfaces.
| Thread | Where it was stuck | What the shared view shows | Next action and owner |
|---|---|---|---|
| Medication mismatch | Two systems disagree, no owner | Status: needs clinician review; blocker: dose conflict | Nurse routes to the prescribing clinician to confirm; nobody calls the patient until it is resolved |
| PT authorization | Both sides assume the other is chasing | Owner: referral coordinator; blocker: authorization pending; expected date passed | Referral coordinator checks the payer portal today and updates the date |
| Patient contact | One voicemail, then silence | Outreach history: one attempt Wednesday; state: waiting on patient, aging | Second attempt at a different time, then escalate to the nurse if still no reply |
Nothing here is clever. The workflow did not diagnose anyone or make a single clinical decision. It made three invisible pieces of stuck work visible, gave each one an owner, and separated the one thread that needed a clinician from the two that were pure coordination. That is the entire job: the team was already capable of handling all three, they just could not see them at the same time.
The illustrative payoff is worth naming plainly. The medication conflict gets caught before anyone calls the patient with the wrong instruction. The authorization stops sitting in the gap between two organizations. The patient outreach follows a real second attempt instead of a hopeful wait. None of it required new staff or new clinical authority.
Give the queue a review the team actually runs
A shared view goes stale unless someone looks at it on a schedule. The coordination work does not need constant meetings. It needs a short, predictable review that turns the queue into decisions.
For most teams a brief daily standup on the queue works well: what is overdue, what is blocked, what needs a clinician, and what is aging in a waiting state. Ten or fifteen minutes is usually enough if the record is current, because the review is looking at exceptions, not reading out every patient. A slightly longer weekly review can then step back and ask which blockers keep recurring, which handoffs keep failing, and whether the routing rules still match reality.
The discipline matters more than the exact schedule. The queue should move the team from collecting information to acting on it. If the review turns into a status readout where nothing gets decided or reassigned, the workflow has quietly become reporting, and reporting nobody acts on is just overhead.
Where AI helps, and where it has to stop
AI can take real weight off coordination work, but only on the administrative side of the boundary you drew earlier. Kept there, it is genuinely useful.
On the helpful side, AI can summarize recent notes so a coordinator does not read ten pages before a call, draft outreach messages from approved templates for a person to review and send, classify blocker types so the queue sorts itself, flag follow-ups that have gone stale, and prepare a first-pass summary of the day's queue. In each case the pattern is the same: it reads, drafts, and flags, and a person decides and acts.
The hard stops are just as important. AI should not make or imply clinical decisions. It should not send a message containing clinical advice without a clinician approving it. It should not resolve the mixed tasks, the ones that look administrative but carry clinical weight, on its own. And it should not move patient data outside the systems approved to hold it. A draft summary that helps a coordinator prepare is fine. A tool that autonomously decides a symptom is minor and closes the thread is not.
A simple way to keep this honest: AI prepares the coordination work, people run it, and clinicians own anything clinical. If a proposed use of AI does not fit that sentence, it is on the wrong side of the line.
Handle patient data with care from the start
Care coordination runs on sensitive patient information, so how the workflow treats that data is not an afterthought. This is not legal advice, and it is not a substitute for your own compliance obligations. It is the operating posture that keeps a coordination workflow trustworthy.
Keep patient data in the systems already approved to hold it. The shared coordination record should reference patients and point back to the EHR and other approved sources rather than becoming a second, less protected copy of clinical detail. Share only what a task needs. A scheduler chasing an appointment does not need the full clinical picture to do their job, so the record should show enough to act and no more. And treat any tool you connect, including AI, as something that has to stay inside the approved boundary rather than quietly exporting notes to wherever it runs.
Getting this right early is easier than retrofitting it. If the first version of the record already respects where data is allowed to live and who needs to see what, you can expand the workflow later without unpicking a privacy problem you built in at the start.
Connect systems only after the path is clear
Once the coordination record and the states are working for one path, connect the systems that keep the record current. The usual sources are the EHR, scheduling, referral tools, secure messaging, care-management software, patient outreach, and document storage. Resist the urge to integrate all of them on day one.
Define the record first, then wire in only the fields that keep it honest: patient reference, trigger, task type, care-plan item, assigned owner, due date, last contact, blocker reason, outside dependency, escalation state, and resolution note. Each connection you add should remove a manual copy-paste step or a re-keying step. If an integration does not make the shared view more current or the team's work lighter, it can wait.
This order matters because integration is where these projects stall. Teams that start by connecting everything spend months on plumbing and never reach the review that actually helps patients. Teams that start with one reviewable queue and connect systems to support it get value in weeks and add integrations as the workflow earns them.
What usually goes wrong
Most coordination workflows fail in predictable ways, and knowing the failure modes upfront is cheaper than discovering them one patient at a time. Here are the common ones and what to do instead.
| Failure mode | Why it happens | What to do instead |
|---|---|---|
| One task list for every issue | All coordination work gets dumped into a single queue with no urgency or blocker distinction | Route by urgency, blocker, and owner so the queue reflects what to handle first |
| Outreach history kept apart from next actions | Call logs live in one place and the to-do lives in another | Keep contact history and the next action on the same record so context travels with the task |
| Follow-ups with no due date or escalation | Work is assigned but nothing surfaces when it stalls | Give every action a due date and a rule for when it escalates to a supervisor or clinician |
| AI added before the record is agreed | Summaries and drafts get bolted on before the team agrees what the record should hold | Settle the record and states first, then add AI to the administrative parts only |
| The clinical line blurs | A workflow or tool starts resolving tasks that carry clinical weight | Route mixed tasks to a clinician as an explicit state; automation stays on pure admin |
| Reviewing volume instead of blockers | The queue review counts open items but never looks at why they are stuck | Review blockers and ownership, not just how many items are open |
The thread running through all of these is the same: the workflow drifts back toward an undifferentiated pile of work with no owner and no context. Every rule you add is really just a way to keep that from happening again.
What to measure
You do not need a dashboard to know whether this is working, but a few honest measures tell you fast. Watch open follow-ups, overdue actions, blockers grouped by type, unassigned items, repeated outreach attempts, escalations, and how long items sit in each waiting state. The most telling one is softer: how much time the team spends reconstructing where a patient stands before they can act. When that time drops, the shared view is doing its job.
To put a rough cost on the manual coordination the workflow removes, the manual-work ROI guide and the Workflow Readiness & ROI Calculator give you a way to estimate it before you commit budget.
A first month that makes one queue reviewable
The whole point of starting narrow is that you can see results inside a month. Pick one coordination queue where follow-up is repeatedly hard, and build just enough to run a real review from it. A sensible sequence looks like this.
- Week 1: map the chosen patient path, its triggers, handoffs, blockers, and outreach points, and write down the clinical and administrative boundary for this path.
- Week 2: define the coordination record, the states, the owner rules, and the escalation rules, and agree how patient data stays inside approved systems.
- Week 3: connect the minimum data needed to keep the record current and build the queue view the team will actually open.
- Week 4: run the daily review, clear real blockers, and tighten the routing and next-action rules based on what you saw.
That deliberately narrow start is the same method described in how to choose the first workflow to improve with AI. Defer everything that is not needed to make one queue reviewable. More paths, more integrations, and AI support can come once the first queue is genuinely running from the shared view instead of from memory.
When to keep going, and when to stop
At the end of the first month, judge it plainly. Keep going if the queue now makes handoffs and blockers visible before patients fall through the gaps, and if the daily review is producing decisions rather than a readout. Expand to the next coordination path, connect the next system, and add the administrative AI support that earned its place.
Narrow or stop if the team cannot agree on owner rules, or if the real blocker turns out to be something the workflow cannot fix, like a staffing gap or an unclear line of clinical responsibility. A coordination workflow makes ownership visible; it cannot invent an owner who does not exist. If that is the problem, name it and solve it directly rather than layering more tooling on top.
How Ubisar would approach this workflow
If we picked this up together, week one would go to choosing one coordination path, post-discharge follow-up, a specialist referral, a chronic-care check-in, or an authorization blocker, and mapping its trigger, owner, patient status, blocker, outreach, and escalation, with the clinical and administrative boundary written down first. The first thing you would have in hand is a working coordination record with urgency, blocker type, next action, owner, due date, source, and escalation state.
Weeks two and three would connect the minimum EHR, referral, scheduling, task, and communication data needed to make one queue reviewable, with patient data staying in approved systems, and add AI only for the administrative parts: reviewed summaries, blocker classification, and outreach drafts a person still sends. By week four the care team should be able to run a short queue review that shows which patient needs what next, who owns it, and where a clinician has to weigh in. That is the shape of a single month under AI, Data & Tech Implementation. If you want to talk through which queue to start with, get in touch.
If you are still deciding what kind of help you need, the comparison of an AI consultant, an automation agency, and software is a straight read, what AI implementation costs in 2026 covers budget, and there are more worked examples in the Ubisar workflow guides.