Back to home

Frequently asked

PHP & IOP documentation, denials, and Lucida — answered.

The questions PHP and IOP operators actually ask us, grouped by topic. For anything we haven’t covered, email hello@lucida.ai or book a 30-minute demo.

Medical necessity & denials

How payers actually decide PHP/IOP medical necessity, what triggers denials and clawbacks, and the documentation patterns that survive audit.

What is the #1 cause of PHP and IOP claim denials?

Failure to establish medical necessity in daily clinical documentation. Across every major payer, auditor, and denial letter, the single dominant reason PHP and IOP claims are denied, cut mid-stay, or clawed back after payment is that the notes don't prove the patient cannot safely step down to a lower level of care today. Everything else — coding errors, timely filing, auth timing — is a distant second.

What does “medical necessity” actually mean in PHP and IOP billing?

For PHP and IOP, medical necessity means the payer's reviewer can read your 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 — standard outpatient — would be clinically unsafe today. This standard gets applied at initial authorization, at every concurrent review, and again during retrospective audit. Vague or templated language fails all three tests.

What is ASAM Criteria and why do payers cite it?

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 PHP and 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.

What is LOCUS/CALOCUS and how is it different from ASAM?

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.

How do concurrent reviews work in PHP and IOP?

A concurrent review is the payer's periodic re-check — typically every 5–10 days in PHP, every 2–4 weeks in IOP — to decide whether the current authorization should continue. The payer's utilization reviewer pulls your recent progress notes and asks: do these notes still justify the intensity the patient is being billed at? If the documentation is weak, the authorization gets cut effective immediately, and every day billed after that cut is denied. Concurrent-review cuts are the most common cause of mid-stay revenue loss in behavioral health.

What is a retrospective clawback and how far back can a payer go?

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 PHP/IOP operator, a single retrospective audit can pull back six figures. Lucida's clawback-exposure monitoring surfaces at-risk claims before the auditor arrives.

What is the 20-hour weekly threshold for PHP?

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. Lucida tracks weekly therapeutic hours per patient and alerts the moment a patient trends below threshold, while there's still time to close the gap.

What counts as a “templated” note in payer audits?

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. Lucida flags templated patterns across your chart in real time.

Why do PHP authorizations get cut mid-stay?

The payer's concurrent-review nurse reads the recent notes and doesn't see evidence that the patient still requires PHP intensity. Common triggers: notes don't reference current symptom severity with objective measures (PHQ-9, GAD-7, ASAM dimension updates), there's no documented reason the patient can't step down to IOP safely today, or notes read identically week-over-week implying no ongoing clinical decision-making. The fix is at the note level, not the appeal level — by the time you're appealing a cut, the revenue for the denied days is already hard to recover.

What documentation changes most reduce PHP/IOP denial 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.

How Lucida works

The product mechanics — how we ingest notes, what scoring returns, which systems we read from, and what changes (and doesn't) in your workflow.

How does Lucida work with our existing EHR?

Lucida is a read-only overlay on the EHR your program already uses — Kipu, Valant, Alleva, Sunwave, TherapyNotes, SimplePractice, or others. We ingest daily progress notes via API or export, score them against payer and ASAM/LOCUS medical-necessity standards, and surface the risk findings in the Lucida dashboard. Clinicians keep their existing workflow. We never write back to the chart, never change how notes are authored, and never require staff to log into a second system to do their current clinical work.

Does Lucida write back to our chart?

No. Lucida is strictly read-only. Every integration we build is one-way: we read notes, billing data, and authorization data from your existing systems. We do not push content back into the EHR 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, keeps compliance review simple, and means our engagement can never corrupt or change your clinical record of truth.

Which EHRs does Lucida support — and what if ours isn't listed?

Primary integrations: Kipu, Valant, Alleva, Sunwave, TherapyNotes, SimplePractice. Secondary: Netsmart, DrChrono, and generic CSV/PDF import. If your program runs on an EHR we don't list — or uses paper or PDFs — we can still ingest notes via a secure export or one-time bulk upload. We've never turned away a design-partner program for EHR reasons. During onboarding we'll confirm the integration path before you commit.

Can Lucida work with paper charts?

Yes. For programs that still run on paper or scanned-PDF charts, we accept secure uploads of de-identified notes and ingest them via OCR + parsing pipeline. Scoring quality is equivalent to digital EHR ingestion — ASAM/LOCUS criteria don't care about the medium. The one caveat is that real-time scoring (inside the note, as the clinician writes) requires an EHR integration; paper workflows score at the batch or weekly level.

How long does implementation take?

For design partners on Kipu, implementation is typically under a week: read-only API credentials, sample note ingestion, payer-criteria calibration against a sample of your recent denials, and first risk report delivered. Other EHRs take 1–4 weeks depending on integration maturity. Paper/PDF workflows start scoring within 48 hours of the first upload. We don't bill implementation time during the 45-day design-partner pilot.

Does Lucida replace our UR nurse?

No, and we don't recommend it. Lucida does what a UR nurse cannot do alone — score every note every day at scale, across every patient — but the clinical judgment in appeals, payer negotiations, and complex concurrent-review prep still lives with your UR team. Programs that use Lucida typically report their UR nurse spends less time assembling justification packets and more time on the work only a licensed clinician can do.

What's in the 0–100 medical-necessity score?

Each note is evaluated against a weighted rubric covering: presence of objective measures (PHQ-9, GAD-7, ASAM dimensions), specificity of clinical observations, explicit step-down rationale, individualization vs. templated language, alignment with the payer's specific LOC criteria, and coherence with the patient's current treatment plan. Scores above 85 are typically audit-ready; 65–84 are medium-risk; below 65 is flagged as high-risk. The score is always broken down into the specific sub-signals that drove it — clinicians see exactly what to change.

Security, HIPAA & data handling

HIPAA posture, BAA timing, encryption, retention, and how we handle PHI. For a deeper technical breakdown see the security page.

Is Lucida HIPAA compliant?

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.

Do you sign a BAA before we send any data?

Yes — if you request one in the risk-scan or demo form, we send a BAA before you transmit anything. For the free documentation risk scan we prefer de-identified notes (no PHI required), but if your workflow makes de-identification burdensome and you want to send identified notes, we'll BAA first. For paid engagements, a BAA is always executed before production data flows.

Do you train AI models on our notes?

No, not without your explicit written consent. Customer notes, even de-identified, are never used to train or fine-tune our scoring models by default. Scoring is performed against a fixed model plus your program's payer-criteria library — nothing persists into training pipelines. For design partners who want to opt in to model improvement, we offer a separate written agreement with specific data-use terms. Everyone else's data stays out of training, period.

Is Lucida SOC 2 certified?

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 can share our audit roadmap and the control evidence we've already collected.

Pricing, contract & the pilot

What Lucida costs, how the 45-day design-partner pilot works, and what the paths out and in look like.

What is the design-partner program?

We're opening 10 design-partner slots with PHP and IOP programs who want to co-develop Lucida against their real payers and real clawback exposure. Design partners get 45 days of full Lucida access at no cost, weekly working sessions with the founder and our UR-experienced clinical reviewer, and lifetime preferred pricing if they continue after the pilot. In exchange, design partners give us access to de-identified notes and denial letters, participate in feedback sessions, and — if it works — let us reference them as a customer.

What does Lucida cost after the 45-day pilot?

Pricing is per program (one PHP track or one IOP track = one subscription), with rates scaling on active authorizations or weekly census rather than employee headcount. Single-program pricing starts around $1,500/month; dual PHP+IOP runs around $3,500/month; multi-site operators with 3+ sites are custom. Design-partner programs lock in their rate for life. Final pricing is confirmed on the demo call once we understand your census and integration scope.

Can we cancel? What happens to our data and reports?

Yes. Design-partner pilots end automatically at 45 days unless you choose to continue — no card on file, no auto-charge, no opt-out required. If you don't convert, every risk report, exposure summary, and concurrent-review packet Lucida produced during the pilot is yours to keep. Your source data (notes, claims) is deleted from our systems within 30 days of pilot end, or sooner at your written request.

Related reading

LOCUS vs. ASAM vs. MCG: which medical necessity criteria do behavioral health payers actually use?

A cross-payer map of the three criteria sets, with what PHP and IOP programs should document to satisfy all three.

Still have a question?

30 minutes with our clinical reviewer, scored against your actual notes.

Book a demo