HIPAA compliance for medical apps in the US and Canada

Most medical app projects start with the same sentence: “it needs to be HIPAA compliant.” It is usually said in Toronto as often as in Texas, and it is usually wrong twice.

HIPAA covers far fewer health apps than people assume. And it does not apply in Canada at all. Canada has its own laws, which are organised differently, and a team that builds to HIPAA alone can end up both over-engineering for the US and under-protected in Canada.

So the first question is not how to comply. It is which law you are complying with. Everything in your architecture follows from that answer.

When HIPAA applies, and when it does not

HIPAA regulates two kinds of organisation. Covered entities are health care providers, health plans and health care clearinghouses. Business associates are the companies that create, receive, maintain or transmit health information on behalf of a covered entity.

An app is a business associate when it works for one of them. A clinic’s patient portal, a hospital’s remote-monitoring app, a telehealth platform a practice licenses to see its patients — all business associates. Before you touch any patient data, you sign a business associate agreement (BAA) with the covered entity, and the HIPAA Privacy, Security and Breach Notification Rules apply to you directly.

An app a consumer downloads and uses on their own usually is not. HHS says so plainly: an app used independently by an individual, with no covered entity behind it, is generally outside HIPAA, because the developer is not acting on anyone’s behalf. A symptom tracker, a fertility app or a meditation app that people find in the App Store themselves is, in most cases, not a HIPAA product.

The line can move within a single app. A consumer app that a hospital later starts recommending and receiving data from can become a business associate for that flow. HHS publishes worked scenarios for exactly this, and the FTC’s Mobile Health Apps Interactive Tool walks through the questions in a few minutes. Both are worth doing before you write a line of code.

“Not HIPAA” does not mean unregulated

This is where consumer health apps get hurt. Falling outside HIPAA puts you under a different set of rules that are, in some respects, stricter.

The FTC Health Breach Notification Rule. Amended rules took effect on 29 July 2024 and made explicit that they cover health apps and connected devices that are not covered by HIPAA. Two details matter more than the rest:

• A “breach” is not only a hack. An unauthorised disclosure counts, which includes sharing health data with an advertising platform without the user’s permission.
• Notification has a clock. Affected users must be told without unreasonable delay and no later than 60 days after discovery. If 500 or more people are affected, the FTC must be told at the same time.

The first enforcement under this rule was GoodRx in 2023, which paid a $1.5 million civil penalty for sharing users’ health information with advertising platforms. The online therapy service BetterHelp agreed to pay $7.8 million the same year over similar sharing with Facebook and Snapchat. The fertility tracker Premom settled the second Health Breach Notification case months later. None of these were hacks. All of them were SDKs doing what SDKs do.

State consumer health data laws. Washington’s My Health My Data Act took effect on 31 March 2024 and covers consumer health data about people in Washington that HIPAA does not already cover — which is to say, most consumer health apps. Crucially, it includes a private right of action, so individuals can sue. Nevada’s consumer health data law took effect the same day, and Connecticut treats consumer health data as sensitive data requiring consent. If you have US users, assume some of them live in these states.

The HIPAA Security Rule is changing, but not yet

In January 2025 HHS proposed the largest rewrite of the HIPAA Security Rule since it was written. The headline change is that encryption of health data at rest and in transit, and multi-factor authentication, would stop being “addressable” — a category that lets an organisation document why it chose an alternative — and become mandatory. The proposal adds annual asset inventories, vulnerability scans every six months, annual penetration tests and the ability to restore systems within 72 hours.

As of September 2026 it is still a proposal. HHS has moved its target date for a final rule several times, most recently to around July 2027, and the proposal itself allows a further 240 days after publication before compliance is due.

Build to it anyway. Encryption and MFA are what any competent security review already expects of a health app, and designing them in now costs a fraction of retrofitting them in 2028.

For scale on what is at stake: from 28 January 2026, HIPAA civil penalties run from $145 to $73,011 per violation for the lower tiers, and up to $2,190,294 per year for violations of the same provision. HHS has, since 2019, applied lower annual caps to the less culpable tiers as a matter of enforcement discretion. State attorneys general can bring their own actions on top.

Canada: no HIPAA, and not one law but several

HIPAA is a US federal statute. It does not apply to Canadian health data, and a Canadian regulator will not accept “we are HIPAA compliant” as an answer to anything. The one exception runs the other way: a Canadian company building for a US hospital or health plan is that organisation’s business associate for that work, and signs a BAA like anyone else.

Canadian health privacy splits along the same line as the US — whose behalf you hold the data on — but the answers are provincial.

If you work for a health custodian, the province’s health privacy act governs. In Ontario that is the Personal Health Information Protection Act (PHIPA); in Alberta, the Health Information Act (HIA); most other provinces have an equivalent. These laws are written around the custodian — the hospital, clinic, pharmacy or practitioner — and your app typically acts as the custodian’s agent or electronic service provider, bound by your contract with them and the act’s rules on how you may use the data.

Ontario went further in 2020, adding a category of consumer electronic service provider to PHIPA: companies that let individuals access and manage their own health records through an app or portal. Those provisions depend on proclamation and regulations, so check their current status with counsel if your app lets patients pull their records from an Ontario provider.

If you run a consumer or commercial app, federal law applies: the Personal Information Protection and Electronic Documents Act (PIPEDA). Health information is among the most sensitive categories under it, which raises the bar for consent and security. Quebec, Alberta and British Columbia have their own private-sector privacy laws that apply instead of PIPEDA for activity inside those provinces; PIPEDA still applies when data crosses a provincial or national border.

Two rules catch teams out:

• PIPEDA breach reporting. A breach that creates a real risk of significant harm must be reported to the Privacy Commissioner of Canada and to affected individuals as soon as feasible. Health data almost always clears that bar. You must also keep a record of every breach, reportable or not, for 24 months.
• Quebec’s Law 25. Before personal information leaves Quebec — including handing it to a cloud provider or processor outside the province — you must complete a privacy impact assessment and put a written agreement in place reflecting it. A US-hosted backend serving Quebec patients needs this done before launch, not after. The most serious offences carry penalties of up to 25 million Canadian dollars or 4% of worldwide turnover.

And federal law is moving. On 15 June 2026 the government introduced Bill C-36, which would replace PIPEDA’s privacy provisions with a new Protecting Privacy and Consumer Data Act. It treats health information explicitly as sensitive, adds deletion and portability rights, and allows administrative penalties of up to 10 million Canadian dollars or 3% of global revenue. It is at first reading and not yet law — the third attempt in six years — but it tells you where the floor is heading.

What this changes in the app itself

Law firms can tell you which regime applies. What they cannot tell you is where health data actually leaks in a mobile app, which is almost never where people look. These are the decisions we make on every health project, whichever branch of the diagram you are on.

Apple’s rules apply regardless of the law

Apple’s App Review Guidelines have their own health rules, and they bind every app in the store:

• No personal health information in iCloud. Guideline 5.1.3(ii) says so in as many words. Apple also does not sign BAAs, so iCloud and CloudKit are off the table for regulated data twice over.
• No health data for advertising. Guideline 5.1.3(i) forbids using data from HealthKit, clinical health records or health research for advertising, marketing or data mining, and requires you to disclose the specific health data you collect.
• Medical claims get scrutiny. Under guideline 1.4.1, an app that diagnoses, treats or measures must disclose the data and methodology behind its accuracy claims, should remind users to consult a doctor, and should link any regulatory clearance it has. An app claiming to measure blood pressure or blood oxygen using only the phone’s sensors will be rejected.

If your app diagnoses or treats, also ask whether it is a regulated medical device — software as a medical device is regulated by the FDA in the US and by Health Canada. That is a separate question from privacy, with its own timelines, and it is far cheaper to answer at the start.

Keep health data out of the places you do not control

• Push notifications carry no health data. Payloads travel through Apple’s and Google’s delivery infrastructure, and Apple offers no BAA. Send “You have a new message” and fetch the content over your own authenticated connection when the user opens it. The lock screen is also a public place.
• Every SDK is a disclosure until proven otherwise. Analytics, crash reporting, attribution, session replay, A/B testing and AI features all send data somewhere. This is the exact failure behind GoodRx and BetterHelp. List every SDK, what it sends and where, and remove or reconfigure anything that can see health data without a signed agreement.
• Logs and crash reports are data stores. A patient name in a log line ends up in your crash reporter. On iOS, unified logging redacts dynamic values by default in production; do not mark health data .public to make debugging easier.

One nuance on tracking: in June 2024 a federal court in Texas vacated part of HHS’s guidance on online tracking technologies — specifically the claim that an IP address plus a visit to an unauthenticated public web page about a health condition is protected health information. HHS dropped its appeal. The ruling was narrow: it did not touch the guidance on logged-in portals and apps, which is where a patient app lives.

Protect what stays on the device

• Encrypt at rest with the platform, not around it. On iOS, write health data with complete file protection (FileProtectionType.complete), which makes it unreadable while the device is locked. Keep tokens in the Keychain with a this-device-only accessibility class so they never sync or restore to another phone. On Android, use keys held in the Android Keystore.
• Hide sensitive screens from the app switcher. Both platforms take a snapshot of your app when it goes to the background. On iOS, cover sensitive content when the scene enters the background — not when it resigns active, which also fires when an app is visible but inactive in Split View and would blank a screen the user is looking at. On Android, FLAG_SECURE keeps a window out of the recents thumbnail and blocks screenshots.
• Re-authenticate for sensitive views. A biometric check with Face ID, Touch ID or the Android equivalent before showing records protects the unlocked phone handed to someone else.
• Encrypt in transit, always. TLS for every connection, with App Transport Security left on. This is already expected, and under the proposed Security Rule it will be required in writing.

Choose a backend that will sign

AWS, Microsoft Azure and Google Cloud all sign BAAs, and each publishes the list of services the agreement covers. That list is the constraint: a service outside it cannot hold health data, even inside an account with a signed BAA. Being “HIPAA eligible” is also not the same as being compliant — the provider covers its share, and configuring, restricting and auditing access remains yours.

For Canadian users, decide where the data lives before you choose regions. PIPEDA does not forbid storing data outside Canada, but you must tell people and protect it, Quebec requires the privacy impact assessment first, and hospital and public-sector clients often require Canadian hosting in their contracts regardless of what the law says.

A checklist before you build

1. Map every data flow and whose behalf it serves. That decides HIPAA versus the FTC in the US, and custodian law versus PIPEDA in Canada — per flow, not per app.
2. List your provinces and states. Ontario, Alberta, Quebec, Washington, Nevada and Connecticut each change something.
3. Sign agreements before data moves. BAAs in the US, agent or service agreements with custodians in Canada, and a Law 25 assessment for anything leaving Quebec.
4. Audit every SDK against what it can see. Assume it sees everything until you have checked.
5. Design for the proposed Security Rule now: encryption at rest and in transit, MFA, an asset inventory and a tested restore.
6. Write the breach plan before you need it. Sixty days in the US, “as soon as feasible” in Canada, and a 24-month breach record under PIPEDA either way.
7. Check Apple’s guidelines 1.4.1 and 5.1.3 against your feature list and your marketing claims before you submit.

Getting this right is mostly a matter of making these decisions at the start. Every one of them is cheap in a design review and expensive in a rewrite. If you are planning a medical or health app for patients in the US or Canada, we build them with these decisions made on day one — see our mobile app development work, or tell us about your project.

This article explains how these laws affect software design. It is not legal advice. Health privacy law depends on your exact facts, and a lawyer who practises in your jurisdiction should review your obligations before launch.