complex systems · regulatory strategy

Compliance at scale

Automated compliance system that enabled rapid multi-state expansion, reducing setup time from days to minutes

ROLE

Lead Designer

TEAM

1 PM, 4 Engineers
Clinical Ops Team

TIMELINE

Mar - June, 2025 (Shipped)

Due to NDA, some design details are abstracted to protect proprietary information

Project context

Nurse practitioners need supervision in the states we wanted to expand

To meet growing demand for more areas, we needed more proviers seeing patients. The fastest path: hire Nurse Practitioners (NPs) to work alongside doctors.

But there's a catch: in most U.S. states, NPs can't practice independently. They must be supervised by a licensed physician — and the rules for how that supervision works are different in every state.

Why this is hard

Three constraints made manual tracking unsustainable

Through research, I mapped the chain of constraints blocking expansion: physician shortage drives NP-led expansion, but supervision mandates vary dramatically by state, creating an operational bottleneck from three converging challenges.

The problem

Manual tracking can't scale

The chain of constraints blocking expansion as setting up each new state took days of manual work, like cross-referencing spreadsheets, verifying licenses, checking supervision caps. One missed detail could mean a compliance violation.

Result of this approach

Expansion pace couldn't keep up with business demand.

Translating regulations

From legal documents to automated rules

I translated ambiguous regulatory language into deterministic rules close collaboration with legal and ops.

Self-serve configuration

Empowering Ops to manage zero-code compliance

Should state rules live in code (faster to build) or in a UI config system (more complex)?

I advocated for zero-code configuration because: hardcoding rules wasn't sustainable given the frequency of regulatory changes. The initial investment paid for itself by eliminating recurring engineering work.

Direction shift

From resource-centric to risk-centric

My initial design organized the system around physicians—the scarce resource. This felt intuitive: doctors supervise NPs, so structure the data hierarchy that way.

But as I refined the workflow, I learned a critical constraint: NPs can only have one supervisor per state. This changed everything.

Physician-centric hierarchy

Risk: Hidden "orphaned" NPs. NPs without supervisors ('orphans') remain invisible as they lack a parent association. Identifying these gaps requires manual audits or ad-hoc reporting.

NP-centric hierarchy

Result: Instant risk visibility. By inverting the hierarchy, every NP becomes a primary record. A missing supervisor is no longer a hidden data point, but an immediate compliance flag.

Design iteration

Testing with Ops convinced skeptical stakeholders

After designing the NP-centric workflow, I faced pushback from two stakeholder groups:

  1. Engineering (worried about rebuild cost): "The physician-centric work have been reviewed. Why not ship what we have?"

  2. Clinical Operations leadership (risk-averse):"We've already reviewed the physician-centric flow and it works. Why change direction mid-project?"

I presented both workflows side-by-side in the group review:

Physician-centric workflow

🔴 Step 1: Scan physician list for [State X] providers (8 physicians)

🔴 Step 2: Click into each physician's detail page

🔴 Step 3: Note which NPs are assigned

🔴 Step 4: Cross-reference with master NP list

⚠️ Result: Took several minutes and missed compliance gaps

NP-centric workflow

✅ Step 1: Locate the NP who lacks of collaborating physician

✅ Step 2: Assign physician from the modal

✅ Result: All 3 orphaned NPs instantly visible

For Engineering: The new workflow saves more development efforts.

For Clinical Ops leadership (already approved previous design): The new workflow helps admins save multiple clicks per assignment and reduce the possibility of missing orphaned NP.

Result: Stakeholders approved the architectural pivot in one meeting. Engineering lead: "That efficiency data is too compelling to ignore."

Impact & Outcomes

Shipped and enabled 5x faster expansion

Business impact

  • Multi-state expansion accelerated by 5x (vs. previous pace)

  • Significantly accelerated multi-state expansion

  • Zero compliance violations since launch

  • Ops team independently manages ongoing rule updates without engineering involvement

What this enabled

This system became a prerequisite for leadership to approve additional state launches.

What I learned

Building trust with Ops was harder than building the system. They'd seen "automation" fail before. I earned buy-in by starting with a 2-state pilot to prove reliability, then training them hands-on rather than documentation dumps.

What I'd do differently

Involve legal counsel earlier in design workshops. We had to revise part of the logic model in month 3 when legal flagged edge cases I'd missed.