Our security and compliance posture, stated plainly
Practice-management vendors love the word "compliant." We'd rather tell you exactly what Braviq does today, what it doesn't do yet, and what has to happen before it does. If a claim on this page stops being true, the page changes.
What Braviq does today
Every mutation is audit-logged
Every create, update, sign-off, import, and export made through Braviq's server functions writes an entry to an append-only audit log — who, what, and when. Entries are written with elevated credentials, so they cannot be edited or deleted from the application. Supervisors and BCBAs can filter the trail and export it to CSV from inside the product.
Row-level multi-tenancy on every table
Every clinical table is protected by Postgres row-level security scoped to your organization, enforced in the database itself — not just in application code. Role gates (supervisor, BCBA, technician, caregiver) further restrict what each account can read and write.
AI output is never final until a clinician approves it
AI-drafted session notes require a BCBA review and signature before they count for anything. Parent-facing weekly summaries are released only after a BCBA approves them. Billing-code suggestions are explainable drafts, never auto-submitted.
PHI input guard on Ask EIDBI
Ask EIDBI (our MN DHS policy assistant) forwards only the question text — never user, organization, or client identifiers. A screening layer blocks questions that appear to contain an SSN, date of birth, phone number, email, Medicaid ID, or an identified person's name; SSNs are hard-rejected server-side. It is a safety net against accidental disclosure, not a data-loss-prevention guarantee.
What Braviq doesn't do yet
Demo data only — no Business Associate Agreements yet
Braviq currently runs on infrastructure without BAAs in place, so no real client information may be entered. Our documented go-live gate moves the PHI path to BAA-covered AWS services (RDS Postgres, Bedrock, SES under AWS's free BAA) and puts a customer BAA in place before any clinic enters a real client. Until every item on that gate is complete, this is a demo-data product.
EVV records are internal-only
Our visit-verification module keeps internal operational records. EIDBI services are not currently on Minnesota DHS's list of EVV-required services, and Braviq does not transmit to the state aggregator (HHAeXchange). If DHS ever adds EIDBI to the required list, EVV would have to flow through the state vendor — and we say so in the product, not just here.
Claims are internal drafts — no MN-ITS submission
The 837P claims module prepares internal drafts for review. Real EIDBI claims go through MN-ITS or a clearinghouse with your clinic's enrolled NPI; Braviq does not submit claims on your behalf, and the billing screens carry a banner saying exactly that.
Why we publish this at all
Because you're choosing a system of record for a clinical practice, and the honest answer to "is this HIPAA-ready?" is a checklist, not a badge. Radical transparency is how a new vendor earns trust: we publish the gaps alongside the strengths, we keep honesty banners inside the product where the limits apply, and we'd rather lose a deal than overstate our posture. When the BAA gate closes and real-client use opens, this page will say so — with the same specificity.
Want to see the audit trail in action? Book a demo and we'll show you every mutation being logged, filtered, and exported — live.
Book a demo