A HIPAA-compliant SMS vendor is not a vendor that promises "we are HIPAA compliant" in their sales deck. It is a vendor that will sign a Business Associate Agreement, can defend the boundaries of that agreement under audit, and has built the infrastructure to honor it on every single message your clinic sends. Most "HIPAA-friendly" SMS providers fail at least one of those three tests.
This guide walks through what a BAA actually covers when your healthcare organization uses SMS to communicate with patients, what it does not cover, and the questions to ask any vendor before you trust them with patient phone numbers.
What a BAA legally covers
A Business Associate Agreement is the contract HIPAA requires whenever a covered entity (your clinic, hospital, payer, or health-tech company handling PHI) shares Protected Health Information with a third party that needs it to do its job. For SMS, that third party is the messaging platform routing your patient-facing texts.
A real BAA does four things. First, it binds the SMS vendor to handle PHI under the same Security Rule and Privacy Rule obligations you operate under. Second, it requires the vendor to use safeguards (encryption in transit, encryption at rest, access controls, audit logs) appropriate to the risk. Third, it obligates the vendor to report breaches within a defined window and cooperate with your breach notification obligations. Fourth, it survives the relationship: PHI must be returned or destroyed when the contract ends.
That last piece is the one most teams overlook. A BAA is not a one-time signature. It is a continuing obligation that follows the data for as long as that data exists in any system the vendor touches.
What a BAA does not cover
Here is where teams get into trouble. A BAA covers the vendor's handling of PHI inside their platform. It does not cover your clinic's choices about what PHI you send in the first place. If you put a patient's full diagnosis and medication list into the message body and that message lands in a screenshot on a family member's phone, the BAA did not break. Your messaging policy did.
HIPAA's "minimum necessary" rule applies inside SMS the same way it applies inside email. The contents of an appointment reminder should be enough to remind, not enough to disclose. "Your appointment with Dr. Patel is Tuesday at 2pm" is reasonable. "Your follow-up for hypertension medication titration is Tuesday at 2pm" tells the recipient (and anyone who sees their phone) the patient's condition. The first message is appropriate for SMS. The second probably is not.
A BAA also does not cover what the patient does after the message arrives. SMS is delivered to a device the patient controls. The vendor cannot prevent screenshots, forwarded messages, or shared phones. Your consent flow needs to acknowledge that SMS is an inherently less private channel than a patient portal, and patients need to opt in knowing what they are signing up for.
The infrastructure questions to ask any vendor
Once you have a BAA, the real test is whether the vendor has the infrastructure to honor it. Ask these questions before you hand over a single patient record.
How is PHI encrypted in transit and at rest? "TLS 1.2 or higher in transit, AES-256 at rest" is the floor, not the ceiling. Ask where keys are stored, who has access, and how rotation is handled. If the vendor cannot answer crisply, they are not ready to handle PHI.
What is the audit log retention period and what is logged? Every message send, every recipient, every delivery state, every staff member who viewed or modified the record needs to be captured and retained for at least six years (the HIPAA documentation floor). If the audit log is "send timestamp and recipient phone," it is insufficient.
Who has access to PHI inside the vendor? Support staff, engineers, third-party subprocessors all need to be inventoried. Subprocessors are the most common gap: a vendor with a tight internal access policy might still route messages through a downstream SMS aggregator that has not signed a BAA. Ask for the full subprocessor list and verify each one has a BAA with your vendor.
What is the breach notification SLA? HIPAA gives you 60 days to notify affected patients of a breach. Your vendor needs to notify you fast enough that you can meet that clock. "We will let you know" is not a SLA. "Within 24 hours of discovery" is.
Can you produce a tamper-evident audit log for a regulator? If the answer is "we can pull a report from our logging system," that is not enough. The audit trail needs to be cryptographically verifiable or at minimum stored in an append-only system where retroactive modification is impossible.
What goes in the message body matters more than the BAA
The BAA is the legal floor. The harder discipline is the day-to-day choice of what your clinic sends. A healthcare SMS program that respects minimum-necessary will look different from a generic marketing SMS program.
Appointment reminders should reference the appointment and provider, not the condition. Prescription refill nudges should reference "your prescription" rather than the drug name. Lab result notifications should direct the patient to the portal, not deliver the result. Recall notices for vaccines or screenings should reference the service generically rather than naming a specific risk factor.
If your team genuinely needs to communicate richer clinical content over SMS (some workflows, like medication adherence check-ins for chronic care, benefit from it), the consent flow needs to explicitly cover that and your vendor needs to support per-patient content policies that downgrade automatically for patients who opted out of richer content.
How Tells handles healthcare SMS
Tells operates under a standard HIPAA BAA executed before any PHI flows. Encryption is enforced in transit and at rest. Every send is logged with a tamper-evident audit trail retained for the full HIPAA documentation window. Subprocessors are inventoried, each with their own BAA. We integrate directly with major EHR platforms so appointment reminders, prescription pickups, and follow-up care messages fire from the same source-of-truth your clinical staff uses.
What we will not do is promise that a BAA solves your minimum-necessary problem. Your content policy is yours to design and yours to defend. We give you the infrastructure to honor it. The discipline to use that infrastructure correctly is the work that keeps your clinic compliant.
If you are evaluating SMS vendors for a healthcare workflow and want a walkthrough of how Tells handles HIPAA at the infrastructure layer, book a demo and we will walk you through the BAA, subprocessor list, audit log structure, and integration patterns for your EHR. Or get started and start scoping the pilot.
Related reading: explore the full healthcare SMS playbook, see how AI SMS and voice agents handle two-way patient conversations under HIPAA, or review the Tells compliance and security stack in detail.
