Late facts

The hardest part of building a billing ledger into a speech therapy EMR is that the facts arrive in the wrong order.

A real example from our data this summer, with the family's details removed.

On June 22, a child has a speech therapy session. The charge is $150. That evening the therapist signs the note, and our system creates two things: a $150 claim for the insurance company and a $70 copay bill for the family. On June 25, the claim goes to the insurer.

On June 30, the insurer responds: "We'll pay $70. We're writing off $80. The family owes nothing." So the system cancels the family's $70 copay, and the books balance.

Then, on July 21, the front desk records a $70 payment from the family, dated May 15. The family had paid that copay five weeks before the session even happened.

Most software would simply add a line: "$70 received." The family now either has a mystery credit floating around, or the books show a copay paid against a copay that no longer exists. Both are wrong, and both eventually turn into a phone call.

Our ledger throws out its own story and retells it from the beginning, in the order the events actually happened rather than the order we learned about them:

  • May 15: Family pays $70 toward a future session.
  • June 22: Session happens. $150 charge, with $70 already paid.
  • June 25: Claim is sent.
  • June 30: Insurer pays $70 and says the family owes nothing.

Conclusion: the clinic owes the family $70 back. One late fact changed the meaning of the other three.

We keep every version of the story. This one session generated 26 ledger records across three different retellings, and nobody edited a number by hand to make it work. When a late fact arrives, the system replays the session from scratch and derives the answer again.

That's also why we couldn't just bolt a traditional double-entry accounting ledger onto an EMR. Double-entry is very good at answering what transaction happened and which accounts it affected. Healthcare billing keeps asking a second question: what did this transaction mean, now that we know something we didn't know when we recorded it? The payer changes patient responsibility, or an electronic remittance advice (ERA) shows up weeks later. A payment gets entered with an earlier effective date. A claim gets corrected, reversed, or reprocessed. The debits and credits still have to balance, but the meaning and allocation of those dollars can change as new facts arrive.

Building an automated double-entry ledger that can rebuild itself after all of that, while preserving the full history, is hard enough that, to our knowledge, Ambiki is the only EMR doing it this way. We have a patent pending on the system.

A timeline graphic titled A late fact changed the whole story, showing five steps: speech therapy session completed on 6/22 with a $150 charge and $70 copay billed, claim sent to insurer on 6/25, insurer response on 6/30 with $70 paid and $80 written off and family owes $0, family payment entered on 7/21 but actually paid 5/15, and the system recalculating so the clinic owes the family a $70 refund. A red arrow points from the 7/21 payment back to 5/15 with the note this happened first.
The payment was recorded last, but it actually happened first.