HIPAA-Compliant Customer Engagement: A Field Guide for Marketing Teams

Healthcare marketing sits at a unique intersection: you're trying to reach patients with timely, relevant messages, but the data you're working with is some of the most protected in the world. HIPAA (the Health Insurance Portability and Accountability Act) isn't just a box for your legal team to check. The messages you write, the segments you build, and the subject lines you test are all within scope.

Any information that ties a person's identity to their health condition, healthcare visits, or health payments is considered protected health information (PHI). That includes the obvious stuff (diagnoses, prescriptions, lab results) and things that might surprise you, like the fact that someone has an appointment at a specific provider, or that they're a patient at all.

The penalties for violations are real. Civil penalties can reach hundreds of thousands of dollars per violation, with annual caps in the millions. Willful misuse of PHI can also trigger criminal liability, including substantial fines and imprisonment. More practically: if a patient feels their privacy was violated by your message, you lose their trust permanently.

The good news is that HIPAA-compliant marketing is very doable. It mostly comes down to being thoughtful about what data lives where, what you put in message content, and how you've gotten permission to use it.

The five areas where marketing teams most often slip up

1. What shows up on the lock screen
Push notifications and SMS messages display on a phone's lock screen by default, which means anyone nearby can see them without unlocking the phone. The same goes for email subject lines and preview text, which surface in notification banners and inbox previews.

If your message content reveals anything about a person's health, you've disclosed PHI to anyone who happens to glance at the screen. Even well-intentioned reminder messages can be a problem if they're specific.

⚠ Watch out: Ask yourself before sending: If someone other than this patient saw this message, would they learn anything about the patient's health? If the answer is yes, rewrite it.

2. What you name your segments and tags
Building segments based on health attributes is normal and useful. The risk is in how you label them inside your platform. A segment named "Diabetes - Type 2" or a tag like diagnosis: depression means your engagement platform now contains plaintext PHI, visible to anyone with platform access.

The fix: use internal codes. Name the segment "Condition 214" and maintain a separate, secured mapping document that only authorized team members can access. Your messaging platform should never be a readable database of health conditions.

3. Message content that reveals a health context
This is where small word choices have big compliance consequences. Here are examples of the same message, written two ways:

The pattern is consistent: keep message content generic enough that an outside observer can't infer anything about the recipient's health. Sensitive details (results, diagnoses, specialist names) belong behind a secure, authenticated portal, not in a push notification.

4. Authorization, not just opt-in
Most marketing teams are used to consent-based opt-ins. HIPAA adds a specific requirement on top of that: any use of PHI for marketing must be covered by a valid written authorization: a dedicated document that specifically describes how health information will be used for marketing purposes.

⚠ Important distinction: A generic "I agree to receive communications" checkbox, even if prominently displayed, does not meet HIPAA's authorization standard. The patient needs to explicitly agree to the specific use of their health information for marketing. When in doubt, check with Legal before building your opt-in flow.

Plain language matters here especially. Patients who aren't native English speakers or who aren't familiar with legal terminology need to be able to understand what they're signing up for.

5. What data you send to OneSignal
Not all patient data belongs in your messaging platform. Before you configure any integration, categorize your data into three buckets:

• Non-PHI (safe to send): Things like membership tier, preferred channel, language preference, and app behavior. No restrictions.
• Operational PHI (send carefully, anonymize where possible): Appointment dates, provider first names, general care status. Needed to send useful messages, but handle with care.
• Sensitive PHI (never send to OneSignal): Diagnoses, lab results, prescriptions, billing details, insurance info. Keep these in your EHR. They should never leave it.

⚠ OneSignal BAA restrictions: OneSignal's Business Associate Agreement expressly prohibits ingesting the following PHI types into the platform: medical diagnoses, medical records, medical images, patient billing information, test results, genetic information, STI information, substance abuse information, and mental health information. If you're unsure whether your use case is acceptable, contact the Security & Legal team before configuring your integration.

Setting up OneSignal for HIPAA-compliant campaigns

OneSignal has completed a HIPAA risk assessment covering both the Security Rule and Privacy Rule, and offers Business Associate Agreements (BAAs) to Enterprise Plan customers. A BAA is a legal requirement before any third-party platform can process PHI on your behalf. To request a BAA or learn more, contact the OneSignal sales team.

Once your BAA is in place, here's how to configure your setup:

Use External IDs to unify patient profiles. Assign each patient an External ID so their push subscription, email address, and phone number are all linked to a single profile. Without this, the same patient on multiple channels could receive duplicate messages, or receive a message on a channel they didn't authorize.

Code your segments and tags. Use internal codes instead of plaintext health terminology in any segment names or user tags. "Condition 214" keeps sensitive data out of your platform. Maintain the key in a separate, access-controlled document.

Configure role-based access. HIPAA's minimum necessary standard means each person on your team should only have access to the PHI they need to do their job. Use OneSignal's team member roles to restrict who can view user data, import/export records, and manage API credentials. Note: Granular roles (Editor, Composer, Finance, Operations) require a Professional or Enterprise plan. Confirm your plan includes the roles you need before using this as a compliance control.

Keep sensitive details behind a secure portal. If a message relates to something sensitive (lab results, a care plan update, a billing statement), keep the notification generic ("You have a new secure message") and direct the patient to an authenticated portal to view the actual details after logging in. The message is the nudge. The portal is where PHI lives.

Pre-launch compliance checklist

Run through this before any healthcare campaign goes live:

• BAA in place. A signed Business Associate Agreement exists with OneSignal and every other vendor that processes PHI.
• Data categorized. You've mapped patient data into non-PHI, operational PHI, and sensitive PHI. Only the first two categories should go into OneSignal.
• Segments and tags anonymized. No plaintext health conditions, diagnoses, or treatment types in your platform.
• Message content reviewed. Every push, SMS, subject line, and preview text has passed the lock screen test.
• Authorization documented. Patient written authorization for marketing use of PHI is in place: explicit, separate from other authorizations, and in plain language. A generic opt-in does not suffice.
• Access roles configured. Team members only have access to the data and functions they need. Import/export is restricted to admins.
• Secure portal in place. Any sensitive health information is accessible only through an authenticated portal, not in message content.
• Audit and training schedule set. Regular risk assessments are on the calendar. Employees with PHI access are trained at least annually. There's a process for revoking access when someone's role changes.

Have questions about OneSignal's infrastructure or HIPAA setup?

If you have specific questions about how OneSignal's platform handles PHI, what our BAA covers, or how to configure your integration for your use case, contact the OneSignal team. We're happy to walk you through the technical and operational details of our infrastructure.

For questions about your own legal obligations under HIPAA, including authorization requirements, data handling policies, and compliance programs, please consult your own legal counsel. This guide is not legal advice.

This guide covers general best practices based on HIPAA's Privacy and Security Rules. It is not legal advice and does not constitute a legal opinion on your organization's compliance obligations. Every organization has unique data flows, risk profiles, and legal requirements. Always consult your own legal and compliance counsel before making decisions about how to handle patient data. HIPAA compliance is an ongoing responsibility, not a one-time setup task.