Most teams starting HIPAA compliant app development assume the health data itself decides whether the law applies. It doesn't.
What decides it is the relationship between the developer and whoever holds the patient relationship. Get that wrong, and a build either ships without the safeguards it needed, or carries rules it never triggered.
The test is simple to state. When a covered entity such as a hospital contracts with a developer to build an app that handles patient data on its behalf, that developer becomes a business associate and the full Security Rule applies.
A patient who downloads a symptom tracker on their own and connects it to their records themselves usually isn't dealing with anyone's business associate, and HIPAA never covers that data.
Why HIPAA Compliant App Development Starts With the Contract, Not the Code
HIPAA Journal has pointed out the sharper edge of that test. Once a covered entity shares a patient's data with an app the patient chose, and the developer isn't that provider's business associate, the data stops being covered the moment it lands in the app.
That's the gap a lot of patient-facing health apps live in.
It doesn't mean no rules apply there. The FTC's updated Health Breach Notification Rule, finalized in April 2024, covers exactly the apps HIPAA misses: fitness trackers, period trackers, direct-to-consumer apps with no covered entity behind them.
It requires notifying affected users without unreasonable delay once a breach is discovered. The FTC has already enforced it, against GoodRx for sharing health data with advertisers and against Easy Healthcare's Premom for disclosing ovulation data the same way.
Settling which side of that line a build sits on comes before any technical decision below.
What the Proposed Security Rule Changes Would Require
Assuming the business associate relationship exists, HHS's Office for Civil Rights proposed sweeping changes to the Security Rule in January 2025. Arnold & Porter's analysis of the proposal lays out what changes for developers.
Today's rule treats safeguards like encryption and multi-factor authentication as "addressable," meaning a covered entity can adopt an alternative or document why one doesn't apply. The proposal would erase that flexibility for the safeguards that matter most to how an app gets built.
Comments closed in March 2025 and it hasn't been finalized since. Whatever its fate, the safeguards it names are a reasonable baseline for any build handling ePHI.
| Safeguard | Today's rule | Under the 2025 proposal |
|---|---|---|
| Encryption | Addressable, alternatives allowed | Required for all ePHI at rest and in transit |
| Multi-factor authentication | Addressable | Required to reach any system touching ePHI |
| Patch management | No fixed timeline | Written policy, reviewed annually |
| Network segmentation | Not addressed | Required to limit ePHI access to authorized systems |
That table doubles as a checklist. Encrypting ePHI at rest and in transit, and requiring MFA for anyone who can reach the database, covers most of it. Segmenting that database from the rest of the network closes the gap.
None of it is exotic, and our guide to healthcare software development covers building it in from day one rather than retrofitting it later.
Building the Agreements In From the Start
None of the technical work replaces the paperwork. A covered entity needs a signed business associate agreement with the developer, and the developer needs matching agreements with its own vendors, starting with the cloud host and the database provider.
That's the part that gets skipped when a build starts as a fast MVP and only becomes a healthcare product later. Our guide to compliance-first healthcare software development covers sequencing that work so the agreements exist before the first patient record does.
Access control had to hold up before our OptimalMD case study platform could launch at all. Building in-house versus bringing in a team that has already done the paperwork is worth settling that early. Our apps and SaaS team can usually tell within a conversation which one your app needs.
Cover photo by olia danilevich on Pexels
