Designing Intelligent Case Routing
Simplifying Workforce Management & Automating Case Prioritization for Complex Healthcare Operations
March–May 2026 | Released October 2026
Overview & Challenge
Judi Health’s prior authorization platform enables healthcare teams to review and process complex cases across different clinical specialties, business lines, and operational workflows.
As case volumes increase, determining which cases should be worked on, by whom, and in what order becomes increasingly difficult.
Historically, reviewers manually selected cases from queues they had permission to access. While this offered flexibility, it also introduced inconsistent prioritization, context switching, and opportunities for users to select less complex cases over more urgent work.
The initial product initiative, Get Next, aimed to simplify this process by automatically directing reviewers to their next case.
However, a more fundamental problem emerged: How could the system determine the right case for the right person without compromising qualifications, operational efficiency, or turnaround-time requirements?
Solving this required more than an automated button. It required rethinking how the platform defined, assigned, and prioritized work.
Role
I assumed primary design ownership during the third discovery and planning phase, following an initial period of collaboration with the previous designer.
I led subsequent stakeholder discovery, requirements exploration, workflow architecture, interaction design, and engineering collaboration through final design delivery.
My work included defining the initial skill-based routing model, facilitating discovery with multiple healthcare stakeholders, exploring operational edge cases, and adapting the design in collaboration with engineering to support a more automated approach.
The design process ran approximately eight weeks, (March-May 2026). The solution was released in October 2026 following development and shifting product priorities.
Part One
Discovery
The original Get Next initiative focused on a relatively straightforward interaction: a reviewer clicks a button and receives the next available case, prioritized by its remaining turnaround time.
But while this could reduce manual case selection, it didn’t account for how healthcare teams actually organize their work.
Reviewers may have different specialties, qualifications, or responsibilities, even when they share access to the same queues. Some process general cases, while others handle more specialized clinical reviews.
Meanwhile, supervisors need to manage staff availability, distribute workloads, and maintain coverage when team members are unavailable.
The challenge wasn’t simply determining which case was next in line. It was determining which case was appropriate for a particular reviewer at a particular moment.
Where the existing process broke down
Initial discovery and product requirements highlighted three recurring operational concerns:
Context switching: Reviewers could move between unrelated cases, introducing additional cognitive load and potentially slowing case processing.
Cherry-picking: Manual case selection allowed users to favor less complex work, contributing to inconsistent workloads and turnaround times.
Coverage gaps: PTO, unexpected absences, and changing case volumes created additional administrative work to ensure important cases were addressed.
The existing processes also relied heavily on manual scheduling and workforce coordination outside the product.
[IMAGE 02 — EXISTING WORKFLOW]
Use the Excel scheduling examples from the early Lucidchart batch or the PHP Jira discovery materials. Show a sanitized example of the weekly workforce assignment spreadsheet, ideally alongside a small annotated explanation of how supervisors coordinated responsibilities.
Learning from different operating models
After taking over the initiative, I led discovery conversations with stakeholders from two healthcare organizations, PHP and Prime, to better understand their operational needs.
I also reviewed recordings of reviewers and supervisors performing existing workforce management activities, including spreadsheet-based scheduling.
The goal was to understand how different teams distributed work and identify what the platform needed to support without prescribing a single organization’s operating model.
The conversations revealed several important considerations.
Assignments weren’t necessarily permanent
Some organizations assigned staff to specific responsibilities for extended periods, while others regularly adjusted assignments based on daily staffing, upcoming PTO, or changing workload demands.
Roles didn’t always determine qualifications
Two employees with the same role could have different levels of specialization. A pharmacist may be qualified to review general clinical cases but not necessarily a complex oncology case.
Supervisors needed flexibility without additional administration
Teams wanted the ability to make temporary staffing adjustments, modify multiple assignments, and maintain visibility into coverage without managing individual cases manually.
Different organizations needed different degrees of control
The system needed to support customer-specific operating models, from highly structured specialty assignments to broader responsibilities across multiple types of work.
Identifying the most important constraint
One of the most consequential findings came from discussing the tradeoff between turnaround time and reviewer qualifications.
I asked stakeholders whether they would prefer to risk missing a turnaround-time target or allow a case to be handled by someone who wasn’t appropriately qualified.
They consistently prioritized qualified case handling.
This established an important principle for the solution:
The system could optimize the order of work, but it could not compromise who was eligible to perform that work.
This became the foundation for the routing model and helped distinguish two requirements that had initially been considered together: eligibility and prioritization.
[IMAGE 03 — DISCOVERY SYNTHESIS]
Part Two
Solution Strategy
Part Three
Execution, Challenges & Rollout
Designing the configuration experience
With the routing approach established, the next challenge was translating its behavior into an administrative interface that was understandable, efficient, and scalable.
The system needed to support several core activities: creating skills, associating them with relevant case attributes, assigning users, and identifying potentially risky changes.
The goal was to make complex configuration manageable without exposing unnecessary algorithmic detail to administrators.
Separating permissions from workforce configuration
One of the first information architecture decisions was where skill management should live.
The existing User Permissions area already contained role and queue access configuration. Introducing skill creation, assignments, and related settings within the same interface would substantially increase its complexity.
Additionally, skill-based routing wouldn’t be available to every customer tenant.
I separated the experience into two connected areas.
User Permissions would control whether skill-based routing was enabled for an individual user.
Skills Management would provide a dedicated workspace for defining skills, assigning users, and managing workforce configuration.
This distinction kept access management separate from operational configuration while creating room for future capabilities, such as skill coverage monitoring and performance dashboards.
[IMAGE 06 — USER PERMISSIONS]
Making assignments visible and manageable
The Skills Management page was organized around two complementary views.
The first table provides an overview of the configured skills, including their type and the number of assigned users.
The second table focuses on individual users, displaying their roles and associated exclusive and non-exclusive skills.
To reduce unnecessary navigation, I introduced expandable rows that allow administrators to review and edit assignments directly within the table.
This keeps the user’s current assignments visible while minimizing the need to move between separate screens for routine changes.
The interface also distinguishes exclusive skills visually, helping administrators understand which assignments carry additional access restrictions.
[IMAGE 07 — SKILLS MANAGEMENT & INLINE EDITING]
Building skills around case attributes
Different healthcare organizations define their work in different ways.
A skill could relate to a particular line of business, drug, clinical review level, questionnaire, client, or other case attributes.
Rather than creating a fixed set of predefined specialties, the configuration experience allows administrators to define a skill using combinations of supported criteria.
The New Skill interface also allows administrators to identify a skill as exclusive, associate it with relevant roles, and manage its assigned users.
This gives organizations the flexibility to define their own operational categories while allowing the routing algorithm to interpret the resulting configuration.
[IMAGE 08 — CREATE AND EDIT SKILL]
Supporting large-scale changes
During discovery, stakeholders described workforce management processes that frequently involved modifying assignments for multiple employees.
Managing every individual change independently would reproduce much of the manual effort the initiative aimed to reduce.
I introduced a bulk-assignment experience organized by role, allowing supervisors to work with groups of eligible users and update their skill assignments within a single interface.
This provided an initial improvement without requiring the team to introduce an entirely new user-grouping system across the product.
[IMAGE 09 — BULK ASSIGNMENT]
Communicating operational risk
Simplifying case routing also meant considering what could happen when administrators configured the system incorrectly.
For example, removing users from an exclusive skill could leave important cases without sufficient coverage.
Similarly, overlapping exclusive skill definitions could change which users were able to access cases that previously matched other skills.
These weren’t simply configuration errors. They could affect real operational outcomes.
Working with engineering, I incorporated safeguards informed by the proposed case-elapse risk logic.
The interface surfaces warnings when changes may introduce coverage risks and uses confirmation dialogs to communicate potentially significant consequences before administrators proceed.
These warnings consider factors such as the relationship between assigned-user coverage and expected case volume.
The intention was not to prevent administrators from making every potentially risky change, but to help them understand the implications and make informed decisions.
[IMAGE 10 — SAFEGUARDS & EDGE CASES]
Prioritizing what mattered for the first release
Throughout the process, the team had to balance operational flexibility against technical feasibility and delivery scope.
The original concept included more manual assignment layers and exception handling. The final architecture reduced that burden through algorithmic prioritization.
Other capabilities, such as reusable user groups, advanced coverage forecasting, and richer skill-health dashboards, were identified as future opportunities rather than prerequisites for the initial experience.
This allowed us to focus on the foundational requirements: defining skills, controlling eligibility, managing assignments, and supporting case routing without unnecessary administrative overhead.
The final designs were delivered in May 2026, approximately eight weeks after I assumed primary ownership.
Following development and changes in product priorities, Skilling 2.0 was released in October 2026.
Part Four
Release & Impact
Although the release is recent and post-launch performance data is not yet available, the solution has already demonstrated value beyond its operational use case.
The skill-based routing experience became a notable differentiator in enterprise sales demonstrations, including those associated with a signed contract with a significant enterprise agreement.
While the feature cannot be credited independently with securing that contract, its ability to demonstrate configurable workforce specialization and more intelligent case distribution was an important part of the product’s commercial story.
The initiative also delivered a production-ready foundation for more sophisticated case assignment across different healthcare operating models.
From a design perspective, the outcome was a streamlined administrative experience that supports capabilities previously dependent on significantly more manual coordination.
[IMAGE 11 — FINAL EXPERIENCE / DELIVERY]
Measuring long-term success
Because the feature has only recently launched, its operational impact still needs to be evaluated.
The next step is understanding whether the system achieves its intended outcomes in production.
Areas worth measuring include:
Adoption of automated versus manual case selection.
Changes in case processing and turnaround-time performance.
Distribution of work across users and specialties.
Frequency of coverage gaps or cases at risk of elapsing.
Administrative effort required to maintain and update skill assignments.
How supervisors interpret and respond to configuration warnings.
These measures will help determine not only whether the routing algorithm performs effectively, but whether the administrative experience supports sustainable workforce management.
Reflection
The biggest lesson from this project was that simplifying an experience doesn’t always mean simplifying the underlying system.
My initial solution relied on a detailed hierarchy of manual assignments because it offered clear control over how work would be distributed.
That approach addressed the operational problem, but it also transferred significant responsibility to administrators.
Through engineering collaboration, we found an opportunity to preserve the important business rules while moving much of that complexity into the routing algorithm.
The result was a simpler interface supporting a more adaptable system.
It also reinforced the value of bringing previous industry experience into product discovery. Having encountered similar workforce coverage challenges earlier in my career, I was able to recognize the underlying problem quickly. But adapting that knowledge to healthcare required validating assumptions, understanding clinical constraints, and accounting for different organizational workflows.
Looking back
If I were to extend the work, I would prioritize understanding how supervisors interact with the configuration experience after launch.
In particular, I would want to validate whether the case-elapse risk warnings are accurate, understandable, and actionable. Surfacing a warning is useful, but helping administrators confidently resolve a potential problem would be more valuable.
I’d also explore reusable user groups to make bulk assignments more efficient, particularly for organizations managing large teams or frequently changing coverage.
Over time, the dedicated Skills Management area could evolve into a broader operational dashboard, helping supervisors understand assignment health, utilization, coverage risks, and upcoming staffing needs.
The underlying architecture was designed to accommodate that growth without requiring a fundamental redesign of the initial experience.
Ultimately, this project reinforced that good enterprise UX isn’t about exposing every available control. It’s about understanding which decisions users need to make—and designing the system to handle the rest.