Work that leaves the system becomes invisible — and invisible work doesn't get done.

Health plan operations generate a constant stream of provider changes within their network: terminating, targeting and excluding providers and entities. Each action could have a responsible party, a timeframe to work within, a status, and a history. Before this project, none of that lived in one place.

Analysts tracked open actions in at a county and specialty level, and sometimes within their own spreadsheet. Network managers had no visibility into processing capacity. Duplicate actions against the same provider — from different team members who didn’t know the other had already acted — was a known and accepted problem. The data to manage this workflow existed in the system. The interface to act on it didn’t.

The system

Shadowing sessions with network management, credentialing, and contracting teams produced one consistent observation: the moment a task was initiated in the system — this action became buried in a specific space within the UI, within a specific combination of filters that would reveal the location. It became invisible to everyone without knowledge or context. Coordination happened through hallway conversations, not shared tooling.

the work was happening — it just wasn’t visible to anyone but the person doing it

Analysts’ feedback across all three teams revealed how they actually grouped and prioritized actions. The mental model was consistent even though their tracking systems looked nothing alike: actions were organized by specific action, not by provider; priority was determined by deadline and consequence; status reflected real workflow states — unprocessed, processed - and impact was grouped by specific rules that pulled in multiple locations per provider, or by specific location itself. That model became the information architecture.

The decisions

The architectural call: queue and record, linked. The hardest decision was whether the action management interface was its own destination or embedded in the provider record. The answer was both. Analysts could work within a global action view or from within a provider record, where all actions for that provider appeared alongside the relevant data. The same actions existed in both places; updating it either place updated both.

The risk was that analysts would treat “my actions” and “provider actions” as separate things when they were the same thing viewed differently. I addressed this with persistent status chips on provider records — visible at all times, not just inside the action panel — so the connection between provider data and actionable work was always legible.

Presence over blocking. The duplicate action problem required a specific design choice: inform or enforce? Automated blocking would have created friction in legitimate cases where two team members genuinely acting on the same provider. I designed a lightweight presence layer instead that surfaced the information within actions, and indicators at the provider and access point level, leaving the judgment call with the analyst. Visibility without removing agency.

Tiered escalation, not noise. Actions needed to surface and be categorized without burying analysts within complexity. Soft indicators that allowed the analysts to know what was new, processed and unprocessed actions within their project helped to surface a conversation, not a performance review. Early testing found the indicator and categorization triggered less anxiety that previous.

Recording criteria as a design decision. Providers in this system aren’t identified by a single key — they can be targeted, terminated or excluded from the network by NPI, TIN, both, or contract entity. Each recording criteria type has different downstream effects on which providers and their locations are pulled into an action. I designed a radio selector that made these options explicit at the moment of action creation, rather than defaulting silently to NPI and requiring analysts to correct it later. I made sure that the actions were also representative of the criteria recorded to make sure it was visible.

What changed

• Teams swapped the deep dive and combination finding for the unified management system
• Duplicate action incidents — the primary coordination failure — dropped to near zero within the first quarter
• Manager visibility into team actions improved significantly; for the first time, managers could see the distribution of actions across their team and identify network changes

Reflection

The most useful design constraint on this project was the presence layer. The instinct early in the process was to prevent duplicate actions through blocking — an automated rule that would stop a second action from being created on a provider already in active state. That would have solved the metric while breaking the workflow. The teams doing this work operate under real time pressure and legitimate constraints. A system that enforces process removes the judgment that makes the process work. Surfacing information and trusting the analyst to act on it was the right call — and the usage data confirmed it.