Is texting patients a HIPAA violation?

You want to text patients. Appointment reminders, a "your results are ready" nudge, a balance notice. It's the channel people actually read, and it beats playing phone tag. Then someone on the team asks the question that stalls the whole project: "Wait, is that even allowed under HIPAA?"

Here's the short answer. No, texting patients is not automatically a HIPAA violation. Texting patients is allowed when the message contains no protected health information (PHI) or when it's sent through a secure, HIPAA-compliant platform under a signed business associate agreement (BAA). It becomes a violation when an unsecured text carries PHI, or when you text without the consent the TCPA requires. Get the content and the pipeline right and you can text patients all day. Get them wrong and a routine reminder turns into a reportable breach.

The whole thing comes down to one engineering decision: decouple the alert from the protected health information. Tell someone that something happened, and keep the sensitive detail behind authentication. Everything else in this post (the minimum-necessary rule, when you need a BAA, consent) follows from that one move. One honest caveat before we start: we're engineers, not your compliance lawyers. What follows is the engineering reality of staying on the right side of the line, not legal advice.

What actually makes a text a violation

A text to a patient crosses into a violation in one of two ways.

The first is protected health information (PHI) traveling over an unsecured channel. PHI is any health data tied to an individual: a diagnosis, a treatment, a test result, or even the bare fact that someone is your patient. And it composes. A name on its own isn't PHI. But a name, plus the date of an appointment, plus the fact that it's at an oncology clinic, together can be. That combination in a plain text message is the classic violation.

The second is contacting someone you don't have permission to contact, or sending through a pipeline that doesn't meet the bar. This is less about content and more about consent and infrastructure, and it's where the TCPA enters the picture later in this post.

The reason plain consumer SMS is risky for PHI is structural. Standard text messages aren't encrypted end to end. They pass through and sit on carrier servers. They leave no audit trail you control. So a text that carries PHI through a normal SMS pipeline fails the HIPAA Security Rule's requirements for encryption, access controls, and audit logging before anyone even reads it.

How to text patients without sending PHI

The core principle for texting patients safely is to separate the notification from the data. The text says something happened. The sensitive specifics live behind a login, in your app, your patient portal, or an in-app inbox.

So instead of texting the result, you text a nudge to go read it. Here's the version that creates a problem:

That text puts a diagnosis into an unencrypted channel. Anyone who picks up the phone, or just glances at the lock screen, reads it: "Your HbA1c is 8.2%, consistent with type 2 diabetes. Call the clinic to discuss." Here's the version that doesn't:

That message is generic by design: "Your latest results are ready. Sign in to your secure portal to view them," with a link to sign in. Same urgency, same prompt to act, none of the disclosure. The patient still gets pushed to the information immediately. The information itself never touches the text.

This pattern covers the large majority of patient texting. Appointment reminders, results-ready alerts, billing notices, and care nudges can almost all be written as "something is waiting for you, here's where to see it."

Minimum necessary, applied to a text

HIPAA has a rule called minimum necessary: use and disclose only the information a task actually requires. Applied to a text message, it's a useful filter for what belongs in the body and what doesn't.

It matters more for a text than for most channels, because of where a text lands: on a lock screen without a password, on a phone shared with a partner or a kid, sometimes on a recycled or mistyped number. The portal sits behind a login. The text doesn't. So the question for every field isn't "is this true," it's "am I okay with this showing on a screen I don't control."

An appointment reminder is a good test case. What it legitimately needs is small. What pushes it into PHI territory is the detail that hints at why. The trick is to look at each piece of information you want to send and ask what the safe version of it is. Most fields have one. The same appointment reminder can carry the what and when without the why.

The pattern holds across almost every message: keep the date, time, location, and a prompt to act, and push anything that hints at why behind a sign-in.

Watch the combinations, too. Individually safe fields can disclose when they stack up, and the sneakiest culprit is the sender. A perfectly generic reminder still gives away the condition if it comes from "Riverside Oncology" or "Main Street Fertility." Check what your "from" name and any branding reveal before you worry about the body.

A few things don't have a safe version. No phrasing makes them okay in a plain text body, so keep them out entirely and let the portal carry them:

• Diagnoses, conditions, or anything that names one ("your diabetes," "the biopsy")
• Test results, lab values, or imaging findings
• Medication names, dosages, or prescription details
• Mental health, substance use, reproductive, or HIV/STI information, which gets extra protection under state and federal law
• A provider or department whose name alone reveals the condition ("the oncology team called")
• Identifiers that aren't needed to act on the text: medical record numbers, account numbers, full date of birth, Social Security numbers, or insurance IDs

There's one wrinkle worth knowing. Under the Privacy Rule, patients have a right to request confidential communications: they can ask to be reached a specific way, including a less secure one like plain SMS. If the request is reasonable, you honor it, warn them of the risk, and document both.

When you need a BAA to text patients

A business associate agreement (BAA) is the contract a vendor signs before it's allowed to handle PHI on your behalf. The rule for texting is clean:

If a text contains PHI, you need a secure platform under a signed BAA. Full stop. "Secure" here means real controls: encryption, access controls, and audit logging, none of which plain SMS or standard email provides. And if a vendor won't sign a BAA, you can't route PHI through it, no matter what its marketing page promises.

If a text contains no PHI, you technically don't need a BAA for that message. But a BAA is still the safe default, for one practical reason: the line between "not PHI" and "PHI" is thinner than it looks, and it tends to move as your templates grow. A reminder that's generic today gets a "helpful" field added next quarter, and suddenly it's disclosing a specialty. Sending everything through a BAA-covered, HIPAA-compliant pipeline means a slip in content doesn't also become a slip in infrastructure.

The TCPA is a separate gate, and a BAA does nothing for it

Here's the trap. You strip every text of PHI, sign your BAA, and assume you're done. You're not, because content is only half the problem. The Telephone Consumer Protection Act (TCPA) governs contacting people with automated systems, and it applies even to a text with zero PHI in it.

Three things follow:

• You need documented consent before you text. For automated texts you need prior express consent, and for anything promotional the bar rises to prior express written consent that's specific to your organization.
• 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 appointment reminders, don't reach them from your billing number next week.
• In the US, automated SMS needs A2P 10DLC registration. This is the registration system for application-to-person texting over standard 10-digit numbers. Carriers actively block unregistered traffic, which produces the worst kind of failure: your system reports the message as sent while the carrier silently drops it. The patient never hears about the appointment, and your logs say everything's fine.

So "no PHI" doesn't mean "no rules." A compliant patient text is one that's clean on content (HIPAA), permitted to send (TCPA consent), and actually deliverable (A2P 10DLC).

Enforcing it at scale: template categorization

Everything above is easy to honor when one careful engineer writes one text. The real problem shows up at scale, when you have dozens of templates and a handful of services that can all trigger a send. It only takes one template, or one well-meaning change to an existing one, to drop PHI into an SMS body. Code review catches some of it. It will not catch all of it forever.

The durable fix is to make the unsafe send structurally impossible rather than merely discouraged. Categorize your templates by sensitivity, and bind sensitive content to secure channels only, so a template carrying PHI cannot render into SMS or push regardless of what data the upstream service passes in.

This is where a notification platform earns its place in a healthcare stack. With Courier, channel routing and template configuration live in the notification layer instead of being re-implemented in every service, so you can enforce "this category never goes to SMS" once, centrally. A results-ready nudge is allowed to fan out to SMS, push, and the in-app inbox because it's generic by construction. A template that renders clinical detail is restricted to the in-app inbox or portal, behind authentication.

import { CourierClient } from "@trycourier/courier";

const courier = new CourierClient({ authorizationToken: process.env.COURIER_TOKEN });

// A results-ready nudge: generic by design, safe to fan out to SMS.
await courier.send({
  message: {
    to: { user_id: "patient_4821" },
    template: "results-ready",
    routing: { method: "single", channels: ["sms", "push", "inbox"] },
    data: { portal_url: "https://portal.example-health.com/results" },
  },
});

The point isn't the exact config. It's that the rule lives in one place and holds for every send, so compliance doesn't depend on every engineer remembering it every time. Courier runs this on HIPAA-compliant infrastructure under a BAA, with encryption, audit logs, and a delivery and preference history, which is also the evidence layer the next section depends on.

Wrapping up: a pre-send checklist

Texting patients is allowed. The job is making sure each text is clean on content, permitted to send, and deliverable. Before you text a patient, run the list:

• PHI is out of the body. The text nudges, it doesn't disclose. Sensitive detail stays behind login.
• You're sending minimum necessary. Date, time, generic location, and a link, nothing that hints at a condition.
• Consent is logged. You have documented TCPA consent, with the disclosure text and a timestamp.
• Opt-out works everywhere. STOP is honored immediately and suppression syncs across every sender.
• You're A2P 10DLC registered. Your US SMS traffic won't be silently dropped.
• A BAA is signed. Your sending platform is HIPAA-compliant, and sensitive templates are locked to secure channels.

Nail those six and texting patients stops being a compliance risk and goes back to being what you wanted it to be: the fastest way to reach someone.

For the full picture, including how this fits into staffing, broker, survey, and compliance notifications, see Courier for healthcare. If you want to see how the compliance posture is built, read how Courier became HIPAA compliant.

Frequently asked questions

Is texting patients a HIPAA violation?

Not inherently. Texting patients is allowed when the content and the platform both 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.

Are appointment reminders considered PHI?

They can be. The fact that someone is your patient, plus an appointment date and the name of a specialty clinic, can together constitute protected health information. The safe practice is to keep reminders minimal: date, time, and a generic location, with no diagnosis, provider specialty, or reason for the visit unless the patient has explicitly asked for that detail.

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.

Related resources:

• Courier for healthcare
• How Courier became HIPAA compliant
• Notification strategy for regulated industries