Do Fitness and Wellness Apps Need to Be HIPAA Compliant?

You are building a fitness or wellness app. Somebody — an investor, a prospective enterprise customer, a lawyer at a party — has told you it needs to be HIPAA compliant. Your engineer says the app only stores workouts and heart rate, so it does not. Both of them are describing a real situation, and neither has asked the question that decides it.

HIPAA does not regulate health data. It regulates specific organizations, and then it regulates the data those organizations hold. That single distinction resolves about 80% of the confusion in this topic, and almost every article ranking for this query skips it because the article was written by a company selling compliance software.

This page is written by people who build these systems. It is not legal advice — nobody on the internet can tell you your regulatory status, and anyone who does without seeing your contracts is guessing. What it will do is get you to the four or five facts that actually determine the answer, so that when you do pay a lawyer, you pay for 90 minutes instead of a discovery project.

The short answer, before the detail

If your row says "no", read the section titled Not HIPAA is not the same as not regulated. That is where most consumer apps actually get into trouble.

HIPAA regulates entities, not information

The Health Insurance Portability and Accountability Act creates obligations for two categories of organization, plus their subcontractors.

Covered entities are three specific things:

1. Health plans — insurers, HMOs, employer group health plans, government programs that pay for care.
2. Health care clearinghouses — organizations that translate health data between formats, typically for billing.
3. Health care providers who transmit health information electronically in connection with certain standard transactions — claims, eligibility checks, referral authorizations, and similar.

That third one has a condition attached that people miss. A provider is only a covered entity if they conduct one of the standard electronic transactions. A cash-only therapist who never submits an electronic claim is, strictly, not a covered entity. In practice most providers are, because insurance billing is electronic, but the condition matters when you are building for cash-pay coaching, concierge medicine, or direct-pay wellness.

Business associates are organizations that create, receive, maintain, or transmit protected health information on behalf of a covered entity, in order to perform a function for that covered entity. This is where nearly every health-tech vendor lands. You are not a hospital. You are a company doing work for a hospital that requires touching its patients' data.

Subcontractor business associates are the layer below that. If you are a business associate and you use a cloud host, an SMS provider, or an analytics service that touches the same data, they are business associates too, and the obligations flow down through the chain by contract.

The word "compliant" attaches to none of these automatically. HIPAA obligations attach because of a relationship, and the relationship is usually created by a contract. Which means the honest version of the question is not "is my data sensitive?" It is: who am I doing this work on behalf of, and what have I signed?

PHI versus consumer health data: the same heart rate, two legal realities

Protected health information is individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate. The definition is circular on purpose. The same data point is PHI in one system and not PHI in another.

Consider a resting heart rate of 48 bpm.

• Recorded by a consumer running app the user downloaded themselves: not PHI. It is consumer health data. Sensitive, valuable, attractive to attackers, subject to other laws — but not PHI.
• The same number, pulled into a cardiology practice's remote-monitoring dashboard by a vendor the practice hired: PHI. The vendor is a business associate. The number is now individually identifiable health information held on behalf of a covered entity.
• The same number in the user's own Apple Health app: not PHI. Apple is not acting on behalf of a provider.

Nothing about the number changed. The relationship changed.

This is why "we store health data so we must be HIPAA compliant" is a category error, and why "we're just a wellness app so nothing applies" is a different one. Both skip the relationship question.

The identifier question people get backwards

De-identified data is not PHI, and the rule gives two ways to get there: an expert determination by a qualified statistician, or the Safe Harbor method — removing a defined list of eighteen identifier categories and having no actual knowledge that the remainder could identify someone.

The list includes the obvious things (name, SSN, medical record number, email, phone) and the ones that surprise engineers: IP addresses, device identifiers and serial numbers, URLs, biometric identifiers including fingerprints and voiceprints, full-face photographs, all elements of dates except the year, and geographic subdivisions smaller than a state.

Two practical consequences for anyone building a mobile app:

• Your analytics payload almost certainly contains an IP address and a device identifier. "We only send anonymized events" is usually false the moment you look at the actual request.
• Age is fine. Date of birth is not. If your cohort analysis needs birthdates, it is not de-identified analysis.

If you are building a research or benchmarking feature on top of user data, this is the section to send your data team.

When the relationship attaches — four scenarios

1. Direct-to-consumer, no provider anywhere

You build a strength-training app. Users find it in the App Store, pay you, log workouts, sync a Whoop strap. No clinician is involved. No employer bought it. You bill nobody's insurance.

HIPAA does not apply. You are not a covered entity and you are not acting on behalf of one. You can stop reading the Security Rule.

You are not, however, free. Skip to the next major section.

2. Direct-to-consumer, with clinicians you employ

You build a nutrition app and you employ registered dietitians who deliver plans through it. Now ask: do you bill insurance electronically for that work? Do you submit claims, check eligibility, or request authorizations?

If yes, you are likely a covered entity in your own right, not a business associate — a different and generally heavier position, because the full Privacy Rule applies to you directly, including notice of privacy practices, individual rights of access and amendment, and accounting of disclosures.

If it is cash-pay only and nothing is billed electronically, the analysis is genuinely more nuanced, and this is one of the specific places where you should stop and get counsel rather than reason your way to a comfortable answer. State licensure and scope-of-practice rules will also be in play and they are frequently the bigger constraint.

3. Employer-purchased wellness

An employer buys your meditation or fitness app for its workforce. The instinct is that this is B2B so HIPAA must apply. It depends on the pipe the money and data run through.

If the app is a perk purchased by HR, sitting outside the group health plan, and the employer receives only aggregate engagement reporting, you are usually outside HIPAA — but squarely inside employment-privacy law, ADA and GINA considerations, and the employee's very reasonable expectation that their employer cannot see their therapy usage.

If the app is offered through the employer's group health plan, or you receive data from the plan or its administrator, the plan is a covered entity and you are likely its business associate.

Ask the buyer this exact question during procurement: "Is this being purchased by the group health plan, or by the company outside the plan?" Their benefits counsel will know. Your contract should say which, explicitly.

4. B2B to a clinic, hospital, or health plan

This is the one that changes everything, and it is the one your sales team will walk into first.

The moment a provider organization signs with you and your product touches their patients' data, you are a business associate. You will be asked to sign a Business Associate Agreement, you will be asked to complete a security questionnaire that is longer than your product spec, and you will be contractually and directly liable under HIPAA for the safeguards in the Security Rule.

This is not a settings toggle. It is an architectural and organizational change: encryption posture, audit logging, access control, workforce training, incident response with defined timelines, documented risk analysis, subprocessor management, and BAAs flowing down to every vendor in your stack that touches the data. We wrote the engineering side of that in how to build a HIPAA-compliant app, and the contract side in what a BAA actually commits you to.

What actually changes the day you sell B2B

Founders underestimate this transition badly, so here it is concretely. Selling the same product to a clinic instead of a consumer changes at least the following.

Your vendor list becomes a liability. Every third-party service that touches identifiable data needs a BAA. Some of your favorites will not sign one — several popular analytics, session-replay, crash-reporting, and customer-messaging tools either will not offer a BAA at all or will only offer it on an enterprise tier at a price that reshapes your unit economics. You will find this out during the security review, not before, unless you audit first.

Your logs become in scope. The error report that includes a request body. The support tool where an agent pastes a screenshot. The Slack channel where an on-call engineer drops a stack trace with a patient ID in it. This is where the majority of real-world exposure lives, and no amount of database encryption touches it.

Your analytics stop being free. Product analytics that identify users, marketing pixels on authenticated pages, and third-party SDKs in an app that handles PHI are the single most common finding in a health-tech security review. Third-party trackers on pages behind a patient login have been an active enforcement and litigation area. Assume you will have to remove or replace some of them.

Your access model gets audited. "Everyone at a ten-person startup has production access" is a normal engineering choice and an unacceptable compliance answer. Role-scoped access, least privilege, and a revocation process become table stakes.

Your sales cycle gets longer and your deal gets bigger. This is the compensation. Security review is a real cost, and it is also a moat: the competitor who did not do it cannot pass it.

You inherit breach obligations with clocks on them. Business associates must report breaches to the covered entity, and the covered entity has notification duties to individuals, to HHS, and in larger incidents to media. There are defined outer limits on these timelines and thresholds tied to the number of individuals affected.

Not HIPAA is not the same as not regulated

Here is the part the compliance-vendor articles skip, because they sell HIPAA products and this is not a HIPAA problem.

If you are a consumer wellness app outside HIPAA, you are still governed by:

The FTC. Unfair or deceptive practices — which in practice means your privacy policy is an enforceable promise. If you say you do not share health data and your SDK does, that is the violation. Separately, the FTC's Health Breach Notification Rule reaches vendors of personal health records and related entities that are not covered by HIPAA, and it has been used against consumer health apps for disclosing user health data to advertising platforms without authorization.

State consumer health privacy laws. Washington's My Health My Data Act is the significant one because of how broadly it defines consumer health data and because it includes a private right of action — meaning plaintiffs' firms, not just regulators. Nevada passed a comparable law. California treats health information as sensitive personal information under CPRA with its own obligations.

Platform rules. Apple and Google both impose health-data terms that are stricter than US law in places. HealthKit data cannot be used for advertising or sold to data brokers, and health apps face additional review scrutiny. Violating these does not get you fined; it gets you removed, which is worse for a startup. Our wearable integrations page covers the permission and review mechanics.

GDPR and UK GDPR, if you have EU or UK users. Health data is a special category requiring an explicit lawful basis. This is frequently a heavier obligation than HIPAA would have been.

State biometric laws, if you do pose estimation, face-based body composition, or voice analysis. Illinois BIPA in particular carries a private right of action and has produced substantial settlements. If you are shipping computer vision for fitness, this is your live risk, not HIPAA.

So the accurate statement for most consumer wellness apps is: HIPAA does not apply, and we have four other regimes to get right. That is a less comfortable sentence than "we're not HIPAA", and it is the true one.

The wrong answers founders are given

"Just use a HIPAA-compliant cloud." No cloud is HIPAA compliant on your behalf. AWS, Google Cloud, and Azure all offer BAAs and a list of covered services — that makes them capable of being used compliantly. Your application architecture, your access control, and your operational practices are still entirely yours. A BAA with your cloud provider is roughly 10% of the work.

"We'll get HIPAA certified." There is no such thing. HHS does not certify anyone and no third party can confer HIPAA compliance. Vendors sell attestations, assessments, and readiness reports, and some of those are genuinely useful — but if a development studio tells you they are HIPAA certified, that single sentence tells you how carefully they read regulations. We say this on our own trust page because it costs us deals with buyers who wanted to hear the word.

"Encryption makes it compliant." Encryption is one technical safeguard among many, and the Security Rule's flexibility means the right implementation depends on your risk analysis. Encryption also does nothing about the largest category of real incidents: authorized people accessing data they should not have, and data leaking through logs, analytics, and support tooling.

"We de-identify everything." Usually not true at the level of rigor the standard requires — see the identifier list above. And even where it is true, the de-identification has to happen before the data reaches the system you are claiming is out of scope, not after.

"Our terms of service say users consent." Consent is not the mechanism HIPAA uses, and for the non-HIPAA regimes above, buried consent in a ToS is precisely the fact pattern regulators have pursued.

A decision framework you can run in an afternoon

Work through these in order and write down the answers. This is the substance of what a good lawyer will ask you, and having it prepared is the difference between a short engagement and a long one.

1. Who pays you? Consumers, employers, providers, plans, or another vendor. List every revenue channel, including the pilot you have not signed yet.
2. On whose behalf are you performing a function? For each channel — nobody, or a named organization.
3. Is that organization a covered entity? Health plan, clearinghouse, or provider that bills electronically.
4. Have you signed, or been asked to sign, a BAA? Being asked is a strong signal about how the counterparty sees the relationship. Signing one you did not need still binds you contractually.
5. What identifiable data actually flows, and where? Not the diagram — the real one. Include analytics, crash reporting, support tooling, backups, and anywhere an engineer can read production data.
6. Which third parties see it? Every SDK, every webhook, every integration. Check which of them will sign a BAA.
7. Where are your users? EU, UK, California, Washington, Illinois each add something.
8. What do you claim publicly? Your privacy policy, marketing site, and App Store copy are the promises you will be held to.

Steps 5 and 6 are the ones teams skip and the ones that produce the ugly findings. If you get through the list and are still unsure which scenario you are in, send us your answers — that is usually enough for us to tell you, or to tell you it is a question for counsel.

We build that inventory as part of the Healthtech MVP Blueprint — a sensitive-data and claims inventory, an intended-use boundary, and the specialist decision points, at $1,999 over seven days. It is planning, not certification, and it is deliberately cheaper than discovering the same list during a customer's security review.

The unprofitable advice: do not build HIPAA scaffolding you do not need

We build HIPAA-aware apps for a living, so the profitable thing to say here is that every health app should be built to the standard from day one. That is not true and it wastes founders' money.

If you are a consumer wellness app with no provider relationship and no clinic pipeline, building full Security Rule infrastructure into your MVP buys you compliance you are not subject to, at the cost of the runway you needed to find out whether anyone wants the product. We would rather scope a $12,000 MVP that ships than a $40,000 one that is audit-ready and unlaunched.

What we do recommend, because it is cheap now and expensive later, is a set of architectural decisions that keep the door open:

• Separate identity from health data at the schema level. Keep identifiers in one place with a stable internal ID, and health records keyed by that ID. This makes de-identification, deletion, and export tractable, and it is nearly free on day one.
• Do not log request bodies by default. Structured logging with explicit field allow-lists. Retrofitting this after a year of logs is genuinely painful.
• Put every third-party SDK behind a flag. So that "remove the tracker from authenticated screens" is a config change, not a release cycle.
• Choose a cloud that offers a BAA and stay on services covered by it, even before you need it. This constrains you very little and saves a migration.
• Write down your data flows as you build them. A one-page diagram maintained continuously is worth more than a forty-page policy generated in a panic.
• Keep audit trails from the start on any read of another person's data. Coach views client. Admin views user. If your product has any multi-party access, log it. This is the single item most often retrofitted badly.

Those six choices cost days, not weeks, and they mean that when a clinic wants to buy your app you are having an engineering conversation instead of a rewrite conversation.

What "HIPAA-aware" means when we say it

We build HIPAA-aware, compliance-conscious systems, and we map sensitive-data, claims, and clinical boundaries during planning. We sign BAAs where an engagement puts us in contact with PHI on behalf of a covered entity or another business associate, and we sign them before touching a PHI environment rather than after kickoff.

We do not issue certifications — none exist — and we do not provide legal or regulatory sign-off. We do not determine whether your product is a regulated medical device; if we think that question needs a specialist, we would rather say so in week one than at submission. That is the same boundary published on our trust page, and it is the boundary we hold in a sales call.

For a product like Patient Talker, that meant end-to-end encryption on patient communication and a third-party security assessment as a condition of release. For an early consumer wellness MVP, it usually means the six architectural decisions above and nothing more, because the rest is not yours to carry yet.

This article is general information about how HIPAA is structured. It is not legal advice, it does not create any advisory relationship, and your regulatory status depends on facts specific to your contracts, your data flows, and your users. Get counsel before you rely on any conclusion here.

If you want the fastest useful next step, tell us who buys your product and what data moves between you and them. That is usually enough for us to tell you which of the four scenarios you are in and what it changes. Start there.

Frequently asked questions

Do fitness apps need to be HIPAA compliant?

Most do not. A consumer fitness app where users sign up themselves, with no relationship to a health plan or a provider organization, is generally outside HIPAA entirely — the data it holds is consumer health data, not PHI. That changes if you sell to a clinic, plan, or employer group health plan, or if you employ clinicians and bill electronically.

Is heart rate or workout data considered PHI?

Only when it is held by a covered entity or a business associate. The identical heart-rate reading is PHI inside a cardiology practice's monitoring vendor and not PHI inside a consumer running app. PHI is defined by who holds the data and on whose behalf, not by how medical the data feels.

We're not covered by HIPAA. Does that mean we can do what we like with user health data?

No, and this is where consumer apps get into the most trouble. The FTC treats your privacy policy as an enforceable promise and has pursued health apps over ad-tech disclosures under its Health Breach Notification Rule. Washington's My Health My Data Act and comparable state laws cover consumer health data directly, some with a private right of action. Apple and Google impose their own health-data terms.

What happens the day a clinic wants to buy our consumer app?

You become a business associate, you sign a BAA, and you inherit direct obligations under the Security Rule. Practically: audit logging, access control, a documented risk analysis, workforce training, incident response with defined timelines, and BAAs with every vendor in your stack that touches the data. Expect a security questionnaire and budget real engineering time for it.

Can a development agency make our app HIPAA compliant?

An agency can build the technical safeguards, architect data flows correctly, and sign a BAA for its own access. It cannot make you compliant, because compliance includes policies, training, risk analysis, and contracts that belong to your organization. Anyone claiming to deliver "HIPAA certification" is describing something that does not exist.

How much does HIPAA readiness add to a build?

It depends far more on your architecture than on a compliance product. We break the honest ranges down in what HIPAA compliance actually costs a startup, including the parts that are one-time and the parts that are permanent operating cost. Our published prices are on the pricing page.

Do we need a BAA with our cloud provider?

If you handle PHI, yes — and you also need to stay within the list of services that provider's BAA covers, which is narrower than its full catalog. A BAA with AWS, Google Cloud, or Azure makes compliant use possible; it does not make your application compliant. See BAAs explained.

Our app gives AI-generated wellness advice. Does HIPAA cover that?

HIPAA governs whether you can hold and disclose the data, not whether the advice is appropriate. If your AI feature makes claims about diagnosing, treating, or mitigating disease, the more urgent question is medical-device status, not HIPAA. We cover that boundary in is your wellness app a medical device.