How to make an app HIPAA compliant

First: does HIPAA apply to your app? #

HIPAA applies to covered entities (providers, health plans, clearinghouses) and to their business associates: anyone who creates, receives, stores or transmits PHI on a covered entity's behalf. If you are a clinic building an intake app, you are the covered entity. If you are a software company whose customers are clinics, you are a business associate, and so is every vendor underneath you that can touch the data.

PHI is health information tied to a person: a name next to a diagnosis, an appointment next to a phone number, a claim next to a member ID. A wellness app that a consumer uses alone, with no provider or plan involved, is usually outside HIPAA (other privacy laws may still apply). When in doubt, assume the rule applies and ask counsel.

There is no HIPAA certificate #

The U.S. Department of Health and Human Services does not certify software, and it does not recognise anyone else's certification. A "HIPAA certified" badge is a marketing statement. What a platform can honestly be is HIPAA-eligible: it signs a BAA and provides the controls a compliant deployment needs. Compliance is what you get when you configure those controls correctly and operate the app responsibly.

That distinction is useful, not pedantic. It tells you what to ask a vendor: not "are you HIPAA compliant?" but "will you sign a BAA, and which safeguards do you enforce for me?"

The checklist #

1. Sign a BAA with every vendor that touches PHI. Hosting, database, email and SMS providers, file storage, analytics, AI models. No BAA means PHI may not go there. Keep the signed copies where you can find them.
2. Do a risk analysis and write it down. List where PHI lives, who can reach it, what could go wrong, how likely it is, and what you will do about it. This is the first thing an auditor asks for, and it is the step most teams skip.
3. Map your PHI. Know which tables and which fields hold it. You cannot protect, log or mask what you have not identified.
4. Give every person a unique login, and add a second factor. No shared accounts. Two-factor authentication for staff and for end users who see PHI.
5. Enforce least-privilege access on the server. A nurse sees her patients, a billing clerk sees claims and not clinical notes, a patient sees only their own record. Hiding a column in the interface is not access control; the rule has to be applied where the data is read.
6. Encrypt in transit and at rest. TLS for every connection, encrypted storage for the database, files and backups.
7. Keep an audit trail of PHI access. Who viewed or changed which record, when, from where, and whether it succeeded. Review it on a schedule; a log nobody reads protects nobody.
8. Set automatic logoff and a password policy. Unattended sessions on shared clinic computers are a common finding.
9. Keep PHI out of side channels. Exports, PDFs, email notifications, error logs, URLs and analytics events are where PHI leaks once the main screens are locked down.
10. Back up and test the restore. Availability is part of the Security Rule.
11. Train your workforce and name your officials. A Security Official and a Privacy Official, training records, and a sanctions policy.
12. Have a breach plan. Who decides, who is notified and by when. Affected individuals must be told without unreasonable delay and no later than 60 days after discovery.
13. Keep the documentation for six years. Policies, risk analyses, BAAs, training records.

What a platform can carry, and what stays with you #

If you write the app from scratch, all thirteen items are yours, including the ones that take an engineering team months: permission enforcement, audit logging, encryption, session handling, backups. Building on a HIPAA-eligible platform moves most of the technical rows to the vendor's side of the BAA. The administrative rows never move.

How the checklist maps to Tadabase AI #

Tadabase AI is HIPAA-eligible: on HIPAA-eligible plans we sign a BAA and run your app on BAA-covered AWS infrastructure. Here is what the product does for each technical row above, in the terms you will see on screen.

• HIPAA is a switch on an app, not a rebuild. You enable it per app from the Compliance Center or the app's settings, including on an app you have already built. The plan is validated on the server.
• PHI classification down to the field. You flag which tables and fields hold PHI. Classification is also available when you build through the MCP integration.
• Row-level security enforced on the server. Record rules and roles are applied where the data is read, so the same rule covers pages, the API, and the AI-generated React front end.
• A PHI access log. On HIPAA-eligible plans, reads and changes of PHI are recorded with the user, the action, the table and record, the source IP and the result. Values are never written to the log, and exporting the log is restricted to trusted roles.
• Security settings applied by HIPAA setup. Automatic logoff, two-factor authentication for end users and a password policy are set when you turn HIPAA on.
• Encryption. AES-256 at rest and TLS 1.2 or higher in transit.
• The AI works on stand-ins. On a HIPAA app the in-app agent sees consistent pseudonyms in place of real PHI, its reads are logged separately from a person's reads, and it refuses to push PHI through side channels such as exports, reports and PDFs.
• A publish gate. A HIPAA-flagged app is checked before every publish: PHI tables flagged, deny-by-default row-level security on them, secure file fields, access logging on, BAA-covered hosting. A configuration that fails cannot go live, and the publish button lists what remains.
• The paperwork has a home. The Compliance Center records the BAA, your Security and Privacy Officials, breach contacts and workforce-training acknowledgments. Those items are attested by you; the product prompts for them and does not tick them on your behalf.

Five mistakes that fail reviews #

• A BAA with the host but not with the tools around it. The app is covered; the email service that sends appointment details is not.
• Access control in the interface only. The page hides other patients, but the API behind it returns them. Generated front ends are especially prone to this when the security lives in generated code instead of the backend.
• PHI in notifications. A text that says "Your lab results for the diabetes panel are ready" is PHI over an unencrypted channel. Send a link to the portal instead.
• Shared logins at the front desk. The audit trail then proves nothing.
• No written risk analysis. Good controls with no documentation still fail, because the rule asks for the analysis itself.

Common questions #

Is there an official HIPAA certification for software? No. HHS does not certify products and does not endorse private certifications. Ask for a BAA and a list of enforced safeguards instead.

Do I need a BAA if the data is encrypted? Yes. A vendor that stores or transmits PHI for you is a business associate even if it never looks at the data.

Can I build a HIPAA app with an AI app builder? Only if the builder signs a BAA and enforces permissions and logging in the backend, not in the generated code. Many AI coding tools produce a front end and leave hosting, access control and audit logging to you, which puts all thirteen checklist items back on your side.

Can I make an app I already built HIPAA-ready, or do I have to start over? On Tadabase AI you turn HIPAA on for the existing app, classify the PHI tables and fields, and clear the publish gate. Elsewhere it depends on whether your vendors will sign BAAs and whether access control and logging were built into the backend.

How long does it take? The technical side is the short part on a HIPAA-eligible platform. The risk analysis, policies and training take as long as your organisation needs to do them properly, and they are the part an auditor reads first.

Where to start #

Start with the PHI map and the vendor list; both fit on one page and they drive every other step. If you want to see the technical rows handled for you, the healthcare page at tadabase.com/healthcare shows the Compliance Center and the publish gate, and the patient intake, patient case management and medical billing templates at tadabase.com/templates are complete apps you can copy, flag for PHI and adapt. Describe your app in a sentence and build the first version today; talk to us about a HIPAA-eligible plan before real patient data goes in.