← 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 or via GET /api/users/me/audit-log.

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. 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: A practice administrator can restore a soft-deleted patient or session within 30 days through the "Recently deleted" view. This catches misclicks. After 30 days the entry is no longer 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.

11. 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 §10).

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.

12. 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.

13. 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.

14. 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.

15. Contact

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