Health plan network analysts manage a constant stream of provider actions — targeting, terminating, excluding. Each action has an owner, a status, and a history. Before this project, seeing any of that required knowing exactly where to look.

To find actions already taken, an analyst had to enter a project, filter by state, then county, then specialty, navigate to a provider list, and toggle to a view of acted-upon providers. Then repeat that sequence for every county-specialty combination relevant to their work. An analyst building a network across multiple counties and specialties might run that path a dozen times in a single session — reconstructing by hand a picture the system already had, but wouldn’t show.

This wasn’t a missing feature. It was a visibility problem the team had stopped questioning.

The system

I came to this project from a parallel initiative — designing a provider profile that unified fragmented data sources into a single view. That work kept raising the same question in a different form: why is information that belongs together being stored in ways that keep it apart? The action management problem was the same pattern. The data existed. The system just wouldn’t surface it.

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

Talking with analysts across network management and contracting teams, the mental model was consistent even though their workarounds looked different: actions were organized by specific action type, not by provider; priority was set by deadline and consequence; status reflected real workflow states — unprocessed, processed, and the downstream rules that determined which providers and locations were pulled in. That model became the information architecture.

The decisions

The architectural call: surface everything, break nothing. The hardest constraint wasn’t the design — it was the system. Our platform had specific rules around how data changes were accepted, how draft states were distinguished from processed ones, and at what level a user could access a consolidated view. I couldn’t change the underlying data model. I couldn’t push users too far outside a workflow they were already being asked to change.

The answer was to build a consolidated action view that sat above the existing filter structure — accessible from within a project, visible to anyone with the right permissions, showing all actions regardless of county-specialty combination. The individual filter paths still existed for users who needed them. But for the first time, the full picture was one click away.

The risk was that analysts would treat the consolidated view and the filtered view as separate things when they were the same data seen differently. I addressed this with persistent status indicators on provider records — visible at all times, not just inside the action panel — so the connection between provider data and open 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. A visible status change at the deadline and a manager-visible flag after a grace period surfaced 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

• Analysts could see every action taken across a project in a single view — without reconstructing it filter by filter
• The repetitive navigation path that had been a normal part of the workflow was eliminated; user path analysis showed a measurable reduction in repeated investigative sequences
• Managers got visibility into team activity they’d never had before — for the first time able to see what actions were in progress across their team without asking
• Clients specifically cited the consolidated view as saving time and reducing confusion about what their team had already acted on

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.

The deeper lesson was about scope. This project started as a task management feature. It became a visibility problem once we asked why the data was structured the way it was. The better question is almost always one level up from the brief.