Billing
Practices change how they get paid. A cash-only clinic signs its first contract; a payer-billed practice adds a membership line; a therapist keeps half the panel on insurance and half self-pay. In most systems that is a platform decision made years before you had the information to make it.
Here it is decided per encounter, on one ledger, and changing your mix does not touch a single clinical record.
Three ways to run
The platform does not have a cash-pay edition and an insurance edition. It has one financial model that both use.
Direct primary care, concierge, cash-based therapy, aesthetics, memberships.
Payer-billed visits, with the coding and claim lifecycle the workflow needs.
The common case: some visits billed to a payer, some paid directly, one set of books.
What does not change
This is the whole design. The parts a practice cannot retrofit later are common to both models; the parts that differ attach at the boundary.
Side by side
A short list, which is the point. The last row is the one that saves a practice a migration.
| Cash pay | Insurance | |
|---|---|---|
| Who is invoiced | The patient directly. | The payer first, then the patient for their responsibility. |
| Coding | Coded anyway — CPT, HCPCS, ICD-10. | The same codes, now on claim lines. |
| Extra workflow | Statement and receipt. | Eligibility, submission, remittance, denial handling. |
| Staff who see it | Whoever takes payment. | The billing role, scoped away from clinical detail. |
| The ledger | One ledger. | The same one ledger. |
Claims and remittance
A denial is not one bad day. It is a claim rebuilt by hand, refiled, and waited on again — and the second attempt is often denied for a different reason nobody was told about the first time. The pipeline is arranged so that the catching happens early, where it is cheap.
Coverage is recorded before the patient is in the room, and the 270 inquiry and 271 response are generated and parsed as X12. No payer is connected to send them to yet, so the check itself is the practice’s until an eligibility adapter is bound.
Coded charges become 837P claim lines with no re-keying, dated by the visit rather than the day the charge was posted, and a visit is assembled once. The diagnoses, their pointers, the place of service and the rendering provider are entered when the claim is assembled and can be corrected until it is filed.
Not the first problem — every problem, split into what will be rejected and what is merely worth a look. A biller who has to resubmit four times has been failed four times.
What was transmitted is hashed into the transparency ledger before transmission. Months later, what the practice sent is provable rather than asserted.
Submission, acknowledgement, and adjudication are distinct events on a timeline, because collapsing them is how “we never heard back” becomes unanswerable.
The payer’s own trace number is the idempotency key. The same file arriving twice posts once; two different files under one reference stop and ask for a human.
The worklist opens on what is worth working, with each CARC and RARC turned into plain language — and codes the system does not recognise are labelled unknown rather than guessed at.
Three things that are always true
These are not settings. They hold for every practice on the platform, because each one is a place where getting it wrong is silent — the numbers end up wrong and nothing on any screen looks unusual afterwards.
The payer’s reassociation trace number is unique per practice and payer. A resent file is recognised as the same file; a different file under the same reference is refused rather than merged.
If what the payer paid, adjusted, and assigned to the patient does not reconcile against what was billed, the file is stored for a person to read and posted to nothing. Posting it would put wrong numbers on every claim it touched, invisibly.
A contractual adjustment is money the practice absorbs and may not bill. Patient responsibility is money the patient owes. Systems that add them together either bill a patient for money they do not owe or write off money the practice should collect.
Billing automation
The goal is to take work off a billing specialist, not to take the decision off them. Those are different, and conflating them is how a system ends up quietly upcoding on a practice's behalf — which is fraud, and the practice is liable, not the vendor.
Happens with nobody watching. Only ever things that are reversible, that assert nothing to anybody, and that a person would have done identically.
The system does the WORK and a person makes the DECISION. This is where the burden actually goes — a corrected claim assembled and waiting for one click is most of the work removed and none of the judgement.
No configuration reaches these. They are constants in the code with no setting, because each is where the failure stops being a bad claim and becomes a false one — and a false claim is a civil penalty per claim plus treble damages, owed by the practice.
Two more acts always need a person, however you configure the rest: submitting a claim, and sending an appeal. Both are assertions to an outside party, and an assertion nobody chose to make is the whole problem. A practice that genuinely wants otherwise does not want this product.
Where this stands
The clearinghouse and the payer are integrations at the boundary, which is exactly why they can land without reshaping the ledger underneath them. Until one is bound, the API answers “not configured” rather than letting a claim look like it went somewhere. We would rather say that here than let you find it out after you have filed.
Cash-only, payer-only, or the messy middle — the demo runs on whichever one you actually have.
Request a demoForged Med is billed per practice, never per claim.
