The question gets asked constantly and answered badly. A vendor that advertises a channel as HIPAA compliant is describing its own contractual posture, not a property of the technology. RCS is a transport. What determines whether your programme is lawful is the content you send over it, the agreements you hold with everyone who touches that content, and the safeguards around access to it.
Why business RCS is not end-to-end encrypted
This is the part that matters most and gets skipped most often. Person-to-person RCS chats are now end-to-end encrypted, following GSMA Universal Profile 3.0 and Apple's rollout in iOS 26.5. Business messaging is different. An application-to-person message has to be processed by the sending platform in order to be rendered, routed, measured, and failed over to SMS, so it is encrypted in transit rather than end to end. Is RCS encrypted sets out the distinction in full.
The consequence for healthcare is direct. Your messaging provider is handling the content, which makes them a business associate if that content includes PHI. That is not disqualifying, it is simply the fact that has to be papered before you send.
The approach that actually works: keep PHI out
The most robust healthcare messaging programmes do not try to make the message safe to contain clinical detail. They design the message so it never contains any. A date, a time, and a practice name is routine operational information. A condition, a medication, a test result, or a specialty that implies a diagnosis is not.
Where a workflow genuinely needs clinical detail, the pattern is to prompt in the thread and put the detail behind authentication. RCS is unusually good at this, because a suggested action button can carry the patient straight into your authenticated portal in one tap, with no link to mistype and no ambiguity about whether the destination is genuine.
Verified sender identity helps for a separate reason. On SMS a patient cannot reliably tell your practice from a phishing attempt, and healthcare is a heavily impersonated category. On RCS the brand name, logo, and checkmark are rendered by the phone from the approved sender record, so an attacker cannot reproduce them by putting your practice name in message content. That is a real patient-safety improvement whether or not HIPAA is the reason you are asking.
What to establish with a provider before you send
- Whether they will sign a Business Associate Agreement, and what it covers. Ask early, because the answer shapes the design of everything else.
- How long message content and delivery logs are retained, and whether retention is configurable.
- Who inside the provider can view message bodies, and how that access is controlled and logged.
- How consent and opt-out are recorded, because HIPAA sits alongside TCPA obligations rather than replacing them.
- What happens on SMS fallback, since a message that falls back is carried by the mobile carriers under their own terms.
Our position is the one already stated on the healthcare page: design the programme so PHI stays out of the thread, and if your programme requires a Business Associate Agreement, raise it with us directly rather than assuming one is in place.
- HIPAA compliance is a property of a programme, not of a channel; no provider can make RCS inherently compliant.
- Business RCS is encrypted in transit but processed by the sending platform, so it is not end-to-end encrypted.
- A provider handling PHI on your behalf is a business associate and needs a signed BAA.
- The strongest design keeps PHI out of the message and uses a suggested action to move the patient into an authenticated portal.
- HIPAA does not displace TCPA: consent and opt-out handling still apply to every healthcare message.