Case Study - A Billing Engine That Refuses to Guess

Overview

Patients on OpBuddy do structured daily recovery work after joint replacement; clinical staff review and log time, and the practice bills CMS for the monitoring under RTM CPT codes. Two separate clocks run in parallel and don't align: a rolling 30-day monitoring period anchored to enrollment date drives device-supply codes, while the calendar month in which that period closes drives management codes. Codes are mutually exclusive in ways that are easy to get wrong, and a global surgical period can suppress RTM billing entirely — but only under specific, easy-to-miss conditions.

The problem

The blocking rules aren't written in engineering language anywhere — they live in CMS billing guidance. A generalist engineer building from a feature spec models "eligible" as a boolean and misses that partial credit isn't allowed: if any blocker fires, no codes are recommended for that period, full stop. Getting this wrong in either direction is either a false claim or silently lost revenue, and because CMS audits can land up to two years later, the system needs to reproduce, on demand, exactly why a determination was made using exactly the inputs it had then.

Why it took a physician-engineer

Applying the CMS rules correctly requires understanding what actually happens clinically during a 30-day recovery period: what counts as a global surgical period, why device-supply and management codes are governed by different clocks, why a phone call isn't interchangeable with attested review minutes, and why RPM and RTM billing for the same patient in the same month is a compliance conflict rather than a data-modeling inconvenience. This is the kind of problem where the CPT-code judgment and the systems-design judgment have to happen in the same head, because the correctness of the engineering is the correctness of the billing.

Approach

The determination engine is a pure function — no I/O, no database calls, no internal clock reads. The current time is passed in as an explicit argument, which is what makes a determination reproducible: run the same function against the same stored inputs any time in the future and get an identical answer. Each rule — period construction, qualifying-day counting, device-code tiering, setup-code timing, management-code tiering, prior-relationship checks, cross-episode conflict detection, global-period suppression, consent-timing checks — is implemented and unit-tested independently, and every rule that fires is cited by ID in the output.

The engine emits recommended codes, blockers, warnings, an evidence packet of the qualifying dates and events that back the count, the full list of rules evaluated, and a snapshot of the config that was active — persisted immutably. A human reviewer and the practice's own biller submit the actual claim.

Under the hood

Node.js pure functions, deployed as an AWS Lambda behind API Gateway with a Cognito JWT authorizer, reading from purpose-built, immutable DynamoDB tables — protocol activity events, attested time entries, interactive-communication events, consent and enrollment records. The evaluator self-selects the latest fully-elapsed 30-day period and produces one determination per invocation, covering device-supply codes, the once-per-episode setup code, and management codes for the calendar month in which the period closes. Test coverage grew from an initial 25 passing cases to 77 as rules were added, covering boundary conditions like DST-affected same-day deduplication and interaction-gate cutoffs on management-code tiers.

Outcome

A fully test-covered, deterministic engine that went from initial rule modeling to a second, gap-closing revision within the same short build window — with every rule traceable to a specific CMS billing constraint and every determination reproducible after the fact. That reproducibility is the property that actually protects a practice under audit.