Email

Email is used for product update announcements, password resets, initial user invitations, and interactions with the Pulsara support team.

Pulsara also sends URLs and hyperlinks via email for new invitations, password reset requests, and account creation confirmations.

Permit all incoming email from *@*.pulsara.com in your email system. Prevent email from *@*.pulsara.com from being tagged as spam. Because Pulsara relies on a third party for email services, if you filter incoming emails by IP address, please ensure your systems are looking up our SPF record to validate the list of IP addresses from which we send mail.

Firewall and Network

Pulsara systems utilize dynamic load balancing to automatically distribute incoming application traffic across a web server cluster. Additionally, to support System Continuity best-practices, our systems leverage multiple geographically separated data centers. 

• Consequently, to ensure continuity of service, we recommend configuring your firewall using host names rather than IP addresses. If you implement allowlisting by IP, be aware that we cannot guarantee continuity of service.

Please permit traffic originating on your network to the destination hosts and specified ports in the tables below. 

• Use of Pulsara requires only egress rules on a firewall - traffic originating from within your network. (We do not require the implementation of ingress firewall rules.)

• Ensure that your firewall allows return traffic to the client on the specified ports. 

• Modern stateful firewalls like Palo Alto, Cisco ASA, Juniper SRX (flow mode), etc. provide this functionality by default when you create rules allowing egress traffic.

Pulsara

Audio-Video Conferencing

If "Video Calling" has been enabled for your account, your Pulsara users can participate in secure Voice or Voice+ Video conference calls.

Zoom

Pulsara uses the Zoom platform for synchronous voice, video, and conferencing capabilities.

After configuring your firewall, preliminary Zoom testing can be conducted using the instructions here:  https://zoom.us/test

If you are able to participate in the Zoom test conference, Pulsara App users on the same network should also be able to participate in Zoom-based conferences.

Specific network and firewall settings for Zoom are available here:  https://support.zoom.us/hc/en-us/sections/201740166-Network-and-Firewall

Additional Zoom Security Information: https://zoom.us/docs/en-us/privacy-and-security.html

Pulsara Web Analytics

Native Mobile Device Capabilities

Mobile App Downloads and Updates

Pulsara’s mobile apps and mobile app upgrades are distributed through the Apple App Store and the Google Play Store.

Either

1. 1. Configure your MDM for Pulsara apps, or

   2. Configure your firewall to allow access to the Apple App Store and/or Google Play Store to install and upgrade mobile apps, including Pulsara.

Push Notifications

Pulsara uses Push Notifications for its delivery of alerts. iOS devices use Apple Push Notification Service (APNS) for this purpose. Android devices use Google Firebase Cloud Message for the delivery of push notifications.

After configuring your firewall(s), we recommend sending and testing push notifications on devices of both types connected to your organization’s network(s) to which devices will be connected. This can be accomplished through the Pulsara mobile apps.

Apple Push Notification Services (APNS)

For further information, see this article entitled If you Apple devices aren't getting Apple push notifications.

Browser Notifications

Pulsara HQ uses native browser notification services to send primary notifications for new patients. To allow these services to send push notifications, you may need to allow the following through your firewall and Group Policy.

Group Policies (Recommended)

ForcebBuiltInPushMessagingClient

Enable Computer Configuration -> Administrative Templates -> Microsoft Edge -> ForceBuiltInPushMessagingClient.

By default, Edge uses the Windows OS-level push client to receive notifications. In many enterprise environments, the OS-level client cannot connect to Microsoft's push service even when general network connectivity is fine. This policy has Edge use its own internal connection instead.

Microsoft Edge Browser Policy Documentation - ForceBuiltInPushMessagingClient

Note: requires full Edge restart after the policy applies.

DefaultNotificationSetting / NotificationsAllowedForURLs

Microsoft Edge has a policy called DefaultNotificationsSetting that controls whether websites can request to display notifications. If your environment uses DefaultNotificationSetting = 2 (block by default), ensure https://*.pulsara.com is included in NotificationsAllowedForURLs.

If DefaultNotificationsSetting is 3 (prompt user, the default) or 1 (allow all), no allowlist entry is needed. 

ToastEnabled

Windows User Settings: Verify that HKEY_CURRENT_USERS\Software\Microsoft\Windows\CurrentVersion\PushNotifications\ToastEnabled is set to 1.

Firewall

Browser Alerts Proxies and SSL/TLS Inspection

Push notification services (both Microsoft ENS and Google FCM) utilize strict security protocols. They do not support proxies or SSL/TLS Deep Packet Inspection (HTTPS Interception).

* If your firewall intercepts and inspects SSL traffic, the notification channel will be intentionally dropped to protect data integrity, and notifications will fail. 

You must ensure that the domains listed in Tables 2 and 3 are added to your firewall's SSL Inspection Bypass / Exemption List to allow a direct, untampered connection between the devices and the notification servers. 

Microsoft Proxy Requirements: https://learn.microsoft.com/en-us/windows/apps/develop/notifications/push-notifications/firewall-allowlist-config#proxy-support

Google Proxy Requirements: https://firebase.google.com/docs/cloud-messaging/network-configuration#proxies

GEO-IP Blocking Contraints

If your enterprise firewall utilizes strict Geo-IP blocking (e.g., dropping all traffic destined for IP addresses outside of the United States), simply allowing the FQDNs in your standard access rules might not be enough. 

Since Google and Microsoft utilize global load balancing for their notification services, domains like mtalk.google.com or *.wns.windows.com will occasionally resolve to non-US IP addresses. 

Please ensure that your rules allowing the specific hostnames from Tables 2 & 3 are explicitly configured to bypass or override your global Geo-IP blocking profiles, otherwise your firewall may silently drop the connections. 

Mobile App Analytics, Crash Detection, and Problem Resolution 

Pulsara’s mobile apps have the capability of reporting crashes, other errors, and analytics. Pulsara uses these reports to proactively correct issues or problems as quickly as possible (sometimes even before impacting customers) and to improve app usability. We use Google Firebase for this purpose.

ePHI is never transmitted to Google Firebase.

Pulsara clients will function properly even when devices are unable to access Google Firebase for the purpose of sending analytics and crash data.

Google does not publish domains or firewall-allow list guidance for Firebase Crashlytics or Firebase Analytics. As such, Table 4 (below) is provided strictly for informational purposes.

Geolocation

Pulsara's mobile apps use location services provided by Android and iOS to calculate and update ETA for inbound EMS patients. For EMS organizations, ensure that each device can detect the current location using Apple Maps on iOS or Google Maps on Android. 

SSL Certificate Pinning

Pulsara uses certificate pinning in our mobile apps in order to protect HIPAA data from "Man in the Middle" (MITM) attacks. If your facility is using a proxy to intercept SSL/TLS traffic, the Pulsara app will not be able to correctly verify that the certificate being provided belongs to Pulsara and will halt further network activity from the app. Additional proxy configuration may be necessary in order for Pulsara to operate correctly. 

Federated Authentication

Pulsara provides an Open ID Connect (OIDC)-compliant federated authentication integration for our customers.

The integration lets customers link their OIDC-compliant identity platform (such as Azure or Okta) to Pulsara to handle all authentication protocols. With the integration, all sign-in requirements (such as MFA, duration, password expiration, etc.) are delegated to your IdP, giving your access management team control over the login experience.

Pulsara's FedAuth integration requires that your IdP is compatible with Single Page and Mobile Applications. Pulsara also suggests that your IdP is configured for JWKS rotation to ensure consistent function.

For more information on our Federated Authentication integration, please contact help@pulsara.com.

Mobile Device and Browser Requirements

Ensure your organization's personnel are using browsers and/or devices supported by Pulsara and listed here: https://www.pulsara.com/faqs/which-web-browsers-and-mobile-devices-can-we-use

WIFI Considerations:

If Wi-FI is to be used for Internet connectivity, determine which Wi-FI network name (a.k.a "SSID") will be used with staff mobile devices, and obtain Wi-Fi passwords or have your IT department configure this for you. 

Wi-Fi must have a persistently active connection, must not require staff members to repeatedly log back onto the system, and must have excellent coverage throughout applicable facilities. 

Prior to testing, a comprehensive connectivity audit should be completed to identify any Wi-Fi or cellular connectivity issues. 

Please consider the following:

• Are there any known dead spots? 

• What is the pathway for reporting and resolving a connectivity issue? 

• For those who may experience repeated connectivity challenges, we recommend enabling the Rollover-to-Page Feature. You can find additional information on the Rollover-to-Page Feature in our Knowledge Base Article: https://knowledge.pulsara.com/technical/alerts/what-is-the-rollover-to-page-feature

Cellular Data:

It is our recommendation, as best practice for system continuity, that devices used by mission critical functions, such as ED nursing stations, have a cellular data plan as a backup method of connecting to the Internet. 

iOS Devices:

If your facility will use hospital-provided iOS device(s) for Pulsara outside of an MDM, then identify the Apple ID that will be used on the device(s) for the installation of the Pulsara application. This Apple ID may be required to authenticate with the Apple App Store for future upgrades of the Pulsara app. 

Mobile Device Management:

Does your facility use/plan to use an MDM (Mobile Device Management) system? If so, contact your Pulsara Project Manager so that the appropriate testing can take place prior to implementation. The IT department should be engaged at the inception of the project. Pulsara can help with this process. 

See this MDM Checklist for more information: https://www.pulsara.com/faqs/mobile-device-management

Pulsara Intelligence

Pulsara's application has the ability to use AI to convert narrative text to structured data fields within Pulsara. The AI is started by a user within the Pulsara mobile application.

Users are required to approve the suggestions prior to committing them to the Pulsara record. Once entered these are treated like all other Pulsara information. The resulting data output is customer owned data and stored in our US hosted AWS environment. 

Pulsara utilizes AWS Bedrock for this feature. No customer data is used to train the AWS Bedrock model. 

All communication between the Pulsara application and our AWS environment is encrypted at the same level as noted in the Privacy and Encryption section. 

No additional firewall rules are required for this feature.