Project Scope
6 Weekly Sprints & Cadence
We worked in 6-week sprints covering data structures, rule modeling, user interviews, and system design. I collaborated daily with BAs, the project owner, and developers to define requirements and structure program logic.
Sprint Timetable
Challenges
Eligibility rules were difficult to locate, confirm, and act upon, especially when every second counted
Manual Spreadsheet
Fragmented Policy Logic
Eligibility rules differed among hospitals, facilities, and programs, each using unique formats, thresholds, and exceptions.
High Mismatch Risk
Slight variations, such as insurance overrides, residency exceptions, and household size buckets, often led to incorrect determinations.
No Unified System
Critical eligibility criteria were spread across different spreadsheets and versions, making quick verification nearly impossible during calls.
Goals
I framed the design goals around turning inconsistent policy data into a modular system that advocates could search, edit, and apply in real time while scaling as policies evolved
01_ Make Policies Searchable
Turn scattered policy data into searchable fields, so advocates can match rules in seconds
02_ Define Eligibility Clearly
Translate vague criteria into clear, reviewable logic that advocates can trust in real time
03_ Prevent Errors at Scale
Use real-time validation to catch errors early and scale new rules without slowing calls
Understanding the Context
Designing for real-time decision-making under call pressure
Matching logic only made sense once I understood the real-life constraints advocates faced during calls. So, I worked closely with clients and the product team to clearly structure the flow.
Even while working fully remote, I kept the feedback loop tight. Daily meetings and consistent client input helped identify edge cases we would've otherwise missed.
Daily Syncs, Remote First
Maintained alignment despite changing priorities and no in-person context
Consistent Client Feedback
Exposed gaps and challenged unclear assumptions early
Support Team Insights
Revealed complex edge cases and call-specific blockers
Interview Synthesis
Critical care breaks down when rules are undefined, and systems are disorganized
I interviewed 10 active users to identify where policy lookup and decision-making failed. Their stories highlighted recurring issues with clarity, speed, and reliability.
Confusing or Missing Rules
"I have to go through multiple documents to find matching eligibility rules."
Lost in Tabs
"I'm busy flipping tabs instead of helping. Tasks became overwhelming."
Frequent Mismatches & Delay
"I once gave someone the wrong info. Now I double-check every single time."
Data Structure Diagram
The domain model defined how the entire system should behave
Policy rules were too inconsistent to design around, so I first mapped all entities and rule dependencies into a single unified model that the system could reliably use.
Core Entities | Rule Models & Validation Flows
System Requirement Overview
The core requirements of a highly adaptable policy system
Eligibility workflows rely on inconsistent, multi-layered policy data that covers health systems, facilities, qualifiers, discount rules, documents, and status logic. Clarifying these requirements helped define what the system must reliably support before proposing solutions.
3 Core Requirements
Exploring Solutions
From recurring pain points to a modular system built for speed and accuracy, solutions focus on:
Guided Rule Builder
Combine rules into a single guided form to eliminate file-switching and reduce vague logic
Smart Policy Filter
Inconsistently reveals matching policies with clear criteria, no spreadsheet required
Live Validation Alerts
Flag incomplete or unclear rule entries immediately to prevent errors
Solutions
01_ Guided Rule Builder
Analysts had to switch between multiple screens to complete a single policy, which caused confusion about what was missing and led to inconsistencies.
I reorganized the whole process into a guided builder that displays requirements in a logical order. This helped analysts complete policies without guesswork and ensured each rule was created with proper context.
Early version
Limited logic capture
The early UI only listed buckets and discount rules as two basic categories. This couldn't handle exceptions or combined conditions, causing mismatches or unclear qualification logic.
Final
Flexible logic composition
So, I redesigned it as a more flexible, structured form that supports combined rules, conditional exceptions, and more straightforward prompts, reducing errors and helping analysts and advocates apply accurate requirements.
*Want to see the full eligibility form?
02_ Integrated Health System Dashboard
A major source of errors came from analysts referencing external spreadsheets to confirm which facilities belonged to which health system.
So, I made sure to display health systems and facility mappings directly within the policy workflow to remove that dependency. This provided analysts with immediate clarity and eliminated the need to verify data outside the tool.
Early version
The initial dashboard only listed basic information about facilities and policies without showing their relationship. This still left advocates to work to piece details together manually.
Final
To fix this, I unified key info for each health system, showing relationships between systems while enabling quick search and in-context add actions. So, advocates can navigate complicated policies in one place.
Policy Logic Status Update
This status model was also restructured to enable more accurate progress tracking, aligning the system logic with the redesigned policy workflow.
03_ Building Flexibility into Eligibility logic
Rather than hard-coding rules, I introduced a modular logic framework that let analysts define eligibility requirements step-by-step. This supports scenarios ranging from simple to highly variable across different health systems and policies.
Use case: An initial assessment to verify if the patient meets the minimum eligibility threshold for assistance (e.g., FPL ≤ 200%).
I designed this as the simplest block in the flow so analysts can quickly set a baseline and avoid early rule conflicts.
Use case: Hospitals often set multiple income ranges with varying discount levels. (e.g., FPL ≤ 200% gets 100% discount, ≤ 300% gets 50%).
Analysts frequently needed 3-5 brackets, and manually recreating each range caused overlaps and errors. I added a bracket builder that lets them duplicate, edit, and reorder brackets safely without breaking thresholds.
Use case: Programs often require multiple factors to be met simultaneously (e.g., FPL > 200% AND Age ≥ 65).
Previously, conditions were spread across fields, making AND/OR logic ambiguous. I unified all condition types into a single structured form so that ("AND within a group, OR across groups") is explicit and easy to follow.
Use case: Fully composed qualifiers that require multiple factors simultaneously (e.g., Income > 200% AND Age ≥ 65 AND Residency = NY within the same group).
Analysts could easily misunderstand which conditions belonged together. I introduced visual grouping so each qualifier group represents conditions that must all be met, making intent more straightforward.
Following this, I also outlined how layered discounts can be defined using the same logical frameworks.
Use case: Programs commonly offer layered discounts across services. (e.g., 75% waiver + 100% discount for specific procedures). Analysts needed a simple way to define these rules without overlaps or errors.
So, I extended the same eligibility logic framework to support discount rules.
Rules can be added, layered, and scoped to specific services, and the system auto-applies them without extra steps, reducing manual work and keeping discounts consistent.
04_ Real-Time Validation to Prevent Downstream Errors
Analysts frequently built policies that appeared valid on-screen but later failed during enrollment or reporting due to silent issues, such as incorrect income ranges, mismatched discount rules, or missing health system IDs. These errors were only discovered after submission, slowing operations and causing rework.
I integrated real-time validation directly into the form to handle this, so users receive immediate, contextual feedback as they set up rules.
Range Validation
Immediate Rule-Level Feedback
Required System Linkage Checks
I also added a save-time system linkage check so analysts don't accidentally create policies without the required health system, a small guardrail that prevents downstream failures before they happen
Outcome
Modular eligibility logic reduced errors and help advocates match patients faster and more accurate
By reorganizing eligibility rules into reusable, predictable modules and implementing real-time checks where necessary, analysts made fewer mistakes when adding policies to databases and completed matching workflows more quickly.
Takeaways
What I learned from designing complex systems from scratch
©Chaeminkim2026