​

HIPAA Compliance

​

Overview

1. Encryption at Rest — PHI encrypted at rest with Google-managed AES-256 (Cloud SQL default)
2. Access Controls — PHI access restricted to designated roles
3. Audit Logging — All PHI access logged with reason codes
4. Data Retention — Automatic deletion after configured retention period
5. BAA Tracking — Business Associate Agreement status management

​

Who can do what

​

Prerequisites

1. Sign a Business Associate Agreement (BAA) with Devotel
2. Designate a HIPAA compliance officer within their team

​

Technical Controls

​

1. Encryption at Rest

• Algorithm: AES-256 (Google Cloud default at-rest encryption)
• Key Management: Encryption keys are managed and rotated by Google Cloud
• Scope: All database-stored content, including message body, media_url, and metadata
• In transit: TLS 1.3 protects all data in transit (see Infrastructure Safeguards)

Note: Devotel does not currently perform per-organization application-layer encryption of message bodies. PHI confidentiality at rest relies on Google Cloud’s transparent AES-256 encryption rather than an application-layer cipher. The GET /settings/hipaa response includes an encryption_algorithm field for reporting purposes only — it does not indicate that message bodies are individually encrypted at the application layer.

​

2. Access Controls

• treatment — Access required for patient treatment coordination
• payment — Access required for payment processing
• operations — Access required for healthcare operations
• legal — Access required for legal compliance
• support — Access required for customer support resolution

Known limitation: Orbit does not currently restrict message-content reads to a narrower set of roles beyond the billing confinement above, and it does not require an operator-supplied reason code on the message read endpoints (GET /messages, GET /messages/{id}). To meet the HIPAA minimum necessary standard, provision workspace membership and API-key scopes so that only staff who need PHI can reach these endpoints. If your program requires per-role read restriction on message content, contact compliance@devotel.io before relying on it.

​

3. PHI audit log

{
  "id": "phi_abc123",
  "userId": "usr_xyz789",
  "resource": "message:msg_def456",
  "reason": "treatment",
  "accessedAt": "2026-04-02T10:30:00Z"
}

• Is append-only and cannot be modified or deleted
• Retains up to 10,000 entries per organization (oldest entries are automatically rotated)
• Is accessible to owner and admin roles via the dashboard or API
• Can be exported for external compliance audits

​

4. Data Retention

• Default retention period: 365 days (configurable: 30–3,650 days)
• Scope: Message content, call recordings, media attachments
• Mechanism: Automated background job scans for expired records and securely deletes them
• Exceptions: Audit logs and PHI access logs are retained independently of the data retention policy

PUT /api/v1/settings/hipaa
{
  "enabled": true,
  "data_retention_days": 365
}

​

5. BAA status lifecycle

• not_required — the organization has attested that no PHI is in scope (the default)
• pending — PHI is in scope and the BAA is awaiting execution
• executed — the BAA has been signed and is within its term
• expired — an executed BAA has passed its one-year term and must be re-executed

​

Executing the BAA

1. Check the current state — GET /api/v1/compliance/baa/ returns baa_status, the signer details, and days_until_expiry (owner/admin).
2. Attest that PHI is in scope — POST /api/v1/compliance/baa/require sets hipaa_required and moves a not_required organization to pending so the execute step opens (owner only). This starts the flow; it does not enable HIPAA mode.

POST /api/v1/compliance/baa/require
{
  "reason": "We began storing patient appointment reminders that contain PHI."
}

3. Execute the BAA — POST /api/v1/compliance/baa/execute records the agreement with a type-the-name click-wrap e-signature (owner only). The typed_attestation must exactly match signer_name. On success the organization is stamped executed with the signer, version, and date, which unblocks PHI sends and lets you enable HIPAA mode.

POST /api/v1/compliance/baa/execute
{
  "signer_name": "Jane Roe",
  "signer_email": "jane@example.com",
  "typed_attestation": "Jane Roe"
}

Legacy endpoint: PUT /api/v1/settings/hipaa/baa (body { signed, signed_at, document_url }) writes an older JSONB status mirror and is a fallback for pre-migration tenants only. Once an organization has a baa_status value, the HIPAA-enable and PHI-send gates read that canonical column and ignore this mirror — so a signed: true write here does not unblock sends or HIPAA mode. Use POST /api/v1/compliance/baa/execute instead.

PUT /api/v1/settings/hipaa/baa
{
  "signed": true,
  "signed_at": "2026-04-01T00:00:00Z",
  "document_url": "https://storage.devotel.io/baa/org_abc123.pdf"
}

​

PHI-Adjacent Audience Registry

GET /api/v1/compliance/hipaa/phi-audiences

{
  "audience_ids": ["list_9f2c1a", "seg_4b7e20"],
  "max": 500
}

PUT /api/v1/compliance/hipaa/phi-audiences
{
  "audience_ids": ["list_9f2c1a", "seg_4b7e20"]
}

Note: The registry is your organization’s attestation of which audiences contain PHI. It is tenant-owned: Devotel never designates audiences on your behalf, and the designation only takes effect once HIPAA is in scope for your organization.

​

Campaign Launch Precheck

1. Launch precheck (campaign-level, hard gate). Before a campaign leaves the draft/scheduled state, the launch precheck resolves its audience against the registry. If the audience is a designated list or segment and your organization’s BAA is not executed and in-term, the launch is refused with 422 HIPAA_BAA_REQUIRED. This keeps a PHI cohort out of campaign enrollment instead of burning wallet credit on thousands of per-recipient refusals. If the compliance state cannot be read, the precheck fails closed (500 HIPAA_BAA_GATE_DB_FAIL) rather than silently admitting a PHI audience.
2. Send gate (per-recipient, existing behavior). The per-recipient send gate documented under BAA — the HIPAA send gate still applies at message time and is unchanged.

{
  "error": {
    "code": "HIPAA_BAA_REQUIRED",
    "status": 422,
    "message": "The designated PHI-adjacent audience for this campaign requires an executed Business Associate Agreement (BAA) before outbound sends are permitted."
  }
}

1. Compose the registry — PUT /api/v1/compliance/hipaa/phi-audiences with the list/segment ids that contain PHI.
2. Verify the block — attempt the launch against a designated audience; expect 422 HIPAA_BAA_REQUIRED while the BAA is not executed/in-term.
3. Resolve the BAA — execute (or re-execute an expired) BAA via POST /api/v1/compliance/baa/execute as described in Executing the BAA.
4. Relaunch — once the BAA is executed and in-term, the precheck passes and the campaign launches normally.

• The registry governs campaign launches only. Legacy one-off per-recipient sends are still governed by the per-recipient send gate, which does not consult the registry.
• Only list- and segment-type audiences resolve against the registry at launch. Audiences assembled per contact (all contacts, CSV, manual entry) are evaluated recipient-by-recipient at send time instead.
• The wizard’s PHI-adjacent warning is advisory on the audience picker; enforcement lives at launch.

​

6. Disabling HIPAA Mode

POST /api/v1/settings/hipaa/reauth-challenge

{
  "challenge_token": "h7Yc...base64url...",
  "expires_at": "2026-04-02T10:35:00Z"
}

PUT /api/v1/settings/hipaa
X-Reauth-Challenge: h7Yc...base64url...
{
  "enabled": false
}

{
  "error": {
    "code": "REAUTH_REQUIRED",
    "message": "Fresh re-authentication is required to disable HIPAA mode. POST /settings/hipaa/reauth-challenge first, then retry within 5 minutes with X-Reauth-Challenge header."
  }
}

Note: The re-auth challenge gates only the enable → disable transition. Enabling HIPAA mode, and retention-only updates submitted while HIPAA mode is already disabled, do not require the header.

​

API Reference

​

Dashboard Configuration

1. HIPAA Mode Toggle — Enable/disable HIPAA mode (requires BAA)
2. BAA Section — Execute the BAA (type-the-name e-signature) and track its status, signer, and term expiry
3. Data Retention — Configure automatic data deletion period
4. PHI Access Log — View and export PHI access audit trail
5. PHI-Adjacent Audiences — Designate which contact lists and segments carry PHI; the campaign wizard warns on designated audiences and the launch precheck enforces the BAA gate

​

Infrastructure Safeguards

• Cloud SQL Encryption: All database storage encrypted with AES-256 by Google Cloud
• TLS 1.3: All data in transit encrypted with TLS 1.3
• VPC Isolation: Database accessible only via private IP within the VPC
• No Privileged Containers: GKE Autopilot prevents privileged container execution
• Secret Manager: All encryption keys and credentials stored in GCP Secret Manager
• Audit Trails: Google Cloud Audit Logs for infrastructure-level access tracking

​

Voice & Video Transcript PII/PHI Redaction

​

Redaction is on by default

Warning: Because this control applies to a whole deployment rather than a single organization, it cannot be scoped to one workspace. If your deployment handles PHI, redaction should stay enabled — confirm its status in writing with your Devotel contact as part of your BAA before you store any PHI.

​

Shared Responsibility

​

Incident Response

1. Devotel’s security team is notified within 1 hour via automated alerting
2. Affected organizations are notified within 24 hours per HIPAA Breach Notification Rule
3. PHI access logs are immediately preserved and exported for forensic analysis
4. Remediation steps are documented and shared with affected parties

​

Related pages

• DLP scanner — the send-time control that flags regulated data crossing an outbound message
• Pre-send policy scanner — the verdict and enforcement mode this control feeds