Healthcare Only Exists When Insurance Can Read It

I keep coming back to a strange fact in the a16z article about behavioral health clinics. A therapist can spend an hour with a child, the session can go well, the parents can see progress, and everyone involved can agree that the work happened. Still, from the clinic’s financial point of view, the session remains incomplete. It has to be rebuilt as a claim that an insurance company is willing and able to understand. The provider needs the correct credentials, the treatment needs the correct code, the authorization has to cover the right dates and number of units, and the documentation has to describe the session in a form that matches all of those things. Until that second version of the session passes through the insurer, the first version has produced care but may not have produced revenue.

The article presents this as a hidden mathematical problem inside behavioral healthcare. Clinics providing autism therapy often have plenty of demand, sometimes more than they can serve, but demand does not automatically create a viable business. A clinic can have full schedules and clinicians working all day while a large part of its income remains trapped in claims that need to be corrected, explained, resubmitted, or chased through an insurance portal. The service has already been delivered, the salaries and rent still have to be paid, and the insurer can take weeks or months to decide whether the administrative representation of that service is acceptable.

This is partly a story about American healthcare being unusually complicated, but I think there is something more general hidden inside it. Most of us imagine healthcare as the interaction between a patient and someone who treats them. There is another healthcare system running behind that visible one, made out of classifications, authorizations, timestamps, credentials, billing rules, and evidence. The patient may never see most of it. The clinician may experience it mainly as irritating forms and extra documentation. Yet this background system can determine whether the clinic continues to exist and whether the next patient can get an appointment.

Coming from Estonia, the scale of this secondary system still feels slightly difficult to comprehend. Estonia certainly has codes, reimbursement rules, clinical documentation, and arguments about what the national system should pay for. Healthcare never becomes administratively simple merely because the government plays a larger role. The American version, however, seems to have produced many parallel payment systems that each need to be learned almost as separate environments. A service can be clinically identical while the process required to get it paid changes according to the insurer, the state, the plan, the provider type, and apparently a collection of rules that may not even be clearly documented anywhere.

The people who understand these rules become unusually important inside a clinic. An experienced billing employee learns that one insurer tends to reject a certain combination of codes, another expects a particular document to be attached, and a third may require the same information to be entered in two different places. Some of this knowledge probably exists in manuals, but much of it seems to be accumulated through repeated failure. A claim is rejected, someone investigates why, the clinic adjusts its process, and eventually the staff member develops an intuitive understanding of how each payer behaves. When that person leaves, the clinic can lose part of the operating knowledge that allowed it to convert treatment into money.

Camber, the company featured in the a16z article, is trying to turn that knowledge into software. It connects the clinical notes, schedules, provider credentials, authorizations, claims, denials, and payments, then tries to identify problems before the claim reaches the insurer. The obvious description is that it automates revenue-cycle management with AI. That description is accurate, but it also makes the product sound smaller than it may become. Automating the forms is useful. Learning the actual behaviour of the payment system across millions of claims is potentially much more valuable.

I started thinking of Camber as a compiler for healthcare. A compiler takes something written in one language and turns it into a form that another system can execute. In this case, the original material is the work done by clinicians, together with their notes about what happened. The target system is the insurer, which only recognises that work after it has been converted into the correct combination of codes, proof, permissions, and structured fields. A rejection resembles a compilation error, although the error message may be vague and the target environment may behave differently from the documentation.

The metaphor is imperfect, because clinical care is not code and an insurer is not a neutral computer. Insurers make choices about what they will recognise, how much they will pay, and how difficult they will make the process. Still, the compiler idea helps reveal where the power accumulates. A company that sees enough claims can gradually learn which representations of care succeed, which ones fail, how long different payers take, which documentation patterns lead to requests for more information, and which claims are probably no longer worth pursuing. It can build a practical map of the payment system that may be more useful than the formal rules published by the insurers themselves.

Once software has that map, it can begin influencing the clinic before a claim is ever created. It can warn that an authorization is running out, prevent a clinician from using an incompatible code, suggest that a note is missing required evidence, or show that one insurer creates much more administrative work than another. These sound like sensible product features, and many of them probably are. A clinic should not lose money because someone selected the wrong item from a dropdown menu or because information already stored elsewhere was not copied into the expected field.

The uncomfortable part is that the same system can gradually shape the care itself. If one kind of session produces fewer payment problems, the clinic has a financial reason to provide more sessions in that form. If one documentation style is accepted more reliably, clinicians will be encouraged to write that way. If certain patients, insurers, or treatment plans are consistently difficult to reimburse, the platform can make that visible to management. The software does not have to issue a direct instruction about which patients to accept or which treatments to provide. It only needs to show which combinations allow the clinic to survive.

This is where administrative software starts to resemble policy. We normally think of healthcare policy as laws, regulations, public budgets, insurance contracts, and decisions made by people in meetings. Much of the policy experienced by a clinic may arrive through an interface. A required field can function as a rule. A validation error can block a treatment from being paid. A dropdown menu can decide which version of a complicated clinical situation is officially available. An automated rejection can have the same practical effect as a human decision, even when nobody feels personally responsible for making it.

The a16z article largely treats better billing as an obvious benefit for clinics and patients. There is truth in that. It is absurd to train clinicians and then force them to spend part of their time producing insurer-compatible paperwork. It is also absurd for a small clinic to become unstable because its most experienced billing employee resigned. If software can prevent avoidable denials and make reimbursement more predictable, it could preserve access to care that would otherwise disappear.

The article is also written by an investor in Camber and relies heavily on numbers supplied by Camber. That does not invalidate the problem, but it changes how I read the proposed solution. Better collections can keep an independent clinic alive, and they can also increase the EBITDA of a private-equity-owned network of autism treatment centres. The same infrastructure that reduces administrative waste can make clinic chains easier to scale, standardise, acquire, and manage from a distance. The money recovered from insurers may support more treatment, improve investor returns, or do both at the same time. The software itself does not resolve that tension.

There is another tension around documentation. Insurers can use administrative requirements to delay legitimate payments, but documentation also exists because healthcare systems contain mistakes, unsupported billing, and fraud. An AI system that helps a clinic submit cleaner and more accurate claims could improve both reimbursement and accountability. A system optimised mainly for getting claims through could also become very good at producing the version of reality that passes the payer’s checks. Those outcomes may overlap for a while, although they are not necessarily the same.

This is why I am less interested in whether Camber can reduce claim rework by a few percentage points than in what kind of institution it could become. If it connects enough clinics, insurers, clinical records, authorizations, and payment histories, it gains a view of healthcare that none of the individual clinics possess. It can see how care is translated into money across the system. It can identify where revenue disappears, which payer rules are changing, and which operational behaviours produce the most reliable payments. At some point, the company is no longer merely helping clinics navigate the system. It becomes part of the infrastructure through which the system is understood.

There seems to be a wider pattern here. AI companies often enter through repetitive administrative work because the pain is obvious and the buyer can calculate the savings. Once the software is connected to enough workflows, it starts learning the unwritten rules of the institution. The useful product may begin as document automation, while the deeper asset becomes a model of how decisions are actually made. In healthcare, that means learning the difference between care that occurred, care that was documented, care that was authorised, and care that eventually became payable.

I am not sure these differences can or should disappear completely. Any system distributing limited money needs definitions and evidence. Estonia’s national health system also has to decide what it funds, which treatments have sufficient evidence, and how providers demonstrate that services were delivered. The strange part in the American case is how much of that decision-making seems to have migrated into fragmented administrative machinery. The rules are distributed across insurers, contracts, portals, code combinations, and the accumulated memories of billing employees. Camber’s opportunity exists because the system has become too complicated for the people inside it to understand consistently.

Perhaps the real product is a clearer interface to that complexity. Perhaps it is a new private layer that becomes powerful precisely because the public and insurance systems underneath remain unreadable. Both can be true. The clinics may genuinely need it, the patients may benefit from it, and the existence of the opportunity may still reveal something deeply broken about how care becomes economically real.

The therapist and the child remain at the centre of the visible story. Somewhere behind them, another system is deciding whether it can read what happened.

Connected reading

• The Product Happens Between the Screens
• Estonia Has the Health Record. It Needs More Measurements.
• The Report Is a Form
• The Problems Companies Admit They Have

AI authorship note

This essay began with Kris Haamer reading an a16z article about the hidden economics of behavioral health claims and asking for the Raw Drafts angle. Kris connected the billing problem to interaction design, Estonia’s national health system, administrative software as policy, and the idea of Camber as a compiler that translates care into something an insurer can execute. AI helped research the claims, challenge the portfolio-company narrative, develop the argument, edit the article and prepare the Raw Drafts publishing files. Kris supplied the original questions, personal perspective, framing, voice and final editorial direction.