HIPAA-Compliant Messaging: What You Actually Need (and What You Don't)

If you're building any healthcare app in the US — patient portals, telehealth, care coordination tools — HIPAA is unavoidable. And whenever messaging is involved, the compliance question becomes: what does HIPAA actually require for encryption?

The answer is more specific (and more achievable) than most guides suggest. Let's cut through the noise.

HIPAA's technical safeguards: the relevant rules

HIPAA's Security Rule (45 CFR §164.312) defines technical safeguards for electronic Protected Health Information (ePHI). The relevant requirements for messaging are:

Note that encryption is "addressable" (not "required") — but in practice, if you don't implement it, you need a documented risk analysis explaining why an alternative safeguard is equivalent. For internet transmission of PHI, that analysis is very hard to make. Encryption is the standard approach.

What level of encryption satisfies HIPAA?

HIPAA defers to NIST for cryptographic standards. The relevant guidance is NIST SP 800-111 and NIST SP 800-52.

For transmission:

• TLS 1.2 or 1.3 with approved cipher suites — satisfies the transmission security rule for most use cases
• End-to-end encryption using strong primitives (AES-256, XSalsa20) — satisfies it and protects against server compromise

TLS alone is sufficient for HIPAA compliance. But there's a critical nuance.

Why TLS alone isn't enough for your liability

TLS protects data between your users and your server. Once the message lands on your server, it's decrypted. Your server now holds PHI in plaintext (or encrypted with a key you control).

This creates two problems:

1. You become a covered entity holding plaintext PHI — breach of your server = breach notification, OCR investigation, potential fines
2. Business Associate Agreements (BAAs) — every vendor with access to your plaintext PHI needs a BAA. Your cloud provider, your database vendor, your analytics tool.

End-to-end encryption eliminates problem #1 entirely: your server never holds plaintext PHI. The ciphertext is useless without the private keys, which stay on users' devices.

Implementing E2E encryption for HIPAA messages

Here's what compliant E2E messaging looks like in code:

// Patient sending a message to their provider
import { useE2EChat } from "@encra/react"

function PatientMessaging({ providerId }: { providerId: string }) {
  const { messages, isReady, sendMessage } = useE2EChat({
    apiKey: process.env.NEXT_PUBLIC_ENCRA_API_KEY!,
    userId: patient.id,
  })

  return (
    <div>
      {messages.map((msg) => (
        <MessageBubble key={msg.id} message={msg} />
      ))}
      <MessageInput
        onSend={(text) => sendMessage(providerId, text)}
        disabled={!isReady}
      />
    </div>
  )
}

What Encra handles automatically:

• X25519 key exchange (ECDH with Curve25519)
• XSalsa20-Poly1305 message encryption
• Double Ratchet for forward secrecy
• Keys stored in IndexedDB (never transmitted)

The server receives and relays encrypted blobs. No PHI at rest on the server.

The BAA question

If you use Encra's managed key server, you'll want a BAA with Encra. We provide one — reach out at encra.dev/contact.

If you self-host the key server (one Docker command: docker run -p 3001:3001 encra/server), you control the infrastructure entirely and the BAA is between you and your infrastructure provider.

For most HIPAA-covered apps, the self-hosted option is the cleanest approach: full data residency, no third-party BAA chain.

What else HIPAA requires beyond encryption

Encryption satisfies the transmission security requirement but HIPAA's Security Rule has more:

• Access controls — Unique user IDs, session timeouts, role-based access. These are your responsibility, handled by your auth system.
• Audit logs — Log who accessed what and when. Log message send events (not content — you don't have plaintext anyway). Your application layer handles this.
• Workforce training — Document that your team understands PHI handling.
• Risk analysis — Annual assessment of threats to ePHI. Document your encryption choice here.

The encryption piece is actually the easiest part of HIPAA compliance. The organizational controls (policies, training, BAAs with every vendor) are where most companies spend most of their time.

The short answer

For messaging in a HIPAA-covered app:

1. Use E2E encryption — protects against server compromise, simplifies your BAA chain, removes PHI from your server
2. Self-host the key server if you want full data residency control
3. Log message events (timestamps, sender/recipient IDs) at the application layer — never log content
4. Sign BAAs with any vendor who processes or could access PHI (even encrypted)

Encra covers #1 and #2. You handle #3 and #4 in your application.

Need a BAA? Contact us. Building something for healthcare? Talk to the team — we've helped several telemedicine platforms navigate this.