HIPAA-Compliant Health Data APIs: A Checklist for Product Teams

Compliance is one of those topics that product teams know matters but often defer until it becomes urgent — usually when a healthcare customer asks “Are you HIPAA compliant?” during a sales call, or when a regulatory change makes the news.

This guide is designed to be the reference you read before that moment. It covers when HIPAA actually applies to your product (the answer may surprise you), what other regulations fill the gaps where HIPAA doesn’t, what the upcoming Security Rule changes require, and a practical checklist for evaluating and building on top of a compliant health data API.

When HIPAA applies (and when it doesn’t)

The most common misconception in digital health: “We handle health data, so we need to be HIPAA compliant.”

Not necessarily. HIPAA has a narrow scope, and understanding it prevents both under-compliance and over-engineering.

HIPAA applies when:

HIPAA covers covered entities and their business associates [1]:

• Covered entities: Health plans (insurers), healthcare providers who transmit data electronically (hospitals, clinics, doctors), and healthcare clearinghouses
• Business associates: Any organization that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity

If your health app or API processes data under contract with a covered entity — a hospital, an insurer, a health plan — you are likely a business associate and HIPAA applies. This requires a Business Associate Agreement (BAA) between you and the covered entity.

HIPAA does not apply when:

If your app collects health data directly from consumers without a relationship to a covered entity, HIPAA generally does not apply [2][3]:

• A fitness app that reads heart rate from a user’s Apple Watch
• A wellness platform that collects sleep data from a smartphone
• A coaching app that tracks activity and nutrition
• A wearable companion app that stores health metrics

The same heart rate reading is PHI when transmitted from a hospital’s monitoring system to a vendor under a BAA, but is not PHI when a user’s fitness tracker sends it to a standalone app [3].

The critical nuance

Many health apps operate in both worlds. Your app might serve individual consumers (no HIPAA) and also contract with an employer wellness program administered by a health plan (HIPAA applies). The moment a covered entity enters your data flow, HIPAA obligations attach.

Practical advice: If your product roadmap includes healthcare customers — insurers, hospitals, health plans, employer wellness programs — build for HIPAA compliance from the start. Retrofitting is significantly more expensive than building it in.

The regulations that apply when HIPAA doesn’t

Consumer health data is not unregulated just because HIPAA doesn’t apply. Several overlapping frameworks create obligations:

FTC Health Breach Notification Rule

Updated in 2024, the FTC’s Health Breach Notification Rule (HBNR) now explicitly covers health apps, fitness trackers, and wearables [4]. Requirements:

• Breach notification within 60 days to affected individuals
• Disclosure of third parties who acquired the data
• FTC notification for breaches affecting 500+ people
• Applies to “personal health records” that include health information from consumer-facing technology

This effectively creates a HIPAA-like breach notification obligation for consumer health apps, even without a covered entity relationship.

Washington My Health My Data Act

Washington State’s MHMDA (effective March 2024) is the most comprehensive state-level health data privacy law [5][6]:

• Applies to any entity collecting health data from Washington residents
• Requires opt-in consent for data collection, with separate consent for sharing
• Selling health data requires written authorization identifying the data, buyer, and purpose
• Prohibits geofencing within 2,000 feet of healthcare facilities
• Grants consumers rights to access, delete, and withdraw consent (45-day response window)
• Enforceable through the state Attorney General and private right of action

The private right of action is significant — it means individual consumers can sue, not just regulators. Other states are considering similar legislation.

GDPR (EU/EEA users)

If your app serves users in the European Union, health data is a “special category” under GDPR with additional protections:

• Explicit consent required for processing health data
• Data minimization — collect only what’s necessary
• Right to erasure — users can request deletion
• Data Protection Impact Assessments required for high-risk processing
• 72-hour breach notification to supervisory authorities
• Data residency considerations for cross-border transfers

State consumer privacy laws

California (CCPA/CPRA), Colorado, Connecticut, Virginia, and other states have comprehensive privacy laws that apply to health data collected by non-HIPAA entities. The specific requirements vary, but common elements include consumer access rights, deletion rights, opt-out mechanisms, and data sale restrictions.

What HIPAA actually requires: the three rules

For product teams that do need HIPAA compliance, the regulation has three core components:

The Privacy Rule

Governs how PHI is collected, used, disclosed, and retained [7]:

• Minimum necessary standard — access only the PHI needed for the specific purpose
• Patient rights — access to their data, amendment requests, accounting of disclosures
• Use and disclosure limitations — PHI can only be used for treatment, payment, healthcare operations, or with patient authorization
• De-identification standards — Safe Harbor (remove 18 identifiers) or Expert Determination methods

The Security Rule

Requires administrative, physical, and technical safeguards for electronic PHI (ePHI) [7][8]:

Administrative safeguards:

• Designated security officer
• Workforce security training
• Access management procedures
• Incident response plan
• Risk analysis and management

Physical safeguards:

• Facility access controls
• Workstation security
• Device and media disposal procedures

Technical safeguards:

• Access controls (unique user identification, automatic logoff)
• Audit controls (logs of who accessed what, when)
• Integrity controls (mechanisms to prevent unauthorized ePHI alteration)
• Transmission security (encryption in transit)

The Breach Notification Rule

Requires notification within 60 days for breaches affecting 500+ individuals. Smaller breaches must be logged and reported annually [7].

The 2026 Security Rule update: what’s changing

The HHS proposed major HIPAA Security Rule amendments in December 2024, with the final rule expected by May 2026 [8][9]. These represent the most significant security updates since the rule’s original adoption in 2003.

Key changes

Encryption becomes mandatory. The current rule classifies encryption as “addressable” — meaning organizations can document why they chose not to encrypt and implement an alternative. The proposed rule makes encryption of ePHI at rest and in transit required, eliminating the opt-out [8][9].

MFA is required. Multi-factor authentication for all systems accessing ePHI is moving from best practice to explicit requirement [8][9].

Annual risk assessments. Comprehensive security risk assessments become mandatory on a 12-month cycle, including threat identification, vulnerability assessment, and technology asset inventory [8][9].

Network segmentation. Systems containing ePHI must be segmented from general-purpose networks [9].

72-hour restoration. Critical systems must be restorable within 72 hours of an incident [8][9].

Business associate oversight. BAAs must include annual written confirmation of technical safeguards, and business associates must provide 24-hour incident notification [9].

No more “addressable” vs “required.” The proposed rule eliminates the distinction entirely — all safeguards become required with limited, documented exceptions [10].

What this means for product teams

If you’re building for healthcare customers, design your architecture assuming all proposed requirements will become final. The direction is clear: stricter encryption, mandatory MFA, continuous risk assessment, and tighter vendor oversight. Building to this standard now avoids costly retrofitting later.

Evaluating a health data API for compliance

When choosing a health data API for a regulated use case, evaluate across these dimensions:

1. Certifications and agreements

SOC 2 Type 1 vs Type 2: Type 1 evaluates control design at a point in time. Type 2 evaluates operating effectiveness over 6–12 months [11]. For health data, Type 2 is the meaningful standard — it proves sustained compliance, not a one-time setup.

2. Data encryption

• In transit: TLS 1.2 or 1.3 with modern cipher suites and perfect forward secrecy [7]
• At rest: AES-256 (or AES-128 minimum) with proper key management via KMS or HSM [7]
• End-to-end: Ideally, data should be encrypted from the user’s device to your backend with the API provider never holding unencrypted PHI unnecessarily

3. Access controls and audit trails

• Role-based access control with least-privilege scopes
• Unique user identification for every API consumer
• Immutable, tamper-evident audit logs recording who accessed what data, when, and from where [7]
• Automatic session termination after inactivity

4. Data handling

• No PHI in logs — the API should not log personally identifiable health data in crash dumps, application logs, or debugging output [7]
• Data retention policies — clear policies on how long data is retained and how it’s deleted
• De-identification support — ability to work with de-identified datasets for analytics
• Data residency options — where data is physically stored, which matters for GDPR and some state laws

5. On-device processing

An API provider that processes health data on-device (computing biomarkers, scores, and insights locally before transmitting) offers inherent privacy advantages:

• Raw sensor data (accelerometer, gyroscope, heart rate samples) can stay on the device
• Only derived, aggregated metrics are transmitted to the cloud
• Reduced surface area for data breaches — less raw PHI in transit and at rest
• Supports data minimization principles across HIPAA, GDPR, and state laws

6. Incident response

• Documented incident response plan
• Defined breach notification timeline (ideally faster than the regulatory minimum)
• Clear communication channels and escalation procedures
• Regular incident response testing

Technical checklist: building on a compliant API

Once you’ve selected a compliant health data API, your own application layer still needs to meet standards. This checklist covers the requirements on your side:

Architecture

• Map all PHI data flows end-to-end: collection → processing → storage → display → deletion
• Ensure no PHI leaks into logs, error messages, analytics events, or client-side caches
• Implement network segmentation between PHI-handling services and general application services
• Use mutual TLS for internal service-to-service calls that transmit PHI

Authentication and access

• Implement MFA for all administrative access and any user access to PHI
• Use OAuth 2.0 with PKCE for user-facing authentication
• Enforce role-based access control with least-privilege scopes
• Implement automatic session termination after inactivity
• Maintain unique user identification — no shared credentials

Encryption

• TLS 1.3 (or 1.2 minimum) for all data in transit
• AES-256 encryption for all PHI at rest (database, backups, file storage)
• Key management through a dedicated KMS — never embed keys in code
• Regular key rotation with documented procedures

Audit and monitoring

• Immutable audit logs for all PHI access events
• Log entries include: user identity, timestamp, data accessed, action taken
• Real-time alerting for anomalous access patterns
• Log retention meeting regulatory requirements (typically 6 years for HIPAA)

Patient rights

• Support data access requests (provide users their PHI in a readable format)
• Support amendment requests (allow users to request corrections)
• Maintain accounting of disclosures (track who PHI was shared with)
• Support deletion requests (for state laws and GDPR where applicable)

Vendor management

• Executed BAAs with all vendors handling PHI (API providers, cloud hosting, analytics, support tools)
• Annual review of vendor compliance status and SOC 2 reports
• Documented procedures for vendor onboarding and offboarding
• Data processing agreements for GDPR-covered data

Risk management

• Annual security risk assessment documented and retained
• Risk mitigation plan with assigned owners and timelines
• Workforce security training (annual minimum)
• Documented incident response plan with defined notification timelines
• Regular penetration testing and vulnerability scanning

The compliance spectrum

Not every health app needs the same level of compliance. Where your product sits on this spectrum determines your obligations:

The practical takeaway: Even if HIPAA doesn’t apply today, the FTC HBNR and state laws create meaningful obligations for any app handling health data. And if your roadmap includes healthcare customers, building to HIPAA standards from the start is cheaper than retrofitting.

The business case for compliance

Compliance isn’t just a cost center. For health data products, it’s a competitive advantage:

• Healthcare customers require it. Hospitals, insurers, and health plans won’t evaluate your product without HIPAA compliance and a willingness to sign a BAA. Compliance opens market segments that non-compliant competitors can’t access.
• Enterprise buyers check for SOC 2. Even non-healthcare enterprises increasingly require SOC 2 Type 2 reports from vendors handling sensitive data. Having it accelerates sales cycles.
• Users trust compliant products. Privacy concerns are a documented driver of health app churn. Transparent compliance practices build the trust that sustains engagement.
• Regulatory direction is clear. Every regulatory update — the HIPAA Security Rule amendments, the FTC HBNR expansion, state health data laws — tightens requirements. Building ahead of the curve avoids disruption.

The product teams that treat compliance as a design constraint rather than an afterthought build architectures that are both more secure and more scalable. The checklist above isn’t overhead — it’s the foundation that makes everything else possible.