HIPAA mode

HIPAA mode for organizations with a signed BAA: who turns it on, what it changes, what it refuses with hipaa_mode_restriction and what stays up to you.

HIPAA mode is one switch for your whole organization, for organizations that handle protected health information (PHI). It narrows where PHI can go and who at coss.com can reach it. The safeguards support your HIPAA compliance, which also depends on how you use coss.com.

Turning it on

You can't turn HIPAA mode on yourself, by any key or role. Ask for it from Settings → Compliance in the dashboard. Then:

  1. You sign a Business Associate Agreement (BAA) with coss.com, and the mode becomes a line on your contract.
  2. Your plan must include the audit log, as the Pro, Scale and Enterprise plans do, or your contract must grant it.
  3. coss.com staff turn it on and record the BAA's date and reference. It applies at once, including to messages still waiting to go out.

Only coss.com staff can turn it off. Billing never does: a contract ending or a downgrade leaves the mode on until someone decides otherwise. When it's turned off, requiring two-factor authentication stays on until an owner changes it.

Every member can see the mode's status, your BAA and the vendors below on Settings → Compliance. Your code can read it too, and so can agents, through the MCP server's get_account_status:

const { :  } = await ..();
.(?..hipaa_mode);
hipaa_mode: boolean | undefined

Whether the organization is in HIPAA mode, which refuses some requests.

What it changes

Sandbox environments reach no vendor and keep test messages for developers to read, so the limits on stored data, tracking and SMS apply to live environments only. Keep PHI out of them: they aren't covered.

A few details:

  • Mail coss.com sends for you. When Forms, Sign, Verify or Scheduling send from coss.com's own sender because you haven't set one, those emails get the same rules: no screening, no stored content, required TLS and hidden from staff.
  • Dropped email. coss.com may not hear that a message was dropped for lack of TLS, so its recipient can stay sent.
  • Dedicated IPs. Your mail uses shared IPs until your dedicated IPs require TLS, usually within minutes of turning the mode on.

What it refuses

A request the mode refuses fails with 403 permission_error and the code hipaa_mode_restriction, whatever the key's permissions. The SMTP relay answers 550. Retrying won't help, and neither will another key.

const {  } = await ..({
  : "+14155550123",
  : "+447700900123",
  : "Your appointment is confirmed.",
});
if (?. === "hipaa_mode_restriction") {
  // Not retryable: reach this recipient another way.
}

Other things stop quietly instead. coss.risk.assess() answers without content scores, and Forms and Scheduling skip their content checks. Scheduling skips SMS reminders to numbers it can't text.

What stays up to you

  • Only send PHI once your BAA is in place, and only from live environments. Sandbox environments keep test emails and aren't covered by the controls above.
  • Discarding only covers sent email and SMS. Received email and SMS, broadcasts, contacts, form submissions and bookings stay stored under your BAA for their normal retention periods.
  • Keep PHI out of email subject lines and metadata such as tags and categories. Discarding removes a subject only once the email is finished, and tags and categories are kept.
  • Webhook endpoints and log drains deliver to services you choose, so you need your own BAA with them where they receive PHI. Form submission webhooks include what was submitted.
  • Calendars connected to Scheduling (Google, Microsoft, CalDAV) and Zoom receive event titles, under your own agreements with those providers.
  • A captcha you configure on a form sends the submitter's address to that captcha provider.

Vendors

Last updated