NexGen RCM: Engineering Case Study

Context & Problem Statement

The U.S. healthcare system loses over $8 Billion annually due to administrative complexity. Eligibility errors are a leading cause of avoidable denials. Small practices often juggle 3–4 different systems, leading to data silos.

Design Constraints

Environment: No direct VPN or payer sandbox access; the entire flow had to be simulated in a browser environment.
Privacy: Must be safe to demo on a laptop in a public setting without exposing real patient data (Zero Trust/PHI).
Target Scale: Architecture designed to support 50,000+ eligibility checks per day with burst traffic handling.
RCM Domain: Must focus on eligibility error prevention to solve the specific business problem of frontend denials.

System Design in Detail

NexGen RCM acts as a centralized "Control Tower." It uses a micro-bot architecture to unify clinical and financial workflows.

📄

1. Intake

CSV / JSON Payload / EHR Export

⚙️

2. Bot Worker

Selenium WebDriver • Queue • NLP Parser

💾

3. Output

JSON Results • Analytics • FHIR Write-back

End-to-End Eligibility Flow

1
Intake: Patient records arrive as a CSV or JSON payload from an EHR export.
2
Queue Builder: The portal batches these into a worklist and tags each record with Payer and Risk Profile.
3
Bot Worker: The simulated Selenium bot opens the hosted portal (headless), authenticates, and runs eligibility for each record.
4
Parser: The script scrapes the HTML response and normalizes values into a single EligibilityResult object.
5
Writer: Results are written to JSON and posted to a simulated FHIR endpoint or data warehouse for analytics.

Data Modeling & Contracts

Because this is an RCM and analytics-heavy application, I treated data shapes as strict contracts between the UI bot and the backend.

// Patient Contract

{
  "id": "UUID",
  "name": "String",
  "dob": "YYYY-MM-DD",
  "member_id": "String",
  "payer_key": "Enum(medicare, anthem...)"
}

// EligibilityResult Contract

{
  "status": "ACTIVE | INACTIVE",
  "financial_summary": {
    "deductible": "Decimal",
    "copay": "Decimal"
  },
  "reference_number": "String",
  "risk_score": "Float"
}

// ClaimSnapshot Contract

{
  "claim_id": "String",
  "diagnosis_codes": ["ICD-10..."],
  "procedure_codes": ["CPT..."],
  "status": "Enum(Paid, Denied, Pending)",
  "denial_reason": "Nullable String (e.g. CO-16)"
}

Engineering for Reliability

Real payer portals are fragile. I implemented Exponential Backoff with Jitter to handle 503 errors gracefully without crashing the batch.

Resilience Simulator

Simulate a Payer API Outage (503 Errors)

Batch Success

100%

Request 1200 OK (22ms)

Request 2 (Failure)Pending...

Testing and Validation

Reliability isn't accidental. I employed specific testing strategies to ensure engineering maturity:

Selector Stability: Used robust XPath/CSS selectors that resist minor layout changes on payer portals.
Synthetic Data Generation: Created a generator for fake patients and benefit responses to stress-test rare edge cases (e.g., secondary coverage, missing DOB).
Property-Based Testing: Enforced logic invariants, such as "A plan with $0 copay and 0% coinsurance must imply deductible applies."

Observability & Runbook

The system treats logs as a first-class citizen to enable SRE-style monitoring.

Structured Logging: JSON logs for each patient run with timestamps and step markers.
Error Taxonomy: Errors are classified as Network (Retry), Auth (Alert), or Data (Skip).
Runbook Rule: "If a single payer fails 3 consecutive times, the bot automatically pauses the queue and surfaces the issue to a human."

Design Tradeoffs

Selenium vs. Direct API

Decision: Used Selenium.
Rationale: While APIs are cleaner, many small payers only expose legacy web portals to smaller practices. This mirrors the messy reality of RCM work where direct APIs aren't always available.

Client-Side Simulation

Decision: Fully static frontend.
Rationale: Kept the system front-end only to avoid server setup friction and make sharing easy, accepting extra JS complexity to simulate backend latency/logic in the browser for portability.

Domain Impact (Simulated)

The simulation models results based on industry case studies for automated RCM solutions.

Manual Workflow

15 min

average per eligibility

NexGen Sim

< 60 sec

per run incl. retries

Denial Reduction

30%

simulated drop

Staff Impact

High Value

focus on exceptions

Personal Reflection & Learning

Building NexGen RCM taught me to think like both a Charge Entry Specialist (focusing on UX speed) and a Systems Architect (focusing on fault tolerance).

What I learned:

Translating messy, non-deterministic payer behavior into reliable code paths.
Balancing UX polish with bot-friendly semantics.

Next Steps:

Real FHIR R4 Integration.
Multi-tenant scheduler to support multiple clinics.
Support for Prior Authorization and Claims Status APIs.

NexGen RCM: The Operating System for
Modern Healthcare

Role

Timeframe

Domain

Stack