A behavioral health practice that is losing money between the referral call and the paid claim usually reaches for one of two answers. Replace the EHR with something newer, or buy another tool to cover what the EHR does not. Both answers start from a feature gap, and neither starts from the thing that actually leaks: facts that exist in one place and are needed in another.

We argued in Behavioral Health EHR Problems Are Probably Not What You Think that a new EHR is rarely the answer. This piece goes one step further and says what to do instead: choose, and connect, the software around the EHR by the five facts that must cross its boundary.

The EHR is the clinical record. Keep it that way.

The EHR holds the chart: assessments, notes, treatment plans, medication, orders. It is built around clinical documentation and the regulatory requirements attached to it, and replacing it is a large, slow and risky project. A practice that has an EHR its clinicians can work in has solved the hardest part of the stack.

What the EHR is usually weak at is everything around the chart. The referral that arrives by phone, fax and web form. The insurance verification before the first visit. The reminder that stops the no-show. The authorization that has to be renewed in week six. The reconciliation of what was done with what was billed. These are business records, not clinical ones, and they are where revenue leaks.

The temptation is to buy software for each, and the risk is that each new tool becomes another place where a fact is stored and nobody owns it.

Five facts that cross the boundary.

A way to keep this under control is to list the facts that have to be right on both sides of the EHR boundary. There are five, and everything else in the surrounding software is a means of keeping them so.

The referral. Who referred the person, when, how, and what stage the referral has reached. It begins outside the EHR and must arrive in it. Direction: into the EHR. Owner: whoever runs admissions. Delay: same day, because a referral that waits is a referral that goes elsewhere.

The authorization. Whether the payer has verified coverage and authorised the level of care, for how many visits, until when. It begins with the payer and must be visible to scheduling and clinical staff before the visit. Direction: into the EHR and the schedule. Owner: the verification role. Delay: before the first appointment is booked, and again before each renewal date.

The schedule and attendance. Who is booked, who attended, who no-showed, who was cancelled. It lives in whichever system schedules and must be known to billing. Direction: both ways, with one system owning the appointment. Owner: front desk. Delay: end of day.

The claim. What was submitted, what was paid, what was denied and why. It begins in billing and must reach the people who can fix the cause upstream. Direction: out of billing to the intake and clinical teams. Owner: billing. Delay: weekly for the pattern, same day for a denial.

The outcome. Discharge status, outcome measures, whether the person returned. It begins in the EHR and is wanted by the practice's reporting and by payers. Direction: out of the EHR. Owner: the clinical lead. Delay: at discharge.

How to use the list.

For each of the five, write three things. Which system owns the fact. In which direction it moves. How long it can take. That is a table of fifteen cells, and every blank cell is a leak you can name.

Then, and only then, look at software. The question for any tool is not which features it has but which of the five facts it moves and whether it meets the direction, owner and delay in that row. A tool that moves the referral into the EHR the same day and shows the status to admissions is doing a job. A tool with an impressive dashboard that holds its own copy of the schedule is making the sixth place a fact can be wrong.

The pattern behind the leak is described in claim denials start at intake: by the time the claim is denied, the cause is a missing field or an unverified authorisation from days earlier. The five facts are the fields that matter, and the video Verified Before Scheduled shows what happens when the second one is skipped.

One referral, traced.

A person is referred by a primary care office on a Tuesday afternoon, by phone. The intake coordinator writes it on a note, enters it into the EHR on Wednesday morning, and calls the person on Thursday. The insurance is verified on Friday, and the first appointment is offered the following Wednesday. Eight days from referral to first visit, and the referring office has heard nothing.

Look at the five facts. The referral reached the EHR a day late and with no source recorded. The authorization was checked after the appointment was discussed, not before. The schedule was set by a person reading a calendar. Nothing here is a software failure. Each of the delays is a fact moving by hand, with no owner or clock.

With the specification in place, the same referral enters on Tuesday, carries its source and a status, triggers the verification the same day and shows admissions that the clock is running. The first visit is offered within two or three days. The practice has the same EHR and the same staff.

A word on privacy.

Every one of these facts is health information, and substance use treatment records carry additional consent rules. The design principle is minimum necessary: each tool receives only the facts it needs for its job, and the list above makes that decision visible, since each row says who needs what. Any connection should be designed with your compliance officer or counsel in the room, and we say that as a matter of practice, not as a disclaimer.

What it looks like when it works.

The referral appears in the EHR the day it arrives, with its source and a clock. The authorization is checked before the first appointment is offered and again two weeks before it expires. A no-show triggers a follow-up the same afternoon. A denied claim goes to the intake lead with the field that caused it. A discharge produces an outcome record without anyone retyping it.

None of that replaces the EHR. All of it makes the EHR's data arrive on time and correct, which is what the clinicians wanted and the billing team needed.

Where we come in.

We connect the tools around an EHR so the five facts move with an owner, a direction and a delay, and we leave the clinical record where it is. Discovery is no-risk: we trace one month of referrals through to paid claims against the five facts and show where each leaked, and you pay only if you go ahead. The build carries a guaranteed estimate, so if we estimate low, we absorb the difference.

The question is not which software to add to a practice. It is which facts must never be wrong in two places, and who answers when they are.

Find out where intake, clinical records and billing fall between your systems.

In a no-risk discovery we look at how a patient moves from intake to billing across your systems today and show what one connected system would change. You pay only if you proceed. Or see how we approach it.

Book the no-risk discovery

More on the same problem:

Where we're not the right answer

We'll tell you if we're a fit. If we're not, we'll tell you that too.

  • Your current stack works and nobody wants to change it
  • You want licences resold at a discount and nothing else
  • Your internal team owns the operating model and is not handing it over
  • You want hours of configuration work and nothing run for you: that is on our services pages, and it is not a managed solution
How we start

Most of our best clients come to us with a feeling, not a plan.

"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.

Talk to us

Have a question about this?

Say who you are and ask. A person replies within one business day.

A new client, or thinking about becoming one
What are you looking for?
An agentic solution (AI OS) is licensed and sold with managed services. An integrated solution is built for a professional services fee. A Service is professional work, done by the hour, the month or the project. Not sure yet is a fine answer.

Agentic solutions (AI OS)

Integrated solutions

Services

Platforms You Use or Are Considering

Your details are never shared or sold.