The person who reaches out to a recovery or behavioral-health clinic at 2am is often the one whose window is closing. Most clinics send that call to voicemail, and the inquiry gets returned the next morning, if it gets returned at all.
An AI intake assistant can cover that gap. In healthcare, though, the chat window is the easy part. This guide covers what has to be true before anyone should turn one on. It's written for clinic owners and operators evaluating a vendor, including us.
This is not legal advice. Have a healthcare-privacy attorney review your agreements and policies before any patient data flows.
There is no "HIPAA-certified" software
HHS doesn't certify software. When a vendor says its product is "HIPAA compliant," that can only mean three things are in place together:
- Signed Business Associate Agreements (BAAs) across the entire vendor chain.
- The Security Rule safeguards: technical, administrative, and physical.
- The documentation that proves both.
The chain is what most people miss. Once a system handles patient data on your behalf, every party that can see that data needs a signed BAA: the vendor who built it, the cloud provider it runs on, the model provider, the SMS or voice provider, and the scheduler or EHR it books into. One missing link makes the whole setup non-compliant, however good the rest of it is.
The shape of a compliant build
The architecture we'd use keeps patient data inside one BAA-covered boundary from the first message:
- Channels (web chat, SMS, or voice) are encrypted in transit and run on services covered by the cloud provider's BAA.
- The assistant runs on a model offered under that same BAA, configured so prompts aren't retained or used for training. For us, that means Claude on Amazon Bedrock.
- The data store is encrypted at rest with a key the clinic's account controls, and access is logged.
- Logs and analytics never contain patient data. No third-party analytics scripts on the intake surface.
Only three things leave that boundary:
- A callback booking, written into a scheduler or EHR that is also under a BAA.
- A staff alert that carries a link, not patient details. The on-call person clicks through to the secure record. The alert itself, which might land on a lock screen, says nothing about who reached out or why.
- The crisis path, covered below.
Collect as little as possible
The assistant's job is to get a callback booked, not to do intake. It needs a first name, a callback number, a rough sense of the need, and a good time to call. Diagnosis, insurance IDs, date of birth, and clinical history all wait for the human call.
One caveat: for a treatment facility, even a name and a phone number count as protected health information, because the fact that someone contacted a recovery clinic is itself sensitive. Collecting less makes the damage smaller if something goes wrong. It doesn't make the data stop counting.
The crisis path can't depend on the AI alone
An intake assistant for a recovery clinic will meet someone in crisis. This matters more than any compliance detail.
- When the assistant detects signs of acute risk, such as suicidal ideation or an active overdose, it surfaces 988 and emergency services immediately and pages an on-call human. Logging it for the morning is not enough.
- The clinic's clinical team reviews and signs off on that flow before launch.
- The assistant never diagnoses, gives medical advice, or promises outcomes or bed availability.
Before go-live
A checklist to hold any vendor to:
- BAAs signed with the clinic and with every service in the chain
- A written security risk analysis. This is legally required, not optional.
- Policies, workforce training, and a breach-response plan
- Encryption in transit and at rest, least-privilege access, MFA, and session timeouts
- No patient data in logs, error trackers, or analytics
- Crisis flow reviewed and signed off by the clinical team
- BAA template and policies reviewed by a healthcare-privacy attorney
SOC 2 is usually not needed for a single-clinic deployment. Treat any vendor who leads with it instead of the items above with some skepticism.
Start small, measure one number
The honest way to pilot this:
- Phase 1: one channel, callbacks only. Web chat or SMS. Capture a name, a number, and a rough need, and book a callback. No voice yet, no clinical questions.
- Phase 2: wire in safety and booking. Crisis detection with on-call escalation, reviewed by the clinical team, plus bookings that write directly into the clinic's scheduler.
- Phase 3: measure. The one number that matters is after-hours inquiries captured and booked that would otherwise have been missed. Expand to voice only after that number holds up.
Where to start
If you run a clinic and after-hours inquiries are slipping through, we're happy to walk through what a pilot would look like for your setup, including whether it's worth doing at all. Start at /discuss or write to hello@fullspecstudio.com. For AI built into your own systems more broadly, see AI integration consulting.