The Compliance Foundation: HIPAA, TCPA, and Consent

Last updated: June 2026

Two separate rulebooks govern most healthcare notifications, and you have to satisfy both at the same time. HIPAA controls the data. TCPA controls the contact. This chapter covers what each one requires from a notification system, and the design pattern that keeps you compliant without making your notifications useless.

What HIPAA requires from a notification system

If a notification contains PHI, HIPAA requires you to send it through a platform with encryption, access controls, audit logging, and a signed Business Associate Agreement (BAA). Plain consumer SMS and standard email don't meet that bar, because they aren't encrypted end to end, they sit on carrier and provider servers, and they leave no audit trail.

A BAA is non-negotiable. Any vendor that touches PHI on your behalf, including your notification provider, has to sign one. If a provider won't sign a BAA, you can't route PHI through it, no matter how secure the marketing page claims it is.

Two more HIPAA rules shape notification content directly:

• Minimum necessary. Include only the information the message actually needs. An appointment reminder needs a date, a time, and a generic location, not a diagnosis or the name of an oncology clinic.
• Right to alternative communications. Under the Privacy Rule, patients can request to be contacted by a specific method, like SMS, even one that carries some risk. If the request is reasonable, you generally have to honor it, warn the patient of the risk, and document that you did.

How to decouple the alert from the protected health information

The core engineering principle for HIPAA-compliant notifications is to decouple the alert from the data. The notification says that something happened. The sensitive detail stays behind authentication, in your app, portal, or in-app inbox.

So instead of texting a result, you text a nudge to go read it:

{
  "message": {
    "to": { "phone_number": "+15555550123" },
    "content": {
      "title": "Lab results",
      "body": "Your HbA1c is 8.2%, consistent with type 2 diabetes. Call the clinic to discuss."
    }
  }
}

That payload puts a diagnosis into an unencrypted channel. This one doesn't:

{
  "message": {
    "to": { "phone_number": "+15555550123" },
    "template": "results-ready",
    "data": { "portal_url": "https://portal.example-health.com/results" }
  }
}

The template renders something generic: "Your latest results are ready. Sign in to your secure portal to view them." Same urgency, none of the disclosure.

The hard part is enforcing this at scale, across dozens of templates and every engineer who can trigger a send. The reliable way to do it is template categorization: mark which templates carry sensitive content, and make it structurally impossible for those to render into an insecure channel like SMS or push, regardless of what data the upstream service passes in. Channel choice then follows sensitivity:

TCPA, consent, and opt-outs

TCPA is a separate track from HIPAA, and a BAA does nothing for it. The Telephone Consumer Protection Act governs automated calls and texts, and it applies to healthcare. Before you send an automated text, you need documented prior express consent. For anything promotional, the bar rises to prior express written consent that's specific to your organization and not bundled into an unrelated agreement.

Three things follow from that:

• Every message needs a working opt-out. A STOP reply has to be honored immediately, confirmed once, and respected across every sender pool. If someone opts out of one workflow, don't reach them from another.
• Consent has to be logged. Capture the exact disclosure text shown, a timestamp, the opt-in or opt-out state, and proof that suppression synced everywhere.
• A2P 10DLC registration is a hard gate. In the US, automated texts sent over standard 10-digit numbers have to be registered. Carriers actively block unregistered traffic, so your system can report a message as sent while the carrier silently drops it.

Audit trails, preference logs, and proving compliance

Compliance isn't only about sending correctly. It's about being able to prove, later, that you did. When an auditor or a patient asks what was sent, to whom, on what channel, and under what consent, you need an answer in minutes, not a database archaeology project.

That means two kinds of logging. Delivery logs show what went out and what happened to it. Preference and consent logs show what each recipient agreed to and when they changed it. Per-channel and per-topic preferences aren't only a user-experience nicety here; they're the mechanism that proves you only contacted people who said yes, on the channels they approved.

This is one of the few places in the guide where a notification platform earns a direct mention. Courier's preference management keeps a history of every change, and its healthcare posture covers the exact controls this section is about: it's HIPAA compliant under a signed BAA, with SOC 2, encryption, audit logs, and data residency in both US and EU data centers. That last point matters more than it looks. If your patients or participants are in the EU, where they're processed and stored is a GDPR question as much as a HIPAA one, so being able to pin notification data to a US or EU region is a genuine requirement for those teams. If you build the pipeline yourself, plan to build this evidence layer too. It's not optional, and it's easy to underestimate.

Frequently asked questions

Is texting patients a HIPAA violation?

Not inherently. Texting patients is allowed if the content and the platform meet HIPAA's requirements. A text with no PHI, like "Your results are ready, sign in to view them," is low risk. A text containing PHI is only compliant when it's sent through a secure, BAA-covered service configured to HIPAA's security standards. Texting PHI from a personal phone or a basic consumer tool is where violations happen.

Do I need a BAA to send appointment reminders?

If the reminder contains PHI, yes, you need a BAA with whatever service sends it. Many teams avoid the question by keeping reminders minimal (date, time, generic location), but even then, using a vendor that will sign a BAA is the safe default, because the line between "not PHI" and "PHI" is thinner than it looks.

Does HIPAA or TCPA consent cover automated texts?

You generally need both, and they're different. HIPAA consent governs sharing PHI. TCPA consent governs contacting someone with an automated system. An automated appointment reminder or balance text can require HIPAA consent for any PHI and TCPA consent for the automation, so build your intake to capture both.

What is A2P 10DLC and do medical apps need it?

A2P 10DLC is the US registration system for application-to-person texting over standard 10-digit numbers. If your medical or healthcare app sends automated SMS to US recipients, you need it. Carriers block unregistered traffic, which means unregistered messages can fail to deliver even when your software shows them as sent.