Healthcare organizations run the most complex messaging infrastructure of any industry. The IT challenge: EHR systems (Epic, Cerner, Oracle Health) generate clinical notifications that must reach care teams on whatever messaging platform the care team uses. The messaging infrastructure: a mix of Slack (administrative and informatics teams), Teams (corporate and administrative functions), Zoom (telemedicine and care coordination), and in some cases legacy pager systems being phased out.
This post covers how messaging bridges fit alongside EHR notification architectures.
The EHR Notification Problem
Modern EHR systems support HL7 FHIR notifications and webhook-style event publishing for clinical workflow events:
- Admission/discharge/transfer (ADT) events
- Lab result availability alerts
- Critical value notifications (abnormal lab results requiring immediate action)
- Medication order alerts
- Care team assignment notifications
- Patient deterioration scores (e.g., NEWS2 score threshold alerts)
These notifications must reach the right care team member on the right platform, reliably and immediately. The challenge: care teams are not standardized on a single messaging platform. Nursing staff may use Zoom Team Chat via their mobile devices. Attending physicians may use Teams. Informatics and clinical operations may use Slack.
The Architecture
A HIPAA-compliant notification routing architecture for healthcare organizations:
Layer 1: EHR Notification Source Epic Hyperspace or Cerner notifications publish to an HL7 FHIR subscription endpoint or via a certified EHR integration engine (e.g., Mirth Connect, Rhapsody). The integration engine normalizes the notification format and publishes to a healthcare-specific message bus.
Layer 2: Clinical Notification Router A clinical notification router (part of the organization's clinical communication and collaboration platform, or CCCP) receives the normalized notification, applies routing rules (which care team receives this notification, based on patient assignment), and formats the message for the target platform.
Layer 3: Messaging Bridge The clinical router — or the native Slack, Teams, or Zoom app of your clinical communication platform — delivers the notification on each platform. A messaging bridge such as SyncRivo does not relay messages posted by bots or apps, so it is not the delivery path for EHR notifications. Its role is bridging the human conversation that follows, so care team members on different platforms can coordinate in one channel.
HIPAA Compliance Requirements for This Architecture
Each layer of this architecture must satisfy HIPAA Technical Safeguard requirements:
Encryption: TLS 1.2+ for all data in transit across all three layers. AES-256 for any data at rest in routing metadata.
Access controls: Each layer must authenticate using named service accounts with minimum necessary permissions. No personal tokens.
Audit logging: Every notification delivery event must be logged with timestamp, source system, destination platform, delivery status, and care team member ID. PHI must NOT appear in audit logs.
BAA coverage: The EHR integration engine, the clinical notification router, AND the messaging bridge must each have a BAA with the covered entity (the healthcare organization). A BAA gap at any layer creates a HIPAA violation.
Data residency: For healthcare organizations with specific data residency requirements, all processing must occur within the appropriate geographic boundary.
PHI in Messaging Notifications: What's Permitted
A common question: can we include PHI (patient name, medical record number, diagnosis) in the notification that goes to the care team's messaging platform?
The answer is fact-specific:
- Permitted with appropriate controls: a notification to a clinician's dedicated work device (managed, enrolled in MDM) containing PHI relevant to the clinician's patient assignment
- Requires additional controls: a notification that includes PHI sent to a personal device where the messaging app may be used by non-covered individuals
- Not permitted without explicit patient consent: a notification sent to an external messaging platform (e.g., a Slack Connect channel shared with a non-covered entity)
The safest approach for initial deployment: send notifications that identify the patient by MRN only, with a link to the EHR for clinical details. The care team member clicks through to the EHR to see PHI. This keeps PHI within the HIPAA-authorized EHR environment while delivering the notification through the messaging bridge.
Case Study: Large Academic Medical Center
Illustrative composite scenario — not a real customer. An academic medical center runs Slack for its administrative and clinical informatics teams and Teams for its corporate and executive functions. Epic notifications are delivered by the clinical notification router's native apps on each platform, and a Slack-Teams bridge connects the coordination channels where staff discuss those notifications.
The goal: care team members who previously had to monitor multiple platforms (email + Slack + Teams) can coordinate follow-up from their single preferred platform.
The deployment requires: signed BAAs with SyncRivo (available for Enterprise customers) and the clinical notification router vendor, IT review of logging configuration to confirm no PHI in logs, and a pilot with the clinical informatics team before org-wide rollout.
Read about SyncRivo's BAA and HIPAA information → | Healthcare industry overview →
Ready to connect your messaging platforms?
