What Even Is RCM? An engineer's map to how healthcare actually gets paid

The first time someone drew the revenue cycle on a whiteboard for me, it looked like a conspiracy board. ICD codes, CPT codes, clearinghouse, CMS-1500, EOB, payer, self-funded plan, out-of-network, post-adjudication. Arrows shooting everywhere, all pointing at one bewildered question in the middle: RCM?

If you've ever felt like you needed a detective's corkboard and a ball of red string to follow it, this one's for you. That was me, not long ago. So this is the explanation I wish someone had given me.

One thing up front, so you know where I'm standing: I come at this from the technical side, not the billing office. What I care about are the systems underneath the revenue cycle: the data, the integrations, the software. So if you're an engineer, a CTO, or anyone responsible for the tech that healthcare runs on, this is written for you, through that lens. And honestly, that's where a lot of the real problems live.

And maybe you’re wondering why someone on the engineering side cares this much about how healthcare gets paid. Fair question. RCM is the part of building healthcare software that nobody hands you a manual for.  You can’t really grasp it from the outside looking in. So I had to learn about it in practice, from first principles. Consider this the map I drew for myself along the way.

By the end you won't be an expert. But the conspiracy board will start to look like a flowchart. That's the goal.

Table of Contents

1. What RCM actually is (in one breath)
2. How I learned it: follow one patient
3. How RCM actually gets implemented
4. The whole point

What RCM actually is (in one breath)

Here's the simplest definition I've landed on: revenue cycle management is everything that has to happen for a healthcare organization to get paid for the care it provides.

That's it. It actually starts before the patient is ever seen, at scheduling and pre-registration (the moment you check whether their insurance is active and will cover the visit), and ends when the bill is fully paid and the books are closed. Everything in between (verifying eligibility, documenting the visit, coding it, sending a claim, getting paid, handling what the patient owes) is the revenue cycle.

When I first heard "revenue cycle," I pictured an invoice. That's wrong, and the word that fixed it for me was cycle. It's not a single bill. It's a loop with a dozen handoffs, and money can leak at every one of them. Understanding RCM means understanding the handoffs, not the invoice.

How I learned it: follow one patient

The thing that finally made RCM click for me wasn't a diagram. It was walking through a single patient's journey and asking, at each step, "where does the money come from, and what could go wrong here?"

It goes roughly like this:

A patient books a visit. Right away, someone needs to confirm their insurance is active and covers what they're coming in for (that's eligibility) Then they show up, and their details get registered: name, date of birth, insurance ID, all of it. The clinician sees them and documents what happened. That documentation gets translated into standardized codes that describe the diagnosis and the services performed (that's coding). Those codes become a claim, which is sent to the insurance company (that's the claim). The insurer reviews it and either pays, pays part of it, or denies it. Whatever the patient still owes after that (their deductible, copay, or coinsurance) becomes a bill sent to them (that's patient collections). Eventually -hopefully- everything gets paid and reconciled.

Once I could narrate that out loud, the jargon stopped being scary. Eligibility, coding, claims, denials, patient collections: they're just names for stops along that one journey. If you can follow one patient from booking to paid, you understand RCM.

But here's the important caveat: that's the abstraction, the north star, the version that fits on a whiteboard. Every one of those stops gets messy the moment you actually build it. Different clearinghouses behave differently. Every insurer names things its own way and returns different details about a plan. Integrations vary wildly: some are clean APIs, some are batch files, some still happen over the phone. And all of it shifts depending on the domain you're in, on two axes at once. The kind of payer: an employer-sponsored plan, Medicaid, Medicare Advantage, and a cash-pay clinic each play by different rules. And the kind of care: nutrition, dental, oncology, and mental health each have their own codes, coverage quirks, and billing realities. The revenue cycle for a therapy practice looks nothing like the one for an oncology center. So the map stays simple, but the terrain doesn't. That gap is exactly why RCM is hard, and why it takes both halves to do well: a clear picture of what you're trying to achieve, and the technical expertise to make it work against the messy, inconsistent systems on the other end. Hold onto that idea, because it's the theme of everything that follows.

How RCM actually gets implemented

This is where people expect a single product, and there isn't one. In practice, RCM is implemented as a chain of connected systems and workflows, and the implementation work is mostly about making sure each stop in that patient journey is handled well and hands off cleanly to the next.

When I think about implementing RCM, I think about getting a few things right:

The front end has to capture clean information and verify insurance in real time, ideally the moment the appointment is booked, not days later. This is the least glamorous part and the most important, because mistakes here turn into denied claims later.

The middle has to turn care into accurate claims: solid clinical documentation, correct coding, and a step that "scrubs" each claim against the insurer's rules before it goes out, so it's right the first time.

The back end has to handle what comes back: posting payments, catching underpayments, working denials, and managing the part the patient owes in a way that's actually easy for them to pay.

And underneath all of it, there has to be a data layer that ties the steps together so you can see where things are breaking. The hardest part of implementation is rarely any single step. It's the connections between them. When the systems don't share information cleanly, errors pile up at the handoffs, and that's where most of the money is lost.

If you take one thing from this section: the hard part of RCM isn't any single step. It's the connections between them. Get the integration and the data clean, and most of the rest follows.

The whole point

Strip away the acronyms and it comes down to one thing: building the full story. Taking a single patient's journey (booked, verified, seen, coded, claimed, paid) and mapping it cleanly across every system it passes through, so it holds together end to end.

And once that story exists (clean, connected, end to end), imagine what AI can do on top of it: interpreting eligibility responses in plain language, checking every claim against payer rules before it goes out, reading denials and telling you exactly why they happened. The catch is that AI can only make sense of a story that's actually been written down. So you build the full story first; the clever part comes after.

And building that story, one system, one seam, one hard-won lesson at a time, is exactly what the rest of this series is about.