HIPAA for health app developers: business associate test

When is a health app a HIPAA business associate?

A health app is a HIPAA business associate when it creates, receives, maintains or transmits protected health information for a covered entity or for one of the covered entity's contractors. It is not a business associate when a consumer uses the app to manage her own information, including data she downloads from her provider's portal or sends to her doctor on her own initiative. Under 45 CFR 160.103, the test is who the developer is acting for. HHS's Health App Use Scenarios (February 2016) apply that test to concrete cases: an app the consumer chooses and directs is generally outside HIPAA, while a developer given PHI access to provide and manage a personal health record or patient portal that a covered entity offers to its patients is generally inside it.

The answer turns on facts, not labels. Developers should map who creates and offers the app, who pays for it, who holds the contract, whether the provider or the consumer initiated the data flow, and whether the developer uses the data for its own purposes. An interoperability arrangement between an EHR and an app set up at the consumer's request does not by itself create a business associate relationship, but a provider-funded program that routes patients into the app may. The same app can sit on both sides of the line depending on the deployment, so the status should be re-checked whenever a new customer, payer or integration is added.

Only HHS guidance, the regulation itself and the advice of counsel who reviews the actual arrangement can settle a developer's status. DeployOpen provides technical scoping and evidence: a data flow inventory, a record of where PHI is created, stored and transmitted, and documentation of the safeguards the system uses. It does not make the legal determination. Confirm with counsel before launch, and confirm whether the FTC Health Breach Notification Rule applies if the app falls outside HIPAA, using the HHS mobile health apps resources as the starting point.

Which app scenarios HHS treats as business associate or not

HHS's first scenario covers an app a consumer uses to manage her own health information. The developer is not a business associate because it is not creating, receiving, maintaining or transmitting PHI on behalf of a covered entity. It acts for the consumer, who decides what the app stores and whether to share it. This holds even when the data was originally downloaded from her provider's patient portal or sent to her doctor at her own initiative.

The example HHS gives: a consumer downloads her lab results from her provider's portal into a fitness or health-tracking app she chose herself.
Who the developer acts for: the consumer, not the provider.
Who started the flow: the consumer, with no contract between the provider and the developer.
Who controls the data: the consumer can view, export and delete it in the app.
Who pays for the service: confirm whether the consumer pays directly. Covered entity funding of the app changes the analysis.

Confirm that the app's own marketing, terms and data flows describe the service as the consumer's tool, and that no provider engages the developer for the service.

Which business associate functions can catch a health app

The definition of business associate in 45 CFR 160.103 turns on what a company does with PHI for a covered entity, not on what kind of product it sells. The cards below map the listed functions and services to app features and contracts that could bring a developer within that definition, and to the checks worth making before assuming an app is outside HIPAA.

Claims processing and repricing

This function covers work that moves claims or payment requests between a provider and a payer, including repricing claims against a fee schedule. An app that submits claims, checks eligibility or recalculates charges for a covered entity may be performing this function. Check who engages the developer, whether the covered entity pays for the service, and whether PHI flows from the covered entity's systems into the app's processing.

Data analysis and benefit management

Data analysis for a covered entity, and benefit management for a health plan, can be regulated functions even when the output is a dashboard. An app that analyzes a practice's patient panel, flags care gaps or administers plan benefits on a plan's behalf may fall here. Confirm which party defines the analysis, who receives the results, and whether the developer uses the PHI for its own purposes.

Billing and practice management

Billing and practice management are named functions, and they are common in vendor relationships with clinics. A scheduling, invoicing or collections tool that a practice gives access to patient records is a typical case. Ask whether the app is sold to the practice to run its operations, or whether the consumer chose it. Where a practice configures or manages the app for its staff, treat that as a strong signal of a business associate relationship.

Legal, accounting and consulting services

The definition also covers legal, accounting, consulting, management and administrative services that involve disclosure of PHI. A developer that advises a covered entity on its patient communications, audits its billing records or runs its administrative operations with PHI access is within this language. Review the statement of work and any data access granted, because the service label alone does not decide the question.

Data access granted by the covered entity

Many developers receive PHI because a covered entity or its contractor provides it, through an EHR interface, a portal feed or a data extract. The definition turns on whether the developer creates, receives, maintains or transmits PHI for the covered entity. Map each data flow, identify who initiated it, and record whether the consumer or the provider is directing the exchange.

Written terms and the function actually performed

A contract that disclaims business associate status does not settle the question, and neither does a silence in the terms. Regulators look at what the developer does in practice. Review the agreements with each covered entity, the features offered to clinicians and the data retained after a consumer's session ends, then document the conclusion and the facts behind it.

Why business associate status makes the Security Rule apply directly

If your app is a business associate, the HIPAA Security Rule applies to you directly, not only through the covered entity that engaged you. The safeguards for electronic protected health information, the risk analysis, the written policies and documentation, and the duty to report security incidents and breaches become your own obligations. A covered entity cannot absorb them on your behalf, and an OCR investigation can name your company even when the covered entity's own practices are also examined. Before you build anything, confirm with counsel whether a given data flow makes you a business associate at all, because that determination sets every other obligation in this section.

Where the relationship exists, the two parties must sign a written business associate agreement before PHI changes hands. That contract must describe the permitted uses of PHI, require the safeguards the Security Rule calls for, and set out how security incidents and breaches are reported. Ask the covered entity for its template early, and check whether it requires the Security Rule protections you already plan to build, such as access controls, audit logging and encryption in transit. The sections on organizational requirements and documentation in the pillar explain what these contracts and records must contain, and the pillar's standards pages walk through each safeguard in turn.

The same duties flow downward. A business associate must obtain satisfactory written assurances from any subcontractor that creates, receives, maintains or transmits PHI for it, and those subcontractor agreements must impose the same restrictions and safeguards. Your hosting provider, analytics service, messaging vendor and support tools are candidates. Make an inventory of every service that touches PHI, confirm which ones will sign a business associate agreement, and record the gaps. The subcontractor flow-down topic in this group covers how those agreements are structured and what happens when one is missing.

Business associate versus app outside HIPAA: what changes

This table compares a health app developer acting for a covered entity with one acting for the consumer. Read each row against your own data flows to see which regime applies, and treat the HHS and FTC source labels as the origin of each position.

Question	Developer acts for a covered entity (HHS source)	Developer acts for the consumer (HHS and FTC source)
Who the developer acts for	The covered entity or its contractor, for example a patient portal or personal health record the provider offers to its patients (HHS, Health App Use Scenarios, February 2016)	The individual, who uses the app to manage her own information, including data downloaded from a provider portal or sent to her doctor on her own initiative (HHS, February 2016)
Whether the Security Rule applies directly	Yes. The developer is a business associate and must comply with the Security Rule for ePHI it creates, receives, maintains or transmits (HHS, 45 CFR 164.302 and 160.103)	No. HIPAA generally does not reach the developer because it is not acting on behalf of a covered entity (HHS, February 2016)
Whether a business associate agreement is needed	Yes. The covered entity needs a written business associate contract with the developer before PHI is shared (HHS, 45 CFR 164.314 and 164.504)	Generally no HIPAA business associate agreement, since the developer is not a business associate. Confirm whether any provider-side contract still applies to data flows (HHS, February 2016)
Breach notification regime that usually applies	The HIPAA Breach Notification Rule, with the business associate notifying the covered entity, which then notifies individuals and HHS (HHS Breach Notification Rule page)	The FTC Health Breach Notification Rule and the section 13407 HITECH provisions, which the FTC enforces against personal health record vendors and their third-party service providers (HHS Breach Notification Rule page, FTC)
Who the regulator is	HHS Office for Civil Rights, which enforces the Security Rule through complaints, compliance reviews and audits (HHS OCR)	The Federal Trade Commission, under the FTC Act and the Health Breach Notification Rule. The FTC, OCR, ONC and FDA jointly maintain the Mobile Health Apps Interactive Tool (FTC, HHS mobile health apps page)
Which role decides the answer	The covered entity's commissioning arrangement and the data it sends to the developer (HHS, February 2016)	The consumer's direction of the data and whether the app is offered on behalf of a provider (HHS, February 2016). Confirm the facts of each data flow with counsel

How to document your health app's HIPAA status

This sequence gives the developer's compliance lead a dated, written record of how the app's data flows, contracts and functions map to the HIPAA business associate definition, so the decision can be reviewed later. The record supports the determination; it does not certify compliance with HIPAA or any other rule.

Inventory every data flow and its initiator
List each place the app receives, stores, sends or displays health information, including data downloaded from a provider portal, data pulled through an EHR interoperability connection and data sent to a clinician. For each flow, record who starts it: the user, a covered entity, or the developer's own product logic. Owner: product lead with an engineer who knows the data architecture. Output: a data flow register that names each flow, its source, its destination and its initiator. The step is complete when every flow has an initiator recorded.
Record contracts and payment relationships
Collect every agreement with a covered entity or its contractor that touches the app, such as a license, integration agreement, patient portal build, co-branded offering or revenue-sharing arrangement. Note who pays for the app, who selects it, and who controls the branding and the data. Owner: contracts or legal counsel. Output: a contract index listing each agreement, its counterparty and the payment direction. The step is complete when the index shows whether any covered entity commissioned or pays for the app.
Map each function against the definition
Take each function from the data flow register and compare it with the regulatory definition of a business associate in 45 CFR 160.103, which covers persons who create, receive, maintain or transmit PHI for a covered entity for a regulated function or provide listed services involving PHI. Mark whether the developer acts for the consumer or for a covered entity on each function. Owner: compliance lead, with counsel review of close calls. Output: a function-by-function mapping memo with the reasoning for each row. The step is complete when every function has a documented conclusion.
Compare results with HHS use scenarios
Check the mapping against the scenarios in HHS OCR's Health App Use Scenarios & HIPAA guidance from February 2016, noting which scenario most closely matches each function. Where a function does not match a scenario, mark it as an open question instead of forcing a match. Owner: compliance lead. Output: a scenario comparison table attached to the mapping memo. The step is complete when each open question has an owner.
Run the Mobile Health Apps Interactive Tool
Work through the FTC, OCR, ONC and FDA Mobile Health Apps Interactive Tool using the same description of the app's function, data and services. Save the answers and the list of laws the tool points to, including the FTC Act, the FTC Health Breach Notification Rule, the HIPAA Rules, the FD&C Act, COPPA and information blocking rules where they appear. Owner: compliance lead. Output: a dated printout or export of the tool's answers and results, with the app version it describes. The step is complete when the output is filed with the mapping memo.
Reconcile the outputs and flag any gap
Compare the mapping memo with the tool's output. Where the tool points to HIPAA but the mapping finds no business associate function, or the reverse, record the difference and the reason for resolving it. Note any non-HIPAA regime that applies, such as the FTC Health Breach Notification Rule, which HHS describes as applying to vendors of personal health records under section 13407 of the HITECH Act. Owner: compliance lead. Output: a reconciliation note with a decision and a list of unresolved items. The step is complete when no output contradicts another without an explanation.
Obtain a written legal view where status is unclear
Where the status remains unclear after the mapping, send the data flow register, contract index, mapping memo and tool output to qualified health privacy counsel and ask for a written view on each open question. Ask counsel to state the assumptions they relied on. Owner: general counsel or outside privacy counsel. Output: a signed legal memo that addresses each open question. The step is complete when every open item has either a conclusion or a documented reason it remains open. Counsel's view, not this record, is the source of legal advice.
Date, approve and schedule a review
Assemble the register, index, memo, scenario table, tool output, reconciliation note and any legal memo into one dated package. Have an accountable executive approve the status determination and name the trigger events that require reopening it, such as a new covered entity contract, a new data flow or a change in who pays for the app. Owner: accountable executive with the compliance lead. Output: an approved status record with a review trigger list. The step is complete when the package is stored under version control and the triggers are assigned.

Mistakes that pull an app into HIPAA by accident

Most app teams do not set out to become business associates. They drift into it through a partnership, a feature request or an analytics integration that changes who the app acts for. The pitfalls below are the points where that drift usually happens, along with what to check and record at each one.

Treating a consumer label as the answer

Calling an app consumer-facing does not settle HIPAA status by itself. HHS looks at who the developer creates or offers the app for and who directs the data flow. Check whether a covered entity or its contractor asked for the app, pays for it, or uses it to serve its own patients. Document the consumer's own initiative for each data flow, such as a user choosing to download records from a portal.

Letting a provider host the app

A common arrangement has a covered entity list the app on its portal while the developer runs the back end and holds the data. HHS treats a developer who creates or offers an app on behalf of a covered entity as a business associate. Confirm in writing who the developer serves, who controls the data, and whether the app exists only because the provider offers it.

Adding a provider-funded feature unreviewed

A provider may pay for a feature that sends clinical data to the app, such as care reminders or remote monitoring. That feature can move the developer from consumer tool to contractor for the provider, even though the base app stayed the same. Before building any provider-funded feature, review the contract, the data specification and the scope of PHI access, and record the status decision for that feature.

Sending PHI to analytics and advertising tools

Software development kits for analytics, crash reporting and advertising often receive device identifiers, health events or form contents. When the app receives PHI from a covered entity, a third party that receives that data on the developer's behalf may also become a subcontractor. Inventory every third-party SDK, state which data it receives, and block health data from advertising and marketing endpoints.

Ignoring interoperability arrangements

An app that connects to a provider's electronic health record at a patient's request is generally not a business associate by that connection alone, because the developer acts for the consumer. The status can change if the provider sets up the arrangement, sponsors the connection or uses the data for its own purposes. Keep records of who requested each connection and who benefits from the exchange.

Relying on vendor certificates as proof

Badges, certificates and security seals do not establish HIPAA status. HHS does not recognize private certifications, and no Security Rule standard requires certification. Status depends on the functions the developer performs for a covered entity. Keep a dated status memo that cites the scenarios relied on and the facts behind them, and revisit it whenever a partner, feature or data flow changes.

Questions developers ask about HIPAA and health apps

Does a wellness app need to comply with HIPAA?

Not automatically. HIPAA applies to a health app when the developer is a business associate, which means it creates, receives, maintains or transmits PHI on behalf of a covered entity or its contractor. HHS's *Health App Use Scenarios* (February 2016) treats an app as outside HIPAA when a consumer uses it to manage her own information, even if the data came from her provider's portal or was sent to her doctor at her own initiative. The deciding questions are who asked for the app to exist, who pays for it and whose instructions the developer follows. Map those answers against the scenarios before deciding.

Is a business associate agreement always required for a health app?

No. A business associate agreement is required only where the developer is a business associate. HHS says an interoperability arrangement between a provider's EHR and an app, set up at the consumer's request, does not by itself create that relationship, because the developer acts for the consumer. The position changes when a covered entity offers the app to its patients, or gives the developer PHI access to provide and manage a personal health record or patient portal the covered entity offers. Review each contract and business model rather than assuming either outcome.

Does the FTC apply to an app that falls outside HIPAA?

It can. The FTC, working with OCR, ONC and FDA, maintains a Mobile Health Apps Interactive Tool that asks developers about the app's function, data and services, then points to laws that may apply. The list includes the FTC Act, the FTC Health Breach Notification Rule, the HIPAA Rules, the FD&C Act, COPPA and information blocking rules. Section 13407 of the HITECH Act also gives the FTC breach notification duties for vendors of personal health records and their third-party service providers. Run the interactive tool early, because a non-HIPAA app still carries breach and privacy obligations.

Who decides whether our app is a business associate?

Your organization decides, based on the facts of each arrangement, and it should document that reasoning. HHS publishes the scenarios and the definition in 45 CFR 160.103, but it does not issue determinations for individual apps. An outside lawyer or consultant can analyze your model and document a view, but that opinion is advice, not an official ruling. No HIPAA certificate exists: HHS states that no Security Rule standard requires certification and that it does not recognize private certifications. Ask any outside party to state its reasoning in writing and to name the scenarios it relied on.

What does it cost to determine HIPAA status, and how long does it take?

The cost depends on how many data flows, customer contracts and partner integrations you have, and on whether you need a written memo or only an internal decision. Most of the work is inventory and contract review, so an app with a single consumer-only data flow is simpler than one that sells to clinics and feeds data to health systems. Ask any provider for a fixed-scope quote that lists the data flows reviewed, the contracts read, the deliverable format and whether a follow-up review is included. No researched fact supplies a price or duration for this work, so confirm both in writing with each provider.

What information does our team need to provide for the review?

Gather a data flow map showing what personal data the app collects, where it is stored, which parties receive it and at whose request. Add the list of customers and partners, the contracts or terms that govern each relationship, and the business model, including who pays for the app. Include the consumer-facing sign-up and consent flows, and any integration with a provider's EHR or patient portal. Finally, identify any FTC Health Breach Notification Rule or state law exposure you already know about. A reviewer who has these inputs can test each scenario against facts rather than assumptions.

Can we handle the status determination ourselves?

Yes, if you have the legal and privacy expertise to read the HHS scenarios, the definition in 45 CFR 160.103 and your own contracts. Many teams do the first pass internally and bring in counsel for edge cases, such as a partner integration that changes who directs the data. Keep the analysis in writing with a date and the version of the app it describes, because your data flows will change. Revisit the decision whenever you add a covered entity customer, a new integration or a new data use.

How DeployOpen assesses a health app's HIPAA position

DeployOpen starts by working out whether your app acts for a covered entity or for the consumer, because that answer decides which HIPAA duties apply. We then prepare the platform, controls and documentation that match the answer, inside your own infrastructure. Only an independent auditor or certification body can issue any report or certificate.

How we scope

Written scope records each data flow, who requests it, and whether a covered entity or its contractor commissions the app.
Scope lists which features touch consumer-directed exchange and which involve a provider's patient portal or EHR integration.
We agree scope, deliverables and timelines in writing before work starts, and quote from that written scope.

How we build

We implement self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks, with access logging and encryption configured.
We test applications, APIs and infrastructure for security weaknesses, and document findings and remediation for the scoped systems.
Where the app may be a business associate, we prepare Security Rule safeguards, policies and documentation for the systems in scope.

How we hand over

Handover includes architecture records, configuration baselines, test results and a data flow map for the scoped systems.
We document which HIPAA determinations are your decisions, which need legal counsel, and which need an independent assessor.
Evidence packages are organized so your compliance team or an outside assessor can trace each safeguard to a system.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can re-check the app's data flows when features, partners or consumer-directed integrations change.
Confirm with us in writing which support and testing services sit inside your retainer before signing.

HIPAA for health app developers: when an app is a business associate