Security

Trellis runs on a small set of HIPAA-compliant infrastructure providers, each operating under a signed Business Associate Agreement:

• Convex — our reactive database and server runtime. Care data lives here, encrypted at rest and in transit. All server-side access happens through typed functions with explicit authentication and authorization checks.
• Vercel — front-end hosting and serverless function execution. The Next.js application is deployed here. No PHI is server-side rendered — all PHI loads through Convex reactive queries on the client after authentication.
• Postmark — transactional email delivery. Email bodies and subject lines never contain PHI. Notification emails are categorical (“A new note was added”) and link back to Trellis where the authenticated user sees the actual content.
• Anthropic (Claude) — AI inference for pattern insights and weekly summaries. Receives only de-identified surrogate data, enrolled in Zero Data Retention so prompts and completions are not retained beyond the request lifetime.

A current list of subprocessors is documented on the HIPAA / BAA page.

In transit. All connections to Trellis use TLS 1.2 or higher. We do not accept unencrypted requests in production. The Convex WebSocket connection that powers live updates is also TLS-encrypted end-to-end.

At rest. Care data stored in Convex is encrypted at rest using AES-256 via the underlying infrastructure. File attachments stored in Convex Storage inherit the same encryption.

Backups. Convex production backups are encrypted with the same standards as primary storage.

Trellis uses Convex Auth for session management. Passwords are hashed with bcrypt before storage. We never see your plaintext password — and your password is never logged in analytics, audit entries, or error reports.

Password reset uses 6-digit one-time codes delivered to the registered email address with a 15-minute expiry. To prevent abuse (OTP-flood attacks against any email), reset emails are rate-limited to one per email address per minute, and the system never confirms whether an email address exists in the database (preventing email enumeration).

Session timeout. An inactivity monitor signs users out after extended idle time, with a tighter timeout on the crisis page where stale sessions could mean stale crisis information.

Google sign-in. Optional OAuth provider for users who prefer SSO over password. Authenticates against Google's identity service with no password ever stored on our side.

Multi-factor authentication is on the pre-launch hardening roadmap (Step 24) and will be enforceable on a per-account basis with a per-organization option to require it for clinical roles.

Authorization in Trellis is granular and per-individual, never per-user-globally. The same person can have different roles and different permission flags on different individuals' care teams.

Role-based defaults. Each of 22 care team roles (parent, BCBA, RBT, OT, SLP, classroom teacher, paraprofessional, case manager, etc.) has a curated default set of permission flags appropriate to that role.

Account-owner gates. Sensitive operations (editing diagnoses or DOB, granting permissions to other members, creating custom role templates, writing voice statements as the individual) default to the account owner only. The account owner can grant these to specific members.

Visibility filtering. Care notes and appointments carry per-record visibility (Team / Clinical only / Family only / Author only / Custom). Filtering happens at the query layer; unauthorized records are never serialized into responses to be filtered client-side.

Server-side enforcement. Every PHI-touching query and mutation in Convex calls requireAuth() or requireCareTeamAccess() before reading or writing. There is no path to read or modify PHI without an authentication and authorization check on the server. Comprehensive access-control test coverage runs in CI.

Every read, write, update, and delete of Protected Health Information creates an entry in the audit log:

• Who performed the action (user ID, role)
• When (millisecond-precision timestamp, server-clock)
• What (action type, resource type, resource ID, individual ID)
• Where (IP address and user-agent string captured for defense-in-depth — these are spoofable from the client and never used for access decisions)
• Per-action contextual details (visibility level changed, fields touched, etc.)

Merkle-chain tamper-evidence. Each audit row is hashed with the prior row's hash. A daily cron verifies the chain end-to-end and emails the head hash to a compliance inbox. If a row is tampered with after the fact, the chain breaks at that row and the verification cron catches it. This makes the audit log effectively tamper-evident even if an attacker had write access to the database.

Family-accessible audit log. Per HIPAA §164.528 (Right to Accounting of Disclosures), family-role members can view a derived audit log for the individuals they support. The view shows actor name, actor role, action, resource type, and timestamp — sufficient to satisfy the disclosure-accounting requirement without leaking sensitive operational metadata.

Trellis uses AI to surface patterns in care data — sleep trends, behavior correlations, medication effects, goal trajectories. Every byte sent for AI analysis passes through a 7-layer de-identification pipeline before leaving our infrastructure. The AI provider never sees a name, a date of birth, an address, or any identifier listed in HIPAA §164.514(b) Safe Harbor.

Layer 1 — Structural scrub. Typed identifier fields (names, DOB, addresses, contact info, MRN) are stripped from the structured payload.

Layer 2 — Free-text scrub. Care-note bodies pass through pattern recognition for the 18 HIPAA identifiers, with surrogate substitution.

Layer 3 — Validation gate. A deterministic regex/denylist check fails the request closed if any residual identifier survives.

Layer 4 — Semantic Haiku validation. A second-stage AI model (Claude Haiku) does named-entity recognition on the scrubbed payload and blocks the request if it surfaces anything that looks human-identifiable.

Layer 5 — Inference call. The analysis prompt runs against Claude Sonnet with Zero Data Retention enabled at the provider level.

Layer 6 — Re-identification. Surrogates in the response are substituted back to the real names/values inside Trellis before display.

Layer 7 — Structured-output parsing. The response is parsed into a typed insight payload; anything that doesn't match the schema is rejected.

Care data is never used to train AI models. Anthropic's ZDR enrollment combined with the de-identification pipeline ensures that model training on our customer data is operationally impossible regardless of policy.

AI features are gated to the Growth tier. Roots and Roots+ users have no AI inference running on their data.

A small number of architectural rules govern how PHI moves through Trellis:

• No PHI in logs. We do not log user data, medical info, or anything that could identify an individual. Logs use internal IDs only.
• No PHI in URLs. Names, DOBs, diagnoses, and other identifiers never appear in URL paths or query strings. Resource IDs only.
• No PHI in error messages. Errors that propagate to Sentry pass through an automatic scrubber that removes PHI before transmission. The Sentry config is unit-tested to prevent regressions.
• No PHI in Stripe metadata. A whitelist sanitizer at the Stripe API boundary rejects any metadata field that doesn't match the allowed schema. Subscription tier, billing cycle, and account ID — yes; anything resembling PHI — never.
• No PHI in push notifications. Push payloads are categorical (“A new note was added”), never the actual content. Tapping the notification opens Trellis where the authenticated user sees the real data.

Convex maintains continuous production backups with a rolling 30-day retention window. The backup store inherits the same encryption-at-rest standards as primary storage.

Recovery procedures are tested as part of pre-launch hardening (Step 24 in the launch punch list). Our recovery time objective (RTO) is 4 hours; recovery point objective (RPO) is 1 hour.

Account deletion requests propagate to backups within the next scheduled rollover (max 30 days), at which point the deleted data is no longer recoverable from any system.

We maintain an incident response plan covering security events, suspected unauthorized access, data integrity issues, and service outages. The plan is exercised through tabletop reviews quarterly.

HIPAA breach notification. If a security incident results in a confirmed breach of unsecured PHI as defined in HIPAA §164.402, we notify affected individuals, covered entities (where applicable), and HHS within the time frames required by §164.404 and §164.408. Notification uses the email on file for the account.

Customer communication. For security-relevant events that don't rise to a HIPAA breach (e.g., a service outage, a non-PHI data exposure), we send a status communication via email and post a public incident note describing impact, remediation, and prevention.

We welcome reports from security researchers. If you believe you've found a vulnerability in Trellis, please email security@trelliscare.app with details. We commit to:

• Acknowledge your report within 3 business days
• Provide a substantive response with our assessment within 10 business days
• Keep you informed as we work on a fix, and credit you in the resolution notice (with your permission)
• Not pursue legal action against good-faith security research that follows the principles below

Safe harbor principles. Good-faith research means: don't access more data than necessary to demonstrate the vulnerability; don't exfiltrate PHI; don't modify or destroy data; don't degrade service for other users; report findings to us before any public disclosure; give us a reasonable window to fix.

A formal bug bounty program with monetary rewards is planned post-launch. Until then, we extend hall-of-fame recognition to disclosed researchers.

Trellis is built to align with the HIPAA Security Rule (45 CFR §164.302–318) and Privacy Rule (45 CFR §164.500–534). The full HIPAA framework, including our Business Associate Agreement, is documented on the HIPAA / BAA page.

Pre-launch we are completing an external penetration test and the findings will be remediated before public launch. Audit reports are available under NDA to qualified enterprise prospects.

SOC 2 Type II is on our post-launch roadmap and we expect to complete the observation period within 12 months of public launch.

Security is a shared responsibility. Steps you can take:

• Use a strong, unique password (or sign in with Google)
• Don't share your account credentials — invite team members through Trellis instead
• Review your care team list periodically and remove members who no longer need access
• Use the visibility controls on care notes (Team / Clinical / Family / Author only) to scope sensitive content appropriately
• Notify us at security@trelliscare.app if you suspect unauthorized access to your account

Security issues, vulnerability reports, or compliance questions: security@trelliscare.app

For general support or non-security questions, use hello@trelliscare.app.