An Azure service that is used to send push notifications to all major platforms from the cloud or on-premises environments.
Hello @Waseem Ali
Your proposed approach is actually very close to Microsoft’s recommended pattern for sensitive push-notification data.
Azure Notification Hubs documentation states that Notification Hubs does not log notification message payloads. However, the notification still passes from your backend through Notification Hubs and then through the platform notification service: APNs for iOS or FCM for Android. Microsoft therefore recommends using the Secure Push pattern for sensitive information.
In your case, avoid putting the patient's name, appointment time, or other PHI directly in the push payload. Instead, use something like:
The push itself could contain only something such as:
{
"type": "appointment-reminder",
"messageId": "opaque-random-id"
}
After receiving it, the application authenticates the user and retrieves the actual appointment information from your protected API. This keeps PHI out of the push-notification payload and follows Microsoft's Secure Push guidance.
One important point regarding silent notifications: don't design the workflow assuming that an iOS or Android background notification will always execute immediately or reliably.
Notification Hubs ultimately hands the notification to APNs or FCM, and Microsoft notes that delivery by those platform notification systems isn't covered by the Notification Hubs SLA.
For an appointment reminder, therefore, use the push primarily as a signal that new information is available, rather than depending on background execution to retrieve PHI. When the user opens the app, authenticate them and retrieve the current appointment information from the API. A silent/data notification can additionally trigger a refresh where the OS permits it, but it shouldn't be your only mechanism.
Regarding HIPAA, having Microsoft's BAA is important, but Microsoft explicitly states that a BAA or use of Azure services doesn't automatically make the customer's solution HIPAA-compliant. The application architecture, access controls, authentication, auditing, device behavior, data handling, and other safeguards remain the customer's responsibility.
I'd therefore recommend:
- Keep PHI out of APNs/FCM payloads.
- Send only generic notification text and/or an opaque identifier.
- Retrieve PHI through an authenticated HTTPS API.
- Authorize access server-side rather than trusting information in the push payload.
- Avoid caching sensitive appointment information unnecessarily on the device.
- Have your compliance/security team validate the complete architecture against your organization's HIPAA requirements.
Also note that all connections from the sender → Notification Hubs → platform notification service use HTTPS, and Notification Hubs doesn't log message payloads.
So don't send "John Smith - Cardiology appointment at 10:30 AM" in the notification. Something generic like "You have a new appointment reminder. Open the app for details." followed by authenticated retrieval is the safer architectural pattern.
References:
Azure Notification Hubs FAQ – sensitive payload and Secure Push guidance
Azure HIPAA compliance and BAA guidance
Azure Notification Hubs overview
Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.