HIPAA Audit Readiness Guide for Fertility Tracking App Developers

When does HIPAA apply to a fertility tracking app?

HIPAA does not apply to an app simply because it collects sensitive reproductive or fertility information. It generally applies when a covered entity—such as a qualifying health care provider, health plan, or health care clearinghouse—or its business associate creates, receives, maintains, or transmits protected health information (PHI) in a regulated relationship. Whether information is electronic protected health information (ePHI) depends on the information and the context in which a covered entity or business associate handles it.

A direct-to-consumer fertility app that operates independently and is not offered by or on behalf of a covered entity is not automatically subject to HIPAA. HHS explains that HIPAA generally does not cover health information users enter into an app that is not offered by or on behalf of a regulated entity; other requirements, including FTC rules, may still apply. See HHS guidance on online tracking technologies and its business associate guidance.

For audit planning, map how the app is offered and how data moves. Identify whether a clinic, health plan, or another covered entity offers the app to patients or members, and whether your company handles their PHI on that entity’s behalf. The sensitivity of fertility data matters for risk management, but does not alone determine HIPAA coverage.

How can developers determine whether they are business associates?

A developer may be a business associate when it performs a regulated function or service for a covered entity involving PHI—for example, providing a fertility-tracking app to a clinic’s patients and handling their data for patient management. A developer may also be a business associate if it handles PHI on behalf of another business associate. HHS describes health app developers working for covered entities as a possible example in its business associate guidance.

Assess the actual arrangement, not just the contract’s title. Document who directs the service, whose purposes it serves, what information the app receives, and whether your company creates, receives, maintains, or transmits PHI on the entity’s behalf. A HIPAA business associate agreement (BAA) records required assurances when the relationship meets the definition; signing a BAA alone does not make an otherwise unrelated consumer app a business associate.

If your company is a business associate, establish the required BAA with the covered entity and assess whether subcontractors that handle PHI need written assurances as well. Keep a current inventory of those relationships, the data each party handles, and the permitted purposes for using or disclosing it. The definition and contract requirements appear in 45 CFR § 164.314 and HHS’s business associate guidance.

How to conduct and document an ePHI risk analysis

The Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI they hold. It also requires them to manage identified risks. Review 45 CFR § 164.308 and HHS’s risk analysis guidance.

For a fertility app, inventory the ePHI, systems, and data flows in scope. Include app inputs and outputs, account and device identifiers, integrations, databases, backups, analytics tools, support systems, cloud services, and administrative access. Record where data originates, where it is stored or transmitted, and which people and software can access it.

Assess relevant threats and vulnerabilities, existing safeguards, and the potential impact if data is exposed, altered, lost, or unavailable. Document the assessment method, findings, risk decisions, assigned owners, planned safeguards, and target dates. Revisit the analysis when you add a feature, vendor, integration, or data source, or when a security incident or operational change could affect ePHI. HHS describes risk analysis as an ongoing process that should inform risk management, not a one-time checklist.

Which audit controls and evidence should developers maintain?

The Security Rule requires mechanisms to record and examine activity in information systems that contain or use ePHI. It also requires regular review of information system activity records, including audit logs, access reports, and security incident tracking reports. See 45 CFR § 164.312 and 45 CFR § 164.308.

Maintain evidence that lets you explain how controls operate and how your team checks them. Depending on your systems and risks, useful evidence may include:

• Current risk analyses, risk-management decisions, system inventories, and data-flow diagrams.
• Policies and procedures for access, authentication, audit controls, incident response, backups, and vendor oversight.
• Audit controls and activity logs, access reports, evidence of log review, and records of identified issues and follow-up.
• User access approvals, periodic access reviews, role or permission changes, and timely removal of access when a worker’s role ends.
• BAAs and subcontractor agreements, security incident records, training documentation, and contingency-plan test results.

This is a practical audit-readiness set, not a fixed list of log fields prescribed for every app. Keep documentation current, assign owners, and make records easy to retrieve. The Security Rule generally requires required documentation to be retained for six years from its creation or the date it was last in effect, whichever is later; see 45 CFR § 164.316.

How to review access controls and automatic logoff settings

Review technical access controls to ensure that only appropriately authorized people and software can access ePHI. Use individual accounts where appropriate, align permissions with job responsibilities, and document processes for granting, changing, reviewing, and ending access. The Security Rule’s access control standard and implementation specifications are set out in 45 CFR § 164.312.

Automatic logoff is an addressable implementation specification—not a blanket requirement to use one particular timeout. “Addressable” does not mean ignore it: assess whether it is reasonable and appropriate for your environment and document the decision. If you do not implement the specification as written, document why and implement an equivalent alternative measure when reasonable and appropriate. Consider the sensitivity of displayed data, session risk, device use, and how quickly unattended sessions could expose ePHI.

Test session behavior and record the settings, rationale, results, and any corrective action. Also review authentication and access logs for failed login attempts, unusual access, privilege changes, and other activity relevant to your risk analysis.

What documentation should cloud vendors and tracking technologies provide?

A cloud service provider that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate generally meets the business associate definition. HHS says this can apply even when the provider cannot view encrypted ePHI because it lacks the decryption key. The customer should enter into an appropriate BAA and assess the service’s security responsibilities as part of its own risk analysis. See HHS guidance on HIPAA and cloud computing.

Do not assume HIPAA requires a cloud provider to supply every requested security document or grant audit rights: HHS notes that the HIPAA Rules do not expressly require a cloud provider to disclose security-practice documentation or allow customer audits. Set out useful evidence and cooperation terms contractually where possible, and understand which security features your company must configure and manage.

Inventory tracking technologies—such as analytics SDKs, advertising tools, pixels, and session-recording scripts—and document what each collects, where it sends data, and who can receive it. For a HIPAA-regulated app, assess whether the information includes PHI and whether the disclosure is permitted. A privacy-policy statement or cookie banner alone does not authorize an otherwise impermissible HIPAA disclosure. HHS explains these limits in its guidance on HIPAA and online tracking technologies.

How do FTC health breach notification rules apply to consumer apps?

A consumer fertility app that is not covered by HIPAA may still fall under the FTC Health Breach Notification Rule if it is a vendor of personal health records, a related entity, or a service provider to one of those entities. For example, the FTC says a health app that collects information from consumers and can sync with a fitness tracker may qualify as a vendor of personal health records. Applicability depends on the Rule’s definitions and the app’s actual data sources and relationships; it does not follow from the app’s subject matter alone. See the FTC’s guidance on complying with the Health Breach Notification Rule.

The FTC Rule covers certain breaches involving unsecured, identifiable health information, including unauthorized disclosures in circumstances covered by the Rule. When it applies, developers should have a response process for assessing incidents and determining required notifications to affected individuals, the FTC, and, in some cases, the media. The Rule generally requires notice to affected individuals without unreasonable delay and no later than 60 calendar days after discovery; the FTC notification schedule varies depending on the number of affected individuals. Consult the current text of 16 CFR Part 318 and the FTC’s Health Breach Notification Rule overview.

For audit readiness, document data flows to analytics and advertising vendors, review whether disclosures are authorized, and keep an incident-response plan that addresses both HIPAA and FTC obligations when relevant. Strong readiness depends on knowing which rules apply, documenting risk decisions, reviewing access and activity, and managing vendors that handle fertility data.

FAQs

Does collecting reproductive health data make a fertility app subject to HIPAA?

No. Collecting reproductive health data by itself does not make an app subject to HIPAA. Applicability generally depends on whether the app developer is a covered entity or handles PHI on behalf of a covered entity or business associate. A direct-to-consumer app may still have obligations under other laws, including the FTC Health Breach Notification Rule.

When is a fertility tracking app developer considered a business associate?

A developer may be a business associate when it handles PHI while performing a regulated function or service on behalf of a covered entity, such as providing an app for a clinic’s patients and managing their data for the clinic. The actual services, data flows, and relationship determine the answer; a BAA records the required assurances but does not by itself create business associate status.

What audit evidence should a HIPAA-regulated app developer maintain?

Maintain current risk-analysis and risk-management records, system and data-flow inventories, relevant policies, audit logs and evidence of their review, access approvals and reviews, incident records, BAAs, and documentation of security decisions. Retain required Security Rule documentation for the period specified in 45 CFR § 164.316.

Do cloud providers handling ePHI need a business associate agreement?

Generally, yes, when a cloud provider creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate. HHS says this can apply even if the ePHI is encrypted and the provider lacks the key to decrypt it. The parties should confirm the service arrangement and document the required assurances in an appropriate BAA.