Behavioral health authorization, end to end — answered.

Continued-stay reviews that don't defend the level of care. Across PHP, IOP, residential, and detox, the dominant ongoing source of lost revenue isn't coding or timely filing — it's authorized days cut mid-stay because the documentation didn't justify continued intensity. Initial denials and retrospective clawbacks are real, but concurrent review is the bleeding artery: it happens every 3–7 days per patient, every patient, every payer.

A concurrent (or continued-stay) review is the payer's periodic re-check — typically every 3–7 days in PHP and residential, every 1–2 weeks in IOP — to decide whether the current authorization should continue. The payer's utilization reviewer pulls recent progress notes, assessments, and treatment-plan updates, and asks: do these still justify the intensity the patient is being billed at? If the documentation is weak or scattered, the authorization gets cut effective immediately, and every day billed after that cut is denied. This is where the daily blood is.

It means the payer's reviewer can read the documentation and agree that (1) the patient's current symptoms, risks, and impairments justify this intensity of care, (2) the patient is responding to treatment but is not yet stable enough to step down, and (3) a lower level of care would be clinically unsafe today. The same standard applies at initial authorization, at every concurrent review, and again during retrospective audit. Vague or templated language fails all three tests.

ASAM Criteria (from the American Society of Addiction Medicine) is the dominant standardized framework commercial and Medicaid payers use to decide whether substance-use level of care is justified. It evaluates patients across six “dimensions” — acute intoxication/withdrawal, biomedical, emotional/behavioral/cognitive, readiness to change, relapse/continued use potential, and recovery environment. For SUD programs (detox, residential, PHP, IOP), nearly every denial letter cites a specific ASAM dimension that the notes failed to support. Documenting in ASAM's language — per dimension, with specificity — is the single highest-leverage documentation change an SUD program can make.

LOCUS (Level of Care Utilization System) and its pediatric counterpart CALOCUS are the mental-health equivalents of ASAM. They're used by commercial and Medicaid payers to decide medical necessity for mental-health PHP, IOP, and higher levels of care. Where ASAM rates six SUD-focused dimensions, LOCUS scores six mental-health risk dimensions to produce a composite level-of-care recommendation. Mixed dual-diagnosis programs typically see both cited in denial letters depending on the primary presenting concern.

MCG Health (formerly Milliman Care Guidelines) is a proprietary medical-necessity criteria set licensed by many commercial payers — especially Optum/UHC — as their internal LOC standard. For behavioral health, MCG's criteria run parallel to ASAM and LOCUS but with payer-specific weighting. A program working with Optum needs to document toward MCG; the same program working with Aetna may need to document toward Cigna's preferred ASAM/LOCUS framing. Per-payer criteria mapping is one of the things Lucida's concurrent-review pillar handles for you.

A retrospective clawback (or “recoupment”) is when a payer audits already-paid claims, decides the documentation doesn't support what was billed, and recovers the money — often 12 to 24 months after the service, occasionally longer under Medicaid RAC programs. Triggers include length-of-stay outliers, high-volume billing, overlapping level-of-care billing, and random sampling. For a mid-sized program, a single retrospective audit can pull back six figures. We surface at-risk claims before the auditor arrives.

Under most commercial payers' PHP definitions (and Medicare's PHP rules), a patient must receive at least 20 hours per week of therapeutic services to qualify for PHP-level billing. Miss that threshold — through absences, holidays, discharges, or programming gaps — and the payer may deny the entire week of PHP claims, not just the missed day. Programs with loose attendance tracking routinely bleed revenue here without knowing.

Payer utilization reviewers and RAC auditors flag a note as “templated” when its language matches prior notes too closely — the same phrases, the same observations, the same clinical impressions with only the date changed. Templated language is one of the single fastest signals auditors use to designate claims for clawback, because it implies the clinician didn't individually assess the patient that day. It doesn't matter if the care was actually delivered; if the note doesn't read as individualized, the claim is at risk.

Three changes consistently move the needle. (1) Every daily note cites an objective measure — PHQ-9, GAD-7, ASAM dimension scores, or equivalent — so intensity is quantified, not asserted. (2) Every note includes an explicit step-down rationale: one sentence that answers “why can this patient not safely step down today?” (3) Every note reflects individualized clinical status — specific behavioral observations, specific clinical reasoning — not templated language. Programs that implement all three see concurrent-review pass rates move from coin-flip to near-ceiling.

Eligibility verification at intake should answer four questions before services begin: (1) is the patient's coverage active for behavioral health, (2) does the plan cover the specific level of care being admitted to (PHP / IOP / residential / detox), (3) what are the deductible and out-of-pocket numbers the patient will owe, and (4) does the payer require prior authorization for this LOC. Most programs do (1) and (3) reliably and lose money on (2) and (4). We connect eligibility-verification automation into the admissions workflow so all four are captured every time.

PA requirement depends on three variables: the payer, the patient's specific plan, and the level of care being admitted to. There's no single universal answer. We maintain a per-payer, per-LOC PA-requirement matrix that the admissions workflow checks automatically — and where the plan-level detail isn't available via API, we route the check through the payer portal (or a phone-call workflow) before services start. The output is a clear yes/no/check-required signal to admissions, with the supporting documentation expectations attached.

The five most common failure modes: (1) admitting before PA is confirmed, (2) capturing diagnosis and ASAM-dimension detail too thin to defend the initial auth, (3) running eligibility for medical benefits but missing the behavioral-health carve-out, (4) using stale plan-level rules that have since changed, and (5) losing the eligibility/PA context between admissions and UR. Fixing the front door is the highest-leverage authorization work most programs aren't doing.

Yes — that's a core part of pillar 2. We attach the eligibility result, PA status, plan-level rules, and initial documentation captured at admissions to the patient's chart in a structured form that the UR team picks up at their first review. No re-typing, no lost context, no day-one auth surprises. The mechanism depends on your EHR and CRM; we build it inside whatever you already use.

Each payer makes independent decisions about which criteria set to use (ASAM vs LOCUS vs MCG vs proprietary), how often to require concurrent review, what supporting documentation they want, what submission channel they accept (portal / fax / phone), and what their reviewers actually weight in their decisions. Aetna isn't Cigna isn't Optum isn't Magellan isn't your state Medicaid MCO. Programs that treat them all the same lose authorized days they should have kept.

We start with payer-mix analysis on your actual book of business — which payers drive volume, which drive denials, where the workflow effort and revenue leakage are concentrated. For each high-leverage payer, we build a workflow playbook: what admissions must capture, when UR submits, what documentation is included, which portal/channel is used, what review cadence to expect, and what the typical denial language looks like (so we know what evidence overturns it). Then we operationalize the playbook inside your existing systems.

Yes — and the variance across state Medicaid programs and the MCOs that administer them is one of the harder parts of the work. We treat each state Medicaid and each MCO as a distinct payer with its own playbook. Programs operating across multiple states get a per-state workflow map; single-state programs get deep specialization on their MCOs. We surface the state-specific coverage rules that drive denial patterns.

Payers update PA requirements, criteria emphasis, and submission rules on their own schedules — sometimes quietly. We monitor changes through the engagement and update your playbooks when they change. Quarterly payer-mix reviews are part of the standard service; in-flight changes are pushed as they're detected.

Both — and on purpose. We're a service + software hybrid. We diagnose your authorization workflows, design payer-specific playbooks, and build the AI and integration layer that runs them — and then a UR-experienced advisor sits with your team weekly to operate alongside you. The software without the service is a dashboard. The service without the software is a consultant. Higher-acuity behavioral health authorization needs both.

Lucida runs inside the EHR, CRM, billing, and payer portals your program already uses. Where APIs exist — Kipu, Valant, Alleva, Sunwave, TherapyNotes, SimplePractice, Availity — we connect read-only. Where APIs don't (most payer portals, some legacy billing systems), we build middleware and secure browser-based automation. We do not rip and replace any system, ever. Your clinicians and admissions team keep every interface they already know.

No. Every integration we build is one-way for clinical content: we read notes, assessments, and treatment plans from the EHR. We do not push content back into the clinical chart, do not modify clinical documentation, and do not alter any record of care. This is a deliberate architectural choice — it keeps Lucida out of your clinicians' workflow and keeps your clinical record of truth intact.

No. The AI surfaces evidence that already exists in the chart and drafts payer-ready narrative language based on that evidence. When evidence is thin or missing, we flag the gap rather than fabricate. Final submissions go through your UR team's review — we support clinical judgment, we don't replace it.

No, and we don't recommend it. The system handles the volume work — reading every chart, surfacing evidence, drafting narratives, tracking cadence — that no human team can do at scale. The clinical judgment in appeals, payer negotiations, and complex concurrent-review prep stays with your UR team. Most programs report their UR nurses go from assembling packets all week to actually defending authorizations.

Primary EHR integrations: Kipu, Valant, Alleva, Sunwave, TherapyNotes, SimplePractice. Clearinghouse: Availity. Common billing platforms: CollaborateMD, Kareo. Payer portals are handled via secure browser automation. If your program runs on a system we don't list, we've almost always been able to build a connector or a workflow around it — the answer is rarely “no,” it's usually “here's how.” We confirm the integration path before you commit.

Yes. For programs that still run on paper or scanned-PDF charts, we accept secure uploads and ingest them via OCR + parsing. The concurrent-review and MN-scoring quality is equivalent to digital EHR ingestion. The caveat is timing — paper workflows score at the batch or weekly level rather than in real time.

The diagnose phase (workflow audit + payer-mix analysis + sample concurrent-review review) is typically 2–3 weeks. The build phase depends on integration scope: programs on Kipu with 3–5 payers are often live with the first workflows in 4–6 weeks; more complex stacks or larger payer mixes take longer. We don't bill implementation time during the design-partner engagement.

Yes. Lucida operates as a business associate under HIPAA when we touch PHI. A BAA is available on request and is required before any paid engagement. All data is encrypted in transit (TLS 1.3) and at rest (AES-256), access is role-based and logged, and our policies align with the 2026 HIPAA Security Rule updates that make encryption mandatory rather than “addressable.” Full details on the security page.

Payer-portal automations are scoped to least privilege, run with credentials the customer controls and can revoke at any time, log every action for audit, and never store payer credentials in clear text. We document each automation down to the workflow step and review the access pattern with your security and compliance team before turning it on. Where a payer's terms of service constrain automation, we route the workflow through human-in-the-loop rather than fight the policy.

Yes — if you request one in the assessment or demo form, we send a BAA before you transmit anything. For the free Authorization Defense Assessment we prefer de-identified samples; if your workflow makes de-identification burdensome, we BAA first. For paid engagements, a BAA is always executed before production data flows.

No, not without your explicit written consent. Customer notes, even de-identified, are never used to train or fine-tune our models by default. Concurrent-review evidence surfacing runs against a fixed model plus your program's payer-criteria library — nothing persists into training pipelines. Design partners who want to opt in to model improvement do so under a separate written agreement with specific data-use terms.

Not yet. SOC 2 Type I is targeted for Q3 2026; Type II follows 12 months of operational history. Until SOC 2 is complete we publish our security controls in detail, answer customer security questionnaires directly, and welcome customer-led security reviews. For programs that need SOC 2 as a procurement gate today, we share our audit roadmap and the control evidence we've already collected.

We're working with a small number of design-partner programs in PHP, IOP, residential, detox, and SUD to co-develop Lucida against real payer mixes and real authorization workflows. Design partners get the diagnose + build phases at no cost, weekly working sessions with the founder and our UR-experienced advisor, and lifetime preferred pricing if they continue after the engagement. In exchange, design partners give us access to de-identified workflow detail and denial correspondence, participate in feedback sessions, and — if it works — let us reference them as a customer.

Pricing is per program, bundled (the subscription includes the software, the weekly advisor, and 2–5 payer workflows). Single-program programs (one PHP, IOP, residential, or detox track) start around $2,500/month. Multi-track programs (PHP + IOP, or residential + PHP) run around $5,000/month. Multi-site operators with 3+ sites are custom, starting around $9,000/month. Design-partner programs lock in their rate. Final pricing is confirmed once we understand census, payer mix, and integration scope.

Yes. Design-partner engagements end at the agreed milestone unless you choose to continue — no card on file, no auto-charge. Everything Lucida produced during the engagement — payer playbooks, workflow audits, concurrent-review packets, exposure reports — is yours to keep. Source data is deleted from our systems within 30 days of the engagement ending, or sooner at your written request.