Trust and safety
HIPAA status
AnswerStack is not offered as a HIPAA-covered service today. What that means for you, and what is already in place.
Warning
AnswerStack is not offered as a HIPAA-covered service today. We do not sign business associate agreements, and you should not use it for calls that require one.
We would rather say that plainly than leave you to work it out from a vague answer. Nothing on this site, in the app or in a sales conversation should suggest otherwise. If anyone tells you differently, they are wrong.
What that means in practice#
- Do not use AnswerStack for workflows that handle protected health information under HIPAA.
- Do not treat an AnswerStack call record as part of a designated record set.
- If your organisation requires a business associate agreement from a vendor that touches call content, AnswerStack is not that vendor today.
- Whether a given sales enquiry falls under HIPAA at all is a legal question. Your counsel decides it, not us.
Why a sales assistant usually is not a clinical one#
AnswerStack is built for inbound sales enquiries, and it is built not to collect clinical detail:
- It never gives medical advice and never assesses what care somebody needs. See What it will not do.
- Its questions are the ones you wrote. A well-built playbook asks "what level of care are you looking at?", not "what conditions does your mother have?".
- Anything a caller volunteers about health can be marked Sensitive, which masks it in the app and keeps it out of notification emails.
That is a sensible design, not a compliance position. It reduces how much health information you gather; it does not change the status above.
What is already in place#
AnswerStack is built so that a stricter mode can be switched on later without a redesign. Today these are simply good practice:
| In place now | Why it matters later |
|---|---|
| A compliance setting on every account, off for all of them | One switch later restricts an account to covered vendors and stricter retention |
| Every vendor behind an interface: voice, speech, language, storage, email | An account can be pinned to vendors that will sign a BAA |
| No transcript text, caller details or collected answers in application logs or error reports | Logs are the most common place health details leak |
| Answers tagged by sensitivity in the playbook | Sensitive values are masked in the app and left out of notifications |
| Account separation enforced in the database, role-based access, and an audit log of who viewed what | Access controls and audit trails are core safeguards |
| Encryption in transit and at rest, private storage, expiring signed links | The expected baseline |
| Per-playbook retention with automatic deletion | Supports keeping no more than you need |
| Notifications that carry a link, not the details | Email is not a safe place for health information |
You can see the setting for yourself in the app, under Settings → General, in Compliance mode, where it reads: HIPAA-grade mode is not available yet. Do not use this account for calls that require it.
If you need it#
Tell us. It is a real piece of work — business associate agreements with every vendor that touches call content, a risk assessment, written policies, staff training and a breach procedure — and none of it is something to improvise once you have already gone live.
We will tell you where it sits on our plans and give you an honest timeline. What we will not do is sign something we cannot stand behind.