Behavioral Health Facility Software: Census, Authorizations, and When to Stop Bending Kipu
If you run one site under about 40 beds with three payers and one level of care, stay on Kipu or Alleva and hire a better UR nurse. If you run multiple locations, multiple licenses and more than six payers, build the system of action on top of your EHR rather than replacing it: a focused first release covering the bed board, the authorization ledger and admissions typically runs $60k to $130k and ships in 12 to 16 weeks; a full multi-entity platform with payer integrations, Part 2 segmentation and analytics runs $150k to $400k phased over 6 to 12 months. The math usually clears in one quarter of recovered authorization days.
Why census and authorization software decides your revenue
Monday, 7:30am. A 96 bed operator with a detox unit, two residential houses and a PHP/IOP building runs its census huddle. The clinical director reads bed counts off a dry erase board. The admissions director reads a different number off Kipu CRM (Customer Relationship Management), because two of last night's admits are still sitting in "pending" while somebody waits on a callback from Carelon. The biller reads a third number off a spreadsheet she exported Friday afternoon. Nobody in that room can say, with confidence, how many beds are open tonight or how many of the clients in them are still authorized.
That gap is the P&L, not a reporting annoyance. Run the arithmetic on your own per diem. If residential bills at $900 a day and eight clients a month drift two days past an expired authorization before anyone catches it, that is $14,400 written off every month, and the clinical work was already delivered. Then add the beds you left empty because the census number was stale and an admissions coordinator turned away a referral you actually had room for. Most operators cannot even measure that second number, which is precisely why it keeps happening.
The tools are not missing. Kipu, Sunwave, Alleva, Ritten, BestNotes, Lightning Step, Netsmart myAvatar and Qualifacts CareLogic are all in this market, and you are almost certainly running one of them. They are just built to be a chart for a generic clinic, then bent into shape with Excel, a whiteboard, a Slack channel called #census, and a utilization review nurse whose real job description is "person who remembers things."
Problem: your census lives in four places and none of them agree
A client leaves against medical advice at 2:10am. The behavioral health tech writes it in the paper shift log. The counselor finalizes the discharge in the EMR on Thursday, because that is when he has chart time. For roughly 48 hours, that bed shows occupied. Your admissions rep, looking at the same system, turns away two referrals. On a bed you already staffed, that is real money that never appears in any report because the loss is invisible by construction.
Off-the-shelf tools cannot fix this because their census view is a report over the chart, and the chart is a clinical artifact updated on clinical timelines. There is no concept of a bed as a resource with a real state machine. There is no hold with an expiry, no pending-admit, no gender or acuity or level-of-care constraint on which bed a specific referral can actually occupy, and no honest cross-entity view when you operate four licenses under three tax IDs. Kipu will show you occupancy per facility. It will not tell you that the male detox bed opening Thursday at your Delray house should be held for the referral your Boca rep is working, because the referral lives in the CRM and the bed lives in the EMR.
A custom build makes the bed a first-class object with states: clean, occupied, hold with a countdown, pending admit, out of service for maintenance. State changes come from the moment they happen, not from chart closure, so the tech taps "client left" on a tablet at 2:10am and the board updates at 2:11am. One board spans every license and every entity. A hold auto-releases after four hours and pings admissions in Slack. Then forecasting starts paying: model projected discharge from level of care, authorization end date and ASAM dimension trend, so on Wednesday you know what Saturday looks like and you staff and market to it instead of reacting.
Problem: authorizations expire while your UR nurse is on hold
Your UR nurse is carrying roughly 60 concurrent reviews across eight payers. Aetna wants concurrent review on a different cadence than Carelon, one Medicaid managed care plan insists on a doctor-to-doctor by phone, and a commercial plan on a single case agreement has its own rules entirely. She tracks all of it in a spreadsheet, yellow at two days out, red at one. She gets the flu on a Thursday. Three authorizations lapse and you find out from the denial.
The UR module in most behavioral health EHRs is a text box and a date field. It does not know each payer's review cadence per level of care, who the last reviewer was, what evidence that reviewer accepted last time, or how many units remain. Avea and Kipu's utilization review tooling records that a review happened. Neither tells you that you are 36 hours from losing a bed's revenue. And there is no clean authorization-status API across behavioral health payers, so the work is a human with Availity and six portals open in tabs.
What we build instead is an authorization ledger: every authorization as a real record with payer, plan, level of care, units approved, start, end, reviewer, next review due, and the evidence packet attached. Rules configured per payer per level of care. An escalation clock that does not depend on anyone's memory: 72 hours out it creates a task, 48 hours out it texts the UR nurse, 24 hours out it texts the clinical director. When she is out sick, it is a queue somebody else can work, not a spreadsheet on her laptop.
This is where AI actually pays. The concurrent review packet is the bottleneck, and it is a document extraction problem, not a judgment problem. Pull the last 72 hours of nursing notes, group notes, vitals, and drug screen results, and draft the ASAM dimension by dimension narrative with a citation back to the source note for every claim. The nurse reads, edits, signs, submits. We have watched that turn a 40 minute packet into an 8 minute review. The guardrail is not optional: the model drafts, a licensed human signs, and nothing auto-submits to a payer.
Problem: treatment plans that satisfy the surveyor and fail the payer
Joint Commission and CARF want plans that are individualized, measurable and updated. The payer wants medical necessity evidenced continuously. What actually happens: a counselor duplicates the last client's plan, swaps the name, picks three goals from a dropdown. Group notes read "client participated in group, affect appropriate." Then a payer denies day 12 of residential because nothing in the record explains why this client cannot step down to PHP, and you spend four months on appeal for care you already delivered.
Templates in off-the-shelf systems are static libraries. There is no link between the problem, the goal, the objective, the intervention, the note that evidences it, and the authorization that pays for it. The golden thread is taught as a training concept in your onboarding deck. It is not a data structure anywhere in your software, so nothing can enforce it or measure it.
Make it a data structure. A note attaches to an objective, not to a date. An objective rolls up to a goal, a goal to a problem, and each authorization review pulls its evidence from that chain. Now you can run the query that matters: show me every client whose last five notes contain zero evidence for the dimension this payer denied on last time. You catch it on day three, not on appeal. Layer AI on top for the counselor's benefit, not the auditor's: as the note is written, flag that it does not support Dimension 5 relapse potential and that this payer denied on Dimension 5 for a similar plan last month. Flag notes that are more than 85% identical to another client's note, before a surveyor finds them.
Problem: the 2am call goes to voicemail and the bed stays empty
Families call when the crisis happens, which is nights and weekends, not Tuesday at 2pm. Your answering service takes a name and a number. It cannot verify benefits, it does not know whether you have a male detox bed, and it certainly cannot hold one. By the time your admissions director calls back at 9:40am, the family has called three other facilities and the person is in someone else's bed. You paid the marketing cost and got nothing.
Kipu CRM and Salesforce are pipeline trackers. They are where a lead goes after a human has already caught it. Verification of benefits is a person logging into Availity and a stack of payer portals and typing. No off-the-shelf behavioral health tool closes the gap between the ringing phone at 11pm and a held bed.
An after-hours intake agent does: answer, run a structured intake (substance, last use, prior treatment, legal, insurance), text a link for a photo of the insurance card, OCR the member ID, run the eligibility check, read the live bed board, and either place a real hold and book an 8am admit or route immediately to the on-call clinician. The benefits summary is sitting in the CRM before your admissions director's alarm goes off. The guardrails are hard rules in the build: the agent never gives clinical advice, never states coverage as final, and any withdrawal or suicidality signal transfers to a human on the first mention. Measure one number, time from first contact to bed hold. In the builds we have shipped it goes from most of a night down to the length of one call.
Problem: 42 CFR Part 2 turns every integration into a legal question
Substance use disorder records are not ordinary HIPAA records. Disclosure is consent-based, redisclosure is restricted, and that changes what your software is allowed to do. So when you want to send a discharge summary to the referring hospital, or share data with the recovery residence you own but which is a separate legal entity, or feed a BI (Business Intelligence) dashboard, the honest answer from your compliance officer is usually no. The practical answer from your team is a fax machine, or a shared Google Drive folder that nobody has told the compliance officer about.
In most EHRs, consent is a scanned PDF attached to a chart. That is a document, and a document cannot enforce anything. Nothing in the system prevents a report from including a protected client, because the system does not know what the consent says.
Build consent as a live object: who, which data classes, what purpose, expiry date, revocable. Every outbound path, every report, every integration checks it at query time and fails closed. Segment the data so your analytics layer gets census, length of stay and revenue without protected clinical detail, which is what your board actually wants anyway. Then keep an audit log that answers "who saw this record, when, and under what consent" in a single query, because that is the exact question a surveyor asks, and the exact question a plaintiff's attorney asks later.
What this costs and how long it takes
These are Digital Heroes delivery bands from more than 2,000 projects, not a market survey. A focused first release, meaning the live bed board across all your entities, the authorization ledger with escalation, and admissions capture wired to your existing EHR, typically lands at $60k to $130k and ships in 12 to 16 weeks. A full platform with payer portal integrations, Part 2 consent enforcement, clinical documentation intelligence, state reporting and analytics runs $150k to $400k, phased over 6 to 12 months, and should go live in pieces rather than in one terrifying weekend.
What drives price up in this category specifically: the number of payers, because each one has its own review cadence, packet format and portal, and going from three payers to fourteen is not a linear cost. Migration out of Kipu, because the export is not a friendly API and clinical history carries retention obligations you cannot shortcut. Multi-entity structure, where four licenses under three tax IDs with separate NPIs means the permission model is real work, not a checkbox. Part 2 segmentation across every downstream system. E-prescribing and lab interfaces through Surescripts, DrFirst, Quest or LabCorp. State reporting to bodies like Florida DCF or California DHCS. And 24/7 uptime, because a nurse needs the medication administration record at 3am and "we deploy on Fridays" is not a plan.
What is comparatively cheap: the bed board, the authorization ledger, the referral pipeline, the analytics. What is expensive and rarely worth it: rebuilding the clinical chart itself.
Build vs buy: when Kipu is the right answer
If you run a single site under about 40 beds, one or two levels of care, and three payers, buy the subscription. Kipu, Alleva or Ritten will hold your chart, your notes and your billing well enough, and every dollar you would spend on engineering is better spent on a strong UR nurse and an admissions rep who answers the phone. Off-the-shelf is right when your workflow is standard and your volume does not fund software. Do not build. Close this tab.
The signals that it is time to build are concrete. You have more than one full-time person whose actual job is moving data between systems. Your census, your CRM and your billing disagree, and reconciling them is a recurring meeting on the calendar. You bought a second and third facility and discovered the EHR thinks per facility while you now think per organization. Your write-offs to authorization lapses and timely filing are big enough that they have their own line in the monthly review. Your competitive advantage is a workflow, say you can take a detox admit in 90 minutes, and the software is what slows it down. Or the vendor's answer to your single biggest request has been "next quarter" for four quarters.
Here is the position: for almost every multi-location operator, the right move is not ripping out Kipu. It is keeping the EHR as the system of record for the chart, and building the system of action on top of it: the bed board, the authorization ledger, admissions, consent enforcement, and analytics, integrated to the EHR and owned by you. It is cheaper, it ships in months instead of years, it does not put your next survey at risk, and it puts the part of your operation that actually differentiates you under your own control.
How to choose a developer for behavioral health facility software
Make them model the domain on a whiteboard before you sign anything. Ask them to draw ASAM level of care transitions, the difference between a hold and an occupied bed, an authorization with units and a concurrent review cadence, and a Part 2 consent. If what appears on the board is "patients" and "appointments," they build clinics. You run a facility. That is a different machine and you will pay for the education.
Ask what they have shipped against a payer portal that has no API. The right answer includes sanctioned integration where it exists, and where it does not, an honest conversation about automation on portals, how it breaks when the portal changes, and how they monitor for that. If someone promises clean authorization status across all fourteen of your payers, they have never done this.
Ask them to explain 42 CFR Part 2 without searching for it, specifically how it differs from HIPAA and what it does to your data warehouse. Then ask who on their team has signed a business associate agreement, where the data will be hosted, and how audit logging works. A vendor who treats this as a legal formality to sort out later will hand you an architecture you have to pay to rebuild.
Get migration and ownership into the contract, not the kickoff deck. Name the export format, the number of years of history, and what happens to the historical chart under your retention obligations. And the code lives in your repository, in your cloud account, with your name on the infrastructure, from day one. If a developer hesitates on that point, you already have your answer.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- ITIF's 2025 report documents that SMEs operate at roughly 60% of large-firm productivity in advanced economies (citing McKinsey), that CRM platforms deliver a 25-40% improvement in customer retention and a 15-30% boost in sales, and that digital advertising returns about $8 in profit per dollar spent on Google Search and Ads. Source: Information Technology and Innovation Foundation (ITIF) (2025) →
- McKinsey's Developer Velocity research finds best-in-class tools are the top contributor to software business success, yet only about 5% of executives ranked tools among their top-three software enablers, signaling underinvestment in developer tools (this finding originates in McKinsey's Developer Velocity study rather than the linked generative-AI article). Source: McKinsey & Company (2023) →
- Sensor Tower's State of Mobile 2026 reports that global users spent 5.3 trillion hours in iOS and Google Play apps in 2025 (+3.8% YoY), roughly 3.6 hours per day per mobile user. (Note: the page does not itself contrast app time vs. mobile-browser time, so the 'overwhelming majority of time in apps vs browsers' framing is not directly supported by this source.). Source: Sensor Tower (2026) →
- The global point-of-sale terminal market is projected to reach approximately $181.47 billion by 2030, growing at an 8.1% CAGR from 2025 to 2030, driven by digital payment adoption and demand across retail, restaurant, and hospitality sectors. Source: Grand View Research (2025) →
Rohan advises mid-market and enterprise teams on ERP, CRM and custom software, and has led delivery on dozens of business-software builds.
Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.