Subprocessors
Last updated 28 July 2026
Two entries say “no BAA”. They are on this list precisely because they are the interesting cases — a vendor that will not sign one is still safe to use if the architecture guarantees it never receives protected health information, and both of those guarantees are enforced in code rather than by policy. The reasoning is written out beside each.
Infrastructure
The services the platform runs on. All hold protected health information.
Managed Postgres — the primary database
Data: All platform data including protected health information, encrypted at rest
Application hosting and delivery for the web, admin and marketing apps
Data: Request routing and application execution; PHI transits, and is not stored at rest
Object storage for documents and attachments
Data: Uploaded documents and clinical attachments
Planned. The documents vault is not yet in service.
Platform services
Services that handle a defined slice of data for a specific function.
Authentication and session management
Data: Name, work email, authentication factors. No clinical data.
Payment processing and merchant-of-record settlement
Data: Payment credentials, transaction amounts, and the minimum identifying data a payment requires
Payment card data is entered into PayArc-hosted fields and never reaches a trellOS server. PayArc is PCI DSS Level 1; the relationship is governed by the merchant agreement rather than a BAA.
SMS delivery for patient and workforce notifications
Data: Mobile number and message content
Planned. SMS is not enabled until the agreement and 10DLC registration are complete.
Services that never receive health information
These vendors do not sign business associate agreements, so the platform is built to keep protected health information away from them entirely. In each case the barrier is structural — a type system, a build-time corpus — not a rule someone has to remember.
Transactional email — workforce and vendor mail only
Data: Recipient address, an opaque count, and a link. No clinical content, ever.
Resend does not offer a business associate agreement. Rather than accept the risk, the platform makes it structurally impossible to send PHI through them: email templates are type-constrained so a patient name cannot be passed into one, a lint scans the rendered output, and a runtime check fails the send closed. This is why trellOS notifications tell you there is something to see rather than what it is.
Routing for the in-app AI assistant
Data: The user's typed question and passages retrieved from trellOS documentation. No patient, order or prescription data.
Every request is sent with zero data retention, restricting routing to providers under a ZDR agreement, and Vercel deletes prompts and outputs on completion. The assistant's knowledge is compiled from source files at build time, so there is no patient record it could retrieve, and questions that look patient-specific are refused before any call is made. See how we use AI.
Changes to this list
We give 30 days’ notice before adding a subprocessor that will handle protected health information, so a customer has time to object. Write to compliance@trellos.org to be notified of changes.
A vendor added in the product and not added here is a breach of our own agreements, so this page is maintained as part of shipping, not after it.
Where data is processed
All processing is in the United States. trellOS does not transfer platform data outside the US, and does not use a subprocessor that would.
Questions about anything on this page? compliance@trellos.org