Approach 1: use Pusher Channels as a conduit
“entities that act as mere conduits for the transport of protected health information but do not access the information other than on a random or infrequent basis are not business associates.” Pusher Channels is a “mere conduit” for all data sent in : it does not store or access the “data” field other than to forward it to clients that are subscribed at that moment. Further, when using our feature, Pusher is unable to read the content of the “data” field, because it is encrypted with a key that, by design, Pusher does not have access to. Therefore, one can be HIPAA-compliant while using Pusher Channels by ensuring that:
- Any Protected Health Information (PHI) sent via Pusher Channels is sent in the “data” field of an event.
- Such events are only sent on private-encrypted- channels.
- Such events are only sent by our official SDKs supporting this feature.
- Your auth endpoint only allows clients to subscribe to such a channel if it should have access to said PHI.
Approach 2: avoid sending PHI via Pusher Channels
Alternatively, you can avoid transmitting PHI via Pusher Channels. When using Pusher Channels in this way, Pusher is neither a business associate (because its activities do not ), nor a conduit (because its activities do not “transport … protected health information”).
To achieve this, you can instead transmit opaque identifiers of PHI, which recipients can then use to fetch the PHI from your system. For example, suppose you are building a postal prescription service, which needs to display a realtime list of pending orders in each pharmacy. You can implement this using Pusher Channels. Give each order an opaque ID, and transmit this ID to the client. When the client receives a new order ID, it should then use it to fetch the order details from your server (using your existing auth mechanisms).
If you have further questions, we're happy to help! Please contact