Pablo Health, LLC operates Pablo.health and the Pablo clinical application. We are a Business Associate under HIPAA. Reach us at privacy@pablo.health.
This policy describes how the Pablo clinical product collects, stores, processes, and shares data when you use it as a licensed clinician (or on behalf of a licensed clinician). It applies to data you enter through app.pablo.health, any Pablo desktop and mobile apps, and any background service that processes your sessions.
Your practice — the clinic, group, or solo therapist who licenses Pablo — is the Covered Entity. Pablo Health, LLC is the Business Associate. We sign a Business Associate Agreement (BAA) with your practice before any protected health information (PHI) is stored. The BAA governs how we may use and disclose PHI; this privacy policy describes the operational reality of that BAA in plain language.
If you are a patient whose information is recorded by your therapist, your therapist is the Covered Entity, not Pablo. Direct any access, correction, or deletion request to your therapist; we will assist them in fulfilling it.
Pablo runs on Google Cloud Platform in the United States (us-central1). All of the services below are covered by Google's Cloud HIPAA BAA:
| Subprocessor | Purpose | Data category | BAA |
|---|---|---|---|
| Google Cloud (incl. Vertex AI) | Hosting, database, AI inference (Gemini, Anthropic Claude routed via Vertex) | All PHI | Yes — Google Cloud BAA |
| Google Cloud Speech-to-Text | Real-time transcription (practice mode) | Audio of practitioner only | Yes — Google Cloud BAA |
| AssemblyAI | Optional transcription provider for recorded sessions | Session audio | Yes — Pablo Health holds a HIPAA Subcontractor BAA with AssemblyAI |
| Stripe | Billing and subscription management | Email + Stripe customer ID only (no PHI) | Not required (no PHI) |
| ElevenLabs | Text-to-speech for AI patient (practice mode) | Synthetic patient text only (no real PHI) | Not required (no PHI) |
| Firebase / Identity Platform | Authentication, MFA | Email, MFA enrollment, sign-in events | Yes — Google Cloud BAA |
We do not use third-party analytics (Google Analytics, Segment, Sentry, PostHog, etc.) inside the application. The weekly internal pentest reviews the application boundary for any egress to hosts outside this list.
Each practice's data lives in its own isolated database partition. The application resolves your practice from your authenticated email at the start of every request and refuses to commit transactions that would write outside that partition — a defense-in-depth check against bugs that bypass schema resolution. A second layer at the database itself fails closed when the per-request user context is unset, so a query that somehow ran outside our middleware returns zero rows rather than leaking across users.
Therapist audio is streamed to a speech-to-text provider in real time and discarded the moment the transcript line is produced. The synthesized AI-patient voice is generated frame by frame and is never persisted. Only the resulting conversation transcript is stored on the session record.
If your practice enables session recording, the audio is uploaded to a Cloud Storage bucket inside our Google Cloud project, transcribed by either an internal Whisper job or AssemblyAI (your choice), and stored alongside the session.
Recorded audio is governed by a per-practice retention window (default 365 days, configurable from 30 days to 7 years by your practice administrator). A daily purge job removes audio older than the configured threshold and writes an audit-log entry for each deletion. You can also delete the audio for any individual session at any time through the application; deleting a session or its patient cascades to the audio.
Every action that touches PHI writes a structured audit record. Audit logs include who performed the action, when, what type of action (view, create, edit, delete, export, finalize, audio upload, transcript upload, EHR navigation, rating), and the resource ID. Audit log contents are PHI-free by contract — a runtime assertion blocks a write that would include a denylisted PHI field — so the audit table can be reviewed without itself becoming a privacy concern.
Audit records are retained for seven years (HIPAA's documentation retention floor is six years; we go one more for safety).
A daily job reviews every tenant's audit logs for behavioral patterns that indicate possible misuse and writes any findings to a retention-locked compliance bucket. High-severity findings page the on-call operator. The review operates on PHI-free behavioral metadata; its findings are independent of the audit log itself, so the audit log remains the source of truth.
You can read your own audit log at any time through the application.
Pablo uses large language models (Google Gemini and Anthropic Claude) and embedding models, all routed through Google Cloud's Vertex AI. Vertex AI is covered under Google Cloud's HIPAA BAA, and inputs to Vertex AI are not used to train Google or Anthropic foundation models.
Specifically:
We do not call OpenAI, Anthropic's direct consumer API, or Google's public AI Studio API from the production application. The weekly internal pentest reviews the application boundary for unexpected egress.
The Vertex AI inference API does not expose a per-request "do not train" parameter. The no-training guarantee is structural rather than per-call:
Pablo can connect to a Google account you control — a calendar, a practice mailbox, or both. Connecting is optional; nothing else in Pablo requires it. This section describes what each connection gives us, what we do with it, what we keep, and how to remove it. Everything else in this policy applies to it as well.
Only through Google’s own OAuth consent screen, which you complete yourself and which names every permission before you grant it. We never ask for your Google password and we cannot connect an account on your behalf. Each permission is requested only when you turn on the feature that needs it, so you never grant more than you are using.
Permissions we request, and why not less.
calendar.app.created — to create one calendar named “Pablo Sessions” in your Google account and write the sessions you book in Pablo to it. This is the narrowest permission that lets Pablo put sessions on your calendar: it reaches only the calendar Pablo creates, and nothing else in your account.calendar.freebusy — to read when you are busy, so Pablo never offers a time that is already taken. It returns start and end times only; it never shows event titles, descriptions, locations or guests.calendar.readonly (optional, only if you choose to bring in your existing schedule) — to list the calendars in your account so you can choose one, and to read the events on the calendar you choose, so Pablo can show you sessions already on it, including ones another scheduling service puts there, and keep Pablo in step when those change. Free/busy alone cannot do this: it carries no event identity, so Pablo could not tell one recurring session from another or notice that one moved. When an event shows the full name of one of your active clients, and no other client has that name, Pablo adds it as a session and shows you what it added, with Undo on each. You can turn that off in Settings › Calendars. Any other event is added only after you say which client it is.calendar.events (optional, only if you choose to put sessions on your main calendar instead of the “Pablo Sessions” calendar) — to write the sessions you book in Pablo to your main calendar. Google only allows writing to a calendar Pablo did not create with this permission; calendar.app.created cannot reach it. Pablo uses it only to create, update and remove the sessions booked in Pablo, and never edits or deletes any other event.What we store. For sessions Pablo writes to Google: the Google event identifier, so Pablo can update or remove that event when you change the session. For a session booked from an event already on your calendar: that event’s identifier, so Pablo can keep the session in step when the event changes. For the calendar Pablo creates: its identifier, so reconnecting reuses it instead of making another. If you bring in your existing schedule: for each event on the calendar you chose, its title, start and end time, Google’s event and recurring-series identifiers, and your answer about which client it is (or that it is not a client). We do not store free/busy results; they are read when Pablo shows you open times and then discarded. We do not store event descriptions, locations, attendees or attachments.
Disconnecting. You can disconnect Google Calendar at any time from Settings › Calendars in Pablo. Disconnecting revokes Pablo’s access with Google, deletes Pablo’s stored tokens, and deletes what Pablo read from your calendar: the event titles, times and identifiers above, and your answers about which client each event is. It also stops Pablo bringing in sessions from your calendar, so connecting again does not start reading it until you turn that back on. Sessions you booked in Pablo stay in Pablo, because they are your records. Each keeps the identifier of the Google event it is tied to, and nothing else from that event, so that if you connect again Pablo picks those sessions back up instead of duplicating them. The “Pablo Sessions” calendar and its events stay in your Google account, because they are yours to keep or delete. You can also remove Pablo from your Google Account’s third-party access page, which stops all further access immediately.
Permission we request, and why not less. gmail.modify, for the Practice Inbox: read messages arriving in the connected mailbox, apply triage labels, and create draft replies for you to review. Google classifies this as a restricted scope, and we request it because the narrower Gmail permissions cannot do the work: gmail.readonly cannot apply a label at all, and gmail.labels can create labels but cannot attach one to a message. Labelling an existing message requires gmail.modify.
What we do with it. Gmail data is used to classify incoming mail (what kind of message it is, how urgent, whether it appears to contain PHI), to apply the corresponding label in your mailbox, and to prepare draft replies that you review before anything is sent. Pablo does not send mail on your behalf without your review. Classification and drafting run through Google Vertex AI under the same posture described in §9 — inside Google Cloud’s HIPAA BAA, and not used to train foundation models.
What we store. For each triaged message we keep: the Gmail message and thread identifiers, the mailbox address, the sender address, the subject line, the time it arrived, our classification of it, the state of any draft reply, and the Gmail identifier of that draft. Where you have opted in to improving Pablo’s drafting, we may also keep a redacted copy of the AI-generated draft — not your correspondent’s message — which is cleared once your correction has been captured. We do not copy the bodies of your email messages into Pablo. Message content stays in Gmail; Pablo holds identifiers, metadata and its own classifications, and reads the content from Google only at the moment it is processing a message. Drafts are written into your Gmail drafts, not stored as mail in Pablo.
Disconnecting. You can disconnect the mailbox from Pablo at any time, or remove Pablo from your Google Account’s third-party access page, which stops all further access immediately.
OAuth refresh tokens are encrypted at rest with AES-256-GCM under a key dedicated to that connection. We do not reuse one key across different Google connections, so a mailbox token and a calendar token are never protected by the same key. Google data is stored in the same isolated, encrypted database partition as the rest of your practice’s data (see §6).
Besides disconnecting, you can ask us to delete any Google user data we hold about you by writing to privacy@pablo.health. We delete it within 30 days and confirm when it is done.
Pablo’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
Concretely, we do not:
Google offers a Business Associate Agreement for Google Workspace, but not for consumer Google accounts — an ordinary @gmail.com address is not covered by one. If you connect a consumer Gmail mailbox or calendar that contains protected health information, that information is sitting in a Google account with no BAA behind it, and Pablo connecting to it does not change that. We flag this rather than leave it implicit: it is your decision as the covered entity, and a Google Workspace account under your own BAA is the safer arrangement.
Two distinct buckets of data, two distinct retention policies. We separate them deliberately.
These are the records of who did what, when, on which resource. They are PHI-free by design — a runtime check rejects any audit-log write that would include clinical content. They live for seven years from the action date, then a daily purge job physically removes them. They are our compliance documentation under HIPAA §164.316(b); your practice does not need a copy.
This is the substance we hold for you as Business Associate: patient names, demographics, sessions, transcripts, notes, recorded audio. HIPAA does not require us to retain it for any particular period. It exists to support your clinical work and stays only as long as you want it.
Deletion is a three-stage process designed so that we never hold protected health information longer than we have to.
Net effect: clinical content (sessions, transcripts, notes, audio) sits in our database for at most about 60 days after you click delete (the 30-day undo window plus up to 30 days of backup rotation). What persists for the seven-year audit window is only the audit log entry and the minimal identity tombstone — neither of which contains clinical content.
If you cancel your subscription or otherwise leave Pablo:
TENANT_DELETED audit event is written to our platform-level audit log so the offboarding itself is documented.Some records are governed by external retention obligations and remain even when you ask us to erase everything:
If you want to delete your Pablo account without going through the offboarding flow — for example, an individual user leaving a multi-user practice — email privacy@pablo.health. We will confirm the request with the BAA signatory at your practice and execute within ten business days. The operator-assisted path is the default for individual-user deletion in multi-user practices because removing one user's access requires a BAA-signatory check; full-tenant offboarding remains self-service through the offboarding flow described above.
Where you are an end user of Pablo:
Where you are a patient whose information is in Pablo through your therapist's use of it: HIPAA assigns those rights to you, but exercises them through your therapist (the Covered Entity). Contact your therapist to request access, correction, or deletion. We will assist them in fulfilling your request.
If we discover a breach involving your PHI:
Your practice is then responsible for notifying affected individuals and HHS as required by the Breach Notification Rule. We retain the breach-notification documentation for six years per HIPAA §164.414.
For a security event you would like to report to us, write to security@pablo.health.
Pablo's infrastructure is in the United States (Google Cloud us-central1). All PHI is processed and stored in the U.S. and is subject to U.S. law. We do not support EU, UK, or Canadian-hosted deployments. If you have a regulatory requirement that rules out U.S. residency, Pablo is not the right fit for your practice.
We will update this policy whenever we materially change how we handle PHI. The "last updated" date at the top of this page reflects the most recent change. We will notify the BAA signatory at every active practice if a change is material.