Is a PWA allowed to handle patient data under HIPAA?

Yes. HIPAA does not restrict the client type. The PWA, its hosting and any data it caches need the same Security Rule safeguards a native app would get.

Can a PWA connect to Bluetooth medical devices?

Not reliably. Web Bluetooth is a community draft with limited browser support, so remote monitoring with Bluetooth devices belongs in a native app.

Will offline data in a PWA survive on iOS?

In a Safari tab, script-writable storage can be deleted after seven days of use without a visit to the site. Home Screen web apps keep their own counter, but offline data should still be treated as temporary and synced as soon as possible.

Can a PWA be listed in the App Store or Google Play?

A PWA runs from the web and does not need a store listing. Teams that need store presence usually wrap the web app or build a native client, and each store's review rules then apply.

Is a PWA cheaper to build than a native app?

Often, because one web codebase serves every platform. The savings shrink when the workflow needs device access or background work, since those parts need native code anyway.

Progressive Web Apps in Healthcare: PWA or Native

A progressive web app is a website built with web standards that can be installed to a home screen, open without a network connection and send notifications, all without an app store package. For a healthcare team, that makes it a real alternative to a native app for some workflows and the wrong choice for others.

This guide is about making that choice. It covers what PWAs can do on current iOS and Android, which healthcare workflows suit them, a decision list against native, how to handle offline ePHI, how to build one and where healthcare PWAs go wrong.

What is a progressive web app?

Choosing between a PWA and a native app?

Agnotic helps healthcare teams pick the right client for each workflow, then builds it with identity, offline rules and HIPAA safeguards designed in.

Fractional CTO for Healthcare

A progressive web app is a website that uses a web app manifest and a service worker so it can be installed, open offline and receive push notifications, without an app store package. In healthcare, a PWA suits intake, portal access and reference workflows, while any ePHI it caches on a device still needs HIPAA Security Rule safeguards.

What makes a website a PWA

Web app manifest: A JSON file with the name, icons, start URL and display mode, so the browser can offer installation.
Service worker: A script that runs separately from the page, caches the application shell, intercepts network requests and shows a usable page when the network is gone.
Secure origin: Service workers only register on HTTPS, so the whole app is served over TLS.
Responsive layout: One origin that works on a phone, a tablet and a clinic workstation.

What can a PWA do on iOS and Android today?

A PWA can install, work offline and receive push on both platforms, with limits that matter for healthcare. The platform facts below decide which workflows are safe to build on the web.

Service workers: The W3C Service Workers specification defines how a worker caches resources and handles requests, and requires a secure context.
Push on iOS: WebKit added Web Push for Home Screen web apps in iOS and iPadOS 16.4. A PWA must be added to the Home Screen before it can ask for push permission on iPhone.
Storage on iOS: WebKit deletes a website's script-writable storage, including IndexedDB and service worker caches, after seven days of Safari use without user interaction on the site. Home Screen web apps keep their own counter of days of use.
Bluetooth: Web Bluetooth is a W3C Community Group draft, not a W3C standard, and browser support is limited, so a PWA cannot rely on it to read medical devices.
HIPAA: Under 45 CFR 164.312, encryption of ePHI at rest is an addressable implementation specification. A PWA that caches ePHI should encrypt it, or document why an equivalent measure is reasonable.

How installation differs by platform

Android with Chrome or Edge: The browser can show an install prompt once the manifest and service worker meet its criteria, and the app can offer its own install button.
iPhone and iPad: The user adds the app through the Share menu in Safari. The app cannot trigger a native install prompt, so onboarding has to show the steps.
Desktop: Chrome and Edge offer installation from the address bar, which suits clinic workstations where staff open the same tool all day.

Which healthcare workflows suit a PWA?

A PWA suits workflows that are occasional, form-based or read-heavy, and that do not need background work or device hardware beyond the camera and file upload.

Good fit, pre-visit intake: A patient follows a link, completes forms on a phone and never needs to install anything.
Good fit, portal access: Appointments, messages, results and bill pay, with a short session and no long-lived chart cache.
Good fit, care instructions: Procedure prep and discharge instructions that should open on weak home Wi-Fi.
Good fit, clinician reference: Protocols and formularies on shared workstations where installing app store packages is restricted.
Poor fit, remote monitoring: Bluetooth cuffs, scales and glucose sensors need native Bluetooth and reliable background sync.
Poor fit, background capture: Location, step counts or audio that must keep running while the app is closed.
Poor fit, health store access: Apple HealthKit and Android Health Connect are native APIs.

PWA or native: a decision list

Score the workflow against these criteria. If any one points firmly to native, build native for that workflow, even if the rest of the product stays on the web.

Device access: Native if the workflow needs Bluetooth medical devices, health stores or background sensors. PWA if camera and file upload are enough.
Frequency of use: PWA for occasional tasks patients will not install an app for. Native for daily use where a store app is worth the install.
Background work: Native if data must sync or capture while the app is closed. PWA if work only happens while the user has it open.
Distribution and updates: PWA when updates should reach every user on next load. Native when the program needs store presence or device management distribution.
Offline depth: PWA for an offline shell and short-lived drafts. Native for large offline datasets and long offline periods.
Team and budget: One web codebase is cheaper to maintain than two native apps, and a cross-platform framework sits between the two.

How should a healthcare PWA handle offline data?

A healthcare PWA should cache the application, not the chart. Where offline ePHI is truly needed, it should be encrypted, short-lived and wiped on sign-out.

Cache the shell: HTML, scripts, styles and icons go in the service worker cache. API responses with ePHI do not, unless the workflow needs them offline.
Encrypt what remains: Store any offline ePHI in IndexedDB encrypted with a Web Crypto key marked non-extractable, so script cannot read the raw key.
Set a time to live: Offline drafts and cached records expire after a period the team sets, and are deleted on next open after expiry.
Wipe on sign-out: Sign-out clears IndexedDB, caches and cookies. The server can also send a Clear-Site-Data header to clear storage for the origin.
Keep push generic: Notification text says a message is waiting, never a diagnosis, result or medication.
Sync with care: Queue offline submissions with an ID so a retry does not create duplicates, and show the user what is still waiting to send.

Caching rules by request type

Static assets: Cache first, with a versioned cache name so a new release replaces the old files cleanly.
Public content: Stale while revalidate for education pages and care instructions that hold no patient data.
Authenticated API calls: Network only by default. Exceptions are listed in the offline policy and stored encrypted.
Uploads and form posts: Queued in an encrypted outbox when offline, then sent and removed on success.

How do teams build a healthcare PWA?

Teams build a healthcare PWA in five steps, starting with the workflow decision rather than the service worker.

1. Confirm the fit: Run the workflow through the decision list and record why a PWA is the right client.
2. Design identity: Use the organization's SSO or SMART on FHIR launch with a short session and the same roles as the desktop site.
3. Write the offline policy: List what may be stored on the device, how it is encrypted, how long it lasts and how it is wiped.
4. Build and test install: Complete the manifest and service worker, then test installation, offline use and push on iOS Safari, Chrome and Edge on real devices.
5. Check accessibility and security: Test against WCAG 2.1 AA, with WCAG 2.2 AA as the design target, and review the service worker's caching rules as part of the security review.

Running a PWA beside a native app

When some workflows need native and others do not, share the design system, the API and the identity provider across both clients. The PWA handles intake and portal tasks, the native app handles device work, and patients sign in with the same account on each, so support and security reviews cover one system rather than two.

Where healthcare PWAs go wrong

These failure points turn a sensible PWA into a privacy or support problem. Each one is easy to test before launch.

Choosing a PWA to avoid HIPAA: The client type does not change the Security Rule. Cached ePHI on a phone is still ePHI.
Caching API responses by default: A generic caching strategy stores lab results in the service worker cache in plain form.
Push on iOS without install: The team plans iPhone notifications but never prompts users to add the app to the Home Screen.
Storage that disappears: Offline drafts kept in a Safari tab can be deleted after seven days of Safari use without a visit, so patients lose unfinished forms.
Device programs on the web: A monitoring program is built as a PWA and then needs a native app for Bluetooth anyway.
Two design systems: The PWA and the desktop site drift apart, doubling accessibility and security work.

How Agnotic can help

The right client is a per-workflow decision, and one healthcare product can sensibly use a PWA for occasional tasks and a native app for device work. Agnotic Technologies helps teams make that call, then builds the chosen client: progressive web apps, native apps or both, with SSO or SMART on FHIR sign-in, an offline policy and HIPAA Security Rule safeguards around any cached ePHI.

Hosting matters too. HHS guidance treats a cloud provider that stores ePHI as a business associate even if it cannot view the data, so Agnotic plans the hosting and its business associate agreement with the client before launch.

Plan your healthcare client with Agnotic

Explore fractional CTO support for healthcare, or browse more build guides in the Guides and Playbooks hub.

Fractional CTO for Healthcare Guides and Playbooks

Sources

Frequently Asked Questions

Yes, since iOS 16.4, but only after the user adds the web app to the Home Screen and grants permission. Plan the install prompt into the onboarding flow if notifications matter.

Progressive Web Apps