HIPAA Compliance for Apps: What Healthcare Businesses Must Know

In 2023, a telehealth startup settled with the FTC for $7.8 million after sharing patient health data with advertising platforms. The company had used tracking pixels from Meta and Google on its platform. Every time a patient booked an appointment or filled out an intake form, that data was shared with ad networks.

The company's developers didn't intend to violate HIPAA. They added standard marketing analytics - the same scripts running on millions of non-healthcare websites. But on a healthcare platform, those scripts transmitted protected health information to third parties without authorization or a Business Associate Agreement.

This story isn't unusual. The HHS Office for Civil Rights investigates every reported breach affecting 500 or more individuals. And most healthcare data breaches trace back to the same root cause: the app was built like a regular product, not a regulated one.

Who HIPAA Applies To

HIPAA covers two categories of organizations:

Covered entities - healthcare providers (doctors, hospitals, clinics, pharmacies), health plans (insurance companies, HMOs, government programs), and healthcare clearinghouses (organizations that process health information).

Business associates - any organization that creates, receives, maintains, or transmits PHI on behalf of a covered entity. This is where app developers usually fall.

If a hospital hires your company to build a patient portal, you're a business associate. If a health plan uses your app for member engagement, you're a business associate. If an insurance company integrates your AI tool into their claims processing, you're a business associate.

The gray area: consumer health apps that aren't connected to a covered entity may not be subject to HIPAA - but they may still be regulated by the FTC's Health Breach Notification Rule. And the moment a consumer health app integrates with a provider's EHR system or is prescribed as part of treatment, HIPAA kicks in.

What Counts as Protected Health Information

PHI is any individually identifiable health information. HIPAA lists 18 specific identifiers that make health data "individually identifiable":

1. Names
2. Geographic data smaller than a state
3. Dates (birth, admission, discharge, death) except year
4. Phone numbers
5. Fax numbers
6. Email addresses
7. Social Security numbers
8. Medical record numbers
9. Health plan beneficiary numbers
10. Account numbers
11. Certificate/license numbers
12. Vehicle identifiers and serial numbers
13. Device identifiers and serial numbers
14. Web URLs
15. IP addresses
16. Biometric identifiers
17. Full-face photographs
18. Any other unique identifying number or code

The combination matters. "Patient has Type 2 diabetes" isn't PHI by itself. "John Smith at 123 Main St has Type 2 diabetes" is PHI. Remove or encrypt all 18 identifiers, and the health data becomes de-identified - no longer subject to HIPAA's privacy protections.

HIPAA's Three Rules

HIPAA compliance rests on three rules. Your app needs to address all three.

The Privacy Rule

The Privacy Rule controls who can access PHI and under what circumstances.

Minimum Necessary Standard - Users should only see the minimum amount of PHI required for their specific role. A billing clerk doesn't need to see clinical notes. A nurse doesn't need to see insurance payment details. Your app's role-based access controls must enforce this at the data level, not just the page level.

Patient rights - Patients can request access to their records, request corrections, request an accounting of disclosures, and request restrictions on who can see their data. Your app needs workflows to handle each of these requests.

Authorization requirements - Sharing PHI outside of treatment, payment, and healthcare operations requires the patient's written authorization. Marketing communications, research use, and sharing with third parties all require explicit authorization.

The Security Rule

The Security Rule applies specifically to electronic PHI (ePHI) and requires three types of safeguards:

Administrative safeguards:

• Designate a security officer
• Conduct a risk assessment (and document it)
• Implement workforce training on PHI handling
• Create contingency and disaster recovery plans
• Establish policies for access management and termination

Physical safeguards:

• Control physical access to systems that store ePHI
• Workstation security policies
• Device and media controls (encryption on portable devices, secure disposal)

Technical safeguards:

• Access controls (unique user IDs, emergency access procedures, automatic logoff, encryption)
• Audit controls (track all access to ePHI)
• Integrity controls (protect ePHI from improper alteration or destruction)
• Transmission security (encrypt ePHI in transit)

The Breach Notification Rule

When a breach of unsecured PHI occurs, HIPAA requires:

• Individual notification within 60 days of discovery - written notice to every affected individual
• HHS notification - within 60 days for breaches affecting 500+ people; annual reporting for smaller breaches
• Media notification - for breaches affecting 500+ residents of a state, notify prominent media outlets in that state
• Business associate notification - BAs must notify the covered entity within the timeframe specified in their BAA (typically 30 days or less)

How HIPAA Affects Your App Architecture

Every HIPAA requirement maps to a specific architecture decision. Here's what your development team needs to build.

Encryption

PHI must be encrypted at rest and in transit. This isn't optional and there's no "we'll add it later" path.

At rest: AES-256 encryption for all databases, file storage, and backups that contain PHI. This includes your production database, staging environments with real data (don't do this), and backup files.

In transit: TLS 1.2 or higher for all data transmission. Every API call, every websocket connection, every file transfer that carries PHI must be encrypted.

The subtle requirement: encryption key management. The encryption is only as strong as the key management. Keys should be stored separately from the encrypted data, rotated on a schedule, and access to keys should be logged and restricted.

Access Controls

HIPAA requires role-based access that enforces the Minimum Necessary Standard.

Your app needs:

• Unique user identification for every person who accesses PHI
• Role-based permissions that restrict access to the minimum PHI required for each role
• Emergency access procedures (break-glass access for emergency situations, with mandatory audit)
• Automatic session timeout after a period of inactivity
• Multi-factor authentication for remote access to PHI

Audit Logging

Every access to PHI must be logged. Who viewed what, when, from where, and what they did with it.

Your audit log needs to capture:

• User identity (who)
• Action taken (viewed, created, modified, deleted, exported, printed)
• PHI records affected (what)
• Timestamp (when)
• Source (IP address, device, location)

These logs must be tamper-proof, retained for a minimum of 6 years, and available for inspection during an audit. This isn't your standard application logging - it's a regulated record that could be reviewed by federal investigators.

Business Associate Agreements

Every third-party service that touches PHI needs a signed BAA. No BAA, no PHI in that service.

Data Backup and Disaster Recovery

HIPAA requires a documented contingency plan that includes:

• Data backup procedures with encrypted backups
• Disaster recovery procedures with defined RTOs (recovery time objectives)
• Emergency mode operation plan
• Regular testing of backup and recovery processes

Your backup data is still PHI. It needs the same encryption and access controls as your production data. And if a patient exercises their right to have data deleted, you need a strategy for handling their data in backups.

What HIPAA Compliance Costs

For a typical health app build:

Total: 15-25% of a standard app build. For a $150K healthcare app, budget $22K-$37K for HIPAA compliance.

Retrofitting? Multiply by 3-5x. You're modifying production systems, migrating data to encrypted storage, replacing non-compliant vendors, and documenting everything retroactively.

Questions to Ask Your Development Partner

1. "Have you built HIPAA-compliant apps before? Which ones?" - Past experience in healthcare development is the strongest signal. Ask for specific examples of how they handled PHI encryption, audit logging, and BAAs.

2. "Will you sign a Business Associate Agreement?" - If your development partner will handle any PHI during development (including test data based on real records), they need a BAA. A partner who hesitates here hasn't done this before.

3. "How do you handle PHI in development and testing environments?" - The right answer: synthetic data that mirrors production structure without containing real PHI. The wrong answer: copying production data to staging.

4. "How do you implement the Minimum Necessary Standard in role-based access?" - Look for data-level access controls, not just page-level. A billing user shouldn't see clinical notes even if they're on a shared data model.

5. "What's your approach to audit logging for PHI access?" - They should describe an append-only, tamper-evident log that captures who, what, when, and where. If they mention "we can add logging later," that's a red flag.

6. "Which cloud services do you recommend, and are they HIPAA-eligible?" - Not all AWS/GCP/Azure services are covered by their BAAs. Your partner should know which services they can and can't use with PHI.

Your HIPAA Compliance Checklist

Before development starts:

• Confirm HIPAA applies to your app (covered entity, business associate, or PHI handling)
• Sign a BAA with your development partner
• Identify all third-party services that will touch PHI
• Sign BAAs with all PHI-touching services (or replace non-compliant ones)
• Define user roles and minimum necessary access levels

During development:

• Use synthetic test data - never real PHI in development environments
• Build AES-256 encryption for all PHI at rest
• Enforce TLS 1.2+ for all PHI in transit
• Build role-based access with minimum necessary enforcement
• Build tamper-proof audit logging for all PHI access
• Build automatic session timeout and MFA for remote access
• Build patient rights workflows (access, correction, restriction requests)
• Build breach detection and notification capabilities

Before launch:

• Complete a risk assessment and document findings
• Document all policies and procedures (access management, incident response, contingency plan)
• Train all workforce members who will access the system
• Test the full audit trail - can you produce a report of all PHI access for a specific patient?
• Test breach notification workflow end to end
• Verify all BAAs are signed and current
• Verify encryption covers all PHI storage locations including backups

HIPAA compliance isn't a checkbox you mark once. The Security Rule requires ongoing risk assessments, regular policy reviews, and continuous workforce training. Build the foundation right, and ongoing compliance becomes a maintenance task - not a constant emergency.