Web push notifications for practice websites and apps: permission, lock screens and HIPAA

Web push lets a website or web app send a notification to a person’s phone or computer after they leave the page. A practice can use it for appointment reminders, office closures, new hours or a short health update. The notification arrives from the browser or from a web app saved to the home screen, without a text message or an app store download. It also raises the same privacy questions as texts and portal messages, plus two of its own: what the browser lets you ask, and what the person’s lock screen shows to whoever picks up the phone.

This guide covers how web push works, what Chrome, Firefox and Safari require before a site may ask for permission, how lock screen previews expose message text, when a push message counts as marketing under HIPAA, what the HHS tracking bulletin says about apps and devices, and when the FTC Health Breach Notification Rule applies to tools outside HIPAA. For related topics, see our guides to cookie consent banners on medical websites, patient portal messages and HIPAA marketing rules, business texting rules for medical practices and the FTC Health Breach Notification Rule. If you plan a native app instead, see our guide to App Store and Google Play rules for health apps.

The short version

• Web push needs the person’s permission, given in the browser’s own prompt. Firefox and Safari on iPhone and iPad require the request to follow a tap, click or key press.
• On iPhone and iPad, web push works only for a web app the person has added to the Home Screen, from iOS and iPadOS 16.4.
• Chrome may switch a site with very low acceptance to a quieter prompt, and may remove permission from sites it finds disruptive or misleading.
• Notifications can appear on a locked screen. Write each one so it reveals nothing about a person’s health if someone else sees it.
• A reminder about the patient’s own care is not marketing under HIPAA. A push that encourages the person to buy or use a service can be, and then needs written authorization.
• A push tool that holds health details for a practice handles protected health information. For apps outside HIPAA, the FTC Health Breach Notification Rule can apply.

How web push works

MDN describes the Push API as a way for a web application to receive messages from a server whether or not the web app is in the foreground or even loaded. A service worker, a script the browser keeps registered for your site, subscribes to push and receives each message. The subscription gives your server an endpoint address and an encryption key. MDN notes that the endpoint is a capability URL: knowing it is enough to send a message to that person’s browser, so the endpoint must be kept secret.

The message travels through a push service run by the browser or device maker. The WebKit post says web push on iPhone and iPad uses the same Apple Push Notification service that powers native app notifications. The IETF standard for web push, RFC 8030, warns that TLS does not protect content from the push service, and that without added safeguards a push service can inspect and modify a message. RFC 8291 adds message encryption between your server and the person’s browser, and RFC 8030 says the W3C Push API adopted it. RFC 8030 also notes that encryption does not hide who is communicating or when. In plain terms, the push service may not read the text, but it carries the fact that your practice sent a message to that device at that time.

Asking for permission: what the browsers require

MDN describes Notification.requestPermission() as the method that asks the person for permission to show notifications for the current site, and notes that it works only in secure contexts, meaning pages served over HTTPS. Each browser then adds its own rules on top.

• Firefox. Mozilla’s November 2019 post says that from Firefox 72, a site must follow a tap, click or key press before it can show the notification prompt. A prompt without that interaction shows only a small icon in the address bar.
• Chrome. The Chromium Blog post of January 2020 introduced a quieter permission prompt from Chrome 80, turned on automatically for people who repeatedly deny notification requests and for sites with very low acceptance rates. Chrome Help says Chrome blocks notifications from sites with intrusive or misleading notifications, may remove a disruptive site’s permission and require it to ask again, and reminds people from time to time to review the permissions they granted.
• Safari on iPhone and iPad. The WebKit post of February 2023 says iOS and iPadOS 16.4 added web push for web apps added to the Home Screen, and that the app can request permission only in response to direct user interaction, such as tapping a subscribe button. A site open in a browser tab on iPhone is not a Home Screen web app.

Mozilla’s post also published what its study found in Firefox release: about 99 percent of notification prompts went unaccepted, and prompts shown after a user interaction were accepted at higher rates. Those figures are Mozilla’s across the web in 2019, not a forecast for your site. The Chromium post gives the same advice in its own words: wait until people understand the context and see a benefit before you ask.

For a practice, the place to ask is the moment the benefit is clear. A button on the appointment confirmation page that reads “Get a reminder on this device” fits. A prompt the moment someone lands on the home page asks for something before they know what it is for. Our guide to pop-ups on medical websites covers interruptions on the page itself.

The lock screen problem

The WebKit post says notifications from Home Screen web apps show on the Lock Screen, in Notification Center and on a paired Apple Watch. The iPhone User Guide lets each person choose when previews appear: at all times, only when the phone is unlocked, or never. The Android Help page describes a setting to show or hide sensitive content in notifications on the lock screen, and notes that settings vary by device. Your practice does not control these settings. Write the message as if the preview is on.

For a HIPAA covered entity, 45 CFR 164.530(c) requires appropriate administrative, technical and physical safeguards to protect the privacy of protected health information, and requires reasonable safeguards to limit incidental uses or disclosures. Under 45 CFR 164.522(b), a covered health care provider must accommodate reasonable requests from patients to receive communications by alternative means or at alternative locations. A patient who asks not to get notifications on a shared tablet is making that kind of request.

We recommend a neutral notification body with no condition, test, procedure or provider specialty in it. “[Practice name]: you have an appointment tomorrow. Tap for details.” works. “Reminder: your fertility consult is tomorrow” does not. Put any detail behind a sign-in, in the patient portal or on a page that asks the person to confirm who they are.

Reminders versus marketing under HIPAA

Under 45 CFR 164.501, marketing means a communication about a product or service that encourages the recipient to purchase or use it. The definition excludes communications for the treatment of the individual, including care coordination and recommending alternative treatments or providers, and communications describing a health-related product or service the covered entity itself provides, unless the covered entity receives financial remuneration for making the communication. An appointment reminder for a visit already on the schedule is part of the patient’s care.

45 CFR 164.508(a)(3) requires the patient’s written authorization for any use or disclosure of protected health information for marketing, with exceptions only for face-to-face communications and promotional gifts of nominal value. A push sent to a list built from patient records that promotes a third party’s product is marketing. So is a push the practice is paid to send. Keep promotions for your own services short and general, and check with counsel before using patient data to choose who receives them. Our guide to patient portal messages works through the same exceptions for portal messages.

Tracking, subscriptions and the HHS bulletin

The HHS Office for Civil Rights bulletin on online tracking technologies says information that a regulated entity’s mobile app collects, including information from the device such as a device ID or advertising ID, generally is protected health information, and the regulated entity must follow the HIPAA Rules for any disclosure to the app vendor, a tracking vendor or any other third party. It also says the HIPAA Rules do not cover health information a person enters into an app that is not offered by or on behalf of a regulated entity.

The bulletin is still posted, with a note. On June 20, 2024, in American Hospital Association v. Becerra, the US District Court for the Northern District of Texas vacated the bulletin to the extent it said HIPAA obligations are triggered when a technology connects an IP address with a visit to an unauthenticated public page about specific health conditions or providers. The rest of the bulletin stands, including its guidance on authenticated pages and on mobile apps.

A push subscription is a device identifier your system stores. If your push tool records that a person subscribed from your page on a specific condition, or tags them by the service they asked about, the tool now holds health-related information tied to a device. We recommend storing the subscription with the patient record only inside systems covered by a business associate agreement, sending reminders from the system that holds the appointment, and leaving condition tags out of any push tool that is not covered. Our guide to tracking pixels on practice websites covers the bulletin in more detail.

Apps and tools outside HIPAA: the FTC rule

A health app may be run by a company that is not a covered entity. The FTC Health Breach Notification Rule, 16 CFR part 318, applies to vendors of personal health records and PHR related entities that are not HIPAA covered entities or acting as business associates. Under 16 CFR 318.2, a covered health care provider includes any entity furnishing health care services or supplies, and health care services or supplies include any online service such as a website, mobile application or internet-connected device that tracks conditions, symptoms, medications, fitness, sleep, diet and similar matters. A breach of security includes an unauthorized acquisition of health information in a personal health record that occurs as the result of a data breach or an unauthorized disclosure.

Under 16 CFR 318.3, after discovering a breach, a vendor or PHR related entity must notify each affected individual and the FTC, and must notify prominent media outlets when the information of 500 or more residents of a State or jurisdiction is involved. A cash-pay wellness app that sends push notifications and shares health details with a push or analytics vendor without the person’s authorization should read the rule with counsel. Separately, 15 USC 45(a)(1) declares unfair or deceptive acts or practices unlawful, which covers what an app says about how it handles data. Our guide to the FTC Health Breach Notification Rule covers the rule in full.

Questions to ask before your practice turns on web push

• Which messages will we send by push, and is each one about the patient’s own care or a promotion?
• Where on the site do we ask for permission, and does the request follow a tap or click?
• Do our iPhone and iPad patients use a Home Screen web app, or will they miss push entirely?
• Would the notification text reveal anything about a person’s health on a locked screen?
• Does the push tool store which page a person subscribed from, or tag them by service or condition?
• Who holds the push subscriptions, and is that vendor covered by a business associate agreement?
• How does a patient turn push off, and how do we record a request to stop or to use another channel?
• If we run an app outside HIPAA, have we read 16 CFR part 318 with counsel?

Use and avoid

• Use: a permission request tied to a clear benefit, such as a reminder button on the booking confirmation page.
• Use: neutral notification text with the practice name and no health details.
• Use: a link to sign in for anything specific to the patient.
• Use: a plain way to turn notifications off, explained on the site.
• Use: push tools that keep subscriptions apart from condition data, unless covered by a business associate agreement.
• Avoid: asking for permission on page load or repeating the request on each visit.
• Avoid: conditions, test results, procedures or provider specialties in the notification text.
• Avoid: segmenting push lists by condition or by the health page a person visited.
• Avoid: paid or third-party promotions sent by push to patients without written authorization.

An illustration

This example is invented. [Practice name], a dermatology practice in [city], wants to add web push to its site. The first plan has the push tool ask for permission as soon as a visitor lands, tag subscribers by the treatment page they came from, and send messages such as “Your acne follow-up is tomorrow” and “New offer for laser patients.”

Before launch, the owner reviews the plan with their marketing contact. The permission request moves to a button on the booking confirmation page. The treatment-page tags come out of the push tool. Reminders go out from the scheduling system, which is covered by a business associate agreement, and read “[Practice name]: you have an appointment tomorrow at [time]. Tap for details.” The laser offer becomes a general post on the website and a newsletter that subscribers chose, not a push to patients selected from their records. The site adds a short page on how to turn notifications off, and the front desk logs any patient request for a different channel.

Checklist

• List the messages you plan to send by push and mark each as care-related or promotional.
• Serve the site over HTTPS and register the service worker only on pages that need it.
• Ask for permission only after a tap or click, at a point where the benefit is clear.
• Test the flow in Chrome, Firefox and a Home Screen web app on iPhone.
• Write notification text that reveals no health details on a locked screen.
• Keep the push endpoint and subscription data secret and access-controlled.
• Keep condition tags and page-of-origin data out of push tools not covered by a business associate agreement.
• Get written HIPAA authorization before any push that counts as marketing.
• Publish how to turn notifications off and record patient requests for other channels.
• Review 16 CFR part 318 with counsel for any app or tool outside HIPAA.

How we help

We build websites, local and organic search, Google Ads and lead generation and an AI front desk for independent practices. For web push, that means placing the permission request where it makes sense, writing notification text that stays neutral on a locked screen, keeping condition data out of push tools and setting up reminders from the systems that already hold the appointment. Our tools are built with HIPAA in mind. We confirm in writing what a BAA covers before any patient information flows through a tool, and if it is not covered, we do not route patient information through it. We are not a healthcare provider and we do not give legal or medical advice. Read our guide to healthcare marketing rules for the wider picture.

Sources

• WebKit blog: Web Push for Web Apps on iOS and iPadOS (February 16, 2023)
• Chromium Blog: Introducing quieter permission UI for notifications (January 7, 2020)
• Google Chrome Help: Use notifications to get alerts (no date shown)
• Mozilla Future Releases: Restricting Notification Permission Prompts in Firefox (November 4, 2019)
• MDN: Push API (last modified May 28, 2025)
• MDN: Notification.requestPermission() (last modified June 11, 2025)
• IETF RFC 8030: Generic Event Delivery Using HTTP Push (December 2016)
• IETF RFC 8291: Message Encryption for Web Push (November 2017)
• iPhone User Guide: Change notification settings (no date shown)
• Android Help: Control notifications on Android (no date shown)
• HHS OCR: Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates (content last reviewed June 26, 2024)
• 45 CFR 164.501: Definitions (marketing)
• 45 CFR 164.508: Uses and disclosures for which an authorization is required (paragraph (a)(3), marketing)
• 45 CFR 164.522: Rights to request privacy protection (paragraph (b), confidential communications)
• 45 CFR 164.530: Administrative requirements (paragraph (c), safeguards)
• 16 CFR 318.2: Definitions
• 16 CFR 318.3: Breach notification requirement
• 15 USC 45: Unfair methods of competition unlawful; prevention by Commission

More in Practice websites, privacy and tracking