Building a HIPAA-compliant app: what founders need to know

Key points

• HIPAA follows the customer, not the data type: it applies when you are a covered entity or work for one as a business associate.
• Protected health information is identifiable health information held by those organizations, including names, dates and other identifiers linked to care.
• Every vendor that creates, receives, keeps or sends PHI for you needs a business associate agreement: cloud, email, logging, analytics and AI model providers included.
• The Security Rule asks for access control, audit logs, integrity checks, authentication and transmission security, all chosen through a documented risk analysis.
• There is no official HIPAA certification: HHS does not endorse or recognize private certifications, so a “HIPAA certified” badge is a vendor’s claim, not a government one.
• A consumer health app outside HIPAA can still owe breach notices under the FTC’s rule, and other countries, such as the EU and the UK, treat health data as a special category.

Who HIPAA applies to

HIPAA is a US law, and its rules apply to two kinds of organization. Covered entities are health plans, health care clearinghouses, and health care providers that send health information electronically in connection with transactions HHS has adopted standards for, such as billing insurers. Business associates are people or companies, other than a covered entity’s own staff, that create, receive, keep or send protected health information on a covered entity’s behalf. A business associate’s own vendors that handle that information are business associates too.

Most startups building health software are business associates: a clinic, a hospital or an insurer is the customer, and the app handles its patients’ information. Whether HIPAA applies depends on who you work for and why, not on how medical the data looks.

What counts as protected health information

Under the Privacy Rule, protected health information, or PHI, is individually identifiable health information held or sent by a covered entity or business associate, in any form: electronic, paper or spoken. It covers information about a person’s past, present or future physical or mental health, the care they receive, or what is paid for that care, when it identifies them or could reasonably be used to. HHS lists common identifiers such as name, address, birth date and Social Security number. The electronic kind, ePHI, is what the Security Rule protects.

In an app that means more than medical records. An appointment time linked to a patient’s email, a push notification naming a clinic, or a support ticket that mentions a diagnosis can all be PHI. Information that has been properly de-identified is not restricted. HHS recognizes two ways: a formal determination by a qualified statistician, or removing a specified list of identifiers with no actual knowledge that what remains could identify the person.

The Privacy, Security and Breach Notification Rules

The Security Rule is deliberately flexible. HHS calls it scalable and technology neutral: it does not name products, and each organization chooses measures that fit its size and risks, starting from a documented risk analysis. Some specifications are required; others are addressable, which does not mean optional. You implement an addressable one when it is reasonable and appropriate, or document why not and what you do instead. HHS has also proposed changes to the Security Rule, so check the current text before you design around it.

Under the Breach Notification Rule, a covered entity must notify affected people without unreasonable delay and no later than 60 days after discovering a breach of unsecured PHI, and must also notify HHS and, for larger breaches, the media. A business associate must tell the covered entity. PHI encrypted as HHS guidance specifies is not unsecured, so a lost encrypted laptop or a leaked encrypted backup does not trigger those notices. That makes encryption one of the most useful decisions in the build.

A BAA with every vendor that touches PHI

A business associate agreement, or BAA, is the contract that lets PHI flow to someone else. It sets out what the vendor may do with the information, commits it to the Security Rule, and obliges it to report security incidents and breaches. HHS’s guidance on cloud computing is blunt: a cloud provider that stores or processes ePHI is a business associate even if it only holds encrypted data and has no key.

Founders usually think of the database host. The list is longer:

• Cloud hosting, databases, file storage and backups.
• Email and text message delivery, when messages carry anything about a patient’s care.
• Error tracking and logging. A stack trace or request log can capture a patient’s details without anyone meaning it to.
• Analytics, session replay and tracking pixels. HHS warns that sharing PHI with tracking vendors without a permitted basis is an impermissible disclosure; a federal court vacated part of that guidance in 2024, about unauthenticated public pages, but pages behind a login are a different matter.
• Customer support, chat and video tools, when patients or staff discuss care in them.
• AI model providers. A prompt that contains PHI sends it to that provider. Use one that will sign a BAA for the service you call, or keep PHI out of the prompt; How to integrate AI into your app covers the wider design.

Map where data flows before you choose tools. For each vendor on the path, either sign a BAA that covers the specific services you use, or design the flow so PHI never reaches it. A vendor offering a BAA does not make every one of its products covered, so check the list in the agreement.

The technical safeguards, in product terms

• Access control. Only authorized people reach ePHI. In the product that means a unique account for every user, roles that limit what each can see, automatic logoff and a planned way to reach data in an emergency; see What is RBAC?.
• Audit controls. Record and be able to review who viewed, changed or exported which records, in the product and in admin tools, and keep the logs where they cannot be quietly edited.
• Integrity. Measures to confirm ePHI has not been improperly altered or destroyed, such as checksums, versioned records and restricted delete rights.
• Authentication. Verify that a person is who they say they are: strong sign-in for patients, multi-factor authentication for staff and administrators.
• Transmission security. Protect ePHI sent over networks, with encryption in transit on every connection, including between your own services.
• Encryption at rest. Addressable, not optional, and the line between a reportable breach and a lost file nobody can read.

The administrative safeguards carry as much weight: a named security official, a risk analysis you repeat when things change, workforce training, an incident procedure, and a contingency plan with backups you can restore. On mobile, keep PHI out of push notification text and screenshots of the app switcher, and encrypt anything cached on the device; Mobile app security best practices goes further. The rest of the application-level work is in the Web app security checklist.

Consumer health apps: outside HIPAA, not outside the law

Plenty of health apps are not covered by HIPAA: a diet app, a fitness tracker, a period or sleep tracker people install on their own. The FTC says that does not leave the data unprotected. It enforces Section 5 of the FTC Act against deceptive or unfair practices, and the Health Breach Notification Rule, which applies to vendors of personal health records, related entities and their service providers that are not covered by HIPAA. Amendments in July 2024 made clear that health apps and connected devices are covered.

Under that rule, a breach is not only a hack. The FTC gives the example of sharing users’ health information and device identifiers with an ad network without consent: that is an unauthorized disclosure, and it triggers notices to users, the FTC and in some cases the media. As under HIPAA, information encrypted as HHS guidance specifies is not unsecured. State laws can add their own duties on top.

Outside the US: health data is a special category

Other countries regulate health data through their general data protection laws rather than a health-specific one. In the EU, the GDPR defines data concerning health as personal data about a person’s physical or mental health, including the care they receive, and Article 9 prohibits processing it unless an exception applies, such as explicit consent. The UK’s data protection regulator, the ICO, explains that under UK GDPR you need both a lawful basis under Article 6 and a separate condition under Article 9, and a data protection impact assessment for processing likely to be high risk. Other countries have their own rules, so check each market you serve.

There is no HIPAA certification

HHS states that no standard requires an organization to certify its compliance with the Security Rule, that it does not endorse or recognize private organizations’ certifications, and that such a certificate does not absolve anyone of their obligations. An outside evaluation can still be useful as the periodic evaluation the rule requires. What counts is the risk analysis, the safeguards, the agreements and the records, kept up as the product changes.

1. Work out whether HIPAA applies: who your customers are, and whether you handle PHI for them.
2. Map every place PHI is created, stored, sent and logged, including third-party services.
3. Sign BAAs with every vendor on that map, or redesign the flow so PHI never reaches them.
4. Run and document a risk analysis, then build the safeguards it calls for, starting with access control, audit logs and encryption.
5. Write the policies, name a security official, train the team and plan for incidents and recovery.
6. Repeat the risk analysis when the product, the vendors or the threats change.

This guide is general information, not legal advice. For your own case, start from the HHS and FTC guidance listed below and ask a lawyer who knows health privacy.

At BYD Tech the code lives in the client’s GitHub from day one, IP is assigned to the client, and AI-assisted work is reviewed by an engineer. Whether a product meets HIPAA is decided by how it is run, the agreements around it and the client’s own counsel. Web app development describes how a build starts.