← Privacy overview

Product Privacy Policy

1. Who we are

Pablo Health, LLC operates Pablo.health and the Pablo clinical application. We are a Business Associate under HIPAA. Reach us at privacy@pablo.health.

2. What this policy covers

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.

3. Roles under HIPAA

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.

4. What we collect and store

Account information

• Your email address, display name, and Firebase user ID
• For the BAA-signing user: legal name, professional license number and jurisdiction, practice address (HIPAA §164.504(e) requires identifiable signatories on a BAA)
• Multi-factor authentication enrollment status
• Subscription/billing status (managed by Stripe — Pablo does not store card numbers)

Patient and session data (PHI)

• Patient names, contact info, demographics that you enter
• Session metadata (date, duration, type, status)
• Session audio (recorded sessions only — see §7 below)
• Session transcripts
• Generated and edited clinical notes (SOAP, narrative, DAP, BIRP, GIRP, intake, treatment plan)
• Quality ratings, export and finalization timestamps

Operational data

• Audit logs of every action that touches PHI (see §8)
• Calendar integrations (Google Calendar OAuth tokens and iCal feed URLs, with additional application-layer encryption applied before storage)
• Practice configuration, signup allowlist, system flags
• Compliance documents you upload to your vault (BAAs you've signed with other vendors, audit memos)

What we explicitly do not collect

• We do not run analytics, session recording, or behavioral tracking on the application. There are no third-party trackers in the app frontend.
• We do not collect patient social security numbers, payment information, or insurance numbers — Pablo is documentation, not billing.
• We do not retain practice-mode (AI patient simulation) audio. The AI patient is synthetic; only the conversation transcript is persisted.

5. Where your data lives

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:

• Cloud Run — application compute
• Cloud SQL for PostgreSQL — patient data, sessions, notes, audit logs (encrypted at rest, AES-256, Google-managed keys)
• Cloud Storage — recorded session audio (when applicable) and compliance reports
• Cloud Tasks, Cloud Batch, Cloud Scheduler — background processing (e.g., transcription, scheduled reports)
• Secret Manager — application secrets and API keys
• Identity Platform / Firebase Auth — user identity and MFA

Subprocessors that may receive PHI

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.

6. How we protect your data

In transit

• All connections to the application require TLS. Plain HTTP requests are rejected at the application boundary, not silently redirected.
• Our domains are configured so that browsers refuse to fall back to plain HTTP after the first successful HTTPS connection (HSTS, with a long browser-cache window and subdomain inclusion).
• Real-time channels (Practice Mode) require a single-use, short-lived authentication ticket exchanged through an authenticated REST call. Your sign-in token is never embedded in a WebSocket URL.

At rest

• All data is encrypted at rest with AES-256 (Cloud SQL for the database, Cloud Storage for audio).
• Integration tokens we receive from third-party services (Google Calendar OAuth tokens, iCal feed URLs) get an additional layer of application-layer encryption before they are written.

Tenant isolation

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.

Authentication and access

• Multi-factor authentication (TOTP) is required by default for all production users.
• Sign-in tokens are checked for revocation on every request, so a revoked token cannot continue to ride a long-lived browser tab.
• You sign up at pablo.health, complete payment, and the application provisions a private tenant for your practice. Before any patient data can be created or stored, you accept Pablo's Business Associate Agreement; the BAA signatory's legal name, professional license, and practice address are captured at acceptance and used to populate the executed BAA.

7. Audio handling

Practice mode (AI patient simulation)

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.

Recorded clinical sessions

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.

8. Audit logging and access monitoring

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.

9. AI processing and model training

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:

• Note generation sends your session transcript to Gemini via Vertex AI.
• Practice-mode AI patient sends therapist utterances to Gemini via Vertex AI.
• Audit-log review sends PHI-free behavioral metadata to Anthropic Claude via Vertex AI.
• EHR navigation assistance may send free-text queries containing patient identifiers to Gemini-Flash-Lite via Vertex AI.

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.

How "no training on your data" is enforced

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's Google Cloud project operates under Google Cloud's HIPAA Business Associate Agreement and the Cloud Data Processing Addendum. Both contractually prohibit Google from using customer content sent to Vertex AI to train, retrain, or improve any foundation model.
• Anthropic Claude on Vertex inherits the same posture — inference runs inside Google's Vertex infrastructure, not Anthropic's first-party API, and the BAA covers it.

10. Google Workspace data (Gmail and Calendar)

Pablo can connect to a Google account you control — a practice mailbox, a calendar, or both. Connecting is optional; nothing else in Pablo requires it. This section describes what that connection gives us, what we do with it, and what we keep. Everything else in this policy applies to it as well.

How we get access

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. You can revoke access at any time — from the disconnect control inside Pablo, or from your Google Account’s third-party access page. Revoking stops all further access immediately.

What we request, and why not less

• Gmail (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.
• Google Calendar — for calendar sync, if you connect it: writing Pablo’s appointments to your calendar, and, where you ask for it, reading your existing appointments so Pablo can import an established schedule or keep up with bookings you make elsewhere. Which permissions are requested depends on which of those you turn on, and each is named on the consent screen before you grant it.

We do not request Google Drive, Google Contacts, or any Google permission unrelated to the features above.

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. Calendar data is used to place your Pablo appointments on your calendar and, where you have enabled it, to reflect appointments you booked elsewhere back into Pablo.

What we store, and what we do not

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.

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.

Limited Use

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:

• use Google user data for advertising, or transfer it to anyone for advertising purposes;
• sell Google user data, under any circumstance;
• allow humans to read your Google user data, except with your explicit consent for a specific message, where necessary for security purposes such as investigating abuse, to comply with applicable law, or where the data has been aggregated and de-identified for internal operations;
• use Google user data to train generalized or foundation AI models. Inference runs inside Google Cloud Vertex AI under a HIPAA BAA and a Cloud Data Processing Addendum that contractually prohibit Google from training on it (see §9).

Consumer Google accounts and HIPAA

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.

11. Retention and deletion

Two distinct buckets of data, two distinct retention policies. We separate them deliberately.

Bucket A — audit logs (Pablo's compliance records)

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.

Bucket B — your patients' protected health information

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.

How deletion works in practice

Deletion is a three-stage process designed so that we never hold protected health information longer than we have to.

• Stage 1 — Soft-delete on user action (Day 0): When you delete a patient or session in the app, the row is immediately marked deleted and disappears from every list, search, export, and report. The audit-log entry for the deletion is written in the same database transaction so the trail and the action are atomic — neither can land without the other.
• 30-day undo window (patients): A soft-deleted patient can be restored within 30 days from the “Recently deleted” view, by any user in the practice who can see that patient. Restoring a patient also brings back the sessions and notes that were deleted along with them. A session deleted on its own cannot be restored — there is no undo for an individual session, and it will be purged at day 30 like any other deletion. After 30 days nothing here is accessible to anyone in the practice.
• State-law retention attestation: Before a destructive delete is accepted, you affirm that you have met your professional retention obligations for that record. We log the attestation alongside the deletion. Your state board's medical-records retention rule (commonly six to ten years for adults, longer for minors) is your obligation as the legal records custodian, not Pablo's. We don't enforce or police state law, but we make the choice deliberate — and we will not retain your patients' clinical content as a substitute for your own retention.
• Stage 2 — Day 30 hard purge of clinical content: A scheduled job runs daily over patients whose 30-day undo window has expired. For each, it writes a minimal identity tombstone (patient ID, name, DOB, MRN) into a separate locked compliance schema, and then physically deletes every row associated with that patient — sessions, transcripts, notes, recorded audio, and the patient row itself. Both writes happen in a single database transaction, so the tombstone exists if and only if the clinical content is gone.
• Stage 3 — Year 7 expiry: Seven years after the original deletion, the audit-log entry and the identity tombstone both expire on the same day, removed by a separate purge cron. After year 7, the question "who was patient X?" is permanently unanswerable, and that's by design.
• Backups: Encrypted database backups roll on a thirty-day cycle. After Stage 2, your patient's clinical content disappears from every backup within thirty days as the rotation progresses. We do not restore from backup to recover deleted data except under your written instruction.

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.

What happens when your practice offboards

If you cancel your subscription or otherwise leave Pablo:

1. Notice + 60-day grace period. We notify the BAA signatory and freeze billing. You retain full access to the application during this window.
2. Tenant-wide export. A single-click export produces an archive of every patient, session, transcript, note, and audit-log entry still live in your practice — JSON for portability and PDF for human readability. You take this with you. Patients you previously deleted are not in the export; their clinical content was already physically removed at Stage 2 of the per-patient deletion flow.
3. End of grace. We physically destroy your practice's database schema (every remaining patient, session, transcript, note, calendar token, vault document, and recorded audio file). For any patients still live at this point, an identity tombstone is written into the compliance schema in the same transaction so audit-log resolution survives the schema drop. Audit-log entries from the tenant schema are extracted into a platform-level archive, also in the same transaction.
4. What we keep, and only what we keep: the audit log entries from your time on the platform (PHI-free, seven-year TTL), and the identity tombstones for your patients — each patient ID, name, date of birth, MRN, and your tenant ID — locked in a separate Postgres schema reachable only by a designated compliance investigator role and never by the application's normal request path. The tombstones exist for one reason: if HIPAA or another regulator asks "when did user X access patient Y," we can answer. Each tombstone expires on the same seven-year clock as the audit log entries that reference it; once both are gone, the question is permanently unanswerable. We keep nothing else.
5. TENANT_DELETED audit event is written to our platform-level audit log so the offboarding itself is documented.

What we never delete on request, and why

Some records are governed by external retention obligations and remain even when you ask us to erase everything:

• Audit logs and identity tombstone (HIPAA §164.312(b), §164.316(b)): retained for seven years, structured as described above. PHI-free in the audit log; minimum-necessary in the tombstone.
• Breach-notification records (HIPAA §164.414): if a breach involving your PHI occurred during your time on Pablo, we retain documentation of the breach, our investigation, and notifications for six years from discovery or resolution.
• Compliance documentation (HIPAA §164.530(j)(2)): the BAA you signed with us, internal policies, training records, risk assessments, and similar artifacts are retained for at least six years.
• Billing records: Stripe retains transaction history under its own terms and U.S. tax-record requirements (typically seven years). We retain only your Stripe customer ID and subscription state; the financial records themselves are at Stripe.
• Legal hold: if your practice or Pablo is under a litigation hold, subpoena, or government investigation, deletion is suspended for the records covered by the hold. We will tell you when a hold is in effect for your data and when it is lifted.

Account deletion outside an offboarding

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.

12. Your rights

Where you are an end user of Pablo:

• Access: You can view your account, your patients, sessions, notes, and audit log through the application.
• Correction: You can edit any clinical content you authored. Edits are themselves audit-logged.
• Export: Patient and session export is available through the application.
• Deletion: Patient and session deletion is available through the application; tenant offboarding is self-service; individual-user account deletion in a multi-user practice is operator-assisted (see §11).

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.

13. Breach notification

If we discover a breach involving your PHI:

• High-severity events (active exposure, exfiltration, or any breach affecting more than 500 individuals): we notify the BAA signatory at your practice within 72 hours of discovery, by email and phone.
• All other breaches: we notify within 30 days of discovery — tighter than the HIPAA §164.404 sixty-day floor — including identification of affected individuals, the types of PHI involved, the date of the breach and date of discovery, what occurred, what we are doing to mitigate and prevent recurrence, and steps individuals can take to protect themselves.

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.

14. International users

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.

15. Changes to this policy

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.

16. Contact

• Privacy questions or requests: privacy@pablo.health
• Security disclosures: security@pablo.health
• BAA execution: legal@pablo.health