"HIPAA Compliant Software" Is Misleading — Here's What to Ask

"HIPAA Compliant" on a vendor's website usually means one of three things:

1. The vendor has done meaningful work to support HIPAA compliance and will sign a BAA
2. The vendor uses encryption and assumes that's enough
3. The vendor doesn't actually understand HIPAA and is using the phrase as a marketing tag

Telling these apart matters because if you're a covered entity (a dental practice, medical office, clinic) and your vendor mishandles PHI, you are still on the hook for the breach. The BAA is shared liability, not transferred liability (source).

Here's how to evaluate vendors honestly.

There is no "HIPAA certified" badge

This is the first thing to understand: HHS does not certify products as HIPAA compliant (source). There is no equivalent to PCI-DSS certification or SOC 2 for HIPAA. A vendor that claims to be "HIPAA certified" either misunderstands the law or is hoping you do.

What exists instead:

• A signed Business Associate Agreement (BAA) between you and the vendor
• Documented administrative, physical, and technical safeguards that the vendor has implemented
• A vendor's willingness to undergo third-party security audits (SOC 2 Type II is the closest proxy)

If a vendor refuses to sign a BAA, that's the conversation-ender. Without a BAA, you cannot legally share PHI with them. Full stop.

What a real BAA requires

A compliant BAA, per HIPAA's Privacy and Security Rules, must include:

1. Permitted uses and disclosures of PHI by the business associate
2. Required safeguards the business associate will implement to protect PHI
3. Reporting requirements for breaches and security incidents (including timelines)
4. Subcontractor flow-down: the business associate must ensure that any subcontractors they use also sign equivalent BAAs
5. Access provisions for the covered entity to request and audit PHI
6. Termination clauses if the business associate violates HIPAA
7. Return or destruction of PHI at the end of the contract

A BAA that's three paragraphs long and signed via DocuSign without negotiation is probably not compliant. A real BAA is 5–15 pages and has negotiable terms.

Five questions to ask any vendor

1. "Can I see your BAA?" Get a copy before you commit to anything else. If they hesitate or push back, you have your answer.

2. "How is PHI encrypted at rest and in transit?" The correct answer mentions AES-256 (or FIPS 140-2 validated) for data at rest, TLS 1.2+ for data in transit. "We use SSL" is not enough.

3. "Where is PHI stored geographically?" U.S.-based storage is the safe answer. If PHI is processed or stored outside the U.S., you need additional contractual protections.

4. "What's your breach notification timeline and process?" HIPAA requires notification "without unreasonable delay" and no later than 60 days. A good vendor's contract specifies a tighter SLA (often 24–72 hours).

5. "Who are your subcontractors and have they signed BAAs?" If your vendor uses AWS, Twilio, OpenAI, or any other service to process PHI, those subcontractors must also have BAAs. AWS and Twilio offer them; OpenAI's API by default does not (the Enterprise tier does).

Red flags

Stop the conversation if any of these are true:

• Vendor refuses to sign a BAA but says they're "HIPAA compliant"
• Vendor says "we don't store PHI" but actually transmits or processes it — transmission and processing both trigger HIPAA obligations
• Vendor claims a HIPAA "certification" from a body that isn't HHS (there isn't one)
• Vendor's BAA disclaims all liability for breaches caused by the vendor's negligence
• Vendor uses AI/LLM providers without disclosing whether those providers signed BAAs

What QotBot does in this space (honestly)

QotBot's standard product is not currently marketed as a HIPAA-compliant product. The infrastructure (TLS in transit, encryption at rest, audit logs, role-based access controls) is built to support a HIPAA-ready deployment, and BAAs are available for healthcare deployments under separate contract. We don't claim a HIPAA "certification" because no such thing exists.

For dental and medical practices evaluating QotBot, the practical path is:

1. Pilot with appointment reminders and missed-call text-back, which generally don't require PHI in the message body
2. Sign a BAA before any deployment that handles PHI (treatment information, diagnoses, etc.)
3. Configure messaging templates to avoid PHI in transit where possible
4. Review the data retention and audit log policies

This is honest about what we do and don't do. A vendor that won't be this specific is probably selling you a label, not a system.

Related: TCPA and SMS in plain English