HIPAA compliant app development: a founder's checklist

When HIPAA applies to your app

The first question in HIPAA compliant app development is not about encryption. It is whether HIPAA applies to you at all. Plenty of founders spend weeks on compliance work they did not need, and plenty more skip work they did.

HIPAA regulates two groups. Covered entities are health plans, healthcare clearinghouses and healthcare providers who conduct certain transactions electronically, such as billing insurers. Business associates are the vendors that create, receive, maintain or transmit protected health information on a covered entity's behalf.

Most health startups land in the second group. If you sell a patient portal to a clinic, a scheduling tool to a therapy practice or a remote monitoring product to a hospital, you are almost certainly a business associate, and HIPAA applies to the data you handle for them.

When it may not apply

A consumer wellness app that people download and use for themselves, with no covered entity behind it, is often outside HIPAA. A sleep tracker or a meditation app sold direct to the public usually is not handling PHI in the legal sense.

That does not mean you are unregulated. The FTC Health Breach Notification Rule covers many health apps that sit outside HIPAA and requires notice when health data is disclosed without authorisation. A growing number of US states have their own consumer health data laws, some with consent requirements stricter than HIPAA. Your product can also shift categories: the day a clinic starts using your app to manage its patients, the analysis changes.

Map your data flows and your customers early, and get a qualified opinion on which rules apply. This post is a practical checklist, not legal advice. Involve a healthcare compliance professional or lawyer before real patient data goes anywhere near your product.

What counts as PHI

Protected health information, or PHI, is individually identifiable health information held or transmitted by a covered entity or business associate. It covers the past, present or future physical or mental health of a person, the care they receive and payment for that care, when it can be linked to them.

The linkage is the part founders underestimate. A diagnosis on its own is not PHI. A diagnosis next to a name, email address, phone number, date of birth, device identifier or IP address is. HIPAA's Safe Harbor method for de-identification lists 18 types of identifiers that must be removed before data stops counting as PHI.

In practice, these things in your app are likely PHI:

• Appointment records tied to a named patient
• Session notes, care plans and progress reports
• Messages between patients and their care team
• Lab results, prescriptions and uploaded documents
• The simple fact that a named person is a patient of a specific clinic

That last point catches people out. A reminder email that says "Your appointment at the eating disorder clinic is tomorrow" discloses health information even though it contains no diagnosis.

When in doubt, treat the data as PHI and design for it. Loosening a control later is easy. Tightening one after a launch is not.

Business associate agreements with every vendor

A business associate agreement, or BAA, is the contract that lets a vendor handle PHI. Your covered entity customers will ask you to sign one. In turn, you need a BAA with every subcontractor that touches PHI on your behalf.

For a typical health app MVP, that list includes:

• Your cloud provider (the major platforms sign BAAs, but only for a defined list of eligible services)
• Your database host, if it is separate from your cloud
• Email and SMS providers that send messages containing PHI
• Video calling, file storage and transcription services
• Error tracking and support tools, if PHI could reach them

Check this before you choose your stack, not after. Some popular developer tools do not offer a BAA at all, and some offer one only on enterprise plans. Discovering that in month three means migrating live data. A signed BAA also does not make a service safe by default: you still have to configure it correctly.

The HIPAA compliance checklist for your build

The HIPAA Security Rule groups its requirements into three kinds of safeguard for electronic PHI. Here is what each one means for a small team shipping an MVP.

Administrative safeguards

• A documented risk analysis of where PHI lives, who can reach it and what could go wrong
• A named person responsible for security
• Written policies for access, incident response and data backup
• Security training for everyone with access, including contractors

Physical safeguards

Your cloud provider handles the data centre. You still own the devices your team uses: disk encryption, screen locks, and a rule that PHI never sits on a laptop or in a downloads folder.

Technical safeguards

• Encryption in transit and at rest. TLS on every connection, encrypted databases, encrypted backups and encrypted file storage. Under the current Security Rule, encryption is technically "addressable", which means you either implement it or document why an equivalent measure is reasonable. In practice, treat it as mandatory.
• Access control and least privilege. Unique user accounts, role-based permissions, and the minimum access each role needs. A receptionist does not need clinical notes. A developer does not need production PHI to fix a button.
• Authentication. Strong passwords, multi-factor authentication for staff and admin users, and automatic session timeouts.
• Audit logs. A record of who viewed, created, changed or deleted PHI, and when. Make the logs tamper-resistant and keep them reviewable.
• Integrity controls. Protection against PHI being altered or destroyed improperly, including tested backups you can actually restore.

Collect less, keep less

HIPAA's minimum necessary standard asks you to limit uses and disclosures of PHI to what a task actually requires. For a product team, the cheapest safeguard is data you never collected. If your MVP does not need a date of birth or a home address to test the idea, leave those fields out. Decide early how long you keep records, how users can request their data and how deletion works, because those answers shape your database design.

None of this is exotic. It is good engineering with a paper trail. The hard part is applying it consistently from the first commit instead of bolting it on later.

Where PHI quietly leaks: logs, analytics and notifications

Most compliance failures in early health products are not dramatic hacks. They are ordinary engineering habits that send PHI somewhere it should never go.

• Application logs. Debug logging that prints a full request body will happily write patient names and notes into a log service that has no BAA. Log identifiers and event types, never record contents.
• Error tracking. Crash reports often capture the state of the screen or the request. Scrub them, or use a tool covered by a BAA.
• Analytics and tracking pixels. Page URLs like /patients/jane-doe/diagnosis sent to an ad or analytics platform are a disclosure. Regulators have taken a firm line on tracking technologies on health websites and apps.
• Push notifications and emails. Lock screens are public. Send "You have a new message" and make the user sign in to read it.
• Test environments. Copying production data into staging puts PHI in a less protected place. Use synthetic data.

Breach notification and the certification myth

Breach notification basics

If unsecured PHI is breached, the HIPAA Breach Notification Rule requires notice to the affected individuals without unreasonable delay and no later than 60 days after discovery. Larger breaches also trigger notice to HHS and, above a threshold, to the media. As a business associate, your duty is to notify the covered entity, and your BAA will usually set a tighter deadline.

Encryption that meets HHS guidance matters here: PHI that is properly encrypted is generally not "unsecured", which can change whether a lost device becomes a notifiable breach. Write your incident response plan before you need it.

There is no official HIPAA certification

No government body certifies apps or vendors as HIPAA compliant. HHS does not endorse any certification. Third-party audits and attestations can help when selling to hospitals, but "HIPAA certified" on a vendor's website is a marketing claim, not a legal status. Compliance is ongoing work that you maintain as the product changes.

Our approach to HIPAA compliant app development

Our view is simple: test the care idea fast, but do not gamble with patient data to do it. We ship a working healthcare app MVP in 10 days, with audit logging, role-based access control, encryption at rest and a no-PHI-in-logs rule in the code from the first commit. Because the code carries forward into production, the safeguards you start with are the ones you scale with.

Patient data is often only half the product. For mjiya, a therapy platform for centres working with specially abled children and adults, we built patient records, sessions and plans into one system alongside interactive wall activities and progress reports, across desktop, web and app. Depending on your product, that might be a patient-facing mobile app, a web-based portal for clinical teams, or EHR integrations over HL7 and FHIR that move clinical data in and out cleanly.