Dash and HIPAA

Dash is designed to support HIPAA-regulated clinics

When your clinic uses Dash to manage patient information, Dash acts as a business associate processing that information on your behalf, under your customer agreement and a business associate agreement (BAA). Dash is software for clinics — it is not a health care provider, and it does not make compliance decisions for your practice.

Software alone does not make a clinic compliant

There is no such thing as certified-compliant software under HIPAA. Compliance is a property of your organization — your people, policies, and tools working together. Dash's job is to give you safeguards that are actually implemented, honestly labeled, and verifiable; your job is to run a compliant practice on top of them. Be skeptical of any vendor that says otherwise.

What Dash takes responsibility for

• Building and operating the platform safeguards listed below, with an honest status for each.
• Keeping patient data structurally separated, access-controlled, and audited inside the platform.
• Managing our own vendors: a maintained subprocessor inventory, PHI-exposure review, and BAA execution before production patient data flows through a vendor.
• Assessing and notifying your clinic about security incidents that affect your data, as a business associate must.
• Not marketing beyond our evidence: our public claims are checked in our build pipeline against an internal control registry.

What remains your clinic's responsibility

• HIPAA training for your workforce, your own risk analysis, and your sanction policies.
• Device and workstation security — screen locks, disk encryption, and who can touch the front-desk machine.
• Access decisions: who gets accounts and roles, reviewing that list regularly, and removing departed staff promptly.
• Legal review of your patient-facing notices, consents, and policies — including content you configure in Dash.
• Safe communication practices: what your staff put in emails and text messages, and honoring patient communication preferences.
• Signing a BAA with Dash before putting patient information in the system.

What is implemented today

Each statement below maps to a specific control in our internal HIPAA control registry. Our build pipeline fails if a statement here loses its backing control or evidence.

• Access to patient data requires sign-in, membership in the clinic's organization, and an authorized role. (TEC-02, ADM-05)
• Each clinic's data is isolated by organization scoping, with a documented threat model and code-enforced boundaries. (TEC-11)
• Sensitive actions are recorded in an append-only audit log — who did what, in which clinic, and when — including blocked attempts in sensitive flows. (TEC-06, TEC-01)
• Sessions use secure, httpOnly, strict same-site cookies and expire automatically. (TEC-04)
• Staff and patient-portal logins support TOTP multi-factor authentication, with account lockout and rate limiting against credential attacks. (TEC-05)
• Data in transit is encrypted with TLS, including connections to our databases. (TEC-10)
• AI features run through a single permissioned gateway with guardrails and redacted interaction logs — product code cannot call model providers directly, and automated checks enforce this. (TEC-12)
• Clinical and patient-facing surfaces load no third-party analytics, advertising pixels, session replay, or error-monitoring scripts — enforced by automated checks. (TEC-14)
• Demos, sandboxes, and development environments run on synthetic data, never on production patient data. (TEC-15)
• Integration credentials live in a managed secrets service, not in our application database or source code. (TEC-16)
• Dash's internal support console is code-blocked from reading patient data, and there is no staff-impersonation feature. (TEC-18)
• Every code change passes automated quality and security gates, including black-box login security probes and a baseline vulnerability scan. (ADM-10, ADM-12)
• Security policies are written, version-controlled, and reviewed on a declared cadence. (ADM-14)

Safeguard status

The full safeguard map with honest statuses, updated 2026-07-04. “In progress,” “planned,” and “needs verification” mean exactly that — we publish the gaps we are working on rather than rounding up to done. Items on our production gate list must be implemented before we onboard production patient data.

BAAs and due diligence

Executing business associate agreements — with our own vendors and with customer clinics — is an explicit gate on our path to onboarding production patient data, and its status is shown above. For our current subprocessor list, security documentation, or vendor due diligence, contact security@connectdash.ai. Clinical questions belong with your clinic; this page describes the software platform only.