Skip to content
Insights

HIPAA compliant app development: what the rules ask of your software

HIPAA compliant app development is mostly ordinary good engineering, written down and applied to every system that touches patient data, including the ones nobody thinks of as part of the app. This guide covers who the rules apply to, what they require of the software, and the mistakes that cause trouble most often. It uses HHS's own guidance, checked on 25 September 2026.

Guide Updated 7 min read 8 sources

A steel clinic tray holding a blank file card and a small padlock with a blue shackle.
On this page

Does HIPAA apply to your app?

HIPAA applies to covered entities (health plans, health care clearinghouses, and health care providers who conduct standard transactions such as insurance claims electronically) and to their business associates, the vendors that create, receive, maintain or transmit protected health information on their behalf.

So the first question is who the app is for:

  • A patient portal, scheduling tool, intake form or clinical app built for a practice, hospital or health plan handles protected health information. HIPAA applies, and the company that builds or hosts it is usually a business associate.
  • A consumer health app that people download and use for themselves, with no covered entity behind it, is generally outside HIPAA. It isn't outside regulation: the FTC's Health Breach Notification Rule covers makers of health apps and connected devices, and its July 2024 amendments say so explicitly.
  • An app that starts as a consumer product and later exchanges data with providers can move from the second group into the first. Design for that at the start if it's on the roadmap.

What the Security Rule asks of the software

The HIPAA Security Rule sets administrative, physical and technical safeguards for electronic protected health information. It doesn't name technologies. It sets standards, and the risk analysis in 45 CFR 164.308 decides how you meet them. In engineering terms, the technical safeguards in 45 CFR 164.312 turn into these requirements:

SafeguardWhat it means in the app
Access controlA unique login for every user, roles that limit each person to the records they need, automatic logoff, and a documented way to reach data in an emergency
Audit controlsA log of who viewed, created, changed or exported each record, kept where users can't edit it
IntegrityProtection against records being altered or destroyed without authorization, and a way to detect it
AuthenticationProof that each user and each connected system is who it claims to be. For staff logins that usually means multi-factor authentication, which the proposed update below would require
Transmission securityEncryption for data moving between the app, its servers and every connected service
Encryption at restCurrently an addressable specification, which means you implement it or document why an alternative is equivalent. Most modern systems encrypt anyway

Three things catch teams out even when the list above is done:

  • Logs and error reports. An error-tracking tool that captures request bodies will collect patient data along with the error. Scrub it before it leaves the app, or treat that tool as a business associate.
  • Backups and restores. Until you have restored from a backup, you don't know it works. Test the restore and write down how long it took.
  • Test data. Production records copied into a test environment carry the same obligations as production. Use synthetic data.

Every vendor that touches patient data needs a BAA

A cloud provider that stores electronic protected health information for a covered entity or business associate is itself a business associate, even if the data is encrypted and the provider has no key to read it. HHS says a business associate agreement is required either way.

Count every service in the path, including the ones added late in a project:

  • Hosting, databases, file storage and backups.
  • Email and text messaging, for appointment reminders and password resets.
  • Error tracking, logging and monitoring.
  • AI model APIs, speech-to-text services and call recording.
  • Customer support and help-desk tools, if staff paste patient details into tickets.

If a vendor won't sign a BAA, it can't handle protected health information. The fix is to keep that data away from the vendor, for example by sending only an ID, or to choose a different vendor. For AI features, a third option is to run the model on your own infrastructure. We did this for a 26-provider dental group: speech recognition and an open-weight language model run on a server inside the practice, so patient audio never leaves its network. Read the case study.

The tracking-pixel trap

Analytics and advertising scripts can leak patient data from a health app without anyone deciding to share it. HHS's bulletin on online tracking technologies says the HIPAA rules apply when information collected through tracking technologies on a regulated entity's website or mobile app includes protected health information.

On June 20, 2024, a federal court in Texas vacated one part of that bulletin, covering tracking on unauthenticated public web pages about health conditions or providers. The rest of the bulletin stands, and HHS has said it is evaluating its next steps. For an app, the practical rule is simple: no third-party tracking scripts or SDKs inside anything a patient logs in to, unless the vendor has signed a BAA and the data sent is limited to what the BAA allows.

If there is a breach

The Breach Notification Rule sets the clock. Affected individuals must be told without unreasonable delay and no later than 60 days after the breach is discovered. A breach affecting more than 500 residents of a state or jurisdiction also requires notice to prominent media there, on the same timeline. Breaches affecting 500 or more people are reported to HHS within the same 60 days. Smaller breaches can be logged and reported to HHS within 60 days of the end of the calendar year.

The engineering consequence: you need to be able to say exactly whose records were exposed. That answer comes from the audit log. An app that can only say "the database may have been accessed" has to treat every patient in it as affected.

The proposed update to the Security Rule

HHS published a proposed rule to strengthen the Security Rule on January 6, 2025. Among other changes, HHS's fact sheet says it would:

  • Remove the distinction between required and addressable specifications, with limited exceptions.
  • Require encryption of electronic protected health information at rest and in transit, and multi-factor authentication, each with limited exceptions.
  • Require a technology asset inventory and a network map showing how the data moves, reviewed at least every 12 months.
  • Require written procedures to restore certain systems and data within 72 hours.
  • Require vulnerability scanning at least every six months and penetration testing at least every 12 months.

It is still a proposal. In the Fall 2025 Unified Agenda, HHS listed the final rule for July 2027. The requirements match what a well-built app does already, so building to them now costs little and avoids a retrofit later.

"HIPAA certified" doesn't exist

No government body certifies software or vendors as HIPAA compliant. HHS says it does not endorse or recognize private organizations' certifications regarding the Security Rule, and that such a certification does not relieve a covered entity of its obligations. When a vendor calls its product "HIPAA certified", ask instead whether it will sign a BAA, for its risk analysis, and for independent evidence of its security program, such as an ISO/IEC 27001 certificate or a SOC 2 report.

A checklist before you build

  • Decide whether HIPAA or the FTC rule applies, and write down why.
  • List every system and vendor the data will touch, and get a BAA for each one that handles protected health information.
  • Do the risk analysis before the architecture is fixed, and let it choose the safeguards.
  • Build roles, audit logging, MFA and encryption into the first release.
  • Keep third-party trackers out of anything behind a login.
  • Keep patient data out of logs, error reports and test environments.
  • Test a restore from backup, and time it.
  • Plan how you will tell which patients were affected if something goes wrong.

How we work on health software

We sign Business Associate Agreements, and we are certified to ISO/IEC 27001:2022; the certificate and its scope are published. For voice and AI features, we can run the models inside your network, as described on our private AI and AI voice agents pages. If you run a dental practice, our guide to whether to subscribe to an AI receptionist or build one covers the vendor questions in detail.

HIPAA compliance is the responsibility of the covered entity and each business associate. We build software that supports it and document how, and this guide is general information, not legal advice.

Sources

// FIXED-FEE EVALUATION

The Automation Audit

One workflow you name, mapped end to end, with the arithmetic done before anyone writes code.

Scope
One workflow you choose, traced end to end, including the steps nobody documented.
Duration
Two weeks, fixed.
Fee
Fixed, and quoted in full before we start. No hourly drift.
You get
A written map: what can be automated, what it would save in hours, what building it would cost, and what we would leave alone.
You keep it
The map is yours whether or not you hire us to build anything.
The TechLand Commitment

And if the audit shows the automation will not pay for itself inside twelve months, we will tell you, and we will not quote the build.

Start with the audit

Keep reading

All guides