For a worker billing Medicaid or reporting to a state funder, a case note is the only thing standing between a delivered service and a denied claim. The rules for what counts as "acceptable" aren't national; they're set state by state, funder by funder, and they change. This post is a preview of where TryCaSIE is going next.
The compliance bar varies by state, and we have been glossing over it
Today TryCaSIE generates generic BPS, SOAP, BIRP, DAP, and GIRP notes that meet a general professional quality bar. That is fine for a lot of settings. It is not enough for a clinician in Virginia.
Virginia's Department of Medical Assistance Services (DMAS) requires a BioPsychoSocial assessment to contain specific elements, phrased in specific ways. The severity, intensity, and duration of each problem have to be documented. Functional impairment has to be described in concrete terms. Medical necessity for every recommended service has to be spelled out. Each recommendation has to link back to an identified need. A BPS missing any of those elements gets rejected, and the claim goes with it. At that point the note isn't a documentation problem; it's a reimbursement gate.
Where TryCaSIE stands today
We already have the compliance primitives that are hard to retrofit:
- Six-year audit retention across the note audit log and the auth event log, with every action tagged by client platform
- Private endpoints for Azure OpenAI, Azure Speech, Key Vault, and Redis
- Microsoft BAA covering every AI call and every transcription
- No PHI persisted on mobile devices; only session tokens, stored in the iOS Keychain
- Per-user BAA tracking with admin override for exceptional cases
- Custom note formats up to eight sections, so admins can already prototype state-specific templates today, though without the validation layer
What is missing is the layer that turns a well-structured note into an auditable note: the guarantee that every regulatory requirement has been addressed before the worker hits finalize.
What's coming: state-aware templates plus validation
The new capability has four parts. Together they turn "TryCaSIE writes a BPS" into "TryCaSIE writes a Virginia-compliant BPS that passes DMAS audit."
1. State-aware templates grounded in regulation
The first template is a Virginia-compliant BPS assessment, built directly against CMS LCD 33252 (psychiatric diagnostic evaluation medical necessity) and Virginia register §10104 (comprehensive needs assessment). Sixteen required sections, each with prompt guidance that tells the AI transformer what auditors expect to see:
- Presenting problem / reason for referral
- History of present illness (severity, duration, intensity required)
- Behavioral health and psychiatric history
- Medical history and current health
- Substance use history
- Developmental and trauma history
- Psychosocial and environmental factors
- Strengths and resources
- Functional impairments (critical for VA audit)
- Risk assessment
- Mental status examination
- Diagnosis
- Clinical formulation / summary
- Medical necessity justification (VA critical)
- Recommended services and initial treatment plan
- ISP linkage: each recommendation tied to an identified need, a functional impairment, and a treatment goal
2. Required-section validation
Before a note can be finalized under a state-specific template, TryCaSIE verifies that every required section is present and non-empty. No worker gets halfway through their week and finds out a month's worth of notes are missing the "Medical Necessity Justification" header that DMAS requires.
3. High-risk flag detection
Section presence is only half the problem. A note can include every required header and still fail audit because the content inside is weak. The AI pass flags the specific triggers documented in Virginia regulation as common reasons for audit failure:
- Missing severity or duration language in the history of present illness
- No concrete functional impairment described
- Diagnosis stated without symptoms to support it
- No documented response to prior treatment
- Weak or absent medical necessity justification
- Recommendations not tied to identified needs
4. Compliance score
The output surfaces an auditor-lens view before the clinician finalizes:
Flags:
— Missing severity of symptoms
— Functional impairment not clearly stated
The clinician decides whether to address each flag, override it with a rationale, or finalize as-is. The score informs; it doesn't block.
Why Virginia first, and what comes after
Virginia is first because its DMAS manual and register requirements are concrete, well-documented, and have a clear audit-failure pattern. Building the framework against a well-specified state keeps the abstraction honest: when we generalize to other states, we're adapting a working system rather than inventing one.
After Virginia BPS, each state becomes a profile: required sections, flag rules, regulatory citations, and the prompt guidance that teaches the AI what auditors in that state want to see. Texas, California, New York, Pennsylvania, and Ohio are the next candidates, chosen by where our users actually work.
How to give feedback
This is a preview. If you run services in a state not yet on the roadmap, or if your agency has internal requirements that go beyond the state baseline, the feedback page is the fastest path to influencing what ships. Specific regulatory citations are especially useful; we build templates from the source, not from secondhand summaries.