Every vendor selling patient outreach automation today will tell you their platform is "HIPAA compliant." That phrase has become so overloaded as to be nearly meaningless during a procurement conversation. It tells you nothing about what they actually built, what they signed, how data flows through their system, or what happens when something goes wrong.
I've spent the better part of a decade building healthcare data systems, and the compliance question in patient outreach is genuinely complicated — not because the regulations are ambiguous, but because the specific technical implementation choices in an outreach system have material HIPAA implications that most vendors haven't fully worked through, or don't want to discuss until after you've signed.
This is an attempt to lay out the questions that actually matter, so that health system IT and compliance teams can evaluate vendors from a position of informed specificity rather than taking the "compliant" checkbox at face value.
What HIPAA Actually Requires for Patient Messaging
The HIPAA Privacy Rule and Security Rule together create the compliance framework for any system that stores, transmits, or processes PHI. For patient outreach automation — which by definition involves taking patient data from your EHR or data warehouse, processing it, and sending messages to patients — the requirements that matter most are:
- Business Associate Agreement (BAA) — any vendor who receives PHI from a covered entity must sign a BAA. This is non-negotiable under 45 CFR §164.308(b). If a vendor cannot produce a signed BAA before any PHI flows through their system, stop the conversation.
- Minimum Necessary standard — the Privacy Rule requires that PHI disclosed to or used by a business associate be the minimum necessary for the stated purpose. An outreach platform does not need your patients' full clinical record to send a refill reminder. The data elements in transit should be scoped to what the specific workflow requires.
- Technical safeguards for ePHI — the Security Rule requires encryption at rest and in transit, access controls, audit logging, and automatic logoff. These are implementation specifications under 45 CFR §164.312.
- Patient authorization for SMS/messaging — this lives in a complicated intersection of HIPAA, TCPA (Telephone Consumer Protection Act), and state-specific regulations. HIPAA permits treatment-related communications without explicit authorization in most cases, but the TCPA adds consent requirements for automated messaging that are separate from HIPAA entirely.
The SMS PHI Problem Most Vendors Sidestep
Here is the technical reality that gets glossed over in most vendor demos: standard SMS is not encrypted in transit. The cellular carrier network handles message delivery, and standard SMS messages are not end-to-end encrypted. They pass through carrier infrastructure, are temporarily stored in SMS gateways, and arrive on patient devices where they persist in the default messages app.
The HHS Office for Civil Rights has issued guidance stating that covered entities may use unencrypted email or SMS to communicate with patients — if the patient has been informed of the risk and the patient still requests that communication method. The operational question is how vendors document that informed consent at scale and what they do with patients who haven't affirmatively consented to unencrypted SMS.
Some vendors handle this by keeping the SMS message itself PHI-free — sending only a generic reminder with a link to a secure patient portal where the clinical information lives. Others argue that a medication name in an SMS doesn't constitute PHI under a reasonable reading. Others don't surface the question at all until your privacy officer asks.
We built Patientrig with HIPAA controls in mind from the data layer forward. Our default outreach messages are designed to be clinically actionable without requiring PHI in the message body itself — but we also built the BAA infrastructure and audit logging as foundational requirements, not retrofits. The point is that these architectural decisions have to be made early; they're very expensive to add later.
The BAA Is Necessary but Not Sufficient
Getting a BAA signed is the baseline. The questions that matter after the BAA is signed:
Where is PHI stored and who can access it?
Patient data flows from your EHR or data warehouse into the vendor's platform. Once it's there: Is it stored in a multi-tenant database where logical separation (not physical separation) keeps your patients' data separate from other customers? Who on the vendor's engineering or support team has access to production data? Under what circumstances, with what approval process?
Ask for the vendor's access control policy. Ask specifically whether engineers have direct production database access and what logging exists around that access. In an early-stage company, it's common for a small engineering team to have broad production access — that's not disqualifying, but it should be documented, logged, and covered by the BAA's workforce training requirements.
What is the data retention policy?
HIPAA doesn't mandate a specific retention period for most PHI types (though there are specific rules for medical records). But it does require that you have documented policies and that your business associates follow them. Does the vendor retain message logs indefinitely? Are patient contact records deleted when a patient is removed from your attributed panel? What is the process for responding to a patient's request for an accounting of disclosures?
What is the breach notification procedure?
Under 45 CFR §164.410, a business associate must notify the covered entity of a breach of unsecured PHI "without unreasonable delay and in no case later than 60 days following discovery." Ask the vendor specifically: what is their incident response playbook, who is the point of contact, and have they had any security incidents or breaches since they launched? The last question will make some vendors uncomfortable, which is informative.
TCPA Sits Alongside HIPAA — Not Under It
This is the compliance gap most healthcare IT teams don't anticipate until they're already running automated messaging campaigns. The Telephone Consumer Protection Act (TCPA) governs automated calls and text messages and is enforced by the FCC and through private litigation — not by HHS. The penalties are per-message, and TCPA litigation is well-funded by plaintiff attorneys because the statutory damages make class action suits economically attractive.
The relevant requirements for healthcare outreach:
- Automated or prerecorded calls/texts to a patient's cell phone require "prior express written consent" under TCPA. There is a healthcare exemption for calls/texts related to "emergency purposes" and for certain healthcare-related calls, but the exemption boundaries have been litigated extensively.
- The exemption does not cover marketing or mixed-purpose messages. If your refill reminder SMS includes a promotional element ("refill today and save"), you've likely moved outside the exemption.
- Patients can revoke consent at any time and the revocation must be honored promptly. Your outreach vendor must have a functioning opt-out mechanism that actually prevents future messages — not just logs the opt-out.
We're not saying TCPA compliance is impossibly complex to navigate — it isn't, with the right consent workflow built into patient onboarding. But it requires a consent management layer that is distinct from HIPAA authorization. Many healthcare outreach vendors treat them as the same problem. They aren't.
Questions to Ask Any Outreach Vendor
The following questions, asked directly, will tell you more about a vendor's real compliance posture than any security certification badge on their website:
- Walk me through exactly how PHI flows from our EHR to your system and where it is stored at each step.
- What does a message look like when it arrives on a patient's phone — does it contain PHI or a link to a secure portal?
- Who on your team has access to production patient data, under what conditions, and what is logged?
- How do you handle opt-outs and consent revocation, and what is the SLA for honoring them?
- Have you experienced any security incidents involving patient data? If yes, how did you respond?
- Can you show me your BAA template and your subprocessor list? (Vendors often use third-party SMS gateways, email delivery providers, or cloud infrastructure — those are subprocessors who also handle PHI.)
The subprocessor question is worth dwelling on. A patient outreach platform almost certainly uses at least one third-party SMS delivery provider to actually send the messages — companies like Twilio, Bandwidth, or similar. Each of those providers handles the PHI in the message and must also be a HIPAA business associate. Ask for the full chain: who sends the message, what do they sign, and where does the data go?
Internal IT and Compliance: What You Own
Vendor compliance is necessary but the covered entity's own compliance posture matters too. Specifically:
Your EHR or data warehouse export that feeds the outreach platform is a disclosure of PHI. That disclosure needs to be covered under the BAA and documented in your accounting of disclosures. The technical mechanism for that export — API, HL7 FHIR feed, SFTP flat file — should be reviewed by your security team to ensure it meets the encryption-in-transit requirement.
Your own staff who configure and manage the outreach platform have access to patient data through the vendor's UI. That access needs to be managed under your workforce access policies — right-sized to the job function, with audit trails, and with an offboarding process that revokes access when staff leave.
None of this is intended to make patient outreach automation sound too difficult to pursue — the operational and clinical value is real and well-documented. But the compliance infrastructure has to be built right from the start. Retrofitting security controls into a running patient engagement program is significantly harder than building them in before the first message is sent.
