Platform

Security & Multi-Tenancy

Security & Multi-Tenancy is the Coralia platform layer built for HIPAA compliance: hard data isolation for every applied behavior analysis (ABA) agency, AES-256-GCM (256-bit Advanced Encryption Standard in Galois/Counter Mode) encryption of protected health information (PHI) at rest, role-based access through a 67-code permission catalog, and an audit log covering every PHI read, change, and export. All of it is inspectable in the live demo — a full synthetic agency, no sign-up.

The problem in real agencies

An ABA agency's records concentrate protected health information (PHI): diagnoses, dates of birth, guardian contacts, session narratives. Access needs differ sharply by role — a registered behavior technician (RBT) should reach only the clients on their caseload, the front office needs demographics and billing detail without clinical depth, and a board certified behavior analyst (BCBA) reviewing the staff roster has no business seeing colleagues' pay rates. When software cannot express those distinctions, agencies over-grant access and hope nobody ever asks who saw what.

ABA staffing is fluid in ways rigid access models punish. An RBT covers a colleague's Tuesday session and needs that client's chart for exactly that visit — not a permanent assignment an admin must remember to revoke. A BCBA who also runs operations wears two hats and should be able to work in one at a time. And when someone leaves mid-authorization, access has to end with employment, not hours later when a login token happens to expire.

Payer and state audits turn access history into evidence. When an auditor asks who viewed a client's chart — or whether a departed employee's account was really closed — the agency needs names, timestamps, and roles, not a shrug. Families raise the stakes further: caregivers log into portals now, and a portal account for one family must be structurally incapable of reaching another family's data, or the portal becomes a liability instead of a service.

How it works in Coralia

  1. 1

    Hard walls between agencies — and between families and staff

    Every agency on Coralia is a tenant with enforced data isolation. The database layer automatically filters list queries by agency across 25 data models and refuses to run if no agency context is present, so isolation is the default rather than a per-query discipline; records fetched by ID carry the same agency filter in the query itself, so a cross-tenant identifier resolves to nothing. A second wall separates account kinds: a parent or caregiver login can only resolve caregiver-portal surfaces, so a portal session can never load a staff-side client chart — isolation by construction, not by hiding menu links.

  2. 2

    PHI encrypted at rest under rotatable, versioned keys

    Protected health information fields are encrypted with AES-256-GCM — 256-bit Advanced Encryption Standard in Galois/Counter Mode — using a 32-byte key, a fresh random 12-byte initialization vector for every encryption, and a 16-byte authentication tag. Because the mode is authenticated, tampered ciphertext fails to decrypt instead of silently returning altered data. Every ciphertext carries a key-version marker, which makes key rotation a zero-downtime operation: new writes use the new key, a previous-key fallback keeps older records readable, and a re-encryption tool migrates stored data forward.

  3. 3

    A 67-code permission catalog with five ABA-native role bundles

    Access decisions resolve through 67 permission codes in 21 functional groups — clients, sessions, billing, authorizations, audit, and more. Five built-in bundles match how ABA agencies staff: Agency Admin, BCBA, BCaBA (board certified assistant behavior analyst), RBT, and Office. The BCaBA bundle excludes every destructive delete permission by rule, so a future delete code can never silently reach the mid tier. Agencies can create custom roles with any permission set and assign them with optional validity windows; changes propagate within 60 seconds. Adding a permission code without its database counterpart fails the platform's automated checks before it can ship.

  4. 4

    Caseload scoping and one-role 'uniform' mode

    RBTs are scoped at the object level. Without a view-all grant, an assistant-category staff member can open only clients they hold an active case assignment, a therapy session, or a scheduled calendar event with — editing the URL to an off-caseload chart is blocked at the server, while a scheduled coverage session still grants access for exactly that engagement. Staff holding several roles can switch into single-role 'uniform' mode, narrowing navigation and permissions to one hat at a time; the switch can never escalate, and blocked pages offer a one-tap role change instead of a bare denial.

  5. 5

    Sign-in defenses: password policy, MFA, lockout, verified email

    Passwords follow a published four-rule policy — 8 to 128 characters with an uppercase letter, a number, and a special character — and the identical rule list drives the server-side check, the live checklist on every password form, and a Weak/Medium/Strong meter. Email must be verified before first sign-in. Users can enable multi-factor authentication (MFA): after the password, a random six-digit code is emailed, valid for 10 minutes and usable once. Five consecutive failed attempts lock the account for 15 minutes, authentication endpoints are rate-limited, and the post-login redirect accepts only in-app paths, closing the open-redirect hole.

  6. 6

    An audit trail that answers 'who saw what, wearing which hat'

    Every PHI read, change, and export writes an audit entry with the actor, the active role the actor was working under, and the source — human user, AI agent, system, background job, data sync, or caregiver — and mutations record which fields changed, never the values. Browsing, filtering, and CSV (comma-separated values) export of the full trail live in the Audit Center, alongside a consent ledger, staff credential matrix, and supervision org chart.

The specifics

  • 67 permission codes in 21 functional groups, resolved through five built-in role bundles — Agency Admin, BCBA, BCaBA, RBT, Office — plus agency-defined custom roles.

  • PHI encrypted at rest with AES-256-GCM: 32-byte keys, a fresh random 12-byte initialization vector per encryption, and a 16-byte authentication tag.

  • Versioned ciphertext supports zero-downtime key rotation: new writes use the new key while a previous-key fallback keeps older records readable.

  • 25 data models are automatically agency-scoped on every list query; records fetched by ID carry the agency filter in the query itself, so a cross-tenant identifier resolves to nothing.

  • Optional email MFA: a random six-digit code with a 10-minute expiry, usable exactly once; toggling MFA is password-confirmed and audited.

  • Five consecutive failed logins lock the account for 15 minutes; a successful login clears the counter.

  • Sessions are 8-hour JSON Web Tokens; every request re-verifies active agency membership, so deactivated staff lose access within seconds.

  • Role and permission changes propagate within 60 seconds through a time-bounded cache with explicit invalidation on role edits and switches.

  • Password policy: 8–128 characters with an uppercase letter, a number, and a special character — one rule list drives both the server check and the on-screen checklist.

Integrations

Email delivery — six-digit MFA codes and email-verification links arrive in the user's inbox · Distributed rate limiting — authentication endpoints share one persistent limiter across server instances · The Coralia Brain — actions by the per-agency AI copilot are written to the same audit log under a dedicated 'ai-agent' source · Caregiver Portal — family accounts use the same hardened sign-in but are structurally limited to portal surfaces

Access control

The module gates itself with its own catalog: audit.view unlocks the log and its CSV export, settings.manage_roles gates role creation and assignment, clients.view_phi is required for any PHI read (which is then logged as sensitive), and staff.view_compensation — held only by the Agency Admin and Office bundles — guards pay rates. One code, domain_clarifications.answer, is manual-grant-only and never auto-bundled into any role, not even Agency Admin.

Frequently asked questions

Is Coralia HIPAA compliant?

No software is HIPAA compliant by itself — compliance describes how an organization operates, and no government certification for software exists. Coralia is built for HIPAA compliance: PHI is encrypted at rest with AES-256-GCM, every agency's data is hard-isolated, access runs through a 67-code permission system, and every PHI read, change, and export lands in an audit log a compliance officer can filter and export.

Can an RBT see clients who are not on their caseload?

No. Assistant-category staff are checked at the object level: without a view-all permission, an RBT can open only clients they hold an active case assignment, a therapy session, or a scheduled calendar event with. Editing the URL to another client's chart is blocked server-side. Coverage still works — a scheduled substitute session grants access to that client for that engagement, with no permanent assignment needed.

What happens when a staff member leaves the agency?

Deactivate their membership and their access ends on their next request. Although sessions are 8-hour tokens, every request re-verifies active agency membership with a 10-second cache, so a deactivated account is redirected to login with its cookies cleared within seconds — not hours later when the token would have expired. Role assignments can also carry validity windows, so temporary access ends on a set date.

Does Coralia support multi-factor authentication (MFA)?

Yes, as a per-user option. With MFA enabled, sign-in requires the password plus a random six-digit code sent to the user's verified email; the code expires after 10 minutes and works exactly once. Enabling or disabling MFA requires re-entering the account password, and the change itself is written to the audit log.

How does Coralia help during a payer audit?

The audit log records every PHI read, mutation, and export with the actor, the role they were wearing, the source (human user, AI agent, system, background job, data sync, or caregiver), IP address, and a request identifier — mutations record field names, never values. Browsing, filtering, and CSV export of the trail live in the Audit Center, which adds a consent ledger, staff credential matrix, and supervision org chart on one compliance surface.