Billing, Unbundled

Every pregnancy Quilted's customers bill today goes out as a single claim. From January 2027 it goes out as about fifteen. This is the system that has to make that survivable for a practice with one part-time biller.

Quilted Health builds a midwifery-focused EHR, rebuilt from the ground up rather than extended from Maternity Neighborhood, the platform it acquired in 2022 and still supports. Billing was the last core workflow to be designed and the most consequential, because it was the only one with a legislated deadline attached.

I designed it across three levels: coding inside the encounter, service rollup and statements at the chart, and financial operations across the practice. The work was not invoicing screens. It was deciding where billing truth lives in a clinical record, and who is allowed to change it.

The American Medical Association is eliminating bundled maternity codes effective January 1, 2027. It is the single largest billing change midwives have faced.

Under the old model, one global code covered months of care and went out after delivery. Under the new one, every visit carries its own diagnosis and procedure code, chart notes have to support the complexity level being billed, providers move from Z codes to O codes to document that complexity, and time based billing becomes critical. For a small practice this is a change in kind, not degree.

The legacy platform could not follow them across. Maternity Neighborhood was built for global billing, had no practice level dashboards for billing, eligibility, or missing services, and no forced chart authentication, which is a compliance exposure of its own.

And the destination could still move. While we were designing, CMS proposed fifteen new G codes that would have effectively re-bundled what the AMA had just unbundled. ACOG, ACNM, and the AMA opposed it in public comment. The final rule was expected in October 2026, the same month our billing module was scheduled to launch, and reimbursement rates for the new codes were still unknown.

That is the actual design problem. Not "build billing," but build a billing system specific enough to be useful under the new codes and structurally loose enough to survive the rule landing somewhere else.

I came to this as a designer, not a biller. Fluency had to be built deliberately, and then checked against people who bill for a living.

Three inputs did most of the work: interviews with the midwives at Quilted's own clinical site, conversations with existing Maternity Neighborhood customers about what they valued and what frustrated them, and a pass through the support queue during onboarding, which is the unfiltered version of what users are actually stuck on. On top of that, repeated review sessions with billing stakeholders and customer practices: at least five distinct practices or customer groups, and at least six midwives, billing experts, and practice operators.

The pattern that shaped the most design was a relationship, not a feature request. Billers depend on providers to code and document correctly, but cannot fix the chart themselves. On the legacy platform that dependency curdled: optional authentication meant charts could sit unsigned for months, then get authenticated in a single bulk pass, and billers were left reconstructing intent from a generic notes field. They could not reliably tell which code a provider meant.

Between review sessions I kept a synthetic billing advisor persona, seeded with what the real billers had taught me, and used it to pressure-test edge cases on demand. It was useful for rehearsing a scenario at midnight and it was also confidently wrong about a state Medicaid rule, which is exactly why it never replaced anyone. It kept me honest between sessions. They kept it honest, period.

I treated this as a systems problem first and a screens problem second. The first real decision was a three level model, which gave the feature a mental model and separated responsibility cleanly between three different users.

The thorniest problem was multi-payer. When one payer partially pays or denies, the remaining balance has to move to a secondary payer or to the patient. The question is whether you mutate the original statement or create a new one.

I drove the decision to create a new linked statement for each payer step, with connected IDs like 245, 245-1, and 245-2, rather than editing the original in place. Mutating would have been simpler to build and would have destroyed the history that makes a ledger auditable. The linked model preserved that history, matched what billing systems expect, and reduced integration risk for the clearinghouse work coming later. It also created its own follow-on problems: zeroing out the parent statement, preventing charge double-counting, handling cancellation order, and showing a person which statements are related and why.

By early August 2026 the billing system had gone from early architecture work to a complete end-to-end design spanning encounter capture, service rollup, statements, dashboards, and multi-payer flows, with a target release in late October 2026, ahead of the January deadline.

Design and delivery figures. The module had not shipped at the time of writing, so there are no adoption or outcome numbers yet.

The design direction was validated repeatedly by billing stakeholders and midwifery practices, who consistently pointed at the same value: fewer missed charges, an audit trail that survives scrutiny, and less reconstruction work after the fact. Just as importantly, the work repositioned billing from a back-office afterthought into a core product capability, and established a foundation that supports manual v1 workflows now while staying ready for claim generation, clearinghouse connection, and full revenue cycle management later.

What I would do differently. I would have brought engineering into the stakeholder sessions earlier. The data modeling debates about statements and payer steps would have been much shorter if the engineers had watched a biller explain, in their own words, why editing a statement in place destroys the thing they need it for.

What held up. Deciding the three level model before designing screens. Every later argument, about where an edit belongs, who can make it, and what it should be called, resolved faster because there was already an agreed answer to which level owns it.

What I am still sitting with. The granularity that closes audit and compliance gaps also adds provider workload. Every quick-pick and dot phrase reduces that cost without removing it. If the final rule re-bundles after all, some of this precision becomes overhead, and I would rather have designed for the transition honestly than pretend the uncertainty was not there.

Credits: designed alongside a VP of Product, a design lead, and a distributed engineering team who treated billing logic as a product surface rather than plumbing, and a group of midwives, billers, and practice operators who kept correcting me, which is the only reason any of this is right.