Built for HIPAA: What That Actually Means

Before we get into specifics: Mandi does not claim to be HIPAA compliant. That's an intentional choice, not an oversight. 'HIPAA compliant' is a legal status that requires executed Business Associate Agreements, a completed risk analysis, written policies, a designated Security Officer, and often a third-party assessment. Claiming it before those elements are in place is a compliance risk, not a selling point.

What we can say, and what we say carefully, is that Mandi is built for HIPAA. That means the architecture was designed from day one with the HIPAA technical safeguards as a constraint, not an afterthought. Here's what that looks like in practice.

Tenant isolation by construction

In a multi-tenant application, the most dangerous failure mode is a bug that allows one customer's data to be read by another. In many systems, this is prevented by access control logic: checks that run at query time and filter results to the right tenant.

In Mandi's architecture, cross-tenant reads are structurally impossible. Each practice's data is accessed through a tenant-bound data adapter, and the adapter itself, not just the query logic, enforces the boundary. A bug in application code cannot cause a cross-tenant data leak, because the layer below it doesn't allow it.

The AI never touches the database

This is the one that surprises people most. In many AI-integrated systems, the language model has relatively broad access: it can query, it can write, it can read patient records directly. The surface area for a mistake (or a prompt injection) is large.

In Mandi, the AI can only call a whitelisted, validated set of tools. It cannot query the database directly. It cannot read a patient record it hasn't been explicitly given access to. It cannot execute a booking without generating a proposal that a staff member must confirm. The boundary between the model and the data is enforced in code, not in prompting.

Minimum-necessary data to the model

HIPAA's minimum-necessary standard says you should only use, disclose, or request the minimum PHI needed to accomplish the purpose. We take this seriously in how data flows to the language model.

• Patient names are masked to 'First L.' before reaching the model
• Phone numbers, email addresses, and dates of birth never reach the model
• Outreach scripts are generated for staff to send; the model doesn't send them
• PHI cannot land in server logs; it's scrubbed before logging

The audit trail

Every action in Mandi (every booking proposal, every confirmation, every cancellation, every time a patient record is read) is logged with the user, the timestamp, and the tenant. The log is tamper-evident and retained.

This matters for two reasons. First, it supports the HIPAA requirement to account for disclosures of PHI. Second, it gives practice owners visibility into what their software is actually doing with patient data, something that's surprisingly rare.

We believe in being honest about where we are.

What's in place today

These safeguards are operating now: TLS end-to-end and encryption at rest; SSO with mandatory MFA and automatic session expiry; a signed Business Associate Agreement with every practice we serve, and with Google Cloud — the sole infrastructure provider that processes patient data; and a documented risk analysis, written security policies, and a designated Security Officer.

What's still ahead

An independent third-party HIPAA assessment as we scale beyond our initial pilot practice.

The questions to ask any dental software vendor before you share patient data: Do you have a signed BAA? Have you completed a formal risk analysis? Can you describe how your architecture prevents cross-tenant access? What data reaches your AI models, and in what form? If you can't get clear answers to those questions, the posture isn't ready, regardless of what the marketing page says.